The Renraku OS team is proud to announce the first release, 0.1alpha.
Major strides have been made in the two weeks since the new codebase
was started, and we're very happy with where things are.

We now have:

• Initial compiler with support for vtables, a good chunk of the CIL instruction set, string object constants, etc.
• Initial memory manager (real memory manager is in progress).
• Basic object manager.
• The start of System.Array/String/Console.
• Keyboard driver and US English keymap.
• Basic shell that can execute applications.
• Basic HAL and interfaces for timer, keyboard, and network drivers.
• Initial PCI base class.
• A few simple applications:
  • 'echo' – Echo terminal
  • 'reverse' – Reverses the arguments passed to it
  • 'halstatus' – Prints the status of loaded drivers
  • 'pci' – Scans for PCI devices and dumps the vendor and device IDs
  • 'shell' – Creates a subshell

We've also created an IRC channel, #renraku on Freenode where
the developers are generally available. If you want to give it a
spin, grab the kernel image and boot it with GRUB. If you run into any problems, drop
us a line on the channel.

For the curious, you can check out this gallery of screenshots of the various commands. And as always, the
codebase is on Github.

Give it a shot and let us know what you think.

Happy hacking,
- Cody Brocious

This is a follow-up to my previous post, Renraku: Future OS.

I got the latest incarnation of Renraku booting yesterday, based on the code base I started the same day I wrote the previous article. There's not much to it, but development is progressing very, very quickly since I have plenty of knowledge of what not to do from previous attempts. What's there (in the GitHub repo) now supports very basic functionality: multiple function compilation, a good number of "Base instructions" (from the ECMA CIL spec), static fields, pointer intrinsics, and string intrinsics (get_Chars for now).

The test kernel is available here (GitHub) and this boots as expected. Obviously, it doesn't do much, but that's coming. What needs to be done in the short term:

• Struct support
• Struct pointers
• Basic object manager

That's it. Once those are done, there's a primitive object model which means actual functionality can be written. A few more days of work, and we should be able to see a simple shell come up.

Happy Hacking,
- Cody Brocious (Daeken)

Renraku is a family of managed research kernels I've been working on
for around 4 years. Though the goals and implementations have changed
over the years, they're all designed to be highly reliable, fast,
portable, and flexible enough to keep up with the changing needs of
today's technology.

Background

Initially, Renraku (known as Colorblind at the time) was simply an
experiment. Inspired by Unununium in its Python era, I saw the value
in kernels being very high level. Ease of development, in the hands
of the right hacker, could mean vast improvements in a short period of
time. With this in mind, I set out to build a prototype. I built a
number of revisions on top of existing OSes, but in the end I couldn't
get the design I wanted, so I shelved the project, but never forgot
about it.

Shortly thereafter, I started playing around with the development of
Talk, an L4-inspired microkernel. It was very simple (written in
straight x86 assembly) and was intended to see how small such a
microkernel could be without sacrificing critical functionality. It
didn't get far due to not having enough time, but while designing the
set of base services and their interactions, it made me think back to
Renraku.

The project sat on the back burner for about a year and a half, until I saw
MSR's Singularity project, some time around 2006. At this point, I
started seriously thinking about what I want in a future OS and how I
can go about implementing it. I've since written a few prototypes in
a mix of C# and Nemerle, and the goals have largely solidified.

Goals

High level:

• Pure managed code. No C, no assembly not generated by the compiler, no pointer access outside of the object manager and certain parts of the kernel.
• Everything is an object. Turtles all the way down.
• Single address space and no userland. Everything is ring 0.
• Completely network-transparent objects.
• Object store instead of a traditional filesystem.
• System-wide orthogonal persistence.
• All components reloadable at runtime.

Implementation:

• Pure .NET. Currently playing around with Boo for it, due to their new macro syntax and functionality.
• Ahead of time compilation for the base services.
• Object model implemented on top of itself. That is, the object model is implemented in terms of value types and pointers, and the compiler has intrinsics for object model instructions to auto-call the implementation.
• While designing/implementing any feature, now is always better than later. Always, always, always go for the practical, simple route before considering a more complex one.

Roadmap

This is a rough roadmap of the implementation of Renraku. How far
this ends up going is really up in the air; it could go to the end,
it could be abandoned half way and rewritten again. Eventually, I'd
love to see these ideas come to fruition, though.

• Initial CIL->x86 compiler. Uses the actual stack to execute code, as optimizations can be added later.
• Initial memory/object manager. Nothing fancy, just enough to get things up and running.
• Begin implementing the .NET BCL. Get basic string manipulation and collections working.
• Implement keyboard support.
• Implement a basic shell. Allow object inspection/manipulation.
• Implement initial object store.
• Implement basic networking and network transparent objects.
• Build framebuffer support and a basic GUI library.
• Implement the dependencies of the Boo, C#, and Renraku compilers.
• Implement a basic terminal and REPL.

Once these things are implemented, development should be able to
progress very rapidly. There's just a lot of work to do to get there.

What would you want to see in a future OS? What would you like to see
go away? What new UI paradigms ought to be used? I'd love to hear
feedback on this, as there's simply a lot to think about.

Happy Hacking,
- Cody Brocious (Daeken)

While lying in bed and trying to sleep last night, I had an idea I'd like some feedback on. The idea is partially destructive garbage collection, which allows the runtime to handle caching, instead of the programmer. With PDGC, the runtime is allowed to destroy an object and keep only the relevant data for recreation around. If you're running a photo management application, for instance, you may want to keep JPEGs and thumbnail bitmaps in memory, while not keeping the full bitmap around. In theory, this is a problem that PDGC can solve for you.   At compile-time, the compiler can look at your class and determine whether or not your object's creation has side-effects, or depends on factors outside of its control (e.g. IO), and make a determination if it's partially destroyable. If it is, then the compiler embeds code into the constructor (and other relevant methods*) to save the data needed to recreate the object. At run-time, the frequency of access, object creation time, etc will be tracked, and the PDGC can make the decision to destroy the object or keep it around. If the object is destroyed, it doesn't entirely go away; rather, it's replaced with a stand-in object that stores the relevant data for recreation.   Further ideas:

• You could allow the PDGC to only destroy certain object properties, rather than the full object
• A more general approach to language-level caching would allow the objects to be saved to disk and loaded lazily. This is something I plan to explore as part of my Renraku research kernel, the details of which I'll be posting on soon.

General open questions:

• What research has been done on this previously? What were the findings?
• How much of this belongs in the compiler and how much in the runtime? This obviously comes down to the implementation, but I believe there needs to be research into good, general approaches.

Implementation questions:

• Should this be involved with the GC at all? In my mind, they're related, but in a specific implementation they may well be completely separated.
• What factors are used in determining whether or not an object persists? Factors I can think of are: frequency of access, cost of object recreation, size, amount of free memory, amount of free swap space.
• Should this be behind-the-scenes compiler magic, or should it be more user controllable? E.g. should the user be able to decide if an object is destroyable at a given point? Should the user be able to override the object recreation portion, rather than letting the constructor do its thing?

I'd love to hear your take on it.

Happy Hacking,
- Cody Brocious (Daeken)

I've finally decided to take the plunge and move to Posterous.  If all goes according to plan, my posts from here should automagickly be crossposted to my Livejournal, but that's going to primarily become my personal blog; this blog will be used for all things tech/business.

To get things started, I'd like to introduce my new programming language, Ultilang.  The name is horrid, so please, add suggestions for a new one here: .

Ultilang is a strange mix of Nemerle, Python, and Lisp.  A curly brace-based syntax, heavy metaprogramming, and multiple backends (.NET, JVM, Python, and JavaScript planned) come together into what I intend to be the most flexible, powerful language out there.  By leveraging features typically reserved for heavy-duty functional languages and blending them with the ease of use we've come to expect with languages like Python, I hope to create a language suitable for near every task.

The compiler, available at , is written in Python and builds/runs a Python AST.  It's currently in the early stages, having just been started yesterday; the first test, a simple recursive fibonacci sequence printer, runs perfectly.  There's a decent bit of work to do before the compiler can bootstrap up to Ultilang itself, but it's coming along nicely.

There's a list of planned/requested features at ; feel free to add your own.  Even if they don't end up in the language itself, they may well become a macro in one of the libraries.

Stay tuned for more information as the language progresses.