How Haiku Is Building a Better BeOS

angry tapir writes "BeOS may be dead, but over a decade after its lamentable demise the open source Haiku project keeps its legacy alive. Haiku is an attempt to build a drop-in, binary compatible replacement for BeOS, as well as extending the defunct OS's functionality and support for modern hardware. At least, that's the short-term goal — eventually, Haiku is intended significantly enhance BeOS while maintaining the same philosophy of simplicity and transparency, and without being weighed down with the legacy code of many other contemporary operating systems. I recently caught up with Stephan Aßmus, who has been a key contributor to the project for seven years to talk about BeOS, the current state of Haiku and the project's future plans."

Comments

Haiku

[wonkey_monkey]

BeOS may be dead
But the only question is
Will I get first post?

Re:Haiku

[Anonymous Coward]

BeOS may be dead
But the only question is
Will I get first post?

You got the first post:
Many congratulations.
It makes you feel good?

Re:Haiku

[Chris Mattern]

From which I can deduce that you pronounce "BeOS" as "bee-oss" and not "bee-oh-ess" (the latter is how the BeOS FAQ says it should be pronounced (http://testou.free.fr/www.beatjapan.org/mirror/www.be.com/support/qandas/faqs/faq-0407.html)).

Re:Haiku

[Anonymous Coward]

BeOS may be dead.
But the real question is:
Does Netcraft confirm?

Re:Haiku

[Anonymous Coward]

They may well say that.
But I do not take commands
How to pronounce it.

Re:Haiku

[MickyTheIdiot]

I wish I could mod this. Slashdot needs a +5 Flamebait post today.

Re:Haiku

[Max Littlemore]

Stupidity aside, I want this to work but having played with haiku, I don't see the point, There must be a point around using low end hardware to do fancy tricks, I just don't see it yet

Re:Haiku

[smittyoneeach]

Like old Stephen King Haiku is a doorstop Like "It: better Be"

Re:Haiku

[Anonymous Coward]

Well, call me when the ARM port is functional enough for the nightly builds, and I'll try it on a Raspberry Pi.

Re:Haiku

[Millennium]

All low-end hardware was high-end once. Extending its useful life is a Good Thing.

Re:Haiku

[cupantae]

Pronunciation
changes to accommodate
those who write po-ems

Re:Haiku

[sgage]

There once was a man from Lahore
Whose limericks stopped at line four.
When asked why this was,
He said, "just because".

Re:Haiku

[MightyYar]

It might be... or it might not be. Older hardware is generally less power-efficient. So it depends on where your power comes from and it depends on the environmental impact of the new product manufacturing and how the old product is disposed of.

Re:Haiku

[Chris Mattern]

Not when you write haiku in the japanese, as a matter of fact. Syllables are very well defined in Japanese and you can't fudge it.

Re:Haiku

[SolitaryMan]

Dude, you must be old here!

Re:Haiku

[Millennium]

Old hardware may be less power-efficient, but the process of making new hardware consumes enough power that even inefficient hardware would have to be kept running for quite a long time indeed before getting new hardware would actually save power overall.

It's like buildings in that regard. New buildings can be greener than older ones, even with upgrades. But the environmental cost of demolition and rebuilding is so high that upgrading an existing building usually turns out to be greener than building a new one.

Re:Haiku

[Anonymous Coward]

There once was a man from Lahore
Whose limericks stopped at line four.
When asked why this was,
He said, "just because".

Leaving us with the feeling there's more.

Re:Haiku

[MightyYar]

Agreed - it's hard to quantify. Moving an old Pentium 4 to an Atom is probably a no brainer, if only for your power bill. But that old Core 2 Duo is probably holding it's own (I have one in my basement...)

Riding off into the sunset

[MetalliQaZ]

I admire their work. They've obviously done some impressive things to preserve that community. I just don't understand them. BeOS hasn't really progressed at all in the past...what? 8 years? At this point they may as well be hacking on Amiga or Plan9. by the time they're done, we're all going to be running on browser-based platforms that use the OS as a layer to support the fancy proprietary graphics drivers. I'm simplifying of course, but that would sure sap my enthusiasm for an OS project.

Re:Riding off into the sunset

[jellomizer]

Computing has a lot of interesting history, and keeping ideas going can come in handy.
We had the first computer that was rather hard wired. No network just crunched numbers.
Then we had the Mainframe, this offered more remote computing with time share and remote dumb terminals.
Then we had the PC, it took over a lot of the mainframe space because every one had their own computing power on their desk and didn't need all that wiring.
Then we got more Web Applications because networking has gotten cheaper and faster, and servers can do a bulk of the work faster and share across many systems.
Then we got mobile devices with apps. As wireless internet is expensive.

Now if wireless companies start offering cheaper and faster internet we will being to see Mobile apps going away and being replaced with more HTML5/other language web apps, and we will be less considered about app lock in.
Then we will get new technology that processes data much better then what we can do over the network and we will go back to apps again...

Ideas came up generations ago, that were considered outdated, or just not useful often get a new life due to new features.
For example compare Windows 8 UI with Plan 9 UI. They are moving away from Windows and to Frames. Also there is a case with newer smaller technology that comes across will need a small light OS (for the time) keeping the Old Concept OS's updated and working, keeps ideas fresh and sometimes they will use them and give them a new life.

Re:Riding off into the sunset

[Kjella]

If he was saying they were going to take down Linux or something, then I'd say they were bat shit crazy but really all they're saying is that they want to try doing their own thing. I think every developer has that "If I could just rewrite this from scratch without having to deal with all the old cruft, it would be soooooooo much better" itch. Maybe the goal isn't competing, it could be sheer accomplishment as in I wrote this and it works great. It could be recognition, that others see the quality of your craft. It could be inspiration, that by showing it as a proof of concept in a small and nimble OS it might be picked up by others. Of course you could end up reinventing the wheel or worse, but then that's a learning experience - but it's still easier to try and fail in a simpler environment. You get to think more on concepts, less on dealing with old code.

I think that's really one of the strengths of open source, you don't have to get anyone's permission, you don't have to convince any naysayers, you don't have to build a business case. You just have to say "yes I could" and code yourself a better mouse trap. Of course you could do that with Linux too but the whole mainlining process is working against you because it goes into millions of production servers that have to be rock stable. It's probably better for you to be part of a project that's open to such radical changes, to be a big fish in a small pond rather than a small fish in a big pond. Perhaps you don't even have any interest in being in the big pond at all.

Re:Riding off into the sunset

[kallisti5]

I admire their work. They've obviously done some impressive things to preserve that community. I just don't understand them. BeOS hasn't really progressed at all in the past...what? 8 years?

Keep in mind that Haiku is compatible to BeOS on the binary level. Be had an army of paid programmers and made the first preview release in a few years. Haiku *reverse engineered* BeOS with a handful of (mostly) non-paid developers. 8 years no longer seems so long :D

At this point they may as well be hacking on Amiga or Plan9. by the time they're done, we're all going to be running on browser-based platforms that use the OS as a layer to support the fancy proprietary graphics drivers. I'm simplifying of course, but that would sure sap my enthusiasm for an OS project.

Haiku supports a wide range of video cards, and has a modern WebKit based browser. Haiku actually fits your description better than Windows or Linux.

Re:Riding off into the sunset

[mkkohls]

I agree completly. The point is that they are doing it and that is cool. Will have to try it one day.

Re:Riding off into the sunset

[jonadab]

> BeOS hasn't really progressed at all in the past...what? 8 years?

Twelve years, give or take a couple of months

Unless you count updated hardware drivers so that it can actually run on a recently manufactured computer as "progress", that is. Personally, I'd call that "treading water".

BeOS is very interesting, and there are definitely some things we can learn from it. I think anyone involved in OS or especially GUI design should make a point of being familiar with it. (The same is also true of VMS, although that has a somewhat higher learning curve.)

I cannot, however, imagine wanting to actually use it as my primary operating system on a day to day basis at this point. I do not see it as a practically useful system today. Haiku perhaps could have been, if it had gotten started much sooner, like, immediately after it became clear in 1996 that Apple was going to buy NeXT and not BeOS, at which point it was already well understood that Be had either failed to convince OEMs to ship BeOS, either as a dual-boot option or solo or that any OEMs they did convince had become unconvinced due to other pressures. Thus, any intelligent person by the end of 1996 could easily figure out that the company was going to go under. If the Haiku project had been started right then, and if the project had progressed much more rapidly once it got underway, if, for example, Haiku R1 had come out in 1998 and a multi-user-enabled R2 in 2000, Haiku might have carved out a significant niche for itself.

But in 1996, and still in 1998, and even still in 2000 for that matter, most BeOS users were in denial about the company's fate and the possibility that store shelves might soon feature computers with BeOS pre-installed, so Haiku didn't even get started at all until 2001 (around the time the company formally announced that it was selling off all its assets and giving up on any possibility of further development in order to salvage what stock-holder value it could). Even as late as 2005 many BeOS users (the ones who had not yet switched to Linux or Mac OS X) were still in denial about the fate of the BeOS R5 source code base and whether whatever company eventually ended up with those assets might either resurrect the OS or else release it under an open-source license. So it's fair to say that Haiku development was a little slow getting started -- a slowness it could ill afford, given how far behind BeOS development had been already. BeOS had some cool advantages compared to the operating systems of the day, such as Windows 95 or, heaven help us, Mac System 7; but there were also some rather notable things it was missing, even then, things that should have been fixed in a subsequent release -- and presumably would have been, if the company had found enough of a market to continue to pay its operating expenses. Haiku, when it was finally started half a decade later, was even further behind, due to the need to start from scratch and reimplement what had already been done -- and once they eventually finish with that, they will still need to design and implement the things that Be had not yet done when it went under.

As a result of those delays, Haiku is still in no position to be adopted as an operating system for regular day-to-day use any time in the forseeable future. Among other things, it has no provision at all for file ownership, user accounts, or (meaningful) permissions. That was one thing in 1996, but now, in an era when we take for granted that everything has to interact with a hostile internet, and so other systems are no longer limiting themselves to simple owner/group permissions but rather are by necessity moving toward adding more complex and discriminating security systems (ACLs, application-level permissions, non-executable memory, ASLR, etc.), the Haiku developers speak of plain old multi-user capability as a pie-in-the-sky "something everyone would like to have" eventually in the distant-future R2. Aside from the obvious implications in multi-user (e.g., business) environments

Re:Riding off into the sunset

[jbolden]

Great comment, you deserve a mod up.

Could BEOS be used as an alternate GUI for a Unix based system. With Ubuntu moving to Wayland there may be an opening for non-X solutions.

Re:Riding off into the sunset

[jonadab]

> Could BEOS be used as an alternate GUI for a Unix based system.

You could borrow *ideas* from BeOS if you were designing an alternate GUI for a Unix-type system, or any other system for that matter.

That would be kind of missing the point, though. The BeOS GUI was largely unremarkable. Okay, yes, if you had multiple desktops they could each have a different resolution (and color depth, if desired). At the time, that was innovative. Other systems have it now, of course.

On the whole, though, the really notable things about BeOS were infrastructural, not superficial. To speak of BeOS as a GUI is to rob it of its strengths and everything that makes it really notable.

The way BeOS did multitasking, for example, provided a level of responsiveness that other systems at the time were not able to deliver on similar hardware. That's a kernel design feature, not something you can layer on top when building a GUI.

The BeOS approach to hardware and drivers was really remarkable and completely unprecedented at the time and eliminated several major categories of problems in one fell swoop. Knoppix has since delivered something almost comparable. (I suspect it's probably implemented differently, but the results are similar, if not quite as impressive.)

Then of course there's the filesystem. Personally I'm not terribly fond of the BeOS approach to that (except for the journaling, which has become standard on other systems), but there's no denying that the filesystem, and in particular the unusual metadata handling, was a significant aspect of what made BeOS unique and conceptually interesting, and it's not something you could implement in a GUI without the underpinnings being there in the kernel and in the on-disk filesystem format.

Re:Riding off into the sunset

[jbolden]

Knoppix interesting. What's special about Knoppix from a BEOS comparison?

  As far as filesystems and metadata the Linux kernel has support for metadata though most compiles turn it off. In addition most of the major filesystems: ext2, ext3, ext4, JFS, ReiserFS, XFS, Btrfs and OCFS2 support it. Linux also has HFS and HFS+ which has multiple resource forks per file. The big issue is that most linux user space programs don't do anything with forks, so while they can exist they can't really be useful. But at least nothing much you would need to do at the kernel level.

Anyway I'm still unclear what is the BEOS killer feature.

Re:Riding off into the sunset

[drsmithy]

Okay, yes, if you had multiple desktops they could each have a different resolution (and color depth, if desired). At the time, that was innovative.

Pretty sure the Amiga was doing this back in the '80s.

(I must say I struggle to see a significant use case, however.)

Re:Riding off into the sunset

[hazydave]

Right.

One big one in BeOS that's kind of the opposite of UNIX/Linux -- BeOS is MASSIVELY multithreaded. Like the AmigaOS that to an extent inspired it, only moreso. Pre-emptive threads (which didn't even exist in Linux until relatively recently) were an everyday programming construct, like "function" or "loop", and used everywhere. This tied in with BeOS being intended primarily for multithreaded systems -- the original BeBox was a dual processor PPC603 machine.

The original Be file system was very interesting -- it was basically a database, not a filesystem. Performance was pretty bad, though, so this was replaced by the attribute-heavy file system that's in the current HaikuOS. Not quite as elegant, but way more functionally practical.

Another very cool aspect was a unified timing architecture, which made BeOS the very best OS for multimedia work in its day. Sadly, this and various other things were evolving, and while a number of major players, particularly in music software, had been working on Be applications, there was a big wait for some of these things to be finished in R5. Which they were -- pretty much at the same time Be, Inc. announced BeIA (which was never going to function, simply because x86 wasn't useful in many embedded platforms at the time) and committed Seppuku.

Re:Riding off into the sunset

[hazydave]

The Amiga was at least a bit of inspiration to the original BeOS team (not to mention a few programmers who had worked on some Amiga projects). The purpose in the Amiga's day was pretty basic: the limits of graphic chips required trade-offs between color depth and color resolution.

Of course, that goes away with modern graphics devices, which were at least on the way when Be was introduced in 1985. There are other considerations, though. For example, in video, you have an advantage if you match your display to the actual video mode (for editing purposes), rather than resampling via a frame buffer (which can hide things). But it's definitely less useful in modern times than it once was. And of course, you can kinda-sorta so this in Windows since DirectX, at least per app if not per virtual screen.

Re:Riding off into the sunset

[BenoitRen]

BeOS hasn't really progressed at all in the past...what? 8 years? At this point they may as well be hacking on Amiga or Plan9.

That doesn't change the fact that BeOS was its own paradigm that still stands apart today. It's worth preserving and using.

Re:Riding off into the sunset

[BenoitRen]

As a result of those delays, Haiku is still in no position to be adopted as an operating system for regular day-to-day use any time in the forseeable future. Among other things, it has no provision at all for file ownership, user accounts, or (meaningful) permissions.

So what? I don't need DRM on my home computer, thank you very much.

Nonetheless, for the other 95.75%, connecting to the internet without being in a limited-permission user account is just a really bad idea.

If your system has been owned, it's already too late. A limited user account isn't going to change this.

The security issue is just one of many. The short version is, it's not 1996 any more. I think it's important for OS and GUI designers to be familiar with BeOS and learn from it. Beyond that, however, I do not think BeOS or Haiku is a useful system today, and its development would need to accelerate significantly for that to ever change.

You mentioned one field where wouldn't be useful, and from that you extrapolate it to it not being useful in general.

I happen to think that it would make a great home desktop OS.

Re:Riding off into the sunset

[BenoitRen]

HaikuOS

The correct name is Haiku.

Re:Riding off into the sunset

[jonadab]

Today, I can't think of a really compelling use case, because we can now all afford monitors that can do 24-bit color and a sane refresh rate at the same time even at the highest resolution our video cards can support.

In the mid nineties, however, it was common that with a mid-range monitor you'd have to choose which of those three things (resolution, color depth, or refresh rate) you were willing to sacrifice to get the other two up to where you wanted them. Being able to place each application on a desktop that supported what it most needed was genuinely useful.

The other major option would've been dynamically changing the monitor's settings, which XFree86 for instance was able to do even while keeping the desktop the same size -- your monitor became a viewport, and you'd scroll around it by moving your mouse pointer past the edge of what was currently visible. (This is still possible in X.org today, though with modern monitor resolutions there's much less reason to use it.)

Neither of these solutions is really ideal (ideal is when one whole wall of your room is a giant high-res monitor, but who can afford that?), but for any given application one or the other of these compromise solutions would be better than the other. Both are a lot less compelling now that you can spend twenty bucks and get a gently-used 19-inch monitor that does 1600x1200 or better at 24bpp and 85Hz refresh, which somebody is letting go cheap because he replaced it with an LCD like all the cool kids. Buy two and have yourself a dual-monitor setup. Throw in a decent new graphics card and it's still cheaper than buying a 15-inch monitor in 1996 that could only do 1024x768 if you lowered the color depth to 16-bit and settled for a 60Hz refresh rate (which with long-tube fluorescent lighting in the room will give you a migraine in less than ten seconds).

Re:Riding off into the sunset

[jonadab]

> Knoppix interesting. What's special about Knoppix

Boot-time hardware detection.

Other Linux distributions (RedHat, Mandrake, possibly others) had done significant work on this previously, but Knoppix was, to the best of my knowledge, the first Unix-like system to get to the point where you could swap out several major components (for different models, not identical replacements) at one time, including perhaps the motherboard, and still reasonably expect it to boot up without a hitch. It's not perfect -- on some hardware I have to try two or three different versions of Knoppix to find one that will boot at all -- but it represents enormous progress over the previous state of affairs.

So, that thing about detecting all your hardware at boot time and not giving you any problems if it's different from last time? BeOS did that in 1996. When you bought a new computer, you could just stick the old hard drive into the new computer and boot from it as if there were nothing unusual about that (assuming it was in the same architecture family, e.g., upgrading from a 486 system to a Pentium II system). No driver installation hassles (don't even get me started on hardware detection in Windows), no worrying about the network card now being eth1 instead of eth0 just because it's a different model (Debian still has this issue in 2012, and I doubt if it's alone in this regard), no problems: with BeOS, you plugged in the new hardware, turned the computer on, and everything just worked (assuming it was supported at all -- at the time, software modems were the most common sticking point).

There was never any nonsense about "Found New Hardware... Looking for driver... say, do you happen to know what model this thing is or maybe have a disk handy?"

Re:Riding off into the sunset

[jbolden]

I see. Yeah I agree Knoppix put several Linux utilities together to get that to work and always did an excellent job. And most importantly did it and then kept doing every boot.

Re:Riding off into the sunset

[jaymemaurice]

Ha, you think app stores are about saving bandwidth and they will be replaced by HTML5? What kool-aid have you been into? :)

Re:Riding off into the sunset

[jaymemaurice]

In the 90's (with the exception of monochrome displays) I don't think your monitor ever cared about the colour depth vs. resolution. It was your graphics card that cared. Your graphics card only had a limited amount of memory so maybe it could not store 24bits of colour information*786432 pixels changing/refreshing 60+ times a second. Your monitor cared only about how fast and accurately it could scan horizontally and vertically across it's shadow mask. Your monitor would have only certain clocks it could lock onto (modes) where it could excite the right red, green and blue phosphorus dots and a certain power of the electron gun(meaning cheap displays would get darker at high resolutions, or you had to modify the brightness dial when changing resolutions) - but the monitor itself could always display 24-bit colour if it could display any 256 colours. Even in 256 colour mode, many applications took advantage of modifying the colour pallet (when supported by the graphics driver) to reproduce any single colour multiple times. Applications would also use dithering to reproduce colors beyond the 256 colour or 16-bit pallet (which was most effective at high resolution). The monitors, being analog, did not care about the colour depth - they just had an analog electron gun that would excite from dark to full bright... sure, some had poor gammut or contrast... but they would still produce the picture regardless of your display mode at the resolutions it supported.

Re:Riding off into the sunset

[jaymemaurice]

The concept of file ownership/permissions != DRM... file ownership/permissions are supposed to be a way to stop you from getting owned - the concept and implemnentation it's a simple method of sandboxing dumb users or poorly writen applications from writing to places it should not be able to. Every modern operating system does this.

I think you miss the point that he is making, with any process/application to be able to write to any other process or application, it creates a completely untrusted environment where you cannot expect the system to be in any state when you cannot completely control it's inputs. Combine that with many alternatives available that are more secure/sane by design, there aren't many uses for it...

Sure maybe it can go in a stand alone video editor... but why would you when you can put linux on that same machine and connect it to the internet/render farm and not have to worry about it getting pwned in a javascript buffer overflow

Re:Riding off into the sunset

[BenoitRen]

The concept of file ownership/permissions != DRM

But it is! It's not the kind of DRM that the MAFIAA is pushing, but it's still DRM. File ownership and permissions are digital rights.

it's a simple method of sandboxing dumb users or poorly writen applications from writing to places it should not be able to.

This is why I'm in favour of permissions for applications instead of users.

I think you miss the point that he is making, with any process/application to be able to write to any other process or application, it creates a completely untrusted environment where you cannot expect the system to be in any state when you cannot completely control it's inputs.

Which I don't think is appropriately solved by DRM aimed at users like Unix does.

Sure maybe it can go in a stand alone video editor... but why would you when you can put linux on that same machine and connect it to the internet/render farm and not have to worry about it getting pwned in a javascript buffer overflow

Because Linux is a crappy desktop OS and BeOS/Haiku offers a better experience.

Since when do we have to worry about JavaScript buffer overflows, anyway? Modern web browsers are pretty good at containing JavaScript and they are updated quickly should an issue arise. Just keep your web browser updated. There are tools like NoScript should you be paranoid.

Re:Riding off into the sunset

[jonadab]

Yes, come to think of it, I believe you're right: it was the graphics card that limited color depth, not the monitor.

Either way, it's much less of a consideration now than it was in the mid nineties.

Re:Riding off into the sunset

[unixisc]

I think BeOS would have done better had Be Inc not killed the BeBox for the likes of Power Computing, Motorola & Umax, but kept it, and targetted it towards developers. Then once Apple ended the Mac clone business, those 3 companies could have made PReP based BeBoxes, and then Be could have retreated from it. Also, Be would have done well at the time to have ported it to other CPUs, such as Alpha, MIPS, Sparc and PA-RISC.

Raspberry Pi?

[a_nonamiss]

Seems like this OS would be a good fit for Raspberry Pi, if someone would take the time to build it for ARM. The fixed hardware and low power of the Pi is just begging for a lightweight, low footprint OS, and people using the Pi aren't really shackled to backwards compatibility. I know absolutely nothing about how to port a kernel, or I'd be right in there trying to figure out how to do this.

Re:Raspberry Pi?

[LifeIs0x2A]

Good idea, but BeOS is lacking the massive software repository that Debian Linux (the current platform for the Pi) is offering, minus the huge development community. The same problem that prevents it from spreading on other platforms as well. Anyway it would be a great alternative. Especially for educational purposes as it is a very clean and efficiently structured OS.

Re:Raspberry Pi?

[Zobeid]

Certainly not the likes of Ubuntu. It's a behemoth.

Re:Raspberry Pi?

[Anonymous Coward]

The fixed hardware and low power of the Pi is just begging for a lightweight, low footprint OS

You mean like Linux or BSD?

Linux or BSD only seem lightweight to people who only are familiar with monolithic kernels. Linux and BSD might seem slick compared to Windows but compared to things like BeOS and AmigaOS they are huge and resource draining.

Re:Raspberry Pi?

[CrazyBusError]

The fixed hardware and low power of the Pi is just begging for a lightweight, low footprint OS

There is one already. It's called RISCOS. Sure, it needs some work (like pre-emptive multitasking and SMP, okay a *lot* of work), but it's small (the OS uses 6Mb of RAM) and it's very fast. And there's already a reasonable amount of software available for it, plus a working GCC implementation, so more can be ported.

It just needs volunteers. Preferably ones who will happily write hand optimised ARM assembler...

Re:Raspberry Pi?

[Hatta]

I remember reading some of the Haiku mailling list once. Posix compatibilty was brought up, and the prevailing opinion was that they didn't want to become yet another posix app launcher. Too much posix compatibility would cannibalize whatever interest there may be in native Haiku apps.

I see their point. There's little reason to switch from Linux when you're just looking at using the same apps you always would. And if you're interested in writing a new app, you'll be more likely to make an impact with an app on a platform with little software than one that has the whole open source ecosystem available to it. I just hope they have enough interest in their platform to draw app developers and not just OS devs.

Re:Raspberry Pi?

[bill_mcgonigle]

Posix compatibilty was brought up, and the prevailing opinion was that they didn't want to become yet another posix app launcher

I'd think they'd be better off taking the opposite approach - merge the advances that BeOS made into the existing FLOSS ecosystem.

I remember some awesome BeBox demos from c. '95, and it was clearly better than anything else at the time. But, I have to wonder how much better was it than Linux 20 years later. If BeOS can do some things more efficiently than Linux (or FreeBSD, et. al.), I suspect the kernel devs would like to know about it. There are features of BeFS that would be nice to have in ext4 or ZFS (I've actually chatted with an ext4 dev about some of these and the disk format wouldn't need to change). There are system-level services that FreeDesktop ought to implement. There are GUI elements that might find a nice home as XFCE features. Etc.

I realize I'm asking to keep the ideas in BeOS alive rather than keeping BeOS alive, and that's a different goal. There are folks who work on and use PDP/11 emulators, and more power to them, but it really has beneficial impact to very few people. Be's legacy ought to be the wide dispersion of its ideas, rather than its code, to as many people as possible.

Re:Raspberry Pi?

[Anonymous Coward]

Linux didn't always have a massive package system either. Somehow it grew. I don't think it's volume that makes an OS, but quality of applications.

Something is necessarily wrong with your statement.

The only quality OSS I can think of are low-level or server-related stuff that require little to no UI/UX. Specifically, the linux and BSD kernels, compilers (gcc, llvm), and a handful of pieces of software related to the web stack (PostgreSQL in particular).

Over the years, I've reported a number of bugs in various interpreted languages, almost all of which were either closed on a won't fix basis, or have been rotting in bug trackers for years. So I clearly wouldn't count them amongst good quality projects.

Likewise for the seemingly infinite scores of libraries to do all sorts of things beyond stdlib. Whether open source or closed source, most libraries are steaming piles of crap that are either or both of unmaintained and unmaintainable. Exceptions are few and rare in between.

When it comes to UI/UX, I'd argue quality is just one notch over puke. The code might be fantastically (over-) engineered underneath, but don't even get me started on the various code editors, Window Managers, OpenOffice or GIMP when it comes to user experience.

And then sometimes, there's OSS is successful precisely because of its UI/UX. And then you look underneath the hood and all you find is a huge mess of spaghetti code (I'm looking at you, WordPress). Hardly quality either.

So please explain... Where are those quality applications that you mention? Please name a few, because I cannot explain to myself why Linux is having such a tremendous success in the consumer space.

Oh wait!

Re:Raspberry Pi?

[BanHammor]

By the time you beat the dragon, you become the dragon.

Re:Raspberry Pi?

[Belial6]

AROS an Amiga clone is already being ported to the Pi as well. http://www.youtube.com/watch?v=COUrcZat6oc Although to be fair, it is currently Linux hosted.

Re:Raspberry Pi?

[Anonymous Coward]

Wasn't FOSS a charmless enough term? Now it's FLOSS? God.

Re:Raspberry Pi?

[s73v3r]

Over the years, I've reported a number of bugs in various interpreted languages, almost all of which were either closed on a won't fix basis, or have been rotting in bug trackers for years. So I clearly wouldn't count them amongst good quality projects.

Without knowing what those bugs are, we can't care about your claim that they aren't good quality projects.

Re:Raspberry Pi?

[icebraining]

The term FLOSS was coined more than ten years ago. Not that it's a great term, I give you that.

Re:Raspberry Pi?

[david.given]

Haiku is Posix! If you fire it up and start a terminal window, you get bash. All the standard fileutils and coreutils are there (although I don't know whether they're the GNU versions or not), and command-line programs usually just compile with the supplied versions of gcc. autoconf works. And, yes, there's vim and emacs. GUI-wise, there's a Qt port, and KDE runs.

It's well worth booting the live CD just to remind yourself what a good single-user can be really like. It's very pleasant to use and it flies.

I do disagree with some of their design decisions --- keeping binary compatibility with BeOS means that Haiku can't lose the heritage of gcc 2's C++ ABI, which is painful. But gcc 4 subsystem is there as well and all it needs is for someone to finally throw the switch and stop building the gcc 2 cruft into the system. And I do think they need to push Qt more; the native Haiku GUI is absolutely fine, but Qt is so much better.

In my view, the three things Haiku really, really needs are: (a) better wireless; (b) a proper package manager with a centralised repository; (c) an improved web browser. And apparently all these are being worked on and are almost ready.

An ARM port would be awesome. It's so perfectly suited to that kind of device.

Re:Raspberry Pi?

[david.given]

There is one already. It's called RISCOS. Sure, it needs some work (like pre-emptive multitasking and SMP, okay a *lot* of work), but it's small (the OS uses 6Mb of RAM) and it's very fast. And there's already a reasonable amount of software available for it, plus a working GCC implementation, so more can be ported.

RISC OS needs throwing away. I'm sorry, but it does. It was good at the time but these days we know so much more about writing operating systems that you simply cannot get to a real OS from there.

Examples? Memory is protected except when it's not, giving you the worst of both worlds. No threads. No preemption. User code runs in supervisor mode (and supervisor mode code on ARM isn't guaranteed to be portable). The GUI is great --- if you have a mouse; it can't be driven from the keyboard, at all. There is a single byte of public workspace at 0x00000108 which means that the bottom page of memory has to be mapped. Yes, this means that null pointer dereferences don't trap! There are about fifteen different APIs for doing anything, with slightly different semantics, some of which pass flags in the top eight bits of addresses. There are roughly five different system heaps, none of which overlap, all of which suffer from fragmentation.

The real jewel of the crown, though, the point at which I went from being a fan to wanting to kill it with fire, was when I discovered the code in the system memory allocator which looks up through the caller's stack trying to figure out whether it's being called reentrantly. If it is, it allocates the memory from a special small heap. Why? So that it could do memory allocations from inside interrupt handlers.

(Just to show my credentials: I discovered all this while working on a RISC OS kernel reimplementation.)

That said, if you want a 1980s grade utterly non-Posix OS, RISC OS is a good one, and if you have a Raspberry Pi do check out the bootable RISC OS image. It's interesting and works well.

But Haiku is a real, modern operating system, and RISC OS isn't.

Re:Raspberry Pi?

[Osgeld]

wtf why on a Pi? get debian, dont install shit for it, and couple it with some obsolete 1990's UI and bam you have Haiku in a nutshell, and its safe cause it really hasnt changed much since day one. (be wasnt really all that special either, it was mainly the beefcake hardware that was the appeal, not an os with nothing to run)

now toddle on little Pi head, and remind your breathern, just cause you just heard of an OS today, doesnt mean you instantly post about how great it would be on a Pi with its tiny amount of computer power (more power than the last generation of video game consoles)

Re:Raspberry Pi?

[Anonymous Coward]

You do realize that netBSD can run perfectly within the shell with 8 megs of ram don't you? There is no linux kernel or windows that does that(you need to go all the way to dos).

Re:Raspberry Pi?

[Taco Cowboy]

Good idea, but BeOS is lacking the massive software repository that Debian Linux (the current platform for the Pi) is offering, minus the huge development community. The same problem that prevents it from spreading on other platforms as well. Anyway it would be a great alternative. Especially for educational purposes as it is a very clean and efficiently structured OS.

 
I think you're missing the point
 
Let me show you an example:
 
http://board.flatassembler.net/topic.php?t=14044&start=49
 
This guy has ported his own OS to Ras Pi. He has no "huge development community" nor "massive software repository"
 
Inspite of not having any of the facility that you mentioned, he has successfully done what he had done, and ...
 
http://board.flatassembler.net/topic.php?t=14044&postdays=0&postorder=asc&start=63
 
... I am quoting that guy ...
 
  ""I have implement[ed] the functions to be the same as the equivalent Arduino commands, so anyone who as programmed the arduino or tut available for the arduino, will be easy to convert."
 
As you can see, if it can take just one person to do what that guy did, I simply do not understand what's stopping Haiku-os.org from porting Haiku to Ras Pi
 
Unless of course, they do-not-want-to
 

Re:Raspberry Pi?

[hazydave]

There have been a whole history of multimedia-friendly possible enhancements to Linux that have been rejected, as they caused server performance to drop by 0.01% or some-such. Ok, maybe an exaggeration.. but remember back when nearly the entire kernel was locked against preemptive interrupts, just a few tiny windows to recognize such when in kernel mode? The fixes had been around for some years, but only got rolled in as part of the update to get SMP working properly (or at all... it's been some decades). Quite a bit of what made BeOS/Haiku great involve relatively huge numbers of preemptive, lightweight threads. In fact, a "process" in Linux speak is called a Team in BeOS... that's a Team of Threads, of course. Very much the opposite of how Linux/UNIX have worked through most of their history... Linux didn't even have preemptive lightweight threads throughout most of its existence. The last time I tried to do asynchronous I/O (kind of a built-in in AmigaOS and commonplace in BeOS), it was a real headache in Linux (ok, this was 2008, maybe it's better supported today).

I'm not sure you can make Linux much like BeOS and still keep it Linux. And that's before you even get to the relatively nice and (for the day) innovative C++ framework for everything.

Re:Raspberry Pi?

[hazydave]

Well, back in the day, I had to walk to work, uphill, in BOTH DIRECTION!!! Ok, but on topic... we had the SVr4 version of AmigaUNIX happy to not only run, but run with X and everything, in 4MB of RAM. The earlier version, with Rico Tudor's far more efficient windowing system, was happy in 2MB.

Not to suggest there's a huge reason to want to run with such small amounts of RAM. Just that, historically, *NIX itself wasn't all THAT bloated.

Re:Raspberry Pi?

[bill_mcgonigle]

Quite a bit of what made BeOS/Haiku great involve relatively huge numbers of preemptive, lightweight threads. In fact, a "process" in Linux speak is called a Team in BeOS... that's a Team of Threads, of course. Very much the opposite of how Linux/UNIX have worked through most of their history

So, each thread was scheduled independently? What about the Teams? Were they group scheduled?

Linux effectively treats kernel threads like processes, so the plumbing should be there. Are CGroups a map to Teams at this point?

Re:Raspberry Pi?

[jaymemaurice]

I think what the guy means by no "huge development community" is no geeks with interest in doing it, just because. ARM is different then x86 and I would assume to make a good port on ARM, there would be a lot of specific x86 hacks that need to be revisited

And re: "massive software repository": The people who are interested in rasberry pi need to be interested in it for a particular prupose... since debian has a huge software repository, there are likely many more users who will be interested in the well established linux that fits their purpose vs the port of beos with few apps

So what I interpreted from that is there is no want to do it...
That and porting your own OS is a lot different then porting a community written OS that is made to be binary compatible with another closed source OS to another architecture.

Haiku Not Stolen

[Anonymous Coward]

CodeSuite forensic software shows no evidence that Haiku was copied from or was a derivative of BeOS.

How is this 'news'?

[dingen]

Haiku has been around for 10 years or something. They've always aimed for a binary-compatible successor of BeOS. And they're still at it.

So what?

Re:How is this 'news'?

[royallthefourth]

But isn't it exciting to think that you could run all your old favorite programs from BeOS such as

Re:How is this 'news'?

[Pope]

BeOS was a cute tech demo back in the day of 120MHz PPC604 processors. That's about all I got out of it.

Re:How is this 'news'?

[TheRealMindChild]

There is hardly anything "binary-compatible" with Haiku anymore

Re:How is this 'news'?

[CompMD]

NetPositive!

It's shit

[Anonymous Coward]

Haiku is based on the excellent micro/monolith hybrid NewOS, and it had a very interesting prospect of becoming a great OS.

Unfortunately, the project is slowly heading towards disaster as more and more incompetent people have started to contribute (think GSoC gone wrong, permanently.)

The code base is 1) not security audited, 2) slow as hell, 3) assbackwards and 4) not having a snowballs chance in hell to work on my 4-way CPU (the memory manager dies under SMP load and must be rewritten.)

I loved BeOS, but this is not going to replace it.

Re:It's shit

[Anonymous Coward]

Can you expand on your numbered points? They're a little vague and incendiary...

Re:It's shit

[kallisti5]

Unfortunately, the project is slowly heading towards disaster as more and more incompetent people have started to contribute (think GSoC gone wrong, permanently.)

Care to elaborate?

The code base is 1) not security audited,

What says it can't be? Also, Haiku is only single user, so at the moment this doesn't even make sense. (pre-beta software is pre-beta)

2) slow as hell

Umm, most 3rd party reviews mention how fast it is

3) assbackwards

This isn't a statement.

4) not having a snowballs chance in hell to work on my 4-way CPU (the memory manager dies under SMP load and must be rewritten.)

Strange, my eight core AMD bulldozer cpu works just fine.

I loved BeOS, but this is not going to replace it.

Patches welcome

Re:It's shit

[maxwell demon]

I once looked at the source code of Haiku's floppy driver. Nuff said. End of story.

Floppy drives are past.
Therefore the floppy driver
No longer matters.

Re:It's shit

[jaymemaurice]

Is that really the floppy driver's source code?!
Is this the display driver detection source code?!

Driver of the screen
impliment vesa if is seen
else just bitch and scream

Not to be harsh but...

[apcullen]

So what? I mean, it's pretty. I can admire its simplicity. But.... can I run open office on it? It's built on Qt... but can I run kde apps on it? Play some ksoduku? The article doesn't really mention application support, except to say that 3d acceleration isn't there yet. I remember back when Be was first released everyone was wowed by its multi-threading support-- but surely modern operating systems have duplicated this by now? It seems to me that if you took a linux distro, stripped out all the 3d support and other power-consuming enhancements, and ran xfce or some other extremely light weight window manager, that you'd have a system that's just as fast but one that you could actually run the programs you wanted on.

Re:Not to be harsh but...

[Bill Hayden]

It's built on Qt... but can I run kde apps on it?

It's not built on Qt in any way. I don't even think Qt has been ported to it.

Re:Not to be harsh but...

[realmolo]

Don't forget that Haiku/BeOS are *single user* operating systems. There are no file permissions.

That all by itself makes it a joke, honestly.

Re:Not to be harsh but...

[cianduffy]

QT has been ported, but the OS is definitely not built on QT.

Re:Not to be harsh but...

[Chrisq]

Don't forget that Haiku/BeOS are *single user* operating systems. There are no file permissions.

That all by itself makes it a joke, honestly.

It does have file permissions, and there are utilities to set them. My understanding is that it is single user in the way the original Windows was, i.e. one user logged on at a time and all processes running as either user or system. However if a different user logs on you can protect files from them.

Disclaimer: my understanding may be wrong, it comes from a brief look at BeOs some years back.

Re:Not to be harsh but...

[sootman]

> There are no file permissions.
> That all by itself makes it a joke, honestly.

No, it just had different aims. What you call a "joke" was in fact a (paraphrased from Wikipedia) "... a modern 64-bit capable journaling file system... it includes support for extended file attributes (metadata), with indexing and querying characteristics to provide functionality similar to that of a relational database. [In other words, you do a search and the results appear pretty much instantly because they came from a DB query, not from walking the whole FS.] It supported volumes up to 2 exabytes."

Also files could be larger than 2 GB (though I forget how big) and it used MIME types.

All of that over fifteen years ago.

Re:Not to be harsh but...

[todfm]

How is it a joke? Day in and day out I'm the only one using my computer. If I share files with someone, it's through a server, and not directly from my computer. The only time I deal with file permissions is when I'm fighting against them blocking my access.

That said, Haiku has plans to adopt multiuser stuff. But the lack of it doesn't impact me in any way.

Re:Not to be harsh but...

[apcullen]

Not just "like"-- I admit that I've never run it. It's actually great to get a response from someone who has.

Part of my original post was trying to get my head around just what made it special, and another part was wondering whether it has any real value today. Is it still unique?

The UI was original. There are Be-like window managers available for linux-- somehow I doubt they capture the complete experience. How close are they to the original? Speed is another thing people always bring up. But they bring that up with light weight linux distros also. So again I must ask: is it truly superior to modern operating systems, given a similar feature set?

Re:Not to be harsh but...

[jonadab]

I haven't looked at Haiku recently, but I've also seen no mention anywhere of their having *added* multi-user capabilities that BeOS didn't have -- and BeOS didn't have the functionality you describe. There was no such thing as a user account or logging in. It was multi-user in exactly the same sense that DOS was multi-user: if the user physically vacated the chair in front of the computer, a different person could sit down in the chair.

Re:Not to be harsh but...

[BenoitRen]

No, the joke is file permissions on a home desktop operating system. It's a cancer that has come from the business world.

Re:Not to be harsh but...

[BenoitRen]

It seems to me that if you took a linux distro, stripped out all the 3d support and other power-consuming enhancements, and ran xfce or some other extremely light weight window manager, that you'd have a system that's just as fast but one that you could actually run the programs you wanted on.

HAHAHAHAHAHAHAHA

You're funny.

Re:The Golden Girls wish you a great day!

[Pikoro]

That's not a haiku
please try harder next time k?
i end this debate

Love the work

[WiiVault]

As somebody who never got to play around with Be, I'm really impressed with how Haiku works and looks. It's simple, but fast and pleasant to use. Can't wait for the next Alpha release, since I'm too lazy to mess with the nightlies.

Re:Compare BeOS with Mac OS X today?

[Kergan]

How would you folks, with far more detailed information on BeOS, compare it to Mac OS X today?

Obsolete.

How is that 'Insightful'?

[Anonymous Coward]

The news is: here's a current interview with a key dev. Which is what the summary says, no further reading required.

Seriously, mods. You've marked a standard troll-remark as Insightful. Stretch, refill your coffee, try again.

Yes, but why?

[TheGoodNamesWereGone]

I loaded up BeOS back in the day whenever it was. It was pretty slick but I went back to OS/2. That should tell you how badly it lacked applications. My hat's off to the guys working on Haiku in recognition of their skill and dedication, but it seems like at best an academic exercise.

BeOS were still in denial?

[dgharmon]

"But in 1996, and still in 1998, and even still in 2000 for that matter, most BeOS users were in denial about the company's fate and the possibility that store shelves might soon feature computers with BeOS pre-installed, jonadab

It's fully documented that Microsoft threatened Hitachi over plans to introduce the operating systems into itâ(TM)s product line. Compaq and Gateway were also prevented from marketing BeOS due to the terms of the Microsoft OEM contract. Microsoft also acted to depress the price of the initial BeOS IPO. See here where MS also acted to supress Tron.

"Microsoft sent two U.S. managers to Japan who expressed their 'anger' with Hitachi over its arrangement with Be, and 'reminded' Hitachi of the terms of its Windows license" theregister.co.uk

"BeOS had some cool advantages compared to the operating systems of the day, such as Windows 95 or, heaven help us, Mac System 7", jonadab

WINDOWS_7 vs BeOS from 1999

Re:Compare BeOS with Mac OS X today?

[longbot]

Responsiveness, namely. While OS X was growing up (it didn't become seriously usable until 10.3 or 10.4) I missed the lightning-fast UI of BeOS. Nothing slowed it down. You could go something, and let it chug away at it while you did something else. Everything felt light or responsive. Applications started instantly, it had Spotlight-quality instantaneous searches built into the filesystem (and none of this "indexing" crap spotlight likes to pull).

Also, it had the absolute best-written SMP support I have ever seen. In Windows and OS X, it's glued-on by comparison. Fast, elegant, usable, simple, and powerful. OS X is nice, but it takes a lot more hardware power for it to manage to be as snappy and responsive. And even then, it lags in odd places.

The Haiku team have made good if slow progress, and I hope they continue to do so.