[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120822185359.GF27715@brightrain.aerifal.cx>
Date: Wed, 22 Aug 2012 14:53:59 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: [Vision for new platform] syslog, sed, cron
On Wed, Aug 22, 2012 at 07:31:49PM +0200, Daniel Cegiełka wrote:
> Hi,
>
> Rich started with basic tools for unix (noXCUse):
>
> http://git.etalabs.net/cgi-bin/gitweb.cgi?p=noxcuse;a=summary
>
> ....and this is a good time to talk about other tools/daemons.
These were not really written as a basis for a new platform. Mostly
they fall into 2 or 3 categories that might overlap:
1. Simple programming exercises to see how difficult/easy some of the
standard utilities are to implement portably on top of just the
standard library.
2. Replacements for some utilities (fold, wc) in Busybox that lack
viable Unicode support.
3. Replacements for standard utilities not covered by Busybox, and for
which the GNU implementations are hopelessly tied to glibc (iconv).
With that said, the intent of my "new platform" discussion/direction
is not to come up with a list of implementations and say "you must use
these!" Which sed, etc. you use is fairly irrelevant as long as it
gets the job done. I'm more concerned with replacing overengineered
junk that's not standardized (possibly even lacking a specification)
with simpler approaches to getting the same work done.
> syslog
> ----------
> rsyslog, syslog-ng - seems to be quite a hard choice. syslog-ng needs glib etc.
Anything that uses glib is going to crash under load, so it's not
viable for core system components. There's no way to use the vast
majority of the glib functionality without encountering abort() in
library code.
> sysklogd - is an old and good, but today might be a little too outdated.
>
> socklog - recommended by suckless.org etc., http://smarden.org/socklog/
>
> metalog - (http://metalog.sourceforge.net/). Require PCRE, but it is a
> very lightweight solution. The original release has ugly gnulib dep. I
> deleted the extraneous code (gnulib) and packed everything into one
> file (mlog.tar). The whole is adapted to musl. This stuff requires
> further work (Makefile +-DOPTIONS)...
I'd like to see a review of the source for the different options, for
security and robustness. Features/outward-behavior are important, but
if the core is rotten it's hard to fix... On the other hand, missing
features could be tacked onto a core that's solid.
> sed
> -----
> sed can be a big problem. I noticed that some programs require gnu sed
> for proper installation (configure, Makefile).
What GNU features do they require? Reportedly busybox sed works for
many packages...
> minised is very interesting and worth a recommendation.
>
> http://www.exactcode.de/site/open_source/minised/
Minised is non-conformant. It does not handle multibyte characters. It
might work for making configure scripts happy, but it doesn't provide
a working sed for users who expect arbitrary characters to work. Also,
if I remember correctly its regex implementation has pathologically
bad performance in terms of big-O...
> Unfortunately, even with minised I can't build packages such as
> e2fsprogs, findutils or find etc.
>
> from my find's build.log:
>
> checking whether gcc and cc understand -c and -o together... yes
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether ln -s works... yes
> checking for a sed that does not truncate output... configure: error:
> no acceptable sed could be found in $PATH
What does "truncate output" mean? Are they trying to process data with
embedded nuls? Or just really long lines?
> We can prepare a patches etc... but if autotools will push gnu sed
> this issue will return in the future as well as with other programs...
It would be nice to get more packages to fix this issue...
> cron
> ------
> I recommend ncron. Works very well with musl.
> http://kain.us/nk/projects/
Yes, it's very nice and by one of my friends and musl contributors.
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.
