HaikuOS running on RISC-V hardware (HiFive Unmatched)
discuss.haiku-os.org
discuss.haiku-os.org
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.
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.
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.
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.
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.
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.
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.
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.
This is not a workload os, or a workspace os, its a having fun os.
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).
The risc-v port probably benefited from the work stated above and stayed focused on a particular board.
Obviously the HaikuOS developers have just found RISC-V easier and having more potential. Or somebody just has sponsored the effort.
It's survived for 20 years despite having none. It will continue as long as there are interested developers.
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.
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.
http://www.tunetrackersystems.com/command-center-system-pack...
They have another system at the bottom of the page for a mere 1600 USD.
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.
Not knocking this Caster, but it might also be the ONLY Haiku OS commercial system
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.
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).
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.
Otherwise, have you raised the issue at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues ? They're pretty responsive.
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.
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.
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.
In no way is it acceptable for Linux to add 5ms to the chain.
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
2) There are no user accounts
3) Hardware support
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
2) it's coming in R2
3) see original 1
That said, Haiku isn't really any worse in this regard than currently existing desktop OS.s
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).
Unless it doesn't cough ppc32 cough
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.
https://mouser.com/ProductDetail/SiFive/HF105-000?qs=zW32dvE...
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.
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.