The best feature of Linux is its stability; considering my uptime is 134 days, I could care less about the boot process
The first word that comes to mind when I see a system with a 134 day uptime is not "stability". The word that comes to mind is "insecure", from the patches you've had to skip to get that uptime.
He's not "just a Sun employee" with a chip on his shoulder, he is a giant in his field. Give the guy the respect he deserves
He's a giant in his field. That means pay attention to the parts where he talks about cryptography. However, it doesn't mean he's got any particular insight into the rest of the issues covered.
He could be like Noam Chomsky, who is a giant in the field of linguistics, but a total goofball in politics, for instance.
Yeah, except the FireWire is used for synching, tranferring files, and recharging the device. You wouldn't want to do any of that with USB
USB is fine for syncing. A typical song would take around 4 seconds to transfer over USB. That sucks when you first get the thing and are downloading months worth of rips to it, but is is fine for keeping the device up to date with your new rips.
Replace the 5 gig drive with a 20 gig drive, change Firewire to USB, keep the ability to use it as an external hard disk, drop the presumed heavy integration with iTunes, knock the battery life down to 8 hours from 10, knock $50 off the price, and you've got this [thinkgeek.com].
iPod is a good product, but nothing to get excited over.
I'll stay with my RioVolt [thinkgeek.com]. Instead of a hard disk, it uses CD-R or CD-RW, and can play regular audio CDs.
Wine was written by people without access to windows source code. SkyOS's linux-emulation layer was written by people with access to linux source code. Therefore, it is far more likely that code was 'borrowed' in writing this emulation layer
That's completely backwards. When writing an emulation layer (I speak from experience...if you ever ran a System V 286 binary on a System V 386 Unix or an SCO Xenix 286 binary on a Systemv V 386 Unix, you were using the emulation layer Darryl Richman, Carl Hensler, and I wrote when we worked at Interactive), you do not want to use actual code from the OS you are emulating. That code doesn't work like your OS works (if it did...you wouldn't need an emulation layer...you'd just need some argument munging and other trivial stuff).
The hard thing about an emulation layer is finding out just what the thing you are emulating does. An emulation layer has to not just follow the written spec (if there is one), but also has to implement the same bugs as the thing you are emulating, and follow the same choices where there was leeway in the spec, or you might break binary compatibility.
When emulating something that is open source, like Linux, you have the documentation you need: the source code. You read it to find out what the real behaviour is, and then implement that in a way that fits in with the way your OS works. It simple is almost never going to be faster to rip the actual code and try to use it.
When emulating a closed source thing like Windows, however, finding out the actual behaviour you need to emulate (remember...gotta match the actual behaviour, not just what the spec says) can take much experimenting and disassembly. It is much more temping (because it can actually save a lot of time), to rip some DLLs from Windows, and cobble together a framework to run them under your system.
So, just from a "what might developer's do" point of view, it is actually more likely a Windows emulation project would use parts of Windows they should not use than a Linux emulation project would use parts of Linux they should not use.
If an ISP wants to offer blocking based on MAPS or any other system, then they should set up an opt-in for individual users, and the default should be opt-out
It is opt-in. When deciding what ISP to use, one of the things you should look at is how they deal with spam. If they use MAPS and you don't want to use MAPS, don't use that ISP.
Spam should be legal, as long as they include a valid return addy, and have a way to remove people (for real)
The big problem with that Gaijin42, is that spam is very cheap to send, and mailing lists are easy to build and exchange.
Run some numbers...say, several thousand companies sending spam to 20 million people each, with a lot of overlap on the mailing lists. Some people would get thousands of emails. This would make email completely unusable for anything other than receiving spam, for many people.
As long as the sender does not pay the cost of email, spam has to be limited.
You never had any "fair use" rights to forfeit. The fair use law (and the common law doctrine it was codified from) never gave you a right to copy...it merely made it so certain copying did not violate copyright.
The copyright holders have always been allowed to stop fair use copying, by contract or by taking technological steps to prevent the copying. Fair use merely prevents them from using section 106 of the Copyright Act to stop copying.
UPS and FedEx packages would not be as good for anthrax delivery for a couple of reasons.
1. They are tracked more extensively than regular mail.
2. Generally, most people do not receive unsolicted UPS or FedEx packages. It would be easy to take precautions when you get an unsolicited package, since that in itself is an unusual event.
Yes, you are allowed to fight the possibility of prosecution...by trying to get the legislature to change the law. Getting a law changed because it might affect you is a legislative function, not a judicial function.
This is generally a good thing (seperation of powers). I don't think this case yet meets the high standard necessary for the courts to break down that separation, so the DOJ position does make sense.
That's true in the office and at home, but when you have to carry the device(s) around, carrying one "do everything" device is a lot better than carrying 3 or 4 devices, even if the separate devices do their jobs better than the "do everything" device.
If they did checksumming of parts of the client, the smart way would be to checksum parts of the client in memory, not on disk. These parts could include data that is set up at initialization.
I see The Matrix as being quite similar to Star Wars. In both, the first released movie basically had rebels fighting against a very stong opponent, and achieving a major, but singular victory. In neither was that victory necessarily a crippling blow.
In TM, all the machines need to do is figure out how to stop outside access, and Neo's being The One won't mean anything. His Oneness is only useful when he's in TM. Like SW, what they have really achieved in TM is to create an opening for further action.
This leaves plenty of room for interesting sequels (and prequels). Heck, they could even have the machines figure out how to construct cyborgs, and go in a Terminator direction.
Back in the anon.penet.fi days, I was looking around for a topic for a paper in law school, and briefly considered something related to porn on usenet, so I spent a couple weeks gathering all the porn that came through my newsreader. I saw quite a bit of child porn from anon.penet.fi posters during that time. I don't see how you can see these things weren't proven.
anon.penet.fi was a perfect example of someone doing something because he thought it would be cool, rather than because it served any real purpose. In nearly 20 years of usenet reading, I don't think I've ever seen something come through an anonymous mail to usenet service that was worth reading.
This topic reminded me of an earlier IBM drive that had a problem. Way back in the 80's, when 80 meg was a good sized drive, IBM had a new SCSI drive with the unheard of capacity of 1 gig. I worked for a company that developed firmware for caching disk controllers, and we had one of the earliest of those drives for testing.
When I hooked it up and powered up the system, the drive fried. We got a replacement, and that worked for a while, but when it got moved to another system, it got fried.
We eventually figured out that what was happening was that in the systems these drives were going in, you could not easily see the power connector when the drive was in its bay. That's not normally a problem, because power connectors are keyed. However, the plastic on these connectors was not very rigid. If you tried to put a power connector in wrong, the plastic would simply bend and allow the connection. There was no noticable difference in the force required to put the connector in right and that required to put it in wrong. So, anyone using the "the right way is the one that actually goes in" method of hooking up power had a 50/50 chance of getting it backwards.
Now here's the funny part. We found out from a contact in IBM that IBM was having something like a 20% failure rate on these drives during testing at their plant, because of their own QA people plugging the power in backwards!
From your mailbox's point of view, there is no difference between getting subscribed to a single 1000 message a day list or 100 lists that are only 10 messages a day.
I think that if TiVO can show that they created this idea without knowing about the patent (which doesn't sound hard as it sounds like the "pause" company was sitting on it) that they should be able to get a co-patent (or something) on the idea.
The normal product development process in every technological industry except software includes a search of patents to see if anyone else has already had your idea. Whoever thought of TiVO may have been unaware of this prior work when he or she conceived TiVO, but they almost certainly found out about the patent early in the development process. At the very latest, they would have found it when they were applying for their own patents.
Remember, for most fields, you cannot "sit" on a patent, in the sense of hiding it from people. You can only do so with software patents because they are not well classified.
This is an example of why my proxy notes the browser's user-agent line, and uses that for its prefetching requests.
The article you cite is correct in asserting that web accelerators could cause problems. However, it fails to note that not all have those problems. Some are careful to limit the amount of bandwidth they use for prefetching, and to stop prefetching from pages that the user has left.
Slashdot Mirror
The first word that comes to mind when I see a system with a 134 day uptime is not "stability". The word that comes to mind is "insecure", from the patches you've had to skip to get that uptime.
He's a giant in his field. That means pay attention to the parts where he talks about cryptography. However, it doesn't mean he's got any particular insight into the rest of the issues covered.
He could be like Noam Chomsky, who is a giant in the field of linguistics, but a total goofball in politics, for instance.
USB is fine for syncing. A typical song would take around 4 seconds to transfer over USB. That sucks when you first get the thing and are downloading months worth of rips to it, but is is fine for keeping the device up to date with your new rips.
USB is much faster than most home broadband connections, so the time to fill 5 gig will be much less than the time it took to download the files. :-)
iPod is a good product, but nothing to get excited over.
I'll stay with my RioVolt [thinkgeek.com]. Instead of a hard disk, it uses CD-R or CD-RW, and can play regular audio CDs.
X.0: should be avoided. Keep running your X-1 release.
X.1: good. This is what you upgrade from your X-1 release to.
X.2: good.
They've been this way since 5.0. I don't recall if they followed this pattern with the 4.x releases.
That's completely backwards. When writing an emulation layer (I speak from experience...if you ever ran a System V 286 binary on a System V 386 Unix or an SCO Xenix 286 binary on a Systemv V 386 Unix, you were using the emulation layer Darryl Richman, Carl Hensler, and I wrote when we worked at Interactive), you do not want to use actual code from the OS you are emulating. That code doesn't work like your OS works (if it did...you wouldn't need an emulation layer...you'd just need some argument munging and other trivial stuff).
The hard thing about an emulation layer is finding out just what the thing you are emulating does. An emulation layer has to not just follow the written spec (if there is one), but also has to implement the same bugs as the thing you are emulating, and follow the same choices where there was leeway in the spec, or you might break binary compatibility.
When emulating something that is open source, like Linux, you have the documentation you need: the source code. You read it to find out what the real behaviour is, and then implement that in a way that fits in with the way your OS works. It simple is almost never going to be faster to rip the actual code and try to use it.
When emulating a closed source thing like Windows, however, finding out the actual behaviour you need to emulate (remember...gotta match the actual behaviour, not just what the spec says) can take much experimenting and disassembly. It is much more temping (because it can actually save a lot of time), to rip some DLLs from Windows, and cobble together a framework to run them under your system.
So, just from a "what might developer's do" point of view, it is actually more likely a Windows emulation project would use parts of Windows they should not use than a Linux emulation project would use parts of Linux they should not use.
It is opt-in. When deciding what ISP to use, one of the things you should look at is how they deal with spam. If they use MAPS and you don't want to use MAPS, don't use that ISP.
The big problem with that Gaijin42, is that spam is very cheap to send, and mailing lists are easy to build and exchange.
Run some numbers...say, several thousand companies sending spam to 20 million people each, with a lot of overlap on the mailing lists. Some people would get thousands of emails. This would make email completely unusable for anything other than receiving spam, for many people.
As long as the sender does not pay the cost of email, spam has to be limited.
The copyright holders have always been allowed to stop fair use copying, by contract or by taking technological steps to prevent the copying. Fair use merely prevents them from using section 106 of the Copyright Act to stop copying.
1. They are tracked more extensively than regular mail.
2. Generally, most people do not receive unsolicted UPS or FedEx packages. It would be easy to take precautions when you get an unsolicited package, since that in itself is an unusual event.
This is generally a good thing (seperation of powers). I don't think this case yet meets the high standard necessary for the courts to break down that separation, so the DOJ position does make sense.
Federal law specifically authorizes states to use your SSN for driver's licenses.
That's true in the office and at home, but when you have to carry the device(s) around, carrying one "do everything" device is a lot better than carrying 3 or 4 devices, even if the separate devices do their jobs better than the "do everything" device.
Many laws that oppress minorities increase the freedom and quality of life for the majority of individuals they apply to. Your proposed test sucks.
If they did checksumming of parts of the client, the smart way would be to checksum parts of the client in memory, not on disk. These parts could include data that is set up at initialization.
In TM, all the machines need to do is figure out how to stop outside access, and Neo's being The One won't mean anything. His Oneness is only useful when he's in TM. Like SW, what they have really achieved in TM is to create an opening for further action.
This leaves plenty of room for interesting sequels (and prequels). Heck, they could even have the machines figure out how to construct cyborgs, and go in a Terminator direction.
anon.penet.fi was a perfect example of someone doing something because he thought it would be cool, rather than because it served any real purpose. In nearly 20 years of usenet reading, I don't think I've ever seen something come through an anonymous mail to usenet service that was worth reading.
When I hooked it up and powered up the system, the drive fried. We got a replacement, and that worked for a while, but when it got moved to another system, it got fried.
We eventually figured out that what was happening was that in the systems these drives were going in, you could not easily see the power connector when the drive was in its bay. That's not normally a problem, because power connectors are keyed. However, the plastic on these connectors was not very rigid. If you tried to put a power connector in wrong, the plastic would simply bend and allow the connection. There was no noticable difference in the force required to put the connector in right and that required to put it in wrong. So, anyone using the "the right way is the one that actually goes in" method of hooking up power had a 50/50 chance of getting it backwards.
Now here's the funny part. We found out from a contact in IBM that IBM was having something like a 20% failure rate on these drives during testing at their plant, because of their own QA people plugging the power in backwards!
From your mailbox's point of view, there is no difference between getting subscribed to a single 1000 message a day list or 100 lists that are only 10 messages a day.
By that argument, Frank Sinatra was no good, because he didn't write his material.
The normal product development process in every technological industry except software includes a search of patents to see if anyone else has already had your idea. Whoever thought of TiVO may have been unaware of this prior work when he or she conceived TiVO, but they almost certainly found out about the patent early in the development process. At the very latest, they would have found it when they were applying for their own patents.
Remember, for most fields, you cannot "sit" on a patent, in the sense of hiding it from people. You can only do so with software patents because they are not well classified.
How about leaving the stupid remarks out of the story?
All that should matter is that they do have a problem with it. That's the whole point of rights.
The article you cite is correct in asserting that web accelerators could cause problems. However, it fails to note that not all have those problems. Some are careful to limit the amount of bandwidth they use for prefetching, and to stop prefetching from pages that the user has left.