Got some spare time and an itch to try out the latest Haiku snapshot? Karl writes in with an easy install method for anyone wanting to try Haiku, using a BeOS Max Live CD.
Got some spare time and an itch to try out the latest Haiku snapshot? Karl writes in with an easy install method for anyone wanting to try Haiku, using a BeOS Max Live CD.
it seems to have something to do with beos…?
It has something to do with BeOS and freedom. Haiku is the future BeOS and it is free and open.
to give you a real answer and not some crap like the other poster.. its an attempt to make nad opensource clone of beos.
haiku-os.org is the homepage
I’m not sure what i should think about the atempt to create a OSS BeOS.. don’t get me wrong, I really liked BeOS 5 PE, but you can hardly say that up-to-date and that it was exceptionally superb (iand i won’t even start with the lack of software/drivers).
Well, the look and feel might have been great, but can’t a simple DesktopEnviroment for Linux/*NIX do the same job more easily?
<<I’m not sure what i should think about the atempt to create a OSS BeOS.. don’t get me wrong, I really liked BeOS 5 PE, but you can hardly say that up-to-date and that it was exceptionally superb (iand i won’t even start with the lack of software/drivers).
Well, the look and feel might have been great, but can’t a simple DesktopEnviroment for Linux/*NIX do the same job more easily?>>
Yes . . . you can use an aircraft carrier to go water skiing if you want to:-)
“can’t a simple DesktopEnviroment for Linux/*NIX do the same job more easily?”
Some people thing it can… Some people don’t…
IHMO, Linux’s much more a “jack of all trades” than BeOS was… BeOS was designed for desktop and multimedia, and it’s pretty good (I mean, amazing!) doing it. Linux in the other hand can running from you digital audio player, your wireless router to the google’s mainframe… But it doesn’t do multimedia as BeOS did, besides other great design ideas that don’t fit today’s linux distributions.
Well, if possible, try BeOS. you’ll understand why… =]
beos=crap
i rather use windows 98
BeOS, at it’s fundamental design, is a perfect match for the future of CPU design. It was always designed to take full advantage of multiple processors by using multi-threading everywhere.
Plus, like has been mentioned, BeOS was designed specifically for the desktop. I’m sure Haiku will continue to offer this same specialization, but as it and it’s developer community matures I fully expect it to begin offering the versatility of Linux with it’s many DE’s and WM’s. Really the best of both worlds, as long as the Haiku developers decide not to overspecialize the API’s for their own integration.
Plus, like has been mentioned, BeOS was designed specifically for the desktop. I’m sure Haiku will continue to offer this same specialization, but as it and it’s developer community matures I fully expect it to begin offering the versatility of Linux with it’s many DE’s and WM’s.
The absolute last thing you’ll ever see for Haiku is a different Windows Manager. Having 6 different window managers is antitethical to everything the average BeOS user wants. Most BeOS users have too much of a ‘just work damnit’ attitude to care to fiddle with different WMs.
I’m sure being open source will mean forks and different desktops eventually, but there’s a reason some people are waiting so desperately for Haiku: they don’t like Linux.
Just thinking out loud here so bare with me… Of course Haiku is a great project with very nice goals. But is there any guarantee Haiku’s code quality will be anywhere near as good as BeOS? Couldn’t it be some parts of the OS are written very differently (maybe better, more efficient, maybe not) to do the same thing? Or are they able to disassemble/reverse engineer the original BeOS files and create code that must be very close to what BeOS coders wrote in the past?
Interesting to think about, every BeOS fan (me included) is looking forward very much to the first Haiku release… but maybe Haiku will prove to be incredibly buggy / unstable / not nearly as fast as BeOS…? After all, it isn’t Be who is creating Haiku
I’d love to be enlightened by someone who actually knows his stuff on this subject
> But is there any guarantee Haiku’s code quality
> will be anywhere near as good as BeOS?
I don’t want to bash Be’s developers, but while developing Haiku we were often surprised how poor BeOS is actually implemented in many parts (robustness, bugs, …).
It’s almost a mystery to me why it mostly works that good; I would be very surprised if we don’t surpass it pretty much everywhere. After all, that’s the point of creating a successor 🙂
Interesting.
Axel
Curious, on the processor count (see the Intel story falling off below), just how many hardware threads would be too many for BeOS-Haiku to use, 4 is obviously coming with dual core 2 way threaded, but what happens say on a 32 way processsor that uses 8 cores each 4 way threaded. I’d imagine there is a real limit to how much can be used and that will mostly be limited by the apps being more single threaded in their internals.
transputer guy
I’ve read BeOS source code and have analyzed the structure, and I assure you, it’s not that big of a deal to come up with something more robust! Why is that? Error checking! BeOS does a poor job in handling when it hits limits, and is fond of saying, “I give up! You should never have gotten here anyway, so I’m going to merely pop up a debug message instead of actually handling the error!” and “Message? I no longer have room for messages! I think I’ll just drop this one, and who will care?” while other parts of the system will wait for the message that never comes.
BeOS has hard-coded limits, which isn’t a problem by itself. However, it doesn’t fail in a graceful way when you hit them (most people in their normal usage, but I don’t use things the way most people do) and it has problems where some API calls that can fail have no manner of returning an error code *at all* which is a real problem, and some cases where it does return something, it dumps you into the debugger instead of returning the error code to the program. In other cases, the system simply doesn’t validate the parameters passed into the kernel API, which leads to some interesting things a user level program can do readily. For example, there’s nothing whatsoever that stops any process from stopping any thread, or getting access to and releasing another program’s shared memory at will.
If Haiku merely validated that one process was accessing something it wasn’t supposed to, that would go far towards making it better than BeOS/Zeta for stability. BeOS/Zeta would be incredibly *easy* for malware to target, but there simply aren’t enough to make it worthwhile.
Just thinking out loud here so bare with me…
Uh – I don’t think will be getting bare with anyone here. The word you were thinking is bear, as in to have a tolerance for, or endure.
Point 1:
Sun is opening Solaris.
Point 2:
IBM, Sun and others are making significant source code contributions, (which may have something to do with SCO and indemnity, I’m not sure.)
Point 3:
Palm, if I’m not mistaken, are themselves moving away from PalmOS and into Linux.
Point 4:
Whatever strategic advantages Palm acquired from Be Inc, the BeOS itself was only a part of, and perhaps a part that no longer provides them with any real strategic advantages.
Which leads me to…
Point 5:
Shouldn’t we, therefore, try to organize and advocate to Palm to open up the original BeOS code?
I’m not opposed to efforts like Haiku and the like. What I am proposing could be a big “shot in the arm” for BeOS development, globally. Don’t you think?
Theres one major reason PalmSource -can’t- and hence don’t opensource the BeOS source code. They own very little of it
OpenGL implementation – SGI code (pre SGI’s open-ness)
Font renderer – Bitstream code (pre Bitstream’s open-ness)
MIDI kit – Headspace code
Development enviroment – Metrowerks code
Entire PowerPC toolchain and C library – Metrowerks code, including Apple-patented algorithms (PEF, etc)
Media kit – peppered with Intel, Microsoft, Fraunhoffer, etc code
Drivers – many written under NDA; some bought in from alt.software, a driver vendor
Strip BeOS down to what Be wrote themselves and theres not a lot left. Theres a booting OS, but its not going to have something as basic as a GUI, due to how embedded the Bitstream code likely is.
can haiku take advantage of all the drivers already written for linux?
Thnx guys for the explanation! Very interesting read! Now I’m even more curious of what we can expect from a full blown 1.0 release!
The BeOS desktop is sure starting to show its age compared to Gnome, KDE and OSX. However it’s still a modern OS in so many ways.
Sure it has some very annoying issues and limitations, but the concept and overall design of BeOS is the best I’ve seen in a mainstream OS so far. It is so clean, simple and well thought out. Just by browsing around the system folders you can grasp pretty quickly what most things are doing there. It’s much more logical to me than Windows and Linux in its structure.
Less is more, and everything just works as adviced.
I had to fiddle around for ages with different sound servers and settings to get audio on my linux desktop. And I still haven’t been able to get any audio input. The applications either crashes or gives me errors.
In BeOS there’s one mediaserver and as long as I have a driver it just works.
Since my BeOS partition refuse to boot nowdays (I haven’t investigated it much though) I am using Ubuntu 95% of the time. And while I enjoy Gnome and many of the excellent applications available, I really feel that the system running behind it was never meant to be used by regular people.
With years of using linux I still haven’t got a clue how some things work and relate to each other. Everything is just much more complex than it has to be really.
With BeOS, I had pretty much everything at my fingertips, even though it wasn’t open-source.
For me, BeOS was the best OS at his time because he represented the future of computing and a very good alternative to windows when my sweet Amiga goes “irrelevant”. I hope haiku will be a success but keep in mind that OSX could change many things on the x86 side in the near futur. Linux have made good progress, but is still very complicated for joe user to use. Indeed, we will see some serious battles on the OS side, may be the beginning of the end for micro$oft…