It’s always a special day on OSNews when Haiku has a new release. While OSNews was founded in 1997, it wasn’t until 2001, when Eugenia took over and relaunched the site, that we really got going. Eugenia came from BeNews, a popular BeOS news website, which shut down in the wake of Be, Inc’s infamous “focus shift” away from BeOS as a general purpose desktop operating system. BeOS continues to have a special place on OSNews ever since.
Today marks the release of Haiku R1/beta6, the first official Haiku release in two years. As such, this new beta covers a monumental amount of progress since beta5, progress I’ve reported on diligently. The highlights of this new beta include a port of Firefox (including branding) and many of its forks, much improve support for Qemu, a new memory allocated largely based on the one from OpenBSD, and improved support for various filesystems. Of course, there’s a massive list of performance improvements, memory management changes, as well as a truly massive number of new application ports.
It’s important to note, as I usually do, that while these Haiku beta releases serve as patches of calm in rough seas, Haiku is generally stable and capable enough that using the project’s nightly releases is usually a totally acceptable way of installing and running the operating system. If you’re not comfortable running nightly releases, however, and haven’t tried Haiku since the previous beta, you’re in for a massive overall improvement.
Everybody loves Haiku.
I ran into the issue that beta6 does not support Virtio disks anymore, resulting in an unbootable system. But changing the disk type to something else fixed that. I missed this in the Release Notes.
There was some discussion about mentioning this in the release notes or not but in the end it wasn’t included. Strictly speaking it’s not all virtio disks, it’s specifically
virtio_blockdisks;virtio_scsiis still supported (but I think virt-manager’s GUI just selectsvirtio_blockwhen choosing “virtio” and may not even have a GUI option forvirtio_scsi?)The driver is still in the tree, but it got disabled due to causing disk corruptions and kernel panics. Actually a fix to the virtio bus manager code was recently merged which may have been the cause of that problem, but nobody’s re-tested yet (it’s an intermittent problem and not the easiest to reproduce.)
Strikes me as very odd to choose Not to include a known system-breaking change. Even if the scenario is a small use case.
What was the justification for leaving it out?!
I have such mixed feelings about this.
First, yes, congratulations! I love Haiku and the BeOS legacy, and it’s new release is more or less daily drivable on a lot of real hardware. It has come a long way in the last few years, particularly with Firefox support, and so many other applications just work. Heck, Firefox on Haiku on low end laptops feels faster than it does on Debian. That had to have been a very hard task and I’m deeply impressed.
And yet, it’s also bittersweet. Haiku is a project I would love to contribute to. But, I’ve been contributing to open source projects for almost 30 years at this point and I’ve never run across a more weirdly passive-aggresivly negative group of core contributers in that time.
Their getting started page is excellent, with well written friendly documentation that covers everything you need to build, test and create patches. They even have a nice list of easy/beginner tasks to warm up with.
But as soon as you actually submit a patch, it very quickly becomes clear that the handful of core contributors consider it to be their closed playground.
Quite some time back I got very excited to contribute and tried to pick up a couple of those easy tasks, creating and submitting two or three PRs. It went like this:
Me: Here’s my first PR for $EASY_TASK. It does these things this way for these reasons and is about 12 lines long.
Reviewer: I don’t like it.
Me: Ok, well, I can also see taking approach B or C. What do you think? Or do you have another approach in mind?
Reviewer: No
Reviewer 2: Why is this code commented? Comments are superfluous.
I also tackled a much harder issue, hardware support for a something that was broken for me and from what I can tell a lot of people. After a rather frenzied, insomniac couple of days I tracked down the driver issue via references in the Linux and FreeBSD drivers for the same hardware. It turns out that according to that code, it’s not just my specific chip that is affected, but an entire family of them with the same fix. It turned out to be one line of real changes, plus some flags to set which hardware families it affects.
Me: Here’s a PR that fixes $HARDWARE. I’ve tested it on the hardware I have, but the Linux and BSD code states that it should apply to the entire family of chips. I think that means this will also fix bugs X and Y.
Reviewer: Why are you bothering to try and fix this if you don’t have all the hardware it could apply to?
At this point I have a handful other other fixes for clear, known bugs that I found along the way, including one for audio playback stuttering on first playback that you hear if you have a startup sound enabled or play a short file in MediaPlayer. But, as the reviewer said, “Why bother”?
And you don’t have to take my word for it. Take a look at the most voted issues in their bug tracker and you will find this attitude over and over. There’s 15+ year old issues in that list where someone offered to fix it or at least some simple approaches that could, but the core maintainers had such a negative attitude that people just stopped bothering.
StripedRiceBowl,
Haha, reviewers like that are one of the reasons code is so poorly documented! Comments CAN be excessive of course, but a complete lack of them often makes it impossible to gauge intent, especially in a language like C that is notorious for unintended side effects.
Yeah, you might well have been right, but one has to be careful in using linux as an authoritative source…it’s not. Testing with actual hardware is the gold standard. I wish hardware manufacturers released their own official authoritative FOSS drivers but they typically don’t. Linux drivers kind of get shoved into this role as a defacto source for FOSS driver documentation even though it shouldn’t be the case. Oh well :-/
Some social cliques don’t appreciate outsiders. I haven’t worked with Haiku myself but I can see why that would be off-putting.
Linux (and BSD) have their own headstrong personalities too. Linus Torvalds himself used to be extremely toxic but in recent years he’s fessed up to it and has become more caring and respectful of others.
> Yeah, you might well have been right, but one has to be careful in using linux as an authoritative source…it’s not.
That’s completely fair! I mean, I did verify with both Linux and FreeBSD, but if the reviewer had said, “Hey, lets only do this for the hardware you’ve actually tested it on, and maybe put out a call for people that can test it on the rest.” I would have completely understood. But instead I literally got, “Why bother?”
> Some social cliques don’t appreciate outsiders. I haven’t worked with Haiku myself but I can see why that would be off-putting.
Yeah, thats exactly it. The Haiku core maintainers are a tight clique that clearly don’t appreciate outsiders. Which is so weird of an attitude to run into after reading their contributing pages which are really well written and welcoming. I don’t want to be too much of a jerk, but they should probably just take them down to stop wasting their time and any one else’s.
I noticed this too, when I submitted some patches to work around a small bug in the terminal application it got rejected with “Not suitable for the project”. I tried to get clarification and I just got the same thing repeated back. I gave up.
I am not sure what your nickname is/was on the Haiku project systems, so I can’t check the code review history to see what happened here (I also glanced at rejected Terminal changes but didn’t see any that seemed to match), but if all we gave in reply to a rejection was “not suitable”, I do apologize. We do have exacting standards about code review and UI/UX changes, but we also try to give clear explanations and rationales of why we reject things. If there wasn’t sufficient clarity at the time, I’d be happy to try and provide some more.
Well, I’d like to apologize for your first impressions of us, it seems we didn’t do our best. I will say that in code reviews we tend to be quite rigorous amongst ourselves and with regulars, which can indeed be off-putting, and in the age of “AI” and people attempting things they don’t really understand we’ve probably gotten somewhat moreso about that as a defense mechanism. Which is an explanation, but not necessarily an excuse, so I’m sorry that we failed you here.
But I will also say that much of the context you give here, you gave much more obliquely in the patches you submitted, and had you given it, I practically guarantee we would’ve reacted very differently. For example, here you say:
Meanwhile your commit message says:
Re-reading the whole commit message I can now see that the implication is that this fixed audio output on your hardware. However it doesn’t actually say this, and I had to re-read it a few times to notice that. If you read many Haiku commit messages, you will notice there is a convention of saying “I tested this on my hardware” even (or especially) for commits where one’s own hardware isn’t expected to be affected by the change, in order to verify that the change doesn’t affect anything but the hardware it’s for.
So then when the end of your commit says “this probably fixes … though I don’t have the hardware to test it on”, I took it to be following this convention, and the implication being that the patch didn’t break your hardware but you also didn’t know if it fixed anything or not. If you had instead said “this patch fixes audio output on my hardware, and probably also …” that would have prompted a quite different reaction.
Meanwhile, here is what I said in response:
I now see that I was mistaken and you do have affected hardware, and had I read the commit message more carefully I could have deduced that, so I apologize. But why abandon the change instead of replying to me to correct my incorrect deduction?
My first sentence, though, remains correct: AFAICT the driver tries to automatically detect and activate the code you added a per-device feature flag for. In other words, the patch shouldn’t be needed, as the driver should do the equivalent using heuristics. I didn’t elaborate more there because I thought you were attempting a patch “blind” without really understanding the problem or the driver’s attempted mitigation. If I’d realized that indeed the patch fixes audio output on your hardware, I would’ve instead said something like: “Why is this necessary? Can’t we make the heuristic work on your hardware too?”
And if yes, then we could help you figure out how to make that happen, so even more hardware can benefit from the fix. If not, then yes, we’d take a patch adding per-hardware quirks.
So once again I apologize for our too-short reactions to your submissions. The long and elaborate response you have posted here provides some great context, though, and I think we would have appreciated getting these remarks even on the code review or bugtracker at the time. Was there something else that made you think you shouldn’t post them there?
Wow, thanks for the response. It it quite measured and I wish that I had gotten that level of discussion before.
I ended up abandoning the change, and everything else, because I have some health issues that often limit my energy and this combined with the other reviews, some comments in the forums (not the AI debate), and perusing the tickets just made it feel like this was a wall that I didn’t need to beat my head against.
For the techincal issue, yes, the driver does try to switch over to LPIB after 32 interrupts, which takes approximatly 1.4 seconds for the buffer size that hardware supports. However, by that time it is already too late. The HDAC_STREAM_POSITION has been reporting 0 the whole time, which is the hardware “quirk”, the buffers never get sent or filled, timestamps haven’t been sent, and for this hardware recovery fails. Presumably the recovery is working for other hardware, which is why I didn’t want to mess with the heuristic when this is a known issue for this hardware family.
I can understand that, and that’s probably more on us than it is on you, so I apologize again.
Hmm. It would be interesting to know why it fails and fix that, even if we do enable the setting via a flag. If you don’t intend to return to your patches, I may make a note of this and investigate later myself, perhaps by manually injecting this error into the driver or emulated hardware.
I don’t know if it is or isn’t at this point. We made a lot of changes to how buffers and timing are handled in the kernel/userland audio interfaces over the past couple years, and it’s possible that we inadvertently broke this.
I’d love to have someone (Thom?!) do an in-depth investigation on this. Talk to the core contributors. Look at other examples of this happening in the code base–as it appears that this isn’t an isolated event. Get both sides of the story.
Because there does seem to be a story here, one way or another. I’d be fascinated to know more. This kind of thing has a real impact on projects, one way or another. Software lives and dies based on these communities. Maybe the core contributors don’t care, but does the user base? And does the current user base know and care about this? They should.
It’s funny. A lot more than this has been going on. I booted “Haiku” on a G4 Mac Mini today. No mention of that. Is it because AI?
I don’t know if that’s why, but it sure is a good reason. Those kinds of things are cool for a minute, maybe as a proof of concept, but the people that “wrote” them don’t (i.e. can’t) maintain them, and rhe people that could maintain something like it written by humans can’t because it wasn’t.
quinn,
There’s a lot of resistance towards AI development. I’m also reluctant to replace humans. but I think that long term it’s going to be a difficult position to hold because AI has been improving by leaps and bounds. IMHO it’s going to keep getting harder for newer generations to complete against AI. I say this as someone who still codes things the “old way” myself. In the future people with our skills are probably going to resemble mainframe developers today – gray beards supporting old code bases with most of the world moving on.
In this case it brings Haiku to a new platform.
Haiku does not support G4 processors yet. You probably used Tabby, an AI coded fork of Haiku.
Yes. You missed the quote around Haiku?
Lol, no did not miss them, but you clearly forgot you asked a question and I was answering that.
I enjoy so much Haiku, especially the beautifully consistent and functional interface (just as we were discussing in the Motif article earlier this week) but, heck, the fact that everything is running as root puts me off so badly for running it as my daily driver. And perhaps also the lack of an encrypted file system. I’d love to. I’d still need to boot Windows to run my film scanners and play Flight Simulator, but I could easily use Haiku for everything else. I hope we get there at some point soon.
If you like the BeOS UI, you may be interested in this:
https://gitlab.com/haydentech/cosmoe
Well done, guys! This is our favorite OS. That soon as posible arrive the Final version, towards the Haiku 2.0 with Glass Elevator and 3DEyes Hardware Acceleration branch
I am wondering how I would choose between the x86 and x86_64 versions, I know there’s an advantage of the former of being able to run (more) original BeOS applications, but are there disadvantages? What is the version you suggest?
I can only speak of my personal experience running Haiku, but as someone who used BeOS as a daily driver from 2000 through about 2003, I feel like the x86_64 branch has enough ported software to be a better fit for most people exploring the OS today. The only reasons a regular user would want to stick with the x86 branch is for compatibility with original BeOS era software that has no modern equivalent or native Haiku port, or on a really old 32bit-only device that won’t boot the x86_64 branch, or a combination of those needs.
32-bit can’t let one process use more than 4GB of RAM. BeOS hardly had any software to worry about compatibility with, and Firefox can definitely use more than 4GB of RAM. Might still be fine on 32-bit because I’m fairly certain Firefox does multiprocess, so you might not need >4GB of RAM for just one of its processes, but again… there’s not really anything anybody’s likely to need to use that’s from the ancient times
I may be wrong but I don’t believe Firefox or any of its forks on Haiku can run on the 32-bit branch, they all run native x86_64. The built in WebPositive works fine on 32-bit.
We all love Haiku
A truly awesome OS
Let’s all make it /home!