SCIENTIFIC-LINUX-USERS Archives

July 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:
"James M. Pulver" <[log in to unmask]>
Reply To:
James M. Pulver
Date:
Fri, 1 Jul 2016 10:08:38 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (93 lines)
Isn't bundle all the system tools basically containers / Docker? Also 
Appimage? I personally am OK with a lot of disk usage if I can just 
download a file that's self contained and run it.

James Pulver
CLASSE Computer Group
Cornell University

On 06/30/2016 10:59 AM, Tom H wrote:
> 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?
>

ATOM RSS1 RSS2