The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
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 ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
