helloSystem / helloSystem/hello
A thought on System Libraries for Applications
- Dominant language
- No language data
- Stars
- 2.5k
- Forks
- 59
- PR merge metrics
- No merged PRs in 30d
Description
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.
Contributor guide
Assessment
This issue has not been assessed yet.