Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I do not know how familiar you are with Flatpak, what it is and what it is for, and Gobo, what it is and what it is for.

So this is a very broad request and could take tens of pages.

Flatpak installs apps on any distro which has or has had Flatpak support installed on it. It does this by unpacking apps into its own directory trees. Apps go into:

`/var/lib/flatpak/exports/share/applications`

Inside there are more complex trees, so for instance, to reply, I just installed Sublime Text, and it is in:

`/var/lib/flatpak/app/com.sublimetext.three/current/active`

Inside that is a `files` folder. Inside that we see an encapsulated version of a traditional xNix filesystem:

    total 40
    drwxr-xr-x 8 root root 4096 Jan  5 12:30 .
    drwxr-xr-x 4 root root 4096 Jan  5 12:30 ..
    drwxr-xr-x 2 root root 4096 Jan  1  1970 bin
    drwxr-xr-x 4 root root 4096 Jan  5 12:30 extra
    drwxr-xr-x 2 root root 4096 Jan  1  1970 lib
    -rw-r--r-- 2 root root 4817 Jan  5 12:30 manifest.json
    -rw-r--r-- 1 root root    0 Jan  5 12:30 .ref
    drwxr-xr-x 6 root root 4096 Jan  1  1970 share
    drwxr-xr-x 2 root root 4096 Jan  1  1970 sublime_merge
    drwxr-xr-x 2 root root 4096 Jan  1  1970 utils
In here are traditional xNix dirs called `/bin` and `/lib` and so on.

Flatpak is a wrapper around traditional xNix directory layout. It encapsulates them inside a layout it manages, allowing apps to be transported between different distros by having their own layout inside a private tree, but it's a fairly conventional xNix tree.

With me so far?

The conventional xNix layout has globally-shared folders, segregated by functional roles: this subtree is for sysadmin stuff, this subtree is for all users; this subtree is on the main disk and is needed for boot, this one is not essential for boot and is only used in multiuser mode, this subtree is auxiliary additions later, this one is local to this network node only, and so on.

This was needed in the 1970s with very small disks that could not hold the entire OS. `/usr` was originally for home directories but some of the people using the OS were also simulatenously writing the OS. Stuff in their home directory became essential to the system. So it got fossilised into place meaning that a new `/home` tree was added later.

The Mac and Windows conceptual model is different.

It says, each app lives in a separate tree of its own, and we will put only files expected to be shared with other apps into system-global locations.

So the OS itself is in `\OS\` and all the components of the app Bar by Foo Corp get put into `\apps\foo\bar`. Any shared libraries get copied into `\OS\libs\` so that other apps could use them. Later this was found to be a mistake and so `\app\Foo\bar\libs` was added for a known good copy.

Gobo discards the traditional xNix model of global shared folders containing binaries from multiple sources, and segregates them in a Mac and DOS-like model. There is no real `/bin` or `/lib` folders. Instead, there are new trees: Programs, Users, System, Data, Mount etc.

Inside Programs is a tree for each app, and inside that, for each version of that app.

xNix: the files containing the components of each apps are split up and put in the system-global dirs for that type of component. Apps do not have their own dir. Config is in the config tree, libraries are in the libs tree, binaries are in the binaries tree, etc.

Flatpak manages its own version of the global OS layout, one per app, inside the Flatpak tree. Apps are not put into the OS global dirs but each has its own private version of the OS-global tree inside its own dir tree inside the Flatpak tree.

DOS, Windows: the OS lives in its own tree. Each app has its own subtree in the Apps tree and copies only shared components into OS-managed shared folders.

Mac OS X: the OS lives in simplified xNix tree. Apps live entirely in their own private shared tree, one per app, with an OS-mandated layout.

Gobo: the Mac OS X concept is extended to the OS itself. The OS' components are in private, versioned folders inside an OS-mandated tree, with the traditional xNix layout hidden. For legacy apps that expect trad xNix dirs, they are there but populated only with symlinks and the OS hides them from the user.

Flatpak adapts the xNix model and encapsulates private versions of it.

OS X keeps some of the xNix model for the OS only and enforces a new private-dir-tree model upon apps.

Gobo takes the app model of OS X and applies it to the entire OS, and only fakes the trad xNix model to make it easier to port legacy code.



I appreciate the really in depth reply; however, they truly do sound similar if Flatpak was the only package manager installed in the OS. The PopOS! distro is like this and is working on relying more on Flatpak than Apt, for example.


I am aware; I wrote this last month: https://www.theregister.com/2021/12/16/pop_os_2110_new_syste...

I think you're missing the point here.

It's not "apps are packaged with all their dependencies inside a private directory hierarchy". That is true of both, yes. But it is also true of Canonical's Snap format, and 0install, and of AppImage, and of NeXTstep & Mac OS X's .app bundles. In other words, it is far from unique.

The real difference with Gobo is twofold:

• Most of the others preserve significant elements of the traditional xNix directory layout. macOS in the main OS if not inside the bundles; Flatpak and Snap inside the apps; and so on. Gobo gets rid of it everywhere, top to bottom, from kernel to text editor.

• Flatpak, Snap etc. are just app-packaging systems. Even on OSes which use Flatpak exclusively – and PopOS is a poor example here; better ones are Fedora SilverBlue or EndlessOS, with read-only root filesystems, no package manager at all, and OS updates using `ostree` – the directory layout is conventional. Like macOS, the app directory structure is entirely separate from the OS directory structure. In Gobo they are one and the same.

I wrote about that here, and you may find it worth a read: https://www.theregister.com/2021/12/03/nixos_linux_os_design...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: