Not exclusive: - Dynamic IP addresses - Authentication - Header Compression. Most uses of PPPoE are applications with much less than 10 Mbit/sec and even on 10M it may be a win with PIII-500 - Easy switching to backup lines that are not ethernet.
Note that the snopping another poster mentioned is nonsense. You usually have your own wire to do this.
I think your intro misses the point. The most pressing issue is that people start to use a license that allows code of other licenses to be used in the same program. Look at the Reisefs issue on linux-kernel. The author has every right to include further restrictions on his own code, as long as he does not affect other people's code. But he is not allowed to by the GPL to which he must obey to get his code into the Linux kernel. Ironically, his move was *towards* the GPL but the GPL doesn't allow it. I'm afraid I get used to events like this as long as noone gets the problem of the GPL. As your initial article shows: people care for code splits and whatnot while there are more pressing issues. Even the (old) LGPL is fine for those who want to protect their own code. it is nobodies business to protect other people's code.
I don't even know where to start complaining about errors in this article.
The most important thing is probably that the GPL doesn't have to do anything with splitting. Obviously not in the emacs/xeamcs case, which are GPLed. The three free BSD variants exist because the people couldn't get together, period. It's also not clear that it is desireable, sine the teams has more than more subteam working on a VM subsystem, and one given BSD variant can have only one VM system. The thing is also about research. The different BSD teams try out different solutions for tasks, in a varity that wouldn't be possible in one shared source tree.
The directions of the free BSD systems as described in the article are inprecise. First of all, FreeBSD isn't x86 anymore. In general, I (as a FreeBSD developer) would say the primary difference between FreeBSD and NetBSD is that FreeBSD is a lot more pragmatic about code changes, while NetBSD aims for the more elegant constructions, with the possible cost of being a bit behind FreeBSD in some areas (not all).
Then, why do xemacs and emacs don't do together? The object-oriented code argument named the article is a joke. These guys don't get together in part because xemacs incorporates a lot more third-party code where the authors don't want to transfer copyright to the FSF. Stallmann requires this for emacs. Also, the packages in xemacs tend to be too new, unstable (you guessed it, I use emacs). xmeacs is also a lot more agressive when it comes to new features, and in my opinion did too much of it in xemacs-20, it is a loss less stable than the other variants.
The worst thing about the article is that its title wants to imply that the GPL might help preventing splits, whereas the actual article doesn't name anything to support this. Typical GPL advocate style, if you ask me: FUD.
I don't think it's appropriate to speak of an "ever-expanding mess of incompatible licenses"
There is just one license that is intentionally incompatible with anything else, the GPL.
It's true that the number of packages under licenses other than the GPL increase, which makes the intention of the GPL (that only GPL software will exit) somewhat obsolete. This plan failed.
Worst thing is that most GPL-using people I spoke to personally expressed they want protection that is covered by LGPL, they didn't need the additional GPL virus. They just didn't care to look and used the GPL because "everyone else does".
Slashdot Mirror
Not exclusive:
- Dynamic IP addresses
- Authentication
- Header Compression. Most uses of PPPoE are
applications with much less than 10 Mbit/sec
and even on 10M it may be a win with PIII-500
- Easy switching to backup lines that are not
ethernet.
Note that the snopping another poster mentioned is
nonsense. You usually have your own wire to do
this.
I think your intro misses the point. The most pressing issue is that people start to use a license that allows code of other licenses to be used in the same program. Look at the Reisefs issue on linux-kernel. The author has every right to include further restrictions on his own code, as long as he does not affect other people's code. But he is not allowed to by the GPL to which he must obey to get his code into the Linux kernel. Ironically, his move was *towards* the GPL but the GPL doesn't allow it. I'm afraid I get used to events like this as long as noone gets the problem of the GPL. As your initial article shows: people care for code splits and whatnot while there are more pressing issues. Even the (old) LGPL is fine for those who want to protect their own code. it is nobodies business to protect other people's code.
I don't even know where to start complaining about errors in this
article.
The most important thing is probably that the GPL doesn't have to do
anything with splitting. Obviously not in the emacs/xeamcs case, which
are GPLed. The three free BSD variants exist because the people
couldn't get together, period. It's also not clear that it is
desireable, sine the teams has more than more subteam working on a VM
subsystem, and one given BSD variant can have only one VM system. The
thing is also about research. The different BSD teams try out
different solutions for tasks, in a varity that wouldn't be possible
in one shared source tree.
The directions of the free BSD systems as described in the article are
inprecise. First of all, FreeBSD isn't x86 anymore. In general, I (as
a FreeBSD developer) would say the primary difference between FreeBSD
and NetBSD is that FreeBSD is a lot more pragmatic about code changes,
while NetBSD aims for the more elegant constructions, with the
possible cost of being a bit behind FreeBSD in some areas (not all).
Then, why do xemacs and emacs don't do together? The object-oriented
code argument named the article is a joke. These guys don't get
together in part because xemacs incorporates a lot more third-party
code where the authors don't want to transfer copyright to the FSF.
Stallmann requires this for emacs. Also, the packages in xemacs tend
to be too new, unstable (you guessed it, I use emacs). xmeacs is also
a lot more agressive when it comes to new features, and in my opinion
did too much of it in xemacs-20, it is a loss less stable than the
other variants.
The worst thing about the article is that its title wants to imply
that the GPL might help preventing splits, whereas the actual article
doesn't name anything to support this. Typical GPL advocate style, if
you ask me: FUD.
I don't think it's appropriate to speak of an
"ever-expanding mess of incompatible licenses"
There is just one license that is intentionally
incompatible with anything else, the GPL.
It's true that the number of packages under
licenses other than the GPL increase, which makes
the intention of the GPL (that only GPL software
will exit) somewhat obsolete. This plan failed.
Worst thing is that most GPL-using people I spoke
to personally expressed they want protection that
is covered by LGPL, they didn't need the
additional GPL virus. They just didn't care to
look and used the GPL because "everyone else
does".