Re: [SCIENTIFIC-LINUX-USERS] Snap - the better,higher,faster etc

[Tom H]

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

Fwd: Re: [SCIENTIFIC-LINUX-USERS] Snap - the better,higher,faster etc

[Hans Kristian Rosbach]

On 06/18/2016 08:33 PM, Nico Kadel-Garcia wrote:


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.


I just love maintaining servers running software that bundles its own
libraries, often using libraries or java several years old, with no
security patches since then. The application works, so the developer
does not want to spend the time updating the libraries. When prompted
to do so, citing security vulnerabilities, I have often heard they have
it on their todo-list for the next 6 months, yet a year later nothing
has been done.

Unfortunately this is the sad case with several expensive commercial
programs, whether running from /opt, in docker or in a VM.

So, from a developers point of view it is great, but from a sysadmin
pov it is often hated and can result in a need for more strict security
measures on and around that server.

I know well the complications of updating system libraries, and we
have to maintain a repo with quite a few nonstandard rpms to achieve
features not otherwise available in SL.

What would be nice is a better separation of libraries in packages,
take mysql-libs for example. It contains more than just the libs, and
thus installation of mariadb-libs will conflict even though the libraries
themselves do not conflict. That means workarounds is needed to solve
something that should not even be a problem.
A worse problem is openssl, since EL7 still does not support ALPN and
google recently stopped supporting NPN for HTTP2 in Chrome.
We maintained a modified openssl rpm for SL6 for similar reasons,
but for SL7 we'd really like to avoid that. So we are currently looking
at BoringSSL as an alternative.

--
  Hans Kristian Rosbach
  Raske Sider AS

Re: [SCIENTIFIC-LINUX-USERS] Snap - the better,higher,faster etc

[Max Linke]

On 06/17/2016 11:45 PM, Pat Riehecky wrote:



On 06/17/2016 04:40 PM, Andrew Z wrote:


I understand it is very lame to refer to a technical article on
cio.com . and yet I'll try :)

http://www.cio.com/article/3085079/linux/goodbye-rpm-and-deb-hello-snaps.html

I never heard of it and just wonder how much of real value is in this
new system.



Related LWN : http://lwn.net/Articles/691309/


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.


best Max

Re: [SCIENTIFIC-LINUX-USERS] Snap - the better,higher,faster etc

[Pat Riehecky]

On 06/17/2016 04:40 PM, Andrew Z wrote:


I understand it is very lame to refer to a technical article on 
cio.com . and yet I'll try :)


http://www.cio.com/article/3085079/linux/goodbye-rpm-and-deb-hello-snaps.html

I never heard of it and just wonder how much of real value is in this 
new system.




Related LWN : http://lwn.net/Articles/691309/

Snap - the better,higher,faster etc

[Andrew Z]

I understand it is very lame to refer to a technical article on cio.com.
and yet I'll try :)

http://www.cio.com/article/3085079/linux/goodbye-rpm-and-deb-hello-snaps.html

I never heard of it and just wonder how much of real value is in this new
system.