No, that would be Thompson and Ritchie. Stallman's neckbeard has spread horizontally to try and compete, but it's still no match for the epic reach into the neck Thompson's has in that shot.
SMART is a part of the modern drive's firmware. You can't bypass it. Anyone who tells you otherwise--such as the makers of Spinrite--is lying to you in order to sell a product.
The quality of SMART implementation varies significantly based on the manufacturer. Anecdotally, I have 3 failed Western Digital drives here that flat out lie about the drive's errors. Running the tool needed to generate an RMA does a full SMART scan of the drive, remaps some bad sectors, and then says everything is good. But it's not--each drive is still broken, in a way the firmware seems downright evasive about. Try to use it again, it doesn't take long until another failure. It does seem like the sole purpose of SMART and its associated utilities on WD drives is to keep people from returning a bad drive, by providing a gatekeeper in that process that never says there's a problem.
Most of my serious installations avoid WD drives like the plague for this reason. I think that Seagate's drives are probably less reliable overall than WD nowadays. Regardless I prefer them, simply because the firmware is more honest about the errors that do happen. Drives fail and I plan for that. What I can't deal with is drives that fail but don't admit it.
The reason there are "RAID edition" firmware available is to provide a drive that isn't supposed to be as evasive about errors. It may be that some WD RAID edition models might not have the problem I'm describing. I soured on them as a brand before those became mainstream.
Spinrite hasn't been useful for years. There's a good analysis why at Does SpinRite do what it claims to do?. Everything the program does can be done more efficiently with a simpler program run from a Linux boot CD. And the fact that it takes so long is a problem--you want to get data off a dying drive as quickly as possible. Here's what I wrote on that question years ago, and the rise of SSDs make this even more true now:
SpinRite was a great program in the era it was written, a long time ago. Back then, it would do black magic to recover drives that were seemingly toast, by being more persistent than the drive firmware itself was.
But here in 2009, it's worthless. Modern drives do complicated sector mapping and testing on their own, and SpinRite is way too old to know how to trigger those correctly on all the drives out there. What you should do instead is learn how to use smartmontools, probably via a Linux boot CD (since the main time you need them is when the drive is already toast).
My usual routine when a drive starts to go back is to back its data up using dd, run smartmontools to see what errors its reporting, trigger a self-test and check the errors again, and then launch into the manufacturer's recovery software to see if the problem can be corrected by it. The idea that SpinRite knows more about the drive than the interface provided by SMART and the manufacturer tools is at least ten years obsolete. Also, getting the information into the SMART logs helps if you need to RMA the drive as defective, something SpinRite doesn't help you with.
Note that the occasional reports you see that SpinRite "fixes" problems are coincidence. If you access a sector on a modern drive that is bad, the drive will often remap it for you from the spares kept around for that purpose. All SpinRite did was access the bad sector, it didn't actually repair anything. This is why you still get these anecdotal "it worked for me" reports related to it--the same thing would have been much better accomplished with a SMART scan.
When someone's reaction to building software is "bring in new multiple team leaders and consultants" without input from the current tech lead, then, yes, they are a know nothing douchebag.
From TFA: "Enlightenment and its libraries are all open source (BSD 2 clause, LGPL or GPL for some executable binaries only). It is a mix because the person who founded each library chose the license, or a license is inherited from some original source." They are trying to integrate into a standard freedesktop.org environment now. I doubt you can do that without utilizing a few GPL library components.
Elive is Debian with Enlightnment E16 and regularly updated E17 builds. It's a live CD so you can test it out before deciding to install. If you install the leading edge Debian Wheezy, e17 is packaged too.
Even your longer example doesn't do enough justice to how much of this problem is management based. This article was terribly biased toward blaming programmers for these issues. Schedule pressure to release on a date no matter what causes more bugs than anything else. Having some sort of deadline is necessary; if left on their own, programmers like to tinker with stuff forever. But you can only compress things so much, and management requirements are often impossible to hit. The standard example here is the Fred Brooks one of "9 women can't make a baby in 1 month".
If companies valued their programmers doing high quality coding, I'd make a living teaching classes in things like error handling paranoia. But they don't. The developers are just an expense to be reduced, and there's almost no business environment that values high quality software correctly.
This is learning the hard way, only it's the maintainer of the site who's learning.
Any tutorial is not the hard way. Everything important I know about UNIX systems was learned while the server and Internet were down. I learned Solaris that hard way; here's how that works. I started a job where I replaced a Solaris admin at an ISP. I was a Linux person, had to learn as I went how to deal with Sun hardware and software. My second day the DNS server crashed and wouldn't come back up. I had a Solaris documentation CD-ROM as my only resource. Go!
Jams and misfires often happen due to ammunition issues. Any drop in reliability for a safety mechanism is going to be additive on top of that. And just the ammo problem rate alone is inherently too high for some people, so a second component adding more risk is hard to justify.
The fact that jams etc. are relatively rare events is part of why I'm not optimistic about fancier electronic mechanisms. How often does software break because it's presented with a rare failure case the programmer didn't anticipate or test? It is amazingly easy to break a lot of software, sometimes permanently afterward, just by running out of disk space. If I have a threat serious enough that I'm arming myself against it, I'd prefer not to have a gun that crashes the first time an unusual ammo jam happens. We've had hundreds of years of evolution in mechanical firing mechanisms to resist problems seen in the field here; it will take a while to match that. And the disappointing track record so far for things like fingerprint security have not been encouraging.
Yes, it's possible to put enough money into R&D to make this a negligable risk, eventually. But who wants to fund that work? It's not as if a unique ID trigger suddenly makes the firearm so safe that you can just leave it sitting out. That means you still need a secured safe instead...so that's what the market has been providing. People who are willing to pay for that safety measure already have options available. And those don't become unnecessary if this other problem is solved, which adds to why it's hard to cost justify.
Firearms are mechanically simple. You can't add electronics to a simple mechanical device and make it more reliable. Electronics are less reliable than simple mechanical things, so any such change is a step backward.
Cars and planes are complicated mechanical and electrical devices. You can simplify the circuits and/or mechanical design by replacing some parts with computer control. But just the engine alone in either is well over an order of magnitude more complicated than a gun firing mechanism.
Good try on the car analogy though, somebody had to do it.
The new agreement says the pictures are being moved to holy ground?
Re:Advantages of Perl
on
Perl Turns 25
·
· Score: 2, Insightful
Programs from 1998 still run because the language has been stagnant ever since. Python breaks because it actually improves sometimes. "The main power of Perl has always been its ability to quickly adapt"...seriously? Perl 6 has been stuck in R&D hell for a dozen years now. Even the Duke Nukem Forever team is starting to feel awkward about how long it's taking.
The fact that you get enough game requests to be annoyed is proving my point. You block all the game requests because you prefer social interaction. But they are very popular, and back before many people were around, it was possible to stay on their site usefully much longer than their competitors. It started due to the applications platform appearing in mid 2007. That event was the inflection point when I started seeing massive migrations of people from MySpace to Facebook. You can easily see it on the growth graph; that is when the site started seriously accelerating in adoption. The app platform launches in May, and by October growth has turned upwards in a big way.
Facebook beat Myspace etc. because they had a good games platform, along with a larger application UI. They were the first site to get other companies adding useful content and services to their site in quantity. There's a reason Zynga raised a billion dollars in their IPO. It was programs like their Farmville that kept people staying on Facebook after they got bored with simple social interaction. Nowadays this isn't as obvious, but when I started on Facebook in 2007, it was easy to blow a lot of time there even without a lot of friends, by playing games instead.
Corsair's AX850 is a solid power supply OEM'd from Seasonic. But you can't cost justify buying one unless you have a truly ridiculous system. As of a few years ago, a good 500W power supply was already plenty to handle even three video card systems, and CPUs in particular have just reduced power requirements since. Newegg is showing me the AX850 as $189. You can get their similarly constructed 650W TX650M instead for $109. I was willing to pay whatever I had to in order to get the most reliable setup possible, but it was impossible to justify buying something more expensive than that. Computers nowadays just don't draw that much power. And if you only have one video card...anything over the good 400W power supplies in the $60 to $70 range is overkill.
An early implementation of Materialized Views was just submitted in November to the project. It may not be finished in time for PostgreSQL 9.3, but it will almost certainly be in the next release if not that one.
Unfortunately secure booting is linked so tightly with vendor lockdown, tracking, and DRM concerns that I never expect it to be embraced by any open-source community. Hysteria over treacherous computing so far has been overblown. For example, the potential abuse of the unique ID features of the TPM chips were not sufficient reason for the boycott against using them when available they generated--especially if you're booting into an open-source OS.
It's pretty ridiculous that software like trusted grub isn't in mainstream Linux distributions, while Windows booting is easy to protect using the TPM with BitLocker. I boot my Linux/Windows Thinkpad using the Windows boot loader specifically because it resists evil maid attacks better when I'm traveling. The hysteria isn't limited to Linux; the same indefensible arguments are made by TrueCrypt. That acts as if TPM provides no protection against physical attacks, which is ridiculous if you look at how much work it takes to hack one.
Windows XP is on "extended support" until April of 2014. There are plenty of businesses that won't even think about upgrading to a later version until that deadline is only a few months off. Global market share for XP still 20 to 35%.
The advertising clause made it impossible to combine the BSD programs with GNU ones in some ways. It's fair to say it's not directly the fault of the BSD license, because it results from license terms that interact very badly. That is effectively a strong restriction though, given the state of open source software at the time. Several of the only feasible choices for critical parts of an open source stack then--gcc comes to mind--were only available via the GNU license.
Slashdot Mirror
No, that would be Thompson and Ritchie. Stallman's neckbeard has spread horizontally to try and compete, but it's still no match for the epic reach into the neck Thompson's has in that shot.
SMART is a part of the modern drive's firmware. You can't bypass it. Anyone who tells you otherwise--such as the makers of Spinrite--is lying to you in order to sell a product.
The quality of SMART implementation varies significantly based on the manufacturer. Anecdotally, I have 3 failed Western Digital drives here that flat out lie about the drive's errors. Running the tool needed to generate an RMA does a full SMART scan of the drive, remaps some bad sectors, and then says everything is good. But it's not--each drive is still broken, in a way the firmware seems downright evasive about. Try to use it again, it doesn't take long until another failure. It does seem like the sole purpose of SMART and its associated utilities on WD drives is to keep people from returning a bad drive, by providing a gatekeeper in that process that never says there's a problem.
Most of my serious installations avoid WD drives like the plague for this reason. I think that Seagate's drives are probably less reliable overall than WD nowadays. Regardless I prefer them, simply because the firmware is more honest about the errors that do happen. Drives fail and I plan for that. What I can't deal with is drives that fail but don't admit it.
The reason there are "RAID edition" firmware available is to provide a drive that isn't supposed to be as evasive about errors. It may be that some WD RAID edition models might not have the problem I'm describing. I soured on them as a brand before those became mainstream.
Spinrite hasn't been useful for years. There's a good analysis why at Does SpinRite do what it claims to do?. Everything the program does can be done more efficiently with a simpler program run from a Linux boot CD. And the fact that it takes so long is a problem--you want to get data off a dying drive as quickly as possible. Here's what I wrote on that question years ago, and the rise of SSDs make this even more true now:
SpinRite was a great program in the era it was written, a long time ago. Back then, it would do black magic to recover drives that were seemingly toast, by being more persistent than the drive firmware itself was.
But here in 2009, it's worthless. Modern drives do complicated sector mapping and testing on their own, and SpinRite is way too old to know how to trigger those correctly on all the drives out there. What you should do instead is learn how to use smartmontools, probably via a Linux boot CD (since the main time you need them is when the drive is already toast).
My usual routine when a drive starts to go back is to back its data up using dd, run smartmontools to see what errors its reporting, trigger a self-test and check the errors again, and then launch into the manufacturer's recovery software to see if the problem can be corrected by it. The idea that SpinRite knows more about the drive than the interface provided by SMART and the manufacturer tools is at least ten years obsolete. Also, getting the information into the SMART logs helps if you need to RMA the drive as defective, something SpinRite doesn't help you with.
Note that the occasional reports you see that SpinRite "fixes" problems are coincidence. If you access a sector on a modern drive that is bad, the drive will often remap it for you from the spares kept around for that purpose. All SpinRite did was access the bad sector, it didn't actually repair anything. This is why you still get these anecdotal "it worked for me" reports related to it--the same thing would have been much better accomplished with a SMART scan.
When someone's reaction to building software is "bring in new multiple team leaders and consultants" without input from the current tech lead, then, yes, they are a know nothing douchebag.
From TFA: "Enlightenment and its libraries are all open source (BSD 2 clause, LGPL or GPL for some executable binaries only). It is a mix because the person who founded each library chose the license, or a license is inherited from some original source." They are trying to integrate into a standard freedesktop.org environment now. I doubt you can do that without utilizing a few GPL library components.
Elive is Debian with Enlightnment E16 and regularly updated E17 builds. It's a live CD so you can test it out before deciding to install. If you install the leading edge Debian Wheezy, e17 is packaged too.
Even your longer example doesn't do enough justice to how much of this problem is management based. This article was terribly biased toward blaming programmers for these issues. Schedule pressure to release on a date no matter what causes more bugs than anything else. Having some sort of deadline is necessary; if left on their own, programmers like to tinker with stuff forever. But you can only compress things so much, and management requirements are often impossible to hit. The standard example here is the Fred Brooks one of "9 women can't make a baby in 1 month".
If companies valued their programmers doing high quality coding, I'd make a living teaching classes in things like error handling paranoia. But they don't. The developers are just an expense to be reduced, and there's almost no business environment that values high quality software correctly.
Seriously, shouldn't FB at least split the payola with the receiver?
They already made the upside of their payola available to people, but it didn't work out so well for those who did.
My e-mail client doesn't show me images. When I view messages in Facebook I have no choice but to see whatever images they have decided are allowed.
This is learning the hard way, only it's the maintainer of the site who's learning.
Any tutorial is not the hard way. Everything important I know about UNIX systems was learned while the server and Internet were down. I learned Solaris that hard way; here's how that works. I started a job where I replaced a Solaris admin at an ISP. I was a Linux person, had to learn as I went how to deal with Sun hardware and software. My second day the DNS server crashed and wouldn't come back up. I had a Solaris documentation CD-ROM as my only resource. Go!
Obviously that SKS is super safe, why it doesn't even have the usual bayonet on it! It's practically child-proof like that.
Jams and misfires often happen due to ammunition issues. Any drop in reliability for a safety mechanism is going to be additive on top of that. And just the ammo problem rate alone is inherently too high for some people, so a second component adding more risk is hard to justify.
The fact that jams etc. are relatively rare events is part of why I'm not optimistic about fancier electronic mechanisms. How often does software break because it's presented with a rare failure case the programmer didn't anticipate or test? It is amazingly easy to break a lot of software, sometimes permanently afterward, just by running out of disk space. If I have a threat serious enough that I'm arming myself against it, I'd prefer not to have a gun that crashes the first time an unusual ammo jam happens. We've had hundreds of years of evolution in mechanical firing mechanisms to resist problems seen in the field here; it will take a while to match that. And the disappointing track record so far for things like fingerprint security have not been encouraging.
Yes, it's possible to put enough money into R&D to make this a negligable risk, eventually. But who wants to fund that work? It's not as if a unique ID trigger suddenly makes the firearm so safe that you can just leave it sitting out. That means you still need a secured safe instead...so that's what the market has been providing. People who are willing to pay for that safety measure already have options available. And those don't become unnecessary if this other problem is solved, which adds to why it's hard to cost justify.
Firearms are mechanically simple. You can't add electronics to a simple mechanical device and make it more reliable. Electronics are less reliable than simple mechanical things, so any such change is a step backward.
Cars and planes are complicated mechanical and electrical devices. You can simplify the circuits and/or mechanical design by replacing some parts with computer control. But just the engine alone in either is well over an order of magnitude more complicated than a gun firing mechanism.
Good try on the car analogy though, somebody had to do it.
The new agreement says the pictures are being moved to holy ground?
Programs from 1998 still run because the language has been stagnant ever since. Python breaks because it actually improves sometimes. "The main power of Perl has always been its ability to quickly adapt"...seriously? Perl 6 has been stuck in R&D hell for a dozen years now. Even the Duke Nukem Forever team is starting to feel awkward about how long it's taking.
The fact that you get enough game requests to be annoyed is proving my point. You block all the game requests because you prefer social interaction. But they are very popular, and back before many people were around, it was possible to stay on their site usefully much longer than their competitors. It started due to the applications platform appearing in mid 2007. That event was the inflection point when I started seeing massive migrations of people from MySpace to Facebook. You can easily see it on the growth graph; that is when the site started seriously accelerating in adoption. The app platform launches in May, and by October growth has turned upwards in a big way.
Facebook beat Myspace etc. because they had a good games platform, along with a larger application UI. They were the first site to get other companies adding useful content and services to their site in quantity. There's a reason Zynga raised a billion dollars in their IPO. It was programs like their Farmville that kept people staying on Facebook after they got bored with simple social interaction. Nowadays this isn't as obvious, but when I started on Facebook in 2007, it was easy to blow a lot of time there even without a lot of friends, by playing games instead.
That the US government is spying on social networks is fact shown multiple places. And only the EFF seems to be doing anything to slow it.
I have my sock puppets play pet society, to remind me how Facebook's overpriced stock looks just like pets.com circa 2000.
Corsair's AX850 is a solid power supply OEM'd from Seasonic. But you can't cost justify buying one unless you have a truly ridiculous system. As of a few years ago, a good 500W power supply was already plenty to handle even three video card systems, and CPUs in particular have just reduced power requirements since. Newegg is showing me the AX850 as $189. You can get their similarly constructed 650W TX650M instead for $109. I was willing to pay whatever I had to in order to get the most reliable setup possible, but it was impossible to justify buying something more expensive than that. Computers nowadays just don't draw that much power. And if you only have one video card...anything over the good 400W power supplies in the $60 to $70 range is overkill.
An early implementation of Materialized Views was just submitted in November to the project. It may not be finished in time for PostgreSQL 9.3, but it will almost certainly be in the next release if not that one.
Unfortunately secure booting is linked so tightly with vendor lockdown, tracking, and DRM concerns that I never expect it to be embraced by any open-source community. Hysteria over treacherous computing so far has been overblown. For example, the potential abuse of the unique ID features of the TPM chips were not sufficient reason for the boycott against using them when available they generated--especially if you're booting into an open-source OS.
It's pretty ridiculous that software like trusted grub isn't in mainstream Linux distributions, while Windows booting is easy to protect using the TPM with BitLocker. I boot my Linux/Windows Thinkpad using the Windows boot loader specifically because it resists evil maid attacks better when I'm traveling. The hysteria isn't limited to Linux; the same indefensible arguments are made by TrueCrypt. That acts as if TPM provides no protection against physical attacks, which is ridiculous if you look at how much work it takes to hack one.
Windows XP is on "extended support" until April of 2014. There are plenty of businesses that won't even think about upgrading to a later version until that deadline is only a few months off. Global market share for XP still 20 to 35%.
It really is impossible to legally combine GPL and original BSD licensed software. See Why is the original BSD license incompatible with the GPL?.
The advertising clause made it impossible to combine the BSD programs with GNU ones in some ways. It's fair to say it's not directly the fault of the BSD license, because it results from license terms that interact very badly. That is effectively a strong restriction though, given the state of open source software at the time. Several of the only feasible choices for critical parts of an open source stack then--gcc comes to mind--were only available via the GNU license.