[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 29 Nov 2012 20:27:01 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Summary of 1.0 marketing plan/scheme/nefarious plot from
IRC.
On Thu, Nov 29, 2012 at 02:50:03PM -0600, Rob Landley 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.
Agreed. I never really wrote down this principle before, but it's been
in my mind for a long time. The main publicizing I've been doing so
far has been in niche places (like mips and microblaze lists) and
making sure musl is well-indexed in databases like freecode (formerly
freshmeat) and ohloh. I suspect there are a lot more of the latter we
should also hit.
> - 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.)
Yep. I especially liked your idea of holding off on some of the
upstream portability fix patches and sending them all at once as a
barrage. We might want to find someone in advance to organize the list
of where patches need to go and organize some people to handle posting
and following up on the bug reports. The *politely* element is key.
Anyone involved in this should spend some time practicing how to make
the reports politely rather than busting in with "omg ur software sux"
or similar. Even if many of the packages that need the most work are
packages that _we_ aren't interested in using for our own legacy-free
systems, working diplomatically with them and getting their bugs fixed
so that [potential] musl users don't come back with "why doesn't
such-and-such work with musl??" is important.
> - 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
> - works side by side with existing libraries, or static linked
> - easy deployment on android without bionic limitations
> - technical advantages
> - support static and dynamic linking and do _both_ well
> - thread implementation is _not_crazy_, and no legacy baggage.
Nice bullet points. I think we could expand on these some, but you
already hit a lot of good ones I was missing or overlooking.
> - obvious "start here" from main page.
> - Why it's cool (collate)
> - how to use it (collate)
> - HOWTO walkthrough
>
> - binaries they can try.
> - cross compiler, build hello world
> - livecd of full-ish x86 distro.
> - with working x11 and simple gui (xfce? fvwm?)
I'd go with xfce or lxde. Last I checked fvwm still didn't even have
modern text support (using legacy X font system). BTW, supposedly the
new HarfBuzz and other text rendering stack stuff has taken a turn in
the direction we like. I saw an article on the redesign that claimed
98-99% drop in bloat for working with fonts. I mention this mainly
because, as much as a lot of us are unhappy with FDO and related
projects, it would be nice to support and praise when that stuff does
move in the right direction.
> - chroot for each target with native development tools
> - system images for qemu maybe?
It would be really cool if we had "system root trees" rather than
"system images", with virtual 9p for booting qemu. By the way, getting
qemu working on musl should probably be in our compatibility goals for
1.0.
> - launch x11 vnc server and display in tightvnc window?
> - jslinux live image on website
Love this idea. I'd like it even better if we could adapt jslinux to
start with a preinitialized memory/machine-state image rather than
having to spend 15-20 seconds booting. BTW I think we need to look
into whether there are license issues with using jslinux...?
By the way, somebody also mentioned a mips emulator in js we could use
instead or in addition to jslinux, but I don't know if it emulates
enough hardware to get linux up.
> - distro conversions
> - leverage existing repositories, don't fall into the buildroot trap
I think I've already avoided this trap without avoiding new distros,
by building a community of people who like rolling their own distros
but not getting involved in the distro/build stuff at all myself. This
has been great for getting musl a lot of testing with lower entry
barrier than large existing distros, but adding the latter now would
be a good next step.
> - approach gentoo guys about a musl build
> - #gentoo-embedded on freenode
> - maybe funtoo would be easier (Daniel Robbins' new project,
> #funtoo on freenode)
> - approach debian guys about musl debootstrap
> - arch linux, slackware, puppy, crunchbang, tinycore...
> - http://distrowatch.com/popularity
> - approach cyanogenmod guys about doing a musl-based cyanogenmod.
> - way into man's heart is through the stomach and up under the
> ribcage,
> one way into android is cyanogenmod.
I like the idea of approaching cyanogenmod.
> - push "musl support" patches to other projects upstream all at once
> - sabotage collected a bunch?
> - people who develop on 3 other project seeing musl on all 3 lists
> makes dev community look big and active.
I like this idea a lot. See notes above.
> - Write linux from scratch "musl hint", contribute it to LFS, then link
> to it on LFS website from musl website.
Can you elaborate on what a "musl hint" would be?
> - is userbase of glibc, uClibc, klibc, or dietlibc better served by
> musl?
> - contribute musl option to buildroot?
> - contribute musl option to crosstool-ng?
There's demand for musl in crosstool-ng at least; the maintainer has
expressed this, but is largely unfamiliar with musl and waiting for a
patch from someone willing to do it.
> - Ask mentor graphics (formly code sourcery) to do a musl toolchain?
> - LOTS of proprietary embedded devs use this one, it's
> "professional".
I suspect they might be particularly interested since their customers
might need to avoid copyleft code.
> - windriver.com 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?
I think musl essentially obsoletes klibc. The main added cost of musl
over klibc for initrds, etc. is the soft-float code that will get
linked in due to printf on archs with no hard-float. If this is a
problem, we could eventually support an option with musl to inhibit
printf float code from getting linked at static-link time. This is a
bit nasty but could be done with weak symbol tricks. Of course, even
with all the soft-float code, I think binaries linked to musl will be
significantly smaller than all the kernel modules, firmware, etc.
stored on an initrd.
On the other side, the big advantage of musl over klibc is that you
don't have to worry about whether the apps you need will be okay with
the limited/non-conformant functionality provided by klibc.
Well-written apps should "just work", and be small.
> - 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."
> - http://www.arm.linux.org.uk/mailinglists/lists.php
> - http://www.linux-mips.org/wiki/Net_Resources#Mailing_lists
> - https://lists.ozlabs.org/listinfo/linuxppc-dev
> - http://vger.kernel.org/vger-lists.html#linux-x86_64
> - http://vger.kernel.org/vger-lists.html#dash
> - http://vger.kernel.org/vger-lists.html#initramfs
> - http://vger.kernel.org/vger-lists.html#linux-embedded
> - http://vger.kernel.org/vger-lists.html#util-linux
> - and maybe one "OS support" message to linux-kernel.
Agreed. I think the key is tailoring the message not to be spammy.
Presumably all of these lists are already used for announcing FOSS
stuff that's potentially useful to the communities they serve.
> - websites that might review musl if we ask nicely:
> - linux
> - lwn.net (submit via lwn@....net)
> - h-online (ping @codepope on twitter)
> - Linux Journal
> - Linux Today (they'll just link elsewhere)
I think getting the 1.0 release on Reddit, Hacker News, etc. would be
useful too. If for nothing else, as one step closer to the magic 7.
> - android
> - not personally familiar, google for "android news" finds several.
> - works well with android kernel, installs side-by-side with
> bionic,
> static links well, doesn't introduce any new licensing issues,
> provides full posix environment, active and responsive dev
> community.
Yep. I'm not familiar with these sites either though.
> - paper magazines
> - long shot, but if you send a press release to pc magazine and
> computerworld
> and such explaining how musl might help android bridge the gap
> between phones
> and the desktop they might write a "will android bridge the
> gap between phones
> and the desktop" article mentioning musl. :)
Nice talking points there.
> - tech bloggers
> - cringely.com
> - Consumer Electronic Linux Forum
> - Tim Bird and elinux.org
>
> - do a musl distro that runs well on raspberry pi, tell
> http://www.raspberrypi.org/
>
> - ask people on mailing list and irc to blog/tweet about the 1.0
> release when it
> happens.
Yes, this is definitely an under-utilized aspect of the (now rather
large) community.
> - write a syllabus for theoretical "teaching musl" one semester
> comp-sci course.
:)
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.
