Re: [dev] Detaolb

I agree with some of the points you raise Kris, imagine staticly linked KDE
eeeep.

But on the other hand, a lot of functions that you might like to have
inlined will not be, and a lot of functions will be dynamic, when in fact,
no one is using them, at all.

So I think the key is controlling what is dynamic and what is static... But
that makes the dev model less minimalist.

I'm not providing this as any proof, more as trivia, but plan9 is static
linked, reasons like dependency hell are listed, it makes the OS its self
less complicated and the libraries less complicated.
Plan9 gains code reuse using servers and file systems, which to me, is a
little better.

Still if the static malloc() has some huge flaw, you won't be able to just
hit glibc, and magicly fix it, but how often is an interface fix that simple
anyway. Tracking code use through software can't totaly be solved by dynamic
linking.

So static linking with nice lean code like plan9, but the problem is, we
wanna use linux and if we want to use expected linux applications, we want
glibc and we want to use gcc and hell soon enough we have a whole gnu
toolchain and the advantages are looking sketchy.

I once saw an old linux version patched to compile with tcc, I'd love to see
a tight staticly linked distro built with this, tcc would see a more
dramatic performance gain in my imagination. And not having a gcc install
and the faster compile times is swell.

I agree that static linking is unreasonable with the current flow of things,
but I disagree that going aganst the flow and being unreasonable is bad, its
worth trying simply because not many distros do it. But I do think it would
be good to try and replace it with something else...

Although I imagine a lot less testing of static linked applications happens
and I'm not sure upstream devs will be happy to help when you post issues
with static linking.

Anywho chill out Kris, it might seem like a subject has no room for debate,
but every idea has the right to breath. I'm skeptical that just taking
ubuntu and then linking it staticly would make it faster (in fact when I was
toying with prelink I benchmarks showed my system was slower.). But with
love and care it's possible, and it might at least solve some package
managment issues, and decress tool chain bloat?

shared libraries are obviously a good idea until you’ve actually used
them. then whether it’s obvious or not that they’re a bad idea is mostly a
matter of how close you are to trying to get them to work.

- Rob Pike

Minimalism can be applied to many aspects of a distro.

Also chroots are less complicated with static linking.

Worth reading:
http://people.redhat.com/drepper/no_static_linking.html
http://en.wikipedia.org/wiki/Dependency_hell
http://en.wikipedia.org/wiki/Prelinking
http://anselmgarbe.blogspot.com/2008/02/linking_15.html
http://blogs.sun.com/rvs/entry/what_does_dynamic_linking_and

Lots of ideas for and aganst, come to think of it, I'm not sure if Kris was
saying that static linking has no merit or mearly that it's not
minimalism.... Etherway I think the debate has a way to go.

Gnome is better than Ktorrent anyway.

2009/5/23 Kris Maglione <maglione.k_AT_gmail.com>

> On Sat, May 23, 2009 at 12:28:47PM +0200, Matthias-Christian Ott wrote:
>
>> On Sat, May 23, 2009 at 11:17:18AM +0200, pancake wrote:
>>
>>> http://detaolb.sourceforge.net/
>>>
>>> Just my first time I see this minimal devel distro :)
>>>
>>
>> uClibc is by no means minimal, even though it's smaller than glibc.
>>
>> In my opinion a minimal system has all libraries in source code form
>> and statically links and compiles them with the programme's source code
>> (much like templates in C++). You can do a lot of optimisations using
>> this approach (constant propagation and dead code elimination, inlining
>> etc.), the programmes can be sequentially read from disk and will be
>> much smaller.
>>
>
> I don't know why I'm getting into this. I can't help but suspect that this
> is troll bait, but I don't know what goes on on this list. What you just
> said makes no sense to me. None of that has anything to do with minimalism.
> Efficiency, maybe. Disk efficiency, certainly not. There are reasons that
> most embedded systems dynamically link everything: it saves disk space. And,
> as for the read speed, dynamically linked libs are mmaped (on most systems,
> anyway) and shared between processes, which means, of course, that they're
> read into memory once. Statically linked binaries certainly might be read
> faster. They might not. It depends on too many variables to make blanked
> statements.
>
> Well, at any rate, I've just reread your post, and realized that that kind
> of nonsensical tripe (strewn with unconnected buzz words) can't be anything
> but troll bait. Nevertheless, I've gone to all the trouble of composing this
> rant, so I may as well send it.
>
> --
> Kris Maglione
>
> And the users exclaimed with a laugh and a taunt: "It's just what we
> asked for but not what we want."
>
>
>
Received on Sat May 23 2009 - 13:24:39 UTC