Navigation
User login
Sponsored By
Alright, here's what's gonna happen...
I figured it'd be about time to post some details on the current status of kyuba, einit, dev9, libcurie and libduat. That, and our plans for world domination, of course. ITT: Details on wtf is going on, wtf this is all about and wtf it's good for.
As some of you may be aware of, after that particular incident with an ex-developer, and the issue with the domainname, einit has been abandoned in favour of a complete rewrite and redesign, which has been dubbed 'kyuba'. In order to implement kyuba, the consensus on #kyuba and #einit was to start from scratch real good like, so i started on a project called the 'atomic-libc', which has since been renamed 'curie'. Curie is basically a libc replacement with just the features that will be needed for kyuba; i.e. just enough to make it usable for just about anything, but completely minimalistic, with the goal to try and make super-small binaries as well as theoretically being easily portable, even to a non-hosted environment. In the meantime, dev9 sparked more interested, and the design was vaguely fleshed out. To implement dev9, which will be sort of a udev-/devfs-crossover for linux, i've started on another library, dubbed 'duat'. Duat will eventually also include support for other protocols but 9p2000 and 9p2000.u, but not just now.
Onwards, to the status report! People may be glad to hear that releases of curie-2 as well as duat-1 are underway. Neither will have top-notch documentation just yet, but I've been told that the testcases for curie are fairly extensive and double as solid examples for how to use the lib. The current version of libcurie is completely self-sustained on linux/amd64 and linux/ppc, and on all other architectures it should work fine as it will simply wrap around any installed posix libc. As a nice highlight for curie-2, i've been able to somewhat get C++ apps working on linux with curie, so i added a 'libcurie++' to the pack, which wraps around some of the constructs in libcurie. On linux/amd64 and linux/ppc, both C and C++ binaries linked with curie or curie++ end up easily being under 30k, statically linked, which is precisely the thing we've been looking for. (Well, on the downside, on all other archs you get binaries of just about the same size, except that they still link against libc, so nothing's lost but nothing's won either, save for the saner interface and goodies in curie).
Duat-1 will support both 9p2000 and 9p2000.u, i've just committed some code that should make the lib conform to the 9p2000.u specs. It even has support for wstat ;). (No offence really, i love libixp.)
Right after both curie-2 and duat-1 have been released, i will start to work on dev9 (yes, we still haven't arrived at kyuba just yet). This means that both kyuba and einit are currently on ice... however, einit-0.40.0, as well as the git 'testing' branch are reported to work very well for people, with a number of minor glitches still occuring, none of which seem critical. This means that if you want fast bootup, now, just use einit-0.40.0 or the git testing branch version. We'll even still try to help ya on #kyuba. Or #einit... although #kyuba would be better ;).
That is all,
Magnus
Use uclibc or dietlibc?
Why cant you just use uclibc or dietlibc? They are lot smaller than glibc and you dont have to reinvent the wheel. Especially dietlibc is really small.
The size alone isn't the reason for Curie
curie isn't a plain libc in the original sense. it's just quite exactly the abstraction around the libc i would have built anyway, except that i designed it so that it's easy enough to make it fully standalone. it's mostly functionality not covered by POSIX, or wrapped around so that it's more convenient and consistent to use. In fact, curie will use whatever libc the host is using anyway, whenever the six 'magic files' that are needed for a standalone libcurie haven't been ported.
Curie doesn't implement the POSIX interface in the slightest, either, which means it can be used in combination with any other POSIX libc, to combine features from both.
as for the dietlibc and uclibc: uclibc is pretty big, and it seems a bit flakey (i'm having trouble compiling it on a good batch of toolchains, even native ones), and dietlibc is, very unfortunately, GPL-only and not LGPL like the other libcs, and I'm admittedly a BSD/MIT fanboy. That, and static binaries with a standalone curie are still smaller than dietlibc ones (just have a look at the tests/ directory on a linux/amd64 or a linux/ppc machine).
Oh and then there's the thing that last time i looked, dietlibc and uclibc were linux-only; all the programmes 'ere should eventually be ported to at least darwin, freebsd and win32 (at the very least to reactos).
It's so lucky for me to find
It's so lucky for me to find your blog! So shocking and great! Just one suggestion: It will be better and easier to follow if your blog can offer rrs subscription service.
Post new comment