12:40 AM - buy midnightbsd cds, status update
Two different sites are now offering MidnightBSD installation sets. The links have been added to the download page of our website. A portion of the sales for OnDisk.com will be given to the project.
I also want to update everyone on MidnightBSD progress. A few months ago, we had a discussion with developers and a few users about the future of the project and issues with MidnightBSD. The most common complaint about MidnightBSD is hardware support and the installer. There have also been feature requests for journaling file systems, ZFS, jemalloc, and .98 openssl.
When MidnightBSD was forked, it was done off 6.1 beta. We spent time fixing bugs that were corrected in the release version and adding hardware support. However, we haven't made significant progress with the base system. This defect has held us back. In part, I feel the steep learning curve to work with the src tree has discouraged new developers. Our mports system is working out well and we've succeeded in dramatically improving the experience and packages generated from ports. A good share of the credit should go to ctriv@ for digging in to the mess and designing something new that continues to get better. However, a ports system is not enough to keep us viable.
A decision was made to bring in select parts of FreeBSD 7 that we feel are useful or parts that we've not had time to maintain. It was a difficult decision because it meant we haven't yet separated ourselves entirely from their project. Other projects such as DragonFly occasionally bring in code from FreeBSD such as the ata code (nata in DF) or their latest approach at writing a wrapper for the network stack in FreeBSD Current. Haiku uses FreeBSD drivers, jemalloc and other parts and has successfully wrote a wrapper for many parts of the system they use. Still, this was something much larger. We haven't blindly imported the entire FreeBSD 7 environment as we have accomplished improving parts of the system, but it was still a large piece of code.
The work on this started in July and began to appear in CVS sometime later. The last two months have been a constant stream of merges, fixes, imports and more testing. At the same time, ctriv@ has been refactoring parts of the mports system to make it more modular and consistent.
The result will be a new system with many improvements and a few regressions. The changes will be present in 0.3-RELEASE. We do not have a very specific time table for this release aside from a target date of October-November of next year.
We have an increasing user base, but need more developers of all skill levels.
mports
As for mports, you can take advantage of the new changes by updating your system to the latest stable version RELENG_0_2 and updating your mports tree. A file was added to /usr/share/mk (src/share/mk) required by the mports system. Without this file, you will have make errors on some ports. This change has occurred in the last two weeks.
GUI
Many users have expressed an interest in our choice of desktop environments. GNUstep and many ports were updated recently. They work on i386 and often sparc64. The amd64 version of gnustep is not working and we're investigating that issue. Etoile is out of date and must be updated for the new version of GNUstep.
We also plan to ship KDE and Gnome in the next release. Until Etoile matures to a point it's usable, it makes sense to let users pick alternatives. Many linux distros have chosen to do a similar approach. Fedora has flavors. Other projects, like Ubuntu, have variations for use scenarios like education, or for desktop choice like Kunbuntu (KDE).
As the GNUstep project is aggressively moving forward, we don't feel it's a good time to count on it for our installer just yet. The amd64 issue is an obvious road block. Our plan is to write the installer in GTK for now and evaluate GNUstep later. Why GTK? It's not huge like QT4, and I have experience with it. We plan to include GNUstep on live DVDs in the future so users can experience it. I'll follow up in a later post.