Ubuntu Has Started Work On A New Desktop Snap Store

[Weasel]

All applications for Linux should be distributed as packages/snaps/flatpaks for Wine win32. Because Wine win32 is the only stable API in the entire Linux world. Am I joking? Not sure. LOL.

That's exactly the spirit. Been saying this for ages now, but people are very ignorant (wait for oiaohm to start with his bullshit).

[Vistaus]

On Windows you download installers that put the needed files in to your system however they please.

Yeah, the only thing that comes close (actually very, as it's a direct copy) is ESH, but so far, Q4OS (who created ESH) is the only distro that uses it.

[MoonMoon]

I like how the flatpak vs snap discussion totally omits which software is available for it. That is like discussing distributions without considering which packages are available.
I work with the Jetbrains IDEs, mostly Goland, PHPStorm and Pycharm.
They are available as snap, but not as flatpak.
Wanna guess which format I have chosen?

[tildearrow]

Things that break system will break it despite that. You can't blame the model by one case, i don't have any problems related to ICU, while i've using Linux.

I do, however. I have 4 versions of js, and only 2 of them work. The other 2 are broken:

~$ js24
js24: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or di
rectory
~$ js38
js38: error while loading shared libraries: libicui18n.so.61: cannot open shared object file: No such file or di
rectory
~$ js52
js>  
~$ js60
js>

So that's error in distribution not by design. If the model was static linking every update will take hours and look more broken like Windows one.

No, I don't mean "static link everything". I'll quote my approach again:

Exactly! This is *exactly* what has to be fixed in Linux userspace in order for it to become a good desktop OS.

Here I propose a solution:

- Separate the userland into 2 spaces: the base system one (the monolithic and glued together one), and the other "variable" one (for user applications, macOS style).

- The base system provides an "SDK" which can be used to develop applications for the "variable" space, and it must consist solely of very stable (as in API) libraries.

- Developers can still target the base system, but they are encouraged to use the "SDK".

Although Flatpak and AppImage are trying to do something like this, they have problems. In Flatpak it demands sandboxing. In AppImage there is no standard "library base", resulting in developers having to pack in many libraries (which sometimes are often used like Qt), and as such AppImage versions of apps are generally bigger than their macOS/Windows counterparts. Furthermore, they don't want the developer to use newer versions of certain libraries (such as newer versions of glibc) to "achieve broad compatibility". What if he/she really needs to use the new features?

Also, it requires the user to "make it executable", something the Windows/Mac user doesn't do when he/she downloads an application.

So no, if it's open source - you don't need to do something, packager will do it, if you have closed source it should be done by flatpak or snap.

We can't be forcing everyone to sandbox.

[tildearrow]

No, it can't work because
- mesa-18.5 depends on libcpp 8.2
- last version of OpenSSL depends on libcpp 7.9
- you can't load two different versions of libcpp at the same time.

The dynamic linker should be improved to allow the concept of namespaces. According to Weasel, Windows can do this.

[betam4x]

Just download LibreOffice appimage and it runs fine. There is nothing better than distribution specific, appimage should be natural bundle for open source apps, Snap and Flatpak goes for sand-boxed ones. Linux distribution software is the best at the moment, bundling like dmg, apk, appimage as well, leave things *dangling* to incorporate 3-th party depends that can involve system at risk. That's why Snap and Flatpak take a hand on, they offer sandboxed environment to leave system untouched. So after all if your distro provide a X application it's better to use it from there, if not then you can leverage to what's offered (appimage only if it's open source).

Except apps DO need to be sandboxed. It's a good security practice. Sandboxing doesn't have to have speed penalties either if properly implemented. Even Windows is heading in this direction. They are using Hyper-V in a future build to sandbox a Windows installation for untrusted applications.

Both snap and flatpak have had security issues, and X itself is one giant security issue, however, either the community will use snaps, or they will use flatpaks. .deb files and .rpm files will eventually go away. I believe that Ubuntu's smallest version already uses only snaps for packages. They are likely slowly working towards eliminating .deb files altogether.

[betam4x]

We can't be forcing everyone to sandbox.

Sandboxing doesn't mean bundling every lib with your app. You can have the libs on your machine and have the app load the appropriate ones in a sandboxed environment. That's actually the correct way to approach things. Libraries are meant to be shared among multiple apps. Sandboxing is a good security practice because it limits access to the system. People place way too much trust in their favorite applications, linux distributions, etc. Sandboxing eliminates quite a bit of the need for trust. However to get the rest of the way there, we need the packaging system to display required permissions and allow the user to opt out of the ones they don't want (and those permissions should be enforced). Right now, none of the proposed formats does that. While you may say that it's an annoyance, that annoyance just might save your bacon the day you download a bad package and it asks for suspicious permissions.

As Linux desktop marketshare grows, it's going to become a target for "hackers" to attack. Unlike Linux, Windows has already dealt with this for many years and is hardened against quite a few attacks, yet Microsoft is still pursuing sandboxing, virtualization, etc. to further increase security. Linux distributions must do the same or they will end up in a similar fiasco to what Windows had where a worm takes over a metric ton of machines.

[mattlach]

NOOOOOOOOOO


All of this Snap/Flatpak/Appimage garbage needs to die a horrible death.

There should only be one way to install linux software. Through the main system package manager!

Seriously. The unified package manager for the entire system is one of the greatest benefits of Linux, and moving away from it, or offering any alternatives what so ever is a huge leap backwards, especially with these ridiculous packages of inefficient statically linked garbage!

I'm all for everyone doing their own thing, but I fear that it will be impossible to opt out of Snaps and other garbage image installers in the future, as they replace available packages for the traditional package managers.

[betam4x]

NOOOOOOOOOO


All of this Snap/Flatpak/Appimage garbage needs to die a horrible death.

There should only be one way to install linux software. Through the main system package manager!

Seriously. The unified package manager for the entire system is one of the greatest benefits of Linux, and moving away from it, or offering any alternatives what so ever is a huge leap backwards, especially with these ridiculous packages of inefficient statically linked garbage!

I'm all for everyone doing their own thing, but I fear that it will be impossible to opt out of Snaps and other garbage image installers in the future, as they replace available packages for the traditional package managers.

There is no 'universal package manager'. There are different package managers for different distros, sometimes more than one (ubuntu with snap as well as apt/dpkg). Even distros using the 'same' package manager may have modifications or additional tools to manage packages which makes them incompatible. In addition, depending on the package version, it may break your Linux install (installing ubuntu packages on a debian system for instance.) The whole reason Snap/Flatpak/AppImage came about is a desire for a better method of distributing applications in a distro independent, more consistent, more secure, more flexible way. Linux is way behind on 3rd party application distribution. In reality, these projects are about catching up to/surpassing Windows and macOS, who have had their own ways of installing applications since uh, the 90s.

Also, did I mention that the packages and package managers themselves quite often break? These large volumes of packages are maintained by volunteers, and if one slips up, it can cause dependency conflict nightmares. Or what happens if one goes rogue and inserts a package that installs an application with a back door? It has happened.

Let's say for argument's sake that every distro out there uses snap. Not only would every distro have access to all Linux software, but that software would be sandboxed, dependencies would not be an issue, so install times would be much quicker and download times much shorter, and you are almost guaranteed to not break the system. In addition, removing the package is just as painless. Also, snap packages can be installed in the user's home folder, so they don't even need to be system wide. There are just too many arguments FOR the concept of a universal package format and package management system and not any real reasons to stick with what we have now other than 'it somewhat works and it's what I'm used to'. This also isn't change for the sake of change. Neither was systemd. Though that didn't stop people from hating on it.

[kingu]

This reminds me of when Intel lied and said the x86 architecture was dead and couldn't be resurrected, and then tried to force the world to dispose of all existing software and hardware and switch to Itanium. But of course that was a foolish and transparent ploy, just as the arguments for suddenly dropping 32 bit today are, and Intel simply wanted to make more money.

You mean you aren't running Itanium? Are you in the past?