DrunkenBlog

Pieter Van den Abeele of Gentoo MacOS and Gentoo Linux PPC

So it's been awhile since I've been able to sit down and have a real drink with my fellow drunkers, but I do have a treat for my 13 loyal readers: Pieter Van den Abeele of Gentoo Linux PPC and Gentoo MacOS was gracious enough to sit down for a weighty chat on both the projects.

It's worth warning that this is a bit of an odd chat, primarily due to the language barrier. I tried to dilute the sheer geek factor where I could, but it's still pretty concentrated. Where things got lost in translation should be obvious and amusing, but still worthwhile.

Before you ask why I didn't clarify more: getting this chat out was even odder behind the scenes and would qualify as a post of its own, and I'm fairly sure there's the Belgian equivalent of a restraining order with my name on it. Special thanks to Pegasos Systems who ended up doing the last phase of stalking for me and who I'll be doing a chat with in the future.

As a quick primer for readers who are unfamiliar (feel free to skip to the chat):

• Gentoo Linux PPC is a Linux distribution, supporting PowerPC hardware in both 32-bit and 64-bit. The Gentoo distro is relatively new to the Mac, but have made a lot of noise lately. If I was forced to sum up Gentoo, I'd characterize it as a relatively raw distro that makes few decisions for you, but provides you with tools to allow you to tailor your environment to your needs. It's not for everyone.
• Gentoo MacOS is a newly-released port of Gentoo Linux PPC's package management tool, Portage, to Mac OSX. A package management system is something that allows you to install and maintain the unix software on your machine while taking care of a lot of the intricacies for you. Think of this as akin to Apple's Software Update, but for *nix software and with the ability to install from scratch as well as update. Sorta.

You've been with the Gentoo project for quite awhile under various hats; what are your current titles and responsibilities?

My career at Gentoo started a few years ago when I founded the first non-x86 Gentoo Linux port, Gentoo/PowerPC. I've been involved with all aspects of that project, ranging from Strategic/Operational lead to release engineering. My ambition was to make Gentoo less x86-centric.

I've set up and am currently leading Gentoo-ALT, a top level gentoo project that manages Gentoo on alternative platforms and runtime environments. Gentoo for Mac OS X, a project I also founded and am currently leading is one of its subprojects. The MacOS siblings are Gentoo/Darwin, Gentoo/*BSD, Gentoo/Cygwin, Gentoo/Solaris...

The projects I've been involved with presented some real challenges for the current Gentoo Package Manager, Portage. In my Msc. thesis at the Free University of Brussels on the role of declarative reasoning in managing large scale software configurations I'm hoping present a solution for the open technical issues related to "metadistributions" such as Gentoo.

For those who aren't in the know, what the hell is a 'Gentoo' exactly?

Gentoo is a collection of tools and knowledge about specific concepts/domains related to Operating Systems. "A Gentoo" would be an operating system automatically built from scratch from that knowledge, satisfying the users requirements.

A more exact definition I wrote has been included in the new Gentoo Social contract, a work in progress.

You were the first working 32-bit distro on the PowerMac G5, as well as the first OS to have full 64-bit on the G5. But relative to other Linux distros, Gentoo historically hasn't had a lot of mindshare on the mac. Do you have a sense this is changing?

Our mindshare is definitely growing leaps. Just recently we gained a lot of mindshare by making all our PowerPC products natively compatible with Pegasos PowerPC Systems.

Freescale semiconductor, (a subsidiary of Motorola Inc.) has donated ten Open Desktop Workstations to this cause. Gentoo is obviously quite popular on these machines because our product, unlike other Linux distributions, just works on them.

Also, the latest release of Gentoo/PPC64 introduced POWER5 support. We are taking our enterprise support to the next level.

Looking through your developer activity, one gets the sense that the PowerPC effort is second only to x86 and growing. What do you think it is about the PowerPC that is drawing the attention?

A lot of people that currently run Linux or any other free and open operating system on their x86 machines, once switched away from another x86 operating system because it didn't meet their requirements. Depending on what their operating system requirements are, chances are their next desktop workstation, server, etc... will be a PowerPC machine.

For instance, some will insist on the ability to use Microsoft Office (or any of the free alternatives) for work, others just want to be able to build their own Operating System from scratch, others want to play games from time to time, others just want a (Unix) operating system manufacturer that contributes to open source development.

Whatever the requirements are, a PowerPC based machine will most likely be able to satisfy those needs better than any combination of x86-based operating systems on an x86 machine.

Aside from older hardware, Mac users are often confused by the idea of running a Linux distro on a Mac. The idea of paying a premium for Apple kit, which already comes with a *nix OS and includes one of the best user experiences around, and then slapping Linux on it seems to be viewed as a downgrade by them. Aside from geek-pleasure, what are the advantages of running Linux versus OSX on newer Apple hardware?

There are several advantages. The customizability of Gentoo is key. Third party applications might depend on some system component/functionality OS X doesn't supply out of the box.

For some people OS X or Darwin might be too slow or bloated. Companies wanting to squeeze every last bit of performance out of their server farm might choose to install a customized Operating System to do the job. Boeing for instance used a G5 based Gentoo Linux solution for its satellite software.

Also, even though Gentoo intends to support Security Enhanced Darwin in a later stage of the project, we currently offer security enhanced / hardened linux support. Such things aren't offered by Mac OS X out of the box.

And Mac OS X and Linux don't exclude each other. Both can be run inside each other, both can provide netboot functionality for each other, and it would be possible to provide cross-platform compiles (where each platform compiles stuff for the other).

As the founder, you were intimately involved with bringing Gentoo over to PPC. This can't be as simple as it sounds, and in fact your project seemed to grind to a halt for awhile with the intro of the G5. Could you give us a sense of what was involved for building in support for the PowerMac G5?

When we were working on G5 support, we were also migrating to a new multi-arch release tool called Catalyst. Combining both jobs was more challenging than we expected. Primarily since Catalyst was still a moving target development-wise back then.

The first G5 livecds were therefore hand-built on my G4 and tested by Eric Van Hensbergen on his G5 at the IBM labs. I think I built about seven series before I got every component right. The first CD consisted of a CVS snapshot of the bootloader, a 32bit kernel snapshot and a generic Linux userland.

Once I had a G5 available for testing we could start working on integrating support into Catalyst, but obviously work only started there. We had to start working on a compiler snapshot that would be able to build G5-optimized stuff. Every time we had a snapshot we thought worked just fine, something would turn out broken. Most of the time related to the optimizer itself (over-optimizing stuff) or Altivec/VMX being experimented with heavily upstream. I published a first set of optimized G5 binaries right after the Gentoo 2004.1 release.

Another aspect of getting G5 support integrated was getting the Gentoo compressed filesystem to work reliably on the G5 kernel. A Gentoo Livecd consists of 4 parts: a bootloader, a ramdisk, a kernel and a compressed userland. The bootloader on the livecd is responsible for loading the kernel and ramdisk into memory. The kernel then executes a script on the ramdisk that bootstraps the compressed filesystem and performs a pivot_root into it.

Loop mounting a compressed filesystem was something that was too alpha to be included in the first beta, we implemented compressed loop support in 2004.1 I believe. In 2004.2 we switched to squashfs2 because that made some things easier on the 64bit side of things.

That clap of thunder was half my readers simultaneously clicking away when they got to terms like 'pivot_root', 'loop-mounting' and 'squashfs2'. There's nothing wrong with a good google, but could you give us an cursory idea of what these are and why they're good things™?

Sure, I'll try :-) If you look at our latest livecd, you'll see that on the cd there is a file called 'livecd.squashfs'. This 600 Megabyte file contains a compressed 2.1 Gigabyte read-only filesystem. The filesystem is compressed using the squashfs tools.

The cool thing about squashfs is that you can mount the compressed files and just use them as a (albeit read-only) filesystem. Mounting a file instead of a device is called loop-mounting.

So, when you boot from one of our livecds, the CDs' bootloader loads a really small linux operating system into memory, containing just enough instructions to 'loop-mount' that livecd.squashfs file and prepare it for the next step in the process called 'pivot_root'.

We want the user to be able to use all those window managers, multimedia applications, developer tools, etc. inside the newly mounted squashfs compressed filesystem, instead of just the tools in the mini-operating system used to loop-mount the squashfs compressed filesystem. We call the technique that does this 'pivot-root'.

So you get Gentoo booting on the G5, and find Apple has raised the bar on you in terms of thermal management because your nine software-controlled fans are constantly running at 100%. How do you begin rolling in support for something like that?

As a software distributor one continuously monitors the work of upstream ppc kernel developers such as Benjamin Herrenschmidt (benh) and Linus Torvalds.

Once you've managed to install linux on the G5, you start testing newer kernels, see how they behave thermal-management-wise and feed new issues back to the kernel developers.

Using Linux on Apple hardware seems to come with some special challenges. NVIDIA, as an example, hands their source to Apple who is then responsible for their own drivers. You don't have the same luxury, and things like Airport Extreme support still seem to be an open-ended question. Is this a situation you see improving or getting worse?

Although most of the PowerPC hardware (Bluetooth, 802.11b, video drivers, etc.) is supported under Linux, 3D video drivers and 802.11g are a bit problematic, since the hardware manufacturers are reluctant to release programming specifications.

We're hoping this situation improves.

Short of a march on Cupertino, what would it take for the situation to improve?

Getting Airport Extreme to work under Linux would require Broadcom to release specs, so people can start engineering drivers. Most 3D video driver manufacturers already build binary drivers for x86-linux.

If we can provide those companies with some incentives to release PPC drivers or just release specs to knowledgeable people, that would be cool.

It would appear the Gentoo PPC team is having to deal with two separate gaps: Old-World versus New-World, and 32-bit versus 64-bit. Are you having to prioritize your efforts on one or the other?

Not particularly.

PPC32 and PPC64 live happily next to each other within the PowerPC scope, and we share resources such as manpower and development machines. I currently run a PPC64 kernel with a PPC32 userland on my 64-bit enabled machines. I have a few PPC64 chroots set up for development.

I work on things mostly from a release engineering perspective: For PPC64 I did some work getting the first PPC64 livecd to boot on G5. Most of the time however, I work on PPC32 specific aspects since the biggest part of our userbase is still on G3, G4, or 32bit G5. Tom Gall does an excellent job on PPC64 meanwhile :-)

Both PPC32 and PPC64 will combine forces somewhere after 2004.3 to work on bi-arch toolchains.

Regarding oldword support, we have a few development machines set up for release engineering purposes, but I'd characterize our support as experimental. Especially since we lack people to continuously test things on 604 cpus. PPC32s main target audience are G3/G4/G5 users, while PPC64 has a bit wider scope.

It's worth noting that PowerPC isn't limited to Apple hardware; IBM offers different flavors of 32-bit and 64-bit PPC hardware, and smaller companies seem to be trying to get some efforts underway. Have you noticed appreciable interest for Gentoo on non-Apple PPC hardware?

Absolutely, Gentoo is extremely popular on Pegasos. There are requests for CHRP and PREP 32bit support, which should be integrated by 2004.3.

PPC64 and PPC32 focus on various markets ranging from embedded to high-end IBM POWER5 machines.

Some of images from the press release that caused the flap...

"Apple, we have a problem, Larry evolved into a Tigercow" was a play on Apple's own "Redmond, we have a problem" theme at WWDC.

I'm not sure where Apple wants to take Package management, there seems to be lots of conflicting information floating around. Anyway, I think we were noticed. :-)

We'll say "Hi Jordan" a few more times this year, when he gets back from Hawaii, rewriting the dependency engine for Darwinports.

Why did you choose to call it Gentoo MacOS instead of Portage OSX or something similar? Is this a sign of moving away from 'Gentoo' as a distro brand, with Gentoo becoming synonymous with Portage?

Gentoo is a metadistribution. A metadistribution defines and distributes knowledge about specific concepts and domains related to Operating Systems. From that knowledge a few distributions can be built in different flavors, completely customized for the user: Gentoo/Linux, Gentoo/Hurd, Gentoo/BSD...

You said it yourself: Gentoo is more/less synonymous with Portage. In our new Social Contract we do intend to make a difference between (self hosted) Operating Systems and just regular Gentoo projects.

Gentoo MacOS seemed to hit a little later than expected; were the technical challenges greater than anticipated, or were there other causes?

The biggest cause for this delay was that we wanted to 'overdo' stuff. At one moment in time we were implementing GoboLinux filesystem compliance in our Portage to allow for something as simple as prefixed installs under Mac OS X.

Taking a step back and clearing up ones mind is often a good way to get things going again.

Some would consider Portage to be the crown jewels of Gentoo Linux; by 'giving it' to OSX you are giving up one of the main reasons why someone using OSX might want to look into installing Gentoo Linux PPC. Are you diluting Gentoo Linux's value by porting Portage to OSX?

No, on the contrary. If different plaforms on different architectures were built using the same knowledge base, that means each platform knows stuff about the other platform and can go make assumptions.

For instance, assume one wants to set up different Linux machines on a network that serve as Xcode cluster nodes for the upcoming Tiger Operating System. If your knowledge base contains declarations about the Tiger toolchain, your Linux system could go build one that closely resembles it, providing the same functionality.

Porting Linux stuff to alternative platforms is not exactly that new either for Linux Projects. After all, Fink uses Debian's apt-get, but Cygwin is a Redhat project.

What is so unique about this is that we use one big knowledge base. We currently have a few hundred apps ported to MacOS, but a user can go test stuff and just report things as working. There's no need to reinvent the wheel each time we want to port an app to a different platform.

Some snapshots of the current Gentoo MacOS installer, and upcoming Preference Pane integration

Apple supplied packages and Gentoo Portage don't exclude each other. We're working on pkg receipt scanning, somewhat related to the topic of injection:

When a user injects a package, a user says a package is installed by a third party. For instance, on Panther one declares bash-2.05b is installed. Whenever a package depends on bash, the dependency will be satisfied by the bash provided by Apple.

The old syntax for injections was:

emerge --inject <functionality>

In the newest portage, we switched to a 'package.provided' file. Everything that file contains, is supposed to be provided by the system. Our Mac OS X profiles come with a default package.provided. It would be relatively simple to provide a mapping between the receipts for installed pkg files and our own package.provided.

But don't worry, files don't get overwritten, portage only touches files it installed itself (Collision Protection). And it only 'extends' Mac OS X functionality by default. You have to explicitly specify you know what you're doing if you want to go remerge the Mac OS X kernel for instance.

You also announced that native OSX applications, not just unix packages, could be converted and distributed as an ebuild through Gentoo MacOS. The idea of being able to type a command and have say, the newest version of AdiumX or Desktop Manager updated not only on your machine but then pushed out and updated across your entire network certainly turned some heads. How difficult is it to create an ebuild from a native app, and are there limitations?

Yes, if we were allowed, you'd be able to build your own Mac OS X from scratch entirely. However, that is sadly not the case right now. Currently we focus on our ability to build the open source part (The Darwin base) from scratch and we provide ebuilds for free software that links against Apple software we can't provide ourselves (We do provide 'virtual' counterparts).

Creating an ebuild yourself is really simple. We have lots of high-quality documentation. Sadly, Xcode can not export to Makefiles, but we are working on an 'xcode.eclass' that will allow you to use Xcode specific syntax in your ebuilds. We are also looking into Xcode to makefile conversion software ourselves, since Xcode is great but may not always be available.

Does that mean that in the future, Xcode will not always have to be installed to use Gentoo MacOS?

That is one of our longer term goals, yes. We're working on our own Gentoo/Darwin support. Some aspects of OpenDarwin currently depend on things from Mac OS X, like Xcode.

We will not only start contributing on getting OpenDarwin self-hosting, but also on things like security bugfixing, since we already have excellent security announcement infrastructure in place to support this. Portage has been made security announcement aware, and knows when to update something if there was a security announcement.

As you mentioned your project is growing in leaps and bounds, to the point where the Gentoo MacOS team is outnumbering the Gentoo Linux PPC team. When a project is this young and growing this quickly, how do you end up not spending all your time training new developers?

We had about 50.000 downloads the first 48 hours and have received tons of new ebuilds and patches that will be reviewed and committed over the next weeks.

We currently have 22 developers. 6 of them were junior devs that required mentorship. Good time management is obviously a requirement for a top level managerial function. In this case those six people were trained by two mentors in about six weeks. So yes, we floored the throttle a bit.

Let's say a kid is reading this on his shiny new iBook and gets inspired. He/she wants to help start testing packages and working their way up. What skill set do you expect them to bring to have?

The best place to start is bugs.gentoo.org. Query for Mac OS X bugs and start contributing patches. Also, our documentation team is always looking for excellent documentation writers.

Join the mailing lists, as often good ideas float around but don't get translated into code. Coding something is the best way to get noticed. We're also looking for people with Xcode skills to help out on building a next generation package management tool and help create prefpanes for most big packages we provide.

By building from source with the appropriate flags, one is hopefully able to avoid egregious performance killers like using a binary built for the G4 on a G5. But a package being available for a platform and a package being optimized for that platform are two wildly different things. How much time are you able to give to things like AltiVec enhancements in ported packages?

Just like we did with the G5 on Linux, we will first focus on getting stuff to work with generic flags. We can and will focus on more advanced stuff like testing out cflag combinations, (creating our own) experimental compilers, optimizing things, etc....

Obviously users can test out Altivec, optimized cflags, compilers, etc., and then report back to us through bugs.gentoo.org.

Is the lack of being able to devote effort to those optimizations (relative to X86) a real issue in your mind, or something performance junkies blow out of proportion?

Actually, work on pushing altivec-optimized applications to the next level is about to start.

As you may have read in the Gentoo Weekly newsletter, the PPC team had their first real-life meeting at Kransberg castle, Germany. About half of our team was able to attend the Freescale conference in Frankfurt.

An interesting note in your personal history, and that of Gentoo, is that you're both founding members of the metapkg initiative that was announced a good while ago between DarwinPorts, Fink and Gentoo... and then things got really quiet. Is this still alive?

Heh. Well, it took us a while to get Gentoo going on Mac OS X, and by the time we were ready...

I still think MetaPkg is a good initiative. It is important that we try to reduce work duplication and coordinate if only for things like Security Announcements. MetaPkg really has a lot of potential, it's probably a good time to start doing something with it.

You've spent a lot of personal effort in the area of distributed compilation and cross-compilation, even going so far as to write your own implementation of ZeroConf. Going forward, what do you think are the current hurdles facing this model?

I didn't write all of it myself, I finished one specific aspect and wrote a few example scripts that illustrated its usage.

One of the scripts could for instance parse the info Xcode sends out over RendezVous about the toolchain. The script in its current form can be used to announce various things like a webserver or a printing service on a linux machine. Just like mod_rendezvous, but in the form of a script.

Regarding cross-compilation there are quite a few package management related issues. Having one knowledge base in which you declare things about toolchains, etc. is a first step in the right direction. Also, setting up cross-compile toolchains needs to be automated (ebuilds...).

Even more difficult is the actual impact on package management. On Linux, KDE depends on ALSA (Advanced Linux Sound Architecture). However, if we're compiling KDE for let's say SeDarwin, then we shouldn't go compiling ALSA, even though the host we run our package manager on is a Linux host.

You've recently started work on Portage-ng, focusing on modularizing Portage and furthering the idea of MetaDistributions. What are some of the major challenges facing Portage and other package-mangagement solutions, and how will MetaDistributions potentially help?

Portage-ng is what Gentoo will label the package management engine after some of the current, hard to solve, open issues are solved. I'd personally like to merge the results of my Msc. thesis into its core.

Some of the challenges portage faces are (illustrated using examples):

• Dependencies on component "options"
• Better 'logic' support
• User Mode Emerge + Pathspec (Prefixed installs like /sw or /opt/darwinports)
• Negation as failure
• Portage management of UID/GID. (Dependencies on Users and Groups)
• Suggestion of alternatives (multiple packages providing the same virtual).
• Automatic Reverse dependency rebuild.
• Even if aborted, portage should leaves system in working state.
• Packages watching each other.
• ...lots more

Anyway, there's a lot of work.

There is no way I am letting you smack my readers over the head with that level of Geekery after they've made it through the whole chat. :) Could you pick one of the above that has you the most excited in terms of potential, and explain it's grabbed your attention?

One of the most exiting new features is User Mode Emerge, which will allow one to install applications in the users home directory, without the need for root privileges.

Doing this requires a separating the 'planning' aspect of portage from the 'executing the plan' aspect. This feature is also closely related to a feature called 'PathSpec', also known as the ability to do prefixed installs like '/opt/gentoo'.

Even though Gentoo for MacOS currently is smart enough to avoid touching files it didn't install itself, we would like to allow people to have both Apple and Gentoo libraries and apps installed at the same time.

In the spirit of the site, what's your spirit of choice?

Belgium is well know for it's beers :-) One of my favorites is 'Kriek', but Palm and Duvel are great too. If you're visiting belgium, make sure to taste them :-)

 Posted by drunkenbatman
    October 03, 2004, at 09:02 AM