For roughly two decades, Linux distributions have been the first choice for servers. Hardware support for Linux on the desktop has historically been an encumbrance to widespread adoption, though support for modern hardware on modern distributions has progressed such that most hardware is detected and configured correctly upon installation.
With these advances in hardware support, the last significant challenge users face when switching from Windows or Mac to a Linux distribution is app distribution and installation. While distribution-provided repositories are useful for most open source software, the release model of distributions such as Ubuntu or Fedora lock in users to a major version for programs for the duration of a particular release.
[...] Because of differences in how they interact with the underlying system, certain configuration tasks are different between Snaps or Flatpaks than for directly-installed applications. Likewise, initial commits for the Snap and Flatpak formats were days apart—while the formats were developed essentially in parallel, the existence of two "universal" package formats has led to disagreement about competing standards.
TechRepublic's James Sanders interviewed Martin Wimpress, engineering manager for Snapcraft at Canonical, about Ubuntu's long term plans for Snaps, its adoption and support in other Linux distributions, Canonical's position as the operator of the Snap Store, and the benefits Snaps provide over Flatpak.
(Score: 2, Informative) by Anonymous Coward on Tuesday August 06 2019, @08:42PM
https://xkcd.com/927/ [xkcd.com] "Standards"
(Score: 3, Interesting) by Anonymous Coward on Tuesday August 06 2019, @08:55PM (1 child)
You lost me, right there...
And, the whole fucking thing is tied into their servers, a 'curated store' of apps (sound familiar?) and you can't switch off the bloody auto updates..
Talk about control freakery, and a Trojan Horse or two waiting to happen.
Momsers.
(Score: 2) by fyngyrz on Wednesday August 07 2019, @03:27PM
From TFS:
Hm. Well, the thing that keeps me on my current OS — OS X — is the fact that the apps I've invested significant amounts of time and energy (and money) won't work except on the OS I'm using now, and my dev systems are all local to this machine as well, so my custom stuff is at least somewhat anchored here.
Worse, since many of the big app makers (of my apps, anyway... Adobe, etc.) have pretty much all moved to the much-despised-by-me "subscription model", those apps will never be available under Linux, except potentially in forms I wouldn't touch with someone else's ten-foot-pole.
I do use Linux for both web and file servers, and often test my Python stuff there before making it public, but other than that... not so much.
Mind, I would not resist moving to Linux if I could take all my goodies with me... the freedom to build custom machines would be great... but really, I can't move my apps except under relatively clumsy (and technically illegal) VMs, so that's not happening.
I guess it all boils down to the fact that you can't distribute an app if there is no app.
--
Any pizza can be a personal pizza if you believe in yourself.
(Score: 5, Interesting) by Thexalon on Tuesday August 06 2019, @09:27PM (14 children)
Anybody can distribute a source tarball. Any distribution can convert a source tarball into a binary package of the type of their choice. What's the problem?
Oh, right: You want to be able to easily add proprietary stuff that does $DEITY-knows-what to my system. Well, there's a solution to that too: Include a component that acts as a shim to connect to the distro's base system, distribute the rest as object files capable of being linked with that shim, and again either I can compile it or my distro of choice can. I'm still not seeing the problem here.
I get why Canonical wants their thing to become the Linux standard. It's the same reason Red Hat created stuff like LSB in an attempt to become the Linux standard. It's the same reason SuSE and quite a few others did: They want to gain enough market share to become the new Microsoft / Apple. Well, we don't need a new Microsoft / Apple, we need systems that can be set up the way the admin wants them set up. Which ultimately means Give Me The Code, and let me build my own damn packages if I need to.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by Gaaark on Tuesday August 06 2019, @09:59PM
"Yakko: "All is strange and vague." Dot: "Are we dead?" Yakko:
"Or is this Ohio?"Yakko: "All is strange and vague." Dot: "Are we dead?" Yakko: "Or is this Microsoft?"
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 3, Insightful) by edIII on Tuesday August 06 2019, @10:44PM (1 child)
I think one of the reasons why they are doing it is that it is the only way to appeal to the masses, and that's with an app store. Or at least the behavior of one. Not just the control of an app store, but the ability to scale the possible number of users up far more.
That's the advantage using an app store versus a CLI repository/package manager. No compiling, automatically includes dependencies (or has flags to), and can configure the system for services in some cases. Snap or flatpak, or whatever, just seems to be an attempt to bring another GUI and more advanced provisioning features with the ease of an app store. That's easily abused when you're trying to change a repo into a revenue generating app store. Understandably, we should be concerned about this. I wouldn't want revenue decisions affecting my repo.
A source tarball isn't necessarily as easy an app store, or even a repository either. You need to, IIRC, install the dependencies and test them on your own. Sometimes those dependencies cannot be met for some reason, or conflict. A GUI package manager would make it easier, but not all software is distribution agnostic, and that's where Snap would have source tarballs beat all day long. I don't have to worry about anything of that, or spend 30 minutes carefully fixing obstacles to an error free fully tested build.
Unfortunately, the Year of Linux on the Desktop might require that bullshit.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 4, Insightful) by JoeMerchant on Wednesday August 07 2019, @02:05AM
First off, when I make a fresh Ubuntu install, one of my first orders of business is usually:
sudo apt purge -y snapd ubuntu-core-launcher squashfs-tools
I've tried snap apps, they do nothing I need, though I do see the potential. One of my peeves of continuing life under the evolving distros is that favorite "apps" go from supported, to replaced with a new default but installable, to uninstallable but can be built from source, to major surgery to keep them compatible with the new library ecosystem - it's happened to me more than once and I hate it. With snap packages (I assume) you can keep your fossil library support system as part of the package and migrate it forward much longer with much less hassle, so that should be a good thing in the future. If it's not, well, I know that's how Docker containers work and we can always use them - though snaps seem more friendly to GUI apps than docker containers currently are.
All of these "lightweight quasi VM" techs still interface with the kernel, so if the kernel functionality drifts too far then the self-contained packages are still screwed, but hopefully the kernel will not need to discontinue too many interfaces "in the name of security" in the foreseeable future.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 5, Insightful) by darkfeline on Wednesday August 07 2019, @12:20AM (9 children)
The problem is shared libraries aka dependency hell.
>Any distribution can convert a source tarball into a binary package of the type of their choice.
HAHAHA no. That only works if all of the dependencies are available in the distribution's package repositories, and of the correct version. Otherwise, you're off to hunt down the source code of all of the libraries, compile those from source, recursively. And make sure you carefully ./configure all of them and set the right build and install paths so they all find the right versions of all of the shared libraries they are expecting, and that they are compiling with the right version of the library headers and also running with the right version of the object files.
Snap (and all of the alternatives like AppImage) is static linking, reinvented. The problem it is solving is dynamic linking. It turns out that in a dynamic linking world, it's easier to bundle all of the libraries up rather than link things statically (hell, glibc can't be linked statically).
Join the SDF Public Access UNIX System today!
(Score: 2) by JoeMerchant on Wednesday August 07 2019, @02:30AM (1 child)
That used to be called Gentoo...
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 0) by Anonymous Coward on Wednesday August 07 2019, @03:10AM
Exherbo!
(Score: 1, Insightful) by Anonymous Coward on Wednesday August 07 2019, @02:34AM
I have spent countless hours trying to resolve dependencies. It is Hell.
One application just breaks when a component is updated. Every. Damn. Time. Sure, I could use another program but ffs this should Just Work.
BSD has the Ports tree. Its a nice idea. When the tree is frozen all software should be usable. It works, mostly.
A while back "Thinstall" was all the rage. It took a snapshot of the Windows system before a program install, and one after to gauge what an installer did to the OS registry, filesystem etc. Then it built a container for the changed objects. When running an application through ThinApp the application was fooled into seeing the containerized files as the OS. It rocked. You could create a runnable container for programs on Win7 that would only run on previous Windows versions. So nice.
(Score: 1, Informative) by Anonymous Coward on Wednesday August 07 2019, @08:58AM (1 child)
The problem it is being a bad workaround for is idiot maintainers not using symbol versioning.
https://sourceware.org/binutils/docs/ld/VERSION.html [sourceware.org]
There are other libc's that can. But the significant detail is, you should not need to. Glibc symbols ARE versioned, so unless the program needs a newer glibc AND you want to stick with an old one for some sentimental reason, all the compatibility problems are for dynamic linker to transparently resolve.
(Score: 2) by darkfeline on Thursday August 08 2019, @02:17AM
If your solution relies on other people doing everything exactly as you command and generally not being irrational and stupid, your solution doesn't work.
While you opine about your solution that doesn't work, other people will be making solutions that do work.
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Wednesday August 07 2019, @09:34AM (1 child)
That problem was solved with NixOS and GuixSD. What Canonical is trying to do is avoid the real solution in favor of ugly, insecure hacks.
(Score: 0) by Anonymous Coward on Friday August 09 2019, @01:29PM
From my somewhat limited understanding, I agree. NixOS and GuixSD are heading in the right direction/have the right general idea, but are too nerdy for normals to use. All three of these "solutions", flatpak, snaps and appimage address the symptoms instead of the root issue and take gnu+linux backwards overall (to varying degrees), even if improving the convenience for end users of distros who won't change their antiquated release model and/or haven't invested in automation or cooperation with other distros. All distros should be rolling release. You don't have to be bleeding edge just b/c you're a rolling release, but i think distros will figure that out eventually, if they aren't allowed to ruin the whole gnu+linux ecosystem before they are forced to change. They can just have separate tracks (seppuku, stable, and luddite).
What should be happening with distros like Ubuntu is, as users move to rolling release distros or stay and complain due to ancient packages, said distro should be doing an honest self evaluation and changing the underlying problem. instead they come up with this cop out. "Let's bastardize the whole gnu+Linux ecosystem so we don't have to have up to date packages the right way! yay, it's so easy! just download bloated binaries from our proprietary cloud app store like a mac user, or from random places around the internet like a windows user! yay!"
The gnu+linux ecosystem needs an upstream packaging description format (or suthin') like php's composer that upstream devs can use to describe the upstream sources that their release relies on, and whatever else. Then, every distro's package manager can read that, and auto-build for their distro. Distro maintainers should be spending all their time improving the distro, not trying to build every release of upstream packages manually. I think this would help with fragmentation, such that it exists, solve the problem of old packages in distros, while keeping repos and the security and QA that those bring. There's no need for a proprietary, vendor controlled app store, nor bloated "packages" that re-ship the same support code. We just need a little cooperation, a standard, automation and if a distro wants to make packages discoverable and easy to install for new users they can make a package installer gui, which already exist.
This should also make completely reliable Auto Update a thing on gnu+linux which would be a big deal for adoption. There are other things, like a completely transparent GLSW (gnu+linux subsystem for windows. no Wine, as it currently exists, does not cut it.) that maintainers/devs could work on that would make linux on the desktop a reality very quickly, if they weren't so busy rebuilding the same software all the time.
I don't know enough about packaging and maintenance to say exactly how it needs to be done (that may be obvious by now), but i know if all the maintainers of all the distros put their heads together to address *the actual problem*, instead of trying to hack around it to maintain the status quo at their distro, they could come up with a system that would work. If there are unsolvable problems with my overall idea i would like to hear what they are, but i suspect these are solvable by people with the right skills who may currently lack the proper motivation (we do have a funding problem in this space), perspective or common sense (no offense, it just seems that programmers can be very intelligent, but lack common sense many times).
Here's hoping we figure it out before the whole ecosystem is ruined for convenience or to control a bigger chunk of a small market, instead of growing the market exponentially, and possibly having a smaller percentage of that. I'm looking at you Canonical.
(Score: 3, Interesting) by loonycyborg on Wednesday August 07 2019, @10:31AM (1 child)
My main reason of supporting flatpak instead of snaps is that flatpak has concept of runtime: a set of libraries that is separate flatpak but will be automatically pulled in by app that depends on it. Multiple apps can share same runtime but you also can have multiple (versions of) runtimes installed. So you can have apps using different runtimes installed side by side yet apps that use same runtime will share it. This is a lot better than static linking. Still wastes lots of disk space but worthy tradeoff IMO if you want truly cross-distro format.
(Score: 0) by Anonymous Coward on Friday August 09 2019, @04:06AM
yes, if i use any of these i expect it to be flatpak.
(Score: 3, Touché) by c0lo on Wednesday August 07 2019, @02:26AM
But... but... games? And DRM content? And... and... behavioural tracking and targeted ads. That's where the money is, why do you hate capitalism?
https://www.youtube.com/watch?v=aoFiw2jMy-0
(Score: 0) by Anonymous Coward on Tuesday August 06 2019, @11:17PM
Apparently the name Snap is already in use: https://packages.gentoo.org/packages/dev-haskell/snap-server [gentoo.org] for a few projects: https://packages.gentoo.org/packages/search?q=snap [gentoo.org] so could you try another? Or are you really distributing Haskell to end users?
Hmm, FlatPack doesn't have the same problem: https://packages.gentoo.org/packages/search?q=flatpack [gentoo.org] so we should adopt that by default.
(Score: 2) by Acabatag on Tuesday August 06 2019, @11:46PM (3 children)
NetBSD's pkgsrc collection [pkgsrc.org] is a compelling 'distribution'-agnostic solution.
You don't even have to run Linux to use it. And it isn't controlled by some corporation.
(Score: 2) by Pino P on Wednesday August 07 2019, @12:15AM (2 children)
I don't see how something called "pkgsrc" can work for programs that for some business reason cannot be distributed as source code under a free software license. The submission policy [netbsd.org] states that pkgsrc must build all binaries. Can you think of, say, any AAA video game that's free software from day one?
(Score: 2) by Acabatag on Thursday August 08 2019, @03:19AM (1 child)
I can't think of any AAA Video Game that is packaged with this 'Snap.' Do you have some examples to show us?
(Score: 2) by Pino P on Thursday August 08 2019, @01:42PM
I concede that I'm not aware of any video game from a major publisher currently distributed by that publisher through Snap Store. But I used "AAA video game" as an example of the sort of software that is unlikely to be distributed under a free software license. Another example is subscription streaming media players, such as Spotify [snapcraft.io].
(Score: 5, Interesting) by optotronic on Wednesday August 07 2019, @02:00AM (2 children)
I've only been using Linux for about 5 years (Xubuntu mainly) and ran into snaps a year or so ago. But my limited experiences have me avoiding them completely. My first experience was with Libre Office. In a recent version of Xubuntu, when I went to the Software program (GUI) and installed Libre Office it installed a snap version. Once installed it only wanted to save files in a virtual volume it had created. I couldn't figure out how to save files to my documents folder in my home folder. It wanted me to use its own documents folder in its own virtual volume.
A couple subsequent Snap installations left me with 5-8 virtual volumes I can't get rid of even after uninstalling the (damn) programs. This is supposed to be helping me??
Now if I can't get a non-snap version I don't use the program.
Did I do something wrong? Were early snap distributions crappy? Is my experience normal and I'm not supposed to care where my files go?
(Score: 0) by Anonymous Coward on Wednesday August 07 2019, @02:37AM
The early Snaps were crappy.
They are fixing it. Microsoft style.
(Score: 0) by Anonymous Coward on Friday August 09 2019, @04:24AM
Yeah, that's absurd. If i can't save stuff where i want, your "solution" is completely stupid!
(Score: 0) by Anonymous Coward on Wednesday August 07 2019, @02:47AM
This is Linux.
Why not have both?