Reviewing DragonFlyBSD 1.8.0
A few days ago, I decided to attempt and run a user-based DragonFlyBSD installation off of my old Dell Latitude CPi D300XT. For those who are not aware of what DragonFly is, let me explain.
First off, BSD (Berkeley Software Distribution) is the Berkeley Software Distribution of UNIX (BSD deviated from UNIX to the point of it's own family). The (Free/Net/Open/DragonFly)BSD family of operating systems of today originated from the first i386 operating BSD, 386BSD, which itself was the offspring of 4BSD.
DragonFlyBSD started out as a fork off of FreeBSD4-Stable branch. It aims to continue FreeBSD4 in a "logical" methodology, and implement new VFS, Userland threading, Lightweight Kernel Threads, clean up the source code, etc,. I have been monitoring DragonFlyBSD for a while now, and seeing 1.8.0, I resolved to attempt a full installation and usage of it. Personally, I loved FreeBSD-4 as it was stable, dependable, and easy to understand. On the side note, I hate FreeBSD-5 and 6. Unstable, and a depearture from 4's values.
First off, let me clarify the requirements for naming DragonFlyBSD either ready or not ready.
It must:
The test victim (computer) has this equipment:
- Pentium-II 300Mhz processor
- Crystal WDM Codec Audio
- Two Texas instruments cardbus.
- IBM DS-208A Hard drive (1038 Megs)
- 1024x768 LCD, Neomagic card.
- 96 megabytes of memory.
- CD-RW, Dell unknown
- USB 1.1 Slot
- PCMCIA CF->Computer adaptor, 512M of space.
Pretty easy requirements, eh? I've been administering and using FreeBSD4 for a LONG time, so I have plenty of experience in cudgeling cranky computers.
First off, I downloaded the 1.8.0 Install/live CD. It is only ~100 megs, which already promises a light install. I bootup using LIVE CD, and log in as installer. I partition the computer to have:
/dev/ad0s1a 100M /
/dev/ad0s1b 96M swap
/dev/ad0s1e 100M /var
/dev/ad0s1f 100M /tmp
/dev/ad0s1g * /usr
This leaves around ~700 megs for playing around. I decided to wire /home to /usr/home, as I wanted more raw space for compilations, etc. The install process ran into a few bad blocks, but succeeded anyway. I set up the user accounts, time/date, language, etc, and rebooted.
It booted up, and I logged into root. Upon inserting my wireless card, I was greeted with a cryptic array of information relating to cbb0, the cardbus. At the bottom of the list, it declared the initialization a "failure". Hmm. Not good. I researched AirLink101 wireless and FreeBSD (DragonFly's wifi architecture came from FreeBSD), and found that projectEvil could make it work, under ndis emulation. Reading the manual, it directed me to get the windows drivers (got that), use ndiscvt to convert it (did that), and recompile the kernel module (uh oh, no kernel sources are not found!). With some quick searching, I found the sources on the CD-ROM, extracted them, and build the ndis.ko kernel module.
I inserted my card, and loaded the kernel modules. Fail. The card detected and claimed to "install", but ifconfig, wiconfig, etc, showed no added devices. I repeated compiling with different drivers, but to no avail. Consulting Google didn't help either. I even tried without ACPI enabled, but nothing happened.
Falling back to the second criteria of Wireless, I grabbed the ancient, supposedly supported, GemTek Wireless B, based on the Intersil Prism xx-xx-xx chipset, written as supported under FreeBSD. I loaded the kernel module, inserted it, and tried ifconfig. To my surprise, it showed up. Following instructions, set the SSID, channel, and told dhclient to ask for a wireless address. It contacted the wireless router, and... jammed. The entire system became unstable. For wireless, DragonFlyBSD (and probably FreeBSD) failed the test.
Next was X.org and audio. I grabbed an old Xircom RealPort II and set up the network. I proceeded to attempt to install Xorg. Lacking any form of web browser on the native DragonFly install, I was forced to use my other computer, via telnet and ftp, to obtain "links-browser" from the DragonFly package index, and install it. Next, after some cryptic how to's on setting up Pkgsrc, I set the PKGSRC_SITE to the exact url of the package index, and typed "pkg_add Xorg-meta". It proceeded to download and install X, with no errors. I setup X using the neomagic device driver, and it worked perfectly. Geting X working: success, installing pkg's: not easy, but manageable.
Audio... what a nightmare. I tried snd_ess.ko, which is built to work with all the Crystal Sound devices I've seen. It printed out a promising message, but failed to load the sound devices. I proceeded to try every single device driver, all fail. Getting audio working: Dismal failure.
To get a video playing, minus sound, I needed to install MPlayer, the defacto multimedia player for all linux/bsd/unix computers. I was disappointed to learn that it did not make the prebuilt package index. I was even more disappointed to find almost no information on setting up pkgsrc for making MPlayer under DragonFly. I then resolved to build MPlayer from the mplayerhq.hu site, testing DragonFly's application building skills.
I downloaded the most recent version of MPlayer, and untarred it. Then, I attempted to ./configure it. It succeeded, but with no X video output. Why? Checking through the configure.log revealed that it failed the X-test, because it failed the header/compile checks. First I told it to look somewhere else (/usr/pkg/xorg). That failed. After many different tries, I just ln -sf /usr/pkg/xorg to /usr/X11R6. MPlayer's configure worked, and began building. It failed at a few points that required forced includes of /usr/include/sys files, but after some light hacking, MPlayer built. I fired up X and tried to play the Animusic retro movie (320x240, 15fps). It played well, using xv driver. I tried a higher complexity avi, this time at 512x384, 30fps. On my Win2k installation, this movie hiccups and jams. On DragonFly, it played perfectly, even with post processing. Verdict? Source code builds, workable, Video playing (-sound): Perfect.
DragonFlyBSD has come a long way from 1.0, which I tested privately through VMware a while back, and should continue it's good work. It passed some of the requirements, demonstrating progress. However, DragonFly is not ready for production on servers and clients without extenseive man power and time. It is making very fast progress, and 1.8.0 could be compared to FreeBSD 4.1 in usability. It took the FreeBSD project several dozen releases to get things right. It is impressive in that DragonFly has released less, but more stable releases, and gotten so high on usability scale. I won't be replacing my FreeBSD 4.10 box now, since DragonFly has not met the minimum requirements (Yes, they are minimum), but perhaps in the future, I will.
Bottom line? DragonFly is deserving of respect and effort. I invite you to support the project in their work, and try it out for yourself.
On a side note, I was talking with some computer buddies of mine, and they told me that many of the drivers I used weren't "tested" correctly and maintained. In fact, one, using the "Basic Kernel Source Code Secrets" by William and Lynne Jolitz, mentioned how this was solved by eliminating drivers, and using the kernel to facilitate requests from userland to device. Meh. Maybe another project will try this. I promise to review and help out if so.
Links:
http://www.dragonflybsd.org
http://www.386BSD.org