The thought of them working together makes me cringe.
I disagree. Having the option of a single tool to play both RealPlayer and QuickTime streams sounds like a good idea to me. Finally they'll stop fighting over who gets to be my default viewer for everything from MP3 to RLE to DVD!
Both players have awful user experiences, whether it's Quicktime's violating Apple's UI guidelines and asking you every day if you want to upgrade to Pro, or RealNetworks asking you, just one more time, what your connection speed and email address are, and asking if it's okay to contact you with exciting information.
All in all though, it's easier to herd one cat than two, and just maybe Quicktime will be better implemented in.+n[ui]x environments than it is now.
Someone needs to get a prototype eNose and a prototype iSmell, and chain them together in a recursive loop so both can hone their skills, though the final result might be like in the Matrix:
"But how do you know that that's what Tasty Wheat really tastes like? Maybe it's just what the computers think it tastes like. Maybe that's why so many things taste like Chicken, because they don't know how it's supposed to taste!"
That'd be a trip, a huge multi-user dungeon, mapped to the space in the real world, so you 'meet' those who are playing around you physically, and can talk to them. Heck, who needs a meatworld at all? Oh yeah, you have to have someplace for your charging cradle...
Nope, Moore's law started out as doubling every one year, as quoted 25 years ago in The Mythical Man-Month, and more recently in the Internet.com Webopedia.
It had a PowerPC 601/60Mhz on the motherboard and a 486DX/66Mhz on a Nubus card. It had minimal support for cutting and pasting between environments and you couldn't run them 'picture in picture' but instead used a hot-key combination to switch the monitor card from the Mac to the PC and back. You didn't have to reboot between them, but you couldn't really use them 'simultaneously' either.
It was useful for a niche (Schools actually got a lot of them), but nowadays a G3 with VirtualPC would be significantly faster than the 486DX. Another huge disadvantage was that the two instances couldn't use the same ram. You had to have extra SIMMs on the PC NuBus card (and that was when 16 megs cost $300!)
Speed and memory both seem to follow Moore's law*, but batteries haven't doubled in capacity in a decade, and longer before that, and power consumption has similarly been slow to come down.
These are both things that will be used if they're available. Like processor speed and memory, the raw figures double, but your computing experience isn't 64 times as fast as it was in 1991, even if your modem is.
It'll either be a long time before your laptop will run easily on a battery for a day, or it'll be a breakthrough product/configuration, not a steady improvement.
*Moore's law actually originally said the number of transistors on a chip would double every year. This was stretched to 18 months a decade later to fit the data, then applied to processor speed, price (inverse), and memory, whenever it seemed nifty to do so.
Use a system like VMware, but with just a simple shared windowing system for the 'boot' OS, you could run windows, linux, MacOS, BeOS, and what have you at the same time, without one being a 'dominant' OS.
Of course, the real beauty comes when you can download the instruction set for Playstation, PS2, Dreamcast, TiVo, or any other embedded system you care to and service all your computing needs with one box.
Well, two if you count the handheld version with PalmOS, NewtonOS, LinuxCE, WAPOS, NokiaOS, etc.
Please, please, PLEASE let's not start calling this MP4. As many of you know MP3 isn't MPEG-3. It's MPEG-2, Audio Layer 3, shortened to MP3.
While MP3 probably shouldn't have been named such, let's not exacerbate the mistake by making another one. MPx should relate specifically to the audio compression specification, while MPEG-x should continue to relate to the entire audio/video specification.
Hopefully, when MPEG-4's audio specification catches on in audiophile circles, MP4 will be used specifically to mean audio files adhering to the MPEG-4 Audio Layer specs.
Open-source is more secure in thge long run, but is less secure immediately.
The idea is that security through obscurity is perfect until someone finds the hole, then it's worthless. In contrast, when using an open source solution, the security is inheirently flawed, because there is no obscurity, but as time goes by it gets less and less flawed, as responsible people find and patch holes, to the point where it's a safer bet than the obscure method.
The most effective real-world security may be to combine both, or only use open methods that have been analyzed long enough that they're virtually certain to be secure.
The security of obscure methods is simply harder to quantify, and you don't know when they become worthless.
With so many nations and agencies broadcasting number stations, some of them have to be solely for disinformation purposes.
If these are actual encryptions are using one-time pads as keys, then a brute-force attack (ala distributed.net) would be worthless, unless they're actually using the 'one-time' pads more than once.
What seems more approachable is taking a look at these streams of numbers, looking for the patterns inherient in random number generators. If the method of generating random numbers can be found (which really shouldn't be that hard if the 'disinformation code' is being generated by two guys in a hut and an old PC), then specific stations can be singled out as disinformation stations, sending out 'predictable' random numbers.
Chances are that most of these stations are just that, disinformation beacons.
On the other hand, if they're not, then there must be some header information to identify whether a given broadcast is intended for you (a specific spy) or another agent. This sort of info would likely be the first step of a decryption process, because it would be unlikely that they would force every agent to use up part of a one-time pad at every broadcast just to determine if the broadcast was for them. More likely, there would be some algorithm performed on the header, so an agent can get a reasonably certain idea if the broadcast is meant for them.
My first guess would be something combinitorial, like multiplying the 'agent IDs' of each agent the message applies to, so the agents have only to take the header numbers and see if it's divisable by their number. If so, grab a pen and dig out your one-time pad.
I wonder how many of these sorts of things are already on the net. It makes me want to start a page (that people should mirror, for obfuscation's sake) with random numbers that change every day. Heck, LavaRand is probably doing that right now. Sure they say it's coming from lava lamps, but it could just as easily be messages to spies all over the world, and with 50,000 hits every day, who could trace each one down to find a mobile spy?
Netscape Navigator has actually had a very weak and undocumented version of alpha channels since at least NS 3.0
The way it works is: Take a gif, double its resolution, then overlay a checkerboard pattern of transparent pixels. Then, create a page with that picture, halving the pixel dimensions so it's compressd down by NS. In most version sof NS 3 (And I believe IE3) this will actually create a 50% non-dithered alpha channel, letting the background show through.
You can see an example of this here, but be warned that it doesn't work on all browsers. There should be two copies of the same image. the first, reduced by 50%, the other full size. Note that on NS 4.7 on Linux the first doesn't show up at all. Elsewhere, YMMV.
What we have here is a problem of semantics. Is the language copyrightable (the DTD that is HTML)? No. Patentable, perhaps, that's not what we're talking about.
HTML code that you (or a computer program you command) produce is most certainly copyrightable, just as source code is. The data (content) inside is also copyrightable, but a blanket copyright covers both.
The precedent of copyrighting code was established in a lawsuit between Apple Computer and Franklin Computer in 1983.
Example: If you created a web site using Yahoo's home page as a base, and changed all the words and all the graphics, you would still be liabel for copyright infringement.
How this pertains to this partocular case depends entirely onthe arrangement between you, the advertising agency, and the end client.
You shouldn't care about choosing the noise-pad size to be large enough. You can always split messages across several communications, right?
Right, unless you either care about a delay of more than one transmit-period (eg, day) or that there might be a backlog if you start getting more than your batch size. If this happens, your backlog would just get longer and longer.
I do like the of constant or randomly placed up and download periods, as options, so the user would have a tradeoff of predictability (some would value more predictability, such as needing their daily files by 9am each day, and sending out their batch at 6pm), while others would value the obscurity a randomized schedule would provide.
As far as legality goes, there's also a nice defense in being able to say "The transmission on 9am wasn't anything out of the ordinary. We always transmit a 5 meg file at that time, every day, before we'd ever met Bob" while a randomized schedule might create unfortuante coincidences, "We see that right after your telephone conversation with Bob, you sent off a 5 meg file. Why is that?"
Steady stream may be the way to go, but then again, if you are looking to hide this at all (not that obscurity is useful), a steady stream tends to attract flies more than a periodic burst.
This is a nifty idea, but now that it's on/. it shouldn't be considered secure anymore than stegography is.
If you want a secure way to transmit data from point A to point B without letting anybody know the size, contents, frequency, or destination of the transfer, I would suggest the following:
An intermediary (ZeroKnowledge, or datahaven of your choice) could be set up such that every day as a specific time, it mails you an encrypted file of size n (Say 5 megs) and you mail it an encrypted file of size m (again, say 5 megs). This is automated (with a 'dispatch program' on the client side), and most days the files just encrypt noise.
Now say that you, Alice, want to send a file to your friend, Bob. You encrypt it with Bob's public key, and put it in your dispatch queue (a program supplied by the data haven) along with Bob's identifier.
The next time your dispatch program is supposed to send something out, it looks in the queue, finds Bob's package, appends it with an EOF and enough noise to reach size m (5 megs), encrypts that with the data haven's public key (either a regular key, or preferably a freshly exchanged key), and sends it on to the DH.
Once there, it's decoded, revealing Bob's package, and the address to send it to. This now goes into Bob's inbound queue at the data haven, so the next time Bob's dispatch program connects at it's regular time, the file is gathered with whatever other files Bob has received and is encrypted (with the appended noise, for size constancy) and sent down to Bob's folder, where it is decrypted, and the individual packages are decrypted as well (automatically or as desired).
The keys here are that you:
Send and receive the same size file every day at the same time, whether you have info to send or receive or not, so no patterns can be tracked
Make m and n big enough that you don't need to change them (because bumping up from 5 megs to 10 is a sign that you're using more, and this is a piece of information you don't want known)
This way outsiders can't tell how much data you're actually sending or receiving, who you're sending it to, who you're receiving it from, how frequently you're sending or receiving data, or whether you're actually getting or sending anything at all (you could sign up just to thwart prying eyes, and never send anything through but the default noise file).
Further, if the data haven is compromised at a given point in time, they would have the packages A was sending to B, which were already encrypted with B's key, so not even the data haven knows what's inside. Depending on how the DH is run, you may or may not be able to tell where the package came from (that info could be hidden inside the package before sent), or any history info of transactions (preferably no record be kept, obviously).
Of course, for the paranoid, you can nest data-havens (send to bob@datahaven2@datahaven1, etc) or chain them yourself with ghost users (send to bob@datahaven2@bobsfakeaccount@datahaven1).
Basically, it'll be like the post office: You send out one batch a day (or week, or hour, whatever) and you get one batch back, no more, no less, and data analysis by activity pattern is thwarted, and obscurity doesn't play a breakable part of the data pipeline.
With all due respect, shouldn't the initial post have been considered flamebait too, for making an assertion the other way? If people are going to start advocating their particular world view while discussing the posts here, and someone else replies advocating the opposing argument, who is to decide whose post is "flamebait?"
Not at all. The original post didn't pass judgement on the Christian Coalition, just that violating privacy to give one group information about another group with diametrically opposed views is a Bad Thing.
The example could have been reversed with exactly the same effect. The point is that I needed to provide an example of one group getting information on a second group illegally. Unless I used an example of smurfs and evil wizards, there would be somebody who would place themselves at the sharp end of the stick and call it flamebait.
Now I suppose smurfette will come after me.
As for who makes the 'flamebait' call, it's viewers like you (well, not exactly like you. the ones who register instead of posting anonymously).
If I hacked into a net conversation between two parties and then sold the information to a third, I would be put in jail. If I refused to say how I got the data I wouldn't be let out on bail. If I did it 350,000 times I'd never be free again. When NetPC does it, they get lots of press as a police presence.
NetPD hails itself as a "force for good", but where's the accountability? If the Christian Coalition approached NetPC asking for the names of everyone emailing to abortion clinics, how do we know they won't turn their 10 employees (5000 monkeys) on that job to make their next dime?
Also, without revealing their methods, it seems like there is a real possibility that they're doing packet sniffing, which would be a violation of the law, constituting illegal search, or they're posing as napster clients, letting people download which, while not entrapment, as they're not a law enforcement agency (among other reasons) is just as illegal as the person downloading them.
If they're only supplying dummy files with authentic-looking names, then the people downloading the files aren't breaking the law.
Of course, there are other major problems, such as the fact that they're using Napster-registered names, which are often fake to begin with, and that they have no way of showing that someone doesn't own the CD in the first place, and thus a license to make or obtain a copy.
None of this will have an effect in the long term, as NetPC admits they can't discuss their information gathering methods, because if they were public Napster would be able to block it. Sorry, but such evidence won't hold up in court without demonstrating exactly how it was obtained (for resons of determining authenticity, accuracy, and legality). Once this is done, Napster can block it.
Language is evolutionary. English will be the base, but new words are coming into it every day, creating a custom vocabulary for the web.
Words and concepts like dotcoms, fulfillment houses, privacy policies, tracking numbers, clickthroughs, wishlists, ISPs, DSL, packet loss, winmodem, etc., are either new or have augmented meaning on the net.
Language has always been an evolutionary phenomenon; here we just get to watch it evolve faster. The idea of a new language popping up and being universally accepted is about as likely as everyone switching over to IPv6 on the same day.
So basically you can carry this beastie around and plug it into any video display and compute, but you still need a keyboard (and probably a mouse). So: does anyone make a compact, collapsable keyboard like the ones for the Handspring and Palm?
Odd. It was created by Microsoft to demonstrate the capabilities of SQL Server 6.5, and when it went live three years ago, it was under the microsoft umbrella. I wonder when/if they sold it.
People that defend pornography generally view pornography. At least, that's what I've seen.
This is flawed logic, and highly circular. People who defend porn and view porn, don't go around saying that it's not porn. I view JenniCam, and I view porn, but I don't think that JenniCam is porn any more than life in and of itself is pron. The voyeurism slant doesn't work either, because she's openly letting you into her life.
Also, it's not a 'show' because she is, as much as possible, not changing her normal lifestyle to appease an audience.
Obviously Caimlas doesn't watch Jennicam, because he/she doesn't like porn, and has somehow decided that it is porn, but making judgements on it, and the truthfulness of the people who participate in it in that context, is stupid.
Slashdot Mirror
The thought of them working together makes me cringe.
.+n[ui]x environments than it is now.
I disagree. Having the option of a single tool to play both RealPlayer and QuickTime streams sounds like a good idea to me. Finally they'll stop fighting over who gets to be my default viewer for everything from MP3 to RLE to DVD!
Both players have awful user experiences, whether it's Quicktime's violating Apple's UI guidelines and asking you every day if you want to upgrade to Pro, or RealNetworks asking you, just one more time, what your connection speed and email address are, and asking if it's okay to contact you with exciting information.
All in all though, it's easier to herd one cat than two, and just maybe Quicktime will be better implemented in
Kevin Fox
Kevin Fox
That'd be a trip, a huge multi-user dungeon, mapped to the space in the real world, so you 'meet' those who are playing around you physically, and can talk to them. Heck, who needs a meatworld at all? Oh yeah, you have to have someplace for your charging cradle...
Kevin Fox
64 times as fast a computing experience? At least... using the same software.
That's the whole point. You're not using the same software. At least I'm not.
Now where did I leave that copy of Word 1.1 for Windows...
Kevin Fox
Nope, Moore's law started out as doubling every one year, as quoted 25 years ago in The Mythical Man-Month, and more recently in the Internet.com Webopedia.
Kevin Fox
It was the "PowerMac 6100 Dos Compatible"
It had a PowerPC 601/60Mhz on the motherboard and a 486DX/66Mhz on a Nubus card. It had minimal support for cutting and pasting between environments and you couldn't run them 'picture in picture' but instead used a hot-key combination to switch the monitor card from the Mac to the PC and back. You didn't have to reboot between them, but you couldn't really use them 'simultaneously' either.
It was useful for a niche (Schools actually got a lot of them), but nowadays a G3 with VirtualPC would be significantly faster than the 486DX. Another huge disadvantage was that the two instances couldn't use the same ram. You had to have extra SIMMs on the PC NuBus card (and that was when 16 megs cost $300!)
Kevin Fox
Speed and memory both seem to follow Moore's law*, but batteries haven't doubled in capacity in a decade, and longer before that, and power consumption has similarly been slow to come down.
These are both things that will be used if they're available. Like processor speed and memory, the raw figures double, but your computing experience isn't 64 times as fast as it was in 1991, even if your modem is.
It'll either be a long time before your laptop will run easily on a battery for a day, or it'll be a breakthrough product/configuration, not a steady improvement.
*Moore's law actually originally said the number of transistors on a chip would double every year. This was stretched to 18 months a decade later to fit the data, then applied to processor speed, price (inverse), and memory, whenever it seemed nifty to do so.
Kevin Fox
Use a system like VMware, but with just a simple shared windowing system for the 'boot' OS, you could run windows, linux, MacOS, BeOS, and what have you at the same time, without one being a 'dominant' OS.
Of course, the real beauty comes when you can download the instruction set for Playstation, PS2, Dreamcast, TiVo, or any other embedded system you care to and service all your computing needs with one box.
Well, two if you count the handheld version with PalmOS, NewtonOS, LinuxCE, WAPOS, NokiaOS, etc.
Suddenly the application is the OS...
Kevin Fox
Please, please, PLEASE let's not start calling this MP4. As many of you know MP3 isn't MPEG-3. It's MPEG-2, Audio Layer 3, shortened to MP3.
While MP3 probably shouldn't have been named such, let's not exacerbate the mistake by making another one. MPx should relate specifically to the audio compression specification, while MPEG-x should continue to relate to the entire audio/video specification.
Hopefully, when MPEG-4's audio specification catches on in audiophile circles, MP4 will be used specifically to mean audio files adhering to the MPEG-4 Audio Layer specs.
Kevin Fox
Open-source is more secure in thge long run, but is less secure immediately.
The idea is that security through obscurity is perfect until someone finds the hole, then it's worthless. In contrast, when using an open source solution, the security is inheirently flawed, because there is no obscurity, but as time goes by it gets less and less flawed, as responsible people find and patch holes, to the point where it's a safer bet than the obscure method.
The most effective real-world security may be to combine both, or only use open methods that have been analyzed long enough that they're virtually certain to be secure.
The security of obscure methods is simply harder to quantify, and you don't know when they become worthless.
Kevin Fox
With so many nations and agencies broadcasting number stations, some of them have to be solely for disinformation purposes.
If these are actual encryptions are using one-time pads as keys, then a brute-force attack (ala distributed.net) would be worthless, unless they're actually using the 'one-time' pads more than once.
What seems more approachable is taking a look at these streams of numbers, looking for the patterns inherient in random number generators. If the method of generating random numbers can be found (which really shouldn't be that hard if the 'disinformation code' is being generated by two guys in a hut and an old PC), then specific stations can be singled out as disinformation stations, sending out 'predictable' random numbers.
Chances are that most of these stations are just that, disinformation beacons.
On the other hand, if they're not, then there must be some header information to identify whether a given broadcast is intended for you (a specific spy) or another agent. This sort of info would likely be the first step of a decryption process, because it would be unlikely that they would force every agent to use up part of a one-time pad at every broadcast just to determine if the broadcast was for them. More likely, there would be some algorithm performed on the header, so an agent can get a reasonably certain idea if the broadcast is meant for them.
My first guess would be something combinitorial, like multiplying the 'agent IDs' of each agent the message applies to, so the agents have only to take the header numbers and see if it's divisable by their number. If so, grab a pen and dig out your one-time pad.
I wonder how many of these sorts of things are already on the net. It makes me want to start a page (that people should mirror, for obfuscation's sake) with random numbers that change every day. Heck, LavaRand is probably doing that right now. Sure they say it's coming from lava lamps, but it could just as easily be messages to spies all over the world, and with 50,000 hits every day, who could trace each one down to find a mobile spy?
Kevin Fox
Netscape Navigator has actually had a very weak and undocumented version of alpha channels since at least NS 3.0
The way it works is: Take a gif, double its resolution, then overlay a checkerboard pattern of transparent pixels. Then, create a page with that picture, halving the pixel dimensions so it's compressd down by NS. In most version sof NS 3 (And I believe IE3) this will actually create a 50% non-dithered alpha channel, letting the background show through.
You can see an example of this here, but be warned that it doesn't work on all browsers. There should be two copies of the same image. the first, reduced by 50%, the other full size. Note that on NS 4.7 on Linux the first doesn't show up at all. Elsewhere, YMMV.
Kevin Fox
Oops, sorry. I'm on Napster.
Kevin Fox
HTML code that you (or a computer program you command) produce is most certainly copyrightable, just as source code is. The data (content) inside is also copyrightable, but a blanket copyright covers both.
The precedent of copyrighting code was established in a lawsuit between Apple Computer and Franklin Computer in 1983.
Example: If you created a web site using Yahoo's home page as a base, and changed all the words and all the graphics, you would still be liabel for copyright infringement.
How this pertains to this partocular case depends entirely onthe arrangement between you, the advertising agency, and the end client.
Kevin Fox
Right, unless you either care about a delay of more than one transmit-period (eg, day) or that there might be a backlog if you start getting more than your batch size. If this happens, your backlog would just get longer and longer.
I do like the of constant or randomly placed up and download periods, as options, so the user would have a tradeoff of predictability (some would value more predictability, such as needing their daily files by 9am each day, and sending out their batch at 6pm), while others would value the obscurity a randomized schedule would provide.
As far as legality goes, there's also a nice defense in being able to say "The transmission on 9am wasn't anything out of the ordinary. We always transmit a 5 meg file at that time, every day, before we'd ever met Bob" while a randomized schedule might create unfortuante coincidences, "We see that right after your telephone conversation with Bob, you sent off a 5 meg file. Why is that?"
Steady stream may be the way to go, but then again, if you are looking to hide this at all (not that obscurity is useful), a steady stream tends to attract flies more than a periodic burst.
Kevin Fox
If you want a secure way to transmit data from point A to point B without letting anybody know the size, contents, frequency, or destination of the transfer, I would suggest the following:
An intermediary (ZeroKnowledge, or datahaven of your choice) could be set up such that every day as a specific time, it mails you an encrypted file of size n (Say 5 megs) and you mail it an encrypted file of size m (again, say 5 megs). This is automated (with a 'dispatch program' on the client side), and most days the files just encrypt noise.
Now say that you, Alice, want to send a file to your friend, Bob. You encrypt it with Bob's public key, and put it in your dispatch queue (a program supplied by the data haven) along with Bob's identifier.
The next time your dispatch program is supposed to send something out, it looks in the queue, finds Bob's package, appends it with an EOF and enough noise to reach size m (5 megs), encrypts that with the data haven's public key (either a regular key, or preferably a freshly exchanged key), and sends it on to the DH.
Once there, it's decoded, revealing Bob's package, and the address to send it to. This now goes into Bob's inbound queue at the data haven, so the next time Bob's dispatch program connects at it's regular time, the file is gathered with whatever other files Bob has received and is encrypted (with the appended noise, for size constancy) and sent down to Bob's folder, where it is decrypted, and the individual packages are decrypted as well (automatically or as desired).
The keys here are that you:
This way outsiders can't tell how much data you're actually sending or receiving, who you're sending it to, who you're receiving it from, how frequently you're sending or receiving data, or whether you're actually getting or sending anything at all (you could sign up just to thwart prying eyes, and never send anything through but the default noise file).
Further, if the data haven is compromised at a given point in time, they would have the packages A was sending to B, which were already encrypted with B's key, so not even the data haven knows what's inside. Depending on how the DH is run, you may or may not be able to tell where the package came from (that info could be hidden inside the package before sent), or any history info of transactions (preferably no record be kept, obviously).
Of course, for the paranoid, you can nest data-havens (send to bob@datahaven2@datahaven1, etc) or chain them yourself with ghost users (send to bob@datahaven2@bobsfakeaccount@datahaven1).
Basically, it'll be like the post office: You send out one batch a day (or week, or hour, whatever) and you get one batch back, no more, no less, and data analysis by activity pattern is thwarted, and obscurity doesn't play a breakable part of the data pipeline.
Kevin Fox
Not at all. The original post didn't pass judgement on the Christian Coalition, just that violating privacy to give one group information about another group with diametrically opposed views is a Bad Thing.
The example could have been reversed with exactly the same effect. The point is that I needed to provide an example of one group getting information on a second group illegally. Unless I used an example of smurfs and evil wizards, there would be somebody who would place themselves at the sharp end of the stick and call it flamebait.
Now I suppose smurfette will come after me.
As for who makes the 'flamebait' call, it's viewers like you (well, not exactly like you. the ones who register instead of posting anonymously).
Kevin Fox
NetPD hails itself as a "force for good", but where's the accountability? If the Christian Coalition approached NetPC asking for the names of everyone emailing to abortion clinics, how do we know they won't turn their 10 employees (5000 monkeys) on that job to make their next dime?
Also, without revealing their methods, it seems like there is a real possibility that they're doing packet sniffing, which would be a violation of the law, constituting illegal search, or they're posing as napster clients, letting people download which, while not entrapment, as they're not a law enforcement agency (among other reasons) is just as illegal as the person downloading them.
If they're only supplying dummy files with authentic-looking names, then the people downloading the files aren't breaking the law.
Of course, there are other major problems, such as the fact that they're using Napster-registered names, which are often fake to begin with, and that they have no way of showing that someone doesn't own the CD in the first place, and thus a license to make or obtain a copy.
None of this will have an effect in the long term, as NetPC admits they can't discuss their information gathering methods, because if they were public Napster would be able to block it. Sorry, but such evidence won't hold up in court without demonstrating exactly how it was obtained (for resons of determining authenticity, accuracy, and legality). Once this is done, Napster can block it.
Kevin Fox
Now maybe my GPS-controlled car will stop driving off the side of the road!
Kevin Fox
Language is evolutionary. English will be the base, but new words are coming into it every day, creating a custom vocabulary for the web.
Words and concepts like dotcoms, fulfillment houses, privacy policies, tracking numbers, clickthroughs, wishlists, ISPs, DSL, packet loss, winmodem, etc., are either new or have augmented meaning on the net.
Language has always been an evolutionary phenomenon; here we just get to watch it evolve faster. The idea of a new language popping up and being universally accepted is about as likely as everyone switching over to IPv6 on the same day.
Kevin Fox
So basically you can carry this beastie around and plug it into any video display and compute, but you still need a keyboard (and probably a mouse). So: does anyone make a compact, collapsable keyboard like the ones for the Handspring and Palm?
I recall seeing a minimouse somewhere...
Kevin Fox
Odd. It was created by Microsoft to demonstrate the capabilities of SQL Server 6.5, and when it went live three years ago, it was under the microsoft umbrella. I wonder when/if they sold it.
Kevin Fox
Has nobody noticed that terraserver is owned and operated by Microsoft?
Sounds to me that this is a case of "Show our business practices to the world and we'll show yours!"
Kevin Fox
Now I just need to hook one of these up to my cloud generator and my plans for world domination will be complete!
Kevin Fox
People that defend pornography generally view pornography. At least, that's what I've seen.
This is flawed logic, and highly circular. People who defend porn and view porn, don't go around saying that it's not porn. I view JenniCam, and I view porn, but I don't think that JenniCam is porn any more than life in and of itself is pron. The voyeurism slant doesn't work either, because she's openly letting you into her life.
Also, it's not a 'show' because she is, as much as possible, not changing her normal lifestyle to appease an audience.
Obviously Caimlas doesn't watch Jennicam, because he/she doesn't like porn, and has somehow decided that it is porn, but making judgements on it, and the truthfulness of the people who participate in it in that context, is stupid.
Kevin Fox