Re: [dev] Linux distros that don't suck too too much

From: Charlie Kester <corky1951_AT_comcast.net>
Date: Thu, 12 May 2016 11:03:18 -0700

On Thu 12 May 2016 at 08:36:44 PDT Hans Ginzel wrote:
>On Thu, May 12, 2016 at 07:42:26AM -0700, Charlie Kester wrote:
>>Package systems are both a symptom and a cause of bloat. They only
>>exist because most software, along with its metastasizing dependencies,
>>is a pain in the ass to compile.
>>
>>The correct solution isn't hiding those problems with a package
>>manager, but to avoid those dependencies and the bloat in
>>individual programs by following suckless principles in the first place.
>
>Which concrete principle do you mean, please?
>
>Copying the “shared/same code” into each program?
>But how to maintain updates of such code, e.g. security update?
>
>The code could be in a library. But if you want to dismiss
>packages/dependencies it is necessary to link statically.
>But how to determinate which all programs to recompile
>in case of (security) update? Grepping header files?
>
>And in multiuser environments, where each user compile it's programms,
>because of the “Configuration/customization in header file” principle,
>how does the maintainer force every user to recompile
>it's appropriate set of programms in case of (security) update
>of a library code? Is such system maintainable, please?

Perhaps if you had some experience with the ports systems I mentioned
you would know that the kind of problems you describe are no more a
problem with them than with a package management system. They both
involve an infrastructure describing the relationships between the
various ports or packages, and therefore they both support updating a
particular library and all of the programs which depend on it.

At the level of a "first approximation", the only difference between a
package and a ports system is whether what you download is a precompiled
binary. And, as I said in my original reply, the reason most people
prefer the precompiled binaries is (a) the time it takes to compile; or
(b) their inability to figure out what to do when the build fails. Both
of these problems arise from the complexity of the software involved.
(Among other things, simpler i.e. suckless software is less likely to
have the kind of corner cases that lead to build failures.)

Static linking is a separate issue, but it has long been favored by the
suckless community. (Hence stali.) You might want to read some of the
insightful things Anselm Garbe has had to say about it.
Received on Thu May 12 2016 - 20:03:18 CEST