I’m a brand new Haiku enthusiast–I loaded it on a USB and ran it on my old 32 bit Dell. It’s fast, and it’s easy. But I’m very inexperienced with non-Windows OS, so figuring out what to do to get it running properly if I load it onto my hard drive is a steep curve. So when will this be out of beta? When will you have an active help forum (your current one’s last questions date from 2017)?
Hello, and welcome.
About one of your questions:
You already are in it. Feel free to ask any question or help request.
1 Like
I’m not on the Haiku dev team, but to give a guess based on history of the project, minus the really big 6 year gap between alpha 4.1 and the first beta (November 2012 - September 2018), the alphas (1-4) were released within a year of each other (9/09, 5/10, 6/11, 11/12), 64-bit support came a year after (July 2013), and Beta 2 itself was released last June. (Source for everything is Haiku’s history page). So going by the usual timeline over its history, hopefully R1/Beta3 will be out sometime in 2021, with Release 1 (R1, 1.0, whatever) finally out in 2022. If there’s a delay between B3 and R1, maybe 2024. For the very latest Haiku in the meantime (has more bugs, but also more fixes and features), there’s the Nightly branch. Plenty of places are available for help; main hub of everything seems to be the forums here. Hope this helps 
2 Likes
What makes you think there will not be beta 4,5,6, and so on?
Beta4 will be created when beta3 is released, and so on.
If this is really true… then what’s the future for the project? What’s everyone doing this for? That’s years in the future just to reach R1 alone 
Why not switch to a rapid release model as a compromise? For example, while there’d still be Nightlies and background work on R1, there could be yearly snapshots like 2021.01, then 2022.02 and so on as semi-stable builds.
What’s the difference to beta 3 then beta 4? As far as I see the developers aim for roughly annual releases already.
Mostly-yearly releases is what we do. They are called beta because of the large number of known bugs and limitations. If you think they are good enough for you, you can use them.
We can change the way we number/name releases but it won’t change the development speed.
Yes, R1 is still years ahead. It has been so for the first 20 years of the project already. Why would it suddenly be a problem? We have set big goals and we will reach them eventually.
Having been following Haiku since the beginning I think the biggest problem for some people for having R1 years in the future is the feature freeze and strict development goals.
Personally I think that is a double edged sword.
On the other hand, having strict BeOS R5 compatibility as a goal and releasing R1 “when it’s ready” is great thing, it helps the developers concentrate on those wanted features and users, even the early adopters, will know that they are getting, stability of the API to work on apps etc. I also think it is essential to release R1 only when it is as bugfree and usable as possible.
On the other hand, the features and fixes that are promised to R2 and beyond and, if I remember correctly, there have been some talk on BeOS R5 design flaws that cannot be fixed until breaking R5 compatibility, are on indefinite hold. Sure, there have been improvements over BeOS R5, like wifi support, experimental bluetooth support, Stack & Tile, layout kit, notifications, 64 bit version, ongoing ARM port etc, but since Beta 1 there have been a feature freeze, so no new features are added until R1.
To solve this problem I think an experimental branch could be created to allow developers to add new features when they want to try new things, want to have a feature that is not in the goal of R1 or plan something post R1 that would break BeOS compatibility etc. That might even attract some new developers who are not familiar with BeOS but would like to work on a desktop operating system project. Some of these experimental features could be even backported to R1 or future betas provided they would not break compatibility and thus we might get some post R2 features on R1 too.
The feature freeze for betas is not all that strict and new things keep being added. Anyone can decide that a feature is too disruptive and work on it is a separate branch (I see no reason to put all the experimental features together in a single branch where you are never sure who broke what).
The developers are mainly focused on R1 and other changes that make the system better. We don’t have a lot of contributors and it seems better to focus on finishing R1 (already a lot of work) rather than split the team and have people working on things that are for an even further future?
Me neither, but having a post-R1 branch where some of the changes that cannot be implemented in R1 could be useful for having them in the open to ensure compatibility, or have developers who might have found a design flaw in BeOS R5 to test a possible fix to that until R1 is released and before forgetting the details.
Or some branch where a collection of more mature experimental features could be found without digging through developers personal github repositories.
I completly agree with that and dind’t mean to suggest splitting contributors to different teams. As I understand, devs work on what they want to work on, and sometimes they might be willing to work on Haiku but don’t feel like those tasks at hand that are needed for R1 release. Having those in the open might make those new features more compatible with R1. That might attract new developers who are interested working on post-R1 features without splitting the current teams.
I don’t know any serious design flows that require incompatible API changes. I think that API compatibility should be kept forever. Otherwise all existing progress and software will be lost. “Stable API is nonsense” Linux approach is terrible and it cause a lot of software to stop working because there are no enough manpower to fix after changed API. Windows have managed to keep API design almost unchanged from Windows 1.0. Fundamental changes was only needed for 16->32 migration.
As I recall I think there have been talks of Media Kit design flaws and BFS flaws that cannot be fixed in R1. I’m not familiar with either so I cannot comment of their validity, but I recall reading about those ages ago.
I don’t advocate for breaking the API, but using those examples, if someone who has knowledge of fex. Media Kit design flaws has intent, time and knowledge to write Media Kit 2 that would fix those flaws and be compatible with media kit, in a way like Midi Kit and Midi Kit 2, I think it would be better if the work was in open and not buried to that someone’s github repostory in some branch, in case the developer loses intrest.
We don’t use github and are not hiding our changes in some secret place. The supposed experimental features either don’t have any code (they are just tickets in trac), or it turns out they canbe implemented without breaking BeOS compatibility after all.
You can check the R2 milestone on Trac for things we have not figured out how to do while keeping BeOS compat yet. You can also check the “apichangesoncompatibilitydrop” page on the wiki for some more. You will find out that there is only a small number of things and maybe not all that important after all.
3 Likes
If someone worked on a media kit 2, they could put it side by side with media kit 1 in the same repo and the same branch.
The supposed problems with media kit were only in the mind of a single developer, who was banned from haiku because they had a “let’s rewrite everything, I know better” approach to things and were insulting the work and competences of theother developers. I think it was not a problem of organization of the git repo.
As for bfs, yes, it does not handle hardlinks, that’s the main limitation. But Haiku already handles many filesystems and bfs2 could be added to the list when someone decides to work on it. So it’s another thing that can very well be done before R1 if someone decides to.
2 Likes
Never meant that. But during the years of following Haiku I’ve seen some interesting features that had some code, but then the developer lost interest and those have been buried on their own github accounts and forgotten. If those had been on some experimental branch it would be easier for someone interested to pick up and continue the work as they might have been kept up to date with current changes and at least they would be easier for interested developer to find.
Links please.
From top on my head I recall few unfinished starts to implement dri and 3D acceleration, fatelf support and few unofficial kits. Probably all of them not needed anymore though. I’ll find the links as I get back to computer.