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.
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 ?
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 !
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.
The underlying problem is, of course, poor library-management discipline.
Many library developers appear to have lost their reluctance to remove
functions, or to spend some effort ensuring backwards compatibility
AND to think about forward compatibility. Likewise, many developers seem
to have decided that the "required" version is the one they're using
now, and so hard-code a link to a *specific* version of a shared library.
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)
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.
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.
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. 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
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 !
Rather than install a new libc, you have to recompile *everything* and
re-release everything. Might as well use GENTOO !
--
Michael O'Keefe | [EMAIL PROTECTED]
Live on and Ride a 03 BMW F650GSDakar| [EMAIL PROTECTED] / |
I like less more or less less than |Work:+1 858 845 3514 / |
more. UNIX-live it,love it,fork() it |Fax :+1 858 845 2652 /_p_|
My views are MINE ALONE, blah, blah, |Home:+1 760 788 1296 \`O'|
blah, yackety yack - don't come back |Fax :+1 858 _/_\|_,
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
