Sure, when they're 16 years old. Throw a four-year-old out in the middle of a large crowd of unfamiliar people and rational thought is the last thing you can expect. That's why it takes a rational adult to calm them down and ask "Are you lost?"
I wish I could be that parent that never loses their child, but I'm a realist and accept that it can happen, so these tracking devices sound appealing to me for use on very young children who are as of yet incapable of rational, level-headed responses to scary situations like getting lost in a shopping mall.
The key here is what you do BETWEEN age four and age sixteen. Kids need to learn how to handle all sorts of situations on their own. A parent would be unwise to hover closely, then at age 16, say "Here's the car keys, drive safely!" It takes years to build up to that point. Relying on the short-term "security" of GPS trackers only delays the day the child is ready to go solo into the wide world.
Brian Contos has something to sell you and isn't afraid to use FUD to better his chances. The CNN reporter isn't very good either -- obviously he understands buzzwords but not automotive electronics.
Here's the deal... Your car built since the 1990s is loaded with at least a dozen embedded microprocessors, probably more. However, it is likely that at most two are running a mainstream operating system such as Linux or (much as I hate to say this) some form of MS Windows. Those two the "infotainment" and telematics or hands-free phone units. Everything else is a closed, closed, closed system. Even to reflash most automotive electronics requires specialized knowledge and equipment. This is done to keep 3rd party replacement gear out of the car as much as anything else.
So the risks come down to a) unusual combinations of inputs that cause unexpected consequences and b) downloadable apps. You can bet that the auto companies are working hard to prevent the first. If there's ever an "app store" for some car electronics, it will be far more tightly controlled than what's out there for smartphones, again as much for control of what gets into the vehicle as for security. Not that I would personally care to "compute-ify" my car, thank you.
The failures of TFA are that the McAfee guy is applying desktop OS assumptions to embedded systems, and the CNN reporter didn't actually talk to any car guys.
Most of the concerns in this thread have been answered many times in hybrid vehicle and hypermiling forums. But just to address a couple...
Car batteries are sized for a cycle of rapid discharge (seconds), followed by moderate recharge while driving (minutes to hours), followed by very slow discharge when the engine is off (hours to weeks). The details are the secret sauce of electrical system design, hard to find out even from inside the auto industry. One would expect an engine start-stop car to have a larger battery and alternator than a conventional car. One consequence of this typical charge-discharge pattern is that any vehicle driven only on ten-minute trips is guaranteed to have battery problems.
Other facts of life (analysis available from EPA, no less) are that cruising at a steady speed is the highest-mileage mode of any car, while stop-and-go traffic gives the lowest mileage. Successful hybrids have features to deal with both of these extremes of fuel consumption. The start-stop system obviously deals with one aspect of the latter.
I remember news stories from fall 1999. People were seriously concerned that gas, electricity and water utilities would fail, planes would crash, cars would stall and Social Security payments would not get made. Some acquaintances didn't like it when I pointed out that from the first time the Social Security Administration began automating, it had to deal with people born in the 19th century and others would not retire until the 21st. Hospitals replaced medical equipment that could not be certified as Y2K-compatible, instead of testing to see whether there would be any problem.
It got so bad that some New York buildings halted their elevators before the fateful midnight, and the U.S. Secretary of Transportation was riding on a commercial flight at midnight on December 31.
Those of us who wrote software for these machines just laughed and repeated the mantra, "Embedded systems programmers don't use COBOL."
Agreeing with the commenter up-thread, it really is just proprietary stuff. Fred Von Lohmann, usually an astute guy, gets it wrong this time.
Back around 2000 I did some work on diagnostic tools. Engine- and emissions-related trouble codes are industry standard as defined by the Society of Automotive Engineers (SAE). There are plenty of tools that will read these trouble codes. Where it gets interesting is that in various cars, the communication hardware could be UART-based, PWM, in the last few years, mostly CAN, but there were others.
A decade ago, I think it was under a consent decree, the 3 Detroit auto companies had to make diagnostic information available after one year. This being the auto industry, through incestuous business relationships one company got to collect the information, and of course they were the only source for the second year, and after that your friendly neighborhood repair shop could get the information from several sources.
The thing about vehicle buses is that they carry a lot more information besides diagnostics, and this "everything else" is held pretty closely by the auto companies. Dealers get access to at least some of it because repairs are where the cash flow is. Also, making warranty repairs quicker helps the auto companies keep their costs down.
Slashdot readers should realize that the world of embedded software inside the car has very little in common with desktop computing; automotive electronics resemble distributed systems more and more every year; and the shadetree mechanic is SOL these days.
Interesting! a) 3 of the 16 pictures are of cars made by American companies, if you count the Jaguars (Ford) and separately count two pics of pickup trucks, b) the racetrack image is from a Nissan plant in the UK, and 3) Slashdot readers once again race to conclusions. Unless, of course, the parent poster thinks American bailout policy should follow the lead of American manufacturing policy.
They don't have a common-carrier status to lose. Then the obvious step is: petition your congressman to have Internet Service Providers regulated as common carriers. That's the only way we'll get rid of this nonsense for sure.
Going to the Dayton Hamvention this year after a 20 year absence was eye-opening. There just weren't many people under 50 to be seen.
I think several trends are at work in amateur radio right now. First is that advances in chip integration have made it more difficult to homebrew equipment. There are fewer and fewer "catalog" parts around with simple functions. This, plus surface mount packaging, have made electronic products cheaper but electronic experimentation much more difficult for the average person.
Another trend is the commercial annihilation of distance. Talking across the country on two-way radio loses its thrill when one can do the same on a cell phone more or less for free, and much more reliably.
Software Defined Radio (SDR) is a bright spot in ham radio today. Forget about the Big Project flavor of Gnu Radio. Amateur SDR projects tend to be quite simple - sometimes ingeniously so - and approach the subject from the experimenter's point of view, not the engineer's. Most are based on the simple proposition that a recent commodity PC plus sound card make a pretty decent digital signal processor.
Organizations like ARRL and TAPR have encouraged digital radio up to and including SDR, though they have each tried to firmly guide the direction of amateur SDR. In fairness, ARRL has published many articles in its experimenter's magazine and in an excellent online compendium.
Two independent projects show the range of amateur SDR. The SDR-1000 is a hardware/software project turned semi-commercial, with a steep price of entry. Flex Radio Systems also has a unique definition of Open Source. On the other hand, the SDRadio project is an independent software receiver that is slowly morphing into a community effort. The project forum is brimming with good ideas.
There are other, loosely related projects such as narrowband signal processing and Digital Radio Mondiale (broadcast) decoders being done by hams. From these resources it's easy to see SDR as an emerging force in rejuvenating ham radio, even though today the various efforts are quite fragmented.
Has anyone else noticed that the publicity for this car runs way out of proportion to a production run of only 20,000 vehicles this model year? What Ford appears to get is a loss on each Escape, but good "enviro-friendly" PR without having to actually deliver in large quantities.
On a personal note, anyone who signs up for information can expect lots of marketing e-mails from a company that doesn't really understand the opt-out principle. Wait long enough and glossy brochures will show up in your mailbox, too.
Proprietary hardware and OS's in this day and age are redundant. No longer should this be seen as an advantage, because its not.
There are some very powerful disincentives to introducing standardized (i.e. generic) hardware or software into any automobile. Start with the notion expressed in the EE Times article that software from one manufacturer would run on another's hardware. Today the auto industry treats software as if it were free, and pays only for metal boxes with wires coming out of them. The European consortium will have to propose a viable way for software-only vendors to make a profit.
Second, the auto manufacturers, in Detroit at least, are obsessive about keeping control over every aspect of what goes into their vehicles. The incompatible controllers are no accident. A lot of it has to do with parts cost -- at a minimum run of, say, 500,000 for any controller, the auto company can afford to cut pennies by making each one fully customized. (Remember, software is free!)
Third, keep following the money. There is a deliberate effort to get you to maintain and repair your new car at the dealer where you bought it. Cash flow has a huge influence on auto company decisions.
Fourth, between the time a new model rolls off the line and the time your corner garage can get hold of the diagnostic codes for it, two or three years will have passed and at least one company will have made money off the slow proprietary-to-public transition.
Starting to get the picture? The right (cynical?) way to look at the consortium is as a way to drive down the cost of their proprietary products, not as a way to get open software or even software standards into cars. MISRA C is standard, OSEK compliance is becoming standard, but that's about it.
Now, having said all this, I would also guess that the auto industry has recognized the problems of software complexity and development cost. Anyone who's been around, though, recognizes that the reality of software components has never lived up to the hype, and the cost-cutting mentality reigns supreme among the gearheads.
Maybe someone Swiss can throw perspective on this. The Swiss murder rate is low, gun ownership is very high.
Simple... The Swiss state is founded on the principle of permanent armed neutrality. That means a long history of successful defense against invaders and universal military service today. In some Swiss cantons, it is traditional to wear a sword when voting.
John McPhee wrote a fascinating book about the Swiss Army, La Place de la Concorde Suisse, that sheds light on the Swiss view of firearms. Not much of it transfers well to American society, though.
To find out, we have to move past his political machine. Like Bush, Dean is very adept at associating himself with issues and causes that are important for his campaign. Thus for Dean we see his association with Lessig and an apparent concern for "the commons". Nothing could be farther from the truth.
I'm throwing away my chance to mod down some of the comments... Better Slashdotters should look beyond the knee-jerk responses, and respond to what Howard Dean has actually said, as well as what he actually writes in Lessig's blog.
That's the thing about Dean. Anyone who extrapolates from two or three of his positions will miss the point. The man is simply not doctrinaire. I see a person who has actually thought through what he says. This doesn't come through to pigeonholing pundits, nit-pickers and especially to the right-wing echo chamber. Don't believe everything you read in the newspaper.
With Dean you get someone who tempers his principles with a sense of what he can reasonably accomplish. He has the same feet of clay as the rest of us, and more willingness than most politicians to admit it.
Here's a prediction: Dean will say things on Lessig's blog that defy expectations on all sides.
To vnv's point on health insurance: funny how Canada, France and Germany each spend about two thirds per person what we do in the USA, give everyone the same standard of health care, and live longer than Americans in the bargain. This is the elephant in the room everyone is trying to ignore. Dean's proposal is not perfect but at least moves us down the road toward a rational health care financing system. Universal health care was not a Clinton idea, it was Truman's proposal first. Is it so bad that someone is willing to pass up the final goal to straighten out part of the mess, rather than get nothing?
Like many Dean supporters, I came looking with a mixture of anger (at BushCo) and curiosity. I stayed for the common sense.
To find out, we have to move past his political machine. Like Bush, Dean is very adept at associating himself with issues and causes that are important for his campaign. Thus for Dean we see his association with Lessig and an apparent concern for "the commons". Nothing could be farther from the truth.
This falls under the rubric of "telematics." There are good reasons why we get odd little devices in the United States while Europe is headed straight toward nav/traffic/routing convergence.
Boiled down to the two most important points: the business model in the States is subscription-based - OnStar is the grandaddy, and it's not making money. Second, Europe has public broadcasts of traffic information to a continental standard, while in the good ol' USA, proprietary protocols rule and the FCC is spineless.
So until USDOT and its state counterparts get the gumption to propose a public alternative to the private General Motors model, expect slow progress.
Now, the amount of abstraction possible does differ depending on what you're doing. Embedded systems programming is hard, and you do have to know details of the machine. But I ask you - do you insist on a gate-level understanding of the embedded CPU, or will you settle for knowing the opcodes and their timing characteristics?
I work on embedded products. A typical design has about 30,000 lines of C code, but the amount of assembly language is 1% of that and dropping. So there is little need for most of the programmers on a team to know something as concrete as assembly.
Our code runs on 16-bit single-chip microcontrollers rated at about 5 MIPS. The chips are typical of what $5 buys today. The application, which Slashdot readers would recognize instantly, has soft real-time requirements. We could probably run most everything on 20 ms timer ticks and get good responsiveness. There are plenty of spare CPU cycles even at peak loading. Yet there are people in my company who want to read the assembly code generated by our ANSI-standard C compiler, and turn off all the compiler optimizations. Some still insist on writing their own memset() functions.
Contrast this with the fact that it takes us 18 months to develop each new product. The 2003 version is about 80% the same as the 2001 version, about 20% of the code handles product differences from the older version, and there's maybe 5% new code for new features. What's wrong with this picture?
One obvious answer is simple: we're probably using the wrong level of abstraction, or just the wrong abstractions, in our design. We'd do much better to:
Trade off a little performance for shorter project schedules.
Profit!
This is not to say we should never open the black box -- just that we should be smart about when to dig deeply into the underlying hardware and CPU cycles. And being able to debug with an oscilliscope is still sometimes a valuable talent. As others have said here, the art of engineering lies in knowing when to do these things.
Successful black-box design can produce amazing results. For instance, look at Pure-Systems, whose initial product generates an optimized embedded kernel, written in C++, that's small enough to run on an Atmel AVR chip.
This book is not completely without redeeming qualities.
It's been sitting on the shelves of the local Borders Outlet for six months or more, always several in stock, though the price is only $6 or $7. The market speaks...
This thread is turning out better than some others about Extreme Programming, like here and here.
I worked on a project that used XP for most of 2001. It was a liberating experience. We had two domain experts who also acted as XP coaches, which helped a lot. Our biggest problem was convincing some team members to suspend their disbelief long enough to give the XP practices a chance. At the end, we found we were about 50% more productive than similar, non-XP projects, despite spending a lot of time cutting excess code out of the project. About 20% of the source code was devoted to unit tests and mock objects to support the tests.
When budget-cutting forced us to halt development abruptly, we had 12 known bugs. 11 of them were GUI problems, which we could not easily unit test. We had 70-80% unit test coverage, most of it written under the mantra "write the test, then the code." This turned out to be a key factor in our code quality.
Having all those unit tests in an automated test framework gave us tremendous confidence to keep moving forward. This leads to the other key factor TDD provides a project: freedom from fear. Why worry about failing the regression tests at the next code freeze when you can run them every hour?
Our XP project convinced me that one big reason for quality problems in C-language software is the lack of automated unit test tools. Sorry, that's just another good reason to move to OO, even for embedded systems.
TDD is still valuable without the other XP practices. Short development iterations also deserve wider use outside XP.
For all the naysayers... Look, nobody is saying you have to abandon experience, judgement or common sense to use XP. What you have to do is immerse yourself in the experience -- add the flow of programming the XP way to the other tools on your belt. XP is a little harder than riding a bicycle, definitely easier than Tuvan throatsinging, and as hard to describe on the printed page as both.
That said, Kent Beck's testing book is pretty thin. It adds very little to what you'd get from reading Extreme Programming Explained plus the JUnit tutorial. To understand why people "get religion" about TDD, understand why people are religious about the most effective ways to get software development done. Two views that come to the same place from vastly different starting points are Alistair Cockburn's excellent book, Agile Software Development, and the "lean software development" material at Mary Poppendieck's website.
"I am looking for the new RAH/Piers Anthony/Roger Zelazny/Weis & Hickman etc..., of the world.
The trouble with science fiction is that it follows Sturgeon's Law: "90% of everything is crap." Finding that good 10% and stories that suit your individual tastes is pretty tough. Years ago I read Chuq von Ruspach's online "Otherrealms" fanzine, because the reviews there lined up with my tastes better than half the time. That's long gone, and I haven't found anything to replace it. The Ebert and Roeper of SF just plain don't exist. So it's word of mouth, random tries at the bookstore, and the occasional review that makes an impression, that's how I find worthwhile new stuff.
With that disclaimer, here's a short list of authors that are thought-provoking but couldn't be farther from Heinlein, Zelazny, etc., if they tried. Try Orson Scott Card, Neil Gaiman, Nancy Kress, Lisa Mason (stick with the "San Francisco" trilogy), Neil Stephenson (skip Zodiac and Big U), Bruce Sterling (later work). Sharyn McCrumb is a mystery writer who has produced some sharp takes on science fiction fandom.
These authors are all well-established, and their styles run toward the literary side of SF. For tastes that run to swords and sorcery, space opera, hard SF, urban or antediluvean fantasy, hard-boiled cyberpunk, punny adventures -- try someone else.
The only way to find good, new SF may be with every fourth or fifth book, just read someone outside your comfort zone.
It's awfully fun reading desktop programmers commenting on an article in a project management magazine.
Here's a few facts about your new-model car. The BMW is extreme with 70 electronic modules but the typical 2003 vehicle has 20 or 30 microprocessor-controlled modules, and the number is rising every year. These range from a door-switch module with 8K of code, through an engine controller with 256K/32K of ROM/RAM, to a navigation system at 8M/8M. Very few of these modules have a manufacturing cost above $100.
The OS in automotive controllers varies from a simple event loop at the low end through OSEK-compliant kernels in the midrange to QNX and its friends in the most complicated systems. If there's Linux in a controller, it will be as well-hidden as the Linux in Tivo. Engine and transmission controllers are designed for hard real-time operation and emphatically do not use anything remotely resembling a desktop or palmtop OS.
Software development starts with the premise that once it's built, you can't change the it, ever. This has enormous consequences for the way automotive code gets made. Most companies spec the hell out of these products, use a strict waterfall development process, are afraid to venture beyond the C language, and test endlessly. They are scared of agile methodologies and even of RUP. Productivity is pretty low, but on the other hand, the products are reliable.
Now, both the article and/. responses are full of misconceptions. There's not really much question about whether an OS vendor shares its source code. The real concern is reliability. There's not much question about who develops embedded software. Detroit is lousy with contractors. One billboard I see on my commute shows a toy car with the caption "about the only vehicle that doesn't run on our software. -- EDS" The GM guy's comment about 10 year old software has the obvious answer: his teenager's 1993 Chevy.
Win CE gets no respect from embedded software developers for several reasons. Chief among them are poor responsiveness, poor stability and code bloat. Typical comment, from an SAE conference presenter: "If you put an embedded system into a car, you still have a car. If you put a PC into a car, you have a PC with wheels."
Rather than rant any further, let me suggest reading any of the books on Jean Labrosse's site, EE Times and Embedded Systems Programming. And have fun! Embedded is where you can see software affect the real world.
... the technology to create a road surface that is less susceptible to the wear and tear imposed by day-to-day traffic is something that appears to be somewhat elusive.
Uh, no. Cost-longevity tradeoffs in road design are well known to civil engineers. The political importance of jobs created through roadbuilding contracts is well known to their bosses.
Automakers are used to being completely in control of how their products are designed, sold and repaired. Look at what data is available from cars. The emissions and diagnostic data that any garage can read out (OBD-II) is essentially what's mandated by the California Air Resources Board. Newer model years incorporate more and more features to prevent hacking into engine controllers... well, into any embedded controllers in the car.
Look at the business practices of the car companies and you'll see how control is valued over nearly everything else. The Vetronix link in one of the replies is typical. Look at how Vetronix has an exclusive contract and how customers are locked into proprietary cables and software.
Fear also runs rampant in the industry. You want 20 MPG SUVs? The cost is $500 or so, but cost has little to do with why they aren't sold. The higher-ups will do almost anything to avoid upsetting the fabulous cash flow they control. That's why the pace of technological innovation in autos is so slow. There's also a lawsuit mentality in the industry. The perception they might be sued drives their actions far more than any actual lawsuits.
These two reasons, control and fear, are why any crash data recording standard would have to be imposed from outside the industry. They're also why both Bill Gates and Linux geeks are dreaming when they spin the fantasy of "open" car electronics.
On the posted topic: too many Slashdotters didn't RTFA. The NY Times article talks about recording the last few seconds before a crash. That's maybe a few hundred data points. It's not a voice recording or a demerit mark every time you break the speed limit or stand on the brakes.
There are 2 good reasons why the crash recorder would be part of the airbag module. First, the data is already used by the module. Second, the airbags have to deploy even if the car electrical system is hosed, so their power supplies have a "hold-up" time of tens of milliseconds. That's enough time to fire two-stage airbags with the battery disconnected. That's also enough time to write crash data to EEPROM.
Would the kind of recorder in the article make cars more expensive? No. Any cost increase would be in the software engineering before the first car was built, not in the manufacturing cost.
Are there good reasons to have them? Yes, but not what's in the article. One reason flying is a couple of orders of magnitude safer than driving is because the FAA is a lot more concerned with finding the causes of aircraft accidents than with assigning blame. If an agency like NHTSA or an industry group like SAE were to use crash data to improve safety, then the technology makes sense. But don't hold your breath - that kind of activity won't happen until after 2004 at best.
Even if these blimps can only give each subscriber 64k (at a flat rate), that'd already be unbeatable in this area.
Do the math. The claim of 300,000 square mile coverage works out to a 309 mile radius from a spot directly under the balloon. At the edge of this area, a balloon flying 13 miles high would be 2.4 degrees above the horizon. At 18 miles altitude, the look angle at the fringe goes up to only 3 degrees. Doesn't sound like good coverage in a mountain valley, or even at street level with trees and houses in the line of sight.
A reasonable angle above the horizon means a much smaller service area, 30,000 square miles or even less.
Then, how many people will Wi-fi bandwidth reasonably support, as the service area scales up from square meters to square miles? Can this scheme offer cellular phone service without screwing up the key principle of small-area frequency reuse? What services will support the operating costs -- maneuvering fuel plus the ground crew? As I add each of these questions, a balloon-based "antenna tower" looks less and less like a rural common carrier and more like a luxury service for city-dwellers.
OK, lossy compression may cause hearing problems. But wait, there's more! DRM watermarking may cause hearing problems, too. Therefore, we must all buy more (analog) LPs...
Probably the real motive of centralizing the net is to make it a corporate playground rather than a citizens' playground. The bit about "security" is just an excuse for doing it.
Yes and no. Rowan Williams, Archbishop of Canterbury, looked at this kind of government action differently in the BBC Dimbleby Lecture a couple of days ago. He wasn't talking about centralizing the Internet, but it's a typical example. Williams thinks governments centralize control and thrash around for quick results because of their relation to what he calls the 'market state.'
To appreciate his view you have to step back from the view of marshalling technology to defeat vague, anti-democratic forces. Instead, look at the human beings behind the proposal. The motivation behind Internet monitoring isn't evil so much as it is a response to unintended consequences. Back in the '80s, some governments deliberately shrank while the power of weapons, money and ideas to cross national borders grew. While we techies were making bits stand up and dance for fun and profit, the rest of the world kept running on older urges. Let the Archbishop tell the story.
This reading of our present situation is [...] one where the nation state's inability to deliver in the terms we have become used to, its inability to meet the expectations we now bring, has led to a shift into a new political mode, the market state, in which the function of government - and the thing that makes government worth obeying - is to clear a space for individuals or groups to do their own negotiating, to secure the best deal or the best value for money in pursuing what they want. It involves deregulation; the 'franchising' of various sorts of provision - from private prisons to private pensions - and the withdrawal of the state from many of those areas where it used to bring some kind of moral pressure to bear.
So...
In the United States and the UK during the eighties and nineties, government tended to strengthen a culture of prompt accountability, enforceable rights to see value for money in institutions, even those where we'd once have recognised that calculations of profit were not easily applicable. It isn't surprising, then, if the unspoken model of political expectation now is increasingly the consumerist one: the individual confronts the state, asking for what is promised - maximal choice, purchasing power to determine a lifestyle.
The issue is that, like it or not, there are irreversible changes in our international environment that have eroded our confidence in the nation state's possibilities. Those pressures that made the UK and US governments of the last few decades 'roll back the frontiers of the state' were perfectly real, in a world where neither military nor economic security lies with strong national government in the way it might once have done. The market state it seems is here to stay. But - here is the difficult point - if we ask about its legitimacy, its claim on us as citizens, we need to come up with a better answer than we've had so far if we are to avoid the reduction of politics to instantaneous button-pressing responses to surface needs.
He's saying that security is not an excuse here. The need to do something quick about security is what drives this ham-handed response. This comes in turn from the notion that corporations are the proactive source of most of the good in society, while governments should react to protect the good, nothing more.
I think Rowan Williams asks some good questions. The answers, though, are much harder beyond the first one. First, organize. Next? Well, probably a lousy Slashdot/libertarian answer, democracy is pretty good at dealing with perpetual uncertainty.
Slashdot Mirror
Sure, when they're 16 years old. Throw a four-year-old out in the middle of a large crowd of unfamiliar people and rational thought is the last thing you can expect. That's why it takes a rational adult to calm them down and ask "Are you lost?" I wish I could be that parent that never loses their child, but I'm a realist and accept that it can happen, so these tracking devices sound appealing to me for use on very young children who are as of yet incapable of rational, level-headed responses to scary situations like getting lost in a shopping mall.
The key here is what you do BETWEEN age four and age sixteen. Kids need to learn how to handle all sorts of situations on their own. A parent would be unwise to hover closely, then at age 16, say "Here's the car keys, drive safely!" It takes years to build up to that point. Relying on the short-term "security" of GPS trackers only delays the day the child is ready to go solo into the wide world.
So the risks come down to a) unusual combinations of inputs that cause unexpected consequences and b) downloadable apps. You can bet that the auto companies are working hard to prevent the first. If there's ever an "app store" for some car electronics, it will be far more tightly controlled than what's out there for smartphones, again as much for control of what gets into the vehicle as for security. Not that I would personally care to "compute-ify" my car, thank you.
The failures of TFA are that the McAfee guy is applying desktop OS assumptions to embedded systems, and the CNN reporter didn't actually talk to any car guys.
Most of the concerns in this thread have been answered many times in hybrid vehicle and hypermiling forums. But just to address a couple...
Car batteries are sized for a cycle of rapid discharge (seconds), followed by moderate recharge while driving (minutes to hours), followed by very slow discharge when the engine is off (hours to weeks). The details are the secret sauce of electrical system design, hard to find out even from inside the auto industry. One would expect an engine start-stop car to have a larger battery and alternator than a conventional car. One consequence of this typical charge-discharge pattern is that any vehicle driven only on ten-minute trips is guaranteed to have battery problems.
Other facts of life (analysis available from EPA, no less) are that cruising at a steady speed is the highest-mileage mode of any car, while stop-and-go traffic gives the lowest mileage. Successful hybrids have features to deal with both of these extremes of fuel consumption. The start-stop system obviously deals with one aspect of the latter.
Alfred P. Sloan has been dead for 44 years.
I remember news stories from fall 1999. People were seriously concerned that gas, electricity and water utilities would fail, planes would crash, cars would stall and Social Security payments would not get made. Some acquaintances didn't like it when I pointed out that from the first time the Social Security Administration began automating, it had to deal with people born in the 19th century and others would not retire until the 21st. Hospitals replaced medical equipment that could not be certified as Y2K-compatible, instead of testing to see whether there would be any problem.
It got so bad that some New York buildings halted their elevators before the fateful midnight, and the U.S. Secretary of Transportation was riding on a commercial flight at midnight on December 31.
Those of us who wrote software for these machines just laughed and repeated the mantra, "Embedded systems programmers don't use COBOL."
Back around 2000 I did some work on diagnostic tools. Engine- and emissions-related trouble codes are industry standard as defined by the Society of Automotive Engineers (SAE). There are plenty of tools that will read these trouble codes. Where it gets interesting is that in various cars, the communication hardware could be UART-based, PWM, in the last few years, mostly CAN, but there were others.
A decade ago, I think it was under a consent decree, the 3 Detroit auto companies had to make diagnostic information available after one year. This being the auto industry, through incestuous business relationships one company got to collect the information, and of course they were the only source for the second year, and after that your friendly neighborhood repair shop could get the information from several sources.
The thing about vehicle buses is that they carry a lot more information besides diagnostics, and this "everything else" is held pretty closely by the auto companies. Dealers get access to at least some of it because repairs are where the cash flow is. Also, making warranty repairs quicker helps the auto companies keep their costs down.
Slashdot readers should realize that the world of embedded software inside the car has very little in common with desktop computing; automotive electronics resemble distributed systems more and more every year; and the shadetree mechanic is SOL these days.
Interesting! a) 3 of the 16 pictures are of cars made by American companies, if you count the Jaguars (Ford) and separately count two pics of pickup trucks, b) the racetrack image is from a Nissan plant in the UK, and 3) Slashdot readers once again race to conclusions. Unless, of course, the parent poster thinks American bailout policy should follow the lead of American manufacturing policy.
I think several trends are at work in amateur radio right now. First is that advances in chip integration have made it more difficult to homebrew equipment. There are fewer and fewer "catalog" parts around with simple functions. This, plus surface mount packaging, have made electronic products cheaper but electronic experimentation much more difficult for the average person.
Another trend is the commercial annihilation of distance. Talking across the country on two-way radio loses its thrill when one can do the same on a cell phone more or less for free, and much more reliably.
Software Defined Radio (SDR) is a bright spot in ham radio today. Forget about the Big Project flavor of Gnu Radio. Amateur SDR projects tend to be quite simple - sometimes ingeniously so - and approach the subject from the experimenter's point of view, not the engineer's. Most are based on the simple proposition that a recent commodity PC plus sound card make a pretty decent digital signal processor.
Organizations like ARRL and TAPR have encouraged digital radio up to and including SDR, though they have each tried to firmly guide the direction of amateur SDR. In fairness, ARRL has published many articles in its experimenter's magazine and in an excellent online compendium.
Two independent projects show the range of amateur SDR. The SDR-1000 is a hardware/software project turned semi-commercial, with a steep price of entry. Flex Radio Systems also has a unique definition of Open Source. On the other hand, the SDRadio project is an independent software receiver that is slowly morphing into a community effort. The project forum is brimming with good ideas.
There are other, loosely related projects such as narrowband signal processing and Digital Radio Mondiale (broadcast) decoders being done by hams. From these resources it's easy to see SDR as an emerging force in rejuvenating ham radio, even though today the various efforts are quite fragmented.
On a personal note, anyone who signs up for information can expect lots of marketing e-mails from a company that doesn't really understand the opt-out principle. Wait long enough and glossy brochures will show up in your mailbox, too.
There are some very powerful disincentives to introducing standardized (i.e. generic) hardware or software into any automobile. Start with the notion expressed in the EE Times article that software from one manufacturer would run on another's hardware. Today the auto industry treats software as if it were free, and pays only for metal boxes with wires coming out of them. The European consortium will have to propose a viable way for software-only vendors to make a profit.
Second, the auto manufacturers, in Detroit at least, are obsessive about keeping control over every aspect of what goes into their vehicles. The incompatible controllers are no accident. A lot of it has to do with parts cost -- at a minimum run of, say, 500,000 for any controller, the auto company can afford to cut pennies by making each one fully customized. (Remember, software is free!)
Third, keep following the money. There is a deliberate effort to get you to maintain and repair your new car at the dealer where you bought it. Cash flow has a huge influence on auto company decisions.
Fourth, between the time a new model rolls off the line and the time your corner garage can get hold of the diagnostic codes for it, two or three years will have passed and at least one company will have made money off the slow proprietary-to-public transition.
Starting to get the picture? The right (cynical?) way to look at the consortium is as a way to drive down the cost of their proprietary products, not as a way to get open software or even software standards into cars. MISRA C is standard, OSEK compliance is becoming standard, but that's about it.
Now, having said all this, I would also guess that the auto industry has recognized the problems of software complexity and development cost. Anyone who's been around, though, recognizes that the reality of software components has never lived up to the hype, and the cost-cutting mentality reigns supreme among the gearheads.
[snip!]
From the details, it looks like this latest BCB is in part Borland's answer to Eclipse.
Simple... The Swiss state is founded on the principle of permanent armed neutrality. That means a long history of successful defense against invaders and universal military service today. In some Swiss cantons, it is traditional to wear a sword when voting.
John McPhee wrote a fascinating book about the Swiss Army, La Place de la Concorde Suisse, that sheds light on the Swiss view of firearms. Not much of it transfers well to American society, though.
If he is not a liberal, just who is he?
To find out, we have to move past his political machine. Like Bush, Dean is very adept at associating himself with issues and causes that are important for his campaign. Thus for Dean we see his association with Lessig and an apparent concern for "the commons". Nothing could be farther from the truth.
I'm throwing away my chance to mod down some of the comments... Better Slashdotters should look beyond the knee-jerk responses, and respond to what Howard Dean has actually said, as well as what he actually writes in Lessig's blog.
That's the thing about Dean. Anyone who extrapolates from two or three of his positions will miss the point. The man is simply not doctrinaire. I see a person who has actually thought through what he says. This doesn't come through to pigeonholing pundits, nit-pickers and especially to the right-wing echo chamber. Don't believe everything you read in the newspaper.
With Dean you get someone who tempers his principles with a sense of what he can reasonably accomplish. He has the same feet of clay as the rest of us, and more willingness than most politicians to admit it.
Here's a prediction: Dean will say things on Lessig's blog that defy expectations on all sides.
To vnv's point on health insurance: funny how Canada, France and Germany each spend about two thirds per person what we do in the USA, give everyone the same standard of health care, and live longer than Americans in the bargain. This is the elephant in the room everyone is trying to ignore. Dean's proposal is not perfect but at least moves us down the road toward a rational health care financing system. Universal health care was not a Clinton idea, it was Truman's proposal first. Is it so bad that someone is willing to pass up the final goal to straighten out part of the mess, rather than get nothing?
Like many Dean supporters, I came looking with a mixture of anger (at BushCo) and curiosity. I stayed for the common sense.
To find out, we have to move past his political machine. Like Bush, Dean is very adept at associating himself with issues and causes that are important for his campaign. Thus for Dean we see his association with Lessig and an apparent concern for "the commons". Nothing could be farther from the truth.
xyzzy
Boiled down to the two most important points: the business model in the States is subscription-based - OnStar is the grandaddy, and it's not making money. Second, Europe has public broadcasts of traffic information to a continental standard, while in the good ol' USA, proprietary protocols rule and the FCC is spineless.
So until USDOT and its state counterparts get the gumption to propose a public alternative to the private General Motors model, expect slow progress.
I work on embedded products. A typical design has about 30,000 lines of C code, but the amount of assembly language is 1% of that and dropping. So there is little need for most of the programmers on a team to know something as concrete as assembly.
Our code runs on 16-bit single-chip microcontrollers rated at about 5 MIPS. The chips are typical of what $5 buys today. The application, which Slashdot readers would recognize instantly, has soft real-time requirements. We could probably run most everything on 20 ms timer ticks and get good responsiveness. There are plenty of spare CPU cycles even at peak loading. Yet there are people in my company who want to read the assembly code generated by our ANSI-standard C compiler, and turn off all the compiler optimizations. Some still insist on writing their own memset() functions.
Contrast this with the fact that it takes us 18 months to develop each new product. The 2003 version is about 80% the same as the 2001 version, about 20% of the code handles product differences from the older version, and there's maybe 5% new code for new features. What's wrong with this picture?
One obvious answer is simple: we're probably using the wrong level of abstraction, or just the wrong abstractions, in our design. We'd do much better to:
Abstract away hardware specifics wherever possible.
Trade off a little performance for shorter project schedules.
Profit!
This is not to say we should never open the black box -- just that we should be smart about when to dig deeply into the underlying hardware and CPU cycles. And being able to debug with an oscilliscope is still sometimes a valuable talent. As others have said here, the art of engineering lies in knowing when to do these things.
Successful black-box design can produce amazing results. For instance, look at Pure-Systems, whose initial product generates an optimized embedded kernel, written in C++, that's small enough to run on an Atmel AVR chip.
It's been sitting on the shelves of the local Borders Outlet for six months or more, always several in stock, though the price is only $6 or $7. The market speaks...
This thread is turning out better than some others about Extreme Programming, like here and here.
I worked on a project that used XP for most of 2001. It was a liberating experience. We had two domain experts who also acted as XP coaches, which helped a lot. Our biggest problem was convincing some team members to suspend their disbelief long enough to give the XP practices a chance. At the end, we found we were about 50% more productive than similar, non-XP projects, despite spending a lot of time cutting excess code out of the project. About 20% of the source code was devoted to unit tests and mock objects to support the tests.
When budget-cutting forced us to halt development abruptly, we had 12 known bugs. 11 of them were GUI problems, which we could not easily unit test. We had 70-80% unit test coverage, most of it written under the mantra "write the test, then the code." This turned out to be a key factor in our code quality.
Having all those unit tests in an automated test framework gave us tremendous confidence to keep moving forward. This leads to the other key factor TDD provides a project: freedom from fear. Why worry about failing the regression tests at the next code freeze when you can run them every hour?
Our XP project convinced me that one big reason for quality problems in C-language software is the lack of automated unit test tools. Sorry, that's just another good reason to move to OO, even for embedded systems.
TDD is still valuable without the other XP practices. Short development iterations also deserve wider use outside XP.
For all the naysayers... Look, nobody is saying you have to abandon experience, judgement or common sense to use XP. What you have to do is immerse yourself in the experience -- add the flow of programming the XP way to the other tools on your belt. XP is a little harder than riding a bicycle, definitely easier than Tuvan throatsinging, and as hard to describe on the printed page as both.
That said, Kent Beck's testing book is pretty thin. It adds very little to what you'd get from reading Extreme Programming Explained plus the JUnit tutorial. To understand why people "get religion" about TDD, understand why people are religious about the most effective ways to get software development done. Two views that come to the same place from vastly different starting points are Alistair Cockburn's excellent book, Agile Software Development , and the "lean software development" material at Mary Poppendieck's website.
The trouble with science fiction is that it follows Sturgeon's Law: "90% of everything is crap." Finding that good 10% and stories that suit your individual tastes is pretty tough. Years ago I read Chuq von Ruspach's online "Otherrealms" fanzine, because the reviews there lined up with my tastes better than half the time. That's long gone, and I haven't found anything to replace it. The Ebert and Roeper of SF just plain don't exist. So it's word of mouth, random tries at the bookstore, and the occasional review that makes an impression, that's how I find worthwhile new stuff.
With that disclaimer, here's a short list of authors that are thought-provoking but couldn't be farther from Heinlein, Zelazny, etc., if they tried. Try Orson Scott Card, Neil Gaiman, Nancy Kress, Lisa Mason (stick with the "San Francisco" trilogy), Neil Stephenson (skip Zodiac and Big U), Bruce Sterling (later work). Sharyn McCrumb is a mystery writer who has produced some sharp takes on science fiction fandom.
These authors are all well-established, and their styles run toward the literary side of SF. For tastes that run to swords and sorcery, space opera, hard SF, urban or antediluvean fantasy, hard-boiled cyberpunk, punny adventures -- try someone else.
The only way to find good, new SF may be with every fourth or fifth book, just read someone outside your comfort zone.
It's awfully fun reading desktop programmers commenting on an article in a project management magazine.
Here's a few facts about your new-model car. The BMW is extreme with 70 electronic modules but the typical 2003 vehicle has 20 or 30 microprocessor-controlled modules, and the number is rising every year. These range from a door-switch module with 8K of code, through an engine controller with 256K/32K of ROM/RAM, to a navigation system at 8M/8M. Very few of these modules have a manufacturing cost above $100.
The OS in automotive controllers varies from a simple event loop at the low end through OSEK-compliant kernels in the midrange to QNX and its friends in the most complicated systems. If there's Linux in a controller, it will be as well-hidden as the Linux in Tivo. Engine and transmission controllers are designed for hard real-time operation and emphatically do not use anything remotely resembling a desktop or palmtop OS.
Software development starts with the premise that once it's built, you can't change the it, ever. This has enormous consequences for the way automotive code gets made. Most companies spec the hell out of these products, use a strict waterfall development process, are afraid to venture beyond the C language, and test endlessly. They are scared of agile methodologies and even of RUP. Productivity is pretty low, but on the other hand, the products are reliable.
Now, both the article and /. responses are full of misconceptions. There's not really much question about whether an OS vendor shares its source code. The real concern is reliability. There's not much question about who develops embedded software. Detroit is lousy with contractors. One billboard I see on my commute shows a toy car with the caption "about the only vehicle that doesn't run on our software. -- EDS" The GM guy's comment about 10 year old software has the obvious answer: his teenager's 1993 Chevy.
Win CE gets no respect from embedded software developers for several reasons. Chief among them are poor responsiveness, poor stability and code bloat. Typical comment, from an SAE conference presenter: "If you put an embedded system into a car, you still have a car. If you put a PC into a car, you have a PC with wheels."
Rather than rant any further, let me suggest reading any of the books on Jean Labrosse's site, EE Times and Embedded Systems Programming. And have fun! Embedded is where you can see software affect the real world.
Uh, no. Cost-longevity tradeoffs in road design are well known to civil engineers. The political importance of jobs created through roadbuilding contracts is well known to their bosses.
It's really quite simple: 1. Control. 2. Fear.
Automakers are used to being completely in control of how their products are designed, sold and repaired. Look at what data is available from cars. The emissions and diagnostic data that any garage can read out (OBD-II) is essentially what's mandated by the California Air Resources Board. Newer model years incorporate more and more features to prevent hacking into engine controllers... well, into any embedded controllers in the car.
Look at the business practices of the car companies and you'll see how control is valued over nearly everything else. The Vetronix link in one of the replies is typical. Look at how Vetronix has an exclusive contract and how customers are locked into proprietary cables and software.
Fear also runs rampant in the industry. You want 20 MPG SUVs? The cost is $500 or so, but cost has little to do with why they aren't sold. The higher-ups will do almost anything to avoid upsetting the fabulous cash flow they control. That's why the pace of technological innovation in autos is so slow. There's also a lawsuit mentality in the industry. The perception they might be sued drives their actions far more than any actual lawsuits.
These two reasons, control and fear, are why any crash data recording standard would have to be imposed from outside the industry. They're also why both Bill Gates and Linux geeks are dreaming when they spin the fantasy of "open" car electronics.
On the posted topic: too many Slashdotters didn't RTFA. The NY Times article talks about recording the last few seconds before a crash. That's maybe a few hundred data points. It's not a voice recording or a demerit mark every time you break the speed limit or stand on the brakes.
There are 2 good reasons why the crash recorder would be part of the airbag module. First, the data is already used by the module. Second, the airbags have to deploy even if the car electrical system is hosed, so their power supplies have a "hold-up" time of tens of milliseconds. That's enough time to fire two-stage airbags with the battery disconnected. That's also enough time to write crash data to EEPROM.
Would the kind of recorder in the article make cars more expensive? No. Any cost increase would be in the software engineering before the first car was built, not in the manufacturing cost.
Are there good reasons to have them? Yes, but not what's in the article. One reason flying is a couple of orders of magnitude safer than driving is because the FAA is a lot more concerned with finding the causes of aircraft accidents than with assigning blame. If an agency like NHTSA or an industry group like SAE were to use crash data to improve safety, then the technology makes sense. But don't hold your breath - that kind of activity won't happen until after 2004 at best.
Do the math. The claim of 300,000 square mile coverage works out to a 309 mile radius from a spot directly under the balloon. At the edge of this area, a balloon flying 13 miles high would be 2.4 degrees above the horizon. At 18 miles altitude, the look angle at the fringe goes up to only 3 degrees. Doesn't sound like good coverage in a mountain valley, or even at street level with trees and houses in the line of sight.
A reasonable angle above the horizon means a much smaller service area, 30,000 square miles or even less.
Then, how many people will Wi-fi bandwidth reasonably support, as the service area scales up from square meters to square miles? Can this scheme offer cellular phone service without screwing up the key principle of small-area frequency reuse? What services will support the operating costs -- maneuvering fuel plus the ground crew? As I add each of these questions, a balloon-based "antenna tower" looks less and less like a rural common carrier and more like a luxury service for city-dwellers.
OK, lossy compression may cause hearing problems. But wait, there's more! DRM watermarking may cause hearing problems, too. Therefore, we must all buy more (analog) LPs...
Yes and no. Rowan Williams, Archbishop of Canterbury, looked at this kind of government action differently in the BBC Dimbleby Lecture a couple of days ago. He wasn't talking about centralizing the Internet, but it's a typical example. Williams thinks governments centralize control and thrash around for quick results because of their relation to what he calls the 'market state.'
To appreciate his view you have to step back from the view of marshalling technology to defeat vague, anti-democratic forces. Instead, look at the human beings behind the proposal. The motivation behind Internet monitoring isn't evil so much as it is a response to unintended consequences. Back in the '80s, some governments deliberately shrank while the power of weapons, money and ideas to cross national borders grew. While we techies were making bits stand up and dance for fun and profit, the rest of the world kept running on older urges. Let the Archbishop tell the story.
So...He's saying that security is not an excuse here. The need to do something quick about security is what drives this ham-handed response. This comes in turn from the notion that corporations are the proactive source of most of the good in society, while governments should react to protect the good, nothing more.
I think Rowan Williams asks some good questions. The answers, though, are much harder beyond the first one. First, organize. Next? Well, probably a lousy Slashdot/libertarian answer, democracy is pretty good at dealing with perpetual uncertainty.