> i wasn't serious [about adding shared libraries]
the trouble with shared libraries is that they seem at first quite reasonable, and indeed at a fairly abstract level, it seems irrational to be more opposed to them than any other form of sharing, such as shared text, but the mechanics of linking and sharing (especially on current processors), and of configuration control, have so many hard facts that the simplicity of the original is quite lost. having experienced several variants, i find it now saves time just to adopt the irrational position from the start.
i think i'd rather have (say) mondrian memory protection than either shared libraries or the vm crud they keep adding to chips and systems.
> the trouble with shared libraries is that they seem at first quite > reasonable, and indeed at a fairly abstract level, > it seems irrational to be more opposed to them than any other form > of sharing, such as shared text, but the mechanics of linking and > sharing (especially on current processors), and of configuration > control, have so many hard facts that the simplicity of the original > is quite lost. having experienced several variants, i find it now > saves time just to adopt the irrational position from the start.
in fact i believe that a large part of the reason i can compress the root image so well is that my super-big-lz pass finds the shared code in all the binaries and gets rid of most of its footprint. (then i hand the result to bzip2 to finish the job.) so i don't even think shared libraries would even help much in this context.
uriel:
> P.S.: Unsurprisingly http://kencc.sf.net is nowhere to be seen in the SoC > site either... *sigh* hey, who knows, maybe in a couple of years more > we will have a website and a tarball for kencc!
there is nothing at all stopping you from setting up http://kcc.sf.net and populating it yourself. listen to dan cross.
Sorry, I hit Post when I wanted to click Undo, this was in answer to rsc's:
> there is nothing at all stopping you from setting up http://kcc.sf.net > and populating it yourself.
Sorry, I had read kencc.sf.net rather than kcc.sf.net. And yes, forking kencc has crossed my mind, mostly so there could be a chance in hell someone would ever use it. I even started to look into it with one of the BSD folks.
Sorry for deciding that maybe it was better idea to try to work with Charles rather than duplicating even more work.
> That is exactly what I proposed to Charles over a year ago, I'm still > waiting for access, I calculate it should take 5 min max to fix it.
no. what i said was that nothing is stopping you from making a new project (called, say kcc) and populating its pages as you see fit. nothing, that is, except that then you'd have one less thing to complain about.
> Sorry for deciding that maybe it was better idea to try to work with > Charles rather than duplicating even more work.
the thing you keep forgetting is that this sort of thing takes my spare time, and that's been limited for a time, even the time to wade through sourceforge conventions.
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.
I remember dmr posting a usenet message that outlined why shared libraries were a bad idea, back when the DLL's were in the works for OS/2. It must be somewhat frustrating to work hard to figure something out only to have everyone that follows walk right into the problem again.
> 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.
