I converted nearly our whole house network to software raid at the start of this year: Big RAID5s for our fileserver, backupserver, netserver and videoserver, and smaller RAID2s for our firewall and workstation boxes.
Overall, I'm very happy with it -- no more rebuilding from scratch every time a boot disk blows!!:) I'd started converting to SCSI boot disks everywhere, but a pair of software RAID2 IDE drives gives me a much better sense of security. My workstation did in fact blow a boot drive a month ago, and rather than being an emergency, I just ambled into Fry's after a week or two and bought a replacement and rebuilt the raid. No muss, no fuss. Feels like living in the third millenium!
I did learn various things the hard way that the HOWTOs don't warn of.
Note that you can't boot off RAID5, only RAID2. The hack they mention of putting/boot on RAID2 and everything else on RAID5 is not worth it with today's drive sizes. Give yourself a 2-16GB RAID2 with a complete bootable system on it, and save yourself mucho grief at very little proportionate cost in disk space.
As of kernel 2.4x, at least, the linux software RAID5 autorecovery is workable but less robust than one might like in the face of serious problems: I had one RAID5 setup totally destroyed because the hardware was flaky leading to constant reboots while RAID5 reconstruction was just underway. After awhile the kernel got confused about the order of the disks (which shouldn't matter, but apparently did) and the whole thing went into a Death Spiral. Lesson: If you're sure the problem is just one flaky disk, feel free to just swap in another and reboot. But if you are in any doubt, play it safe: Switch off RAID autodetect first thing (by fdisk'ing the partition type from FD back to 82. Get the hardware stable, rebuild the RAID by hand, then switch everything back to FD.
RAID5 is a comparative pain in the ass to work with vs RAID2, because under RAID2 any of the partitions can be mounted normally as a non-RAID drive in an emergency, getting you back on the air fast, but not so with RAID5. (You'll want a live Linux CD with a RAID-supporting kernel, likely. Knoppix &tc don't yet ship this way.) So only use RAID5 if the extra space really matters -- the big servers.
BTW: One of the reasons I like software RAID over hardware: If you have hardware RAID and the controller blows and you can't find a matching model, you may be stuck reverse-engineering their RAID scheme to recover your data. No worry about that under software RAID.)
I tested automatic failover to hot spare disks under the kernel, and it worked perfectly for me in a handful of tests. For whatever that's worth.
Do keep an eye on/proc/mdstats readout of your RAID system health. If you're asleep at the wheel and don't notice anything until enough disks fail to bring the whole system down, you haven't gained much. I have a crontab-driven set of Perl scripts which check all sorts of things weekly to minutely and email me if they look wrong: Checking for failed RAID drives is one of the things they do. If you don't have a comprehensive solution like that, the raidtools2 package has an ad-hoc solution specifically to email you on drive failure. USE IT.
FWIW, here's the system I've evolved for partitioning disks in such systems:
First partition: One cylinder (the innermost one): Ext FS containing a THIS_DISK file in which I record when and why I bought the drive and any interesting history it has had. In an emergency when you're suddenly shuffling eight hot drives plus a couple spares plus a dead and replacement motherboard &tc, you WILL lose track of which disk was doing what. This little partition will save you a lot of grief.
Second partition: Swap, in the outermost (lowest numbered) cylinders -- because these give the fastest transfer rates, up to about a 50% advantage. Putting swap on every disk lets the kernel stripe swaps across
This is probably not Dignified Enough to count, but I just use outline-minor-mode with outline-regex set to something like "^[A-Za-z]" and two custom keybindings to un/fold. (Like Greyfox, I usually have xemacs open anyhow, either for coding or else for reading email in Gnus, or most likely both. I type this on an 11Mpixel display with at a quick glance four main emacs windows open -- and this isn't even my C coding or email desktop. So xemacs start-up time isn't usually a consideration...)
Definitely. I introduced smileys to the Seattle BBS scene in 1981 from the ARPAnet, and while they were new to local Seattle BBS users isolated from the ARPAnet, they were old hat nationally at that point.
Anyone seriously looking for the first smiley should at minimum search the SF-LOVERS archives. It is reputedly the first big ARPAnet mailing list, and was certainly one of them. I believe it started about 1975+-2 years; I was on it on and off in the late 70s. I would be amazed if its archives didn't show lots of smileys predating 1982. 1982 was when I got sick of ARPAnet and took a half-decade vacation from it.:)
The model I use, at least, you hold in the right hand with the base pointing horizontally left. You don't use the regular desktop mode buttons at all: Instead you use a track on/off button which is now on the bottom, and a click button which is now on the top. (Trying to use my model as a two or three button mouse in 'air mode' isn't very practical, although it is possible in principle.)
Re:Does it make a buzzing noise?
on
Gyroscopic Mouse
·
· Score: 1
No, there's no detectable vibration or sound. Considering how small the gyro is, it might well be supersonic to humans. My cat doesn't pay any attention to it either. Except to absent-mindedly sit on it just when I need it most...
Re:Gives a new meaning to mousepad upgrades
on
Gyroscopic Mouse
·
· Score: 2, Informative
Actually, there's a track on/off button for precisely this reason, in midair use. Kind of nice for scrollbars sometimes, you can just put the cursor on the pagedown button and turn off tracking, then click down by pages with no worry about drifting off the widget.
Because it is impossible to be as precise with your hand in midair as when firmly grounded, because a change is as good as a rest, and because the gyros can occasionally start wandering, and running it on the desk for a few seconds recalibrates them.
I bought six of their earlier wired model on closeout for $50 each a few years back, and I swear by them. You can use them as a regular desktop friction mouse, or pick them up and use them as gyro mice. Perfect way of varying the stress when your wrist starts to get sore, or getting around the ball sticking when you don't have time to stop and clean the gunk off.
The models I'm using (at least) aren't precise enough in gyro mode for drawing lines or such. But gyro mode is fine for webbrowsing similar noncritical point-and-click stuff.
The gyros are really cute, tiny little gadgets maybe a centimeter long and half that high and wide, mounted on a tiny daughtercard. They look perfect for sticking in RC airplanes and such. Gyration lists (used to list?) a development kit for them, but the one time I tried contacting them about it, I was unable to get any reply. They seemed to be busy retreating from the general desktop mouse market into their current niche market.
Summary: Really cool technology that works like a charm. I dread the day when my last GyroPoint mouse bites the dust. So far, however, it looks entirely possible that they will outlive me...
Triple DES is used because affordable machines can brute-force DES in seconds to minutes. Triple DES effectively has twice the keylength of DES, 112 bits instead of 56 bits. This means triple DES is about 65 quadrillion times more expensive than DES to build a brute-force machine for, putting it beyond the budget of any known earthly agency such as the NSA. The only reason to go further is if you are trying to defend against the galactic government or something.:) Basically, the chances are very good that anything which cracks 3DES will crack 10DES too, to the extra compute effort isn't buying you anything obvious.
Triple encryption isn't altogether silly if done right -- it is insurance against some disastrous hole being found in any single one of the algorithms used. But disastrous holes in codes like DES which have had decades of attack are seen as rare. Basically, other attacks are much more likely to be your undoing, and triple encryption won't address them, so the win isn't seen as great.
Linux distros tend not to include much crypto because Uncle Sam has been insisting for a long time that national security requires that the national network be insecure: Distributing crypto from the US could get you jailed. Debian has offshore sites which distribute the crypto part of their distribution. (non-us.debian.org)
Crypt shouldn't be hard to find. There used to be a 'crypt user's workbench' or some such with tuned implementations &tc. Very good attacks on it are now known, so there's not much interest in it.
The 'fish' doesn't mean anything in particular, it has just become a habit to name crypto algorithms after animals -- pike, serpent, &tc.
I went through this recently. For Muq I picked twofish basically because: (1) It is patent-free. If you want patent-free code for open source, that narrows the field enormously. (2) After reading up a fair amount, I trust Bruce Schneier a whole lot. (3) Muq is currently more game stuff than life-critical stuff. If it was life-critical I'd go with 3DES for the reasons mentioned -- it has been analysed to death. Which is basically Bruce's recommendation currently. (4) twofish has very fast set-up time, which is important for my application, which involves N-to-N UDP communication with very short transactions. Most alternatives have unacceptably long set-up time for this.
I'm not a symbolic algebra hacker, but I poked through JACAL once and got the impression that it had a relatively clean, pretty architecture where other packages were more ad hoc.
This might be relevant if you intend to be customizing it.
The projection in question was the "low variant", which is to say the "fantasy variant". There is a heavy element of fantasy in almost all population growth discussions.
If a population consists of three subgroups with growth rates of -10, 0, and 10 percent per generation, what is the overall long term growth rate? 10 percent, right. Every population growth extrapolation I've seen to date ignores this, which makes the results largely fantasy.
Asimov pointed out decades ago that the lamebrains who think technology can somehow enable indefinite geometric population growth Just Don't Get It: At current growth rates, in not very many centuries the human population will be a solid sphere of protoplasm expanding outward at lightspeed. If the lightspeed limit is licked, in a few millenia the human population will weigh more than the observable universe. This will not happen.:) As Malthus correctly noted, exponential growth must always be a short-lived transitional phase in a finite universe. Less than half of all humans are dead: This has never been true in previous millenia and will never be true again in future millenia: It is a unique signature of the millenium centered on today.
Slashdot Mirror
Overall, I'm very happy with it -- no more rebuilding from scratch every time a boot disk blows!! :) I'd started converting to SCSI boot disks everywhere, but a pair of software RAID2 IDE drives gives me a much better sense of security. My workstation did in fact blow a boot drive a month ago, and rather than being an emergency, I just ambled into Fry's after a week or two and bought a replacement and rebuilt the raid. No muss, no fuss. Feels like living in the third millenium!
I did learn various things the hard way that the HOWTOs don't warn of.
Note that you can't boot off RAID5, only RAID2. The hack they mention of putting /boot on RAID2 and everything else on RAID5 is not worth it with today's drive sizes. Give yourself a 2-16GB RAID2 with a complete bootable system on it, and save yourself mucho grief at very little proportionate cost in disk space.
As of kernel 2.4x, at least, the linux software RAID5 autorecovery is workable but less robust than one might like in the face of serious problems: I had one RAID5 setup totally destroyed because the hardware was flaky leading to constant reboots while RAID5 reconstruction was just underway. After awhile the kernel got confused about the order of the disks (which shouldn't matter, but apparently did) and the whole thing went into a Death Spiral. Lesson: If you're sure the problem is just one flaky disk, feel free to just swap in another and reboot. But if you are in any doubt, play it safe: Switch off RAID autodetect first thing (by fdisk'ing the partition type from FD back to 82. Get the hardware stable, rebuild the RAID by hand, then switch everything back to FD.
RAID5 is a comparative pain in the ass to work with vs RAID2, because under RAID2 any of the partitions can be mounted normally as a non-RAID drive in an emergency, getting you back on the air fast, but not so with RAID5. (You'll want a live Linux CD with a RAID-supporting kernel, likely. Knoppix &tc don't yet ship this way.) So only use RAID5 if the extra space really matters -- the big servers.
BTW: One of the reasons I like software RAID over hardware: If you have hardware RAID and the controller blows and you can't find a matching model, you may be stuck reverse-engineering their RAID scheme to recover your data. No worry about that under software RAID.)
I tested automatic failover to hot spare disks under the kernel, and it worked perfectly for me in a handful of tests. For whatever that's worth.
Do keep an eye on /proc/mdstats readout of your RAID system health. If you're asleep at the wheel and don't notice anything until enough disks fail to bring the whole system down, you haven't gained much. I have a crontab-driven set of Perl scripts which check all sorts of things weekly to minutely and email me if they look wrong: Checking for failed RAID drives is one of the things they do. If you don't have a comprehensive solution like that, the raidtools2 package has an ad-hoc solution specifically to email you on drive failure. USE IT.
FWIW, here's the system I've evolved for partitioning disks in such systems:
This is probably not Dignified Enough to count, but I just use outline-minor-mode with outline-regex set to something like "^[A-Za-z]"
and two custom keybindings to un/fold.
(Like Greyfox, I usually have xemacs open anyhow, either for coding or else for reading email in Gnus, or most likely both. I type this on an 11Mpixel display with at a quick glance four main emacs windows open -- and this isn't even my C coding or email desktop. So xemacs start-up time isn't usually a consideration...)
Definitely. I introduced smileys to the Seattle
:)
BBS scene in 1981 from the ARPAnet, and while
they were new to local Seattle BBS users isolated
from the ARPAnet, they were old hat nationally at
that point.
Anyone seriously looking for the first smiley
should at minimum search the SF-LOVERS archives.
It is reputedly the first big ARPAnet mailing
list, and was certainly one of them. I believe
it started about 1975+-2 years; I was on it on
and off in the late 70s. I would be amazed if
its archives didn't show lots of smileys predating
1982. 1982 was when I got sick of ARPAnet and
took a half-decade vacation from it.
The model I use, at least, you hold in the right hand with the base pointing horizontally left. You don't use the regular desktop mode buttons at all: Instead you use a track on/off button which is now on the bottom, and a click button which is now on the top. (Trying to use my model as a two or three button mouse in 'air mode' isn't very practical, although it is possible in principle.)
No, there's no detectable vibration or sound. Considering how small the gyro is, it might well be supersonic to humans. My cat doesn't pay any attention to it either. Except to absent-mindedly sit on it just when I need it most...
Actually, there's a track on/off button for precisely this reason, in midair use. Kind of nice for scrollbars sometimes, you can just put the cursor on the pagedown button and turn off tracking, then click down by pages with no worry about drifting off the widget.
Because it is impossible to be as precise with your hand in midair as when firmly grounded, because a change is as good as a rest, and because the gyros can occasionally start wandering, and running it on the desk for a few seconds recalibrates them.
The models I'm using (at least) aren't precise enough in gyro mode for drawing lines or such. But gyro mode is fine for webbrowsing similar noncritical point-and-click stuff.
The gyros are really cute, tiny little gadgets maybe a centimeter long and half that high and wide, mounted on a tiny daughtercard. They look perfect for sticking in RC airplanes and such. Gyration lists (used to list?) a development kit for them, but the one time I tried contacting them about it, I was unable to get any reply. They seemed to be busy retreating from the general desktop mouse market into their current niche market.
Summary: Really cool technology that works like a charm. I dread the day when my last GyroPoint mouse bites the dust. So far, however, it looks entirely possible that they will outlive me...
Triple DES is used because affordable machines can brute-force DES in seconds to minutes. Triple DES effectively has twice the keylength of DES, 112 bits instead of 56 bits. This means triple DES is about 65 quadrillion times more expensive than DES to build a brute-force machine for, putting it beyond the budget of any known earthly agency such as the NSA. The only reason to go further is if you are trying to defend against the galactic government or something. :) Basically, the chances are very good that anything which cracks 3DES will crack 10DES too, to the extra compute effort isn't buying you anything obvious.
Triple encryption isn't altogether silly if done right -- it is insurance against some disastrous hole being found in any single one of the algorithms used. But disastrous holes in codes like DES which have had decades of attack are seen as rare. Basically, other attacks are much more likely to be your undoing, and triple encryption won't address them, so the win isn't seen as great.
Linux distros tend not to include much crypto because Uncle Sam has been insisting for a long time that national security requires that the national network be insecure: Distributing crypto from the US could get you jailed. Debian has offshore sites which distribute the crypto part of their distribution. (non-us.debian.org)
Crypt shouldn't be hard to find. There used to be a 'crypt user's workbench' or some such with tuned implementations &tc. Very good attacks on it are now known, so there's not much interest in it.
The 'fish' doesn't mean anything in particular, it has just become a habit to name crypto algorithms after animals -- pike, serpent, &tc.
I went through this recently. For Muq I picked twofish basically because: (1) It is patent-free. If you want patent-free code for open source, that narrows the field enormously. (2) After reading up a fair amount, I trust Bruce Schneier a whole lot. (3) Muq is currently more game stuff than life-critical stuff. If it was life-critical I'd go with 3DES for the reasons mentioned -- it has been analysed to death. Which is basically Bruce's recommendation currently. (4) twofish has very fast set-up time, which is important for my application, which involves N-to-N UDP communication with very short transactions. Most alternatives have unacceptably long set-up time for this.
This might be relevant if you intend to be customizing it.
The projection in question was the "low variant", which is to say the "fantasy variant". There is a heavy element of fantasy in almost all population growth discussions.
If a population consists of three subgroups with growth rates of -10, 0, and 10 percent per generation, what is the overall long term growth rate? 10 percent, right. Every population growth extrapolation I've seen to date ignores this, which makes the results largely fantasy.
Asimov pointed out decades ago that the lamebrains who think technology can somehow enable indefinite geometric population growth Just Don't Get It: At current growth rates, in not very many centuries the human population will be a solid sphere of protoplasm expanding outward at lightspeed. If the lightspeed limit is licked, in a few millenia the human population will weigh more than the observable universe. This will not happen. :) As Malthus correctly noted, exponential growth must always be a short-lived transitional phase in a finite universe. Less than half of all humans are dead: This has never been true in previous millenia and will never be true again in future millenia: It is a unique signature of the millenium centered on today.