SCIENTIFIC-LINUX-USERS Archives

June 2016

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Sat, 18 Jun 2016 14:33:55 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (60 lines)
On Sat, Jun 18, 2016 at 7:09 AM, Tom H <[log in to unmask]> wrote:
> On Fri, Jun 17, 2016 at 5:48 PM, Max Linke <[log in to unmask]> wrote:
>>
>> https://www.happyassassin.net/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/
>>
>> A good post giving a little bit of context for the actual snapy adoption by
>> other distributions. The pres release from canonical is a bit over
>> enthusiastic about adoption, security and how well received snapy is by
>> others.
>
> Isn't the point of a press release to oversell something?
>
> I'd take this article with a grain of salt - or even a few grains.

Put the salt on the mushrooms they've been serving. There was a
similar discussion recently on the Fedora development lists about
including "flatpak" for Fedora 24 or 25. Fedora is where bleeding edge
software for RHEL and thus for Scientific Linux is tested, so it can
be worth keeping an eye open over there for pending SL changes.

> 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.

> 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/rsolv.conf" with an
inconsistently managed symlink into systmed'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!!!!

> Ubuntu/Canonical (UC) 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.

ATOM RSS1 RSS2