Just a heads-up for those trying it out, I've found a couple of regressions in Beta 6 that rendered my Haiku system unbootable, until I remembered about hammering the space key during the boot sequence to get to the safe mode menu.
In my case, my ThinkPad X1 (Yoga 3rd Gen) used to boot despite what appeared to be kernel panics, but typing "continue" at the kernel prompt would skip past them and everything would then work fine. In Beta 6, it now hangs at boot instead with no kernel panic warning. Disabling ACPI in the safe mode options gets me past that, and there's a way to disable ACPI permanently at boot via some configuration files - though obviously that isn't desirable.
It also seems there's been some work on USB Audio (yay!), but it now causes a kernel panic on boot if a Focusrite Scarlett is connected. Turning the Scarlett off avoids the kernel panic. The Scarlett has never officially worked in Haiku, but it at least never used to crash the system. In my case, I've reverted back to the USB Audio Scarlett Haiku driver that Claude Sonnet vibe coded for me, and for me that's working. (I can't contribute that code because of Haiku rules against AI code, but hopefully the humans will eventually find time to hand code it and get it working.)
I think there should maybe be shadow repositories available for Open Source projects where things like your driver could be contributed.
I get why Haiku does not want to deal with it do this is not a criticism. But I have also used AI to port software and create drivers. Others may not have the ability, even with AI. Perhaps I have docs you don’t. And some of it took a reasonable amount of money and time. I am not going to dedicate that to everything I might use if it was available. And in addition to wasting duplicated money and time, we are destroying the earth recreating things others have already done.
I use Chimera Linux and I have thought about starting a repo just for the stuff that I have ported.
I am not sure what the exact answer is but I hope this is something we figure out.
This is one of the things I like with NixOS: it's easy enough to add new packages and patch existing ones that stuff like this can either live in the core nixpkgs repo or be managed through some community-supported overlay. (Great example of this is [nixos-hardware](https://github.com/nixos/nixos-hardware) which shares settings and fixes for specific laptop models and the like, or [emacs-overlay](https://github.com/nix-community/emacs-overlay) which has a bunch of extra Emacs-specific stuff that would not belong in the core repo.)
Will do, I think I recognize your username from the forums :) Life is getting in the way and makes it difficult to write a bug report with the necessary level of detail & logs. But when I can find time, I intend to.
I think the ACPI issue is long standing, but I can't find my bug report anywhere in Trac. I'm fairly sure I've made at least one report, I created my Trac account roughly 6 years ago. But I also remember running into issues with Trac, so maybe it never went through.
Haiku should rethink that AI rule. Put very high code quality gates in place, sure, but Haiku in particular is a very low-velocity project and AI could help them so much. There is no reason you can't produce high-quality code with AI conformant to your style guidelines and structural preferences, it just takes a lot more effort than the slop.
I'm curious why velocity is sooooo important. Every single AI discussion that I've read always always always mentions velocity or development speed as though that somehow is the ultimate goal. Why does it matter if your velocity isn't as fast as everyone else? Maybe taking things slowly might actually be a good thing.
I'm not at all trying to be overly critical or pissy; I'm genuinely curious as to why this is always the gain that AI brings as though it matters (or, rather, this is how it's always stated in one way or another). So I come from a place of confusion when asking this. Why should I care if you can write 100000 or 1000000 lines of code and push out 10 billion commits per minute? (Yes, I am intentionally exaggerating here to prove a point.) If anything, I would argue that increased velocity just brings about recklessness and unnecessary churn instead of accomplishing anything useful.
Velocity is important because we all eventually die.
I've been following Haiku since it was announced. In that time a couple of personal friends have passed on, and a number of family members. In that time children have been born, gone to school, grown into adults, and had children of their own.
Projects that drag on forever make for an interesting artistic statement, but if their goals in any way include utility then velocity is important because time is important.
Not everything has to happen in your or my lifetime. Not everything will happen in our lifetimes. If time is so important, Haiku was never going to work for you anyways on account of it being niche, which adds friction, which adds time. Velocity isn’t going to fix this either
Velocity of LoC isn't important. Velocity of user visible improvements can matter if a project feeds off of usage and popularity. Or at least that velocity matters until the OS is capable enough to satisfy the user base.
I... Don't agree with this. If your users have followed your projects developments even remotely reasonably, you taking a few months to implement something or to figure something out is not a sign that the project is dead. It would be one thing if your project was completely inactive for like 2-3 years.
Haiku OS has gone up to 6y between releases. While not entirely inactive in that time, lurkers who aren't as motivated to dig for signs of life could reasonably conclude the project is inactive.
For example, I'm a big fan of DOSBox. And while the core project still has some code check-in's from time to time, its last release was 7ya. Now I use and follow forks because they're consistently releasing useful features and fixes.
My understanding is that the AI policy is more to do with issues of copyright and code provenance. They want to make sure that all of their code is cleared with no risk of accidentally using 'stolen' code or GPL code repeated by an AI. I can at least understand the policy.
I think there's other opinions around AI use there as well, but I'll back off from that. I didn't mean for my post to become top voted, when we should be celebrating Haiku reaching Beta 6. I'm just disappointed that for me, R1/b6 has been a very big regression, right at a time when I've been using AI to make all the software I write cross-compatible with Haiku via Go & SDL, and even use AI to write drivers so more of my hardware works on Haiku... and instead, now I can barely even boot the system.
No one is trying to get rich from working on Haiku. They are doing it for fun, as a passion project. Sure AI would help with velocity but velocity is not the only goal. Journey before destination.
Also: Open source is about relationships.
Reviewing code sucks. However at least reviewing code from humans allows you connect and learn from each other. You get to mentor someone. Build a relationship and trust. They learn and grow and maybe someday can also review other people's code.
Nowadays with lots of low effort merge requests and spam it is already easy to burn out. Now add AI. Yeah, no. Why should anyone review AI slop for free. Why? It is the prefect solution to burn your contributors out.
I have no qualitative opinion as to whether the Haiku team should reconsider the AI rule or not, but you select about just one possible advantage. There may be disadvantages using AI. One that keeps on happening is that real humans use AI slop spam to pester other humans with it.
> There is no reason you can't produce high-quality code with AI conformant to your style guidelines and structural preferences, it just takes a lot more effort than the slop.
It's not just code though. There are humans who deliberately and actively use AI slop to spam people. I saw this first on gobolinux, then on prawn, then on the ffmpeg mailing list. There are really good reasons why many humans dislike the proliferation of AI slop spam.
> Haiku in particular is a very low-velocity project and AI could help them so much
I am not entirely certain about that. If AI were to work so well, Haiku-AI could have already been insta-spawned and auto-fixed everything. Clearly this does not work, so I am unconvinced that AI is the final solution to everything - at the least right now.
What is also unfortunate about Haiku is that things such as ruby do not work by default. Ruby even works on windows, though on Linux it is much more convenient to use.
I'm so happy. Haiku to me, is visually the most beautiful operating system out there. The icons, apps, designs. If there be anything that can ever steal the spotlight from Mac; it would be Haiku. And the OS is perhaps the one and only one that remains a tool in the old sense. All other operating systems are now service and signups and telemetry and notifications; this is the last resort remaining for the rest of us. I only wonder sometimes when it is going to become usable. With LLMs I'm wondering can't they be put to find the stability issues and make the solving faster?
What really sets Haiku (and the preceding BeOS) apart is that it's built for the express purpose of being a desktop operating system. As good as desktop Linux has gotten it still suffers from servers being the chief use case for Linux-based OSes, seen in quirks such as how poorly it handles running out of memory (not as big of a deal in the server world, particularly in the container era; just tweak your setup and reboot your containers). It's not bogged down with corporate IT needs either.
The last time we got an OS that was as purely desktop-end-user-oriented with no competing influences was Classic Mac OS, which had serious technical issues.
The problem is, Linux is improving too quickly for Haiku.
I have been looking forward to running Haiku as a daily driver for years. And it is almost there. It may even be good enough now for many people. Modern browsers really help.
But I was amazed recently when I put Haiku on an old laptop that was already running Linux. I remember Haiku being so lean and fast and multi-tasking so smoothly. But honestly Linux felt faster on this machine. The memory usage was about the same (a real shock to me). And I missed being able to use containers. So, I ended up putting Linux back on.
This bummed me out because I have been a Haiku fan forever and it has never been better. But when I tried to use it, I could not convince myself there was any benefit (other than diversity). And the reason had nothing to do with applications or drivers.
> The problem is, Linux is improving too quickly for Haiku.
Ain’t it the truth. It’s really great now the snowball is fully in flow down the mountain with Linux. But at the same time it’s sad that there’s little time for anything else. We are a bit of a victim of our own success. We beat the drum in the 90s that Linux needs to win and now that it won what does it really mean. Free and open source to do anything but at the same time, why in the world use anything else. We have come a bit of a Chromium in that regard (or it became us?)
Cosmoe and VitruvianOS are two different approaches of "Haiku" you may find interesting.
Cosmoe works at the application toolkit level, allowing to build and run BeOS/Haiku apps on Linux. The toolkit is then implemented using Linux classic APIs.
Vitruvian is Haiku on the Linux kernel (with some extra modules).
could you point them out? i actually did a search but could not find much. there are GTK themes, but nothing i could find that converts a gnome desktop. stuff is either incomplete or outdated. i actually managed to get half BeOS theme together for KDE, and i still use that on my desktop. but it's inconsistent, and in particular the tab style window management is missing, which is really the best part of the interface.
> such as how poorly it handles running out of memory
What is interesting, FreeBSD last time I used it, had far ,pre simple predictable kernel OOM killer. Anyway, I always either switch off swap on Linux machines or install EarlyOOM.
I guess this depends on how you see things. Windows was meant to be a desktop OS and crashed all the time. Probably still does, but the wise have abandoned that burning ship.
Linux, however, rarely crashes on a desktop, and when it does, it is usually due to a graphic card driver that doesn't want to work there.
Windows crashing all the time? I haven’t experienced crashes since WinXP… Or when trying beta drivers and overclocking. As a day to day windows and OSX user, I’ve had more stability issues with OSX than Windows.
Windows has gotten more stable, that's for sure, but I have seen BSOD's on every single edition of Windows, and that's only on my personal life. In my time in corporate IT I can tell you that Windows is generally much more problematic than MacOS for a variety of reasons, though modern MacOS certainly has its share of issues. But again, that's in a corporate IT environment, not regular consumer usage. Not sure how you got away with no crashing in your Windows experience, but congratulations!
Nvidia drivers crashed Windows 7 for me multiple times and so did virtualization software (VMware in particular). I had Windows 10 crash a few times when I last touched it doing really nothing special. I'm not using any ancient software or obscure peripherals. But yeah, if it works on your machine then I guess...
Perhaps I’m contrasting it to my Windows ME experience…
But, I have seen BSOD multiple times, it’s just that I could trace the problem pretty easily, to something like IRQ interrupts and faulty hardware, MB needs to be replaced, bad driver needs to be downgraded, things like that. And it used to happen a lot more often.
Overall, I just think XP and NT kernels kind of solved this, in large part, by improving the system logging, sys internal tools, adding system restore, etc
On my MacBooks, however, whenever I get the beach ball, I rarely have any idea what to do, and have reinstalled or changed random hardware multiple times.
So yeah, I’ve had my share of problems with all systems, and worked in different environments, but personally I have rarely seen BSOD compared to all the other issues.
Even before the more recent enshittification, Windows has long suffered from prioritization of corporate/enterprise needs over those of end users, rendering various parts of the system more complicated than they need to be. This is visible going back to 3.x/9x; the versions of Mac OS (and BeOS) of the same vintage are more friendly and approachable on several fronts.
> If there be anything that can ever steal the spotlight from Mac; it would be Haiku.
I looked at the Haiku slideshow and I'm not seeing this. It looks like an eye sore, desktop environments familiar of the 90s. Even early OSX is a massive improvement (as it was to the NeXT desktop).
Don't get me wrong; Mac is light years ahead. What I mean is the level of harmony and design integrity the Haiku has. I doubt that any corporation can ever have even the team that used to make the icons of Tiger/Leopard era. The scrollbars of the Leopard or the whole Aqua. But given their team size and small scale of Haiku; this is one amazing job. The apps, the website, the icons; the documentations... all are in harmony and you don't find it anywhere else.
All of that has been straight copied from BeOS, which was a real corporation worth millions of dollars and in the cutting edge of technology at the time.
I agree, it's arguably clean, and definitely an improvement over Windows 98 era GUI, probably also XP era. But the world has moved on. Even KDE looks better today.
I honestly don't get this, what have we gotten since that's a considerable UI improvement? Bigger paddings? Flat UI?
IIRC you can even configure custom colors, have dark mode, etc. It might look dated with the gray color scheme but that's really the only thing I can guess would look dated to someone.
Haiku could theoretically fill a niche for music production workflows. Ultra tight MIDI timing and sequencing, low-latency audio and a beautiful desktop. I hope this dream comes true eventually.
I worked on a Elektron MachineDrum firmware fix that corrected the MIDI jittering due to incorrect ISR configuration.
MD itself is pretty tight already with its RTOS but the fix brought it down to microseconds.
I was pretty proud of it because it solves a few phasing problems.
I then turned this over to a friend running a lot of Elektron boxes, and his reaction was, "you mean the sound we've got is wrong? how strange!"
So while I feel the same urge to have ultra tight MIDI timing, I doubt this would be a general interest of the non-technical musicians out there.
IMHO, it's not just DAWs keeping people on main OSes, but plugins. On the Linux side, Reaper, arguably one of the most popular options on Windows/macOS, has been available since 2018, BitWig is a good Ableton-like experience, and Ardour is also decent. But on the side of plugins - in my case drum VSTis and amp sims - the selection is still quite limited.
I would love to give Haiku a try. Indeed, I've looked at it's code before (it's quite good, or was, last time I looked at it). What prevents me is accessibility. To be fair to Haiku, implementing an actually good accessibility stack is genuinely a nightmare that AI isn't going to help much with, were you to ask it to help you with it. Primarily because many accessibility stacks (UIA, MSAA, IAccessible2, AT-SPI, ...) are massive collections of incredibly nasty hacks. I have yet to find an accessibility stack that is actually well-designed, thought out and future-proof. And screen readers are pretty much collections of good code alongside a bunch of app-specific workaround as well which just complicates things.
All of that said, I might fire it up if only to play with it from the console if I can get something like SSH working.
In a world where Haiku is widely adopted, I figure its accessibility model would be much like that of Windows XP, in that it works by not restricting you from doing things, rather than specifically allowing certain things. XP and Haiku let the user do pretty much whatever, and for this reason, many disabled people still rely on systems like XP.
Menu that does different things based on modifier keys seems novel to me, is BeOS or Haiku the first interface where menus take modifier keys into account?
Tried Haiku on an old laptop. Loved it. Then realized Linux feels just as fast now and has containers. Haiku is cool, but it's losing the lightweight edge.
Congrats to the team, I adore Haiku from afar and hope they continue to do good work. Had to do a bit of debugging with some code I help maintain for the new release, but it was a fun excuse to mess around with it a bit again.
I tried Haiku recently on a not-super-old PC and was impressed by the speed and the reasonable availability of software. I then wished I could run this on my old Powerbook G4 because nothing else seems to run there anymore with ease, and this seems like the perfect desktop OS for such old machines. And it turns out there is now a fork for PPC: https://github.com/ActionRetro/Tabby-PPC !
(Why a fork? Because it's primarily vibecoded and Haiku won't take the patches upstream. But hey, I'm gonna give it a try anyway.)
I wish Haiku all the best. It's always great to see some diversity in the FOSS OS landscape. Hope it finds its niche eventually like the BSDs did after the lawsuit drama.
Also, for Haiku users: What is the experience like using LibreOffice on it? And i - is it the popular office suite, or is there another one, perhaps more focused on the OS rather than cross-platform?
Just a heads-up for those trying it out, I've found a couple of regressions in Beta 6 that rendered my Haiku system unbootable, until I remembered about hammering the space key during the boot sequence to get to the safe mode menu.
In my case, my ThinkPad X1 (Yoga 3rd Gen) used to boot despite what appeared to be kernel panics, but typing "continue" at the kernel prompt would skip past them and everything would then work fine. In Beta 6, it now hangs at boot instead with no kernel panic warning. Disabling ACPI in the safe mode options gets me past that, and there's a way to disable ACPI permanently at boot via some configuration files - though obviously that isn't desirable.
It also seems there's been some work on USB Audio (yay!), but it now causes a kernel panic on boot if a Focusrite Scarlett is connected. Turning the Scarlett off avoids the kernel panic. The Scarlett has never officially worked in Haiku, but it at least never used to crash the system. In my case, I've reverted back to the USB Audio Scarlett Haiku driver that Claude Sonnet vibe coded for me, and for me that's working. (I can't contribute that code because of Haiku rules against AI code, but hopefully the humans will eventually find time to hand code it and get it working.)
I think there should maybe be shadow repositories available for Open Source projects where things like your driver could be contributed.
I get why Haiku does not want to deal with it do this is not a criticism. But I have also used AI to port software and create drivers. Others may not have the ability, even with AI. Perhaps I have docs you don’t. And some of it took a reasonable amount of money and time. I am not going to dedicate that to everything I might use if it was available. And in addition to wasting duplicated money and time, we are destroying the earth recreating things others have already done.
I use Chimera Linux and I have thought about starting a repo just for the stuff that I have ported.
I am not sure what the exact answer is but I hope this is something we figure out.
This is one of the things I like with NixOS: it's easy enough to add new packages and patch existing ones that stuff like this can either live in the core nixpkgs repo or be managed through some community-supported overlay. (Great example of this is [nixos-hardware](https://github.com/nixos/nixos-hardware) which shares settings and fixes for specific laptop models and the like, or [emacs-overlay](https://github.com/nix-community/emacs-overlay) which has a bunch of extra Emacs-specific stuff that would not belong in the core repo.)
Looks like a user that was porting to ARM64 disagrees with the Haiku AI stance:
https://github.com/rcarmo/haiku-arm64-build#haiku-arm64-buil...
Makes sense. I had codex port haiku to arm64. Works decently, fun to play with on my Mac.
What I'd love to see (but likely lack the skill to, even with Claude Opus) is PowerPC. Haiku would look great on an iMac G4.
Maybe share my old article with Haiku developers: https://clickhouse.com/blog/agentic-coding
Could be a small chance, but it has already made many engineers reconsider their AI stance.
Feel free to reach out, I will be happy to try help with these issues :)
Will do, I think I recognize your username from the forums :) Life is getting in the way and makes it difficult to write a bug report with the necessary level of detail & logs. But when I can find time, I intend to.
I think the ACPI issue is long standing, but I can't find my bug report anywhere in Trac. I'm fairly sure I've made at least one report, I created my Trac account roughly 6 years ago. But I also remember running into issues with Trac, so maybe it never went through.
Haiku should rethink that AI rule. Put very high code quality gates in place, sure, but Haiku in particular is a very low-velocity project and AI could help them so much. There is no reason you can't produce high-quality code with AI conformant to your style guidelines and structural preferences, it just takes a lot more effort than the slop.
I'm curious why velocity is sooooo important. Every single AI discussion that I've read always always always mentions velocity or development speed as though that somehow is the ultimate goal. Why does it matter if your velocity isn't as fast as everyone else? Maybe taking things slowly might actually be a good thing.
I'm not at all trying to be overly critical or pissy; I'm genuinely curious as to why this is always the gain that AI brings as though it matters (or, rather, this is how it's always stated in one way or another). So I come from a place of confusion when asking this. Why should I care if you can write 100000 or 1000000 lines of code and push out 10 billion commits per minute? (Yes, I am intentionally exaggerating here to prove a point.) If anything, I would argue that increased velocity just brings about recklessness and unnecessary churn instead of accomplishing anything useful.
Velocity is important because we all eventually die.
I've been following Haiku since it was announced. In that time a couple of personal friends have passed on, and a number of family members. In that time children have been born, gone to school, grown into adults, and had children of their own.
Projects that drag on forever make for an interesting artistic statement, but if their goals in any way include utility then velocity is important because time is important.
Not everything has to happen in your or my lifetime. Not everything will happen in our lifetimes. If time is so important, Haiku was never going to work for you anyways on account of it being niche, which adds friction, which adds time. Velocity isn’t going to fix this either
Velocity of LoC isn't important. Velocity of user visible improvements can matter if a project feeds off of usage and popularity. Or at least that velocity matters until the OS is capable enough to satisfy the user base.
I... Don't agree with this. If your users have followed your projects developments even remotely reasonably, you taking a few months to implement something or to figure something out is not a sign that the project is dead. It would be one thing if your project was completely inactive for like 2-3 years.
Haiku OS has gone up to 6y between releases. While not entirely inactive in that time, lurkers who aren't as motivated to dig for signs of life could reasonably conclude the project is inactive.
For example, I'm a big fan of DOSBox. And while the core project still has some code check-in's from time to time, its last release was 7ya. Now I use and follow forks because they're consistently releasing useful features and fixes.
I imagine that their issue is reviewer bandwidth.
If all submissions were high-quality, it would probably work. But that is probably unlikely.
Maybe the project could host a searchable directory of AI contributions hosted at external GitHub repos or something.
My understanding is that the AI policy is more to do with issues of copyright and code provenance. They want to make sure that all of their code is cleared with no risk of accidentally using 'stolen' code or GPL code repeated by an AI. I can at least understand the policy.
I think there's other opinions around AI use there as well, but I'll back off from that. I didn't mean for my post to become top voted, when we should be celebrating Haiku reaching Beta 6. I'm just disappointed that for me, R1/b6 has been a very big regression, right at a time when I've been using AI to make all the software I write cross-compatible with Haiku via Go & SDL, and even use AI to write drivers so more of my hardware works on Haiku... and instead, now I can barely even boot the system.
> I imagine that their issue is reviewer bandwidth.
This feels to me as the real bottleneck in general. Maybe along with thinking through what to code/prompt.
I don't need more tokens or automated generation of PRs, I'm already at capacity for the care and understanding I want to have for code I own.
No one is trying to get rich from working on Haiku. They are doing it for fun, as a passion project. Sure AI would help with velocity but velocity is not the only goal. Journey before destination.
Also: Open source is about relationships.
Reviewing code sucks. However at least reviewing code from humans allows you connect and learn from each other. You get to mentor someone. Build a relationship and trust. They learn and grow and maybe someday can also review other people's code.
Nowadays with lots of low effort merge requests and spam it is already easy to burn out. Now add AI. Yeah, no. Why should anyone review AI slop for free. Why? It is the prefect solution to burn your contributors out.
I think the most productive thing is:
1. Read rules about not using AI
2. Reflect upon and understand why they exist
3. Develop software however the f*ck you want
4. Ensure it is high quality
5. Open a PR
6. Don’t tell anyone (i.e. don’t do the things people hate about AI-assisted code)
People are going to get made at this take but come on, we’re trying to build things. Use the hacker spirit. Make things that solve problems.
I have no qualitative opinion as to whether the Haiku team should reconsider the AI rule or not, but you select about just one possible advantage. There may be disadvantages using AI. One that keeps on happening is that real humans use AI slop spam to pester other humans with it.
> There is no reason you can't produce high-quality code with AI conformant to your style guidelines and structural preferences, it just takes a lot more effort than the slop.
It's not just code though. There are humans who deliberately and actively use AI slop to spam people. I saw this first on gobolinux, then on prawn, then on the ffmpeg mailing list. There are really good reasons why many humans dislike the proliferation of AI slop spam.
> Haiku in particular is a very low-velocity project and AI could help them so much
I am not entirely certain about that. If AI were to work so well, Haiku-AI could have already been insta-spawned and auto-fixed everything. Clearly this does not work, so I am unconvinced that AI is the final solution to everything - at the least right now.
What is also unfortunate about Haiku is that things such as ruby do not work by default. Ruby even works on windows, though on Linux it is much more convenient to use.
I'm so happy. Haiku to me, is visually the most beautiful operating system out there. The icons, apps, designs. If there be anything that can ever steal the spotlight from Mac; it would be Haiku. And the OS is perhaps the one and only one that remains a tool in the old sense. All other operating systems are now service and signups and telemetry and notifications; this is the last resort remaining for the rest of us. I only wonder sometimes when it is going to become usable. With LLMs I'm wondering can't they be put to find the stability issues and make the solving faster?
What really sets Haiku (and the preceding BeOS) apart is that it's built for the express purpose of being a desktop operating system. As good as desktop Linux has gotten it still suffers from servers being the chief use case for Linux-based OSes, seen in quirks such as how poorly it handles running out of memory (not as big of a deal in the server world, particularly in the container era; just tweak your setup and reboot your containers). It's not bogged down with corporate IT needs either.
The last time we got an OS that was as purely desktop-end-user-oriented with no competing influences was Classic Mac OS, which had serious technical issues.
The problem is, Linux is improving too quickly for Haiku.
I have been looking forward to running Haiku as a daily driver for years. And it is almost there. It may even be good enough now for many people. Modern browsers really help.
But I was amazed recently when I put Haiku on an old laptop that was already running Linux. I remember Haiku being so lean and fast and multi-tasking so smoothly. But honestly Linux felt faster on this machine. The memory usage was about the same (a real shock to me). And I missed being able to use containers. So, I ended up putting Linux back on.
This bummed me out because I have been a Haiku fan forever and it has never been better. But when I tried to use it, I could not convince myself there was any benefit (other than diversity). And the reason had nothing to do with applications or drivers.
> The problem is, Linux is improving too quickly for Haiku. Ain’t it the truth. It’s really great now the snowball is fully in flow down the mountain with Linux. But at the same time it’s sad that there’s little time for anything else. We are a bit of a victim of our own success. We beat the drum in the 90s that Linux needs to win and now that it won what does it really mean. Free and open source to do anything but at the same time, why in the world use anything else. We have come a bit of a Chromium in that regard (or it became us?)
Cosmoe and VitruvianOS are two different approaches of "Haiku" you may find interesting.
Cosmoe works at the application toolkit level, allowing to build and run BeOS/Haiku apps on Linux. The toolkit is then implemented using Linux classic APIs.
Vitruvian is Haiku on the Linux kernel (with some extra modules).
https://gitlab.com/haydentech/cosmoe https://v-os.dev/
There are Haiku/BeOS-style window manager/GTK themes if that suits your needs better.
could you point them out? i actually did a search but could not find much. there are GTK themes, but nothing i could find that converts a gnome desktop. stuff is either incomplete or outdated. i actually managed to get half BeOS theme together for KDE, and i still use that on my desktop. but it's inconsistent, and in particular the tab style window management is missing, which is really the best part of the interface.
https://www.opencode.net/phob1an/besot
https://github.com/B00merang-Project/Haiku
https://github.com/B00merang-Project/BeOS
https://gitlab.com/metsatron/BeOS-r5-GTK
https://gitlab.com/metsatron/BeOS-r5-XFWM
https://www.opendesktop.org/p/1012423/
https://www.opendesktop.org/p/1016430/
> such as how poorly it handles running out of memory
What is interesting, FreeBSD last time I used it, had far ,pre simple predictable kernel OOM killer. Anyway, I always either switch off swap on Linux machines or install EarlyOOM.
I guess this depends on how you see things. Windows was meant to be a desktop OS and crashed all the time. Probably still does, but the wise have abandoned that burning ship.
Linux, however, rarely crashes on a desktop, and when it does, it is usually due to a graphic card driver that doesn't want to work there.
Windows crashing all the time? I haven’t experienced crashes since WinXP… Or when trying beta drivers and overclocking. As a day to day windows and OSX user, I’ve had more stability issues with OSX than Windows.
Windows has gotten more stable, that's for sure, but I have seen BSOD's on every single edition of Windows, and that's only on my personal life. In my time in corporate IT I can tell you that Windows is generally much more problematic than MacOS for a variety of reasons, though modern MacOS certainly has its share of issues. But again, that's in a corporate IT environment, not regular consumer usage. Not sure how you got away with no crashing in your Windows experience, but congratulations!
I didn’t mean to say it never happened. It’s just that when it happened it was a memory stick, MB, or other non Windows specific issue
Nvidia drivers crashed Windows 7 for me multiple times and so did virtualization software (VMware in particular). I had Windows 10 crash a few times when I last touched it doing really nothing special. I'm not using any ancient software or obscure peripherals. But yeah, if it works on your machine then I guess...
Perhaps I’m contrasting it to my Windows ME experience…
But, I have seen BSOD multiple times, it’s just that I could trace the problem pretty easily, to something like IRQ interrupts and faulty hardware, MB needs to be replaced, bad driver needs to be downgraded, things like that. And it used to happen a lot more often.
Overall, I just think XP and NT kernels kind of solved this, in large part, by improving the system logging, sys internal tools, adding system restore, etc
On my MacBooks, however, whenever I get the beach ball, I rarely have any idea what to do, and have reinstalled or changed random hardware multiple times.
So yeah, I’ve had my share of problems with all systems, and worked in different environments, but personally I have rarely seen BSOD compared to all the other issues.
Even before the more recent enshittification, Windows has long suffered from prioritization of corporate/enterprise needs over those of end users, rendering various parts of the system more complicated than they need to be. This is visible going back to 3.x/9x; the versions of Mac OS (and BeOS) of the same vintage are more friendly and approachable on several fronts.
Yep, I used 3.x and Tabworks. Mac also had a habit of crashing and inopportune times in that era. BeOS, though, was in a league of its own...
> If there be anything that can ever steal the spotlight from Mac; it would be Haiku.
I looked at the Haiku slideshow and I'm not seeing this. It looks like an eye sore, desktop environments familiar of the 90s. Even early OSX is a massive improvement (as it was to the NeXT desktop).
Don't get me wrong; Mac is light years ahead. What I mean is the level of harmony and design integrity the Haiku has. I doubt that any corporation can ever have even the team that used to make the icons of Tiger/Leopard era. The scrollbars of the Leopard or the whole Aqua. But given their team size and small scale of Haiku; this is one amazing job. The apps, the website, the icons; the documentations... all are in harmony and you don't find it anywhere else.
All of that has been straight copied from BeOS, which was a real corporation worth millions of dollars and in the cutting edge of technology at the time.
Very good point!
I agree, it's arguably clean, and definitely an improvement over Windows 98 era GUI, probably also XP era. But the world has moved on. Even KDE looks better today.
I honestly don't get this, what have we gotten since that's a considerable UI improvement? Bigger paddings? Flat UI?
IIRC you can even configure custom colors, have dark mode, etc. It might look dated with the gray color scheme but that's really the only thing I can guess would look dated to someone.
We are these days blessed with the gift of elegantly useless skinny scrollbars
Looks like Windows 98. Which is of course a compliment.
I mean, Linux is still pretty squarely in service of the end user.
>All other operating systems are now service and signups and telemetry and notifications
What are you talking about? That doesn't make any sense.
Haiku could theoretically fill a niche for music production workflows. Ultra tight MIDI timing and sequencing, low-latency audio and a beautiful desktop. I hope this dream comes true eventually.
I doubt this, but hear me out for the reason:
I worked on a Elektron MachineDrum firmware fix that corrected the MIDI jittering due to incorrect ISR configuration. MD itself is pretty tight already with its RTOS but the fix brought it down to microseconds. I was pretty proud of it because it solves a few phasing problems.
I then turned this over to a friend running a lot of Elektron boxes, and his reaction was, "you mean the sound we've got is wrong? how strange!"
So while I feel the same urge to have ultra tight MIDI timing, I doubt this would be a general interest of the non-technical musicians out there.
correctness of minor logic details is of general interest to no one, but of substantial benefit to everyone
Tunetracker[0] radio automation software (not sure what else it did/does) started on BeOS, then moved to Haiku. After 25 years(!)[1] it's on Mac now.
[0] https://www.tunetrackersystems.com/
[1] https://rbr.com/tunetracker-ditches-beos-haiku-for-mac-backb...
I think it'll need a compelling DAW to make that a reality.
IMHO, it's not just DAWs keeping people on main OSes, but plugins. On the Linux side, Reaper, arguably one of the most popular options on Windows/macOS, has been available since 2018, BitWig is a good Ableton-like experience, and Ardour is also decent. But on the side of plugins - in my case drum VSTis and amp sims - the selection is still quite limited.
I would love to give Haiku a try. Indeed, I've looked at it's code before (it's quite good, or was, last time I looked at it). What prevents me is accessibility. To be fair to Haiku, implementing an actually good accessibility stack is genuinely a nightmare that AI isn't going to help much with, were you to ask it to help you with it. Primarily because many accessibility stacks (UIA, MSAA, IAccessible2, AT-SPI, ...) are massive collections of incredibly nasty hacks. I have yet to find an accessibility stack that is actually well-designed, thought out and future-proof. And screen readers are pretty much collections of good code alongside a bunch of app-specific workaround as well which just complicates things.
All of that said, I might fire it up if only to play with it from the console if I can get something like SSH working.
In a world where Haiku is widely adopted, I figure its accessibility model would be much like that of Windows XP, in that it works by not restricting you from doing things, rather than specifically allowing certain things. XP and Haiku let the user do pretty much whatever, and for this reason, many disabled people still rely on systems like XP.
Code blooms, Haiku flies
A new release greets the world
Congrats to the team
Summer nears its end
And Haiku blooms like heather
New flowers emerge.
I see what you did there.
Lurking eyes perceive
Your clever, veiled slight, well played.
I tip my fedora.
Fedora got a syllable dangling
Fed'ra
> User interface and user experience improvements
https://www.haiku-os.org/get-haiku/r1beta6/release-notes/#:~...
Menu that does different things based on modifier keys seems novel to me, is BeOS or Haiku the first interface where menus take modifier keys into account?
No, macOS has changed menus using the Option key since it was known as System.
I love the UI style of HaikuOS, so cool to see new ports like Firefox and a Go runtime in this release. Congrats to the team!
Tried Haiku on an old laptop. Loved it. Then realized Linux feels just as fast now and has containers. Haiku is cool, but it's losing the lightweight edge.
Congrats to the team, I adore Haiku from afar and hope they continue to do good work. Had to do a bit of debugging with some code I help maintain for the new release, but it was a fun excuse to mess around with it a bit again.
Still rocking an older Haiku alpha install on a netbook. Might be time to spin up a VM and see how far this beta has progressed.
What do you use the netbook for?
Always love seeing Haiku releases. Brings back memories of trying it out on an old machine, still hoping for a modern browser.
I tried Haiku recently on a not-super-old PC and was impressed by the speed and the reasonable availability of software. I then wished I could run this on my old Powerbook G4 because nothing else seems to run there anymore with ease, and this seems like the perfect desktop OS for such old machines. And it turns out there is now a fork for PPC: https://github.com/ActionRetro/Tabby-PPC !
(Why a fork? Because it's primarily vibecoded and Haiku won't take the patches upstream. But hey, I'm gonna give it a try anyway.)
Please report back and let us know how that goes. Curious to see how well it works.
I wish Haiku all the best. It's always great to see some diversity in the FOSS OS landscape. Hope it finds its niche eventually like the BSDs did after the lawsuit drama.
Hopefully, it won't be a small niche. It would be great if Haiku ends up getting used for meaningful work.
Has anyone tried installing Haiku on old mac 2012 intel and older ? How challenging would that be ?
I just so happen to have a 2008 Core 2 Duo MacBook Pro doing nothing. I followed the directions at:
https://www.haiku-os.org/guides/uefi_booting/
and it installed and booted without any issues.
Congratulations to the haiku team!
I wonder if they got it to run smoothly in Qubes yet?
I can't see steve blamer's face without remembering how fun beos was in the 90s.
Me thinking Anthropic released a new version of the haiku model....
Are there usage statistics for Haiku?
Also, for Haiku users: What is the experience like using LibreOffice on it? And i - is it the popular office suite, or is there another one, perhaps more focused on the OS rather than cross-platform?
congrats to waddlesplash and team