Re: [dev] Detaolb

From: Matthias-Christian Ott <>
Date: Sat, 23 May 2009 16:52:11 +0200

On Sat, May 23, 2009 at 11:24:39PM +1000, Nathan Hutchison wrote:
> 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.

I don't understand what you mean. You remove useless functions when
doing dead code elimination and inlining is a space-time tradeoff and
depends on the CPU you are compiling for.
> 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.

Well that's just theoretically true, in practice you have versioned
dynamic libraries (sometimes several versions).

For static linking you could simply save separate files with hash sums
of the files you compiled in and compile the applications when one of
the files changed. You could also do chaching.
> 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 certainly don't want to use GNU/Linux, I just have to.
> 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.

But the code optimisation tcc performs is very poor. Despite all the
bloat of gcc, it sill does something useful when compiling your programme.
> 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...

Well, I certainly don't intend to invent yet another GNU/Linux
distribution. Moreover, fixing Linux is not a good idea too - it's simply
not worth the effort (it just has all the drivers, this is why nobody
wants to reinvent it).

> 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:
> 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 <>
> > 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:
> >>
> >>>
> >>>
> >>> 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 - 14:52:11 UTC

This archive was generated by hypermail 2.2.0 : Sat May 23 2009 - 15:00:01 UTC