A thought on System Libraries for Applications

[Lestibournes]

As was mentioned by the creator and Bryan Lunduke, there is a problem with how system libraries are implemented on Linux, and that got me thinking on how HelloSystem could do things differently and fix this problem for itself. The main gist is to imitate how installing Applications works, only to do it for system libraries.

• Define a set of shared libraries as being the HelloSystem platform.
• Place all these libraries in a single folder, with each major release having a different folder name. For example: HelloSystem-1, HelloSystem-2, etc.
• Install each major version of the platform simply by moving this folder to standard location, let's say /Libraries, so you get: /Libraries/HelloSystem-1, /Libraries/HelloSystem-2, etc.
• Updates to a platform are applied by taking an up to date copy and moving it to /Libraries, overriding all existing files: mv -r -f HelloSystem-1 /Libraries/HelloSystem-1 (or something like that)
• Applications then link against the shared libraries of a specific version of the platform. Any dependencies that are outside of that platform are to be bundled with the application.
• Release new major versions on a regular but infrequent schedule, say on every year that ends in either a 0 or a 5 (so 2025, 2030, 2035, etc)
• Support major versions with bugfix and security updates and port them to newer versions of the system components (such as kernel, display server, sound server, or whatever) for a long period of time, say 10 years. That would mean up to 3 major versions being supported concurrently.
• Major versions will receive no feature updates and will maintain ABI stability throughout their lifetime. If an application developer wants new features then he will have to use a new major version, or a "developer preview" of the upcoming major version.
• Depending on how this is implemented you could let users choose which platform to run an app with, so that even if an app isn't built to run properly with the HelloSystem libraries it could still be made to run, like when using chroot to make it think it's on a "normal" system while running with a specific version of the libraries, chosen by the user.
• You could have other platforms on the system, such as DE-specific platform, or platforms that are basically another OS's libraries ported to run on HelloSystem. So for example with this system someone could create an Ubuntu-20.04 platform that would let users choose to run Linux applications as if they are on Ubuntu 20.04.

Advantages:

• Offers a single, well-defined, stable, long-term target for applications developers.
• Multiple versions of the libraries installed and used in parallel.
• Simple, easy installation, removal, and updates through the file manager and nothing else.
• Can be shared with other OSs, which could cause HelloSystem to become a preferred target platform, especially if its platforms are ported to work on top of more popular systems.
• Makes it easy to maintain backwards compatibility, especially if the components that the libraries are built on maintain ABI backwards compatibility, so an app written 10 years ago (or even more) will work exactly the same today, with no hassle.
• Can be used to make applications for other OSs work through a compatibility layer. For example, a Linux compatibility layer, or a Wine-based Windows compatibility layer.

Anyway, that's the general idea for my suggestion on this issue.

[probonopd]

You describe the problem well. However the answer should also be manageable by us without recreating most of FreeBSD. What I was thinking of is using one file per operating system version which gets loop-mounted and run, similar to the Live ISO. Wdyt?

[Lestibournes]

If I understand correctly then that would be a quick and easy way to achieve this. I don't really care if it's a folder or an image, since it should be treated as a discreet immutable unit anyway.

I would say that it shouldn't be one file per OS version, unless you plan to release new OS versions very infrequently. Choose one OS version which will then be used for the next several releases of the OS. Otherwise you will have many versions to support concurrently and create a dilemma for the applications developers as to what they should target and a headache for users who will keep having to add more and more platforms to their device.

[probonopd]

If I understand correctly then that would be a quick and easy way to achieve this. I don't really care if it's a folder or an image, since it should be treated as a discreet immutable unit anyway.

Imagine you'd have

• helloSystem-$VERSION.iso
• ubuntu-$VERSION.iso
• ...

At boot, helloSystem-$VERSION.iso would be used; you could have multiple versions available in parallel. When running a Linux application, Linuxulator would use ubuntu-$VERSION.iso; you could have multiple versions available in parallel. And so on. Software could define which ISOs they need to run.

Ideally, the ISOs would follow semantic versioning, and applications written for a major version of the ISO would also run on subsequent minor versions of the same major version of the ISO. In a truly ideal scenario, we could also give a guarantee that an application keeps running on at least, e.g., major+2 versions (because every major version would ship with compatibilty packages for the last 2 packages). [Unfortunately real-world Linux distributions don't seem to really make any formal guarantees of this type and don't even follow semantic versioning.]

At this point, this is just a thought experiment; I imagine it could be implemented on top of what already exists with less work and overhead than redesigning things entirely from scrach. I am open to other solutions, as long as they don't require us to re-engineer the whole way existing FreeBSD and Linux distributions are put together (this needs to stay manageable by a very small team).

Choose one OS version which will then be used for the next several releases of the OS. Otherwise you will have many versions to support concurrently and create a dilemma for the applications developers as to what they should target and a headache for users who will keep having to add more and more platforms to their device.

Agree. What you are describing sounds like Flatpak, where there are so many different runtimes that unless you only keep the very latest versions of everything, it quickly becomes a large collection of different versions of runtimes.