The FAQ page states that: Haiku aims to be developed under a single unified vision for the whole OS. …
Frankly the only distinguishing characteristic about the original BeOS was the fine grained and extremely effective task priority controls that ensured that foreground application always had priority.
All the current GUI OSes (Windows, MacOS, Linux etc… I haven’t tried Haiku yet) suffer form the same problem. The user is not the first priority. In all cases applications can bring the OS response to a crawl if the application misbehaves for whatever reason.
To have an OS where the system ALWAYS responded to my key press or mouse click would be a godsend.
Is Haiku that OS?
I would say definitely “Yes!” - Haiku aims to honor user requests first and foremost.
Currently, every window of every native application running has its own thread/message queue that responds to user events as quickly as possible. You will notice that while using Haiku, if an application seems to hang (Firefox - with it’s huge amount of non-native UI code, for example), you can still do other things on the system without lag - like switching workspaces, or interacting with other applications.
It’s important to note, however, that Haiku’s scheduler is still a bit immature - and needs some attention. I believe that handling user events will always be top priority with Haiku, as this was indeed a notable feature of BeOS that generally set it apart from other systems.
To add on to what Urias said, Haiku is meant to be a desktop OS, which gives it advantages over Linux and other server-oriented Unix varients. Even when running a Linux desktop distribution you are still dealing with a kernel designed to be run as a server. The user is not the priority.
I think Mac OS X has some element of that as well. I certainly have had my fair share of programs and even the whole OS just becoming non-responsive for several seconds at a time.
As for Windows, well even if they intend for it to be a desktop OS, there is some element of server in it, and worse all the single-threaded applications are just waiting to lock up the moment something blocks. We’ve all experienced a window that won’t repaint or respond because of something it is waiting on.
Because of the multi-threaded architecture Haiku has borrowed from BeOS, non-responsive applications should be much more rare (though developers can still write bugs, nothing is foolproof.) Plus the scheduler is designed to put the user first, everything else second. Though as Urias said, the scheduler still needs work.
Another aspect of Haiku that has kept me interested for a while is the cohesiveness of the system, as you mention from the FAQ. That is where Linux fails very badly in my opinion: by its nature it is cobbled together from all kinds of pieces that don’t always work well together. Understanding even one aspect of Linux can be a challenge, let alone the whole thing together. Then of course there is all the variation between the different distributions. Haiku on the other hand has all the primary parts of the OS written by one team, with common ideas and architecture, and even the code is all written to the same standard. It is possible for one human to understand most of the Haiku code (and we already have a few on the project.)
I also think it is quite fun to write code for Haiku, even though I am far from being an expert in C++, the main Haiku development language.
I guess it’s worth reiterating that Linus Torvalds wrote Linux to run on the 386 desktop PC he’d just bought. Linux was running on desktops from day one.
The “desktop” vs “server” silliness just reinforces the idea that Haiku developers don’t know what they’re talking about. Yes, programming is fun - and so is painting. But it’s more fun if you learn a little about what you’re doing, otherwise you’re just another kindergärtner with their fingers covered in paint, and nobody’s going to know those pink blobs were supposed to be flowers.
I guess it’s worth reiterating that Linus Torvalds wrote Linux to run on the 386 desktop PC he’d just bought. Linux was running on desktops from day one.
The “desktop” vs “server” silliness just reinforces the idea that Haiku developers don’t know what they’re talking about. Yes, programming is fun - and so is painting. But it’s more fun if you learn a little about what you’re doing, otherwise you’re just another kindergärtner with their fingers covered in paint, and nobody’s going to know those pink blobs were supposed to be flowers. [/quote]
successful troll is unsuccessful :\
How about just to build a system without a UAC or Sudo to second guess every users action.
@alex12 well… problems with sudo on Linux are because of misconfiguration normally it is usually quite noninvasive
@NoHaikuForMe give it a rest will ya
Misconfiguration? I just hate sudo because it gets in my way all the time using Ubuntu’s configuration.
The idea behind that is that it’s making sure you’re doing the changes, and not some malicious software that has hijacked your system in the background that is running with your security privileges.
It’s sane - You can probably just give yourself root privileges and do away with sudo entirely if you really want to (or use a distro that doesn’t even use sudo by default, such as Debian).
I never understood why people get all uptight about it personally… it’s for your own good because most people can’t/won’t monitor every bit of code running on their machine at any given time.
“The “desktop” vs “server” silliness just reinforces the idea that Haiku developers don’t know what they’re talking about.”
apparently you don’t understand the difference between hardware and software. A desktop PC that runs a server application as its primary focus is a server.
I think it is telling that I find Haiku’s user interface vastly more responsive than Gnome under Fedora Linux - even though Haiku is running under VirtualBox on that same Fedora system - and so doesn’t have the full capacity of my machine - and Haiku isn’t even Alpha yet, whereas Gnome has been a mature product for years.
Quite aside from boosting the priority of the frontmost process, BeOS had very fine-grained multithreading from the very beginning, and I’m sure Haiku has as well.
But Linux? It didn’t support threads at all at first, and when threads were bolted onto it - painfully - the locking was very coarse. Even now the Linux kernel still has a Big Kernel Lock.
The BeOS had a latency of 2 milliseconds; in my own tests, I found that I was able to play dozens of audio files simultaneously, and have then all mix smoothly. I think I did that test back in 1999 or so. Linux wasn’t able to achieve that kind of multimedia performance for several years, and I expect was only able to do so at all because PC hardware got so much faster.
actually you can build a preemptive Linux kernel for instance I have also compiled my kernel to allow preemption of most kernel code… I dunno about the BKL but I thought they had already removed most of that with Ingo Molnar’s patches