7:36 AM - The good, the bad, the ugly
First, I'd like to start off with some good news. Our last few magus runs have shown a noticeable improvement in mports. The tree again appears to be stable with only 5 ports failing. Remember that you need to update your OS if you haven't already to take advantage of recent mports. It is a good idea to update your system anyway as we've had several security updates since 0.2.1 was released. I'd rather avoid doing another 0.2.x release, but it might be something for consideration for i386 at least.
The crazy merge we're doing is moving along. We missed the November completion date, but I feel that we've made progress. Each architecture has a unique problem right now and a few common ones. amd64 will probably be working first. The world can be built on amd64 and sparc64 now. i386 is only failing with pcc (which can be commented out). At this point, we're working on updating device drivers in the kernel. I'm in the middle of working on the ATA code. Sadly, some areas of the kernel had not yet been touched and I've brought many of them in line with FreeBSD 7. Other parts of the kernel had many local changes which require case by case decisions. I'm still not happy with this approach, and would rather have had more assistance maintaining.
Since we're injecting a large amount of new code into the project, there are bound to be many bugs at first. The new code has some known issues and the old code did as well. I will need useful bug reports from users. Please check tinderbox.midnightbsd.org before reporting compile errors with the code as I may already know about it.
The next question is what do we do now. This injection of code is not unlike the bsd 4.4 lite / UCB lawsuit situation from the early 90s for the other BSDs. The reasons are different, but it's a bunch of code to get cleaned up and put in. FreeBSD and NetBSD diverged greatly after that time period because they had very distinct goals as well as coders adding, tweaking and fixing here and there. I started this project to work on a desktop BSD. In the mean time, many of the other BSDs have gotten better on the desktop. OpenBSD, NetBSD, and DragonFly have decent wifi support. FreeBSD has been improving it for 7.x and 8.x. Many of them have loosely associated live cd/dvd projects now.
In order to make a list of areas we need to address, let's first consider the environment. I use MidnightBSD on some desktops, a laptop, many mports nodes, and several servers. For my own purposes, I often try to maintain some of the server elements of the system. It does aid me in finding bugs, but it also distracts me from the desktop environment. Over the holidays, my mother told me she got a new monitor. I asked her if she wanted to use the old monitor on her 700mhz celeron which has MidnightBSD on it. I had set it up as a backup computer for her some time ago. She was concerned about using something besides windows. I wanted to argue in favor of using MidnightBSD for her, but I realized that we don't have an intuitive system just yet for someone like her. When I first envisioned MidnightBSD, it was to make it for everyone. That task has not been completed (nor started in a satisfactory manor). So the obvious step is to pop a CD into a system, and try to set it up for a typical home computer user. There are many challenges to that task. These areas need to be met with our project first.
As we've discussed before, the installer is a priority and next on my list after the merge is complete. Combined with the installer, we'll have a beginnings of a decent live dvd. This solves the first two complaints I often hear if we do it right.
So what's next? What packages do we install? How do we partition the system? What features should be enabled by default? What should be a kernel module and what should be part of the kernel? What do we do about binary blobs?
These questions should all be answered by now, and many of them were. Things are different now. We need to evaluate some of these decisions and write up a clear policy on our website.