The monitoring in the US is particularly bad given how it's been combined with reduced right to legal process, all under the banner of fighting terrorism. That's not new either though; the parallels between Guantanamo Bay and the 1942 Japanese American internment are very obvious.
If you care enough about quality that you're using AccurateRip and need to check how the drive is caching, a USB interface might not work. The sort of USB->SATA chipsets used in USB CD-ROMs, which are universally cheap devices nowadays, will likely not pass data through faithfully enough to be useful for accurate CD ripping.
That said, it is possible to find useful models if you test carefully. The external drive I'm using is a LG "Portable Super Multi Drive", model GP10NB20. LG makes many of the best CD ripping DVD drives available, and the USB chipset in this model is transparent enough for accurate ripping. At around $35, it's not the cheapest model on the market, but it's not like that's expensive.
The biggest source for early XFS corruption issues was that at the time the filesystem was introduced, most drives on the market lied about write caching. XFS was the first Linux filesystem that depended on write barriers working properly. If something was declared written but not really on disk, filesystem corruption could easily result after a crash. But when XFS was released in 2001, all the cheap ATA disks in PC hardware lied about writes being complete, Linux didn't know how to work around that, and as such barriers were not reliable on them. SGI didn't realize how big of a problem this was because their own hardware, the IRIX systems XFS was developed for, used better quality drivers where this didn't happen. But take that same filesystem and run it on random PC hardware of the era, and it usually doesn't work.
ext4 will fail in the same way XFS used to, if you run it on old hardware. That bug was only fixed in kernel 2.6.32, with an associated performance loss on software like PostgreSQL that depends on write barriers for its own reliable operation too. Nowadays write barriers on Linux are handled by flushing the drive's cache out, all SATA drives support that cache flushing call, and the filesystems built on barriers work fine.
Many of the other obscure XFS bugs were flushed out when RedHat did QA for RHEL6. In fact, XFS is the only good way to support volumes over 16TB in size, as part of their Scalable File System package, a fairly expensive add-on the RHEL6. All of the largest Linux installs I deal with are on XFS, period.
I wouldn't use XFS on a kernel before RHEL6 / Debian Squeeze though. I know the software side of the write barrier implementation, the cache flushing code, works in the 2.6.32 derived kernels they run. The bug I pointed to as fixed in 2.6.32 was specific to ext4, but there were lots of other fixes to that kernel in this area. I don't trust any of the earlier kernels for ext4 or xfs.
Differences among models in a motherboard line are larger than variation among manufacturers. Check out the BeHardware Components returns rates survey for example. The average quality from MSI, Asus, and Gigabyte is very evenly matched. But both Asus and Gigabyte have models that are just plain junk.
As for "more important than ever", in the last 10 years the period when motherboards were most critical to select carefully was the peak of the capacitor plague era.
The problem isn't just that time spent on installers would be better spent adding features. Good installers for complicated software are also hard to write, in a way that requires your best developers to do it well. Consider the installer features being criticized here: things like good error checking. Writing code that doesn't handle errors gracefully is impossible for a junior person to do well. They just haven't been exposed to enough of the strange ways software fails in the field to do that job well. And not doing good error checking in general is a classic new developer issue.
If it were just a matter of diverting manpower from features to get a good or better installer; that could easily be justified. It's that you need to divert very experienced people to do it well, and those are never available in the quantities development companies would like.
Why should they go to jail? Honestly, there are people who fuck up entire countries and their partners, and not only get away with it, but actually get applauded at the end of their terms.
Yes, all of those people should be in jail too. The fact that a large swath of our government and corporate officers are corrupt and criminally negligent, and that's considered fine by many of the ignorant masses who believe what the news tell them, is one of the largest structural problems in the world right now.
Here is the important line from the article you quoted:
"The implied valuation of the company is equivalent to 47 times the pre-tax profits earned by Autonomy in the 12 months to June this year."
If you buy a company on valuation terms like that, the way HP did, whoever voted for the decision should be held accountable by their stockholders and be facing jail time. If it happened because Autonomy sold them some story about future profit magic and they bought it, that does not change the fact that HP was criminally negligent in paying that much for a company.
Yes, it is dangerous for small companies to take giants amounts of other people's R&D on Linux and use it selfishly. If you're going to use a large body of public code licensed under the GPL, and then figure out loopholes such that you don't release derivative work based on it, expect that you will be considered a bad member of the software community for doing so. If that's not acceptable to you, you shouldn't have used all of the Linux code freely provided to you without thinking about that. The GPL is a written contract, but along with it is an implied social contract that involves releasing code. Companies can ignore that social part, but it's unwise to think it doesn't matter.
If you're considering building software on Linux and are so disconnected from the expectations of its developers that you're not aware of the controversy around topics like Tivoization, you really haven't done your homework.
This is a no lose political play by RedHat; they never expected there was a real licensing violation. Consider the two outcomes here:
-Rising Tide Systems says that it developed their EXTENDED_COPY and COMPARE_AND_WRITE commands under a different license, walled off from the main code they contributed to the kernel under the GPL. (That's what they've done now). Then RedHat's sales position is that people who buy Rising Tide's Linux are getting a licensed closed-source product. It is guaranteed not to integrate smoothly with the *real* Linux kernel because of the architecture needed to keep it licensed differently, it's not getting community review for features and security issues, and if Rising Tide goes out of business their customers are screwed--good old fashioned vendor lock-in.
-Rising Tide rolls over and releases their code into the mainline kernel. Now RedHat benefits from it being available too.
RedHat makes much of its money from companies that are moving to open-source because they are sick of the downsides of commercial software, which go from quality issues to vendor lock-in. They're compelling Rising Tide to either give away somethings they're trying to keep closed, or to shame themselves by admitting they're not really an open-source team player. RedHat can launch that sort of acusation safely because they are operating very transparently. We know that companies are not locked in to RedHat from how many clones of it exist. When CentOS and Scientific Linux work, clearly RedHat is sharing all the important parts. And if you've made that part of your competing position, preaching down to people who are not sharing as being sellers of inferior products is very easy to do.
FDE is mandatory for keeping all of the data on a stolen laptop from being exposed. It allows something that is broken to be repairs without fear that the repair company will get access to everything as well. That someone might give up their key if pressed for it--via violence, court order, or stealth--doesn't mean it's useless to use in the general case.
There is still no FDE in Mint 14. Even worse, the reports I've read suggest that Mint 14 broke the popular howoto hack. The feature voting board was recently updated to say this feature was "selected" though. Hopefully that means it will be coming in Mint 15. Linux distributions are useless to me without encryption; you're basically saying "this is not meant for real work" to every business user who might consider it. It's a shame that Mint isn't ready to fill in yet for companies who are pushed away from Microsoft OSes by the mess around Windows 8.
Kid, you obviously don't know anything about dating in 1967. During the Summer of Love, showers were strictly optional, and instead of going for a burger the invitation would include "we'll get some acid".
Intel provides an Itanium reference board that makes it possible for other manufacturers to release OEM Itanium based systems. As a second manufacturer example, I've used on of Bull's Novascale Bullion servers. It wasn't very cost effective, but it did include 256 cores, and continued running just fine when one socket was damaged during shipping. The sort of applications that need that many cores and heavy redundancy against hardware failures exist, and no commodity hardware will satisfy them. There's just only a few hundred thousand of such systems sold each year.
Confinity, the company that originally wrote PayPal, had the Palm Pilot and similar mobile units as their first target for deploying the software. That's either idiotic or visionary depending on how you look at it; in any case it wasn't going anywhere in 2000. Elon's company X.com was instead focusing on online banking. It's fair to say that the original PayPal business model was crap, and Elon refocusing the service to the web and promoting it was important to it becoming successful. Inventing the business model that turns technology into a useful service is important, and it's fair for him to take credit for that.
Slashdot Mirror
The monitoring in the US is particularly bad given how it's been combined with reduced right to legal process, all under the banner of fighting terrorism. That's not new either though; the parallels between Guantanamo Bay and the 1942 Japanese American internment are very obvious.
If you care enough about quality that you're using AccurateRip and need to check how the drive is caching, a USB interface might not work. The sort of USB->SATA chipsets used in USB CD-ROMs, which are universally cheap devices nowadays, will likely not pass data through faithfully enough to be useful for accurate CD ripping.
That said, it is possible to find useful models if you test carefully. The external drive I'm using is a LG "Portable Super Multi Drive", model GP10NB20. LG makes many of the best CD ripping DVD drives available, and the USB chipset in this model is transparent enough for accurate ripping. At around $35, it's not the cheapest model on the market, but it's not like that's expensive.
The biggest source for early XFS corruption issues was that at the time the filesystem was introduced, most drives on the market lied about write caching. XFS was the first Linux filesystem that depended on write barriers working properly. If something was declared written but not really on disk, filesystem corruption could easily result after a crash. But when XFS was released in 2001, all the cheap ATA disks in PC hardware lied about writes being complete, Linux didn't know how to work around that, and as such barriers were not reliable on them. SGI didn't realize how big of a problem this was because their own hardware, the IRIX systems XFS was developed for, used better quality drivers where this didn't happen. But take that same filesystem and run it on random PC hardware of the era, and it usually doesn't work.
ext4 will fail in the same way XFS used to, if you run it on old hardware. That bug was only fixed in kernel 2.6.32, with an associated performance loss on software like PostgreSQL that depends on write barriers for its own reliable operation too. Nowadays write barriers on Linux are handled by flushing the drive's cache out, all SATA drives support that cache flushing call, and the filesystems built on barriers work fine.
Many of the other obscure XFS bugs were flushed out when RedHat did QA for RHEL6. In fact, XFS is the only good way to support volumes over 16TB in size, as part of their Scalable File System package, a fairly expensive add-on the RHEL6. All of the largest Linux installs I deal with are on XFS, period.
I wouldn't use XFS on a kernel before RHEL6 / Debian Squeeze though. I know the software side of the write barrier implementation, the cache flushing code, works in the 2.6.32 derived kernels they run. The bug I pointed to as fixed in 2.6.32 was specific to ext4, but there were lots of other fixes to that kernel in this area. I don't trust any of the earlier kernels for ext4 or xfs.
Differences among models in a motherboard line are larger than variation among manufacturers. Check out the BeHardware Components returns rates survey for example. The average quality from MSI, Asus, and Gigabyte is very evenly matched. But both Asus and Gigabyte have models that are just plain junk.
As for "more important than ever", in the last 10 years the period when motherboards were most critical to select carefully was the peak of the capacitor plague era.
The problem isn't just that time spent on installers would be better spent adding features. Good installers for complicated software are also hard to write, in a way that requires your best developers to do it well. Consider the installer features being criticized here: things like good error checking. Writing code that doesn't handle errors gracefully is impossible for a junior person to do well. They just haven't been exposed to enough of the strange ways software fails in the field to do that job well. And not doing good error checking in general is a classic new developer issue.
If it were just a matter of diverting manpower from features to get a good or better installer; that could easily be justified. It's that you need to divert very experienced people to do it well, and those are never available in the quantities development companies would like.
Your movie idea is odd, but I would still prefer watching it to using GNOME3.
Jesus cries when he loses to statistics.
Why should they go to jail? Honestly, there are people who fuck up entire countries and their partners, and not only get away with it, but actually get applauded at the end of their terms.
Yes, all of those people should be in jail too. The fact that a large swath of our government and corporate officers are corrupt and criminally negligent, and that's considered fine by many of the ignorant masses who believe what the news tell them, is one of the largest structural problems in the world right now.
Here is the important line from the article you quoted:
"The implied valuation of the company is equivalent to 47 times the pre-tax profits earned by Autonomy in the 12 months to June this year."
If you buy a company on valuation terms like that, the way HP did, whoever voted for the decision should be held accountable by their stockholders and be facing jail time. If it happened because Autonomy sold them some story about future profit magic and they bought it, that does not change the fact that HP was criminally negligent in paying that much for a company.
And he's only vulnerable because he forgot to renew his yearly protection fees. Ha-ha!
Actually the 17 year old girlfriend has been taking the bath salts, so she both thinks and looks as if she's aged 3 years in the last month.
Yes, it is dangerous for small companies to take giants amounts of other people's R&D on Linux and use it selfishly. If you're going to use a large body of public code licensed under the GPL, and then figure out loopholes such that you don't release derivative work based on it, expect that you will be considered a bad member of the software community for doing so. If that's not acceptable to you, you shouldn't have used all of the Linux code freely provided to you without thinking about that. The GPL is a written contract, but along with it is an implied social contract that involves releasing code. Companies can ignore that social part, but it's unwise to think it doesn't matter.
If you're considering building software on Linux and are so disconnected from the expectations of its developers that you're not aware of the controversy around topics like Tivoization, you really haven't done your homework.
This is a no lose political play by RedHat; they never expected there was a real licensing violation. Consider the two outcomes here:
-Rising Tide Systems says that it developed their EXTENDED_COPY and COMPARE_AND_WRITE commands under a different license, walled off from the main code they contributed to the kernel under the GPL. (That's what they've done now). Then RedHat's sales position is that people who buy Rising Tide's Linux are getting a licensed closed-source product. It is guaranteed not to integrate smoothly with the *real* Linux kernel because of the architecture needed to keep it licensed differently, it's not getting community review for features and security issues, and if Rising Tide goes out of business their customers are screwed--good old fashioned vendor lock-in.
-Rising Tide rolls over and releases their code into the mainline kernel. Now RedHat benefits from it being available too.
RedHat makes much of its money from companies that are moving to open-source because they are sick of the downsides of commercial software, which go from quality issues to vendor lock-in. They're compelling Rising Tide to either give away somethings they're trying to keep closed, or to shame themselves by admitting they're not really an open-source team player. RedHat can launch that sort of acusation safely because they are operating very transparently. We know that companies are not locked in to RedHat from how many clones of it exist. When CentOS and Scientific Linux work, clearly RedHat is sharing all the important parts. And if you've made that part of your competing position, preaching down to people who are not sharing as being sellers of inferior products is very easy to do.
Let's be honest. You didn't get the joke.
Could be worst--at least it's not Cinnamon the Maltese puppy
FDE is mandatory for keeping all of the data on a stolen laptop from being exposed. It allows something that is broken to be repairs without fear that the repair company will get access to everything as well. That someone might give up their key if pressed for it--via violence, court order, or stealth--doesn't mean it's useless to use in the general case.
There is still no FDE in Mint 14. Even worse, the reports I've read suggest that Mint 14 broke the popular howoto hack. The feature voting board was recently updated to say this feature was "selected" though. Hopefully that means it will be coming in Mint 15. Linux distributions are useless to me without encryption; you're basically saying "this is not meant for real work" to every business user who might consider it. It's a shame that Mint isn't ready to fill in yet for companies who are pushed away from Microsoft OSes by the mess around Windows 8.
No, there's been plenty of blind hate for Rovi/Macrovision too.
Kid, you obviously don't know anything about dating in 1967. During the Summer of Love, showers were strictly optional, and instead of going for a burger the invitation would include "we'll get some acid".
Intel provides an Itanium reference board that makes it possible for other manufacturers to release OEM Itanium based systems. As a second manufacturer example, I've used on of Bull's Novascale Bullion servers. It wasn't very cost effective, but it did include 256 cores, and continued running just fine when one socket was damaged during shipping. The sort of applications that need that many cores and heavy redundancy against hardware failures exist, and no commodity hardware will satisfy them. There's just only a few hundred thousand of such systems sold each year.
I was picturing him behind the keyboard.
Cisco has unwisely been fighting a land war in Asia too.
Mixed with periodic bad trips where oh my god THE HEADCRABS are eating me!
Confinity, the company that originally wrote PayPal, had the Palm Pilot and similar mobile units as their first target for deploying the software. That's either idiotic or visionary depending on how you look at it; in any case it wasn't going anywhere in 2000. Elon's company X.com was instead focusing on online banking. It's fair to say that the original PayPal business model was crap, and Elon refocusing the service to the web and promoting it was important to it becoming successful. Inventing the business model that turns technology into a useful service is important, and it's fair for him to take credit for that.
You've had simulated sex with a BMW? That does sound like it would be terrible.