The biggest change last month is that I entirely rewrote the kernel’s “guarded heap” implementation. Some users may be familiar with the userland version of this, which we often ask users to try when encountering problems in userland software, with some invocation like LD_PRELOAD=libroot_debug.so MALLOC_DEBUG=g program.... This facility basically puts every single allocation on its own page, right up against a guard page. This is extremely inefficient, but it is very effective at catching buffer overruns (and, with memory reuse disabled, use-after-frees and double-frees; though not always ones that are race-sensitive) without recompiling anything.
As always a big thank you to everybody involved in Haiku development and especially to @waddlesplash for writing the detailed paragraph about the kernel guarded heap.
Thanks everyone, welcome new contributers, keep it up!
Unrelated really, but considering the steady improvements, are there any plans to start on a Beta6 release? The list of Beta6 milestone tickets isn’t short though… maybe some can be pushed to Beta7?
Great job all concerned with this months progress. As always.
I’d scrap the whole beta(X) until R1 convention where R1 just always seems to be next year, in favour of Month.Year nomenclature - e.g 11.25 if released now. This would be in line with Genode or Ubuntu, and reflects that people are already happily using Haiku as their main OS.
I woulkd reverse that, actually. If you just see the numbers, it is not immediately obvious that 6.2026 is an update to 11.2025.
Let’s drop the “20”. That sees us through until 2099 and is my grandchildren’s problem. Today’s release is 25.11 and next year’s will be 26.09 or whatever. More immediately obvious which one comes after which other one and more in line with how we number program versions.
And of course, Ubuntu also adds these two-word release descriptions in which the second word is always an animal. We are Haiku, so we can use poetry-related terms instead: Astonished Alliteration, anyone?
I second that.
Also, more broadly, the American way of writing dates (MMDDYYYY) confuses Europeans and others who use DDMMYYYY. It would be much better to make YYYYMMDD the default throughout. And the 24 hour clock instead of PM and AM.
But this is OT. Well done the developers for another productive month.
Credit where credit is due: while I had originaly started that change, my version wasn’t very good, and PulkoMandy was kind enough as to re-write it properly. Guess he just forgot to --reset-author when amending the commit :-).
by whom? There are still 500+ bugs in the beta1 milstone on Trac. Anyone who is not happy with the current numbering should go on the bugtracker, look at these bugs, and try to convince everyone that they are non-essential for an R1 release, that we should lower our expectations, and tell people that it’s ok to have half a thousand known bugs with no workarounds.
Maybe some people can use Haiku in its current state. But you have to be ready to spend some time tinkering with your computer, reporting bugs, etc. At the very least joining this forum to get some help and support. R1 will be when none of that is needed. When you start randomly hitting people you never heard about (not the usual suspects from the forum) casually running Haiku in unrelated contexts. Until then, it’s a beta and only suitable for early adopters.
Probably off-topic, but so are the comments that Haiku should switch to a more Ubuntu versioning system. I can’t think of a time when a versioning system change made people like the OS more, or made the OS function better. Since Haiku is based on BeOS, it should just retain that very simple and understandable versioning system.
Not that we have DR or PR, but adding a date like Windows or Ubuntu won’t clarify anything in a useful fashion. After whatever number beta (doesn’t matter what number Haiku gets to) it would naturally get to R1, R3, R5.0.3, R7.6.8. It’s quite obvious which versions are newer, and if they are released in 2042, 2099, 2106, it just doesn’t matter. Also that way, we don’t have to worry about Europeans who are confused by dates.
Suggestions for the good of Haiku that are based on making the OS more like another OS seem like bad ideas. If someone wants another Ubuntu like OS, or Windows like OS, they can just use one of those. People who want a Haiku-like OS or BeOS like OS would like to see Haiku keep those characteristics as much as possible.
My suggestion (or comment) for the good of Haiku, and this may already be the case, is that R1 shouldn’t be based on BeOS compatibility or replacement. We already have that with 32-bit Haiku, and 64-bit has already dropped such support. (Hopefully reintroduced in the future).
R1 should be based on usability. Fully functional browsers ported, and the current WebKit based one should be just as good as any other. Hardware support for entire lines of computers, focusing on audio, storage, and networking. Also something like GoBe that is fast and fully compatible with documents generated by other office suites. When it is completely usable for someone and they don’t need to switch to a different OS or computer for most browser, hardware, or application crashing issues, then R1 is appropriate.
Google around a bit and see the reviews in the general computing media. Every one starts with “20 years old and still in beta …” Now you and I know that this is pretty meaningless. Strictly speaking “beta” is supposed to mean “no new features, bug fixes only”, and our small number of devs are doing an incredible job. But out there, “beta” is perceived as “unfinished”. @squizzler and I were just exploring what one alternative might be. There are others. “The way BeOS did it” is not holy writ, after all.
I used to advocate for a 32-bit subsystem to run old BeOS apps myself. But I’m changing my mind on that. Seriously, what functionality did BeOS apps have that we still don’t have now with Haiku? Quite a lot if you disdain QT/GTK ports and insist on native apps only. But as soon as you make peace with the existence of ports, Haiku can now do far more. Running old apps for which licenses are no longer sold, purely for nostalgic reasons, is not a valid reason for major design changes IMHO.
Amen, brother!
Won’t argue with that
A fully native Office suite would be a flagship, something that we could point to with pride and use as a reason to use Haiku. Agree 100%
Actually writing such a beast would be a job almost as big as the OS itself. Keep in mind that the GoBe founders had prior experience from creating ClarisWorks. If this is set as a necessary milestone for R1, we’ll be seeing Beta 37 around my 100th birthday.
The posts get automatically created under the @Haiku account, and then manually changed to be authored by me. The forum software gets confused between the two sometimes it seems…
My statements about BeOS methods were in this case more about versioning. Keep it simple in this case, and avoid unnecessary Linux comparisons.
About the 32-bit compatibility, this isn’t needed for a release-quality operating system, but would be great if implemented in the future. Sort of like Rosetta or Windows compatibility mode.
I believe there are a couple of ported office suites, calligra and libreoffice if I’m not mistaken. The problems I had with them were slowness and crashes. However, I’ve not attempted lately with any computer newer than 2010. Picking a mainstream one and having it work just as well as on any other OS would be good.
These things working well would be good enough to not be considered beta. Fixing most of the OS bugs is great, but there will probably be bugs to fix for a long long time. When it’s usable by the general public without having to futz, I would say it can be considered release.
If we took a random version that is not ready and renamed it “R1” or woatever, the headlines would be “Haiku finally makes a non-beta release after 25 years, and it’s a huge disappointment”. The proper way to fix media opinion is to do proper press releases that explain the details, remind people what we call beta, and then the media can turn it into a story about how the other OS providers are much more careless about quality these days, and our beta is better than some of their releases.
