[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 18 May 2012 20:56:55 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: gcc segfault at src/mman/mlockall.c
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, we might as
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.
> well remember Android's toolbox,
Somehow I doubt this works at all...
> 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).
> 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.
> 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. It's not
like other GNU packages that give you plenty of technical reasons to
dislike them in addition to whatever your ideological reasons are.
Rich
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.
