Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 12 Jan 2013 12:39:20 +0100
From: Jens Staal <>
Subject: Re: NULL

lördagen den 12 januari 2013 00.32.44 skrev  Rob Landley:
> I wouldn't be too impressed by this.
> There are somewhere between 200 and 900 packages that cross compile  
> "easily", for a decreasingly obvious definition of "easily" depending  
> on how many rocket engines you want to strap to the turtle. Projects  
> like OpenEmbedded and Beyond Linux From Scratch recapitulate phylogeny  
> with these packages, and then hit the point where your volunteers' time  
> is entirely consumed dealing with package upgrades to hold the existing  
> turf against bit-rot. (Personally, I refer to this as "the buildroot  
> event horizon".)
> Actual distributions eventually separate "the OS" from "the  
> repository", where they have a core team who does work on the operating  
> system and a separate (much, much larger) set of package maintainers  
> who keep their packages of interest working but don't generally work on  
> the base OS other than complaining when something breaks.
> You only get to the "real distro" stage when the base OS stops being  
> interesting. While the base OS remains a moving target, package  
> maintainers can't do their jobs without also being OS maintainers,  
> which is a much bigger time commitment and has Brooks' Law problems  
> with coordination overhead scaling your core team.

pkgsrc is already doing quite well with musl libc and Gregor's "per package 
namespace" ideas in Snowflake seeem very interesting*, also utilized in 
Sabotage. Most likely, source-based or combined source/binary based 
distributions like pkgsrc or gentoo are probably the fastest and "easiest" to 
get going. Hooking up to a binary distribution distro like the debian-based or 
rpm-based ones still means that one needs sepparate repositories for the new 
libc (so the number of repositories will then be supported archs * supported 
libcs) - probably a more difficult proposition.

* Even cooler would ofcourse be to be able to use union mounts and private 
namespaces instead of symlinks to a default PATH like /bin, but that is not 
really relevant for this particular discussion.

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.