No I am not going to ship my servers, users, configurations and proprietary data to some vendor so that they can maybe get to something in a few months.)
Ummm, this does actually happen in real life, although it's more common to have the vendor send one of their less assertive employees to the servers and users, than it is for the customer to send the servers and users to the vendor. I have seen both happen within my various employers, both as vendor and customer.
Per-diem on-site support is usually available for around $2000 per day, give or take a factor of 10 depending on how poor the vendor feels on any given day.
You might not get an actual, live developer, but you might get someone who is on an email basis with an actual, live developer.
A logical pessimist would point out that there are many people who care about spectral synthesis of stars undergoing quakes; however, you may be the only one in the world who cares about writing software for it.
He's close, except the space unit is probably less than a kilobyte (this is an age where programmers worried about using dozens of bytes, and used "kilo" the same way we use "giga" today), and the time unit is probably a day or at most a week. No doubt the bill arrived every month--after all, your phone company doesn't mail you a bill after every call, even if the amount you used paid for the envelope and stamp...
I recall the price was something like $0.03 per 480 bytes (remember: a kilobyte is over a *thousand* bytes) for storage on a non-IBM mainframe (the vendor shall remain nameless, but you can probably recognize it from the size of the allocation unit) in the 1980's. The billing was exact to a tenth of a penny--the filesystem kept track of how old your files were when you deleted them, so that you could be billed accurately. This was actually considered a feature, like per-second billing with cell phone and long-distance companies, because The Competition would round your usage up based on your daily peak usage or something.
If you're wondering about what happens if you shorten a file or append to it--well, you can't do either with this filesystem, so don't ask. The OS did provide a file type that could be accessed randomly, but the billing structure for those was different. There were no directories either.
Incidentally, if you wanted that data sent to your terminal during the daytime, it cost on the order of $0.80 per kilocharacter (which was almost, but not quite, a kilobyte). There were also charges for I/O, memory, CPU time, operator attention, and any other scarce resource that could be metered and sold.
To put this in perspective: the swap space used by a typical KDE desktop would cost a little under $200 per day in disk space rental fees at 1980's prices.
I wasn't using port 135 for anything in particular......so I started tunnelling encrypted VPNs over UDP on port 135. I did this for years......and then my ISP started blocking that port. Oops, no more VPN for me.
There's a nasty pattern developing here:
1. MS produces some awful software. 2. Net admins see how awful the software is, and look for a quick and easy way to disable it. 3. Net admins find the quick and easy way: block ports 137-139. 4. MS realizes that nobody can use their software because everyone with half a brain has blocked the ports it uses. 5. MS "enhances" the awful software, which really means the same protocol (trivially patched to avoid backward compatibility) on different port numbers (135, 445, and a bunch of others...also SOAP, which goes over TCP port 80 and looks like web traffic). 6. See step 2. 7. See step 3, but substitute the new port numbers. 8. See step 4. 9. Repeat the above until there are no TCP or UDP ports left.
If your software is so awful and so ubiquitous that *BACKBONE ISPs* are blocking the port numbers it uses, then you have problems that open-source developers can only dream of having some day.
1. Make (or allow braindead software to make) dozens of copies of everything: a permanent copy of every message that has ever seen the inbox, plus copies in project directories, version-control systems, installed on machines, etc. Minimum one backup copy of all of that.
2. Work out how to store it all efficiently (i.e. let the filesystem find duplication and replace it with references--even better, scan for the duplication while writing and never have it in the first place). So 'cp foo bar' should operate in O(1) time, and be identical to 'ln foo bar' except with copy-on-write semantics. Use caching where appropriate for performance or compatibility.
3. Work out how to search it all efficiently, e.g. with SQL queries, regexps, grep, Google, whatever's appropriate. The data from #2 is nice here...how many times have I asked "are there other copies of this file lying around somewhere?" or "where did this file come from?"
Who is this silent majority of supporters that SCO CEO Darl McBride referred to? Are we going to see people come out and support the company in statements or legal filings?
We'll have to see. The case is really in its infancy. There haven't been any amicus briefs yet.
Note to SCO: the reason why there haven't been any amicus briefs yet is because you have no friends.
But they have done this already for the Mac OS (version < 10). Remember the look-and-feel lawsuits of the 80's?
Dig around and you'll find RMS in the past saying essentially "Don't write software for the Mac because Apple is a bunch of litigious assholes" for more or less the same reasons that RMS is now saying essentially "Don't write software for SCO Unix because The SCO Group is a bunch of litigious assholes."
I see pattern developing here: RMS doesn't want anyone who will listen to him to write software for litigious assholes, especially (but not necessarily) when the people getting the business end of the lawsuits are major FSF contributors.
Quick, how many FSF programs run on pre-OS-10 MacOS? Think about how long it would take to implement a Cygwin-like Unix compatibility layer for the Mac before you answer that question.
Microsoft, for all their faults, has never acted like a bunch of litigious assholes. It is one thing to do everything you can (including a legally acceptable amount of cheating, and total indifference to the impact of your own community's improvements on the members of some other community) to improve the lives of members of your community as much as seems to be possible, as Microsoft does. It's another thing to launch a direct attack against individual members of another community because yours isn't so nice to live in any more, as SCO does now and Apple did in the past.
Hmmm, a US corporation, suing someone for outrageously inflated sums of money as a way to either gain some fast cash or prevent someone else from doing same, without legal merits? Nah, you're right, it couldn't happen.
This is the second major Unix copyright lawsuit. The first one went away, quietly, shortly after it was necessary to provide evidence.
SCO is owned by Caldera, a major corporate Linux contributor. Caldera is largely responsible for many of the Linux improvements SCO alleges were stolen from them.
SCO used to give away genuine (but old) Unix sources for free from their own web server, until a month or two after filing their lawsuit, after which they disappeared. Whoops?
The text of the SCO lawsuit looks like it's intended to be read by stockholders and trade analysts, not lawyers or judges. It also claims that IBM stole features from SCO that are not present in either of SCO's Unix products.
Think of it like this. I trust Bob, so I let Bob connect. Bob trusts Cathy, so I can get a network of trust relationships going.
Find 'em works better than ever before simply by making sure that there is absolutely no possibility of not knowing who the guy sharing the illegal stuff really is. The flip side of this is that the individual users may have no idea what files they might be sharing, if the software refuses to tell them. Maybe you plan to use "I have no idea what files I'm sharing because I can't access/decrypt them" as a legal defense...which is Freenet in a nutshell.
Fake 'em works best when the clients all trust some common information that allows them to be compromised in mass numbers. I'd imagine that the Law Enforcement Edition of Windows Palladium will have features that make hacked P2P clients not just easy, but utterly trivial. The second or third release will probably ship with **AA Wizard, which creates trusted viruses that will patch all of the (limited number of) signed P2P client binaries so that they will disclose whatever information the authorities want to know. The signature of the executable files on disk won't change, because they'll be patched on the fly by the OS. This will work because MS will agree to sign the virus with the "install this on sight" key as part of their next antitrust lawsuit settlement.
Kill 'em isn't effective against current P2P networks of any size, but does work against small networks whether they're P2P or not...so I have no idea why it would work (or not) against future ones.
"Well, what does he know? He only created the protocol and client."
Sounds to me like he's never created a filesystem, then (besides, anyone can create a protocol if they define it as "whatever input is acceptable to this program";-).
It's really not that hard to build a filesystem out of any pile of existing static data, providing that you have a practically unlimited amount of read-write temporary storage lying around (which you must, if you're casually downloading multi-hundred-megabyte files), and you make damned sure that you never need to swap onto the filesystem in question (which you won't, since the file system will be read-only).
The hard part is talking to many thousands of lines of code that has never been truly tested on anything other than ext2. But that's an issue for any kernel-space filesystem.
It would be simple enough to make a bittorrent flesystem--that is, to make large collections of many small files distributed via bittorrent mountable as a filesystem. You start with many small files embedded within a single large file using some other filesystem format (e.g. ISO9660) and a device driver that talks to a torrent file while it's being downloaded (tricky, but far from impossible). The device driver would block whenever it tries to access parts of a file that haven't been downloaded yet, and unblock as those parts arrive. Bonus points for an implementation that tries to download the blocked parts first, or only downloads the parts that are asked for through the filesystem. After you have the first few megs of the file, you'll be able to randomly seek to access any file as it downloads. A ZIP file can also be used instead of an ISO9660 image--the ZIP directory is at the end, and as a bonus the individual files are compressed. Tarballs would be bad, as tar format doesn't have a single contiguous directory that you could start with.
There will be limitations, of course: the latency near startup will be incredible (imagine NFS over dialup PPP, but slower) and the filesystem metadata areas will be hotspots that will impair bittorrent's load distribution among servers. The important thing is that you'll be able to run 'find' over it, or serve it from a web server, or whatever it is that you do with things on read-only mounted filesystems.
Which brings up the "WHY" question. Damned if I know. It might be good for Debian CD/DVD images, I suppose--everyone who installed Debian could be their own Debian mirror for a while, and a Debian CD/DVD consists of many medium-sized files in ISO9660 format, so it could work reasonably efficiently as a mounted bittorrent filesystem. It doesn't make sense to mount a filesystem just to access a single large video file, and it doesn't make sense to use bittorrent to access only a few small web pages.
Most laptops are stolen for the hardware's immediate (and not insignificant) resale value. If the perp has a clue, the disks and BIOS NVRAM are carefully scrubbed first. The data is usually useless to the thieves--the market for stolen data is usually very small, and the window to sell the data is small, and the buyer will have awkward questions about where the data comes from. Thieves are people too, so they might copy some of the more interesting pr0n, but usually they just want to get rid of the hardware ASAP, and data mining takes time.
Many stolen laptops are recovered as soon as the buyer calls in for tech support or warranty coverage transfer. It sounds dull and boring compared to the shiny new technology measures, but it actually does work some of the time.
This idea would still work if there was no easy/convenient way to remove a unique ID signature from the BIOS (e.g. CPUID, or a chipset-specific serial number ROM) and of course no easy/convenient way to remove the TheftGuard feature itself.
Unfortunately, historically BIOS vendors have been entirely useless at providing real anti-theft security measures. Don't be surprised if all of Phoenix's "anti-theft" features can be disabled by disconnecting a battery or hitting a magic key sequence. The BIOS may still be reflashed with some more cooperative software, or even physically replaced if the machine can't be booted at all.
This feature would only really work on machines with integrated NICs that are transparently connected to the Internet at times when their NICs are reliably under BIOS control (e.g. at suspend/resume time or at startup). You wouldn't be able to ping random machines while the OS was running because doing so would mangle device state beyond all recognition or impose serious performance penalties (although some BIOS vendors seem to regard randomly crashing the running OS as a feature, so it's not impossible).
The OS might have some special device driver support (e.g. a "Phoenix TheftGuard-enabled NIC driver") which would make the feature work while the OS was running, if the thieves are clueless enough to not disable it.
Any Linux user who actually wants such a dangerous feature has had the tools to implement it themselves for years now--it's just a few lines of shell script plus a cron job, even for the cryptographically secure version.
This feature could also be implemented directly in the actual NIC firmware. The disk erasure could be done by forcing a reboot of the host machine, then grabbing control of the BIOS through the normal net-boot BIOS extension features. The pinging could be scheduled by the NIC itself during idle times--no OS support required.
In the beginning, NT was written on something else (for obvious reasons). Since the first version, Microsoft has probably been rebuilding their toolchains to be hosted on previous NT versions, if not completely self-hosted. This process would have been repeated at least twice since NT 4.0. The current tools might not be able to build low-level NT 4.0 code.
The Hallowe'en documents suggest that building low-level pieces of NT is not a trivial or common endeavor, and supposedly not something that the compiler toolchain usable by typical MS customers is capable of doing. It's very possible that there are only a handful of machines in Microsoft which are set up for building NT 4, and those are probably getting old, crotchety, and fragile, if they haven't broken already...
Try building a working 1.0 or 1.2 Linux kernel on modern binutils and gcc 3.2, or build 2.4.20 on gcc 2.6.3. If you somehow manage to get it to compile and link without patches, it probably still won't work properly without deep understanding of the toolchain and its bugs.
Now consider the same problem, but you only get to use the tools that came with Minix (or worse, SCO). That's probably Microsoft's current situation.
I've seen shops where coders get new computers on their desks after a product release--the old computer, with all the software, source code, development tools, etc, gets locked in a vault. If the company needs to do support work on the product years down the road, they pull the computer out of the vault, do the work, then put it back again. No worries about software rot (although hardware rot is a very real problem), although admittedly it's hard to find someone in 2003 who is fluent in Windows 3.0...
If you've ever had the misfortune to need IBM service for your laptop, the first thing you'll notice is that they subcontract almost all service to local companies, who in turn hire droids who consider themselves hardware experts because they know where Windows XP has hidden the device manager.
Frankly, if my laptop needs service, the first thing I do is delete the decryption keys for my Linux filesystems, and tell them that whatever was broken also ate the entire contents of the hard drive. To date, they have never failed to restore the original software.
You are getting CRC errors on your cables. That is what the error means.
As for what is causing the problem...
0. Bad cooling 1. Bad cables 2. Large noise source near the cable (e.g. power supply) 3. Bad motherboard / IDE controller 4. Bad brand of motherboard / IDE controller (simply replacing a brand X part for another brand X part will not solve your problem if all brand X parts are flawed by design) 5. Bad cooling 6. Bad drive electronics (especially if this happens on only the one disk) 7. Bad cooling
If your drives have temperature sensors, check them. Over 60 deg C means your disk is too hot, and will fail soon if it hasn't already. Below 30 deg C means cooling is not your problem. Temperatures in between will have different effects depending on the drive (some disks happy at 50 deg C, others flake out in the mid-40's).
Most IDE controller chips need cooling too, but they often don't even have heat sinks let alone dedicated fans.
DOS floppies? All the BIOS utilities I've seen (other than the ones inside the actual BIOS, and stand-alone bootable disks) seem to require Windows NT.
So I can meet you in person and get the key, or call you on the phone and verify your PGP (or GPG if you please) fingerprint (assuming you're not being wiretapped as well), and then use the Internet as a medium from then on.
Ummm, it works just as well if your phone is being wiretapped. Public keys (and therefore their fingerprints) are public. All that anyone listening to the conversation can do is learn what GPG public keys you're using, so they can know which encrypted messages to archive. Later, after recovering the private keys from your cold, dead fingers, they can decrypt the messages and sit down for an evening of light reading.
It doesn't work if someone redirects your call to an agent who is unusually adept at voice impersonations, and who can supply you with a fingerprint different from mine. Of course there would have to be two such agents, otherwise we might later discover that we were not having the phone conversation with each other at exactly the same time, and we'd know that they keys were compromised.
Slashdot Mirror
A logical pessimist would point out that there are many people who care about spectral synthesis of stars undergoing quakes; however, you may be the only one in the world who cares about writing software for it.
He's close, except the space unit is probably less than a kilobyte (this is an age where programmers worried about using dozens of bytes, and used "kilo" the same way we use "giga" today), and the time unit is probably a day or at most a week. No doubt the bill arrived every month--after all, your phone company doesn't mail you a bill after every call, even if the amount you used paid for the envelope and stamp...
I recall the price was something like $0.03 per 480 bytes (remember: a kilobyte is over a *thousand* bytes) for storage on a non-IBM mainframe (the vendor shall remain nameless, but you can probably recognize it from the size of the allocation unit) in the 1980's. The billing was exact to a tenth of a penny--the filesystem kept track of how old your files were when you deleted them, so that you could be billed accurately. This was actually considered a feature, like per-second billing with cell phone and long-distance companies, because The Competition would round your usage up based on your daily peak usage or something.
If you're wondering about what happens if you shorten a file or append to it--well, you can't do either with this filesystem, so don't ask. The OS did provide a file type that could be accessed randomly, but the billing structure for those was different. There were no directories either.
Incidentally, if you wanted that data sent to your terminal during the daytime, it cost on the order of $0.80 per kilocharacter (which was almost, but not quite, a kilobyte). There were also charges for I/O, memory, CPU time, operator attention, and any other scarce resource that could be metered and sold.
To put this in perspective: the swap space used by a typical KDE desktop would cost a little under $200 per day in disk space rental fees at 1980's prices.
I wasn't using port 135 for anything in particular... ...so I started tunnelling encrypted VPNs over UDP on port 135. I did this for years... ...and then my ISP started blocking that port. Oops, no more VPN for me.
There's a nasty pattern developing here:
1. MS produces some awful software.
2. Net admins see how awful the software is, and look for a quick and easy way to disable it.
3. Net admins find the quick and easy way: block ports 137-139.
4. MS realizes that nobody can use their software because everyone with half a brain has blocked the ports it uses.
5. MS "enhances" the awful software, which really means the same protocol (trivially patched to avoid backward compatibility) on different port numbers (135, 445, and a bunch of others...also SOAP, which goes over TCP port 80 and looks like web traffic).
6. See step 2.
7. See step 3, but substitute the new port numbers.
8. See step 4.
9. Repeat the above until there are no TCP or UDP ports left.
If your software is so awful and so ubiquitous that *BACKBONE ISPs* are blocking the port numbers it uses, then you have problems that open-source developers can only dream of having some day.
I ended up using a multi-pronged approach:
1. Make (or allow braindead software to make) dozens of copies of everything: a permanent copy of every message that has ever seen the inbox, plus copies in project directories, version-control systems, installed on machines, etc. Minimum one backup copy of all of that.
2. Work out how to store it all efficiently (i.e. let the filesystem find duplication and replace it with references--even better, scan for the duplication while writing and never have it in the first place). So 'cp foo bar' should operate in O(1) time, and be identical to 'ln foo bar' except with copy-on-write semantics. Use caching where appropriate for performance or compatibility.
3. Work out how to search it all efficiently, e.g. with SQL queries, regexps, grep, Google, whatever's appropriate. The data from #2 is nice here...how many times have I asked "are there other copies of this file lying around somewhere?" or "where did this file come from?"
Dig around and you'll find RMS in the past saying essentially "Don't write software for the Mac because Apple is a bunch of litigious assholes" for more or less the same reasons that RMS is now saying essentially "Don't write software for SCO Unix because The SCO Group is a bunch of litigious assholes."
I see pattern developing here: RMS doesn't want anyone who will listen to him to write software for litigious assholes, especially (but not necessarily) when the people getting the business end of the lawsuits are major FSF contributors.
Quick, how many FSF programs run on pre-OS-10 MacOS? Think about how long it would take to implement a Cygwin-like Unix compatibility layer for the Mac before you answer that question.
Microsoft, for all their faults, has never acted like a bunch of litigious assholes. It is one thing to do everything you can (including a legally acceptable amount of cheating, and total indifference to the impact of your own community's improvements on the members of some other community) to improve the lives of members of your community as much as seems to be possible, as Microsoft does. It's another thing to launch a direct attack against individual members of another community because yours isn't so nice to live in any more, as SCO does now and Apple did in the past.
#endif
What, your trojan can't send email to the cops itself? What's less traceable than that? ;-)
It would become GIU (Gnu Is Unix), or GINU (Gnu Is Now Unix), or "FSF Unix", or maybe ... ..."FSF/1"...
Uhhh, have you checked vacuum tube prices recently?
No, going to the fridge must be allowed, otherwise you're missing about half of the components of the raw material that commercials are made of.
Hmmm, a US corporation, suing someone for outrageously inflated sums of money as a way to either gain some fast cash or prevent someone else from doing same, without legal merits? Nah, you're right, it couldn't happen.
This is the second major Unix copyright lawsuit. The first one went away, quietly, shortly after it was necessary to provide evidence.
SCO is owned by Caldera, a major corporate Linux contributor. Caldera is largely responsible for many of the Linux improvements SCO alleges were stolen from them.
SCO used to give away genuine (but old) Unix sources for free from their own web server, until a month or two after filing their lawsuit, after which they disappeared. Whoops?
The text of the SCO lawsuit looks like it's intended to be read by stockholders and trade analysts, not lawyers or judges. It also claims that IBM stole features from SCO that are not present in either of SCO's Unix products.
Unless you meant that no SCO product has any Unix98 certification (apparently there are three), which does seem to be true.
Fake 'em works best when the clients all trust some common information that allows them to be compromised in mass numbers. I'd imagine that the Law Enforcement Edition of Windows Palladium will have features that make hacked P2P clients not just easy, but utterly trivial. The second or third release will probably ship with **AA Wizard, which creates trusted viruses that will patch all of the (limited number of) signed P2P client binaries so that they will disclose whatever information the authorities want to know. The signature of the executable files on disk won't change, because they'll be patched on the fly by the OS. This will work because MS will agree to sign the virus with the "install this on sight" key as part of their next antitrust lawsuit settlement.
Kill 'em isn't effective against current P2P networks of any size, but does work against small networks whether they're P2P or not...so I have no idea why it would work (or not) against future ones.
"Well, what does he know? He only created the protocol and client."
;-).
Sounds to me like he's never created a filesystem, then (besides, anyone can create a protocol if they define it as "whatever input is acceptable to this program"
It's really not that hard to build a filesystem out of any pile of existing static data, providing that you have a practically unlimited amount of read-write temporary storage lying around (which you must, if you're casually downloading multi-hundred-megabyte files), and you make damned sure that you never need to swap onto the filesystem in question (which you won't, since the file system will be read-only).
The hard part is talking to many thousands of lines of code that has never been truly tested on anything other than ext2. But that's an issue for any kernel-space filesystem.
It would be simple enough to make a bittorrent flesystem--that is, to make large collections of many small files distributed via bittorrent mountable as a filesystem. You start with many small files embedded within a single large file using some other filesystem format (e.g. ISO9660) and a device driver that talks to a torrent file while it's being downloaded (tricky, but far from impossible). The device driver would block whenever it tries to access parts of a file that haven't been downloaded yet, and unblock as those parts arrive. Bonus points for an implementation that tries to download the blocked parts first, or only downloads the parts that are asked for through the filesystem. After you have the first few megs of the file, you'll be able to randomly seek to access any file as it downloads. A ZIP file can also be used instead of an ISO9660 image--the ZIP directory is at the end, and as a bonus the individual files are compressed. Tarballs would be bad, as tar format doesn't have a single contiguous directory that you could start with.
There will be limitations, of course: the latency near startup will be incredible (imagine NFS over dialup PPP, but slower) and the filesystem metadata areas will be hotspots that will impair bittorrent's load distribution among servers. The important thing is that you'll be able to run 'find' over it, or serve it from a web server, or whatever it is that you do with things on read-only mounted filesystems.
Which brings up the "WHY" question. Damned if I know. It might be good for Debian CD/DVD images, I suppose--everyone who installed Debian could be their own Debian mirror for a while, and a Debian CD/DVD consists of many medium-sized files in ISO9660 format, so it could work reasonably efficiently as a mounted bittorrent filesystem. It doesn't make sense to mount a filesystem just to access a single large video file, and it doesn't make sense to use bittorrent to access only a few small web pages.
"Now he is facing expulsion."
Must be a good school, if being expelled from it is worse than facing criminal charges for theft.
That depends on the computer.
Most laptops are stolen for the hardware's immediate (and not insignificant) resale value. If the perp has a clue, the disks and BIOS NVRAM are carefully scrubbed first. The data is usually useless to the thieves--the market for stolen data is usually very small, and the window to sell the data is small, and the buyer will have awkward questions about where the data comes from. Thieves are people too, so they might copy some of the more interesting pr0n, but usually they just want to get rid of the hardware ASAP, and data mining takes time.
Many stolen laptops are recovered as soon as the buyer calls in for tech support or warranty coverage transfer. It sounds dull and boring compared to the shiny new technology measures, but it actually does work some of the time.
This idea would still work if there was no easy/convenient way to remove a unique ID signature from the BIOS (e.g. CPUID, or a chipset-specific serial number ROM) and of course no easy/convenient way to remove the TheftGuard feature itself.
Unfortunately, historically BIOS vendors have been entirely useless at providing real anti-theft security measures. Don't be surprised if all of Phoenix's "anti-theft" features can be disabled by disconnecting a battery or hitting a magic key sequence. The BIOS may still be reflashed with some more cooperative software, or even physically replaced if the machine can't be booted at all.
This feature would only really work on machines with integrated NICs that are transparently connected to the Internet at times when their NICs are reliably under BIOS control (e.g. at suspend/resume time or at startup). You wouldn't be able to ping random machines while the OS was running because doing so would mangle device state beyond all recognition or impose serious performance penalties (although some BIOS vendors seem to regard randomly crashing the running OS as a feature, so it's not impossible).
The OS might have some special device driver support (e.g. a "Phoenix TheftGuard-enabled NIC driver") which would make the feature work while the OS was running, if the thieves are clueless enough to not disable it.
Any Linux user who actually wants such a dangerous feature has had the tools to implement it themselves for years now--it's just a few lines of shell script plus a cron job, even for the cryptographically secure version.
This feature could also be implemented directly in the actual NIC firmware. The disk erasure could be done by forcing a reboot of the host machine, then grabbing control of the BIOS through the normal net-boot BIOS extension features. The pinging could be scheduled by the NIC itself during idle times--no OS support required.
I'm not so sure they can fix it.
In the beginning, NT was written on something else (for obvious reasons). Since the first version, Microsoft has probably been rebuilding their toolchains to be hosted on previous NT versions, if not completely self-hosted. This process would have been repeated at least twice since NT 4.0. The current tools might not be able to build low-level NT 4.0 code.
The Hallowe'en documents suggest that building low-level pieces of NT is not a trivial or common endeavor, and supposedly not something that the compiler toolchain usable by typical MS customers is capable of doing. It's very possible that there are only a handful of machines in Microsoft which are set up for building NT 4, and those are probably getting old, crotchety, and fragile, if they haven't broken already...
Try building a working 1.0 or 1.2 Linux kernel on modern binutils and gcc 3.2, or build 2.4.20 on gcc 2.6.3. If you somehow manage to get it to compile and link without patches, it probably still won't work properly without deep understanding of the toolchain and its bugs.
Now consider the same problem, but you only get to use the tools that came with Minix (or worse, SCO). That's probably Microsoft's current situation.
I've seen shops where coders get new computers on their desks after a product release--the old computer, with all the software, source code, development tools, etc, gets locked in a vault. If the company needs to do support work on the product years down the road, they pull the computer out of the vault, do the work, then put it back again. No worries about software rot (although hardware rot is a very real problem), although admittedly it's hard to find someone in 2003 who is fluent in Windows 3.0...
Nonsense. There is no evidence that SCO "infringes" on any "Linux technologies". If they had, their product would suck a lot less...
If you've ever had the misfortune to need IBM service for your laptop, the first thing you'll notice is that they subcontract almost all service to local companies, who in turn hire droids who consider themselves hardware experts because they know where Windows XP has hidden the device manager.
Frankly, if my laptop needs service, the first thing I do is delete the decryption keys for my Linux filesystems, and tell them that whatever was broken also ate the entire contents of the hard drive. To date, they have never failed to restore the original software.
You are getting CRC errors on your cables. That is what the error means.
As for what is causing the problem...
0. Bad cooling
1. Bad cables
2. Large noise source near the cable (e.g. power supply)
3. Bad motherboard / IDE controller
4. Bad brand of motherboard / IDE controller (simply replacing a brand X part for another brand X part will not solve your problem if all brand X parts are flawed by design)
5. Bad cooling
6. Bad drive electronics (especially if this happens on only the one disk)
7. Bad cooling
If your drives have temperature sensors, check them. Over 60 deg C means your disk is too hot, and will fail soon if it hasn't already. Below 30 deg C means cooling is not your problem. Temperatures in between will have different effects depending on the drive (some disks happy at 50 deg C, others flake out in the mid-40's).
Most IDE controller chips need cooling too, but they often don't even have heat sinks let alone dedicated fans.
DOS floppies? All the BIOS utilities I've seen (other than the ones inside the actual BIOS, and stand-alone bootable disks) seem to require Windows NT.
Ummm, it works just as well if your phone is being wiretapped. Public keys (and therefore their fingerprints) are public. All that anyone listening to the conversation can do is learn what GPG public keys you're using, so they can know which encrypted messages to archive. Later, after recovering the private keys from your cold, dead fingers, they can decrypt the messages and sit down for an evening of light reading.
It doesn't work if someone redirects your call to an agent who is unusually adept at voice impersonations, and who can supply you with a fingerprint different from mine. Of course there would have to be two such agents, otherwise we might later discover that we were not having the phone conversation with each other at exactly the same time, and we'd know that they keys were compromised.