Re: [9fans] acme, rio workalike available in plan 9 ports

[Eli Collins <eli@cs.wisc.edu>]

ron minnich wrote:

> On Tue, 20 Apr 2004, boyd, rounin wrote:
> 
> 
>>debian managed to shoot themselves in the foot with some libc,
>>some time back.  you couldn't go forward 'cos other stuff would
>>break and you couldn't go back 'cos more stuff would break.
> 
> 
> gets better. Symbols are now versioned (well, this really happened a few
> years back). So you are very tightly screwed (good word) to the library
> you use, and it covers a definite range forward/backward. I assume but am
> not sure that glibc nowadays encompaesses lots of versions of lots of
> functions going back for years. Which also means the version naming of the
> file (libc-2.3.2.so) has a lot less meaning than it used to. At some
> point, given the tight wiring of an executable to the particular library
> version, one starts to lose track of just why .so's are still thought to
> be a good idea (I mean, on a 1960s-era Burroughs machine with not much
> memory, I get it, but ... /bin/cat on my Redhat box at 20K, is not much
> smaller than /bin/cat on Plan 9 (22K stripped), and the Plan 9 one doesn't
> do symbol fixup every time it runs ...).
> 
> And, as Linus mentioned, TLBs matter. Hmm. Judging by 'ps', cat on linux
> needs 256 of them, and cat on Plan 9 needs 6. xclock has got 900 or so, 
> and Plan 9 clock appears to have 3*30 or so (3 clock procs when you run 
> clock). 
> 
> So you do pay a bit for .so's. You don't gain an
> implementation-independent interface for your programs, since the .so is
> versioned and the symbols in it are versioned; I wonder what you DO gain?  
> The theory always was you could swap out a shared library and swap in a
> bug-fixed version, which sounds nice until you try it and it fails
> miserably (there was a time when this worked ...)
> 
> ron
> 

Why does this no longer work? I've upgraded glibc on a gentoo linux 
system without much dificulty.

I like the simplicity of static linkage but it seems like a nightmare if 
Oracle had to build/test/ship a new version of their code every time 
there was a bug in printf or some xml parsing library.

Regarding the TLB and SOs, I can't figure out all the fuss either since 
the TLB is flushed on context switch (on x86 at least).

eli