From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2388 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: Summary of 1.0 marketing plan/scheme/nefarious plot from IRC. Date: Fri, 30 Nov 2012 20:04:44 -0600 Message-ID: <1354327484.2190.28@driftwood> References: <60202.132.241.44.242.1354242108.squirrel@lavabit.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1354327504 19167 80.91.229.3 (1 Dec 2012 02:05:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Dec 2012 02:05:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2389-gllmg-musl=m.gmane.org@lists.openwall.com Sat Dec 01 03:05:14 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 1TecS8-0003dI-PT for gllmg-musl@plane.gmane.org; Sat, 01 Dec 2012 03:05:12 +0100 Original-Received: (qmail 14067 invoked by uid 550); 1 Dec 2012 02:05:01 -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 14056 invoked from network); 1 Dec 2012 02:05:00 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:subject:to:in-reply-to:x-mailer:message-id:mime-version :content-type:content-disposition:content-transfer-encoding :x-gm-message-state; bh=slFHPDgPwwPUuVnZ52ozFiPdltGPjk50c5wJQBL45uU=; b=c2vo043UaAhqJp2vOhiUuGTakYD05KwIBz60LwZMnFm1MTVjlEEFJJyKlxAgJthEGa tybonm1GsBwMR7maLjiCGVHdI7TqZ4PAMVChYlXOE9/Vm751TWFU/xx4WdoZEhrW4ttd 4mlqQNVT2CoZm0YRfzQfLmpbzwR6XwruLvkrP276cP7vD1mF3i48kAPAJYrNjRk1a/3b 2TNmtI6uQmXXByaSjnrCK0eTuCvYpBrF8WM2h6kEI9/mHfaipmLGq8hTN2AP67/lRAO/ XLlvejYzDFFvpDMs0H/HM9vXX5GNqV3wtKUwL5cZsce31xHYfgG6QGcutBjhHIwwaiOc 5qNw== In-Reply-To: <60202.132.241.44.242.1354242108.squirrel@lavabit.com> (from idunham@lavabit.com on Thu Nov 29 20:21:48 2012) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQm2+iUQBeEueJEz1EEyJXvVhE1vliKc0pJfRoTAFFjmPqF0FwC5td6qodqd4gkBvfdvDcaU Xref: news.gmane.org gmane.linux.lib.musl.general:2388 Archived-At: On 11/29/2012 08:21:48 PM, idunham@lavabit.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 =20 > won't > > remember they've > > even heard of you until they've seen it in ~7 different =20 > places. So > > once you _ARE_ > > ready, get the word out everywhere. (Politely.) > > > > - prepare the website to covert casual browsers into long-term =20 > 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" =20 > 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 =20 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 =20 license and call all the code "compatible" with that, and then link to =20 the big long copyright list for everybody who cares but have a clear =20 story on the website. (Gregor is of the opinion that every binary statically linked against =20 musl cannot be distributed without including a copy of the complete =20 text of every single sub-license in the entire musl tree, in all the =20 varied wordings, and that distributing binaries without bundling them =20 in an archive with such an array of legal documents would be a license =20 violation. I point out that he's not a lawyer, say "the program" =20 referring to source versions sounds like a perfectly reasonable =20 interpretation to me and anybody trying to prove otherwise in court =20 might have an interesting time getting nonzero damages although if they =20 asked nicely for me to include it I would happily stop using or =20 distributing any of their software, and otherwise ignore him.) > > - distro conversions > > - leverage existing repositories, don't fall into the buildroot =20 > 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, =20 > and one > of them is involved in a large number of the puppy projects/puplets. > TinyCore: Already some awareness: someone emailed pcc-list about =20 > enabling > linux-arm, with the intended usecase being microcore/some variant of =20 > "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 =20 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 =20 > them) We can triage, confirm, document, and send them upstream as a batch =20 when 1.0 happens. > > - people who develop on 3 other project seeing musl on all 3 =20 > lists > > makes dev community look big and active. > > > > - Write linux from scratch "musl hint", contribute it to LFS, then =20 > 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 =20 > starting > to try musl. I'm tempted to analyze each libc variant: eglibc, uClibc, klibc, =20 dietlibc, newlib. Look at it, figure out what specifically its users =20 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 =20 time to do proper research right now... > FWIW, I got their attention by mentioning the size of a full-static =20 > binary > for tinymp3, a little ffmpeg-based MP3 player; the license change got =20 > some > interest too. >=20 > > - 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 =20 will probably outgrow it, but to start with it might be nice. (There's =20 a chicken and egg problem: it would be a great thing to include in a =20 release announcement, but if you poke people about it more than maybe a =20 week before the actual 1.0 release date or you might blunt your splash. =20 Then again there's something to be said for building anticipation, and =20 musl isn't currently a _secret_...) > > - Ask mentor graphics (formly code sourcery) to do a musl =20 > 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@vger or embedded@vger (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 =20 > architecture, > > here are > > a cross compiler, chroot with native compiler, and a system =20 > 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@lwn.net) > > - h-online (ping @codepope on twitter) > > - Linux Journal > > - Linux Today (they'll just link elsewhere) >=20 > 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 =20 > 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 =20 > of > the simplest benchmarks PTS does involves building apache from =20 > _unpatched_ > source, then testing its performance. What's needed for that? Rob=