Though IMO this misses the point of the OS which is the deep integration and fast UI the native APIs allow that these cross platform applications (and any application ported to Haiku through Qt and Java) ignore. There is no real reason to use Haiku over some Linux desktop (you can even make XFCE look kinda similar to Haiku/BeOS if you want) if the applications you use do not take advantage of it.
As a Haiku developer (and user, naturally!) I have to disagree. Obviously native software would be preferred, just as it is on macOS, but I am pretty sure that macOS users will tell you that they still prefer macOS, even if they are using Firefox, or JetBrains, or Inkscape, etc., yes?
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.
Hey, thanks for your good work! Haiku is like "enjoyable computing" restarted, reminds me of the spirit of the Amiga with the stability of proper modern OS! :)
I never implied that the Haiku developers would dislike these applications, so i'm not sure you being a Haiku developer has anything to do with your disagreement.
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).
Being a developer (and a user as they acknowledge), they have relatively deep experience with the system and the benefits of "native" vs. ported apps. Because of that, they have a reasonable basis of knowledge in order to dispute your statement about the suitability of Haiku for someone using those apps, or the benefits of using those apps on Haiku.
They may have (i don't know) but they didn't dispute anything, they just said that they disagree and the rest was about what macOS users would probably say and something about how Linux is more fragmented and how in theory Haiku is better but neither of those had anything to do with what i wrote.
> 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?
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.
Ok, first of all, if you are targeting Linux you can target ALSA and X11 and your application will work on any desktop Linux environment. OSS hasn't been relevant for decades and unless we're talking about some embedded system, all Wayland desktops also support X11 applications and will continue to support it for the foreseeable future.
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?
> (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)
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.
Your rosy picture of the Linux desktop where software gets along due to standards, etc. does not match up with my (and indeed many others') lived experiences. See my replies elsewhere in this chain about that problem.
I did not present a rosy picture, Linux has its issues, however i wrote that the fragmentation isn't that much of an issue. Your other replies in elsewhere do not really show anything about fragmentation, unless you are confusing having separate projects for different layers of the operating system with fragmentation.
Then you'd need to explicitly mention your definition of "fragmentation" because i think mine's differ.
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.
Don’t you think this depends on the exact process followed? Different countries built the ISS after all. So long as you plan and standardize properly, and write to the spec, you can develop east subsystem independently and still integrate it as a single, cohesive system.
WoW thank you very much for working on that OS, as a Desktop OS it's blazing fast!
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.
> but I am pretty sure that macOS users will tell you that they still prefer macOS, even if they are using Firefox, or JetBrains, or Inkscape, etc., yes?
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.
As a long time BeOS (and Haiku) developer, I agree that the design is significantly cleaner. Your argument however is significantly false. Haiku has several design problems in the Kernel and the Filesystem, any serious use other than hobbyist is quite limited. Definitely Linux could have a better Desktop, but saying that the Haiku design is less fundamentally fragile is a complete lie. Linux desktop may be more conservative, and may not really adhere to a truly common standard, but they offer several orders of magnitude more what Haiku could hope to have by far. This includes Security, IPC capabilities, Virtualization, Containerization. Android is an example of a Linux platform, that still retains an high number of native apps, coherence of UI etc.
Linux has a lot more features than Haiku, for sure, but a lot of these are oriented towards servers, which we probably will never implement because we are not targeting servers. Obviously there are others which we will eventually implement, sooner or later (like virtualization).
However, I have no idea what you mean when you say that Haiku's kernel and filesystem has "several design problems."
Is there any good intro on how to get developing under Haiku? I seem to remember there being a wxWidgets port years ago but the documentation regarding it is scant. I would like to know which development environment I could use (Qt Creator perhaps?) and get to writing some apps on it as I really enjoyed using Haiku and BeOS for fun.
Do you have any tips or pointers? Thanks in advance
Haiku has it own set of API's, that is a bit different than other platforms (message passing, multi-threaded). The UI API's is defined in the Interface Kit. See https://www.haiku-os.org/docs/api/
There is wxQt running on top of the Qt5 port, yes, but it isn't that well used. I know someone got Code::Blocks running under it, but they were working on some issues in the wx port still. Development should be like it is under Linux with that.
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 :)
The really interesting thing would be to have a wx port using the native API for it, but unfortunately the last time I heard about wxBe was in the last century...
That's not what I mean by "fragmentation"; I mean that the Linux desktop is a collection of different software projects (GRUB, the kernel, X11, ALSA, systemd, GNOME, ...) which are combined to form the operating system proper. Ubuntu is just as fragmented as any other distribution here.
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.
It's interesting that you don't mention the absolutely unusable browser that the project is continuing to develop, instead of using a modern mature browser like Chromium.
WebPositive in based on modern WebKit (specifically a snapshot from a few months ago), which is the same engine that powers Safari. Is that not a "modern, mature browser"? The bugs in Web+ are mostly in our WebKit port, which is continuing to improve.
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.
> 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).
Please have a closer look at those patches. 98% of it is constituted of C preprocessor ifdefs. This means that most of them just enable the same features as Linux alongside other operating systems. Most of it is purely code configuration. Haiku instead reimplement many parts of WebKit, instead of relying on mature code. This is the reason why the WebKit performance on Haiku is so poor.
You do realize that WebKit has no native graphics API, right? It uses Cairo under GTK, CoreGraphics under macOS, etc. etc. So we created a Be API implementation, and yes, it needs more optimization. But you are acting like we are reinventing the wheel here or something...
Web+ is integrated with the Haiku Network Kit and other things, accomplishing nothing for the end user. Most of the performance issues comes from there.
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.
Okay. And the same is true of macOS; they use LibreSSL. We also use libpng, libgif, libjpeg, etc. and of course WebKit for the web browser. Nobody is claiming that this is a 100%-from-scratch-no-reuse-allowed project. What's your point?
My main development VM for Haiku has no Qt software, or even the Qt libraries, installed. I'm using native apps for code editing, debugging, error messages, etc. So that's not quite true.
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?
Uh, both of my main machines have bare-metal installs and I do develop from them. But when you are doing kernel development, it's much easier to "unbrick" a VM than bare metal, yes?
See my reply to reddotX below for the "theory"; in practice, this winds up causing all kinds of breakage when e.g. you are using a "non-default" configuration, and then upgrading fails to change some critical line in a configuration file, and now you have no audio out and must spend multiple hours Googling to even find an error message and install a missing package and start a daemon manually (true story, happened to me on Kubuntu some years ago.)
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.
Haiku lacks a lot of features the Linux kernel has, but the overall system architecture and design is significantly cleaner and less fundamentally fragile.
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.
I don’t think anyone is suggesting Haiku to compete against windows or macOS. It seems to be more of a hobby play than anything else. The real company failed trying to commercialize this — why would a design from the 90s be commercially viable now when the main selling features are standard, and all the innovation is on phones anyway?
And how can one even make money selling an OS these days? They may have a small marketshare from techies wanting it for fun but turning this into an actual business I would think would be very difficult these days.
I actually much prefer the usability of the haiku desktop environment, especially how it handles keyboard input compared to X11. It feels really well thought-out and polished.
Then why work for 18 years to make make a fully fledged OS if in the end the expectation is that it does nothing? For an OS practicality is pretty much always a concern, if not necessarily the top one. Otherwise it's relegated to literal "toy" status. An OS without any practical apps might as well be a GUI made in Flash. Looks nice, does nothing.
If I was developing software on Linux, which distro should I choose?
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?
Yes, but there is less stuff you can assume to already exist on a Linux desktop environment than on a Windows one, so you either need to bundle those with your application or have them as requirements.
I am waiting for the next big thing, where the 3rdparty programs comes as a virtual machine image with a complete OS in it, with own kernel for maximal platform-independency.
Isn’t this kind what java is already? And also if there is another OS running in this VM, this would lead to less efficient executables as you’d have to partition resources
like mem
