Future and impact of ongoing projects in Linux world

Xen list at xenhideout.nl
Thu Oct 6 14:18:03 UTC 2016


Colin Watson schreef op 05-10-2016 21:44:
> On Wed, Oct 05, 2016 at 04:23:38PM +0200, Xen wrote:
>> Oliver Grawert schreef op 05-10-2016 14:41:
>> >along with that click packages are user packages and being used in
>> >ubuntu products on sale since 2015 (snaps will replace them
>> >eventually).
>> 
>> That just means a user can install them, not that they are installed
>> specifically for a user?
> 
> Not so; click packages may be installed (technically, "registered")
> specifically for one or more users.  The process is mediated by a 
> system
> facility, certainly, but it can be per-user.  (It's also possible to
> register them for use by all users, which is roughly equivalent to a
> system-wide installation.)

I understand that there can be good reasons for this yes.

> The reason for it to be mediated by a system facility was so that ten
> users all installing the same click package don't end up using ten 
> times
> the storage.  Not very interesting on a single-user phone, but
> potentially interesting on e.g. a multi-user tablet and would have been
> pretty important if click packages had ever made it to the desktop in a
> big way.

In principle all of this is good idea. The issue I have with it (in 
principle) is that they are high level solutions to things that do not 
yet have low level solutions.

What I mean is that you craft some functionality and then you limit its 
use case, e.g.

Say you write some script (as I have done) to forcibly close all open 
handles to a filesystem. Your script can operate on any kind of device; 
on plain volumes as well as device-mapped ones. However now you restrict 
the functionality to only work on device-mapped volumes. And then you 
further restrict it to only work on LVM, as that is your use case.

Now you find a need to force-close an encrypted volume with a plain 
filesystem in it, and you can't do it (anymore).

Because the functionality is there but it does not comply with the 
target: it is no logical volume.

Oops. Now suddenly you are screwed and you have to dig in your script to 
find the required calls to other programs to enable the functionality 
runtime for your specific use case now in this moment.

This is what I mean by having high level functionality as a solution to 
a problem that should have been solved at a lower level prior to this. 
Now we have snaps (or clicks) and they do something everyone wants but 
not everyone wants snaps (or clicks). They contain functionality 
everyone wants as a lower level thing but because the thing has been 
entirely tailored for Ubuntu or even tablets perhaps, other people can't 
use it.

For example....

You see it already but.

The deduplication is a good strategy for the use case described. But it 
also involves system-wide installation as per the strategy and the 
solution wanted. But /in principle/ the same functionality could also 
simply be realized for a very simple system where some random user just 
puts a package file in his home directory and she then mounts it like 
you have and can access the program without any system-wide things 
(loopback mounting must be supported for a user without priviledges).

It would be the smallest possible solution to the problem. Once you have 
that as a building block (as I had with my script, but chose to throw it 
away), you can construct your high level solution easily on top of that.

But since we present or provide a complete solution to our users and 
nothing other than that, it is take it or leave it.

And so some take it and some leave it but there is no middle ground for 
them.

Add to that the fact that your mount output (/bin/mount, no parameters) 
is now getting polluted with EVERY app you have installed.

It is already impossible to use because of all the cgroups and other 
crap, but now it is getting worse even ;-).

Actually (it is much better than the cgroup crap because this at least 
has some meaning to the user).

Regards.




More information about the Ubuntu-devel-discuss mailing list