Other than BeOS nostalgia: is there any good reason to prefer Haiku over [name any modern Linux distribution]? I can see that it’s fun to hack on an OS and make it your own. But is Haiku actually known to do anything particularly well that other operating systems struggle with?
BeOS was a good desktop, and Haiku reproduces it well, providing a high quality desktop experience.
Meantime, the usual Linux desktops continue to fail at even the basics, such as low quality file dialogs that e.g. change your selection after you've already clicked.
Other than that, BeOS system kits are elegant, so are its APIs for drivers and filesystems. Linux does instead have a huge, ugly, syscall interface.
It just takes enough perspective to not see UNIX and its clones as the "end it all" of what an operating system should be, and then you'd realize it's actually pretty hard to come up with anything that Linux does better.
At its core, Linux offers variety, while Haiku strives to be a unified system. There is only one official UI, one sound API, one filesystem, one preference system, etc. making Haiku easier to administer. The system kits are designed to work together.
For instance, I created a from scratch video editor for Haiku which does 4K UHD videos with OpenGL based plugins, with over 30 effects, and 10 languages. The installer package with no dependancies is 1.3Mb (fits on a floppy disk). https://github.com/smallstepforman/Medo Under Linux, I would require many more dependancies since I have no guarantee what libraries or API’s the users have installed.
> Under Linux, I would require many more dependancies since I have no guarantee what libraries or API’s the users have installed.
That is an unfortunate, probably unavoidable, byproduct of the freedom that brought Linux on so many computers, platforms and users. Everyone can write a software, or fork an existing one, nobody enforces a standard for development or integration. I guess it's not easy to build a giant free community around a free software and keep consistency.
It's a mess, and has been a necessary one when the aim was to spread Linux as much as possible, but now we're paying the consequences. (Which is why I believe the day Microsoft will reveal their Linux distro, bringing stability and unification behind a known brand, is the day all non technical die-hard users and more importantly most commercial entities that use Linux will abandon the usual distributions, essentially killing them.)
Haiku however was born as a clone of a closed system, and only recently is seeing some media coverage; there's no guarantee that, should it one day reach Linux' level of popularity, the influx of developers , users, and demand for more software, won't create the same issues there as well.
> That is an unfortunate, probably unavoidable, byproduct of the freedom that brought Linux on so many computers, platforms and users.
People love to bash linux for this and they are right. The single feature that makes linux historically suck on the desktop is the one reason it succeeded everywhere else.
> is there any good reason to prefer Haiku over [name any modern Linux distribution]?
That's the problem. There are too many Linux distributions to 'support'. From a developer standpoint. I have to 'define Linux support' and need to draw the line somewhere and pick a Linux distro and write a guide for it.
Several people will ask if their distro is also supported and another one will ask, followed by another one with the same question and then you would be updating more than 10 troubleshooting guides and maintaining more than 10 CIs for 'official' support. That's very expensive and this is why you cannot target 'all' Linux users.
On the other hand, I can support all Windows users 100% of the time. Same thing with macOS, and Haiku also has little to no fragmentation and that means I can give 1 CI per OS. Not 10 or 20. Even Redox gets it right with the same idea.
It's nice to see an open-source OS for once that has a sane desktop, usable software and is unified just like Windows and macOS.
That's just because no one actually uses HaikuOS or RedoxOS (no offense to these wonderful projects of course). If these came even remotely close to the popularity of Linux, you'd have remixes, spin-offs, and eventually full-blown distributions.
You can try to prevent it with project structure, but even something really unified like FreeBSD ended up having derivatives like GhostBSD as well as full-blown divergent forks like DragonFly BSD that are not necessarily compatible anymore with upstream.
Fuchsia is based on the same idea and has support to just one OS. The BSDs are not even a good example of 'something really unified' from the start anyway.
The actual reason for all of this is that the distro's themselves (and the BSDs) bundle 'hundreds' of external third-party system packages as first party just to get a 'basic desktop working'. I don't want to start pointing fingers at where a bug could be located at as it would be very painful to maintain and start searching through the whole Linux or BSD desktop stack. Good luck with that.
The only difference with the BSDs is that they just have a different kernel. Everything else has the exact same software stack just like many Linux distros.
Hence this, with having little to no OS fragmentation, it is also the reason why everyone only targets Mac and Windows. 'Official support' gets very expensive when 10 or 20 distros need to be tested on a CI or guides need to be updated as users tweak or mess around with their Linux distro.
> The only difference with the BSDs is that they just have a different kernel. Everything else has the exact same software stack just like many Linux distros.
This is true once you install a bunch of desktop stuff from ports and packages, however, any of the *BSDs are much more cohesive than Linux in the base system.
And I guess even the degree of desktop integration varies. On OpenBSD X11 is part of the standard installation. On FreeBSD it comes from ports.
I prefer Haiku over any Linux distro. For me it is the tight UX and GUI that makes it a very good desktop. I’d rather have more native developed software instead of ports but I understand why ports are crucial.
As a tinkerer I would love to run HaikuOS for the fun of it. BeOS gives a really enjoyable user experience and the things we can achieve make them more than good enough for me.
This is not a workload os, or a workspace os, its a having fun os.
This is awesome but this is a rather strategic move. Hopefully RISC-V boards will emerge and this will become practical. Today, however, a RaspberryPI port could make more sense.
It is strange to me that the RISC-V leapfrogged past the Pi port (per https://www.haiku-os.org/guides/building/port_status the ARM, including the Pi, exists but isn't very useful yet); I wonder why it made progress so fast even with poor hardware availability.
as far as i can tell, the whole point of haikuos at this point is "fun". as pointed out e.g. at https://en.wikipedia.org/wiki/Haiku_(operating_system)#Criti..., haiku will never be a "mainstream" os. it seems plausible to me that riscv enablement is more "fun" than figuring out how to mangle crappy proprietary drivers enough to barely run.
The Haiku community was quite resistant to the idea of supporting the Pi, a resistance which was only partly technical in nature.
These days I would say it is essentially a matter of focus. Considering that the Pi 4 is a tiny little beast hardware-wise (certainly good enough to run as a light desktop, which is what I use it for), Haiku would be amazing on it, but I just don’t see it happening (if it was meant to be, it would have come about by now).
I think there are several reasons and my understanding is probably mostly wrong. First, the original port was using Uboot and then the focused shifted to uefi. Around the same time efforts shifted from a port to raspberry pi to use fdt and support for arbitrary boards. This should give a more flexible solution with the downside being less focused development.
The risc-v port probably benefited from the work stated above and stayed focused on a particular board.
It looks like it has almost leap=frogged past the PC port as well.
(A cheap shot but it does not yet boot on my PC and I wish it did.)
I have bought dedicated hardware to run interesting systems before; but feel like I am over that; low volume systems are expensive and stock PCs are cheaper and faster.
I can see the attraction of RISC-V though, hope it takes off.
Perhaps. But this means Broadcom propagates itself the adorably right way, beneficial to everybody. Also note "all the additional bite people end up buying" is mostly made by other parties, often small indy businesses. E.g. I have bought a 3D-printed chassis suiting my needs from a local vendor (and they also offer the source model and customization on demand).
It's always nice to see the wonderful advancements the HaikuOS devs make. As an operating system it's very nice and fun to use. It gives me the same vibes as old workstations from the 90s. Although it still has a bit longer to go before it could be considered as a daily driver for any useful assortment of applications.
Why not serious in this case? A full-featured browser makes is the most important thing to make an OS usable today, isn't it? Of course I assume all the basic stuff like file system and device drivers, relevant multimedia codecs, bash or a likely-featured shell, SSH, basic GNU/BSD/alike command-line tools are already there. And that things like LibreOffice, ImageMagick, LaTeX, GnuPlot, Inkscape, VLC, runtimes like CPython and OpenJDK are next in the queue. But what is the most important thing which makes an OS usable today? For me it seems obvious it's the browser. If only there was a browser supporting all the today standards (including the H264 and AAC codecs support) I would already be able to do everything I need in it, the rest mentioned (after "And that things like") would just make my life slightly more convenient and fun.
I am very pessimistic. I think it would need a strong usp or some killer app. Maybe going into hard real time direction might allow it to live in a niche in audio and machine operation console. But currently I don't see a path.
Realtime audio on hardware that isn't sold by Apple would be quite a killer reason to use Haiku. Especially seeing Apple is progressively abandoning the Pro, configurable market again.
They released a Mac Pro, as configurable as you could desire, less than two years ago and have a replacement already in the works. They aren’t abandoning the market.
It starts at 6000 and has similar specs to $2600 dell or alternatively a $1500 machine you could build.
Just going from the dinky 256GB SSD your 6000 machine comes with to a more reasonable 2TB actually takes you to 6800.
Furthermore for this very substantial price you are buying a machine on an arch they are in the process of abandoning a bigger issue than the price.
To recap in 2013 the trash can came out. It was I guess OK but by 2015 its specs were noncompetitive. Between 2015-most of 2019 there was no real great answer for a mac tower. At the cusp of 2020 the new tower emerged followed 1 year later by the announcement that everything is moving to arm sooner or later.
Out of the last 8 years there has been one year in which it was a great year to get a mac tower and only if you are rich.
Yes. But you get properly working real-time audio out of the box with the Mac Pro that you don't get with any PC system.
Assuming that this is true (which it is based off of the other comments) then that is EASILY worth the extra 4000 or even 10.000 USD to someone who needs real-time audio to do their recording or other audio creation job.
When I became a professional (in another field than audio/music) I developed 0 tolerance for tech that didn't work or that has me fiddle around with it for hours to work. It financially just doesn't make any sense to spend your time on that. It also doesn't make any sense from a mental health and free-time point of view.
I think that was the point (even though I'm not knowledgeable on the subject, other than having spent many day of my hobby-life trying to get Cubase to record with audio monitor (VST) without jittery latency on Windows and utterly failed).
People who aren't in the industry don't really realize that the Mac Mini is the entry-level into audio production for most people (iMac is the same for video). It has just enough to get started, and when you're making the big bucks the Mac Pro is in fact affordable for what you get.
Developers only see MacBooks for so long that they forget the rest of the product line exists, yet it's there for a reason.
What profession is the Mac Pro targeted? They used to be great for video production and 3D modeling, animation, and light baking, but the current version just isn’t good enough and I’m seeing more and more professionals opt for a pc with a big dedicated gpu.
I would definitely consider Haiku for music if it had the same low latency capabilities as BeOS, but latency aside, a lot changed since the BeOS era: today pretty much all non consumer audio interfaces are external, therefore driver support for them is needed as well. Also it's not uncommon to see hybrid systems in which
Linux runs a DAW and its plugins under WINE. It's a mess to configure and breaks very easily (lesson learned: don't do that in your tinkering machine that you upgrade often or install/compile different kernels etc. use a separate machine for Linux+music), so a WINE port would be useful as well, but I guess it'd be a huge job.
Yes, this product historically was a BeOS product, and eventually it became cheaper to put together a version of Haiku with no show stopping bugs for their customers on hardware you can actually buy than to try to find hardware that would still run an obscure 1990s operating system.
The very first versions of this product are essentially BeOS, plus an existing MP3-player type application, plus a little bit of software glue, the right off-the-shelf hardware and the know-how to use it for radio broadcast.
It's definitely one of those products some HN regulars would dismiss as "I could basically make that in an hour". Me too. But, after an hour nobody else can maintain it and it doesn't work on anybody else's computer. The hard work is in turning that into a product that generates some net revenue, which is mostly non-technical work.
I've heard that Haiku's audio APIs are similar to those of BeOS, which are harder to use than today's APIs. I hope they can be improved though, if Haiku is a better foundation for real-time media than standard Linux (or even realtime).
The BeOS Media APIs enshrine a strange way to think about multimedia latency, which is maybe useful if your central idea is that you need to synchronise audio and video through different production pipelines, but doesn't serve real time audio work at all.
I believe Haiku did eventually fix some of the most egregious mistakes in their audio handling for example for years if you played silence it made everything else quieter, which is a classic goof†. But it's a long way from ideal for this application. You can of course use anything, if your hobby is making music with Haiku, knock yourself out, same with a ZX Spectrum or a toy xylophone, but yeah, not ideal.
† How do I mix samples for N channels together? Adding them together and dividing by N ought to work right? No.
The Haiku MediaKit API was available 5 years before Fabrice Bellard published ffmpeg, and back in the early 90’s BeInc’s goal was to attract the next successor to the NewTek toaster, and to be the next real time audio mixer. This is why they emphasised chaining of media nodes and sorting our “performance time” synchronisation issues with their API. The famous BeOS marketing video demos such a device.
BeOS kernel allows unique app access to a shared memory area, eliminating memory copies when sharing data. When creating the shared area, media apps can set several media access flags to engage the “fast path” if the devices have that buffer. These days modern graphics API’s (eg. Vulkan) offer the same buffer creation hints to help the driver figure out where to best allocate memory (device local, host accessible etc). Because not all memory is equal.
I’ve used both ffmpeg API and BMediaKit (I’m the author of a Haiku native video editor, https://github.com/smallstepforman/Medo). The BMediaKit API is trivially easy to use. ffmpeg is notoriously convoluted. Likewise, the native GUI API is also a pleasure to use. This is why my open source media editor is Haiku native (and not cross platform).
Since Pipewire, the Linux view on audio is changing a lot. The latencies are not what they used to be. Even if Haiku becomes more usable, it's unlikely to achieve a massive difference.
Conversely, in my own experience, Pipewire removed everything I held dear, destroyed my will to compute, and has somehow crippled my systems for the purposes of multitasking with any type of media playing.
Hyperbole aside, I'm glad someone was looking at the audio situation, but this one seemed to knock me out of the game on every machine that received it. Examples of common scenarios for me: I can't have firefox open and virtualbox at the same time, or bitwig and firefox, or visual studio and audacious. Common pairs of apps cause a bitrate mismatch for whatever reason, and everything sounds like a heavily bitcrushed and ring modulated signal.
The exception to this are machines that were installed with pipewire, rather than upgraded to pipewire. Also, using Cadence, a router type app helps, but inconsistently.
Does the PREEMPT_RT patchset matter wrt. audio latencies in Linux? That seems to be the biggest effort wrt. "low latency" workloads at least on the kernel side.
It does for latency and reliability, but in my experience running the xanmod kernel with just preempt without rt provides low enough (sub-5ms) latency that I stopped caring about RT in my home recording use.
5ms is an eternity, and without PREEMPT_RT I get xruns at 5ms on jack, which is (still) far better than pipewire on the same hardware.
Even with PREEMPT_RT, I can't even run 2ms pipelines without xruns.
I don't think this is within the realm of fixable. Linux simply isn't a good design for this. Kernel too large and unpredictable. Who knows when or if execution will return to userspace.
It depends on the use case, I'm quite happy with 5ms :-)
Ftr, on Pipewire on a Dell xps with iRig2, I'm getting 4.6ms reported with just PREEMPT. An xrun every few minutes if I try to go to ~2ms. I suspect I could get that working reliably with RT.
People are weird about this. Because audio is ultimately a vibration moving through the air, latency is equivalent to distance because sound can only travel a few hundred metres per second.
So, 5ms is less than two metres. When COVID-19 forced you to stand a little further away from people, did you find it added "an eternity" of latency to everything? No? You barely noticed? Right.
One exercise that's interesting is you can build a physical loop (e.g. speaker plus microphone) and play with how long it takes samples to leave your software, turn into audio, then re-enter and come back to your software. You might find that to your disappointment a software stack may be giving you just 256 samples of latency but your hardware adds say 8 milliseconds on top of that.
This approach also helps you ensure you're doing apples to apples comparisons.
Latency is the whole chain. That's Linux's latency, on top of everything else that could be there, such as however many meters of distance between speakers and listener in a live performance.
In no way is it acceptable for Linux to add 5ms to the chain.
Audio latency is only measured in the air once it leaves a transducer. You're comparing apples to oranges here and deliberately misunderstanding the issue.
Are there any Pi/Nuc style boards one could get to run this on? I’m an old BeOS user and would love to have a little device to play with for nostalgia.
I ran Haiku on my Nuc for awhile. It is starting to show its age, i.e. doesn't support locking your desktop, no multiuser support etc. As an also old BeOS user, it's purely nostalgia at this point
Can't answer for parent, but my personal biggest gripes are:
1) No graphical acceleration yet
2) No application sandboxing mechanism (yet?)
3) A package manager that doesn't seem to have a reason to exist.
To expand on 3: Native Haiku software really has no need for a package manager because it has no need for dependency management. It appears the only real reason to have it is so Qt can be installed as a dependency for the ports that need it. Why not just provide Qt in the base system? According to the developer I talked to, its because they want to encourage people to write against the native API. Ok, so why support this use case at all? Because ported software is better than no software. Either I am still misunderstanding something or this is an incredibly strange decision.
Which isn't to say I don't like Haiku, indeed it understand Desktop as a usecase far better than any Linux distro that ever existed, I just have those particular gripes.
As far as reasons others might not like it:
1) I hear that porting some POSIX software is a bit jank
As always, AnIdiotOnTheNet has valid comments, but you cannot dismiss a journey because its too far, you need to start with the first steps and eventually you'll get there.
1) re: graphical acceleration, it will come when the user base increases, the 3 big players will eventually want skin in the game
2) re: sandbox mechanism, yes it's missing, however since Haiku has a read only package system, the damage a rogue app can cause is much smaller eliminating the need for sandboxing in the first place. Also, the Haiku system is easy to restore, and from a user point of view, I care more about preserving my data, not protecting a system that I can easily restore. This is also a fault of most OS's out there, they protect you from installing a driver, and do nothing for protecting your family photos.
3) see 2
1) re: posix, Haiku has similiar issues as the BSD's in that POSIX != Linux
Regarding your reply for 2: I completely agree, however the immutable packages do nothing to protect my personal files. Any modern Desktop OS should recognize the need to distrust applications by default.
That said, Haiku isn't really any worse in this regard than currently existing desktop OS.s
Personally, I found it painfully mouse-heavy (ditto Plan 9); on *nix, I can use i3+tmux+vimium+keynav and basically never touch the mouse. This matters particularly on laptops where the keyboard is good and the mouse, such as it is, sucks.
Thanks. I'm kind of surprised that Firefox doesn't have the ability to compile with a pure C/C++ platform-independent javascript interpreter for odd architectures.
It does, actually: the POWER9 Raptor Talos II I'm typing this on uses the C++ interpreter entirely right now. (We're working on a JIT: https://www.talospace.com/2021/07/firefox-90-on-power-and-ji... ) I don't see any reason you couldn't build Firefox on a RISC-V system.
EDIT: Actually, there is a reason, but it's not JavaScript. Firefox needs stubs written for XPCOM to map the ABI for XPConnect calls. Once this is done, it should "just work;" it's not difficult (I rewrote them for ppc64 myself).
Nowadays you have to contend with Rust, LLVM, Skia, and the other porting headaches...
There are XPCOM stubs for a lot of platforms in Mozilla. Mostly bitrotted, but even if they're fully restored, I just don't think Firefox is that portable anymore.
Although apparently there's a RHEL package for Firefox on s390 that worked fairly recently, so I dunno.
EDIT: Using Debian as an example, the latest version is available on x86{_64}, ARM{64}, mips64, and ppc64le. And s390x. ppc64 is in debports.
32 bit MIPS is lagging behind a few versions, no idea if it just hasn't been rebuilt or there's a new blocker. sparc64 is stuck on 62, it probably can be patched up but judging by some bug reports is sort of similar to ppc64{le} in needing some TLC, and I doubt anyone is really using it. hppa/m68k are stuck on 52/50, left behind with the move to Rust I'd assume.
All I'm saying is in practice I'd expect porting firefox to a new platform to be a pretty involved effort. Even if you have LLVM and Rust support, there's a lot of moving parts inside, and it's not like the old days where most of the platform specific bits were inside NSPR.
This is an amazingly fast progress, can't wait to try it on my Unmatched board... and the port is more or less still the work of one or two persons IIRC.
I'm running Ubuntu 21.04. As for using it as a daily driver, you might be disappointed with the performance. It's slower than a Raspberry Pi 4. Also, no Firefox or Chrome browsers (yet). You have to use Epiphany.
It's really targeted as a development platform and that's how I'm using it. I just SSH to it from my x86 box.
Yup, the CPUs are around half the speed of those in a Pi4, and around the same or a bit better than a Pi3. The RAM is much bigger and better than a Pi3 (16 GB of DDR4), and also bigger than the biggest Pi4. You can run a real GPU in the PCIe slot and a fast SSD in the M.2, so things that use a lot of I/O rather than CPU tend to be pretty snappy. The gig Ethernet also works well. So does ethernet on the Pi4, but Pi3 is a bit lacking.
RISC-V CPU cores equivalent to the Pi4 were announced around 1.75 years ago and the way these things go are probably getting to the stage of working test chips right about now, and boards in the first half of next year.
Obviously the price is much higher than a Pi, bit it's not out of line with x86 PCs (just a low slower). If you're actually working professionally on RISC-V software then the HiFive Unmatched is affordable, and enough more productive than the current alternatives to be worth it.
Later in the year, the BeagleBoard BeagleV "StarLight" will have the same CPU specs as the HiFive Unmatched for $120 (4 GB RAM) to $150 (8 Gb RAM). That's still above Pi prices, but much closer. It will have I/O closer to Pi specs than PC specs.
RISC-V is still in its infancy, but progress is rapid.
