Slashdot Mirror

i dont understand why RMS would be angry at the KDE team at all now... they use the GPL (and so does the QT library, despite popular belief). whereas GTK+ (which GNOME is built on) uses the LGPL . it seems ironic that RMS would therefore support GNOME over KDE, when KDE use his 'favourite' licence...

also, there was no need for RMS to ask such a redundant question as "GNU/Linux or Linux?" to the team, he could have looked here ;-)

does anyone have a mirror of this story? the server has been totally slashdotted...

i dont understand why RMS would be angry at the KDE team at all now... they use the GPL (and so does the QT library, despite popular belief). whereas GTK+ (which GNOME is built on) uses the LGPL . it seems ironic that RMS would therefore support GNOME over KDE, when KDE use his 'favourite' licence...

also, there was no need for RMS to ask such a redundant question as "GNU/Linux or Linux?" to the team, he could have looked here ;-)

does anyone have a mirror of this story? the server has been totally slashdotted...

i dont understand why RMS would be angry at the KDE team at all now... they use the GPL (and so does the QT library, despite popular belief). whereas GTK+ (which GNOME is built on) uses the LGPL . it seems ironic that RMS would therefore support GNOME over KDE, when KDE use his 'favourite' licence...

also, there was no need for RMS to ask such a redundant question as "GNU/Linux or Linux?" to the team, he could have looked here ;-)

does anyone have a mirror of this story? the server has been totally slashdotted...

Parts of Mac OS are Free. The Darwin core is open source, the Safari browser is based on an open source core, which is based on KHTML and KJS. Tell me it's not Free. (And, all the stuff under the Darwin link is Free too!)

For example Microsoft can buy Apple (perhaps not monopoly wise) and cripple the BSD kernel so Apple users can only play DRM'ed WMA's.

Unless they've changed things recently, Apple uses a Mach kernel for OS X (at the bottom of the page under the heading "Core OS"), not a BSD kernel.

This is of course theoretical, but KHTML (for KDE Konqueror) has had code back from Apple, due to GPL. I seriously doubt they had provided their changes if KHTML was BSD-licensed.

Actually, the libraries that Apple used from KDE (KHTML and KJS) are covered under the LGPL. The LGPL being a little bit different than the GPL, this has two implications: (1) Apple is not obliged to send any code back KDE's way; and (2) it is what keeps Apple from having to distribute the source code to Safari (the whole static-dynamic linkage issue aside). If the KDE libraries had been covered by the GPL apple most likely would have had to distribute the code to Safari, and I suspect this was one of the reasons Apple selected the KDE libraries over competing libraries from Mozilla.

And you can use Qt without creating a GUI, right?

Were you one of those people who thought this was real? It's not

"Apple can help their long term position by leveling the internet playing field and thus making migration to a non Windows platform that much smoother."

Although I agree building these from scratch is a great learning (and waiting) experience, I do recommend things like Garnome or Konstruct to build those. They worked a treat when I set up my LFS box (which is now a gentoo box again though).

Of course, when I want to finish off a machine quickly, I just use FreeBSD and be done with it :)

Cut and paste mirror link from previous article.. I'm going to fire him so hard when I get in to work Monday...

Must you use the magic word, Kappa Delta Edward?

Why not use Konstruct instead of typing all this manually?

This has already been discussed, look better and here. Thats the beauty of opensource. It gets better.

This has already been discussed, look better and here. Thats the beauty of opensource. It gets better.

Koffeemaker - for KDE hot drinks

Not far from reality, see the about box of KTeaTime:
"KDE utility for making a fine cup of tea"

It is not the outlook client that is of most interest, it is replacing exchange as backend that we should replace first...

Kolab server already does this [replacing exchange servers]. It works with either Outlook clients, or KMail clients.

we still don't have a decent graphical user interface desktop solution for Linux.

Dude, you need to put down the glue. We have two kickass graphical interface desktop solutions.

Have you even tried running Linux?

Erik

kes!

Go gou grust ge?
Kuck Koff Kuntil Kou kimplemented ka kEAL kesktop kenviornment

-1, kroll, klamekait, kfftopfic.

This sucks
Semi propeitery works better!

FP and flamebait!

Better still: Try this for the project homepage

Forgot the darned 'http://'... Grrr...

KDE 3.0.5b and KDE 3.1.1a were announced today to address a Ghostscript-related vulnerability.

Read it and weep

When I read this I thought of Valgrind. It's a program designed to find memory management problems such as memory leaks and using unitialised memory. The program being tested runs under Valgrind so it is very much like a virtual machine. I've never thought of running a server under it, but if you can stand the (probably substantial) performance hit it would probably do what you're intending.

Better read this article first, don't want to be stuck with not be able to configure your computer.

i completely agree with the idea in the article. More effort should (IMHO) be put into making each 'segment buster' application the best in all Computerdom (TM). For instance, look at the "diversity" of Instant messangers for GNU/Linux. There are millions (search for msn, icq, yahoo, jabber) on Sourceforge to see all these projects.

The "best" way (IMHO) for GNU/Linux to pull into the lead is to follow the 'apache' (gimp) (sorta) idea: central core builds versatile framework, places emphasis on extensability (to draw in help by plugin/module writers) and the synergy happens... because Apache is the 'leading' opensource app in its sphere A) people write the mods B) people deploy it so C) see A.

M$ is going to have a VERY hard time busting in the webserver market unless it employs some famous monopoly tricks (.net, passport renders 'webserver' un-usuable/un-necessary/???)

A good example is IMHO the tact taken by the KDE team with Kopete. Here we have the "official kde IM client". Developed with interoperation with KDE at its core. With extensability as a central design imperative. Ive actually spent time writting messages in the forums of freshmeat to 'competing' im clients asking to look at Kopete and implement their features THERE instead. I forsee Kopete becoming the best GNU/Linux IM client because of these design goals AND this 'official' status.

Im running a little here, but I cannot AGREE MORE with this article, its assumptions and the goals described. GNU/Linux needs to cast off some of the 'also rans' (not banish them--not tell them they arnt invited etc) but sorta "PICK A LEADER" and try and get people to rally around and run with it. Writing it from the 'ground up' to encourage this (facilitate quick uptake by new/passing developers) is necessary, but having projects like FSF picking Official GNU Applications, GNOME picking "official IM" or "official sound server"*, KDE picking "official IM"* only helps highlight and lend credibility (proving "staying power" (no one likes to see there work dumped - so people who fix bugs, add features would want to ADD them to something that has a future (...like apache modules ))).

I would like to see this meme develope into a War Cry for GNU/Linux.

*only until GNOME/KDE merge. ;)

Just as the roadmap talks about embedding Minotaur into Phoenix, the way forward for the calendar could be as an embedded extension for Minotaur.

Some people like a standalone mail/news client that isn't your jack-of-all-trades Outlook/Evolution replacement. That's going to be Minotaur.

But Minotaur could also be an Outlook replacement for those who are looking for that sort of solution. Allow the calendar to be installed as an extension (like Phoenix's extensions) and you've got three of the main features of a PIM (mail, address book, calendar). Develop some sort of stickynote-style scratchpad extension and you've mostly got the whole thing.

Evolution at the moment is only available for Linux and friends, and it seems as if there are no plans for a Windows port any time soon. This would provide a lever for those on Windows to abandon MS Office entirely. I mean, OpenOffice.org replaces much of the rest of MS Office bar Outlook; a Minotaur that can be extended to be that Outlook replacement would finish the job.

Not to mention having a further competitor to Evolution on Unix and Linux, particularly once Kontact gets going.

Going the extension route makes far more sense than adding the Calendar to the monolithic Mozilla suite, slowing everybody down.

And anyway, does a stand-alone calendar really make sense? A stand-alone Composer perhaps. But a calendar naturally fits into a PIM environment - surely this is the way forward?

Thexder.

Nope, that's in KDE :-)

At home I also use IMAP, it is just great, it's a shame its so hard to find a good graphical (I come from windows world so I do like my graphical app sometime) imap client for linux (sylpheed I tried and don't like, which leaves mozilla-mail and that is what I call heavy taking 2mins just to check mail, I use it anyway, but I can't wait for minotaur).

Hard? No, I wouldn't say that. Kmail, which has won various awards, fully supports IMAP. Screenshots are here.

Evolution, which is basically a feature-for-feature clone of Microsoft Outlook, also supports IMAP. Screenshots are here.

I've used both and they are both excellent GUI mail clients. I've also used IMAP with both, and their support of IMAP is very good. Evolution is nice because it is a total PIM/Groupware solution, while kmail is a nice "just-a-mail-client" app (it's a lot like Eudora). Both support nice filtering options for POP3 mail. With IMAP you really need server side filtering, though as there is no standards for filtering mail on IMAP. Both support multiple mail accounts and servers and multiple protocols. Both apps support all standard Unix mail formats, including mbox and maildir. In addition, Evolution supports Eudora, Netscape and Outlook Express mailboxes.

Both are nice apps, each has their strengths and weaknesses, but both are open source and run on many Unix platforms and of course Linux.

You may want to keep an eye on the Kroupware Project with it's kolab server: http://kroupware.kde.org

It requires a commercial plugin from outlook and is currently beta, but it could be one for the future.

If you want rigorous definitions, you'll be working entirely within an abstract system. [...]

I really should have put a smiley at the end of my first paragraph. This was meant to be an ironic jab against the verbosity which seems to often occur both at debian-legal and in philosophic circles. Sorry. In fact, I really think you are very right esp. with the first two sentences of the post I answered to.

So the reason you prefer GPL instead of BSD is that Microsoft might come out with a better product for a short period of time, during which time some developers might become demotivated and the open source developers would become demotivated?

Searching on google indeed shows that some developers themselves think that (not all links there, but I found two with a quick glance on the summary texts). There are at least some developers not wanting to have *big company* use their code in proprietary products.

And yes, I really think this is a big difference to the case where a group of developers starts an open source project in order to catch up with an existing proprietary product. Again, I'll use google for some empirical evidence.

I'm not a GPL zealot. I also prefer practical solutions and see the problems with zealotry in any camp. One example is debian and QT/KDE after the Kde Free QT Foundation was founded, which btw. still exists today! Another is linux-kernel and bitkeeper, or Bruce Perens and his GPL/linux diatribes. But I also think that in dealing with legal stuff (i.e. licenses) one has to be careful and consequent.
My main point is that indeed there's irrationality involved, and this has to be taken into account for the best success of any project.
So your claim (paraphrased):

People who think GPL is necessary are (a) [...] or (b) [...] or (c) irrational.

is always true, therefore not very significant.

I would say that the SuSE OpenExchange server is a pretty good solution, overall. It is still not perfect but, it does work and it is fairly well integrated. BUt, I do have an issue with it. The price of OpenExchage server is too high. Indeed, for a shop of the size you describe, it costs almost as much as MS Exchange 2000.

SuSE OpenExchange is a combination of open source applications that have been nicely integrated with each other, by SuSe. It is built using Postfix for the MTA, Cyrus for IMAP, OpenLDAP for the directory, Apache for the web interface, and a few others.

However, there are other simialr solutions available, that you should look at too. SCO makes Volution Messaging, recently renamed to Office Mail Server. Also, there is the Kolab (I refuse to call it Kroupware) project. All three solutions use the Postfix, Cyrus, OpenLDAP, Apache, etc components stitched together to create a unified groupware system.

One major distinction between the three solutions is price. While OpenExchange and Office Mail Server are NOT cheap, Kolab is FREE.

Did you Vote for Linux?

Depends on your needs, really. I happen to like the integrated approach KDE's taking with their Kroupware project that's supposed to be merged into KDE 3.2. It provides integrated PIM features that make sense, like being able to manage contacts, and calander information from a single group of windows; the default app is the mail app, which you'll probably have running most of the time anyways, with additional programs executed as needed. It makes sense, really. Usually when you're looking someone's info up, you're going to be using that info pretty immediately, so why not have it already at your fingertips. It's got some rough edges as far as appearance goes, but it works pretty well right now, and it's based on open standards.

Depends on your needs, really. I happen to like the integrated approach KDE's taking with their Kroupware project that's supposed to be merged into KDE 3.2. It provides integrated PIM features that make sense, like being able to manage contacts, and calander information from a single group of windows; the default app is the mail app, which you'll probably have running most of the time anyways, with additional programs executed as needed. It makes sense, really. Usually when you're looking someone's info up, you're going to be using that info pretty immediately, so why not have it already at your fingertips. It's got some rough edges as far as appearance goes, but it works pretty well right now, and it's based on open standards.

If you don't know how to compile it, then get the RPMS

khtml is LGPL'd

Whatever happened to choice in this debate?

We can choose between various window managers, various linux flavors, and even office suites. Why don't we have a choice with our window system?

Why would it be any different for a fork of X for a choice between client/server and direct rendering, if backwards compatability was kept?
Would that not help the the people who only use Linux on their desktop, while allowing people with networks to use the tool, as it is now, that works for them?

Just go to the adopt-a-geek site! They are screaming for old hardware.

"Can OSS build a mail client/PIM that plays well with Exchange servers?"

Not only that, but the Kolab/ Kroupware project server can even replace exchange servers!

How about if it didn't look like shit. That picture's just one example of the kind of screenshots Linux fans get all excited over (although they're usually a little less colourful than that and with far more ugly flashing lights and terminal windows). Can't you see that it's ugly? Look at the icons -- the spacing is wrong, the font is wrong. Look at the small, unlabeled buttons in the web browser. See the way the bar at the bottom doesn't fill the screen, yet feels the need to duplicate icons from the desktop. That wouldn't be so bad, but it leaves barely any space for the taskbar (with the app titles). Look at the titles of the sections on that page showing in the web browser? They're screwed up and squished. Look at the huge number of pointless menus and other assorted bits everywhere, and compare it to the amount of completely empty unused space. Minimalism in buttons and clickable things (not necessarily in graphical design) is better -- for example, Windows XP's Recycle-Bin-only-by-default desktop and customisable Start menu. I won't even start on the time I tried to change the positions and groups of apps around on the KDE and Gnome graphical menus. No drag-and-drop? No right-click? But I'm getting off the point, so I'll stop. To conclude: Linux distros, especially their GUIs, are big, ugly, slow and needlessly complicated. That's why Linux is not yet ready for the desktop.

Has anyone used the KOrganizer Exchange Plug-in? From this page it appears to need Outlook Web Access activated, saying it needs WebDAV to work. I'm curious if it can do all the features of Outlook/Exchange calendaring, like notification of conflicts, handling of "resources" as well as normal contacts, etc.

IE does not has not moved an inch standards wise since IE 4

That is not true. In ie6, for example, they have finally got the box model right. The css support has come a long way from ie4.

Is it still pathetic compared with mozilla, opera, konqueror, etc? Yes. But don't try and say that they haven't done anything, because it just isn't true.

Just try using a correct XHTML MIME type, or using XHTML DOM (which is read-only in XHTML) or CSS (changes to case rules in XHTML) in IE and it will fail. Mozilla and Opera (and no doubt Konq also) do all the above just fine.

Konqueror does not. See Bug #52665. Last I checked, there was an XHTML icon on the Safari website, but it didn't handle XHTML properly either.

Until MS update IE the web stays looking just as it does now for 70-80% of users, however innovative the rest of the world gets.

Of course, they could just sit back and do nothing, as www authors are pretty much forced to support ie due to its market share.

Here are some high-res screenshots taken from BSD:

on gnome
on kde


BSD is truly free and open.

But if it must be so, the people should receive something in return, such as requiring the code to be open source or at least have it revert to open source after some specified period of time.

In any case I wish someone would fix the damn America's Army bug that still occasionally causes "General Protection Fault" even with GeForce cards, and get the game to work on other cards as well. If it was open source I bet it would be fixed by now.

So we are now seeking more libraries to release under the ordinary GPL.

Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Library GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Library GPL for that library.

I'm all for releasing libraries under the GPL. I do so myself. But for something as fundamental as the GUI libraries, and with as many available alternatives, that makes little sense.

Your argument is particularly disingenuous since Stallman, the guy who wrote that note, supports Gnome/Gtk+ the way it is. (At least I have never heard him call for a change to the Gnome/Gtk+ license; if you have, please post a pointer.)

Another thing that makes your argument really bogus is that, as the KDE 2.0 documentation states,

By far, the most common license for the KDE libraries is LGPL, and the most common for applications is GPL.

Also, a dual license is not the same as a pure GPL license. A dual license means that people either have to donate their enhancements to Qt to Troll Tech so that Troll Tech has the option of incorporating them into their commercial product, or they are not going to make it into the Qt distribution. It also means that the evolution of Qt is drive, at least in part, by the commercial interests of Troll Tech; from a free software point of view, for example, there is no reason to burden Qt with supporting Windows or MacOS. That is not what the GPL was intended to achieve. Dual licensing with a GPL component differs substantially from GPL-only licensing.

Altogether, arguments that KDE is somehow "more free" or "more in the spirit of free software" are nonsense. Gnome is doing something very sensible, using the LGPL for the core libraries and using the GPL for applications and some special libraries.

A small but vocal minority appear to be dead-set against using even GObject, which only tackles a small subset of the problem of code sharing - the idea of using GObject seems to scare them witless. I wouldn't normally name names, but it's starting to get very irritating. Neil Stevens and Zack Rusin in particular, (there are others) consistantly object whenver the possibility of using something based on GObject (even when wrapped in the KDE style) is brought up.

Can you give a link to this discussion? I've searched the mail archives at lists.kde.org but I can't find any mails from Zach Rusin discussing the GObject issue.

Also, it doesn't seem fair to bitch in Slashdot about people because they don't support the path you would like for KDE. If you have technical arguments for your position, present them in the appropriate mailing list. If you don't, name-calling is not the solution.

In other messages you've admitted you don't even know C++, so your experience in KDE development must be inevitably small. These people probably know quite a lot more than you about KDE's internal workings, so why not show a little respect for their position.

Harmony is pretty dead... if you want to see how dead it is, go to the old kde-freeqt mailing list here . Hasn't had messages since Nov 2000, and hasn't really been active since around March 1999.

There's a relatively large thread going on in the kde-core-devel mailinglist about such interoperability efforts that you guys might be interested in, too... check out this thread for the whole story.

The short version is - arts, the KDE sound daemon, uses glib code internally, but the maintainer wanted to move the glib code to rely on an externally-installed glib (instead of maintaining a copy of glib in the arts distribution). Lots of developer confusion over this has ensued, but a lot of interesting discussion has also resulted. Check it out.

GNOME in general seems to be more "distributed" than KDE. The KDE technologies seem to be more of a "you're either with us, or against us". Qt, KParts and DCOP are a good example of this. When KParts was first being designed, back then it was called Canossa, Waldo Bastian made the following comment here:

Well, you don't see me cheering about that, do you? So instead of improving this situation we will make it worse. Instead of making KDE a open desktop environment we keep coming up with solutions which nobody but KDE and our Troll-friends use. It might be that we are giving away the source, but or the rest of it we are becoming more proprietary than MS.

Waldo BTW is a well respected and noted KDE developer. He has a point. In many ways the KDE technologies are more integrated, because they are more proprietary. A lot of stuff produced by GNOME is reused outside of the desktop project, for instance libxml2, librsvg, GTK and so on.

I can configure every option I want, upcoming versions are going to have VIM integrated into stuff such as the kmail application, etc. I have no idea where Gnome stands but it seems to be removing all power.

GNOME isn't about removing power. GNOME is about having clean user interfaces. A lot of the "powerful features" in the old gnome were, as their delightful expression goes, "crack features". They were working around stuff that was broken elsewhere. They put insane amounts of configurability into the GUIs themselves, slowing everything down. The new GNOME still has power, but it's revealed in the right place - the more esotoric options are stored in a hierarchy of documented preferences, and the more common options are put into the GUI.

To make a closed-source app, yes you must pay Trolltech. However, I don't think that should make you turn your back on KDE.

You should read up on the history of KDE and Qt. The main issue is that back when KDE started, Qt was the best tool for the job, and I don't think Gtk even existed.

At the time, Qt wasn't even GPL yet, it was licensed more like qmail, where you can't distribute a modified version of it. This bothered many Free software purists, because if they wanted to add a new feature, the best they could do is send a patch to Trolltech and pray it gets added. The KDE team acknowledged this problem, but they decided that writing a toolkit is easier than writing a desktop environment (on kde.org, they mention at one point KDE had 800,000 lines of code, while Qt had 80,000). So the logic was that they could always go back and recode a free toolkit if Trolltech ever went bad. Eventually though, the KDE Free Qt Foundation was formed, which gives KDE the power to release the latest Qt under a BSD-like license. Basically, if Trolltech stops working on Qt for any reason, stops selling commercial licenses, wishes to change the license to Qt, or otherwise abuses or loses control of their position, all at the discretion of two signed KDE members, a BSD Qt gets released (at which point, KDE would likely start their own LGPL fork of it). I've read over the Foundation papers a few times, and I think Trolltech must have been on crack when they signed it, but I guess it worked out alright since they are hugely popular now because of KDE's succes.

In the meantime, the Harmony project, a reimplementation of Qt, had started. To quote kde.org: "... the solution doesn't lie in writing a new desktop from scratch but in writing an LGPL'ed Qt clone. This is what the Harmony Project does. Even for GPL purists there is no viable reason to refuse KDE since a Qt clone will be available in the not so far future. We believe that we have made the right decision by first building a desktop rather than first building a Qt clone. There would have been a good chance that we would have suffered the same fate that the GnuStep project had to endure if we had acted otherwise."

Today, Qt is GPL, and so Harmony ceases to exist, and the Free Qt Foundation is not really necessary anymore except for ensuring closed-source KDE applications are always possible.

To make a closed-source app, yes you must pay Trolltech. However, I don't think that should make you turn your back on KDE.

You should read up on the history of KDE and Qt. The main issue is that back when KDE started, Qt was the best tool for the job, and I don't think Gtk even existed.

At the time, Qt wasn't even GPL yet, it was licensed more like qmail, where you can't distribute a modified version of it. This bothered many Free software purists, because if they wanted to add a new feature, the best they could do is send a patch to Trolltech and pray it gets added. The KDE team acknowledged this problem, but they decided that writing a toolkit is easier than writing a desktop environment (on kde.org, they mention at one point KDE had 800,000 lines of code, while Qt had 80,000). So the logic was that they could always go back and recode a free toolkit if Trolltech ever went bad. Eventually though, the KDE Free Qt Foundation was formed, which gives KDE the power to release the latest Qt under a BSD-like license. Basically, if Trolltech stops working on Qt for any reason, stops selling commercial licenses, wishes to change the license to Qt, or otherwise abuses or loses control of their position, all at the discretion of two signed KDE members, a BSD Qt gets released (at which point, KDE would likely start their own LGPL fork of it). I've read over the Foundation papers a few times, and I think Trolltech must have been on crack when they signed it, but I guess it worked out alright since they are hugely popular now because of KDE's succes.

In the meantime, the Harmony project, a reimplementation of Qt, had started. To quote kde.org: "... the solution doesn't lie in writing a new desktop from scratch but in writing an LGPL'ed Qt clone. This is what the Harmony Project does. Even for GPL purists there is no viable reason to refuse KDE since a Qt clone will be available in the not so far future. We believe that we have made the right decision by first building a desktop rather than first building a Qt clone. There would have been a good chance that we would have suffered the same fate that the GnuStep project had to endure if we had acted otherwise."

Today, Qt is GPL, and so Harmony ceases to exist, and the Free Qt Foundation is not really necessary anymore except for ensuring closed-source KDE applications are always possible.