3:11 AM - current
MidnightBSD 0.3-CURRENT now includes GCC 4.2.1 as the system compiler. I4B (ISDN for BSD) has been removed from the userland; previously it was removed from the kernel.
Several changes have been made to sysinstall recently, and I'm working on switching over to libarchive. In 0.3, bsdcpio (backed by libarchive) is exec'd for each install phase. 0.2 used pax as cpio and 0.1 used GNU cpio which was removed for security (and GPLv3) reasons. The installer now tries to figure out keyboard mappings from the user's selection of a country at the beginning. Tape install features were removed as they were quite dusty.
One may ask why I'm even bothering working on sysinstall at all. While I have started work on a new installer, I realized that it won't be at the level I would expect for 0.3 necessarily. Having a tuned sysinstall is a good backup and possibly the only option for the sparc64 architecture at this time. Also, it makes sense to work more in the problem domain with an existing piece of software and then improve upon it.
I'm planning on releasing a new snapshot soon with GCC 4.2.1 and the sysinstall improvements. I'd also like to create a new live cd (or dvd?) soon. I'm considering using xfce 4.x and possibly gnustep (if i can get the port using the system compiler quickly) on it along with midori. We'll see what transpires.
Lastly, I'd like to mention my current thoughts on pcc. I was excited about it at first, but at this point I don't think it makes sense for a default system compiler. We've got C++ code in userland, and with our Objective-C ambitions, it doesn't make a lot of sense. I haven't decided if I"m going to remove it or not from src yet. It very well may be disconnected from the build for the release unless I get time to fix it/update it. Both Dragonfly and FreeBSD have been eyeballing llvm + clang. I've got reservations about that just as much as I do about newer versions of GCC with GPLv3 licensing. Some members of the BSD community are strongly against the license and certainly it hurts business interests with the various projects. FreeBSD has a lot of corporate users and developers. On the other hand, we want to move forward with several GPLv3 licensed pieces of software in the installation for the graphical user interface components. So, even if i make some grand point with the src tree, it's lost with the package as a whole anyway. I don't really care all that much about it beyond the limitations it imposes on use of my operating system. I've been contemplating this issue (and others) lately as I'm thinking of writing a very public roadmap. This project has been moving forward mostly from some mini roadmaps I've detailed in my blog and this blog in the past, ideas I've had for years and work done by new developers. The flexibility is great, but many people don't know where we're headed and that means we can't gain momentum with more conservative users. I have to admit that I like a bit of randomness to software I write in my own time. It does seem like a fresh contrast to work. However, this is an operating system project and should have a higher level of planning. (and yes we do discuss major changes amongst developers)
If you refer to the wiki planning document for 0.3, you can see that we're working on a feature release. The critical points for this release are the new installer, libmport / mport package tools, and the crazy src merge I've been working on. The good news is that libmport and mport tools are in "pre alpha" state and they are ready for selective testing now. You can find them in the src tree, but remember that the database and other aspects could dramatically change. A large part of the "merge" is complete. That leaves the installer.
Here's a big picture thought process as of right now:
1. 0.3 will contain the changes mentioned above and install either KDE 3.5.10 or xfce or windowmaker + gnustep. Many of our developers have fallen in love with xfce (not me), none of us are very happy with KDE 4 and we feel it's redundant to ship KDE as PC-BSD and DesktopBSD do that. Not to mention it doesn't integrate well with GNUstep. For this release it will be a choice.
2. Most likely we're doing a 0.4 release which will focus on syscons and refinements to the installer. I'm sure some hardware and userland software changes will be committed.
3. We're talking about going to 1.0 after 0.4 among the developers. Regardless which it is, we want to have a binary update system in place by then. Also, usb flash images suitable for installs and live cd/dvd functionality. The latter I'd like for 0.3 ideally. It depends on time.
Finally, I'd like to mention Etoile. They've made some progress with Etoile and we need to get the new software running on our system via mports. I'm not sure the timing will work out for 1.0 but we will still consider shipping Etoile with the system. At this point, I think a Redhat style dual desktop setup is in order (choice during install?) with xfce and some gnustepish environment.
At the end of the day, this project is no longer just about what I wanted when I started it. Users and developer input is important to consider with any open source project, particularly an operating system. At present, I've heard a lot of people push for either a very light weight desktop or a very mac os x like desktop.