The problem with the way packaging and distribution has been done in the past
In case one has not noticed, a lot of changes have been happening with regard to how software is packaged and delivered to the end of the chain, i.e. a particular distribution's users.
In the past, software was released by developers as source code, whereby packagers would package the source code into various formats that were the standard for a particular distribution. While being pretty straightforward, it introduced a lot of burden especially for packagers who had to constantly stay up with current releases, as well as current versions of the operating system they are providing packages for.
This system inevitably leads to delays for users who expect the most current software versions available in order to get the latest and greatest features and bug fixes.
Other problems arise from the fact that developers develop on a particular operating system on a particular set of hardware. This reality is often less than ideal for distributing software across a multitude of variables with regard to the respective software and hardware nuances in the wild.
Along came containerized ideas whereby software can be delivered in a universal package format, including all the dependencies required to ensure that it would run on a particular user's machine. The applications could be released once and distributed across any Linux distribution out there.
Enter Snaps
Over on his personal blog, KDE Neon dev Jonathan Riddell discusses Snap packages within KDE and some of the benefits of delivering software to users in this manner. he states the following regarding traditional Linux software deployment:
"No other computer environment works like this and it goes against the fashion of DevOps concepts where the people who code are empowered to deploy to the end user going through QA as appropriate. We changed that with KDE neon where we brought the packaging into KDE making .deb packages. That integration allows for blockages and imperfections which get identified to be solved easily through the most efficient channels."
"With new containerised formats Linux is changing, and projects like KDE can now package software and send it direct to the user."
Jonathan dives into the concept of stores, channels and, ultimately, control. And what it all means to the user. The process appears to be fairly automated just the same as packages are built for a traditional .deb and RPM packages for different distributions.
One interesting point he makes is that Snaps should be built not from within the KDE Neon team, but as part of the greater and global KDE CI build system.
What this means to you
Ultimately, Linux is moving in new directions with regard to software deployment. Much to some people's chagrin, containerized formats appear to be the future of software distribution to users.
In fact, there are already distributions out there that only distribute software via containers. One such example is Nitrux, whereby all applications are delivered to users via AppImages. I'll be discussing Nitrux more here in the near future, so stay tuned.
 |
| Nitrux - The first all-containerized KDE distribution |
In the end, a user won't care where an application comes from as long as it is from the official app store of the particular distribution at hand. Weather Snap, Flatpak, AppImage, or repository package, the user just wants the latest and greatest stable release of their software to use.
And we cannot blame them for that.
Much more information is available on Jonathan's Blog.
No comments:
Post a Comment