No question. If KDE had gone with #3 and #3 had been successful the Linux world might have been a lot different. For one thing there would have been very strong Mac KDE sharing. Linux would be getting all the cool mac apps because KDE could have had GNUStep keep up.
Well if GNUStep every picks up again I'll be thrilled. With the new LVVM compiler (part of GCC) this would be a great time to make GNUStep an LVVM app and have GNUStep be the home of desktop apps for linux that take advantage of multiple cores.
The FSF doesn't agree with you, "This [QPL] is a non-copyleft free software license which is incompatible with the GNU GPL. It also causes major practical inconvenience, because modified sources can only be distributed as patches."
QPL is a fine software license.
As for not being able to modify the license itself says the opposite:
3. You may make modifications to the Software and distribute your modifications, in a form that is separate from the Software, such as patches. The following restrictions apply to modifications:
a. Modifications must not alter or remove any copyright notices in the Software.
b. When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer.
_______
Now there was a license called the FreeQT license which existed when objections were being made but well before Gnome. That license was an open source, free as in beer license with heavy restrictions on patches.
But again the issue came up because of the GPL conflict with redistribution. There are other packages with restrictive licenses that put downsteam code requirements on (for example LaTeX) but it was when this licenses were linked that the problems got severe enough that Debian felt they were non compliant.
That is had QT just used this license Debian would have just stuck it in non-free and moved on. The problem came from the major user of QT being KDE which was GPL at the time.
Yes./. users in general don't tend to make as much use of drag and drop / OLE as most users. They don't use application extensions (like the commercial addons to Word or Excel). So they don't see integration on Windows as being a huge plus.
Many of them don't even need the level of integration from Mac.
With this crowd you need to give specific examples of types of integration that aren't provided. And even then it is going to be unconvincing.
Let me give an example in another way. One of my biggest with windows is not having simple raw to hardware writes:
i.e.
echo "...." >/dev/eth0
I would expect to have to explain to people why I want to be able to write to hardware that directly.
I believe openoffice has some sort of GUI abstraction layer and then binds to a variety of different widget sets. This is for example how it binds to the Windows widgets and Cocoa.
Re:time to port gnome!
on
Qt Becomes LGPL
·
· Score: 1, Troll
Color me ignorant, but aren't there language bindings that allow you to use Qt in C?
Probably but every binding I've seen for QT sucks, including the commercial binding for Java that trolltech themselves wrote. Note that Trolltech even admits it sucks. QT is designed top down and bottom up as a C++ library not as a library that happens to be implemented in C++. QT gets advantages from not having to have language abstraction but also gets disadvantages in that binding are: really buggy and complex or low featured.
I think the Gnome developers are being fair. If you use QT you want to use C++.
1) Use a good toolkit available only commercially (including redistribution of libraries) like Win32 or OpenStep
2) Use a bad toolkit available free
3) Jump on the GNUStep project bandwagon and tie themselves to Objective-C.
4) Use a sorta kinda free one, with libraries that were clearly free that was excellent and tied to the language the wanted to use.
5) Write their own toolkit.
Smart people picked all sorts of options from this list. I don't know that #4 was really a mistake. Mozilla foundation has been devastated by the work for XUL. OpenOffice ended up picking up the disadvantages of #5 and #2 with none of the advantages of either. Gnome burned through a lot of their very heavy resources on #5.
I was a big fan of option #3 at the time, but look how that would have turned out.
Re:time to port gnome!
on
Qt Becomes LGPL
·
· Score: 5, Informative
If I recall, Gnome was created because people didn't feel the Qt/KDE license was "Free" enough.
It wasn't that. It was that the Q public license was incompatible with the GPL. QT was Q public and KDE was GPL. KDE is clearly a derived work of the Q public license. That means as far as Debian legal was concerned redistribution of KDE was a license violation.
TrollTech handled this by licensing QT under the GPL (they actually first went through the QPL but that didn't solve the problem). That fixed the legal problems but it meant that any and KDE app had to be GPLed because the userspace exemption (as per Linux kernel) wasn't there. Now KDElib is LGPL which means with QT being LGPL you don't uneed the exemption.
People who are picky enough to care about which text editor and which IRC client can handle the notion of different apps using different structures where integration is important. For example on a Mac I use TextEdit when I want integration and VI when I want features.
The widget kits born in the mid 80s died out just recently. I can't see the ones from the late 90s being gone anytime soon. So you are talking something like 2020.
I think Gnome vs. KDE is going to be an example of what Linux brings: choice and "have it your way" type computing.
I can think of ways to integrate Yahoo. For example for any website do a reverse yahoo topic lookup and have an "also on this topic" button.
For Microsoft its a little harder since they essentially offer Google but worse. OTOH Microsoft search is skinable so Firefox could throw their own ads on top. Or they could offer topical ads like A9 used to do (which used to be my default engine).
In terms of SEC enforcement: Bernie Madoff is a perfect example. The SEC had numerous complaints for years. Other examples would have been auditing resources for financial derivatives in terms of capital adequacy requirements.
Allowing the mega mergers reduced diversity in the banking system. It is the same way that reducing diversity can lead to species extinction.
No labor enforcement: Not having overtime rules. Not protecting the union process during union membership drives.
I'm not exactly sure what you were objecting to in my description of what happened with Parrot but I certainly accept yours as conveying the same thing I was trying to convey. I'm not sure what you saw as different.
I have no problem with the 2 years for regexes though that could have happened as an extension to perl 5 (i.e. really slow but at least the syntax would have worked). That is it could have been done in parallel in terms of design.
In terms of your numbers, that's good to see. The 80/20 rule has me worried but it looks like they get to 12,000 or so by September. From there the next 3,000 are going to be the hard ones. What worries me is how hard.
Any indication of how steep the curve is going to be for those latter bugs / features?
As an aside you may want to check the link in your sig. Thanks for the info.
First off in rereading my old post I should have said Parrot is much more innovative not python. You didn't quote that part, but it changed the meaning of the sentence.
Rather than quibble, lets start this over. What in your opinion has been the hold up with Perl 6? Where did all the years go as you see things? In your opinion how far off is a release?
Glass-Steagall Act repeal Bankruptcy Abuse Prevention and Consumer Protection Act Allowing mega mergers in banking. Almost no SEC enforcement (which is effective deregulation) Almost no Labor enforcement
They didn't kill the deflation problem via. monetary stimulus. Also Keynes didn't advocate worthless public works projects. Things like direct equity injections would have been better. So no I don't think this is disproves it at all.
Glass-Steagall Act repeal Bankruptcy Abuse Prevention and Consumer Protection Act Allowing mega mergers in banking. Almost no SEC enforcement (which is effective deregulation) Almost no Labor enforcement
Slashdot Mirror
The Verizon install disks
1) Walk you through configuring the home router (basically get you to the 192.168.0.1:80 page)
2) Create a weblink in your browser to verizon.net and get the cookie on your browser.
How exactly did this stop her from using the internet?
And Ubuntu comes with OpenOffice. Also she goes to a tech school. This seems to me like a very poorly researched article.
I don't know the answer, sorry.
No question. If KDE had gone with #3 and #3 had been successful the Linux world might have been a lot different. For one thing there would have been very strong Mac KDE sharing. Linux would be getting all the cool mac apps because KDE could have had GNUStep keep up.
Well if GNUStep every picks up again I'll be thrilled. With the new LVVM compiler (part of GCC) this would be a great time to make GNUStep an LVVM app and have GNUStep be the home of desktop apps for linux that take advantage of multiple cores.
The FSF doesn't agree with you, "This [QPL] is a non-copyleft free software license which is incompatible with the GNU GPL. It also causes major practical inconvenience, because modified sources can only be distributed as patches."
QPL is a fine software license.
As for not being able to modify the license itself says the opposite:
3. You may make modifications to the Software and distribute your modifications, in a form that is separate from the Software, such as patches. The following restrictions apply to modifications:
a. Modifications must not alter or remove any copyright notices in the Software.
b. When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer.
_______
Now there was a license called the FreeQT license which existed when objections were being made but well before Gnome. That license was an open source, free as in beer license with heavy restrictions on patches.
But again the issue came up because of the GPL conflict with redistribution. There are other packages with restrictive licenses that put downsteam code requirements on (for example LaTeX) but it was when this licenses were linked that the problems got severe enough that Debian felt they were non compliant.
That is had QT just used this license Debian would have just stuck it in non-free and moved on. The problem came from the major user of QT being KDE which was GPL at the time.
Yes. /. users in general don't tend to make as much use of drag and drop / OLE as most users. They don't use application extensions (like the commercial addons to Word or Excel). So they don't see integration on Windows as being a huge plus.
Many of them don't even need the level of integration from Mac.
With this crowd you need to give specific examples of types of integration that aren't provided. And even then it is going to be unconvincing.
Let me give an example in another way. One of my biggest with windows is not having simple raw to hardware writes:
i.e.
echo "...." > /dev/eth0
I would expect to have to explain to people why I want to be able to write to hardware that directly.
That kind of license wouldn't be enforceable.
A is code that uses the QT and is free as in beer but no right to redistribute.
B is code that uses A but makes no use specifically of QT and is completely proprietary.
QT&A&B are distributed together commercially and there is no enforcement of any violations for A.
I didn't see didn't want I said could handle.
If you want that kind of monolithic Windows is the right choice for you.
I believe openoffice has some sort of GUI abstraction layer and then binds to a variety of different widget sets. This is for example how it binds to the Windows widgets and Cocoa.
Color me ignorant, but aren't there language bindings that allow you to use Qt in C?
Probably but every binding I've seen for QT sucks, including the commercial binding for Java that trolltech themselves wrote. Note that Trolltech even admits it sucks. QT is designed top down and bottom up as a C++ library not as a library that happens to be implemented in C++. QT gets advantages from not having to have language abstraction but also gets disadvantages in that binding are: really buggy and complex or low featured.
I think the Gnome developers are being fair. If you use QT you want to use C++.
At the time there are options were:
1) Use a good toolkit available only commercially (including redistribution of libraries) like Win32 or OpenStep
2) Use a bad toolkit available free
3) Jump on the GNUStep project bandwagon and tie themselves to Objective-C.
4) Use a sorta kinda free one, with libraries that were clearly free that was excellent and tied to the language the wanted to use.
5) Write their own toolkit.
Smart people picked all sorts of options from this list. I don't know that #4 was really a mistake. Mozilla foundation has been devastated by the work for XUL. OpenOffice ended up picking up the disadvantages of #5 and #2 with none of the advantages of either. Gnome burned through a lot of their very heavy resources on #5.
I was a big fan of option #3 at the time, but look how that would have turned out.
If I recall, Gnome was created because people didn't feel the Qt/KDE license was "Free" enough.
It wasn't that. It was that the Q public license was incompatible with the GPL. QT was Q public and KDE was GPL. KDE is clearly a derived work of the Q public license. That means as far as Debian legal was concerned redistribution of KDE was a license violation.
TrollTech handled this by licensing QT under the GPL (they actually first went through the QPL but that didn't solve the problem). That fixed the legal problems but it meant that any and KDE app had to be GPLed because the userspace exemption (as per Linux kernel) wasn't there. Now KDElib is LGPL which means with QT being LGPL you don't uneed the exemption.
OpenOffice isn't QT or GTK. That problem ain't going away.
People who are picky enough to care about which text editor and which IRC client can handle the notion of different apps using different structures where integration is important. For example on a Mac I use TextEdit when I want integration and VI when I want features.
The widget kits born in the mid 80s died out just recently. I can't see the ones from the late 90s being gone anytime soon. So you are talking something like 2020.
I think Gnome vs. KDE is going to be an example of what Linux brings: choice and "have it your way" type computing.
I agree in general but...
I can think of ways to integrate Yahoo. For example for any website do a reverse yahoo topic lookup and have an "also on this topic" button.
For Microsoft its a little harder since they essentially offer Google but worse. OTOH Microsoft search is skinable so Firefox could throw their own ads on top. Or they could offer topical ads like A9 used to do (which used to be my default engine).
Google is a customer / partner of Mozilla. Mozilla offers a service (default search engine) and Google pays a fee for that service.
Remember this is a whole country with its own language. Likely they are going to be creating their own distribution
Red Hat's entire workforce is 2200. That wouldn't make a dent in government payrolls.
Yep. And he wrote that in 2004. I stand corrected, they did do what I was thinking. Why is it at 0.03?
In terms of SEC enforcement: Bernie Madoff is a perfect example. The SEC had numerous complaints for years. Other examples would have been auditing resources for financial derivatives in terms of capital adequacy requirements.
Allowing the mega mergers reduced diversity in the banking system. It is the same way that reducing diversity can lead to species extinction.
No labor enforcement: Not having overtime rules. Not protecting the union process during union membership drives.
I'm not exactly sure what you were objecting to in my description of what happened with Parrot but I certainly accept yours as conveying the same thing I was trying to convey. I'm not sure what you saw as different.
I have no problem with the 2 years for regexes though that could have happened as an extension to perl 5 (i.e. really slow but at least the syntax would have worked). That is it could have been done in parallel in terms of design.
In terms of your numbers, that's good to see. The 80/20 rule has me worried but it looks like they get to 12,000 or so by September. From there the next 3,000 are going to be the hard ones. What worries me is how hard.
Any indication of how steep the curve is going to be for those latter bugs / features?
As an aside you may want to check the link in your sig. Thanks for the info.
First off in rereading my old post I should have said Parrot is much more innovative not python. You didn't quote that part, but it changed the meaning of the sentence.
Rather than quibble, lets start this over. What in your opinion has been the hold up with Perl 6? Where did all the years go as you see things? In your opinion how far off is a release?
Glass-Steagall Act repeal
Bankruptcy Abuse Prevention and Consumer Protection Act
Allowing mega mergers in banking.
Almost no SEC enforcement (which is effective deregulation)
Almost no Labor enforcement
They didn't kill the deflation problem via. monetary stimulus. Also Keynes didn't advocate worthless public works projects. Things like direct equity injections would have been better. So no I don't think this is disproves it at all.
Glass-Steagall Act repeal
Bankruptcy Abuse Prevention and Consumer Protection Act
Allowing mega mergers in banking.
Almost no SEC enforcement (which is effective deregulation)
Almost no Labor enforcement
should I keep going?