Also if the article I linked to and the gamers I worked for are any indication SSDs don't "fail gracefully" or give you plenty of advanced warning like HDDs do. With every HDD I've had fail short of being dropped there was plenty of time to get the data off as SMART gave warning long before the point of no return. With both of the gamers it was "flip the switch and its gone" no warning at all.
I'd agree - don't use SSDs to store important data, or, if you feel that you must, be obsessive about backing it up. My own experience with SSDs have been mixed. I've used them in two OpenSolaris (actually now OpenIndiana) systems. They were identical OCZ Vertex 20GB drives, used for ZFS L2ARC (caching). One of them failed in operation without warning after about a year in service, and the other is still working after a similar amount of time, but it will undoubtedly fail at any moment. Since the fried SSD was a cache, there was no data loss, but it still gives me pause to think of using one as a main drive.
The bad drive is completely dead; it is not even detected during POST. It has been replaced by a 60GB Samsung. I'm through with OCZ, not just for the drive, but I had one of their 700W power supplies go "pop" on me last November (shortly after the warranty expired).
Actually, the 50 Hz transformers would work just fine on 60 Hz (but they would be heavier than necessary). It's when you run a transformer on a lower-than-rated frequency that you need to derate its power-handling capacity.
Of course, there would be plenty of other problems with a frequency switch, especially changes in motor speeds. A whole lot of equipment would need to be replaced, or remotored and regeared. The logistics of switching half of Japan would dwarf that of Ontario's 1950s-era switch from 25 Hz to 60 Hz.
Not only that, but if you're don't feel like using using the OpenSSL command line, you could always use a GUI front-end like TinyCA to make life easier. On Ubuntu, it's available prepackaged.
They're just giving away the development tools for free. So when/if developers use them, and end users like the result, they've got you by the short and curlies. It's a time honoured tradition, often rightly or wrongly compared to a drug dealer's "the first hit is free, kid".
Another way of looking at it:
Prospective customer is already a Solaris (or Oracle DB, etc.) shop, and wants a project based on this platform. If the development tools cost a fortune, you might pass up the business.
That still doesn't excuse Oracle for its shabby treatment of the OpenSolaris community - though Sun was partly to blame with its half-hearted opening of Solaris to begin with. Illumos will be nice to have, but it's going to be a while before they replace the closed code with open code.
At the meter, you can calculate the power draw. Look for the Kh value on the meter, and count the number of seconds it takes for the disc to make one full rotation. Then, use this formula:
W = Kh / (Seconds / 3600)
to get the power draw in watts.
Of course, this assumes you're still using an old-school spinning-disc meter.
Actually, OpenSolaris was way ahead of Solaris 10 (as it was originally conceived as the development version of the yet-to-be-released Solaris 11). It has a more advanced version of ZFS, the COMSTAR storage framework, a package management framework, and other goodies not in Solaris 10.
Unfortunately, Oracle's corporate culture of radio silence was incompatible with Sun's open development model - and the very first thing they did when they took over was shut off the distro snapshots. I'm surprised it took them this long to quit updating the Mercurial repository.
The Achilles heel of OpenSolaris was that Sun chose a half-assed approach to opening the code; there are still lots of closed binaries, which means more work for the Illumos effort. They at least have an unencumbered C library now, but a lot more needs to be done.
When I started trying out OpenSolaris early this year, ZFS actually saved me from losing files to a hard drive that was silently corrupting data. Needless to say, my file server now runs OpenSolaris, even though the rest of my network is a mix of Linux and Windows.
Yes, FreeBSD has ZFS now, but it lags behind the OpenSolaris version - and I don't have the time for the compile-the-world approach for updates that the FreeBSD world prefers.
When they start using rectal numerology to prop up a story like this, I can't help but think that this is a propaganda piece to grease the skids for ACTA.
Step 1: Bamboozle Joe and Jane Consumer with nifty "the future is now" capabilities on shiny new gadgets. Step 2: Make them pay through the nose if they actually use them. Step 3: Profit! (for a while) Step 4: Go bankrupt when the Joes' and Janes' contracts are up, they don't renew them, and they switch back to cheap, basic phones.
In many Zappa albums, there are some tracks that are all-time favorites of mine, and others that I just can't stand. There are only a few albums of his that I can play through without interruption -- Hot Rats, the Shut Up 'N Play Yer Guitar series, Apostrophe ('), and Over-Nite Sensation come to mind.
This seems to be true with technology in general. Railway museums are a good example of this; the steam locomotives with their more-or-less blacksmith level technology have a better future as working exhibits than 1930s-era diesels. The restoration of the Flying Yankee streamliner required a great deal of effort to recreate the long-out-of-production injectors for its obsolete diesel engine.
As another example, the Seattle Museum of Communications has several working telephone switches representing a variety of different switching technologies. The most recent of these is a Western Electric #3 ESS, a small computer-controlled analog switch that was built in small quantities and was obsolescent when it rolled off the production line. It has a variety of proprietary chips that will never be made again, and spare parts are extremely scarce since most of the #3s built were scrapped. Contrast that with the 1920s-era panel switch, a Rube Goldberg contraption for which parts could be fabricated by any competent machine shop.
The one thing that is missing is an equivalent to CentOS. On the other hand, boot environments make it a lot more pleasant to keep up with OpenSolaris' bleeding edge than to do so with Fedora. If the latest update proves unsatisfactory, I can switch back to the previous boot environment.
The "OpenSolaris is dying" talk is FUD, plain and simple. Besides, if you really feel like you have to give up on OpenSolaris, ZFS has made it into FreeBSD as well.
I recently set up an OpenSolaris ZFS file storage server on my home network, and am using the latest development snapshots as they come out. Development has not stopped on OpenSolaris, by the way. At any rate, I think the Fedora vs. RHEL comparison is a pretty good summary - though we don't have a Solaris equivalent of CentOS.
One very cool thing in OpenSolaris is the "boot environment" capability; it uses the ZFS cloning feature to create what is in effect a separate installation when you upgrade from one version to the next. If the latest update doesn't work right, you can boot back into your previous setup without having to try to downgrade your installed packages.
IMO, that makes keeping up with the bleeding edge a lot less risky. I gave up on Fedora years ago when I had a "yum update" blow up in my face one too many times.
The downside: Hardware support is a bit limited. OpenSolaris doesn't have support for HighPoint controller cards, which work fine in Linux and FreeBSD.
The ECC support involves the motherboard RAM itself - each DIMM has extra chips to carry the error-correcting information. It's mainly used in servers that run 24x7. Single-bit errors are automatically corrected, and, if they occur, multiple-bit errors are at least detected. The point is of course to keep the server from crashing, or worse, silently corrupting data.
Up until about the mid-1990s, most PCs had parity memory, which provides error detection but not correction. But, in the rush to make things cheaper, computer makers realized that they could shave a few pennies off the cost of a machine by eliminating the parity chips. By doing so, they made it very easy for bad RAM to cause all sorts of hard-to-diagnose problems. Unfortunately, non-parity, non-ECC RAM became the standard, and there are very few places you can buy ECC DIMMs off-the-shelf.
Socket AM2+ and AM3 boards can easily support ECC RAM, but it's up to the motherboard maker to enable it. My recent Asus board for an OpenSolaris box has 4G of ECC memory installed.
Outside of the geek world, these data breaches either go unreported or just get a passing mention between breathless coverage of $CELEBRIDEATH and breathless coverage of $REALITY_SHOW_CONTESTANT. A lot of people simply don't realize that these things are going on.
If the Gimli Glider or Flight 1549 had been on an Airbus, there would have been a lot of dead people. When something goes wrong, Rule 1 is FLY THE FUCKING PLANE. Well, if the computers fail on an Airbus, good luck flying it!
A critical factor in the Gimli Glider situation was that the pilot was able to put the plane into a forward slip - a maneuver that glider pilots routinely use, but is something that would normally Not Be Done in an airliner. In an Airbus, if the pilot tries to perform such an action, the computer will say "I'm sorry Dave. I don't think I can do that."
Slashdot Mirror
Also if the article I linked to and the gamers I worked for are any indication SSDs don't "fail gracefully" or give you plenty of advanced warning like HDDs do. With every HDD I've had fail short of being dropped there was plenty of time to get the data off as SMART gave warning long before the point of no return. With both of the gamers it was "flip the switch and its gone" no warning at all.
I'd agree - don't use SSDs to store important data, or, if you feel that you must, be obsessive about backing it up. My own experience with SSDs have been mixed. I've used them in two OpenSolaris (actually now OpenIndiana) systems. They were identical OCZ Vertex 20GB drives, used for ZFS L2ARC (caching). One of them failed in operation without warning after about a year in service, and the other is still working after a similar amount of time, but it will undoubtedly fail at any moment. Since the fried SSD was a cache, there was no data loss, but it still gives me pause to think of using one as a main drive.
The bad drive is completely dead; it is not even detected during POST. It has been replaced by a 60GB Samsung. I'm through with OCZ, not just for the drive, but I had one of their 700W power supplies go "pop" on me last November (shortly after the warranty expired).
"Elevation of starting location is 158.171 meters. A tsunami must start in the ocean."
Then again, I was trying to create a tsunami on Lake Michigan.
Actually, the 50 Hz transformers would work just fine on 60 Hz (but they would be heavier than necessary). It's when you run a transformer on a lower-than-rated frequency that you need to derate its power-handling capacity.
Of course, there would be plenty of other problems with a frequency switch, especially changes in motor speeds. A whole lot of equipment would need to be replaced, or remotored and regeared. The logistics of switching half of Japan would dwarf that of Ontario's 1950s-era switch from 25 Hz to 60 Hz.
Not only that, but if you're don't feel like using using the OpenSSL command line, you could always use a GUI front-end like TinyCA to make life easier. On Ubuntu, it's available prepackaged.
Of course, how many years from now will that filter into the distros? My guess:
Gentoo: soon
Debian Unstable: 2Q 2011
Ubuntu, Fedora: 1Q 2012
Debian Stable: 2015
RHEL: 2020
They're just giving away the development tools for free. So when/if developers use them, and end users like the result, they've got you by the short and curlies. It's a time honoured tradition, often rightly or wrongly compared to a drug dealer's "the first hit is free, kid".
Another way of looking at it:
Prospective customer is already a Solaris (or Oracle DB, etc.) shop, and wants a project based on this platform. If the development tools cost a fortune, you might pass up the business.
That still doesn't excuse Oracle for its shabby treatment of the OpenSolaris community - though Sun was partly to blame with its half-hearted opening of Solaris to begin with. Illumos will be nice to have, but it's going to be a while before they replace the closed code with open code.
At the meter, you can calculate the power draw. Look for the Kh value on the meter, and count the number of seconds it takes for the disc to make one full rotation. Then, use this formula:
W = Kh / (Seconds / 3600)
to get the power draw in watts.
Of course, this assumes you're still using an old-school spinning-disc meter.
I was thinking that they stole Hotblack Desiato's stuntship.
Actually, OpenSolaris was way ahead of Solaris 10 (as it was originally conceived as the development version of the yet-to-be-released Solaris 11). It has a more advanced version of ZFS, the COMSTAR storage framework, a package management framework, and other goodies not in Solaris 10.
Unfortunately, Oracle's corporate culture of radio silence was incompatible with Sun's open development model - and the very first thing they did when they took over was shut off the distro snapshots. I'm surprised it took them this long to quit updating the Mercurial repository.
The Achilles heel of OpenSolaris was that Sun chose a half-assed approach to opening the code; there are still lots of closed binaries, which means more work for the Illumos effort. They at least have an unencumbered C library now, but a lot more needs to be done.
When I started trying out OpenSolaris early this year, ZFS actually saved me from losing files to a hard drive that was silently corrupting data. Needless to say, my file server now runs OpenSolaris, even though the rest of my network is a mix of Linux and Windows.
Yes, FreeBSD has ZFS now, but it lags behind the OpenSolaris version - and I don't have the time for the compile-the-world approach for updates that the FreeBSD world prefers.
When they start using rectal numerology to prop up a story like this, I can't help but think that this is a propaganda piece to grease the skids for ACTA.
Step 1: Bamboozle Joe and Jane Consumer with nifty "the future is now" capabilities on shiny new gadgets.
Step 2: Make them pay through the nose if they actually use them.
Step 3: Profit! (for a while)
Step 4: Go bankrupt when the Joes' and Janes' contracts are up, they don't renew them, and they switch back to cheap, basic phones.
In many Zappa albums, there are some tracks that are all-time favorites of mine, and others that I just can't stand. There are only a few albums of his that I can play through without interruption -- Hot Rats, the Shut Up 'N Play Yer Guitar series, Apostrophe ('), and Over-Nite Sensation come to mind.
One problem with freeze distillation is that it doesn't get rid of methanol. How are they getting around this problem?
This seems to be true with technology in general. Railway museums are a good example of this; the steam locomotives with their more-or-less blacksmith level technology have a better future as working exhibits than 1930s-era diesels. The restoration of the Flying Yankee streamliner required a great deal of effort to recreate the long-out-of-production injectors for its obsolete diesel engine.
As another example, the Seattle Museum of Communications has several working telephone switches representing a variety of different switching technologies. The most recent of these is a Western Electric #3 ESS, a small computer-controlled analog switch that was built in small quantities and was obsolescent when it rolled off the production line. It has a variety of proprietary chips that will never be made again, and spare parts are extremely scarce since most of the #3s built were scrapped. Contrast that with the 1920s-era panel switch, a Rube Goldberg contraption for which parts could be fabricated by any competent machine shop.
The one thing that is missing is an equivalent to CentOS. On the other hand, boot environments make it a lot more pleasant to keep up with OpenSolaris' bleeding edge than to do so with Fedora. If the latest update proves unsatisfactory, I can switch back to the previous boot environment.
The "OpenSolaris is dying" talk is FUD, plain and simple. Besides, if you really feel like you have to give up on OpenSolaris, ZFS has made it into FreeBSD as well.
I recently set up an OpenSolaris ZFS file storage server on my home network, and am using the latest development snapshots as they come out. Development has not stopped on OpenSolaris, by the way. At any rate, I think the Fedora vs. RHEL comparison is a pretty good summary - though we don't have a Solaris equivalent of CentOS.
One very cool thing in OpenSolaris is the "boot environment" capability; it uses the ZFS cloning feature to create what is in effect a separate installation when you upgrade from one version to the next. If the latest update doesn't work right, you can boot back into your previous setup without having to try to downgrade your installed packages.
IMO, that makes keeping up with the bleeding edge a lot less risky. I gave up on Fedora years ago when I had a "yum update" blow up in my face one too many times.
The downside: Hardware support is a bit limited. OpenSolaris doesn't have support for HighPoint controller cards, which work fine in Linux and FreeBSD.
The ECC support involves the motherboard RAM itself - each DIMM has extra chips to carry the error-correcting information. It's mainly used in servers that run 24x7. Single-bit errors are automatically corrected, and, if they occur, multiple-bit errors are at least detected. The point is of course to keep the server from crashing, or worse, silently corrupting data.
Up until about the mid-1990s, most PCs had parity memory, which provides error detection but not correction. But, in the rush to make things cheaper, computer makers realized that they could shave a few pennies off the cost of a machine by eliminating the parity chips. By doing so, they made it very easy for bad RAM to cause all sorts of hard-to-diagnose problems. Unfortunately, non-parity, non-ECC RAM became the standard, and there are very few places you can buy ECC DIMMs off-the-shelf.
Socket AM2+ and AM3 boards can easily support ECC RAM, but it's up to the motherboard maker to enable it. My recent Asus board for an OpenSolaris box has 4G of ECC memory installed.
Outside of the geek world, these data breaches either go unreported or just get a passing mention between breathless coverage of $CELEBRIDEATH and breathless coverage of $REALITY_SHOW_CONTESTANT. A lot of people simply don't realize that these things are going on.
CentOS could have simply morphed into MentOS
Just don't spill Diet Coke on your server!
If you're willing to do your own output generation, Zebra Technologies provides programming references for their printers.
I ran into that this morning. After a quick check of the CentOS Forums, I found the answer:
yum clean metadata
That fixed it for me.
As they say, "Be sure brain is engaged before putting mouth in gear."
Still, the Gimli Glider is a good example of why the pilot should be able to make the final decisions.
If the Gimli Glider or Flight 1549 had been on an Airbus, there would have been a lot of dead people. When something goes wrong, Rule 1 is FLY THE FUCKING PLANE. Well, if the computers fail on an Airbus, good luck flying it!
A critical factor in the Gimli Glider situation was that the pilot was able to put the plane into a forward slip - a maneuver that glider pilots routinely use, but is something that would normally Not Be Done in an airliner. In an Airbus, if the pilot tries to perform such an action, the computer will say "I'm sorry Dave. I don't think I can do that."