Category: crestfs

The second-to-last release of Braydix…

So I’ve definitely made some Braydix progress – here’s the latest. I need to eventually come up with some kind of name that’s catchier than “Braydix” – that has the syllable for “dicks” in it, which…isn’t that nice. It’s still pretty huge – 140MB right now – but I have things being compiled with debugging information ‘on’ (which bloats the sizes out) and some things that I should have working as libraries are actually compiled-in. I think I may also make some stuff compressed, which very rough back-of-the-envelope math says should cut the size to a third (!).

So what’s in it, and why is it the second to last release? Well, I’ve tied in the CREST-fs ‘internetty’ filesystem pretty early into the boot sequence, so the system in essence can ‘boot off the web’. The idea is, when it’s integrated perfectly, that you would be able to do some kind of initial installation thing, and never have to do any upgrades or anything. Just reboot, and what you need is ‘there’. But right now it’s not quite integrated perfectly – I’m not sure how I do kernel or initramfs updates, or how they’d get picked up by the client. So once I’ve got *that* figured out, then *that* release becomes my ‘final’ release.

I’ve also built a very very simple installer, which you can launch using one of the virtual terminals (Ctrl-Alt-F1 is the main browser window, Ctrl-Alt-F2 through F4 gives you a terminal. Type ‘installer’). I wouldn’t run it on any piece of hardware you cared about though – it could format the wrong disk, or install to the wrong partition, or do any number of other, awful things.

The clever bit – well, there are many clever bits, but the ‘novel’ clever bit – is that I have a special ‘bootstrap’ image to prime the CREST-fs backing cache. So you can, in fact, boot up off this disk image with no network connection at all. And you’ll at least get the browser launched and the GUI up and running. From there, you can possibly configure wireless or something and continue to use the system from there.

The idea – and I don’t think I’ve articulated this very well – is that you should never have to install anything on this. Whenever new things show up on the internet, they’re just ‘there’ automatically. You never have to update anything – reboot and you should have the latest. If I end up doing a third-party application thing, just chuck your binaries and libs and stuff on a website somewhere, and it’s available to the systems – the CREST-fs mounting can talk to any webserver just as easily as any other, mine isn’t particularly special (except for the odd symlink that points to it, or a PATH entry).

Some notes:

  • Libraries SUCK
  • Compiling things ‘static’ is really hard
  • Booting is really complicated
  • The Linux Initramfs is really brilliant. You can do all kinds of ridiculously crazy shit with this. Very cool stuff.
  • Busybox is still awesome
  • “Virtualbox” as a development environment under OS X is (relatively speaking) an extremely pleasant place to develop in

Nerd Alert!

The following post is intended for a very technical audience. Consultant supervision is advised.

I wrote a thingee that lets you mount “The Web” as a filesystem. So far it works under Mac OS X, but I intend to port it to Linux. It uses MacFUSE for the filesystem interface – makes it much easier to write without kernel muckery. It’s all written in C. It’s available on GitHub. It’s called CREST fs – Cached REST, or Cached Representational State Transfer.

The thinking is that The Web, as a whole, is a set of resources, which I should be able to access like files from a file system. So as opposed to doing something like trying to curl http://samplesamp.sa/apage/something, then trying to run the code that lives on that page, you could instead mount the web under some directory, then cd to samplesamp.sa and execute apage/something directly. The first access to ‘something‘ would require it be fetched from across the internet, but with a caching scheme built in, subsequent accesses should be from the local hard-drive caching system.

I thought it would be clever to be able to mount it under a folder called /http:/ – so you could say:
ls -al /http:/www.google.com/someurl/something
See? I think that’s clever. You could probably put two slashes there and it wouldnt’ mess up anything. And if you were sitting in the / directory you could skip the first slash. But that’s starting to get too clever just for cleverness’s sake.

There’s stuff like that Out There already, but I wanted to build something that was extremely aggressive about caching, and very primitive (low-level, usable in Early boot environments). I expect it to notbe remotely coherent, but I do want it to be fast. So far, so good.

Sidenote: it’s my first Git project. Git is nice. Hosting it on GitHub is interesting, too, but less interesting than the fact that it’s on Git.

Writing code in C is painful. Allocating memory is not fun. Troubleshooting subtle memory leaks is not fun. Doing your own string manipulation by hand is not fun. But there is a certain feeling you get from being this close to the bare metal of the hardware…that’s really pretty exciting.

This is the second time I’ve written this – the first version was lost in the Great Hard Drive crash of ’08. Writing all this low-level crap is not that cool, but writing it for the second time is even less cool.

The intent behind all of this is to tie it in with Braydix somehow – to allow you to boot a “minimal” Braydix image from CD or USB key, and have it pull the rest from Teh Intarwubs. I have a new client who does a lot of work within Amazon’s EC2 environment, so I’ve had to study how that works. I think this FS might be interesting for that, too. As soon as I can find an excuse to put something up over there, I definitely will mess around with that too. Once I’ve done that, just think of it – they’ll be Braydix both client and server versions.