You only need one leak between a consistent alias and your legal identity to connect all the dots though. The idea that you'll be forever vigilant and never goof up on an alias is a bit optimistic. Why is that approach any less prone to mistakes than being vigilant about your real name? You could rotate aliases instead, but that increases complexity, and complexity introduces its own increased odds of error. You could make the same argument about having a single alias too. I see having to guard at least one usernames as being unavoidable if you want to participate on discussion forums. I don't have any illusions that using a non-real name on its own provides me improved security though.
I said there aren't many. Adaptec is also an option. HP has their own RAID cards too. There are a good number of vendors/integrators where the LSI controller is the only supported choice though.
There are three reason to use hardware RAID, and your claim that software RAID is safer isn't true in a few situations. Neither is better than the other, they have slightly different use cases and trade-offs. The overhead of the RAID computations is an irrelevant factor to this decision now.
First thing I mentioned, relatively seamless mirroring of all the blocks on disk. With Linux software RAID as a common deployment, it's easy to end up in a situation where the boot loader isn't the same on both drives, as the most obvious way a pair of disks can get out of sync. There are others. The normal way to find this out is to lose the first drive, only to discover the second won't boot. That shouldn't ever happen on a hardware RAID pair.
Second, you won't get a proper battery-backed write cache with anything but a hardware RAID controller. If you care about write integrity, you need one of those in order to safely cache writes. It's easy to get database corruption on a software RAID setup if you try to use the drive's write cache for that; and if you don't use it, performance will be slow doing some things. A battery-backed hardware cache will be fast all the time, and it won't lose writes and cause corruption unless the server is powered off a long time.
The third thing is a fuzzier issue. Motherboard disk controllers can easily go insane if you lose a drive. It's not important for most of them to handle this gracefully. Hardware RAID controllers should be testing that and seamlessly switching to the other disk, since not having the system go down is part of why people buy them.
The purpose of hardware RAID to try and improve the odds an important server will keep running even when a drive fails. Good practices there have some overlap with good backup strategy. Neither alone is sufficient. The problem with the "RAID is not backup" line of thinking is that most true backups require a non-trivial restore time. That's fine for when it's needed. You shouldn't have to roll back via a long process every time you lose a single drive though. That's the problem hardware RAID is better at solving than most other forms of "proper" backups.
The failure rate on many computer related things floats at some fraction of a percent. If you've only done a few hundred of them, it wouldn't surprise me that you haven't seen a BIOS failure. It's not that unlikely from a statistics standpoint, just like two bad updates in a row is unlikely--but it's surely happening to some unlucky soul.
I got a shipment of 500 motherboards once that turned out to need an update before they could be deployed, to add support for the CPUs purchased. A bit under 1% of those BIOS updates didn't work out and the boards had to be RMAd. It was less of a problem than ones that were DOA though, where the system wouldn't even boot far enough to do the update. (These were Asus board in 2003, and I dream of DOA rates this low now)
I tell anyone who is considering a serious deployment of hardware RAID that they should buy two of the cards from day one, to have one in a backup server. Then you can run experiments on unrecognized drives or firmware updates on the backup. Also, if something fails on the main server, it increases the odds you'll be able to get to the data if it's still intact. Needing spares around is unfortunately part of the overhead of having this sort of hardware.
RAID controllers are pretty low volume products compared to a lot of other computer parts. And the problem where a new drive doesn't work with an old controller is depressingly common too. You could just as easily run into this same issue with any other RAID hardware. LSI at least does keep updating things. I have a drawer full of old RAID cards that stopped being useful mainly because the manufacturer gave up on updates.
Ever since 3ware was assimilated by LSI, there aren't many viable alternatives to them, if you must have hardware RAID. The only good reason to prefer it over software RAID nowadays, where you can move the drives anywhere and read them, is that booting is preserved in more failure cases. It's easy to let the boot area of a software RAID1 volume be mismatched.
I have a Lenovo Thinkpad T500 brick that I made this way three months ago. I was running into a few weird Windows problems--everything was fine on Linux--and "upgrade the BIOS" was a stock troubleshooting suggestion. After a decade of happy Thinkpad ownership I didn't think this was risky. On the first reboot the update did something to fry the TPM chip. It worked fine before, never again afterward. Boots hung for about 10 minutes as the BIOS tried to talk to it, I stopped that only by disabling it there. And then the next week the computer stopped POST altogether. The laptop had been running fine for 3 years at that point. I've seen a few similar reports at the Lenovo forums; it's not just me. The only people who resolved this were still under warranty, the rest of us haven't considered it cost effective to pay for a fix.
I tried to jump two major point releases at once here, from 1.20 to 3.24. My guess is that QA wasn't done on this much of a jump at once. Maybe 1.X->2.X->3.X or some other two step sequence would have worked. The Thinkpads have been disappointing is several ways recently, so I can't really say this surprised me.
A true bricking BIOS update will trash the system so badly you can't reach any backup BIOS. By definition, if the machine is still functional enough to allow reverting the BIOS update, you didn't really brick it.
You draw the line as deeply as you can while still being able to make forward progress moving it downward, and accumulating popularity has some value too. Saying you shouldn't work on free software/hardware unless it achieves 100% free at every level means you'll never get anywhere. GNU tries to advance on multiple development layers when it can, but it can't completely ignore the economics of mass production.
You think there are a significant number of repair places who routinely pull hard drives from dead devices for forensic/cause analysis? If the idea is to suggest there are smart bean counters, I guess that's no more silly.
If my goal were to prove Linux is responsible for the problem, regardless of reality--which is the idea I'm parodying here in case you're not sure--I would brick one using a live CD. In an ideal situation for Samsung, not only would they not give the RMAs out, asking for one due to this problem would result in US customers being arrested for using hacking tools. Play that perfectly, and their potential competitors at Canonical would also be sued for providing the tools.
Your suggestion is a good idea to avoid this code being copied to another platform and breaking there. Microsoft does specify what happens here though, and the program as written does the right thing. Both char and unsigned char casts get "Preserve low-order byte" when you start with a larger integer.
Sure, Stallman uses a web browser sometimes...but only when he can't read the text from the HTML. And in any case, "I fetch web pages from other sites by sending mail to a program that fetches them, much like wget, and then mails them back to me."
Your theory that there are capable bean counters who understand statistics and make good decisions using them is an interesting one. I'm going to pick option B however, where RMAs for the model are denied because everyone knows those users destroyed their hardware using that nasty Linux program, and they're not going to get a replacement or refund at all. Why, if anything it's proof that the ability to lock down the bootloader is even more important than ever!
The awesome thing about statistics is that the intent of person applying them suggests the outcome long before the data is analyzed. Given enough numbers, people will see what they look for.
It is possible to buy a UPS for around $40, and all of these items are crap. CyberPower, DirectUPS, Tripp-Lite, Opti-UPS, Minuteman, Powercom...any of these can end up becoming the least reliable component to a Linux system.
Even with APC, who sells reliable units if you spend enough, you're looking at a few hundred dollars for one that is usefully reliable. And even there you have to be careful, do your research, and test to be sure. The biggest issue right now is how power is generated, which determines whether they will support active PFC power supplies. The models from APC that say "stepped approximation to a sinewave" for example are nothing but trouble. You want "pure sine wave". The Smart-UPS PCW-SUA1000 has the right design at $370. It is depressing how bad their cheaper models are nowadays, and how much you can spend on a unit that's still junk.
"The Design of Everyday Things" shows that people can make complicated things even more difficult to use than they have to be. It doesn't prove that everything can be made simpler with no downside.
Every non-trivial device requires tech support if exposed to a wide enough audience. There's an unbreakable trade-off between the complexity that comes from adding more features and making more ways something can fail. Note that I didn't say "in a phone" or "on a computer"; this trade-off exists in all design.
If Apple products really removed support, you wouldn't have to schedule time at their "genius" bars. The idea that Apple has lowered support overhead by decreasing visible features has some truth to it, but that this only goes so far has been obvious for years. I think the Onion pointed out how bizarre that turns if you go too far best, with Apple Introduces Revolutionary New Laptop With No Keyboard.
Your description violates my patent on preemptive war, which I totally invented despite it being common for over 100 years. Expect to hear from my patent attorney you scoundrel.
You idiot kids think you invented having a brain...this was exactly how just-in time ordering was already done on a computer by the auto industry in the 80's. Electronic data interchange (EDI) with exactly this sort of capability wasn't a new concept even then. "Please deliver me X widget assemblies and Y doodads every 9 days until I use EDI to tell you otherwise". Yup, remember first doing that myself in 1991.
Too late; Apple already sued everyone over the trash can icon thing back in 1994. Why do you think Widows calls it the "Recycle Bin"? What Apple should have patented is the "on a computer" lawsuit.
Slashdot Mirror
You only need one leak between a consistent alias and your legal identity to connect all the dots though. The idea that you'll be forever vigilant and never goof up on an alias is a bit optimistic. Why is that approach any less prone to mistakes than being vigilant about your real name? You could rotate aliases instead, but that increases complexity, and complexity introduces its own increased odds of error. You could make the same argument about having a single alias too. I see having to guard at least one usernames as being unavoidable if you want to participate on discussion forums. I don't have any illusions that using a non-real name on its own provides me improved security though.
I said there aren't many. Adaptec is also an option. HP has their own RAID cards too. There are a good number of vendors/integrators where the LSI controller is the only supported choice though.
There are three reason to use hardware RAID, and your claim that software RAID is safer isn't true in a few situations. Neither is better than the other, they have slightly different use cases and trade-offs. The overhead of the RAID computations is an irrelevant factor to this decision now.
First thing I mentioned, relatively seamless mirroring of all the blocks on disk. With Linux software RAID as a common deployment, it's easy to end up in a situation where the boot loader isn't the same on both drives, as the most obvious way a pair of disks can get out of sync. There are others. The normal way to find this out is to lose the first drive, only to discover the second won't boot. That shouldn't ever happen on a hardware RAID pair.
Second, you won't get a proper battery-backed write cache with anything but a hardware RAID controller. If you care about write integrity, you need one of those in order to safely cache writes. It's easy to get database corruption on a software RAID setup if you try to use the drive's write cache for that; and if you don't use it, performance will be slow doing some things. A battery-backed hardware cache will be fast all the time, and it won't lose writes and cause corruption unless the server is powered off a long time.
The third thing is a fuzzier issue. Motherboard disk controllers can easily go insane if you lose a drive. It's not important for most of them to handle this gracefully. Hardware RAID controllers should be testing that and seamlessly switching to the other disk, since not having the system go down is part of why people buy them.
The purpose of hardware RAID to try and improve the odds an important server will keep running even when a drive fails. Good practices there have some overlap with good backup strategy. Neither alone is sufficient. The problem with the "RAID is not backup" line of thinking is that most true backups require a non-trivial restore time. That's fine for when it's needed. You shouldn't have to roll back via a long process every time you lose a single drive though. That's the problem hardware RAID is better at solving than most other forms of "proper" backups.
If a simple recovery procedure can fix the problem, it's not a brick.
The failure rate on many computer related things floats at some fraction of a percent. If you've only done a few hundred of them, it wouldn't surprise me that you haven't seen a BIOS failure. It's not that unlikely from a statistics standpoint, just like two bad updates in a row is unlikely--but it's surely happening to some unlucky soul.
I got a shipment of 500 motherboards once that turned out to need an update before they could be deployed, to add support for the CPUs purchased. A bit under 1% of those BIOS updates didn't work out and the boards had to be RMAd. It was less of a problem than ones that were DOA though, where the system wouldn't even boot far enough to do the update. (These were Asus board in 2003, and I dream of DOA rates this low now)
I tell anyone who is considering a serious deployment of hardware RAID that they should buy two of the cards from day one, to have one in a backup server. Then you can run experiments on unrecognized drives or firmware updates on the backup. Also, if something fails on the main server, it increases the odds you'll be able to get to the data if it's still intact. Needing spares around is unfortunately part of the overhead of having this sort of hardware.
RAID controllers are pretty low volume products compared to a lot of other computer parts. And the problem where a new drive doesn't work with an old controller is depressingly common too. You could just as easily run into this same issue with any other RAID hardware. LSI at least does keep updating things. I have a drawer full of old RAID cards that stopped being useful mainly because the manufacturer gave up on updates.
Ever since 3ware was assimilated by LSI, there aren't many viable alternatives to them, if you must have hardware RAID. The only good reason to prefer it over software RAID nowadays, where you can move the drives anywhere and read them, is that booting is preserved in more failure cases. It's easy to let the boot area of a software RAID1 volume be mismatched.
I have a Lenovo Thinkpad T500 brick that I made this way three months ago. I was running into a few weird Windows problems--everything was fine on Linux--and "upgrade the BIOS" was a stock troubleshooting suggestion. After a decade of happy Thinkpad ownership I didn't think this was risky. On the first reboot the update did something to fry the TPM chip. It worked fine before, never again afterward. Boots hung for about 10 minutes as the BIOS tried to talk to it, I stopped that only by disabling it there. And then the next week the computer stopped POST altogether. The laptop had been running fine for 3 years at that point. I've seen a few similar reports at the Lenovo forums; it's not just me. The only people who resolved this were still under warranty, the rest of us haven't considered it cost effective to pay for a fix.
I tried to jump two major point releases at once here, from 1.20 to 3.24. My guess is that QA wasn't done on this much of a jump at once. Maybe 1.X->2.X->3.X or some other two step sequence would have worked. The Thinkpads have been disappointing is several ways recently, so I can't really say this surprised me.
A true bricking BIOS update will trash the system so badly you can't reach any backup BIOS. By definition, if the machine is still functional enough to allow reverting the BIOS update, you didn't really brick it.
Question: What's the only thing worse than Flash?
You mean besides Java applets, right?
You draw the line as deeply as you can while still being able to make forward progress moving it downward, and accumulating popularity has some value too. Saying you shouldn't work on free software/hardware unless it achieves 100% free at every level means you'll never get anywhere. GNU tries to advance on multiple development layers when it can, but it can't completely ignore the economics of mass production.
You think there are a significant number of repair places who routinely pull hard drives from dead devices for forensic/cause analysis? If the idea is to suggest there are smart bean counters, I guess that's no more silly.
If my goal were to prove Linux is responsible for the problem, regardless of reality--which is the idea I'm parodying here in case you're not sure--I would brick one using a live CD. In an ideal situation for Samsung, not only would they not give the RMAs out, asking for one due to this problem would result in US customers being arrested for using hacking tools. Play that perfectly, and their potential competitors at Canonical would also be sued for providing the tools.
Your suggestion is a good idea to avoid this code being copied to another platform and breaking there. Microsoft does specify what happens here though, and the program as written does the right thing. Both char and unsigned char casts get "Preserve low-order byte" when you start with a larger integer.
Sure, Stallman uses a web browser sometimes...but only when he can't read the text from the HTML. And in any case, "I fetch web pages from other sites by sending mail to a program that fetches them, much like wget, and then mails them back to me."
Next you'll be suggesting the Samsung bug is triggered by someone driving a car into their memory pool.
P.S. The boom was at the Smothers Brothers Comedy Hour.
Your theory that there are capable bean counters who understand statistics and make good decisions using them is an interesting one. I'm going to pick option B however, where RMAs for the model are denied because everyone knows those users destroyed their hardware using that nasty Linux program, and they're not going to get a replacement or refund at all. Why, if anything it's proof that the ability to lock down the bootloader is even more important than ever!
The awesome thing about statistics is that the intent of person applying them suggests the outcome long before the data is analyzed. Given enough numbers, people will see what they look for.
It is possible to buy a UPS for around $40, and all of these items are crap. CyberPower, DirectUPS, Tripp-Lite, Opti-UPS, Minuteman, Powercom...any of these can end up becoming the least reliable component to a Linux system.
Even with APC, who sells reliable units if you spend enough, you're looking at a few hundred dollars for one that is usefully reliable. And even there you have to be careful, do your research, and test to be sure. The biggest issue right now is how power is generated, which determines whether they will support active PFC power supplies. The models from APC that say "stepped approximation to a sinewave" for example are nothing but trouble. You want "pure sine wave". The Smart-UPS PCW-SUA1000 has the right design at $370. It is depressing how bad their cheaper models are nowadays, and how much you can spend on a unit that's still junk.
"The Design of Everyday Things" shows that people can make complicated things even more difficult to use than they have to be. It doesn't prove that everything can be made simpler with no downside.
Every non-trivial device requires tech support if exposed to a wide enough audience. There's an unbreakable trade-off between the complexity that comes from adding more features and making more ways something can fail. Note that I didn't say "in a phone" or "on a computer"; this trade-off exists in all design.
If Apple products really removed support, you wouldn't have to schedule time at their "genius" bars. The idea that Apple has lowered support overhead by decreasing visible features has some truth to it, but that this only goes so far has been obvious for years. I think the Onion pointed out how bizarre that turns if you go too far best, with Apple Introduces Revolutionary New Laptop With No Keyboard.
They also have irregularly scheduled deliveries of new gerbils.
Your description violates my patent on preemptive war, which I totally invented despite it being common for over 100 years. Expect to hear from my patent attorney you scoundrel.
There's this thing called delivery logistics, and Amazon is at best hundreds of years late to be inventing it now.
You idiot kids think you invented having a brain...this was exactly how just-in time ordering was already done on a computer by the auto industry in the 80's. Electronic data interchange (EDI) with exactly this sort of capability wasn't a new concept even then. "Please deliver me X widget assemblies and Y doodads every 9 days until I use EDI to tell you otherwise". Yup, remember first doing that myself in 1991.
The Columbia Record Club goes back to 1955.
Too late; Apple already sued everyone over the trash can icon thing back in 1994. Why do you think Widows calls it the "Recycle Bin"? What Apple should have patented is the "on a computer" lawsuit.