UPM - The Future of the Project
In our previous article on why we will not support Snaps, we mentioned UPM, which will use Snap as one of many parts of the system. I wanted to elaborate on why we will support UPM, and what we will do with it in the future.
First is our reason why we are supporting and building the technology. We believe there is an issue in Linux, and it can partially apply to FreeBSD. Packages are separated and split. You have stability, or you have rolling, but it seems like you never get both. To get both, you either run rolling and install stable from source, or you run stable and run scripts to build new editions of your software from source as new versions/commits/whatever are pushed into the public. We want UPM to give you stability and cutting edge by the addition of a single argument of a command. If you have one distribution, you can run UPM on another. We want packaging to be simple, easy enough for everyone to run with the software as they so please, at the stability they so choose. It is a simple request that we are filling ourselves, cross-platform packages that just fucking work. No need for Systemd to install one package from one of 8,000 false solutions like Snap and Flatpak. While we understand Snap and Flatpak fill a market, we need a package management system that works everywhere without a stupid dependency to install the installer. Even we want to do our best to build our project in a way that doesn't depend on one thing or another to run it, because we feel like dependencies for a package manager binary are stupid. For source building the package manager? Sure, dependencies will exist, but we don't want to force users into Systemd to run software. If you wanna run the same app on Arch, Ubuntu, Alpine, and FreeBSD? You should be able to run the same app on Arch, Ubuntu, Alpine, and FreeBSD. The idea of UPM is simply "it should just work."
What we will be adding to UPM. Other than it being able to build, we will be making configuration files. These configuration files will be in the home directory as a dot file called ".upmc" and it will be the system on deciding how everything is to run. It will have inputs for system shell, system package management, external package management systems (like Flatpak and Snap), extra sources, alternate installers (like rpm, dpkg, etc), and AppImage installation. That is large of an order, we will not deny, but we hope this starts to slow down the issues of Linux software. Linux is splitting more and more, and while we believe that Linux is one tool of many to run an OS, and should not be a defining factor in an operating system's requirement to exist, UPM isn't built JUST for Linux. Early on in the existence of UPM, I wanted to add support for many systems, as UPM isn't supposed to join together Linux, it is supposed to join computer users. No matter what OS, we want UPM to support it (as long as 5 or more people use the system). The bare minimum we want to support is all Linux systems, MacOS, Windows, the BSD family, the Solaris family, Minix, HaikuOS, and anything we can get working.
UPM is going to take a lot of time to build, and there is a lot we need to do with it. But we really want to do this right, so let's explain the technology we will use and why. First, the V programming language. I originally wanted to use Common Lisp or C++, but the issue with those two languages is external libraries, while Common Lisp has good libraries internally, the need for internal libraries is the downside for us. The V programming language has amazing internal libraries that do more than enough. Not only that, V manages its own external packages, meaning if we REALLY needed external libraries we had an easy system to grab the libraries without much issue. I currently only see need for the OS library and the net library to build the system. The last great things with V we get tons of safety in the language, we also have stability, a great community to work with, internal libraries that do most of the work for us, and best of all, syntax any contributor can read and recognize how it works (for the most part).