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.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
