<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 2, 2014 at 2:55 PM, Khalid Baheyeldin <span dir="ltr"><<a href="mailto:kb@2bits.com" target="_blank">kb@2bits.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">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.<br><br>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).<br>
</div></blockquote><div><br></div><div>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."<br><br></div><div>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).<br>
<br></div><div>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.<br>
<br></div><div>Chrome has the same selection as Libreoffice, but *does* provide updates once installed.<br><br></div><div>This has been an ongoing discussion topic for years. Ubuntu's solution is their store: Essentially vendor PPAs that only work for Ubuntu. What if Fedora had their own store? Suse, Arch, etc? 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?<br>
</div><div><br></div><div>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, 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.<br>
<br></div><div>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.<br>
<br></div><div>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.<br>
</div></div><br>-- <br><div dir="ltr">Chris Irwin<br><<a href="mailto:chris@chrisirwin.ca" target="_blank">chris@chrisirwin.ca</a>></div>
</div></div>