faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
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. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
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)
