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

Tue Sep 2 21:55:07 EDT 2014

In general, I find this to be true of any distribution.  For Linux Mint,
stick with the Linux Mint repositories provided. Same for Trisquel, and
even Debian itself.

unsolicited wrote:
> Reading most of it, I'm getting an itchy feeling on the back of my 
> neck that their real goal is to permit commercial / proprietary /
> for pay core packages to seep into today's distros.

Agreed. What is being proposed seems to me to increase the amount of
control exercised by the application vendor.  That's good when you
want to enforce library compatibility (dependencies), but bad in
almost every other way.

- --Bob.

On 02/09/14 04:53 PM, Khalid Baheyeldin wrote:
> 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.
> 
> 
> 
> _______________________________________________ kwlug-disc mailing 
> list kwlug-disc at kwlug.org 
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Ensure confidentiality, authenticity, non-repudiability

iEYEARECAAYFAlQGdPkACgkQuRKJsNLM5eqfWACg3kV4likutehD+cl5QyvmUWxr
l40AoPS3i0K0RBDv+vKgfe84TXkopq4j
=Nu5c
-----END PGP SIGNATURE-----