Evoke (formerly D*mnSmallBSD)

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>