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

From: Charlton Head <charlton_AT_openmailbox.org>
Date: Thu, 12 May 2016 15:16:23 -0500

On Thu, May 12, 2016 at 05:36:44PM +0200, 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?
>
> Kind regards,
> Hans
>
> PS: Think about the Heartbleed bug in openssl for example.
>

If you use GNU grep you could just type 'grep -r TLS /bin' and it will
find matches for binaries that are likely linked with the TLS/SSL library.
Even better, you could grep for an exact symbol as well. And of course
timestamps will tell you the last time the binary was updated/changed.

You might be able to do this with just the sbase tools, but I don't know how
offhand as I pretty much know which of my programs are using TLS/SSL without
needing special commands.

As for configuration/customization in header files, the point is that users
can't make those changes, as they can potentially find bugs and do things
you did not intend them to do with the program. But if you want to allow
users to make configuration changes and not run their own binaries, then
that is a different use case and I don't think you can satisfy both in a
program that is suckless. So the default is that all configuration is done
in a header file and that is the most secure(among other things).

AND, of course, user configuration of suckless programs are optional and are
not required as far as I can tell.
Received on Thu May 12 2016 - 22:16:23 CEST