From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2390 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Summary of 1.0 marketing plan/scheme/nefarious plot from IRC. Date: Fri, 30 Nov 2012 23:06:20 -0500 Message-ID: <20121201040620.GE20323@brightrain.aerifal.cx> References: <60202.132.241.44.242.1354242108.squirrel@lavabit.com> <1354327484.2190.28@driftwood> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1354334793 32550 80.91.229.3 (1 Dec 2012 04:06:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Dec 2012 04:06:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2391-gllmg-musl=m.gmane.org@lists.openwall.com Sat Dec 01 05:06:46 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TeeLk-0002ow-VS for gllmg-musl@plane.gmane.org; Sat, 01 Dec 2012 05:06:45 +0100 Original-Received: (qmail 22458 invoked by uid 550); 1 Dec 2012 04:06:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22450 invoked from network); 1 Dec 2012 04:06:32 -0000 Content-Disposition: inline In-Reply-To: <1354327484.2190.28@driftwood> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2390 Archived-At: On Fri, Nov 30, 2012 at 08:04:44PM -0600, Rob Landley wrote: > >> - already tested against 8 gazillion packages > >> - standards compliant > >> - BSD license: static linking ok, android deployment ok > >Little quibble: MIT + some BSD and some PD code. > > Alas, we don't have a good group term like "copyleft" for "would be > public domain if our legal system wasn't screwed up". We do have a word for this license class; it's called "permissive". Roughly speaking, "FOSS" breaks down into "permissive" and "copyleft" licenses, where the former basically allow you to do whatever you like, and the latter burden you with ensuring that the parties who get the software from you get the same freedoms you had. > I poked Dalias on irc to clarify that we can give a single top level > license and call all the code "compatible" with that, and then link > to the big long copyright list for everybody who cares but have a > clear story on the website. The MIT license text serves this purpose. > >> - push "musl support" patches to other projects upstream all at once > >> - sabotage collected a bunch? > >And a number in musl-pkgsrc-patches (though I'm dubious about some > >of them) > > We can triage, confirm, document, and send them upstream as a batch > when 1.0 happens. > > >> - people who develop on 3 other project seeing musl on all 3 > >lists > >> makes dev community look big and active. > >> > >> - Write linux from scratch "musl hint", contribute it to LFS, > >then link > >> to it on LFS website from musl website. > >> > >> - is userbase of glibc, uClibc, klibc, or dietlibc better served by > >> musl? > >The dietlibc & uclibc section is where the puppy developers are > >starting > >to try musl. > > I'm tempted to analyze each libc variant: eglibc, uClibc, klibc, > dietlibc, newlib. Look at it, figure out what specifically its users > get out of it, figure out if musl can meet their needs. I can give you the short version... eglibc has very few advantages over plain glibc now that Drepper is gone. Mainly just some build-time options to tweak/omit features. My impression is that it will become obsolete now that glibc is improving. uClibc I think you know. :-) klibc is probably only relevant to initrd. In principle it's a lot like Bionic -- a "thin" libc that said "screw standards as long as we can provide the libc functionality needed in our very-limited domain". dietlibc's user base seems to be mostly fefe/djb fans, and maybe people making rescue disks and such. It's not secure or robust enough for internet-facing use or for many embedded uses. newlib's niche is systems with no kernel, or kernels very different from POSIX-oriented ones. I don't think it would be used on any systems any of the other libcs you mentioned get used on. Among these, I think the only two against which musl wins in all respects are klibc and dietlibc. As for the others: [e]glibc: There may be "enterprise" uses where musl lacks bloated legacy features glibc has (think things like NIS, locales with different charsets, utmp, ...), and of course glibc has established lock-in due to the existing binary ecosystem as well as software with source-level portability problems. uClibc: Its main advantage is just compatibility with existing embedded software that's non-portable and making uClibc-specific assumptions (probably without the authors even being aware). Compatibility with ancient Linux kernel versions may also be an issue for some embedded uses (needing to use an old kernel for compatibility or size reasons). musl has roughly the same level of compatibility with 2.4 kernels as uClibc does, except that uClibc also provides the hackish LinuxThreads for crappy-but-sometimes-usable multithreading on 2.4. On older kernels (2.2, 2.0), uClibc is probably the only working option. newlib: As distributed, musl is a full POSIX libc targetting the Linux kernel syscall API. Newlib can be used on all sorts of systems provided you fill in the system glue. However, if you're willing to do the same with musl (which could be as easy as making a __syscall function which implements the equivalent of the syscalls for stuff you do), musl could possibly fill newlib's role. > >> - contribute musl option to buildroot? > >> - contribute musl option to crosstool-ng? > >May be sensible. > >Embtoolkit is advertising that musl support is on its way. > > Yay! Nice. We should add a link back from the website and wiki. > Should we have a page collecting "projects using musl"? The project > will probably outgrow it, but to start with it might be nice. Yes. This is something I'd kind of hoped would evolve on the wiki. > (There's a chicken and egg problem: it would be a great thing to > include in a release announcement, but if you poke people about it > more than maybe a week before the actual 1.0 release date or you > might blunt your splash. Then again there's something to be said for > building anticipation, and musl isn't currently a _secret_...) If Embtoolkit, Aboriginal, and perhaps crosstool-ng or buildroot have support for it before 1.0, they would certainly be good items to mention in publicity materials. > >Also getting musl support upstream into apache would help, since > >one of > >the simplest benchmarks PTS does involves building apache from > >_unpatched_ > > source, then testing its performance. > > What's needed for that? Yes, I'd like to know too. Aside from this thread on the marketing/publicity aspects, we should have a pre-1.0 thread on determining what missing interfaces, bugs, differences from glibc, etc. are blocking compatibility with important packages so that I can get around to fixing them. At this point it might be nice if we had a bug tracker for it, but I think we can manage with just the list for at least a while longer. Rich