Those are arguments consistent with my point on the despotic approach. As you pointed out, all depends on your needs and preferences. Hoping to get all things done necessitates a lot of time relative to resources. Furthermore new needs will always appear, that’s why I am talking about “sacrifice” but only for the release. Otherwise you will always have a moving target and it’s difficult to get a release out.
Again, there is no right or wrong here. It is only food for thought.
Please do not blame the ELF format for my own stupidity when I decided to link libtracker or libbe to libshared without taking care of this.
The ELF format provides everything needed to do this properly and support in modern compilers is good. The proof for this is that this is exactly what we used to fix the proplem now.
The issue is made worse by having to support gcc2 which doesn’t do hidden symbols very well, but that’s a problem of obsolete tools, not a problem of the ELF format.
You can however complain about the tools, even today, having an “everything is visible by default” approach. That’s annoying and should be fixed at least in our version of GCC.
Then please answer my questions. Which parts and features of Haiku, exactly, would you remove in your supposed R1?
Also you seem to have missed one key part. The change in milestone was decided collectively after the alpha 1 release. There was a large poll of both users and developers back then, to re-evaluate the goals. And, yes, this was done at a time where we just had shipped the first alpha, there was a rather large and active team of developers, a lot of excitation and… everyone was way too ambitious in the things we should add. Seeing what happened then, several years without releases after alpha 4.1, the work on the package manager that ended up much larger and complex thna expected, etc, maybe it was not the best choice. But this was voted in by both the users and developers, and it also had its upside: it really helped keeping Haiku relevant. If we had stuck to the initial goal of just replacing R5, yes, maybe we would have reached it a few years earlier.
But it was already too late for that goal anyway. Not a lot of people were still running BeOS or Zeta even in 2009, everyone had either already jumped to Haiku or to some other OS. So that part of the appeal for the initial goal of Haiku was already lost. And this meant setting new goals was necessary. At that point we could have decided to drop the old goals. We didn’t, and we just added some new ones, but we didn’t want to give these new goals a lower priority than the existing ones. And so a compromise was made: keep the old goals, and add the new one with the same priority, in the same milestone.
Wifi wasn’t part of BeOS. According to your own posts, we shouldn’t work on it. Same for the PDF viewer and a web browser able to work with any modern standard. Same for sound since the main problem there is lack of support for mordern hardware (that BeOS also doesn’t have).
They are nightly builds. They are work in progress and yes, during this work, things do break. That’s how software development goes anywhere. If you had access to nightly builds of any other OS it would be no different.
You are however correct that we should do beta releases more often, maybe every 6 months.
You are very much involved in this discussion for someone who doesn’t care about Haiku. It looks like you are pretending to not be interested, but that doesn’t seem quite true…
The current situation can be very frustrating for everyone. None of us like to see our machines broken by an update. None of us developers like to spend hours, or days or weeks, debugging an issue with a regression or a new bug when we wanted to get useful work done. But that’s how software development goes, especially given our lack of a formal QA team.
I have already asked here but no one seems to be in for setting up the practical details on how to actually achieve that (trolling is more fun, I get it): please go over the tickets in the R1 milestone on Trac. Please tell us which ones exactly we should remove from the milestone in order to reach R1 quicker. I have done my job in that area, as I moved a lot of tickets to an R1.1 milestone (there has been some extra movement since then but the initial effort was me doing what I suggest here).
A great way to make everyone else leave the project. Or, if you want to tell me what to work on, you pay me to work on it. Otherwise, I’m here to have some fun during weekends and I work on whatever I want. If you want to see progress in Haiku you have to compose with that: only one of the developers is paid and can - to some extent - be told what to do (to some extent, because if you make him unhappy enough he could also just quit the job). So you have to compose with that.
Why is it that way? Because this organisation is, in a way, self-sustaining. There are people who try to join the project but expect to receive directions on what to do, but the project isn’t set up for that, so they get bored of having nothing to do and they leave. On the other hand, there are people who appreciate that they have some freedom here to work on whatever they think is fun, valuable or interesting, or whatever motivates them to contribute. And this allowed us to build a place where people can continue to work on the project, for two decades, and making steady progress, as well as make course changes in a gradual and smooth way. It isn’t the most efficient way, certainly, but it is at least a sustainable one, and it made it possible to keep Haiku relevant 22 years later. Of course the goal isn’t the same as when the project started. The world around us is not the same. The people contribuing to the project are not the same, except for maybe a handful of them. And so we have found ways to adjust to this, and I think we have done it while not having big crisis and drama and huge disruptive changes for the most part (there were some, at various points in the project life, but generally it went quite well).
So, if you want to change that, you know what to do: find a few million dollars or some other way to attract developers, and hire people who are willing to work under the strong direction and vision of a single person. Oh, and also find one single person with the correct vision and direction. Maybe yourself, it is the best way to make sure the vision agrees with yours.
14 Likes
Hi, i see plenty new names in this thread: Please use the search function to search and read all the countless previous i-have-a-super-idea, you-guys-are-all-morons, lets-do-a-release-now-then-drop-everything, the unforgettable guys-listen and the remarkable “lets-switch-to-linux” and other evergreen rant threads. Thanks you.
It would be a shame, if this would be just yet another rant thread repeating all the previously discussed ideas. Thank You for not doing this and thanks for trying to maintain a healthy discussion and not just TL;DR: Oh, look, this thread again.
6 Likes
Were there more (or more active) developers back then? Thinking back to this time, from a user perspective it did not seem like there were more developers than today. It did seem like GSoC used to bring very big benefits every year, on the other hand. Perhaps we have more developers now but lower activity overall?
It seems to me that a lot of the development is directed towards fixing hardware support, which is okay, but is stalling the goal? Just thinking out loud. Maybe a stable base system would attract more people working on newer hardware support?
I’m sure @waddlesplash has a more clearer picture about the goal reach, since he’s the one working full time now.
PulkoMandy did the same for a while when Web+ was added.
If Haiku does not work on my machines, I have no reasons to use it. So of course that’s what I work on first.
I would love to have time to work on strictly R1 things, but first and foremost I try to keep Haiku usable for my own needs, and that means spending pretty much all my time on 1) drivers for my hardware and 2) web browser improvements
We have lower activity in terms of commit count, but a part of that is caused by having pre-commit code review: each commit that goes into Haiku gets several revisions before it’s merged, so the final count of commitsiis lower but not necessarily the work.
It’s hard to measure the progress in other terms (of features or stability).
If measuring by the number of people attending coding sprints, then it’s definitely much lower now. When I joined Haiku back in 2009 there were coding sprints every 6 months, and usually around 8 devs attending? Now we get at most one a year and only 3-5 devs (which hardly justifies organizing a sprint). But that just means current devs are not interested in in-person sprints or can’t afford to travel and spare a full week of time for it.
Maybe my view of things is a bit distorted: when I joined Haiku I was a beginner developer and everything looked great and exciting, and I’m becoming (a little) older and grumpier now 
3 Likes
Maybe making more people excited and in knowledge of Haiku can get more interested devs?
All I know is that Haiku would do everything I would need it to if I didn’t commonly play games on my PC
If you are disappointed with the support of something in Haiku, feel free to add support for it.
4 Likes
You were paid, and my understanding was that the (unelected) board decided to pay you to do just whatever you wanted for some reason. I don’t see many jobs advertised where “Do whatever you want” is the job description but maybe I’m just looking in the wrong place.
[[FWIW “they just let me work on whatever I wanted (as usual)” is literally how Adrien himself described this closer to the time, and yet of course now he insists that’s wrong. Then he locks the thread … ]]
A noble ambition is worth essentially nothing. For unrelated reasons I spent a bunch of time studying WG21 (the JTC-1 sub-committee for the C++ Programming Language, when C++ people say “The committee” WG21 is who they mean) recently. You may notice that the last several C++ versions were very regular, C++ 20 and before that C++ 17, C++ 14, C++ 11. (The next standard will be C++ 23 but that isn’t technically out yet)
That is not an accident, or luck, it’s because of P1000, an actual Standards Proposal which says here’s what we’re going to do and here’s when we’ll do it, and every three years they just update it by adding three years.
C++ Follows a “Train model”. At the set date, the train leaves. If you’re not on the train, you are left to wait for the next train. This may seem unfortunate, why not hold the train just a couple of weeks to get that last thing aboard? Because this never ends. C++ 11 was once going to be named C++ 07, and was soon nicknamed C++ 0x because it was so unclear when it would actually happen. The Train Model allows them to see what they promised and then a personal commitment to success gets the rest done.
Haiku has repeatedly stated an ambition to do more regular releases, to actually get stuff done, but such ambitions are worthless. Haiku developers need to actually get out and push. So far most of them don’t want the train model, and those who do are willing to sit back and allow it not to happen.
I’m not criticising, I’m just an observer. But if you don’t like the results of what you do, doing the same thing most likely won’t fix that.
By the way, just in case it sounds as though P1000 (the train model) fixed everything one of the fun things in the current P1000 document (the one for C++ 23) is that it says this model solved their conformance problem and predicts C++ 20 will be the first time multiple conforming C++ implementations (ie compilers, standard libraries etc.) ship the same year as the standard. This didn’t happen, nobody shipped a conforming C++ 20 compiler in 2020. Microsoft shipped a conforming (but supposedly very buggy) C++ 20 implementation in 2022, others are on course for maybe 2023 or beyond.
If OpenBeOS R1 had shipped in say 2005 as its original core team imagined, it would not have included all the features Haiku R1beta4 or whatever they’re up to has. Not by a very long stretch, But on the other hand, it would have shipped and that’s something.
This may be a very “root” (human nature?) problem. When end-users, such as myself, say “I want this, this, and this” and developers try to appease those wants, then the project gets endlessly protracted. If a developer (such as Pulkomandy) says, “I want this, this, and this”, the project gets endlessly protracted.
What is needed, is for us (end-users and developers alike) to agree on a consensus of functionality. Nothing more. Nothing less.
-
We all know that the Internet is (in general) a requirement for most people. Along with that is a way to connect. WiFi is now an almost ubiquitous subset of that. I know it is for me. My wife only allows our son to run an Ethernet cable to his room, because of his constant complaints about his WiFi breaking in Windows 10. Him being happy with his gaming is like uber important in her mind. Whatever. So, what is considered the bare minimum of WiFi functionality? Have we reached it? Last I read, now USB WiFi devices were working, to a degree or more. Great progress there. But there has to be a “core functionalty” bottom line. A chipset (or series of them) that are definitely supported and almost, (if not absolutely) guaranteed to function, based on driver support.
-
Video cards, likewise. What drivers are basically feature complete or level of functionality is rock-solid? I believe VESA mode is a rocksolid bottom line. EVERY card works at THAT level. So, that’s our fallback position. But what cards/chipsets are basically guaranteed to work with 2D acceleration? Stop at that point.
-
CPU’s and motherboard chipsets, sound chips, etc. That’s a sticky wicket, because it covers a myriad of possibilities, so we have to go with the most common denominator (likely subset). This is where we go through the drivers we have and state exactly what we do and do not support consistently. Not EVERYONE is going to be happy with the end result, but we HAVE to settle on a ledge of the cliff we can camp out on and defend. At this point, we gather up everyone (end-user and developer alike) willing to do their best to verify functionality on their hardware. If the majority of people have no issues and only a few do have problems, then we have to assume that the majority wins. We cannot battle every jot and tittle. I say this for myself as well. I do not expect of others what I am not willing to accept myself. And I wouldn’t go to this length to make a point, if I was not willing to compromise for the sake of the many on a defensible line in the sand.
-
As far as applications, that is an indeterminate territory. That ultimately becomes a battle between developers, if there is a conflict. As long as Haiku, itself (all it’s core functions and drivers and incl. software), operates on a given set of hardware that we’ve settled on and verified as completely functional, that is ultimately our primary goal. We’ve done our part.
Haiku is an OS, not an application. It is our job to make sure the Operating System works on a given, agreed upon, set of hardware. Nothing more. Nothing less. It’s up to the developers to make their software comply with the Operating System, not the Operating System to comply with the applications.
- Surely there is a common set of hardware that we have developed/ported drivers for… a line in the sand we CAN draw. And, therefore, actually be able to say… “We reached Haiku R1”. And, I think we’d reach that point THIS year, if we took a step back and looked at the defensible lines of support we’ve reached on all the bits and pieces of hardware that make up a computer.
Haiku R1 is not an end, but a beginning. And as Windows 11 and macOS Ventura both attest… settling on a specific goal point and releasing that, is better than always going after the next new shiny…
Windows 3.1 became Windows 95, because Microsoft settled on a set of changes they didn’t keep changing. Once they reached those changes, they STOPPED and released Windows 95. Can you imagine where we’d be, if they never stopped “improving” Windows 3.1?
Windows 3.976.93.76.23.44.8, anyone? 
1 Like
Oh man! What an exciting thread.
So, as someone who has been contributing to the project for quite a while (and who has been a member of Haiku, Inc. for a few years too) let me highlight my perceived objectives of Haiku.
Objectives:
- A modern re-implementation of BeOS
- A cohesive, unified desktop environment for personal computing
- A comfortable POSIX compatible environment for the developers + technical users.
- A level of ABI / API compatibility with BeOS
tldr; Haiku wants to be an open-source replacement for BeOS while modernizing it. For those who didn’t get the pleasure of using BeOS, BeOS is like Linux but offers a consistent design where it’s clear “how to do what”.
Now. That was our goal 20 years ago. It took us over two decades to get to a reasonable stable desktop environment with package management.
Now, we all want to see Haiku succeed, but we also know that the original BeOS desktop environment turns a lot of non-technical people off. Why would someone not excited about BeOS use Haiku in 2023?
I honestly think our target has shifted. With Haiku as it stands today, we’re no longer targeting “grandma’s desktop”. Today we’re targeting anyone who values retro-computing experiences, anyone who values privacy, anyone who admires BeOS, anyone who wants a lightweight operating system that can run on pretty much all hardware newer than a i586.
With that all said, what Haiku needs are developers. We have a fast modern kernel, a bunch of drivers, a webkit based browser, and a unique desktop experience. We need developers however which invest in making Haiku more usable. Haiku has been maintained and developed with a (extremely skilled) skeleton crew over the last few years.
Needs:
- We need to improve WebPositive more. Webkit is a fast moving project, and we need more than one or two people working on it.
- We need better hardware drivers. Our developers have been moving us to BSD compatibility layers so we can borrow drivers from other operating systems. This has proven valuable over the last few years.
- We need more exciting projects (Containers, unikernels, hardware accelerated virtualization, etc)
- We need users to have the choice of a modern desktop environment.
All of these things require developers. It’s also why Haiku, Inc. hired @waddlesplash last year to work on Haiku full time. We need more people working on Haiku, and fell back to using some of our funds to have a “basic level of stable developer time”.
13 Likes
Ok, to be realistic, we can’t remove what is now thoroughly integrated into Haiku. We’ve gone too far, for too long, to undo what took years to incorporate. But if we look at where we stand currently (and step back a pace or two, where possible, if it’s still unfinished), could we definitively settle on a stable, reliable, usable version of Haiku that we could call R1? Surely we’ve reached something that we COULD call R1, even if the majority don’t WANT to call it R1. A set of hardware and drivers and such that we currently KNOW to be solid and supported and stable. Do we not?
I disagree, as a developer I can choose to spend my time where I want to, this will most likely be stuff I consider important. Sure I could ask users what they want, and to a certain extent I do that by watching the bugtracker, but I don’t have any interest in debating endlessly where I should put my time.
I have two hobby games I am making also, if Haiku time is consumed completely by debating what someone else wants me to do I might aswell just do something else.
3 Likes
Then don’t run nightly builds.
That’s it, it’s that simple.
Were you happy with beta3? Then you could have kept using it until the beta4 branch was cut off. All new software at HaikuPorts (with maybe one or two exceptions) continued working on beta3 while we did more development on the nightlies. Then you wouldn’t have to worry about things breaking from version to version like they naturally do in any development process.
2 Likes
Then you are no longer working on a Public project, you are working on a PET project. BeOS was never a PET project, it was a PUBLIC project. Intended (and sold/distributed) to the masses. To be used and appreciated for everyone that had a computer that could run it. It is why Haiku even exists as an idea.
And, I fear, that is WHY Haiku has taken 22 years to get to this point. Because it BECAME a PET project. The focus was no longer to produce an Operating System for EVERYONE… but just to scratch a curious itch here and there for whomever was willing to work on it. Screw everyone else who actually wants a completely usable OS called Haiku.
And now we know why I’ve lost 99% of my interest in Haiku. Because of trying to make points like this. Screaming at the top of my lungs (virtually speaking), to a room full of willfully deaf people. I’ve literally given up trying. But at some point, I will lose that 1% of interest remaining… and you will NEVER hear a peep from me ever again. And the crickets will reign supreme. Enjoy the silence… it will be deafening.
If you would, kindly offer us millions of dollars of funding for Haiku so we could then make it a “PUBLIC” project
We would be devastated XD
7 Likes
That’s not correct.
I did two contracts. The first one for two months in 2010 was specifically about finishing the locale kit I had started the prior year during GSoC. At the time, it was more or less part of the Haiku Code Drive. That was created in 2008 or 2007 because Haiku had not received many slots for GSoC, and Haiku inc made a donation call that allowed to recruit a few extra students.
This experiment lasted for a while, but did not give very convincing results. After discussing it with other developers and members of the inc, the conclusion was to try to direct the money to existing contributors rather than unknown students, in order to spend it more efficiently. 2010 was the first time this happened, and continuing my previous GSoC work was an easy thing to set up. Later on, some other contracts were made and the topics were selected to be more in line with the R1 goal (as defined and extended by the already mentionned “R1 features poll”) for most of them.
The second contract was in 2014. I offered Haiku inc a choice of two ideas: work on WebKit and WebPositive, or work on the ARM port. They picked the first, again because it was more important in reaching a final release. During the year I worked on a lot of things but the goal connecting them together was improving the web browsing situation, which a few years earlier was mostly OK with Firefox 2, but that was becoming less and less relevant, so a solution had to be found.
In 2005 it was barely booting to the desktop, if even that?
If I say “fine, I want this, but I’m not allowed to do it because Luposian doesn’t agree. As a result, my computer is completely unusable with Haiku and I will just run Linux.”, what do you think my motivation for working on Haiku would be, exactly? I would be writing apps for Linux, then.
WiFi works when it works on my machine. Thanks to Waddlesplash’s recent efforts with the OpenBSD compatibility layer, that is the case. Otherwise that machine would be running Linux.
Explain that to mmu_man who has his laptop stuck in 1024x768 on a 16:9 display. As a result he does not run Haiku natively anymore, and as a result of that his contributions went way down because it’s just easier to do things from Linux.
Very easy for me: it has to work on my machine. If it doesn’t, I can’t make any use of Haiku.
I write or port the applications I need. Does that count as distractions from the Haiku project or am I allowed to spend my free time however I want? When I spend an evening watching TV series instead of coding, is that also distracting from the goal of Haiku R1?
As long as it is my laptop. And even that isn’t an easy ride currently, I still have several drivers to write. I kept my old Thinkpad X220 for a long while, and I never quite figured it all out. And now I have a new, faster machine that allows me to build WebKit in a more reasonable time. Should I not use it and keep working on Haiku on the old Thinkpad? Then in a few weeks that machine will be forgotten in a corner and I will be writing Linux apps.
Yes, of course we are. As I already said, if you want to decide what I work on, you have to pay me. Otherwise it’s mainly for my own fun and enjoyment.
My goal is to keep Haiku usable for myself, which is a race against changing hardware, changing web standards, and sometime other devs making changes I don’t agree with. Of course it is deeply personal, I’m not here for the public good or whatever, and I think I give more than enough dedication to Haiku already. Do you think my time on Haiku is not well spent? Well, too bad, but I’m not accountable to you. I do this for my own fun.
The situation is different for Waddlesplash who is currently paid by Haiku inc and making progress towards R1, as defined by currently the 635 tickets in the R1 milestone here: Roadmap – Haiku
That’s probably at least two years of work in that list (given that we close about 300 tickets per year), and there will be more, because each beta release gets a lot of testing and new bugreports.
So, now, we may look at the past and lament over the fact that we have set way too ambitious stretch goal (and, again, this “we” include users, during the R1 feature poll they were also involved). Or, we can sit down, look at this ticket list, and see if there are things we should remove from it because it’s the only thing that will make R1 happen faster. Personally I think that forward-looking discussion would be more constructive.
11 Likes
Haiku is awesome, I love it; and I am grateful for the developers, maintainers, and community whose efforts continue to make it possible. Thank you 
.
12 Likes
You logic is humorous. As if human nature (of those interested in computers and Operating Systems) can so easily be thwarted. Let’s assume, for the moment, beta 3 was PERFECTLY usable for me. I see there’s an update! Do I simply go… “oh, no… don’t want to update… it might break my perfect world”… or do I run the update to get the latest/greatest revision of Haiku? Updating my OS (Windows 11 or macOS) is one of the highlights of my computing life… the latest/greatest changes and improvements is what technology is all about. But breakage is not something I oft have to deal with with THOSE OS’s. I can easily count on one hand the number of times I ran into issues with the latest version of MacOS X 10.3.x The most memorable was a networking issue, for which there was a workaround I used until it was fixed in the next point release.
No such “work arounds” really exist for Haiku. How do I fix broken WiFi, if I can’t download the next revision? How do I search for the solution, if I can’t get online?
I “get it” concerning nightly builds. But nightly builds are what spur enthusiam. They are the next great leap of development. It’s like getting to meet your favorite actor, in person… EVERY NIGHT! That’s where human nature comes in. Am I expected to just turn those emotions off? To play it safe? Or do I hope against hope, I’ll get something I want (some incremental improvement), without something I don’t want (breakage that renders my system useless)?
If there were, at this moment, a Haiku R1. And everything I use my computer for worked, as expected and desired. I could possible forstall that need to update constantly. But there is no Haiku R1. There is only a Haiku R1/Beta 3… an incomplete version… and therefore it screams “UPDATE MEEEEEE!” every…chance… possible.