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