Kinetic source release

I’ve received a request to release the source for Kinetic, a project I worked on in Haskell around the winter of 2006 (iirc). There are two reasons why I’ve put this off:

  1. This was one of the first projects I worked on in Haskell, and the source shows that. My experience has been Haskell is often criticized based on the quality of code produced by its n00bs. This is an unreasonable thing to do (imagine judging a unicycle based on how well someone can ride it on their first go!) but I see it often none the less. I hope that this release does not lead to more of this nonsense.
  2. The project had ambitious goals that I never had the time to pursue (I’m sure many hackers know that feeling…) I’m really not interested in hearing about how I didn’t deliver on that. It’s just something I was working on when I was in college, you dig?

I’ve uploaded a snapshot of my development directory here. The build process attempts to download the source to ghc-6.6 and build it locally for use in the construction of the kernel. It will also try to find (using very basic means) the object files for many non-system C routines used to support the GHC runtime.

The Makefile should be able to produce a bootable CD ISO that can be used with VMWare. The operating system includes a driver for the VMWare graphics adapter, which it will assume is what the host system provides (so it probably won’t get very far in Bochs or qemu).

Of course, when I tried building it on my current machine, the build failed in ghc-6.6. I know that I was working on replacing the GUI with a console-based shell at some point; it’s possible that the source I posted is somewhere in the middle of that, and won’t build as a result. I’ll investigate this more when I get a chance.

I’d be happy to answer any questions about the system as best as I can. Happy hacking!

Kinetic: Greetings, Redditors

Much to my surprise, Kinetic was linked to from the Programming sub-Reddit today.

In the past couple of days, Kinetic has suddenly drawn some attention. The feedback has been encouraging, but a few themes have come up in the questions people have asked. So here’s a few comments that might clear things up a bit:

  1. I hadn’t really intended for Kinetic to get much review; I had created the website merely so my friends could see what I was up to. In other words, the statements aren’t meant to be taken too seriously: this isn’t an academic journal, it’s a personal website.
  2. Kinetic uses the Foreign Function Interface to interact with C++ and Assembler. In general, the FFI enables pointer arithmetic, and is therefore able to subvert type safety. I haven’t yet come up with a better way for addressing a graphics adapter’s linear frame buffer. I’m sincerely interested in suggestions for how to deal with that.
  3. Nope, I haven’t posted any code yet. I’m not opposed to the idea of releasing snapshots in the future, when things are a bit more mature.
  4. There has been speculation as to how much of the operating system is written in Haskell. Here’s a rough breakdown. C++: Stuff for initializing the IDT and GDT, some bitmap routines (for performance), the FreeType library, as well as basic functions for supporting the GHC runtime. Haskell: PCI driver, mouse and keyboard driver, VMWare graphics adapter driver, most of the GUI.

Hope that helps to clarify a few things.

Kinetic: The console

For the past two years, only my “real life” friends have known about Kinetic. Now that I’ve put stuff online, I’ve started getting comments and emails from the greater population. This is quite neat!

Development on Kinetic is very stop-and-go for me. I typically only work on it when I have an extended break from the rest of my life (say, during Winter break, or otherwise slow quarters at school). I do spend most of the year thinking about the project, though.

Most recently I have been thinking about models for the shell. At this point in the game, the shell is not especially important. However, having some basic UI is quite useful for interacting with the operating system, which is vital for testing.

While I’ve started work on a GUI (with a driver for the VMWare graphics adapter), I’ve lately been thinking of dropping the GUI and focusing on a console-based shell instead. The advantages are clear:

  1. Takes less time to develop
  2. Does not require any particular graphics adapter
  3. Can be replaced with a GUI later if I need to

This isn’t really sophisticated stuff here.

I’ve got a kinda goofy idea for where to go from there. I was thinking about having a Haskell interpreter for a shell, where you browse packages instead of directories, and where files are just Haskell variables. From this perspective, programs are just functions, which naturally plays into the goal of having typed programs.

I know it’s not exactly brilliant, but it’s cute enough that I want to see how it works out.