Once every few years I give Haiku a go to see if its any closer to letting me switch to using it as my main desktop OS. I primarily run Ubuntu but I also use Arch a bit too (there, I said it).
Why do I want to switch to Haiku? I’m a big fan of lightweight software and I love that I can install Haiku off a dirt cheap USB2 thumb drive in 40 seconds and that even without accelerated graphics it is still more responsive than Linux running a lightweight desktop such as MATE or XFCE. The desktops thing is another advantage Haiku has over Linux in that there is no official, standardised desktop for Linux and there never will be. I prefer the Haiku desktop to GNOME and KDE although it is missing a few important features that those desktops support like HiDPI and multi monitor support.
So what needs to be fixed or added to Haiku before I could switch from Linux?
Hardware video decoding. I’m not a gamer so I can live without 3D accel but I want to be able to watch 4K videos smoothly in a Haiku browser and playing video files with mpv. I’m delighted to see X512’s progress on a Radeon driver which will hopefully mean we’ll get Vulkan hardware accelerated video decoding.
Qt printing support. Haiku has a Libreoffice port but its not much use because there is no printing support for LO or any other Qt app and its also very unstable. I’ve not been able to open a file with it.
Hardware virtualisation support. I use VMs a lot so I’d really need hardware virtualisation support. It’d be great to see VirtualBox get ported to Haiku when this gets implemented.
RNDIS / USB tethering support. If I was going to run Haiku on my laptop then I’d really want USB tethering support for mobile internet access.
That’s pretty much it for my wishlist so it doesn’t seem that Haiku is too far off becoming a viable alternative to Linux for me because most of the Linux apps I use have already been ported to Haiku.
BENCHMARKS
I thought I’d do a few benchmarks to compare a recent Haiku nightly to Ubuntu 21.10. All of these benchmarks were took running Haiku and Ubuntu ‘bare metal’ on a rather old Gigabyte N3150-D3V with a Celeron 1.6 GHz quad-core processor, 8 GB RAM and running off the same Crucial BX500 SATA 3 SSD. SMP was enabled for all tests and Ubuntu was running Linux kernel 5.13.0. The 64 bit versions of each OS were installed to the same SSD.
In most tests Linux is about twice as fast as Haiku. Of course I’m very much aware that Linux has thousands of developers and lots of resources provided by its mega corp backers such as Intel, IBM and Google etc whilst Haiku has a maybe a couple of dozen developers so its not a fair comparison but…
HiDPI is already available,but it’s probably not where someone coming from Linux would search for it.
You only need to increase the font size,then the rest of the UI will scale depending on the font size.
Also there’s a very new feature for thumbnails in tracker,I think it’s only in nightly and only for pictures right now,but maybe it can be easily extended to videos.
The feature that you want for Deskbar is very useful btw.
I use my deskbar in a Windows-Taskbar-like form factor and it consumes too much time that I have to go through the dropdown everytime to switch windows.
Under Preferences → Appearance → Fonts there are 4 font settings. If I increase them all it doesn’t affect the size of the fonts used in menu bars, in the file lists in tracker nor for the labels of icons on the desktop. Is there another setting I’m missing? I can’t see any options to adjust the font size in the Tracker preferences.
I just tried it on my own computer.
If I change all four settings,it immediately takes effect only on a few places.
After a reboot,everything has the correct size,also the menu bars,desktop icon labels and tracker.
Tracker has no own font settings,it uses the size you set in the system settings (but only after a reboot).
Ah yes! I didn’t reboot and now that I have all of the fonts are bigger. It would be good if the reboot wasn’t necessary to have all of the fonts adjust themselves.
I agree that it would be better,but likely most applications only read the font settings once at startup and then keep then in memory.
I don’t know how hard it would be to fix it.
For the xz tests the latest Haiku nightlies performed better than beta3. It compressed the iso about a minute or two faster, using the same version of xz. I can’t comment for the other tests but I expect that using a non-debug build won’t make that much of a difference and if the xz tests are anything to go off they may also be slower.
The Amiga only had a few models and peripherals / add-in boards. They didn’t have to support the wide array of hardware that Haiku and Linux attempt to support.
I am booting off a SATA 3 SSD with BeFS and I must admit that I expected Haiku to boot faster. I’ve looked at the verbose boot logs but I can see any obvious delays or errors that might be slowing my boot time down.
Ideally all fonts should be updated when the size is changed, but rather than a reboot the Team Monitor can be used to “Restart the desktop” which will restart Tracker and Deskbar which will then use the updated fonts. Other apps can also be restarted to get the new font size.
This is still a bit annoying but less annoying than a reboot.
restart tracker and deskbar, aswell as any apps you want the new font to use. a reboot is not neccesary
for a bit of technical background: the application gets the inital sets of fonts from the app_server on startup and keeps this. We could, if we want to, broadcast the font change to all running apps and apply it directly.
We already do just this with colors everywhere and with locale in FirstBootPrompt.
The only real problem I could see is when a gui control is used to change the font or font size which may cause a relayouting to occur might interfere with this, as in the ui ubder the cursor jumps around or something (a slider may get bigger and then change its value when still held, thus junping around.)
This can probably be easily worked around by ignoring font changes for the layout of an application that changes fonts at runtime though.
I have updated the top post to include links to the relevant bug reports or package/feature request tickets.
I forgot to mention that another non-technical advantage that Haiku has over Ubuntu, FreeBSD and most other open source OSes I’ve tried is it developers have usually responded to my bug reports within 24 hours or so. This is definitely to be commended as it is not the norm in this space.
Regarding benchmarks with file system write operations, Haiku is doing more than other OS’s simply due to updating its attribute databases, so a compression/decompression test will always involve more work under Haiku. On the flip side, you’ll never see a benchmark that measures how long it takes to search/find a set of files. A benchmark like this and Haiku will win.
I’d bet it doesn’t have to do as much as Linux or FreeBSD when using ZFS but I opted for XFS in these tests to show Linux’s best case (well, better case. I just used the default mount options and I very likely could’ve tweaked those) scenario for Linux disk performance.
It’s been my experience that the boot performance is essentially the same with a SATA HDD; possibly slightly slower than with a SSD, but still much faster than most other OSes out there.
Compression usually involves creating just one file, and probably without any specific attributes. So there should not be this much work on the attribute index.
This benchmark just shows that Haiku is currently slower than Linux. There is proably not a single reason for that, we would need to investigate the thing a lot closer (using perf on Linux and DebugAnalyzer on Haiku, I guess) to identify why we are so much slower, and do the needed improvements and optimizations.
Thnak you for doing this, but IMHO you are not being fair to Ubuntu if you measure it in leightweight category…you should compare Haiku with Lubuntu - no?
I suppose I compared it to Ubuntu MATE because that is my favourite flavour / Linux desktop although it will have made little to no difference in these benchmarks except for the boot time when I would expect Ubuntu would’ve took even longer to boot if I was running KDE Plasma.
