Posted
by
Zonk
on Tuesday February 12, 2008 @11:41AM
from the going-back-in-time dept.

Technical Writing Geek writes "The Haiku project, which began shortly after the death of BeOS in 2001, aims to bring together the technical advantages of BeOS and the freedom of open source. 'The project has drawn dozens of contributors who have written over seven million lines of code. Although Haiku is nearly feature-complete, there are still numerous bugs that must be fixed before it is ready for day-to-day use. The design principles behind Haiku are very closely aligned with those of BeOS. The central goal of the Haiku project is to create an operating system that is ideally suited for use on the desktop--this differs significantly from Linux and other open-source operating systems which are intended for use in a diverse range of settings including server and embedded environments.'"

Haiku is a ground-up rewrite of BeOS. The only thing shared between the two is the general design and the support for BeOS R5 applications. Haiku addresses many of the shortcomings in BeOS R5 (e.g. better POSIX compliance). I'm sure they are considering security as well.

Actually there is a fairly substantial legacy issue associated with BeOS/Haiku, but not in the way you are thinking. The ABI [wikipedia.org] used by BeOS is not supported in GCC anymore. Haiku Release 1 is striving for binary-compatibility with BeOS. What this means is that if you want to run original BeOS applications, it can only be compiled against GCC version 2.x. Haiku can be compiled against later versions of GCC, but you will lose the ability to run older software unless it's recompiled for Haiku, which may be impossible if it's closed source.

there were other legacy issues with modern hardware that existed with BeOS as a result of having died so young, but these don't exist with Haiku.

When you say a ground up rewrite, I worry. This is because the real-time nature of the OS is something that none of the other "big 3" have gotten right

The kernel of Haiku is a fork of the open source NewOS kernel. It was written by Travis Geiselbrecht, who was a kernel hacker for Be, Inc. My understanding is that conceptually the kernels are similar.

I could be mistaken here, but BeOS was never label by the company as a 'real-time' OS. They described it as a true multimedia OS which translates into a highly responsive OS to the users input. Big difference.

What I want is a computer where the "OS" is just a virtual PC launcher. I would have multiple OS installs on scaled down "OS" virtual drives and then a common (shared) "user" drive that consumes the rest of the available space. An OS wouldn't be shutdown or started, it would just be resumed (and in the case of Microsoft, reset occassionally). And the virtual environment would have a set of drivers for my hardware so that my virtual PC's could use full 3D rendering and sound and whatever else I stick in that box.

God, that was really unclear. OK, first of all if the OS is compiled with GCC v.2.x so that you get binary compatibility with BeOS, that means that ALL software for your system has to be compiled against GCC v2.x. With regards to "legacy modern hardware," what I meant was that BeOS just plain doesn't run on many hardware that came after Be died, because of incompatibilities in the kernel. BeOS Max Edition is an unofficial "distribution" of the free "personal" version of BeOS which includes some binary kernel patches to allow BeOS to run on more modern hardware. Of course Haiku is open source, so it does not suffer from this limitation because it can just be patched and recompiled.

Lack of drivers will be an issue with both platforms, but the intent is that there will be driver compatibility between BeOS and Haiku, of course. AFAIK this mostly works. Additionally, both OSS sound and FreeBSD drivers can be recompiled and used in Haiku, so you get all that hardware support in Haiku that never existed in BeOS.

in 1997 Beos could run multiple videos in real time and remain responsive to the user. This was back when playing one video on windows or quicktime introduced dramatic slow downs on the same hardware.

Beos originally had a database file system that MSFT has been trying to duplicate since. BeOS had a local file search in 1997 that would rival OS X 10.4 or Windows Vista.

they were a decade ahead of their time, and got killed by MSFT because of it. Unfortunately parts of the GUI and system now are behind the others. It is a bit dated, but there are many things that can still be learned by the other OS/GUI makers.

The BeOS network "stack" was at one point modular and outside the kernel. In doing so the performance was not acceptable so it was folded in to the kernel. Someone else will have to chime in with what release this happened.

i suggest you read the output of man memlock. you clearly don't know enough about linux (or POSIX) to be making generic hand waving comments that appear to be intended to authoritative.

when you're done with memlock, check into SCHED_FIFO scheduling too. oh, and/etc/security/limits.conf while you're there. the problems with multimedia "performance" on linux are mostly distro-related: distro's do not generally ship in a way that lets ordinary users run apps that request the use of these facilities. media-centric distros (Ubuntu Studio) or overlays (Planet CCRMA) fix this.

"got killed"? Apple didn't buy them, and Microsoft encouraged VARs to not sell it pre-installed, but the simple fact is that it wasn't really valuable enough for most people to want to buy it. Windows 95, Windows 2000, linux and MacOS 9 were "good enough" for most folks across most market segments.

This I must agree with. BeOS was like an amazing concept OS or technical demo, but given that it was essentially a distant 4th (if that) in desktop market share, behind Windows, Mac, and Linux, it just didn't have the momentum it needed. Not the huge library of commercial apps that Windows had, or the trendiness that MacOS had, or the open source movement and apps that Linux had. It just ended up being a neat toy more than a useful tool.

Interesting tidbit though: from what I've read, BeOS was Apple's #1 choice as a base for what they wanted to build into Mac OS X. BeOS's CEO wanted $400 million for the company though, and Apple was only prepared to offer $100 million. So, Apple ended up buying out NeXT instead, and based OS X on that. Now OS X is a WONDERFUL platform, and that might have even bee the best choice, but I really, really wonder what MacOS X would look like today if it HAD been based on BeOS. My gut feeling is that we'd have an even nicer Macintosh operating system than we do now.

BeOS R5, the last BeOS release by Be inc still had the network stack in user space. There was an in-house development version that had networking in the kernel, but this never made it into a commercial release because Be went bankrupt. This version was at one point leaked onto the internet, though.

Zeta [zeta-os.com], which is based on the original BeOS binaries and/or source code has the network stack integrated in the kernel.

As an example to all, I'll fire up qemu this afternoon and install haiku on my trusty old thinkpad. If 100./'ers did it and provided feedback to the project, it's a benefit to all.

Very true, though I recommend using VMware's free VMware Player [vmware.com] instead of qemu. It's available on both Windows & Linux and performs about a million times better (for running Haiku, at least).

I've tried Haiku on a virtual machine and I must say it's pretty cool. If you are thinking about trying it yourself, beware, it doesn't come with a web browser installed. You can download one as well as various other programs at Haikuware.com [haikuware.com]. If you want a version that has everything pre-installed try the weekly superpack [haikuware.com].

Let's not whitewash the past. Microsoft used it's monopoly position to strong arm VARs into not selling it pre-installed with Windows. MS stated clearly that the VARs had to either stop pre-installing BeOS with Windows or had to pay retail for Windows, which would have been a death sentence for any VAR distributing BeOS.

That was the basis for one of the anti-trust lawsuits filed against Microsoft.

Well, if you want to get technical about it, haikus are set as 5-7-5 mora, not syllables. They are different. In fact, I would argue that most English haiku fail because they should be even shorter than 5-7-5 syllables. One great thing about haiku is that Japanese words have a lot of syllables, relatively speaking, making haiku short, with very dense meaning. English has a great number of monosyllabic words, making writing pleasant English haiku easier than composing Japanese haiku. Furthermore, Japanese haiku typically are two phrases in length, either of the form PHRASE_ONE//PHRASE//TWO or PHRASE//ONE//PHRASE_TWO.

Beyond that, haiku must have a seasonal word in them; otherwise, it probably is a senryu [wikipedia.org] instead.

There's also frequently a "turn" that takes the first couple lines and resolves it in a different way. Let us glance briefly at one of Basho's most famous haiku, translated:

will you turn toward me?I am lonely too,this autumn nightfall

Here, we have two phrases (one of a line, and one of two lines). We also have the "turn," in that it is two lines of loneliness, and then resolves, surprisingly, to a statement about the weather. "Surprising" is not the right word, I know. Finally, the entire haiku is sublime, and contains the season word (kigo).

One final thing: Basho was famous for saying, "Learn the rules; then forget them."

My guess is "Grammar Taiyokuin." That was an attempt at "Grammar Member of the Imperial Rule Assistance Association [wikipedia.org]," but my understanding of Japanese politics/history is not up to snuff.

I'm not an authority on the subject, but I've always thought the best way to translate the requite for 5-7-5 moras (that's the plural of "mora", unless you want to get classical and say "moræ"—it's a Latin word, not Japanese) is with 5-7-5 stressed syllables. That's traditionally how entity-counting is done in English poetry: For instance, Old English poetry had four stressed syllables per line (with a variable number of unstressed syllables), whereas in Shakespeare's iambic pentameter, there's five feet of unstressed-stressed pairs per line.

This makes logical sense, because in Japanese, each mora has approximately the same length of time when spoken, whereas in English, there's approximately the same length of time from stressed syllable to stressed syllable (hence, if the stressed syllable is long, nearby unstressed syllables will be even shorter; but if the stressed syllable is short, nearby unstresssed syllables will be comparatively longer; and if there's a lot of unstressed syllables in a word, the stressed syllable will be shorter than if there's none at all).

It would of course make English haikus even longer, but they will end up sounding more poetic to English ears.

I'd say that if you look back at OS history then, it's clear why Apple went with Next.

BeOS had a lot of buzz and a lot of attention from the media producing world, and in fact, that's where it actually made the most real impact: Level Control Systems was selling a BeOS-based theatre system that actually ran some Broadway and Vegas productions for years, Tascam made a multitrack recording system based on it, Steinberg ported their "Nuendo" system to it, etc. And that's why a lot of people thought it made more sense for Apple to start with it than Next, which was known mostly for their dazzling development environment and deployment through a few large organizations. But Gil Amelio, Apple's CEO at the time, was obsessed with getting into the "enterprise" market. BeOS on the cheap would have been fine, but not at the price Be's CEO was asking -- which was around $250 million, IIRC, not the $400M that someone else mentioned. As it turned out, Amelio paid over $400M for Next, because the "enterprise credibility" he thought they had was that important to him.

At the time, I thought Apple hadn't made the right choice, but in retrospect, bringing Steve Jobs back to the company has almost certainly put them in a much stronger position a decade later than they'd have ever gotten under Amelio. From a purely technical standpoint, BeOS would have been at least as strong a foundation. (It had its share of technical problems, but if it had kept being developed by a team the size of the current OS X team, for another ten years, it's reasonable to assume those would have long since been solved.)

Despite having various servers for large areas of the operating system it can't really be called a microkernel. A microkernel will have (as close as possible) to the bare minimum of functionality to get and keep a machine running safely; see L4, etc. As another poster commented, BeOS included drivers, filesystems, and even started moving networking _into_ kernel land (with the BONE system which was released in a final form). A modular kernel, yes. A microkernel, no.

Now, there's quite a few features that AmigaDOS lacked that we would consider essential in this day and age. That would add to the bloat as well.
a) Printing. I think printers are terrible and foolish but some people can't live without them and have to have that paper copy. Does anyone remember the hype of computers bringing the paperless office? That was a few billion trees ago!

The printing support is there; it's just not particularly advanced. There are/were commercial packages to correct that, though.

b) Scalable Fonts. Amiga DOS had nothing like True Type

Not true. You probably used your Amiga back in the AmigaOS 1.x days? The later AmigaOS versions incorporated support for the scalable CompuGraphic fonts, licensed from Agfa. There are/were also add-on libraries to deal with PostScript and TrueType fonts.

c) Clear Type, font anti aliasing, scaling, etc. Amiga just had bitmap fonts. Fonts were blitted over and that was that.

Again, that bit about scalability and bitmap fonts is just not true. (Subpixel antialiasing support [and font antialiasing support in general] might be lacking, I give you that.)

d) 3d graphics.

Depends on what you mean by that.

e) Better sound. Amiga's 4 channel 8 bit sound would a bit dated by today's standard. Although, I loved how easy it was to program.

There are/were add-on sound cards. Even the built-in sound hardware can be manipulated to output 14-bit audio, although that's a bit of a hack.
The existing Amiga hardware is dated and obsolete (I mean, what would you expect from a hardware platform whose active development stopped in 1994?) and the OS lacks features, abstractions and protections that would be expected and needed in the modern world, but issues you complain about seem to be a bit off... either fixed already 15 years ago, or easily fixable, if there was a modern platform on which to run the OS. The deepest design issue with AmigaOS is the lack of memory protection: any app can crash the system the hard way. There is no easy way to fix that, expect by creating some sort of sandbox/emulator/virtual machine for the old apps and requiring new apps to be written by new rules.
But it's all fairly academic now. AmigaOS could have been brought up-to-date, just like Windows 3.x and the original MacOS were, had there been constant development and revisions over all these years... but where's the incentive to do that now? If someone wants a new, modern AmigaOS, it's easier to write such a system from scratch - borrowing only the good features and ideas from the "old" AmigaOS - than build it upon the old API and libraries.

Well, the Color Macintosh was created after Steve Jobs left, so it wasn't him that told them not to produce a color Mac. After all, Steve left about 1985 or 1986. From what I understand about BeOS, the idea was that, by creating an entirely new OS, they could create a light and fast OS that wouldn't be encumbered by backwards compatibility. Apple borrowed this idea/philosophy while they were working on Copeland and when they purchased NeXT, except that, instead of eliminating backwards compatibility entirely, they created a special environment, which allowed them to cut old code out of the OS.

The dependency on the C++ ABI was one of the strangest things about BeOS. Having to recompile all of your applications for incremental OS releases is a real drag for third-party developers.

Except, that never happened. Be employed people who actually new a thing or two about C++ and as a result, they were able to maintain the ABI across versions. In fact, it's quite simple. The biggest worry is the fragile base class problem, and if you look around on the intertubes you'll find a short paper written by a Be engineer that explains how they handle it. If you take a look at Haiku you'll see it in action. If you take a look at Syllable you'll see another way of handling it (they use a more sophisticated inner class encapsulation and reserved vtable slots).