Why maintainers matter

[xenopeek]

Interesting article about the social impact of snappy packages: Maintainers Matter: The case against upstream packaging

While I think the technology behind snappy packages and alternatives like flatpak are very interesting the above article makes a good argument for why you want your packages packaged by your distro maintainer.

Linux Mint 18 will likely add support for installing snappy packages, though Software Manager and Update Manager continue to install software from the repositories of packages packaged by Ubuntu & Linux Mint maintainers.

[Cosmo.]

why you want your packages packaged by your distro maintainer.

As I do and already wrote 2 months ago, obviously not understood by some others, who used partly simply wrong facts as arguments against.

Linux Mint 18 will likely add support for installing snappy packages

Hopefully not. At least in the beta of LM 18 the package snapd, which is needed as prerequisite, is in contrast to ubuntu 16.04 not preinstalled. I wise decision.

[rene]

The article as a whole makes a number of good points, some lesser ones, but one thing that is fully missing from it is the case of non-opensource software. I have no quarrel with some closed-source software; some scientific software that I use, but also games for example.

Games tend to be scripted around an engine and are far too easy to change to for example make honest online multiplayer possible as open source. The engines themselves are moreover at times extremely involved pieces of software in a very competitive and generation-wise short lived field; a very commercial field. One moreover where "your right to change" seems not all that well-defined (even if on occasion your right to review would still be applicable).

I would expect that commercial closed-source software would be the primary user of snaps and I personally welcome (a bit) more of it.

[Ark987]

I believe maintainers should learn to make the system to work for them instead of working for the system.

I agree with most of what he wrote, the added value of maintainer is invaluable as an extra security layer. But I do believe that he is missing the bigger picture here.

What if... What if... all package maintainers from all distributions join forces to create this utopia of software repository for all distros. Join as a cross-community effort setup some sane rules and deliver user applications for all distros following a standardized process. This is an opportunity for package maintainers to become even more valuable for the community, they will become an independent and stronger entity. So yes! they matter so much! and I expect even more from them!

With universal packages we should be able to create an intermediate Linux Software Distribution that strip-out what makes the Operating System itself (drivers, kernel, etc.) and just deliver user applications and similar software.

Have you explored the .steam folder? Is a nasty place where you can find a folder named Ubuntu 12.04 and a lot of bundled crap anyway.

[rene]

Have you explored the .steam folder? Is a nasty place where you can find a folder named Ubuntu 12.04 and a lot of bundled crap anyway.

Precisely. Steam would be a primary use case for snaps. Even with all its bundling it does not for example manage to currently install onto a fresh Mint 17.3 system and work; you need to move its private libgcc_s and libstdc++ in ~/.steam out of the way due to its versions of those libraries conflicting with the by now quite old "trusty" base of 17.x.

That is the kind of thing that app packaging and sandboxing in the sense of snaps is designed to combat, and Steam is moreover the kind of application that many quite decidedly want on Linux; closed source or not.

[Ark987]

That is the kind of thing that app packaging and sandboxing in the sense of snaps is designed to combat, and Steam is moreover the kind of application that many quite decidedly want on Linux; closed source or not.

My dream scenario is that all distros agree on not packaging Firefox in their native format and let it be just an universal package. Officially tell end-users: this is the place where should get your software (Firefox). And then all maintainers just focus their energy in one single place to deliver the exact same thing to all distros.

[rene]

And then all maintainers just focus their energy in one single place [...]

Well, not all. Debian will fork it anyway due to the Non Free nature of, say, the lower-left corner of the bookmarks icon, but otherwise quite fully agreed, and I found it interesting to see Firefox featured as a primary adopter in the original post's second link. VirtualBox is another one I'm starting to be passionate about. Have like no doubt many here been looking at and testing Ubuntu 16.04 and the upcoming Mint 18 in VirtualBox and was presented all sorts of issues I did not want to deal with until I removed all trace of the standard repository version of VB from both host and guest and installed from the Oracle repository directly.

I find the article to mostly make a fair point with current app stores functioning as a spyware delivery channel to Windows and Mac users but as long as "we" manage to avoid that specific aspect I really quite welcome the direction this is taking.

[Ark987]

Debian will fork it anyway due to the Non Free nature of, say, the lower-left corner of the bookmarks icon

I understand that point but still I believe there are enough Distribution out there (not only Debian) that would be interested on a dedicated area of "Free Software Only".

One benefit of the universal apps is to have multiple version of the same software, why not have the vanilla version from the vendor and the Free Software (stripped out) version of the software. And still Debian and I suppose Trisquel, Parabola and the likes will also benefit. Well this are just dreams and speculation from my side

[rene]

In an adjacent thread I just now saw someone mention LibreOffice having a PPA;

https://launchpad.net/~libreoffice/+archive/ubuntu/ppa

and having also just spent some time coaching OpenOffice to correctly handle another one of those blasted Microsoft Word forms someone wanted me to fill out... shall we try and organize a forum-poll to say whether snaps either succeeded or failed at the point we see a Microsoft Office snap appear?

[rene]

This being a general chat forum anyway let me expand somewhat, because that was actually semi-serious. Microsoft Office already exists for Android and if snaps(-like) infrastructure catches on, I would indeed expect to see Microsoft Office enter the Linux application market.

Cost will offset some of it in the Linux-sphere but I do also expect that if it does, quite a few people will "snap it up" immediately. I would, having no patience or interest in dealing with office-app stuff plus many acquaintances having no patience or interest in dealing with me, and that is while I consider Microsoft's de facto office monopoly damaging. That, then, will likely spell the end of Libre/Openoffice and further cement said monopoly.

I've never been one for the Debian side of the force; entered here in a last ditch effort to hang on to the Linux desktop, but do in fact believe we may after nearly 20 years finally start to live in interesting times. Wayland plus systemd will make constructing a Linux system a matter of jigsaw-puzzling a kernel, systemd, GNU bash/utilities, Wayland and "a GUI", and snaps would distribute (some) application management on up to software vendors directly.

That seems to mostly leave said GUI to the distribution, and we may as such be experiencing the death of the current distribution. Of course, we may have done so many times before as well -- but at the moment a more perfect storm than has been usual for the life of desktop Linux does seem to be brewing.

[Habitual]

While I think the technology behind snappy packages and alternatives like flatpak are very interesting, and snappy packages are now supported on many distros, the above article makes a good argument for why you want your packages packaged by your distro maintainer.

Good read thanks.
You think the Owncloud reference is a poor example considering the changes there recently?

[MintBean]

Many people experience instances where they need or want a newer version of an application than is available in the repositories, or one that isn't available at all in the repositories. In the real world, a good solution to this is the use of PPAs and for me, Snaps are looking like a better option in these situations.

[Fred Barclay]

Great read! Thanks, xeno.
We should start a "Hug a maintainer campaign." What? No takers? Come on, mates.
Okay, well, we owe them a lot at any rate.

I personally will side with Linux's traditionally diverse user-experience here. All the distros are here to fill a purpose. Some of those may be only for one guy, or a couple of chaps. Some, like Debian, reach a huge audience and themselves are the base of many other distros. Some, like TAILS, are used worldwide but only for one specific purpose. And some, like Mint, are designed with the end user in mind.
There's no way this would be possible if a single format were enforced. The OSes that have a unified format tend to crush diversity and experimentation. Who suffers when this occurs? We all do.

[Ark987]

Many people experience instances where they need or want a newer version of an application than is available in the repositories, or one that isn't available at all in the repositories. In the real world, a good solution to this is the use of PPAs and for me, Snaps are looking like a better option in these situations.

Exactly, in addition to that the resulting Snap (hopefully) will work in any other Linux distro. However I don't see the point of ditching package/distro maintainers, somebody needs to package those snaps and ideally put them in a centralized repository, so basically we need another team of maintainers.
The only setback that I see is some license for distribute certain types of software, the vendors should just propose a solution, e.g.: https://www.adobe.com/products/players/ ... ution.html

All the distros are here to fill a purpose.

Err... aren't we talking about software distribution, I mean how many types of Gedit/Chromium/FireFox/VLC are they? Just take VLC as an example, Isn't VLC for Fedora (RPM) the same VLC for Ubuntu (DEB) or for Arch (PKG)?

Forking VLC into a new project is OK, but repackaging the same software 135 times just because each distro is different? What kind of results are you expecting from this experiment?

Insanity: doing the same thing over and over again and expecting different results.

[Fred Barclay]

Err... aren't we talking about software distribution, I mean how many types of Gedit/Chromium/FireFox/VLC are they? Just take VLC as an example, Isn't VLC for Fedora (RPM) the same VLC for Ubuntu (DEB) or for Arch (PKG)?

Forking VLC into a new project is OK, but repackaging the same software 135 times just because each distro is different? What kind of results are you expecting from this experiment?

But the distros install software to different locations, and have different libraries at different locations. Having software that can run on any distro would (usually) require major changes in all the distros to a unified file system and way of calling things. Not to mention the confusion that different versions of kernels/compilers/libraries can cause.

You'd have to enforce a pretty strict standard to the distros in order to guarantee software that would work anywhere as-is. Even Windows which is arguably much more unified than Linux has instances when you can't run the same software between two versions, like Xp and 7.

But yeah, generally, VLC is VLC is VLC. The exceptions would usually be when you compare VLC on a stable distro to VLC on a rolling distro--usually the stable distro will have an older version of VLC.

[Ark987]

But the distros install software to different locations, and have different libraries at different locations. Having software that can run on any distro would (usually) require major changes in all the distros to a unified file system and way of calling things. Not to mention the confusion that different versions of kernels/compilers/libraries can cause.

That's the whole point of Universal packages which provides isolation, a solution to those problems that you just mention.... Snaps, Flatapk, etc, does not require that Distros change anything at all, because the package provides everything in a sort of virtual container isolated from the rest of the system.

[Fred Barclay]

Oh, I see. I must have misunderstood something.

But doesn't that require your system to work harder? Or is it a security risk? I don't know why, but something just doesn't feel right!

[rene]

It can require your system to "work harder" if different sand-boxed applications load different versions of the same shared library, whereas currently they would all need to be compiled against the same version hence also load said same version only once (but note that if they in fact require the same version, that version is also still loaded only once).

With the other option being at least one of them not working at all lest it's recompiled, I'd say go for it...

[Ark987]

Afaik there are no performance issues reported so far, the only thing that is required is that distros start working together on this.

Look at the Xapps initiative by Clem, now put those in a snap package and now you have an app that is cross Desktop Environment and also cross Distribution.

Whats missing is the huge repo for this.

[xenopeek]

Oh, I see. I must have misunderstood something.

But doesn't that require your system to work harder? Or is it a security risk? I don't know why, but something just doesn't feel right!

It's a security risk. Instead of the security teams and package maintainers of your distro handling security (providing updates) for system libraries used by programs, those programs ship each with their own versions of the system libraries they need. So if a system library needs an update for a security issue, you'll have to wait for each of the programs that uses it (and that ships it own version of that library) to get around to providing you with an update. Hence the isolation of those programs becomes even more important (as most likely for many programs you'll never see such updates).

Have you explored the .steam folder? Is a nasty place where you can find a folder named Ubuntu 12.04 and a lot of bundled crap anyway.

Precisely. Steam would be a primary use case for snaps. Even with all its bundling it does not for example manage to currently install onto a fresh Mint 17.3 system and work; you need to move its private libgcc_s and libstdc++ in ~/.steam out of the way due to its versions of those libraries conflicting with the by now quite old "trusty" base of 17.x.

That is the kind of thing that app packaging and sandboxing in the sense of snaps is designed to combat, and Steam is moreover the kind of application that many quite decidedly want on Linux; closed source or not.

You can quite easily tell Steam to use your system libraries instead of its own. There are several ways: https://wiki.archlinux.org/index.php/St ... ve_runtime