High-speed trains are quite popular in Japan and Europe, and many Americans scratch their heads and ask why?, especially when they cost almost as much as flying.
There are a few key reasons why they are so great:
1. Central terminals: trains tend to depart and arrive near the center of cities, while airports tend to be located outside the city. When I take the Eurostar train from London to Paris, I knock off 1/2 hour travel time at each end just because of the location.
2. No airports: flying in America (and to a lesser extent other places) is painful. You're asked to arrive a few hours early and treated like a criminal. I traveled in Japan on the bullet trains, and we had to arrive before the train left (they are famous for being on time) but that was it. No body cavity search, no x-rays, no checking in a few hours early. No only did I leave and arrive right in the middle of the respective cities (saving time) I did so according to the actual travel schedule, not according to some ridiculous security schedule.
3. Comfort: trains are the most comfortable way to travel. They are quieter than planes, roomier, have bigger windows and nice views (when flying I sometimes get a nice view out the window, but usually just see clouds or the dude sitting next to me), the air is normal pressure, you can walk around at any time, etc. You also have your luggage right there in the car with you so you can get to it at any time. A recent train ride I took from London to Edinburgh took half the time driving takes, each seat had power outlets, and there was WiFi access available as well as a full meal car.
4. Distances: when traveling in Europe and Japan, travel time isn't dominated as much by the distance. The end-to-end time is often better on trains when traveling between major cities (with good rail links). You arrive at the centrally located station a few minutes before the train leaves, enjoy a (relatively) comfortable ride, then step off at the other end with your bags (no waiting for baggage claim) and walk out into the center of your destination city. The timing may not work quite as well for New York to Los Angeles, but for London to Paris or Brussels, or for Los Angeles to San Francisco, a good train line makes a lot of sense.
I'm no expert, but isn't labeling a court case using v. instead of vs. reserved for supreme court cases (from the first page of the document)? I suppose it's nit-picking, but it seems that SCO regularly overstate their importance in the world.
I finally uninstalled all the card games from my machine. I don't enjoy playing them, but somehow I managed to sink a lot of time into them anyway. Unplug your network cable, move the TV to another toom. Sure, you can just plug it back in or move it back (or even re-install the games in my case), but that's a fairly deliberate action that at least triggers a clear signal to yourself that you are breaking the rules (and might as well go out with your friends). Sometimes a (mostly) mental obstactle is enough to keep you in line.
Another trick that helped me sometimes was to recognize when my mind was wandering and set a fairly short but focused goal. Read 50 pages and I can go get a slice of pizza, or get 10 problems done and I can go to a movie. Actually take the reward--this isn't meant to be a carrot on a stick--and you'll at least get more done than you would have otherwise without beating yourself up for hours. It can also help develop the mental discipline you are seeking stepwise.
If I wanted to pick a single identifier (which, like many others who have commented, I don't), I wouldn't want it to be a 10 digit number. Maybe I should start giving out my IP address instead of my named web site address, too. You don't see people rushing out to register domain names like 2139812309.com because they suck compared to even a ridiculous name like slashdot.org.
I thought we were past using meaningless numbers for electronic addresses. Am I the only one who thinks they are doing this backwards?
- Russ
The design is meant to be decentralized (except for some databases like DNS) but in practice it isn't nearly as decentralized as it should be.
I remember an anecdote about some company that installed multiple data feeds from multiple vendors to ensure reliability--redundancy is always good, right? Some construction worker was fixing a pipe and cut a fiber cable and sure enough, the company was offline. The different vendors all shared the same fiber so the redundancy wasn't real.
Tons of traffic gets jammed through a few key distribution routes. I'll bet the typical internet user sends traffic through many routers with no backups--you could probably shut down my home cable modem service by pulling the plug on any of at least half-a-dozen routers before it gets out of the provider's internal network. Redundancy in the backbone is nice, but useless if the endpoints are vulnerable.
- Russ
rounding bugs
on
Pet Bugs?
·
· Score: 2, Interesting
My favorite rounding bug was the floating point bug in Applesoft BASIC on the Apple II series. A loop that adds.1 repeatedly to a variable would expose it pretty quickly. It was a basic part of life for years on that machine. To this day I am still very careful about comparing floats using an EPSILON value, i.e., the equivalent of abs(x - y) EPSILON rather than x == y.
The Pentium bug was definitely a big one, but the Applesoft bug had more of an effect on me personally.
I feel like a gray-haired old man showing my age and I'm only 25. Weird industry we're in..
Remember tiny, small, medium, large, and huge memory models under DOS with Borland C? Huge existed to provide pointers that were normalized and could be compared like integers (offset was always less than 16), unlike large. Under pre-32 bit x86, all memory addresses were of the form segment + offset, where segment might be implied. The actual address was segment * 16 + offset. This was useful for some things, but it was abandoned in favor of a much better system (virtual memory).
Unfortunately, pointer normalization didn't actually work, at least in the version I used. It took me forever to figure that out--after all, the whole purpose of the huge memory model was to provide that functionality. After the clumps of hair that I'd pulled out grew back, I wrote a bunch of ugly C macros to do the job.
Such a dumb bug, but it was so frustrating that it immediately jumped to mind.
One of the biggest strengths of Solaris has always been the Sparc hardware. Hot swappable components, beefier IO channels, etc. have contributed much to typical Solaris installations over a typical x86 server running Linux. x86 machines are built with home and business users in mind, not servers. Server lines from most vendors are little more than home machines with a little extra memory and a bigger hard drive.
Have a look at Solaris on x86, which Sun dropped completely for a while (I don't remember for sure, but I think they brought back some support for it). It has never been used much, because those that need the scalability and stability that Solaris is reputed to provide know that they'll only get it when using Sun's hardware.
I'm guessing that we'll see an iterative process that will improve matters on the x86/Linux side. As Linux is used more widely for server deployments, more hardware vendors will jump in the game and provide better hardware, and as the hardware becomes available the reputation of Linux on that hardware will improve and the cycle will repeat itself. For now, there are a few small vendors (small marketshare) trying to make x86 server hardware that is actually appropriate for big installations, but most people buy a machine labeled for server use and install Linux on it, and then they blame the shortcomings of the desktop user hardware on Linux.
At least on Linux systems, the scheduler behavior is definately affected by even a single low priority (nice value 19) task. I run distributed.net clients full time on my system and generally it's not a problem, but sometimes when running another CPU bound interactive job (playing back movies or MP3s, playing games on an emulator, games in general) the effects are noticeable.
When I was an undergrad I did a semester research project on this and identified some of the problems:
I run a dual CPU machine now which generally masks the problem, but even the fastest single CPU systems will suffer noticeable effects once the scheduler falls back to a round robin scheme with weighted timeslice lengths which is essentially what happens once you have two or more CPU bound jobs competing for CPU time.
It's not necessarily a matter of mapping a specific engineering problem to an OOP model that will yield benefits. I see OOP as valuable for any large software project even if the problem itself is not particularly object based. User interface code maps better to OO designs and collaboration in a developement team tends to work more smoothly with an OO framework. I think it is in the general construction of an application that OOP will give benefits (if used properly) rather than in the specific solution to a specific problem. In that sense, any engineering application could benefit. For small problems (and small applications) I generally use an imperative language like C or Perl, but for larger projects I favor a OOP approach.
I almost bought a similar mouse a year ago (I forget who made it) but they aren't actually that nice to use. The design makes you use your whole arm to move instead of your wrist, and you lose the fine level of control that your wrist gives you. The result is that motion is pretty clumsy and inaccurate with this kind of design.
I suspect that many people will take a similar route and find smaller scale file sharing systems. Many companies have (unofficial and probably illegal) mp3 servers behind their firewalls that the employees use for swapping songs. Simple unadvertised web sites and ftp servers as well as Windows filesharing (or Samba) make it easy to set us similar arrangements for other groups like college buddies. That happens now and will continue to happen no matter what the conclusion is with Napster and similar services.
A legal, public solution is still necessary. Napster was an interesting case because of the legal ambiguities involved. They tried arguments about how they weren't actually trafficing the illegal files but rather providing an infrastructure that others could use either legally or illegally. A nice argument but it didn't hold up in court.
Even if Napster had won or another decentralized service managed to thrive so the RIAA didn't have anyone to sue, we would still have a lot of _illegal_ filesharing going on. We may not like or agree with the laws, but it's pretty clear that the level of music copying going on right now is not legal according to the laws that are on the books. Even if you believe that file sharing helps album sales, you are still faced with the reality that the copyright laws prohibit that copying.
Personally, I would love to see reforms to the copyright laws and see the RIAA recognize that these services actually help them in many ways (I have spent a lot more money buying CDs than before because friends have given me mp3s to listen to and I've ended up buying the album) but even if that doesn't happen we need some way to get a legal public face to the file sharing problem. Something that imposes reasonable royalties is much better than saying that any public service is contraband. Maybe the RIAA would finally stop harassing everyone that way.
The whole point of the article was that if the two parties could not come to an agreement on a fair licensing rate, then the court could call for third party arbitration to determine the licensing fees. Naturally, Napster would want to license everything for free, and the RIAA would want to license everything for some ridiculous price; the option of an arbitrator is what gives the court decision some teeth.
I'd have to disagree. The contest was designed to have tangible numbers to show to clueless lawmakers who seem to think that weak encryption is the only safe option for normal people to use.
The DES challenges (and particularly the EFF's Deep Crack machine) were very effective in showing that 56 bit DES wasn't good enough any more. Believe it or not, many lawmakers will still insist that there's no need for private individuals to have access to anything more powerful.
The RC5-64 challenge provides some hard evidence about what computing resources a volunteer effort can muster up to attack an encryption key. One should always assume that a government or corporate sponsered effort can accomplish much more using custom hardware and/or more CPUs. A project that takes a few years with idle CPU cycles shows that 64 bit keys are not good enough for data that needs to be safe for years to come. That helps RSA only in that it helps them lobby for less restrictive legistation. Selling 64 bit RC5 is no less profitable to them than selling 128 bit RC5.
An unfinished challenge is infinitely less useful than a completed challenge. The latter gives positive proof, the former says that a bunch of people tried to break a key for years and failed. Which tells a better story to a Congressman who still has a secretary in the next room typing up letters for him and has no real clue about technology issues?
Distributed.net is not about RSA Data Corp, it's about privacy and technology in general. We all stand to benefit. I'm still not convinced that finding large prime numbers or OGRs will help life outside of the research community. I have nothing against those efforts and will likely switch to them when the RC5-64 challenge is complete, but for now I see a lot more to gain from RC5-64 than the others.
This would be a great way to get my noisy box out of my room. My roommate described my computer as sounding like a small airplane, and he's not too far off. Stupid noisy fans all over the place.
My first internet account was through our local community college which was a 2 year college with a.edu domain. It recently turned 4 year, but it had a.edu domain for years before that was even planned. Did the rules change at some point?
I thought factoring was NP-complete, in which case all (all, he says ^_^) you should need to do is make the keyspace large enough such that it would take a hundred years to crack even if every elementary particle in the universe were used to crack it. But I'm quite possibly wrong (and we haven't gotten to NP-completeness in my algorithms class yet ^_^)
Actually, it's not known to be NP-complete, i.e., it hasn't been proved. You aren't alone in thinking it is; I've seen quite a few people make that assumption. One of the unsolved problems in complexity theory is the question of whether or not NP = co-NP. It turns out that if factoring is NP-complete then NP = co-NP (I can point you to more details if you are interested), so it's actually a little bigger question than many people realize.
True, but he doesn't claim to do so. He assumes that a reasonable distribution method exists that can resist attack for some relatively short period of time. I agree with you that he relies on assumptions, and this is one of them. However, I also think that this is a relatively safe assumption, and to say that his scheme falls apart because of this assumption is too strong a statement.
Existing key distribution protocols such as Diffie-Helmen work well enough for passing secret keys around, but they are only secure for a limited time (hopefully a long time, but finite nonetheless). An important stream of data transmitted using that secret key is then only secure for as long as it takes the opponent to either crack the secret key directly or to crack the key exchange protocol (which would yield the secret key). Large keys and a trusted protocol give us a good measure of assurance, but we are vulnerable to future advances in the field. If someone finds a fast factoring algorithm, then he could go back and easily decode lots of transactions whose 128 bit secret keys were transmitted using RSA for protection.
Rabin's proposal eliminates this future uncertainty, and that's the crux of his idea. The window of vulnerability is limited--if the attacker can't find the secret key quickly, then even if he finds it later it will do him no good.
> He's smart, so it must work? Yeah, right.
I agree with you on this as well. However, I do think that an argument by someone like Rabin deserves a little extra thought before a rebuttle is made. I've attended talks and classes by him, and also talks where he's been in the audience and asked questions of the speaker. He drills right to the weak points and very little gets past him. I'm not saying he's infallible, but I'd be pretty surprised if he missed any obvious points. He also atracts a high caliber of peers to review his work (people like Ron Rivest at MIT) and it's unlikely they'd let obvious errors slide by.
> I do have to at least be leary of the
> assumption that storage is a more finite
> resource than computing power.
I'd have to agree with you on this one. It's obviously not practical for any but a few applications. Still, I think it's interesting in that, given a few assumptions (which he does lay out clearly even if the NYT doesn't), he can prove that your data will be secure forever. If the secret key is safe for a given amount of time, then the rest of your data is secure forever. Pretty interesting, I think, even if it's not terribly practical for most users.
- Russ
p.s. I apologize if my tone was beligerent before.
> I mean, really. If we had a 'secret' way to
> safely exchange keys, we could just use that
> method to communicate in the first place!
This is missing the point--the secret only has to be secure for a short amount of time. If the listener cannot crack your secret key immediately, he has no chance of ever intercepting the data.
> If we take the window of vulnerability in his
> method to be X seconds, then this would be no
> better than using current techniques but issuing
> a new private key every Y X seconds (no
> satellite required)
Again, not true. Using your scheme, a cryptanalyst with plenty of time could decode your message at his leisure. Using Rabin's approach, an analysis after the fact is useless. You're missing the whole point of this scheme.
I should point out that Rabin has an excellent understanding of practical issues. RSA encryption would not be usable without his randomized primality testing algorithm (every RSA key generator relies on it) for which he won the Turing award in the 70's. I'd be a little more careful when trying to poke holes in the work of one of the gods of the field.
It's not too surprising that a dual processor machine gets more than double performance on a kernel compile. Compiling requires several processes working in serial (preprocessor feeds the compiler front end, etc.). One a single processor system, you have to switch back & forth constantly and you lose a lot to context switch overhead. Also, you don't typically run make with a "-j" setting so when you are blocked on I/O everyone waits and the processor goes idle. Having two complete jobs tends to fill in the holes better (the 2-3 processes involved in one compile will fill in the slack while another compile gets started up by make).
There are actually a lot of benefits to a dual-processor setup. I did a research project on the Linux scheduler for interactive users:
True, robot.txt is optional, but all major search engines _do_ honor it. I attended a talk by some of google's engineers a while back and they have a lot of legal threats early on just because they crawled a site too fast. Most commercial search engines are pretty responsible about crawling because they can't afford the legal threats and bad press otherwise.
Someone else mentioned a per-page META tag alternative to robot.txt, and I would also point out that the server-level configuration problem is between you and your ISP, as are many other access and content issues. The outside user only really cares (legally at least) about how their browsing/searching behavior interacts with the ISP, and then the ISP has a relationship with the site that is completely seperate.
It's worth noting that search engines honor the robots.txt protocol, so any web site can easily opt out of being indexed. There isn't anything like that in WHOIS. If I remember right, ebay lists its auction items as off-limits for bots in robots.txt. I see that as the strongest distinction between search engines and the cases mentioned here.
The guy writing plex86 did a project (from which he borrows a lot of code) which aims to do that. It's called bochs and it was initially written as a x86 emulator that can run on any host. I read at some point that they were planning to do dynamic recompiling so that the majority of code could run directly on the host hardware.
Someone else mentioned HP's Dynamo system. It's not really the same thing, though. It focuses on applying extra optimizations based on run-time profiling. For example, it reorders basic blocks and optimizes common execution paths, but it is still the same instruction set.
There have been other commercial systems that do just what you describe. Digital (now Compaq) had a system called FX/32 (if I remember right) which allowed x86 Win32 binaries to run on Alpha Win32. There was a version of WinNT for the Alpha which ran natively with the same API, so the translation mainly had to deal with instruction set differences; it was still running under Windows NT. It was a pretty cool system that worked fairly well. The fastest way to run some common x86 Win32 applications was to load them up on an Alpha.
In addition, there have been other commercial systems designed to help transition existing customers to a new architecture. Some of these had hardware support (I believe that was the case with Apple's move to PowerPC from the Motorola 68k line) but others did binary translation.
Slashdot Mirror
High-speed trains are quite popular in Japan and Europe, and many Americans scratch their heads and ask why?, especially when they cost almost as much as flying.
There are a few key reasons why they are so great:
1. Central terminals: trains tend to depart and arrive near the center of cities, while airports tend to be located outside the city. When I take the Eurostar train from London to Paris, I knock off 1/2 hour travel time at each end just because of the location.
2. No airports: flying in America (and to a lesser extent other places) is painful. You're asked to arrive a few hours early and treated like a criminal. I traveled in Japan on the bullet trains, and we had to arrive before the train left (they are famous for being on time) but that was it. No body cavity search, no x-rays, no checking in a few hours early. No only did I leave and arrive right in the middle of the respective cities (saving time) I did so according to the actual travel schedule, not according to some ridiculous security schedule.
3. Comfort: trains are the most comfortable way to travel. They are quieter than planes, roomier, have bigger windows and nice views (when flying I sometimes get a nice view out the window, but usually just see clouds or the dude sitting next to me), the air is normal pressure, you can walk around at any time, etc. You also have your luggage right there in the car with you so you can get to it at any time. A recent train ride I took from London to Edinburgh took half the time driving takes, each seat had power outlets, and there was WiFi access available as well as a full meal car.
4. Distances: when traveling in Europe and Japan, travel time isn't dominated as much by the distance. The end-to-end time is often better on trains when traveling between major cities (with good rail links). You arrive at the centrally located station a few minutes before the train leaves, enjoy a (relatively) comfortable ride, then step off at the other end with your bags (no waiting for baggage claim) and walk out into the center of your destination city. The timing may not work quite as well for New York to Los Angeles, but for London to Paris or Brussels, or for Los Angeles to San Francisco, a good train line makes a lot of sense.
- Russ
I'm no expert, but isn't labeling a court case using v. instead of vs. reserved for supreme court cases (from the first page of the document)? I suppose it's nit-picking, but it seems that SCO regularly overstate their importance in the world.
- Russ
From the download page:
"...which includes the Dis virtual machine, integral support for the Styx network protocol, and an implementation of the Tk user interface toolkit."
So Tk gets lumped in with all the other hell stuff. And here I always thought it was Tcl that was demonspawn...
- Russ
I finally uninstalled all the card games from my machine. I don't enjoy playing them, but somehow I managed to sink a lot of time into them anyway. Unplug your network cable, move the TV to another toom. Sure, you can just plug it back in or move it back (or even re-install the games in my case), but that's a fairly deliberate action that at least triggers a clear signal to yourself that you are breaking the rules (and might as well go out with your friends). Sometimes a (mostly) mental obstactle is enough to keep you in line.
Another trick that helped me sometimes was to recognize when my mind was wandering and set a fairly short but focused goal. Read 50 pages and I can go get a slice of pizza, or get 10 problems done and I can go to a movie. Actually take the reward--this isn't meant to be a carrot on a stick--and you'll at least get more done than you would have otherwise without beating yourself up for hours. It can also help develop the mental discipline you are seeking stepwise.
- Russ
If I wanted to pick a single identifier (which, like many others who have commented, I don't), I wouldn't want it to be a 10 digit number. Maybe I should start giving out my IP address instead of my named web site address, too. You don't see people rushing out to register domain names like 2139812309.com because they suck compared to even a ridiculous name like slashdot.org. I thought we were past using meaningless numbers for electronic addresses. Am I the only one who thinks they are doing this backwards? - Russ
The design is meant to be decentralized (except for some databases like DNS) but in practice it isn't nearly as decentralized as it should be.
I remember an anecdote about some company that installed multiple data feeds from multiple vendors to ensure reliability--redundancy is always good, right? Some construction worker was fixing a pipe and cut a fiber cable and sure enough, the company was offline. The different vendors all shared the same fiber so the redundancy wasn't real.
Tons of traffic gets jammed through a few key distribution routes. I'll bet the typical internet user sends traffic through many routers with no backups--you could probably shut down my home cable modem service by pulling the plug on any of at least half-a-dozen routers before it gets out of the provider's internal network. Redundancy in the backbone is nice, but useless if the endpoints are vulnerable.
- Russ
My favorite rounding bug was the floating point bug in Applesoft BASIC on the Apple II series. A loop that adds .1 repeatedly to a variable would expose it pretty quickly. It was a basic part of life for years on that machine. To this day I am still very careful about comparing floats using an EPSILON value, i.e., the equivalent of abs(x - y) EPSILON rather than x == y.
The Pentium bug was definitely a big one, but the Applesoft bug had more of an effect on me personally.
I feel like a gray-haired old man showing my age and I'm only 25. Weird industry we're in..
- Russ
Remember tiny, small, medium, large, and huge memory models under DOS with Borland C? Huge existed to provide pointers that were normalized and could be compared like integers (offset was always less than 16), unlike large. Under pre-32 bit x86, all memory addresses were of the form segment + offset, where segment might be implied. The actual address was segment * 16 + offset. This was useful for some things, but it was abandoned in favor of a much better system (virtual memory).
Unfortunately, pointer normalization didn't actually work, at least in the version I used. It took me forever to figure that out--after all, the whole purpose of the huge memory model was to provide that functionality. After the clumps of hair that I'd pulled out grew back, I wrote a bunch of ugly C macros to do the job.
Such a dumb bug, but it was so frustrating that it immediately jumped to mind.
- Russ
One of the biggest strengths of Solaris has always been the Sparc hardware. Hot swappable components, beefier IO channels, etc. have contributed much to typical Solaris installations over a typical x86 server running Linux. x86 machines are built with home and business users in mind, not servers. Server lines from most vendors are little more than home machines with a little extra memory and a bigger hard drive.
Have a look at Solaris on x86, which Sun dropped completely for a while (I don't remember for sure, but I think they brought back some support for it). It has never been used much, because those that need the scalability and stability that Solaris is reputed to provide know that they'll only get it when using Sun's hardware.
I'm guessing that we'll see an iterative process that will improve matters on the x86/Linux side. As Linux is used more widely for server deployments, more hardware vendors will jump in the game and provide better hardware, and as the hardware becomes available the reputation of Linux on that hardware will improve and the cycle will repeat itself. For now, there are a few small vendors (small marketshare) trying to make x86 server hardware that is actually appropriate for big installations, but most people buy a machine labeled for server use and install Linux on it, and then they blame the shortcomings of the desktop user hardware on Linux.
- Russ
When I was an undergrad I did a semester research project on this and identified some of the problems:
http://www.russross.com/cs261/paper.html
I run a dual CPU machine now which generally masks the problem, but even the fastest single CPU systems will suffer noticeable effects once the scheduler falls back to a round robin scheme with weighted timeslice lengths which is essentially what happens once you have two or more CPU bound jobs competing for CPU time.
- Russ
It's not necessarily a matter of mapping a specific engineering problem to an OOP model that will yield benefits. I see OOP as valuable for any large software project even if the problem itself is not particularly object based. User interface code maps better to OO designs and collaboration in a developement team tends to work more smoothly with an OO framework. I think it is in the general construction of an application that OOP will give benefits (if used properly) rather than in the specific solution to a specific problem. In that sense, any engineering application could benefit. For small problems (and small applications) I generally use an imperative language like C or Perl, but for larger projects I favor a OOP approach.
- Russ
I almost bought a similar mouse a year ago (I forget who made it) but they aren't actually that nice to use. The design makes you use your whole arm to move instead of your wrist, and you lose the fine level of control that your wrist gives you. The result is that motion is pretty clumsy and inaccurate with this kind of design.
- Russ
I suspect that many people will take a similar route and find smaller scale file sharing systems. Many companies have (unofficial and probably illegal) mp3 servers behind their firewalls that the employees use for swapping songs. Simple unadvertised web sites and ftp servers as well as Windows filesharing (or Samba) make it easy to set us similar arrangements for other groups like college buddies. That happens now and will continue to happen no matter what the conclusion is with Napster and similar services.
A legal, public solution is still necessary. Napster was an interesting case because of the legal ambiguities involved. They tried arguments about how they weren't actually trafficing the illegal files but rather providing an infrastructure that others could use either legally or illegally. A nice argument but it didn't hold up in court.
Even if Napster had won or another decentralized service managed to thrive so the RIAA didn't have anyone to sue, we would still have a lot of _illegal_ filesharing going on. We may not like or agree with the laws, but it's pretty clear that the level of music copying going on right now is not legal according to the laws that are on the books. Even if you believe that file sharing helps album sales, you are still faced with the reality that the copyright laws prohibit that copying.
Personally, I would love to see reforms to the copyright laws and see the RIAA recognize that these services actually help them in many ways (I have spent a lot more money buying CDs than before because friends have given me mp3s to listen to and I've ended up buying the album) but even if that doesn't happen we need some way to get a legal public face to the file sharing problem. Something that imposes reasonable royalties is much better than saying that any public service is contraband. Maybe the RIAA would finally stop harassing everyone that way.
- Russ
The whole point of the article was that if the two parties could not come to an agreement on a fair licensing rate, then the court could call for third party arbitration to determine the licensing fees. Naturally, Napster would want to license everything for free, and the RIAA would want to license everything for some ridiculous price; the option of an arbitrator is what gives the court decision some teeth.
- Russ
I'd have to disagree. The contest was designed to have tangible numbers to show to clueless lawmakers who seem to think that weak encryption is the only safe option for normal people to use.
The DES challenges (and particularly the EFF's Deep Crack machine) were very effective in showing that 56 bit DES wasn't good enough any more. Believe it or not, many lawmakers will still insist that there's no need for private individuals to have access to anything more powerful.
The RC5-64 challenge provides some hard evidence about what computing resources a volunteer effort can muster up to attack an encryption key. One should always assume that a government or corporate sponsered effort can accomplish much more using custom hardware and/or more CPUs. A project that takes a few years with idle CPU cycles shows that 64 bit keys are not good enough for data that needs to be safe for years to come. That helps RSA only in that it helps them lobby for less restrictive legistation. Selling 64 bit RC5 is no less profitable to them than selling 128 bit RC5.
An unfinished challenge is infinitely less useful than a completed challenge. The latter gives positive proof, the former says that a bunch of people tried to break a key for years and failed. Which tells a better story to a Congressman who still has a secretary in the next room typing up letters for him and has no real clue about technology issues?
Distributed.net is not about RSA Data Corp, it's about privacy and technology in general. We all stand to benefit. I'm still not convinced that finding large prime numbers or OGRs will help life outside of the research community. I have nothing against those efforts and will likely switch to them when the RC5-64 challenge is complete, but for now I see a lot more to gain from RC5-64 than the others.
- Russ
The keyrate is constantly accelerating, though. The stats listed on the site are for the current keyrate, so the calculation is a bit more involved.
- Russ
This would be a great way to get my noisy box out of my room. My roommate described my computer as sounding like a small airplane, and he's not too far off. Stupid noisy fans all over the place.
- Russ
My first internet account was through our local community college which was a 2 year college with a .edu domain. It recently turned 4 year, but it had a .edu domain for years before that was even planned. Did the rules change at some point?
Actually, it's not known to be NP-complete, i.e., it hasn't been proved. You aren't alone in thinking it is; I've seen quite a few people make that assumption. One of the unsolved problems in complexity theory is the question of whether or not NP = co-NP. It turns out that if factoring is NP-complete then NP = co-NP (I can point you to more details if you are interested), so it's actually a little bigger question than many people realize.
- Russ
> He hasn't solved the key distribution problem.
True, but he doesn't claim to do so. He assumes that a reasonable distribution method exists that can resist attack for some relatively short period of time. I agree with you that he relies on assumptions, and this is one of them. However, I also think that this is a relatively safe assumption, and to say that his scheme falls apart because of this assumption is too strong a statement.
Existing key distribution protocols such as Diffie-Helmen work well enough for passing secret keys around, but they are only secure for a limited time (hopefully a long time, but finite nonetheless). An important stream of data transmitted using that secret key is then only secure for as long as it takes the opponent to either crack the secret key directly or to crack the key exchange protocol (which would yield the secret key). Large keys and a trusted protocol give us a good measure of assurance, but we are vulnerable to future advances in the field. If someone finds a fast factoring algorithm, then he could go back and easily decode lots of transactions whose 128 bit secret keys were transmitted using RSA for protection.
Rabin's proposal eliminates this future uncertainty, and that's the crux of his idea. The window of vulnerability is limited--if the attacker can't find the secret key quickly, then even if he finds it later it will do him no good.
> He's smart, so it must work? Yeah, right.
I agree with you on this as well. However, I do think that an argument by someone like Rabin deserves a little extra thought before a rebuttle is made. I've attended talks and classes by him, and also talks where he's been in the audience and asked questions of the speaker. He drills right to the weak points and very little gets past him. I'm not saying he's infallible, but I'd be pretty surprised if he missed any obvious points. He also atracts a high caliber of peers to review his work (people like Ron Rivest at MIT) and it's unlikely they'd let obvious errors slide by.
> I do have to at least be leary of the
> assumption that storage is a more finite
> resource than computing power.
I'd have to agree with you on this one. It's obviously not practical for any but a few applications. Still, I think it's interesting in that, given a few assumptions (which he does lay out clearly even if the NYT doesn't), he can prove that your data will be secure forever. If the secret key is safe for a given amount of time, then the rest of your data is secure forever. Pretty interesting, I think, even if it's not terribly practical for most users.
- Russ
p.s. I apologize if my tone was beligerent before.
> I mean, really. If we had a 'secret' way to
> safely exchange keys, we could just use that
> method to communicate in the first place!
This is missing the point--the secret only has to be secure for a short amount of time. If the listener cannot crack your secret key immediately, he has no chance of ever intercepting the data.
> If we take the window of vulnerability in his
> method to be X seconds, then this would be no
> better than using current techniques but issuing
> a new private key every Y X seconds (no
> satellite required)
Again, not true. Using your scheme, a cryptanalyst with plenty of time could decode your message at his leisure. Using Rabin's approach, an analysis after the fact is useless. You're missing the whole point of this scheme.
I should point out that Rabin has an excellent understanding of practical issues. RSA encryption would not be usable without his randomized primality testing algorithm (every RSA key generator relies on it) for which he won the Turing award in the 70's. I'd be a little more careful when trying to poke holes in the work of one of the gods of the field.
- Russ
There are actually a lot of benefits to a dual-processor setup. I did a research project on the Linux scheduler for interactive users:
http://www.people.fas.harvard.edu/~rross/cs265/pap er.html
Afterward I put together a dual-celeron system and the improvement in the overall responsiveness and feel of the system was quite dramatic.
- Russ
True, robot.txt is optional, but all major search engines _do_ honor it. I attended a talk by some of google's engineers a while back and they have a lot of legal threats early on just because they crawled a site too fast. Most commercial search engines are pretty responsible about crawling because they can't afford the legal threats and bad press otherwise.
Someone else mentioned a per-page META tag alternative to robot.txt, and I would also point out that the server-level configuration problem is between you and your ISP, as are many other access and content issues. The outside user only really cares (legally at least) about how their browsing/searching behavior interacts with the ISP, and then the ISP has a relationship with the site that is completely seperate.
- Russ
It's worth noting that search engines honor the robots.txt protocol, so any web site can easily opt out of being indexed. There isn't anything like that in WHOIS. If I remember right, ebay lists its auction items as off-limits for bots in robots.txt. I see that as the strongest distinction between search engines and the cases mentioned here.
- Russ
The guy writing plex86 did a project (from which he borrows a lot of code) which aims to do that. It's called bochs and it was initially written as a x86 emulator that can run on any host. I read at some point that they were planning to do dynamic recompiling so that the majority of code could run directly on the host hardware.
Someone else mentioned HP's Dynamo system. It's not really the same thing, though. It focuses on applying extra optimizations based on run-time profiling. For example, it reorders basic blocks and optimizes common execution paths, but it is still the same instruction set.
There have been other commercial systems that do just what you describe. Digital (now Compaq) had a system called FX/32 (if I remember right) which allowed x86 Win32 binaries to run on Alpha Win32. There was a version of WinNT for the Alpha which ran natively with the same API, so the translation mainly had to deal with instruction set differences; it was still running under Windows NT. It was a pretty cool system that worked fairly well. The fastest way to run some common x86 Win32 applications was to load them up on an Alpha.
In addition, there have been other commercial systems designed to help transition existing customers to a new architecture. Some of these had hardware support (I believe that was the case with Apple's move to PowerPC from the Motorola 68k line) but others did binary translation.
- Russ