Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 30 Nov 2012 20:04:44 -0600
From: Rob Landley <>
Subject: Re: Summary of 1.0 marketing plan/scheme/nefarious plot from

On 11/29/2012 08:21:48 PM, wrote:
> > Notes from the discussion we had on IRC, plus some further random
> > thoughts on telling the world about musl:
> >
> > - wait until 1.0 so it's most likely to works for them.
> >    - People who take a look and wander off again are less likely to
> > take another look,
> >      so try to make a spash when you're _ready_, not before.
> >    - counter this with "rule of 7", people filter out noise and  
> won't
> > remember they've
> >      even heard of you until they've seen it in ~7 different  
> places. So
> > once you _ARE_
> >      ready, get the word out everywhere. (Politely.)
> >
> > - prepare the website to covert casual browsers into long-term  
> users.
> >    - press release extoling virtues
> >      - simple
> >        - realtime: less code is more deterministic
> >        - security: less code is easier to audit
> >        - students/teachers: learn how a posix system works
> >      - link to the online git browser for the "show me the code"  
> guys.
> >      - 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".

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.

(Gregor is of the opinion that every binary statically linked against  
musl cannot be distributed without including a copy of the complete  
text of every single sub-license in the entire musl tree, in all the  
varied wordings, and that distributing binaries without bundling them  
in an archive with such an array of legal documents would be a license  
violation. I point out that he's not a lawyer, say "the program"  
referring to source versions sounds like a perfectly reasonable  
interpretation to me and anybody trying to prove otherwise in court  
might have an interesting time getting nonzero damages although if they  
asked nicely for me to include it I would happily stop using or  
distributing any of their software, and otherwise ignore him.)

> > - distro conversions
> >    - leverage existing repositories, don't fall into the buildroot  
> trap
> >    - approach gentoo guys about a musl build
> >      - #gentoo-embedded on freenode
> >      - maybe funtoo would be easier (Daniel Robbins' new project,
> > #funtoo on freenode)
> Luca Barbado covered this one ;)

I happily defer to the judgement of domain experts.

> >    - approach debian guys about musl debootstrap
> >    - arch linux, slackware, puppy, crunchbang, tinycore...
> Puppy: Already some awareness. Fatdog64 allegedly includes a musl
> toolchain.  At least two of the developers involved in pupngo (an
> experimental "puppy project" that produces a _very_ small & minimal
> ~Puppy-style distro/project) have been working on musl toolchains,  
> and one
> of them is involved in a large number of the puppy projects/puplets.
> TinyCore: Already some awareness: someone emailed pcc-list about  
> enabling
> linux-arm, with the intended usecase being microcore/some variant of  
> "Army
> Core" on A10 devices.
> (pcc apparently supports ARM but only on some BSD flavor)

I look forward to the toolchain problem being solved. I'm not holding  
my breath.

> > - 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.

But I'm just not familiar enough with most of them, and haven't got  
time to do proper research right now...

> FWIW, I got their attention by mentioning the size of a full-static  
> binary
> for tinymp3, a little ffmpeg-based MP3 player; the license change got  
> some
> interest too.
> >    - contribute musl option to buildroot?
> >    - contribute musl option to crosstool-ng?
> May be sensible.
> Embtoolkit is advertising that musl support is on its way.


Should we have a page collecting "projects using musl"? The project  
will probably outgrow it, but to start with it might be nice. (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_...)

> >    - Ask mentor graphics (formly code sourcery) to do a musl  
> toolchain?
> >      - LOTS of proprietary embedded devs use this one, it's
> > "professional".
> >      - is now a wholly owned subsidiary of intel
> >    - klibc guys are initramfs@...r or embedded@...r (see lists)
> >      - ask clibc author Peter Anvin if musl serves his needs?
> >
> > - mailing lists you can post a "here's how musl can help _you_" on:
> >    It's not spam if you tailor a post to each list, especially if
> > there's patches
> >    attached in the case of dash or util-linux...
> >    - each architecture list for arches you support (linux-arm,
> > linux-ppc, etc).
> >      "musl is pleased to announce support for the $BLAH  
> architecture,
> > here are
> >       a cross compiler, chroot with native compiler, and a system  
> image
> > to play with."
> I'm assuming this would mean some of your work and some of Gregor's?

It would mean getting it to work, doesn't matter which implementation.

> >      -
> >      -
> >      -
> >      -
> >    -
> >    -
> >    -
> >    -
> >    - and maybe one "OS support" message to linux-kernel.
> >
> > - websites that might review musl if we ask nicely:
> >    - linux
> >      - (submit via
> >      - h-online (ping @codepope on twitter)
> >      - Linux Journal
> >      - Linux Today (they'll just link elsewhere)
> I'd add Phoronix.  I'd suggest inquiring about a "guest article" (make
> sure to mention that it builds with clang as well as GCC, since  
> Micheal
> seems to to love anything related to LLVM)

Always good to tailor the article to the outlet. :)

> 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?


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.