It's clear that the KDE Project has done a very poor job in communicating our policy on releasing binary packages. I say this because as the primary contact on the release blurbs, I am the one that gets swamped with emails asking "where isinsert-your-distro package?" and "how does this package work?" and "why are you discriminating against that-distro?" These emails obviously stem from the (incorrect) belief that the KDE Project is responsible for creating those packages. The following document will hopefully clear up just what our policy is in this situation.

KDE Package Policy Explained

The KDE Project only releases source code. Period. When we make a
release, we package up our code into source code archives (.tar.bz2)
and put them on our FTP
server. Those are the only packages that we release and
support.

We do recognize, however, that most people want binary packages for
their particular distribution or platform. As a result, in the days
before a release, we make the source packages available to "packagers"
who then create binary packages from them. The packagers send us
their results and we put them up on our FTP site and mirrors for the
convenience of our users.

This explains why some packages are available immediately and some
take awhile to appear. While we do "pre-release" the source packages to packagers
with ample time to create the binaries, sometimes a few packagers are
busy and they don't upload their packages in time for the release
date.

In the case of Linux distributions, the packagers are the Linux
companies themselves. For instance, if you inspect a SuSE RPM from
our FTP site, you will see that it was created by SuSE. Mandrake,
Caldera, and Slackware all do the same. This ensures that the RPMs
fit into the distribution in the way that it was intended, rather than
as a third-party "add-on".

We also accept some binary packages from individuals where the
companies or groups behind the platform do not distribute KDE
themselves, and so individual volunteers contribute packages to our
FTP server. Examples are cases like Tru64, *BSD, Solaris or HP-UX (or
similar).

The Red Hat packages are a special case in that while the companydoes distribute KDE, they don't officially make the binary
packages that are found on our FTP server. In prior releases, the
Red Hat packages were created by a Red Hat employee packaging KDE in his
spare time. When his other responsibilities (the ones that he was
paid to do) took precedence, the KDE packages were (understandably)
slow in coming. Creating packages is very hard work, so we don't
fault him for this. As a stop-gap measure, we are looking for a Red Hat user to contribute binary packages for 2.1.1. Stay tuned.

The Future

We are looking into changing this policy in the future.
Rather than getting the packages from the vendors and putting them on
our FTP site, it might be best if the vendors put them on their own
sites and we just pointed to them. This would have the advantages of
freeing up bandwidth on our servers (which are always overloaded on
release days) and making it clear where the responsibility of support
lies.

Comments

As Underthumb so prophetically said in his initial post by quoting the Goals of the KDE Project HTML page:

"...the lack of an easy to use contemporary desktop environment for UNIX has prevented UNIX from finding its way onto the desktops of the typical
computer user in offices and homes...It is our hope that the combination UNIX/KDE will finally bring the same open, reliable, stable and monopoly free
computing to the average computer user."

Ok, call me blind but nowhere does this mention LINUX or LINUX distributions.

As my Aunt Mary used to say, "Build a bridge and get over it!"

Warlord and Undethumb can quit whining right now, before I send a pound of cheese to both of your houses.

"Without UNIX the internet would not be. But UNIX did not address the needs of the average computer user. This fact is particularly unfortunate since a number of implementations of UNIX ( Linux, FreeBSD, NetBSD etc.) are freely available
on the internet. All of which are of exceptional quality and stability."

The bottom line analysis here is that the KDE general overview is clearly grouping *all* of the Unix implementations together when they use the word "UNIX," and Linux was even specifically listed in this grouping.

> The reality here is that Underthumb is,
> without a doubt, 100% correct.

I am sorry but things are not always what they seem.

There are fundamental errors in that theory(!) of KDE developers ignoring their own goals by not taking enough care for the for existence and quality of binary packages!

Please let me explain what I mean.

1st:
Right, since in the KDE project there >>are the GOALS that KDE is going for... an "easy to use" or "user-friendly" desktop<< it is quite reasonable to think:
"OF COURSE they MUST look for ways to have _good_ binary packages available _in_time_."

2nd:
Seeing KDE developers planing to make it more visible that the Distro-Makers are the ones who actually take care for the binary packages (by changing the policy so that KDE would only publish pointers to the Distro-Makers servers and the users would get the packages *there*) /might/ lead to the conclusion that these KDE developers DO NOT MIND IF the users will get good binary packages in time.

3rd:
Comparing this conclusion ("They don't mind...")
to their goals (user-friendly...) can produce an imagination of KDE developers who do not act according their own goals.

The thread shows clearly that this has allready happened: there actually are some people thinking that the way KDE developers act is not nice/not according to their goals/not smart... and so on.

Ok, where is the misunderstanding?

Very simple!

ad 1st:

The KDE developers actually *do*look*for* ways to have _good_ binary packages available _in_time_.

ad 2nd:

The KDE developers actually *do*mind*if* the users will get good binary packages in time.

ad 3rd:

The KDE developers actually *do*follow* their goals of being user-friendly and easy-to-use.

Why this?

Didn't we read about them whishing to have the binaries on the Distro-Makers servers?

This is right, but this is no Con - it is a Pro argument for my claim!

Please take the following into account:

* There are lots of Linux Distributions.

* The Distro-Makers know best how to build
KDE-packages for their respective distribution.

* The KDE developers encourage the Distro-Makers
to build packages by giving them the sources
even *before* the self-compiling :) users will
get them.

Look at the contrary: What would be the result,

* if the KDE developers tried to make the
packages themselfes?

The result would be:

* Packages that do not fit so good into the
respective distributions - since the KDE
developers don't have all internal information
about how the Distro-Maker wants to set up
his system...

* Packages would not be available in time - since
not *all* distributions could be covered by
the stressed developers fast enough...

* Users would cry!

* Distro-Makers would cry!

* You, dear WorLord, would cry: "Why do these hackers think they are smarter than the people who constructed Distribution A???"
"Why the hell do these hackers not support Distribution B 6.9 but only B 7.0???"
"Why do they not HELP THE PEOPLE WHO KNOW HOW to do the packaging job???"
"If they arrogantly thinking they must do it themselfes, than I expect them to do the job PERFECTLY!!!"

and so on...

I am sure, this is not the scenario you would like most!

You surely appreciate to get _good_ binaryp ackages and to get them _in_time_.

So the solution is extremely simple: Just act as any Linux User who does not want to build her/his system from crash:

Choose the distro that fits your needs!

The one where you see that the Makers support KDE by providing you with good binary packages - in time!

Every Linux-Distro user expects to get a mail each time the company making the distribution has fixed a security hole and the new RPMs (or whatever they use) are prepared.

It *should* be quite normal to find a mail telling you nicely that "YES, we have the KDE binaries in place TODAY!" soon after (or even the evening before?) the official announcement of the next KDE release is made.

This is reality:

* The Distro-Makers are the ones who CAN do this job best - because of their internal knowledge.

* The Distro-Makers are the one who SHOULD take this job seriously - because of their internal knowledge.

Where does this knowledge come from?

It results from them making things THEIR WAY - to be better than (or at least diifferent from) the competition.

This 'making things different' produces both a CHANCE and a RESPONSIBILITY for the distro makers:

+ The big chance to be very good and to have many friends loving your special concepts...

+ The responsibility to take care for things like having important packages updates fast enough.

The result would be:

a) KDE users will be happy.

b) KDE developers will help the distro makers understand some KDE details (in case they will need such knowledge in order to adjust the KDE to their system...).

c) Distro makers would compete not only on the field of having the best ideas but also on the field of being the first to provide their users with a KDE update.

All of this is not theory but the way it is right now and I am sure: this is the way is *must* be in order to have good packages and to have them in time!
(Oops, did I say this before?) :-))

There is only *one* way to make things even better:

Tell your Distro-Maker that you die hard WANT
the next KDE update and you want it SOON!

The KDE developers *do* their job: encouraging the distro makers to take KDE package updates even more seriously is the best they could do!

"I am sorry, but this comment gives me the idea that you never read Maximum RPM or something like that."

What is "Maximum RPM"? A Magazine? You're using a magazine to back an argument?

"What binaries do you want? Statically linked ones of enormous size?"

See my other post. I answered this one already.

"Or do you want packages that could be plugged into your distribution - taking all dependencies and side-effects into account automatically."

With all due respect, sir, I've yet to see more then a handful of Distribution Packages that work well and proper with the _Distribution they were created for_, much less with anything else. And I've seen more then my share of "dependencies" that - well, weren't.

Point being, I don't think the KDE people could do anything worse then what's being done now.

"The 'normal user' wants a package made by people knowing the Distro, not a plain _binary_ - so forget about that!"

You have no idea what a "normal user" is, or what they want - and this sentence proves it. ;-)

A normal user wants to download a file, run it, and have it work. That's it, and thats all. The normal user doesn't know or bloody well CARE who made the package, or if it "knows" the distro. A normal user doesn't even know how to properly define "Linux Distribution." They say things like "I just bought Linux 7.1, can you help me set it up?"

Now normally, I'd be on your side in the situation... but then again, we're talking about people who've made it a goal to create a desktop environment FOR the "normal user" - the ones who don't really know what they are doing.

They simply want a download, click, and run experience (or else more of them would be running linux instead of MacOS or Windows). Most, if not all of them, could care LESS if copies of files get installed to different places on the hard drive, as long as it *works*.

"The normal user doesn't know or bloody well CARE who made the package, or if it "knows" the distro."

The normal user might not know who made the package, but they certainly will CARE when none of their programs show up in the K menu, or when they find out they can't configure anything except KDE itself from the Control Center, or when Konqueror takes twice as long to start up because they're out of memory from the extra sets of libraries they have to load to run their binary-distributed KDE, or when KDE doesn't automatically start when they boot their computer.

These are the sorts of problems that distro-created packages solve. Distros integrate their programs into their own customized menus, which would not show up in an "official" KDE binary package. Distros add icons to the KDE desktop to access their value-added features such as X configurators, hardware detection and setup utilities, etc. Distros link KDE against the proper libraries so that the "shared" aspect of the libraries can work as it was intended to and reduce memory usage. Distros add KDM to their startup scripts so that KDE is started automatically. None of these features would be provided by an official KDE binary distribution.

A binary-distributed KDE would be an isolated KDE - totally seperate from the distribution, and much worse off because of it.

In short, users may not care who made the package, but they DO care about how well the package integrates with the distribution. Official KDE binary packages could not provide that integration.

You allege that distro-provided packages do not work well. Which packages are you referring to? I'm curious. Anyway, I think that in 6 months or so, dependency conflicts will be much less of a problem. It seems that everyone and their brother is rushing to implement apt-get like functionality in their distribution (and for good reason!). RedHat has up2date, Ximian (or is it Eazel?) has Red Carpet, Mandrake has DrakRPM and urpmi. With the introduction of these automated package tools, upgrading will suddenly become a whole heck of a lot easier, and more foolproof. rpm --force could become a thing of the past, solving many package conflicts before they begin.

Personally, though, I can't understand why they don't all just switch to Debian ;-)

"The normal user might not know who made the package, but they certainly will CARE when none of their programs show up in the K menu,"

As far as I'm aware, only MD 7.x integrates the K-Menu with the generic X-based menu system. So anyone not using mandrake is used to menus *not* being integrated in different X shells/WMs.

"or when they find out they can't configure anything except KDE itself from the Control Center,"

I'm using packages for my distribution, and Control Center STILL only configures KDE. That's because the KDE CC was only written _to_ configure KDE I am unable to find any documentation stating that it's built to configure anything else.

"or when Konqueror takes twice as long to start up because they're out of memory from the extra sets of libraries they have to load to run their binary-distributed KDE"

Why does it have to be extra? QT and KDElib isn't going to load *twice*, you know it's just that the "isolated" libraries will load, instead of any other copy of the file that may be lurking in the system's "/usr/lib" directory.

"or when KDE doesn't automatically start when they boot their computer."

This was discussed already, wasn't it?

"These are the sorts of problems that distro-created packages solve."

And for the *last frickin' time*, I will - for the record - state that I ***never once implied or directly stated that Distro packagers should or would stop pumping out their own RPM/DEB/tar.gz packages***. I'm really trying to stay calm about this, but how many goddamn times do I have to write this before someone will actually read and understand it? I'm up to three different times, by my count and unless I miss my guess, I've already cleared this up with you, specifically, at least once. That the individual distro packagers should stop what they're doing and let KDE people take over completely is _just not what I'm suggesting_. IT'S NOT WHAT I'M SUGGESTING. Okay? Jeeeez.

"You allege that distro-provided packages do not work well. Which packages are you referring to?"

I'm referring to the (sometimes) nightmare that is the current state of RPMs in general. 9/10 times, they claim to need a file or are missing a library that is already installed, or in plain sight, or simply not required for functionality.

Several times, in fact, certain few RPMs (which will remain nameless) were claiming dependency on a library that was actually contained in the PRM itself - effectively, an RPM that was refusing to install because it was dependent upon ITSELF! Talk about doing a double-take

(Slightly off-topic, and from my own personal experience now, MandrakeUpdate was really working well to relieve this headache. I say "was" because somewhere along the line the packagers just stopped releasing 'new software release' packages for 7.2, and stuck to security updates only. And even *that* was okay for a while, until the Cooker switched over to glibc2.2, making any and all cooker files totally incompatible with 7.2 unless you REALLY, REALLY knew what you were doing. So - practically speaking now - the one good tool that made RPMs a snap to use made itself unworkable after only about 3-4 months of its official release.)

"Personally, though, I can't understand why they don't all just switch to Debian ;-)"

Because, for the most part (IMO now) Debian is just a pain in the butt to install, even for a seasoned veteran. I don't imply that it's _difficult_, mind you just a PITA and a chore to do. I'd love to use Debian myself, but I refuse to do so in an age where there are so many other good distributions that *don't* require hand-holding all throughout the install process. ;-)

And I must admit that the Pentium Optimizations of Mandrake are the main reason I stick with it. Does Debian do this?

Debian does too (though they don't replace the entire menu - they make their own submenu, which is nice). I don't know about RedHat or anyone else, but my impression was that most distros added at least _something_ to the K menu. I know they add stuff to the desktop. Mandrake is a poster-child for this, as they entirely replace the K menu with their own.

"Control Center STILL only configures KDE."

Yes, but distros include their own control centers, which are integrated into the KDE menus or desktop, and would be inaccessable from your universal KDE. (except by the command line, however we're talking about so-called "normal users" here who want everything to be easy and GUI). When I said that the users would be frustrated that they could only configure KDE, I meant that they would only be able to find KDE's control center and wouldn't see their distro's control center. BTW, some distros actually do add modules to KControl to configure the distro (Caldera). IMHO they should all do this, especially Mandrake (what's up with all the GTK based config tools inside a default KDE/QT desktop?!).

"QT and KDElib isn't going to load *twice*"

The KDE libraries won't, but if the user has *any* package from their distro that uses QT, that will require a seperate version of QT to load and QT *will* be loaded twice. I wasn't talking about QT, though, I was talking about glibc and libstdc++ and all the other shared system libraries that *will* be loaded twice because KDE uses a different version than the entire rest of the system. This was discussed up in our other thread.

"This was discussed already, wasn't it?"

I'm sorry, I don't see that discussion. I don't see how universal packages could solve that problem.

"IT'S NOT WHAT I'M SUGGESTING."

DID I SAY THAT WAS WHAT YOU WERE SUGGESTING? NO! Jeez yourself. I was SAYING that these problems are solved by distro-created packages. My point was that if distro-created packages are better for the reasons I described, there is no reason for KDE to put out their own inferior packages.

"9/10 times"

Hyperbole. If RPM was really THAT bad, no one would use it. Anyway, let me guess: You're using Cooker packages. There's a _reason_ they're in Cooker. If you really care that much about not having RPM headaches, you simply can't use Cooker RPMs. Don't use beta RPMs and then go around complaining to everyone when they don't work correctly.

"Debian is just a pain in the butt to install"

Got to agree with you there, the install is hard. I had a lot of headaches because I was trying to do a network install, but my network card wasn't supported, so I had to get the kernel headers for Debian's kernel onto my other distro and compile the new kernel module driver there, then insert it manually into the running kernel during the install from a text console.

But it's sooooooo much easier to maintain afterwards! Anyway, the new version of Debian due out this year will include a nice graphical installer (plus kernel 2.4.X, which would have solved my networking problem). Also, you could give Progeny Debian a try. They supposedly have a really nice and easy graphical install, available now.

"When I said that the users would be frustrated that they could only configure KDE, I meant that they would only be able to find KDE's control center and wouldn't see their distro's control center."

Oh.

Well, *that* is certainly out of the scope of the KDE project.

"IMHO they should all do this, especially Mandrake (what's up with all the GTK based config tools inside a default KDE/QT desktop?!)."

Boy, if that's not the best question to ask, I don't know what is.

"I wasn't talking about QT, though, I was talking about glibc and libstdc++"

Pardon my ignorance, but why were you talking about glibc and libstdc++? As far as I'm aware, *everyone* who uses Linux has these, so why would KDE need to supply it? That wouldn't be a KDE binary, that would be a whole new system (and, as such, way out of the scope of what I was talking about).

"DID I SAY THAT WAS WHAT YOU WERE SUGGESTING? NO!"

Then why the heck do you keep bringing them up??

My suggestion that KDE release their own binary has NOTHING to do with distribution packages/packagers. Nothing whatsoever. I'm only concerned that KDE release *some* kind of binary package, because I think that foisting binary releases off on distros is an irresponsible thing for KDE to do (in light of it's stated goals, and everything). What the distributions do outside of (or instead of) that generic binary is their own story, and not at all related to the idea that KDE should release one.

"I was SAYING that these problems are solved by distro-created packages. My point was that if distro-created packages are better for the reasons I described, there is no reason for KDE to put out their own inferior packages."

Yes, there is. Their stated goals are the reason they should at least release something.

"You're using Cooker packages."

Bad guess. To be honest, I don't seem to have very many problems with Cooker. More often then not, my problems come from the software homepages themselves. If I want to d/l something, I typically try to go to its page to see the latest information and d/l the latest binaries direct from the writer. Such RPM packages for Mandrake have proven to be more of a trial then anything else.

"But it's sooooooo much easier to maintain afterwards!"

Because they wait two years between updates? Just kidding.

which would have solved my networking problem). Also, you could give Progeny Debian a try. They supposedly have a really nice and easy graphical install, available now.

One question: do they use Pentium Optimizations in their packages? That's pretty much the Main Reason I use Mandrake. I don't know of any other distro that does this, and I really do see a difference between i386 and i586 or i686 packages 'specially on something as large as the entirety of KDE.

Yes! Its up to the distros to supply packages for their control centers. Its up to the distros to supply KDE packages that integrate nicely and display icons for their control centers and all that. It is NOT up to KDE to provide inferior packages when there already are superior distro packages out there. It would only be confusing to new users of KDE. Which packages should they get? Some would end up going for the "official" packages and would end up with bad performance and no distro integration.

>*everyone* who uses Linux has these, so why would KDE need to supply it?

As we discussed earlier, but you seem to have forgotten, a universal binary KDE would have to include its own versions of these libraries. Thus KDE would load its own version, and share it between KDE components, and all distro programs would share a different version. Therefore there would be 2 libraries loaded in memory for every library that KDE uses, doubling library memory usage. Intstant bloat.

>Then why the heck do you keep bringing them up??

Because I'm showing that any KDE universal binaries would be inherently inferior to distro packages and thus it would be a *BAD* thing for KDE to put out these inferior packages. It would confuse and frustrate users because they would get bad performance and bad distro integration - they would switch to GNOME or go back to Windows or something.

>I think that foisting binary releases off on distros is an irresponsible thing for KDE to do (in light of it's stated goals, and everything).

I think would be irresponsible and against KDE's goals to put out inferior packages. KDE wants to provide the best desktop possible.

>Yes, there is. Their stated goals are the reason they should at least release something.

I don't think that some page of several-year-old stated goals archived somewhere on the KDE website should suddenly require KDE to put out inferior binary packages.

>One question: do they use Pentium Optimizations in their packages?

Unfortunately, no. Ah well, they can't have everything, I guess.

I might try Mandrake again now that 8.0 is out. I'm happy with Debian, but I do happen to have a spare partition lying around, and I like nifty control panels and Pentium optimizations...

"It is NOT up to KDE to provide inferior packages when there already are superior distro packages out there."

It is up to KDE to provide some kind of working binary packages, because that is the very _first_ step towards making the desktop easier. There is just no logical way to talk around this fact. They want to make the desktop experience easier, they need to be sure that there is at least one easy way for a _standard user_ to get KDE (and JUST KDE) working on the system.

And personally, I think your idea of an "inferior" binary package is warped. Tying in to a distro is a *nicety*, not a *requirement*. Are all Red Hat configuration tools "bad" or "inferior" because their RPMs don't tie into DrakConf's control panel? Should I fire off a flame letter to anyone who releases a binary RPM for Mandrake that doesn't put a "shortcut" in the DrakMenu system? Of course not. DrakConf tools are a nicety provided to Mandrake users, as is the DrakMenu System. These are by no means some kind of a cross-platform Linux requirement.

The only "inferior" binary I can think of is one that _doesn't work_, or only works halfway (half the supplied KDE apps don't function properly, for example). A binary KDE package that works, but doesn't tie in to a distro is simply a 3rd party software release... like most out there that aren't specifically packaged for a distro (StarOffice's and Mozilla's packages come to mind most readily, and there are many others).

"Some would end up going for the "official" packages and would end up with bad performance and no distro integration."

Pure unfounded speculation, on both counts.

"As we discussed earlier, but you seem to have forgotten, a universal binary KDE would have to include its own versions of these libraries."

Uh, we did NOT discuss core libraries like Glibc or libstdc++. We discussed libraries that were *Core Only To KDE's Functionality*, like QT or LibKDECore.

Look at Mozilla and StarOffice - complete binaries, free of dependencies, are available for each different Version of Glibc (there aren't that many), and include all files required to run each package. To say that Glibc needs to be included is to exaggerate things beyond the point of usefulness. Are you purposefully being dense to prove a point, or have you just not seen other software packages provide binaries similar to what I'm suggesting? Because what I'm suggesting is certainly not a new or flawed idea.

"It would confuse and frustrate users because they would get bad performance and bad distro integration - they would switch to GNOME or go back to Windows or something."

Well, see, that's kind of why I'm fired up about this in the first place... with the attitude that KDE has displayed in this article (which boils down to "If you don't like or are unable to compile our source code release, then bugger off or contact your distribution's people," to put in in a nutshell) people will definitely switch to GNOME or back to Windows left and right. And they'll do this because it's either A) Such a pain in the ass to install KDE from source, or B) KDE binaries for their specific distribution aren't available yet. GNOME may be technically inferior, bloated, buggy, and almost always technically inferior to KDE (especially 1.4, Red Carpet, and Nautilus, IMO) - but at least one can type a single command and have a graphical installer not ONLY walk them through the process of installing, but *also* find them the fastest server and D/L all packages and dependencies for them whilst they stare at pretty pictures.

KDE is, IMO, the best Unix users have as far as a terrific desktop shell system. But before the average user can form that opinion, they have to get in on their system first - which is exactly where KDE stops. It's a damn shame to see them forget their values, point fingers, and abandon their target audience (regular users) in all the areas where they are really needed the most. GNOME may not be the best answer, but at least it can be installed by someone who really wants the stability of Linux, but doesn't know what an RPM or header file is.

"I think would be irresponsible and against KDE's goals to put out inferior packages. KDE wants to provide the best desktop possible."

Provided you pass all the necessary gear-head requirements to compile it from source or wait for packages, that is.

Hypocrisy is, at it's simplest, saying one thing and doing another. Kind of like saying you want people to have the best desktop possible, and then doing nothing to facilitate the process of attaining and installing it.

">Yes, there is. Their stated goals are the reason they should at least release something.
I don't think that some page of several-year-old stated goals archived somewhere on the KDE website should suddenly require KDE to put out inferior binary packages."

Because it's "several years old" does not change the fact that such a document is essentially the Mission Statement for KDE - it's whole reason for existing. (And if it is out of date, then why not revise it and change the motive line to better reflect the KDE project's current attitude? I've suggested that point twice now, and it essentially went ignored.)

And to say it's "buried" are the words of someone who doesn't really surf the KDE site very often - the "What is KDE" link (from which the quoted material was taken) is pretty much the very first link available in the left-hand NavBar.

And I'd argue that "inferior" is a warped way to look at the proposed package scheme, but since I argued this already, I'll just say "see above".

">One question: do they use Pentium Optimizations in their packages?
Unfortunately, no. Ah well, they can't have everything, I guess.
I might try Mandrake again now that 8.0 is out. I'm happy with Debian, but I do happen to have a spare partition lying around, and I like nifty control panels and Pentium optimizations..."

MD 8.0 is supposed to be uber-excellent - I haven't seen the alt.os.linux-mandrake NG have so many positive postings on one of their new releases since MD 6.2. Naturally, I'm looking forward to it, although I'm quite happy with 7.2 (but damn, I want the new kernel). Apt-Get is about the only thing about Debian I envy, and with MandrakeUpdate (hopefully it'll stay useful longer this time), I don't really miss it that much.

>they need to be sure that there is at least one easy way for a _standard user_ to get KDE (and JUST KDE) working on the system.

There are KDE packages available for every distro I'm aware of, and surely any distro that a _standard user_ would be using. That _is_ one way for users to get KDE on their system, and as I have been arguing, it is a better way*. Look at it this way. A user would have only four reasons to want your binary KDE packages:

1. Their disto doesn't provide KDE packages.

I don't know of any distro that would be used by people who couldn't compile KDE on their own that doesn't have KDE packages available. Heck, I don't know of ANY distro that doesn't offer KDE packages! No one needs binary KDE packages for this reason.

2. Their distro's KDE packages are a couple days late and they want the NEWEST KDE RIGHT NOW!!!

This is not really a valid reason. I mean come on, a couple of days is NOT too long to wait for better* packages!

3. Their distro's KDE packages are broken.

This is a valid reason to want KDE binaries. However, it hardly ever happens - most problems are due to errors such as rpm --force when it's not really necessary. When it does happen, distros upgrade their packages promptly, as KDE is an important package for them and it is essential that it work properly.

4. They don't know that their distro has KDE packages available.

In this case, it is better to direct users to their distro's KDE packages than give them inferior* binaries.

There is no other reason for users to want or need official KDE binaries.

>Kind of like saying you want people to have the best desktop possible, and then doing nothing to facilitate the process of attaining and installing it.

You think the KDE people have done nothing to facilitate the process of attaining and installing KDE?! You're crazy. The KDE people care very much about this - they work with the individual distro packagers closely, and a KDE auto-installer program is in the works.

Simply because one guy got fed up with all the newbies asking him to help them with packages that he didn't make and posted this article to the dot doesn't mean that the entire KDE project doesn't care about its users. Simply because the KDE project doesn't see the need to release inferior* binary packages doesn't mean it doesn't care about its users.

*You claim that I am just speculating when I state that official KDE binaries would be inferior? You must not have been reading my comments! That is exactly what I have been arguing (and, IMHO, proving) in most of my comments! I have given reasons galore! Let me respond to your latest objections:

>Tying in to a distro is a *nicety*, not a *requirement*.

It may be a nicety, but it makes distro packages superior. Themeing is a nicety. Heck, all of KDE is a nicety! Do you want to go back to the command line? It's just as capable (and in many cases more capable, once you learn how to use it!) GUIs are just a nicety. I claim they are superior because of their niceties. I claim that distro packages are superior to proposed KDE binary packages because of their niceties. What is wrong with this?

Besides, having an icon for a distro control center, auto-updater, etc isn't just a nicety for some people - perhaps even your _standard user_ - because they wouldn't know otherwise how to start it, or even that it exists!

>The only "inferior" binary I can think of is one that _doesn't work_, or only works halfway

How about one that is bloated and doesn't have as many features as compared to another that's also available? Doesn't that qualify as inferior?

>Look at Mozilla and StarOffice - complete binaries, free of dependencies, are available for each different Version of Glibc (there aren't that many), and include all files required to run each package

Oh, now KDE has to provide a seperate binary package for every permutation of Glibc and libstdc++ versions that is out there? Give me a break! Now, instead of having one, canonical, easy KDE binary package, you have many, only one of which will work on a given user's system. To tell them apart and tell which one will work on their system, users have to poke around in their system directories looking for library version numbers. I prefer distro packages, of which there are only one set and they always work. If the distro packages are out there, KDE's packaging obligations are fulfilled.

OK, I found the page on the KDE site. You seem to be most worried about this part or a part like it:

"It is our hope that the combination UNIX/KDE will finally bring the same open, reliable, stable and monopoly free computing to the average computer user that scientist and computing professionals world-wide have enjoyed for years."

You seem to be saying that because of this statement KDE has an obligation to see that all users can enjoy an easy way to install and use KDE, without mucking around with source code or obscure command-line interfaces. And here I agree with you. You also seem to be saying that because of this, KDE has an obligation to provide universal binary packages. The second statement does not follow from the first! If there is *already* an easy way for users to install KDE, then KDE has no such obligation. I argue that distro packages are *already* an easy way for users to meet their KDE needs and therefore, KDE's packaging obligations are already met.

">they need to be sure that there is at least one easy way for a _standard user_ to get KDE (and JUST KDE) working on the system.
There are KDE packages available for every distro I'm aware of, and surely any distro that a _standard user_ would be using. That _is_ one way for users to get KDE on their system, and as I have been arguing, it is a better way*."

But it **is NOT KDE making sure** that there is at least one easy way. That is KDE letting the distributions fend for themselves - which, again, is something that is totally contradictory to their stated goals.

Just because this perceived "better" way exists doesn't do anything to deter my point. In fact, I argue that this "better" way exists 'cause KDE refuses to be bothered with making an official, proper, and easy way (like they really should.)

You don't seem to be understanding where I'm arguing from; I'm arguing from the position of "KDE is saying one thing, and doing another;" I'm NOT arguing from the place of "KDE can do a better job then what's being done currently". Your position, while admittedly more _practical_ then my own, misses the point I'm making entirely.

"You think the KDE people have done nothing to facilitate the process of attaining and installing KDE?! You're crazy."

Uh, HELLO? What the heck do you think the Dot story that started this mess was all about?? It was pretty much a _direct statement_ to the tune of "we are not responsible for facilitating the process of attaining and installing KDE, so _stop asking_"!!!

"Simply because one guy got fed up with all the newbies asking him to help them with packages that he didn't make and posted this article to the dot doesn't mean that the entire KDE project doesn't care about its users."

That statement would be true if he weren't speaking on behalf of the entire KDE project problem is, he happened to be speaking on behalf of the entire KDE project!

"*You claim that I am just speculating when I state that official KDE binaries would be inferior? You must not have been reading my comments! "

This statement is a variation of the "understand/agree" logical fallacy. Just because I find your comments to be purely speculatory doesn't mean I haven't read them it only means that I've read them and found them to be purely speculatory.

>Tying in to a distro is a *nicety*, not a *requirement*.
"It may be a nicety, but it makes distro packages superior."

But "preference" is not spelled s-u-p-e-r-i-o-r. I am skipping other like arguments, because I have the same response.

"Themeing is a nicety. Heck, all of KDE is a nicety!"

This is a slippery-slope fallacy, and is steering the conversation functionally out of range.

"Do you want to go back to the command line?"

Now that you mention it, the CL is where I spend most of my time.

"Besides, having an icon for a distro control center, auto-updater, etc isn't just a nicety for some people - perhaps even your _standard user_ - because they wouldn't know otherwise how to start it, or even that it exists!"

Since you bring that up, I'd like to let you know that your "standard user" doesn't really use the updater tools/control center because it was set up FOR them in most cases. The "standard user" Uses the computer; 99% of them don't update them or change the preferences in the control center. (Of course, my job as a Sysadmin is the only experiential fuel I have for this fire; but the fact that I've been at it for 15 years makes me pretty certain of the truth in my words).

"Oh, now KDE has to provide a seperate binary package for every permutation of Glibc and libstdc++ versions that is out there? Give me a break!"

I find it humerous how you can complain about something that at least two _very_ popular pieces of software do already. This is a standard practice I'm suggesting, not a radical one.

"Now, instead of having one, canonical, easy KDE binary package, you have many, only one of which will work on a given user's system. To tell them apart and tell which one will work on their system, users have to poke around in their system directories looking for library version numbers."

Are you being dense on purpose? A simply-designed web site (that can even go as far as asking what distribution the user has) would point to the proper download.

You really are making this sound so much harder then it really is.

OK, I found the page on the KDE site. You seem to be most worried about this part or a part like it:
"It is our hope that the combination UNIX/KDE will finally bring the same open,

"see that all users can enjoy an easy way to install and use KDE, without mucking around with source code or obscure command-line interfaces. And here I agree with you. You also seem to be saying that because of this, KDE has an obligation to provide universal binary packages. The second statement does not follow from the first!"

I suggested what I suggested as a possible solution; not the final one. The bottom line of my statement is that KDE is, by their OWN rules, responsible for providing SOMETHING other then source code and that's it (which is pretty much what this article is about!)

There are better ways being suggested, and even worked on. I welcome better ideas, and actually prefer the KDE Installer - that idea totally trumps my own.

You're right. I don't understand how you can argue that KDE should provide packages that aren't as good simply because they state they want to make an easy-to-use desktop. My argument is that if good distro packages are in fact out there then KDE's obligation to make the installation easy (an obligation that comes from their stated goals) is *already fulfilled*. It doesn't matter that KDE itself hasn't actually made the installation easy, KDE didn't state in their goals that they had to do everything themselves. If there weren't distro packages out there, or if KDE could do better than distro packages, then of course it would be a whole different story.

"[this article] was pretty much a _direct statement_ to the tune of "we are not responsible for facilitating the process of attaining and installing KDE, so _stop asking_"!!!"

KDE doesn't do much to help users with specific distro packages, that is true. However, that doens't mean that they have done nothing to help users obtain and install KDE! They work with distro packagers and help them. And, as long as _support_ for distro packages exists, then KDE has no obligation to support distro packages. It's the same argument as my other one. This article was about misdirected complaints: People are complaining to KDE about packages that were made by distros. They can and should contact their distros instead.

>"Simply because one guy got fed up with all the newbies asking him to help them with packages that he didn't make and posted this article to the dot doesn't mean that the entire KDE project doesn't care about its users."

"That statement would be true if he weren't speaking on behalf of the entire KDE project problem is, he happened to be speaking on behalf of the entire KDE project!"

The statement is still true. I would argue that this article doesn't even mean that the author doesn't care about KDE's users. He simply wants them to direct complaints to the correct place. Just because that place is not technically part of KDE (though the packagers are closely related) doesn't mean that he doesn't care.

"This statement is a variation of the "understand/agree" logical fallacy. Just because I find your comments to be purely speculatory doesn't mean I haven't read them it only means that I've read them and found them to be purely speculatory."

You can't call my arguments speculatory because I have provided reasons. You can call them wrong (and you have), but that's different.

"But "preference" is not spelled s-u-p-e-r-i-o-r."

Huh? If you have a preference for something, don't you think its better? I prefer Windows over Linux because I think its better. I prefer distro packages over proposed KDE binary packages because I think they are better.

"This is a slippery-slope fallacy"

It is not an out-of-line slippery-slope fallacy. I was merely giving examples of the fact that niceties make programs easier to use and easier-to-use programs are better. You were arguing that since you thought distro integration was a nicety, it wasn't required. I was arguing that "niceties" such as integration make KDE easier to use and therefore make distro packages better, which supported my point.

"your "standard user" doesn't really use the updater tools/control center because it was set up FOR them in most cases."

They may not use it on a regular basis, but there _will_ come a time when they wish to use it for _something_. What if they buy a new printer or something and want to set it up? I agree that a "standard user" wouldn't use the control panel on a regular basis, but there would definitely be a few times when they would want it to be there.

"The bottom line of my statement is that KDE is, by their OWN rules, responsible for providing SOMETHING other then source code and that's it"

No, KDE is responsible for *seeing that* something other than source code is provided. They *do* see that something other than source code is provided, therefore their responsibility in this case is fulfulled. It does not matter that the distro packagers aren't technically part of the KDE project. Their product is easy-to-use KDE binary packages for everyone.

Now, if KDE could do *better* than disto packages, then it *would* be their responsibility to do so. As you point out, the KDE installer project is a good way to improve on distro packages.

Hey, does anybody want to listen to me, user? I don't want a big mega-super package from KDE, I want a package from my distro. And I want that the Slackware team co-work with KDE team to make good package. If I want a KDE version, which not has been released by Slackware yet (as for now KDE 3.2.1), I will use KDE.SlackBuild script which will build whole KDE. I just will need to launch KDE.SlackBuild script - thats all! And I think to make KDE team to make the package for Slackware is very stupid!!!! Why then there should be any distros? I thought that the distro it is the original way to compile, patch and versioning of packages (or maybe some additional programs), so why KDE need to do it for all distros???? Maybe they should also build gcc , sendmail or mozilla for Slackware :))) ? I don't think so, it is very stuppid, to say so - sorry - no offence.
P.S. I can find the site of Slackware very easy, and also can find download section and where the scripts are located, why the users of other distros can't do it do you think? I think, they can.
However I would like to have something like Windows Update from Slackware (to build new packages), but I think that I should contact Slackware and not KDE for that.

Oh, forgot to say. Why you wrote maximum RPM??? I wont Maximum TGZ!!! :))) Or I want Maximum deb!! or Gentoo, I don't know :)) To think the KDE should do them all it is absurd, anyway I never will use it, and will wait for kde in tgz format from Slackware or launch KDE.SlackBuild if I will loose my patience :)

P.S.
You should say "Thank you" for KDE team for this bueatifull desktop, if they leave it - there will be only GNOME - oh, no - I'm scared :))

I don't know what you want. Open Source means that whoever wants to contribute can do so. It's the way the enormous amount of work and time is shared. Normally the people working on such a complex project can't know or even do _everything_. _Think_ a minute: KDE is the best desktop, and it runs under _several_ environments, and they are all different. You pay nothing for this awesome result.

So, what do you want?

If I gave you one Dollar ore one Euro, for free, and you say: "There's one cent missing!", then I think: "Dem fehlt aber mehr als ein Pfennig an der Mark" (=there's much more missing than one cent), as people say in Germany.

Good luck.

Tim

P.S.: To all who contribute to KDE: GREAT WORK!!!

P.P.S.: Don't get me wrong, it is okay, when you say there is a thing worth thinking about. But what you say and especially the way you do it lets me know you are an egoist. Switch on the tv and eat some potatoe chips.

P.P.P.S: A few days are a very short time to build the packages. If you can make it faster, _then do so_. But if you can't wait and want to be on the bleeding edge you _can_ get the sources. Daily. It's not too difficult.

It's not about me, it's about the average user. I'm already running KDE 2.1.1 (with AA support compiled in, even), so I'm obviously not the one who would be having problems installing anything. Making it about me when it clearly isn't is simply an artful (yet clichéd) way to dodge the issue.

"I don't know what you want. Open Source means that whoever wants to contribute can do so."

It's not about Open Source in general, it's about the KDE desktop and it's *>_Stated Goals_<*. Confusing the two is simply an artful (yet clichéd) way to dodge the issue.

"_Think_ a minute: KDE is the best desktop, and it runs under _several_ environments, and they are all different. You pay nothing for this awesome result. So, what do you want?

It's not about money, it's about integrity. I don't care if its free or if it costs a million bucks: if one says that one is going to do something, then I expect that person to live up to his/her word without half-assing or ignoring an integral part of the process. That's what I want. And making it about money instead of integrity is simply an artful (yet clichéd) way to dodge the issue.

If I gave you one Dollar ore one Euro, for free, and you say: 'There's one cent missing!', then I think: "Dem fehlt aber mehr als ein Pfennig an der Mark" (=there's much more missing than one cent), as people say in Germany.

It's not about giving gifts, it's about being true to your word. There is a difference between 1)simply giving something away, or 2) SAYING you're going to give one thing away and then giving another (noticeably lesser) contribution. The first makes you generous. The second makes you a generous liar. Making it about generosity instead of honesty is simply an artful (yet clichéd) way to dodge the issue.

*shrug*

Of course, no one has addressed the idea of simply changing the stated goals of the KDE project, which would be another equally good (and considerably easier) solution to this whole issue.

P.S.: To all who contribute to KDE: GREAT WORK!!!

Seconded, yet again.

P.P.S.: Don't get me wrong, it is okay, when you say there is a thing worth thinking about.

Hollow words, considering the less-then-receptive responses I've gotten... but thanks for at least acknowledging the concept.

But what you say and especially the way you do it lets me know you are an egoist.

Oh, now wait just a damned minute, sir. Throughout the ENTIRETY of your reply, you've consistently twisted the entire issue to reflect upon me instead of looking at where it's supposed to be targeted (normal users and the stated goals vs. the actual results and actions of the KDE project). And I've pointed out where you've done this, in a point-by-point fashion.

How can you screw things up so utterly and completely, and then accuse ME - with a straight face, no less - of being the Egoist in this situation? If you want to know what an Egoist looks like, I strongly recommend that you find the neares mirror and take a good, looong look.

(And all I've done here is tell the truth in the easiest most direct, no-nonsense way possible. The "way I do it" is a non-issue, as the decision to take things personally (or not) is entirely yours, and yours *alone*. If you want to actually discuss the points I've brought up, then fine; but I'm not going to waste my time going off-topic and discussing how these concepts make you feel.)

Switch on the tv and eat some potatoe chips.

TV bores me. I'd much rather be finishing up Clive Barker's _Undying_.

This is only half of the truth, because
in your source code distribution you
have the /debian directories in every
part of KDE which are
only needed for generating the .deb
package, and I am glad that you add this
directory.

I believe that the source of the problem lies in the fragmentation of Linux in Distributions. Not that I propose that there shouldn't be distributions: just that each should not fragment Linux creating its own little universe.

More than the LSB (Linux Standard Base) , a standard Linux distribution should be created, as is the case for FreeBSD. This should be created and managed in an open source fashion, and should become freely available via the internet. Let's refer to it as Linux Standard Distro (LSD) for the rest of my post. This distro should also have a standard package management system, with automatic dependecies dissolvement (sounds a little like Debian? Wait, there's more).

The key point is this: commercial distributions should adopt this LSD, and built on top of it their value added thingies, like fancy installers, package managers, documentation, services, support, the whole lot.

Programmers and packagers then will only have to support ONE PLATFORM: the LSD platform. The commercial distribution add-ons will not affect the programming enviroment. All distros will all have the same gcc version, the same glibc, the same package managment system etc etc.

Some Linux advocates will mumble something about 'freedom of choice', and 'variety is the spice of life' etc, and point out that a single agreed LSD is a "bad thing". This, I think, is based on a misunderstanding of the whole 'freedom of choice', 'DIY' thing.

In fact, an LSD platform would *increase* freedom of choise. For example: a user won't be tied anymore to a particular distro's packaging system for binaries, as is the case now. All LSD applications will be at his disposal whatever distrubition he chooses to run. Another example: If someone solved a problem in his LSD, the solution will be applicable to every other LSD. As is the case now, you often find that advice on how to do so and so on Mandrake, for example, doesn't apply to Debian.

And, most important of all, Distributions will be focused to provide what they ought to provide, anyway: value added services and add-ons. Nowadays, they strive with assembling packages and stuff together, and perform pourly on the added value part: I mean it took them three years to get a decent installer program for christ's sake (and many distro's still lack one).

It's not a distribution's job to decide the filesystem hierarchy, or the config files format, not even to decide what gcc version the users should be using. That should be a standard on any self-respecting O.S.This is the way FreeBSD works already, yet FreeBSD lacks distributions (there is only the FreeBSD standard distribution). I think, my proposed scheme, combines the benefits of the FreeBSD standard base, with the added value that Linux Distributions provide.

P.S Just my 0.2$.

P.S 2 The KDE 2.1.1 announcement on kde.org reads:

"On March 27th, 2001, the KDE Project released KDE 2.1.1, a powerful and easy-to-use Internet-enabled desktop for Linux."

Since KDE also runs happily on BSD, Solaris, etc, shouldn't that be "for Unix"? Let's not alienate other users.

Count Zero wrote:
All distros will all have the same gcc version, the same glibc, the same package managment system etc etc.

Unfortunately that's only true if all users are forced to upgrade their whole distribution everytime a new version of KDE is released. And I don't think that this is desirable. For example there are KDE 2.1.1 binary packages for the last four SuSE distributions (6.3, 6.4, 7.0 and 7.1). Of course these different distributions don't include the same version of glibc.
Even if there is a LSD you can never assume that all versions of the LSD include the same versions of all libraries. Some LSDs will have older libraries and some will have newer ones. Therefore it will never be possible to just make one binary package for one LSD. You will always have to make packages for LSD 1.0, 1.1, 1.2, 2.0 and so on and so forth.

Definetly true. Almost all the problems I have seen in Linux are the result of distribution companies mucking up what the hackers got right. Mandrake, RedHat, SuSE, Slackware, and others have all done this. Fragmentation is bad, it isn't helping BSD, and it won't help linux.

On another note, I sort of agree with this post but then there is Slackware, which is basically a straight-out-of-the-box linux distro, as close to an 'LSD' as you can get without being a complex molecule.

1st off- Hat's off to all the developers and volunteers worldwide. Your hard work does not go unnoticed or unappreciated! You've made the transition from Windows to Linux so easy for many of my friends!
As far as I'm concerned you guys have better things to do than compile packages for every distribution. As a Helpful Hint, why not have direct links on the front page to the latest (unofficial or not) updated binaries ftp sites?

My big bone is with the distributions. I'll grant that for $30 you get quite a huge assortment of software. I can't complain about that. What I DO complain about - and many others is the whole broken libraries issue with Mandrake, Red Hat, et al. To get up to KDE 2.1.1 (Mandrake) there were (fortunately!) a few kind individuals out there who built their own packages to get past the Mandrake 7.2 glibc_2.2 update problem. Ditto for a few hundred other packages as well. If one or two people can compile all these packages, why can't one of Mandrakes' PAID programmers do this right?

I PAID for the email tech support (through McMillan Publishers) and only got an auto-bot response for the glibc update problem. I scoured the newsgroups and linux sites and never could get a clear answer about the updates (SORRY fellas- using rpm -Uvh --force --nodeps glibc* is NEVER a good idea!). I learned that the hard way when forcing an install of Star Office 5.0 back in the days of SuSE 5.3 (libc5). Broke a lot!

So distributors who expect us to pay good money for this software- GET ON THE BALL! You won't exactly win people over w/ these incompatibility issues vis a vis M$FT and may give a lot of people reason to switch back.

Oh, and for those of you having trouble with Mandrake 7.2 updates- try this site :::

WRT distributors providing binaries, I think we
have to realize they can only support what they
provide. If they do not provide KDE 2 in their
distribution, they are not obligated to provide
binaries as add-ons. If they do, we should be
grateful. Now if KDE 2 is a bugfix for KDE 1, I
would say they are obligated to provide binaries.
Meanwhile, as time consuming as compiling source
is, it is still the best option. Just my 2 kopeks
worth.

This whole topic is rather moot... meaning that the folks at kde.org don't really need to explain or justify why they do things the way they do.

Given the fact that a few here are fairly concerned about not having a package available for their particular distribution, I would suggest to them to learn a bit more about linux... especially when it comes to building software from source. It is not difficult and you will benefit wholly in the long run.

RPM's are something of a misnomer. On the surface they appear to be the 'saving grace' when it comes to software management. I, however, avoid them like the plague. Why? Because RPM only lives up to it's *full* promise by meeting all of the conditions below:

1. Anything and everything you have installed was delivered via RPM.

2. Anything and everything you want to have has an RPM available for your specific linux distro... even rpm's that account for changes in core libraries that the given package may require, i.e., glibc, blah, blah, blah...

3. The rpm's for your distro, assuming they exist, have been *tested* and are *supported* by your distro vendor. Good luck.

4. The rpm's were build with the options that you specifically need/want.

Anyways, I'm getting a bit off topic. Learn how to configure, make, and install from source... not only is it the overwhemingly most common distribution method (DUH!!!)... you shall be rewarded in the long run.

You raise some good points, but I must admit that I max out at building either KDE or the incomprehensible GNOME because of the multitude of packages. It's just a big pain in the ass to compile because of the handholding that you have to do to compile and install.

But, OTOH, I've downloaded and compiled XFree86 (comparable in source size) because it contains one configure and one make file. It takes time, but it's a straightforward compile and install -- just like every other compile that I bother to do.

I've seen recently that a global make script is in the works. After that's reasonably stable, you're absolutely right -- RPMs won't matter. Today for me personally, they do matter.

Here is my compile-from-cvs-script: I call it "makelib". You can easily change it to a "makebase", "makegraphics" ...
I am far away form being a script-god. If you want to use this script, you have to change it according to your own system settings.
(There are maybe some unmotivated line breaks caused by the HTML-formating)

My personal belief would be that the KDE group should be at least concerned that the binaries being distributed pay them good lip-service.

To not be involved, even with just a cursory nod of approval, with the binary releases can lead to severe issues that would only blacken the "KDE" name.

A minor annoyance I have is with the Caldera binaries that have consistently missed out the kdeadmin RPMs in (I believe) all of their KDE 2.x releases. To get the full complement, I have to resort to source compilation. This is something that should be flagged before release. A binary distribution should at least meet the same expectations that a source compilation would give, including not requiring additional libs etc, if the standard compilation would not require them also.

Lets get real. If you don't want to deal with making your own package either wait on your distribution to make an update, or wait for the next version of your distribution. This whole I want it now attitude is counter-productive. Lets be grateful that they even make KDE at all. I really like KDE a lot, and I know I get impatient for the next new feature or next new version, and even keep a copy of the CVS tree just so I can get that next neat new thing 3 days before anyone else on my block (although probably no one else even runs KDE). But I don't expect anyone to make it simple for me. If I can't wait for the distributions to do their thing, then it is my problem and only my problem.

I think that the statement that KDE made was very up front and very to the point. It is right that they shouldn't be in the packaging business. I will only say this. I think KDE should build one binary package for Linux and maybe one for the next largest platform. This binary package should be built with the lowest common library in current distribution, and should be placed in /opt. If you decide to get this package you take the responsibility of piecing it into your distribution. This package should have an easy installer something similar to the Loki installer. Again if you choose to go this route you take the responsibility for doing so. Once installed and configured the upgrade should be straight forward, a simply click on the updater and a check of the root password. I don't think that KDE should get into the game of locating packages and dealing with the different distributions. What would be nice is if this package distributor, were builts dynamically enough to allow for perhaps XML configuration files which the distributions could manipulate into their own setup, and then also run an external applet to update the distribution's package database. But again it would be the distributions responsibility to take this additional step, and the only option that the general person would have if they don't want to wait for the distribution is the centrally managed binary tree.

Again I think it isn't KDE's responsibility, and I think that in the long run we are getting a lot for the litttle that many of us give back. It seems very ungrateful to respond in this way saying that windows can do X or Y why doesn't KDE do that. WHen in reality Linux can do that, it just isn't managed at the KDE level.

Lets get real. If you don't want to deal with making your own package either wait on your distribution to make an update, or wait for the next version of your distribution. This whole I want it now attitude is counter-productive. Lets be grateful that they even make KDE at all. I really like KDE a lot, and I know I get impatient for the next new feature or next new version, and even keep a copy of the CVS tree just so I can get that next neat new thing 3 days before anyone else on my block (although probably no one else even runs KDE). But I don't expect anyone to make it simple for me. If I can't wait for the distributions to do their thing, then it is my problem and only my problem.

I think that the statement that KDE made was very up front and very to the point. It is right that they shouldn't be in the packaging business. I will only say this. I think KDE should build one binary package for Linux and maybe one for the next largest platform. This binary package should be built with the lowest common library in current distribution, and should be placed in /opt. If you decide to get this package you take the responsibility of piecing it into your distribution. This package should have an easy installer something similar to the Loki installer. Again if you choose to go this route you take the responsibility for doing so. Once installed and configured the upgrade should be straight forward, a simply click on the updater and a check of the root password. I don't think that KDE should get into the game of locating packages and dealing with the different distributions. What would be nice is if this package distributor, were builts dynamically enough to allow for perhaps XML configuration files which the distributions could manipulate into their own setup, and then also run an external applet to update the distribution's package database. But again it would be the distributions responsibility to take this additional step, and the only option that the general person would have if they don't want to wait for the distribution is the centrally managed binary tree.

Again I think it isn't KDE's responsibility, and I think that in the long run we are getting a lot for the litttle that many of us give back. It seems very ungrateful to respond in this way saying that windows can do X or Y why doesn't KDE do that. WHen in reality Linux can do that, it just isn't managed at the KDE level.

First off as a KDE user, I completely agree with this policy. Binary packaging across all of Unix today is not a trivial task. This decesion makes the most sense.

Secondly, for all those saying "it is free, this is what you get"(and variations of), you are repeating exactly what Microsoft says. You are indeed proving points made on the MS "Linux myths" page. That free software has no quality assurance, is not easy to use, and you have to be a programmer to install it.

Now instead of bitching and whining, lets see if there are any ways of improving the situation in the future...

Well, this looks like a perfect situation for an commercial entity to fill a niche. How would KDE developers feel about a company who tests, packages, and distributes KDE binaries? Maybe with an official KDE project blessing? (ewwh blessed Kandalf pee?)
Of course this would lead to the company not packaging a flavor of *n?x if it is not econmoically viable...

Another nots-so-hard solution is simply have the the distrubitors do the packaging as they do now...But informally require them to make those packages public in a certain amount of time from a release, with maybe some minimal testing done. In exchange, the KDE project will link to their site in a nice prominent "we think these guys make decent packages, and they get our seal of aproval" section. Otherwise, the link goes in the "oh yea, you might find binaries here but they might be crap" section.