[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120519114508.7206ec85@newbook>
Date: Sat, 19 May 2012 11:45:08 -0700
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: noXCUse, userspace options
On Fri, 18 May 2012 20:56:55 -0400
Rich Felker <dalias@...ifal.cx> wrote:
> On Fri, May 18, 2012 at 05:45:33PM -0700, Isaac Dunham wrote:
> > > There is also my noXCUse package, which aims at complete
> > > conformance in all commands implemented, but not many commands
> > > are implemented yet.
> > Had not heard of that one, and Google seems not to recognize it...
> > Is it publicly available yet?
>
> It's on git.etalabs.net. I didn't put any effort into the release;
> it's mostly code I had around from years ago. Only grep is new. Here's
> the gitweb link:
>
> http://git.etalabs.net/cgi-bin/gitweb.cgi
>
> > While we're enumerating permissively-licensed userspaces...
> Actually mine are still GPL or LGPL (I forget which), but I have no
> objection to relicensing them. I can do it sometime soon if anybody's
> interested.
I'd assumed that it was permissively-licensed because you mentioned it
in a thread that started with:
|Very cool, so with obase-musl [1] and pcc self-hosting on musl, we
|would only need the BSDfund challenge [2] to compile Linux with pcc to
|have a self-hosting system with only permissive stuff in userland :)
Your call on license. But if the discussion is about a
permissively-licensed userspace, mentioning a GPL one seems a bit odd.
> > well remember Android's toolbox,
> Somehow I doubt this works at all...
Enough to boot Android, that's all. I guess strike that.
> > and more relevantly toybox (Landley's
> > project that set off the whole discussion of licensing).
> Yes, toybox is quite interesting but incomplete. In the long term it's
> probably going to be the best option, though, especially if Rob ends
> up being responsive about issues that come up... (Like my recent
> finding that xargs is doing what many ppl wrongly assume it does,
> rather than what it's actually supposed to do.)
> > And in the less-viable set of options, there's beastiebox (way too
> > limited and BSD-specific, though it may compile on Linux),
> > and somewhere I saw a git repo with a port of netbsd userspace to
> > uclibc (incompatible with musl, of course--uclibc seems to be the
> > most "legacy friendly" libc in terms of headers, even compared with
> > glibc). Besides that there's heirloom-tools.
> > That would make 8 packages under permissive licenses that aim at
> > what you're talking about.
>
> But how many of them aim to implement POSIX compatible utilities, and
> of those, how many come close to succeeding? Tools that are rough
> lookalikes/workalikes for the standard tools but which behave
> differently in subtle ways are rather useless for the purpose of
> running third-party scripts (including configure scripts).
Implement POSIXish utilities: at least the NetBSD utilities,
heirloom (they have multiple personalities, one being xpg).
Aim at POSIX-like: those plus obase (by virtue of bing a port of
OpenBSD's usrspace, which is fairly close to conformant)
Farther upthread, it was indicated that the goal isn't a POSIX
userspace, but a self-hosting one.
> > So it isn't like there's a lack of options, it's just that none of
> > them seem to be ready at present.
> I agree there are several options, but not quite as many as you think.
Option: project aims to provide something that could be used for a
self-hosting permissively-licensed userspace, as per the quote I
referred to. Full POSIX/SUS4 conformance is not mandatory, as long as
builds work.
Ready: usable at present for a self-hosting environment.
In other words, "Plenty of projects aim to be usable for this, but few
of them are."
> > By the way, make is probably one of the biggest limitations--Linux
> > and musl both rely extensively on gmake features that none of the
> > BSD/permissively-licensd make versions support yet. You probably
> > won't get the kernel policy changed, either.
> GNU make is by far the best/only decent make. If anybody really cares
> that much about permissive license, they're free to make a clone, but
> since GNU make is self-contained, extremely portable, clean code, I
> think refusing to use it on the basis of license is silly...
The person who started this discussion was talking about a permissively
licensed userspace. While I agree that a fully permissive userspace
isn't really sensible, I thought I'd best clarify that they're
underestimating the work.
Isaac Dunham
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.
