I've never quite figured out people who are opposed to software patents. Sure, they can be
abused (like Amazon's "one-click" patent), but is that any reason to throw the baby out with the
bathwater? Large corporations, though they are much maligned on Slashdot, invest billions of
dollars in research and development.
I have developed a number of new algorithms and software methods, both while working as a consultant and while working for various corporate research labs.
In my experience, trying to patent software methods is pointless for the individual inventor. For two methods that are in fairly wide use now, I actually tried going through with it as an individual. The legal costs just for getting the patent are staggering and you do not have a prayer of enforcing your patent without devoting your life to it. Besides, most individual inventors do not want to become lawyers, and the process of trying to get patent protection is not only very expensive, it's also very time consuming.
In my corporate life, I hold several patents. My company likes them because they can trade with other companies. That's of great value to them, even though the patents themselves probably each cost them as much as a year's salary. Corporations make patent applications really easy: you write an informal note, corporate lawyers get to work on it fleshing it out in legal language that will hold up in court, and the patent gets submitted. Afterwards, there are lots of efforts involved in marketing the patents, trading the portfolio, and looking for infringements.
While companies like to point at their patent revenue stream and say "this is all the money we get from patents, and it funds further research", in practice, I have my doubts that purely financially, it results in a net gain once you add in all the administrative costs. I think the reason why big companies like software patents is because they allow them to limit competition from small companies, and that is very attractive even if it costs lots of money.
Based on nearly two decades of experience in the software industry, as far as I can tell, the net effect of software patents is to:
allow large companies to create legal and financial barriers to entry for small companies and inventors
keep small inventors out because they can't afford to create a meaningful, solid patent portfolio, or to enforce it
threaten open source software because open source software is pretty much the only kind of software where patent infringement can be determined without a huge legal battle
While color calibrationists are pushing the idea that there is some ideal notion of "accurate" that monitors can be made to conform to, the reality is much messier: color perception depends intricately on context, monitors cannot even begin to match the visual experience of real pigments and dyes, a wide range of "calibrations" are visually acceptable, and different people have different preferences and perceptions.
So, what should you do? Often, you can work reasonably well without more than a rough calibration. In fact, most critical color correction can be done completely in black and white--matching known colors (logos, skin color, neutrals) correctly is actually better and much more accurately done numerically than "by eye". Once you have established those anchor colors, you have a visual context, and you can fiddle with the other, less specific colors around them by eye without worrying too much about monitor calibration.
For on-line applications, you need to worry even less: none of your colors will display "accurately" on most machines anyway. You simply have to make sure that your images look OK on "average" PCs. While having a consistent starting point for designing those kinds of images is kind of nice, most good graphics cards and good monitors are probably going to be "in the ballpark" if they are reasonably well set up.
Maybe you really do need calibration for some of your applications; I have occasionally needed it for some really obscure work. But I think in many cases people want calibration for all the wrong reasons: for print work, calibration isn't accurate enough, and for on-line work, it doesn't help you much.
OpenOffice (the free version of StarOffice) has been released under the GPL/LGPL. Sun can't take that back for future versions. The same is true for many other open source efforts.
That is very different from Microsoft's subscription model. MS Office is not open source. If you subscribe to it, you have to stop using it when your subscription runs out. You don't get to keep using even the old binary version.
As for keeping down the useless features, what makes you think it will do that? If companies send lots of money per seat to Microsoft, they expect something back in return. And if they don't get anything, they'll wonder why they pay Microsoft lots of money merely for the right to continue using software whose development costs have been paid for many times over.
Microsoft has always had a strong incentive to tie their users to their company with overly complex, proprietary file formats and with intricate user interfaces that get people hooked quickly and keep them with the software. None of that is going to change with the subscription model.
Mostly what the subscription model does is allow companies to engage in more creative accounting techniques to reduce sticker shock for Microsoft software. That's good for Microsoft and it's bad for anybody else. And that's exactly why Microsoft is doing it.
Microsoft holds no one anymore hostage than Standard Oil. You want to drive a normal car, you buy gasoline. You
want to operate a normal business computer, you run Office.
Very good analogy, indeed. Standard Oil was broken up because they were close to becoming the only supplier of gasoline. By analogy, it is clear that Microsoft ought to be broken up because they have become the only supplier of Office. Just like we should ensure a supply of gasoline from many competing vendors, we should ensure a supply of office software from many competing vendors.
Office, if I'm not mistaken, is business productivity software.
Arguably, you are mistaken about the "productivity" part: most people would probably be more productive without the upgrades (and consequent retraining and format conversions) Microsoft forces upon the industry every year.
Still JFS's at least save you time after a crash and I think the still provide higher data Security because you have the Journalling Log,
JFS will appear to save you time after a crash, but you will more than pay for that in extra time spent while doing each and every disk operation. If your production machine dies once every few months, you will be spending a total of days or weeks in wasted computer time on JFS operations, compared to a few minutes of running fsck at boot time. And with all that, JFS still doesn't guarantee that your data is intact.
And, again, the journalling only recovers file system structure; it makes no guarantees about your file system contents.
However even if some or another JFS becomes the standard with Linux that doesn't mean you have to use it.
One of the big attractions of Linux is that it's easy to install. If distributions start standardizing on some form of JFS, everybody will have to deal with it. Even if I have the wherewithal not to configure my systems to use it, other people will be doing it. They'll be complaining about lousy performance and unexpectedly lost data, putting Linux in a bad light.
And stating you dropped AIX for Linux is quite ridicolous because the two don't really use the same hardware.
What does using the same hardware have to do with that? Of course, I started using PC hardware and retiring the PPC-based machines. Some of us really do use Linux for real-world applications and have a choice of hardware, you know.
I think it might be worth considering switching to XML for many system and config files. That preserves the traditional UNIX approach of having files that are user-readable and can be modified with a text editor or scripts. But it would add the capability of having a single set of tools for dealing with things like network configuration, PnP configuration, firewalls,/proc information files, etc.
JFS journals file system structures, it doesn't journal data and doesn't guarantee "data integrity". It doesn't even guarantee file system integrity, it only guards against a limited set of events. With JFS, you still have to back up your data, use RAID, or mirror it because you will still lose it sooner or later. All it saves you is running fsck when you boot up your machine, but you pay a heavy price in runtime performance for that. For the price you pay in performance, you can probably buy a mirroring solution and switch over when you need to, resulting in much better data security and lower downtimes than any journalling solution.
Some commercial users will probably not want to use a UNIX system without journalling, whether it is rational or not. But I hope JFS and the like won't become the standard on Linux: I switched to Linux in part because I found AIX's JFS so intolerable.
If you buy a gadget that infringes on some patent, the patent holder has full rights to demand that you either pay them royalties or stop using that gadget. If you continue to use it, you are in violation of their patent. The only claim you have is against the person that sold you the infringing gadget in the first place.
We seem to entrust vital decisions in our lives to unvalidated, unscientific, suboptimal methods. Fingerprint identification methods apparently have never been statistically verified. Many of the voting machines and methods we use also lack scientific evaluations of their reliability and margin of error.
As long as the people who fund voting machines and police labs don't understand what is necessary, the money for accurate scientific evaluations doesn't get allocated. And that comes ultimately down to scientific illiteracy.
It's ironic that the guy who likely will have to fix this, George "W" Bush, and his staff (including Jams Baker) have displayed such a stunning lack of scientific literacy themselves by proclaiming, without evidence, that "machine counts are more reliable".
The $1500 you pay for Qt is quite perishable: it entitles you to only one year of upgrades and free E-mail. Since the base operating systems change more frequently than that, you will have to upgrade pretty much every year. Furthermore, it is "personal" for each developer, so if people change on the project, it looks like you have to buy new licenses.
So, your amortization over the lifetime of the company doesn't work. Many companies will have to keep buying Qt licenses, not just every year, but every time they get a new person on board to replace an existing developer.
Whether it's worth it or not should be up to each company to decide for themselves. We have licensed different commercial toolkits in the past, after careful evaluation, so I have no problem in principle with licensing commercial software. What I have a problem with is if my commercial choices get limited because a company uses the open source community as a marketing gimmick.
If Troll Tech succeeds at becoming the predominant toolkit for the Linux desktop, there won't be any choice anymore: commercial developers will have to buy their toolkit because that's what their customers will expect from "professional" applications. The situation won't be any different than it is with MFC on Windows right now.
The fact is that, right now, Qt is QPL/GPL while Gtk+ is LGPL. Eazel's business model doesn't change that. And I see no problem with either Eazel or KDE distributing GPL'ed applications. At issue is the license of the underlying toolkit.
For many kinds of libraries, assuming that funding is needed at all, I would agree with your statement that Troll Tech's business model is the most plausible one and may represent the best compromise. But for something as central and as well understood as GUI libraries, it seems unnecessary to make that compromise because there are alternatives.
Big players like Sun and RedHat have an intrinsic interest in seeing a high quality set of GUI libraries available on Linux platforms to make Linux a viable platform and increase its adoption. Those companies make their money from systems sales, not supporting a GUI library. Therefore, they can (and apparently do) afford supporting Gnome/Gtk as a free toolkit even for commercial applications.
As for all the scenarios you paint, I don't see a problem at all. Gtk is LGPL, and that can't be taken back. Mozilla is MPL. If people build, in accordance with the license, commercial software based on free software and you don't like the commercial software, just don't use it. If Troll Tech released Qt under the MPL and built a commercial browser with lots of banner ads on it, that would be just fine with me.
I actually also have serious doubts that big commercial funding is really needed at the toolkit level (it may be needed at the application level). There are probably half a dozen well-designed GUI toolkits besides Qt and Gtk out there. The issue is really one of market share and acceptance.
Yes, both desktops are nice and both are "free" in some sense of the word. There are some important technical differences between the two, but neither is clearly better in that regard.
The difference is really in terms of licensing. People can develop commercial GUI applications with Gnome/Gtk+ without paying anybody. With KDE/Qt, commercial developers need to pay Troll Tech.
Some people seem to believe that the KDE/Qt approach, making commercial users pay, is more in the spirit of free software, while others believe that it will limit the adoption of any system based on Qt and that the free software community should not be doing the marketing and bug fixing for a commercial vendor. I suspect those differences of opinion won't get resolved either, but they are genuine, rational, and don't amount to "flaming".
Leaving aside the issues of "free software philosophy", look at what kind of business proposition this comes down to for commercial users of Linux. If they develop for Gnome/Gtk+ (or wxWindows, or any of a number of other free toolkits) all they need is a free copy of Linux to get their developers working. With KDE/Qt, they need to pay $1500/developer; that's more than people pay for a very complete, industry-standard Microsoft development environment.
And what interest does a commercial vendor have in supporting KDE and Troll Tech? RedHat won't see a dime of Troll Tech's revenue stream; they'd simply be investing a lot of money in marketing someone else's product, and they'd be increasing the cost for their customers to adopt their own product. Everybody who uses or supports Qt ultimately primarily contributes to the commercial interests of Troll Tech: increasing their market share and improving their commercial product.
I think KDE2 is technically quite well done. But the KDE/Qt license (GPL/QPL), while better than a pure GPL, is simply not commercially competitive when there are half a dozen of reasonable and LGPL or BSD toolkits around.
Ideally, RedHat or some other open source company would buy out Troll Tech and put Qt under the LGPL or a BSD license. Under its current license, I think KDE/Qt will be harmful to both free software and the commercial acceptance of free software.
And, according to NPR, Gore retook New Mexico again today because some election official had confused the digits "1" and "6". Correcting the mistake gave Gore 500 extra votes.
Is it free and open source? If not, you risk investing a lot of time and effort in something that may go away when the company disappears.
Is it well designed? Proven? Can standard tools (emacs, etc.) cope with the syntax? Too much flexibility in defining and extending the syntax can be disadvantageous for languages, in particular if you expect to have multiple programmers working on a project.
Are there available alternatives? There are zillions of nice little scripting languages for all sorts of purposes. Many of them have extensive tool support. Just some that come to mind are Perl, Python, PHP, Lua, Scheme, Pike, Tcl/Tk, JavaScript, VBScript, and Visual Basic.
Altogether, I'm doubtful that the world needs another scripting language, in particular one that seems to allow tricky syntactic redefinitions and appears to be proprietary as well.
Python has been successful because it's an easy-to-use, simple language that integrates well with UNIX systems. That's the "market" I think Python should stick to.
And, nice as Python is, there is some room for improvement in its role as a scripting and VHLL for UNIX. Module configuration even in 2.0 is somewhat messy (configure, compile, edit Setup, compile some more). There is still nothing quite like CPAN and the CPAN shell module for Perl. Documentation is still more difficult to get to than "perldoc". Despite distutils, Python extensions still sometimes don't "just" install. And building C extensions could also be greatly simplified with a bit more support from the Python installation. Just about the only language enhancement I would like to see for now is lexical closures, not because I think its functionality is desparately needed, but because it would simplify scoping rules if done right.
I think Python is at risk of going down the same path as other dynamic languages before it. Adding a lot of new features (continuations, type declarations, list comprehensions, etc.) complicates the language to the point where people may not feel comfortable just picking the language up anymore. And the effort that goes into those fun features is effort that doesn't go into making the language even easier to install and interface with.
CLX has been open source for 15 years, and it is available here. CLX is the CommonLisp X interface, a widely used low-level toolkit for interfacing Lisp programs to X11.
This is, incidentally, the first Google result that pops up for CLX. I wish vendors would at least do a websearch before picking a name for a product. In this case, it's particularly confusing because both CLX and Borland's toolkit are about interfacing programs to window systems.
As for the announcement itself, let's wait and see what actually happens. This could be little more than the source code Microsoft includes with MSDN, which is largely useless to anybody who hasn't also bought their product.
QT/Embedded includes a big bunch of applications [...] That is much better then X11 and any other toolkit.
Without tuning and with support for multiple graphics cards and lots of extensions compiled in, the X server is about 2.2M and the FLTK toolkit is about 0.5M. With tuning and adaptation to PDA hardware, you can easily cut those in half. That leaves plenty of room for applications like an address book, word processor, and MPEG player and still stay under 2-3M, the size claimed for Qt/Embedded.
We are down to arguing differences in the few 100k range. Even if those were in favor of Qt/Embedded, they would be insignificant. But the disadvantages of Qt/Embedded, tying yourself to a single vendor and toolkit and giving up network transparent access, are huge.
"800kb to 3Mb" isn't any better than a tuned implementation of X11 with FLTK as a toolkit; in fact, it's worse.
Of course, it's better for Troll Tech, because by taking over the screenbuffer, you cannot use any other toolkit besides theirs. If their software catches on for the basic, open source software on Linux-based PDAs, all commercial developers will be forced to license their software, no matter what their competitors offer. KDE's use of Qt isn't quite as harmful to competition because non-Qt applications can live side-by-side with it, but with Qt/Embedded the takeover of the UI for the purpose of commercial tie-ins is complete.
I hope the free software community is smarter than to be taken advantage of in this way.
X servers are quite "svelte" in principle. For years, I was using a hardware accelerated X11 server on a 20MHz 386 running UNIX with 4Mbytes of memory. And PDA-based X11 servers are trying to get back to their frugal beginnings.
The reason why X servers these days take much more space on your desktop is because they are configured that way, because the screen memory often counts against them, and because clients (including Gtk and Qt-based ones) aren't written to conserve server side memory.
And in the bargain, you become a marketing tool for Troll Tech. Your bug fixes and suggestions become help improve their commercial software. The add-ons you produce enhance the value of their commercial product through network effects. We both may not like the possibility that commercial vendors take advantage of free software efforts, but with Troll Tech, it's not a possibility, it's a certainty.
If Troll Tech were to become the predominant GUI platform for handheld Linux devices, development for those devices would become more expensive than even proprietary systems like Windows CE. In fact, with their handheld architecture, their software will not live side-by-side with alternative, free toolkits. That kind of "charity" by commercial vendors will kill free software, not support it.
Troll Tech is free to license their software whichever way they want. But I think people who buy into the bargain are foolish, in particular if they think that this kind of marketing gimmick has anything to do with free software.
But in the end, I still see this huge fact staring out from the window of reality: people who are charging money for their own software are bitching that Trolltech is doing the same.
I think it's simplistic to view the world as divided into the evil people who charge for "Closed Source" software and the good people who produce "Open Source" software. In fact, most people who make such decisions do so as individuals, people who sometimes develop open source software, who sometimes develop commercial software for others, and who sometimes convince their employers to turn commercial projects into open source projects.
The fact is that if you, as an individual, invest time and effort into Qt, you immediately become a marketing tool for Troll Tech. That's the bargain. If you take on a commercial job after a couple of years of work with Qt, you'll probably try to convince your employer to buy Qt rather than something else. And if you contribute feedback, bug fixes, or enhancements to Qt, you contribute to Troll Tech's bottom line. In doing so, Troll Tech is just as much taking commercial advantage of free software as someone who uses an LGPL'ed library and doesn't voluntarily share their sources.
Yes, LGPL'ed and BSD'ed libraries might be abused by people I work for. But by using them, I don't immediately sign up to become a marketing tool for a commercial software vendor; the commercial abuse of those tools is someone else's doing, not mine. And by sharing software freely, I think LGPL'ed and BSD'ed libraries are leading by example.
From a purely practical point of view, there are nice cross-platform alternatives to Qt which are much less restrictive for me personally when I write open source software, and I don't think it is "bitching" to point this out. And from a philosophical point of view, if the kind of thinking that underlies Troll Tech's business model takes hold, I think you can kiss the free software movement goodbye.
If I ask myself "do I want to write an open or closed application", the answer is "both". And Troll Tech knows that that is true of many people. That's why their free offer isn't so free: they can count on a big fraction of their "free" users to eventually pay. It's neither "fair" nor "unfair" on their part to propose that bargain, and it's neither "fair" nor "unfair" on my part to say "no thanks"; that might have been a good deal compared to Motif, but I don't think it's a good deal compared to the other available alternatives.
And from the point of view of promoting open source software, I think the kind of opportunism Troll Tech represents is ultimately harmful. You lead by example, and a transparent commercial bargain like the one Troll Tech proposes is not the example I would like to see companies emulate. If Linux imposed the same restrictions on software that is based on it as Troll Tech's license imposes on Qt applications, Linux would not stand a chance at widespread adoption.
I think in the current environment, choosing GPL for something as fundamental as a GUI library is, ultimately, harmful to the goals of free software. You are welcome to disagree with that assessment.
Efforts like these by Microsoft aren't about hardcore programmers. Someone who is really "into" C++ will easily transition from Visual C++ to GNU C++ on Linux.
Microsoft's drive into schools is to hook end users who may also program. Scientists who need to do some calculations, business people who will be writing some VB add-ons for spreadsheets, etc. Microsoft doesn't care about the hardcore programmers because they know that those ultimately will have to program in whatever environment end users demand their software to run on.
Realistically, these users are going to face Microsoft software eventually, and they won't have the interest to learn a lot of new stuff. But the best thing from the perspective of the users is probably still to learn programming based on well-designed, non-proprietary tools like Python. That way, they learn skills that help them on Windows right away without being dragged irretrievably into the Microsoft marketing maul.
Of course, what is irritating about the whole process is that Microsoft can probably get tax write-offs for all those "educational contributions". We should really ask ourselves whether contributions like those shouldn't be written off at the incremental cost of producing an extra unit, which would be close to $0 for software.
Oh really. How is learning motif easier then the mfc classes?
What does Motif have to do with anything? wxWindows, FLTK, and Gnome certainly are easier to learn and use than MFC, and they are a lot better designed.
Have you even read the unix haters manual? X is terrible
The UNIX Hater's Handbook is many things, but it isn't a serious evaluation of technical merits.
languages like visual basic are alot easier to learn if your new to programming.
Easier than what? UNIX has a full complement of programming languages, including excellent beginner's languages, including Python, Logo, Scheme, and others. UNIX even had Basic long before VB existed.
ALso its now the year 2,000 and xwindows still does not support true type fonts. Incredible!
The X window system has supported scalable fonts since long before Windows did. And it has even supported TrueType fonts for a few years, although I don't see why support for a proprietary Apple/Microsoft standard is relevant to anything.
I am sick of looking up archane commands in text files. I am sick of poorly docuemented api's. I am sick of shell scripting.
Well, Windows won't save you from any of those if you try to do any significant work on it.
Slashdot Mirror
I have developed a number of new algorithms and software methods, both while working as a consultant and while working for various corporate research labs.
In my experience, trying to patent software methods is pointless for the individual inventor. For two methods that are in fairly wide use now, I actually tried going through with it as an individual. The legal costs just for getting the patent are staggering and you do not have a prayer of enforcing your patent without devoting your life to it. Besides, most individual inventors do not want to become lawyers, and the process of trying to get patent protection is not only very expensive, it's also very time consuming.
In my corporate life, I hold several patents. My company likes them because they can trade with other companies. That's of great value to them, even though the patents themselves probably each cost them as much as a year's salary. Corporations make patent applications really easy: you write an informal note, corporate lawyers get to work on it fleshing it out in legal language that will hold up in court, and the patent gets submitted. Afterwards, there are lots of efforts involved in marketing the patents, trading the portfolio, and looking for infringements.
While companies like to point at their patent revenue stream and say "this is all the money we get from patents, and it funds further research", in practice, I have my doubts that purely financially, it results in a net gain once you add in all the administrative costs. I think the reason why big companies like software patents is because they allow them to limit competition from small companies, and that is very attractive even if it costs lots of money.
Based on nearly two decades of experience in the software industry, as far as I can tell, the net effect of software patents is to:
So, what should you do? Often, you can work reasonably well without more than a rough calibration. In fact, most critical color correction can be done completely in black and white--matching known colors (logos, skin color, neutrals) correctly is actually better and much more accurately done numerically than "by eye". Once you have established those anchor colors, you have a visual context, and you can fiddle with the other, less specific colors around them by eye without worrying too much about monitor calibration.
For on-line applications, you need to worry even less: none of your colors will display "accurately" on most machines anyway. You simply have to make sure that your images look OK on "average" PCs. While having a consistent starting point for designing those kinds of images is kind of nice, most good graphics cards and good monitors are probably going to be "in the ballpark" if they are reasonably well set up.
Maybe you really do need calibration for some of your applications; I have occasionally needed it for some really obscure work. But I think in many cases people want calibration for all the wrong reasons: for print work, calibration isn't accurate enough, and for on-line work, it doesn't help you much.
That is very different from Microsoft's subscription model. MS Office is not open source. If you subscribe to it, you have to stop using it when your subscription runs out. You don't get to keep using even the old binary version.
As for keeping down the useless features, what makes you think it will do that? If companies send lots of money per seat to Microsoft, they expect something back in return. And if they don't get anything, they'll wonder why they pay Microsoft lots of money merely for the right to continue using software whose development costs have been paid for many times over.
Microsoft has always had a strong incentive to tie their users to their company with overly complex, proprietary file formats and with intricate user interfaces that get people hooked quickly and keep them with the software. None of that is going to change with the subscription model.
Mostly what the subscription model does is allow companies to engage in more creative accounting techniques to reduce sticker shock for Microsoft software. That's good for Microsoft and it's bad for anybody else. And that's exactly why Microsoft is doing it.
Very good analogy, indeed. Standard Oil was broken up because they were close to becoming the only supplier of gasoline. By analogy, it is clear that Microsoft ought to be broken up because they have become the only supplier of Office. Just like we should ensure a supply of gasoline from many competing vendors, we should ensure a supply of office software from many competing vendors.
Office, if I'm not mistaken, is business productivity software.
Arguably, you are mistaken about the "productivity" part: most people would probably be more productive without the upgrades (and consequent retraining and format conversions) Microsoft forces upon the industry every year.
JFS will appear to save you time after a crash, but you will more than pay for that in extra time spent while doing each and every disk operation. If your production machine dies once every few months, you will be spending a total of days or weeks in wasted computer time on JFS operations, compared to a few minutes of running fsck at boot time. And with all that, JFS still doesn't guarantee that your data is intact.
And, again, the journalling only recovers file system structure; it makes no guarantees about your file system contents.
However even if some or another JFS becomes the standard with Linux that doesn't mean you have to use it.
One of the big attractions of Linux is that it's easy to install. If distributions start standardizing on some form of JFS, everybody will have to deal with it. Even if I have the wherewithal not to configure my systems to use it, other people will be doing it. They'll be complaining about lousy performance and unexpectedly lost data, putting Linux in a bad light.
And stating you dropped AIX for Linux is quite ridicolous because the two don't really use the same hardware.
What does using the same hardware have to do with that? Of course, I started using PC hardware and retiring the PPC-based machines. Some of us really do use Linux for real-world applications and have a choice of hardware, you know.
I think it might be worth considering switching to XML for many system and config files. That preserves the traditional UNIX approach of having files that are user-readable and can be modified with a text editor or scripts. But it would add the capability of having a single set of tools for dealing with things like network configuration, PnP configuration, firewalls, /proc information files, etc.
Some commercial users will probably not want to use a UNIX system without journalling, whether it is rational or not. But I hope JFS and the like won't become the standard on Linux: I switched to Linux in part because I found AIX's JFS so intolerable.
If you buy a gadget that infringes on some patent, the patent holder has full rights to demand that you either pay them royalties or stop using that gadget. If you continue to use it, you are in violation of their patent. The only claim you have is against the person that sold you the infringing gadget in the first place.
As long as the people who fund voting machines and police labs don't understand what is necessary, the money for accurate scientific evaluations doesn't get allocated. And that comes ultimately down to scientific illiteracy.
It's ironic that the guy who likely will have to fix this, George "W" Bush, and his staff (including Jams Baker) have displayed such a stunning lack of scientific literacy themselves by proclaiming, without evidence, that "machine counts are more reliable".
So, your amortization over the lifetime of the company doesn't work. Many companies will have to keep buying Qt licenses, not just every year, but every time they get a new person on board to replace an existing developer.
Whether it's worth it or not should be up to each company to decide for themselves. We have licensed different commercial toolkits in the past, after careful evaluation, so I have no problem in principle with licensing commercial software. What I have a problem with is if my commercial choices get limited because a company uses the open source community as a marketing gimmick.
If Troll Tech succeeds at becoming the predominant toolkit for the Linux desktop, there won't be any choice anymore: commercial developers will have to buy their toolkit because that's what their customers will expect from "professional" applications. The situation won't be any different than it is with MFC on Windows right now.
For many kinds of libraries, assuming that funding is needed at all, I would agree with your statement that Troll Tech's business model is the most plausible one and may represent the best compromise. But for something as central and as well understood as GUI libraries, it seems unnecessary to make that compromise because there are alternatives.
Big players like Sun and RedHat have an intrinsic interest in seeing a high quality set of GUI libraries available on Linux platforms to make Linux a viable platform and increase its adoption. Those companies make their money from systems sales, not supporting a GUI library. Therefore, they can (and apparently do) afford supporting Gnome/Gtk as a free toolkit even for commercial applications.
As for all the scenarios you paint, I don't see a problem at all. Gtk is LGPL, and that can't be taken back. Mozilla is MPL. If people build, in accordance with the license, commercial software based on free software and you don't like the commercial software, just don't use it. If Troll Tech released Qt under the MPL and built a commercial browser with lots of banner ads on it, that would be just fine with me.
I actually also have serious doubts that big commercial funding is really needed at the toolkit level (it may be needed at the application level). There are probably half a dozen well-designed GUI toolkits besides Qt and Gtk out there. The issue is really one of market share and acceptance.
The difference is really in terms of licensing. People can develop commercial GUI applications with Gnome/Gtk+ without paying anybody. With KDE/Qt, commercial developers need to pay Troll Tech.
Some people seem to believe that the KDE/Qt approach, making commercial users pay, is more in the spirit of free software, while others believe that it will limit the adoption of any system based on Qt and that the free software community should not be doing the marketing and bug fixing for a commercial vendor. I suspect those differences of opinion won't get resolved either, but they are genuine, rational, and don't amount to "flaming".
And what interest does a commercial vendor have in supporting KDE and Troll Tech? RedHat won't see a dime of Troll Tech's revenue stream; they'd simply be investing a lot of money in marketing someone else's product, and they'd be increasing the cost for their customers to adopt their own product. Everybody who uses or supports Qt ultimately primarily contributes to the commercial interests of Troll Tech: increasing their market share and improving their commercial product.
I think KDE2 is technically quite well done. But the KDE/Qt license (GPL/QPL), while better than a pure GPL, is simply not commercially competitive when there are half a dozen of reasonable and LGPL or BSD toolkits around. Ideally, RedHat or some other open source company would buy out Troll Tech and put Qt under the LGPL or a BSD license. Under its current license, I think KDE/Qt will be harmful to both free software and the commercial acceptance of free software.
And, according to NPR, Gore retook New Mexico again today because some election official had confused the digits "1" and "6". Correcting the mistake gave Gore 500 extra votes.
Is it well designed? Proven? Can standard tools (emacs, etc.) cope with the syntax? Too much flexibility in defining and extending the syntax can be disadvantageous for languages, in particular if you expect to have multiple programmers working on a project.
Are there available alternatives? There are zillions of nice little scripting languages for all sorts of purposes. Many of them have extensive tool support. Just some that come to mind are Perl, Python, PHP, Lua, Scheme, Pike, Tcl/Tk, JavaScript, VBScript, and Visual Basic.
Altogether, I'm doubtful that the world needs another scripting language, in particular one that seems to allow tricky syntactic redefinitions and appears to be proprietary as well.
And, nice as Python is, there is some room for improvement in its role as a scripting and VHLL for UNIX. Module configuration even in 2.0 is somewhat messy (configure, compile, edit Setup, compile some more). There is still nothing quite like CPAN and the CPAN shell module for Perl. Documentation is still more difficult to get to than "perldoc". Despite distutils, Python extensions still sometimes don't "just" install. And building C extensions could also be greatly simplified with a bit more support from the Python installation. Just about the only language enhancement I would like to see for now is lexical closures, not because I think its functionality is desparately needed, but because it would simplify scoping rules if done right.
I think Python is at risk of going down the same path as other dynamic languages before it. Adding a lot of new features (continuations, type declarations, list comprehensions, etc.) complicates the language to the point where people may not feel comfortable just picking the language up anymore. And the effort that goes into those fun features is effort that doesn't go into making the language even easier to install and interface with.
This is, incidentally, the first Google result that pops up for CLX. I wish vendors would at least do a websearch before picking a name for a product. In this case, it's particularly confusing because both CLX and Borland's toolkit are about interfacing programs to window systems.
As for the announcement itself, let's wait and see what actually happens. This could be little more than the source code Microsoft includes with MSDN, which is largely useless to anybody who hasn't also bought their product.
Without tuning and with support for multiple graphics cards and lots of extensions compiled in, the X server is about 2.2M and the FLTK toolkit is about 0.5M. With tuning and adaptation to PDA hardware, you can easily cut those in half. That leaves plenty of room for applications like an address book, word processor, and MPEG player and still stay under 2-3M, the size claimed for Qt/Embedded.
We are down to arguing differences in the few 100k range. Even if those were in favor of Qt/Embedded, they would be insignificant. But the disadvantages of Qt/Embedded, tying yourself to a single vendor and toolkit and giving up network transparent access, are huge.
Of course, it's better for Troll Tech, because by taking over the screenbuffer, you cannot use any other toolkit besides theirs. If their software catches on for the basic, open source software on Linux-based PDAs, all commercial developers will be forced to license their software, no matter what their competitors offer. KDE's use of Qt isn't quite as harmful to competition because non-Qt applications can live side-by-side with it, but with Qt/Embedded the takeover of the UI for the purpose of commercial tie-ins is complete.
I hope the free software community is smarter than to be taken advantage of in this way.
The reason why X servers these days take much more space on your desktop is because they are configured that way, because the screen memory often counts against them, and because clients (including Gtk and Qt-based ones) aren't written to conserve server side memory.
If Troll Tech were to become the predominant GUI platform for handheld Linux devices, development for those devices would become more expensive than even proprietary systems like Windows CE. In fact, with their handheld architecture, their software will not live side-by-side with alternative, free toolkits. That kind of "charity" by commercial vendors will kill free software, not support it.
Troll Tech is free to license their software whichever way they want. But I think people who buy into the bargain are foolish, in particular if they think that this kind of marketing gimmick has anything to do with free software.
I think it's simplistic to view the world as divided into the evil people who charge for "Closed Source" software and the good people who produce "Open Source" software. In fact, most people who make such decisions do so as individuals, people who sometimes develop open source software, who sometimes develop commercial software for others, and who sometimes convince their employers to turn commercial projects into open source projects.
The fact is that if you, as an individual, invest time and effort into Qt, you immediately become a marketing tool for Troll Tech. That's the bargain. If you take on a commercial job after a couple of years of work with Qt, you'll probably try to convince your employer to buy Qt rather than something else. And if you contribute feedback, bug fixes, or enhancements to Qt, you contribute to Troll Tech's bottom line. In doing so, Troll Tech is just as much taking commercial advantage of free software as someone who uses an LGPL'ed library and doesn't voluntarily share their sources.
Yes, LGPL'ed and BSD'ed libraries might be abused by people I work for. But by using them, I don't immediately sign up to become a marketing tool for a commercial software vendor; the commercial abuse of those tools is someone else's doing, not mine. And by sharing software freely, I think LGPL'ed and BSD'ed libraries are leading by example.
From a purely practical point of view, there are nice cross-platform alternatives to Qt which are much less restrictive for me personally when I write open source software, and I don't think it is "bitching" to point this out. And from a philosophical point of view, if the kind of thinking that underlies Troll Tech's business model takes hold, I think you can kiss the free software movement goodbye.
And from the point of view of promoting open source software, I think the kind of opportunism Troll Tech represents is ultimately harmful. You lead by example, and a transparent commercial bargain like the one Troll Tech proposes is not the example I would like to see companies emulate. If Linux imposed the same restrictions on software that is based on it as Troll Tech's license imposes on Qt applications, Linux would not stand a chance at widespread adoption.
I think in the current environment, choosing GPL for something as fundamental as a GUI library is, ultimately, harmful to the goals of free software. You are welcome to disagree with that assessment.
Microsoft's drive into schools is to hook end users who may also program. Scientists who need to do some calculations, business people who will be writing some VB add-ons for spreadsheets, etc. Microsoft doesn't care about the hardcore programmers because they know that those ultimately will have to program in whatever environment end users demand their software to run on.
Realistically, these users are going to face Microsoft software eventually, and they won't have the interest to learn a lot of new stuff. But the best thing from the perspective of the users is probably still to learn programming based on well-designed, non-proprietary tools like Python. That way, they learn skills that help them on Windows right away without being dragged irretrievably into the Microsoft marketing maul.
Of course, what is irritating about the whole process is that Microsoft can probably get tax write-offs for all those "educational contributions". We should really ask ourselves whether contributions like those shouldn't be written off at the incremental cost of producing an extra unit, which would be close to $0 for software.
What does Motif have to do with anything? wxWindows, FLTK, and Gnome certainly are easier to learn and use than MFC, and they are a lot better designed.
Have you even read the unix haters manual? X is terrible
The UNIX Hater's Handbook is many things, but it isn't a serious evaluation of technical merits.
languages like visual basic are alot easier to learn if your new to programming.
Easier than what? UNIX has a full complement of programming languages, including excellent beginner's languages, including Python, Logo, Scheme, and others. UNIX even had Basic long before VB existed.
ALso its now the year 2,000 and xwindows still does not support true type fonts. Incredible!
The X window system has supported scalable fonts since long before Windows did. And it has even supported TrueType fonts for a few years, although I don't see why support for a proprietary Apple/Microsoft standard is relevant to anything.
I am sick of looking up archane commands in text files. I am sick of poorly docuemented api's. I am sick of shell scripting.
Well, Windows won't save you from any of those if you try to do any significant work on it.