Some of the software ported to this OS [0] (some not on this list but looking at their repo [1] ):
LibreOffice
Krita
Telegram
Jetbrains (PyCharm, ItelliJ)
Rust, Node.JS, Python, Java 12
Qt Creator
Arduino
Obviously there's more in their repo, looking promising though. (Try find your favourite software in there!)
[0] https://www.haiku-os.org/get-haiku/r1beta2/release-notes#mor...
The Linux desktop is a horribly fragmented and fragile ecosystem. Haiku lacks a lot of features the Linux kernel has, but the overall system architecture and design is significantly cleaner and less fundamentally fragile.
Do you have any tips or pointers? Thanks in advance
Qt Creator is indeed in the depots and works pretty well, so you can use that.
If you have more questions, feel free to find us on IRC (Freenode#haiku), the forums, the mailing lists, the bug tracker, or (for ported software) on GitHub (@haikuports/haikuports). Or continue asking here if you prefer :)
Here is the code for the Magnify App in Haiku: https://github.com/haiku/haiku/blob/master/src/apps/magnify/...
In Haiku, on the other hand, the bootloader, the kernel, window manager / display server, init system, base applications, etc. are all developed by one team in one source code repository.
Recommended exercise for people who might be inclined to believe this hogwash: Go find where in that "one source code repository" for Haiku they implement RSA to make their web browser work.
You won't find it. After a while you'll dig down to a layer that just calls OpenSSL, the same OpenSSL you'd be calling on a Linux distribution. Was this developed by Haiku's "one team" in their "one source code repository"? No of course not and yet here it is, foundational to their operating system.
I'm not sure what arguments I made "don't quite stand" simply because you need to use Qt apps. In fact I was arguing that using Qt apps is perfectly alright! LibreOffice is not "native" on Windows or macOS, but people still use it there, yes?
Of course there is going to be third party code, its immensely complicated to "make a web browser work".
Show me a GNU TCP/IP stack or socket implementations. Oh, wait.
Also, OpenSSH. GNU LSH exists, but it's... ahem. A bit misrepresented; if not, not at all.
We have no interest in trying to port Chromium. Even OpenBSD, which uses X11 that Chromium already has a native backend for, has thousands of lines of patches they have to maintain (and spend hours and hours rebasing every upgrade). Haiku would have to maintain far more than a few thousand lines, as we would have to add a new graphics backend at the very least.
Firefox is better in this department, but has a codebase larger than Haiku itself, and none of us have any expertise there. If someone knowledgeable about Firefox's codebase wanted to port it, we'd be happy to help where we can, but there's only so many of us.
Wow, you're not kidding. https://github.com/openbsd/ports/tree/master/www/chromium/pa... is positively scary.
Or you want to use Xrdp to connect to your desktop via Windows RDP, but the default shipped configuration enables the wrong plugin, so you can connect but get cryptic errors when signing in, so you have to edit the Xrdp configuration file and change the plugin load order and then restart X11 while signed in via SSH (happened to me a few months ago, on 18.04 LTS.)
Those are just two examples off the top of my head; back when I did use Linux as a daily driver, I would spend multiple hours a month fixing something that got broken or did not work as it was supposed to, and this was just on Ubuntu, not even on Arch or some more up-to-date distro like that.
I’ve been a desktop Linux user for at least 27 years (pre 1.0 days), and I can’t get Ubuntu to work at all anymore. (Ubuntu was my daily driver for over ten years.)
I agree with the sentiment that Linux stability isn’t where it should be. I swear it used to be better. I’m definitely looking for a new OS. OpenBSD is on my list. I think I’ll give Haiku a spin. I liked BeOS back in the day, but couldn’t afford hardware it ran well on.
Have matured non-native 'apps' is a big YESYES, it flattens the adaption curve.
Hope more peoples test Haiku, they will love it, its so fast and un-bloated and still has everything a Desktop OS need's...oh man and the startup...i mean even OpenBSD feels bloated, the booting time is phenomenal.
Yes, absolutely, spot on.
But an OS does not exist on it's own. I'm afraid it will all be for naught unless you (or someone) has a viable business model to push the surrounding ecosystem forward.
And yes, macOS users probably also tell you that they prefer macOS, though note that they also are often very loud about preferring software that takes advantage of their OS' features because this is why they use that OS.
The thing is, macOS has a much richer selection of software than Haiku has (and most likely, ever have) so macOS users at least can fall back to those. But if all you are going to use on Haiku is ported software that ignores native APIs then what is the point of using an OS with less hardware support and features?
The Linux desktop being fragmented doesn't mean much - your Qt application ported to Haiku will also work on KDE perfectly fine and chances are even if you limit your software selection to Qt-only applications, you'll still have more applications to work with. Though that fragmentation is really a poor description since there are standards you can rely on, like X11 - sure someone might be using Gnome or XFCE or Window Maker or i3 or whatever as their desktop, but applications do not target those environments, they target a lower level of the stack that is shared among these and making an application on XFCE doesn't mean it'll only run under XFCE.
So yeah, it might look fragmented, but unless you are some custom support worker that tries to navigate someone through the UI via phone, that isn't much of an issue in practice (and "in practice" is the important bit here because the reasons i've seen people put forth for having Qt/Java applications ported to Haiku and ignore Haiku's own APIs are all about practicality - which ignores the elephant in the room which is that if you care about practicality using Haiku in the first place wouldn't be a good choice anyway).
When i hear about fragmentation i think about incompatibilities, like -e.g.- the home computer fragmentation of the 80s or the Java ME fragmentation of the 2000s. However there are very few incompatibilities between modern Linux distributions and you can avoid them when you are releasing software.
Haiku already has its own third-party 'native apps' that directly use its APIs and also promotes them in HaikuDepot [0]. Users from other OSes will always ask for other apps and if the OS has a 'modern browser' even when WebPositive is based on the same technology as Safari. i.e, WebKit. But they'll still ask for Firefox and Chrome.
The fragmentation argument can be made from a maintenance point of view. For typical platform support, it's easier to maintain and target one OS that has a single unified stack and SDKs (GUI toolkit, sound, input APIs, etc) than to do this on multiple distros and to only officially support 5 Linux distros, which is why Windows and Mac are always targeted easily. There is no 'standard' SDK on Linux distros, which is why one user could be using ALSA or OSS, X11, XWayland or pure Wayland with Sway, etc. Haiku has first-party default system components which it maintains.
It also sits in middle of macOS and Linux, being that its open-source like Linux and has a standard defaults and a SDK like macOS. So maintenance-wise, maintaining one of each OS like macOS or Windows sounds less expensive than targeting 3 separate distros here.
Second, what you point out about having its own third party apps is correct and i know about what Haiku is - i even did some quick port of my older 3D game engine some years ago [0] for fun.
But none of that answer the question you quoted. What you are writing is from the perspective of a programmer who may want to target Haiku or works on Haiku. My question is from the perspective of a user.
As a programmer i'd target Haiku out of fun since there is no practical reason to target it. As a user i'd also use Haiku for fun since it has too many limitations to have any practical use (except perhaps if all your work can be done via the console and you connect with ssh to some remote Linux server to do your work).
But if you are not using it for any practical use (since for that you'd use Windows or Linux), why bother with anything else than the native APIs for your desktop applications on a desktop focused operating system where applications are meant to integrate with the system itself?
I have to agree with this. Although, if Haiku met a few more of my personal criteria for what I'd like in a Desktop OS I would be willing to sacrifice a good deal of practicality to use it. For some, that threshold may already be met.
To an extent, most of my software is cross platform and most runs better on Windows but the only real app keeping me on MacOS is TextMate. If I couldn't use that anymore I'd probably just switch fully to windows.
Ported apps are great for extremely complicated things but then there are other parts where there is a lot of UX benefit if the soul of the OS shines through them.
However, I have no idea what you mean when you say that Haiku's kernel and filesystem has "several design problems."
Can I write a native GUI program that is guaranteed to work on all Linux distros, just as I can develop native software on Windows and target all Windows users?
This is the open source continuation of BeOS, which was first released in 1995. It's barely younger than Linux, and about the same age as the older distributions like SuSE, RedHat, and Debian.