Well, first off, I don't think anyone capable of running today's Linux distros will have much problem jumpering a drive to slave, dropping it in and plugging in two cables. I can't see it taking very long for someone to get a multiboot manager working, even if it requires a patch to XP's boot sequence.
MBR has been a thorn in the side of OS development ever since people wanted to create more than 4 partitions, and has also chronically stood in the way of hard drives' exponential capacity growth. It has been begging to be replaced for years, and I'm glad someone is finally doing it.
...with companies hiring open-source authors is those companies' looking to subsume the programmers' projects. If you let people keep their current code, and especially if you let them keep working on their projects on their own time, I think you'll have trouble picking from all the competent people who will apply.
A ground loop would work fine for cooling things during the summer -- though you'd want to be careful to have that loop nice and far from the data center. Wouldn't be a good thing to have it sink in the mud, now, would it?
Should've read more. I suppose one could swap the power supply for a conventional unit with a fan, and then have the water cooling system handle only the processor, chipset and video heat sinks...
I wonder how well this water cooling system would work with Intel's Pentium 4 processors? One of the problems people had with the P4 is that the dang thing would slow itself down when the chip got too warm. Would a good water cooling system keep this from occurring? I'd love to see benchmarks on air-cooled versus water-cooled P4 systems...
Exponential growth of program code always alarms me. Nothing worse than feeping creaturism is my belief. But don't be too alarmed; so long as the doubling rate is lower than Moore's Law (18-24 months, depending on Moore's mood), you'll still have an OS that is more efficient on newer hardware. The only worry is if the code base becomes so large no human can handle it.
Watermarking, in the way the RIAA means to use it, will never work. Period. No argument.
The RIAA means to lock up all music as it is copied onto the PC by placing a watermark as it is encoded; hardware will then detect the watermark and, if it is not registered to that piece of hardware, will refuse to play that music.
Read My Lips: IF YOU HAVE ACCESS TO THE ORIGINAL MUSIC AND THE WATERMARKED SAMPLES TOGETHER, YOU CAN DETERMINE THE METHODS USED AND AT THE LEAST MASK THE WATERMARK. IF YOU HAVE A PIECE OF HARDWARE AT YOUR DISPOSAL TO TEST WHETHER A WATERMARK IS VISIBLE, YOU WILL EVENTUALLY DISCOVER HOW TO OBSCURE IT.
The DeCSS challenge, while a good idea, and while it proved the system faulty, was not a good real-life test. To be a valid test of the technology, the RIAA would've had to allow people to submit their own samples for encoding. Given encoding software, or even hardware, one could submit audio of test tones looking for patterns in the encoding.
I've done a bit of work with Steganography; I've seen one system that would work in tracing the path of music that had been pirated to the person who let it out in the first place, and would survive any attack, where data would be recoverable even if the music were played in analog and redigitized. But these systems depend on having an encoder and analyzer that is not in the hands of the public, even if the basic system is known, and having your MP3 players check for watermarks would be violate that system.
You wouldn't have to worry about BSoD if the pacemaker unit were transmit only.
What you MIGHT have to worry about is exploits on the receiving computer. DDoS on a medical server might block reception of statistics for thousands of implants. Or an exploit might lead to patients' being called in unnecessarily.
Monitoring nurse: "Um, Doctor. Mrs. Magruder's heart is beating SOS in Morse code..."
What about a provision in the GPL that invalidates such EULA restrictions on derivative code? That way you could click through the EULA (or get the code some other way, by hook or by crook), repair the fork, and if Sony decided to sue you, you could rebut that Sony was using your code, and that their EULA was invalid.
A dongle may be a good thing when it comes to protecting one's private crypto key, but when it comes to "copyright protection", it is simply insufficient.
How would you use a dongle to protect music? Have a unique encryption key in each one? Forget the "legitimate software" -- reverse engineer it, read the key off the dongle using new code and write it in the clear.
Pumping the music through the dongle, which contains a decryption engine? Again, new code, take the output stream and send it to the hard drive rather than the sound board.
Nope nope, the only way to truly protect your "digital rights" is to engineer a sound board, with a decryption engine and the A->D audio (video?) hardware all on a single chip, so there's no way for the PC to get at the digital stream. Problem solved!
But, uh, wait. Even assuming you've used flawless encryption and hardware design to perform this deed, you forget that a high-quality first generation copy is about as good as the original. Take that sound board's output and route it to an A->D converter, on the same machine or an extra one. Then burn to MP3, so all additional copying is digital, with no further loss of quality.
When you've pushed the price of CDs to $25 apiece, do you think people will pay that much just for a perfect copy?
FYI -- before flipping your desk over to install that heavy mounting hardware, take a good look at the slide rails. This heavy keyboard drawer I purchased looked like it was going to be a similar bitch to install -- until I discovered you could slide the rails completely out. Failing that, you might also try to unbolt the rails from the tray.
I'd first held that heavy assembly up, but rather than try and drill, or even mark the holes, I only marked the corners for one side. Removing that rail, I then held it up and marked the drill holes, drilled, and installed that rail.
I then slid the keyboard assembly onto that rail, and supported by the one side, I was easily able to mark the drill holes. I then removed the assembly from the side already installed (being careful not to let the weight bend the mounts on that side), removed the rail on the other side, drilled and installed the other side. The assembly finally slid onto both mounts.
Hmm... I wonder how many of the Chinese people are going to internet cafes and watching streaming video of their hero fighter pilot flying like an idiot next to the US spy plane?
Admittedly it could cause some serious problems while being phased in. You'd be tossing people out of their domains left and right.
Once you were done, once a certain deadline had passed... You could phase out the trademark system and have everything done via domain name. Want to reserve a name? Forget paying a trademark lawyer $375; just reserve a domain name for $12. It's already taken? Darn.
Being a type-A personality who charges off and gets to work without thinking things over, I immediately went and squatted on "dtdcache.org", intending to set up a donation-supported central repository for DTDs. This would solve problems caused by changing web structures and provide a permanent location for static XML specifications.
Of course, given an additional 30 seconds of mature reflection, I realized that XML.org would be the best host of such a repository, probably tied into their XML registry program. Ah well.
I haven't audited the 802.11b protocol, so I can't say whether I think the basis is secure or not, but I have noticed one potential security problem for networks based on a certain brand of local access point hardware (name withheld for now)...
This particular manufacturer stated the hardware was compatible with up to 128-bit encryption, and I did set my remote interface to 128-bit with no problems. The base unit, on the other hand, had no such setting; encryption could either be turned on or left off.
This leads to two potential exploits:
1. Brute force: trying to connect using all 2^40 keys until you are able to access the network. This is probably unworkable, but worth noting.
2. For a network with a large number of remote connections, one or more might have been set to 40-bit instead of 128-bit. Traffic from these nodes could be sniffed and analyzed, and the passphrase hash recovered.
Since I'm administering all of the remote points on my network, I've taken steps to keep this from happening; but for a large corporate net where users tend to fiddle with things, this could definitely cause a problem.
The AHRA says that individuals trading copies is exempt from copyright law, as part of fair use. Napster merely facilitates this behavior. At no time is any copyrighted material on Napster's servers. Why should they be punished?
I'm not sure why you think this is so complicated. If the customer has definitely traced the bug to the original code, including conditions required to elicit it, and you can replicate the problem, then you should take responsibility for fixing it. The customer has already handed you pretty much everything you need to find and kill the bug anyway, and squashing it now saves you having to fix it for future expanded releases or code re-use.
If the customer's coder hasn't definitely traced it to your code, the customer dropped the program in your lap and said fix it, and you have to take the time tracing through the custom routines, then the customer should pay for support, even if the bug eventually turns up in the original code.
You're going to run into all sorts of problems, including power limitations, not to mention the fact that you're going to need a computer there to grab the images and send them over the link.
You might consider taking a plain old video camera and sending it to shore via a 900 MHz radio link (X10 makes a short-range version, other companies have ones with more distance) and setting up your computer and net connection there.
The whole premise behind demanding AOL to open up access to AIM is that it lets people contact all those unfortunates who are locked into the AOL dial-up service. The TOC interface lets people talk, but doesn't permit any of the other neat things AOL and AIM provide.
But there's something you are forgetting... AOL's IM service and AIM aren't completely interoperable, either. Using AIM I cannot send a file to my brother on AOL; I cannot bring him in on a multiperson chat; and he cannot see if I am away or not.
If you make an all-encompassing instant messenger standard and include only proxy AOL communications, and most everyone currently only using the AIM client switches over, then no one has lost anything; we still can't fully reach those stuck in AOL.
Pondering the subject some more, I realized I'd made two wrong assumptions...
1. The signals used would be analog in nature, and
2. The bands used would be VHF and UHF.
The fact is, this technology isn't well-suited to broadcasting over the old TV bands; the receiving antennas required would be large and ungainly, and the transmitting antennas might be completely impractical, depending on the amount of directionality you wanted. Satellite broadcasting is better done 'round the microwave region.
This means a directionally-sourced satellite signal would work best on a system much like the one HDTV will soon be broadcast on. It also means people still stuck in fringe areas for VHF/UHF won't be affected (at least, not until the networks give up the old bandwidth).
As for the fringe areas for the new ground-station broadcasters, because of the nature of digital transmissions the "fringe area" where the signal strength goes from effective to obscured is much smaller than the fringe area on an analog footprint. Adding more noise from satellites overhead would reduce that footprint, but many fewer people would be affected than if this were tried with analog.
Slashdot Mirror
Well, first off, I don't think anyone capable of running today's Linux distros will have much problem jumpering a drive to slave, dropping it in and plugging in two cables. I can't see it taking very long for someone to get a multiboot manager working, even if it requires a patch to XP's boot sequence.
MBR has been a thorn in the side of OS development ever since people wanted to create more than 4 partitions, and has also chronically stood in the way of hard drives' exponential capacity growth. It has been begging to be replaced for years, and I'm glad someone is finally doing it.
...with companies hiring open-source authors is those companies' looking to subsume the programmers' projects. If you let people keep their current code, and especially if you let them keep working on their projects on their own time, I think you'll have trouble picking from all the competent people who will apply.
Hello friends. This message is to let you know
that my email address is changing. Please update
your address list.
Prior address: glevin@timewarner.com
New address: glevin63195@aol.com
Thank you very much.
A ground loop would work fine for cooling things during the summer -- though you'd want to be careful to have that loop nice and far from the data center. Wouldn't be a good thing to have it sink in the mud, now, would it?
Have three or four data centers; land is cheap.
Should've read more. I suppose one could swap the power supply for a conventional unit with a fan, and then have the water cooling system handle only the processor, chipset and video heat sinks...
I wonder how well this water cooling system would work with Intel's Pentium 4 processors? One of the problems people had with the P4 is that the dang thing would slow itself down when the chip got too warm. Would a good water cooling system keep this from occurring? I'd love to see benchmarks on air-cooled versus water-cooled P4 systems...
Exponential growth of program code always alarms me. Nothing worse than feeping creaturism is my belief. But don't be too alarmed; so long as the doubling rate is lower than Moore's Law (18-24 months, depending on Moore's mood), you'll still have an OS that is more efficient on newer hardware. The only worry is if the code base becomes so large no human can handle it.
:-P
Or has that already taken place?
Watermarking, in the way the RIAA means to use it, will never work. Period. No argument.
The RIAA means to lock up all music as it is copied onto the PC by placing a watermark as it is encoded; hardware will then detect the watermark and, if it is not registered to that piece of hardware, will refuse to play that music.
Read My Lips: IF YOU HAVE ACCESS TO THE ORIGINAL MUSIC AND THE WATERMARKED SAMPLES TOGETHER, YOU CAN DETERMINE THE METHODS USED AND AT THE LEAST MASK THE WATERMARK. IF YOU HAVE A PIECE OF HARDWARE AT YOUR DISPOSAL TO TEST WHETHER A WATERMARK IS VISIBLE, YOU WILL EVENTUALLY DISCOVER HOW TO OBSCURE IT.
The DeCSS challenge, while a good idea, and while it proved the system faulty, was not a good real-life test. To be a valid test of the technology, the RIAA would've had to allow people to submit their own samples for encoding. Given encoding software, or even hardware, one could submit audio of test tones looking for patterns in the encoding.
I've done a bit of work with Steganography; I've seen one system that would work in tracing the path of music that had been pirated to the person who let it out in the first place, and would survive any attack, where data would be recoverable even if the music were played in analog and redigitized. But these systems depend on having an encoder and analyzer that is not in the hands of the public, even if the basic system is known, and having your MP3 players check for watermarks would be violate that system.
You wouldn't have to worry about BSoD if the pacemaker unit were transmit only.
What you MIGHT have to worry about is exploits on the receiving computer. DDoS on a medical server might block reception of statistics for thousands of implants. Or an exploit might lead to patients' being called in unnecessarily.
Monitoring nurse: "Um, Doctor. Mrs. Magruder's heart is beating SOS in Morse code..."
IMHO it's in a software company's best interests to not prosecute open software companies for violating software patents, for two simple reasons:
(1) An open source developer probably doesn't have very deep pockets, so there's nothing worth suing.
(2) Other companies might use that open source for their own projects, and when that happened, they'd be potential targets.
Hmm... I wonder if there's anything in the code Apple subsumed for OSX that's been patented? Or Sony with the Palm emulation software?
What about a provision in the GPL that invalidates such EULA restrictions on derivative code? That way you could click through the EULA (or get the code some other way, by hook or by crook), repair the fork, and if Sony decided to sue you, you could rebut that Sony was using your code, and that their EULA was invalid.
A dongle may be a good thing when it comes to protecting one's private crypto key, but when it comes to "copyright protection", it is simply insufficient.
How would you use a dongle to protect music? Have a unique encryption key in each one? Forget the "legitimate software" -- reverse engineer it, read the key off the dongle using new code and write it in the clear.
Pumping the music through the dongle, which contains a decryption engine? Again, new code, take the output stream and send it to the hard drive rather than the sound board.
Nope nope, the only way to truly protect your "digital rights" is to engineer a sound board, with a decryption engine and the A->D audio (video?) hardware all on a single chip, so there's no way for the PC to get at the digital stream. Problem solved!
But, uh, wait. Even assuming you've used flawless encryption and hardware design to perform this deed, you forget that a high-quality first generation copy is about as good as the original. Take that sound board's output and route it to an A->D converter, on the same machine or an extra one. Then burn to MP3, so all additional copying is digital, with no further loss of quality.
When you've pushed the price of CDs to $25 apiece, do you think people will pay that much just for a perfect copy?
Well, you'd better hope so.
FYI -- before flipping your desk over to install that heavy mounting hardware, take a good look at the slide rails. This heavy keyboard drawer I purchased looked like it was going to be a similar bitch to install -- until I discovered you could slide the rails completely out. Failing that, you might also try to unbolt the rails from the tray.
I'd first held that heavy assembly up, but rather than try and drill, or even mark the holes, I only marked the corners for one side. Removing that rail, I then held it up and marked the drill holes, drilled, and installed that rail.
I then slid the keyboard assembly onto that rail, and supported by the one side, I was easily able to mark the drill holes. I then removed the assembly from the side already installed (being careful not to let the weight bend the mounts on that side), removed the rail on the other side, drilled and installed the other side. The assembly finally slid onto both mounts.
Hmm... I wonder how many of the Chinese people are going to internet cafes and watching streaming video of their hero fighter pilot flying like an idiot next to the US spy plane?
Maybe this isn't such a bad thing.
Admittedly it could cause some serious problems while being phased in. You'd be tossing people out of their domains left and right.
Once you were done, once a certain deadline had passed... You could phase out the trademark system and have everything done via domain name. Want to reserve a name? Forget paying a trademark lawyer $375; just reserve a domain name for $12. It's already taken? Darn.
Being a type-A personality who charges off and gets to work without thinking things over, I immediately went and squatted on "dtdcache.org", intending to set up a donation-supported central repository for DTDs. This would solve problems caused by changing web structures and provide a permanent location for static XML specifications.
Of course, given an additional 30 seconds of mature reflection, I realized that XML.org would be the best host of such a repository, probably tied into their XML registry program. Ah well.
I haven't audited the 802.11b protocol, so I can't say whether I think the basis is secure or not, but I have noticed one potential security problem for networks based on a certain brand of local access point hardware (name withheld for now)...
This particular manufacturer stated the hardware was compatible with up to 128-bit encryption, and I did set my remote interface to 128-bit with no problems. The base unit, on the other hand, had no such setting; encryption could either be turned on or left off.
This leads to two potential exploits:
1. Brute force: trying to connect using all 2^40 keys until you are able to access the network. This is probably unworkable, but worth noting.
2. For a network with a large number of remote connections, one or more might have been set to 40-bit instead of 128-bit. Traffic from these nodes could be sniffed and analyzed, and the passphrase hash recovered.
Since I'm administering all of the remote points on my network, I've taken steps to keep this from happening; but for a large corporate net where users tend to fiddle with things, this could definitely cause a problem.
This troll's already been fed; can you mod the parent message back up so all its siblings are in the right context? Thanks.
The AHRA says that individuals trading copies is exempt from copyright law, as part of fair use. Napster merely facilitates this behavior. At no time is any copyrighted material on Napster's servers. Why should they be punished?
I'm not sure why you think this is so complicated. If the customer has definitely traced the bug to the original code, including conditions required to elicit it, and you can replicate the problem, then you should take responsibility for fixing it. The customer has already handed you pretty much everything you need to find and kill the bug anyway, and squashing it now saves you having to fix it for future expanded releases or code re-use.
If the customer's coder hasn't definitely traced it to your code, the customer dropped the program in your lap and said fix it, and you have to take the time tracing through the custom routines, then the customer should pay for support, even if the bug eventually turns up in the original code.
You're going to run into all sorts of problems, including power limitations, not to mention the fact that you're going to need a computer there to grab the images and send them over the link.
You might consider taking a plain old video camera and sending it to shore via a 900 MHz radio link (X10 makes a short-range version, other companies have ones with more distance) and setting up your computer and net connection there.
The whole premise behind demanding AOL to open up access to AIM is that it lets people contact all those unfortunates who are locked into the AOL dial-up service. The TOC interface lets people talk, but doesn't permit any of the other neat things AOL and AIM provide.
But there's something you are forgetting... AOL's IM service and AIM aren't completely interoperable, either. Using AIM I cannot send a file to my brother on AOL; I cannot bring him in on a multiperson chat; and he cannot see if I am away or not.
If you make an all-encompassing instant messenger standard and include only proxy AOL communications, and most everyone currently only using the AIM client switches over, then no one has lost anything; we still can't fully reach those stuck in AOL.
subject
Pondering the subject some more, I realized I'd made two wrong assumptions...
1. The signals used would be analog in nature, and
2. The bands used would be VHF and UHF.
The fact is, this technology isn't well-suited to broadcasting over the old TV bands; the receiving antennas required would be large and ungainly, and the transmitting antennas might be completely impractical, depending on the amount of directionality you wanted. Satellite broadcasting is better done 'round the microwave region.
This means a directionally-sourced satellite signal would work best on a system much like the one HDTV will soon be broadcast on. It also means people still stuck in fringe areas for VHF/UHF won't be affected (at least, not until the networks give up the old bandwidth).
As for the fringe areas for the new ground-station broadcasters, because of the nature of digital transmissions the "fringe area" where the signal strength goes from effective to obscured is much smaller than the fringe area on an analog footprint. Adding more noise from satellites overhead would reduce that footprint, but many fewer people would be affected than if this were tried with analog.