Hello, it has been some time since my last article, in the meantime I continued to improve things out and since I changed some important parts of the media_kit, I think it’s correct to notify the community about new and ‘old’ features added recently. This is an article mostly written for application developers, but I tried to explain the improvements made with simple words so I hope it will be interesting to anyone.
Of all the alternative operating systems from the golden days (2000-2005 or so), Haiku is one of the very few – possibly the only one – still going strong. And by “going strong” I mean seeing a ton of development seemingly without seeing a sort of definitive release. They’re trying to reach zero by endlessly dividing by 2, it seems, getting ever so much closer to zero without actually getting there.
The situation is a bit worse than div by 2, I’m afraid. The amount of blocking issues has been pretty stable at 40-60 the last few years, and as more testing occurs, more bugs are found, some of which are rather fundamental.
What really bugs me (!) is the fact that instead of fixing fundamental problems with Haiku (both the OS and the project), they spend an incredible amount of time porting and packaging tools, which then breaks four months later because the “maintainer” lost interest.
The reason Haiku is not going to see the light is that the core members have no incentive. They are in it “for the fun of it” and Haiku getting released means boring work like avoiding regressions and fixing disk corruption bugs (they’re still there)
All in all, it’s a pretty sad project for all the BeOS fans (those that are left), but probably fun for the hobbyist working on it. Just don’t count on anything getting released, because nobody working on the thing actually wants that, it seems. Go figure.
This, however, is definitely not the case. EVERYONE in the project wants a release. The problem is that people keep adding massive changes/features that cause problems. IMHO, things like package management and launch_daemon should have waited until after R1… they didn’t exist in BeOS, and they shouldn’t exist in Haiku R1.
Yep. BeOS needs a package manager and launch daemon at this point like I need a rash. Just release a stable OS with functional drivers and some basic apps like a word processor and solid web browser.
Exactly. Unfortunately, they really really don’t care about getting the thing released, it’s just a hobby, and not a serious one that led to Linux.
Zeno would be proud of their methodology.
Despite the fact that Haiku is in pretty good shape and very close to usable, there is a feeling that it is currently a project which is floating along in the ocean like driftwood. We need to raise the sails…
Over the years I have kept an eye on a few hobby operating systems which started around 2000.
MenuetOS reached 1.00 a few months ago and it still fits on a floppy because it is coded in X86-64 Assembler and its file system has not evolved beyond FAT.
All three projects re-using the BeFS have issues.
Syllable OS (AtheOS in the earlier years) appears to have stalled at 0.6.x – after a split in development efforts between “Desktop” and “Server”.
SkyOS has stumbled and will forever remain only unfinished since its source code was never released.
Haiku OS is an interesting story.
The project, started from the few open-sourced ashes of BeOS, could not continue using its initial name of “OpenBeOS”. The appearance of Zeta OS as a pseudo-legitimate continuation/extension of BeOS hijacked a number of would be developers – who probably cannot re-use much of the code developed for Zeta into Haiku for contractual reasons remaining in force long after the demise of the Zeta branch.
The project community is currently addressing a number of user wishes in their path for releasing a strong 1.0 version while maintaining a decent binary compatibility with BeOS R5/Dan0 so that the old applications can still be used.
So, we have:
-A modern web browser (port of WebKit)
-An cleaner debugger (to make development of applications and drivers much easier)
-A clean up of the application packaging sub-system
and squashing fundamental bugs associated with the core code of the system.
In some ways, as an user I prefer this over an half-backed “Release” such has been experienced with Windows in its last few iterations.
There may also be a curse arising from the original BeOS Inc. era – shifting objectives…..
I would add that there are two really nice and fast OS to add to the list:
MorphOS
Amiga 4.1
MorphOS really stand out but both of them need dedicated & PowerPC hardware. I’m using my MorphOS on a MacMini G4 and its a blast from the past! Its incredible to see OS that fast on a older hardware.
Thanks for reminding me of the Amiga branch of the family.
Most hobby OSs are also said to be quite fast on an older hardware – I’m not sure if such statement would still hold if this was tested in a systematic fashion instead of general responsiveness to user interactions compared to the OS that originally came with such hardware.
The reason for not being able to use BeOS or Zeta code is that both were closed source and Zeta was found to be an illegal release even if their obtainment, development and sales agreement for Dano was indeed legal whilst Be.Inc STILL was around, that was no longer the case after the demise of Be according to ACCESS corp and later also the German district court.
Bernd Korz (former owner of yellowtab) used to have a website describing why they stopped selling Zeta and why the legal hurdles vs potential economical benefits of contesting those hurdles would not be advantageous to pursue no matter how much he loved the BeOS.
I worked for a gentleman a few years ago who jokingly (but, not jokingly at the same time) would say “At some point you’ve to got shoot the engineers so you can ship the product.”
The insight there is that to an engineer, the product can always be better. Even when everyone else thinks it’s ‘good enough’.
At some point, I keep hoping Haiku will figure out how to either do a fully rolling distribution (with an initial release marking that achievement) or at very least start removing features that don’t fully work, and ship the product they do have.
If one has to shoot the engineers to ship the product, than the quality/timeline targets were likely ill-defined to start with. The reality is that the chief most often passes on the blame for bad/late product delivery onto their underlings rather than accepting it.
The search for “the best product ever” has been the root cause of the demise of many technology based companies/projects. Symbolics is one often quoted as the example of this. However, I do not believe this is the case for Haiku.
Of all the GUI-OS Recreation Projects – e.g. ReactOS (Windows), OSFree and Voyager (OS/2) – Haiku OS is the main one having reached official “Alpha” status. Even better, there has been four iterations for the Alpha. In addition, the nightly builds keep showing progress towards the Beta although I would not be surprised if there is a fifth alpha first.
And, the project has progressed so much in the last six months that getting a Beta pretty soon appears a near reality!
Engineers are going to keep engineering until the last minute; that’s what engineers are supposed to do. It’s up to the Project Manager to set a deadline and insist that the engineering efforts culminate in a stable product before the deadline.
Haiku appears to have no deadline.
Hum…..
Do engineers keep engineering until the last minute because it is part of their training and an integral component of how they work?
Or do engineers keep engineering until the last minute because their deliverables could not be achieved due to unrealistic goals and too few of the brain resources needed for the tasks?
I have seen the latter far more frequently than the former.
Maybe if you give them a week they take a week, and if you give them a month they take a month?
I don’t know any BeOS engineers so can’t say.
Bobthearch,
I will say, jokingly (but not jokingly at the same time) “A good project manager knows to double the estimates given by engineers, but a bad project manager will pressure his engineers to complete the project in half the time.”
Obviously you need a common sense middle ground, but all too often when there is strong top-down pressure to rush, rush, rush, the end result is a turd.
The Package Manager is a very good and needed addition to Haiku and now is the time it is needed most. How many Libs are there in Haiku? Lots. Every time a lib is updated it creates a potential conflict with Haiku and with an App. Did you ever try to install an App only to find out you are missing several libs? So you went to haikuware (gone now) and downloaded Maxlib, with dozens and dozens of libs? And then found out most of those libs were out of date?
This is the problem that Package Manager solves. And you know what else it solves? It solves libs and apps for different platforms. Such as PPC, ARM, and X86-64.
Waddlesplash has a contract to write the server back end that handles the packages. He is working on this now. This is a big part of what is left to finish Haiku Beta 1.
waddlesplash is also the guy who keeps breaking things, like bfs corruption bugs.
Anyway, your “almost done” projection sounds exactly like something you’d write 8-9 years ago about Haiku.
What a joke.
No, I don’t recall that with BeOS.
In fact it reminds me more of past Linux experiences than BeOS.
Everyone i have ever known using BeOS either had their own library archive they installed after main install OR they downloaded the excellent LibPak from bebits.
As long as he kept the pack up to date, everyone essentially had access to the same libraries and all was swell.
Beyond that, there never was dependency problems on BeOS, most applications was contained in the Zipfile that you unpacked unto /boot/apps .
I think one of the problems here is that of continuity – as people feel R1 is getting closer, the perceived 1% of remaining work will seem to need 99% of the effort – and thinking about “R2” means that people want to get “past R1” already. Haiku was always intended to become a certain thing – if people are looking too far ahead, it’s easy to lose sight of the goal. There are people talking about UI changes, others wanting to move the kernel to Linux – but a focus on getting a stable R1 is all that is needed for now. Care about R2+ afterwards.
The biggest problem is that it only the hobbyist developers who are still working on Haiku and as they only want to tinker around with things, a full release(R1) will either be far in the future or will never happen.
Contracted work might be able to make up for this, but this relies on money and thus donations, which in turn comes from the community/supporters. However because the community/supporters are held to such low esteem by the developers, plus the lack of releases or tangible progress for supporters, therefore means that donations are drying up and thus can not be guaranteed to be available to aid development.
None of this can be changed because the project management is controlled by the same hobbyist developers who are quite happy with the status quo, while the administrative board (Haiku, Inc.) is still as dysfunctional as it has ever been (regardless of the recent board member changes).
Further, new developers or contributors are few and far between because this requires them to use an antiquated patch system to supply code, then wait somewhere between 6 to 24 months for a developer to complain that the patch is stale and ask for a newer version. Because the hobbyist developers already have commit access to the code and therefore this issue does not affect them, changing to a pull request system (or the likes) for new contributions will not happen.
To top it off, both negative and positive criticism is unwelcome and is often taken as a personal attack, which means that there is a major reluctance to suggest systematic changes. (This excludes the “suggesttions” made by the troll who is harassing the developers, which are appropriate to ignore)
Ricard,
I think your whole post is insightful, but I can’t vote on it.
You know what, I think that’s the case with most small/indy projects. With Haiku, they have a 2015 goal of $35K, of which less than $8k has been donated so far, some of that no doubt needs to go to administrative overhead like corporate tax accountants. That can’t even cover office rent in NYC where they’re registered. It’s obviously not going to pay many first world salaries, at these levels you are forced to rely on code contributions rather than employees or contract work. When your contributors are comprised of volunteers, they’re entitled to work on whatever they want to work on. Who can blame them?
If Haiku wants more Donations, it has to post news to non technical folks. I stopped donating when I could no longer grasp that any progress was being made to R1.
Why would I want to give money to a project where the developers are chasing their own goals rather than mine?
There should be monthly reports of what was fixed, what new things were added, and there should be new builds for end users each month to test, not the buggy nightly builds. Do that, and you’ll start seeing money rolling in to hire people to work on the important things.
When that was abandonded due to laziness, it made us feel like Haiku was never going to become a real, finished OS.