The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
I still don't see it
by not me on Wednesday 11/Apr/2001, @14:30
|
I still do not see _any_ benefit from the KDE project going out and telling all the existing packagers "Thanks, but we don't need you anymore" and doing the whole thing themselves.
Look, the KDE project couldn't do a better job itself! First, it would have to go out and get people to do the packaging. Who would do it?
The core KDE developers? Not if you still want KDE to be developed! They would have to spend all their time making packages, fixing dependencies, resolving conflicts, answering package-related e-mails, etc. We can rule them out.
Should KDE go out and find all new packagers? Who would they draft into their service? It would be really hard to find new packagers.
The remaining option would be for KDE to adopt the existing packagers to be part of the KDE project. And this doesn't fix anything! Giving the packagers "honorary KDE developer" status wouldn't suddenly increase the quality of their work, and there's no "KDE stamp of approval" that will magically make packages function better either.
The fact is, the current packagers DO work almost as part of the KDE project. They have complete access to all the resources that are available to the developers (as do you, me, and everyone else who has Internet access).
I really don't see how to improve the situation. It's not like binaries aren't available, or something! Maybe the RedHat rpms are a week late. I'm sorry, I really am. (I'm sorry for anyone who can't use apt-get) But giving KDE the burden of providing packages, WHEN THERE ARE ALREADY THESE GREAT PEOPLE WHO DO IT, is silly.
Sorry for the caps. <b>Bring back HTML posts!</b>
|
[
Reply To This | View ]
|
Re: Because you're looking in all the wrong places
by WorLord on Wednesday 11/Apr/2001, @16:24
|
What amazes me about your last post is not how well you criticized what I've said - which you didn't do at all, IMO - but rather, how well you've criticized things I *didn't* say. You've read so much into my post that you missed the boat entirely. Here, let's review:
"I still do not see _any_ benefit from the KDE project going out and telling all the existing packagers "Thanks, but we don't need you anymore" and doing the whole thing themselves."
Please quote where I suggested that the KDE project do this. (Clue: I didn't).
"Look, the KDE project couldn't do a better job itself!"
Yes, they could, but I'll get to that in a minute.
"First, it would have to go out and get people to do the packaging. Who would do it?
The core KDE developers? Not if you still want KDE to be developed!"
Oh, don't lay that one down. I ask you, who BETTER is there out there to supervise the compilation of a working binary (notice I didn't say "working binarIES") then the people who WROTE THE PROGRAMS themselves?? After all, it should be blatantly obvious (simply by the program's existence) that they are, shall we say, MORE then familiar with the whole ./configure, make, make install routine.
Learning to compile is the first part of learning to code. The first lesson I ever got in C was how to write and _compile_ a working "hello world" program. If they can _write_ it, it should be more then obvious by now that they can successfully _compile_ it.
"The fact is, the current packagers DO work almost as part of the KDE project. They have complete access to all the resources that are available to the developers (as do you, me, and everyone else who has Internet access)."
And they will probably still make their distro-specific packages regardless of what I'm about to propose. In fact, they will probably make their distro-specific packages BECAUSE of what I'm about to propose.
"I really don't see how to improve the situation."
That's because you've restricted your options to the point of futility. If you're willing to read it, I'm willing to offer a simple solution:
KDE should go the way of Opera, and give the option of a single _statically linked_ binary that is completely distribution inspecific (which is kind of the point of static linking). One huge *.tar.gz file (and it WILL, in all likelihood, be huge), maybe KDE-everything.tar.gz, that unzips to /opt/kde and contains all the lib.xxxxxx.so.x files (and such) required to run a self-sufficient, latest and greatest, shiney and new version of KDE. Perhaps an installation script that unzips the file for the user, and edits the .xinitrd file accordingly (not unlike WindowMaker) - and this is something simple enough even for peons like me to write.
Thus endeth all of the problems, and everyone is happy. Would the file be huge? Yes. Yes, it would. But would it provide a simple, reliable, and easy to install version of the Latest KDE (read: a "user-friendly desktop experience")?
Yes. Yes, it sure would.
(And the idea can even be expanded upon, even! KDE-Barebones.tar.gz would be just KDE and the minimal amount of apps in the core packages. KDE-MidGrade.tar.gz would be business oriented. You get the picture by now, probably.)
NOW, whether or not the KDE crew would want to sully their hands with close integration with X or Y distribution or package format is entirely up to them, and a different matter altogether. If I were on the team, I'd vote against such a thing, though - and rightfully so, IMO. While I may believe that it's the KDE crew's responsibility to provide a working binary of their product, I do *not* believe that it's KDE's responsibility to bow and scrape to the various and strange niceties and inconsistencies of the various Linux distributions out there, and at no time have I ever stated or implied such as that. If Mandrake users want a version of KDE that ties in with the Mandrake Menu System and ends in i586, then the Mandrake Packagers can make it (which they will doubtlessly be doing for cooker, anyway). If the debian people want to use apt-get to update their KDE, then I'd say it's up to Debian to provide such things (again, they'll be getting around to this eventually anyway).
But I do think that they are fully responsible for offering a *some kind of a working binary distribution of their product* in the interest of remaining true to their aforementioned _Stated Goals_. And I think a single statically linked binary that doesn't care WHAT distro of Linux it gets unzipped to would be just the trick to accomplish this.
--WorLord
|
[
Reply To This | View ]
|
Say what you mean and mean what you say
by not me on Wednesday 11/Apr/2001, @22:07
|
>What amazes me about your last post is not how well you criticized what I've said - which you didn't do at all, IMO - but rather, how well you've criticized things I *didn't* say.
I'm sorry, I misconstrued your statement that "Underthumb is, without a doubt, 100% correct" as indicating that you actually agreed with what he said and were going to back up his argument. You were both apparently arguing that KDE should take on the full responsibility of providing binaries itself. You made no mention of your scheme for KDE to provide a single "official" set of portable binaries.
Now that you have, in fact, revealed your scheme in all its glory, I can respond to your actual argument. (by the way, why didn't you just say what you meant in the beginning?)
First of all, I agree that of course the developers are the ones who are best suited to compile KDE (although they are not best suited to adapting to the quirks of each and every distribution, which you seem to agree with).
However, I think your idea of providing a "single, statically linked binary" is not feasable for other reasons.
Here's the problem: KDE is not a single binary (not even close), so how do you propose to make a single statically linked binary out of it? Statically link every component, you say? My God, that's bloatware extreme! KDE memory usage would skyrocket! Only people with _over_ 256 MB of RAM would even be able to _think_ about running a statically linked KDE. A KDE with every component statically linked against QT would be impossible to run. Include QT as a shared library and statically link the rest, you say? Still extreme bloatware. The KDE project would _not_ be doing itself or anyone else a service by providing unusable binaries.
Besides, the utterly gigantic tar.gz file would be out of the reach of all but the most persistent modem downloaders.
These statically linked binaries would appeal only to a very small audience: Those people who have broadband connections to the Internet and also have truckloads of RAM that they don't mind wasting for no reason. Anyone else who tried these binaries would be repulsed by their large size and insane memory usage, and they would probably think of KDE as bloated and slow from then on.
This distribution method works well for Opera, and I think its a great idea in their case. The difference is that Opera is one small binary. KDE is much larger, and is composed of many smaller binaries. This makes static linking impractical.
What really should happen is changes should be made in the GNU environment to facilitate moving binaries around much like Windows does. However, the focus of the GNU project has never been and never will be portable binaries, so it is unlikely that this will happen.
|
[
Reply To This | View ]
|
Say what you mean and mean what you say
by not me on Wednesday 11/Apr/2001, @22:11
|
>What amazes me about your last post is not how well you criticized what I've said - which you didn't do at all, IMO - but rather, how well you've criticized things I *didn't* say.
I'm sorry, I misconstrued your statement that "Underthumb is, without a doubt, 100% correct" as indicating that you actually agreed with what he said and were going to back up his argument. You were both apparently arguing that KDE should take on the full responsibility of providing binaries itself. You made no mention of your scheme for KDE to provide a single "official" set of portable binaries.
Now that you have, in fact, revealed your scheme in all its glory, I can respond to your actual argument. (by the way, why didn't you just say what you meant in the beginning?)
First of all, I agree that of course the developers are the ones who are best suited to compile KDE (although they are not best suited to adapting to the quirks of each and every distribution, which you seem to agree with).
However, I think your idea of providing a "single, statically linked binary" is not feasable for other reasons.
Here's the problem: KDE is not a single binary (not even close), so how do you propose to make a single statically linked binary out of it? Statically link every component, you say? My God, that's bloatware extreme! KDE memory usage would skyrocket! Only people with _over_ 256 MB of RAM would even be able to _think_ about running a statically linked KDE. A KDE with every component statically linked against QT would be impossible to run. Include QT as a shared library and statically link the rest, you say? Still extreme bloatware. The KDE project would _not_ be doing itself or anyone else a service by providing unusable binaries.
Besides, the utterly gigantic tar.gz file would be out of the reach of all but the most persistent modem downloaders.
These statically linked binaries would appeal only to a very small audience: Those people who have broadband connections to the Internet and also have truckloads of RAM that they don't mind wasting for no reason. Anyone else who tried these binaries would be repulsed by their large size and insane memory usage, and they would probably think of KDE as bloated and slow from then on.
This distribution method works well for Opera, and I think its a great idea in their case. The difference is that Opera is one small binary. KDE is much larger, and is composed of many smaller binaries. This makes static linking impractical.
What really should happen is changes should be made in the GNU environment to facilitate moving binaries around much like Windows does. However, the focus of the GNU project has never been and never will be portable binaries, so it is unlikely that this will happen.
|
[
Reply To This | View ]
|
Oops!
by not me on Wednesday 11/Apr/2001, @22:18
|
Argh! Stupid IE!
Sorry for the repeat post. I wish I could use Linux all the time and never deal with Windows and IE.
|
[
Reply To This | View ]
|
Read the text. Don't read *into* the text.
by WorLord on Thursday 12/Apr/2001, @12:36
|
"Now that you have, in fact, revealed your scheme in all its glory, I can respond to your actual argument. (by the way, why didn't you just say what you meant in the beginning?)"
I *did* say what I meant in the beginning... but I had no idea you'd read quite so much into it.
"Here's the problem: KDE is not a single binary (not even close), so how do you propose to make a single statically linked binary out of it?"
KDE is a gaggle of programs (executables) that require a flock of files to run (libraries).
Provide all of them in one zip (tar.gz) file. Or, ideally, privide a bare-bones, mid-range, and full set of each in separate tar.gz files.
"Statically link every component, you say? My God, that's bloatware extreme! KDE memory usage would skyrocket! Only people with _over_ 256 MB of RAM would even be able to _think_ about running a statically linked KDE."
Actually, I completely fail to see how the RAM requirements would change one iota. It takes RAM to load the executables + libraries on ANY system. I don't really think it matters *where* those libraries are located on the hard drive. The only difference would be that the static KDE binaries would provide these library files in one single directory (as opposed to how different distributions place them in different spots on the filesystem).
Now, there WOULD be wasted resources and redundancies WRT hard drive space; there would be whatever versioin of QT that came with the distribution AND a KDE-provided version of QT in the KDE directory (for example). And this would, undoubtably, make the download bigger. But KDE is already out of reach of most modem users - I think I d/led the 2.1.1 Mandrake Packages at roughly 80M. At that scale, what's another 20M tacked on? For downloads of that scale, I set it to download and go to bed either way, and it's all going to ZIP or CD/R anyway... both of which can handle the size.
"The KDE project would _not_ be doing itself or anyone else a service by providing unusable binaries."
They would be perfectly usable. Just a bit larger.
Whether or not they would be the most _practical_ solution for the _advanced_ Linux user is another matter entirely, and one that falls out of the scope of the argument. I suspect this is exactly where the Cooker/Rawhide/Woody people would step in and do what they've always done best, and I personally would probably wait for that (if for no other reason then to get the Pentium-optimizations that MD packages provide).
Does this make more sense, or am I off on understanding how Static things work?
--WorLord (a Tisket, a Tasket, a Task Manager)
|
[
Reply To This | View ]
|
Re: Read the text. Don't read *into* the text.
by Lubos Lunak on Thursday 12/Apr/2001, @16:15
|
The difference between shared and static libraries is that shared libraries are shared, while static are simply included in the executable, and therefore are not shared between different apps. Which means statically linked KDE would multiply memory usage and it would also multiply disk usage ( it wouldn't be another 20M, but maybe another 80M, or more probably 160M, or maybe even 320M, or maybe even more, I'm really not going to find out ).
This makes your 'universal static KDE binaries' idea useless and we're back at what's the best thing to do - to let the distros create the right packages ... after all, they get paid to create packages for people, unlike KDE developers, right ?
|
[
Reply To This | View ]
|
Re: Read the text. Don't read *into* the text.
by WorLord on Thursday 12/Apr/2001, @16:27
|
Hm.
Is it then possible to compile it shared, and simply include all the necessary shared *files* (libraries) in the distribution tar.gz? I've done this before on my local machine (with KDE library files of a different version) so I know something like it could be done.
<Rant>
And will you all stop saying that I advocate the idea that the distro packagers should stop, or are going to stop, making packages already? I've already clarified *twice* now that I don't believe that this should be the case, and frankly, I'm tired of hearing it stated or insinuated.
</Rant>
--WorLord
|
[
Reply To This | View ]
|
That's better.
by not me on Saturday 14/Apr/2001, @13:38
|
Including all of KDE's shared libraries with it would reduce the memory requirements from a statically linked KDE. It still wouldn't be an optimal solution, though, because there would be duplicates of nearly every shared library in memory. For example, KDE would come with its own glibc, and the system's glibc would also have to be in memory at the same time for all other applications. It might be worth looking into, though. Certainly it's much better than a statically linked KDE.
Still, though, I think that KDE would be better off letting people download their distribution's packages, and staying out of the binary distribution business. It reduces the support load that KDE must bear, and it provides a smaller download, better performance, and better distro integration for the end user.
|
[
Reply To This | View ]
|
|
Re: Here is the reality...
by CyberCzar on Wednesday 11/Apr/2001, @16:27
|
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 <b>typical
computer user</b> 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 <b>average computer user</b>."
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.
|
[
Reply To This | View ]
|
Um, you _are_ blind...
by WorLord on Thursday 12/Apr/2001, @14:57
|
...Either that, or you didn't read the *entirety* of the KDE general overview, and dealt with Underthumb's quote completely out-of-context as a result.
You wrote, "Ok, call me blind but nowhere does this mention LINUX or LINUX distributions."
From http://www.kde.org/whatiskde/index.html :
"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.
So yes, it does, in fact, quite clearly mention Linux. Specifically, even.
"Warlord and Undethumb can quit whining right now, before I send a pound of cheese to both of your houses."
Typical. Unable to address the issues at hand, you reduce valid points to "whining".
--WorLord
|
[
Reply To This | View ]
|
|
A very big misunderstanding. (was: Here is...)
by Karl-Heinz Zimmer on Thursday 12/Apr/2001, @13:57
|
On Wednesday April 11, @02:44PM, WorLord wrote:
> 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!
Best greetings,
Karl-Heinz (and please forgive my bad english!)
--
Karl-Heinz Zimmer * Foehren * Germany
|
[
Reply To This | View ]
|
You are correct - there IS a big misunderstanding
by WorLord on Thursday 12/Apr/2001, @14:43
|
...and you're making it.
"binary packages"
That phrase IS the whole misunderstanding. I said I thought it best for KDE to produce working _binaries_, not working binary _packages_.
The two concepts are radically different, although most people here seem to erroneously take them as synonymous.
Since those facts pretty much render most of your post irrelevent, see my discourse with no_one for the latest and greatest details.
--WorLord
|
[
Reply To This | View ]
|
Re: You are correct - there IS a big misunderstanding
by Karl-Heinz Zimmer on Saturday 14/Apr/2001, @14:22
|
Worolrd wrote:
> "binary packages"
> That phrase IS the whole misunderstanding.
> I said I thought it best for KDE to produce
> working _binaries_, not working binary
> _packages_.
I am sorry, but this comment gives me the idea that you never read Maximum RPM or something like that.
What binaries do you want? Statically linked ones of enormous size?
Or do you want packages that could be plugged into your distribution - taking all dependencies and side-effects into account automatically.
The 'normal user' wants a package made by people knowing the Distro, not a plain _binary_ - so forget about that!
* The KDE developers produce programs of high quality.
* The Distro Makers should produce packages by taking the sources, building the programs and libs and building the packages - that's the only thing that makes sense!
|
[
Reply To This | View ]
|
Maximum RPM?
by WorLord on Wednesday 18/Apr/2001, @15:57
|
"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*.
And that's pretty much the bottom line.
--WorLord
|
[
Reply To This | View ]
|
Re: Maximum RPM?
by not me on Thursday 19/Apr/2001, @23:59
|
"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 ;-)
|
[
Reply To This | View ]
|
Distro Integration issues
by WorLord on Friday 20/Apr/2001, @11:20
|
"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?
--WorLord
|
[
Reply To This | View ]
|
Re: Distro Integration issues
by not me on Friday 20/Apr/2001, @16:39
|
"As far as I'm aware, only MD 7.x integrates the K-Menu with the generic X-based menu system."
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.
|
[
Reply To This | View ]
|
Re: Distro Integration issues
by WorLord on Wednesday 25/Apr/2001, @16:25
|
"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? <grin> 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.
--WorLord
|
[
Reply To This | View ]
|
Re: Distro Integration issues
by not me on Wednesday 25/Apr/2001, @20:28
|
>Well, *that* is certainly out of the scope of the KDE project.
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...
|
[
Reply To This | View ]
|
Re: Distro Integration issues
by WorLord on Thursday 26/Apr/2001, @14:31
|
"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.
--WorLord (wonder if CheapBytes has it yet...)
|
[
Reply To This | View ]
|
Re: Distro Integration issues
by not me on Thursday 26/Apr/2001, @19:38
|
>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.
>MD 8.0 is supposed to be uber-excellent
That's über :-)
|
[
Reply To This | View ]
|
Ideas and Clarifications
by WorLord on Thursday 03/May/2001, @14:06
|
">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,
Actually, no. Refer to my earlier posts (and Underthumb's as well) to find the specifically quoted bits I'm talking about.
"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.
>MD 8.0 is supposed to be uber-excellent
That's über :-)
Oh. Sorry. ;-)
--WorLord
|
[
Reply To This | View ]
|
Re: Ideas and Clarifications
by not me on Sunday 06/May/2001, @19:58
|
"You don't seem to be understanding where I'm arguing from"
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.
|
[
Reply To This | View ]
|
Re: Maximum RPM?
by Denis on Tuesday 16/Mar/2004, @13:38
|
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.
|
[
Reply To This | View ]
|
Re: Maximum RPM?
by Denis on Tuesday 16/Mar/2004, @13:51
|
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 :))
|
[
Reply To This | View ]
|
|
Re: Here is the reality...
by Tim on Thursday 19/Apr/2001, @07:39
|
Buy Windows.
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.
|
[
Reply To This | View ]
|
Re: Here is the reality...
by WorLord on Thursday 19/Apr/2001, @11:14
|
"Buy Windows."
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_.
But you're right on the Potato chips thing.
--WorLord
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
