[kwlug-disc] What is all this about systemd?

[Chris Irwin]

I'm not going to quote/reply the whole message (with one exception) 
because I think we're on the same page on some things (apt/yum is great 
and not going away), and on different pages on others (apt/yum is all we 
need). I don't think either of us is prepared to budge, so arguing 
specifics of chromium, versions, and distro-pacakgers is moot.

That said, I'd like to just clarify what I think the goal is, using 
android as a model -- since it's pretty similar I think, and we're 
hopefully familiar with it now.

Getting apps on android: google-play, fdroid, whatever. All use the same 
apk packages, and those packages work on any android phone or tablet, 
whether it's a samsung note running touchwizified android 2.3 or a nexus 
10 running stock 4.4. When there's an update, you don't have to wait for 
the next version of Android, or for a community packager. You get 
updates straight from the developer, through whatever channel you used 
to install it.

When you install an app, you're getting the *current* version, *from the 
developers*. It tells you what permissions it needs. It's restricted to 
those  permissions. There is functionality to individually allow/deny 
access levels, but for some reason isn't exposed on android. You can try 
out new apps from new developers on the day they're shipped if so 
desired. Their package can't accidentally have an `rm -rf / tmp/myfiles` 
in a post-install script.

Add the systemd-managed linux-namespaces, you could limit filesystem 
access, cap cpu usage, etc.

So I don't see this as a project to replace deb or rpm. I'd go as far as 
saying you probably *can't* run a distro with only software packaged in 
it's own isolated namespaces like that. And even if upstreams started 
supplying bundles, this isn't creating any *more* work for distro 
maintainers who build packages from source anyway.

But having distro-agnostic bundles sounds great to me for some software,


Note: I've also left in the quote & reply for the one security issue I 
see with the containers, since it's also applicable to android and osx 
app bundles, and I think is worth discussion if anybody wants to chime 
in (I don't have anything else to add on this topic)

>     The only issue I see, and this is a problem also in
>     OSX/Windows/Android, is how libraries are handled. If libraries
>     are part of the bundle, then updates (particularly security
>     updates) become a pain. If they aren't, you lose some of the
>     containerization that makes this such a great win for upstreams.
>     I'm sure further discussion will follow.
>
>
> If you install everything from the official repo, you never see 
> library dependency or version conflict. That has been my experience 
> running Ubuntu on the desktop and on servers for many years. The odd 
> exception here and there (local compile, or vendor repo) also mostly work.

The concern I have wasn't concerned about missing dependancies or 
version conflicts.

I was concerned with appabc bundling libxyz. When appabc+1 comes out, 
the bundle gets updated. When libxyz+1 comes out, that container would 
need to be updated also, even though the developer might not notice 
(everybody reads CVEs, right?). In the distro packages, the opposite 
would happen: libxyz would be updated (because security is rightfully 
important), but appabc will likely have to wait for the next major 
distro update. If you ask users whether they want a appabc or new 
libxyz, they'll say appabc. If libxyz is something like openssl, and it 
hits mainstream news, then users *might* care (even then it's not a given).

-- 
Chris Irwin
e: <chris at chrisirwin.ca>
w: http://chrisirwin.ca

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20140902/5a6cf723/attachment.htm>