Re: Summary of 1.0 marketing plan/scheme/nefarious plot from IRC.

[Rich Felker <dalias@aerifal.cx>]

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