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:
- I want this one.
- Why do you want it?
- It is light-grey, exactly what I like it!
- But did you see the engine, the mileage, etc.
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.
So I read your lengthy message and from what I get out of it is that there is a possibility R1 (stable) will never see the light of day. I feel that if that is the case, then it needs to be made known to the Haiku community so folks (like myself) can decide what do do concerning the future.
I think I have to agree with some folks who felt that the inclusion of package management definitely sidetracked getting to R1 (stable) and has added limitations and regressions when compared to Alpha 4 or even BeOS itself.
I think I’d be down to the following said…
As we discussed on IRC recently, I think the Haiku project needs to get back to a more structured/team oriented setup. IMHO, it would be easier to get more folks involved if the project was a little more organized where potential contributors can find where they could fit in and be groomed by a team of developers. I would certainly be willing to contribute my QA skills if such teams existed, but doing QA in a more lone ranger mode is not something I want to do.
Haiku could almost follow in Apple’s footsteps where they had two sets of APIs they developed/maintained, which was Carbon (supporting classic MacOS) and Cocoa (for the new OS X stuff). Of course Apple eventually dropped support for Carbon since it was no longer needed and was obviously meant as a transition path for classic MacOS applications, giving their developers time to make the jump.
I really appreciate the lengthy, detailed reply. It shows you care about people’s concerns and the project. It’s very refreshing to see that.
But I wonder… I got a sense of developer decline in the way you worded things. Maybe it’s just me. Dunno. How many people are currently, actively, working on Haiku right now? Is it only slightly less or significantly less? Is it a seasonal slump or a growing apathy with the project? I hope I’m wrong about my “sense”.
But a supposed 9 yrs. between releases of beta or any type, just doesn’t seem very… encouraging.
Yes, an R2 with some way to run R1 apps would provide a nice and smooth transition. Let’s try to dig down into the details. I see two ways:
- R1 is 32-bit only. This means R2 will have to run 32 bit apps, too.
- R1 is released as both 32-bit and 64-bit. In this case, it could be enough to have R2 run 64-bit R1 apps and we can drop 32bit support completely by R2
I prefer solution 2, it seems to be the way we are headed now (as we do plan to ship a 64bit version of beta1) and it allows us to drop 32bit support earlier.
–
On wether R1 may or may not happen: at his time I really don’t know. If there are enough people interested, it will happen before R2 is ready for end-users. Otherwise it may stay in “beta” for a long time. But that does not change much from an user perspective, one would still get support for the beta releases. Maybe calling it beta allows a little more flexibility in what we consider acceptable, but if we get past R1 we could make point releases as well (R1.1, etc). It is just a way of numbering versions. I do plan to keep that branch running in some way until R2 is more clearly defined. I did not discuss this with all other devs and the few I did discuss with (it was during a coding sprint, so maybe 4 or 5 of them) were more willing to work on R2, however this was a few years ago and they may also have changed their minds.
As I said, this is only my personal view on the project, and things may evolve. There has been few discussion in the Haiku project about what comes after R1, and I think it is time to start thinking about it.
–
On number of developers: it is best to check the numbers.
http://pulkomandy.tk/stats/authors.html
According to this we had 57 people who contributed at least one patch to Haiku in 2017. The all-time low is 24 in 2006 (however we were using SVN so this included only people with commit access and not users submiting patches), and the record is 72 in 2012.
We can look at it in another way, by number of commits per year:
Surprisingly, 2012 is a low activity year (despite having the most contributors). But you can see that roughly since 2009 and the alpha release there is less and less activity on the OS itself. This is however not entirely true, because on the other hand we have a lot of activity on HaikuPorts and people working on applications. So it may just be a sign that the OS is getting ready, and people are shifting their interest towards applications
So, let’s look at haikuports which has history since 2008:
http://pulkomandy.tk/stats_hp/activity.html
66 authors in 2017, which is the all-time best year. A net up from the 2 contributors in 2008, where the git history for haikuports starts! You can also see how package management was a game changer here, just by looking at the difference between 2012 and 2013.
I don’t have statistics about HaikuArchives because it is many small git projects, so it is harder to keep track of things happening there. This also doesn’t track my work on WebKit or KapiX work on porting LibreOffice, for example.
Another aspect of this is that over time, developers join or leave the project (or temporarily step away). However, in some cases it would be nice to have the knowledge of people who worked on it for a dozen of years. In other cases, a fresh look at things can help, too, but it takes time to get new developers up to speed.
As for the 9 year cycle, it is just something I noticed about the times for alpha1 and beta1. I don’t know if R1 or R2alpha1 could be delivered faster. But, I don’t mind setting up an ambitious plan for the next 9 years. The mistake we must not make again is to say “we don’t ship anything until we reach the goal”. So we can plan for 9 years, but have many releases (beta or alpha or stable, it doesn’t matter to me) in the timeframe.
–
And one last word on the alpha/beta/stable wording. You have to match them with rc/stable/LTS Kernel releases at Linux. Our final releases (R1, R2, …) will all be long term support. So our betas are what the Linux team would consider stable releases. It’s just a difference in wording and project culture, but not necessarily in the quality of what you get. So for me it is fine if the R1 branch never gets LTS status and gets only short term support (a release replaces another every 6 months). But if we are to keep the current terminology of Haiku, this means all these releases are to be named “beta”. After all, there was another BeOS-legacy system named after a greek letter 