From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1296 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: Draft: musl promo materials Date: Sat, 14 Jul 2012 12:05:15 -0700 Message-ID: <20120714120515.1b75fddb@newbook> References: <20120713181254.GA31206@brightrain.aerifal.cx> <20120713233052.GA1110@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1342292736 27517 80.91.229.3 (14 Jul 2012 19:05:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 14 Jul 2012 19:05:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1297-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 14 21:05:36 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 1Sq7eo-0000o3-Gv for gllmg-musl@plane.gmane.org; Sat, 14 Jul 2012 21:05:34 +0200 Original-Received: (qmail 30178 invoked by uid 550); 14 Jul 2012 19:05:33 -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 30168 invoked from network); 14 Jul 2012 19:05:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=lXdysAHKMnlmote8kzmoJJcBti2cnyedMJtMuJOk9S4Y1FihEM2qtDxeE4szeO9ralATjIUUej4G9nde2aEyUk86rD5mEZ/eXhiyR1GFLxfa0ftwZCRysZBkNwfncNu7tplFdaIyVWGQ+qVae7O+cl38IDYmAkNO1PT9G3gSYVE=; h=Date:From:To:Subject:Message-ID:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; In-Reply-To: <20120713233052.GA1110@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.20.1; i486-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:1296 Archived-At: On Fri, 13 Jul 2012 19:30:52 -0400 Rich Felker wrote: > Updated version based on some comments.. I think the list is getting > long enough that it would possibly make sense to reorder/trim it for > the intended target audience in some usages, and only include the full > thing on the website. > > Rich > > > ---------------------------------------------------------------------- > > Consistent quality and implementation behavior from tiny embedded > systems to full servers. > > Minimal machine-specific code, meaning less chance of breakage on > minority architectures and better success with "write once run > everywhere" development. One criticism I've heard (not saying I agree!) is that you lose performance with musl thanks to most functions being in C... > Extremely efficient static and dynamic linking support, yielding small > binaries and minimal startup overhead. > > Realtime-quality robustness. No unnecessary dynamic allocation. No > unrecoverable late failures. No lazy binding or lazy allocation. > This reminded me about _XOPEN_REALTIME: "This Option Group consists of the set of the following options from within POSIX.1-2008 (see Options ): _POSIX_FSYNC _POSIX_MEMLOCK _POSIX_MEMLOCK_RANGE _POSIX_MESSAGE_PASSING _POSIX_PRIORITIZED_IO _POSIX_PRIORITY_SCHEDULING _POSIX_SHARED_MEMORY_OBJECTS _POSIX_SYNCHRONIZED_IO " Of these, the MEMLOCK ones are the only ones defined yet. It seems _POSIX_FSYNC is supported, but not advertised. The other 4 are not defined yet; what's musl's support for them? I'm curious how far from complete _XOPEN_REALTIME support musl is. X/Open also defines the Advanced Realtime, Realtime Threads, and Advanced Realtime Threads options. > MIT license. > > Full math library with a focus on correctness. Exact and > correctly rounded conversion between binary floating point and decimal > strings. > > Reentrancy, thread-safety, and async-signal safety well beyond the > requirements of POSIX. Even snprintf and dprintf are fully reentrant > and async-signal-safe. > > Highly resource-efficient POSIX threads implementation, making > multi-threaded application design viable even for memory-constrained > systems. > > Simple source code and source tree layout, so it's easy to customize > or track down the cause of unexpected behavior or bugs, or simply > learn how the library works. Other than the mention of realtime when no proper realtime support is advertised in the headers, seems pretty good.