C library system-call wrappers, or the lack thereof

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 18:52 UTC (Thu) by farnz (subscriber, #17727)
In reply to: C library system-call wrappers, or the lack thereof by plugwash
Parent article: C library system-call wrappers, or the lack thereof

The advantage of the current system becomes clear when you have a split between "system administrators" (SAs) whose expertise does not lie in maintaining complex software, and "developers" (Ds) whose time is considered valuable by management. SAs don't build new binaries - they maintain systems on which binaries from Ds are run. Ds work with the latest and greatest systems at the time they build software, and can debug anything that breaks.

In the current system, SAs can upgrade glibc, knowing that binaries that Ds have stopped maintaining will still work. If a mission-critical binary has no Ds working on it, it'll keep giong until it's replaced by the new thing. If you take that away, SAs get told to not apply updates to systems, even critical security fixes, because the tradeoff between a potential security hole and a guaranteed failure of business-critical systems is rarely in favour of the security hole being fixed. OTOH, if the binary is being maintained (i.e. Ds are working on it - no other process produces new binaries), the Ds working on it will debug the failures with the new libraries.

In a good organisation, it's a non-issue either way round - you build from source regularly, and you debug anything that stops working after an update. System libraries advance whether you like it or not, and you just have to keep up. The question then is what sort of dysfunctional organisation is more common; one in which there's no-one available to debug an old codebase, but there are binaries that you can run, or one in which there's more issues with a rebuild from source being broken than old binaries suddenly ceasing to work?

---

to post comments