We also ship with a utility called 'switchdesk' that lets you switch with one click between KDE, GNOME, and AnotherLevel (an fvwm-2 configuration). How many other distributions do that?
SuSE had this as early as 5.3 (!). Back then, Gnome 0.30 would install without problems, while RedHat didn't even offer it as a regular install option at the same time. You had to fiddle around to get it running.
I'm not sure what your beef is with paths, either.
Well, I don't know if this is what he meant, but RedHat's interpretation of the FHS is IMHO a bit peculiar. Throwing everfything into/usr/bin isn't the best way to ensure a orderly and clean system. In fact RedHat's KDE setup is so annoying that quite a number of people have suspected this was intentional to make KDE look bad...
As for graphical config tools, I'd say in a feature-to feature comparison Yast and Sax score better than the RedHat tools, so it's not just a matter of opinion. But the main problem of RedHat's distribution is the lack of maturity and careful packaging. This is one of SuSE's strengths. OTOH, RedHat usually offers bleeding edge technology, while SuSE is more conservative (libc, egcs, etc.).
But one thing most of you have overlooked is the fact that RedHat bought DELIX, which makes an excellent, highly underestimated German distribution. It is relatively up-to-date, stable and offers decent ISDN support. If RedHat is clever enough to use Delix' know-how to improve their own distro, they will really be able to become a competitor to SuSE.
I don't think those are numbers supplied by the manufacturer, I guess c't did them themselves. (I'll run and buy one in a minute). And, c't is by far the most reliable source I know of, *far* more reliable than (even) places like Tom's Hardware.
Whenever a cool independent company is swallowed by some other, I hurts a little bit. Sure, it's not quite like AOL purchasing Netscape, but still. Slashdot would have deserved to be an independent name, but alas, there is no such thing as free bandwidth...
On the other hand,/. has never been impartial, so at least I don't have to fear they lose their (non-existant) neutrality;-)
Could you please be more precise? C't is always biased in favor of the more advanced technology (guess what the "t" in c't stands for), and that means they are open to BeOS, Linux/*BSD, (in earlier times) OS/2, and, as they try to be comprehensive, MacOS (X and below).
As for the c't tests, I've yet to find someone who proves serious factual errors therein. On the contrary, c't tests tend to be very sophisticated and neutral. No wonder, as c't employs the best computer tech journalists in the German-speaking world, probably even world wide. Maybe you'd recall
PIII proc ID software switch by processor guru Andreas Stiller,
the SoftRam scandal, where everybody from APC to ZiffDavis hailed this as an ingenious way to get cheap 'Software' RAM, until c't examined that the company had just put non-functional (unused) code to the standart MS libraries...
Well there are many other things I could mention, but in general it's save to say c't is one of the best computer mags worldwide, certainly the best I know (and I know quite a number of US/UK/french ones as well).
After having dealt with static pages, both systems also needed to prove their ability to handle dynamic contents. The smallest common denominator for tasks of this kind is the Common Gateway Interface (CGI). [...] Of course, this configuration is not first choice for generating dynamic HTML pages on a Windows system. An NT administrator would normally prefer Active Server Pages (ASP) and VBScript, which is why these results should rather be read like a CGI or Perl usability test for NT than a proper system comparison. Since Microsoft's solution isn't portable to other systems we unfortunately couldn't make the reverse comparison. And the figures for CGI and ASP aren't really comparable due to theirentirely different underlying concepts.
But the main point is the overall impression. It's a much more differentiated view than the other tests. Particulatly interesting are IMHO IIS's problems with delayed requests (3 sec). This seems to be the downside of the threading approach.
With a little bit of imagination, one could probably find a way to use this as a loophole to develop "in-house" applications that are in fact propritary programmes. With huge international corporations like DaimlerChrysler 'in-house' could be quite big. So you could make additional contracts between (independent) divisions that prevent free distribution without some sort of payment... That way, companies could 'steal' GPL'd code with this clause (they couldn't distribute it outside of the company, but that is not wanted anyway in some cases - the 'intra-corporation' market is big enough). I'm not sure if this could be prevented somehow, but the danger is there, and getting rid of it is not necessarily such a bad thing...
Re:Debian and KDE, the current situation (IIRC)
on
qt 2.0 released
·
· Score: 1
However, some of them feel it is a none issue so they just ignore it ...and they may well be right with that.
The GPL is very unclear when it comes to dynamic linking of any kind (Corba with non-GPL apps will be a mess). Let's face it: The current GPL is not suited for modern software development anymore. Even RMS knows that and is working on a new version.
Until this new version is released, it is IMHO very sensible to just sit back and wait. "Adding a waver" to the KDE-GPL is a hairy thing. What about compatibility to the "plain" GPL, e.g. when combining code...
And while RMS has said once that adding such an amendment would be fine, he has said later, it wouldn't work anyway... As long as the GPL depends on the whim of Mr. Stallman, I wouldn't rush and change things in a hurry. And besides that, as long as no author complains, there is no urgent reason to act. Even RMS was kind of pleased with the latest changes in the QPL (except for the missing code "secrecy"), esp. as they've dropped the patch requirement.
Qt is NOT part of the regular KDE packages (check for yourself). It is expected to be present on the system (and it mostly is).
Debian's problem with KDE was that they couldn't include Qt as a 'system component' as long as it didn't conform to the DFSG. Now that Qt 2 is DFSG-free, Qt can be a system component and the respective clause can be applied.
The situation is by far not as clear as you present it here. And you are not sufficiently up-to-date concerning the QPL.
Indeed. Essentially, the GPL requires that code linked to by a GPL-ed piece of software be under the GPL or under a license that imposes no more restrictions than the GPL (like public domain, the MIT license, or BSD without the ad clause)
The problem is, that this is a very arbitrary interpretation of the GPL except when that code is part of a major system component (something like a proprietary Motif or C library in an environment where they're always present (think Motif on SUN)).
Qt is for Caldera/Corel/easyLinux/etc. what Motif is for SUN.
X doesn't qualify as such a component (you can have a perfectly working Linux system without it, and X is not part of all distributions), so Qt, a layer over X, doesn't either.
Motif is a layer over X just like Qt. There is no difference wrt licensing. And your definition of system component is your own, not that of the GPL. The GPL doesn't say *essential* component. It even mentions the compiler, although a precompiled Linux runs very well without one.
And Qt's license, now the QPL, imposes more restrictions than the GPL (e.g. the "patch requirement" that modified versions may only be distributed as original code + separate modifications).
That's not true anymore. This was the case in the first draft of the QPL, which was heavily critizised for that. The QPL 1.0 only demands that new code is clearly marked as such with info about the coder. The GPL requires the same. There is no "patch requirement" anymore, at most a patch or CVS recommendation. Even RMS admitted that, and you should too. The only remaining problem RMS saw was the "non-non-disclosure" issue. You can't use QPL'd code secretly in-house without notifying TrollTech, while the GPL allows for such quasi-proprietary development. I'm not quite sure if this is rather a loophole in the GPL than a flaw of the QPL.
Even the first version of the QPL (0.90 IIRC) has been declared free software by RMS. He did, however, mention the 'patch clause' as an obstacle.
This patch 'requirement' has been changed into a 'recommendation', i.e. TrollTech recommends using patches (or CVS). The only requirement is that the new, non-TrollTech code be clearly marked as such. That's nothing else than what the GPL requires (and is very sensible, as responsibilities for bugs and possible trojans are more obvious that way).
The QPL is pretty much like the GPL, and the main (or even only) reason why RMS thinks the current QPL is not GPL compatible, is that it doesn't allow 'secret' in-house improvements that aren't distributed outside e.g. a respective company. This is, however, not a problem for average OSS developers, and IMHO it's rather a loophole in the GPL that it allows this than a flaw of the QPL.
c't has a comprehensive test and description of CSS (wannabe) capable browser (unfortunately not online). Gecko is best, even in version M3, followed by Opera and IE5.
Things look pretty bad on the CSS 2 side, though.
Anyway, with IE5 trying to undermine the web standards it's excellent to see Mozilla make progress.
Re:Writing GNOME apps with Qt - Sure
on
The Desktop Wars
·
· Score: 1
Sure that's possible. But I have the impression that more people are dissatisfied with Qt than with gtk, in particular those who want to make Shareware or secret In-House applications (both of which seems to require the proffesional edition of QT). On the other hand, Gnome developers are usually writing in C, and they don't care so much about gtk's lack of proper C++ support (GTK-- is very restricted in the use of C++ features).
So, my point is: When people complain about KDE, then it's usually about QT (i.e. the license). I say that's unfounded, as you can write KDE (compliant) apps with other toolkits like tcl/tk. As GTK is very popular, a KDE support lib would be very helpful for people disliking the Qt license.
Sure, if both environments agreed on more common standards like the XDND, this would be much easier to accomplish...
Of course this statement is true. Doing the same thing two times IS a waste of time in common business sense.
Just, Linux doesn't work this way. If you had, say 100 programmers to do such a job in 2 years, you'd certainly not split them up in two groups. BUT: In this case, you have 0 programmers at hand, and 100k potential ones. If you mobilise only a small part more of this potential by splitting the project, both projects will move on faster.
And that's exactly what happens. The kind of technical rivalry between the two group built up a fierce loyalty on both sides, resulting in more motivated contributors. =>Gnome 1.0, KDE 1.1.1 q.e.d.
But of course there are serious drawbacks, especially when technically superior solutions are shunned because they come from the other camp (NIH syndrome). This was the case with Gnome's window manager hints (just duplicated KDE's effort, just in an incompatible and name space polluting way), and seemed to be similar in the case of the Corba object model (but they do seem to come together now).
As for your points: I don't think KDE and Gnome are so different. I don't see e.g. why "network distribution" is "incompatible" with KDE. Don't forget KDE used CORBA first and are clearly in the lead with their object model already working in KOffice. But as both projects seem to be willing to cooperate now, I see a bright future...
One thing that is overestimated is the toolkit dependence of KDE. Sure, Qt is needed for the basic libs, but as they are free software, this will never be a problem.
But why does everybody think *every* KDE app does need to use Qt? For programmers, KDE is just a framework, and you can easily 'plug in' other toolkits.
Ktk for Tcl/TK A Tixwish extension, Ktk offers KDE look and feel for Tcl/Tk developers, without using Qt
StarOffice 5.0, offers some KDE integration like Drag&Drop, Mimetypes and KMenu support. Its widget set is not publicly available, but it shows this can easily be done.
FLTK supports theming in the next release, which does also include certain KDE support
There is no fundamental problem in writing a KDE support lib for GTK, making it easy to add a certain KDE compliance to GTK apps. Maybe it's not as comprehensive as with Qt apps, but common Drag&Drop, colours, Mimetypes, address book, help system still make it a lot easier for the user.
It could be a compile-time option (like Window Maker), or even a run-time check for the KDE system running. So people won't end up having two desktop environment libs loaded into memory.
Once again: KDE is a open framework for the developer, and an integrated environment for the user. The user doesn't care about which widgets are used, as long as they feel the same. The developers don't have to use Qt to make their apps fit into this environment.
Does anybody know free voice recognition software? KVoiceControl has been mentioned, are there other ones available.
I've got nothing against ViaVoice, but for easier tasks (command recognition, easy texts), it is overkill.
There are a lot of universities working on that, so there should be something available.
Slashdot policy on KDE suscks so bad! - Agreed
on
Quickies a go-go
·
· Score: 1
The last thing you can expect from Slashdot is being impartial.
But I must agree that posting this is really nasty. When creating an cartoonish figure like the KDE mascot, you'll always resemble similar figures so some extent. And dragons are very popular.
But exept for the colour, this 'Crock' doesn't look very much like the KDE dragon, and Stefan certainly didn't think of it. He may have thought of Tabaluga or Urmel from Augsburger Puppenkiste, which is very popular in German-speaking countries. But IMHO the KDE dragon is still unique enough, and in particular it's an excellent piece of work.
As I've said posting this was nasty, as it degrades the work of the artist without giving him the possibility to comment on that. I don't mind Rob posting "Gnome rules" statements all the time, but he should drop those "KDE sucks" ones. Please report rather the newsworthy things about KDE and let people decide on their owm. And yes, KDE themes stuffdoes matter!
The MiniDisk uses a compression technology similar to the MPEG Level 3 Audio format, i.e. eliminating parts fo the music that can't be heard due to 'technical deficiencies' of the human ear.
So you should rather compare CD RAW and MiniDisk RAW (around 80MB,don't know exactly), or better: CD-R with MP3s: ~800min MiniDisk 80min
The important thing with these compression algorithms is to know a lot about how the ear and brain handles audio information, and this means doing a lot of experiments, empirical research (as opposed to creating mathematical algorithms like wavelet compresseion et al). World leader in this area is the IIS Erlangen, which created the MP3 format and is currently working on the successor.
This also explains why it's not so easy to come up with a new -and better- "standard" format, as MS and the music companies would like to...
The Comparison (KDE vs GNOME)
on
CDE vs Gnome
·
· Score: 1
I know OOP is a matter of philosophy, if not ideology, and not only among UNIX developers.
Sure you can use OO concepts in all languages. I had an Amiga Macro Assembler that supported it. But basically it is about using the right tools for the right job, and therefore a language should support OO concepts if you want to use them seriously. It's like opening an beer bottle with a chainsaw: It'possible, it may be even cool, but it is not particularly practical.
We can argue whether or not C++ has very useful OO features, but we should agree that C is entirely inappropriate for OO programming. Sure, you can simulate it with nonstandard means like big macro collections and such, like the Netscape guys did it, but the code becomes extremely messy and the compiler has no possibility to optimize well.
But that's what a language should offer for OOD: compiler optimization of OO features, inheritance mechanisms, polymorphism and the like.
It is very hard (if not impossible) to achieve this with bindings like gtk--, which are based on code written in a procedural language like C.
Anyway, I don't think this is so important in the KDE-GNOME comparison. If you don't agree with these philosophical issues, just forget about it, and read just the rest. My intention was to make clear that there are still important differences between a native toolkit and a wrapper. A point that hasn't been mentioned yet is the difficulty of keeping a wrapper up to date. While this has more or less worked in the case of gtk, the GNOME wrappers are AFAIK pretty outdated in most cases. The same will be true for QT bindings when Qt 2.0 comes out.
The Comparison (KDE vs GNOME)
on
CDE vs Gnome
·
· Score: 1
As Millenium is obviously a GNOME user who has used KDE only occasionally, I will try to reply to his points. For some more comprehensive - and maybe objective - comparisons, you mau consider looking at Ars Technica about KDE, Mininco about GNOME (sorry, has vanished), and Predawnia for a comparison. Another GNOME article is on Linuxworld. Interestingly, only the entirely positive articles about GNOME are posted on Slashdot.
Now for the points mentioned above: Stability I've never had either Gnome or KDE crash my machine. So So you're either very lucky or very lazy. Look at the newsgroups, mailing lists and reviews and you'll see people are *very* annoyed about GNOME's instability. Look at the Predawnia article for more.
functionality In terms of functionality KDE excels in areas Gnome does not, but Gnome too is way ahead of KDE in some areas. I'd call it a flat-out draw in that area. Sorry, but that's an illusion. KDE offers undoubtedly more functionality, if you look at productivity features. You may argue that for technology (CORBA) and eyecandy (widget themes), but there you should compare GNOME -at least until it is really stable- to the most recent KDE, and KOffice technology, which is far ahead of GNOME (CORBA object model technology working for many months, while Baboon isn't even finished).
Looks In terms of looks I doubt anyone can argue against the assertion that Gnome wins, so I won't go into that one here. You are using geeks' standards here: GNOME looks screamingly flashy (what I'd call kitsch; maybe cool for you). KDE looks cleaner and more elegant. All that is a matter of taste. Look at kde.t.o for WM themes or these brand new icons!
Speed and Resources Now, we come to speed. [...] KWM is a BIG problem for KDE; it makes E look stunningly fast and stable.[...] Now there's the matter of resources. I'm afraid Gnome wins it here. It appears to use far less in the way of resources than KDE does. This was probably true for KDE 1.0, it's certainly wrong for KDE 1.1. This is *much* faster and leaner than KDE 1.0. As for resources: Surely you're joking Mr Mil! GNOME needs 3 times as much diskspace than KDE (for about the same functionality), and GNOME panel applets eat memory like crazy! (But that's partly a general problem of CORBA, not so much GNOME's fault) Besides that, many WM are already KDE aware, so you can use Window Maker, Afterstep, or the lean blackbox or flwm if you find KWM too bulky. As much as I love the eyecandy of Enlightenment, saying that E is faster/more stable than KWM is IMHO fiction instead of fact...
Toolkits Raw toolkits: Strip out the desktop environments, and GTK wins out over Qt. This is simply a matter of functionality: GTK offers more than a few things which you can't get with Qt alone. I don't know where you get this information from. Even gtk advocate concede that QT is way ahead in terms of productive features, simply because they started earlier. Take e.g. printing, a pretty basic thing: gtk doesn't offer the respective widgets yet, while it is very easy to implement with QT. (And with all due respect, having pinnable or themable toolbar is not such a top priority). More importantly, we're talking about QT 1.4x here. QT 2 is currently in late beta, and it offers many major improvements. Don't get me wrong, gtk is a nice toolkit, and I'd love to see KDE support for it (like for fltk and tcl/tk), but we should stay realistic.
Programming Language The language issue is irrelevant; several C++ bindings exist for GTK and a set of C bindings is being worked on for Qt You are not an OO programmer, I presume. There is a big difference whether you have OO bindings or a entirely OO structure. Many Object Oriented features (overloading, inheritance etc.) are restricted if you have just bindings. Making a OO lib like QT "flat" by offering a procedural interface (like C) is easier, but many C advocates will still say it's not the ideal solution (less efficient that plain C etc.) Thus, Gtk is still the best choice for C, and QT for OOP and C++ programming. As OOP is more appropriate for GUIs, things look maybe a bit better for QT, but with the large C coder base on Linux, this may still be a draw.
Conclusion: Due to the longer development period, KDE is undoubtedly ahead of GNOME in terms of stability, maturity and productivity. It's much better than its reputation among geeks. GNOME does a good job in offering a more individual and artistic look, so it is well suited for experiments at home.
Linux companies are usually short of money, but in their unlimited benevolence MS lawyers have taken over the position of the Linux Marketing Department.
Out of their sincere love for technological superiority they actively promote Linux as a better alternative and immense competition to Windows, in court and in the media.
Definitely, they just want the best for the customer...
I gather that KDE is further along in terms of development, but is there some fundamental feature that makes it worth looking at?
KDE 1.0 is very easy to use, has nice, consistent looking tools that can interoperate, there are equivalents to most Win tools, and nearly everything can be configured graphically. It also offers the best filemanager for X and the window manager with the most features. kISDN is about the only easy way to set up an ISDN connection if you haven't a SuSE distro.
IN short, it's a must for newbies, great for users, and nice, but not necessary for sysadmins.
KDE 1.1 however, is a totally different beast (should be KDE 2 IMO anyway). It offers *real* functionality, is more flexible, bug-free, better integrated etc. Just to name a few features:
Konqueror, the web browser part of kfm, has dramatically improved. It can absolutely compete with Netscape on most areas now (not Raptor, however, no CSS yet), features Javascript!
New editor (syntax highlighting etc.), terminal emu, many other standard tools improved
kDiskavigator
Much more things configurable in the K Control Center, flexible keybindings, KDE colorsetting for non-KDE apps like XEmacs etc., GUI for keyboard setting, theme manager...
needs less memory, is yet faster (kfm)
better integration and cooperation of apps with system wide address book, better pager, cut&paste util, system info tools...
application like korganizer etc greatly improved.
all known bugs removed
more individual look with easy-to-use theme manager, new icons, wallpapers, themes, Mac-like common menubar
The most important point is the increased maturity. They haven't tried to introduce new and funky technologies and experiments, but made real improvements 'under the hood' not only on the surface.
KDE 1.0 was more or less a 'pretty face' and offered some very useful tools as well (kppp,kisdn,kfm). This will be similar with Gnome 1.0 (which is an even prettier face, and implements some interesting ideas).
KDE 1.1 is a real step forward. It has leading applications on X in nearly all areas, is highly mature and very well integrated with other, non-KDE applications. Together with e.g. StarOffice, you get an extremely competitive system. For home users, it offers much more customizability (like choice of different compliant window managers), and for corporate use it is a proven, secure and stable alternative to Windows. As logical errors in the user interface have beeern largely eradicated, employees will need no long training to use it.
I'm sure many of those bitching here will be pretty surprised by KDE 1.1
If someone is risking to be shot or or imprisoned for what they say here they either live in a society they should work to turn around (not wasting time here) or they shouldn't say it. I have never even gotten an e-mail due to my postings here.
Somebody complained he got several threats of murder after a posting (to a political topic). I am fiercely against discrimination people (here: their opinion) because of their origin, profession or preference (e.g. Windows background etc.). Works should be judged by the results, statements by the quality of the arguments. Judging people by the name (or their willingness to make them public) in unacceptable to me. If somebody gives his name, I tend to trust the facts more, but whenever an argument is based on logic and reason, the name is entirely irrelevant. Linking this to a name seems to me a sign of intolerance and prejudices. The internet offers freedom of speech even to those who would otherwise do not dare use it. Anonymity is a privilige, not a stigma.
This is of course my personal opinion. Others, who value personal integrity (which you would assume under a name) more than logic and reason, may have a different one. So we might prefer to 'agree to disagree' on that matter.
My 'attitude' isn't anymore unnecessary than anything you want to raise your voice against. Such as your questioning about why GNOME isn't using KOM/OpenParts - the users and the developers will choose what they prefer, so your attitude is unnecessary. Voila. This is a bad comparison: It is absolutely necessary to discuss which object model Gnome will be using, as (potentially) millions of users will be affected. If Gnome's object model is compatible to KDE's, we will have overcome the borders of the desktops nearly immediately, resulting in a highly competitive environment with many choices (choice meaning not just running parallel, but embedded within each other). If the object models remain incompatible, we've lost the last chance of 'reuniting' the project on a high level, while remaining the individual character of each. Much time would go into reimplementing apps for the other project, and commercial software vendors would have to choose one (or they'll simply not implement any distributed object technology at all). The best we could posibly get are memory-consuming wrappers to make the two models speak to each other.
To sum it up, the comfort of many users, and perhaps the future of the free Unix desktop is at stake, so I'd hardly call this discussion unnecessary. Once the decision is made, the *users* can't make a decision anymore. They have to accept the fact that they can't use KFormula within Gnumeric. And, believe me, users would always choose the compatible solution!
Slashdot Mirror
We also ship with a utility called 'switchdesk' that lets you switch with one click between KDE, GNOME, and AnotherLevel (an fvwm-2 configuration). How many other distributions do that?
/usr/bin isn't the best way to ensure a orderly and clean system. In fact RedHat's KDE setup is so annoying that quite a number of people have suspected this was intentional to make KDE look bad...
SuSE had this as early as 5.3 (!). Back then, Gnome 0.30 would install without problems, while RedHat didn't even offer it as a regular install option at the same time. You had to fiddle around to get it running.
I'm not sure what your beef is with paths, either.
Well, I don't know if this is what he meant, but RedHat's interpretation of the FHS is IMHO a bit peculiar. Throwing everfything into
As for graphical config tools, I'd say in a feature-to feature comparison Yast and Sax score better than the RedHat tools, so it's not just a matter of opinion.
But the main problem of RedHat's distribution is the lack of maturity and careful packaging. This is one of SuSE's strengths. OTOH, RedHat usually offers bleeding edge technology, while SuSE is more conservative (libc, egcs, etc.).
But one thing most of you have overlooked is the fact that RedHat bought DELIX, which makes an excellent, highly underestimated German distribution. It is relatively up-to-date, stable and offers decent ISDN support. If RedHat is clever enough to use Delix' know-how to improve their own distro, they will really be able to become a competitor to SuSE.
I don't think those are numbers supplied by the manufacturer, I guess c't did them themselves. (I'll run and buy one in a minute).
And, c't is by far the most reliable source I know of, *far* more reliable than (even) places like Tom's Hardware.
Whenever a cool independent company is swallowed by some other, I hurts a little bit.
/. has never been impartial, so at least I don't have to fear they lose their (non-existant) neutrality ;-)
Sure, it's not quite like AOL purchasing Netscape, but still.
Slashdot would have deserved to be an independent name, but alas, there is no such thing as free bandwidth...
On the other hand,
So, no Slashdot boycott for now...
Could you please be more precise?
C't is always biased in favor of the more advanced technology (guess what the "t" in c't stands for), and that means they are open to BeOS, Linux/*BSD, (in earlier times) OS/2, and, as they try to be comprehensive, MacOS (X and below).
As for the c't tests, I've yet to find someone who proves serious factual errors therein.
On the contrary, c't tests tend to be very sophisticated and neutral. No wonder, as c't employs the best computer tech journalists in the German-speaking world, probably even world wide.
Maybe you'd recall
PIII proc ID software switch by processor guru Andreas Stiller,
the SoftRam scandal, where everybody from APC to ZiffDavis hailed this as an ingenious way to get cheap 'Software' RAM, until c't examined that the company had just put non-functional (unused) code to the standart MS libraries...
Well there are many other things I could mention, but in general it's save to say c't is one of the best computer mags worldwide, certainly the best I know (and I know quite a number of US/UK/french ones as well).
But the main point is the overall impression. It's a much more differentiated view than the other tests. Particulatly interesting are IMHO IIS's problems with delayed requests (3 sec). This seems to be the downside of the threading approach.
With a little bit of imagination, one could probably find a way to use this as a loophole to develop "in-house" applications that are in fact propritary programmes.
With huge international corporations like DaimlerChrysler 'in-house' could be quite big. So you could make additional contracts between (independent) divisions that prevent free distribution without some sort of payment...
That way, companies could 'steal' GPL'd code with this clause (they couldn't distribute it outside of the company, but that is not wanted anyway in some cases - the 'intra-corporation' market is big enough).
I'm not sure if this could be prevented somehow, but the danger is there, and getting rid of it is not necessarily such a bad thing...
However, some of them feel it is a none issue so they just ignore it
...and they may well be right with that.
The GPL is very unclear when it comes to dynamic linking of any kind (Corba with non-GPL apps will be a mess).
Let's face it: The current GPL is not suited for modern software development anymore. Even RMS knows that and is working on a new version.
Until this new version is released, it is IMHO very sensible to just sit back and wait. "Adding a waver" to the KDE-GPL is a hairy thing. What about compatibility to the "plain" GPL, e.g. when combining code...
And while RMS has said once that adding such an amendment would be fine, he has said later, it wouldn't work anyway... As long as the GPL depends on the whim of Mr. Stallman, I wouldn't rush and change things in a hurry.
And besides that, as long as no author complains, there is no urgent reason to act. Even RMS was kind of pleased with the latest changes in the QPL (except for the missing code "secrecy"), esp. as they've dropped the patch requirement.
Sure you can use the system library exception.
Qt is NOT part of the regular KDE packages (check for yourself).
It is expected to be present on the system (and it mostly is).
Debian's problem with KDE was that they couldn't include Qt as a 'system component' as long as it didn't conform to the DFSG.
Now that Qt 2 is DFSG-free, Qt can be a system component and the respective clause can be applied.
The situation is by far not as clear as you present it here.
And you are not sufficiently up-to-date concerning the QPL.
Indeed. Essentially, the GPL requires that code linked to by a GPL-ed piece of software be under the GPL or under a license that imposes no more restrictions than the GPL (like public domain, the MIT license, or BSD without the ad clause)
The problem is, that this is a very arbitrary interpretation of the GPL except when that code is part of a major system component (something like a proprietary Motif or C library in an environment where they're always present (think Motif on SUN)).
Qt is for Caldera/Corel/easyLinux/etc. what Motif is for SUN.
X doesn't qualify as such a component (you can have a perfectly working Linux system without it, and X is not part of all distributions), so Qt, a layer over X, doesn't either.
Motif is a layer over X just like Qt. There is no difference wrt licensing.
And your definition of system component is your own, not that of the GPL. The GPL doesn't say *essential* component. It even mentions the compiler, although a precompiled Linux runs very well without one.
And Qt's license, now the QPL, imposes more restrictions than the GPL (e.g. the "patch requirement" that modified versions may only be distributed as original code + separate modifications).
That's not true anymore. This was the case in the first draft of the QPL, which was heavily critizised for that. The QPL 1.0 only demands that new code is clearly marked as such with info about the coder. The GPL requires the same.
There is no "patch requirement" anymore, at most a patch or CVS recommendation.
Even RMS admitted that, and you should too.
The only remaining problem RMS saw was the "non-non-disclosure" issue. You can't use QPL'd code secretly in-house without notifying TrollTech, while the GPL allows for such quasi-proprietary development.
I'm not quite sure if this is rather a loophole in the GPL than a flaw of the QPL.
Regarding the 'freedom' of Qt, may I point you to my other post, as I've followed the licensing discussions for quite a while.
It's here.
Even the first version of the QPL (0.90 IIRC) has been declared free software by RMS. He did, however, mention the 'patch clause' as an obstacle.
This patch 'requirement' has been changed into a 'recommendation', i.e. TrollTech recommends using patches (or CVS). The only requirement is that the new, non-TrollTech code be clearly marked as such.
That's nothing else than what the GPL requires (and is very sensible, as responsibilities for bugs and possible trojans are more obvious that way).
The QPL is pretty much like the GPL, and the main (or even only) reason why RMS thinks the current QPL is not GPL compatible, is that it doesn't allow 'secret' in-house improvements that aren't distributed outside e.g. a respective company.
This is, however, not a problem for average OSS developers, and IMHO it's rather a loophole in the GPL that it allows this than a flaw of the QPL.
To find the original sources please go to the Troll pages and the KDE licensing mailing list.
c't has a comprehensive test and description of CSS (wannabe) capable browser (unfortunately not online). Gecko is best, even in version M3, followed by Opera and IE5.
Things look pretty bad on the CSS 2 side, though.
Anyway, with IE5 trying to undermine the web standards it's excellent to see Mozilla make progress.
Sure that's possible. But I have the impression that more people are dissatisfied with Qt than with gtk, in particular those who want to make Shareware or secret In-House applications (both of which seems to require the proffesional edition of QT).
On the other hand, Gnome developers are usually writing in C, and they don't care so much about gtk's lack of proper C++ support (GTK-- is very restricted in the use of C++ features).
So, my point is:
When people complain about KDE, then it's usually about QT (i.e. the license). I say that's unfounded, as you can write KDE (compliant) apps with other toolkits like tcl/tk.
As GTK is very popular, a KDE support lib would be very helpful for people disliking the Qt license.
Sure, if both environments agreed on more common standards like the XDND, this would be much easier to accomplish...
Of course this statement is true. Doing the same thing two times IS a waste of time in common business sense.
Just, Linux doesn't work this way.
If you had, say 100 programmers to do such a job in 2 years, you'd certainly not split them up in two groups. BUT: In this case, you have 0 programmers at hand, and 100k potential ones. If you mobilise only a small part more of this potential by splitting the project, both projects will move on faster.
And that's exactly what happens. The kind of technical rivalry between the two group built up a fierce loyalty on both sides, resulting in more motivated contributors.
=>Gnome 1.0, KDE 1.1.1 q.e.d.
But of course there are serious drawbacks, especially when technically superior solutions are shunned because they come from the other camp (NIH syndrome). This was the case with Gnome's window manager hints (just duplicated KDE's effort, just in an incompatible and name space polluting way), and seemed to be similar in the case of the Corba object model (but they do seem to come together now).
As for your points: I don't think KDE and Gnome are so different. I don't see e.g. why "network distribution" is "incompatible" with KDE.
Don't forget KDE used CORBA first and are clearly in the lead with their object model already working in KOffice.
But as both projects seem to be willing to cooperate now, I see a bright future...
One thing that is overestimated is the toolkit dependence of KDE. Sure, Qt is needed for the basic libs, but as they are free software, this will never be a problem.
But why does everybody think *every* KDE app does need to use Qt? For programmers, KDE is just a framework, and you can easily 'plug in' other toolkits.
Ktk for Tcl/TK A Tixwish extension, Ktk offers KDE look and feel for Tcl/Tk developers, without using Qt
StarOffice 5.0, offers some KDE integration like Drag&Drop, Mimetypes and KMenu support. Its widget set is not publicly available, but it shows this can easily be done.
FLTK supports theming in the next release, which does also include certain KDE support
There is no fundamental problem in writing a KDE support lib for GTK, making it easy to add a certain KDE compliance to GTK apps. Maybe it's not as comprehensive as with Qt apps, but common Drag&Drop, colours, Mimetypes, address book, help system still make it a lot easier for the user.
It could be a compile-time option (like Window Maker), or even a run-time check for the KDE system running.
So people won't end up having two desktop environment libs loaded into memory.
Once again:
KDE is a open framework for the developer, and an integrated environment for the user.
The user doesn't care about which widgets are used, as long as they feel the same. The developers don't have to use Qt to make their apps fit into this environment.
Does anybody know free voice recognition software?
KVoiceControl has been mentioned, are there other ones available.
I've got nothing against ViaVoice, but for easier tasks (command recognition, easy texts), it is overkill.
There are a lot of universities working on that, so there should be something available.
The last thing you can expect from Slashdot is being impartial.
But I must agree that posting this is really nasty. When creating an cartoonish figure like the KDE mascot, you'll always resemble similar figures so some extent. And dragons are very popular.
But exept for the colour, this 'Crock' doesn't look very much like the KDE dragon, and Stefan certainly didn't think of it. He may have thought of Tabaluga or Urmel from Augsburger Puppenkiste, which is very popular in German-speaking countries.
But IMHO the KDE dragon is still unique enough, and in particular it's an excellent piece of work.
As I've said posting this was nasty, as it degrades the work of the artist without giving him the possibility to comment on that.
I don't mind Rob posting "Gnome rules" statements all the time, but he should drop those "KDE sucks" ones.
Please report rather the newsworthy things about KDE and let people decide on their owm.
And yes, KDE themes stuff does matter!
The MiniDisk uses a compression technology similar to the MPEG Level 3 Audio format, i.e. eliminating parts fo the music that can't be heard due to 'technical deficiencies' of the human ear.
So you should rather compare CD RAW and MiniDisk RAW (around 80MB,don't know exactly), or better:
CD-R with MP3s: ~800min
MiniDisk 80min
The important thing with these compression algorithms is to know a lot about how the ear and brain handles audio information, and this means doing a lot of experiments, empirical research (as opposed to creating mathematical algorithms like wavelet compresseion et al).
World leader in this area is the IIS Erlangen, which created the MP3 format and is currently working on the successor.
This also explains why it's not so easy to come up with a new -and better- "standard" format, as MS and the music companies would like to...
I know OOP is a matter of philosophy, if not ideology, and not only among UNIX developers.
Sure you can use OO concepts in all languages. I had an Amiga Macro Assembler that supported it.
But basically it is about using the right tools for the right job, and therefore a language should support OO concepts if you want to use them seriously.
It's like opening an beer bottle with a chainsaw: It'possible, it may be even cool, but it is not particularly practical.
We can argue whether or not C++ has very useful OO features, but we should agree that C is entirely inappropriate for OO programming. Sure, you can simulate it with nonstandard means like big macro collections and such, like the Netscape guys did it, but the code becomes extremely messy and the compiler has no possibility to optimize well.
But that's what a language should offer for OOD:
compiler optimization of OO features, inheritance mechanisms, polymorphism and the like.
It is very hard (if not impossible) to achieve this with bindings like gtk--, which are based on code written in a procedural language like C.
Anyway, I don't think this is so important in the KDE-GNOME comparison. If you don't agree with these philosophical issues, just forget about it, and read just the rest.
My intention was to make clear that there are still important differences between a native toolkit and a wrapper. A point that hasn't been mentioned yet is the difficulty of keeping a wrapper up to date. While this has more or less worked in the case of gtk, the GNOME wrappers are AFAIK pretty outdated in most cases. The same will be true for QT bindings when Qt 2.0 comes out.
As Millenium is obviously a GNOME user who has used KDE only occasionally, I will try to reply to his points.
For some more comprehensive - and maybe objective - comparisons, you mau consider looking at Ars Technica about KDE, Mininco about GNOME (sorry, has vanished), and Predawnia for a comparison.
Another GNOME article is on Linuxworld.
Interestingly, only the entirely positive articles about GNOME are posted on Slashdot.
Now for the points mentioned above:
Stability
I've never had either Gnome or KDE crash my machine.
So So you're either very lucky or very lazy. Look at the newsgroups, mailing lists and reviews and you'll see people are *very* annoyed about GNOME's instability. Look at the Predawnia article for more.
functionality
In terms of functionality KDE excels in areas Gnome does not, but Gnome too is way ahead of KDE in some areas. I'd call it a flat-out draw in that area.
Sorry, but that's an illusion. KDE offers undoubtedly more functionality, if you look at productivity features.
You may argue that for technology (CORBA) and eyecandy (widget themes), but there you should compare GNOME -at least until it is really stable- to the most recent KDE, and KOffice technology, which is far ahead of GNOME (CORBA object model technology working for many months, while Baboon isn't even finished).
Looks
In terms of looks I doubt anyone can argue against the assertion that Gnome wins, so I won't go into that one here.
You are using geeks' standards here: GNOME looks screamingly flashy (what I'd call kitsch; maybe cool for you). KDE looks cleaner and more elegant. All that is a matter of taste. Look at kde.t.o for WM themes or these brand new icons!
Speed and Resources
Now, we come to speed. [...] KWM is a BIG problem for KDE; it makes E look stunningly fast and stable.[...]
Now there's the matter of resources. I'm afraid Gnome wins it here. It appears to use far less in the way of resources than KDE does.
This was probably true for KDE 1.0, it's certainly wrong for KDE 1.1. This is *much* faster and leaner than KDE 1.0.
As for resources: Surely you're joking Mr Mil! GNOME needs 3 times as much diskspace than KDE (for about the same functionality), and GNOME panel applets eat memory like crazy! (But that's partly a general problem of CORBA, not so much GNOME's fault)
Besides that, many WM are already KDE aware, so you can use Window Maker, Afterstep, or the lean blackbox or flwm if you find KWM too bulky.
As much as I love the eyecandy of Enlightenment, saying that E is faster/more stable than KWM is IMHO fiction instead of fact...
Toolkits
Raw toolkits: Strip out the desktop environments, and GTK wins out over Qt. This is simply a matter of functionality: GTK offers more than a few things which you can't get with Qt alone.
I don't know where you get this information from. Even gtk advocate concede that QT is way ahead in terms of productive features, simply because they started earlier. Take e.g. printing, a pretty basic thing: gtk doesn't offer the respective widgets yet, while it is very easy to implement with QT. (And with all due respect, having pinnable or themable toolbar is not such a top priority).
More importantly, we're talking about QT 1.4x here. QT 2 is currently in late beta, and it offers many major improvements.
Don't get me wrong, gtk is a nice toolkit, and I'd love to see KDE support for it (like for fltk and tcl/tk), but we should stay realistic.
Programming Language
The language issue is irrelevant; several C++ bindings exist for GTK and a set of C bindings is being worked on for Qt
You are not an OO programmer, I presume. There is a big difference whether you have OO bindings or a entirely OO structure. Many Object Oriented features (overloading, inheritance etc.) are restricted if you have just bindings.
Making a OO lib like QT "flat" by offering a procedural interface (like C) is easier, but many C advocates will still say it's not the ideal solution (less efficient that plain C etc.)
Thus, Gtk is still the best choice for C, and QT for OOP and C++ programming. As OOP is more appropriate for GUIs, things look maybe a bit better for QT, but with the large C coder base on Linux, this may still be a draw.
Conclusion: Due to the longer development period, KDE is undoubtedly ahead of GNOME in terms of stability, maturity and productivity. It's much better than its reputation among geeks.
GNOME does a good job in offering a more individual and artistic look, so it is well suited for experiments at home.
Linux companies are usually short of money, but in their unlimited benevolence MS lawyers have taken over the position of the Linux Marketing Department.
Out of their sincere love for technological superiority they actively promote Linux as a better alternative and immense competition to Windows, in court and in the media.
Definitely, they just want the best for the customer...
KDE 1.0 is very easy to use, has nice, consistent looking tools that can interoperate, there are equivalents to most Win tools, and nearly everything can be configured graphically. It also offers the best filemanager for X and the window manager with the most features. kISDN is about the only easy way to set up an ISDN connection if you haven't a SuSE distro.
IN short, it's a must for newbies, great for users, and nice, but not necessary for sysadmins.
KDE 1.1 however, is a totally different beast (should be KDE 2 IMO anyway).
It offers *real* functionality, is more flexible, bug-free, better integrated etc.
Just to name a few features:
The most important point is the increased maturity. They haven't tried to introduce new and funky technologies and experiments, but made real improvements 'under the hood' not only on the surface.
I'm sure many of those bitching here will be pretty surprised by KDE 1.1
But SuSE says that the "X" server link is an executable and thus does not belong in /etc. ARGH!
/etc. If at all, it's a X problem.
And they're right about it. Executable files don't belong into
As for the rest, they've apparently changed a couple of things for 6.0. Let's see.
Anyway, for home users, SuSE is still way better than RedHat.
Now finally something that's more than vapour on the Amiga front.
And MUI is a really great toolkit. It's theming capabilities make gtk look pale.
Now if only those serial ports would be a bit faster on my Amiga...
If someone is risking to be shot or or imprisoned for what they say here they either live in a society they should work to turn around (not wasting time here) or they shouldn't say it.
I have never even gotten an e-mail due to my postings here.
Somebody complained he got several threats of murder after a posting (to a political topic).
I am fiercely against discrimination people (here: their opinion) because of their origin, profession or preference (e.g. Windows background etc.). Works should be judged by the results, statements by the quality of the arguments. Judging people by the name (or their willingness to make them public) in unacceptable to me. If somebody gives his name, I tend to trust the facts more, but whenever an argument is based on logic and reason, the name is entirely irrelevant. Linking this to a name seems to me a sign of intolerance and prejudices. The internet offers freedom of speech even to those who would otherwise do not dare use it. Anonymity is a privilige, not a stigma.
This is of course my personal opinion. Others, who value personal integrity (which you would assume under a name) more than logic and reason, may have a different one.
So we might prefer to 'agree to disagree' on that matter.
My 'attitude' isn't anymore unnecessary than anything you want to raise your voice against. Such as your questioning about why GNOME isn't using KOM/OpenParts - the users and the developers will choose what they prefer, so your attitude is unnecessary. Voila.
This is a bad comparison: It is absolutely necessary to discuss which object model Gnome will be using, as (potentially) millions of users will be affected.
If Gnome's object model is compatible to KDE's, we will have overcome the borders of the desktops nearly immediately, resulting in a highly competitive environment with many choices (choice meaning not just running parallel, but embedded within each other).
If the object models remain incompatible, we've lost the last chance of 'reuniting' the project on a high level, while remaining the individual character of each. Much time would go into reimplementing apps for the other project, and commercial software vendors would have to choose one (or they'll simply not implement any distributed object technology at all). The best we could posibly get are memory-consuming wrappers to make the two models speak to each other.
To sum it up, the comfort of many users, and perhaps the future of the free Unix desktop is at stake, so I'd hardly call this discussion unnecessary. Once the decision is made, the *users* can't make a decision anymore. They have to accept the fact that they can't use KFormula within Gnumeric.
And, believe me, users would always choose the compatible solution!