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
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 
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.
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?
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
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.
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
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 
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
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]
probably ↩︎
Like for example, when the Firefox Flatpak isn't configured to allow any inter-process communication outside of dbus ↩︎
exclusively / only ↩︎
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. ↩︎
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.
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.
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.
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.
2 Likes
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.
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.
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.
1 Like
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
1 Like
Agreed, when any average Joe can come and install packages without running into weird quirks that'd be a different story then.
1 Like
That's fair.
@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?
2 Likes
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.
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.
2 Likes
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
1 Like