Just about anybody who runs Beowulf clusters or does scientific computing on Linux is a potential customer for these. Many people run into the dreaded 4G barrier, but Itanium is too costly and too much of a jump. With the x86-64, moving to 64bit is essentially no-risk--you know that at worst, you just get a really fast x86 machine.
But what will be really interesting is when operating systems will be specifically designed for this. With 64bit, a lot of the cruft in 32bit operating systems can finally go away. For example, memory mapped I/O finally becomes useful again, shared libraries don't clash as easily, etc.
As I was saying, and as you seem to agree, they can run Microsoft software, it's just that the school (which almost certainly means the undergraduate computing services) shouldn't license it.
So what if a faculty member can buy Microsoft software if they can't run it on the school supplied computer?
That's not what the posting says. The school can't buy or license Microsoft products, but it sounds like faculty and students can certainly install whatever they like on school computers.
That is exactly analogous to the situation as it exists right now: the school buys machines with Microsoft software and people install Linux.
If the donor wants to stipulate that the donation can only be spent on non-MS software, fine. The college would probably choose to stop buying a lot of Microsoft products but no college should have its affairs dictated by a big donor.
A university like this needs a single, standard computing platform. Right now, that platform is Windows. If they end up having to fully support multiple platforms, that makes their problems worse, not better. The only sensible solution for this kind of switch to Linux is to make it the standard, supported platform and let individuals that want something else (like Windows) worry about how to get and maintain it themselves. In short, the only thing that makes sense for switching to Linux is to reverse the roles of Windows and Linux.
There is something quite distasteful about it: basically, it means that a tax on hardware is handed out to a bunch of companies merely by virtue of being big. Keep in mind that a large amount of the content on the web is created by people like you and me, and we aren't going to see a dime of that money.
Still, one has to be realistic. As an alternative to the DCMA and pervasive DRM, it may well be preferable. Lots of uncompetitive industries get subsidized. Subsidies and handouts to the media industries to have them shut up seem no worse than subsidies and handouts to steel or defense companies. If anything, they are less harmful.
So, it really depends on the details, as some people in the article also point out.
Note that blank CDs are already taxed in both the US and Germany (and many other countries) just for this reason.
I wish it did, but it doesn't really help. To name just some of the problems with that "license", it's non-transferable, Sun has a case-by-case final say in whether you are compliant, and the conditions for compliance are essentially impossible to meet. Not even the licensed ports from Apple, IBM, or Sun itself satisfy the conditions of that license.
To compare the speed of a byte-code compiled language to that of a more classical syntax-tree based compile/execute language is as off-the-wall as comparing a true interpreter to a byte-code compiled language
Nonsense. I was giving people a point of reference for what speed they can expect from Squeak. Of course, it makes sense to compare all sorts of implementations there. After all, people even compare Squeak and C speed.
As for your other points, they are both trivial and irrelevant. If you have a problem with Perl's nomenclature, take it up with the Perl developers, not me.
1) If Microsoft did something like this, everyone would be screaming and calling the Justice Dept. It isn't right for someone else to do the same thing.
The two situations have nothing to do with one another. When Microsoft makes exclusive agreements and throw money into the pot, it's a loss leader--they intend to recoup it. When a philanthrope donates money for the adoption of an open source operating system, there is no financial interest there.
Taking all MS products off the campus would be a dis-service to the students.
They aren't talking about "taking all MS products off the campus", they are talking about not having the university make site purchasing agreements. Presumably, individual students, faculty, and researchers can keep buying whatever they like.
I think you misunderstand what this would mean. This doesn't sound like a ban of Microsoft products on campus, it is a decision on what to buy for core undergraduate computing suppport. Right now, that environment is effectively 100% Windows. Sure, individuals can install Linux, but they probably have a license anyway. The question is, would 100% Linux be more cost effective and would it give the students a better education.
I think the answer to both questions is yes, unless this is some sort of trade school that teaches typing and office skills.
Anybody who wants to can still buy and install Microsoft products themselves, either privately, or out of research grants. That's the same way people install Linux right now. Why not reverse the roles?
Nothing misleading about using language according
to the norms of ordinary and dictionary usage.
Which would that be? The term "open source" had no meaning before Raymond defined it.
And yes, I'll call it Java, just as I'll call
this paper thingy a kleenex.
Well, you can call it "Java". You can also call your dog your girlfriend if you like. But the guy was asking about setting stuff up for customers. Customers expect something Sun Java compatible, not "Aminorex Java". Furthermore, since he would be misusing the Java trademark as part of a business transaction, he would be liable for trademark infringement.
The source to Windows NT has been released, too. That doesn't make Windows NT open source, and talking about it in that way would be very confusing.
The Java Language specification is open.. ie. it can be viewed and implemented by anyone.
Even if that were true, it would be irrelevant. We are not talking about the Java Language, we are talking about Java, which is a language and a set of libraries.
But your claim actually does not even appear to be true: as far as I can tell, Sun has made no legally binding commitment to allow "anyone" to implement Java. So far, all we have is a letter of intent, as part of the JCP, to allow open source implementations.
First poster says Smalltalk is no longer slow and that Java is "dangerous", but fairly recent testing [google.com] showed the truth:
I'm sorry, I must be missing something, but who is "first poster"? All I said was that Squeak has a pretty zippy byte code interpreter. Yes, that makes it about an order of magnitude slower than compiled C/Java, and plenty fast for its intended purposes. So, what is your point again?
"Better" in terms of speed, which is what is under discussion here.
Are you talking about the implementation of the current bytecode engine?
Yes, the point being to give people a rough idea of how Squeak compares to Perl or Python (in the benchmarks I did), to languages that are widely used. That's all.
Of course, interference is a property of the receiver. If we all switched to spread spectrum communications, we could get many orders of magnitude increase in capacity out of our spectrum. But there is no infinite bandwidth available, there is still a limit.
Furthermore, allowing "substandard" receivers to exist is deliberate. We did this with the AM spectrum when FM came along, and we are doing it with other receiver technologies. AM can be received with a few cents worth of primitive electronic components and it is widely deployed, that's why we continue supporting it.
The division into bands also allows enforcement and specific power limits. Without that, people might broadcast over astronomical frequencies, or they might engage in RF shouting matches until they light up each other's fluorescent lightbulbs.
Basically, Reed's science is iffy, and his arguments are completely missing the point. Yes, we can open up spectrum (UWB is essentially trying to do just that), but let's not kid ourselves about the consequences, which will at the very least include the obsolescence of lots of radio equipment and probably a kind of arms race over the airwaves.
Squeak's byte code engine is better than Perl's or Python's, and there is a JIT available (although it's nowhere near as good as Sun's JIT for Java). And you can translate time-critical stuff into native code using a batch compiler and some manual intervention.
But raw execution speed isn't all that counts. Because Squeak has everything in one address space (unlike Gnome/KDE) and doesn't need to load anything on the fly (unlike Java), it's actually very responsive and uses comparatively little memory.
I don't think Squeak or anything based on it is going to replace mainstream desktops now or in the future. But it is an interesting platform for experimentation. It's also historically interesting because you can see the kinds of environments people already had available in 1980 (Smalltalk-80 is contained in Squeak).
In windows, I double-click setup.exe, a GUI pops up, I pick the destination and off it goes.
That works fine for a few applications. Linux has thousands of applications, and people tend to install hundreds of them (they are free, after all, so why not). Do you want to go through hundreds of GUI installers, and then hundreds of GUI updaters? I don't.
Why can't someone make something like this for Linux?
There are interactive installers for Linux packages, but they are usually a nuisance compared to a normal package.
But every time I download something that's not part of Debian it turn into a horrible experience I wish I would have never had.
Well, then don't install non-Debian packages. After all, there are plenty of Windows programs that come with horrible installers. As a Debian user, think of non-Debian packages as "programs that come with horrible installers", and then decide whether they are worth the trouble. (Note that you can usually import packages reasonably well via "alien".)
The package system you get with Debian (or RedHat, for that matter) is already so much better than anything you get for Windows that it isn't funny. If Linux developers adopted the equivalent of setup.exe more widely, that be a real blow to Linux.
"Java" is a trademark of Sun Microsystems. It's a platform, the total of the Java language and the Java libraries, as defined by Sun. Most of the Java platform exists only in a Sun proprietary implementation, which you can obtain under roughly the same conditions as Microsoft's "shared source" implementation.
Kaffe and GNU gcj are not implementations of Java. At best, they are implementations of the Java language or virtual machine, but even in that capacity, they are not blessed by Sun. Porting most substantial Sun Java-based software system to Kaffe or gcj is essentially impossible.
So, please spare us your cynicism or misleading use of language. Sun's implementation of Java is not "open source" in any sense that the term is commonly understood (and the term was created and defined by Eric Raymond). It isn't even close to open source; you enter into legal obligations to Sun just by looking at it. If you treat it like it's open source, you may get into lots of legal trouble with Sun. Neither are gcj or kaffe an implementation of "Java"; they aren't even close, as you would find out if you tried porting anything to them.
However, we agree on this: gcj is a pretty good compiler, and SWT is a pretty good toolkit. I do recommend using them instead of Sun Java. They also have lots of practical advantages, like being smaller, starting up faster, and requiring less memory. But gcj and SWT together don't make "Java". If you are really careful, you can write libraries that will compile and run under both gcj and Sun Java, but it's a significant amount of work and requires a lot of care (as I can tell you from first hand experience).
There is a difference between good packaging (I don't need ActiveTcl for that, I already get it with Debian) and integration. One may be able to argue whether sound support should be part of a core source distribution, but I think the object system and drag-and-drop should be.
I think there is a risk that when an open source project becomes associated with a company that sells support or packaging for it, in order for the company to be able to add value to the product, the open source version ends up being more cumbersome to install or use. That's not necessarily a deliberate strategy, but when it comes down to allocating programmer time, creating a more integrated open source solution probably ends up being low priority--since the perception is that the commerciallly packaged version already addresses that need. I hope that's not the case here with making a more integrated Tcl/Tk source distribution.
Hey, anyone can make a mistake and let their integrity get in the way of making a living.
If you don't let your integrity get in the way of making a living, what the hell is your integrity worth?
And what does it say about the computer industry and Microsoft if losing the opportunity to work at Microsoft has to be considered a serious problem by someone?
Yeah, so you won the lottery. Big deal. You were lucky to be able to join Microsoft when they were growing fast, and you were lucky that Microsoft didn't fail. And for all the past glory of Microsoft's stock price, the good times are over now.
Winning the lottery, participating in a pyramid scheme, or joining the next Microsoft are not viable life plans. For every Microsoft employee that made it, there are hundreds of employees at other companies that worked as hard as you did and didn't make it. In fact, for every Microsoft employee like you, there are probably half a dozen Microsoft employees now that aren't doing any better than anybody else employed by a big company.
So, count your blessings and thank your stars for your good fortune.
My wife worked at Microsoft for a couple of years, and they are a GREAT employer. In terms of corporate culture they really rock.
And that surprises you? Of course, an organization that makes that much profit treats its employees nicely. Even the most cut-throat Wall St. firms treat their employees to all sorts of perks. Why not? It's peanuts compared to the money that comes in.
And everyone there LOVES Microsoft. They love being part of an org that's in the forefront of technology.
And which organization would that be?
(the stock has flatlined for the past 2 years, but before that it went up something like 50-75% ever year).
And there is little reason to believe that MS stock will resume its spectacular growth. From now on, it will be just another big company. Right now, it's still very profitable, but that will also decline over time.
If you say "I'm a vice president" at any multi-billion dollar corporation, people will be impressed because you presumably are paid well. That was true also for vice presidents at Enron or Arthur Andersen.
Programmers who joined Microsoft in 1985 or 1990 also may impress people because it's pretty clear that their stock options made them rich. But over the last couple of years, Microsoft stock has not grown. If you are a programmer for Microsoft, you are roughly in the same financial situation as a programmer for any other big company. And there is no reason to believe that Microsoft stock will ever resume its spectacular growth, even with Microsoft's accounting and business tricks.
So, you are basically saying that if you can join the mafia, then it's a pretty nice organization? And that's basically what Microsoft's anti-trust violations and business practices amount to: bullying distributors, blacklisting competitor's products, selling under cost to drive others out of business.
People don't "hate" Microsoft because they find Bill Gates annoying, they "hate" Microsoft because Microsoft behaves illegally. And while Microsoft's conduct may Microsoft employees really rich, it costs lots of other people their jobs and livelihood.
I would have to agree somewhat that the default look of itk is rather outdated (Motif-based), but that is not a limitation of Tk.
I wasn't referring to the appearance, I was referring to design and APIs of iTcl. People have had (I think legitimate) complaints about how large Tcl/Tk projects become difficult to manage, but in my experience, I don't find iTcl helps all that much.
[...] Tk allows you to toss up windows with such minimal code as pack [button.b -text "Hello" -command {puts "Hello World"}]
That was my point: Tcl/Tk is the fastest way I know to create small to medium sized GUIs and it's an enormously practical tool, but the language also has some serious limitations.
In any case, the biggest practical problems with Tcl/Tk I find are that a lot of extensions still aren't part of it: iTcl doesn't ship with Tcl, and drag-and-drop doesn't ship with Tk.
I don't know what it is about Tcl/Tk, but somehow it seems to be the one tool that lets me build GUIs with the least amount of hassles. Python/Gtk+, wxPython, Perl/Gtk+, Guile, and all of those, still seem to require a lot more work to get anything done. The utility and conciseness of Expect also has not been met by any other tool, IMO.
Also, if you look at areas where Tcl/Tk applications compete with applications written in other toolkits (Zircon, Tkabber, etc.), the Tcl/Tk applications may be uglier, but they tend to be far more feature-complete.
Of course, Tcl/Tk has its limits, and something like iTcl/iTk is rather ugly. But overall, it looks to me Tcl/Tk must be doing something right, and it might be well worth for the developers of other GUI tools to try to figure out what that might be so that we might get the best of both worlds.
Well, that is a rather selective reading. The key points are:
So we are now seeking more libraries to release under the ordinary GPL.
See, that says "more" libraries, not "all" libraries. Choosing LGPL vs. GPL is still a matter of strategy.
Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Library GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Library GPL for that library.
Well, there are plenty of alternative libraries for proprietary GUI libraries.
I'm all for releasing libraries under the GPL. I do so myself. But for something as fundamental as the GUI libraries, and with as many available alternatives, that makes little sense.
Your argument is particularly disingenuous since Stallman, the guy who wrote that note, supports Gnome/Gtk+ the way it is. (At least I have never heard him call for a change to the Gnome/Gtk+ license; if you have, please post a pointer.)
By far, the most common license for the KDE libraries is LGPL, and the most common for applications is GPL.
So, obviously, KDE has lots of code under the LGPL. It just happens to have a GPL'ed library for the core GUI functions and then lots of LGPL'ed code built around that. So, to argue that KDE is somehow more free than Gnome because Gnome uses an LGPL'ed toolkit is just wrong. If you are so convinced that the GPL is the right thing for GUI libraries, why don't you stand by your own convictions and cover all KDE libraries under the GPL as well?
Also, a dual license is not the same as a pure GPL license. A dual license means that people either have to donate their enhancements to Qt to Troll Tech so that Troll Tech has the option of incorporating them into their commercial product, or they are not going to make it into the Qt distribution. It also means that the evolution of Qt is drive, at least in part, by the commercial interests of Troll Tech; from a free software point of view, for example, there is no reason to burden Qt with supporting Windows or MacOS. That is not what the GPL was intended to achieve. Dual licensing with a GPL component differs substantially from GPL-only licensing.
Altogether, arguments that KDE is somehow "more free" or "more in the spirit of free software" are nonsense. Gnome is doing something very sensible, using the LGPL for the core libraries and using the GPL for applications and some special libraries.
Slashdot Mirror
But what will be really interesting is when operating systems will be specifically designed for this. With 64bit, a lot of the cruft in 32bit operating systems can finally go away. For example, memory mapped I/O finally becomes useful again, shared libraries don't clash as easily, etc.
As I was saying, and as you seem to agree, they can run Microsoft software, it's just that the school (which almost certainly means the undergraduate computing services) shouldn't license it.
So what if a faculty member can buy Microsoft software if they can't run it on the school supplied computer?
That's not what the posting says. The school can't buy or license Microsoft products, but it sounds like faculty and students can certainly install whatever they like on school computers.
That is exactly analogous to the situation as it exists right now: the school buys machines with Microsoft software and people install Linux.
If the donor wants to stipulate that the donation can only be spent on non-MS software, fine. The college would probably choose to stop buying a lot of Microsoft products but no college should have its affairs dictated by a big donor.
A university like this needs a single, standard computing platform. Right now, that platform is Windows. If they end up having to fully support multiple platforms, that makes their problems worse, not better. The only sensible solution for this kind of switch to Linux is to make it the standard, supported platform and let individuals that want something else (like Windows) worry about how to get and maintain it themselves. In short, the only thing that makes sense for switching to Linux is to reverse the roles of Windows and Linux.
Still, one has to be realistic. As an alternative to the DCMA and pervasive DRM, it may well be preferable. Lots of uncompetitive industries get subsidized. Subsidies and handouts to the media industries to have them shut up seem no worse than subsidies and handouts to steel or defense companies. If anything, they are less harmful.
So, it really depends on the details, as some people in the article also point out.
Note that blank CDs are already taxed in both the US and Germany (and many other countries) just for this reason.
I wish it did, but it doesn't really help. To name just some of the problems with that "license", it's non-transferable, Sun has a case-by-case final say in whether you are compliant, and the conditions for compliance are essentially impossible to meet. Not even the licensed ports from Apple, IBM, or Sun itself satisfy the conditions of that license.
Nonsense. I was giving people a point of reference for what speed they can expect from Squeak. Of course, it makes sense to compare all sorts of implementations there. After all, people even compare Squeak and C speed.
As for your other points, they are both trivial and irrelevant. If you have a problem with Perl's nomenclature, take it up with the Perl developers, not me.
The two situations have nothing to do with one another. When Microsoft makes exclusive agreements and throw money into the pot, it's a loss leader--they intend to recoup it. When a philanthrope donates money for the adoption of an open source operating system, there is no financial interest there.
Taking all MS products off the campus would be a dis-service to the students.
They aren't talking about "taking all MS products off the campus", they are talking about not having the university make site purchasing agreements. Presumably, individual students, faculty, and researchers can keep buying whatever they like.
I think the answer to both questions is yes, unless this is some sort of trade school that teaches typing and office skills.
Anybody who wants to can still buy and install Microsoft products themselves, either privately, or out of research grants. That's the same way people install Linux right now. Why not reverse the roles?
Which would that be? The term "open source" had no meaning before Raymond defined it.
And yes, I'll call it Java, just as I'll call this paper thingy a kleenex.
Well, you can call it "Java". You can also call your dog your girlfriend if you like. But the guy was asking about setting stuff up for customers. Customers expect something Sun Java compatible, not "Aminorex Java". Furthermore, since he would be misusing the Java trademark as part of a business transaction, he would be liable for trademark infringement.
The source to Windows NT has been released, too. That doesn't make Windows NT open source, and talking about it in that way would be very confusing.
The Java Language specification is open.. ie. it can be viewed and implemented by anyone.
Even if that were true, it would be irrelevant. We are not talking about the Java Language, we are talking about Java, which is a language and a set of libraries.
But your claim actually does not even appear to be true: as far as I can tell, Sun has made no legally binding commitment to allow "anyone" to implement Java. So far, all we have is a letter of intent, as part of the JCP, to allow open source implementations.
I'm sorry, I must be missing something, but who is "first poster"? All I said was that Squeak has a pretty zippy byte code interpreter. Yes, that makes it about an order of magnitude slower than compiled C/Java, and plenty fast for its intended purposes. So, what is your point again?
Oh really? How do you think your Perl code gets executed? By little gnomes?
In any case, I was merely comparing the speed of the interpreters anyway.
"Better" in terms of speed, which is what is under discussion here.
Are you talking about the implementation of the current bytecode engine?
Yes, the point being to give people a rough idea of how Squeak compares to Perl or Python (in the benchmarks I did), to languages that are widely used. That's all.
Furthermore, allowing "substandard" receivers to exist is deliberate. We did this with the AM spectrum when FM came along, and we are doing it with other receiver technologies. AM can be received with a few cents worth of primitive electronic components and it is widely deployed, that's why we continue supporting it.
The division into bands also allows enforcement and specific power limits. Without that, people might broadcast over astronomical frequencies, or they might engage in RF shouting matches until they light up each other's fluorescent lightbulbs.
Basically, Reed's science is iffy, and his arguments are completely missing the point. Yes, we can open up spectrum (UWB is essentially trying to do just that), but let's not kid ourselves about the consequences, which will at the very least include the obsolescence of lots of radio equipment and probably a kind of arms race over the airwaves.
But raw execution speed isn't all that counts. Because Squeak has everything in one address space (unlike Gnome/KDE) and doesn't need to load anything on the fly (unlike Java), it's actually very responsive and uses comparatively little memory.
I don't think Squeak or anything based on it is going to replace mainstream desktops now or in the future. But it is an interesting platform for experimentation. It's also historically interesting because you can see the kinds of environments people already had available in 1980 (Smalltalk-80 is contained in Squeak).
That works fine for a few applications. Linux has thousands of applications, and people tend to install hundreds of them (they are free, after all, so why not). Do you want to go through hundreds of GUI installers, and then hundreds of GUI updaters? I don't.
Why can't someone make something like this for Linux?
There are interactive installers for Linux packages, but they are usually a nuisance compared to a normal package.
But every time I download something that's not part of Debian it turn into a horrible experience I wish I would have never had.
Well, then don't install non-Debian packages. After all, there are plenty of Windows programs that come with horrible installers. As a Debian user, think of non-Debian packages as "programs that come with horrible installers", and then decide whether they are worth the trouble. (Note that you can usually import packages reasonably well via "alien".)
The package system you get with Debian (or RedHat, for that matter) is already so much better than anything you get for Windows that it isn't funny. If Linux developers adopted the equivalent of setup.exe more widely, that be a real blow to Linux.
Kaffe and GNU gcj are not implementations of Java. At best, they are implementations of the Java language or virtual machine, but even in that capacity, they are not blessed by Sun. Porting most substantial Sun Java-based software system to Kaffe or gcj is essentially impossible.
So, please spare us your cynicism or misleading use of language. Sun's implementation of Java is not "open source" in any sense that the term is commonly understood (and the term was created and defined by Eric Raymond). It isn't even close to open source; you enter into legal obligations to Sun just by looking at it. If you treat it like it's open source, you may get into lots of legal trouble with Sun. Neither are gcj or kaffe an implementation of "Java"; they aren't even close, as you would find out if you tried porting anything to them.
However, we agree on this: gcj is a pretty good compiler, and SWT is a pretty good toolkit. I do recommend using them instead of Sun Java. They also have lots of practical advantages, like being smaller, starting up faster, and requiring less memory. But gcj and SWT together don't make "Java". If you are really careful, you can write libraries that will compile and run under both gcj and Sun Java, but it's a significant amount of work and requires a lot of care (as I can tell you from first hand experience).
I think there is a risk that when an open source project becomes associated with a company that sells support or packaging for it, in order for the company to be able to add value to the product, the open source version ends up being more cumbersome to install or use. That's not necessarily a deliberate strategy, but when it comes down to allocating programmer time, creating a more integrated open source solution probably ends up being low priority--since the perception is that the commerciallly packaged version already addresses that need. I hope that's not the case here with making a more integrated Tcl/Tk source distribution.
If you don't let your integrity get in the way of making a living, what the hell is your integrity worth?
And what does it say about the computer industry and Microsoft if losing the opportunity to work at Microsoft has to be considered a serious problem by someone?
Winning the lottery, participating in a pyramid scheme, or joining the next Microsoft are not viable life plans. For every Microsoft employee that made it, there are hundreds of employees at other companies that worked as hard as you did and didn't make it. In fact, for every Microsoft employee like you, there are probably half a dozen Microsoft employees now that aren't doing any better than anybody else employed by a big company.
So, count your blessings and thank your stars for your good fortune.
And that surprises you? Of course, an organization that makes that much profit treats its employees nicely. Even the most cut-throat Wall St. firms treat their employees to all sorts of perks. Why not? It's peanuts compared to the money that comes in.
And everyone there LOVES Microsoft. They love being part of an org that's in the forefront of technology.
And which organization would that be?
(the stock has flatlined for the past 2 years, but before that it went up something like 50-75% ever year).
And there is little reason to believe that MS stock will resume its spectacular growth. From now on, it will be just another big company. Right now, it's still very profitable, but that will also decline over time.
Programmers who joined Microsoft in 1985 or 1990 also may impress people because it's pretty clear that their stock options made them rich. But over the last couple of years, Microsoft stock has not grown. If you are a programmer for Microsoft, you are roughly in the same financial situation as a programmer for any other big company. And there is no reason to believe that Microsoft stock will ever resume its spectacular growth, even with Microsoft's accounting and business tricks.
(MSFT stock chart here)
People don't "hate" Microsoft because they find Bill Gates annoying, they "hate" Microsoft because Microsoft behaves illegally. And while Microsoft's conduct may Microsoft employees really rich, it costs lots of other people their jobs and livelihood.
I wasn't referring to the appearance, I was referring to design and APIs of iTcl. People have had (I think legitimate) complaints about how large Tcl/Tk projects become difficult to manage, but in my experience, I don't find iTcl helps all that much.
[...] Tk allows you to toss up windows with such minimal code as pack [button .b -text "Hello" -command {puts "Hello World"}]
That was my point: Tcl/Tk is the fastest way I know to create small to medium sized GUIs and it's an enormously practical tool, but the language also has some serious limitations.
In any case, the biggest practical problems with Tcl/Tk I find are that a lot of extensions still aren't part of it: iTcl doesn't ship with Tcl, and drag-and-drop doesn't ship with Tk.
Also, if you look at areas where Tcl/Tk applications compete with applications written in other toolkits (Zircon, Tkabber, etc.), the Tcl/Tk applications may be uglier, but they tend to be far more feature-complete.
Of course, Tcl/Tk has its limits, and something like iTcl/iTk is rather ugly. But overall, it looks to me Tcl/Tk must be doing something right, and it might be well worth for the developers of other GUI tools to try to figure out what that might be so that we might get the best of both worlds.
I'm all for releasing libraries under the GPL. I do so myself. But for something as fundamental as the GUI libraries, and with as many available alternatives, that makes little sense.
Your argument is particularly disingenuous since Stallman, the guy who wrote that note, supports Gnome/Gtk+ the way it is. (At least I have never heard him call for a change to the Gnome/Gtk+ license; if you have, please post a pointer.)
Another thing that makes your argument really bogus is that, as the KDE 2.0 documentation states,
So, obviously, KDE has lots of code under the LGPL. It just happens to have a GPL'ed library for the core GUI functions and then lots of LGPL'ed code built around that. So, to argue that KDE is somehow more free than Gnome because Gnome uses an LGPL'ed toolkit is just wrong. If you are so convinced that the GPL is the right thing for GUI libraries, why don't you stand by your own convictions and cover all KDE libraries under the GPL as well?Also, a dual license is not the same as a pure GPL license. A dual license means that people either have to donate their enhancements to Qt to Troll Tech so that Troll Tech has the option of incorporating them into their commercial product, or they are not going to make it into the Qt distribution. It also means that the evolution of Qt is drive, at least in part, by the commercial interests of Troll Tech; from a free software point of view, for example, there is no reason to burden Qt with supporting Windows or MacOS. That is not what the GPL was intended to achieve. Dual licensing with a GPL component differs substantially from GPL-only licensing.
Altogether, arguments that KDE is somehow "more free" or "more in the spirit of free software" are nonsense. Gnome is doing something very sensible, using the LGPL for the core libraries and using the GPL for applications and some special libraries.