Packaging formats and their use in Zorin OS

Chat about Zorin
1

I've seen a lot of debate regarding different packaging formats and their use/support in ZorinOS, however lots of it is uninformed repeats of what other people have said. As such, I will try to clear up some common misconceptions regarding the major packaging formats that will be supported in Zorin OS 17: Debian Packages, Flatpaks, and AppImages.

What are the differences, anyways?

Inherently, apt is the default package manager in Debian and Ubuntu, and in extension Zorin OS as well. It handles system packages.

As such, anything you install using apt is installed directly onto the primary system. There is no seperation between users, everything is system-wide, and packages you install can freely modify system settings and configuration.

Additionally, because of the nature of apt, debian packages (.deb) will only work on Linux-based Operating Systems that also use the apt package manager (or the underlying dpkg).[1]

This is where other packaging formats come in

Flatpak is a Linux-Distribution-Agnostic solution to package management. This means that it is completely uncoupled from your system, can have per-user installations and it manages it's own dependencies. Additionally it offers runtime permissions to control what apps can do and sandboxing to make sure the permissions that you set are enforced.

Snap is similarly distribution-agnostic, but it does some things differently on a more technical level. It uses different tech for sandboxing, and isn't as widely supported by Linux Distributions. GUI Options to interact with Snap are also less common[2].

AppImages take a different approach to being Distribution-Agnostic. Instead of being a package manager, it is a way for developers to package their apps into single-file executables. Kind of like Portable-EXE files on Windows. Most of them are made well, but there may be some exceptions where an appimage doesn't contain everything it needs, at which point you may encounter compatibility issues. By default, AppImages will not show up in your Menu. You may want to use Gear Lever to integrate and manage them.

Note that these packaging formats aren't all the same. Flatpak != Snap != Appimages

How does Zorin OS use/incorporate these?

In most cases, by the Software Center's design, Zorin OS encourages the use of Flatpak. This is not because they want to do something malicious, or because they want to force you into using it (there is the source-picker after all) but rather because it is currently the most reliable and fleshed-out experience there is for apps on Linux[3]. Additionally it provides some security benefits over running apps "bare" through apt, snap or AppImages primarily due to it's sandboxing[4].

What about Firefox?

In Zorin OS 17, the developers have replaced the Firefox .deb package with the Flatpak. This is presumably because the Firefox Flatpak is:

  1. Officially Supported by Mozilla
  2. Doesn't interfere with System Packages
  3. Can be updated seperately from the system.
  4. Doesn't rely on snapd

All of the above are important, but they are speculation on the Zorin Developers' reasoning.

Misinformed Downsides and bad takes:

  • "Flatpak takes up more space!"
    At first, this might seem to be true as you're duplicating some dependencies. However, Flatpak can also deduplicate it's own dependencies. In other words, an effort is made to minimize the amount of duplication whilst maximizing the amount of supported software. This comes with the side-effect of offering different versions of runtimes, which cannot be easily deduplicated but are there for using older apps. Note that they're only downloaded when you have apps installed which require them.
  • "Flatpak takes longer to start!"
    This is only partially true, as it doesn't take into account different software and hardware. Start times differ dramatically with different hardware, and where I have had no issues running on relatively slow HDD storage and an okay CPU[5] there have been reports of others running different configurations which suffer from longer start times.

  1. The same goes for other system package-managers, like pacman or dnf ↩︎

  2. this is why Snap mostly caters to developers in the opinion of many. ↩︎

  3. However, there are still some things that need work, primarily by app developers, to make everything work smoothly with Flatpak. If you experience issues with it, try debian packages (apt, .deb files) and see if the issue persists. ↩︎

  4. remember that Sandboxing isn't an end-all to viruses and other malware. ALWAYS be careful with what you run! ↩︎

  5. AMD Athlon X3 460 at 3.2 gHz base, overclocked to 3.415 gHz ↩︎

4 Likes
2

I don't know where you got that from, but I never had to restart the system when firefox needed to update

Restarts with apt are only necessary with system components (like the kernel, a driver update, a security update or anything that is necessary to keep the system running), but normal non-system .deb apps do not require a restart to apply the update. More than once I set firefox to update while using it, and once it was finished, next tab I would try to open/load would say that an update has happened in the background and prompt me to restart the browser, not the system. And after doing so, the browser opens with the new update installed

On newer devices it may be, but on older devices that take a bit long to start some native .deb apps, the difference is pretty big. On my laptop, firefox takes around 10-20 seconds to open as a .deb and around a full minute to open as a flatpak

3 Likes
3

Flatpak's sandbox environment is something most people unfamiliar with Linux don't know about. For a distribution such as ZorinOS, aimed at this particular audience, this has a massive impact. You can take a look at the amount of issues raised in this forum that are caused by this exact reason (packages installed as Flatpak by default). Sometimes this isn't a problem, depending on the package itself, and the specific use case. This hit-or-miss situation is the opposite of reliable.

This is technically true, with a twist. After a while you might end up with packages that require different runtime environments e.g.: Gnome 43, Gnome 44, Gnome 45, etc. that need to be installed and maintained separately. This in turns results in double, triple or even quadrupled the amount of dependencies needed.
What's more, Flatpaks that have an update available but that depend on different runtime version will not be automatically updated: you need to manually uninstall and then re-install to the newer version.

I don't know about the security claim on this sentence and in fact I'd like to know more, but restarting the system after a Firefox update is completely untrue.

EDIT:

In the second screenshot of this post you can see what I mean about quadruplicating dependencies (note the multiple gnome platform versions)

And the huge size difference:

4

I am running Zorin 17 and snap installed itself yesterday evening during an apt update & apt upgrade :face_with_raised_eyebrow:

5

@TGRush,
Thanks for taking the time to write out a great and informative guide. Over-all, it is excellent. There are a few points that need to be addressed, though.
For this reason, I have temporarily moved this to Chat about Zorin so we can hash out these details, which then can be transferred back to Tutorials & Guides with greater confidence.

This is an unknown and we cannot assume the case or the intention.
The same goes for:

The ZorinGroup has long stood by providing the option of choice to the users. No official statements have been made and our current edition of Zorin OS 17 is a Beta. It may be that ZorinGroup has eliminated Snap; but it may not be and until they announce their intentions, we cannot assume that the Beta is fully representative.
For Example: The Beta also does not have all the featured layouts that will be in the Final Release of 17.

I do not think that this statement is accurate nor can it reasonably be. The space Flatpak dependencies can take will vary widely dependent on the users choice of Flatpaks and how many they install... Flatpaks must include even the most basic dependencies, however and by this must take up a noticeable amount of more space than APT packages will.

It is important to note that all packages will devote some space toward dependencies, under any format.

Snap packages are sandboxed:
Security policy and sandboxing | Snapcraft documentation.
Similairly to Flatpak, flags can be set to the containerized application to allow it system access points. Unlike Flatpak, this is not readily accessed by the user (Flatpak has Flatseal).
Both apps are containerized and by this are sandboxed. It is important to note that on GnuLinux, system applications are already contained. So a person can safely say that a containerized app has the same effect as "Double-sandboxing" applications (This is an oft-raised side topic of "Does Zorin OS require anti-virus?").
The effect this can have is important to discuss as users need to know when an application that they install is prohibited from communicating with their system files.
This can cause certain apps to not work as expected or indeed, to not work at all.

Again, the move to a different subforum is temporary and intended to help refine a great Tutorial and Guide.

6

I can confirm that there was some snapd packages (can't remember which) but followed my tutorial where I posted a video on how to remove snap - it is now all gone. When looking to remove Flatpak I would have destroyed Zorin 17 Beta:

image
image1798×1026 142 KB

7

I removed Flatpak from my build of the Zorin OS 17 Beta without any issues or difficulty. I am not sure where you had trouble but we can look at that.

8

ZorinOS Isn't affected (yet?), although many distributions have been moving to Offline Updates, which would (by default, unless you run the CLI) require a reboot to be applied. Additionally, any dependencies that get updated which Firefox also depends on may break unexpectedly as different versions of it are loaded at the same time for different processes.

That is odd. Whilst I have an okay CPU (although, overclocked to make it usable) my storage is quite slow at 5800RPM on a HDD. I figured that if start times didn't differ much on this device, letalone my Core 2 Duo ThinkPad running Zorin Lite on an even slower 3200RPM HDD, that it wouldn't make much on a difference on similarly specced devices. Thanks for offering more points of comparison!

I do agree there needs to be more ways the end-user is informed about this, but it is not something that I would say is inherently bad to have as a default option, especially as Windows is also pushing for Sandboxing all of their apps.

True, as said above, I think more transparency/information on the UX-end on what format a program is running from could assist in clearing this up a little.

I should've clarified that by reliable I meant the packaging format in of itself, apps implemented in Flatpak are a different story. Still thanks for reminding me of this

Although, there is not much you can do about this if you have programs which require different runtimes. With deb packages you have to patch and test applications or drop them from repositories if they require older or newer versions of certain dependencies. We aren't NixOS, after all.

Yes, that may happen if you install something that pulls in Snapd as a dependency, but the base Zorin 17 Beta installation image does not include Snapd.

Flatpak runtimes, especially the base, graphics and GNOME/KDE runtimes take care of deduplication relatively well, and more and more rarely do applications have to include their own dependencies in the Flatpak nowadays. It is not perfect, but it is improving constantly.

Interesting, since when is that the case, if there's a date available for that? The last time I used snapd was quite a while ago, but back then I could not find any options that would allow me to restrict what a Snap can do, letalone GUI options.

You can safely remove all of these as they only provide access to ZorinOS themes and some dependencies interally to Flatpak. They do not affect outside packages (namely, things installed with apt) at all.

1 Like
9

I agree: This is a severe advantage Flatpak has over Snap. Flatpak only includes the needed dependencies and if it already has them, it treats them as present and accounted for just as APT does.
It does require those dependencies that are not duplicated to be present and these dependencies will be installed, whether you already have them installed in the system via APT. This should be known to the users. And, this additional packaging means that Flatpaks will require more space.

I think it is important that we all keep a reality check on this. All package formats must devote space not only to dependencies, but to package growth. In many cases, a user will have many gigabytes of available space. A particular package including an additional 500 megs of data is a tiny percentage of that and not worth fretting over.
We cannot also say that additional dependent packages take up near equivalent space however, when it does not. This can be misleading and it is very important to not mislead.
Many users are also reviving older machines and preventing e-waste and they can have good reason to worry about all available free space and bloat. From spinning HDD speed to less space available to be cavalier about.

I posted the link on the documentation above. As it is, I do not know if or when there were changes to Snaps sandboxing nature, but I can reliably point toward Snap being containerized for the past 2 years at a minimum.
The flags also appear to be geared toward developers, not users (dismay) and I cannot point to any timeframe on those being developed.
To the best of my knowledge, your frustration at having access to restricting or lifting Snap access is as true today as it was when you used it last.

1 Like
10

That would explain why I was so frustrated that I didn't find anything relevant. Thanks for clearing that up!

11

I've updated some things according to the feedback that I've received here. As per usual, you can view the edit history. Note that I'm not done editing and that more changes will be done, until we can come to a conclusion.

2 Likes
12

I think it's unreasonable to expect from users to be educated on the topic of package formats. Installing software it's such a simple and common task that it should be a no-brainer; click, install, carry on... why generate so much unnecessary friction for so little gain? I'd much rather have someone complain about some software they've installed to be "out of date", than have them complain about it not working at all.

Let's not make decisions based on what Windows does, please :smiley:

The overwhelmingly vast majority of users will never be in a position to patch or test packages. I don't think this is a compelling argument in favor of using Flatpak as the default package format.

Precisely, less control for the user that results in more inconveniences.

The bottom line here is that sandboxed package formats have their time and place, they are a great addition to the Linux ecosystem. However, the reality is that native formats are perfectly suitable for the majority of cases. Therefore, let's offer those first whenever there's a choice to be made.

13

Hi Aravisian,

I haven't removed it as I was scared to do so, specially when it referred to Mesa packages in that screenshot! It would have removed all the Accent Colours too?

14

Flatpak packages will include Nvidia and related graphics components due to its inability to access system files.
It is helpful to remember that this restricted access means that these packages are Doubled Up.

1 Like
15

Oh no that's not quite what I meant

I meant that there should be some sort of clearly visible indicator that the packaging format you've installed an app with has a sandbox, and how that sandbox affects how the app runs. Zorin Exec Guard (which is already included) could theoretically be used to deliver such a message.

I meant package maintainers, which have to fit multiple pieces of software requiring different versions of packages into one repository. With apt that is not possible without modifying said packages to either duplicate dependencies or up/downgrade the dependencies they need. Flatpak supports multiple versions of the same runtime out-of-the-box and can thus support multiple apps with different runtime requirements

Well, these solutions do not offer easy per-user installations or permissions, things that people have come to expect, especially from mobile devices.

16

I stand corrected:
From the ZorinGroup:

The Software store has been greatly improved and is now significantly faster and more stable. It also sports a new design with a refined home screen and more information-rich app listing pages. Please note that we no longer include Snapcraft as a default app source for performance and user experience reasons, but you'll still be able to access it by installing snapd (sudo apt install snapd ) and downloading the Snap Store app separately (snap install snap-store ). We're aiming to make this process (to install snapd & the Snap Store) easier with a single app listing in the Software store.

Indeed, yes. The Snapd and Snap Gnome Software Plugin has been removed as a default option by choice of the ZorinGroup. While it will not be included by default, the hope is to include it as a single click and install listing.

3 Likes
17

I don't know about you but most people I know and/or install ZorinOS for don't even know what Ubuntu is. Asking them to understand the concept of sandbox would be pointless. Not because they couldn't possibly understand it, but because they don't care. They see a computer for what it is: a tool to get some work done. The less resistance there is in the way of getting that work done, the better.

This is not to say that warning wouldn't be helpful, but it would be better if people didn't even have to think about it, because they are busy doing whatever it is they're trying to do.

I'm not familiar with the process of maintaining a repository so I can't comment on this. But I can compare what other distributions do and they seem to be able to get by just fine.

But ZorinOS is not a mobile device... and most people these days have one computer per person or share the same machine under the same user account. However if need be this can also be implemented, even if not as straight forward. Then again, I haven't seen many people asking for this so it's clearly a non-issue.

I think I'll call it right here, we have different opinions on the topic, and that's quite all right. I just don't see the need to replace something that isn't broken and that has a proven track record of over 30 years :man_shrugging:

18

Since Zorin OS is a stepping stone from Windows OS to GnuLinux, I generally agree with this. That users need an easier time and a less steep learning curve.

However, this does not mean that a learning curve can be ignored. Human nature is to take the path of least resistance; but human success and happiness stems from tackling challenges and enjoying accomplishments.

To me, this does not mean making an easy push-button OS, but rather, making an OS that gently introduces the belief "I Can Learn."

The users on this forum have responded far more positively to encouragement and regaining control over their machines in the last several years, than to having things done for them. In fact, the "Do it for me" crowd is so few, that they are notable when they actually post.

3 Likes
19

You would be surprised about the expectations people have for their desktop computers. I know that Zorin doesn't run on mobile devices, but I also know what people have come to expect when using computers nowadays. We can either """force""" people into submission, or we can adapt some of the good things those mobile platforms have introduced, like sandboxed runtimes.

On mobile devices and soon Windows too[1], people have had no issues with runtiem permission-systems or sandboxes without ever having to know about them. The reason we need some sort of indicator to begin with is not that the Sandbox is the problem, but rather that on mobile platforms which pioneered this concept the platform is already established, on Linux we are in a transitioning phase where some things will not work or be misconfigured by default[2]

We cannot possibly finish a transition by just sticking to our old solutions, either.

I agree with this sentiment. The OS shouldn't be a 1-to-1 clone of another OS' workflow, and it should introduce improvements where they can be put. If this means there is a learning curve, it should show the user that they can learn about these concepts and learn to use them instead of trying their best to[3] make them disappear into the background[4]

  1. probably ↩︎

  2. Like for example, when the Firefox Flatpak isn't configured to allow any inter-process communication outside of dbus ↩︎

  3. exclusively / only ↩︎

  4. As in, if we make things like this disappear into the background now we would just end up with the Sandbox being useless. We have to let the platform establish itself for developers to properly make use of it. ↩︎

20

Right, so instead of "forcing people into submission" by providing them with perfectly working tools, we should force them into submission by providing them tools that may or may not work as expected.