begin quoting Michael O'Keefe as of Mon, Aug 28, 2006 at 01:52:03PM -0700: > >>>>Linux *still* sucks. > >>> > >>>In many ways yes - dependencies (WTF can't people compile static > >>>versions of applications?!), > >> > >>And waste all that diskspace linking in libc (at least!) a couple of > > > >Sometimes, disk is cheap. > > Sometimes, but not on embedded systems, but I will assume from herein we > are talking about big-arse disk-spaced desktop systems.
Indeed. But embedded systems bring a whole different set of issues to the table. > >>thousand times (ok, yes it doesn't link it all in, only the required > >>symbols) and let's not even talk about security fixes...got a patch for > > > >'cuz if it don't work at all, that's secure. > > But how do I know (in a static linked environment) who is using the code > that is vulnerable ? Documentation? > We had some developers linking statically, and when we released a patch > to one of our "common software" libraries, they got in a huff coz they > had to re-release. From our point of view, they shouldn't have been > using static libraries. Yes, they'd locked themselves into a "well > tested" (HA!) version, but the flip side of that coin is they have to > re-release becoz they locked themselves in ! Yup! TANSTAAFL. There's always a tradeoff. > Of all the apps that are statically linked, who is using function X() > that has been patched ? Do we have to do a complete code survey to find > out ? Or just upgrade the .so and everyone who IS using it, gets the fix > automagically. ....and a bunch of stuff crashes because it's hard to change just one thing. Either way, someone's going to get screwed. There is no "just upgrade the .so" -- it's "upgrade the .so, then run the regression test suite" and quite possibly recompile several applications. Or you can just use your build system to recompile everything, and then use cksum or diff to identify those programs that need to be rereleased because they generated a different executable. (And then run the regression test suite anyway to make sure no bugs were introduced, but that's hopefully part of the "build-everything" target.) [snip] > >If I, as a application developer, am going to require a specific version > >of a shared library, to where a point-increment on the library will break > >my program, then I might as well use the static version of the library. > > (I assume here your "point-increment" is the 3rd digit in a > major.minor.minimal version numbering scheme) Yes. Major.Minor.Point or Major.Minor.Bugfix. Point or bugfix (or minimal) is for no changes to the interface. Minor is for additions to the interface. Major is for incompatible changes to the interface/design. > A point release should not affect anyone outside the interfaces > (following libtool rules/guidelines). If it does, then either the rules > haven't been followed, or it should not have been a point release. That's the theory, yes. Practice differs, as you point out: > >If I, as a library developer, want to remove functions from the library, > >or reorganize the argument lists, I should save up these changes and > >then bump the major revision of my library. I should ensure that code > >written against my libFoo.so.4.0.0 works with libFoo.so.4.21.34 without > >recompiling the application code. > > Absolutely. Should be using libtool for the versioning and following the > libtool numbering rules. But it's still prone to human error. I have C++ > developers who think that adding a new parameter with a default value > preserves the compatbility. They don't realise that this removes the N > parameter symbol from the table and add's an N+1 symbol version, and > will instantly break the running apps. Exactly. > >This will, however, slow down development. It would require more testing. > >I should dope-slap anyone on my team who wants to put a "works best with" > >disclaimers for a particular distro. > > Not really. That it will slow down development, or that I should be dope-slapping folks? > If you follow your proposed rules (and libtools rules) the > moment you release a change that removes "something" (function, enum > value, #define) you should bump the major number. Somethings won't > affect runtime (enum) but they will affect a compilation. I treat > major-number-bumping as a "oh, I HAVE to pay attention to this" for the > developers Yup. > >>libc, release EVERYTHING statically linked again ? f*ck that ! > > > >If we're finding security bugs in libc on a regular basis, we have > >more serious problems than saving a little time upgrading our programs. > > Just once is a enuff to cause a PITA ! There are times when the idea of a just-once PITA versus a semi-routine PITA looks really appealing. I know of systems where they *don't* apply security patches because if they do so, Important Software *will* break (or produce garbage output). They know it's dangerous, but as what they _do_ depends on the Important Software, they can't afford to break it... and even if they have the source code, they may not be able to afford to have someone make it work (and make sure it gives the same answers as before). What we need is an easy way to take a program and it's shared libraries and make it into a statically-linked program.... > Rather than install a new libc, you have to recompile *everything* and > re-release everything. Might as well use GENTOO ! Heh. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
