BeOS Ready for a Comeback as Zeta OS

Anil Kandangath writes "BeOS, the operating system that could have been the foundation for Mac OS X, but almost died, instead has returned as Zeta OS -- which is supposed to be fast, stable, media centric and boot within 15 seconds. Zeta is being released by yellowTAB of Germany and has applications such as an office suite and the Firefox browser bundled with it. Most BeOS applications will also run as-is. Screenshots are available." According to the NewsForge story linked there, the release could be as soon as next month.

Comments

For those who know...

[Amiga Lover]

Which would have been technically better as Apple's new OS - the nextstep based OSX, or a BeOS based OS?

Re:For those who know...

[Anonymous Coward]

BeOS was pervasively multithreaded but at the same time had incredibly expensive threads that had to be reused as much as possible in order to obtain decent performance from them. The multithreading also made creating correct software more difficult, as well as hindering debugging.

On the other hand, Mach is pretty slow, and stuffing the BSD layer into the kernel space and building everything off of it made a Mach base superfluous. Objective C is a mediocre language with expensive message dispatch, but OpenStep was a powerful platform that proved itself to be easy to develop for.

Re:For those who know...

[nate nice]

My main problem with Objective-C is it feels like Small Talk bolted on rather crudely with C. It works and I see it's purpose, but it feels like you're using 2 different languages when programming in it.

Openstep is a well designed API, if not the best ever so this makes up for the ugliness of Objective-C. However, I could not imagine using Objective-C for anything but a Cocoa program.

The dispatch is rather expensive, but having dynamic binding like it does is the reason for this. This allows for great flexibility while designing software but of course comes at an execution cost. For the OOP nuts, it's pure but I agree, they could have done things better with the language. It's definitely the Achilles heal of the whole Cocoa thing and makes you guess they will have a superior Java implementation eventually.

Re:For those who know...

[argent]

My main problem with Objective-C is it feels like Small Talk bolted on rather crudely with C.

And C++ feels like Simula bolted crudely on to C, and Java feels like C++ on Prozac, and runs like C++ on 'ludes.

The REAL problem is that C is not a good base for an OO operating system. The best OO C derivitive is Livescript/Javascript/ECMAscript, and that's because it doesn't try and retain C semantics anywhere.

Re:For those who know...

[gkitty]

Java versus Obj-C is rather a religious argument, so I would not argue that your preference is wrong given your priorities.

But for believers (and those in the know :-) obj-c is a terrific lightweight and very capable tool. The programs can be, in practice, as fast and small as C applications, yet you can still design abstract api's that easily support inheritance and polymorphism. It's not an academic argument; Obj-C has been key to the design of one of the best application development environments for 15 _years_. And I would still consider it one of the strongest choices for such development, starting clean-sheet today.

Obj-C is in the OSX kernel, and it was in the NeXT kernel a decade ago. It's in the Mac display system. You would be crazy to use Java in these circumstances.

I would not argue that Obj-C is one of the better OO languages for applications where true OO is necessary or useful. The biggest issue is that memory management is in your face, for better and for worse. There are plenty of situations where such control is useful or critical, and much as I love the convenience & safety of a garbage collector, a large gc app in my experience is hell on virtual memory, whereas it is possible to have a very light footprint with obj-c.

Your argument on the expense of the message dispatcher doesn't hold water. A message dispatch is 3x as expensive as a C function call; compared to the cost of most algorithms, it's totally in the noise. Even if it were substantial in a heavy loop, you could indirect through the message's function for a cost no higher than normal C. This is trivial though rarely useful. You're arguing for a Java implementation, where the cost will be higher even before the garbage collector takes its toll on the CPU and VM.

Objective-C is a terrific choice as a system programming language, and I would consider it a strong choice for most problems sets you would otherwise choose C or C++ for, and it wallops these for extensibility and reuse. It's a poor choice for problems where you would have a good reason to choose Java or Smalltalk.

Re:For those who know...

[rice_burners_suck]

I was really angry when Apple didn't want to use BeOS as the foundation for OSX. But BeOS by itself wasn't enough... They made mostly the right choice, except that they should have bought out Be for the code and used it in the process of making OSX, because though BeOS wasn't enough, neither was BSD. By doing that, the first version of OSX could have been where Tiger will be when it comes out, or maybe even further ahead. (Except that the user interface for much of the stuff in Tiger would still have taken a long time to create.)

Now I must say, for the record, that I am using OSX for most of my purposes now. Only the engineering stuff from work, like Autocad, Pro/E, and Mastercam, doesn't run on this thing. My boss told me that when versions of those programs become available for the Mac, the entire Windows-based network is going in the trash. This is cool, because seven years ago, when I told him to dump NT and use FreeBSD as his server system, he didn't believe that some alternative to Windows that he never heard of could get the job done at all, let alone do it better. Boy, did I prove him wrong after a while, but I had to make him a bet that if FreeBSD didn't do the job, I'd take him and his family out to dinner at his favorite restaurant, which is a very, very expensive restaurant!

Back to OSX and BeOS, though... There were a number of things about BeOS that I loved, including:

• Live filesystem. In other words, the operating system knows when it puts a file somewhere, right? So why poll for that information? BeOS has hooks that allow your software to install a "monitor" on a file or directory. When something happens to that object in the filesystem, your application receives an asynchronous message, and then you can act on it. Why is this useful? Someone else in this discussion mentioned that you could load a device driver just by dropping it in the appropriate directory, without rebooting. There are other reasons. Samba, for example, has an option that monitors the contents of a directory for changes, and acts on them. You have to set up how often to monitor. Samba has to maintain an internal list. This takes up a bunch of computer time. In BeOS, a simple line of code an a handler for the event would do the trick, and waste less computer time. This was cool. And it worked on any filesystem supported by BeOS.
• Attributes. This existed in BeOS long before any other OS had something like it. These things are showing up in OSX and Linux only recently. Attributes are programmable metadata that you can attach to a file. This turned the filesystem into a sort of database. The operating system had certain information that it would associate with files, such as their MIME type. This information was used to open the proper application for a file, instead of going by the file's extension. This could allow you to completely do away with extensions. Most of the time, I kept extensions on files anyway, because it was convenient for transferring them to and from other computers. But it was not necessary. You could also run queries on information, and save the query. The query could be accessed just like a directory, and it was "live" due to the previous feature I mentioned, which means that as things moved around the disk, or were created or deleted, that change would show up immediately in the query window.
• The OS was just so damn fast.
• It was built the way the Hurd should have been built, if it were ever built. In other words, there was the kernel, and then there were a bunch of "servers", like the input server, the network server, the window server, etc. Then, there were the "kits", or the APIs, that each server had. This meant the OS was so modular that you could conceivably remove any component and replace it with a better one, if the OS had ever gained widespread adoption.

Unfortunately, BeOS didn't fulfill all needs quite so well. Let's see a few things BSD has that BeOS doesn't:

• Multiuser. The BeOS filesystem and other OS components were written to mak

Yeah, but...

[demondawn]

One of the most appealing facets of BeOS, IIRC, is the fact that it was FREE. At ~$100+tax, I don't see this flying off store shelves. Furthermore, I didn't read anything about it supporting RISC architecture (did I miss it)?

Hardware requirements?

[kwoo]

I looked over their site and couldn't find hardware requirements documented.

One thing I love about open source operating systems is that the system requirements are right there, up front -- or at least you don't have to look hard to find them.

It claims to boot in 15 seconds, which I don't doubt. It would be great to use on a laptop for that very reason. However, will my poor little laptop be able to handle it? I'd love to know before I get my hopes up.

Funny,

[z80]

It was back in 2002 at the CeBIT show in Germany that the people from YellowTAB gave me a "late beta" of Zeta for reviewing purposes. "Only a few problems left to fix", they said.

Turned out the entire GUI crashed all the time and tons of drivers where missing. Then came a big upgrade, then another beta and then... nothing.

Now it's 2005, and it's now "ready for a release next month". I suggest they bury it instead. For good, or turn the whole thing over to the OpenBeOS people.

I hate hate hate that ZetaOS

[magerquark.de]

I do work for a small German company called "zeta software".

Currently, yellowTab is selling the ZetaOS through multiple German home-order-TV shows to computer-illiterate persons. Of course most of them fail to successfully install ZetaOS on their supermarket-bought PCs.

A daily average of two or there of them call us (not yellowTab!) and ask what they can do, now that they crashed both their Windows installation and their ZetaOS.

Even the hints beside every phone number on our website that we have absolutely nothing to do with that ZetaOS did not help much.

yellowTab seems to be aware of the problem that many many customers seems to be very discontented with ZetaOS and additionally call all companies that seem to have the Word "zeta" in their name (which are quite a few), because yellowTab hired a marketing agency (or how you call that in English) that called us some time ago on the phone.

This agency seemed to have the task to call all those zeta-named companies and apologize for the "idiots" (= ZetaOS customers) calling them. The agency further asked us what the average questions of the ZetaOS customers was. You could call that "Indirect surveying" ;-).

I really whish myself and all zeta-named companies that yellowTab runs out of venture-capital really soon and that they disappear and never ever return again *sigh*.

Re:Well, yeah...

[nofx_3]

I concur, and therefore propose a new and relevent benchmark for system boot time called BMPY or Boot Minutes Per Year. This will measure the amount of time (a 24/7 machine) spends per-year in a booting state. for instance imagine you can boot Zeta in 15 seconds but you need to reboot every three days (this is a hypothetical example I have no idea how often it will need to be rebooted) then you have 365/3 boots per year or 122 total boots for a total boot time of 1830 seconds or 30.5 BMPY. Now take another system for example linux that takes 1.5min (a conservative estimate, my system with no optimization takes slightly less) too boot but needs to be rebooted only once a month (again conservative as sometimes I only reboot at major kernel releases) for a total of 90*12 or 1,080 seconds, which comes to 18 BMPY. So in this case although it takes the linux system longer to boot, it actually spends 12.5 minutes less per year booting up. I hope someone will take this idea into serious consideration and maybe create a standard benchmark.

-kaplanfx

Re:Well, yeah...

[Queer Boy]

In any event, at least seeing that your computer is almost there is a psychological relief. Sort of like 2 minutes of commercials is usually better than seeing 2 minutes of black screen.

I call this the Disney effect. If you've ever been to a Disney theme park you typically wait about 20 minutes to get on a ride (excluding the "mountains") however they break the line up and never let you see the whole thing as well as have little pitstops of entertainment before you get on the actual ride.

I've always thought it was brilliant and was reminded of it the first time I saw Windows 2000 boot (it goes through 3 stages, NT text, then the splash, then the screen before login).

Re:Say what now?

[bani]

no, i do understand.

the problem of storing metadata that way is that its non portable. it's exactly the same problem that plagued macos classic. great when you only deal with macs but bad when the internet comes around and suddenly you have no simple way to transport files around.

also bad when you need to talk eg nfs or smb.

storing metadata in bundles and the whole bundle system allows macos to be transparenly "native" on just about any filesystem.

linux and nt have the ability to attach metadata to files, but nobody uses it. it would be a huge pain if anyone did start, because it would then suffer from again being non portable.

osx bundles are a sort of compromise between having metadata available, but in a way thats portable. its a bit ugly, but it works.

its also all xml, woo woo.

BeOS

[wootest]

BeOS was insanely great, with some innovations that were entirely ahead of its time. But do they really have that much going for them now? Microsoft, Apple and several Linux groups already have highly GPU-integrated window managers going, for example, and work's being done on more metadata-rich filesystem-based platforms - WinFS and Spotlight both sit on top of NTFS and HFS+ respectively.

I wouldn't be surprised if it'd take them a few months or years to catch up to the current state of technology, because it's been maintained by enthusiasts ever since the company maintaining it dropped it. Even for something that was ahead of its time, it has catching up to do, both when it comes to technology and killer apps, and I guess what I'm asking is... is it worth it?