Follow-Up With Sven Jörg, BNX Project

Today we have a second interview with Sven Jorg, head developer of BNX, an implementation of Haiku on the QNX Neutrino microkernel. Since the last interview, public reactions have formed about the project and the BNX SourceForge project has gone live. We'll cover those and other topics in the talk below.

1. Grant: Hi Sven. First things first. How do you pronounce BNX?

Sven: I pronounce BNX as |binɪks|.

2. Grant: And in the IPA no less! Very good. Moving on, your SourceForge project went live. When we last talked, it was still pending approval. What was that all about?

Sven: SourceForge has a slow approval process that typically takes several days. In our case, however, another project was using the BNX name. Since it was inactive, we requested to take over the name. At this point Eric S. Raymond stepped in and told us that unless we used the Linux kernel, he would prevent our use of the BNX name on SourceForge. He was holding our project name hostage. We had to appeal to higher-ups at SourceForge and they eventually approved our request. So, finally, our SourceForge project is up and running.

3. Grant: I never knew Mr. Raymond took such a particular interest in what software SourceForge projects used.

Sven: Nor did I. The people from SourceForge said it's been a problem lately and they're trying to get him some help.

4. Grant: I hope everything goes well for him. What else has happened with BNX since we last talked about it two months ago?

Sven: We've looked more into XFS and its performance. We've been delighted with what we've seen. We're running Haiku and have found it to be quite stable. My test system only crashed twice in an hour! But on our new box, I was up to six crashes an hour. I was very impressed. Our new system uses dual processing and performance is simply astounding. We're multi-booting BeOS 5, Haiku, QNX 6.3 and Linux 2.6.16.16 using XFS. We also have Windows XP on there for games and Windows Vista build 5381.1 just because.

5. Grant: What kind of new development system did you get?

Sven: It is truly a sweet-ass setup. It took us the last six weeks scouring eBay for the parts, but every second was worth it. Our new system has half a gig of ECC RAM, two 320 GB hard drives, a Radeon 9200 PCI graphics card, and two 200 MHz Pentium Pros with 1 MB L2 cache each. And to top it all off I overclocked the chips to 233 MHz! Linux starts up in less than two minutes! We are ready to rock and roll.

6. Grant: Wow, that's some serious hardware. But why didn't you opt for something a little newer?

Sven: Well for one we are not a rich project. It is only Adolf and I. There is no financial base for the project, just the time and skill we can muster. No one gets paid to make BNX. For two, if we are getting our clock speeds up to the 2 GHz range, that would be something like 10x the speed of the Pentium Pros, and we would be at 60 crashes per hour. How could we develop an operating system? All of our time would be spent crashing and rebooting, never getting any work done. Six crashes per hour is a workable rate — 60 is not.

7. Grant: I guess that makes sense. Now, there were some questions raised after our last interview. First, are you aware of the existence of Zinzala, a BeOS-inspired work-alike for QNX?

Sven: Yes. It was, in part, inspiration for BNX. But as far as its usefulness goes, it hasn't been updated since 2004. It was also proprietary and, most importantly, was not BeOS-compatible.

8. Grant: Do you think your projection of a year until usability is an accurate one?

Sven: Our work lies in two places: making Haiku work on Neutrino and making Neutrino and Haiku work with XFS. I think the making XFS work will take between three to six months. QNX has no problem with XFS, it's just another userspace process. We might run QNX off its own file system and Haiku on XFS, but we'd prefer to have everything on XFS. It took three years to fully integrate XFS into the Linux kernel after SGI released it under the GPL. But we have their work to go from, So about 36 months for them but only six months for us.

Getting Haiku to work with Neutrino is the real challenge, and I believe it will take nine months to make Haiku work on Neutrino. Hopefully with the work we do to Haiku's servers, they'll be kernel-agnostic and you could run them on anything.

9. Grant: So does that mean that you will be developing the Haiku servers and integrating your changes back into the project? There was some noise over that — whether you would fork or share improvements with the main project.

Sven: What we'll do is share our changes that are easy to share and let Haiku integrate what they want. I imagine a lot of our changes will only be useful in certain contexts. But they can do with it what they want. We may end up forking but we'll try to avoid that as long as possible. Haiku would be a more powerful project if they had support for more than one kernel, so they will be thanking us before long.

10. Grant: Haiku News ran an item about BNX being yet another Haiku derivative and expressed doubts about the project.

Sven: This is insecurity and jealousy. BeOS users have seen a lot of failed attempts to resurrect their favorite operating system. Haiku has every right to think they will do the best with the bits they're making. We will prove to them just what BNX can do in the future. But really, if they don't want us using their servers on another kernel, they should change their license. It's as simple as that. Don't whine about us using your code when the license you used allows us to! I just have this to say: Don't worry, be happy! You're getting Neutrino support for free!

11. Grant: Does any work with Neutrino itself have to be done?

Sven: It could be, but with how we're licensing it, it'll be a stock QNX Momentics SMP kernel with no customizations. We took this route because frankly it was cheapest for us as developers and for potential end-users. Haiku source is open; QNX is closed and any work on it would be expensive if QNX even does work like that. We never even asked if they modify their kernel for customers. We will eventually use a custom configuration for Neutrino, tuned for our priorities, which will be much different from a typical QNX install.

12. Grant: Is there anything else you would like to address today?

Sven: If there are any more concerns or questions, please contact me directly. Thanks for the interest in BNX. See you at the SourceForge!

Back to Kansas: A Look at the Fastest, Most Expandable Pre-G3 Power Macs

Remember the Power Mac 8600 and its bigger, badder brother, the 9600? You know, the beige titans based on the Kansas motherboard architecture, Apple's exclamation point to the end of the cloning era meant to outperform every previous Mac that had ever shipped? The systems that, at their fastest, would challenge their successors for months? I bought one of these beasts, a Power Mac 8600/300, in May '01 for use as a hobby system and found that, despite its age, the system was far from being a relic.

The Top End

The last of the second generation PowerPC Macs, the Kansas systems ruled Apple's high end for quite some time. Announced August 5th, 1997, this revision used a speed-bumped version of the PowerPC 604e, the Mach V. This chip ran from 250 to 350 MHz in the Kansas systems, though it eventually reached 400 MHz elsewhere. The 9600 had 12 RAM slots, enough for 768 MB at the time. It also housed a whopping six PCI slots. The 8600 was slightly less robust, with eight RAM slots and three PCI slots. Needless to say, these systems whipped Mac OS 7.6 around like a a tricycle tied to the end of an F-22 Raptor.

As more of the operating system was rewritten for PowerPC as Mac OS 7.6 gave way to Mac OS 8, these systems got even faster. The same held true when Mac OS 9 was released. The systems could also house double their original memory capacities as newer RAM chips debuted. So powerful and expandable were these systems, in fact, that Apple actually reintroduced the 9600/350 to supplement the G3 high end due to its greater expandability. Even as PCIe and PCI-X appeared there were never any other Macs with six PCI slots.

8600 vs. G3 iBooks

My primary systems in 2001 were a 300 MHz clamshell iBook and a 500 MHz Dual USB iBook. The clamshell ran Mac OS 9.2 and the Dual USB ran Mac OS X v10.0. And the 8600, running Mac OS 9.1, wailed on both of them. Of course, a lot of this was due to the chip, as the Mach V was a high-end workstation processor and the 750 was a low-end chip. But the difference was there and it was startling. Only the PowerPC G4 truly eclipsed the PowerPC 604 and 604e in Apple's high end.

	Power Mac 8600	iBook	iBook (Dual USB)
Processor	300 MHz 604e	300 MHz 750	500 MHz 750CXe
L2 Cache	1 MB (2:1)	512k (2:1)	256k (1:1)
Bus Speed	50 MHz	66 MHz	66 MHz
Max RAM	1,024 MB	320 MB	640 MB

Figure 1 Power Mac 8600, iBook, and iBook (Dual USB) compared.

The first thing I did with the 8600 was upgrade the memory to 1 GB. After turning virtual memory off, the system was the most responsive Mac I had ever used. Turning my disk cache up to a ludicrous 32 MB resulted in a Finder that seemed never to access the hard drive. For daily use the 8600's performance easily surpassed either of my iBooks, and even processor-intensive applications ran faster. The only thing the iBooks had over the 8600 was OS X, which I had just started to seriously evaluate.

Switching to OS X

I continued using the 8600 as my primary system while I adjusted to Mac OS X on my Dual USB iBook. After upgrading to Mac OS X v10.1, however, I completely switched to OS X. Musing over my switch, I recalled that Apple had developed the operating system on 604-based Macs but later reneged on its deal to support those systems and wondered if there were some way to install OS X on the G2 systems. Mac OS X officially supported the G3 or newer only, but the possibility of running Mac OS X on the 8600 was too great a temptation to abandon.

Ryan Rempel's XPostFacto, then called Unsupported X Installer, allowed for just such installations, and in no time at all I made the switch. In testament to Mac OS X's G2 heritage, it accurately reported my processor and speed. And everything just worked. I eventually updated to Mac OS X v10.1.5 and was hard-pressed to tell OS X wasn't running on a supported system. And Mac OS X loved the gig of RAM to say the least. And now, since I had overcome the one drawback to using the 8600, it became my primary system again.

No Jaguar for You

A few months later, Apple debuted Jaguar. And with the new features and optimizations in the operating system, Mac users upgraded as fast as they could. Except for G2 owners. Not long after, the XPostFacto site had the news: Jaguar would not work on PowerPC 603 and 604 systems since Apple had dropped support for the chips from Jaguar. If you wanted Jag on your G2, you had to buy a G3 or G4 upgrade card. There was no other recourse, just a new CPU or bust. Period. Finito. The end.

And so the line had been drawn for my 8600. If I wanted to move forward with Apple technology, I had to shell out for a CPU upgrade that I just didn't have the money for. Instead, I switched over full-time to my Dual USB iBook and made the 8600 a headless home server and storage system. It served that purpose well, but a few months later I mothballed it when I moved and its hard drive died while in storage. My iBook went on to run Panther and Tiger and I eventually bought a Power Mac G4 Digital Audio.

XPostFacto Comes Through

And then, just over a year ago, XPostFacto 3.1 arrived with support for Jaguar on 603 and 604 chips. The XPF forum-goers seemed happy with stability on G2 systems, and Mac OS X v10.2.8 was quite a bit more capable than v10.1.5 had been. I started looking for a new hard drive for the 8600 and fished out my Jaguar CDs, which I hadn't touched since September '03, eager to revive my sleeping giant. In the meantime, I took the tower apart and blew all the dust out, lovingly cleaning the system in anticipation of its reawakening.

But what happened on my return to Kansas is another story, for another time, in another column.