OpenDarwin.org Releases Darwin With Fixes

An anonymous reader writes "OpenDarwin released a 'fixed' version of the Darwin 6.0.2 ISO (the OpenDarwin-20030213 Binary Release) for both x86 and PPC. It is currently installing, so I can't tell you all what works now, etc. Hopefully I can use my old PC box as a server with this..." Apparently, it is mostly a recompile, without local OpenDarwin modifications. It doesn't include perl, pending integration of perl 5.8 ... could this mean Mac OS X will finally have a current perl in the next Mac OS X release?

Perl version

[Draoi]

My TiBook (w/vanilla kernel 6.4) tells me this;

[dhcp1i174:~] pcassidy% perl -v

This is perl, v5.6.0 built for darwin

Copyright 1987-2000, Larry Wall
[blah snipped]

So, when I check with perl.com [perl.com], I see that the latest, stable release is 5.8.0. It's not *that* far removed, so why imply that MacOS X is 'finally' getting a current release of perl?

Re:hmm

[Anonymous Coward]

Darwin is composed of the Mach kernel and the BSD subsystem.

Re:Perl version

[Ranger Rick]

5.6.0 has a number of nasty bugs that (at the very least) 5.6.1 fix, especially in unicode support. Also, Apple built their perl in a way that makes their perl modules go into an essentially unversioned directory, which makes it harder to upgrade perl as time goes on.

The longer they wait, the messier the upgrade is going to be...

Re:Darwin x86 or BSD???

[Gropo]

Depends on what you need it for... If you want a personal file server for a predominantly Mac household, you might appreciate the NetInfo abstraction Darwin offers.

Other than that, you might get better performance out of one of the tried-n-true BSD's due to the lack of overhead taken up by the message-passing microkernel.

Re:No it doesn't.

[Oculus Habent]

The problem with the home directory being the desktop is it goes against the filing metaphor. In the truest use of the desktop metaphor, the only things on the desktop should be what you are working on right now.

Apple originally had the best system for this, and it was lost in Mac OS X. You could drag files out of their respective "filed" locations on to the desktop to work with them, and when you were finished, there was a "Put Away" command (Command-Y for you OS 9 and lower users) that would return the file to it's original location.

Put Away really helped the Desktop metaphor by simplifying filing tasks and allowing the Desktop to fulfill its intended function. Unfortunately, it wasn't well documented or pushed in any way, and it was lost.

Returning to the home/desktop issue, if you were to make the Desktop the home directory, clutter becomes a more difficult issue. If I have stuff on the Desktop, I can move it into my directory to organize it, clearing my Desktop for other stuff. If my Desktop is my home directoy, I am always exposed to the filing system of my design - much like always keeping a filing cabinet open in the real world.

The biggest problem the Desktop/Filing metaphor faces, in my opinion, is the inability to leave it. We don't usually keep filing cabinets on our desks, but we can't leave our desktop, so we have to. Microsoft tucked it all under Start in Windows XP, which is simply a clumsy way to make it look more organized while actually adding layers of inconvenience to the interface. My Documents used to be on the Desktop. This is as close to a valid implementation of a filing system metaphor as possible, and they decided it was better under the Start menu.

The Filing metaphor suffers greatly from the lack of transparency in applications. Plenty of different groups have tried to produce an Open Document Architecture (ClarisWorks, Apple's OpenDoc, Microsoft's OLE) that allows you to create a new document and then determine it's contents, but getting people on board was difficult because no one could guarantee the supremacy of their products when it was completely possible to have two different companies software interact. Making software on the basis of cost and quality didn't appeal to many (j/k) so that died quietly... OLE is only really alive within Microsoft's own Office suite.

Microsoft tried a different tactic to start handle the Application problem - the "New" submenu on the Contextual menu. While some people put this to good use, its placement and function was difficult for some to grasp, especially with many users having difficulty with the the nebulous nature of the contextual menu. The New submenu can be a great tool, but it take time to get used to it, and many forego the learning curve in favor of the Start button, which houses all your programs.

Anyway, I'm rambling now, so I'll stop. Basically, I think using home as the desktop would cause more confusion for the typical user, as it breaks the separation of filing and working. While this may not be a problem for Joe SuperUser, it could seriously impair average users.

Also, how do you handle multiple desktops? Will they have the same content? If you have too many files in your home directory to be displayed on the Desktop, will a scroll bar appear? Will you be forced to open a windowed copy of your home directory to conveniently browse it while other windows are open, or will you have to minimize everything? Will the desktop contents flow around docks?

Like I said a minute ago, I'll stop.

Update your Perl. It's easy

[acomj]

I downloaded and built perl for OSX. Perl Version 5.8.? built without a hitch.

Now you don't even need to build perl yourself. Get Fink [sourceforge.net] Macos X version of Apt-get and get a perl binary. (I'm pretty sure one is available). Fink is a great tool for keeping all the gnu/opensource software up to date.

Re:hmm

[Ryan Amos]

Take the mach microkernel, then take FreeBSD and put it on top of that and add what amounts to a central registry (NetInfo) and essentially you've got darwin. Apple essentially took UNIX, made it more like modern graphical OSes by adding functionality (not removing) and out came darwin. OS X is one hell of a sleek OS; insanely modular, everything is XML and embedded PDFs yet you can still run most (read: 99.9%) *nix programs with minor makefile modifications. It's BSD for the 21st century ;)

Re:Darwin x86 or BSD???

[TheCrazyFinn]

Darwin is a BSD

FreeBSD and OpenBSD probably better on x86 though.

Re:Perl version

[pi radians]

Ummm, do you mean this upgrade [apple.com]?

Re:Current (6.4) Darwin kernel ?

[Anonymous Coward]

build it yourself from the apple cvs... bewarned... the name would besomething like xnu-3024

Re:Update your Perl. It's easy

[pi radians]

Or if you want to forget all about fink you can take an even easier route [apple.com].

Microkernel performance

[Anonymous Coward]

...overhead taken up by the message-passing microkernel.

I thought Apple didn't use a true microkernel [apple.com] for precisely this reason.

Re:hmm

[Mikey-San]

I direct you to, no pun intended, /Applications/Utilities/Directory Access.

Authenticate and check "BSD Configuration Files". Now you can start using the BSD flat files, like /etc/groups.

If I'm missing something, it's because it's early and even though I'm at my desk, I'm still at home in bed.

-/-
Mikey-San

Re:Can I run Mac OS on i386 ?

[Anonymous Coward]

without emulation, negative.

Re:Update your Perl. It's easy

[jameshowison]

There is one wierdness.

Due to the HFS filesystem not being case-sensitive if you install libwww-perl (which you will probably do when upgrading to 5.8) then it puts HEAD (a tool for manipulating http headers) in /usr/bin which stomps all over the familiar head.

One to watch out for.

Re:Perl version

[Anonymous Coward]

I have installed Perl 5.8.0 on Mac OS X, and it can replace 5.6.x. I ran with it for a few days, but then found that the older version of the free Teradata module that I have would not work. The new version of the Teradata module is very expensive, and my organization is moving to a different data warehouse soon, so I'll wait for that and then try 5.8 again.

Perl 5.8 in Mac OS X default location

[daveschroeder]

Then just use these instructions [apple.com], provided by Apple, for installing Perl 5.8 in Mac OS X's default location for perl.

Re:Darwin x86 or BSD???

[Leimy]

The reason is that the Darwin kernel runs in one address space (even both the Mach and BSD personalities run the same address space).

Actually the fact that they are running BSD + Mach [the XNU components] in the same addreess space is a speed optimization to reduce context switching for every message from BSD to Mach. This isn't a cause of slowness but a reduction. Can you imagine how bad it would have been if they hadn't done this? This is documented on Apple's website in Kernel programming so I am not just making it up. Its in the section where they clarify that XNU itself is not a proper microkernel.

Apple didn't just pick up the Mach kernel and used it, they improved it a lot and one of the things they did was to rip out all that message passing stuff, while still retaining the modular design of the kernel.

The message passing stuff still exists and is still useful [while it may not be used in the kernel space... I haven't verified this yet.] Walking through the source of CFMessagePort stuff shows you that it calls mach_msg a lot actually. It's also super fast due to out-of-line memory transfers etc.

Re:Darwin x86 or BSD???

[geniusj]

Darwin currently has better threading (read: true kernel level threading) in SMP machines than any of the other stable releases of BSD do. But I'm not sure if that's available on Darwin x86 or if it's only ppc. I'm going to guess the latter.

-JD-
(waiting for KSEs to be finished . . .)

update Berkeley DB first

[teridon]

Those instructions note that you'll get an error during "make test" because of the old, buggy version of Berkeley DB included with Mac OS X. If you plan on using perl's DB functionality, upgrade to a more recent version. You can either use fink ("fink install db41") to get 4.1.24, or compile from source (available here [sleepycat.com]) to get 4.1.25. If you compile from source, you'll need to link /usr/local/BerkeleyDB->/usr/local/BerkeleyDB.4. 1

Re:Update your Perl. It's easy

[Ranger Rick]

Actually that is not the reason perl isn't in Fink, it's because we haven't found a good way to provide it without screwing things up for people that have already built modules against 5.6.

A couple of people have proposed solutions, but no one has yet had enough time or inclination to come up with a solution that has a halfway feasible upgrade path.

It is true that perl is not yet in Fink, however.

Re:Darwin x86 or BSD???

[Halo1]

oohoo!!! Why didn't I think of that??? Just rip out message passing!

I know you're just trolling, but for other peolpe that might be interested: in the original Mach kernel, every subsystem of the kernel talks to the rest by using message passing (which is obviously quite slow, but otoh allows you to keep every subsystem in its own address space). Apple changed this so that every subsystem lies in the same address space, so they don't have to use the slow message passing interface, but can use function calls instead to let different parts of the kernel communicate.

Obviously, the message passing interface is still there and e.g. can still be used to have kernel space code communicate with userland code.

Re:Darwin x86 or BSD???

[Halo1]

In fact, getting rid of message passing doesn't give you anything from both worlds, it gives you a monolithic kernel, plain and simple.

Fortunately, that's not true. I would suggest you to read this [apple.com] and this [apple.com] message posted quite a while ago on the darwin-development mailing list (use archives as both login and password).