From: Jens Staal <staal1978@gmail.com>
To: musl@lists.openwall.com
Subject: Re: NULL
Date: Sat, 12 Jan 2013 12:39:20 +0100 [thread overview]
Message-ID: <1610513.RlLnocsNNl@krypton> (raw)
In-Reply-To: <1357972364.32505.4@driftwood>
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.
next prev parent reply other threads:[~2013-01-12 11:39 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-09 11:02 NULL John Spencer
2013-01-09 12:18 ` NULL Szabolcs Nagy
2013-01-09 13:36 ` NULL John Spencer
2013-01-12 6:32 ` NULL Rob Landley
2013-01-12 6:46 ` NULL Rich Felker
2013-01-12 7:15 ` NULL Luca Barbato
2013-01-12 13:33 ` NULL Rich Felker
2013-01-12 11:39 ` Jens Staal [this message]
2013-01-09 13:09 ` NULL croco
2013-01-09 13:47 ` NULL John Spencer
2013-01-09 14:49 ` NULL croco
2013-01-09 14:42 ` NULL Luca Barbato
2013-01-09 14:47 ` NULL Rich Felker
2013-01-09 15:03 ` NULL Luca Barbato
2013-01-09 15:18 ` NULL John Spencer
2013-01-09 15:36 ` NULL Rich Felker
2013-01-09 21:11 ` NULL Rob
2013-01-09 21:53 ` NULL Szabolcs Nagy
2013-01-09 22:17 ` NULL Rob
2013-01-09 23:42 ` NULL Szabolcs Nagy
2013-01-12 6:56 ` NULL Rob Landley
2013-01-12 7:07 ` NULL Bobby Bingham
2013-01-12 13:31 ` NULL Rich Felker
2013-01-13 14:29 ` NULL Rob Landley
2013-01-13 14:56 ` NULL Luca Barbato
2013-01-13 16:29 ` NULL Rob Landley
2013-01-13 17:14 ` NULL Luca Barbato
2013-01-13 15:23 ` NULL Strake
2013-01-13 17:17 ` NULL Luca Barbato
2013-01-13 17:47 ` NULL Szabolcs Nagy
2013-01-13 19:46 ` NULL Rob Landley
2013-01-14 6:11 ` NULL Rich Felker
2013-01-14 8:45 ` musl as a framework to test applications' compatibility with POSIX (was: NULL) Vasily Kulikov
2013-01-14 14:03 ` Rich Felker
2013-01-14 14:30 ` Vasily Kulikov
2013-01-14 15:02 ` Szabolcs Nagy
2013-01-14 15:14 ` Rich Felker
2013-01-14 13:19 ` NULL Rob Landley
2013-01-12 5:56 ` NULL Rob Landley
2013-01-12 6:42 ` NULL Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1610513.RlLnocsNNl@krypton \
--to=staal1978@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).