Gathering infos about Haiku way

Software
1

I thought that there are many things in Haiku who are different from Windows and GNU/Linux, so even experienced users have a hard time to get used to Haiku.

I thought about listing them here and perhaps I even manage to turn them in a documentation webpage someday.

[Edit: Maybe call it “Intro to Haiku for experienced computer users”? Other title suggestions?]

Ok, I start:

  • You can reverse a kernel update if it doesn’t work.
  • Installing the system copies ALL files, even private ones.
  • The native API is C++ (but you can program a lot of things with other programming languages.)
  • The applications’ names sometimes don’t give a hint of what they are good for. One solution would be searching for a keyword in HaikuDepot.
  • All files and directories are in one file hierarchy but it differs from the Linux and Windows hierarchy.
  • Booting on (U)EFI needs some manual work. This will change I’m sure. (Maybe I can fix that but I’m a slow coder.)
  • BFS has some special features. (Which?)
  • Building from source code requires a special variant of jam (which is there readily in Haiku but has to be installed if cross-compiling from a different system )
  • Installing both the core system and applications is quite simple.
  • You don’t need the X window system if you program something with a GUI (but you can use an emulation layer named xlibe for existing X programs).
  • the GUI (like the whole system) is not distributed over many concurring solutions (in contrast to Linux with its many WMs, DEs etc.)

Edit: Maybe I wasn’t clear enough, so: Feel free to add stuff.

4 Likes
2

First thing that a new user will encounter in Haiku (assuming they no prior knowledge or experience with BeOS or ZetaOS) is the ALT key with CRTL key switch-a-roo!

3

There is also Qt, KDE, java, pascal … :slight_smile:
EDIT there are also the available build tools like the autotools, cmake, meson, python, rust … (probably missing a dozen here)
Third party installers like pip, npm …

4

Most Linux distributions do this for the kernel as well

Just like Qt or Windows MFC.

Queries, extended attributes which are typed and not limited in size

But also it has some missing features, like hardlinks.

Building Linux also requires a specific version of make (GNU make, other variants won’t work) and a specific compiler (gcc). I can’t imagine what building Windows looks like. I don’t think this is anything special to Haiku?

Isn’t there a contradiction here?

We have GTK, Qt, and a few more now. So, not much better than Linux on that regard…

On Linux you can choose one environment but then 90% of your apps will use the same toolkit. And occasionally you will have to use apps meant for a different environment because there is no “native” one available. Haiku is in a similar situation now.

I think you can find some ideas about what makes Haiku special in the FAQ: General FAQ | Haiku Project

1 Like
5

I suppose you have a point here. Whilst the majority of Haiku’s applications are written using the Haiku UI toolkit and they work perfectly and look consistent, my bugbear is the GTK-ported applications just do not look right inside Haiku. Web, for example, has toolbars and tabs that are far too big.

1 Like
6

Is it the only issue? :stuck_out_tongue_winking_eye:
GTK apps don’t get along with the way Haiku passes args on the command line, they use an odd way to communicate with a running instance, they don’t respect system colours, BView hierarchy, system key maps (well these maybe limitations of Wayland)…
Need more?

2 Likes
7

I’m a UI developer - that’s the first thing I see!!!

8

So… like Haiku? we don’t pass args on the commandline… and instead send them to the running instance

9

I was not clear, They don’t accept either B_ARGS_RECEIVED or B_REFS_RECEIVED messages. They forward argv to the running instance via a socket but this never worked for me. At least with Gimp and Claws Mail.

1 Like
10

Well, I would really curious … how do you mean this ?

Lately I got huge problem with it on Haiku 32bit with permanent solution.

I had FS related problems when I installed hrevxxx +93 and wanted to go back permanently to hrevxxx +91.
I could boot back into previous state with hrevxxx + 91, but I wanted to avoid playing with selection everytime I boot.

Unfortunately there is no permanent revert back.
So this wayI wanted to replace all related *93*.hpkg files to *91*.hpkg files using the statement directory.

Well, copy back and removing files went “smoothly”, if I do not count that Haiku always wanted to remove dependencies as weell – I simply ignored closing the appearing windows.

So I thought I was successful, so I did a reboot … when I got a smash hit in my face.
The installed Haiku could not booted. The most of hpkg files were missing. There was a Haiku live image as well in the first partition - that was also full empty related packages … even the full home directory was missing there. It was also a spare for me to keep favorite settings. Fortunately the settings I had in install partiton that remained with home directory.
After some big sucks I could got to install a 64bit Haiku finally instead of Haiku 32bit - I intended it for a spare drive to have a clean installer that fast and there is 14 GB instead of 1.4 GB live system.
I bult this instead of live image to have a smaller test instance of Haiku on the same thumb drive as where the main install - that there would be a bigger space about 100 GB as it is a 128 GB USB 3.0 thumbdrive.
The newer problems starts here. I could not

cloned the installed Haiku 64bit using dd command with help of DVD Haiku live … because some USB errors.
Sometimes could not read the input file (so the source drive) but with checkfs the affected BFS was healthy.
Sometimes I was reading timeouts in syslog about usb disk.

→ not even install it to the 128 GB pendrive from the 32bit pendrive - I can prepare the partitions , filesystems successfully, could copy all files onto ‘haiku esp’ from installer’s ‘haiku esp’ partition … but when I start installing finally
the copying files interrupts … ALWAYS … at one of the files.
I got
Bad file descriptor just as from DVD installer media
and
General fault
error messages.

Sometimes I checked both BFS filesystem before, but install interrupts ALWAYS.

And before someone suggest to download 64bit iso again - I did it.
I made an USB installer media first onto 128 GB pendrive using dd command from that ISO file.
From that cloned installer I installed the 64bit Haiku install onto another 32 GB pendrive.
I wanted to keep this pendrive to have a spare, healthy install drive that would remain on R1B4 as its first released and a source of cloning it - again, instead of installation I had many problems with it earlier. (Some failures needed learnig curves due to EFI, for example, but EFI was not about installation but booting after that.)
Cloning failed (more times, several attempts I made),
install back to 128 GB test partition and main partition always failed.
This way I started to use this primarily spare drive purpose install – after I became badly mad furious …
It does not fit to that way I want to live right now, so honestly came up into my mind … I would freeze Haiku and experiences with it a little bit.

Iinstalled Haiku R1B4 64bit from one USB pendrive to another USB pendrive happened
only once successfully
Every other attempts failed as just before - I used available ports in multiple combinations, I checked filesystem health, dongle insertion … I had not give up, I checked syslog messages.
It is just copying files from one USB drive - both filesystem is BFS … and fails … ununderstable
I was terribly mad (that’s when you shout and would use and axe too :stuck_out_tongue: )

It should work , but it just does not work – that way it expected to do … even for “an experienced computer user”.

11

sure there is… just install the packages from the previous state
That is, tell pkgman to install the package from the previous state, by pointing at it
pkgman install /path/to/previous/hpkg

12

Thanks @nephele ,

Next time I will try out this tip. :j

13

Don’t forget to deactivate Haiku repo after that. Otherwise when you will run SoftwareUpdater, it will propose the update of Haiku packages and since you can’t chose…

14

Exactly, I think we need to emphasize here that Haiku does have a wonderfully designed, consistent native API and UI toolkit based on the principles of loose coupling, asynchronous multi-threading and messaging with a slick and responsive look&feel.

This should be the preferred way for writing Haiku apps, as it uses the full potential of Haiku and its unique features.

Everything else should be used for enabling ports, writing simple apps and quick solutions, command line apps, prototypes, or for integration of external services (i.e. using an official Python library to access some web API etc.).

That’s at least my take on this as it would avoid Haiku becoming more and more mix and match, loosing its streamlined uniform appeal.
We should take a page from Apple here, as they care a lot about this and they managed to keep MacOS distinctive and clean, usable and pretty this way.

1 Like