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

Tue Sep 2 18:02:22 EDT 2014

This seems pretty cool to me. It would require a lot of cooperation; kind of almost a pipe dream scenario. Could this really happen?

Date: Tue, 2 Sep 2014 16:53:51 -0400
From: kb at 2bits.com
To: kwlug-disc at kwlug.org
Subject: Re: [kwlug-disc] What is all this about systemd?

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

_______________________________________________
kwlug-disc mailing list
kwlug-disc at kwlug.org
http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20140902/6e16ba27/attachment.htm>