True enough. OTOH, it also existed in a wide variety of commercial distributions, so it's hard to draw any conclusions about OSS vs. commercial from this.
Perhaps the lesson to draw is that we should throw out old code and rewrite it more often...:')
OSS' quick fix to BIND 4 and BIND 8 was to release newer versions. BIND 4 is a hopeless clump. BIND 8 was a partial rewrite. BIND 9 was a complete rewrite precisely because BIND 8 wasn't a good basis for a new start.
The problem, if you want to call it that, with OSS is that once you release something broken, you have to hear bug reports about it for the rest of your life. I still occasionally hear from people who are running pre-1.0 snapshots of the ISC DHCP server. That's just how it is in the open source world.
In 2150, some idiot on the Mars colony is going to get hacked by a guy in Plano, TX, because he or she is still running BIND 4 on the Marinaris City web server.
BIND 9 is slower than BIND 8, because it does a more correct job, but it's not significantly slower for most applications. If you are running a root name server, you will have to buy bigger iron. If you are running a corporate nameserver, you probably won't. For home use, BIND 9 will perform nicely on a 486 (I run it on a Soekris board, for example).
BIND 9 is also not bug-for-bug compatible with BIND 8, so there are some things you can do in BIND 8 that are broken, that you can't do in BIND 9. So upgrading can require some rework if you happen to have unwittingly tripped over those bugs.
On the other hand, BIND 9 is a complete, ground-up rewrite of BIND. It works better, is easier to use, and because of the strict practices that were followed in implementation, is much more reliable.
BIND 9 also supports DNSSEC, which isn't yet widely deployed, but is worth checking out.
(I used to work for the ISC, so you might think I'm biased, but I wasn't involved with the ISC BIND project, so it's more that I got to look on while they did it, and was there to see some of the design work they did to make it more reliable, I know the engineers who did it, and I really think they did a great job.)
This is not a showstopper, but just a word of warning - don't do what I did and upgrade in the middle of your work day when you don't have time to fix it.:'}
The software must be open source, so that it can be reviewed by the interested parties. There is simply no other choice that ensures fair elections and does not lead to scapegoating.
To protect against a black hat exploit, the voting system must issue a human- and computer-readable receipt. Then if there is any accusation or evidence of impropriety after the fact, the vote can be recounted.
Also, voting software in the U.S. is used at least once every two years in every district, and in most districts it's used every year. And it doesn't need to (and shouldn't) change much. So even if you have a few elections with black hat exploits, as long as they are discovered and fixed, you do wind up with more reliable voting software over time.
One more thing: making the software open source isn't enough. The hardware has to be open source too. It has to be verifiable, and it has to be available for verification. Otherwise, it can just say it's running your open source software, while in fact it's running a modified closed-source version, or has compromised drivers, or the like.
The government is elected. They can't be the ones that check the software, because they have a conflict of interest. If the software is not open source, there is no way to maintain an appearance of fairness - anybody who doesn't like the outcome of the election can always say "it was rigged," and there's no way to disprove their assertion.
Other than that one nit, I completely agree with you.
Except when you thrash the cache...
on
Is Mac OS X Slow?
·
· Score: 3, Informative
The one time I do notice a lack of zippiness on a Mac is when I thrash the cache. Unfortunely, OSX seems to have a unified buffer+page cache, which means that I/O and virtual memory compete with each other head to head for physical memory. So if you have an app that runs through a gigabyte file, all the programs that weren't running at that time wind up swapped out, and it takes a while to get them back.
This is something Apple could probably fix with some intelligent tuning - it's exactly the same problem Sun had in the early versions of SunOS 4. I do hope they fix it soon - it's a bit of a drag.
500MHz iBook + 512M RAM is nice and zippy!
on
Is Mac OS X Slow?
·
· Score: 3, Informative
I bought one of the 500MHz iBooks shortly before the 600Mhz iBooks were released (D'oh!), and it was a bit slow until I stuffed an extra 512M into it. Since then, I've been using it for development work, lots of compiles, lots of testing, and it is just great. My G4 tower is faster, but I do not find myself wishing the iBook was faster when I'm on the road (which is a *lot*, unfortunately - what I find myself wanting is more pixels.:')
Yeah, I'm wondering if the affected drive might be one of those IBM drives.:'} It might also just be that when you have 80G worth of sectors, the possibility of a bad one times the number of sectors produces a probability of >1 that there will be at least one bad sector.
I've read a lot of books in my day, but quite frankly, most of what little knowledge I have comes from the kindness of people who have helped me to learn.
I don't think there's any excuse for asking a question without first doing a little basic research, but here we have somebody who has legitimately never had any experience with terabyte storage asking if there's a cheaper way. It's a legitimate question, and one that probably could not be answered by looking in a book. So the person here is right to ask, and has already gotten some very good answers.
I have a somewhat similar problem: how do I make sure that on the order of a terabyte of audio and video data survives the next hundred years? This given that the disk on which the first 80 gig of this data were delivered to me has two errors that have corrupted two of the files already, and the data isn't even a year old.
What I've been doing is asking other people how they've solved the problem, and also thinking about it on my own. It's how problems get solved. I've gotten some very good and thoughtful answers to my questions already.
Try Mozilla again. I've removed Internet Explorer from my system, and I have no regrets. I still run into the occasional incompatibility, but no showstoppers. The one inconvenience is that some advertising pops up in the wrong place. Personally, I'm willing to live with it, but of course your milage may vary...:'}
This probably sounds silly, but when I was living in Arizona and had problems with sun-laser-light crawling across my desk during the day, I found that a broad-brimmed hat was very helpful during certain periods of the day. It's not enough on its own, but it definitely helps. Stylish, too!:'}
It's really awful that Real Media uses un-published formats because it means that if my bits are in Real Media format, I am Real Media's captive - I can only run software that Real Media likes.
If Real Media gets bought by someone who wants to discourage users of certain operating systems, all they have to do is introduce incompatibilities in the undocumented format and do a new release that doesn't support the operating systems they don't like. Because the format is a trade secret, we have no defense against this.
Because MP3 is an open standard, and there are open source programs that decode it, I can play mp3s on any operating system I want. The only thing I have to do is pay the patent fee.
The only way of extending patents that I was able to find in my brief search of the PTO's regulations is that if a prescription drug trial delays release of the drug, the owner of the patent applying to the drug can apply to have the patent extended. So that doesn't apply here.
The difference between this patent and the one-click patent is that the one-click patent patents something that is obvious. The MP3 patent patents something that is not obvious, and that required quite a bit of ingenuity to design. Look into it sometime - mp3 is not something you'd come up with in an afternoon's hacking, or even a month's hacking. It really is a nice piece of science. I don't mind that the people who designed it are getting money for it.
I do wish there were some way for them to get paid that didn't involve coercion. But don't think that a system that would compensate them justly is a simple thing to set up. If you've got any genuinely thoughtful ideas for how to create such a system, I'd be interested in hearing them.
1. This is an open standard. It's just patented. Patents expire. Nobody is trying to prevent you from writing decoders - they just want to get paid for (I hope) work that they did in developing the technology, which is pretty cool, and which I don't think I could have invented on my own. I am not fond of software patents, but a patent on MP3 is not the same as a patent on one-click or xor cursors.
Compare this to, for example, Real Media player, where the file format isn't *patented* - it's a trade secret. So if Real doesn't support your platform, you can't play real media. This is really awful - much worse than the patent situation with mp3.
2. The royalty is quite reasonable. If you had to pay $0.75 for your copy of WinAMP, would that really seem unfair to you? That's the price of a can of coke, for Pete's sake! It it really that unfair?
3. Like it or not, this is not going to kill MP3, because most MP3 players are commercial, licensed products, and there are a ton of them out there, and they don't support Vorbis. So you don't have to do anything to keep using your MP3s, but if you want to use Vorbis in protest, it's going to be very difficult.
4. I have a large library of audio files that need to get published on the net. They're free, noncommercial, non-revenue-generating. I'll publish them at least in MP3 format, and maybe Ogg if I can get a good encoder. I have a feeling that if I publish Ogg, it's not going to get downloaded very much, but it'll be interesting to see.
If she can't push a button, maybe you could attach a string to her finger and have her pull on it, and that could actuate a lever that crosses a light beam to set off an alarm. You could probably reduce the effort required to sound this sort of alarm quite a bit. Other than that, you're looking at some smart goggles that watch her pupils, which is not a cheap solution.
I haven't seen the bugtraq posting, but I've read the posting on Macslash, and nowhere does it make the claim that this attack has been proven to work. Instead, the claim is made that because Software Update uses port 80, the attack must be possible.
This is untrue. Yes, you can definitely spoof the DNS, if the circumstances are right, and the resolver doesn't support DNSSEC. I don't know if Apple's resolver supports DNSSEC. But practically every software update anybody ever downloads is downloaded in the clear over an unauthenticated connection to an FTP server or an HTTP server. This is not in itself a security hole.
The hole exists _only_ if there is no client-side authentication of what's been downloaded. The authentication needn't be done in-band - it's quite possible that the update client knows an Apple Software Update public key. The client should be doing an MD5 checksum across the entire binary and checking that against a published signature. Does the Apple Software Update client do that? I don't know. As far as I can tell, neither does the person who published this "exploit."
Until we know the answer to this question, saying that this is an exploit is kind of absurd, particularly because I don't know of _anybody_ who downloads software over HTTP+SSL. If Apple are bad guys because they don't use HTTP+SSL, so is everybody else, from Redhat to NetBSD to the ISC to HP.
What many diet proponents ignore is that people are different. What works for one person won't work for another. My wife has completely different nutritional needs than I do.
If exercising in the gym isn't helping you, you may be a person who responds better to aerobic exercise. Try rollerblading or bicycling. The bad news is that, at least for me, it takes real dedication to make a dent in my standard body pattern - I have to do ~1h of aerobics almost every day to lose weight. Some people might not be willing or able to dedicate that much time to the process (I find that I can't generally find the time, frankly).
So the point is, if you want to do it, try some other patterns and see if they work better for you. If you're satisfied with what you've got going now, don't worry about it - it sounds like you're getting a pretty healthy result.
They might be doing voice messaging rather than telephony. That is, you slap your finger down on the little Starfleet logo and hold it, and talk. The communicator stores the info. When you let go, it sends it. No timing problems, no problem if the bandwidth is low. The recipient gets the message with a slight time lag. Then they whack their communicator, reply, and the process repeats. If you want privacy, you use voice recognition to say where the message is going.
There's no new technology here - my NexTel phone already does every part of this except WiFi. The only thing new is the miniaturization. I think this would be a pretty cool app for an internet company - I work at a company with geeks on two continents, and I'd really like to be able to do this kind of communication with people at work. They have WiFi there, and I have WiFi here, so there's no reason why it couldn't work. You could use SMTP+MIME as the transport layer if necessary.
One of the big problems with most streaming audio of which I am aware is that it uses a TCP/IP connection from the listener to the sender. If I listen to Radio Paradise and my wife listens to it in the next room, the bits come down the wire all the way from Radio Paradise *twice*. This means that unlike with radio, webcasters' bandwidth usage is proportional to the number of listeners.
With multicast, the distribution process is spread out across routers, so it's much less likely that the same bits will cross the same wire twice. If multicast routers were ubiquitous, the same bits would never cross the same wire twice.
If you think about it, this is a fantastic deal - one of the big problems with broadband right now is that the broadband provider has a nice fat pipe to each subscriber, and a similarly fat pipe to the whole rest of the world. So there's a lot of contention on the pipe to the outside world, whereas the pipe to your house is mostly idle. With multicast, a 192kbps feed down the pipe to the outside world can put 192kbps on a significant percentage of the customer pipes. So the ISP can feed much more data to the subscriber for much lower cost.
Interestingly, this also works to the webcaster's advantage - if you want to set up a webcast service on your home machine, it's no skin off the ISP's nose, because you're not pushing 192kbps *per listener* out their pipe to the world - you're pushing a total of 192kbps, which is much less expensive for them. This reduces their incentive/ability to provide lopsided connectivity, where you can receive a lot but send only a little.
My only worry is that AOL might be deploying something proprietary and non-interoperable, and then the ISPs will wind up paying for a system that we can't use this way, even though it would have cost the same as a system we could use this way.
Being one of those jerks who talks on my cell phone a fair amount (I do try to be considerate, honest!) I have to say that reducing the number of moving parts in the phone sounds like a wonderful idea. My biggest problem with cell phones is how flimsy they are, and how quickly parts of them wear out. if this improves the MTBF for the phone, I say bring it on!
I have friends who use PCs, and I can't recommend the iPod to them. This looks like a fine substitute. However, if you have a Mac, I think the iPod is a better choice. My wife has an iPod, and I _really_ like the user interface. The Toshiba's user interface looks like it would be hard to operate while rollerblading, which is when I usually use it.
Yes, the iPod "prevents" you from copying the music from the iPod onto your computer, but it's trivial to get around it - all the data is there. The "prevention" is in iTunes. If you just plug the thing in and fish around on the drive, all the data is there in discrete files, and writing a perl script to extract it back into a music folder would be very easy.
Slashdot Mirror
True enough. OTOH, it also existed in a wide variety of commercial distributions, so it's hard to draw any conclusions about OSS vs. commercial from this.
:')
Perhaps the lesson to draw is that we should throw out old code and rewrite it more often...
OSS' quick fix to BIND 4 and BIND 8 was to release newer versions. BIND 4 is a hopeless clump. BIND 8 was a partial rewrite. BIND 9 was a complete rewrite precisely because BIND 8 wasn't a good basis for a new start.
The problem, if you want to call it that, with OSS is that once you release something broken, you have to hear bug reports about it for the rest of your life. I still occasionally hear from people who are running pre-1.0 snapshots of the ISC DHCP server. That's just how it is in the open source world.
In 2150, some idiot on the Mars colony is going to get hacked by a guy in Plano, TX, because he or she is still running BIND 4 on the Marinaris City web server.
BIND 9 is slower than BIND 8, because it does a more correct job, but it's not significantly slower for most applications. If you are running a root name server, you will have to buy bigger iron. If you are running a corporate nameserver, you probably won't. For home use, BIND 9 will perform nicely on a 486 (I run it on a Soekris board, for example).
BIND 9 is also not bug-for-bug compatible with BIND 8, so there are some things you can do in BIND 8 that are broken, that you can't do in BIND 9. So upgrading can require some rework if you happen to have unwittingly tripped over those bugs.
On the other hand, BIND 9 is a complete, ground-up rewrite of BIND. It works better, is easier to use, and because of the strict practices that were followed in implementation, is much more reliable.
BIND 9 also supports DNSSEC, which isn't yet widely deployed, but is worth checking out.
(I used to work for the ISC, so you might think I'm biased, but I wasn't involved with the ISC BIND project, so it's more that I got to look on while they did it, and was there to see some of the design work they did to make it more reliable, I know the engineers who did it, and I really think they did a great job.)
This is not a showstopper, but just a word of warning - don't do what I did and upgrade in the middle of your work day when you don't have time to fix it. :'}
The software must be open source, so that it can be reviewed by the interested parties. There is simply no other choice that ensures fair elections and does not lead to scapegoating.
To protect against a black hat exploit, the voting system must issue a human- and computer-readable receipt. Then if there is any accusation or evidence of impropriety after the fact, the vote can be recounted.
Also, voting software in the U.S. is used at least once every two years in every district, and in most districts it's used every year. And it doesn't need to (and shouldn't) change much. So even if you have a few elections with black hat exploits, as long as they are discovered and fixed, you do wind up with more reliable voting software over time.
One more thing: making the software open source isn't enough. The hardware has to be open source too. It has to be verifiable, and it has to be available for verification. Otherwise, it can just say it's running your open source software, while in fact it's running a modified closed-source version, or has compromised drivers, or the like.
The government is elected. They can't be the ones that check the software, because they have a conflict of interest. If the software is not open source, there is no way to maintain an appearance of fairness - anybody who doesn't like the outcome of the election can always say "it was rigged," and there's no way to disprove their assertion.
Other than that one nit, I completely agree with you.
The one time I do notice a lack of zippiness on a Mac is when I thrash the cache. Unfortunely, OSX seems to have a unified buffer+page cache, which means that I/O and virtual memory compete with each other head to head for physical memory. So if you have an app that runs through a gigabyte file, all the programs that weren't running at that time wind up swapped out, and it takes a while to get them back.
This is something Apple could probably fix with some intelligent tuning - it's exactly the same problem Sun had in the early versions of SunOS 4. I do hope they fix it soon - it's a bit of a drag.
I bought one of the 500MHz iBooks shortly before the 600Mhz iBooks were released (D'oh!), and it was a bit slow until I stuffed an extra 512M into it. Since then, I've been using it for development work, lots of compiles, lots of testing, and it is just great. My G4 tower is faster, but I do not find myself wishing the iBook was faster when I'm on the road (which is a *lot*, unfortunately - what I find myself wanting is more pixels. :')
Yeah, I'm wondering if the affected drive might be one of those IBM drives. :'} It might also just be that when you have 80G worth of sectors, the possibility of a bad one times the number of sectors produces a probability of >1 that there will be at least one bad sector.
I've read a lot of books in my day, but quite frankly, most of what little knowledge I have comes from the kindness of people who have helped me to learn.
I don't think there's any excuse for asking a question without first doing a little basic research, but here we have somebody who has legitimately never had any experience with terabyte storage asking if there's a cheaper way. It's a legitimate question, and one that probably could not be answered by looking in a book. So the person here is right to ask, and has already gotten some very good answers.
I have a somewhat similar problem: how do I make sure that on the order of a terabyte of audio and video data survives the next hundred years? This given that the disk on which the first 80 gig of this data were delivered to me has two errors that have corrupted two of the files already, and the data isn't even a year old.
What I've been doing is asking other people how they've solved the problem, and also thinking about it on my own. It's how problems get solved. I've gotten some very good and thoughtful answers to my questions already.
Indeed. Sorry I didn't make that explicit. :'}
Try Mozilla again. I've removed Internet Explorer from my system, and I have no regrets. I still run into the occasional incompatibility, but no showstoppers. The one inconvenience is that some advertising pops up in the wrong place. Personally, I'm willing to live with it, but of course your milage may vary... :'}
This probably sounds silly, but when I was living in Arizona and had problems with sun-laser-light crawling across my desk during the day, I found that a broad-brimmed hat was very helpful during certain periods of the day. It's not enough on its own, but it definitely helps. Stylish, too! :'}
It's really awful that Real Media uses un-published formats because it means that if my bits are in Real Media format, I am Real Media's captive - I can only run software that Real Media likes.
If Real Media gets bought by someone who wants to discourage users of certain operating systems, all they have to do is introduce incompatibilities in the undocumented format and do a new release that doesn't support the operating systems they don't like. Because the format is a trade secret, we have no defense against this.
Because MP3 is an open standard, and there are open source programs that decode it, I can play mp3s on any operating system I want. The only thing I have to do is pay the patent fee.
The only way of extending patents that I was able to find in my brief search of the PTO's regulations is that if a prescription drug trial delays release of the drug, the owner of the patent applying to the drug can apply to have the patent extended. So that doesn't apply here.
The difference between this patent and the one-click patent is that the one-click patent patents something that is obvious. The MP3 patent patents something that is not obvious, and that required quite a bit of ingenuity to design. Look into it sometime - mp3 is not something you'd come up with in an afternoon's hacking, or even a month's hacking. It really is a nice piece of science. I don't mind that the people who designed it are getting money for it.
I do wish there were some way for them to get paid that didn't involve coercion. But don't think that a system that would compensate them justly is a simple thing to set up. If you've got any genuinely thoughtful ideas for how to create such a system, I'd be interested in hearing them.
A couple of points:
1. This is an open standard. It's just patented. Patents expire. Nobody is trying to prevent you from writing decoders - they just want to get paid for (I hope) work that they did in developing the technology, which is pretty cool, and which I don't think I could have invented on my own. I am not fond of software patents, but a patent on MP3 is not the same as a patent on one-click or xor cursors.
Compare this to, for example, Real Media player, where the file format isn't *patented* - it's a trade secret. So if Real doesn't support your platform, you can't play real media. This is really awful - much worse than the patent situation with mp3.
2. The royalty is quite reasonable. If you had to pay $0.75 for your copy of WinAMP, would that really seem unfair to you? That's the price of a can of coke, for Pete's sake! It it really that unfair?
3. Like it or not, this is not going to kill MP3, because most MP3 players are commercial, licensed products, and there are a ton of them out there, and they don't support Vorbis. So you don't have to do anything to keep using your MP3s, but if you want to use Vorbis in protest, it's going to be very difficult.
4. I have a large library of audio files that need to get published on the net. They're free, noncommercial, non-revenue-generating. I'll publish them at least in MP3 format, and maybe Ogg if I can get a good encoder. I have a feeling that if I publish Ogg, it's not going to get downloaded very much, but it'll be interesting to see.
If she can't push a button, maybe you could attach a string to her finger and have her pull on it, and that could actuate a lever that crosses a light beam to set off an alarm. You could probably reduce the effort required to sound this sort of alarm quite a bit. Other than that, you're looking at some smart goggles that watch her pupils, which is not a cheap solution.
the tighter you squeeze your fist, the more Stars will slip through your fingers...
(with apologies to George Lucas, I just couldn't resist...)
I haven't seen the bugtraq posting, but I've read the posting on Macslash, and nowhere does it make the claim that this attack has been proven to work. Instead, the claim is made that because Software Update uses port 80, the attack must be possible.
This is untrue. Yes, you can definitely spoof the DNS, if the circumstances are right, and the resolver doesn't support DNSSEC. I don't know if Apple's resolver supports DNSSEC. But practically every software update anybody ever downloads is downloaded in the clear over an unauthenticated connection to an FTP server or an HTTP server. This is not in itself a security hole.
The hole exists _only_ if there is no client-side authentication of what's been downloaded. The authentication needn't be done in-band - it's quite possible that the update client knows an Apple Software Update public key. The client should be doing an MD5 checksum across the entire binary and checking that against a published signature. Does the Apple Software Update client do that? I don't know. As far as I can tell, neither does the person who published this "exploit."
Until we know the answer to this question, saying that this is an exploit is kind of absurd, particularly because I don't know of _anybody_ who downloads software over HTTP+SSL. If Apple are bad guys because they don't use HTTP+SSL, so is everybody else, from Redhat to NetBSD to the ISC to HP.
What many diet proponents ignore is that people are different. What works for one person won't work for another. My wife has completely different nutritional needs than I do.
If exercising in the gym isn't helping you, you may be a person who responds better to aerobic exercise. Try rollerblading or bicycling. The bad news is that, at least for me, it takes real dedication to make a dent in my standard body pattern - I have to do ~1h of aerobics almost every day to lose weight. Some people might not be willing or able to dedicate that much time to the process (I find that I can't generally find the time, frankly).
So the point is, if you want to do it, try some other patterns and see if they work better for you. If you're satisfied with what you've got going now, don't worry about it - it sounds like you're getting a pretty healthy result.
There's no new technology here - my NexTel phone already does every part of this except WiFi. The only thing new is the miniaturization. I think this would be a pretty cool app for an internet company - I work at a company with geeks on two continents, and I'd really like to be able to do this kind of communication with people at work. They have WiFi there, and I have WiFi here, so there's no reason why it couldn't work. You could use SMTP+MIME as the transport layer if necessary.
With multicast, the distribution process is spread out across routers, so it's much less likely that the same bits will cross the same wire twice. If multicast routers were ubiquitous, the same bits would never cross the same wire twice.
If you think about it, this is a fantastic deal - one of the big problems with broadband right now is that the broadband provider has a nice fat pipe to each subscriber, and a similarly fat pipe to the whole rest of the world. So there's a lot of contention on the pipe to the outside world, whereas the pipe to your house is mostly idle. With multicast, a 192kbps feed down the pipe to the outside world can put 192kbps on a significant percentage of the customer pipes. So the ISP can feed much more data to the subscriber for much lower cost.
Interestingly, this also works to the webcaster's advantage - if you want to set up a webcast service on your home machine, it's no skin off the ISP's nose, because you're not pushing 192kbps *per listener* out their pipe to the world - you're pushing a total of 192kbps, which is much less expensive for them. This reduces their incentive/ability to provide lopsided connectivity, where you can receive a lot but send only a little.
My only worry is that AOL might be deploying something proprietary and non-interoperable, and then the ISPs will wind up paying for a system that we can't use this way, even though it would have cost the same as a system we could use this way.
Being one of those jerks who talks on my cell phone a fair amount (I do try to be considerate, honest!) I have to say that reducing the number of moving parts in the phone sounds like a wonderful idea. My biggest problem with cell phones is how flimsy they are, and how quickly parts of them wear out. if this improves the MTBF for the phone, I say bring it on!
I have friends who use PCs, and I can't recommend the iPod to them. This looks like a fine substitute. However, if you have a Mac, I think the iPod is a better choice. My wife has an iPod, and I _really_ like the user interface. The Toshiba's user interface looks like it would be hard to operate while rollerblading, which is when I usually use it.
Yes, the iPod "prevents" you from copying the music from the iPod onto your computer, but it's trivial to get around it - all the data is there. The "prevention" is in iTunes. If you just plug the thing in and fish around on the drive, all the data is there in discrete files, and writing a perl script to extract it back into a music folder would be very easy.
Whois reports who is maintaining DNS for the zone file, not who owns the company. As to your other comment, I can't really help you with that.