Continuation.
C) "Issues and deficiencies:"
1. and 3. can be mitigated by the fact that the application does not
have to come straight from the author, but can also be taken from a
trusted software supplier (distribution or whoever) which builds it
itself. A binary bundle does not have to be closed source. Other than
that not much to add.
D) "General Ideas"
I have a slightly different picture here: the application lives in its
own directory hierarchy, AppFolder style. It does not know the absolute
paths of its files in advance, just their locations relative to each
other and notably to the binary file which is executed. I would highly
recommend that the layout reflected Linux and Unix standards relative to
the top-level application folder, which may but may not be "/usr". In
addition, operating system resources (possibly only those provided by a
sand box) are available at their usual absolute locations ("/usr/bin"
and so on), which may be the same as the application's private ones if
the application is e.g. installed via a distribution package. If a file
exists in the application's private hierarchy and in the system one it
would make sense to prefer the private version, but I see no need to
require this. Note that an application designed in this way should work
fine in the context described in the "Linux Apps" paper, with the
AppFolder further wrapped in an image file and loop-back union mounted.
Regarding the manifest files described, I would expect the application
to probe for required system resources and report which if any were
missing, but having the manifest file in addition would make sense in
the GNOME OS usage case.
Again, regarding X11 in a sand box, this can be done by running a
private X server in the sand box and proxying whatever is wished to and
from the main one. In my work time I am currently re-examining proxying
OpenGL in this way.
E) "App Images" and "Kernel D-Bus"
I think I have said everything relevant here already. Though from
personal experience of this sort of thing I have doubts about whether
kernel D-Bus over the current type will really provide as much benefit
as the paper suggests.
F) "Portals"
Sounds like an excellent idea, not least because the application would
not have to know whether or not it was in a sand box. That said, you
might look for ways to decide which files the application should have
read and write access to and find a way to make them visible in the
normal way in sand box. I am not familiar with Linux name spaces and
the other tools you intend to use, so I can't say how realistic this is.
It would be easy though for the application manifest to declare which
files it needs access to and for the person running it to allow or
disallow them.
G) "The Search Path Problem"
I would expect an application to interface with other applications on
the system in the usual Freedesktop way, with configuration files in
their folders - by default under /usr/share. Not saying that I love
this way, but that is just how it works now. On start-up the
application could check, more or less OS X-style, whether those
configuration files are installed globally and if not install them for
the current user. Preferably in a way which will not cause problems if
the application is deleted from disk. Applications which should be
startable from the command line could drop a script into $HOME/bin if it
existed or any decent alternative locations. A sand box could mirror
these configuration files to the global file system if appropriate.
H) "To Do"
Not really the bit which interests me. I am more interested in working
out how to do something with what is available now in a way that it can
easily be made to fit in with the GNOME OS infrastructure as it becomes
available (and existing distribution guidelines and more right now).
Hope that wasn't too much. I would not mind a bit of feedback.
Otherwise my plan is to write up my document with guidelines on writing
portable applications. Or rather most likely two, one general
guidelines and one a "cook book" of how to deal with specific problems,
which I hope people would fill out with their own experience, though I
think have enough to get it started. Can any one suggest to me what a
suitable place would be to host this?
Regards, and thank you for your patience.
Michael
On 06/07/13 08:14, Michael Thayer wrote:
After writing this I was too busy to follow it up myself until now -
sorry. I will run through the Linux Apps paper, commenting on each
point. I will ask straight away: would there be interest on the list
(there definitely is on my part) in my writing up a document with a set
of guidelines for creating portable binary applications based on the
current software stack? I would do this iteratively (though likely
somewhat slowly) based on feedback from the list. The guidelines could
be updated to incorporate GNOME OS components as they became available.
This message would probably serve as the basis for the document.
A) "We believe for a full Linux App solution we need six big changes:"
1) Sand boxes: it would be nice to keep sand box and application
logic as separate as possible, not least so as not to depend on Linux
unnecessarily. That means on the one hand that applications probe at
run-time for any system facilities they can use (e.g. the portal system
described in point 4)) which would make them work better in a sand box,
but not depend on finding them, and on the other that the sand box
implementation should be as generic as possible. As mentioned
previously, we have practical proof that X11 can be proxied through a
sand box without an application needing to being aware of this.
2) Loop-back image-based application solution: I personally prefer
the AppFolder style. It is clean, has less dependencies and it can be
made to work on current systems, including legacy ones, with only
minimal source code changes. Since this is mainly a FLOSS ecosystem I
do not consider that to be an issue. It would be good to have feedback
on this point as it would be rather central to the guidelines I am
planning.
3) Kernel-based D-Bus: this is more a sand box specific. As
mentioned, I would prefer to keep this orthogonal to applications and
focus on the application part, so not much to say here.
4) The "portal" system of privilege separation: I like the sound of
this, other than that see point 3).
5) See point 1). X11 can be made to work fine here, and making this
work better - notably making the mechanisms we use inside VirtualBox
more generic and usable in other contexts - is on my personal road map
(which my employer has definitely not committed to!) Nothing against
Wayland, just against making it a hard dependency at this stage.
B) "We accept the following changes from the traditional application
distribution model:"
1) Applications direct from vendors: I would personally prefer this
point to be softened to making it easier to get applications directly
from vendors, without requiring it at this stage. A particular point of
interest for me is for the guidelines to cover making applications
sufficiently flexible that a user can install and preferably run a
distribution packaged version and a vendor version in parallel, to make
it easier for distribution users to try out the latest version of a
piece of software when reporting bugs.
2) Libraries may be bundled: it follows from point 1) that this
should be a compile-time choice so that applications can easily fit
distribution requirements. It should be restricted to low security
libraries though, and ideally the mechanism for providing new versions
of applications should involve automatic builds on a well-updated (Linux
or other, as appropriate) distribution. Alternatives to static linking
are run-time loading of shared libraries with known reliable ABIs and
run-time use of system binaries, like say "ssh". Note that in my
experience pleasant GUI integration, at least with Linux and Solaris,
can be rather tricky this way due to the wide variance of installed
tool-kits.
3) Different applications using more or less stable APIs: partly
covered by point 2). Applications should ideally be able to probe for
and make use of what the system they are running on has to offer with
some flexibility to broaden the target base. The application developer
will decide though what they are targeting.
4) Target system profiles: I would prefer to leave this out of my
guidelines and let applications target these as wished by run-time
probing once they are available.
More to come...
Regards,
Michael
On 21/06/13 01:17, Michael Thayer wrote:
Dear List,
Alexander Larsson pointed me to the "Linux Apps" paper after I asked him
some questions regarding his "Glick2" project. I am sure you have had
no shortage of thoughts and feedback on the paper, but as that is the
price you have to pay for working in the public eye I would still like
to add a bit of my own from the perspective of a developer with some
experience of packaging out-of-distribution software on Linux, and some
interest in the subject.
An important point I would like to make is that many of the goals you
set in the paper are actually possible today. Usually in rather
inelegant ways, and perhaps not quite the way you envision them in the
paper, but possible nonetheless. You can create an app in the style of
an OS X application bundle. The app needs some way of finding its
resources relative to the executable. This can be solved without
mounting tricks, see "gnulib"[1] for example. Obviously this will not
work without modifying the programme source, but since I presume that
the majority of software you are targeting is either open source or
packaged by the author of the software getting modifications upstream
should be quite feasible. Again OS X-like, the app will need to be run
through the file manager the first time a user executes it (but since
they have just installed it by copying it that is not such a burden); on
first execution the app sets up any user-local search path directories
to point to it. For example (example, not recommendation), the app can
put a symbolic link to its icon in ${HOME}/.icons. And of course
application sand boxes can be done relatively transparently - as a proof
of concept from my corner (you would probably want to use a different
method in practice!) see VirtualBox in seamless mode, which works fine
for X11 applications - no Wayland needed here. (I realise that some of
our Guest Additions tools could do with some polishing; a better
seamless mode is on my personal to-do list, though with no date set for
completion. I hope to make the code as generic as possible to make as
much as possible usable in other sand box contexts.)
To make a long story short, as well as planning ways to make apps
possible in the future, it might make sense to catalogue best practices
for doing them now. That is a goal you could reach a lot faster, and
once you have such a catalogue and people start looking at it I suspect
that they will also start finding ways of doing it better now and start
fixing the bits of the system which get in their way.
I have quite a bit more that I could write, but this e-mail is already
long enough and it is getting rather late in this time zone. If the
list subscribers are not too annoyed at me yet (please let me know!) I
plan to follow it some time with a more detailed look at individual
points of the paper.
Thank you for your patience.
Regards,
Michael
[1]
https://www.gnu.org/software/gnulib/manual/html_node/Supporting-Relocation.html
--
ORACLE Deutschland B.V. & Co. KG Michael Thayer
Werkstrasse 24 VirtualBox engineering
71384 Weinstadt, Germany mailto:[email protected]
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
_______________________________________________
gnome-os-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-os-list
