I have to disagree with you here. I use inst & co. quite a lot (I admin a number of irix machines) and have very little good to say about it. It's may be a bit better than some others, but compared to apt/dpkg *or* rpm it's woefully inadequate. It's always a relief, after installing an irix box and weeding out the hundreds of unecessary fluf packages in the default install, to go back to one of my debian machines.
Version dependancies, for example, can be extremely confusing. If you have the wrong version of some eoe.* package for a package you want to install, it can be very difficult to parse the version info and jump through the necessary hoops to get what you want in place.
My biggest problem with inst, though, is that there is no effective way to deal with large numbers of packages. Sure, there are various keywords you can use, and they help, but they're basicaly a hack. Going through an extensive list (e.g., the freeware distribution, or even worse, the default install) and trying to prune out the stuff you don't want and/or put in the stuff you do want can be extremely unpleasant. I generaly find I have to make a large list, on paper, of the often literaly hundreds of package additions/removals, then use inst to implement them.
You may want to check out stow. It's not exactly what you're talking about, but does allow you to have the traditional etc, bin, lib, etc., and a mutt directory with everything mutt-related at the same time.
The recent ssh vulnerability is a good example of why this is wrong. The encryption methods can be entirely open (hell, they can be secure, even) but the app can still end up being vulnerable because it leaks some piece of information that the programmer didn't realize was sensitive -- like the timing between key presses.
The Cluetrain manifesto was talking about individual to individual communication. Talking to the press is centralized to begin with, since the press itself is centralized. The great thing about communication with peers is that it goes both ways and it's always possible to straighten things out if there's misscomunication (which there will be).
With the press that's not possible -- not in any meaningful way, anyway. So sure, have your engineers talk to their engineers, but don't go blabbing to the press because then it's too likely to get out of control.
PS1 is the left-side prompt for normal commands, PS2 is for inside things like for & while loops. RPS1 is the right-side prompt for normal commands. All prompts are bold. PS1 is the machine name, the exit status (if non-zero) and then '#' if uid=0. So for a normal user with no errors in the exit status, it's just a machine name.
PS2 lists the blocks I'm in (e.g., "for then" if I'm inside of an if block inside a for block). Then, if root, '#'.
RPS1 is the tilde-encoded directory (e.g., '~' for home dir) followed by a ':', followed by the time.
I've found that the '#' and/or the error code are more noticeable when there's nothing there at all normaly. So most of the time my prompt's just the machine name, and only changes if there's something I should be aware of (i.e., I have root or a command failed).
Even better, though, is that I have "user@host:/dir" in my xterm (well, aterm, actualy) title bar:
precmd () {print -Pn "\e]0;%n@%m:%~\a"}
Great when I have a bunch of shells open and I'm looking through a menu for a particular shell session.
> So the LSB folks put together a set of minimum requirements for a Linux distribution, and quite frankly, my guess is that they are too minimum to really be of any use.
Can you be specific here? Maybe I'm not understanding something, but if software package foo depends on lib baz, the lsb rpm for foo should depend on baz. Simple.
LSB doesn't need to include every lib anybody will want when writing software, it only needs to include the realy basic stuff every distro has, so that distros can be standard about it. But if a package needs extra functionality, that's what package manager dependancies are there for. Does that mean LSB should be pared down to the most minimalist possible set of system requirements? No, that's not practical. The requirements need to reflect reality, and most systems just aren't that minimal.
Personaly, I'm very impressed with the LSB. Especialy the naming conventions for rpms. My guess is that that could go a long way toward giving rpms some of the same reliability and dependability that debian users are used to with debs.
You don't sound like a troll, so I'll assume you're talking about yourself & not the original.
Sure, the things Katz is pointing out are straightforward results of economics and not some evil conspiracy by "big media". But unless you're a hopeless Randian that doesn't make them good. Maybe Katz is anthropomorphising too much, but that doesn't make the issues any less important.
Ask yourself a few simple questions:
Does control of the media by a few huge corporations have a "lowest common denominator" effect on the content that's produced?
What sort of effect does this have on people, most of whom may be quite capable of thinking criticaly but don't unless goaded?
Do you want to live in a world where most people (even if not yourself) don't think or worry about anything that hasn't first been fed to them by large corporations?
For myself, the trend Katz is talking about is very worrysome. Sure, it's nothing new, but I think there's a chance we can use the net to break the cycle that's been going on for the past 50 years. So I think it's worth it to try to understand why it's going on and how we might be able to change it.
One thing worth noting is that they're not talking about what most people mean when they say "stem cell," i.e., totipotent cells.
Totipotent cells can become any type of tissue found in the human body. They're the cells found in embryos & (female) reproductive tissues.
Pluripotent cells are much more common, found in bone marrow and (I believe) other places as well. They can become some types of tissues, but not others.
The article's fascinating, but in the end I don't think I buy it. He measures voting power by the chance that your vote will turn the election. Which I see no real problem with untill you bring districts (i.e., the electoral college) into it.
There, part of what determines whether or not your vote turns the election isn't your vote, it's *where* you vote. So to say that using districts increases the power of individual votes is disingenuous at best.
It simply takes the (pseudo) random factor of the votes themselves and creates a new random factor of how the votes are aportioned into districts. It doesn't give voters more power; it just throws a new element of chance into the race.
But the fact that most states follow a winner-take all system directly reverses this. Small states may have more delegates per individual, but large states are likely to have more delegates per majority-voting individual. Since it votes as a block, a large state has comparatively more power.
Anyone know where to find info on how various states allocate delegates?
It's not a stupid question at all -- it's a very good one.
I don't know exactly what ICANN's official duties are, but my understanding is that they're quite limited, in the grand scheme of things. Sure, there's the issue of domain name squating, dispute resolution policies, etc., which are quite important. But if that were all I wouldn't be too concerned about it.
The problem is this: ICANN is "the internet governing body" to the press. There are a lot of global issues re: the net that need to be resolved, and, assuming the US doesn't decide it's Supreme Ruler of the World, there isn't a clear place to go to get answers to these questions. (Not that I mean to imply that the US is a clear place to go for answers -- far from it.)
So you tell me what happens when there are issues to be resolved, no one around to resolve them, and a bunch of bozos in the press talking about ICANN as "the internet governing body"?
I'll tell you: ICANN makes a polite suggestion as to how to deal with the problem, one that (intentionaly, or, more likely IMHO, un-intentionaly) puts the 'net more under their control. No one else has a better claim to be making the decision, and so, almost by default, ICANN wins out. Just as, in physics, nature abhors a vacuum, in politics, power abhors a vacuum. So, like it or not, I expect ICANN's power to slowly increase over time, moving into new areas that currently have little or nothing to do with ICANN.
To be honest, I don't think that's necessarily a bad thing. There *are* issues to be resolved in a net-wide way, and I don't think that any of the other international bodies are a good fit for the job. Can you imagine the UN taking a role? Or, worse yet, but more likely, the WTO? Not if I have anything to say about it.
ICANN at least makes a *pretense* at being open to direct influence by individuals, and, with work, we can improve on that. That's why, IMHO, it's incredibly important that we be aware of what's going on, and, if possible, get in on the ground floor here so that we have a say as to how ICANN develops.
The problem is if the licenses conflict for some reason, and one or the other of the licenses claims to govern the license of the other.
I don't know exactly what the situation is for Python, but this can happen when a lib says programs that link it must be distributed under the lib's license (the GPL does this, essentialy) and the license of the prog doesn't permit itself to be distributed under the license of the lib.
This is what the KDE fracas was about (before QT went GPL), and is why license proliferation is such a Bad Thing(tm).
Re:Sounds interesting, but I'm annoyed by the US c
on
Ash: A Secret History
·
· Score: 1
Actualy, anybody have a UK source other than amazon.com? Damned if I'm going to pay extra just to keep track of extra books (I have way too many series as it is), but I'm not buying anything from amazon.com.
Preferably someplace that won't have any problems shipping to a US address.
Farmer Fred's out of business. Sucks to be him; he'll have to find another way to make money. Unfortunately, this sort of thing happens all the time.
Fortunately for us, though, we get all the fruit we want. And when hobyists spend years developing the perfect fruit, we all get to have that too. Prety soon we'll have fifty bazillion varieties of apples, with different colorings, flavorings, etc, and someone (Farmer Fred?) will make lots of money keeping them all straight and making sure you can find the right fruit for you.
That's a fascinating point, and you may be right. But in MLK's day, how would he have gotten the word out other than being in front waving a standard? For good or ill, this provides another way for people to communicate, and predicting the effect on society is a crap shot.
An interesting analogy, actualy, is the Kilroy story. I'm not familiar w/ the details but (I believe it was during one of the world wars?) the phrase "Kilroy was here" started showing up in bathroom stalls and such all over the world in an entirely anonymous way. Peaple simply saw it in one place, and put it up someplace else. Whatever the reason, it captured people's imagination -- and isn't that all you need to do to effect social change?
> Cheap?! You call $1.50 one-way "cheap"? IIRC, it's > the most expensive mass transit system in the > world. And it still has to be subsidized.
I call it damn cheap. When I was using the DC metro (a very nice, clean, fast metro system, btw, if a bit overloaded at times) it was $3.50 one way. For public trans, that's really high, but it's still not bad when you compare it to gas, parking, etc. Add to that that I could sit & read a novel on my way to work, it was wonderful.
Now I'm using the Baltimore subway, which is rather poorly organized (one (slow) subway line, and some light rail, even slower -- basicaly an electric bus). But by choosing where I moved I was able to get a very nice comute for $1.35 (one way).
As far as SUV's, well, SUV's are evil. I was comuting by car for a while, and I'd guess that half of the vehicles on I95 durring rush hour were SUV's. Nice SUV's, that had clearly never seen so much as a gravel road. Now, back where I grew up (SW Oregon) there are mountains, trees, etc.. I can see where some people would find an SUV useful there. But the area here is in the middle of a city, there are no mountains to speak of (not like Oregon, anyway), very little bad weather (precipitation-wise), nowhere I've seen that would need an SUV. But these a*holes think they're hot sh*t if they drive an SUV. It really pisses me off.
So many people seem to think that this whole uproar is because Debian folks have their collective noses up in the air and don't want to include KDE. I can only assume that these people think that this whole licensing issue is just a smoke screen for Debian's "real" reason for not inculding KDE.
I'm not a Debian maintainer or anything, but from everything I've heard on the debian-legal list, etc., an awful lot of debian folks would really love to have KDE in the Debian main collection. But, partly because they're not a big corp that can accept the (possibly small) risk of a lawsuit, and partly because they've always tried to be above reproach when it comes to respecting other people's licenses, they really don't feel comfortable including it unless this license issue is cleared up.
What, after all, is so terrible about the idea that Debian folks would want to hold themselves to a higher standard than Redhat, Mandrake, and the like? Not that these places aren't doing a lot for the linux and free/open comunities, but Debian is a different kind of distribution, with different goals. Part of that means doing it the Right Way(tm), and one thing that means is absolute respect for the wishes of the author when it comes to licensing and distribution.
Are the KDE folks doing anything really terrible by not pursuing this issue the way Debian people think they should? No, I don't think so. They're coders, not lawers, and so code is their priority. But that doesn't mean Debian can ignore the issue just because KDE happily puts up with a little bit of a grey area in their licensing.
The result of this, obviously, is that Debian can't include KDE. That's fine for me personaly, I'm a command-line guy, and tend to distrust integrated desktops anyway. But many Debian users want KDE to be part of Debian, and I'm certain there are Debian maintainers that would love to manage a set of KDE packages. These people are understandably aggravated that they can't do this simply because of a piddling little license issue (one that would admitedly take a lot of legwork to resolve).
The QPL (v2.0) *is* free, that's not the issue. The issue is that the QPL & GPL are, in themselves, incompatable (meaning that QPL code & GPL code can't be distributed as a combined, derived app). This is why Debian doesn't distribute KDE, not because it isn't free.
The problem isn't free vs. non-free, it's whether it's legal to distribute the combination of GPL & QPL at all. My understanding is that if it's possible to distribute KDE at all, Debian can distribute it in main.
As I said in another post, many people see this as a technicality, since (for instance) Redhat is willing to overlook the issue and distribute KDE anyway. Debian isn't willing to overlook the issue and compromise its strict view on licensing though (for reasons long & historical).
For an explanation of the QPL, you'll have to look to someone else.
However, it doesn't matter. The issue isn't the QPL (at least not directly), it's that the QPL has requirements that the GPL doesn't. Since the GPL doesn't permit extra requirements (I'm putting this loosly -- IANAL) the GPL & QPL aren't compatable (i.e., code under both licenses can't be put together into a single derived work). Since they're incompatable, technicaly no one has the right to distribute such a derived work, which I understand much of KDE is.
Arguably, this is a technicality; certainly many distributions (e.g., Redhat) ignore it and move on. However, for lots of reasons, Debian isn't willing to ignore it and compromise their strict view on licensing. So despite the fact that they'd (probably) not be sued over it or anything, they're unwilling to distribute it at all -- even in non-free.
This has been the subject of many a flame war on debian-legal, and hopefuly this won't turn into another one.
As you mention, there's the issue of pursuing copyright violators -- the FSF will do this for you if you sign the copyright over to them.
The other reason I've heard is that there must be something in writing in order for the license to have any legal standing. What that must be, I don't know, but presumably signing the copyright over under a particular license would do the trick.
My understanding (IANAL, of course) is that the problem occurs because the GPL isn't an agreement with a particular person. Because of this there's no document that represents the license agreement, and so there's no legal standing for the license. Hopefuly, a court would realize that all parties (well, most all) are well aware of the license, and that there is a meeting of the minds. But who knows whether that's even relavent in the twisted mind of the court.
Since I'm not really sure if there is a reason behind the legal fact (or if it's just a historical artifact), I don't know whether something like having a copy of the license signed & dated by a notary public would help.
Much as I agree with your basic point (people need to learn to express themselves better in print, and to take the time to read others' writing well), to assume that the problem is simply a lack of education is to completely miss the real problem.
Certainly communicating over long distances via the written word is a solved problem, but that's not the problem we're facing. We have a very fast medium here, where instant responses are expected and provided. When people are in a world where "written" means "takes days, if not weeks to get to the reader" it is one in which people will naturaly take the time to make sure that the message is perfect, and to read & reread the letter to make sure they understand it correctly. I don't see any reason to think this has anything to do with education.
I think it's true that we need to pay more attention to our writing skills, and to our reading comprehension skills, but we're also going to have to accept that confusion will happen. So in addition to the above, we need to learn to get over misunderstandings when they happen.
There's going to be a sort of law of increasing risks at work with something like this. The more people/machines/targets involved, the more likely that the people behind it will get caught. So that's the crucial question that determines whether this is a fundamental problem (rather, whether it will continue to be a problem) or not. If the threshold of risk is low enough so that people have to cross it in order to do something like this, it isn't going to be done all the time. If the threshold is too high, though, it may well become commonplace.
I don't think he's concerned about other people writing modules for litestep. It's the people who write (GPL'd) modules for litestep who are concerned that their code will be apropriated for use in a non-GPL shell replacement. Evidently the problem is made worse than usual because the modules have a very general interface and could (presumably) trivialy be integrated into another shell replacement in a non-GPL way.
Anyway, since I'm posting anyway, I'll put in my $.02. Knowing that someone else has stolen your GPL code could be very difficult. If you know, though, you can take legal action. One option would be to sign the copyright over to the FSF, in which case they will take responsibility for bringing violators to court.
Slashdot Mirror
I have to disagree with you here. I use inst & co. quite a lot (I admin a number of irix machines) and have very little good to say about it. It's may be a bit better than some others, but compared to apt/dpkg *or* rpm it's woefully inadequate. It's always a relief, after installing an irix box and weeding out the hundreds of unecessary fluf packages in the default install, to go back to one of my debian machines.
Version dependancies, for example, can be extremely confusing. If you have the wrong version of some eoe.* package for a package you want to install, it can be very difficult to parse the version info and jump through the necessary hoops to get what you want in place.
My biggest problem with inst, though, is that there is no effective way to deal with large numbers of packages. Sure, there are various keywords you can use, and they help, but they're basicaly a hack. Going through an extensive list (e.g., the freeware distribution, or even worse, the default install) and trying to prune out the stuff you don't want and/or put in the stuff you do want can be extremely unpleasant. I generaly find I have to make a large list, on paper, of the often literaly hundreds of package additions/removals, then use inst to implement them.
You may want to check out stow. It's not exactly what you're talking about, but does allow you to have the traditional etc, bin, lib, etc., and a mutt directory with everything mutt-related at the same time.
The recent ssh vulnerability is a good example of why this is wrong. The encryption methods can be entirely open (hell, they can be secure, even) but the app can still end up being vulnerable because it leaks some piece of information that the programmer didn't realize was sensitive -- like the timing between key presses.
The Cluetrain manifesto was talking about individual to individual communication. Talking to the press is centralized to begin with, since the press itself is centralized. The great thing about communication with peers is that it goes both ways and it's always possible to straighten things out if there's misscomunication (which there will be).
With the press that's not possible -- not in any meaningful way, anyway. So sure, have your engineers talk to their engineers, but don't go blabbing to the press because then it's too likely to get out of control.
Mine is fairly simple, but I like it. (I wonder if this will make it past the lameness filter.)
export PS1='%B%m%(?..[%?])%(#.#.)%b '
export PS2='%B%_%(#.#.)%b '
export RPS1='%B%~:%*%b'
Explanation:
PS1 is the left-side prompt for normal commands, PS2 is for inside things like for & while loops. RPS1 is the right-side prompt for normal commands. All prompts are bold. PS1 is the machine name, the exit status (if non-zero) and then '#' if uid=0. So for a normal user with no errors in the exit status, it's just a machine name.
PS2 lists the blocks I'm in (e.g., "for then" if I'm inside of an if block inside a for block). Then, if root, '#'.
RPS1 is the tilde-encoded directory (e.g., '~' for home dir) followed by a ':', followed by the time.
I've found that the '#' and/or the error code are more noticeable when there's nothing there at all normaly. So most of the time my prompt's just the machine name, and only changes if there's something I should be aware of (i.e., I have root or a command failed).
Even better, though, is that I have "user@host:/dir" in my xterm (well, aterm, actualy) title bar:
precmd () {print -Pn "\e]0;%n@%m:%~\a"}
Great when I have a bunch of shells open and I'm looking through a menu for a particular shell session.
> So the LSB folks put together a set of minimum requirements for a Linux distribution, and quite frankly, my guess is that they are too minimum to really be of any use.
Can you be specific here? Maybe I'm not understanding something, but if software package foo depends on lib baz, the lsb rpm for foo should depend on baz. Simple.
LSB doesn't need to include every lib anybody will want when writing software, it only needs to include the realy basic stuff every distro has, so that distros can be standard about it. But if a package needs extra functionality, that's what package manager dependancies are there for. Does that mean LSB should be pared down to the most minimalist possible set of system requirements? No, that's not practical. The requirements need to reflect reality, and most systems just aren't that minimal.
Personaly, I'm very impressed with the LSB. Especialy the naming conventions for rpms. My guess is that that could go a long way toward giving rpms some of the same reliability and dependability that debian users are used to with debs.
You don't sound like a troll, so I'll assume you're talking about yourself & not the original.
Sure, the things Katz is pointing out are straightforward results of economics and not some evil conspiracy by "big media". But unless you're a hopeless Randian that doesn't make them good. Maybe Katz is anthropomorphising too much, but that doesn't make the issues any less important.
Ask yourself a few simple questions:
Does control of the media by a few huge corporations have a "lowest common denominator" effect on the content that's produced?
What sort of effect does this have on people, most of whom may be quite capable of thinking criticaly but don't unless goaded?
Do you want to live in a world where most people (even if not yourself) don't think or worry about anything that hasn't first been fed to them by large corporations?
For myself, the trend Katz is talking about is very worrysome. Sure, it's nothing new, but I think there's a chance we can use the net to break the cycle that's been going on for the past 50 years. So I think it's worth it to try to understand why it's going on and how we might be able to change it.
One thing worth noting is that they're not talking about what most people mean when they say "stem cell," i.e., totipotent cells.
Totipotent cells can become any type of tissue found in the human body. They're the cells found in embryos & (female) reproductive tissues.
Pluripotent cells are much more common, found in bone marrow and (I believe) other places as well. They can become some types of tissues, but not others.
The article's fascinating, but in the end I don't think I buy it. He measures voting power by the chance that your vote will turn the election. Which I see no real problem with untill you bring districts (i.e., the electoral college) into it.
There, part of what determines whether or not your vote turns the election isn't your vote, it's *where* you vote. So to say that using districts increases the power of individual votes is disingenuous at best.
It simply takes the (pseudo) random factor of the votes themselves and creates a new random factor of how the votes are aportioned into districts. It doesn't give voters more power; it just throws a new element of chance into the race.
I'll go along with that.
But the fact that most states follow a winner-take all system directly reverses this. Small states may have more delegates per individual, but large states are likely to have more delegates per majority-voting individual. Since it votes as a block, a large state has comparatively more power.
Anyone know where to find info on how various states allocate delegates?
It's not a stupid question at all -- it's a very good one.
I don't know exactly what ICANN's official duties are, but my understanding is that they're quite limited, in the grand scheme of things. Sure, there's the issue of domain name squating, dispute resolution policies, etc., which are quite important. But if that were all I wouldn't be too concerned about it.
The problem is this: ICANN is "the internet governing body" to the press. There are a lot of global issues re: the net that need to be resolved, and, assuming the US doesn't decide it's Supreme Ruler of the World, there isn't a clear place to go to get answers to these questions. (Not that I mean to imply that the US is a clear place to go for answers -- far from it.)
So you tell me what happens when there are issues to be resolved, no one around to resolve them, and a bunch of bozos in the press talking about ICANN as "the internet governing body"?
I'll tell you: ICANN makes a polite suggestion as to how to deal with the problem, one that (intentionaly, or, more likely IMHO, un-intentionaly) puts the 'net more under their control. No one else has a better claim to be making the decision, and so, almost by default, ICANN wins out. Just as, in physics, nature abhors a vacuum, in politics, power abhors a vacuum. So, like it or not, I expect ICANN's power to slowly increase over time, moving into new areas that currently have little or nothing to do with ICANN.
To be honest, I don't think that's necessarily a bad thing. There *are* issues to be resolved in a net-wide way, and I don't think that any of the other international bodies are a good fit for the job. Can you imagine the UN taking a role? Or, worse yet, but more likely, the WTO? Not if I have anything to say about it.
ICANN at least makes a *pretense* at being open to direct influence by individuals, and, with work, we can improve on that. That's why, IMHO, it's incredibly important that we be aware of what's going on, and, if possible, get in on the ground floor here so that we have a say as to how ICANN develops.
That'd be 187.64.230.78
Well, Pi * 10^9, anyway.
The problem is if the licenses conflict for some reason, and one or the other of the licenses claims to govern the license of the other.
I don't know exactly what the situation is for Python, but this can happen when a lib says programs that link it must be distributed under the lib's license (the GPL does this, essentialy) and the license of the prog doesn't permit itself to be distributed under the license of the lib.
This is what the KDE fracas was about (before QT went GPL), and is why license proliferation is such a Bad Thing(tm).
Actualy, anybody have a UK source other than amazon.com? Damned if I'm going to pay extra just to keep track of extra books (I have way too many series as it is), but I'm not buying anything from amazon.com.
Preferably someplace that won't have any problems shipping to a US address.
Farmer Fred's out of business. Sucks to be him; he'll have to find another way to make money. Unfortunately, this sort of thing happens all the time.
Fortunately for us, though, we get all the fruit we want. And when hobyists spend years developing the perfect fruit, we all get to have that too. Prety soon we'll have fifty bazillion varieties of apples, with different colorings, flavorings, etc, and someone (Farmer Fred?) will make lots of money keeping them all straight and making sure you can find the right fruit for you.
That's a fascinating point, and you may be right. But in MLK's day, how would he have gotten the word out other than being in front waving a standard? For good or ill, this provides another way for people to communicate, and predicting the effect on society is a crap shot.
An interesting analogy, actualy, is the Kilroy story. I'm not familiar w/ the details but (I believe it was during one of the world wars?) the phrase "Kilroy was here" started showing up in bathroom stalls and such all over the world in an entirely anonymous way. Peaple simply saw it in one place, and put it up someplace else. Whatever the reason, it captured people's imagination -- and isn't that all you need to do to effect social change?
> Cheap?! You call $1.50 one-way "cheap"? IIRC, it's
> the most expensive mass transit system in the
> world. And it still has to be subsidized.
I call it damn cheap. When I was using the DC metro (a very nice, clean, fast metro system, btw, if a bit overloaded at times) it was $3.50 one way. For public trans, that's really high, but it's still not bad when you compare it to gas, parking, etc. Add to that that I could sit & read a novel on my way to work, it was wonderful.
Now I'm using the Baltimore subway, which is rather poorly organized (one (slow) subway line, and some light rail, even slower -- basicaly an electric bus). But by choosing where I moved I was able to get a very nice comute for $1.35 (one way).
As far as SUV's, well, SUV's are evil. I was comuting by car for a while, and I'd guess that half of the vehicles on I95 durring rush hour were SUV's. Nice SUV's, that had clearly never seen so much as a gravel road. Now, back where I grew up (SW Oregon) there are mountains, trees, etc.. I can see where some people would find an SUV useful there. But the area here is in the middle of a city, there are no mountains to speak of (not like Oregon, anyway), very little bad weather (precipitation-wise), nowhere I've seen that would need an SUV. But these a*holes think they're hot sh*t if they drive an SUV. It really pisses me off.
But enough ranting.
So many people seem to think that this whole uproar is because Debian folks have their collective noses up in the air and don't want to include KDE. I can only assume that these people think that this whole licensing issue is just a smoke screen for Debian's "real" reason for not inculding KDE.
I'm not a Debian maintainer or anything, but from everything I've heard on the debian-legal list, etc., an awful lot of debian folks would really love to have KDE in the Debian main collection. But, partly because they're not a big corp that can accept the (possibly small) risk of a lawsuit, and partly because they've always tried to be above reproach when it comes to respecting other people's licenses, they really don't feel comfortable including it unless this license issue is cleared up.
What, after all, is so terrible about the idea that Debian folks would want to hold themselves to a higher standard than Redhat, Mandrake, and the like? Not that these places aren't doing a lot for the linux and free/open comunities, but Debian is a different kind of distribution, with different goals. Part of that means doing it the Right Way(tm), and one thing that means is absolute respect for the wishes of the author when it comes to licensing and distribution.
Are the KDE folks doing anything really terrible by not pursuing this issue the way Debian people think they should? No, I don't think so. They're coders, not lawers, and so code is their priority. But that doesn't mean Debian can ignore the issue just because KDE happily puts up with a little bit of a grey area in their licensing.
The result of this, obviously, is that Debian can't include KDE. That's fine for me personaly, I'm a command-line guy, and tend to distrust integrated desktops anyway. But many Debian users want KDE to be part of Debian, and I'm certain there are Debian maintainers that would love to manage a set of KDE packages. These people are understandably aggravated that they can't do this simply because of a piddling little license issue (one that would admitedly take a lot of legwork to resolve).
The QPL (v2.0) *is* free, that's not the issue. The issue is that the QPL & GPL are, in themselves, incompatable (meaning that QPL code & GPL code can't be distributed as a combined, derived app). This is why Debian doesn't distribute KDE, not because it isn't free.
The problem isn't free vs. non-free, it's whether it's legal to distribute the combination of GPL & QPL at all. My understanding is that if it's possible to distribute KDE at all, Debian can distribute it in main.
As I said in another post, many people see this as a technicality, since (for instance) Redhat is willing to overlook the issue and distribute KDE anyway. Debian isn't willing to overlook the issue and compromise its strict view on licensing though (for reasons long & historical).
For an explanation of the QPL, you'll have to look to someone else.
However, it doesn't matter. The issue isn't the QPL (at least not directly), it's that the QPL has requirements that the GPL doesn't. Since the GPL doesn't permit extra requirements (I'm putting this loosly -- IANAL) the GPL & QPL aren't compatable (i.e., code under both licenses can't be put together into a single derived work). Since they're incompatable, technicaly no one has the right to distribute such a derived work, which I understand much of KDE is.
Arguably, this is a technicality; certainly many distributions (e.g., Redhat) ignore it and move on. However, for lots of reasons, Debian isn't willing to ignore it and compromise their strict view on licensing. So despite the fact that they'd (probably) not be sued over it or anything, they're unwilling to distribute it at all -- even in non-free.
This has been the subject of many a flame war on debian-legal, and hopefuly this won't turn into another one.
As you mention, there's the issue of pursuing copyright violators -- the FSF will do this for you if you sign the copyright over to them.
The other reason I've heard is that there must be something in writing in order for the license to have any legal standing. What that must be, I don't know, but presumably signing the copyright over under a particular license would do the trick.
My understanding (IANAL, of course) is that the problem occurs because the GPL isn't an agreement with a particular person. Because of this there's no document that represents the license agreement, and so there's no legal standing for the license. Hopefuly, a court would realize that all parties (well, most all) are well aware of the license, and that there is a meeting of the minds. But who knows whether that's even relavent in the twisted mind of the court.
Since I'm not really sure if there is a reason behind the legal fact (or if it's just a historical artifact), I don't know whether something like having a copy of the license signed & dated by a notary public would help.
Much as I agree with your basic point (people need to learn to express themselves better in print, and to take the time to read others' writing well), to assume that the problem is simply a lack of education is to completely miss the real problem.
Certainly communicating over long distances via the written word is a solved problem, but that's not the problem we're facing. We have a very fast medium here, where instant responses are expected and provided. When people are in a world where "written" means "takes days, if not weeks to get to the reader" it is one in which people will naturaly take the time to make sure that the message is perfect, and to read & reread the letter to make sure they understand it correctly. I don't see any reason to think this has anything to do with education.
I think it's true that we need to pay more attention to our writing skills, and to our reading comprehension skills, but we're also going to have to accept that confusion will happen. So in addition to the above, we need to learn to get over misunderstandings when they happen.
How many machines did it take?
There's going to be a sort of law of increasing risks at work with something like this. The more people/machines/targets involved, the more likely that the people behind it will get caught. So that's the crucial question that determines whether this is a fundamental problem (rather, whether it will continue to be a problem) or not. If the threshold of risk is low enough so that people have to cross it in order to do something like this, it isn't going to be done all the time. If the threshold is too high, though, it may well become commonplace.
At least, that's my $.02
I don't think he's concerned about other people writing modules for litestep. It's the people who write (GPL'd) modules for litestep who are concerned that their code will be apropriated for use in a non-GPL shell replacement. Evidently the problem is made worse than usual because the modules have a very general interface and could (presumably) trivialy be integrated into another shell replacement in a non-GPL way.
Anyway, since I'm posting anyway, I'll put in my $.02. Knowing that someone else has stolen your GPL code could be very difficult. If you know, though, you can take legal action. One option would be to sign the copyright over to the FSF, in which case they will take responsibility for bringing violators to court.