[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1610513.RlLnocsNNl@krypton>
Date: Sat, 12 Jan 2013 12:39:20 +0100
From: Jens Staal <staal1978@...il.com>
To: musl@...ts.openwall.com
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
