[Sugar-devel] Fwd: [Zero-install-devel] Summary of the chat on #sugar-meeting (2009-10-18)

[Bernie Innocenti]

FYI

-------- Mensaje original --------
Asunto: [Zero-install-devel] Summary of the chat on #sugar-meeting
(2009-10-18)
Fecha: Sun, 18 Oct 2009 16:02:50 +0100
De: Thomas Leonard <talex5 at gmail.com>
Responder-a:: The Zero Install system
<zero-install-devel at lists.sourceforge.net>
A: The Zero Install system <zero-install-devel at lists.sourceforge.net>

Sugar (http://www.sugarlabs.org/) is a graphical environment designed
for children, as an alternative to the familiar office-destkop. It is
intended to be used in places with very limited network access, and so
has a heavy focus on peer-to-peer interactions. It is an open system,
encouraging children to write and distribute their own software. It is
often run on XO laptops (brightly-coloured laptops for children),
which are fairly low-spec machines (256 MB RAM).

Like ROX in 2003, they currently have a system of self-contained
bundles which is easy to use, but which does not handle dependencies.


Summary of the chat on #sugar-meeting (2009-10-18):


Q: How do you deal with library variability between distros?

A: For ABI-compatibility, if the distro packages vary too much then we
ignore them and use our own.

   For package name variability, we allow the feed to list all the
possible names. If we can't find the package because we don't know its
name then again we just use the Zero Install version.
   We check packages rather than files because we need to know the
version too (although checking the filename could work for the
specific case of .so files).

Q: Sugar wants to support multiple CPU types. Are fat bundles supported?

A: There are two ways of getting software. Normally you get the feed
and then download the right package for your system. However, 0export
can create bundles with packages for multiple architectures:
http://0install.net/0export.html

   [ However, importing a bundle only imports the bits you need. If
you want to be able to give the program to someone else later without
an Internet connection and with a different CPU type, then you'll need
to keep a copy of the original, or change it so that it imports
everything. ]

Q: How does 0install handle build-time dependencies for source taballs?

A: Source packages have a CPU type of "src". Build dependencies can be
flagged as build only or build and runtime. If you want runtime-only
dependencies, your build process must add them to the resulting feed
itself. See: http://0install.net/0compile.html

Q: Would gcc be a dependency of a source package for a program written in C?

A: Ideally, yes, but we don't have a gcc feed at the moment.
   [ Delight is based on gcc and works, though, so there should be no
surprises here. ]

Q: Does a source package compile to produce a binary package, or is it
simply "compiled and installed" in one step?

A: When you use a program, you may get told there are no binaries
available. You have the option to compile from source at that point.

Q: Are there any facilities for reporting compilation errors (or other
obvious run-time errors) back to the author of a feed?

A: Yes, except that currently they come to us instead of to the
author. Examples are:

   Compile failure reports:
https://sourceforge.net/tracker/?group_id=76468&atid=905152
   Run-time failure reports:
https://sourceforge.net/tracker/?group_id=76468&atid=929902

  [ Compile failures prompt the user to report a bug, while run-time
failures don't.
    Runtime bug reports include the version and digest of every
dependency. Compile reports
    should too, but looks like I broke that at some point. ]

Q: How do build-time variants work (options to ./configure)?

A: We generally prefer to have all configuration work at runtime.

Q: What sorts of programmatic interfaces does z-i expose?

A: There's a Python API: http://0install.net/python-api/html/index.html

Q: If a distro package is later installed, would it be possible to
detect the redundancy as remove the redundant 0install package?

A: Zero Install checks for dependencies on each run, so if the
distribution package disappears then it just behaves as if it was
never there and prompts you to download a suitable version. Currently,
we're not at all smart about garbage collecting unused packages (you
have to select them manually). Sugar would probably check for unused
packages at start-up and remove them.

Q: What's the startup performance penalty of checking for the dependencies?

A: About 0.1s on my laptop. [ Actually that was on my old laptop.
Measuring it again, ROX-Filer starts 0.04s faster when not using Zero
Install. Edit starts 0.02s faster. ]
   We have thought about caching the results and having a C launcher
quickly check that they were still valid, but so far speed hasn't been
an issue.

Q: How did you become or find such talented documentation writers? :)

A: :-)

Q: We are very much concerned with deployments that lack internet
access. Has anyone considered the issues involved with P2P 0install on
a LAN, or with a local proxy server?

A: p2p on a LAN (experimental): http://0install.net/0share.html

Given a feed with a list of packages, you broadcast on the LAN for
someone with a package with the digest you want.

However, that still gets the feeds and keys over the Internet. You
could send them too, but how do you trust the key?

We need to know that a particular feed belongs to the URL it claims.
Currently we do that by keeping a list of GPG keys approved to sign
feeds for each site. We have a key information server to give the user
hints about whether to trust a key.

Sugar users may not have access to the Internet and therefore will
have even less chance of validating the keys correctly than our
current users do.

It may be desirable to put the fingerprint of the key in the URL. Then
we wouldn't have to confirm with the users. We have discussed this in
the past. However, this means that the feed moves whenever the key
changes (e.g. the old key expires, gets lost, a new maintainer takes
over). In theory, there's no problem with supporting this, though.

Q: What is the abstract object represented by a 0install feed?

A: This diagram shows what's in a feed:
http://0install.net/interface-spec.html
   Basically, it's a list of versions, their dependencies, and where
to get them.

Sugar Activities are often "collaborative", meaning that they
communicate over the network. It's preferable to be using the same
version on both machines, to minimize the likelihood of network
protocol incompatibilities. So if I wanted to join someone's shared
session of some Activity, my first step would be to find out the name
and version.

A: You would give the other person the URI and the version number.

   [ Actually, you could give them the results of "0launch
--get-selections THE-PROGRAM". That gives the version and the digest
of each component. The other person could then use the digest if it's
compatible with their machine, or get a different package with the
same version number. ]

If the two machines are identical, then that search is guaranteed to
at least find the version on the originator's machine (if they're both
running the P2P system).

Q: Have you considered what would be required to make something like a
good caching proxy or local package-server for 0install feeds?

A: For feeds and keys: http://0install.net/0mirror.html

   The feeds in the local cache still have their signatures, so they
can be exported back out again easily.

Q: Internationalization? All of the text that I've seen so far has
been in English.

A: z-i is localized to sv and es, using standard .po GNU gettext, but
the site is English-only.


[ One interesting issue which didn't come up is where to store the
feeds. Sugar runs each application (activity) under a seaprate user
account. The most efficient thing would be to have 0launch run as a
launcher user, sharing feeds whenever possible. A more paranoid design
would run it separately within each activity's account, sharing
implementations but not feeds. ]


-- 
Dr Thomas Leonard		ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zero-install-devel