More BeOS like file system hierarchy in Haiku

Feedback
1

Conversations in other topics about the programs menu accessibility reminded me of an old thing that should be handled (in my opinion) in a Haiku file hierarchy system.

I think that Haiku file system hierarchy has moved too far from the original idea of BeOS. Now, in the “/boot” partition, there are only two directories, this is wasteful of good space! In BeOS from the desktop menu there was quick access to programs and settings, demos and devtools.

Thus, the following folders (apps, preferences, develop and demos) should be moved in the file system hierarchy level higher (that is, into “/boot”). Also those parts of Haiku do not belong strictly to the “system”.

This change would make the Haiku file system hierarchy more consistent, convenient and clear:

/boot
   /apps
   /demos
   /develop
   /preferences
   /system
3 Likes
2

You can use the folders at the root of /boot just like you did in beos, to install non-packaged applications. If we put packaged applications there, it would massively break beos compatibility.

1 Like
3

How it breaks?
And why can’t manually placed files and package virtual links exist in the same folder?

In any case, the user’s convenience should be the priority, not some special implementation of the technology and it’s restrictions.

4

/boot/apps is a normal folder. You can put your apps there if you want. Nothing changed since BeOS here. Packages are installed in a different folder to not get in the way of that.

We have tried this, but it is too slow (the filesystem needs to search in both the packages and in the normal filesystem) and it is also confusing to use (because it’s never clear what happens if you have a file in a package and a file outside a package with the same name). So we decided the current solution is better: it is simpler to understand, and it is also faster.

5

That’s why I don’t like this whole extra virtual package file system thing, I think it complicates things more than it solves. All packages should be installed on a normal file system.

6

Then you can continue to not use it and install your apps by extracting zip files as you did before. Nothing changed there, this is still fully supported.

2 Likes
7

Not gonna happen. You’d have to go back ten, twelve years and throw away everything that has been achieved since then. The packaging system and the file hierarchy that goes with it is a done deal.

8

I believe that is what slowed down the momentum of Haiku’s development. I’m still skeptical that it was worth it. This is no knock on the amazing developers who made it possible. I think it would have been great if Haiku would have stayed much closer to the BeOS way of doing things while shoring up some of its shortcomings, which has been done in various places.

Here is a not-so-fun fact…R1A4 boots much faster than R1B4.

2 Likes
9

Consider the following:

  • Haiku does not have enough native apps to be usable without ports
  • Linux ports bring a little dependency hell with them
  • You need a package manager to keep this dependency hell under control
10

Perhaps, but allow me to put things into perspective: Haiku Beta 4 boots much faster on my ancient Eee PC 701 than Debian 10 does on my refurb Dell Optiplex 780, a machine at least 12 times faster. Do you run Haiku on such an old machine that the performance loss from Alpha 4 made a difference? (Genuine question: some people do.) In compensation, the overlay filesystem has definite advantages when it comes to security and robustness, not to mention familiarity for someone used to a modern operating system with a package manager / app store. And I suspect this system makes things easier and faster for Haiku developers.

11

I’m not a fan of package management in operating systems. So you won’t be able to sell the idea to me. And yes, I’m a longtime GNU/Linux user going all the way back to RedHat 6 saying this. I get some of the positives from it, like getting a bunch of ported libs and non-native apps to Haiku. I just think the trade offs brought some unsuspecting compromises.

12

I was against this too, because it just felt like BeOS-mutated-into-Linux, but this is where things are and that ship has sailed years ago. The chosen system seems to allow for BeOS R5 compatibility, which is pretty much the whole point of Haiku in the first place, AND if it allows for greater ease of ports of non-BeOS-native software to Haiku, I will take the bad with the good.

3 Likes
13

The thousands of apps available in the package manager disagree with that. Shifted focus, yes, maybe. But slowed down, I don’t think so. A lot of the things now available in HaikuDepot would not be possible without a package manager, and a lot of the people who contribute there wouldn’t do so otherwise because they don’t know how to write C++ code.

Again, and this is already the thrird time I say this just in this topic, nothing prevents you to continue using your BeOS apps installed in /boot/apps as you did before. The fact that no one chooses to distribute any applications in this way is not caused by any decisions on Haiku side. We intentionally preserved this option, developers of apps just pretty much unanimously decided to use it.

And if you think I’m blindsided and a supporter of the package management way, one of the applications I develop, the ACE Amstrad CPC Emulator, is available as a zip file and not as a package, because it is designed to have several writable directories next to the executable. That is not a problem at all.

6 Likes
14

So you don’t think that the lapse between the R1A4 release in 2012 to the R1B1 release in 2018(?) wasn’t considered a slowdown in momentum? I strongly feel that the work to implement the package management system played a big role in some of the slowdown. Obviously it was a fundamental change in how the operating system is architected.

15

I probably wouldn‘t have joined Haiku if it haden‘t been for the package management system. It is what got me interested in the first place since so many linux distros struggle massively with this. : )

5 Likes
16

How about the progress SINCE then?

17

And during that period? It’s not like nothing else happened, even if the setup needed for shipping a version of Haiku based on packages took some time, there still were many other things happening at the same time.

3 Likes
18

My comment was in favor of the progress made. Just FYI. From what I can tell, things accelerated.

EDIT: For example, I was shocked to see WINE ported finally. I remember trying to organize that back in the BeOS days and it was just impossible.

1 Like
19

Try that in Linux! Even if you install something in /opt, and I prefer it for certain apps that ship as prebuilt binaries, you still don’t get that simple convenience we used to take for granted in older operating systems. Having choices matters.

2 Likes
20

For example, I was shocked to see WINE ported finally. I remember trying to organize that back in the BeOS days and it was just impossible.

Some Russian guys like @X512 or @3dEyes do a lot of good work. That’s why I got interested in Haiku in the first place: not because of nostalgia (I never used BeOS on real hardware), but because of merit.

3 Likes