I sent an email to Dylan Cochran with some question regarding his Evoke BSD project. It’s been sitting in my email for a little while, so it’s time to post it.

These were my questions and Dylan’s answers:

1) Can you give a quick update on the state of the project and what you’re planning for 2009.

We are going to make a release soon, and have been working on solidifying procedures, adding documentation, etc. A lot of the unexciting phases.

2) Can you explain how Evoke is different from nanoBSD.

NanoBSD, TinyBSD, PicoBSD, etc, are toolkits to build FreeBSD for embedded devices.

Evoke is not primarily a toolkit, though we have a flexible build system similar to TinyBSD’s, it’s not intended to be used by the users.

I could spend several paragraphs explaining out differences in detail, however, I’d rather talk about our goals. For one, we have tried to clean up our namespace; so that there are no collisions in operation. This means that we can have multiple versions of evoke on a disk, support multiple architectures per version, and even, multiple abis per version. Since the beginning, we’ve built for 6.x and 7.x at the same time, and we’ve also had amd64 and i386 support being built at the same time (Unfortunately, due to economics, we can’t build the amd64 binaries at this time)

The active version, abi, architecture, they are all seperated on several levels. This allows us to remove restrictions that prevent users from running arbitrary i386 binaries on amd64, from moving a
machine from i386 to amd64, to i386, to back again, without losing data or putting the system in an inconsistant state if problems occur.

We also abstract as many interfaces as we can, that may be architecture or abi specific. For example, rather then using mount, you would use mounter, which has a more abstract interface for
handling various filesystems, native, fuse, or otherwise. This grew out of the necessity of dealing with many different mount interfaces between various kernels.

This is a small sample, there is much more. I’ve been pulling in a lot of design elements from a lot of sources, and using the most effective ones for our needs. It’s deceptively simple.

3) When are you planning to release a new version (alpha, beta?)

We are nearing our first ‘real’ release, 0.1. Though we aren’t there yet, there are some autoconf related bugs in the 6.4 target, and some missing features that I consider show stoppers. A big problem is Xorg support, as Xorg and it’s modules take up a large amount of disk space; inflating our image size signficantly. I would rather use kdrive, and build Xvesa, but all my attempts at porting it so far have
failed. So it’s still up in the air on whether or not X support will be in 0.1.

4) Are you planning to track FreeBSD releases (like PC-BSD, FreeNAS, pfSense etc) as the underlying base or are you forking (like MidnightBSD or DragonFlyBSD)

We build for multiple targets, FreeBSD 6.4, 7.1, and even 8-CURRENT. We also have support for other kernels, Linux, Plan 9, etc, but the build system and scripts don’t have any real support for it.

5) Does the project have a new logo yet?


6) Any other things you want to let the BSD community know?

We are always looking for help, our blog has an entry on contributions, and a list of things we are having problems with. If anyone has any knowledge on these problems (especially kdrive) I will be grateful.

Many thanks to Dylan for his time and for explaining a bit more about the background of Evoke.

More about Evoke