Apple OS X, BSD and Jordan Hubbard

We've had a number of posts noting that Boston.com's digitalMASS has a very decent article on Apple's OS X, BSD and Jordan Hubbard.

Comments

Re:OS X

[trurl3]

I've been a linux user for almost 6 years, and generally laughed at Macs (the whole one-button thing, etc.)

I wanted to find a nice laptop that would run linux, and even had a dell for a few days. Then, a friend of mine introduced me to Macs, and, in particular, the Tibook. You can see it yourself - overall, its probably the single best piece of hardware engineering imaginable.

And OS X really is awesome. I'm not into having the point-and-click interface myself, and love the console. But OS X really is nice to use. Its networking support is amazing, and works right out of the box. Support for sleep is great too.

Right now, from what I can see, the biggest problem with OS X is the lack of a decent DivX player. (4.11 tends to desync in about a second). Otherwise, it's awesome. And, if you really can't let go of blackbox or whatever (like me), there's the XDarwin project that lets you run X on top of OS X. So far, I've only tested the default twm, which runs fine. But using the apple developer tools you can compile any window that's been ported (I believe at least gnome and afterstep have been), and run it there.

Certain products are still not quite ready for OS X, but the situation is improving rapidly. I have to disagree with one of the posts below - its not about being "productive"; one could easily do that in Linux. (I refused to run IE, and will
NOT be getting Office). But it is a sincerely nice operating system to use, and the hardware is definitely going to be a computer legend.
Regards,

trurl

Package Management via Ports

[Christopher B. Brown]

The crucial difference between the "free" BSD systems and Linux is that OpenBSD/FreeBSD/NetBSD define as their "base OS" something rather larger than Linux does.

In effect, all Linux proper is is an OS kernel. Everything on top of the kernel is something that is bolted on independently of any kernel development. Thus Slackware is the Linux kernel plus "all sorts of stuff Patrick Volkerding added;" Red Hat Linux is the kernel plus "all sorts of stuff they added;" ditto for SuSE, Debian, Mandrake, ad infinitum.

With the BSDs, there's quite a lot of additional "environment" that is tightly tied to kernel development so that you've got a "base system" that is defacto-standardized that is capable of, for instance, recompiling itself.

With Linux, you've got to add in whatever that is needed that isn't in the kernel in order to do that yourself.

With that larger basis of "stuff" surrounding the kernel, a whole lot of the arguments "Red Hat puts the files here; Debian puts them there" just plain go away. The "Linux Standard Base" effort where they're trying to standardize where a bunch of the basic stuff goes and what it does is an effort that would be ludicrously irrelevant amongst the BSD folk; they started off by standardizing the user space stuff that LSB is fighting over.

Then there's Ports. Ports is sort of the BSD equivalent to Debian's apt-get or perhaps the Red Hat-oriented autoRPM . Except with a difference: With Ports, the approach is not to download binary packages, it is rather to download the sources, pull in any patches needed for Ports integration, and then compile it all.

That's got the demerit that it's a lot more work for your poor, overworked CPU.

However, it has the merit that if you compile libraries and packages, together, on your system, with the same compiler, the sorts of "DLL Hell" that people suffer from when they grab RPM files from here and there just can't happen. The libraries will necessarily be compatible with the applications because the applications were compiled with and for the precise set of libraries you have on your system.

This means that if there are any challenges in getting programs to compile, you'll hit them. That being said, since the folks collecting and maintaining the Ports will indeed hit those issues, they're likely to have patches in place so that by the time you see the code, it should compile cleanly.

In effect, the crucial concept involved in all of this is that the BSD packaging paradigm is that everything should be readily compilable and recompilable, from the ground up. The classic "make world" will compile all the base tools, the kernel, all the kings horses, and all the kings men, and what you get at the end is that every single component in the "world" (which is the base system; the stuff below Ports ) has been rebuilt locally.

It's all using Makefiles, and can be downloaded using CVS, so the details are all visible. None of the controversies of "well, the Red Hat kernel compiles include some special patches, and getting at them is a bit challenging...."

Big-time learning opportunity.

Re:had to beg for a job?

[jkh]

This is something which got a little confused in the translation. What I said was that it took me several months to come to Apple after my initial interviews because a little detour to Wind River happened in the middle (for reasons I won't go into). This somehow got permuted into my spending months chasing the job. In reality, Apple never gave up after "losing" me to WindRiver and their persistence coupled with my desire to get involved with MacOS X is what finally induced me to leave WRS.