On Sat, Jun 18, 2016 at 2:33 PM, Nico Kadel-Garcia <[email protected]> wrote: > On Sat, Jun 18, 2016 at 7:09 AM, Tom H <[email protected]> wrote:
>> The first that I heard of snaps being available on non-Ubuntu systems >> was on the fedora-devel@ list where the poster floated the idea of >> banning snapd because it might get a first-to-market advantage over >> flatpak, a more or less similar Red Hat and Gnome technology. > > Which got shot down fast as a bad reason to reject the software. Thankfully! >> It's interesting (and depressing) to see otherwise rational people >> lose the plot like this, just like many did regarding systemd or many >> are here in the UK regarding Brexit. > > Permit me to call "straw man argument fallacy" on this one. It was one > person on a mailing list, who was shot down very quickly. The many > reasons to dislike systemd's policies, practices, size, and creeping > featuritis are well documented and remain a risk. Take a look at the > threads when it tried to replace "/etc/resolv.conf" with an > inconsistently managed symlink into systemd's DHCP configurations, and > its more recent attempts to disconnect all background processes not > tied to a user session that are not directly managed by systemd. > > Shall we break remotely run tmux, screen, ssh-agent, and nohup based > long-running backgrounded tasks with no warning and no logging? What a > magnificent idea, let's break stuff without telling anyone!!!! My point about "losing the plot" wasn't just about the moron who wanted to ban snap/snappy/snapd or whatever the actual package is called. There wasn't even one positive thing said, there wasn't any fact-checking before saying "it sucks because of ...". It was an unending attack on the technology because it originated at Canonical and because it might pre-empt the use of RH's Flatpak. The technology was intended as Ubuntu-only and, if Canonical/Ubuntu are to be believed, people from other distros asked them about porting snaps so they did some work towards that. And then there was a premature press release... resolv.conf: IIRC, the problem was that if you weren't using systemd-resolved, you were left with a dangling symlink. Disconnection of background processes: The current solution's an OTT solution to what could easily be regarded as buggy Freedesktop and Gnome software. No one brought up during the fedora-devel@ discussion the possibility of creating a new systemd.special unit, logout.target, that would kill all the misbehaving processes like pulseaudio, evolution-*, ... at logout while allowing nohup & co to work as intended, as the upstream dbus maintainer suggested when he opened this can of worms. Whatever their other good and bad qualities, the systemd developers have a special talent for pissing people off. >> Ubuntu/Canonical created its own system for installing >> self-contained apps a-la Android and iOS. AIUI, these apps are >> confined on Ubuntu using AppArmor. >> >> According to Mark Shuttleworth, non-Ubuntu developers asked whether >> patches would be accepted to port snaps to other distros. So some >> work's been done and it's resulted in the press release and all this >> brouhaha. > > I'm extremely leery of any system that tries to "bundle all the system > tools" to run packages. It might be usable for containers, but it > presents real library and package management problems for deployed > such working environments. The approach is very familiar: it used to > be done with chroot a lot, it's more recently been done with docker > and Vagrant, and I don't see any compelling need for more such tools. There are people on this list who regularly ask about software that's more recent than what's in SL's repos. Snaps/Flatpaks would simplify their lives. AFAIK, Android and iOS apps "bundle all the system tools." Given how many of these phones are used in the world, isn't it enough of a proof of concept for you?
