Adios Apt and Yum? Ubuntu's Snap Apps Are Coming To Distros Everywhere (arstechnica.com) 274
An anonymous reader shares an Ars Technica report: Ubuntu's "snappy" new way of packaging applications is no longer exclusive to Ubuntu. Canonical today is announcing that snapd, the tool that allows snap packages to be installed on Ubuntu, has been ported to other Linux distributions including Debian, Arch, Fedora, and Gentoo among others. To install snap packages on non-Ubuntu distributions, Linux desktop and server users will have to first install the newly cross-platform snapd. This daemon verifies the integrity of snap packages, confines them into their own restricted space, and acts as a launcher. Instructions for creating snaps and installing snapd on a variety of distributions are available at this website. Snaps can exist on the same system as either deb or RPM packages. Snaps aren't the only new package manager for Linux distributions that aims to simplify installation of applications. There's also AppImage and OrbitalApps.
lol (Score:2, Funny)
Hay, finally a universal app for Linux!
Re:lol (Score:4, Funny)
And hello problems (Score:5, Insightful)
Adios to tried and true package managers, hello dependency and network/firewall hell as you try to resolve conflicts between the different sources?
Re: (Score:3, Funny)
Curses you package installer!!! No really, how do I install Curses with this?
Re: (Score:2)
I thought the idea was for snaps was that it would be statically linked packages so that they wouldn't depend on the system libraries (so basically we're moving back to /opt) and could theoretically have multiple versions of the same thing installed?
Re: (Score:2)
TFS does a crappy job of describing that, as certainly no such system is going to replace the primary package manage (apt/yum).
Re:And hello problems (Score:5, Informative)
Well, snaps actually are trying to solve this.
Let's say you have a critical program you need for your work. And let's also say that it needs specific versions of software installed - you can't upgrade those dependencies or your risk breaking the program.
Now, all package managers have the ability to freeze a package - that is, prevent updating it. So you dutifully do it, and it works great - in the beginning. Slowly as time goes on the number of updates you get will slow to a trickle as you get more and more new packages dependent on newer versions of the dependencies. Eventually you'll get to a point where you can't install anything as what you want needs a newer version than what you have, or is dependent on things that need a newer version.
Snaps help solve that - your program can be made into a snap with the versions of libraries it needs, while the rest of your system marches forward
It doesn't matter what the application is - if it needs specific revisions of dependencies, holding back can lead to various DLL hells.
Snaps won't replace apt or yum - those tools are always going to be required. Snaps are useful for programs with a tricky set of dependencies to have them easily met
Re:And hello problems (Score:5, Insightful)
That sounds a lot like the "winsxs" folder, which is currently eating up 25% of the total space on my Windows machine, for no good reason. Having the same "feature" on Linux really doesn't thrill me.
Re:And hello problems (Score:5, Insightful)
Re: (Score:3)
Snaps are useful for programs with a tricky set of dependencies to have them easily met
I suspect snaps will be used for far more than 'tricky dependencies'. They'll be used as an excuse to not keep code up-to date, because developers will be able to continue using obsolete 'legacy' libraries instead of coding against newer ones which will presumably be more secure and/or more stable.
Having said that, I still look forward to the day when I can install a snap of almost any application, in almost any version, (and even several versions of one program, say, Kicad), and be fairly likely to have th
Re:And hello problems (Score:5, Insightful)
So in other words the "solution" is the Microsoft way of shipping a copy of the .dlls with every single program. So if someone finds a security issue with .dll (say OpenSSL) even if the bug gets fixed in the library you need to issue updates to all the apps as well. Fun.
Re: (Score:3)
What would be really nice is if libraries would report backwards compatibility, so that you could default to using the latest version compatible with your program, but still have the "canonical" version bundled in case of program-breaking changes.
It sounds like Snaps are primarily targetting desktop software, and frankly if it's a choice between being as up-to-date and secure as possible, or being able to actually run the program that does what I need to do, I'll choose the second one every time. Besides,
Re:And hello problems (Score:5, Insightful)
FUCKING AWESOME!
You mean certain programs can opt to keep using vulnerable libraries?! YES! Soon Linux will finally catch up to Windows in terms of malware thanks to Snap!
Re: (Score:3)
Let's say you have a critical program you need for your work. And let's also say that it needs specific versions of software installed - you can't upgrade those dependencies or your risk breaking the program....
It seems that you have not heard of library symbol versioning.
Re: (Score:2)
Well, no, thankfully. "ported" of course doesn't mean "switched to." This is significantly misleading, but it will at least help with packages that don't have support on multiple distros. Not surprising when the headline writer thinks "yum" is still one of the package managers...
Where can I find a UNIX-like Linux distro?! (Score:4, Insightful)
In the year 2016, where can I, a long time Linux user, get a decent UNIX-like Linux distro?!
What I mean by that is a Linux distro that follows the UNIX philosophy of simplicity, doing one thing well, openness, and modularity.
All of the major distros today, including conservative ones like Debian, are rife with systemd, GNOME 3, now this "snap" crap, and all sorts of other shenanigans that violate the UNIX philosophy.
I don't want to use a goddamn relic like Slackware, either. I guess what I want is Debian, but just before systemd was forced on Debian users. So a distro that's sensibly conservative, that's reliable, that works, and that follows the UNIX philosophy.
And don't even bother suggesting Devuan. It's a terrible, terrible joke of a distro in my experience. Conceptually it's what I'd want, but in practice I've found it to be a total shitfest.
At this point I don't think I'll have any choice but to use FreeBSD. Yeah, it's not Linux, but I don't think that I even care about using Linux at this point. I need a UNIX-like system, and if FreeBSD can deliver (and all of the evidence suggests that it can!) maybe I should just say to hell with Linux and use FreeBSD instead.
Re:Where can I find a UNIX-like Linux distro?! (Score:4, Insightful)
1) I want to avoid modern technologies as much as possible because I hate them (therefore use Slackware, Devuan, CRUX, Gentoo, etc.).
2) I want a modern distro that uses mainstream technologies (therefore use Ubuntu, Fedora, openSUSE, Debian, etc.).
3) I want my own custom mix of 1 & 2 exactly how I like it (therefore make your own distro).
Re:Where can I find a UNIX-like Linux distro?! (Score:5, Interesting)
It's not a contradiction. A better way of putting it might be "more Unix and less Windows please".
It remains to be seen whether today's iteration of "yet another standard" is going to reduce the number of standards or just increase them (as is usually the case).
Also, dpkg and rpm are already widely supported. Moving to something new wipes out all of that progress. Churn for it's own sake in general does that.
We're not Microsoft. We can't burn something down and completely redo it every release like they do. We don't have the clout for people to put up with that kind of nonsense.
Re: (Score:3)
It's not a contradiction. A better way of putting it might be "more Unix and less Windows please".
It remains to be seen whether today's iteration of "yet another standard" is going to reduce the number of standards or just increase them (as is usually the case).
Also, dpkg and rpm are already widely supported. Moving to something new wipes out all of that progress. Churn for it's own sake in general does that.
We're not Microsoft. We can't burn something down and completely redo it every release like they do. We don't have the clout for people to put up with that kind of nonsense.
Ignore the clickbait headline. Nobody is saying "deprecate apt and yum". Snappy was invented to be used in parallel to them.
Re: (Score:2)
yum was already replaced.
Re:Where can I find a UNIX-like Linux distro?! (Score:5, Insightful)
I don't know if I'd throw the term "modern" around so much as "trendy". After all, isolating apps in containers where they cannot integrate with the rest of the OS is pretty much warmed over mainframe thinking.
Re: (Score:2)
I think the issue is that there is a lot of welcome new work, and a lot of unwelcome new work. This is of course nothing new and has been the case from the beggining of time.
However, this time, systemd is not something that can be opted out of so simply. You could for the most part pick and choose which things you thought were good and gleefully ignore what you don't like. systemd is not something that can be ignored in the event you disagree with it as a distro embraces it.
Thus far, Devuan has come the
Re: (Score:3)
It is trivial to avoid GNOME in every distro I've looked at. I really dislike GNOME 3, and as a result I avidly avoid anything by the GNOME team. I've had no problem doing this! It is really easy to never touch GNOME.
SystemD is not a deal breaker for me, but I would avoid it if it were easy to do so. It does not appear to be. Slack and Gentoo can function just fine with any other init system, and Devuan will hopefully eventually scratch that itch. If the requirement is "no systemd", you are ultimately
Re: (Score:2)
I think ultimately the community has been taken by surprise at the massive surge in most distros toward systemd. Different distros have all kinds of diverse things under the hood, different package managers, different locations for stuff, etc. But systemd just swarmed over everything, it seems really odd.
No, forum posters were taken by surprise. Fedora started using it in Nov 2010 and set it default 6 months later. RHEL introduced it 3 years after Fedora (2014). Debian had a massive 4 months long discussion complete with web pages detailing the pros and cons of each init system before coming to an agreement in early 2014.
Really though, the only actual problem I ever had with it was that on MY PC, I had removed a dead drive and never replaced it. When the SystemD update happened, it just hung. Ihe earlie
Re: (Score:2)
I happen to really like Gnome 3. I have had no problems completely avoiding KDE, LXDE, Unity, or what have you. Yay, Linux!
Re:You're making up contradictions that don't exis (Score:5, Insightful)
There's no contradiction.
1) Systemd and GNOME 3 aren't the only "modern technologies" out there. They are among the most anti-UNIX-philosophy ones. There are other modern init systems and desktop environments that do follow the UNIX philosophy, we just see the major distros treat them as second-class citizens, although they're typically superior to systemd and GNOME 3.
2) The point of using a mainstream distro is to get access to the wide community support network and the benefits it brings, including more testing of releases and quicker bug/security fixes.
3) The whole point of using a Linux distro is to avoid having to roll your own! In the past there used to be choice among the major distros. Debian is what you used when you wanted a system that worked. SuSE is where you went if you liked KDE. Ubuntu is where you went if you wanted a Windows-like experience. Fedora is where you went if you wanted to subject yourself to Red Hat-produced shit.
I know you're intentionally ignoring the real problem here: the fact that the major Linux distros have converged to the point where they're nearly identical. Worst of all, they've chosen to converge on software that exhibits a very anti-UNIX approach, such as systemd and GNOME 3.
Today, a modern Linux distro installation is closer to Windows than it is to anything resembling UNIX. The Linux userland has become a cheap imitation of Windows in so many ways, from the GUI down to the init and service management systems.
If you want a Linux distro that doesn't use systemd, you have a lot of options. But your complaint seems to be that that most of the Linux community has moved away from your preference. Well I'm sorry princess that you're not in the majority anymore, so either get comfortable in the minority, get your hands dirty with the majority, or do the work getting things exactly how you want them. But I'm not terribly sympathetic to your complaints if you're sad that the rest of the world isn't 100% empathetic to your desires, sparing you from the work of making your own perfect distro to your preferences.
At least I can understand the systemd complaining, because most distros don't support sysvinit or upstart anymore. But I really don't get the GNOME 3 bitching. I hate it just as much as you do, but literally every single one of the big distros (so that's Ubuntu, Fedora, openSUSE, Debian, CentOS, Arch and Gentoo) support alternatives.
Re: (Score:2)
What we actually see is that the Linux distro maintainers have moved away from the preference of the Linux community.
That's why there has been such a huge uproar about systemd. Systemd is not what Linux users want. It's what Red Hat wants.
As we saw from the debacle around forcing systemd into Debian, systemd may make the maintainers' lives easier, but it absolutely ruins the Linux experience for the users.
People using a Linux distro in the first
Re: (Score:2)
The usage statistics of all the major Linux distros and the financials of the major Linux companies (Red Hat, IBM, SUSE, Oracle, Canonical) don't seem to suggest that at all.
I see a lot of anonymous cowards on Slashdot being loud against systemd, but in the real world it's just another tool that people use, no different than the GNU utilities or APT.
The same anonymous cowards are proclaiming some kind of exodus to the BSDs, but their usage statistics don't really support that either.
Re: (Score:2)
I see a lot of anonymous cowards on Slashdot being loud against systemd, but in the real world it's just another tool that people use, no different than the GNU utilities or APT.
I'm not an AC and I'm actually in agreement with most of the people against systemd for reasons that have already been discussed ad nauseum.
Does SysVinit need to be updated or replaced? Probably, depends on what you want or need. Is systemd the answer? Oh, hell no. There are plenty of other alternatives that don't risk breaking the system to the extent that systemd does.
I'm pretty sure that the only reason systemd got off the ground is because GNOME3 required it. It is the epitome of "dependency hell".
Re: (Score:3)
Re: (Score:2)
At least I can understand the systemd complaining, because most distros don't support sysvinit or upstart anymore.
That's just horseshit, distros still support SysV init. Why are you still recycling these lies, even after they've been refuted again and again?
No, package dependencies don't mean you have to use it, it means that it will be installed because nobody competent actually has a use case for removing the dependency and managing the extra packages. (Just pre-empting the usual follow-up lie)
Re: (Score:2)
At least I can understand the systemd complaining, because most distros don't support sysvinit or upstart anymore. But I really don't get the GNOME 3 bitching. I hate it just as much as you do, but literally every single one of the big distros (so that's Ubuntu, Fedora, openSUSE, Debian, CentOS, Arch and Gentoo) support alternatives.
Support is a vague term. I've used Debian with several desktop environments. XFCE and Cinnamon don't have near the polish that was put into GNOME 3. It's clear Cinnamon on Debian is an afterthought. Supported, and that's where it ends. The Debian team put most of their effort into GNOME
Conversely, Cinnamon on Mint is wonderful. It's clear the Mint team put a lot of time and effort towards making it a great experience.
Re:You're making up contradictions that don't exis (Score:5, Informative)
Old does not mean bad.
Slackware is old, but certainly not a relic. And boasts a stability track-record that most other distros simply do not match. It not only adopts the unix philosophy, but embraces it so fully that the only comparable distros to it in this regard that I know of are Arch and Gentoo. Gentoo is a bit of a bitch because you have to compile everything, which can take a long time when doing system updates, and Arch is regretfully somewhat less stable than Slackware because it updates its packages so frequently (although if you are willing to risk some stability in the interests of running the bleeding edge versions of all available packages, Arch might be right up your alley).
But slackware is still being actively maintained, despite having longer release cycles than most other distros. Slackware is at a release candidate stage for 14.2 in slackware-current at the moment, and I'd be honestly quite surprised if 14.2 wasn't released sometime this summer or fall.
Re:You're making up contradictions that don't exis (Score:5, Interesting)
Disclaimer: I've been using Gentoo since 2002/2003.
I agree that Gentoo's build process is cumbersome, especially on slower processors. This is a lot less of an issue now as compared to when I started using it in '02/'03, when I probably had five-year-old hardware then. Larger packages like Firefox and LibreOffice have always had a binary package to install. (On my 2002-era machine libreoffice would take something like 9 hours to compile.) My machine now, which is around 8 years old compiles this same package in a bit over an hour.
However, Gentoo also has another huge benefit, and that is customizing packages to your needs using USE flags. These toggle build-time options, so as an example, when heartbleed came out I was able to remove the offending tls heartbeat component using a USE flag and rebuild the package until a fix was made available.
Another thing I've discovered is if you have similar hardware and similar configurations you can tell portage to build binary packages. If you share this directory via nfs export you can instruct portage to favour binary packages when all use flags and other build-environment options are the same. This has saved my poor celerons on my MythTV frontends quite some compile time.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Someone collects links here: http://without-systemd.org/wik... [without-systemd.org]
Re: (Score:3)
Re: (Score:2)
What's wrong with Slackware? They usually have a yearly release cycle (little behind right now, but it's in RC stages), regular security patches, easy to install software, releases ship with updated kernel, KDE and XFCE for desktop users, plus the collection in slackbuilds as an extra software repo - all the power is in your hands. The only thing that I'm not sure about running on Slackware is Google Chrome - I didn't try when I was running Slackware, but I did have Chromium installed.
Also, snaps don't se
Re: (Score:3)
Ever try Gentoo? or Funtoo?
Re: (Score:2)
This. Gentoo's Portage is modelled after BSD Ports, and it follows a minimalist unix style in many other ways. At the same time, it uses the GNU userland on the Linux kernel for a much better hardware and software availability. And no, it doesn't use systemd by default. As a side effect of the compilation thing, Gentoo is a nice environment for developers [iki.fi].
Re: (Score:2)
Re: (Score:2)
Here ya go Snowflake... http://www.linuxfromscratch.or... [linuxfromscratch.org]
I Like Apt (Score:5, Informative)
In fact, that model works so well, Apple and others now use the same model. They call it an "App Store". I've even heard rumors that Microsoft wants to switch to this model
So, why is Linux going back to the old, and inferior way of doing things?
Re: (Score:2)
I still prefer the idea of static build executable. Shared libries while a good idea doesn't work well for lesser known libraries.
Re: (Score:2)
I've even heard rumors that Microsoft wants to switch to this model
Do you mean the PackageManagement module that comes standard with Windows 10/Server 2016?
It's kind of a package manager manager. It's a set of simple commands that let you add and use different package managers ("Providers") and their repositories ("Sources"). They all manage dependencies and whatnot in their own way, but it seems like a nice start.
Chocolatey is the provider with a lot of bread and butter FOSS and even MS binaries you might be looking for. For instance, you can install 7-zip, FreeMind, or
Re: (Score:2)
The repository system is so much better. No more worrying about compatibility, or someone adding malicious software to my programs.
Any software you install is potentially malware or contains an exploitable bug -- all it takes is one to slip through. As it stands now, on a typical Linux distribution when you run a program it has full access to all of your account.
Linux really needs to move towards "app" models where the programs are self-contained and explicit permissions are required for sharing. This is a step in that direction -- though I haven't looked at the details as to how good it is.
Re: (Score:2)
...because it has a niche role to play that you don't ever have to use if you don't want to.
Just like systemd!
Re: (Score:2)
...because it has a niche role to play that you don't ever have to use if you don't want to.
Just like systemd!
While it's true that you don't have to ever use systemd if you don't want to (as mentioned above, you can use Slackware, Devuan, CRUX, Gentoo, and others), they're really not comparable. systemd logically has to replace some other init system, so it's not a niche tool at all. On the other hand, Snappy Core is meant to complement other packaging systems, not replace them.
Re: (Score:2)
Re: (Score:2)
Many Linux and OSS contributors today are under 25 years old.
Do you have a single citation for that? And not some Stack Overflow survey, I mean the people who make decisions at Canonical, Debian, Red Hat, etc.
Re: (Score:2)
Re: (Score:2)
Clickbait headline... (Score:5, Insightful)
2) As TFS indicates, Snaps can coexist with all the other packaging tools (apt, dnf, yum, zypper, slapt, portage, pacman, etc.).
3) A large percentage of the Linux community are [a] too suspicious of Canonical to ever adopt any of their technologies and [b] conservative to the tried-and-true methods of doing things. apt will probably live forever on account of that.
Re:Clickbait headline... (Score:5, Insightful)
I don't know if I agree with point 1. SNAPS (as a concept) should be better for third party apps because the APP as it is packaged, now imports all of the libraries it needs. The downside of course, l is that if some library has a security issue, you must wait for the package maintainer of each SNAP app that contains it to do the update.
Re: (Score:2)
And there is the issue, we can barely get package maintainers to support their regular apps with many "apps" being hopelessly out of date on various standard platforms (try anything: Sympa, Drupal, MySQL, nginx, Apache, PHP... - you'll be several point versions if not major version numbers behind the 'stable' version available from the original websites).
Re: (Score:2)
you'll be several point versions if not major version numbers behind the 'stable' version available from the original websites
Unless the original website is providing the 'snaps'. I run several vendors' yum repos, preferentially to the distros' versions of their app. It gets updates when needed, not when an additional volunteer has time to look at it.
Re: (Score:2)
Particularly since the whole advertised benefit is you don't have to keep up with the distro, mr. app developer. Which means you are explicitly trying to attract folks who are almost certainly *also* too lazy to keep up with CVEs and such. At least with dynamic linking, you have some *hope* of fixing lots of app problems externally without the app maintainers specific attention... here....
Re: (Score:2)
Particularly since the whole advertised benefit is you don't have to keep up with the distro, mr. app developer. Which means you are explicitly trying to attract folks who are almost certainly *also* too lazy to keep up with CVEs and such. At least with dynamic linking, you have some *hope* of fixing lots of app problems externally without the app maintainers specific attention... here....
I also imagine that I would need to check my system *and* all the snaps for CVE updates, rather than just the system. I look forward to telling my manager and/or customer that the system is mostly up-to-date, except for snaps and having to track down those separate developers to get things fixed. Perhaps fine when it's against an app, but not so much when against libc. (sigh)
Re: (Score:2)
Maintainers would be a lot more motivated to fix their dependency issues if its trivial to fix (across all architectures/OS's). It also means that my Xyz app doesn't need an Ubuntu maintainer, Fedora, Mint, etc... or even if they did, the surface area becomes significantly smaller. For what its intended for, it seems pretty great. This all assumes near universal Linux distro adoption, but I like it in concept.
Re: (Score:2)
Snaps are really better for things like Chrome, third party applications that don't want to screw with actually following the distribution roadmaps. They are specifically architected to provide for mobile 'apps' to attract developers that are too lazy to keep up with distributions (btw, that would also mean too lazy to keep up with security vulnerabilities, by and large). On the server side, if you are still worried about 'downtime' in a way that any single system can impact, you are almost certainly doin
Whatshisname's Law says... (Score:3)
...that the answer to any question posed in a headline is "No".
I'd be all for a single consistent package management system for Linux that everyone could get behind. This isn't that. This is just a third option everyone's going to have to deal with.
Snappy Appy APP! (not the app guy) (Score:3)
Et tu, Gentoo? Then fall Linux
Snapd seems to be spreading with the same wildfire potential that systemd did. I hope I'm cringing over nothing in this case and snapd will only be an optional package management system (so far it sounds like it). But I'm leery. Systemd fractured a lot of distros with the "my way or the highway" attitude they had over it. I managed to avoid it on my servers where just about everything run on it right down to the compiler time sharing are background user processes. If even more distros move on pushing snapd in the same way it may finally be time for me to look into one of the Beasties to migrate to... either way, there's going to be a lot of workflows that will need analysis for migration one way or the other.
Re: (Score:3)
Snappy Core used by itself has a lot of disadvantages to apt, yum, etc. so it likely won't replace any of them (ignore the clickbait title). However it can be used well in parallel to them.
Re: (Score:2)
"Wanting to support" something and "accepting it because upstream is shoving it down your throat and forking is too much work" are two different things.
Re: (Score:3)
"Wanting to support" something and "accepting it because upstream is shoving it down your throat and forking is too much work" are two different things.
What's the "upstream" here? The only case where that seems to apply is Ubuntu switching from upstart in order to stay in sync with Debian. Fedora, openSUSE, Debian, and Arch all decided entirely of their own volition.
Re: (Score:3)
They made Gnome dependent on systemd which pushed it on the distrobutions.
Re: (Score:2)
There is a myriad of other Debian offshoots besides Ubuntu. Ubuntu has its own ecosystem, but just about all the others are stuck with whatever crap the asshats at Debian may decide on a whim to pollute Debian with.
Re: (Score:3)
Not really ... it was pushed to AUR which anyone can do and is in COPR like anyone can do.
No one from the Fedora side has worked on this, the Canonical employee who has that COPR is not a Fedora packager and the various desktop communities have been coordinating on Flatpak
I'd strongly suggest never taking a Canonical Press Release at face value given the recent history with them...
"snapd"? (Score:3, Funny)
We all know this technology won't really be mature until "snap management" is fully subsumed and integrated into systemd, where it belongs.
Re: (Score:2)
snapd, systemd, that's what I thought too.
Said without irony. (Score:2)
Said without irony.
Re: (Score:2)
I think there's also Steam, right?
Comment removed (Score:3)
Re: (Score:3, Insightful)
And i think i speak for us all when I say I'll be in the cold cold ground before i ever trust some bull-shit packager repository more than portage. Shuttleworth can eat my ass like groceries.
I don't understand the hostility. Canonical developed a new tool for you to use if you want to, for free (as in both beer and speech). Nobody is taking portage away from you.
Re: (Score:3)
I think it's a lot of paranoia related to the systemd controversy. Before that, things that people might have bitched about could be used or ignored at will. systemd, being a pretty core init system is something people couldn't easily step away from as an individual choice (unlike, say, desktop environments). Now *every* thing that could *conceivably* be construed as 'core' is going to be regarded with more worry than before.
Comment removed (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Insightful)
Re: (Score:2)
Yeah. I don't know which is stupider, the stupid headline, or the stupid blockheads who are running terrified in circles moaning "oh noze they are taking away apt".
Re: (Score:2)
This just sounds like yet another shitty reinvention of wheel idea with YOLO douchey distro dev backers that I'm going to see take over yet another great part of Linux distro's as we know it --- I thought enough was enough with systemd.
It's things like this that make me think Linux on the desktop peaked in 2010. Everything has been downhill since.
Where is Microsoft? (Score:2)
We don't even have anything as capable as apt and yum. Meanwhile Linux is moving ahead even further.
What restricts them? (Score:2)
"confines them into their own restricted space"
I'd like to know more on this. What restricts them? Are they, like, restricted by SE Linux to only act in their own little space, or is something outside the kernel doing this restriction? Whenever I hear about these types of access control, I always get concerned. All these sandboxes and jails have ways out of them normally, and the more obscure, the longer they wait, and their mere existence and claims makes people trust the supposedly protected applicati
Re: (Score:2)
In theory AppArmor ... except confinement only works under Mir ...
And as for the cross distro stuff in the PR statement? The Arch build disables the confinement tech (since it's a Canonical special and not upstreamed) and the Fedora COPR in addition to that only "works" with selinux not enforcing.
Weren't there security problems? (Score:2)
I seem to recall a big panic over some fundamental security flaws in Snaps, something about them leveraging the worst ways X11 is written. Unless it's some convoluted way to try and progress what seems to be the IPv6 of the display server world (Mir / Wayland), isn't spreading this thing to other distros a bit of a bad idea?
Re: (Score:2)
You recall a kerfuffle over the fact that if you use X11 on a system you are no more secure than X11 is (which is to say, not very). Snaps do not allow one single system-wide X11 server, so that particular flaw is avoided.
Snaps are apps? (Score:3)
That run in some sort of 'restricted' space? Fine. But what about all the other components of a Linux distro that aren't apps, can't run in a restricted space and will never be ported to the Snap model?
I think apt, yum and their kin will be around for a long time. Snap sounds like an environment written for people like the ones that thought Microsoft Windows Metro apps would be all that users would need.
So - it's like .dmg files for Linux? (Score:2)
I could get behind this for some programs - especially games.
It might be a little space-wasting for "core" stuff.
Re: (Score:2)
Re: (Score:2)
So are snaps more powerful, or faster, than what we had before?
If not, your analogy breaks down.
Re: (Score:2)
You don't want to switch. Nobody is saying use Snappy Core exclusively, it's not designed for that.
The "adios" in the headline would seem to imply that as a rhetorical, at least.
Its main purpose is for servers that require zero downtime, where you want to upgrade application X and/or its dependencies without breaking even the smallest functionality of application Y.
... -_- No server "requires" zero downtime. Anyone who put that into a req. document should be shot. You get more 9's by duplicating and providing physical, logical, and temporal redundancy. And we've gotten high redundancy for servers just fine using RPMs, thanks. (And .deb's, I assume.) Acting like there are no solutions out there is ludicrous. But then, a lot of the last six years of Linux-land have been like that.
Re: (Score:2)
The headline is spectacularly stupid. Nobody but nobody thinks that every package will/should be a snappy. It's basically a way to get some package here and there installed when it is not convenient to try and get a whole pantload of dependencies installed - perhaps because these dependencies as shared libraries might then conflict with some other packages you have.
I see it as less needed for a bleeding edge rolling distro like A
Re:Why switch? (Score:5, Insightful)
Its main purpose is for servers that require zero downtime, where you want to upgrade application X and/or its dependencies without breaking even the smallest functionality of application Y.
I disagree, snapd is Canonical's attempt to bring an android/ios like 'app universe' to their linux OS. Unfortunately if it succeeds, I also forsee it bringing the in-app advertisements and micro-payments mess :(
Re: (Score:2)
Its main purpose is for servers that require zero downtime, where you want to upgrade application X and/or its dependencies without breaking even the smallest functionality of application Y.
I disagree, snapd is Canonical's attempt to bring an android/ios like 'app universe' to their linux OS. Unfortunately if it succeeds, I also forsee it bringing the in-app advertisements and micro-payments mess :(
There will only be in-app advertisements and micro payments if the developers put them in. If they do so, blame them, and not the format of the package they decided upon.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Dynamic linking is for the weak!
It is hilarious, once upon a time it was commonplace for *every* library to be available static linkable and dynamic linkable, and the toolchain would have a simple flag to let the build decide if it should produce a static or dynamic binary.
They decidid this was a 'harmful' approach and by and large the toolchains removed the easy way to statically link things to force dynamic as it was seen as better.
Now you have snappy and singularity and go... all saying 'screw dynamic li
Re: (Score:2)