5:20 PM - Long term plans
I've had a lot of questions about MidnightBSD's future plans. We have not provided a comprehensive roadmap or even a weak one in some time. Here's a brief summary of our current situation and where we are headed plus some of our possible plans.
First, we have nearly completed 0.1 for release. I am building packages for 0.1 on i386 right now. There are several problems with mports exposed in the builds for 0.1. We should have work arounds before the release. 0.1 will not include a new installer, but some of the mports changes will be included.
Security patches present in 0.1 and 0.2 for everything known except the recent theoretical scheduler attack that effects practically every OS except Mac OS X. I don't see us moving off of a tick based kernel anytime soon. It's in the back of my mind though.
Most of the changes in 0.2 so far are in the mports infrastructure or userland. There were a few subtle updates to drivers including firewire. I expect more driver work in the next month. No one has reported any hardware that doesn't work in MBSD but does in other systems barring the limits of Xorg 6.9.
One of our developers has been working on migrating to Xorg 7.2. I don't want to commit this change to a specific release, but it will happen before 1.0. We will also include an x11 based installer, current GNUstep environment, and a GUI mports management system for 1.0 release.
0.1 release will not be an ideal desktop system. It is a new project working out release engineering, testing, and proving the changes we've made from FreeBSD are correct. It should be fairly stable, but not feature complete as a desktop. (think CLI) We are toying with a way to install GUI packages as a hack until the new installer is done.
0.2 release will include the critical ports of the mports tree. Depending on ctriv and wintellect's progress, we hope to ship command line tools and possibly a GUI if caryn and alex get that part done. If not, we will be very close to done with major mports work. We also plan on having a new installer for desktop installation, plus any userland + kernel work during the development cycle. (cvs, ssh, and quite a few other things have been updated in current already)
0.3 should complete the mports and installer work based on feedback from 0.2 and anything that was not completed during the previous release. More kernel and userland improvements
0.4 will focus on the desktop experience. We plan to get documentation in order, determine the final packages for 1.0 release, and work on integration. This will be point we make the judgement call on Etoile. Prior to this release, we plan on using WindowMaker and slim. We could revisit Etoile later, but not for 1.0. (more userland + kernel stuff)
0.5 will be the beginning of the server release. The desktop version of MidnightBSD is the focus of the project, but we've decided to ship a server installer with separate ISOs. People in the project use MBSD as a server and it would be helpful for us to have it. The installer will be a bit different for this release as we plan on allowing users to select packages (think httpd, mail, ftp, etc) as well as add more control over partitioning and things required in a server OS. I don't plan on making the server a priority as FreeBSD is quite capable as a server as is all of the mainstream BSD projects. (Free, Net, Open, DF) You could compare this to Mac OS X server versus Mac OS X client. They are the same but the server had additional tools and services. Die hard security fans wouldn't run a GUI on a server so we don't consider this to be a mission critical type of thing. It's for a computer lab or small business environment where the other BSDs fail to target and Linux or windows get used.
... (whatever else we need to do before release)
1.0 Release
Full desktop environment with installer, GUI package management, command line environment and package management, documentation, client/server, and GNUstep integration with many GNUstep based applications. There will be a web browser, some office productivity software, etc. (mozilla based, open office?) We'll also have a server version.
That covers what we'll be doing with basic desktop stuff which is what most people want to know. However, there are a lot of things we'd like to see under the hood too. These are projects with which we have no specific timetable but want to see added.
1. Enhanced disk encryption for portions or the entire disk. (subset might be like an OS X home directory with encryption)
2. Something similar to OS X style dmg files. A transparent disk image system. There are many things we could use to implement this.
3. An alternative scheduler more suited to desktop SMP usage. Multicore is here to stay. We need to grow up to it.
4. Disk schedulers. Disk IO is notoriously slow in FreeBSD and MidnightBSD. There are a number of factors including locks, scheduling, poor UFS2 performance, etc.
5. Enhanced wifi configuration and support. Wifi should be much more transparent than trying to enable wpa_supplicant in rc.conf and hacking out a config file for it. The network stack is not optimized for wifi or the newer FIOS/cable modem packages available in some parts of the world. This means we need a self tuning stack to handle both extreme cases.
6. Support for Intel Macs. This is a combination of power management, fans control, drivers, and either Mac EFI 1.x support or a hack around it. (i.e. use the emulation) MBSD does not boot on a Mac Pro due to the keyboard probe timeout and other issues.
7. Cleanup of the threading libraries. The FreeBSD project has changed to libthr from KSE in current. We need to evaluate what is best for us and pick a final default and make sure it is standards compliant. Changing threading libraries every other release is very painful with ports and third party software development for your OS.
8. Integration of BSD licensed replacements for GNU licensed tools. Unlike some projects, we are much more content with other licenses, but for flexibility it is preferred to use BSD licensed software in the system. As much as possible we'd like to keep everything below the GUI layer a BSD licensed app. I do expect to use a lot of GPL/LGPL code during the course of the project as well. Both licenses serve different needs. This also includes importing code from OpenBSD, NetBSD and to a lesser degree DragonFly. Those projects have more actively targeted userland improvements. We also hope to develop many of our own.
9. Security. We have a great deal of plans to improve security including a default firewall, improvements to the existing firewalls. (pf upgrade, changes to ipfw) I've mentioned the disk encryption and we hope to look at other sections of the code for enhancement. Switching to gcc 4.x would also be helpful on this path.
I'll write more on this later.
First, we have nearly completed 0.1 for release. I am building packages for 0.1 on i386 right now. There are several problems with mports exposed in the builds for 0.1. We should have work arounds before the release. 0.1 will not include a new installer, but some of the mports changes will be included.
Security patches present in 0.1 and 0.2 for everything known except the recent theoretical scheduler attack that effects practically every OS except Mac OS X. I don't see us moving off of a tick based kernel anytime soon. It's in the back of my mind though.
Most of the changes in 0.2 so far are in the mports infrastructure or userland. There were a few subtle updates to drivers including firewire. I expect more driver work in the next month. No one has reported any hardware that doesn't work in MBSD but does in other systems barring the limits of Xorg 6.9.
One of our developers has been working on migrating to Xorg 7.2. I don't want to commit this change to a specific release, but it will happen before 1.0. We will also include an x11 based installer, current GNUstep environment, and a GUI mports management system for 1.0 release.
0.1 release will not be an ideal desktop system. It is a new project working out release engineering, testing, and proving the changes we've made from FreeBSD are correct. It should be fairly stable, but not feature complete as a desktop. (think CLI) We are toying with a way to install GUI packages as a hack until the new installer is done.
0.2 release will include the critical ports of the mports tree. Depending on ctriv and wintellect's progress, we hope to ship command line tools and possibly a GUI if caryn and alex get that part done. If not, we will be very close to done with major mports work. We also plan on having a new installer for desktop installation, plus any userland + kernel work during the development cycle. (cvs, ssh, and quite a few other things have been updated in current already)
0.3 should complete the mports and installer work based on feedback from 0.2 and anything that was not completed during the previous release. More kernel and userland improvements
0.4 will focus on the desktop experience. We plan to get documentation in order, determine the final packages for 1.0 release, and work on integration. This will be point we make the judgement call on Etoile. Prior to this release, we plan on using WindowMaker and slim. We could revisit Etoile later, but not for 1.0. (more userland + kernel stuff)
0.5 will be the beginning of the server release. The desktop version of MidnightBSD is the focus of the project, but we've decided to ship a server installer with separate ISOs. People in the project use MBSD as a server and it would be helpful for us to have it. The installer will be a bit different for this release as we plan on allowing users to select packages (think httpd, mail, ftp, etc) as well as add more control over partitioning and things required in a server OS. I don't plan on making the server a priority as FreeBSD is quite capable as a server as is all of the mainstream BSD projects. (Free, Net, Open, DF) You could compare this to Mac OS X server versus Mac OS X client. They are the same but the server had additional tools and services. Die hard security fans wouldn't run a GUI on a server so we don't consider this to be a mission critical type of thing. It's for a computer lab or small business environment where the other BSDs fail to target and Linux or windows get used.
... (whatever else we need to do before release)
1.0 Release
Full desktop environment with installer, GUI package management, command line environment and package management, documentation, client/server, and GNUstep integration with many GNUstep based applications. There will be a web browser, some office productivity software, etc. (mozilla based, open office?) We'll also have a server version.
That covers what we'll be doing with basic desktop stuff which is what most people want to know. However, there are a lot of things we'd like to see under the hood too. These are projects with which we have no specific timetable but want to see added.
1. Enhanced disk encryption for portions or the entire disk. (subset might be like an OS X home directory with encryption)
2. Something similar to OS X style dmg files. A transparent disk image system. There are many things we could use to implement this.
3. An alternative scheduler more suited to desktop SMP usage. Multicore is here to stay. We need to grow up to it.
4. Disk schedulers. Disk IO is notoriously slow in FreeBSD and MidnightBSD. There are a number of factors including locks, scheduling, poor UFS2 performance, etc.
5. Enhanced wifi configuration and support. Wifi should be much more transparent than trying to enable wpa_supplicant in rc.conf and hacking out a config file for it. The network stack is not optimized for wifi or the newer FIOS/cable modem packages available in some parts of the world. This means we need a self tuning stack to handle both extreme cases.
6. Support for Intel Macs. This is a combination of power management, fans control, drivers, and either Mac EFI 1.x support or a hack around it. (i.e. use the emulation) MBSD does not boot on a Mac Pro due to the keyboard probe timeout and other issues.
7. Cleanup of the threading libraries. The FreeBSD project has changed to libthr from KSE in current. We need to evaluate what is best for us and pick a final default and make sure it is standards compliant. Changing threading libraries every other release is very painful with ports and third party software development for your OS.
8. Integration of BSD licensed replacements for GNU licensed tools. Unlike some projects, we are much more content with other licenses, but for flexibility it is preferred to use BSD licensed software in the system. As much as possible we'd like to keep everything below the GUI layer a BSD licensed app. I do expect to use a lot of GPL/LGPL code during the course of the project as well. Both licenses serve different needs. This also includes importing code from OpenBSD, NetBSD and to a lesser degree DragonFly. Those projects have more actively targeted userland improvements. We also hope to develop many of our own.
9. Security. We have a great deal of plans to improve security including a default firewall, improvements to the existing firewalls. (pf upgrade, changes to ipfw) I've mentioned the disk encryption and we hope to look at other sections of the code for enhancement. Switching to gcc 4.x would also be helpful on this path.
I'll write more on this later.