Benjamin Herrenschmidt On PPC/Linux, Apple and OSS

MacBoy writes "The folks over at ResExcellence have a great interview with Benjamin Herrenschmidt, kernel guru for the PPC/Linux camp. He offers up some history of Linux on Apple and PPC hardware, and some discussion on Apple's current and past contributions to the open-source and Linux communities. He makes some interesting comparisons of Linux on PPC vs. Intel hardware, such as the ease of getting important patches into the kernel on PPC compared to Intel. It's an interesting read, especially if you are amoung the many who covet the new Dual-CPU GHz G4 Macs and want to know a little more about the PPC/Linux community."

Comments

Re:Question:

[MaxVlast]

Umm, have you ever used it?

> I don't have to mention the GUI do I. Apple's is
> terribly slow and most of it is in fact useless.

That's just from outer space. It can get bogged down, sometimes, but it remains extremely peppy and always responsive on my G4 400.

> OS X costs $129.00

And it's a bargain for that.

> OS X hides many admin tools deep in the GUI

Care to name one? The applications are in /Applications. The admin tools are in /Applications/Utilities. If that's deep, you need to stick to MS Bob.

> Apple should have built OS X off of Linux if they were smart

Or, they could have stuck with the system that the OS was developed on, the development environment that everything is targeted for, and the environment that they retain complete control of (and doesn't come with thousands of screaming teenagers.)

Re:Comparison between x86 and PPC performance?

[hettberg]

I would be interested to see some comprehensive real-world benchmarks comparing the two platforms. Really, I'm rather tired of the "Megahertz-myth" PPC touters and the "RISC sucks" x86 campions arguing which is better without any solid numbers.

You could have done that a long time ago with NetBSD, probably the most portable OS in the world.

Oooooh, I forgot. IT'S NOT LINUX!

Apple doesn't know what it wants

[Y-Crate]

On one hand, you have them using and contributing to open source. On the other, you have them sending the lawyers after people who try to create a theme engine because they believe it is theoretically possible for someone to use it to violate Apple's trademarks.

You have them giving away developers tools a short while after they send their users firmware upgrades to prevent G3 users from upgrading (without telling the G3 users what the magical firmware upgrade did)

You have them sending firmware upgrades to block the use of RAM that doesn't meet Apple's strict standards, without telling users ahead of time the sticks they spent hundreds on are now utterly useless.

Apple can't decide wether it wants to be free and open, or continue to manifest its worst control-freak tendancies - ones that even rival Microsoft.

Day for PPCLinux is past but......

[marktwain]

With OS X the usefulness of Linux on the PPC platform is indeed brought into question, but article is still a good read.

It's interesting, however, to note that Linux people still miss the whole point of finding out about Mac OS X. Don't like it? Don't use it. But if you're smart you'll develop for hit. Read the O'Reilly Network, or any any other article, for writing in cocoa for MacOS X.

If there's anything missing in the viability of the comments about PPCLinux and its "questionable viability" you could well say the same thing about Linux in general as a desktop platform. It's going nowhere. Genome and KDE will not only never be the finished GUI that OS X is, but they also won't have the installed (and growing) desktop users that OS X has either.

New games are shipping for OS X, not ports, but original games. The recent O'Reilly network article about writing for cocoa represents an idea which any geek interested in making a living doing something besides tweaking SQL databases may want to consider.

Sure, the Mac OS X kernal, Darwin, itself offers much to users. But any Linux geek who likes to write code should give it even more serious consideration, its portability to other platforms, including Linux.

If you're hung up on the idea of free software disregard this, but if you're looking for a good *nix OS check out OS X if you're smart.

Re:Question:

[Bodrius]

I'm no Apple user, but I had the chance to play a bit with Macs for some weeks and I'm afraid you're dead wrong.

I'm sure Linux is faster than OS-X for some tasks. Probably a lot of them, actually. But are those the tasks OS-X is geared to?

A web-server? What do you need a GUI and Aqua for in a pure web-server? You don't put KDE and GLTron on your Linux webserver, do you? OSX without Aqua is not OSX, it's Darwin.

OS-X is a desktop-geared operating system. It's made for interactive use, to play with Photoshop, 3D animation, movie editing, software development and whatever the user happens to require. It contains a web-server (and all the other servers) because it's useful for the user/developer. The user wants to see his personal webpage at once. The developer wants to code and deploy.

System requirements? Can I run KDE/GNOME on "very little memory" anymore than I can run Aqua? I don't think so. I tried a couple of times, and I feel stupid for trying. Linux can survive in very little memory just like Darwin can, but Linux-OSX is no valid comparison.

I don't understand either what you're saying about admin tools deep in the GUI. The shell is right there, waiting to be used as always and with all the tools one needs. So are their GUI front-ends, which I never had problems to find as a non-Mac user, and which are much simpler and convenient (the whole point of the GUI front-end) than any I have seen in Linux.

What does Linux offer in advantage to the GUI's organization in OSX? Are you talking about KDE, or GNOME, or something else, any of which you could install over Darwin (if they can be installed in LinuxPPC)?

Apple's GUI is not so slow these days (maybe it was in 10.0). At least it didn't seem to me when I used it, and it's not like I had the time to "get used to it". Not as responsive as my Win box, but much more responsive than my Linux with XFree. Useless? If you mean the pretty effects, transparency, etc... sure, but it's part of the Mac style. Aesthetics matter. If they didn't, you probably wouldn't be buying a Mac.

Price? For a competent, fully-functional, user-friendly desktop system based on Unix? I would prefer free, of course, but if I were willing to pay for the Mac I'd pretty much buy the OS-X no questions asked. But of course, that's included in the price of the Mac.

Apple did the smart thing using BSD/NextStep. Even if they didn't consider it a superior, more robust Unix as they said, it lets them avoid the politics that surround Linux. Just not having to deal with all the license zealotry and "Linux is always better" chanting is worth the price.

Re:Oh, those dual G4's look nice

[calumr]

I'd love to get the "other endian machine" and compile some game code on it. Anyone have any recommendations? How did id do the Quake3 port to Macs ?

I ported Doom to the Mac about a year ago, and let me tell you - endianness is a bitch to debug. There is no easy way to do it other than running the game until it crashes, then stepping through the suspect functions until you find the culprit.

It was probably a little easier for id, seeing as how they wrote Quake3 themselves with cross-platform compatibility in mind.

Re:Question:

[Lars T.]

Let's ignore that not even all Macs can run OS X, here's a quote from the interview:

"The PPC tree has it's own complexities, mostly because we have to deal with a large set of very different machines and CPUs. From the PowerMacs, PRePs & CHRP, the 4xx and 8xx based embedded platforms, and even IBM pSeries and iSeries servers."

Re:Question:

[MouseR]

How about price. Linux is free while OS X is not. OS X costs $129.00 at the Apple store.

How much would you pay to get ProjectBuilder and InterfaceBuilder for Linux?

We get 'em for free with Mac OS X, and also get a copy of Mac OS 9.2 for free.

Oh sure, rant as much about OS 9. How often do you have to boot in Windows to do something (your favorite game, or perhaps Word).

So, see it this way: for 130$, you get 4 distros:

1. Darwin,
2. 
   Mac OS X (Quarts etc)
   Incredible dev tools
   Mac OS 9

I say that's pretty good value for the buck. (Besides, if you buy a new machine, you get all that anyhow).

Re:Oh, those dual G4's look nice

[shamino0]

I develop network protocol stack code for a living.

Endinanness isn't entirely trial and error. The big deal is that you must explicitly convert any value that you read from an external source (a network socket or a data file that may be read by a different implementation.) Similar conversions must be done whenever you write data to such an external destination.

The biggest problem you find when porting code that wasn't designed for portability is people who decide to read a block of bytes from a file/socket and then cast a struct pointer onto it. This is inherently evil. It only works if the endinanness matches, and the compiler pads the struct identically to the external source.

The solution is to parse the buffer byte-by-byte, arithmetically combine the bytes into their integer values, and then assign them into a struct. For instance, if I have code that is trying to read a 2-byte integer, followed by three 3-byte integers (ignoring possible I/O errors, for simplicity), this would be a bad and non-portable implementation:

typedef struct foo
{
short a;
longb[3];
} foo;

foo*fooptr;
charbuffer[14];

read(fd, buffer, 14);
fooptr = (foo *)buffer;
...

The above code assumes that the size of long and short will be exactly 4- and 2-bytes, respectively. It assumes that the integer representation matches that of the data stream. And it assumes that the compiler not insert any padding between the structure members.

Using the same struct, this code would be portable across all platforms (assuming that the data is big-endian format. If the data is little-endian, the solution is left as an exercise for the reader):

foofoobuffer;
char buffer[14];

read(fd, buffer, 14);
foobuffer.a = (buffer[0] << 8) | buffer[1];
foobuffer.b[0] = (buffer[2] << 24) | (buffer[3] << 16) | (buffer[4] << 8) | buffer[5];
foobuffer.b[1] = (buffer[6] << 24) | (buffer[7] << 16) | (buffer[8] << 8) | buffer[9];
foobuffer.b[2] = (buffer[10] << 24) | (buffer[11] << 16) | (buffer[12] << 8) | buffer[13];
...

It's a bit more tedious to write and read, but it will work on all platforms, regardless of the internal representation of integers and structs. It will even work if the internal size of short and long variables is longer than the usual 16- and 32-bits (which is legal according to ANSI-C). And the ugliness can be mostly avoided through use of macros (or inline functions, if you prefer.)

If your data format consists entirely of big-endian integers of 16- and 32-bit sizes, you can also use the system-provided ntohs(), htons(), ntohl(), and htonl() functions. If your data is little-endian format, or some other format, then you obviously must roll your own converters.