[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20121119224428.6ae2d82d.idunham@lavabit.com>
Date: Mon, 19 Nov 2012 22:44:28 -0800
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: Revisiting 1.0 wishlist
On Tue, 20 Nov 2012 00:09:40 -0500
Rich Felker <dalias@...ifal.cx> wrote:
> In addition, significant progress has been made on the open-ended
> goals of application compatibility and ability to load/run some
> glibc-linked binaries (applications and libraries). Part of the goal
For what it's worth:
Although I can run ksh93 with a patched musl (see the g_hack branch* if you're curious), it crashes on executing any external command.
I have yet to track down whether this is an issue with the patches, UB, or ABI incompatability in musl.
> originally stated in the wishlist was to determine a collection of
> "important" applications and ensure compatibility against them. I
> think now would be a good time to start doing that. Perhaps LFS (Linux
> From Scratch) might make a good base set to start with, especially
> since lots of people building their own systems who might use musl
> will be starting with LFS as a guide. We could add and remove some
> packages from the list as desired.
>From the LFS list, I'm not sure about DejaGnu, texinfo, tcl (I think some versions work, but don't know about all of them), sysklogd, expect, or systemd (I think LFS wants that for udev); sysvinit works as expected apart from who/related utils, plus previous runlevel changes aren't known (utmp).
Beyond LFS, I'd suggest:
-Xorg, with Intel/Radeon/Nouveau/modesetting/vesa/fbdev drivers.
These *should* work at present, as well as GTK2.
-Python is too widely used on Linux for incompatability to be easily overlooked. I know sabotage builds it, are patches required?
-A full LAMP stack or similar (LAMP currently means upstreaming anything needed for Apache/PHP to build, and getting MySQL or MariaDB working...PostgreSQL is the DB I'd want, though ;))
Longer-term, making sure Wine, Java, Qt, GTK3, and Webkit work is probably going to be important for relevance. I don't really like most of them, but that's where the action is.
> Aside from yet-to-be-defined compatibility goals, the only thing
> missing from musl that was in the original 1.0 wishlist is
> documentation.
>
> There is also one other goal I introduced later, on which I think 1.0
> needs to depend: support for a to-be-determined set of additional
> legacy character encodings in iconv. At the very least, the major
> legacy encodings for Korean and Traditional Chinese should be
> included, and it may also be desirable to add support for stateful
> encodings (ISO-2022). Aside from these, I believe all encodings
> important for supporting legacy data on the web, in email, etc. are
> supported.
--
Isaac Dunham <idunham@...abit.com>
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.
