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

[Khalid Baheyeldin]

On Tue, Sep 2, 2014 at 4:02 PM, Chris Irwin <chris at chrisirwin.ca> wrote:

> On Tue, Sep 2, 2014 at 2:55 PM, Khalid Baheyeldin <kb at 2bits.com> wrote:
>
>> Lennart Poettering, systemd developer, outlines what he (and others in
>> the systemd cabal) see as wrong with Linux distros, and what they propose
>> to fix it.
>>
>> They totally miss that packaging has been a solved problem for ages
>> (since .deb was invented), and that centralized repositories have existed
>> for over a decade (Debian, Ubuntu).
>>
>
> They mentioned deb, rpm and distro repositories in the second paragraph.
> He even says "For a variety of uses this is a fantastic scheme: users have
> a large selection of readily packaged software available, in mostly uniform
> packaging, from a single source they can trust."
>

He says: "Many users are used to app markets like Android, Windows or
iOS/Mac have. Markets are a platform that doesn't package, build or
maintain software like distributions do, but simply allows users to quickly
find and download the software they need, with the app vendor responsible
for keeping the app updated, secured, and all that on the vendor's release
cycle."

How is that different from someone using an Ubuntu variant since 2008, and
using "aptitude search ..." and "aptitude install ...", or their GUI
equivalent?

Maybe because Lennart works for RedHat and the concept of a central
repository with everything in it is not so common?

Moving on, their arguments of trying to get an upstream-to-user channel
> don't sound too crazy. I recently wanted to update LibreOffice. On their
> website, they have Windows, OSX 32 and 64, Linux 32 and 64 in both rpm and
> deb. Great that they've got packages, but it's four different downloads,
> that then need to be untar'd, the `yum install *rpm`. And it doesn't even
> provide updates. Try walking a user through that. Or tell the user to cross
> their fingers that somebody will have the time to package it (or even
> better: Just wait, Ubuntu 14.10 will have it).
>

The lesson I learned over the years is: stay with the whatever is in
Ubuntu/Debian repositories, even if it is a tad older. You have all
dependencies taken care of, and you get security updates.

If you need to deviate from the above rule, it has to be for a very good
reason (e.g. a crucial functionality that you or your client needs), and it
has to be weighed against "you own it now, you update it".


> Similarly, Java is 32 or 64 in both rpm and tar files (no deb). Out of
> luck for Debian/Ubuntu. But luckily, somebody will have duplicated the
> effort of re-packing java into one of Ubuntu's repos somewhere, and
> hopefully they don't lag too far behind upstream.
>

I have OpenJDK 7, 64bit, on my laptop running 14.04. It is from the
repository, I did not need to do anything special, nor go on a hunting
expedition to find version/architecture/package-format ...

# aptitude show openjdk-7-jdk
Package: openjdk-7-jdk
New: yes
State: installed
Automatically installed: yes
Multi-Arch: same
Version: 7u65-2.5.1-4ubuntu1~0.14.04.2
Priority: optional
Section: java
Maintainer: Ubuntu Developers <ubuntu-devel-discuss at lists.ubuntu.com>
Architecture: *amd64*
Uncompressed Size: 20.6 M
Depends: openjdk-7-jre (= 7u65-2.5.1-4ubuntu1~0.14.04.2), libc6 (>= 2.2.5)
Recommends: libxt-dev
Suggests: openjdk-7-demo, openjdk-7-source, visualvm
Breaks: openjdk-7-jdk (!= 7u65-2.5.1-4ubuntu1~0.14.04.2)
Replaces: openjdk-7-jdk (< 7u65-2.5.1-4ubuntu1~0.14.04.2)
Provides: *java-compiler, java-sdk, java2-sdk, java5-sdk, java6-sdk,
java7-jdk*
Description: OpenJDK Development Kit (JDK)
 OpenJDK is a development environment for building applications, applets,
and components using the Java programming language.

 The packages are built using the IcedTea build support and patches from
the IcedTea project.
Homepage: http://openjdk.java.net/

Chrome has the same selection as Libreoffice, but *does* provide updates
> once installed.
>

On Ubuntu, I use Chromium (close enough), and it updates using the deb
mechanism. I just got an update for Chromium today:

===
The following packages will be upgraded:
  chromium-browser chromium-browser-l10n chromium-codecs-ffmpeg-extra
firefox ...
===

This has been an ongoing discussion topic for years. Ubuntu's solution is
> their store: Essentially vendor PPAs that only work for Ubuntu.
>

Or once you add the repo for that vendor, you get the same update mechanism
seamlessly. You even forget that you added a repo one day.


> What if Fedora had their own store? Suse, Arch, etc?
>

Why is that odd? They use a different package format anyway, so they can't
unify their repo with Ubuntu/Debian for example.

How many upstreams can properly support that many distros and package
> systems. That's just putting them back into the same boat they are now: How
> many distros can you package for, and at what niche-level do you not care
> about users anymore?
>

Which goes back to the package format fragmentation, rather than the
central store paradigm.

If RedHat had adopted Debian back in the day, we would be better off now.
But that also goes for many things in our community, e.g. KDE vs. Gnome,
...etc.

There's also the entire eco-system of user-run PPAs to get up-to-date
> software. You've got PPAs of "up-to-date chromium by some guy" that hasn't
> been updated in a year,
>

You know the risk of using random Joe Linuxer's PPA.

But you don't need to use that, because Chromium is in universe.

Again, if you configure an additional repository, you'd better know what
you are doing, and what are the risks. Mostly stuff works. I have Opera,
Skype, Viber, and have used additional repos for Google Talk, Varnish,
MariaDB (broke dependencies once).

ditto for gnome, etc. I'm even using the equivilant on Fedora: rhughes
> gnome-3.12 copr. I generally like COPR/PPAs, and I've even repackaged
> software myself, but there should be something in-between having to compile
> or re-pack tarballs and depending on some third party to package things
> nicely.
>

I don't use Gnome, so can't comment here. I did have issues with KDE when
they moved from 3.5 to 4.x, and non-LTS releases were too broken that I
wanted to move off KDE totally. Once I upgraded to the following LTS, the
problems were gone, and I stayed with KDE because I have been using it for
so long ...


> Some of their ideas are pretty cool, too. Using btrfs dedup to provide a
> 32/64-bit hybrid OS and app bundles is pretty clever. Snapshots for
> version-rollbacks is nice, too. I've been using btrfs snapshots before yum
> updates, but it would be neat to roll back only a specific app.
>

All that is good, except for eliminating choice.

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.
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
Fast Reliable Drupal
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
For every complex problem, there is an answer that is clear, simple, and
wrong." -- H.L. Mencken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20140902/5f806cd9/attachment.htm>