Slashdot Mirror
No Love For Darwin?
There's an interesting column regarding the attention -- or lack thereof -- that Darwin is getting, at least compared to OS X. Somogyi points some out some interesting diversions of interest that people are having, and what exactly is Apple /doing/ about Darwin?
This article, Open-sourcing the Apple, has a different point of view on the subject.
If you travel in geek circles, by now you have no doubt heard about Apple's beta release of OS X, a wholly new operating system for the Macintosh. That's especially true if you are a member of that subset of geeks who closely follow open-source software issues.
OS X is a much anticipated amalgam of the Mach 3.0 microkernel from Carnegie-Mellon University, and FreeBSD 3.2, a more traditional open-source Unix-compatible operating system from the FreeBSD Project. But knowing that OS X is a microkernel wrapped up in a Unix OS, which is in turn wrapped up in a whole new layer of graphical user interface (GUI) technology, doesn't tell the whole story. Is OS X just another fancy GUI-based operating desktop system like Windows or is it a more industrially useful server-centric operating system like FreeBSD or Linux-based OS's? Crafting user interfaces is Apple's widely acknowledged forte; FreeBSD technology is known to power major Internet sites like Yahoo and Sony Japan. So which is it?
Or is it both? It is possible for one operating system to satisfy both the needs of someone like myself, a FreeBSD developer who expects a lot of power and flexibility from an operating system, and the average user who just wants to point and click?
( read more)
That's assuming that Darwin is really targeted at the Open Sourcers to begin with. My thought was that primary goal of Apple's Darwin strategy was to provide the best damn device driver documentation possible in order to remove what could be a huge upgrade hinderence (see Win 98's ability to load SCSI drivers from '88, and MS's two fork OS strategy going on seemingly forever)
But then, you read things like this:
Part of the problem is also that Darwin's infrastructure is still incomplete. IOKit, Darwin/Mac OS X's whizzy new driver scheme, is still missing such esoterica as basic PC Card support, which explains why there is no Airport driver in the Public Beta
And you wonder, What exactly does Apple need? Would any kernel hacking on Darwing just get in the way of Apple or be irrelevent as soon as Apple gets done? Or is Apple waiting for 'the community' to come up with stuff like Powerbook support that Apple has already promised long ago.
So, is there any roadmap? Have they advertised for help in any department (except x86, which is obviously a lower priority to them)? Is there any development infrastructure besides a mailing list (see Mozilla's array of bugtracker, newsgroups, CVS, daily builds, docs, and so on.) I don't know the answers, but if they want more people to become interested, those are obvious places to start.
There's lots of capable hackers in the Mac community, but outside of commercial hardware companies that write device drivers, I can understand why Darwin-level infrastructure isn't all that interesting. It's a desktop OS, and the user interest (and shareware $) will always be in GUI tweaks and user utilities. Nobody's really going to care about NFS performance or mounting 200 different filesystems or whatever Linux-kernel people are worried about. And the consumer version won't even have a term window, so forget about classic Unix userspace stuff.
--
Business. Numbers. Money. People. Computer World.
I would guess that a lot of the reason the OSS community isn't putting a lot of effort is the "schism" between OSX beta and Darwin mentioned by Somogyi. If there's a two month delay between releasing OSX beta and the equivalent Darwin, then there's two months of work that's happened at Apple that isn't in the current Darwin.
How much effort would you put into fixing two-month-old code that you knew a large group of people were modifying daily?
...but not many people use the whole thing. Darwin Streaming Server is a top notch streaming media element, and is out for FreeBSD, Red Hat, Solaris, and Win NT/2k, as well as the source code. It also includes a proxy, so that you can configure your server as desired. It's equivalent to the QuickTime streaming server for OS X. As it becomes used, there will probably be patchs for each operating system, and it's development will parallel the QuickTime development for OS X.
e aming/
w in/
. html
http://www.publicsource.apple.com//projects/str
Darwin 2.1 is the core of OS X, and it's been released in segments, so developers can concentrate on the aspect of darwin they want to tweak, and maintain compatability with the main release.
http://www.publicsource.apple.com//projects/dar
All in all, there are many possibilites, but for the average hacker, the resources to get a G3 or a G4 to test the software out are probably lacking. As for the intel release, it's being worked on. The current version of Darwin can be tweaked to run on an intel, and there are details here:
http://www.publicsource.apple.com/projects/mail
this is also addressed in the FAQ.
Let's see. Darwin lacks all Quartz, Aqua, the OO API, and all of the nifty features in OSX, and in return, it uses an antiquated microkernel (mach) and runs FreeBSD in user space.
A) It's an ugly hack.
B) Its slower than straight FreeBSD.
C) It offer absolutely no advantage over FreeBSD in terms of anything. Not even stability, since BSD runs in kernel space anyway.
Why SHOULD anyone pay attention to Darwin, given its total lack of salient features?
A deep unwavering belief is a sure sign you're missing something...
I've heard that Darwin boots on Intel, and I'd love to check it out for myself, but I haven't been able to actually find any way of doing it. Anybody here been able to get it working? If so, how?
If you're interested in seeing Apple pursue this further, make sure to check out the OSX on Intel petition. Also, read the Register article about rumors that Apple is actually porting OSX to Intel, and their article about Apple's recent Darwin update.
---- I made the Kessel Run in under 11 parsecs.
First on the list, I suspect, would be...
'When is Quicktime player components going to be open sourced?'
I don't think that's going to happen, any time soon. For those people who want it as a matter of convenience (do everything in Linux!), that's all it is, a convenience.
For those who would need the Quicktime functionality... I guess it's too bad. For each OS their respective strengths, and movie/audio/media happens to be an Apple thing.
For those who would want that codecs for tinkering/development purposes... isn't that what Vorbis is all about?
'When are you going to port Aqua to the Intel world?'
We have, but since we don't make Intel/AMD branded hardware, we won't be selling the software. We would get millions in sales, as a secure, stable, BSD based Intel-platform OS, without any sales of hardware(currently), which means the only revenue model we could pursue would be updates and upgrades to the OS... Therefore shortchanging the R&D and development innovations of a floppy-less iMac, the FireWire enabled devices, the Airport capable systems, the long-battery life portables, the fanless designs, etc.
'How about your PDA plans?'
We are currently researching and developing a PDA strategy.
Now that those questions are out of the way... Hopefully more interesting philosophical/technical/social questions can be asked.
Geek dating!
GPL Deconstructed
I feel that one of the strongest points of Darwin that everyone is really overlooking is the Bundle system, a directory that groups together all the associated files of an application (and which abstracts out this directory *as* the application). This is a system far superior to the way that windows or any linux/RPM deals with the question of "what constitutes a packaged application?". If you have a centralized database such into which app information is installed (such as the RPM database or windows registry) and there is no metadata or anything else from which a new database can be rebuilt, you end up with a techsupport nightmare. The centralized database could (and usually does) get hosed and (re)(de)installing an application is difficult if not impossible. The bundle system presents a far more robust solution, since all files associated with an app are kept together in a directory and not just in a single, fragile, non-rebuildable database. The bundle system could dramatically reduce the TCO that windows incurs through the registry (probably at the cost I/O efficiency), something the corporate world would find attractive (if the dumb bastards actually looked at TCO when making purchasing decisions). Linux should scrap RPM/Deb altogether and simply go with Bundles.
Right here.
;)
That should get you started.