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.
Comments
One can debate the need for a fork all day. However, I feel that just doing it put the thought in the mind of other BSD developers to work on the desktop/laptop space more. FreeBSD: the power to serve is not a focus on laptops. Considering they have moved to the embedded space recently, I still don't think the desktop is their top priority nor is supporting hardware for it. OpenBSD pumps out wifi drivers like there is no tomorrow and the other BSDs benefit from it. So in terms of sharing code, it happens anyway. However, someone has to step up and do it. With a project focused on these types of problems, we have the potential to move forward faster than a server centric culture. Most of the recent innovations have been from SoC or PC-BSD funded work in the desktop arena. It has not been from within. Obviously the PC-BSD and desktopbsd folks agree with me that BSD can be a good desktop platform and they have moved the bar up for FreeBSD to start caring more about the desktop. In my opinion, NetBSD has the most momentum right now in terms of desktop use, but it's still no where near popping in an os x, ubuntu or windows cd and running with it. So back to your question, is a fork necessary perhaps not. Does it have psychological benefits? yes. Can we try to solve some of the community problems? yes. Also, you didn't comment on MirBSD. Why not hit them all? :) Besides, in the BSD world we fork. It's what we do. From one perspective, every current BSD has forked. 386BSD anyone.
I do not want to be a troll but why is it necessary to fork the kernel and not add to the kernel like fixing driver bugs or improving drivers? In the following *-BSD=[Dragonfly,Free,Open,Net]BSD with emphasis on NetBSD A good GNUstep/Etoile oriented distro is a MUST and using a BSD kernel I think is beneficial to the end user. Linux offers it as an option whereas MidnightBSD can maintain a desktop on *-BSD as a direct competitive solution to MacOSX Many visual tools can be developed to tweak the kernel/drivers from userland something more or less existing in Windows but not satisfactory. Does it require a fork? Another example : the firewire driver cannot export an interface to OpenCV like on Win/Linux which is a must for CV/IP applications. this should be improved on all BSDs having firewire support. Is a fork necessary? Another example : USB4BSD brings the possibility of using the cameras on NetBooks. MidnightBSD can provide a framework for this which will be crossplatform between BSDs. Is a fork necessary? Another example : A pictBridge printing solution for BSD is necessary for bluetooth devices. Is a fork necessary? As an example : If a version of *-BSD on L4 with drivers ported to userspace was intended I believe it has value as a research project with end user implications(personal opinion) As an example :A desktop oriented ports distribution with frequent updates is useful instead of compiling packages, something like Cygwin. It is beneficial to developers to do their work.
I did not mean to be a troll and I respect your opinion and hard-work. I just wanted to understand the intentions of the project. Are there any plans to provide a good hardware experience on the desktop? By the way I posed some typical questions which are usual Pro-windows arguments in my lab. Will these issues be addressed? Will you base the distribution on NetBSD? There was no clear answer if forking is the target of this project. A netbsd distro with gnustep/etoile and forward looking enhancements in USB/BlueTooth/FireWire and WiFi which will be imported back to netbsd makes a lot of sense to me. Is a re-design necessary? Possibly in selected areas it is necessary but how far is midnightbsd intended to go? A detailed roadmap+ real issues or user requirements (like a feature request list on existing solutions can be helpful). So I think a voting system for desktop enhancements to various bsds can help identify a roadmap. I have stated some and I think they are crucial. This way things not implemented or that will take time can be identified and solved possibly by a re-design - aka FORK.
I did not mean to be a troll and I respect your opinion and hard-work. I just wanted to understand the intentions of the project. Are there any plans to provide a good hardware experience on the desktop? By the way I posed some typical questions which are usual Pro-windows arguments in my lab. Will these issues be addressed? Will you base the distribution on NetBSD? There was no clear answer if forking is the target of this project. A netbsd distro with gnustep/etoile and forward looking enhancements in USB/BlueTooth/FireWire and WiFi which will be imported back to netbsd makes a lot of sense to me. Is a re-design necessary? Possibly in selected areas it is necessary but how far is midnightbsd intended to go? A detailed roadmap+ real issues or user requirements (like a feature request list on existing solutions can be helpful). So I think a voting system for desktop enhancements to various bsds can help identify a roadmap. I have stated some and I think they are crucial. This way things not implemented or that will take time can be identified and solved possibly by a re-design - aka FORK.
Just another suggestion. Netbooks are becoming important. A voting system can help identify what is not existing in other BSDs and detail a roadmap to support them. So the question is not only taking what is good, but mainly improving what is bad and disseminate it. And do not forget, USB3.0 is getting ready.