Say,
How is R2 coming along? Or at least Beta 5?
David
1 Like
Hello, fellow time traveller! How’s life in 2054? 
7 Likes
you can check the topic.
2 Likes
R2?
Waddlesplash will have a heart attack 
1 Like
It’s taken 23 years (assuming work began in 2000) to get to Beta 4. Beta 5 should likely be sometime in the next few months, I’d assume. But R2? Don’t even think of such things… I’ve likely got about 25 years left on this earth (I’m estimating I’ll live to about 80), if Jesus doesn’t come back before then. But if R1 is finished by/before then, R2 would be likely to be seen sometime when Buck Rogers is born! 
5 Likes
Be Inc. didn’t go under until around sometime in 2001.
Never forget!
1 Like
I am pretty confident R2 will take less time than R1 
I think haiku is coming along fine right now, though i do hope for beta5 soon (maybe R1 after that?)
Keep up the good work
I’d prefer the Haiku devs get it right than rush to R1. Best thing comes to those who wait.
This is not true. Don’t settle for that in life. You will have nothing.
I recall that in R2 we vill breake compability to BeOS so we need a R1 first.
Next step would ne a beta 5 I guess.
//Fredrik
I don’t agree with you.
Always the bridesmaid never the bride.
Whatever!
Why not just port as many apps as it would take to make Haiku daily usable, and call it Haiku R! “Portsfest” edition - afterall, you’ve got Haikuporter software for such purpose. Then devs can take as much time as they want to make a Haiku R2 “BeOS compatable” edition, or a “native apps” edition. The advantage of doing it this way is that you get over the embarrassing 23-year-long R1 hump (which screams there must be something wrong with the OS / will it ever get off the ground, etc). An R1 will attract more users/devs to a new OS, and then everyone can move forward with clear air and renewed energy.
1 Like
Surely we can count you among those willing to provide man power towards achieving that goal, right?
On the other hand… while having useful ports is indeed useful… no amount of ported apps will ever “make an OS daily usable” by themselves.
The OS needs to work reliably, and our mighty, but few, devs are doing their best to try and achieve that.
HaikuPorter is just a tool to assist on the creation of .hpkg packages… it doesn’t auto-magically ports software by itself.
Porting software requires people doing actual work. And porters are volunteers.
That’s like… you’re opinion, man. And frankly… I take issue with your use of such language.
Google Mail had "BETA in its logo for how many years? Didn’t stopped it from getting as many users as it got, right?
Do you really believe that the portion of users/developers that get put off by a “0.1” vs “1.0” version are THAT many, and more importantly… good enough for a project?
Even really mediocre tinkerers like myself understand that a software version/tag is just that, a name tag. I doubt any proper developer, worth its salt, would dismiss a project based on that.
On the other hand… first impressions are hard to revert. Do you think releasing an R1 PortFest Edition with lots of known issues/limitations will do any good for unsuspecting “regular Joes”? Or would that backfire as bad publicity?
“Disclaimer”:
My English is badly self-taught, and it is hard to communicate intended tone through text.
FWIW, the tone I was aiming for was “a bit stern, but playful” (hoping I didn’t ended up with “straight abrasive” 
).
4 Likes
It is just a version number. How can version numbers magically attract people to a project they didn’t care for?
You can port as many software as you want, if the OS has bugs and doesn’t boot or doesn’t have sound or wifi, you can’t use all the ported software.
Also, “ports fest” is not the goal for R1. If you want to make your own “ports fest OS 1.0”, sure, you can. But that is not the vision for Haiku. So it will have to be done by someone else (which can also be a team sharing some people with Haiku, if they feel like so).
2 Likes
Why break compatibility? Is this a goal? To break compatibility? If anything, the ideal future goal would be to have some compatibility environment/layer so that even 64 bit Haiku has BeOS compatibility. But for now, I don’t see any reason to break compatibility in 32-bit Haiku.
I sort of agree with Syd, in a sense, with taking your time on R2. Haiku isn’t even at R1. Who knows what will develop between now and R2, but let’s jump off that bridge when we get to it, and not rush into breaking things.
Not really a goal, but we have two main problems with BeOS compatibility:
- We have to maintain a version of gcc2 and compile parts of the system with it. This prevents us from using any modern C++ in these parts of the system, for example.
- Be did some mistakes in parts of the API, or put in some limitations that made sense at the time, but get in our way now. So, at some point we’ll have to fix that.
Their original vision was to start from scratch, leaving behind the legacy of old Mac OS and Windows versions that were blockedin their progress by legacy technology. Wouldn’t it be ironic if Haiku ended up blocked trying to keep the BeOS apps running without any changes, replicating the problem that BeOS was createrd to solve?
Compatibility can still be achieved, these two problems are solvable in other ways as well (for example: modifying a modern compiler to emit code that’s compatible with the way gcc2 did things; introducing some new classes alongside the old ones, either in a different library or with some symbol versioning tricks). But, in the past two decades, no one has done much work in that direction.
It’s possible that, for example, R2 could be compatible with applications compiled to run on R1 with a modern gcc, but not with old apps compiled with gcc2. For me that seems a reasonable option, whereas a “let’s break everything, R2 will not run any of the existing apps” would be a stupid shoot-yourself-in-the-foot move.
Rather than jump off the bridge, we can plan ahead, and make sure the bridge is built when we reach the river, and we can cross safely.
(ok that was a terrible bridge based analogy, whatever).
Having at least some plans for R2 allows us two things:
- Say when something can’t be done for R1 (because it would be incompatible with BeOS apps in some way), and has to wait for after R1
- Sometimes, identify changes that we can already do to prepare ourselves for the transition from R1 to R2. For example, we are already maintaining compatibility with BeOS. At this point, this compatibility is not massively useful: a lot of the BeOS apps have been recompiled, or rewritten (there are a few exceptions, but not many). However, it is very interesting for us developers because we learn many tricks of maintaining compatibility. When R2 comes by, we can use that experience, to have R2 keep running R1 apps. And, we can also use this experience right now so that R1 things already make some plans to be easy to maintain in R2 days.
So, having some vision of the work ahead, even if we don’t plan to start working on it soon, is still helpful.
6 Likes