in my opinion, it is bad hardware design if it *can* be irreversibly damaged by software. there should be checks at the hardware level against that, as well as ways to factory-reset any piece of hardware that commercially ships.
There is no reasonable way to do that with many types of hardware. You need to be able to write data to areas which contain the necessary code that allows data to be written to that area, because somtimes the code that communicates with external devices needs updating, so you cannot 'protect' that code in any way.
I'm not sure if you guys really know much about Linux, but I've been running it over half my life, and one of the first things I learned is never run anything that's an alpha. They aren't meant for real hardware yet, unless your a developer (and this goes for the majority of them too) you should run it in a virtual machine. If you want a sneak preview, wait for a beta, if you want a current system, use a current build, and if you want a stable system, get an older "stable" build.
Last I checked, hardware isn't usually designed AROUND operating systems. And moreover if Intel's industry standard networking hardware wasn't "designed" to run under Linux kernels, I doubt they would code their own drivers for them...
Sure you can. Motherboard manufacturers have been doing it for YEARS. I've even un-bricked my WRT54G router that had a bad flash. It's all in the design.
Do people not know what Alpha version of a piece of software means? It means it's not even ready for testing. It's when developers are still adding to the schedule release. It is in Beta stage you have something worthwhile testing. Well so you might ask what's the point of Alpha versions? ( Mainly for integration testing, developer testing and not aimed for the general public). If you use Alpha or Beta that's too bad, you shouldn't be using those if you have the slightest clue what's going on. That's why there are official release date. This is good though that this bug was found in the Alpha stages of development rather than final gold master.
@dv "in my opinion, it is bad hardware design if it *can* be irreversibly damaged by software."
How do you suggest updating BIOS, firmware etc? The reason so many devices say "UPDATING FIRMWARE. DO NOT POWER OFF" is because it's difficult/expensive to design hardware which requires updates yet cannot be damaged irreversibly. You'd have to have a reliable redundant power source such as a battery should power go out during the write, or a secondary fallback firmware (as some motherboards/servers now have).
There are also various levels of irreversibility (not sure if that's a real word). The actual bug report says "recovery may be possible via a BIOS update". That's not so painful. Other techniques might include shorting pins (http://www.linksysinfo.org/forums/showthread.php?t=47259) or pulling off a chip and using an eeprom burner. At what point do you consider a device irreversibly damaged?
Now that we've thrown 'em off the trail, use the form below to get in touch with the people at Engadget. Please fill in all of the required fields because they're required.
You expect a few bad bugs in a OS alpha stage but not this bad.
Shocking.
Someone fucked up.... bad....
There's a difference between "a few bad bugs" and bugs that destroy hardware.
It could be worse....
http://lh6.ggpht.com/shaileshdoke/SDym7NzNupI/AAAAAAAAAq4/sLfF2cd_muQ/Hack%20and%20Blow%20like%20Bomb%5B5%5D.jpg
in my opinion, it is bad hardware design if it *can* be irreversibly damaged by software. there should be checks at the hardware level against that, as well as ways to factory-reset any piece of hardware that commercially ships.
These people do it for free, they owe you nothing.
Whoopsiedaisy. Lol
@dv
There is no reasonable way to do that with many types of hardware. You need to be able to write data to areas which contain the necessary code that allows data to be written to that area, because somtimes the code that communicates with external devices needs updating, so you cannot 'protect' that code in any way.
@ Curtis
@ Chris
I'm not sure if you guys really know much about Linux, but I've been running it over half my life, and one of the first things I learned is never run anything that's an alpha. They aren't meant for real hardware yet, unless your a developer (and this goes for the majority of them too) you should run it in a virtual machine. If you want a sneak preview, wait for a beta, if you want a current system, use a current build, and if you want a stable system, get an older "stable" build.
"You expect a few bad bugs in a OS alpha stage but not this bad. Shocking."
Well, I can tell you that I'm running the alpha build right now and I haven't... OW! What the hell was that?!?
@ dv
Why would intel need to protect their hardware against Operating systems it was not designed for? HMMmmm?
@rock99rock
Last I checked, hardware isn't usually designed AROUND operating systems. And moreover if Intel's industry standard networking hardware wasn't "designed" to run under Linux kernels, I doubt they would code their own drivers for them...
@rock:
considering both e1000 and e1000e drivers are actually written by Intel itself, I find your comment quite amusing
@rock
You comment would've held some credibility, if it wasn't for the fact that Intel Writes Their Own Modules
@Kamokazi:
Sure you can. Motherboard manufacturers have been doing it for YEARS. I've even un-bricked my WRT54G router that had a bad flash. It's all in the design.
Do people not know what Alpha version of a piece of software means? It means it's not even ready for testing. It's when developers are still adding to the schedule release. It is in Beta stage you have something worthwhile testing. Well so you might ask what's the point of Alpha versions? ( Mainly for integration testing, developer testing and not aimed for the general public). If you use Alpha or Beta that's too bad, you shouldn't be using those if you have the slightest clue what's going on. That's why there are official release date. This is good though that this bug was found in the Alpha stages of development rather than final gold master.
Intel network cards usually have problems with both Linux and Mac installs.
@dv "in my opinion, it is bad hardware design if it *can* be irreversibly damaged by software."
How do you suggest updating BIOS, firmware etc? The reason so many devices say "UPDATING FIRMWARE. DO NOT POWER OFF" is because it's difficult/expensive to design hardware which requires updates yet cannot be damaged irreversibly. You'd have to have a reliable redundant power source such as a battery should power go out during the write, or a secondary fallback firmware (as some motherboards/servers now have).
There are also various levels of irreversibility (not sure if that's a real word). The actual bug report says "recovery may be possible via a BIOS update". That's not so painful. Other techniques might include shorting pins (http://www.linksysinfo.org/forums/showthread.php?t=47259) or pulling off a chip and using an eeprom burner. At what point do you consider a device irreversibly damaged?