SoylentNews is people
SoylentNews
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: 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...
🌻🌻 [google.com]
(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.