[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141230193246.GR4574@brightrain.aerifal.cx>
Date: Tue, 30 Dec 2014 14:32:46 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Call for ideas for future musl-related talks
On Sun, Dec 28, 2014 at 04:24:43PM +0000, Justin Cormack wrote:
> On Mon, Dec 15, 2014 at 5:04 AM, Rich Felker <dalias@...c.org> wrote:
> > After having done a couple conference talks already at Ohio LinuxFest
> > 2013 and 2014, I'm considering pursuing more conferences, but I'm not
> > sure what topics/framing would be most interesting and effective at
> > getting more people interested in musl. If there's anything special
> > you'd like to hear me give a talk on, or think would be constructive
> > to the project, reply and let me know.
>
> Apologies for not getting back sooner.
No problem. Thanks for the feedback/ideas!
> I think the most interesting topic for a talk for a generalist
> audience is to cover the kinds of bugs you write about on ewontfix. (I
> wouldn't talk about systemd though, it is too partisan for people to
> listen clearly).
I agree completely and I've omitted systemd from past talks except
possibly some brief mention in response to questions from the audience
(I forget whether my remarks on systemd were during or after the
sessions but they weren't inflammatory anyway :).
> The focus should be around techniques for writing better software,
> better specifications, and how to find problematic areas. And about
> how writing tests for these things is hard, because a lot of them are
> races, although talking about where tests do and dont work is good
> too.
This has a lot of overlap with my Ohio LinuxFest 2013 talk, and while
I think people found it interesting, I think it was too
developer-oriented for most of the audience to get a lot out of it. If
I do that type of talk again I'd want either to make sure I'm talking
to an audience with the appropriate technical background or to find a
way to make it less technical but still compelling (and IMO that's
really hard).
> A title could be:
> Finding bugs in glibc by writing a better libc
> Better code by design, thought, and hard work
>
> A structure like:
> 1. What is Musl and why did I start writing it
> 2. Libc bugs are like compiler bugs they really ruin your day
> 3. Go into some detail as per ewontfix on 1-3 bugs as per ewontfix
> depending on talk length
> 4. How to spot potential bugs: code inspection, tests
> 5. Why Musl is less buggy than glibc: size, consistency, structure etc
> 6. Working with specifications, feedback, clarification
> 7. Musl is great, how to get started with it
I like this structure.
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.
