If directing funds to interested third-parties for 3D drivers is allowed independently, I’ll do that. I’ve already donated to Haiku Inc. last week. Who else do I need to bribe donate to?
3 Likes
Is R1 a big deal?
If it’s when Haiku is good to go as a usable OS, I can see why people would be worried about the state of the applications.
When BeOS came out, NetPositive seemed to me like a pretty outstanding web browser, and I forget what email application I was using (was there something called “Mail-It”?) but it was OK. WebPositive is far beyond that today, but if we’re waiting for it to be a generally usable browser, then R1 is far off.
If on the other hand, R1 just means a stable point in the base operating system that developers can target and expect their users to be on the same page, and people with hardware that works can expect it to keep working, is that pretty close? Would it be better to drop a new beta 6?
1 Like
For me a stable API and standard apps and system components including WebPositive would be totally fine for R1.
There are still some quirks in media server that should be ironed out (I’m lucky to have sound but playback is nowhere near the quality I was used to in BeOS, and these are known issues with synchronization and stuttering playback with occasional crashes).
I also discovered some regressions in WebPositive that seem to be triggered by GitHub again, where the app takes forever to load a page and eventually locks up.
So maybe we get webkit2 in for R1 but that would be totally sufficient.
I’d certainly not put a moving target like drivers for whatever as a goal for R1.
Haiku feels already faster and more responsive than mainstream OSs with what we have already.
2 Likes
Since compatibility breaking changes start after R1, then yes.
I believe that making comparability breaking changes give a little benefits, but make a lot of harm. Breaking changes have a risk of having Haiku identity and evolution vision lost and project fading out.
Most problems can be solved without breaking compatibility. Many of proposed compatibility breaking changes list in dev.haiku-os.org are purely cosmetic changes and not strictly required.
As can be observed in Windows, evolution without breaking backward compatibility is definitely possible.
Backward compatibility is a one of reason that Haiku project is still alive and have users. For example Serenity OS don’t gain users because it often break compatibility, so it is not possible to reliably develop 3rd-party applications.
2 Likes
It’s a psychological and marketing turning point. Every review of Haiku starts with the same line: something like “20-odd years and still not at 1.0”
Those of us who have been around the scene know that there is steady improvement, R1 or no R1. But to the wider world, “Beta X” means “Well, I’m going to wait a bit longer till they get their act together”
3 Likes
Bad example but I agree anyway.
1 Like
we might be talking about two different things here, if we started out talking about compatibility with BeOS 5, and now we’re talking about backwards compatibility between Haiku versions.
I think compatibility with BeOS 5 has one foot in the edge of the grave already, and is not really a factor in Haiku user activity. But that’s just a casual look from the outside, no doubt there’s someone that’s very dependent on some BeOS application. After R1 comes out, that might be when they stop upgrading.
1 Like
I haven’t tried it, but just looking at the blurb … if it supports IMAP protocol, then the blurbs out there need to be updated. If it can only fetch emails the same way as with POP, that’s kind of a problem.
My home rolled email goes somewhat farther than that with IMAP, but it’s still far short of supporting all the things people are accustomed to doing. That’s a big job.
Good, beta 6 is the way to go, then.
I enjoy using Haiku, it’s an ideal user interface, it’s fun to write programs for, and I use it for things. But I have a Linux partition, despite having no interest in Linux whatever, for when I need to really use a web browser, and that’s how it’s going to be, for a long time. This isn’t a slam against Haiku. I have a NetBSD partition too, and as I like NetBSD better than Linux I was going to use it for that. But it doesn’t work all that well, I think because it isn’t really native like it is on Linux. This is one of the things that Haiku users aren’t close to getting, and that’s a more important reason for the wider world to wait a bit longer, than the numbering scheme.
The problem is that proposed breaking changes will break compatibility with both BeOS and previous Haiku versions.
I agree that importance of old BeOS application is not high now. Also it require to compile userland API libraries with ancient GCC 2 compiler that limits using new C++ features.
I would propose following after R1 plan for dealing with BeOS compatibility.
-
Fork code of API libraries needed for BeOS applications (libroot.so, libbe.so etc.) and put them in separate repository. So using new C++ features will become possible in Haiku libraries. Old forked libraries are updated only for internal protocol chanes and minor bug fixes. No new features will be added.
-
Switch Haiku to gcc4_hybrid (gcc4 is often used as an alias of Itanium C++ ABI in Haiku project, it is used by modern Clang ang GCC compilers) build as it was initially done when package system was introduced. Make gcc2 libraries optional.
-
Maintain backward compatibility with previous Haiku versions forever unless there are strong reasons to do otherwise.
4 Likes
https://dev.haiku-os.org/roadmap
Roadmap
Milestone: R1/beta6
Due in 7979 years (Jan 1, 9999, 5:00:01 PM)
75%
Total number of tickets: 117 - closed: 88 - active: 29
Milestone: R1
No date set
94%
Total number of tickets: 9188 - closed: 8632 - active: 556
Essentially, a fully working and stable operating system. A viable replacement for BeOS R5 (and later).
Depends on: R1/beta2, R1/beta3, R1/beta4, R1/beta5, R1/beta6
…
it is a long way to get R1.
so, just wait.
There are still some glaring issues that need to be addressed. You do t want miss the mark on the first stable release. A first good impression is a lasting one.
1 Like
Absolutely. Absolutely. Absolutely.
1 Like
Stop blaming everything on WebKit2. The current regression in WebKit is entirely my fault, and I “just” need to make a new release. Which was delayed by trying to also fix the 32 bit build. I’m trying MadMax’s suggested fixes now, but my 32 bit machine is old and slow (and possibly broken, I had some random compiler crashes that disappeared after a reboot) and so this will take a day or two.
Regardless, in the grand scheme of things, that is an easy fix and not really something that gets in the way of R1.
It depends what the vision is. One part of the vision for BeOS was to start from a clean state, and remove all the legacy support that Windows and Mac OS already had to maintain back then (it has only gotten worse since). Without sticking to some of that, Haiku will surely grow more and more big and complex and heavy, until it becomes just as frustrating to use as the other systems.
Now, we’re certainly not talking about a complete rewrite from scratch, and, of course, we have to think about maintaining compatibility with the existing applications. So we’ll have to find the right compromises there. That means, on one side, seeing how we can keep existing things working, maybe drop gcc2 but keep gcc13 with a stable ABI for example (or maybe not, this is just one possibility). And we have to think about what R2 really means, so that any possible new thing there justifies a breakage of compatibility. Can we make writing apps easier? Can we future proof things? Should we change the way we use ELF or switch to a better executable format? And in each of these cases, can we keep support for the existing thing?
I think yes, it is possible. We can keep libbe.so as it is and introduce a new libbe.so.2 (now with proper soname) with a slightly different version of the API, that may be unstable and experimental for a long time, while apps continue to use the old one. And when that new API is stable, and R2 is released, we can start deprecating the old one if it is still a reasonable thing to do at that time, but maybe it will not be, if there are many apps and some of them did not migrate.
All our years of keeping gcc2 support alive already show that we can do this: make new things, but keep the old ones working as long as reasonably possible and until they become irrelevant. Surely the R1 API/ABI will live a similar life, and be supported for years (or 10s of years) while the new (or just “updated”) API matures, and for some time even after that.
I would do things slightly differently (I don’t think we need a separate repository, just a different directory in the same git repository for example), but with the same general idea.
Except for this:
There is no need to plan for “forever”. Just like BeOS support has become largely irrelevant now, hopefully, in 25 more years, the Haiku R1 ABI will be irrelevant as well. Then it will be time to retire it. Hopefully by then Haiku will be wildly succesful, but I would place my bet on people complaining that it’s been 25 years since R1 and there is still no R2 
As long as Itanium C++ ABI is actual, there are no reason to bring some other ABI to Haiku. So no reason to retire. It you are telling about binary compatibility, there are a lot of room of improvement and introducing new features without breaking binary compatibility: use reserved virtual methods and fields, use ELF symbol versioning etc… There are no even a single important item in current binary compatibility breaking proposals, only cosmetic or opinionated things.
The only reason why BeOS ABI become obsolete is decision of GCC developers to abandon their C++ ABI and switch to Itanium C++ ABI. If GCC will still use their original ABI (or Be Inc. decided to continue use PE executables with Microsoft C++ ABI that is still actual today, why they even take a look at GCC…), there were even no reason to consider abandoning BeOS ABI support in Haiku because it will be not a burden at all, it will be the same as modern Haiku ABI.
1 Like
I used to consider 3D hardware support a must. Now I see how gpu drivers and firmware have eaten most of Linux kernel size and coding time. Also causing most of crashes.
However, I think we need support for external/dual output, so we can properly do talks at events with a laptop. I don’t know if it is possible but… perhaps fixing the vsync a bit. I remember using R5 Dano was the smoother experience I ever had on a computer. What was the trick?
In the security aspect, I would run from the multi-user approach of Linux but would be great to at least, have disk encryption.
last but not least, everything involving multimedia (wasn’t that one of the BeOS strong points?). ie: webcams, media encoding/decoding, a decent midi latency…
2 Likes
This solves only ABI problems, not API problems.
It is a different discussion.
Cleaning the API is about keeping the system simple and easy to use for programmers. Maybe to you that is only “cosmetic or opinionated”, but it is an important part of what makes Haiku fun. To develop an app for Haiku, you rarely have to consider some decision taken by some guys in the 1970s and the consequences that led to a complicated and un-intuitive thing.
Surely, people in the future will think the same of us.
Regarding the ABI, yes, usually you can play tricks. But in some classes, we have already run out of extra vtable slots, and just “refilling” these would be an ABI break. Sure, the idea is not to just do that and say “sorry, your old apps are broken now”, but to plan it in a way that we can do a smooth transition, over 20 or more years. I don’t think “it’s fine, we can keep these hacks forever” is a good way, so I’d prefer to plan now so that people in 20 years will be happy that they can finally retire some of these things, and make things simpler again.
Because the old ABI was broken: in some cases, two different C++ constructs ended up generating the exact same symbol name. So, they had a choice: change the ABI, or not implement the C++ standard.
Such things may happen again. Maybe some new C++ feature will require an ABI change. Maybe CPUs will retire support for 32 bit. Maybe RISC-V will take over the world and no one will want to use and support x86 anymore.
At some point, some change of that sort will require some kind of break. The next one is already scheduled: in 2038, just 13 years from now, our time_t type will overflow on 32 bit systems. There isn’t a way to get out of that without breaking old ABIs. Sure, we can introduce some hack, maybe a time64_t like glibc did. But this makes things complicated and confusing, and surely it’s not a thing we want to keep forever.
We can plan for it, and have it become irrelevant slowly and gradually while keeping it working. Just as we did for BeOS apps. It will be a slow and long term process, but I don’t think it will be a “forever” thing (as much as we’d like to, we can’t stop the world around us to move on)
1 Like
This can be handled with ELF symbol versioning like it is already done with BeOS struct stat.
Don’t create thousands of files locally, I don’t need them, I want my email to stay on my mailserver (I have 10+ years of email in my mailbox, and I don’t need to download it all)
This can be handled with more detailed control on the time frame of mails to synchronize. We shouldn’t ditch the wonderful data-centric concept that makes Haiku (and BeOS) so special just because of some practical and easy to fix issues.
Being able to easily query for mail, jump to recently opened messages and scanning/manipulating them with other applications instead of having to rely on a single bloated do-it-all app is a unique strength of Haiku that is one of the main reasons I still care about Haiku and develop for it.