This isn't quite my TODO because there'll be a few things in here which I don't intend to do. Either because I don't have the know-how or the time, occasionally because I don't have the inclination but would still like to see it happen. There are things in here which I do intend to do, or at least to attempt in some non-trivial way. There are also things which are underway but I'd like to see reach fruition. Later annotations highlit.
There are SCSI interfaces available for the "pro" machines, the Xserve and PowerMac. Some companies have commercial products which provide tape support, but as many other UNIXen support SCSI tape out of the box, and there's a big wodge of data out there stored on tape (especially in the scientific community); it'd be great to have at least a simple /dev/st built into the OS.
Status: not for me. I've got no idea how to do a device driver, nor how to support the multitude of tape devices out there. I suppose that's why Apple dropped tape support between Rhapsody and Darwin in the first place. There already is a Darwin tape project, but it's been stagnant for rather a long while. It'd be good to see a KEXT coming out of that...
In order to get wider acclaim from distributors and hackers alike, I think that a build process similar to FreeBSD's is essential. Now DarwinBuild is cool and gets its job done, but it's designed for a different task. Namely, it's all about taking a specific release of Darwin and then being able to tweak individual projects. Any time you want to sync against Apple's Darwin releases (remember there's no live CVS) you have to seed a new darwinbuild environment, then merge your changes in. Reasonable in the cathedral model, bad for a bazaar.
Having a 'make kernel; make world'-style process would make it much easier to merge arbitrary updates into an existing source base. It would - naturally - mean fairly rapid forking from any Apple or OpenDarwin release, but that can be a good thing. Third-party distributions would only be viable if they're going to "add value" to Darwin - whether they support other architectures, are configured in different ways, have different userland, whatever. They're also going to need a 'make releasecd' or something, which would hang off of a 'make world' environment in a fairly natural manner.
Status: I'd like to have a go. This is a big task but one I believe is essential to much that is coming up below. I think initially I'd base it off of one particular Darwin release and have a make frontend to darwinbuild. Once it's capable of building the entire OS, it'd be time to reverse-engineer darwinbuild and have a completely self-contained build process. Then being able to build an installer CD would be the next step...I notice FreeDarwin has been set up to do exactly this.
This is a big one. As I've already said elsewhere, Apple provide the Darwin sources for reference only, and OpenDarwin produce occasional distributions based on packaging up the existing Darwin sources; but they're infrequent, hard to keep up to date, and don't add much to the mix (tools like NCutil are indeed cool, but just involve plonking a new RPM onto the installer CD). What I'd like to see is people actively forking the Darwin sources and making new products; I think there's a lot of scope for innovation there. Whether a particular distribution aims to be binary-compatible with Mac OS X would depend on the goals of each product; obviously those that are can be inserted "under" an existing OS X installation in certain use cases. Of course, voiding the warranty in the process. So, here are my ideas, I'm sure other people can think of many, many more:
With the switch to Intel, it's now only a matter of time (granted, probably at least five years) before Apple decide to drop the PPC support from the Mac OS X product. Of course, with no new Mac/PPC hardware in the pipeline, any potential PPC distribution of Darwin is going to have an easy time with architecture support, and could gear itself toward updating the userland, supporting new peripherals, implementing new and cool things etc. I think that would be rather exciting.
Status: this is the one for me! I think what I'm going to do is get some ideas together and start a project, concentrating initially on getting a good build and installation mechanism together as described above with 'make world'. I'll take the final version of 10.4.x (or of 10.5.x, depending how long the preliminary stages take :-) as the forking point, and work initially on integrating it into the build/installation/distribution stuff. From there, I can see where the fancy takes me; being able to support Mac OS X is something I'll probably test for and consider nice but not necessary. I tried this, and it's more or less dead now. The problem was that there isn't enough source available from Apple to even boot to a single-user shell from open source components. However, FreeDarwin appear to be pointed in the correct direction.
GNUstep is very similar to Cocoa; both are descending from the OpenStep specification written by NeXT and Sun. As many GNUstep users came from the OpenStep world, and a system based on Darwin and GNUstep would be very similar to OPENSTEP, there may be much mileage in producing such a distribution.
Status: not for me. Again, this is something I'd like to see but wouldn't want to launch into myself. For a start it involves switching the default compiler from Apple gcc to FSF gcc, and I can imagine that being complex (though I may be wrong). Doing it properly would also require quite a mess of other Darwin projects; a functionally-similar-to-OPENSTEP OS would probably need to be based on a Darwin version before 7 (e.g. 6.8); but then there would be all sorts of bugfixes and potential new features from 7 and above to be merged as well as looking after GNUstep and its various applications.
Now this is so much pie in the sky that I won't even put a status tag; it's just something I'd never know how to do [although of course, someone else does...]. Darwin, as with its NEXTSTEP predecessors, is based on a Mach microkernel with a BSD grafted on to it. However it's not a true microkernel OS; while some things like the device drivers (IOKit, really cool and something I need to learn about) are in userspace, the BSD isn't a Mach personality server. It'd be theoretically nice and good for developers to have a true personality instead of the current xnu scheme. That said, I'm not sure what any practical benefits would be (and I'm sure Linus would have a rant about DMA being slower).
| Þæs ofereode | About the author | comp.lang.objective-c FAQ | Darwin/Mac OS X things | Coding stuff blog |