Dylan Cochran posted  an update as  to where he is with the developement of Evoke and what we can expect to come:

I’ve been working on portions of what will become 0.2. We’ve replaced init with nexusd (a hybrid of init, watchdogd, and eventually powerd and devd). This means that now evoke has a ‘single user mode’, to bypass systart. You will probably never need to do this, however, now if you accidentally select it, the system won’t panic, it will just drop you into a shell.

I’ve also added 8.0 to the image, and added a ‘kernel only’ option, so 0.2 will be released with 8.0 and 7.2 as kernels, but will share the 7.2 userland. There are also some cluster related additions in the works, but they will probably not be usable for this release.

Autologin commands, which finally allow evoke to be used outside the ‘administrator’s toolkit’, are now supported. in your user directory, just add an ‘autologin’ file, chmod +x it, and sysconfig commit current /mem/sysconfig a few times (yes, I’ll fix that before release). Right now evoke can be used as an evoke bootserver, if you set up the autologin file by hand. Before 0.2 release, we will make this part ‘automagic’ (within reason).

As for X.org, well, with recent changes to Xorg (and some changes, which are not in ports, but will also be a massive shakeup), it is difficult to build X into the image without overflowing the boot time size limit for memory disks. Unfortunately, Linux based systems have the luxory of KDrive/TinyX, which on FreeBSD, does not work too well. Unless someone wants to assist with finding a solution to either problem (getting kdrive Xvesa working, or fixing the memory disk overflow), I don’t see X being on 0.2. One of our biggest strengths come from using a memory disk in all environments for the base system. While we could cheat and mount the cd for X support, it’s something I’d rather not do. We would lose a lot, just to get a GUI environment. This is considering that in all cases, we would be running unaccelerated, it’s just not worth it.

Read the whole  post here: The leaves are falling

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?

No.

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

The Evoke Project (formerly D*mn Small BSD) is starting to take more shape.

0.1 is the first official ‘release’ of Evoke, It represents the first step into our ultimate goal of improving the UNIX userland. This release contains scaffolding and general structural improvements, including the binary updater that will support releases in the future, the sysconfig utility that provides a backing store for key data, and various other build time improvements to streamline the development.

While 0.1 may be underwhelming, it was a necessary step to lead the way to 0.2, which will begin the changes on user and data management, including defining what a ‘datastore’ is, what functions the librarian will have, and what api is exported to userland.

Read further

It’s been quiet around D*mnSmallBSD the last 12 months. Progress is slow as it’s only a small project and there has been a leadership change.

The project has moved their website to Google Code and changed it’s name to Evoke on request of the D*mn Small Linux team who said there was confusion amongst their users who thought the 2 projects were related.

There were some reasons for choosing for Evoke:

• It has a ‘blank’ connotation. D*mnSmallBSD has a connotation of small size over everything, or worse, a connotation that we are exactly the same as D*mnSmallLinux, except for BSD.
• It deliberately lacks the ‘BSD’ postfix. This is due to the fact that from a technical standpoint, we are not bound to a BSD kernel. Given infinite resources we could be using NT as our primary kernel, along with Linux, FreeBSD, and Darwin…
• It also lacks a ‘OS’ postfix, common to a lot of systems. This is done purely for aesthetics.
• There is a low number of syllables, making it easy to remember.
• It’s different.

Evoke is a small (50mb or less) live FreeBSD environment geared toward developers and system administrators, but we also include applications that the average user may find handy.

Our goal is to be able to run on older hardware, as well as modern machines, while providing a responsive system. We support both SMP and uniprocessor machines.

Dylan is putting a quite some thought in how to build and develop Evoke. For instance:

sysconfig

Conventionally, most UNIX’s store their configuration information in the /etc directory on the root filesystem. This has numerous downsides:

• The system configuration is accessed like a conventional root filesystem, meaning that if the disk drive fails, or the controller/bridge, the system configuration is unusable.
• There is little to no redundancy, and rarely will you be able to recover from obvious consistency problems. As well, there’s no way of rolling back to a previous version.
• The system configuration info is almost always required to exist on the same filesystem as the boot system. This means that you have to implement hacks such as unionfs to have a running system from a read-only root, for files that are normally modified, such as /etc/resolv.conf, or /etc/mtab on SYSV systems.

userconfig

Originally, sysconfig was going to extract everything, and to have more then one user, you would have more then one sysconfig partition. However, I realized that this was adding unnecessary inflexibility, and user’s may wish to have multiple ‘users’, which they can log in as at will.

What do you think of these changes? Should this be considered by the FreeBSD devs, or should sysconfig be left as it is? Please leave your feedback below in the comments.

Hopefully I’ll have some more info on the project and it’s progress over the next few days.

On the first of December 2007 a very tiny FreeBSD-based flavour was launched: D*mn Small BSD (DSBSD). It’s weighing in only under 50mb and comes with a Fluxbox desktop.

There are many Linux distros like this, the most popular distro being D*mn Small Linux (DSL Linux). This must have been the inspiration for Damn Small BSD

Damn Small BSD is a small (50mb or less) FreeBSD live-CD desktop environment geared toward developers and system administrators, but we also include applications that the average user may find handy.

DSBSD comes with everything you need in a basic desktop environment. We include the fluxbox window manager, firefox, xmms, and many other applications. We also include tools to help you get work done, such as an ssh server, a mini httpd, xvncviewer, and more.

The goal of the DSBSD project is to provide a FreeBSD based disto that is able to run on both older hardware with little memory, as well as modern machines, while providing a responsive desktop. SMP and uniprocessor machines are supported and support for more architectures may be provided in the future.

Development is still in a very early initial stage, so there’s no official release yet.

UPDATE:
First pilot, 0.1P1, has been released. This is merely a test of concepts, rather than a real ‘preview’ of what D*mnSmall BSD is. This version doesn’t include any X system yet or any of the goals listed on the website.