[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