Michael Phipps has a long list of reasons, but I don’t find any of them very convincing. On the whole Haiku still looks irrelevant.
Distribution - Be got this one right and neither Linux nor Windows have. Build all of the libraries that developers need into the OS and update them with an ultra-high quality build every year or two. No one likes to reload their OS and no one likes .dll or .so misery.
It’s hard to say how Haiku could get this more wrong than BeOS. Hardly any useful stuff included in the OS, and what is available comes in several flavours which are silently incompatible. Every popular system today does better, and they’re not resting on their laurels.
BFS - It's journaled, it's as big as anyone will ever need, it has live queries and attributes, it is built for fast throughput at the expense of slower deletes/creates. No checkdisk ever.
Without data journalling BeFS lacks the integrity required for some business critical data. Maybe Michael’s filesystem is as big as he’ll ever need, but if your BeFS isn’t as big as you need you won’t be resizing it on the fly, and Haiku doesn’t do logical volume management either. The lack of integrity and repair tools is hardly a plus point unless your objective is to lose data.
Kits - Everyone building a new language (with the exception of .Net languages) needs to start from scratch on both Windows and Linux - the OS provides you with very little for dozens of common functions (i.e. loading a bitmapped image). We have very powerful kits and more to come.
Rebadging a few features as "Kits" does little to disguise the lack of functionality in BeOS or Haiku. Binding a new language to libraries with a C API in Windows or Linux is far easier than trying to use the Haiku kits in a similar way, even ignoring the horrible C++ symbol mangling.
MIT license - I know that licensing is always a touchy subject, but even the most ardent GPL devotees have to admit that it is easier to talk to potential embedding situations with a BSD license. Certainly an advantage over Windows.
This might make sense if Haiku distributed nothing but MIT licensed code developed by Haiku Inc and its volunteers. Unfortunately any potential “embedding situations” have to hire someone to untangle which bits are owned by who and covered by which licenses. It would probably be easier to buy from an established embedded Linux vendor, maybe even just to pay for Microsoft’s embedded licenses.
Fast Boot/Shutdown - With energy concerns growing, the age-old practice of leaving your machine on (to reduce thermal stress and prolong the life of the machine) is becoming something that people question more and more. Fast booting will allow people to use their machines only when they need them in a more comfortable way.
Of course, when you turn off your machine you lose all your work. Other systems have standby and hibernate modes that conserve power or turn it off altogether without losing your open documents, half-written emails and progress at Freecell. Haiku doesn’t.
C++ - Given a choice between C, C#, Objective C or C++, I believe that the vast majority of developers would choose C++ for native application development. I know that I would.
It’s only to be expected that Michael is behind his own project. Doesn’t make any more relevant than anyone else’s pet projects.
Replicants - People are starting to see the value of replicants with Widgets and a dozen other cute names. We have had them for almost a decade. We need to make much better use of them.
This feature has been around since the 1980s under a variety of names. Every modern GUI system has it. Be’s implementation (and thus Haiku’s) isn’t especially good, but it’s workable. Not much relevance here.
Unity of Direction - No one serious about the Haiku community will go out and write their own windowing environment. They will work from the inside on app_server. Likewise the Media Kit, kernel, etc.
Not so much a reason as a tautology. When people leave or fork the code, Michael can say they aren’t serious about the Haiku community. If they stay they’re “working from the inside”. It’s hard to imagine a project so dysfunctional that it couldn’t make this argument and harder to imagine why anyone would bother.
Simplicity - Every programming project that is not brutally trimmed (and, honestly, very few are) grow hoary with age. Functions are obsoleted but not removed, reasons for performing a particular action become irrelevant, hardware is discontinued but the code doesn't change. Haiku, even though it is using the BeOS API, is a fresh start.
4.5 years ago Haiku was a fresh start. Tomorrow someone will make a fresh start on something else. That doesn’t make either project relevant.
Multi-Threading - Designed with and for multi-threading from the ground up, Haiku will make better use of the dual, quad (and more!) core chips that are the future. It makes our windowing feel snappier and more responsive.
Everybody has multi-threading, although without Be’s involuntary “pervasive multi-threading” that made it such a nightmare to develop for. In regards to multi-processor and especially today’s non-uniform memory designs, Haiku is a mere toy. It has almost a decade of basic work to catch up on.
Focus - Everyone else out there is determined to be in as many "markets" as possible - much like the old story about the whole world looking like a nail when you hold a hammer. When doing anything in life, there are tradeoffs; software is no exception. The same tradeoffs that make an OS good for the desktop make it less than ideal for a server. With a solid focus on the desktop, we will exceed what others are doing on the desktop because they are doing a dozen things.
Didn’t Michael mention embedding a few paragraphs ago? How is that an example of “focus on the desktop”? Software is an exception to a lot of rules, and this is one of them. Ideas percolate from tiny embedded devices and from big iron, systems with a broader horizon benefit, staying ahead of the game.
Small Footprint - While machines are getting faster, with more memory and more hard drive space, Haiku is staying small and efficient. That means savings to users who won't need to buy the newest equipment to run the OS. It also makes us more fit for endeavors like the $100 laptop.
We haven’t seen any evidence that Haiku is “efficient” and small can mean lacking in features, rather than actually doing the same things in less space.
Files are Power - Our e-mail and people files are a concept that I don't see on other operating systems. The power of MIME-typing and standardization give us the power to create a desktop that has more interoperability and flexibility than any other. It is trivial to switch between mail applications or contact management applications on Haiku.
The email-as-file is so old I couldn’t even find an origin for it. The most popular example still in use is called Maildir. It’s trivial to switch… so long as all your applications store the same things in the same kinds of files and in the same way. Which makes Haiku no better or worse than any other OS.
Add-Ons - Rather than making monolithic libraries, we build frameworks and add-ons. The Translation and Media Kits are great examples of how this can make the operating system extensible between releases in easily understood and maintained ways.
The same facilities exist on every other platform, often put to much better use than in BeOS, it remains to be seen whether Haiku can catch up.
"Do The Right Thing" - We have a focus on the user experience that others lack. Rather than dozens of confusing options hidden behind wizards, we strive to make the software do the right thing: go the extra mile and figure out what can/should be done, choose the best setting by default, etc.
Every UI design group has been claiming to do this since at least the 1990s, probably earlier. Haiku is no more relevant on this front than OS/2.
Relocatability - You can take the Haiku installed hard drive out of one PC, put it into another, and it will "just work" (assuming that we have the drivers). Backups, likewise, can be done just by copying files. No system files that can't be copied, no ghosts required.
The same “relocatability” is present in other systems. Haiku may avoid “system files that can’t be copied” but it’s foolish to imagine that this alone does away with the need for Ghost or similar image software. You need robust, configurable, automated installation for anything beyond SOHO.
API Stability - Our R1 will be binary compatible with R5. That means that applications from the late nineties will work on a brand new operating system. That is the sort of environment where people can feel confident in investing in software; they know that they will be able to run it for years to come. It is also the sort of environment where driver developers can feel confident knowing that they can develop a driver once and have it work for years.
With the exception of Apple (who’ve changed OS fundamentals and CPU architectures in that time) everyone else can run applications from the late 1990s on their brand new system. Of course they can also run much newer software with features invented this century.
Scripting - Every control in Haiku is fully scriptable. Every app, via those controls, is fully scriptable. Many apps have their own scriptability beyond the built-in scripting. BeHappy is a great example. While there is no "official" Haiku scripting language, it is fairly easy to add sending and receiving of BMessages to most scripting languages, making any language able to script Haiku apps.
This is true on other popular systems as well. Of course, when there’s a wealth of really good application software, and particularly when its available as source code for your own use, people spend less time trying to kludge things with scripting.
"Console vs. GUI"-Agnostic - We provide the best of both. Some people like command lines. Some people fear them. Some people use both. We let the user make that choice.
Ignoring for a moment the fact that BeOS applications can hardly be said to be “the best” of GUI software, this is essentially true of all the popular systems, with the possible exception of Windows (great CLI tools for Win32 are widely available but they’re not included in the box)
Community - I have had the opportunity to meet many, many people in the Haiku community. They are, without exception, the nicest, most helpful, kindest, most friendly group of people I have ever met. Even the ones on BeDoper.
On the whole Haiku fans seem like typical “alternative computing” types. People have written equivalent things about Windows users, librarians, Nigerians, and many other groups. It’s pretty irrelevant. Most people are nice, if you’re nice to them.
