During British Double Summer Time in World War 2, the second zone shift (from single summer time to double) occurred at a 02:00 which got redesignated to 03:00. So on a BDST transition morning, if you said "see you in 6 hours" at 01:59:59 and started a stopwatch, then met up again in 6 hours according to the stopwatch, the time on the wall clock would read 09:00, not 08:00 (well, 08:59:59 if you're being pedantic).
Or, since the above example technically doesn't disprove the point because there is no 02:00 on that paticular morning, use a shift in the opposite direction: the shift from BDST back to BST occurred at 03:00, which got redesignated to 02:00. In that case you could say "see you in 6 hours" at the first 02:00, then meet up in 6 hours and see that it was 07:00 on the clock.
This is the problem with human timekeeping that OP is talking about: the only rule you can make that's absolute, is that you cannot make *any* assumptions, no matter how reasonable they seem. Go ahead. Pick some other pair of hours that you think is safe to say something like this about, and I'll show you a case where you're wrong. Timekeeping could be such a simple thing, if we just ticked seconds, but to actually keep truly accurate human time in all possible situations requires thousands of lines of code and some fairly extensive lookup tables to keep track of all the exceptions.
I don't understand why a nuclear accident is enough to make us seriously consider phasing out nuclear power on such large scales, but other unsafe things humanity does don't have the same effect.
Alright, Fukushima was a disaster. Obviously the long-term benefits of nuclear power, the decades of power generation without incident, are not worth the risk that this could happen again. (My opinion is that this is not true, but never mind...)
But rebuilding New Orleans again is OK? Katrina killed a lot more people than the Fukushima plant; why are we perfectly OK with going back in there and, to paraphrase Monty Python, building another castle on top of the swamp until it stays up?
I've long given up on the whole MB/GB thing in many applications. Nowadays the definitions have eroded so much that a readout in bytes is the only way to be sure.
Speaking from experience: The software RAID in Windows XP (and to a somewhat lesser extent, Server 2003) is *VERY* temperamental. Unless your drives and controller channels are identical and are both configured exactly the same, the RAID would need a re-synch after every single boot. Also, to get it working requires that you use Microsoft's "dymanic disk" format, which probably makes the partition table nonstandard (and on one occasion I had a dynamic disk created on one computer not readable on another computer running the same version of Windows).
Linux software RAID on the other hand is very reliable and operates very simply: the RAID superblocks are placed so that you can just ignore them and mount the drive normally; the filesystem is exactly where it would be if there were no RAID. It doesn't screw with the partition table, so all the disks are just normal disks and you can read them in any computer, in any OS that reads whatever filesystems you used.
The hardware can be very different -- I have a few arrays where part of it is on SATA and the other part is on PATA. For fun, I once tested an array where half was on PATA and the other half was on external USB. Worked fine, even across reboots (as long as you remembered to turn on the USB drive first:P).
You can even (if you're sadistic, or rsync isn't realtime enough for you), have half of the array on a network mount. If you set it with the write-mostly flag, your read performance won't even be that much worse (but large writes will probably suck).
I actually called my network documentation this. The first paragraph is an example of some of the horrible things that could happen to me, and then it goes on to explain what all the machines do:P
The network diagram is done in inkscape, with much zooming -- at 100% you see a network overview; if you zoom in far enough on each box you can see all kinds of notes about it (services, IP addresses, etc.) in very tiny text. And when you're trying to find something ("Which goddamn box has 198.222.40.6 and since when does it do mail??"), inkscape lets you search the text.
As for passwords, my predecessor kept a meticulous password list that he didn't make accessible when he left. Mine's not very accessible either, but the manual has a page that explains how to get it if I die.
Slashdot Mirror
It's OK everyone; dimissing half of them just means they're running a controlled experiment about scientists
> 8 is always 6 hours after two. Always.
Incorrect.
During British Double Summer Time in World War 2, the second zone shift (from single summer time to double) occurred at a 02:00 which got redesignated to 03:00. So on a BDST transition morning, if you said "see you in 6 hours" at 01:59:59 and started a stopwatch, then met up again in 6 hours according to the stopwatch, the time on the wall clock would read 09:00, not 08:00 (well, 08:59:59 if you're being pedantic).
Or, since the above example technically doesn't disprove the point because there is no 02:00 on that paticular morning, use a shift in the opposite direction: the shift from BDST back to BST occurred at 03:00, which got redesignated to 02:00. In that case you could say "see you in 6 hours" at the first 02:00, then meet up in 6 hours and see that it was 07:00 on the clock.
This is the problem with human timekeeping that OP is talking about: the only rule you can make that's absolute, is that you cannot make *any* assumptions, no matter how reasonable they seem. Go ahead. Pick some other pair of hours that you think is safe to say something like this about, and I'll show you a case where you're wrong. Timekeeping could be such a simple thing, if we just ticked seconds, but to actually keep truly accurate human time in all possible situations requires thousands of lines of code and some fairly extensive lookup tables to keep track of all the exceptions.
Make a folder and put symlinks in it.
I don't understand why a nuclear accident is enough to make us seriously consider phasing out nuclear power on such large scales, but other unsafe things humanity does don't have the same effect. Alright, Fukushima was a disaster. Obviously the long-term benefits of nuclear power, the decades of power generation without incident, are not worth the risk that this could happen again. (My opinion is that this is not true, but never mind...) But rebuilding New Orleans again is OK? Katrina killed a lot more people than the Fukushima plant; why are we perfectly OK with going back in there and, to paraphrase Monty Python, building another castle on top of the swamp until it stays up?
I've long given up on the whole MB/GB thing in many applications. Nowadays the definitions have eroded so much that a readout in bytes is the only way to be sure.
Speaking from experience: The software RAID in Windows XP (and to a somewhat lesser extent, Server 2003) is *VERY* temperamental. Unless your drives and controller channels are identical and are both configured exactly the same, the RAID would need a re-synch after every single boot. Also, to get it working requires that you use Microsoft's "dymanic disk" format, which probably makes the partition table nonstandard (and on one occasion I had a dynamic disk created on one computer not readable on another computer running the same version of Windows). Linux software RAID on the other hand is very reliable and operates very simply: the RAID superblocks are placed so that you can just ignore them and mount the drive normally; the filesystem is exactly where it would be if there were no RAID. It doesn't screw with the partition table, so all the disks are just normal disks and you can read them in any computer, in any OS that reads whatever filesystems you used. The hardware can be very different -- I have a few arrays where part of it is on SATA and the other part is on PATA. For fun, I once tested an array where half was on PATA and the other half was on external USB. Worked fine, even across reboots (as long as you remembered to turn on the USB drive first :P).
You can even (if you're sadistic, or rsync isn't realtime enough for you), have half of the array on a network mount. If you set it with the write-mostly flag, your read performance won't even be that much worse (but large writes will probably suck).
I actually called my network documentation this. The first paragraph is an example of some of the horrible things that could happen to me, and then it goes on to explain what all the machines do :P
The network diagram is done in inkscape, with much zooming -- at 100% you see a network overview; if you zoom in far enough on each box you can see all kinds of notes about it (services, IP addresses, etc.) in very tiny text. And when you're trying to find something ("Which goddamn box has 198.222.40.6 and since when does it do mail??"), inkscape lets you search the text.
As for passwords, my predecessor kept a meticulous password list that he didn't make accessible when he left. Mine's not very accessible either, but the manual has a page that explains how to get it if I die.