The announcement said MontaVista were providing both real-time latency and a pre-emptible kernel. Only one of those will be in 2.5, and so it looks like 2.5 will not make MontaVista's alternate kernel obsolete all that soon, as alleged by the post I replied to.
The point isn't about web designers not having exact control over the output, it is about colour rendering for web pages being done in an internally inconsistent manner by almost all browsers. That's pretty bad.
I think you have misunderstood the point being made. The article is saying that Netscape consists of pieces X, Y, Z developed in different companies which are independently well written, but because the developers on each team to do not have much insight into the work done in the other teams, when it comes to stitch them together a hash is made of the job. The advantage of an open development model is that the political dimension that prevents openness between the teams is gone. Rarely are there developer meetings that you just have to attend to know what is going on, instead everyone can follow the developers lists and follow the work being done on the related pieces.
The point doesn't have much to do with quality of developers, but is to do with the circumstances under which they work.
If you're referring to this discussion, my understanding was that while Linus though low latency was a desirable goal for the kernel, he thought that `hard real time' was a bad thing for the kernel as a whole, becuase somtimes you do need to lock the kernel to have other important features like robustness and reliability. That ws in the context of RT linux, but I didn't see any big changes in that attitude since.
The conclusion was that if you really needed these kinds of tiny latencies, then the right approach was to use a derivative kernel, but for the rest of us, it wasn't worth the candle. So I guess hard real-time isn't in the pipeline for 2.5.
With only one variable assocaited with each asset, (value and not weight) your asset problem isn't 0-1 Knapsack. It looks similar to the Bin Packing problem, which is NP hard.
This is not true. Copyright is a very robust form of IP (under the Berne convention, you can assert your rights under copyright after years of ignoring violations), and the GPL license simply specifies when the copyright holder permits copying and derivative worksto be made.
I'm talking about RMS's claim that the KDE developers retroactively forfeited their rights (normally granted under the GPL) to redistribute/modify GPL code because in the past they had linked it against non GPL code. What gets me is that RMS is objecting to developers writing GPL code (ie. KDE) borrowing other GPL code. It makes a mockery of the claim that the GPL respects the freedoms of its developers and users.
As for `slapping a license' on code, that arises from one of the following interpretations of the GPL (caveat: I'm not sure this is RMS's interpreatation, but this interpretation has been posted on slashdot before):
Sections 0 and 3 specify what code the GPL covers. Section 0 defines the `The Program' to be the code carrying the license, and anything derived from it. Section 3 talks about `complete source code' which is all source necessary to compile the output, with a vaguely worded special exception that at least covers OS libraries.
Section 1 says that (verbatim) redistributions must contain the license.
Section 3 says that the whole source code must be made available for redistribution if an executable is made available.
Section 6 says that the redistribution must not contain restrictions further to the GPL.
Interpretation one: section 3 only mandates that the whole source must be available, but does not specify how it is made available. Therefore if part carries the GPL and another part carries the QPL, you can satisfy the conditions of the GPL by doing two separate redistributions. This is my favoured interpretation, and it means that GPL code may be linked against QPL code.
Interpretation two: the same distribution is being talked about in sections 1, 3 and 6. The GPL must be taken to apply to all of it. Then the GPL license is being applied to code by someone other than the copyright holder, hence my talk of `slapping on the GPL'.
I think the GPL is relatively clear in intent, but it also charts new legal territory. Here are a few intricacies:
Shrinkwrap `licenses' purport to be contracts and are backed up by statute, so in accepting it, you can restrict your freedoms. The GPL is a license, pure and simple, which means that you do not have to accept it, and so it cannot restrict the freedoms you would have with the program anyway. Thus it is an altogether more difficult kind of document to interpret in terms of what it forces upon you. The idea that you can retroactively forfeit your rights under a license looks to me to be completely absurd.
The `viral' nature of the GPL arises because you are expected to slap the GPL license on work other than your own. It isn't clear that anyone other than the copyright holder is legally entitled to do that.
The incompatibility between the GPL and QPL was, for the most part, unforseen by the open source community: my own understanding, and the understanding of many others before this brouhaha emerged, was that if the license on the linked against code was free (ie. it permitted free redistribution and modification of source), then there was no problem linking against the GPL. The argument that it isn't so depends upon many counterintuitive features of the GPL. I don't believe the argument, personally.
I think Stallman has thought hard about these issues, but I don't think he has a lawyers mind. In particular, I think he finds it difficult to think in terms of what the courts will do with the license when expected to interpret it. Just my opinion, I may have misjudged him, but I don't trust his opinion on the GPL too much.
The `special exception' in section 3 is vaguer than that: it covers `anything that is normally distributed (in either source or binary form) with the major components'.
The point about section 6 is well taken. It means that all of sections 1, 3 and 6 are required to support the claim that the GPL and QPL are incompatible. My understanding of section one is that it only requires that the license accompanies the redistributed source, which must be available in total. It does not assert that the license applies to that whole redistribution, though perhaps section 6 asserts this.
Section 9 is worth a look: it has a `get out clause' if the GPL turns out to be flawed: one can always apply higher numbered versions of the GPL in place of the current one. If the GPL really were to threaten freedom of software, as I think RMS's posturing could well make it do, then the FSF is free to authorise a new version of the GPL with a workaround. Nice idea, again a legal timebomb.
Being free software, it seems, isn't enough for RMS. After all he didn't dispute that QPL was free.
LGPL and BSD aren't afflicted with the curse of viral GPL. Since switching to GPL doesn't protect you from RMS's legal threats any more, I suggest ditching viral GPL altogether is the path of least resistance.
Not true: no-one (yet) doubts that BSD code can be linked against GPL code. The whole incompatibility issue comes up as a claimed interaction of two sections of the GPL. The section that is taken to be talking about linking code against other code is section 3 (the GPL actually does not contain the word `link'), and that only specifies that you must make the source available for the whole of the executable. It is section 1 that specifies that the GPL must also be applied to redistributions of the code. (There's also a vaguely worded exception to section 3, which pretty much threatens to undermine the credibility of that section.)
It used to be the case that people believed that the the GPL was compatible with any license that permitted free redistribution of the source. RMS's claim that the QPL was incompatible with the GPL really came from nowhere, and I don't believe it can be correct. It seems to me that you should be perfectly able to redistribute the separate pieces of source to your executable separately, under the different licenses, thus satisfying the conditions of section 3.
If he is right, then it is likely that the courts would take a dim view of the GPL. Courts don't like arbitrary restrictions on the private individuals free use of property, unless forced upon them by statute.
It's high time we got an legal IP specialist to pass his opinion on the matter.
KDE has always been GPL. The idea that there could be source-to-source conflict between KDE and GPL code sounds to me to turn on legal subtleties that I doubt RMS, pace his status as co-author of the GPL, is at all qualified to judge.
What really irritates me is that RMS can never resist the urge to make the worst of some legal hairsplitting. If he just sounded a note of caution, I would be happy, but he has to talk in terms of KDE developers forfeiting their rights to develop the code on which they are working.
One of the goals of the MathML design team is intercovertibility with TeX. Id MathML proves to be a fad, there should already *be* a converter into TeX.
You've got to take your hat off to RMS. He manages to turn any good news into bad news. He couldn't quite manage to argue that the QPL was non-free, but he did manage to argue that it was incompatible with the GPL (I doubt this claim would stand up in court), and managed to convince the world that this threatened the end of free software. Now he takes the psoition that, even when the QPL is replaced by the GPL, the fact that you ever tried to link against the QPL irrevocably forfeits your rights to release the software under the GPL.
I hope no-one buys this garbage. It certainly would make a nonsense of the idea that the GPL respects the freedoms of its users and developers.
I don't get the point about `powerful APIs', but you might have a look at the scheme2c compiler which has excellent support for linking C libraries into scheme code.
I guess my experiences are out of date, but I had found games support for NT lagged far behind that for Win98. I also saw a lot of whining on Ars Tech. about poor gaming support for Win2k.
Sure, but Common LISP doesn't compare so well with C in terms of leanness and predictability.
I posted before I read Kernighan's comments about ML (nicely put, I guess I agree with him), and if Scheme is less an `academic' language than ML, you do need to grok higher-order functions to get the most out of it. My own guess is that in the very long term, functional languages will win out, but that's a long, long way off yet.
Well, I think C scores impressively highly considering its age, but surely scheme beats it! It's far more expressive, and gives pretty good resource predictability, due to its simple execution model, uniform syntax and treatment of data. And, if I had just one compiler on a desert island, I can't think I'd choose one without garbage collection:-
Comparing Windows 2000 and Linux from the gamers position is like arguing the merits of fleas and lice: both are dreadful. Win98 is the target OS of almost all PC games.
Re:We have a level playing field
on
Qt Going GPL
·
· Score: 2
Not quite identical: GTK+ is LGPL, and I think this may be preferable to many corporate developers. There is of cource the anti-competitive advantage of GPL to corporate developers: it can't find itself in a commercial offering by a rival.
I have to say the whole QPL vs. GPL spat has me disillusioned with the GPL: the GPL doesn't just ensure that it can only find itself in free software (no-one disputed that the QPL license guarantees this), it also ensures that it can only find itself in software that conforms exactly to RMS's conception of free software. This reeks of ideological intolerance, though I suppose one shouldn't expect anything else of RMS.
Nicely put, and in general I couldn't agree more, but there is an advantage in the formulation of the early legislative documents: the reasons and motivations were presented with reasonable clarity, and were thought to be things that you should establish by argument. Today bills pass as a result of complex political horse-trading, and is usually hard to unambiguously identify the idea that lies behind a law, let alone be confident that it has been subjected to much criticism.
This isn't an attempt to whitewash the flaws of the constitution: to pick a controversial example, the second amendment is a horribly ambiguous and flawed document. But I don't think that the retroactive provision of the CTEA was subject to proper criticism, and, if I think it's hopeless, I like the idea of being able to challenge laws for being unconstitutional becuase it gives a chance to test the ideas that lie behind them.
I think Napster is about this reflex: to me it looks like the RIAA are: (a) in the right, and (b) stupid to try to win this fight. The RIAA are desperately trying to fight any change in the way the industry works, but beating Napster won't stop that change from happening.
DeCSS *is* about control of intellectual property, and it makes more sense. Here I think the case is exactly the other way about: the MPAA are (a) in the wrong, and (b) smart to try to win this fight. The MPAA are looking at changing the product they are offering the viewer, and they've invested a lot of money in the DVD solution. The MPAA are not threatened from smaller independents in the way that the big music companies are: the revenue is concentrated in the big releases in the movie industry to an extent not true in the music industry. The centralised control of the product makes all the difference: they really can control the industry if they get control of the DVD players.
"Because this allows developers to make Mozilla on at least 3 platforms simaltaneously..."
In other words, a feature. WWLD? (What Would Linux Do?) Concentrate on one platform (either OS or hardware). Don't do anything platform specific to lock the other out, but don't make everyone wait for the slowest member
Writing your applications from the ground in a cross platform manner saves you a horrednous refactoring problem later, when you want to port your code to another platform. WWLD here is in direct contradiction to good software engineering practice, and stupid as well.
This isn't a feature, it's good development practice.
Slashdot Mirror
The announcement said MontaVista were providing both real-time latency and a pre-emptible kernel. Only one of those will be in 2.5, and so it looks like 2.5 will not make MontaVista's alternate kernel obsolete all that soon, as alleged by the post I replied to.
The point isn't about web designers not having exact control over the
output, it is about colour rendering for web pages being done in an
internally inconsistent manner by almost all browsers. That's pretty
bad.
saying that Netscape consists of pieces X, Y, Z developed in different
companies which are independently well written, but because the
developers on each team to do not have much insight into the work done
in the other teams, when it comes to stitch them together a hash is
made of the job. The advantage of an open development model is that
the political dimension that prevents openness between the teams is
gone. Rarely are there developer meetings that you just have to
attend to know what is going on, instead everyone can follow the
developers lists and follow the work being done on the related pieces.
The point doesn't have much to do with quality of developers, but
is to do with the circumstances under which they work.
discussion, my understanding was that while Linus though low
latency was a desirable goal for the kernel, he thought that `hard
real time' was a bad thing for the kernel as a whole, becuase somtimes
you do need to lock the kernel to have other important features like
robustness and reliability. That ws in the context of RT linux, but I
didn't see any big changes in that attitude since.
The conclusion was that if you really needed these kinds of tiny
latencies, then the right approach was to use a derivative kernel, but
for the rest of us, it wasn't worth the candle. So I guess hard real-time isn't in the pipeline for 2.5.
With only one variable assocaited with each asset, (value and not
weight) your asset problem isn't 0-1 Knapsack. It looks similar to
the Bin Packing problem, which is NP hard.
This is not true. Copyright is a very robust form of IP (under the
Berne convention, you can assert your rights under copyright after
years of ignoring violations), and the GPL license simply specifies
when the copyright holder permits copying and derivative worksto be
made.
Well, to my knowledge Germany doesn't fall under the US code, so what rights that offers is irrelevant to the `Bertelsmann Tax'.
forfeited their rights (normally granted under the GPL) to
redistribute/modify GPL code because in the past they had linked it
against non GPL code. What gets me is that RMS is objecting to
developers writing GPL code (ie. KDE) borrowing other GPL code. It
makes a mockery of the claim that the GPL respects the freedoms of its
developers and users.
As for `slapping a license' on code, that arises from one of the
following interpretations of the GPL (caveat: I'm not sure this is
RMS's interpreatation, but this interpretation has been posted on
slashdot before):
Sections 0 and 3 specify what code the GPL covers. Section 0
defines the `The Program' to be the code carrying the license, and
anything derived from it. Section 3 talks about `complete source
code' which is all source necessary to compile the output, with a
vaguely worded special exception that at least covers OS libraries.
Section 1 says that (verbatim) redistributions must contain the license.
Section 3 says that the whole source code must be made available
for redistribution if an executable is made available.
Section 6 says that the redistribution must not contain
restrictions further to the GPL.
Interpretation one: section 3 only mandates that the whole source
must be available, but does not specify how it is made available.
Therefore if part carries the GPL and another part carries the QPL,
you can satisfy the conditions of the GPL by doing two separate
redistributions. This is my favoured interpretation, and it means
that GPL code may be linked against QPL code.
Interpretation two: the same distribution is being talked about in
sections 1, 3 and 6. The GPL must be taken to apply to all of it.
Then the GPL license is being applied to code by someone other than
the copyright holder, hence my talk of `slapping on the GPL'.
statute, so in accepting it, you can restrict your freedoms. The GPL
is a license, pure and simple, which means that you do not have to
accept it, and so it cannot restrict the freedoms you would have with
the program anyway. Thus it is an altogether more difficult kind of
document to interpret in terms of what it forces upon you. The idea
that you can retroactively forfeit your rights under a license looks
to me to be completely absurd.
slap the GPL license on work other than your own. It isn't clear that
anyone other than the copyright holder is legally entitled to do that.
part, unforseen by the open source community: my own understanding,
and the understanding of many others before this brouhaha emerged, was
that if the license on the linked against code was free (ie. it
permitted free redistribution and modification of source), then there
was no problem linking against the GPL. The argument that it isn't so
depends upon many counterintuitive features of the GPL. I don't
believe the argument, personally.
I think Stallman has thought hard about these issues, but I don't
think he has a lawyers mind. In particular, I think he finds it
difficult to think in terms of what the courts will do with the
license when expected to interpret it. Just my opinion, I may have
misjudged him, but I don't trust his opinion on the GPL too much.
`anything that is normally distributed (in either source or binary
form) with the major components'.
The point about section 6 is well taken. It means that all of
sections 1, 3 and 6 are required to support the claim that the GPL and
QPL are incompatible. My understanding of section one is that it only
requires that the license accompanies the redistributed source, which
must be available in total. It does not assert that the license
applies to that whole redistribution, though perhaps section 6 asserts
this.
Section 9 is worth a look: it has a `get out clause' if the GPL
turns out to be flawed: one can always apply higher numbered versions
of the GPL in place of the current one. If the GPL really were to
threaten freedom of software, as I think RMS's posturing could well
make it do, then the FSF is free to authorise a new version of the GPL
with a workaround. Nice idea, again a legal timebomb.
didn't dispute that QPL was free.
LGPL and BSD aren't afflicted with the curse of viral GPL. Since
switching to GPL doesn't protect you from RMS's legal threats any
more, I suggest ditching viral GPL altogether is the path of least
resistance.
code. The whole incompatibility issue comes up as a claimed
interaction of two sections of the GPL. The section that is taken to
be talking about linking code against other code is section 3 (the GPL
actually does not contain the word `link'), and that only specifies
that you must make the source available for the whole of the
executable. It is section 1 that specifies that the GPL must also be
applied to redistributions of the code. (There's also a vaguely
worded exception to section 3, which pretty much threatens to
undermine the credibility of that section.)
It used to be the case that people believed that the the GPL was
compatible with any license that permitted free redistribution of the
source. RMS's claim that the QPL was incompatible with the GPL really
came from nowhere, and I don't believe it can be correct. It seems to
me that you should be perfectly able to redistribute the separate
pieces of source to your executable separately, under the different
licenses, thus satisfying the conditions of section 3.
If he is right, then it is likely that the courts would take a dim
view of the GPL. Courts don't like arbitrary restrictions on the
private individuals free use of property, unless forced upon them by
statute.
It's high time we got an legal IP specialist to pass his opinion on
the matter.
source-to-source conflict between KDE and GPL code sounds to me to
turn on legal subtleties that I doubt RMS, pace his status as
co-author of the GPL, is at all qualified to judge.
What really irritates me is that RMS can never resist the urge to
make the worst of some legal hairsplitting. If he just sounded a note
of caution, I would be happy, but he has to talk in terms of KDE
developers forfeiting their rights to develop the code on which they
are working.
One of the goals of the MathML design team is intercovertibility with TeX. Id MathML proves to be a fad, there should already *be* a converter into TeX.
news into bad news. He couldn't quite manage to argue that the QPL
was non-free, but he did manage to argue that it was incompatible with
the GPL (I doubt this claim would stand up in court), and managed to
convince the world that this threatened the end of free software. Now
he takes the psoition that, even when the QPL is replaced by the GPL,
the fact that you ever tried to link against the QPL irrevocably
forfeits your rights to release the software under the GPL.
I hope no-one buys this garbage. It certainly would make a
nonsense of the idea that the GPL respects the freedoms of its users
and developers.
I don't get the point about `powerful APIs', but you might have a
look at the scheme2c compiler which has excellent support for linking
C libraries into scheme code.
I guess my experiences are out of date, but I had found games support
for NT lagged far behind that for Win98. I also saw a lot of whining
on Ars Tech. about poor gaming support for Win2k.
leanness and predictability.
I posted before I read Kernighan's comments about ML (nicely put, I
guess I agree with him), and if Scheme is less an `academic' language
than ML, you do need to grok higher-order functions to get the most
out of it. My own guess is that in the very long term, functional
languages will win out, but that's a long, long way off yet.
Well, I think C scores impressively highly considering its age, but :-
surely scheme beats it! It's far more expressive, and gives pretty
good resource predictability, due to its simple execution model,
uniform syntax and treatment of data. And, if I had just one compiler
on a desert island, I can't think I'd choose one without garbage
collection
Comparing Windows 2000 and Linux from the gamers position is like
arguing the merits of fleas and lice: both are dreadful. Win98 is the
target OS of almost all PC games.
to many corporate developers. There is of cource the anti-competitive
advantage of GPL to corporate developers: it can't find itself in a
commercial offering by a rival.
I have to say the whole QPL vs. GPL spat has me disillusioned with
the GPL: the GPL doesn't just ensure that it can only find itself in
free software (no-one disputed that the QPL license guarantees this),
it also ensures that it can only find itself in software that conforms
exactly to RMS's conception of free software. This reeks of
ideological intolerance, though I suppose one shouldn't expect
anything else of RMS.
advantage in the formulation of the early legislative documents: the
reasons and motivations were presented with reasonable clarity, and
were thought to be things that you should establish by argument.
Today bills pass as a result of complex political horse-trading, and
is usually hard to unambiguously identify the idea that lies behind a
law, let alone be confident that it has been subjected to much
criticism.
This isn't an attempt to whitewash the flaws of the constitution:
to pick a controversial example, the second amendment is a horribly
ambiguous and flawed document. But I don't think that the retroactive
provision of the CTEA was subject to proper criticism, and, if I think
it's hopeless, I like the idea of being able to challenge laws for
being unconstitutional becuase it gives a chance to test the ideas
that lie behind them.
are: (a) in the right, and (b) stupid to try to win this fight. The
RIAA are desperately trying to fight any change in the way the
industry works, but beating Napster won't stop that change from
happening.
DeCSS *is* about control of intellectual property, and it makes
more sense. Here I think the case is exactly the other way about: the
MPAA are (a) in the wrong, and (b) smart to try to win this fight.
The MPAA are looking at changing the product they are offering the
viewer, and they've invested a lot of money in the DVD solution. The
MPAA are not threatened from smaller independents in the way that
the big music companies are: the revenue is concentrated in the big
releases in the movie industry to an extent not true in the music
industry. The centralised control of the product makes all the
difference: they really can control the industry if they get control
of the DVD players.
Root can do just the same thing to you on an untrusted UNIX box. At least with S/Key he won't know your password.
platforms simaltaneously..."
In other words, a feature. WWLD? (What Would Linux Do?) Concentrate on
one platform (either OS or hardware). Don't do anything platform
specific to lock the other out, but don't make everyone wait for the slowest member
Writing your applications from the ground in a cross platform
manner saves you a horrednous refactoring problem later, when you
want to port your code to another platform. WWLD here is in direct
contradiction to good software engineering practice, and stupid as
well.
This isn't a feature, it's good development practice.