kyuba.org

Not much has happened in this release regarding the API, just a few minor stability fixes. However, - SHOCK! HORROR! - this release adds a port of both curie and icemake to Windows/x86, which works with msvc++, borland/turbo c++ as well as mingw/gcc! That's right, carefully designed curie-only programmes that do not use libsyscall should now work on Windows as well as Linux and Darwin, and icemake should prove to be a very effective tool to write and port programmes with.

Icemake binary for windows to match the curie-9 release.

This particular question seems to have come up a lot lately, on IRC as well as other places. People wonder why oh why I would have started Curie. A lot of it is along the lines of "why didn't you use one of the glibc alternatives?" and "ZOMG THE WHEEL IS BEING REINVENTED AGAIN!?". I'll try to point out why not only was it not possible to use "an alternate libc", but also why the whole notion of that sort of question is both pointless and meaningless in this context. In a nutshell: Curie is NOT simply a clone of glibc, or any other libc for that matter!

I'd like to take this opportunity (my acute post-release mood), to point you all to http://glendix.org -- a project that strives to bring plan9 binary compatibility and more plan9 goodiness to the linux kernel. The reason for me pointing this out is that since a month or two now, we're the proud hoster of the glendix.org domain, and we more or less joined up with those nice fellows back then. Check it out and give it a shot, it's made of large quantities of awesome and fluffy, and the guys are really nice over on their IRC channel (freenode, channel #glendix) :D.

This is the very first release of a usable kyuba init daemon. NOTE NOTE NOTE this is nowhere near the final state of the project. In fact it really is ONLY the init daemon hardly anything else. This is intended as a preview of how small things can get, and it might be useful for development of embedded projects due to its small size (roughly 20k statically linked for most binaries, last-rites is even smaller at under 10k, although as usual this requires a freestanding libcurie, which is currently only available on linux/powerpc and linux/amd64).

This release has some minor fixes, but nothing majour. d9c got itself a manpage, some bugs were fixed, that's about it.

update for icemake and some curie API changes.

Oh the week is getting really good. First of all, I'm proud to properly announce that we're being sponsored by the Greek company Codex. Markos_ had already given us some code back in the eINIT days, and I've mentioned this sponsoring in each and every release's documentation, but it's just a lot better to have it right on the frontpage! Second, the v9fs patch i wrote has been accepted, so you might be able to use dev9 with the next coolest linux version. Or maybe in two version. Either way, it's coming.

... I've finally slept enough for a change, and last weekend I moved my arse to find that character dev issue in v9fs. Well, now it really is with v9fs. It's a trivial fix too, the patch against current kernels is now on the v9fs-users ML. That means dev9 actually works (with some other issues that I still need to work out :D). Now someone just needs to go and test it... I'll try to patch it into openrc sometime during the week or on the weekend.

First release. It should work in theory, but there seems to be an issue with character device handling in v9fs... or in duat, no idea just yet. Either way, It's a nice snapshot and something to look at.

I completely forgot to point out that there's an official IRC hideout for kyuba.org: #kyuba on freenode. Join up and have fun. Oh and don't forget about #9p, also on freenode, which is made of awesome and plan9 goodiness.

Linux /dev manager. The idea is to write a 9p2000.u server that ends up providing the same functionality as a combined devfs and udev.

This version fixes some memory handling issues that have been pointed out as flaws by sqweek. I also moved my ass a bit to fix the other issues reported by splint in the core library, and i've slightly modified parts of the API.

This is the first release of duat... thanks to syntropy, it even has doxygen documentation ;).

Kyuba is not going be ready any time soon, but I've set the record time for boot up speed for benchmarking, and if you would like some help getting eInit's git-testing running, please come nudge me on #kyuba. I will say that git-testing has been working for me for well over 6 months without problems at all, and I'm running a relatively old machine. If you have issues with einit-0.40.0 only reaching ~80% on boot up, random lock ups or reboots, come talk, as I think git-testing fixes these issues. Glad to see y'all around.

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.

Duat is an I/O library for C applications. It may be used to implement FS-ish servers; the primary method for this is via the 9p2000(.u) protocol. Depending on my mood, it may also include a simple http server and a number of other protocols.

... and here to stay. Been off the interbutts for long enough now, and the wiki isn't exactly a great replacement for this 'ere. Let's get right back to work then, shall we?

Go~~ intertubes!

Curie is a small C library that provides basic I/O, sexpr reading and writing, networking, process handling, signal handling abstraction and process multiplexing in an abstract way. It's designed to work standalone if special glue-code (in assembly) is added; whenever this glue-code is not available, it may use target-specific or generic C code instead.