Umm, that's not really the problem. It doesn't matter what the hardware clock is set for, UTC or local time. In any sane installation you're only going to use the hardware clock until you sync with the NTP servers anyway. The local time is still going to change on a different date than the OS is configured for. If you have Linux or UNIX boxes and keep the hardware clock set for UTC, you're STILL going to need to fix the time zone setings for the correct DST changeover dates, otherwise all local times will be off by an hour between the new changeover date and the old one. It's not a clock thing, it a time zone thing. We're having to apply patches to every single box in our infrastructure -- that's around 15,000 systems, not including desktops. Those add another 100K or more. We've had to patch Slowaris, Linux, HPUX, AIX, and a few flavors of Windoze, and that's just the servers. Then there are patches required for Java and a host of other crap, don't ask me why they don't just use the damn system clock.
The issue here is not the DST patch, it's the fact that Micro$loth was charging $40K for the Windoze 2000 patch. They justified it because W2K is officially out of support for patches - it's EOL or EOSL, I don't remember which becuase I pay very little attention to Windoze server issues.
I saw as much of that horrible pile of crap as I could stand. The books were good, the movie was an utter abomination. Anyone associated with it should have been swallowed whole by a worm.
"AMD and Intel continue to beat the crap out of each other with customers gaining but wondering why there is no software that supports those new 8-way processors, as both compilers and third-party developers fail to keep up."
Linux... VMWare... hello??
I've had numerous CFL bulbs die after a few months. I believe the supposed huge savings over the life of the bulb is nothing but wishful thinking. I still use them in some places, but have learned not to buy them for more than a couple of bucks each -- the expensive ones seem to suck just as badly as the cheap ones.
It has been my experience that they won't take anything that's not commercially packaged and sealed. Nothing prepared, nothing home-made. Apparently the homeless have lawyers, too.
Sad, really. Tons of food goes to waste daily, and we still have people going hungry.
Ummmm.... accelerometers are what people now use to measure tilt. Assuming a horizontally mounted accelerometer, 0G = horizontal and 1G = vertical. Something between 0 and 1G indicates some degree of offset from vertical or horizontal. Tilt. There are 1, 2, and 3-axis accelerometers commonly available. They're used in all sorts of things, many of them as (you might have guessed it by now) tilt sensors.
It's not just a different encoding, it's a completely different method of transmission. Morse code usually implies CW (continuous wave) transmission, which is readable by humans at signal levels far below those usable for voice. It's copyable without the use of a computer or any other specialized gear, other than (obviously) a recevier.
Umm, that's not really the problem. It doesn't matter what the hardware clock is set for, UTC or local time. In any sane installation you're only going to use the hardware clock until you sync with the NTP servers anyway. The local time is still going to change on a different date than the OS is configured for. If you have Linux or UNIX boxes and keep the hardware clock set for UTC, you're STILL going to need to fix the time zone setings for the correct DST changeover dates, otherwise all local times will be off by an hour between the new changeover date and the old one. It's not a clock thing, it a time zone thing. We're having to apply patches to every single box in our infrastructure -- that's around 15,000 systems, not including desktops. Those add another 100K or more. We've had to patch Slowaris, Linux, HPUX, AIX, and a few flavors of Windoze, and that's just the servers. Then there are patches required for Java and a host of other crap, don't ask me why they don't just use the damn system clock.
The issue here is not the DST patch, it's the fact that Micro$loth was charging $40K for the Windoze 2000 patch. They justified it because W2K is officially out of support for patches - it's EOL or EOSL, I don't remember which becuase I pay very little attention to Windoze server issues.
I saw as much of that horrible pile of crap as I could stand. The books were good, the movie was an utter abomination. Anyone associated with it should have been swallowed whole by a worm.
"AMD and Intel continue to beat the crap out of each other with customers gaining but wondering why there is no software that supports those new 8-way processors, as both compilers and third-party developers fail to keep up." Linux... VMWare... hello??
I've had numerous CFL bulbs die after a few months. I believe the supposed huge savings over the life of the bulb is nothing but wishful thinking. I still use them in some places, but have learned not to buy them for more than a couple of bucks each -- the expensive ones seem to suck just as badly as the cheap ones.
It has been my experience that they won't take anything that's not commercially packaged and sealed. Nothing prepared, nothing home-made. Apparently the homeless have lawyers, too. Sad, really. Tons of food goes to waste daily, and we still have people going hungry.
Ummmm.... accelerometers are what people now use to measure tilt. Assuming a horizontally mounted accelerometer, 0G = horizontal and 1G = vertical. Something between 0 and 1G indicates some degree of offset from vertical or horizontal. Tilt. There are 1, 2, and 3-axis accelerometers commonly available. They're used in all sorts of things, many of them as (you might have guessed it by now) tilt sensors.
We have sharks for that.
It's not just a different encoding, it's a completely different method of transmission. Morse code usually implies CW (continuous wave) transmission, which is readable by humans at signal levels far below those usable for voice. It's copyable without the use of a computer or any other specialized gear, other than (obviously) a recevier.