Here are some technical suggestions done against the agreed plan for Haiku R1 Beta and Haiku R1 release:
Put yourself in place of developer who makes a very hard job doing such a complicated product as an OS, gives it for free, because enjoys the way it acts, and hears such a comments!
I am not a Haiku developer, but I am a software developer. I strongly disagree with you. A software user estimates the time / effort in terms of the number of bugs, a software developer looks at the difficulty of bugs. A user asks: “When will the bug X be fixed?”, a software developer asks: “How to fix the bug X?”. A user asks: “Developers, why don’t you listen to me?”, a software developer answers: “Dear users, please learn to file a bug with relevant information to get it fixed!”
I can continue with such examples. But I stop here. The only idea to add is: normally in commercial software industry the customer complain is not taken in consideration unless there exists an official customer request about it. This request is analyzed by the developers and if it was a user error, customer pays for it and software doesn’t get changed. If there is a software error, it is considered for fixing, with estimation about when it will happen given by developers. If this change is outside the specification signed by customer, he pays for it. And when customer pays again and again, he usually calms.
I have a project at sourceforge.net, which uses some library. When I found this library cannot do something, I opened a bug about it. Additionally I try to prepare the fix for it, which eventually will be merged in the library for all who use it.
Hey, leave me out of this! My comments are different! So radically and completely different… that no one… could… possibly… make any… rational… com…par… ison…
Oops. 
I included your comments not only to show that you make a technical suggestions, but that your comments can discourage developers for no good reason. The Haiku developer’s team puts priority on what is NEEDED for the project more that you can imagine.
OK. What you mean by ‘technical’?
I mean first definition in this dictionary:
https://www.oxfordlearnersdictionaries.com/definition/english/technical?q=technical
Seems, you mean second deffinition, anyway… than where I saying something about how software must use some C++ methods or classes, where I saying to developers how they must use compiller, how they must debug theirs software and etc. This was the technical questions. 32 bit vs 64 bit can be technical question if you tallk about nuances of code or compiling, but if you talk about promotion and usage of product this is another thing, also can be technical, but in another area of work. Notion, if you are one developer by itself and you do everytinig by itself from planing software, developing, selling, packing and etc. software, than all questions from this activity will be technical for you, but this not the case, I think.
Wow! this is harsh, your customers must be real idiots.
Let me explain it other way. A husband and his wife look to buy a new car for her and go to a dealer auto. Wife looks at all the cars available and says:
Wife’s wish is a non-technical. The husband’s is technical. Many technical decisions in Haiku project are taken from arguments, which are “under the hood”, which look completely irrelevant from the user perspective, but are much more important for the good of the project than what they believe. On the other hand, the user wishes and suggestions to “promote” Haiku, if they are implemented, usually lead to increasing development time / effort and are destructive in long term. Again, only closer look at that suggestions with technical eyes can reveal this. However, when some developer politely explain why some decision is not good for Haiku and user complains: “Why you never listen to me?” it gets not only silly, but also frustrating for both.
First of all, if you think that Haiku ussers are not technical at all, I think you mistaken us with some MS Windows users. I think, here we all know something more about software and hardware than average MS Windows user.
Another thing, you suggest some silly model and later impose it with some personal view and feelings on the another situation, ignoring what is really going on.
Why not? maybe it is not technical in your expertise, but I think, wife is very certain about the color of the car, shes major concern is how it will looks with her garderob and make-up. It is obvious that that wife is that sort of women wich sells her look to others, this is her buisnes, her way of life. Technical insides for her are not important, because she can not use them for promoting to others her look.
First of all, I didn’t make any supposition about how technically skilled are the users of Haiku. Second, there are different skills around computers and computing. Somebody very skilled to buy and repair a computer can be very unskilled to write software for it and vice-versa. Somebody very skilled to write the applications can be unskilled to write the drivers and vice-versa. I only say that the silly suggestions make somebody to look very little technically skilled.
I am not interested in war ‘developers’ vs ‘users’.
You missing the point of all discussion. In my view, goal of this discussion not in accusing some parties in some inability to do some job. Goal is to find best decision for Haiku future.
Glad to hear it. This is my wish too:
More than that, for Haiku I am a user, not a developer, so I am in user’s club. Also, I have in-deep understanding of how coding works, what means to port some software, what means to prepare a package for some written software, what means to write the code upon which large part of applications will depend, what means bugs, regressions, fixes, relevant and irrelevant information for that. So, I can understand what Haiku developers feel when communicating with the community. My point is: Let’s be constructive, not destructive!
No… this is normal for custom software development and enterprise software. Bugs get fixed by the vendor’s support team, but if it turns out what the customer asked for is a change in scope, not a bug, then there is a change order and the customer has to pay for the new functionality if they want it.
Anyways, this is getting off-topic…
I meant only this answering to “And when customer pays again and again, he usually calms.” nothing more.
Which also shows miscommunication between vendor and customer.
Ok.
First of all, this suggestion is not against the agreed plan for Beta 1 or R1, it is completely in agreement with the plan. It is just suggesting that the project should get something out of the door as soon as possible.
Second, about you suggesting that I am a non technical person writing. It’s true that I am not a Haiku developer. But I am a software engineer with over 15 years experience. So I don’t by any means speak from a position of ignorance.
May I suggest that the discussion moves back on topic? It’s no longer about the beta release. I stopped reading the thread due to the diversion, I only came back because I was notified that I had been quoted.
My apologies to all you who feel attacked by my words. I really don’t wont to offend somebody. And it is a pity that from all my words only the most irrelevant are cited.
I understood these words as Haiku cannot move towards R1 Beta / R1 unless it breaks binary compatibility with BeOS R5, which is against the agreed plan for R1. Again, sorry if I understood something wrong.
My position is as plain as these:
and
In the interest of seeing Haiku R1 reach beta, I think any and all further “feature creep” (if I understand the term correctly; an endlessly growing feature increase) needs to be stopped, period. If it has been, great.
Haiku R1 is meant to duplicate BeOS R5, not endlessly improve upon what BeOS R5 never achieved.
Haiku is already every bit as “feature-laden” as BeOS R5 ever was, period. Now is time to refine what is there, to the point it ALL works reliably and stable.
Now, the question is, are there any “advanced parts” (better than what BeOS R5 had) that are inhibiting “standard parts” (the same as what BeOS R5 had) and, is that an acceptable “break” in compatibility or not? Have devs driven past the “stop here” point (as good as (or maybe a tad better than) BeOS R5), to the degree getting back to that point is either too difficult or no longer worth the effort? We’ve already seen rogue ABI coders mess things up and then walk off without a care.
Though I am no coder or dev, I do know/remember what the original goal of Haiku was. I honor that “legacy” in what I’m saying now, even if I personally think it’s a moot point these days.
The problem is, have the cart and horse gotten so horribly tangled, that it’s about time to shoot the horse and scrap the cart for firewood… or can this situation be salvaged? Or must the original goal be scrapped and we now just say “we’ll arrive at Haiku R1/beta whenever… and we no longer care how actually BeOS R5-like/compatible it is”?
Either honor the original goal or don’t. But don’t keep pretending it’s being honored by endlessly “tinkering” with it. We already know Haiku is waaaaaay better than BeOS R5 ever was. So let’s stop fooling ourselves and simply refine and finish what is already there. Haiku x86_64 is the sandbox for devs to “play with and expand and change forever”.
At the very least… get to R1 and THEN start adding and tinkering more, for R1.1, R1.2, etc. Let’s get the whole “BeOS R5 compatible” thing finished and behind us (I use “us” and “we” in the general end-user/dev sense; i.e. everyone) and THEN start dreaming huge with “Haiku Beyond”!
I would suggest making the Haiku kernel, modular, and also removing the unnecessary state of the file system from the package manager, and that’s rootfs, or whatever.
in order to even run the software on weaker computers, as well as it is extremely important for arm mini pc, this should add speed.
No one talked about “getting back” to exactly a clone of BeOS R5. If you want BeOS R5, just use BeOS R5, it works, it won’t change in the future.
Haiku of course needs to make compromises. Let’s look a little at our history and how we got where we are (as they say, "when you don’t know where you’re going, first check where you’re coming from).
The initial project vision was “to create a free software replacement for BeOS R5”. Yes, in terms of features, this goal has been reached, and this is why we are ready to enter beta stage (as defined in Haiku, a beta is a feature complete system, which may still have bugs).
After the alpha1 release (remember, the alpha1 also had a precise goal: it was shipped once the OS was able to compile itself), there has been a large discussion with devs and users (it happened at BeGeistert) and then an online poll to decide what should and shouldn’t be included in R1. This was in 2009-2010. Already back then, people understood that just replicating BeOS R5 wouldn’t quite work. Because the world had moved on in the 8 years it took to get Haiku to alpha1, and some things that were ok in 2001 were not acceptable anymore. Examples are support for USB and Wifi. Would Haiku still exist if we had decided these were not important? In my case, the answer is clearly no: I would have given up on using such an OS and moved on to something else.
Now, the decisions were made at a time where Haiku had an highly active team of developers working on it. They had just reached their first major milestone after 9 years of hard work, and everyone was quite enthusiastic about the future. Maybe a little too much. In particular, one item slept in: “it should be possible to update the system without reinstalling everything”. This looked simple enough at the time. However, once the Haiku team started thinking about it, they tried, as usual, to do things right once and for all. As a result, it ended up with something that goes further than the goal: a package manager that handles updates not only to the system, but also to all applications.
Anyways, eventually the work on this was completed on the software development side. However, it turned out that the designed system also needed a lot of infrastructure work. This is setting up a server to host all these packages, having buildbots creating the packages automatically, etc. This is a large work and something the Haiku team is not really knowledgeable about. We are all learning there.
Notice that it took 9 years to get from the project start to alpha1, and 9 more to get from alpha1 to beta1. What we are discussing now is the plan for the next 9 years, which should lead us to R1.
I tried to share my vision but it seems some people misunderstood me. So let me repeat it again (note: this is only my vision, I don’t consider it ready. We should discuss this with other devs and users - probably starting at BeGeistert with a brainstorming session as we did after alpha1).
I think Haiku should aim to provide a stable, supported platform. For me, this is what R1 should be. Something you can count on, that will never have regressions, with very careful testing. Something TuneTracker systems could ship to their customer and base their work on. Something users could trust their data to. This is one long term goal, however: there are still hundreds of bugs to solve before we get there.
However, we cannot focus just on this: if we put all our resources on just fixing this almost endless list of bugs, it means we make no progress on anything else. This means no USB3 support, no support for modern video formats, and no changes to the API. We can’t stay in the 1990s forever. So there need to be work on modernizing some aspects of Haiku in what will eventually lead to R2.
When we get to shipping a stable version of R2, it means we can retire the old R1 and customers/users can update to R2 (hopefully with a migration path so they can continue using their apps - the problem in defining R1 and R2 more precisely is around defining that migration path).
This is all great, but it assumes people are willing to invest effort in both maintaining a working R1, and adding new features to R2. This may not be the case forever. As far as I know, many of the developers are - and rightfully so - willing to work on new stuff for R2. Doing maintenance on R1 is not that fun of a job. I’m ok with taking care of R1 for some time after the beta1 release. There will be more betas after the first one. We’ll see how we organize this, maybe a release every 6 months or every 6 years with whatever bugfixes got in. It is likely that the bugfixes will be imported from R2. However, as time passes, it will become more and more difficult to do that, and at some point, R2 will be ready for its first alpha version.
What will happen then? Well, if R2 alpha works well enough, I may start using it. And in that case, my interest for keeping the R1 branch moving forward would stop. So, I would need a reason to keep spending my time on that old code. Maybe if someone really needs it and pays me for doing the maintenance, I will. But otherwise I will just tell people to migrate directly to R2. This is what I mean when I say “R1 may never be reached”. No software is ever perfectly finished and done. It just works well enough for what people do with it. We could at this point make one last release from the R1 branch, and name it “R1” (no beta or anything). It would be some gcc2 based thing in the 2020s. Who would care about it?
Now, I’m ready to change my mind on this. But as you can see, this post is rather long and detailed and tries to cover a lot of things. And I didn’t even start discussing the various options for the R1->R2 migration path. As a result, I find 2-line plans like “R1 is the gcc2 branch, R2 is the 64 bit branch” not any serious. There may be some sense in doing that, but you have to define the global vision, who is doing what, what is the goal for each branch, etc. Not just jump straight into “it’s all about the compiler version we use” or some other technical detail.
I do appreciate discussing these matters with users and outsiders, but the input I need is not technical solutions - not at this point. The input I need is your visions for the future Haiku, does it matter to have a supported R1 branch like that or would people just jump straight into R2, etc. Once we have agreed on a common vision for this, we can start refining it and seeing how we can implement it (things such as “when/how can we stop using gcc2”, “when/how can we drop ABI compatibility”, etc). And we should finally reach a technical plan for 2018-2027, which results in releases that satisfies as much as possible of the users needs.
I voting for 64 bit modernized Haiku (with updated API, no matter how it would be called R1, R1+ or R2) with some support layer for 32 bit BeOS apps.