On Sat, Jun 18, 2016 at 2:33 PM, Nico Kadel-Garcia <[log in to unmask]> wrote:
> On Sat, Jun 18, 2016 at 7:09 AM, Tom H <[log in to unmask]> 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?