BNX? Sven Jörg Talks About Merging BeOS & QNX

In the last few years, BeOS fans have witnessed the beginning of what some say is a renaissance for the beleaguered operating system. Haiku, an open source re-implementation of BeOS based on a kernel by a former BeOS developer, and Zeta, based on official Be source code taken over by German firm yellowTab, are the two projects on which many place their hopes for a BeOS revival.

And then there's the focus of today's interview with Sven Jörg — BNX, a mating of Haiku's open source BeOS servers with a specially-licensed, real-time kernel from QNX Software Systems. Jörg, lead developer of the project, talks with us today about his team's unique approach to their BeOS successor. I corresponded with Sven over the course of several weeks regarding what led the BNX team to their idea and how they will implement it in the near future.

1. Why the need for another BeOS? With Haiku and Zeta, haven't all the bases been covered?

Sven: Some might be happy to accept that. But those two other approaches have some serious drawbacks. Haiku is working on recreating an operating system that at this point over six years without an update. By the time they have something to fully replace BeOS 5, it'll be ten-year-old technology. When it's done, it'll be like 2000 all over again. In 2010. You might be able to use it to run old BeOS apps for nostalgia, but that's about it.

With Zeta, yellowTab are amending the BeOS API to make it more modern, but as hardware is changing so much so quickly today, they must devote a lot of resources to getting Zeta working with USB 2, FireWire, multiple cores, 64-bit, etc. Zeta takes the same small/efficient approach BeOS did, and it's farther ahead than Haiku is, but it still has the same basic problem: They are a long way from what we consider modern hardware and operating system concepts in 2006.

2. What is the ultimate goal of the BNX project?

Sven: Our goal, simply, is to create a bleeding-edge BeOS that can be used for high-end production. We want BNX to be a Media OS today, like BeOS was in the late Nineties.

3. What has changed that you must address in BNX in order to be a modern Media OS?

Sven: Two things. What an OS is expected to do, and the hardware it is expected to support.

Six years ago MP3 was coming into its own. Video-on-demand was also in its infancy. Now we have ways to manage tens of thousands of MP3s with just a few clicks and we're right on the verge of video-on-demand being ubiquitous. There's simply no BeOS solution to do anything like that. The Web has become richer and more complex, and has crept into the rest of the OS. Graphics standards have shot ahead as well. Everything is richer and offers more functionality.

As far as hardware goes, What was yesterday's high-end server or graphics workstation is now on the desktop and today's high end workstation includes 64-bit, four or more gigs of memory, two or more cores, larger and faster cache memory, real-time video encoding, etc. And here we have BeOS still choking on half a gig of RAM. This is the first thing that needs addressed in order to truly bring BeOS ahead to current times — modern hardware support.

4. How do you intend to take care of the hardware support problem without being bogged down in it like you say the other two BeOS projects are?

Sven: We asked which part of the OS that had to be upgraded in order to take advantage of these things, and that was the kernel. From that realization, we agreed that recreating it would take too long, as with Haiku. Licensing the actual BeOS kernel wasn't an option but still would have left us with too much work to do. So we began shopping for kernels.

5. What different options did you look at?

We looked at Linux first, of course, because it's everywhere nowadays. And we we weren't satisfied with what we found. Linux takes a very sturdy, monolithic approach. It's so sturdy and monolithic, in fact, that it's just plain bloated.

6. What about the real-time extensions to the Linux kernel that have received so much attention in the last year or so? Did you look at those?

Sven: Real-time Linux extensions are basically hacks. You can't expect it to be as good a product built to be real-time. Go with something built from the ground up to perform a certain way rather than a poorly kludged mess. This was the route the BlueEyedOS project had taken years ago. And looking to that project today, it is a footnote. Linux sucks.

7. Were there any other options worth noting before you settled on QNX Neutrino?

Sven: We looked at almost every popular Open Source kernel as well as a few commercial ones. None of them made sense, either because of their capabilities and performance or their licensing programs and prices.

8. So what was it about QNX that seemed right?

Sven: Adolf, one of the other BNX developers, dual-booted QNX for several years and had a lot good to say about it. And from there it was pretty simple. They have a proven track record and they aggressively support the latest hardware. Since they have a microkernel, you can choose which parts of the OS to license and which to leave out. We could just take the kernel and let QNX take care of the hardware while we focused on moving the BeOS API ahead.

9. So what parts go where? Are you licensing the whole QNX shebang?

Sven: No. All we want from them is their kernel. We'll throw Haiku's servers on top of it. In this manner, we get the tight fast kernel that supports new hardware innovations and the free time to work on the API of the system. We're also looking at taking some parts from elsewhere, like the TCP/IP stack from FreeBSD and and the XFS file system from IRIX. We will take whatever will give the BeOS API the best advantage, even if it means going beyond BeOS itself.

10. Where is the project now? What are your near-term goals for BNX?

Sven: We are running QNX Momentics 6.3 SP2 as our development platform and, thanks to QNX's modular design, are getting different parts going. While we test parts for our OS, the whole QNX OS is already there working. So for instance we can just fire up the TCP/IP stack and test it. Moving to XFS is another goal, a bit trickier but so far it still seems feasible. Before we do anything else, we want filesystem and networking support on top of our kernel. From there we will get Haiku's BeOS servers running, and that will take some work. They have to be modified to work with Neutrino and our new file system and networking stack. After that, it's pretty much all in place.

11. To get it down to a number, when do you expect to be able to run BeOS apps?

Sven: Within a year from now.

12. A year? That's a fairly short amount of time compared to the other projects.

Sven: We'll spend a year getting things together and still end up just about where the others are in terms of functionality. That's thanks to using Haiku and Neutrino. We can focus on sewing it all together rather than recreating anything.

13. What were the licensing terms with QNX Software Systems?

Sven: We aren't allowed to comment on any of the figures or stipulations involved, but I can say that their contract with us was very generous. It went a long way to making our decision with QNX final. :)

14. Do you find it ironic that many saw BeOS and QNX as rivals at one point and now you're dependent on one to realize the other?

Sven: There aren't really any feelings involved except the desire for a working BeOS successor.

As for the rivalry, I think it was misplaced. BeOS was a Media OS, and QNX was an embedded OS. While there are many common things between the two, they were targeted at different places. QNX only ran on the desktop as a development environment for itself anyways. BeOS ran laps around that incarnation of it.

15. What kind of PC will I need to run BNX?

Sven: You can get by well with a 1 gig Pentium III and half a gig of RAM, though BNX will in theory run on anything the Intel QNX Momentics system would run on, from Pentiums on up. Adolf is on a 450 MHz Pentium II system with 512 MB RAM while I use a 2.8 GHz Pentium 4 with a gig of RAM. It will depend on what you want out of the system, really, that will dictate hardware requirements. The newer the better though. We're about to get a Core Duo system to develop on.

16. And what's the current status of the BNX project page at SourceForge?

Sven: Another project had the BNX name already, but since it was inactive, we took it over. Unfortunately that process takes about two or three weeks to complete. So we have our page, we're just waiting for it to activate.

17. Thanks for taking the time to talk with us, Sven, and best of luck on the project.

Sven: Thank you, Grant.

Leopard to be "Invisible OS?"

Sources close to Leopard development are starting to report that the new OS, set to debut in late '06 or early '07, is gearing up to be a graphics powerhouse unlike any Mac OS before it. Continuing Apple's use of increasingly powerful GPUs, Leopard will offload even more graphical tasks to current and next-generation graphics hardware. Currently in testing are some new system-wide graphics options Leopard developers are calling Invisible OS.

So far, here's what we know:

• Full-screen mode — Think maximization plus Exposé. Full-screen mode is a way to make one window take the entire screen, effectively making Mac OS X a one-trick pony while engaged. In full-screen mode, the menu-bar becomes an extra layer below the window in question's title-bar, and everything else just disappears. No Dock, no Apple menu, nothing else but the window you're working in. This feature might be the beginning of the long-rumored Mac OS X kiosk mode for use in commercial and industrial applications. Reportedly, Apple is still working out the specifics for drawers and windowlets while in full-screen mode.
• Menu and window opacity — Leopard will allow you to adjust drop-down menus to be anywhere from totally solid to completely clear, leaving only what you're working on visible. Likewise with title-bars and side-bars — only the title and close/minimize/maximize buttons and the scroll-bar remain.
• Quartz 2D Extreme — Included but disabled in Tiger, this feature will be enabled by default in Leopard. Previously dependent on Shader 2.0, Leopard's implementation of Q2DE will support Shader 2.1. And performance is said to be astounding. For an idea of how much faster, Xbench graphics scores tripled on my dual 2 gig G5, said one source.
• Resolution independence — This feature is present in Tiger using Xcode 2. Leopard will have full support for the feature. Some options will be Mac (72dpi), Windows (100dpi), and Desktop Publishing (300dpi). Other resolutions will be available as well. Applications may need updated to support the feature properly, but sources say it's a trivial matter and that Mac OS X itself will make most everything just work.
• Screen saver backgrounds — The user will be able to choose a screen saver to run as their desktop background. This includes all of the current screen savers as well as a few new ones, such as a live graphical RSS feeed, system resources bars and graphs, and even iTunes visualizer.
• System-wide ripple effect — Just like Dashboard! When a window appears on-screen, it ripples for a few seconds. There's also an option for an application window to ripple when it needs attention, but sources say this likely won't be included in the final release of Leopard.

Apple is also reportedly trying video encoding on newer GPUs, as well as tweaking the virtual memory system to work better with graphics hardware. The results are impressive so far, though the cost may not be practical. Further Leopard development will tell.

It looks like Apple is taking full advantage of its 18-month development cycle with Leopard. There's still almost a full year to go yet, and new features are already starting to look good. This is as about exciting as it gets. While Microsoft releases its shoddy copy of Tiger in 2007, Apple will leapfrog the Redmond giant once again. The Mac community waits eagerly to see the invisible operating system. (Pun fully intended.)

Stay tuned to Trollaxor for future Leopard reports!

Eight-Core Mac Pro

The excitement at 1 Infinite Loop continues to grow over the Intel-based Power Mac replacement, code-named Hydra after the eight-headed serpent from Greek mythology. Since the iMac and mini have gone Intel, more resources are being devoted to the project. Beta testing of the systems should begin some time in May or June, and most sources predict their debut some time in September or October.

And from what we've been hearing, it'll be well worth the wait.

First and foremost, Hydra will feature two, four, or eight cores, twice the number featured in the current Power Mac G5 Quad. Testing units currently employ one, two, or four Core Duo chips, though sources suggested that Apple will eventually use four-core processors when they became available. Test units are currently running two 2.0, four 2.0, and eight 2.16 GHz configurations, all on 667 MHz busses.

Memory capacity will remain the same as current Power Macs, but with support for the faster RAM found in the new Intel Macs, for up to 16 GB 667 MHz DDR2 SDRAM. Sources say all test units have had 1 GB of memory, and that Apple may opt for a minimum gigabyte once the system goes on sale sometime later this year.

Performance reports are positive across the board. One reviewer said his four-core system felt faster than the G5 Quad by a factor of two, while other testers say improvements are in line with new MacBook Pro and iMac figures. And this is just for the current chips — Conroe, the next major Intel desktop chip, doubles the L2 cache and finally catches up with DDR2 SDRAM performance, as well as upping the clock speed.

Other notes on Hydra include built-in Bluetooth, AirPort Extreme, and SuperDrive, up to 1.25 terabyte of SATA storage, 64-bit support, and virtualization. We're compiling future reports as we speak, so stop back in for an update on the Mac Pro soon!