What's so good about Haiku anyway?

One of the statements on the about Haiku page is “What’s so good about Haiku anyway”. Highlighted below is the snippet from that page.

Just curious is all, is that Haiku now 10 years after it was started, and at an Alpha stage right now, are these highlights still relavent in todays computing world.

I am not a programmer but a user, and can understand some of the things below, but I guess one thing that comes to mind is, what OS does not already focus on “personal computing” these days. I would think even Linux has become more user friendly that many folks can install and use it.

Is this “personal computing” statement still a major point of Haiku and what is different about Haiku’s personal computing approach over other OSes such as Mac OS X, etc…

I guess something to comes to mind, is after 10 years now, does Haiku really offer us something over other OSes or is this just a hobby for some here that have memories of the BeOS past and want to keep it alive.

Don’t get me wrong, I liked BeOS then in the 1990s, still like it today in a retro feel kind of way, but wonder if Haiku gives us something much better than other OSes that are not Alpha, not Beta, but shipping product.

From what I understand it will take another 5 years before Haiku is out of Alpha and Beta and by then, computing may be much different than we see today and wondering if at the speed things are progressing now, if Haiku would ever be of mass appeal values.

TJ

What’s so good about Haiku anyway?

The key highlights that distinguish Haiku from other operating systems include:

Specific focus on personal computing
Custom kernel designed for responsiveness
Fully threaded design for great efficiency with multi-processor/core CPUs
Rich OO API for faster development
Database-like file system (OpenBFS) with support for indexed metadata
Unified, cohesive interface

I highly doubt the 5 year time span. I am thinking like next year if all goes well we could see R1. In all seriousness !

Haiku offers

Responsive desktop interaction
low latency subsystems
easily implemented application inter messaging

there are tons of advantages to Haiku, the problem now is a lack of forward development on applications.

I forget where I saw that 5 year for non beta OS. Might of been an article or forum post around here. But I remember the #5. hehehe

If next year, that is cool!

I take it R1 as you call it means non alpha and beta state but a first official release?

tj

The one area I am hoping to be pleasantly surprised with is the responsive desktop interaction. I tell ya, in OS X, I am growing tired of clicking on stuff and icons hoping around in the dock forever and things happening. I want to click and it just happen. :sunglasses:

In my testing of Haiku on my Mac Mini 2010 model booting from a USB Thumb Drive, I did not feel explosive responsive desktop that I remember. My guess is running off a USB Thumb drive is not optimal and blame that for now. Since my Mini is mission critical for work, had no plans on trying to install on hard drive, etc… Plus since sound and the 2010 mini for Haiku is dead, why bother.

I am exploring building a small atom based Haiku box and hoping I can have a fast little Haiku box on my hands. Hoping for that responsive desktop as you noted above. Hoping to not be disappointed.

If this one feature, responsive desktop, can happen with Haiku, I may become a fast believer. I know how good my BeBox is for its day and age but wanting to see so much more with a HaikuBox on dual 1.8ghz atom based box.

TJ

[quote=macsociety]The one area I am hoping to be pleasantly surprised with is the responsive desktop interaction. I tell ya, in OS X, I am growing tired of clicking on stuff and icons hoping around in the dock forever and things happening. I want to click and it just happen. :sunglasses:

In my testing of Haiku on my Mac Mini 2010 model booting from a USB Thumb Drive, I did not feel explosive responsive desktop that I remember. My guess is running off a USB Thumb drive is not optimal and blame that for now. Since my Mini is mission critical for work, had no plans on trying to install on hard drive, etc… Plus since sound and the 2010 mini for Haiku is dead, why bother.

I am exploring building a small atom based Haiku box and hoping I can have a fast little Haiku box on my hands. Hoping for that responsive desktop as you noted above. Hoping to not be disappointed.

If this one feature, responsive desktop, can happen with Haiku, I may become a fast believer. I know how good my BeBox is for its day and age but wanting to see so much more with a HaikuBox on dual 1.8ghz atom based box.

TJ[/quote]

BUY a AMD Zacate system E series APU, they are cheaper and they run circles around the ATOM. USB it usually slows for the first boot or 2 and then it seems to run close to HDD speeds. I find Haiku works best with 2gb of ram from a USB stick. just seems like it can cache enough that it really gets moving nicely again.

I would divide them into two groups:

Specific focus on personal computing
Rich OO API for faster development
Unified, cohesive interface

These three are generic claims that could have been made by lots of systems from the past decade or more. None of them is particularly more believable about Haiku, and they all require some squinting to seem true, for example the “unified cohesive interface” is achieved by having only a handful of applications, and discounting any that present an unusual or distinctive interface since they contradict the claim.

Custom kernel designed for responsiveness Fully threaded design for great efficiency with multi-processor/core CPUs Database-like file system (OpenBFS) with support for indexed metadata

These are more technical claims, where you can point to something in Haiku that attempts to specifically fulfil the claim.

Firstly “designed for responsiveness” roughly equates to “our scheduling quantum is short” and “we’ve put lots of tuning effort into our scheduler”. Well, everybody offers short quanta today and Haiku’s scheduler has actually sat unloved on the back burner.

“Fully threaded design” refers to the needless requirement that programmers handle one thread per BWindow in the BeOS API. It’s a design bug, as much as anything, and Haiku actually lacks decent affinity and does not scale to multiple CPUs “efficiently”.

“Database-like file system” is probably the strongest claim. BFS isn’t very much like a database (its predecessor OBFS was, but Be got rid of that because it’s tortuously slow even compared to BFS). However building the metadata index into the filesystem is a more or less unique feature. Possibly because other developers have looked at it and shook their heads at the overheads and weak performance justification.

[quote=NoHaikuForMe] I would divide them into two groups:

Specific focus on personal computing
Rich OO API for faster development
Unified, cohesive interface

These three are generic claims that could have been made by lots of systems from the past decade or more. None of them is particularly more believable about Haiku, and they all require some squinting to seem true, for example the “unified cohesive interface” is achieved by having only a handful of applications, and discounting any that present an unusual or distinctive interface since they contradict the claim. [/quote]

Whats up Pete B.

Haiku is desktop/workstation focused. No arguments about that can be made

Haiku has a strong C++ api that offers allot of really great features to wright programs, its so good Trolltech basically copied it and called it QT with some changes.

the cohesive interface is that all base system functions in the OS try to have a similar look and common sense approach to use and implementation. The API also trys to be consistent.

Applications have nothing to do with the system itself.

[quote=NoHaikuForMe]

Custom kernel designed for responsiveness
Fully threaded design for great efficiency with multi-processor/core CPUs
Database-like file system (OpenBFS) with support for indexed metadata

These are more technical claims, where you can point to something in Haiku that attempts to specifically fulfil the claim.

Firstly “designed for responsiveness” roughly equates to “our scheduling quantum is short” and “we’ve put lots of tuning effort into our scheduler”. Well, everybody offers short quanta today and Haiku’s scheduler has actually sat unloved on the back burner. [/quote]

And yet, linux osx and windows all have horrifically blocked GUI response. go figure

[quote=NoHaikuForMe]
“Fully threaded design” refers to the needless requirement that programmers handle one thread per BWindow in the BeOS API. It’s a design bug, as much as anything, and Haiku actually lacks decent affinity and does not scale to multiple CPUs “efficiently”. [/quote]

It encourages threading in a asynchronous manner, which improves user interaction. you may argue the semantics if you like. User feedback says, users like it.

[quote=NoHaikuForMe]
“Database-like file system” is probably the strongest claim. BFS isn’t very much like a database (its predecessor OBFS was, but Be got rid of that because it’s tortuously slow even compared to BFS). However building the metadata index into the filesystem is a more or less unique feature. Possibly because other developers have looked at it and shook their heads at the overheads and weak performance justification. [/quote]

BFS has no real performance problem I know of, yeah its slower at deleting large numbers of files and a few other tasks,however those tend to be server functions and Haiku is not a server OS, but its fast at access and finding files folders and paths. I’ll take the trade offs. In this world where lots of bad developers are out there, I generally take those comments with a grain of salt. ZFS is just a better version of OBFS and BFS anyways. Looking at the overall design of ZFS I think that will be the future Haiku filesystem for R2 and beyond.

you have a good day Pete. !

We’re making up silly names for people now? Perhaps I shall call you Gomer Pyle.

Qt pre-dates Haiku by a long way, it was begun in 1991, BeOS DR1 didn’t appear until 1995. Moreover, Qt is primarily a modern widget toolkit, the rest of the framework exists to support that, whereas Be were building an entire OS API. Be’s GUI API doesn’t even do scalable UI (every scalable Be program has hand crafted code to make that happen), even fairly trivial Qt applications would require extra work with Be’s API, only in Haiku a decade later has work begun on rectifying this problem.

Applications are the whole point unless it’s your hobby to install new operating systems. So that’s a few hundred OSNews readers covered, but any ambition beyond that is dependent on applications.

When you do a like-for-like comparison, I don’t think Haiku comes off any better here.

There’s no evidence that this improves user interaction. In the usual cases cited there is only one GUI thread that ever actually does anything, the others are simply created and then sit idle throughout, they aren’t contributing to the behaviour of the system in any way, they just waste resources.

Even Haiku’s own developers acknowledge that BFS performance leaves a lot to be desired. Too many routine operations are serialised.

There is no more resemblance between ZFS and BFS than between BFS and FAT. ZFS is a COW object filesystem with built-in redundancy, volume management and integrity maintenance features that would otherwise be the preserve of RAID and LVM subsystems.

Today’s always a good day to learn something, Gomer.

I can tell your Peter Bright from ARS technica, just by your commentary style.

Umm, one of the lead engineers at Trolltech, was a former Be Engineer. actually a lead engineer. the QT api has a similar design to the BeAPI and its very noticeable from version 4 onwards. It definately shares roots and the similarity don’t surprise, as the same guy had a hand in both.

Dooh.

Wow, so few applications, that I even posted this with a native application. your fialing here. I don’t need 400,000 applications, just a few really good ones, just like everyone else. We already get it. you won’t develope for Haiku. Considering they have the ball and the bat, just go home.

[quote=NoHaikuForMe] When you do a like-for-like comparison, I don’t think Haiku comes off any better here.

[/quote]

Considering I use all 4, I think I have more authority to speak on the subject then you do.

[quote=NoHaikuForMe] There’s no evidence that this improves user interaction. In the usual cases cited there is only one GUI thread that ever actually does anything, the others are simply created and then sit idle throughout, they aren’t contributing to the behaviour of the system in any way, they just waste resources.

[/quote]

Here I am, I am saying, it works better for MY expectations, continue to dribble on your chin if you wish.

Geuss what, the device is serial, you can’t escape that, and despite the supposed issue you raise, I find my system performance markedly better using Haiku then OSX,Linux,Windows. So you think what you want while I enjoy using my computer.

Your call.

Really ?

Maybe on the low level side there are substantive differences, they have many similar design goals. Nevermind that ZFS was designed several years after OBFS and BFS and likely had a chance to really look at all the fialing of given file systems.

But whats your point again ?

Well check it out Pete B. you ain’t got nothin to teach.

Hey all, I now have a dedicated HaikuBox to use for Haiku. And yes, even on a small dual 1.8GHz Atom based PC, Haiku is indeed responsive.

I am a BeBox lover and have been rooting for Haiku but was unsure how it could compete today and if Haiku is up to snuff.

Well, I must say if this is any indication, Haiku on my Atom is fast, I bet it screams murder on a Quad i7 system. :sunglasses:

Anyway, follow this thread for future developments of my Zotac Zbox running Haiku.

https://www.haiku-os.org/community/forum/finally_have_my_little_haikubox_zotac_zbox

Keep the faith! :sunglasses:

TJ

[quote=thatguy]I can tell your Peter Bright from ARS technica, just by your commentary style.
[/quote]

I’d never heard of “Peter Bright” before Axel Dörfler linked an Ars thread where he and Stippi are apparently disagreeing with Peter. Was the point of that link to suggest that I’m the same person, even though my background, opinions and interests are different? Is that what Haiku’s community has come to?

They don’t “share roots” as I already explained, Qt dates back to 1991. Benoit joining Trolltech in October 2005, four months after Qt 4 shipped, and then after Nokia bought the company he shifted to working more with Nokia’s Symbian platform, jumped ship again for a smaller outfit, then left his new employer to work at Facebook. I guess he’s just a restless kind of guy, or he needs the money (for someone like Benoit these changes of employment would mostly come with increased financial compensation).

This is the same mistake people make when trying to understand why products like Office are popular. Everybody’s needs are slightly different, so breadth works out to be important. And of course there’s a difference between “it works, barely” and “ideal”. For example, on most platforms the web browser helps correct your spelling when writing forum posts, but it seems the system you used did not provide this.

Serialisation of low-level operations in the filesystem code is not tied to the fact that disks (were, once) only capable of executing one I/O operation at a time, nor to the fact that the standard by which they’re connected is referred to as “serial”. It’s a failing of the filesystem design. Would you be more comfortable hearing this from Axel?

It’s part of the reason why compiling software on Haiku is slower, for example (there are lots of reasons, the compiler gives the OS quite a workout, and Haiku is pretty flabby).

A COW object filesystem is completely different from the extent oriented BeOS BFS, let alone OBFS. If you want an example of a filesystem that has similar design goals to ZFS, you can look at btrfs in recent Linux kernels. I doubt the designers of either gave BFS more than a casual glance, it really isn’t anything unusual (except for the “metadata index” thing, which neither ZFS nor btrfs do of course).

That indeed this list is not relevant.

It seems you needed at least one lesson: I am not “Pete B”.

I think Axel posted that link to Ars Technica, because the topic of that thread was Haiku’s scheduler and the comments of that Ars article shed some light on the opinions of some Haiku devs on that. I don’t think your person entered into it at all.

Don’t mistake the whole Haiku community to the two or three guys that keep falling for your trollings. Most of us know that Haiku is very far from perfect and don’t look at a distorted reality through rose-coloured glasses. It’s a bit funny but even more sad, to imagine you sitting on your sofa, surfing into these forums every other week to post a few condescending comments, and then waiting gleefully for the inevitable few to take the bait.

Regards,
Humdinger

That’s a fair point.

I actually expected that, having taken an interest in the thread at all, Axel would fix the bug. I was interested to see whether he would acknowledge the inspiration or whether it would just be fixed silently. But instead the whole thread passed into history, a possibility I hadn’t considered. Maybe I was too subtle.

Don’t have a sofa, but I appreciate the mental picture. You may underestimate how much work it is to write critical commentary like this. Although Haiku does make it easier than BeOS because instead of speculating and then having to write rigorous tests, one can review the source code to confirm ones suspicions. Still sometimes it takes me a while to remember to do that, I spent some minutes staring at the crazy memory usage results in Haiku’s About dialog before it occurred to me to look in the kernel source code and find…

// TODO: We should subtract the blocks that are in use ATM, since those // can't really be freed in a low memory situation.

So for example if a program loads a 200MB picture into RAM, Haiku accounts this as “file cache” and not used memory. A Haiku system with 2GB of RAM and showing only “88MiB used” may actually be full to bursting, you’ll only know if you try to load more data. This was so incredible that it actually took quite a while to grasp, yet so far as I can tell it’s purely an accident, albeit one Haiku’s developers are in no hurry to fix.

Hello ,
Im not trying Haiku for about 48Hours so im not an expert yet :smiley:
I run Haiku on a very old and slow computer with about 512MB RAM and
a 1.6GHZ CPU and i was surprised how fast it boots up and how fast a
program starts.Well on newer computer it might run faster.And other systems
are still better to example Windows 7 wicht coast about 100€ and take years of
development with houndrets of programers.
The next point why i think that Haiku is a nice OS :
Its nice when you want to write your own software.To create a Window in Windows
you have to write many lines of complex code.In Haiku it is realy easy
to show ‘Haiku Rocks !’ in a window :).And think : it is easy to write a program
so it is easyer to write better programs than in other OS.

I’m sorry about my bad english , i try my best to make it better :smiley:

Pretty sure that finally just got fixed, and it sure annoyed me too, such that I logged a bug.

With your knowledge and technical skill you could write some useful bug reports, or for goodness sake, FIX BUGS.

But I guess you don’t consider it worth your time?</not_being_sarcastic>

Also for anyone listening, don’t try to argue technically with NoHaikuForMe, he/she will eat you alive, i.e. he/she knows their shit.

That’s annoying me. NoHaikuForMe is putting a lot of energy in arguing against whatever we do. With all that knowledge and effort, instead he/she could be an asset. What I am saying is; Instead of picking on what you (NoHaikuForMe) think is bad with Haiku, help us change it to the better.

Just to set that one straight: I have no suspicions that you are Pete from Ars; he’s not cynical, he just misses the point. Personally, I usually enjoy reading your posts as I’m rather fond of cynicism, I hope that doesn’t spoil it for you :wink:

deejam and thatguy,
you fail to understand that NoHaikuForMe should not be blamed, but instead we can be thankfull for his comments.
If somebody is spending his time to show you your own weak points, it’s one of the greatest gifts that you can get. That way you are more likely in the future to correct them.
If somebody telly you how great you are, then perhaps you will feel happy, but in fact you win nothing, you can win much more if somebody shows you your week points and limitations.
People who are criticizing Haiku are more important that people who say how great something already works in haiku. It’s always good to know the weak points too, but if we want to improve we need people who are telling us what they dont like about haiku (and what’s wrong in their opinion).

[quote=cipri]deejam and thatguy,
you fail to understand that NoHaikuForMe should not be blamed, but instead we can be thankfull for his comments.[/quote]
I’m not blaming anybody. I said that NoHaikuForMe would be an asset contributing to Haiku with all the time and energy spent writing (mostly negative) about Haiku.

Firstly “designed for responsiveness” roughly equates to “our scheduling quantum is short” and “we’ve put lots of tuning effort into our scheduler”. Well, everybody offers short quanta today and Haiku’s scheduler has actually sat unloved on the back burner.

“Fully threaded design” refers to the needless requirement that programmers handle one thread per BWindow in the BeOS API. It’s a design bug, as much as anything, and Haiku actually lacks decent affinity and does not scale to multiple CPUs “efficiently”.

I take exception to this comment. You should know better. You know and you’ve commented that the scheduler is minimal. Designed for Responsiveness is all about the messaging and the BLooper construct of the apps. It’s real, and it’s a real advantage.

Although Haiku currently lacks affinity, I haven’t seen any benchmarks that support your claim of scalability.

Please put a little more effort into your rhetorical claims.

And for anyone interested in detail about Haiku, apps, messaging, BLoopers, BWindows, etc, there’s this:

  • http://www.osnews.com/story/24945/A_Programmer_s_Introduction_to_the_Haiku_OS