Or you can just not opt into pointless farting around with the exacting stuff, and make a gun-type fission weapon on the general principle of the Hiroshima weapon. The principle and the level of engineering required are both so dead simple foolproof that you can skip the proof testing.
A gun-type weapon will even work fine without an initiator if you pay enough attention to the combined bullet and target staying together for the fraction of a second necessary for spontaneous neutron emission to do the job.
It is considered that a gun-type will not work with plutonium because of pre-ignition before the bullet and target are fully assembled. What I have never seen is an analysis of likely explosive yield given pre-ignition. An explosion of only 1-10% of maximum theoretical would still do one hell of a lot of damage. Also, a "dirty bomb" with comparatively slight explosive effect might float the boat of a terrorist. It most certainly would ruin the day of a city.
On which grounds do you refuse the right of the residents to decide who they want to belong to again?
I suspect GP realizes on some level that there are no conceivable moral grounds for such refusal, any more than there were grounds for the Union, headed by the tyrant Abraham Lincoln, engaging in murder and mayhem to prevent the self-determination of Virginia and the Confederacy.
But then again, Ukraine and Russia are both similarly at fault, although at least there has been very little bloodshed to date in the current affair, when compared for example to the War of Northern Aggression.
Hard disks use ECC to allow the disk to reach the capacities it does. It is not designed for anything other then making the hard disk perform well. It doesn't protect you against hard disks which write incorrect data to start with, or have faulty cables etc.
So you don't think it's worth providing recovery from some error cases just because you can't protect against every single case?
If you don't mind my asking, why would you claim something that is patently untrue? ECC detects and corrects ALL instances of a hard drive writing single bad bits per sector. So it's clearly "protecting you" against a great many instances of "incorrect data" being written by the drive.
Incidentally, the SATA protocol incorporates 32-bit CRCs in all packets flowing in either direction. This will pick up an extremely high percentage of errors arising from faulty cables and bad receiver and transmitter circuits at the interface. For reads, the host does not use data flagged with CRC errors. For writes, the drive does not write data flagged with CRC errors. This feature has saved my ass more than once by preventing the writing of corrupt data when I had problems with my cables.
If it was indeed bad system RAM, wouldn't bad system RAM cause a random BSOD (Windows) or Kernel Panic (Linux)?
Likely so, but if we are talking about errors that only show up in 28 file-reads out of millions of file-reads, there is no reason to believe that you would be bound to see such a panic during the period in question.
BTW, bad RAM anywhere in the chain from disk drive to CPU - main system RAM, CPU cache RAM, hard drive cache RAM, controller RAM, etc - could cause such a panic, since most data travels all the way through such a chain. I am rather awestruck at how reliable the millions to billions of transistors in that chain actually are.
They would also be sued pretty quickly by Oracle. Clearly not an option.
Your conclusion is a bit hasty and unwarranted. I am not going to tell you that Oracle CANNOT sue anyone for any trumped-up reason, but ZFS is licensed under the Common Development and Distribution License (CDDL) and is open source. For linux, there is an issue with how CDDL plays with GPL, so no distro has yet bundled ZFS with linux. Linux users, however, can themselves pick up "ZFS on Linux" and install it themselves without violating either the CDDL or GPL.
But OSX is not GPL. Other systems that are not GPL bundle ZFS, and are not sued. For example, FreeBSD comes with ZFS, and there are a number of other systems, such as FreeNAS, PS-BSD, illumos and nexenta.
And no, HDDs do not have built-in error correction, they have checksums -- those things are not the same thing.
Sorry to inform you that your knowledge on this subject is not perfectly correct and inclusive. Hard drives use per-sector ECC. ECC stands for Error Correction Code. The very term tells you its function is to do precisely what you say is not done. Here is one tutorial. This stuff is pretty basic and widely known.
"When a sector is written to the hard disk, the appropriate ECC codes are generated and stored in the bits reserved for them. When the sector is read back, the user data read, combined with the ECC bits, can tell the controller if any errors occurred during the read. Errors that can be corrected using the redundant information are corrected before passing the data to the rest of the system. The system can also tell when there is too much damage to the data to correct, and will issue an error notification in that event. The sophisticated firmware present in all modern drives uses ECC as part of its overall error management protocols. This is all done "on the fly" with no intervention from the user required, and no slowdown in performance even when errors are encountered and must be corrected."
The miracle is that the human immune system has held the line against extinction from viruses and infections for so long. As we tamper with that balance through antibiotics and resistant strains of unimagined virulence burgeon and explode, over a period on the order of 100 years out of 1 million+ years of human existence, that is coming to an end. Why would not the selfish impetus to preserve one's personal life not spell the end of the species life for most/all intelligent species?
"Stronger than steel" or "stronger than x", by either absolute measure or ratio of strength to weight, doesn't mean shit. There are a million factors.
1) What kind of steel? Tensile yield strength (MPa) is all over the place: ASTM A36 structural steel: 250 API 5L X65: 448 AISI 4130, water quenched 855C (1570F), 480C (900F) temper: 951 Aermet 340: 2160 2800 maraging steel: 2617 Micro-Melt 10 Tough Treated Tool Steel (AISI A11): 5171
Usually when someone says "stronger than steel" they mean stronger than crappy A36 or the like. If you're going to build a fabric-covered fuselage, you use the 4130. If you've got a building or bridge to erect, you use something closer to A36. For a cutting bit, tool steel. It is brittle as hell but harder than any steel you can use structurally; takes and keeps a wicket edge when ground.
2) Do you care about anything besides tensile yield strength? Just say yes. It matters. Such properties as the following: Elastic modules Compressive strength Hardness Toughness Elongation Endurance limit / fatigue properties Resistance to corrosion and other degradation
Many of these properties play off against each other. Want hard or tough? Pick one. They are inversely related. Want something that is mechanically workable? It better have decent elongation, which limits achievable strength. On the other hand, piano wire doesn't need to be very workable at all. It has fantastic strength.
3) What safety factor will you require? Depends on a number of factors, and one of these factors is material chosen. Balsa needs a much higher safety factor than steel or aluminum alloy. Its mechanical properties are much more variable, and it tends to have imperfections.
These are just some of the factors that make the simplified table you reference horse shit. Bottom line, if you are building a bridge or airplane to highly optimized requirements, suitable steel or aluminum alloy is going to give you a lot less weight for the same safety-factored strength as balsa - completely aside from temperature/humidity limits, flammability, and liability to rot.
I don't think it's quibbling to point out that you can have multiple users on a system with no GUI at all. By convention, none or only one of them has administrative access, or you maintain some kind of user discipline with respect to administration. This is mostly true for what are customarily called servers.
Ever see the text "Warning, system is shutting down in 10 minutes" splattered over your emacs screen, heh heh?
Anyway, as I reveal elsewhere on this page, init is not the ONLY login system I use. In fact my main desktop system runs arch with systemd, so I am reasonably comfortable with either system. And your points are well taken. I don't think there is anybody who thinks there is the slightest question that the "battle of init systems" for linux is over and systemd has won, and furthermore it's not going to be tenable for long to stay current with ANY distro and avoid systemd for whatever reason.
But I remain skeptical that a server "needs" systemd - witness that BSD servers work fine and none of them have systemd.
Actually the Armstrong limit describes the PRESSURE at which water and similar fluids boil at body temperature. Yeah, if you withdrew some of your blood and put it in an open container, it would boil. But the blood in your blood vessels is not at outside pressure. Arthur C. Clarke had it right in 2001. You can experience a vacuum briefly without the blood in your blood vessels boiling. You do need to mind your eyeballs, mouth, trachea and alveoli though.
You probably know this already, but the truth of the matter of exposure of the human body to a vacuum is a bit less horrific than uninformed lurid speculation has it. You're not going to last long, but your body does not quickly blow up like a balloon from the blood boiling. There is actual experience of 10+ second exposure.
The other problem is the entire wind chill factor is still being disputed about, here on earth. I could be -20F outside with no wind and the dry air alone would suck the moisture from your body.
[raises hand] Nobody, but nobody, who has experienced a cold climate in both still air and high winds disputes the wind chill factor.
Somebody already beat me with the post about the surface of Mars being beyond the Armstrong limit.
I'll just reinforce that by pointing out that the atmosphere at the surface of Mars is the same density as Earth's atmosphere at 34,600 m of altitude. Feeling a bit chilly is about the LAST thing you would have to worry about on Mars. Saliva vaporizing from the surface of your tongue, tears vaporizing in your eyes, and fluids evaporating from the alveoli in your lungs will be a bit bothersome if you open your mouth and eyes before you pass out from anoxia. Ever see the space-suit-looking contraption with full helmet that you have to wear in an SR-71? Well, the ceiling of the SR-71 is a good 8700 m below 34,600. Then there's the itsy bitsy detail that Mars' atmosphere is 96% CO2.
no support for FreeBSD systems in the Enterprise, other than hiring consultants
This lack seems to spell o-p-p-o-r-t-u-n-i-t-y. I am currently running 2 big multiple-RAIDZ2 file servers for my own personal storage, using ZFSonLinux on RHEL6. I am definitely going to switch one to FreeBSD/ZFS. There must be A LOT of enterprises that could benefit enormously from ZFS, but are hesitant to say the least about adopting ZFSonLinux, and unlike me cannot handle their own support.
As usual, an excellent exposition of stuff a lot of us still aren't familiar with. Do you have a systemd FAQ/exposition site? Could we get you to open one?
Well, journald is sort of the mirror of the hypothetical registryd, and journald is quite well established and doing fine at this point. The comparison is far from perfect; for example you can still run syslog in parallel with journald, but on the mirror side you pretty much would need to pick one-and-only source of config data.
A case can certainly be made for a registryd. It is appealing to have all your config info nicely hierarchically arranged in a single tree, rather than hunting for scattered files amongst all the millions of other files for multitudes of other purposes, all mixed together in a single hierarchy based on filename. You would need highly portable tools for rescue and repair, but that is eminently addressable.
As one who has taken strong exception to both the form and substance of the systemd steamroller, I readily volunteer that Peter has a point. If you don't think any alternative to some form of init scripts is necessary, just say that. Peter and other proponents will make a strong well-supported point-by-point case for the alternative-IS-required viewpoint.
Peter - hi - I still dig BSD with init scripts, particularly FreeBSD, but I'm not manning the barricades against linux with systemd. I do run arch with systemd as my main desktop at this point. The pointers from you and other knowledgeable supporters did help a lot. I'm not sure there is an adequate systemd FAQ/pointers site yet.
Slashdot Mirror
Or you can just not opt into pointless farting around with the exacting stuff, and make a gun-type fission weapon on the general principle of the Hiroshima weapon. The principle and the level of engineering required are both so dead simple foolproof that you can skip the proof testing.
A gun-type weapon will even work fine without an initiator if you pay enough attention to the combined bullet and target staying together for the fraction of a second necessary for spontaneous neutron emission to do the job.
It is considered that a gun-type will not work with plutonium because of pre-ignition before the bullet and target are fully assembled. What I have never seen is an analysis of likely explosive yield given pre-ignition. An explosion of only 1-10% of maximum theoretical would still do one hell of a lot of damage. Also, a "dirty bomb" with comparatively slight explosive effect might float the boat of a terrorist. It most certainly would ruin the day of a city.
USA and USAF, welcome to the real world where you pay to play.
Laying waste to domestic industry is a whole hell of a lot cheaper and faster to do than [re-]building domestic industry.
I suspect GP realizes on some level that there are no conceivable moral grounds for such refusal, any more than there were grounds for the Union, headed by the tyrant Abraham Lincoln, engaging in murder and mayhem to prevent the self-determination of Virginia and the Confederacy.
But then again, Ukraine and Russia are both similarly at fault, although at least there has been very little bloodshed to date in the current affair, when compared for example to the War of Northern Aggression.
The part where you claim "It [ECC] doesn't protect you against hard disks which write incorrect data to start with, or have faulty cables etc."
So you don't think it's worth providing recovery from some error cases just because you can't protect against every single case?
If you don't mind my asking, why would you claim something that is patently untrue? ECC detects and corrects ALL instances of a hard drive writing single bad bits per sector. So it's clearly "protecting you" against a great many instances of "incorrect data" being written by the drive.
Incidentally, the SATA protocol incorporates 32-bit CRCs in all packets flowing in either direction. This will pick up an extremely high percentage of errors arising from faulty cables and bad receiver and transmitter circuits at the interface. For reads, the host does not use data flagged with CRC errors. For writes, the drive does not write data flagged with CRC errors. This feature has saved my ass more than once by preventing the writing of corrupt data when I had problems with my cables.
Likely so, but if we are talking about errors that only show up in 28 file-reads out of millions of file-reads, there is no reason to believe that you would be bound to see such a panic during the period in question.
BTW, bad RAM anywhere in the chain from disk drive to CPU - main system RAM, CPU cache RAM, hard drive cache RAM, controller RAM, etc - could cause such a panic, since most data travels all the way through such a chain. I am rather awestruck at how reliable the millions to billions of transistors in that chain actually are.
Your conclusion is a bit hasty and unwarranted. I am not going to tell you that Oracle CANNOT sue anyone for any trumped-up reason, but ZFS is licensed under the Common Development and Distribution License (CDDL) and is open source. For linux, there is an issue with how CDDL plays with GPL, so no distro has yet bundled ZFS with linux. Linux users, however, can themselves pick up "ZFS on Linux" and install it themselves without violating either the CDDL or GPL.
But OSX is not GPL. Other systems that are not GPL bundle ZFS, and are not sued. For example, FreeBSD comes with ZFS, and there are a number of other systems, such as FreeNAS, PS-BSD, illumos and nexenta.
See OpenZFS.
Sorry to inform you that your knowledge on this subject is not perfectly correct and inclusive. Hard drives use per-sector ECC. ECC stands for Error Correction Code. The very term tells you its function is to do precisely what you say is not done. Here is one tutorial. This stuff is pretty basic and widely known.
"When a sector is written to the hard disk, the appropriate ECC codes are generated and stored in the bits reserved for them. When the sector is read back, the user data read, combined with the ECC bits, can tell the controller if any errors occurred during the read. Errors that can be corrected using the redundant information are corrected before passing the data to the rest of the system. The system can also tell when there is too much damage to the data to correct, and will issue an error notification in that event. The sophisticated firmware present in all modern drives uses ECC as part of its overall error management protocols. This is all done "on the fly" with no intervention from the user required, and no slowdown in performance even when errors are encountered and must be corrected."
It doesn't even mean a single goddam objective thing.
See? Imperial is no different from metric.
The 0 mile device weighs just 0 hundredweight and measures a mere 0 miles in thickness.
Unless I am mistaken, the cost of an iPhone 5S and a Samsung Galaxy S 5 are very comparable. Why is one a luxury product and the other non-luxury?
Really? You don't understand how the immune system can go off the deep end on either side?
Immune system too weak -> infection, cancer.
Immune system too strong -> self-attack (rheumatoid arthritis, lupus, multiple sclerosis, a LOT more).
The miracle is that the human immune system has held the line against extinction from viruses and infections for so long. As we tamper with that balance through antibiotics and resistant strains of unimagined virulence burgeon and explode, over a period on the order of 100 years out of 1 million+ years of human existence, that is coming to an end. Why would not the selfish impetus to preserve one's personal life not spell the end of the species life for most/all intelligent species?
Just a thought.
"Stronger than steel" or "stronger than x", by either absolute measure or ratio of strength to weight, doesn't mean shit. There are a million factors.
1) What kind of steel? Tensile yield strength (MPa) is all over the place:
ASTM A36 structural steel: 250
API 5L X65: 448
AISI 4130, water quenched 855C (1570F), 480C (900F) temper: 951
Aermet 340: 2160
2800 maraging steel: 2617
Micro-Melt 10 Tough Treated Tool Steel (AISI A11): 5171
Usually when someone says "stronger than steel" they mean stronger than crappy A36 or the like. If you're going to build a fabric-covered fuselage, you use the 4130. If you've got a building or bridge to erect, you use something closer to A36. For a cutting bit, tool steel. It is brittle as hell but harder than any steel you can use structurally; takes and keeps a wicket edge when ground.
2) Do you care about anything besides tensile yield strength? Just say yes. It matters. Such properties as the following:
Elastic modules
Compressive strength
Hardness
Toughness
Elongation
Endurance limit / fatigue properties
Resistance to corrosion and other degradation
Many of these properties play off against each other. Want hard or tough? Pick one. They are inversely related. Want something that is mechanically workable? It better have decent elongation, which limits achievable strength. On the other hand, piano wire doesn't need to be very workable at all. It has fantastic strength.
3) What safety factor will you require? Depends on a number of factors, and one of these factors is material chosen. Balsa needs a much higher safety factor than steel or aluminum alloy. Its mechanical properties are much more variable, and it tends to have imperfections.
These are just some of the factors that make the simplified table you reference horse shit. Bottom line, if you are building a bridge or airplane to highly optimized requirements, suitable steel or aluminum alloy is going to give you a lot less weight for the same safety-factored strength as balsa - completely aside from temperature/humidity limits, flammability, and liability to rot.
Thanks for the thoughful reply.
I don't think it's quibbling to point out that you can have multiple users on a system with no GUI at all. By convention, none or only one of them has administrative access, or you maintain some kind of user discipline with respect to administration. This is mostly true for what are customarily called servers.
Ever see the text "Warning, system is shutting down in 10 minutes" splattered over your emacs screen, heh heh?
Anyway, as I reveal elsewhere on this page, init is not the ONLY login system I use. In fact my main desktop system runs arch with systemd, so I am reasonably comfortable with either system. And your points are well taken. I don't think there is anybody who thinks there is the slightest question that the "battle of init systems" for linux is over and systemd has won, and furthermore it's not going to be tenable for long to stay current with ANY distro and avoid systemd for whatever reason.
But I remain skeptical that a server "needs" systemd - witness that BSD servers work fine and none of them have systemd.
Actually the Armstrong limit describes the PRESSURE at which water and similar fluids boil at body temperature. Yeah, if you withdrew some of your blood and put it in an open container, it would boil. But the blood in your blood vessels is not at outside pressure. Arthur C. Clarke had it right in 2001. You can experience a vacuum briefly without the blood in your blood vessels boiling. You do need to mind your eyeballs, mouth, trachea and alveoli though.
You probably know this already, but the truth of the matter of exposure of the human body to a vacuum is a bit less horrific than uninformed lurid speculation has it. You're not going to last long, but your body does not quickly blow up like a balloon from the blood boiling. There is actual experience of 10+ second exposure.
[raises hand] Nobody, but nobody, who has experienced a cold climate in both still air and high winds disputes the wind chill factor.
Mod parent up. Good points.
Problem with that is that the atmosphere of Mars is already 96% CO2, buddy. The only reason it's not a furnace is because it's so goddam thin.
Somebody already beat me with the post about the surface of Mars being beyond the Armstrong limit.
I'll just reinforce that by pointing out that the atmosphere at the surface of Mars is the same density as Earth's atmosphere at 34,600 m of altitude. Feeling a bit chilly is about the LAST thing you would have to worry about on Mars. Saliva vaporizing from the surface of your tongue, tears vaporizing in your eyes, and fluids evaporating from the alveoli in your lungs will be a bit bothersome if you open your mouth and eyes before you pass out from anoxia. Ever see the space-suit-looking contraption with full helmet that you have to wear in an SR-71? Well, the ceiling of the SR-71 is a good 8700 m below 34,600. Then there's the itsy bitsy detail that Mars' atmosphere is 96% CO2.
An oxygen mask alone just won't do any good.
This lack seems to spell o-p-p-o-r-t-u-n-i-t-y. I am currently running 2 big multiple-RAIDZ2 file servers for my own personal storage, using ZFSonLinux on RHEL6. I am definitely going to switch one to FreeBSD/ZFS. There must be A LOT of enterprises that could benefit enormously from ZFS, but are hesitant to say the least about adopting ZFSonLinux, and unlike me cannot handle their own support.
As usual, an excellent exposition of stuff a lot of us still aren't familiar with. Do you have a systemd FAQ/exposition site? Could we get you to open one?
Well, journald is sort of the mirror of the hypothetical registryd, and journald is quite well established and doing fine at this point. The comparison is far from perfect; for example you can still run syslog in parallel with journald, but on the mirror side you pretty much would need to pick one-and-only source of config data.
A case can certainly be made for a registryd. It is appealing to have all your config info nicely hierarchically arranged in a single tree, rather than hunting for scattered files amongst all the millions of other files for multitudes of other purposes, all mixed together in a single hierarchy based on filename. You would need highly portable tools for rescue and repair, but that is eminently addressable.
As one who has taken strong exception to both the form and substance of the systemd steamroller, I readily volunteer that Peter has a point. If you don't think any alternative to some form of init scripts is necessary, just say that. Peter and other proponents will make a strong well-supported point-by-point case for the alternative-IS-required viewpoint.
Peter - hi - I still dig BSD with init scripts, particularly FreeBSD, but I'm not manning the barricades against linux with systemd. I do run arch with systemd as my main desktop at this point. The pointers from you and other knowledgeable supporters did help a lot. I'm not sure there is an adequate systemd FAQ/pointers site yet.