[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 30 Nov 2012 20:04:44 -0600
From: Rob Landley <rob@...dley.net>
To: musl@...ts.openwall.com
Subject: Re: Summary of 1.0 marketing plan/scheme/nefarious plot from
IRC.
On 11/29/2012 08:21:48 PM, idunham@...abit.com 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.
Yay!
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".
> > - 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?
> >
> > - 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.
> > - 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.
> >
> > - 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'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?
Rob
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.
