Packaging formats and their use in Zorin OS

[anon2532484]

I don't think you quite get what I wanted to say, so let me paraphrase.

Instead of just endlessly sticking to the exact same way of doing things for years on end, and just making anyone which picks up the OS use it that way and only that way, we should be able to adapt to not only the time, but also to the user in front of the screen.

By offering and encouraging tools out-of-the-box that give more control^[1] over the software they run to users we not only fill an expectation that many users especially of the coming generation have, but also give the user the ability to decide how their software runs. This isn't only about the packaging format, or whether maintains are willing to step up to make their software work, this is about a larger paradigm-shift in the Linux Desktop landscape.

→ Developers want something that they can target, that is consistent across distributions, and which gives them control over how they ship their apps to users.
→ Users want something that works everywhere no matter which Linux OS they install, that they have control over, and that isn't tied to the system^[2].

Flatpak and related tech accomplishes basically all of the above, and it provides extra APIs that developers should make use of, like Portals^[3], to ensure they're handling their user's data with care.

---

1. permissions, sandboxing ↩︎

2. in the sense of offline updates, for instance ↩︎

3. important for ensuring an app doesn't have access to all of a users' files or system settings ↩︎

[zenzen]

@anon2532484

and just making anyone which picks up the OS use it that way and only that way

You keep framing this as if people are actually being told how to use their computers, but at the same time you're pushing for a change that has already proven to be faulty from a user experience standpoint, and calling it progress. You're playing both the victim and the offending sides.

I fully understand what you're saying, I'm just disagreeing. What you are proposing is changing something that you think is better, despite the fact that empiric evidence exist to the contrary.

@anon2532484

By offering and encouraging tools out-of-the-box that give more control[1] over the software they run to users we not only fill an expectation that many users especially of the coming generation have, but also give the user the ability to decide how their software runs.

If by out of the box you mean that they are readily available if the user so wishes to use them, then I agree. Just don't make it the default, because whether we like it or not there are shortcomings to those tools.

[anon2532484]

@zenzen

You keep framing this as if people are actually being told how to use their computers, but at the same time you're pushing for a change that has already proven to be faulty from a user experience standpoint, and calling it progress. You're playing both the victim and the offending sides.

That's a fair point, I often loose sight of what I'm trying to say and as such become more opinionated than I intend to be. Sorry on that part.

@zenzen

Just don't make it the default, because whether we like it or not there are shortcomings to those tools.

Couldn't I say the same about apt and other system package managers, though?

The tech that Flatpak brings forward is (what I believe to be) the better fit for user applications as it doesn't require any modification to system packages and offers (in most cases) better security and control due to the sandbox. One real-life example where this has caused major trouble was LinusTechTips just trying to install Steam and consequently bricking his system due to a dependency error. Something like this just cannot happen if your package manager is seperate from the system

I also believe the issues that often arise are not purely because the sandbox exists - if that were the case we would see the same issues on other platforms with similar measures - but rather that primarily because the platform is developing so fast, many developers have not held their software up-to-date with support for the tech that we now use, or are lagging behind. Good example would be the Discord Flatpak: Until recently^[1], the maintainers have done the best they could do maintain it from "the outside"^[2] but there were some things that they simply couldn't fix, like Discord's outdated version of Electron causing it to not support file pickers or screen sharing on some setups.

I believe that a higher adoption of Flatpak means that more developers will shift focus to it, which will in turn increase the quality of maintained flatpak applications. We saw that with Chromium, which adopted support for portal-filepickers instead of requiring filesystem access or PipeWire for screensharing, so that it works on any setup.

---

1. The Flatpak is now officially maintained by Discord, and as such they are no longer involved in community-maintaining it ↩︎

2. as in, the Flatpak but not the contained software ↩︎

[zenzen]

@anon2532484

Couldn't I say the same about apt and other system package managers, though?

You could, and with great validity, but that doesn't justify changing it for the first tool that comes around full of promises of goodness. We'd be changing package managers more often than we change socks if we followed that policy.

Can we agree to disagree at this point? I don't think this back and forth is very productive anymore.

[Sorro]

Flatpak and wayland as defaults would be kind of controversial and not ideal, but in a way, they both make sense

As of the current state of both, they should not be used as a default simply because they have problems that the older tools (apt and x11) don't have

But in the future I can see them becoming as good options to have as default: Wayland has better touchpad support for laptops, flatpaks have better security and lower risk of breaking a system. As development for both advance, the amount and frequency of problems will be reduced until, someday, they are as stable and reliable as apt and x11. Then it will make a lot of sense to make both of them, flatpak and wayland, defaults on a system. But today we are still a bit far from that, as both of them give problems more frequently than the old options do

[zenzen]

Agreed, when any average Joe can come and install packages without running into weird quirks that'd be a different story then.

[anon2532484]

@zenzen

Can we agree to disagree at this point? I don't think this back and forth is very productive anymore.

That's fair.

[anon2532484]

@zenzen I've added this extra note, does this look fine to you or should I make fundamental changes to the way that paragraph is written?

[Aravisian]

@anon2532484

that on mobile platforms which pioneered this concept the platform is already established

I really need to point something out about this.
The statement above is true. But it is important to examine why Mobile Devices pioneered this.
It was to lock the user out.

Mobile Devices wanted to ensure that the user could not modify, customize, or change the way the Device works. Google and Cellular service suppliers wanted to be sure that their apps could not be uninstalled. Or that users couldn't change the workflow on the device.

And this is exactly what we experience on our mobile devices. We are locked out.
And google is in full control of all the data that passes through Android. And which apps we have.

What we experience on mobile devices cannot be described as anything other than being forced to step toe to line.

But at least Mobile Devices are Secure and Safe, right?
No. Containerizing the mobile devices did not help their security and people regularly fall victim to ransomware and scams on their mobile devices. You see... the ransomware is installed in its own container, too.
https://pages.nist.gov/mobile-threat-catalogue/cve-list.html

The words "improvement" and "improving" the user experience are often pushed on the users as a means of trying to get them to accept changes that the users do not want.
If something was an improvement of the user experience, they would probably like the changes and not need to constantly be pressured to accept them.
In reality, the users are often angry, frustrated, resistant and constantly searching for ways to remove these "improvements" (locking the user out) in order to actually take ownership of the device they paid a ridiculous amount of money for.

@anon2532484

just trying to install Steam and consequently bricking his system due to a dependency error.

I cannot fathom how he did that. You cannot brick a system from a dependency error.
Bricking a system means that the hard drive is destroyed and cannot be used again. It must be replaced. A bricked machine is broken beyond repair. That is the definition of "Bricked" - the device has been reduced to the electronic properties of a Brick.

A dependency issue does not lead to bricking a machine. It can lead to necessary steps to correct the dependency and these errors most often appear when a user tries to install from the Wrong Repository (usually being Gung Ho for the latest and greatest...)
If LinusTechTips could not handle a dependency issue: He Has No Business Making YouTube Videos.

[Sorro]

@Aravisian

Mobile Devices wanted to ensure that the user could not modify, customize, or change the way the Device works.

Due to how complicated and tech-savy it can be to get root privileges on android devices that had been found a way to do so, when I was starting to switch to linux and saw on a tutorial "you will need root privileges" I immediately thought I was about to have to learn to do something so complicated that I would probably have to give up, not just type "sudo" and that's it. Android gives more freedom than iOS (sideload .apks and other software stores) but I wish it gave a bit more freedom.

And because of android's locked-in measures (locked bootloader) and the update methods (seeing an android device with more than 4 years of updates is rare, and phones/tablets can last much longer than that) I'm surprised Google hasn't gotten sued over the huge e-waste that this causes. My tablet runs the literal minimum android version required for most apps nowadays (Android Oreo, 8) but it still works almost like new

Containerizing can be a good way to improve safety and privacy. But Android is not the best example for this

[Aravisian]

@Sorro

Containerizing can be a good way to improve safety and privacy.

Containers were a solution to a problem: Creating an ability to make apps installable cross platform. That was it. It was never about security or privacy. Indeed, when tested, they do little for security or privacy.
Initially, when resistance to the problems containerization brings was met; Containers provided a bit of security due to it being new and not yet exploited. So, this was picked up and used as a selling point. That was then; this is now. And containers are not so safe, after-all. This is why I was posting links to the CVE reports above.

We must be skeptical about claims made by those who have a vested interest in pushing their wants onto the user base.

[zenzen]

I mean, since you ask, I would phrase it such that the connotation is to use .deb first, and use flatpak as a fallback.

[zabadabadoo]

@Aravisian

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.

@zenzen

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

@zenzen

I mean, since you ask, I would phrase it such that the connotation is to use .deb first, and use flatpak as a fallback.

I have taken time to read through many posts in this interesting thread today. The quotes above resonate with me, as I am running Z16 Core very well indeed on a decades old-but-solid laptop, which I hope to upgrade ito Z17 without drama.
Having to install (Mozilla) apps as Flatpaks may defeat that objective for me, if their installed size on disk is inflated and if app extensions cannot be added.

Also, how many times do you see on the forum issues where apps seem not to function correctly with the rest of the system due to double sandboxing. I am so used to asking the OP the question: "how did you install the app, was it a snap or flatpak by chance."

[zenzen]

Exactly, I don't even use Flatpak myself and I've learned a ton about it simply by trying to help other people out with that. Even without considering any of the other pros and cons, this alone is more than enough for me to not recommend Flatpak as the first option; this is not say that it shouldn't be used or that is doesn't provide any value.

[anon2532484]

@Aravisian

No. Containerizing the mobile devices did not help their security and people regularly fall victim to ransomware and scams on their mobile devices. You see... the ransomware is installed in its own container, too.

Containerizing - or sandboxing, two different concepts - helps in letting that ransomware stay inside the sandbox, minifying the threat to only that one program.
Additionally, the weakest link being someone uninformed on basic Cybersecurity is not fault of a Sandbox.

Although, Android's Sandbox is far from the strongest. It works by cleverly using Linux's user and groups system, limiting each app to it's own user and giving that user only very specific permissions, as well as some things implemented in the Android Runtime / ART; Although this is sometimes not sufficient.

However, I have heard rumours of Google wanting to implement a proper Hypervisor, essentially introducing virtualization-based security to Android in the future.

@Aravisian

List of CVEs · Mobile Threat Catalogue

I don't believe that just linking CVEs that are unrelated to sandboxing in of itself and are all fixed and don't go any further than 2017 - over 5 years ago - is really making a good point for you. Unlike other historical comparisons in different contexts, CVEs are bugs in software that can be exploited and are to be fixed, although lots of these may go unnoticed with or without Sandboxing. It really doesn't fit the point.

@Aravisian

I cannot fathom how he did that. You cannot brick a system from a dependency error.
Bricking a system means that the hard drive is destroyed and cannot be used again. It must be replaced. A bricked machine is broken beyond repair. That is the definition of "Bricked" - the device has been reduced to the electronic properties of a Brick.

I come from the Android world with that term, so pardon me for linguistic differences. Here we differentiate between a Soft Brick and Hard Brick. The former being a brick that renders the device unusable, but can be fixed. The latter presents a failure so bad that it is beyond repair. I didn't notice people from outside the Android world used the word "brick" different.

Although to explain what happened (or at least, what I've understood from it), Steam required a newer version of a dependency that was included in the pop-desktop metapackage. Because Linus hadn't yet updated his system, trying to install the steam .deb package tried to pull in a newer version of said dependency. Instead of apt marking the pop-desktop package for an upgrade too, it decided that removing it was the way to go as it ""conflicted"" with the newer version of said dependency. Although Linus had to write out a full sentence as confirmation ("Yes, do as I say") he still ended up soft-bricking the system, rendering it unusable for it's intended usecase.

It was truly a sight to behold, although the Debian developers have since patched this up and made it harder to remove essential packages.

[anon2532484]

@zabadabadoo

how many times do you see on the forum issues where apps seem not to function correctly with the rest of the system due to double sandboxing

"Double Sandboxing"? Flatpak only provides one, Snap only provides one, and Zorin doesn't implement something like Firejail on-top either

[Aravisian]

@anon2532484

I don't believe that just linking CVEs that are unrelated to sandboxing in of itself and are all fixed and don't go any further than 2017 - over 5 years ago - is really making a good point for you.

They are related to Sandboxing. That is exactly why I linked to them.
That they are fixed - or even old, does not detract from the point at all. The vulnerabilities are exploitable - as demonstrated by the exploitation.
It would be unrealistic to think that exploits are left unfixed or still open after a few years. The demonstration is not in that something got addressed; but that these vulnerabilities are present and can be exploited.
The argument is that Sandboxing prevents this type of exploitation - it doesn't and above this is demonstrated.

@anon2532484

"Double Sandboxing"? Flatpak only provides one, Snap only provides one, and Zorin doesn't implement something like Firejail on-top either

Sudo.

GnuLinux already sandboxes the Root from the User.

Having Flatpak or Snap also sandboxed on top of this is where the "double sandboxing" comment comes from. While we do not refer to the "User Isolate" as "sandbox", the concept of referring to it as doubled up is valid.
It is also valid to point out the commonality of user issues with Snap or Flatpak packages being isolated from the system and therefor unable to function properly or function at all.
These are serious and also too-often seen issues and covering their occurrences means addressing these issues, not being "mean to Snap and Flatpak."

[swarfendor437]

Well let's take a look at the history. Flatpak was an idea put together by a group of independent developers and guess who showed up to join them? Leonard Pottinger who produced the goo ball of systemd and the awful Pulse Audio. Flatpak became adopted by Red Hat. snapd is a "competitor" to flatpak, both projects having the same ideas of a cross-platform installation process. Whilst it looks good on paper, what happens in practice is not clear. The people who lose out are the end users. I can speak of two incidents that occurred to me recently using both flatpak and snap packages in KDE neon, based on Jammy Jellyfish. When Discover tried to update Inkscape it reported that the flatpak framework had crashed. The other issue of standalone packages is that it prevents seamless integration with the system. Apt might be 'old hat' but the old hat fits the GNU/Linux ecosystem far better than flatpak or snap! I want a stable system, not one with different parts to go wrong. I've read elsewhere on here that the Gnome project wants to move away from GNU, the essential half of GNU/Linux, which to some extent is what Red Hat have been attempting to do for some time with regard to its long-term aim to remove /etc from the GNU operating system. If that had happened I would not have been able to create a blaclist.conf file in order to get my SoundBlaster Audigy Rx 5/7.1 working, and /etc is where pulse (audio) lives, but now it lives in 'pulseoff' inside /etc to prevent it from starting up so I can enjoy the superior audio package of Advanced Linux Sound Architecture.

[anon2532484]

if I'm going to be completely honest, your argument seems not based on actual reasons that one is better over the other but hate for RedHat
don't get me wrong, I don't like RedHat personally, but I also do not hate them either.

The arguments you've listed in here are as follows:

• Flatpak crashed once = apt hasn't in my experience = flatpak worse
  This statement holds no value in regards to neither Flatpak or Apt's stability as all software is imperfect. All software will crash or has crashed at some point in time, and no piece of software will ever be crash- or bug-free. This includes Flatpak, Snap, apt/dpkg and tons more software.
• The 'old hat' fits better than Flatpak or Snap
  This is an unreflected statement based on the sentiment that old solutions are supposed to be replaced. They are not. The intent behind the Flatpak project is not to replace traditional packaging, but to provide one platform, set of dependencies and more to target, especially in regards to being distribution-agnostic as long as some basic needs are met. Flatpak has it's uses, apt has it's uses, neither are supposed to replace eachother.
• I want a stable system, thus no flatpak!
  Numerous instances on this forum alone have shown that apt is far from perfect in handling packages, especially complex upgrade transactions. Many of the issues reported have to do with unmet dependencies, unfinished upgrades, package conflicts and more caused from various different apt-related things. As I moderate the Matrix and Telegram communities I can also say that many of the issues there reflect the same pattern. Apt is not inherently more stable just from being a system package manager, there is still a lot of complexity with it that the Zorin, Ubuntu and Debian developers are trying their best to avoid breaking.

I want to add that the fact system integration works differently with Flatpaks due to one of Flatpak's goals being sandboxing does not make apt better for EVERY usecase. I know many people that even go out of their way to intentionally run things installed with apt under Bubblewrap, Flatpak's sandbox or Firejail. Yes, the fact that system-wide apt installation of packages does mean these programs kind of just get access to everything your user can makes it more convenient, but it also proposes a security issue as any program could abuse this access.

Now this is not to say the Flatpak Sandbox, which I'll refer to by it's name Bubblewrap from here on out, is perfect. There is known ways to escape bubblewrap as it is pre-configured for most packages that have no simple solution that wouldn't break some existing Flatpak packages, although some of this is to blame on Flatpak package maintainers, which forget to properly adjust the default permissions to fit the program's need (e.g some programs ship with full /home access where it isn't needed).

@swarfendor437

I've read elsewhere on here that the Gnome project wants to move away from GNU, the essential half of GNU/Linux, which to some extent is what Red Hat have been attempting to do for some time with regard to its long-term aim to remove /etc from the GNU operating system. If that had happened I would not have been able to create a blaclist.conf file in order to get my SoundBlaster Audigy Rx 5/7.1 working, and /etc is where pulse (audio) lives, but now it lives in 'pulseoff' inside /etc to prevent it from starting up so I can enjoy the superior audio package of Advanced Linux Sound Architecture.

And this part is not related to packaging at all, but is a rant on things you dislike about what RedHat (supposedly, you've not cited sources of these /etc claims) wants to do.

I also to reiterate on the fact that I do not want to get you to use Flatpak. You're free to use whatever software you like, but spreading misinformation or unreflected takes on this software is something that I do not want to see in the Zorin Forums as it creates a false narrative of when you should / shouldn't use certain software.

---

TL;DR:
Many of your takes are unreflected and on the basis of everyone wanting to replace system packaging, which is not the case. Not only do some of your points also apply to Apt but also have you not taken into consideration that apt and Flatpak aren't used for the same things, in the same situations nor are they supposed to replace one another's usecases.

[swarfendor437]

In respect of the /etc issue it appeared in an article from this website which I can no longer hone in on:

https://unixsheikh.com/index.html

The only BSD I have had success with is Ghost BSD. Perhaps I should take another look!