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  and pcc self-hosting on musl, we |would only need the BSDfund challenge  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.