Before everyone goes completely non-linear, it should be noted that if you have a trademark, you have to protect it if you want to keep it yours. Since one of the trademarks of Apple's latest batch of products is its unique interface style and artwork, they MUST take action when their artwork is being circulated and incorporated into other products. Even if there is a part of them that recognizes that imitation is the sincerest form of flattery.
You can't fault the programming language. The problem is in the application if it doesn't check buffer size against how much data is being read; it's in the OS if the problem is occurring when the application does a system call of some sort and is compromised in the process.
However... it looks like there are Oo.org users digging into that side of the problem. Probably they'll have an accurate synopsis of the failure mechanism and a patch on the way in a few days. Unfortunately we can't say the same (with the same confidence level) about MS Word.
Keck (both I and II) got damaged during last week's earthquake ( article ) and they're still working to get Keck II back to operational status. You never know when you will lose a valuable asset through a natural disaster... it would be ironic if the Keck system got wiped out shortly after the Hubble telescope was allowed to deteriorate beyond a reasonable threshold for maintenance or upgrading.
From the coders' perspective they would be better served if they could submit sealed bids (or at least, if the bids or statistics were only visible to the organization that posted the job). In that way you wouldn't get people going "$500? I can do that for $400" and progressively undercutting each other right out of existence.
TFA mentions they're going to accelerate it in a circle, to about 10 km/s, and then divert the launch projectile onto a ramp which will deflect it upward at a 30 degree angle, at about 8 km/s. There's a huge amount of energy dumped into the ramp there... why not build the accelerator at a 30 degree inclination to the horizontal, and then all you have to do is let it go at the appropriate time, and you won't be losing 20% of your speed due to the friction of the ramp.
The reason for using a vanilla F/OSS operating system is that it will, for the reasons described by the parent, be unlikely that it's corrupted specifically for the purpose of throwing an election. The voting application should only make generic use of the OS services so that it is less likely that an unknown or little known weakness of the OS will be exploited or exposed.
Other than Diebold's unwillingness to expose the source to their voting machines, the main problem with them appears to be simply that they're way too complicated... all that you need is a screen that presents the candidates and a button beside each candidate's name, which has to be pressed long enough that it can't be an accident. And counting software at the other end, which should be manageable using any competent database app.
More likely it is that IBM's legal team can clearly see where the current trend towards "patent portfolio management" by the trolls, and the formation of companies purely for the purpose of scavenging patents and/or patent applications from companies without sufficient means to resist the onslaught, is leading. IBM and a few others have the power to hopefully counter the self-destructive path that the USPTO seems to be following, by lobbying for patent reform in the US and the international arena.
I'll disagree with you... A compiler catches grammatical errors, not mistakes in design or bad assumptions about the system your program is supposed to control or model. When the computer and software in question is a realtime system the need for rigorous design and testing is an order of magnitude more difficult. I've seen a number of folks who claimed to be experienced at embedded system design make some pretty nasty mistakes, none of which were at the level where a compiler or testbed could flag the errors.
Same thing with cache operation as well as the latest double-data-rate RAM. Cache is transfered a block at a time, to reduce overall latency, and they do it because most of the time you read and/or write multiple data elements within a small contiguous memory area, then move on. Even with small caches that are used in embedded CPUs you end up with cache hit rates that exceed 90 percent for most common applications.
Or legos that are don't get stuck together as badly, or something else?
Buy MegaBloks or those crappy Tonka BTR blocks. Not only are they barely compatible with Lego(TM) blocks, they're barely compatible with themselves.
The Power Tap hub weighs maybe an ounce (at the most two ounces) more than a standard hub... and since it's got a wireless link straight to the display computer, there's no extra drag or other downside to using it. Not much penalty for getting a fairly definitive indication of your riding performance throughout the day.
A "practical" electric vehicle for the commuter market could be nothing more than a Smart car with a battery pack. The main desirable features are that it carry one or two occupants and provide shelter during inclement conditions. Gearing things more toward the performance end of the spectrum is fun and it will increase the appeal to the buyers - and that's important! Given the choice, most folks would rather drive a cool-looking fast car than a slow box. I'm not slamming the Smart car here - I actually think it's the right answer until the electric or other "alternate" power source car is commercially realizable.
For the freight market, the respondent that commented on the energy density of batteries vs. chemical fuels has it exactly right. Maximizing load capacity is the overriding requirement, and electric power alone will not let you do that. A hybrid scheme makes a lot of sense in this case - use a big-ass traction motor on the wheels, and a high power constant speed genset to keep a set of batteries charged (and to provide direct power for acceleration) so that you can maximize internal-combustion engine efficiency while minimizing driveline losses. The Canadian company Railpower has created hybrid switching locomotives that use this principle, and they give much better fuel economy (and correspondingly reduced emissions) than a locomotive that has the conventional engine-generator-motor driveline.
I had a spare computer I wanted to use as a mindless entertainment display device (in front of a treadmill). It's a P3-550 with about 128 Meg of RAM and maybe 10 gig HD, LCD display, and TV decoder and sound cards. Not top of the line exotic crap, and some of it was older. Downloaded and burned Mandrake/Mandriva to 3 CD's, popped the first one in the drive and went through the installation process. All the hardware got detected appropriately, and it all worked, and performance is OK (the computer's probably six years old - it has some issues with DVD playback due to the computational load and lack of memory). The decisions you have to make are not much different (if at all) than what is required for the average Windoze installation, and the default options turned out to be the right answers anyway (as far as I can recall). The windowing system (KDE) is enough like Windoze that most of the time it Just Doesn't Matter, especially since all it's used for is web browsing and enterntainment.
There's no reason to switch - but there's no reason to not do it for your next new computer.
Good points. The main problem with trying to benchmark CPU performance using C code that was "previously optimized" by competent programmers, is that it was written to exploit features and capabilities of a particular platform. As an example, there used to be a distinct advantage on many platforms if you used pointers to index arrays; if you didn't then the compiler would generate code that explicitly dereferenced from the array start for every access. Most compilers (even for embedded systems) now have enough brains to create a pointer in a register and index with it, regardless of whether or not you wrote the source code that way.
A few years ago I discovered that the embedded compiler I was using, would generate smaller code if I selected "optimize for speed" as opposed to "optimize for size"... When life hands you lemons, make lemonade. That truism applies to writing software, but as systems get bigger and you're working with smarter compilers, it makes sense to write your source so that it tells the compiler what you want the program to do, not how it ought to do the machine code.
Standardizing the intake limits the power that the engine can make, because it is very nearly impossible to exceed the speed of sound through the air intake venturi. This is what is (or used to be, anyway... I'm not up to date on this one) done in Formula 3 - you could build anything but it had to breathe through a 30mm intake hole.
It's probably the best idea from a long term perspective on keeping track speeds in bounds. For those that think that it should be 'anything goes', think back to the GTP wars in the early 90's when Nissan ruled the roost... and then Dan Gurney brought out the Toyota Eagle with the turbo 2 liter engine that ran very high boost. It was nearly as fast (or faster) than Indy cars on the same track. The organizers kept on making Dan add weight, and they kept on winning. Then they started limiting tire sizes and still Dan kept winning. The point is that if they hadn't put any limits on that car (or on any race car that breaks new ground in handling or engine development) it would have been totally unbeatable except through unforeseen circumstances, unless a team were to spend a kazillion dollars to come up with the Next Better Thing. And it's not exciting (for most people) to watch a race where only two cars out of twenty have any chance at all of winning. On the other hand, NASCAR (with all it's mandated obsolescence) draws bigger crowds than anything except international football (soccer).
I think it was Karl Marx who 'staged' the development of "true Communism" such that there would be a revolution against the ruling elite by the noble workers, followed by a period of 'socialism' where the government ran everything, and THEN somehow "communism" was attainable. The fiddly bit is that no country has actually made it past socialism. The USSR came the closest to calling a spade a spade, by not having "democratic" or "people's" or any such adjective in their country's name.
This isn't how a Communist country is supposed to be run. There isn't supposed to be any "tuition fees" for education. There isn't supposed to be competition dividing people into two classes (one worthy of secondary education, one not). In a perfect Communist society, I was born to do something and as long as I work hard and do it, I get the exact same education you get. I haven't seen one good thing coming from China's "Communist" party. It seems the only parts of Communism that China kept are the parts that favor the government!
Welcome to the real world... In a Socialist society, government decides what you're going to be, and any amount of "hard" work (i.e. harder than your neighbor) is actively suppressed because it will be made out to look like you're trying to curry favor with your boss. Think of it as a really bit institutionalized trade union.
It's been a little overtaken by events, but the book about Viktor Belenko's defection in a MIG-25 and his subsequent amazement at society in mid-70's USA contained the quote by Viktor that the USA had actually achieved true Communism, since anyone could do or be anything they wanted... even do nothing at all, and they'd still get supported (albeit only a little) by the government.
Actually... even in residential areas (US and Canada), the line voltage on overhead transmission wires is typically 13800 volts, and long distance power transmission is done at 45000 volts and higher, up to 500 kV for really high power, long distance lines. These voltages are high enough that you need to use 3, 4, or six-wire bundles (spaced about 8 inches or so apart) to keep the electric field gradient low enough so you don't get corona discharge around the wires.
I think we're pretty much on the same page. Over the last fifteen or sixteen years I've been lucky enough to be involved in design teams where pretty much everyone regards their work as far more than just a job. There was ONE guy (at the management level) who, over a period of four or five years, would consistently get his project to about the 80 to 90 percent complete level (going about 50 percent over budget on time in the process), and then decide to fundamentally change the architecture (because the requirements had changed in the mean time) so that the project completion date was pushed another year into the future.
Your upset response complete with cussing and stupid personal remarks that were unwarranted, shows that everyone's just used to it at this point.
What? "No shit, Dick Tracy" is a euphemism for "you're making motherhood-and-apple-pie statements". No offense intended - I just don't think that what you said has merit.
If I was going to get upset, I'd take umbrage at your slagging of engineers in your response. I've worked among several hundred engineers, in companies ranging from seven to seventy thousand employees, and I can count the number of engineers that did not take a personal stake in everything that touched their hands, on one hand. Even when the company where they were working was going through a management crisis and they downsized from 1800 to 200 employees. If they produced substandard products then it was almost always because of poor direction: building a design that didn't meet market requirements or being forced to include features that diluted the central effort.
and good engineering isn't done anymore.
If that's true then it's not because the engineers don't care - at least not that I've seen. I have seen a lot of good engineering get distilled out by poor upper-level decisions, though, so I certainly agree with your sentiments about "idiots in leadership".
No shit, Dick Tracy. What was said was "The hardware should enforce the FCC (or other regulatory) limits". Without other qualifications, "the hardware" does not encompass embedded software drivers or API abstraction layers, especially because part of Theo's rant was directed at the hardware vendors that insist that the PC load the embedded code (in the form of binary blobs) into the peripheral at boot time, or else that the PC link to precompiled API objects.
Extensible specification? That's a good theoretical construct. Kind of like "software reuse". I'm not saying that nobody does this effectively, just that I haven't seen it happen in any place where there were tight deadlines and executable code size limitations.
I don't think I forgot that part. In fact I stated that not only does the hardware have a broad enough design to operate within the parameters dictated by the software, manufacturing and component spec tolerances require that the hardware design be broad enough to allow it to meet the system design spec when significant component variations are taken into account.
In multi-band radios, the equipment can typically be operated slightly beyond the intended band edge due to the filters not having an infinitely steep roll-off. It doesn't matter whether or not the manufacturer allowed for other operating bands with hardware configuration diodes or resistors. Also... these configuration resistors are generally (but not always) interpreted by software, since operating in multiple bands usually also requires slight protocol variations. Therefore, if the software is open, you can just eliminate the part where the configuration is read.
I interpreted Theo's comments to imply that they want the radio firmware to be open down to the hardware level. Pushing binary blobs into flash and publishing an API into a buggy hardware driver does not do what he wants...
Filters limit the frequencies that a system can broadcast or receive, but they also have an insertion loss penalty. This reduces the efficiency of the system significantly - if a given filter has 1 dB insertion loss (which would be pretty good, implying that the filter probably costs a decent amount of money) then it would impart a 20 percent reduction in power output. Therefore it would cost you 20 percent more current, at least, to get the same RF range. That would (a) decrease the battery life and (b) increase the heat load in your system.
Wireless system designers use filters already to limit out-of-band emissions, but the problem is that no practical filter has a 'brick-wall' response where the passband ends exactly at the edge of the allowed spectrum. In a typical 2.4 GHz wireless network system you could probably go outside the band by 10 MHz before the filter rolloff became significant. With that freedom, an enterprising wireless LAN operator could set up his own little playing area away from everyone else's interference - but he'd be tromping on some unsuspecting folks.
Slashdot Mirror
Before everyone goes completely non-linear, it should be noted that if you have a trademark, you have to protect it if you want to keep it yours. Since one of the trademarks of Apple's latest batch of products is its unique interface style and artwork, they MUST take action when their artwork is being circulated and incorporated into other products. Even if there is a part of them that recognizes that imitation is the sincerest form of flattery.
You can't fault the programming language. The problem is in the application if it doesn't check buffer size against how much data is being read; it's in the OS if the problem is occurring when the application does a system call of some sort and is compromised in the process.
However... it looks like there are Oo.org users digging into that side of the problem. Probably they'll have an accurate synopsis of the failure mechanism and a patch on the way in a few days. Unfortunately we can't say the same (with the same confidence level) about MS Word.
Keck (both I and II) got damaged during last week's earthquake ( article ) and they're still working to get Keck II back to operational status. You never know when you will lose a valuable asset through a natural disaster... it would be ironic if the Keck system got wiped out shortly after the Hubble telescope was allowed to deteriorate beyond a reasonable threshold for maintenance or upgrading.
From the coders' perspective they would be better served if they could submit sealed bids (or at least, if the bids or statistics were only visible to the organization that posted the job). In that way you wouldn't get people going "$500? I can do that for $400" and progressively undercutting each other right out of existence.
TFA mentions they're going to accelerate it in a circle, to about 10 km/s, and then divert the launch projectile onto a ramp which will deflect it upward at a 30 degree angle, at about 8 km/s. There's a huge amount of energy dumped into the ramp there... why not build the accelerator at a 30 degree inclination to the horizontal, and then all you have to do is let it go at the appropriate time, and you won't be losing 20% of your speed due to the friction of the ramp.
The reason for using a vanilla F/OSS operating system is that it will, for the reasons described by the parent, be unlikely that it's corrupted specifically for the purpose of throwing an election. The voting application should only make generic use of the OS services so that it is less likely that an unknown or little known weakness of the OS will be exploited or exposed. Other than Diebold's unwillingness to expose the source to their voting machines, the main problem with them appears to be simply that they're way too complicated... all that you need is a screen that presents the candidates and a button beside each candidate's name, which has to be pressed long enough that it can't be an accident. And counting software at the other end, which should be manageable using any competent database app.
More likely it is that IBM's legal team can clearly see where the current trend towards "patent portfolio management" by the trolls, and the formation of companies purely for the purpose of scavenging patents and/or patent applications from companies without sufficient means to resist the onslaught, is leading. IBM and a few others have the power to hopefully counter the self-destructive path that the USPTO seems to be following, by lobbying for patent reform in the US and the international arena.
I'll disagree with you... A compiler catches grammatical errors, not mistakes in design or bad assumptions about the system your program is supposed to control or model. When the computer and software in question is a realtime system the need for rigorous design and testing is an order of magnitude more difficult. I've seen a number of folks who claimed to be experienced at embedded system design make some pretty nasty mistakes, none of which were at the level where a compiler or testbed could flag the errors.
Same thing with cache operation as well as the latest double-data-rate RAM. Cache is transfered a block at a time, to reduce overall latency, and they do it because most of the time you read and/or write multiple data elements within a small contiguous memory area, then move on. Even with small caches that are used in embedded CPUs you end up with cache hit rates that exceed 90 percent for most common applications.
Or legos that are don't get stuck together as badly, or something else? Buy MegaBloks or those crappy Tonka BTR blocks. Not only are they barely compatible with Lego(TM) blocks, they're barely compatible with themselves.
How about "Slashdot Announces NASA Announces Announcement of Dark Matter Discovery"?
The Power Tap hub weighs maybe an ounce (at the most two ounces) more than a standard hub... and since it's got a wireless link straight to the display computer, there's no extra drag or other downside to using it. Not much penalty for getting a fairly definitive indication of your riding performance throughout the day.
For the freight market, the respondent that commented on the energy density of batteries vs. chemical fuels has it exactly right. Maximizing load capacity is the overriding requirement, and electric power alone will not let you do that. A hybrid scheme makes a lot of sense in this case - use a big-ass traction motor on the wheels, and a high power constant speed genset to keep a set of batteries charged (and to provide direct power for acceleration) so that you can maximize internal-combustion engine efficiency while minimizing driveline losses. The Canadian company Railpower has created hybrid switching locomotives that use this principle, and they give much better fuel economy (and correspondingly reduced emissions) than a locomotive that has the conventional engine-generator-motor driveline.
There's no reason to switch - but there's no reason to not do it for your next new computer.
Then again...
10 print "Hello World"
20 goto 10
Good points. The main problem with trying to benchmark CPU performance using C code that was "previously optimized" by competent programmers, is that it was written to exploit features and capabilities of a particular platform. As an example, there used to be a distinct advantage on many platforms if you used pointers to index arrays; if you didn't then the compiler would generate code that explicitly dereferenced from the array start for every access. Most compilers (even for embedded systems) now have enough brains to create a pointer in a register and index with it, regardless of whether or not you wrote the source code that way. A few years ago I discovered that the embedded compiler I was using, would generate smaller code if I selected "optimize for speed" as opposed to "optimize for size"... When life hands you lemons, make lemonade. That truism applies to writing software, but as systems get bigger and you're working with smarter compilers, it makes sense to write your source so that it tells the compiler what you want the program to do, not how it ought to do the machine code.
It's probably the best idea from a long term perspective on keeping track speeds in bounds. For those that think that it should be 'anything goes', think back to the GTP wars in the early 90's when Nissan ruled the roost... and then Dan Gurney brought out the Toyota Eagle with the turbo 2 liter engine that ran very high boost. It was nearly as fast (or faster) than Indy cars on the same track. The organizers kept on making Dan add weight, and they kept on winning. Then they started limiting tire sizes and still Dan kept winning. The point is that if they hadn't put any limits on that car (or on any race car that breaks new ground in handling or engine development) it would have been totally unbeatable except through unforeseen circumstances, unless a team were to spend a kazillion dollars to come up with the Next Better Thing. And it's not exciting (for most people) to watch a race where only two cars out of twenty have any chance at all of winning. On the other hand, NASCAR (with all it's mandated obsolescence) draws bigger crowds than anything except international football (soccer).
Flossing while waiting for the light to change... I saw that this morning on the way in to work.
This isn't how a Communist country is supposed to be run. There isn't supposed to be any "tuition fees" for education. There isn't supposed to be competition dividing people into two classes (one worthy of secondary education, one not). In a perfect Communist society, I was born to do something and as long as I work hard and do it, I get the exact same education you get. I haven't seen one good thing coming from China's "Communist" party. It seems the only parts of Communism that China kept are the parts that favor the government!
Welcome to the real world... In a Socialist society, government decides what you're going to be, and any amount of "hard" work (i.e. harder than your neighbor) is actively suppressed because it will be made out to look like you're trying to curry favor with your boss. Think of it as a really bit institutionalized trade union.
It's been a little overtaken by events, but the book about Viktor Belenko's defection in a MIG-25 and his subsequent amazement at society in mid-70's USA contained the quote by Viktor that the USA had actually achieved true Communism, since anyone could do or be anything they wanted... even do nothing at all, and they'd still get supported (albeit only a little) by the government.
Actually... even in residential areas (US and Canada), the line voltage on overhead transmission wires is typically 13800 volts, and long distance power transmission is done at 45000 volts and higher, up to 500 kV for really high power, long distance lines. These voltages are high enough that you need to use 3, 4, or six-wire bundles (spaced about 8 inches or so apart) to keep the electric field gradient low enough so you don't get corona discharge around the wires.
I think we're pretty much on the same page. Over the last fifteen or sixteen years I've been lucky enough to be involved in design teams where pretty much everyone regards their work as far more than just a job. There was ONE guy (at the management level) who, over a period of four or five years, would consistently get his project to about the 80 to 90 percent complete level (going about 50 percent over budget on time in the process), and then decide to fundamentally change the architecture (because the requirements had changed in the mean time) so that the project completion date was pushed another year into the future.
What? "No shit, Dick Tracy" is a euphemism for "you're making motherhood-and-apple-pie statements". No offense intended - I just don't think that what you said has merit.
If I was going to get upset, I'd take umbrage at your slagging of engineers in your response. I've worked among several hundred engineers, in companies ranging from seven to seventy thousand employees, and I can count the number of engineers that did not take a personal stake in everything that touched their hands, on one hand. Even when the company where they were working was going through a management crisis and they downsized from 1800 to 200 employees. If they produced substandard products then it was almost always because of poor direction: building a design that didn't meet market requirements or being forced to include features that diluted the central effort.
and good engineering isn't done anymore. If that's true then it's not because the engineers don't care - at least not that I've seen. I have seen a lot of good engineering get distilled out by poor upper-level decisions, though, so I certainly agree with your sentiments about "idiots in leadership".
Extensible specification? That's a good theoretical construct. Kind of like "software reuse". I'm not saying that nobody does this effectively, just that I haven't seen it happen in any place where there were tight deadlines and executable code size limitations.
In multi-band radios, the equipment can typically be operated slightly beyond the intended band edge due to the filters not having an infinitely steep roll-off. It doesn't matter whether or not the manufacturer allowed for other operating bands with hardware configuration diodes or resistors. Also... these configuration resistors are generally (but not always) interpreted by software, since operating in multiple bands usually also requires slight protocol variations. Therefore, if the software is open, you can just eliminate the part where the configuration is read.
I interpreted Theo's comments to imply that they want the radio firmware to be open down to the hardware level. Pushing binary blobs into flash and publishing an API into a buggy hardware driver does not do what he wants...
Wireless system designers use filters already to limit out-of-band emissions, but the problem is that no practical filter has a 'brick-wall' response where the passband ends exactly at the edge of the allowed spectrum. In a typical 2.4 GHz wireless network system you could probably go outside the band by 10 MHz before the filter rolloff became significant. With that freedom, an enterprising wireless LAN operator could set up his own little playing area away from everyone else's interference - but he'd be tromping on some unsuspecting folks.