Inconclusive. We don't know what's the "Kessel run".
Han could also be using the term incorrectly to test if his passengers are completely ignorant of spaceflight terminolgy. If they are, then he can take advantage of them with "creative" billing that they won't detect.
(Cabdrivers sometimes test if the passenger knows anything about the city layout. If not, then he can intentionally take a longer route for more money)
Phone companies are regulated in what they are and aren't allowed to do with the phone conversations. They can't, for example, monitor your calls for marketing ala Gmail
That's not a regulation- wiretapping or otherwise secretly listening to a phone conversation is a felony in most states.
On the contrary, telco regulation forces the phone company to be able to wiretap you at any time. But normal law prevents them from doing so without judicial approval.
I can imagine a future VoIP company wanting to advertise an encrypted service that's "so secure, even WE can't listen in on you!". But that would be apparently against regulations. This is a danger of treating VoIP companies like telcos: it starts down the path towards outlawing the use of encryption.
Ha! Don't kid yourself, it's about the money (taxes)...
Money is part of it. But probably more important is control. Specifically, wiretapping. Phone companies are required to keep equipment ready so that any cop who shows up with a warrant can listen in on anyone's calls.
To serve and protect their customers, Vonage might add end-to-end encryption to their product, making wiretapping impossible. The government has to act fast and declare them a telco before wiretapping becomes impossible.
Sure there is. It adds detail, and makes the speaker more credible, because it proves that the topic is actually something he cares heavily about. Demonstrating passion is a way to quickly prove that although your beliefs might not be perfectly correct, you've at least spent a lot of time and effort researching them, and are thus an informed source.
And from another perspective: show that he is still antagonistic to Linus's system gives him even more credibility. If a friend vouches for you, that might be discounted as a buddy covering for you- but if an enemy says you're innocent, then he's got no motivation to lie on your behalf.
(This reminds me in a roundabout way of Iraq today: the US Army "raiding" Chalabadi's headquarters, and he's publically "upset" about it. But they could've really been trying to help him gain power in Iraq, because the common people won't trust a leader who's too friendly to the USA. An OT example of how people can be easier to categorize by counting their enemies rather than their supporters)
remove himself from the political aspect and just enjoy the work. Think Einstein and the atomic bomb.
That's completely backwards. Regarding the atom bomb, Einstein wasn't "an engineer" at all. He had no technical input to the Manhattan Project- he wasn't even on the site.
The only way Einstein helped make the bomb was by suggesting to President Roosevelt that the project should be started at all. His role was much closer to a philosopher or politician, and not an engineer (that was Oppenheimer)
sites providing binaries of prereleases could be technically in trouble there
The safest way to avoid the trouble is to make it easily possible to get the source code alongside the binary. So just extend whatever scripts run the compile process to also build a tar.gz of the code used, and put it on the same webserver. If the users had the ability to get the source with the binary, your obligation is fulfilled.
If you don't do that, then you need to be able to fulfill requests in the form of "I want the source code for version 5.4.33 from 2004/3/6". If you have a CVS server, then it's pretty easy to respond to this (with a few caveats). If that CVS server is non-public, then developers will occasionally face the irritation of answering those source code requests manually, rather than just pointing to the available repository.
However, I have seen a real project get hurt because they didn't provide exact source code corresponding to their binaries. The damage in that case wasn't legal, it was technical- no users could submit correct bug reports or patches because they had no idea if what they were running had any similarity to the current code.
Did you even read the definition you linked to? Apparently not, so I'll paste it here: "A collection of data..." "...sets of persistent data..." According to that page, "databases" aren't programs at all- they're only the files (data) that the software handles. So by that definition, even Oracle isn't a database (although it handles them)
For crying out load, my blog is a database!
The word "is" isn't equivalent to "has". By claiming your blog "is a database", you are saying that it is just a pile of data, and has no functional features.
Or alternatively, you have defined the word in such a generic way that all software is a database, which robs "database" of any informational content.
Or how about this: Would you say your blog "is an operating system?" After all, it's a "system" of some kind, and it "operates"...
The obvious suggestion, of course, is to get it pre-compiled from Fink. They apparently are on an older 1.11 version, but I'd imagine they'll try to backport security fixes quickly... maybe.
The 2nd obvious suggestions is to point out that even regardless of this particular vulnerability, you should never run cvs:pserver on the internet. Instead run cvs:ext over ssh. That won't necessarily stop authorized users from escalating their privs (although for this exploit it does), but should totally protect you from "cold calling" attacks.
As for those specific error messages- I don't have a Mac with me here, but I've noticed before that the OS X setup of standard libraries is different from what BSD (and Linux and other Unix) normally use. They don't have the same library files much source code assumes it can find, so the Apple-provided compiler makes some secret substitutions to allow software to build. But that's guesswork, and it can sometimes guess wrong, producing inscrutable situations until you sit down with "nm" and "ld" to work out exactly what's happening. (Probably more trouble than it's worth)
There are much better options; CVSup and rsyncing tarballs are probably the best.
They certainly aren't! Well, CVSup is OK (although most of it's advantages over straight CVS are just implementation details, which could be added to CVS is someone cared enough)
But rsyncing tarballs is just horrible. It's not powerful at all- it can only supply access to the very latest version of the files, while interested power-users may validly desire older or tagged revisions.
That's bad in general, but there's also a specific legal limitation to it: If the source code is GPL, and the project releases precompiled executables, then they are obliged to provide the exact source code version used for that executable. This is trivially accomplished with CVS, but rsync alone is inadequate.
Seriously, your solution to the problem makes the source closed to the world and only open to input from 'trusted' people. Managing the list of trusted people would be a huge job on a large project where a million code monkeys are contributing.
Oh my! Here's another poster with no idea how OSS actually works.
Guess what: there really IS a small list of trusted people, and somebody works manage which of the million possible helpers deserves to
Handling "millions" is actually a simple problem for a computer programmer. Any good coder is familiar with binary tree division, which allows you to handle lists of any size with just a few (max ~7) layers of hierarchal control.
If you want to restrict contributions to people you really trust then don't put your CVS repository on a public server.
Try this: go over to sourceforge.net, pick a random project, and add a file into the CVS tree. Good luck, you'll need it. The only way you can contribute is to convince a live human project-member that your code is worthwhile.
It seems that you are writing entirely from your imagination. Either you don't know how real OSS projects work, or you misread the parent post to think it suggested a drastic change to development methods.
because the whole idea of the "bazaar model" is to allow anyone to contribute
Almost no Open Source developer allows relative strangers write-access to a CVS repository. In reality, "bazaar" development allows anyone to create changes, but it's still up to the original author (or her trusted friends, or a declared maintainer) to actually add them to the codebase. (If they refuse, then somebody can decide to fork a new project containing the desired change)
Observe how Linux works: millions of people can create changes, which they can send to one of 20 people for possible inclusion. If approved, then the patch is sent onward to the single person maintaining that kernel release (Linus, Marcello, or someone like that).
That's why it has been broadly noted that CVS is sub-optimal for managing large Free/Open projects. The one master server is too much of a bottleneck/vulnerability. Competitors like BitKeeper have arisen to try making the management of source code as distributed as writing it.
(Amusingly, BitKeeper supports OSS style development but is not itself open source)
Since the program itself has been hijacked, it bypasses exactly the sort of second-level protection you suggest.
But CVS and Subversion have no need to write to a "system" file, so this protection can work fine. And indeed, every serious CVS server admin has done something like this.
(Much more important, of course, is that CVS- or any important server- be run behind a separate, simpler server handling authentication. Usually ssh)
However, much research has shown that sandboxes themselves can be vulnerable, incomplete (think race conditions), and so on.
I don't really believe that- if the sanbox boundaries are sufficiently simple, verification is managable- but it's irrelevant anyway.
A CVS server will normally only have write permission to the files making up the source code repository. A correct sandbox would give no more protection than simple file ownership (which still allows exploits if a buffer overflow occurs- if a user could insert malicious code into the source without producing the normal check-in message, she can do much mischief to all the other developers)
Hasn't been true for a long time. Now CVS reads/writes directly, with no RCS process active. But even if that were still the case, saying "CVS is a database" is like "airplanes are wings".
I'd personally like to thank the retard editor who let this spoiler go.
That's no spoiler.
If you paid attention during Empire Strikes Back, it should've been apparent that this movie will feature a lightsabre fight which ends with Anakin dangling from one arm over a pit of lava/acid/boiling chocolate until Obi-wan ignores a cry for mercy and cuts him off at the wrist.
I think B&Bs' one saving grace this season is that they're trying to make Star Trek "fresh" again.
The most surefire way to do that would be to actually allow a gap, and not fight to have new Star Trek come out every single year. After an abscense, the same old ideas seem "fresher" (and with no more effort from the producers)
throwing away the entire known history of the UFP and building it from scratch, distancing themselves as much as possible from the "known" Star Trek universe.
The details of the backdrop aren't so important. What matters is the fact that they still have a government-sponsored spaceship filled with humans and 1-2 token aliens that randomly wanders into one dangerous encounter after another.
Creating a new bunch of names for the props and makeup is a fairly minor change. (And they're not even really going to do that. They've already forgone the chance to have a ship that is unequipped with Transporters and Phasers)
furthermore, it's trivial to defeat such attacks completely by inserting a meaningless random element.
No. If your cipher is good, then you don't need to add random junk to prevent known plaintext analysis- and if it's bad, then the random element won't protect you.
(All the random effect can do is shift the position of the known plaintext within the encrypted message. This will at most increase the effort to brute-force by a factor of message length, so you can do better by choosing a superior cipher. If the randomness does something more, then it has become effectively an extension to the cipher algorithm)
Not nearly as easily as now, since it requires cooperation from the DNS server.
No, that has no effect. If my worm roots your box, then the DNS server will claim that the new emails being sent have the same source as the old ones.
This is a way, it seems, to help prevent spoofed header information in spam. I'm certainly glad that right is not infringed, thanks Slashdot.
If a technology prevents you from omitting, obfuscating, or falsifying your return address, it has reduced your ability to communicate anonymously. Some people consider that a right to be defended.
(I'm not saying that the threat is necessarily grave or even real- but discussing it here is not off-topic)
You seem to have no idea what "commoditize" means. By definition, MS's products are non-commodities, because only one entity supplies them to the market. With commodities, the large number of sellers means none of them has power to choose prices.
In a non-commodity market, raising the price you charge a small amount will cause a small reduction in sales, which could either increase or decrease net revenue. But if you're selling a commodity, then a small price increase will cause a large (or even total) drop in sales (think about what you'd do if one fuel station is $0.1 more than the others).
Linux distros are actual commodities, and that poses revenue problems for the companies that work on them. SUSE Linux, for example, is available not only from Novell, but also from any random guy who declares himself a "Linux Support Contractor". So the Linux distro itself can only ever have a low price- the corporations' sales depend on the perception that they bundle superior additional services.
Please note that your argument about the variety of possible distros does somewhat support the idea that Linux is not a commodity- but each particular Linux distro is a commodity of it's own kind.
but it's a near certainty that if you do what this guy's doing you're in breach of contract, and his service provider would be quite within their rights to terminate his connection, or worse.
So what? Common carrier means you provide communication to others without discriminating based on message content. Whether you were allowed to share that bandwidth or not is a whole other issue...
Or would you say that if some financial fraud or contract dispute with another ISP showed up at Comcast, then suddenly they wouldn't be a common carrier either?
Did you even watch the show? The station DS9 was not really located within sight of Bajor, let alone orbiting it. It was a deep space station, after all.
Nope. According to the show, it was originally built (by cardassians) to orbit planet Bajor, and transport between the surface and other systems was the main function.
Later on, the federation moved it from the planet to the wormhole. However, it was still inside that star-system, and thus not really "Deep Space". (The Federation apparently considered Bajor far enough from their territory that the whole system was "deep space", because they gave it that name while the station was still at the planet)
Of course, the producers were never really sensible with interplanetary distances, so everything fluctuated as needed by any particular episode.
True, I didn't have enough pain tolerance to watch it closely (I saw all of the 1st 3 episodes, though)
The entire last 3 seasons were tightly tied in the Dominion War story arc, with only occasional episodes stepping directly outside of that arc for plot
However, when I heard DS9 was going off the air, I did begin tuning in again. And I found that its Dominion War section was only slightly more continuous than TNG had been in the Borg War or Cardassian War sequences.
For the specific test of continuity, look for enforced ordering between episodes. Find pairs of episodes and see if they could be swapped in order without introducing a "temporal anonmaly". Even in the last season, most of episodes could be shuffled freely. And each prior season, there were usually just 2-3 "gateway" episodes that mark a transition from one phase to another:
"Now the Dominion is fighting us, and my camping trip is ruined!"
"Doh, you're not slimey anymore" "That fireball-throwing Cardassian has made me 15 years younger, but I'll still be here with you guys, even though re-association is completely against the rules" "Ooh, Voyager came out. So I'll talk like a Vulcan from now on!" "Ooh, A movie is out. New lame costumes for everybody!"
The last 3 seasons were overall only connected insofar as they had a different backdrop than the first 4.
I suppose there's actually a simpler check for continuity: When an episode starts, do you hear a narrator say "Previously on..."?
That happened almost 100 times on B5, but less than 20 times on DS9 (the longer series!)
It's not even like the show and it's characters were trapped on the station
The show was designed so that the Wormhole could bring the cast to a new planet each week, while still keeping the orbital station.
It basically succeeded at that function- but it's too bad they had to resort to that scheme at all. If the series had been MORE about Bajoran+Federation+Cardassian+Dominion relationships in that one system, and LESS about "new alien or subspace phenomena each week", it could've been great. But instead, they basically kept to the same zero-continuity pattern established in previous Trek.
Sometimes, those sorts of stories can be best told when you have people coming to you, rather than the other way around.
Worked for B5. Too bad DS9 couldn't have been a more accurate copy.
Slashdot Mirror
Inconclusive. We don't know what's the "Kessel run".
Han could also be using the term incorrectly to test if his passengers are completely ignorant of spaceflight terminolgy. If they are, then he can take advantage of them with "creative" billing that they won't detect.
(Cabdrivers sometimes test if the passenger knows anything about the city layout. If not, then he can intentionally take a longer route for more money)
Phone companies are regulated in what they are and aren't allowed to do with the phone conversations. They can't, for example, monitor your calls for marketing ala Gmail
That's not a regulation- wiretapping or otherwise secretly listening to a phone conversation is a felony in most states.
On the contrary, telco regulation forces the phone company to be able to wiretap you at any time. But normal law prevents them from doing so without judicial approval.
I can imagine a future VoIP company wanting to advertise an encrypted service that's "so secure, even WE can't listen in on you!". But that would be apparently against regulations. This is a danger of treating VoIP companies like telcos: it starts down the path towards outlawing the use of encryption.
Ha! Don't kid yourself, it's about the money (taxes)...
Money is part of it. But probably more important is control. Specifically, wiretapping. Phone companies are required to keep equipment ready so that any cop who shows up with a warrant can listen in on anyone's calls.
To serve and protect their customers, Vonage might add end-to-end encryption to their product, making wiretapping impossible. The government has to act fast and declare them a telco before wiretapping becomes impossible.
Theres just no need for that second clause.
Sure there is. It adds detail, and makes the speaker more credible, because it proves that the topic is actually something he cares heavily about. Demonstrating passion is a way to quickly prove that although your beliefs might not be perfectly correct, you've at least spent a lot of time and effort researching them, and are thus an informed source.
And from another perspective: show that he is still antagonistic to Linus's system gives him even more credibility. If a friend vouches for you, that might be discounted as a buddy covering for you- but if an enemy says you're innocent, then he's got no motivation to lie on your behalf.
(This reminds me in a roundabout way of Iraq today: the US Army "raiding" Chalabadi's headquarters, and he's publically "upset" about it. But they could've really been trying to help him gain power in Iraq, because the common people won't trust a leader who's too friendly to the USA. An OT example of how people can be easier to categorize by counting their enemies rather than their supporters)
remove himself from the political aspect and just enjoy the work. Think Einstein and the atomic bomb.
That's completely backwards. Regarding the atom bomb, Einstein wasn't "an engineer" at all. He had no technical input to the Manhattan Project- he wasn't even on the site.
The only way Einstein helped make the bomb was by suggesting to President Roosevelt that the project should be started at all. His role was much closer to a philosopher or politician, and not an engineer (that was Oppenheimer)
sites providing binaries of prereleases could be technically in trouble there
The safest way to avoid the trouble is to make it easily possible to get the source code alongside the binary. So just extend whatever scripts run the compile process to also build a tar.gz of the code used, and put it on the same webserver. If the users had the ability to get the source with the binary, your obligation is fulfilled.
If you don't do that, then you need to be able to fulfill requests in the form of "I want the source code for version 5.4.33 from 2004/3/6". If you have a CVS server, then it's pretty easy to respond to this (with a few caveats). If that CVS server is non-public, then developers will occasionally face the irritation of answering those source code requests manually, rather than just pointing to the available repository.
However, I have seen a real project get hurt because they didn't provide exact source code corresponding to their binaries. The damage in that case wasn't legal, it was technical- no users could submit correct bug reports or patches because they had no idea if what they were running had any similarity to the current code.
Database
Did you even read the definition you linked to? Apparently not, so I'll paste it here: "A collection of data..." "...sets of persistent
data..." According to that page, "databases" aren't programs at all- they're only the files (data) that the software handles. So by that definition, even Oracle isn't a database (although it handles them)
For crying out load, my blog is a database!
The word "is" isn't equivalent to "has". By claiming your blog "is a database", you are saying that it is just a pile of data, and has no functional features.
Or alternatively, you have defined the word in such a generic way that all software is a database, which robs "database" of any informational content.
Or how about this: Would you say your blog "is an operating system?" After all, it's a "system" of some kind, and it "operates"...
Any ideas?
:pserver on the internet. Instead run cvs :ext over ssh. That won't necessarily stop authorized users from escalating their privs (although for this exploit it does), but should totally protect you from "cold calling" attacks.
The obvious suggestion, of course, is to get it pre-compiled from Fink. They apparently are on an older 1.11 version, but I'd imagine they'll try to backport security fixes quickly... maybe.
The 2nd obvious suggestions is to point out that even regardless of this particular vulnerability, you should never run cvs
As for those specific error messages- I don't have a Mac with me here, but I've noticed before that the OS X setup of standard libraries is different from what BSD (and Linux and other Unix) normally use. They don't have the same library files much source code assumes it can find, so the Apple-provided compiler makes some secret substitutions to allow software to build. But that's guesswork, and it can sometimes guess wrong, producing inscrutable situations until you sit down with "nm" and "ld" to work out exactly what's happening. (Probably more trouble than it's worth)
There are much better options; CVSup and rsyncing tarballs are probably the best.
They certainly aren't! Well, CVSup is OK (although most of it's advantages over straight CVS are just implementation details, which could be added to CVS is someone cared enough)
But rsyncing tarballs is just horrible. It's not powerful at all- it can only supply access to the very latest version of the files, while interested power-users may validly desire older or tagged revisions.
That's bad in general, but there's also a specific legal limitation to it: If the source code is GPL, and the project releases precompiled executables, then they are obliged to provide the exact source code version used for that executable. This is trivially accomplished with CVS, but rsync alone is inadequate.
Seriously, your solution to the problem makes the source closed to the world and only open to input from 'trusted' people. Managing the list of trusted people would be a huge job on a large project where a million code monkeys are contributing.
Oh my! Here's another poster with no idea how OSS actually works.
Guess what: there really IS a small list of trusted people, and somebody works manage which of the million possible helpers deserves to
Handling "millions" is actually a simple problem for a computer programmer. Any good coder is familiar with binary tree division, which allows you to handle lists of any size with just a few (max ~7) layers of hierarchal control.
If you want to restrict contributions to people you really trust then don't put your CVS repository on a public server.
Try this: go over to sourceforge.net, pick a random project, and add a file into the CVS tree. Good luck, you'll need it. The only way you can contribute is to convince a live human project-member that your code is worthwhile.
It seems that you are writing entirely from your imagination. Either you don't know how real OSS projects work, or you misread the parent post to think it suggested a drastic change to development methods.
because the whole idea of the "bazaar model" is to allow anyone to contribute
Almost no Open Source developer allows relative strangers write-access to a CVS repository. In reality, "bazaar" development allows anyone to create changes, but it's still up to the original author (or her trusted friends, or a declared maintainer) to actually add them to the codebase. (If they refuse, then somebody can decide to fork a new project containing the desired change)
Observe how Linux works: millions of people can create changes, which they can send to one of 20 people for possible inclusion. If approved, then the patch is sent onward to the single person maintaining that kernel release (Linus, Marcello, or someone like that).
That's why it has been broadly noted that CVS is sub-optimal for managing large Free/Open projects. The one master server is too much of a bottleneck/vulnerability. Competitors like BitKeeper have arisen to try making the management of source code as distributed as writing it.
(Amusingly, BitKeeper supports OSS style development but is not itself open source)
Since the program itself has been hijacked, it bypasses exactly the sort of second-level protection you suggest.
But CVS and Subversion have no need to write to a "system" file, so this protection can work fine. And indeed, every serious CVS server admin has done something like this.
(Much more important, of course, is that CVS- or any important server- be run behind a separate, simpler server handling authentication. Usually ssh)
However, much research has shown that sandboxes themselves can be vulnerable, incomplete (think race conditions), and so on.
I don't really believe that- if the sanbox boundaries are sufficiently simple, verification is managable- but it's irrelevant anyway.
A CVS server will normally only have write permission to the files making up the source code repository. A correct sandbox would give no more protection than simple file ownership (which still allows exploits if a buffer overflow occurs- if a user could insert malicious code into the source without producing the normal check-in message, she can do much mischief to all the other developers)
CVS uses RCS as a back-end store.
Hasn't been true for a long time. Now CVS reads/writes directly, with no RCS process active. But even if that were still the case, saying "CVS is a database" is like "airplanes are wings".
In the current climate, it is just plain foolish to use a language without bounds checking in a security critical capacity.
Ironically, CVS was originally a Perl program until a C version was needed to make it real software.
Any movie that can be ruined in any way by a spoiler isn't a very good movie in the first place.
Psst... Darth Vader is Luke's father!
(Seriously, Sixth Sense was spoiled for me when someone mentioned that Bruce Willis was actually a robot)
I'd personally like to thank the retard editor who let this spoiler go.
That's no spoiler.
If you paid attention during Empire Strikes Back, it should've been apparent that this movie will feature a lightsabre fight which ends with Anakin dangling from one arm over a pit of lava/acid/boiling chocolate until Obi-wan ignores a cry for mercy and cuts him off at the wrist.
1) It will feed the hungry if money spent on licences go charity/ social support.
Windows(r) feeds the hungry! The money Bill Gates takes from your licenses goes to charity/social support.
I think B&Bs' one saving grace this season is that they're trying to make Star Trek "fresh" again.
The most surefire way to do that would be to actually allow a gap, and not fight to have new Star Trek come out every single year. After an abscense, the same old ideas seem "fresher" (and with no more effort from the producers)
throwing away the entire known history of the UFP and building it from scratch, distancing themselves as much as possible from the "known" Star Trek universe.
The details of the backdrop aren't so important. What matters is the fact that they still have a government-sponsored spaceship filled with humans and 1-2 token aliens that randomly wanders into one dangerous encounter after another.
Creating a new bunch of names for the props and makeup is a fairly minor change. (And they're not even really going to do that. They've already forgone the chance to have a ship that is unequipped with Transporters and Phasers)
furthermore, it's trivial to defeat such attacks completely by inserting a meaningless random element.
No. If your cipher is good, then you don't need to add random junk to prevent known plaintext analysis- and if it's bad, then the random element won't protect you.
(All the random effect can do is shift the position of the known plaintext within the encrypted message. This will at most increase the effort to brute-force by a factor of message length, so you can do better by choosing a superior cipher. If the randomness does something more, then it has become effectively an extension to the cipher algorithm)
Not nearly as easily as now, since it requires cooperation from the DNS server.
No, that has no effect. If my worm roots your box, then the DNS server will claim that the new emails being sent have the same source as the old ones.
This is a way, it seems, to help prevent spoofed header information in spam. I'm certainly glad that right is not infringed, thanks Slashdot.
If a technology prevents you from omitting, obfuscating, or falsifying your return address, it has reduced your ability to communicate anonymously. Some people consider that a right to be defended.
(I'm not saying that the threat is necessarily grave or even real- but discussing it here is not off-topic)
MS has a commoditized product,
You seem to have no idea what "commoditize" means. By definition, MS's products are non-commodities, because only one entity supplies them to the market. With commodities, the large number of sellers means none of them has power to choose prices.
In a non-commodity market, raising the price you charge a small amount will cause a small reduction in sales, which could either increase or decrease net revenue. But if you're selling a commodity, then a small price increase will cause a large (or even total) drop in sales (think about what you'd do if one fuel station is $0.1 more than the others).
Linux distros are actual commodities, and that poses revenue problems for the companies that work on them. SUSE Linux, for example, is available not only from Novell, but also from any random guy who declares himself a "Linux Support Contractor". So the Linux distro itself can only ever have a low price- the corporations' sales depend on the perception that they bundle superior additional services.
Please note that your argument about the variety of possible distros does somewhat support the idea that Linux is not a commodity- but each particular Linux distro is a commodity of it's own kind.
but it's a near certainty that if you do what this guy's doing you're in breach of contract, and his service provider would be quite within their rights to terminate his connection, or worse.
So what? Common carrier means you provide communication to others without discriminating based on message content. Whether you were allowed to share that bandwidth or not is a whole other issue...
Or would you say that if some financial fraud or contract dispute with another ISP showed up at Comcast, then suddenly they wouldn't be a common carrier either?
Did you even watch the show? The station DS9 was not really located within sight of Bajor, let alone orbiting it. It was a deep space station, after all.
Nope. According to the show, it was originally built (by cardassians) to orbit planet Bajor, and transport between the surface and other systems was the main function.
Later on, the federation moved it from the planet to the wormhole. However, it was still inside that star-system, and thus not really "Deep Space". (The Federation apparently considered Bajor far enough from their territory that the whole system was "deep space", because they gave it that name while the station was still at the planet)
Of course, the producers were never really sensible with interplanetary distances, so everything fluctuated as needed by any particular episode.
True, I didn't have enough pain tolerance to watch it closely (I saw all of the 1st 3 episodes, though)
The entire last 3 seasons were tightly tied in the Dominion War story arc, with only occasional episodes stepping directly outside of that arc for plot
However, when I heard DS9 was going off the air, I did begin tuning in again. And I found that its Dominion War section was only slightly more continuous than TNG had been in the Borg War or Cardassian War sequences.
For the specific test of continuity, look for enforced ordering between episodes. Find pairs of episodes and see if they could be swapped in order without introducing a "temporal anonmaly". Even in the last season, most of episodes could be shuffled freely. And each prior season, there were usually just 2-3 "gateway" episodes that mark a transition from one phase to another:
"Doh, you're not slimey anymore"
"That fireball-throwing Cardassian has made me 15 years younger, but I'll still be here with you guys, even though re-association is completely against the rules"
"Ooh, Voyager came out. So I'll talk like a Vulcan from now on!"
"Ooh, A movie is out. New lame costumes for everybody!"
The last 3 seasons were overall only connected insofar as they had a different backdrop than the first 4.
I suppose there's actually a simpler check for continuity: When an episode starts, do you hear a narrator say "Previously on..."?
That happened almost 100 times on B5, but less than 20 times on DS9 (the longer series!)
It's not even like the show and it's characters were trapped on the station
The show was designed so that the Wormhole could bring the cast to a new planet each week, while still keeping the orbital station.
It basically succeeded at that function- but it's too bad they had to resort to that scheme at all. If the series had been MORE about Bajoran+Federation+Cardassian+Dominion relationships in that one system, and LESS about "new alien or subspace phenomena each week", it could've been great. But instead, they basically kept to the same zero-continuity pattern established in previous Trek.
Sometimes, those sorts of stories can be best told when you have people coming to you, rather than the other way around.
Worked for B5. Too bad DS9 couldn't have been a more accurate copy.