mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Call for ideas for future musl-related talks
Date: Tue, 30 Dec 2014 14:32:46 -0500	[thread overview]
Message-ID: <20141230193246.GR4574@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAK4o1WyP9Rk_rX-JKG=2WXxWB-0WKfH8Lm-3oReQcfkZF8vV-Q@mail.gmail.com>

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


  parent reply	other threads:[~2014-12-30 19:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-15  5:04 Rich Felker
2014-12-28 16:24 ` Justin Cormack
2014-12-29  0:29   ` Szabolcs Nagy
2014-12-30 19:45     ` Rich Felker
2014-12-30 22:11       ` Laurent Bercot
2014-12-31  7:12     ` Natanael Copa
2014-12-30 19:32   ` Rich Felker [this message]
2015-01-04  4:17 ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141230193246.GR4574@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).