Haiku Beta Discussion

I’d say spend a short period time (less than a year) fixing critical bugs and create a stable version, call it Beta1/R1/whatever you want. This is a version you can tl users is the last version to support “legacy” apps. It’s a safe point of reference, and something TT can point users too.

Then jump straight to R2 with the breaking changes.

1 Like

Reaing through the various posts in this thread, I sense that a path forward is being collectively developed.

I like this and here is my take on it.

 * I see R1 as having both 32-bit and 64-bit builds available.
 * I see R2 as being only 64-bit.
 * Application developers should not expect the availability of support for 32-bit applications in R2.
 * R1 32-bit would still receive fixes for bugs encountered only with applications and hardware existing at the time of its release. Not point in patching it for the Intel Core 
 * During the evolution from R1 to R2, some form of migration recipe should be available to help current 32-bit applications migrating to a 64-bit only environment.

One thing, I would not be surprised if within the next 2-3 years, the Linux kernel drops support for 32-bit CPUs.

2 Likes

Thinking better 32 bit should be optional for r2 from the source and the official support for x64.

1 Like

After reading through this thread my thoughts about the path to Beta have changed somewhat. Initially I was in favour of having both a x86_gcc2h and x86_64 beta release. However, if the stated goal of Beta/R1 was “Essentially, a fully working and stable operating system. A viable replacement for BeOS R5 (and later)”, then the SOLE focus ought to be x86_gcc2h by all those involved, since it is the only version of Haiku that meets the definition stated above and unlike x86_64, all legacy BeOS applications can (or should be able to) run on this architecture.
Another factor to consider, is that many of the core developers are themselves only using x86_gcc2h exclusively.
People who wish to further development of x86_64 should be free to do so in a development branch, with the understanding that it does not, and will not meet the R1 criteria, and that the API will be subject to breakage, and is of secondary importance until R1 is complete.
The future of Haiku is x86_64, but for the present, we need to get Beta/R1 completed and out the door ASAP. Without a concensus, and focued effort by all involved, we may never get there.
Just my 2 cents worth to add to the discussion…

2 Likes

I don’t agree on “let’s ship beta1/R1/whatever ASAP and then start working on R2” plan. Let’s step back a few years and look at the previous release where this is more or less what we did: “let’s ship alpha4 ASAP and then start working on beta1”. Are people using alpha4 as the stable version today? Certainly not. When they report bugs, all we can say is “download a recent nightly and try again”. And sometimes the nightlies are broken, too. They will be much more broken while R2 is being worked on, because we are going to rewrite quite a lot of the OS.

So, I don’t think this is a working solution. This is why I lean towards developping R1 and R2 in parallel, until R2 is at least ready to ship an alpha version. Until then, I don’t want to leave the poor users stuck using nightlies. There are a lot of people complaining for the lack of a stable release, but when we start discussing the details, suddenly people are like “uff, this sounds like a lot of work. It is unrealistic.”. Yes, it is a lot of work to have supported releases. This is why I’m not too keen on releasing at a very high rate like Ubuntu’s 6 month cycle or Firefox’s even crazier one. I prefer to take my time to get the details right and ship things when they are ready. I agree that the 6 years and counting since alpha4 are too much, however. Hence the plan for an R1 branch with less activity, from which it is easier to make releases from time to time, while R2 gets all the fun experimentations.

I can then get into what makes the difference between beta1 and R1:

  • A stable web browser
  • A working encoding/decoding system so you can watch any video and re-encode it to any format
  • No more KDLs and filesystem corruptions
  • Probably a few other similar things

It may seem not that far off, but these issues have been around for years.

2 Likes

Hi PulkoMandy, I checked APlayer serveral weeks ago. I am wondering why you did so many changes to the original code, since the 4.01 source builds nicely without that.
Is there a short summary why/what you did?

There is the git log.

I don’t remember exactly but some changes include:

  • Fixing the build with gcc4
  • Adding a player based on the GME (Game Music Emu) engine for listening to various video game console musics
  • Replacing the scrollbar used for volume control with a slider
  • Fixing drawing glitches in the song position slider
  • Replacing the ogg, mp3, … decoders by a decoder using the media kit (which also support many other formats)
  • Improving the look of the “spinning squares” visualization plug-in

Waddlesplash then went further, replacing the buildsystem and starting to work on 64bit support. This is the kind of things we are talking about here, keeping applications up to date for modern systems. And yes, it can lead to quite a lot of changes even if the application still looks and behaves the same.

1 Like

There are two adopted approaches to software release:

  1. Release it when ready, very solid and bugs free. This approach takes Debian Stable release. It is very appreciated by enterprise customers, who value stability over newest feature, but keeps average home user away, because when Debian releases new version, it is already outdated.
  2. Timely release every X month / years. The release is guaranteed to have all new features from last X month, but from stability point of view it can be frustrating. Here, the end users are happy, but enterprise customers are not.

I feel the problem from user’s point of view is more psychological than technical. I mean, the quality of nightly builds is quite acceptable. However when somebody sees hrevNNNN, he thinks: Wow, it is not even Beta! Maybe a simple renaming of releases will help understanding of what it is all about. For example, instead of R1AlphaX or R1BetaY to use something like 2012.11 (Alpha) or 2018.MM (Beta) or YYYY.MM (Production) and instead of nightly hrevNNNN something like 2018.MM.DD (Rolling).

2 Likes

Looks like I might be building my own 32-bit R2 haiku and packages… then again if it’s 9 years away maybe not!

1 Like

Be careful about something: unlike Debian, we are discussing just the OS here, not the whole application ecosystem. The problem with Debian is that they put everything (from kernel to web browser) into a single release cycle. This can’t work.

I aim for a stable OS, but applications would still get updates. I think this gives a good compromise. Moreover, when it becomes complicated to update applications because the core is too old, it means we should make a new release of the OS itself. There isn’t a need for time based or “when it’s ready” then, it’s more a “when it’s needed”.

1 Like

Understand, Haiku building model is more like *BSD than Linux, i.e. OS on one hand and applications on the other.

This doesn’t affect the following release naming convention, which may help end users to understand what to expect and what to use:

1 Like

Hello PulkoMandy,
Please tell, how it can affect the weak glands, after all BeOS was developed as Geek OS for a large amount of iron, and much as we know the big cardinal changes in BeOS except for the interface did not happen after all, except as porting to platforms, it may be worth reviewing the optimization and Somewhere simplification, for the end user in terms of at least a batch system - in terms of full access, at least through the terminal? And also, in terms of security, a firewall?
And the release of 64-bit versions will not make you think about porting back? 64-bit version, more suitable for user application, it’s natural that someone will be in failure, or are technologies developing so that we are going to the future, and we need some kind of constancy? After all, the same developments in 2017 and with the 32-bit version are not bad?

I does not understand why some people does not like to have r2 64bit with suport of 32bit apps. I think this is the best way to get a smooth way from 32bit to 64bit. R3 can be 64bit only then.

  • r1 32bit
  • r2 64bit with suport for 32bit
  • r3 64bit (if possible and if it makes sense with 32bit again)
  • r4 128bit, let us to be the first ones :slight_smile:

We does not need a complete break with a system without apps at the end (pulkomandy told this before).

Step by step and with dialog to the people who write the apps. And not forget tunetracker systems.

3 Likes

Having a system that runs both 32 and 64bit apps is something we don’t know how to do yet. By the time we get to R2, 32bit will likely be largely obsolete, so I don’t think it looks like an exciting project to add support for this.

This is why I lean towards officially supporting 64bit starting from R1 (as a separate, non-binary-compatible system) and seeing wether that takes off or not. Then when we get to R2 time we have all options open. Full 64bit system, still making a 32bit version if there are enough people who find that relevant, or some 64/32 hybrid. I would much prefer going full 64bit and doing away with the legacy at that point (it is far enough in the future that this wouldn’t be a problem for me).

We will also see how long gcc continues to support compiling 32bit x86 code, how long WebKit continues to support 32bit systems (they are considering removing the JIT javascript engine support for 32bit already), how long it is possible to build ffmpeg on 32bit systems and still get realtime video decoding, etc. There are external factors which may prevent us from keeping a 32bit system working for the whole R2 lifetime.

6 Likes

I’d also add that in a decade 32bit x86 will be probably so old that it will be possible to emulate it with little visible overhead. Nowadays for Haiku makes sense to look forward.

5 Likes

Totally true here.

2 Likes

I agree with the points that followed, but I’m surprised by “between beta1 and R1”. Wouldn’t beta1 be a test release of R1? Would it make sense to have a beta1 without addressing those points?

Our definitions are:

  • alpha: missing features
  • beta: all features present, but there are bugs
  • R1: no known bugs

We now have the features implemented (the code is there), but not working (there are bugs). This is ok for a beta. Otherwise we would never be able to ship a beta.

There could be an intermediate steps between betas and R1, which would be “release candidates” (no known bugs, but help us find some!)

5 Likes

By that definition, we are in beta right now. Am I correct?

1 Like

Interesting,… which features must be added to Haiku to go into beta state?