I suspect Linux has better hardware support than Haiku, which is not exactly easy to run on laptop hardware (w/ wifi, sleep, &c)
replyI suspect it was a freak occurence, but I actually had incredible luck running Haiku on an old laptop back in the day. It was incredibly fast, and just about all the amenities you'd expect worked with no or minimal intervention.
replyIn the last year sometime I ran the Haiku live image off USB on my only laptop (2011 X201t), it worked fairly well.
replyEven running from an HDD?
replyI recently tried the latest version (Beta 5?) on a 2005-ish PC with an even older HDD and it ran surprisingly fast off that. The only thing where it was somewhat slow was web browsing.
replyYeah. I installed it to HDD and it worked great. You'd think the thing had an SSD ot was so snappy. No issues with compat on the drive or anything.
replyYeah, a good opportunity to contribute upstream.
replyPresumably there's a lot more modern software written for Linux which you'd end up running through a compatibility layer from Haiku? The better option seems relative. I could be misremembering how Linux programmes are handled on Haiku though.
replyVitruvianOS has the clothes of BeOS, which is nice and refreshing.
replyBut Haiku has the soul.
Maybe the fallacy is not exploring what a given OS is great at?
replyWe don't need to clone UNIX all over the place.
How strictly do you mean “UNIX clone”? Because Linux isn’t strictly UNIX. But then at the other end of the scale, BeOS was also partially POSIX compliant and shipped with Bash plenty of UNIX CLI tools.
replyPerhaps it’s better to play it safe and just run DOS instead ;)
It certainly is, what it is not, is a derivative.
replyBeOS on its final commercial version certainly did not allow to compile UNIX applications, beyond the common surface that is part of ISO C and ISO C++ standard library.
But Vitruvian is running its own graphics stack so no X11 or wayland applications will run afaict.
replyNot quite really.
Vitruvian runs virtually the same identical sw stack of Haiku and there's a haiku-wayland that works.
However on vitruvian the app_server could provide real Gbm buffers, so that would give us pretty much native rendering.
We're still working on it but you'd have the advantages of a BeOS-like gui and the power of linux!
replySo what's the point of this -- it's essentially a different Haiku?
replyI think itbis the reverse, it is haiku with a linux kernel so it works with more hardware.
replydeleted
replyWith xlibe they should.
replyMaybe, but at some point you're duct-taping 90s driver hacks just to run Haiku on modern hardware unless you enjoy daily spelunking in kernel panics.
replyAnd things such as ruby don't work on it. Well, what shall
I say? The "best" ideas get beaten when in practically already
works very well - aka Linux. People need to compare to Linux
and if there are failure points, they need to fix it. Haiku
keeps on failing at core considerations. If you look at guides,
they recommend to "run in qemu". Well, that is a fever dream.
They need to focus on real hardware. And they need to support
programming languages just as Linux does. And modern hardware
too. Would be great if Haiku could shape up but the development
is way too slow. I've been looking at it for many years - they
are simply unable to leave the dream era. ReactOS is even worse
in this regard. At some point those projects gave up on the real
world. I think qemu, while great, kind of made this problem
worse, since people no longer focus on real hardware; the mantra
is "if it works in a virtual EM, it is perfect". Until one notices
that it doesn't work quite as well on real hardware. Case in point
how ruby does not work on Haiku. Ruby works well on BSD (for the most
part), linux (no surprise) and also windows (a bit annoying, but it
does work there too and surprisingly well, for about 99% of the use
cases, though it is annoyingly slower in startup time compared to
linux).
replyWhat does not work? You can install Ruby version 3.2.9 (2025-07-24) with a point-and-click package manager HaikuDepot and it works perfectly fine.
reply> I've been looking at it for many years - they are simply unable to leave the dream era.
replySit down and do the work needed to get Ruby running properly on Haiku instead of sitting here complaining and basically admitting that you're just being a noisy spectator... On HackerNews, no less.
Huh, PHP works on Haiku, and there aren't even that many #ifdefs for it in the source. If a language can be ported to Windows, Haiku should be a no-brainer. Seems more a matter of having someone interested in maintaining the port, and I think it ultimately just points to the size of Haiku's userbase being a rounding error.
reply> And things such as ruby don't work on it.
replyWhat doesn't work about it? We have Ruby in the software repositories, and Ruby is required to build WebKit (and we build WebKit on Haiku), so clearly it works for that much at least. I don't see any open tickets at HaikuPorts about bugs in the port, either.
Getting Rebol running on Haiku was fairly easy task, so I guess it shouldn't be that hard for Ruby too, if someone's willing to do the work.
replyPeople aren't really running servers on Haiku, which is basically the only relevance to use Ruby in 2026, Rails powered web applications.
replyThen again, there is a golden opportunity to become a Ruby contributor, road to fame on Ruby contribution list.
Maybe 5% of what I use Ruby for is on the server. I'd suggest those of us who use Ruby client side are likely to outnumber Haiku users by magnitude or two.
replyHomebrew would like a word.
replyHomebrew wouldn't support Haiku anyway.
replyMostly relevant for folks on macOS, and I skip on it when using Mac anyway rather using UNIX and SDK tools in the box, so kind of debatable.
replyDebatable because you don't use it?
reply