Where is Haiku R1? | Haiku Project

Blog
41

At the time including pm to haiku many devs outside the system main team frustrated because all apps and games need to be rebuild, because many folders are read only and the place fir non packaged apps are changed. We lost many apps, good ones, because they are not open source or the source are not available. Apps like insidecobatructor.

But today i love this pm. I wish to use my payed apps ob haiku but this is away and we need to focus the current system.

I would go a step forward and place the home folder als Container, so one User one home-Container, all other folders are admin part, to get multiuser support to haiku. Admin can set up the size of the home-Container and the user can only install anything into his user container (home part). Thats would be nice.

42

Hi allā€¦ what is a ABI Break? And how long will it take to fix? After this is Haiku R1 beta worked on?

I could not post that comment on the ABI Breakage Page started by Hummdinger, since it is a read only announcement. So I posted it here which is a bit related to a Haiku R1 beta releaseā€¦ thx

Maybe somewhat related to the PkgManagement too but thatā€™s not the object of this articleā€¦

1 Like
43

ABI stands for Application Binary Interface.
It breaks when a change in one of Haikuā€™s kits and libs is not backward compatible with previous ABI.

A recent change in app_serverā€™s BControlLook API does that (in fact it does it because ABI was not yet taken care off).
At start, it was designed to be a private API, but in fact some apps uses it already (and, so, where broken since) andto allow UI themes it has to become a public API.

Anyway, this will be fixed before Haiku R1B is out, obviously.

1 Like
44

There was a bit of bad planning from one of the developers here.

Let me explain in more details. The ABI is the interface between applications and libraries. The application must know how to call a specific function from a library, where it should put the parameters, etc. This is the ABI.

We normally have some ā€œextra spaceā€ left in our ABI for future extensions. This means we make sure it is possible to add some functions or make some changes without applications noticing. This was already the case in BeOS and saved our project many times, as we added extra functionality in many places.

However, not all parts of Haiku are immediately designed in such a way. Some parts are considered ā€œinternalā€ and not supposed to be exposed to applications. This was once the case for BControlLook, the class which implements drawing of all graphical widgets (buttons, scrollbars, etc). At first it was used only inside the interface kit, so there was no need for applications to access it. However, some applications wanted to draw custom controls that looked like the default ones, and the simplest way to achieve that was to use BControlLook directly (with instructions such as ā€œdraw a button-like gradient here, add a tab border here, etcā€.

So, BControlLook became widely used by applications. This was not too much of a problem except for occasional breakage when we made changes to it (not too often, I think the last time was when looncraz added live color change updates to the GUI). However, we should make sure such breakage donā€™t happen again after we release the beta, so, we should add the ā€œextra spaceā€ to this class to make sure we can make changes to it in the future (and in particular, maybe add complete theming support someday).

So, we just did that. The new BControlLook provides an API that should last for the next decade. However, this means there is one last and large breakage to all apps which were already using it. The fix is stupidly simple: just recompile the applications, and in a few cases make minor fixes to the code (maybe 1 or 2 lines per application).

However, the developer who made the ABI change apparently has no interest in updating these apps. It seems he is happy with leaving stuff broken for a few weeks. The long term plan would be for the rebuilds to be largely automated by the package build bot, but that is not quite ready yet (itā€™s making a lot of progress lately, however). And, none of the other developers seem to be willing to fix the problem either. Maybe because they donā€™t have time, or maybe because itā€™s up to the one who breaks things, to fix them.

2 Likes
45

Ah ok thx Philippe and Adrien nice readingā€¦ now I understand!

So the positive thing about this is that it wonā€™t happen after the beta releaseā€¦
and that it is a easy thing to fix and we all learned from this!

So the developer should just go on work on the system and donā€™t waste time compiling the brocken applications.

But at least the ā€œVisionā€ App should be working for communication reason.

Thanksā€¦ great read!

46

You have GOT to be kidding me! Some dev BREAKS the ABI and cheerfully goes his merry way without a care in the world? ARE YOU SERIOUS?!? What kinda mad carnival is being run here?

And now others (i.e. those who are willing (who actually care) and able) have to pick up the pieces? Thatā€™s just not right. But, I guess, you get what you pay forā€¦

47

Hmmm first we should analyse that apps does not run any more. Then we need to know that apps of this have avaialbe sources. And second, this is not the first time breaking apps now, but if it need to make Haiku ready for the futureā€¦ Things need to do, and not all are the winners

48

Thanks for well explaining the issues.

I guess that no matter how much foresight the designers have, issues with changes to the ABI will arise from time to time.

Maybe two lessons learned here:

  1. Developers should refrain as much as possible from using directly ā€œinternalā€ classes as forward compatibility cannot be assured. If they still do so, then the internal classes used directly are to be identified so that changes to their ABI should trigger a rebuild (automated or manual).

  2. When it makes more sense to publicly expose an internal class/function for use by applications, then its API should be reviewed to ensure that it is reasonably future proof. If not, then adding the ā€œextra spacesā€ to do so when there are only a few applications needing it would be preferable than doing it much later (with more applications breaking!).

This leaves me with a couple of questions though:

  1. What happens to older applications now existing only in binary format? Are they stuck to use only nightlies built before the change to the API of the internal class/function?

  2. Is the BeBook maintained to capture such changes?

49

Older apps only available in binary format are from BeOS era, and canā€™t be using an API that was introduced many many years later in Haiku. There is no breakage here possible.

50

Some programs (old ones) used private source files there no one knows if they are for free or protected by copyrights, so the Haiku team starts in the past to through out this source parts to get no problems with copyrights. This is good and needed, but through out this files brings problems with older not open sourced programs, so they are borken.

51

Hi,

great news. I am looking forward to R1. If there would only be 3D hardware acceleration I could imagine I could fall again in love with Haiku/BeOS world.

Best regards
Andreas

3 Likes
52

I think we are pretty clear about private APIs. We donā€™t add them to the Haiku Book, but some clever people use them anyway and then, by copy pasting they propagate from a project to another.

The main problem here is we waited too much before making this public, and the API is really important to apps developers.

53

The package management system was huge distraction, as I expected. I was quite OK with how BeOS 4.5 and 5.0 managed apps - yeah, it wasnā€™t managed, but it was very transparent. You just had a directory with the files and that was it. It was primitive, but it didnā€™t matter, because BeOS was awesome.

I donated to Haiku OS every year except this. I think Iā€™m done waiting for Haiku OS - itā€™s clear it has become Just One of Those Software Projects. You know, big, bloated, and self-serving.

54

I am kinda in the same boat. I know it is an OS being created by those in their spare time but at a certain point, and this is what my father used to tell me as a kid, ā€œshit or get off the potā€. BeOS was wonderful in the 1990s. So ahead of its time. Now we are almost at 2018 and still no beta. Sure there is nightlies but there is a certain point it just seems we will never see Haiku make it. That is OK, I know we all have our own lives. I am not a programmer so canā€™t help make it all happen and sure, I bet it is a lot of work and so much has been done to date butā€¦ there is a certain point folks may just have to move on.

I purchased a nice i7 Maingear about 3 to 4 years ago and made the purchase hoping to install a beta of Haiku on and make it a permanent HaikuBox. Well, still no beta to do it. Time to move on but hope Haiku gets to beta but it may be time for me to stop looking here every day and reading forums like I normally do. Maybe time to let my dream of BeOS/Haiku go.

TJ

55

i love package management. there are things i wish were different but i have no idea how to make them different, and the approach here is definitely new and unique among package management systems. itā€™s never going to be a bad thing to be able to update libraries at the same time as apps easily, and in a modular system such as this or any posix, thatā€™s going to mean something other than new static libraries bloating up every app. beosā€™ approach (almost) worked for it because all the commercial software of the ā€˜90s was monolithic, but now you donā€™t have to look hard to find frustration with every os update and every production software update in osx and windows breaking workflows irreparably. package management doesnā€™t entirely fix that, but it does mitigate it, heavily, and encourage developers to consider the systems theyā€™re deploying to.

1 Like
56

yes same hereā€¦ I look everyday for news about Haiku and reading forumsā€¦
And I hate this behaviorā€¦ I do this for all those yearsā€¦ I am an addictā€¦

All those bugs I reportedā€¦ still many not solved until now! Haiku wonā€™t shut down. Media add on crashingā€¦ Wireless not connecting automaticallyā€¦ and much moreā€¦

Sometimes it works sometimes notā€¦ It is similar to a relationship only not productive at all! My son will become 18 next monthā€¦ He was using Beos, Zeta, Haiku and now Windows! At least there are lots of open source projects to use nowā€¦

Media Converter does not convert files, Screen capture doesnā€™t work as expected you cannot share your screencapturesā€¦ If you create media you cannot make it productive save a pdf or make a video or make musicā€¦
But you can use Vision!

Yes the beta could change the situationā€¦ for good or worse!?
We will see what is going to happen.

57

The beta will not magically fix any bugs. Itā€™s the other way around: first we fix the bugs, then we can consider making a release. We are painfully aware of the problems, but we are a small team and working part time. It is frustrating to see how slowly things are moving, despite all the hard work put into the project.

5 Likes
58

I guess we need more people that wait and read forum postsā€¦

4 Likes
59

Great answerā€¦ thx!

60

Why not just change to a ā€œrolling development modelā€ due to having a small part time team. This will negate the need to keep mentioning alphas, betas, r1, r2 releases etc.that donā€™t materialise - which is causing annoyance and some to leave. Some Linux distros do this kind of thing - just work on apps and donā€™t release many new ISOā€™s.

Also, what percentage of dev time & effort is put into browser development - 50-60% maybe? Wouldnā€™t it be better to concentrate on developing apps that make use of Haikuā€™s unique features. And find a way to utilise webOSā€™s or online browsers for surfing - until more developers come on board to work on a dedicated browser. If feature development is good maybe firefox will make a browser version for Haiku like theyā€™ve just done for ARM. Because due to browser complexity it increasingly sounds like Haiku is a browser with an OS attached to it.