[klibc] Development forever
H. Peter Anvin
hpa at zytor.com
Mon Sep 10 20:22:17 PDT 2007
Oleg Verych wrote:
> Hallo, Peter. Cheers, developers!
>
> I'd like to join this effort, in case i'll useful with my crazy stuff.
>
> First of all, please consider subscribing this ML to Gmane interface.
> It would be great! Especially, if you will provide full-text archives
> for importing. (All that web archives suck, you know. Small and big
> archives are most easily handled with news server/reader.)
>
Unfortunately, that adds to the spam probability. The mailman archives
does have mboxes for importing.
> Secondly. Did you started klibc as `for of dietlibc'?
> http://permalink.gmane.org/gmane.linux.lib.dietlibc/1160
No. (And the link is broken at the moment, so I can't read the post.)
> Why i'm asking, not for trolling or that kind stuff. I just want to know
> your opinion about inclusion some comprehencive tools in addition to
> dash and kinit.
Well, the focus has been on supporting initramfs well. Other options
has been a minor consideration.
Note that klibc does not offer a stable ABI. This limits its usefulness.
> For example how klibc relate to posix utils by Jeff Garzik?
Not in any direct way.
> I'd like to have sed in setups like klibc. This is because i can write
> quite rich applications only in dash/sed. This requires BRE support,
> as opposed to just shell patterns. I'm about to start TUI system based
> on it and TERM=linux. Latter may be expanded via Linux development of
> vt, i guess. Because current prehistoric set of capabilities is just
> dead and stupid. Careful (re)design of such thing can lead to
> comprehensive framebuffer support even on console based apps in the
> end (i.e. world domination).
>
>
> I saw your changes to dash, like timeout support. Why is that? Bash
> is good example of NIH stuff not to follow.
Debian had a specific use for it.
-hpa
More information about the klibc
mailing list