Re: Introducing myself: Andres Gomez

[Colin Walters <walters verbum org>]

On Wed, 2012-07-11 at 01:05 +0300, Andres Gomez wrote:

> As a simple example: if I understand correctly, some software like
> Apache would not be included in the tree. If so, you can switch Apache
> with any other system service like, for example, Radius. How would be
> the distribution and configuration of a Radius service in an OSTree-d
> system?

At a high level, I *personally* am not trying to "compete" exactly with
Linux "distributions" as they exist today exactly, and I don't think
GNOME should be doing that either.  My goal is more
to make the right tradeoffs at a base layer for a client operating
system, and show that some things can be done significantly better.

One simple answer to "I want to run Apache" is that you reboot into
whatever distribution you want and apt-get/urpmi/yum/whatever the system
you want.  I'm really happy with this fact that OSTree doesn't destroy
whatever installed distribution you have today; it takes off a lot
of the pressure to handle all use cases immediately.

A slightly more complex answer is that it should be possible
to use RPMs/debs as an "extension" style tool.  So assuming apache
is a self-contained RPM, it can overlay some files on top of the base
system and run.

There are two longer term answers.  First, I hope and expect that
some of the OSTree ideas (if not code) may get into the mainstream
"distributions".  While the gnome-ostree build system is hardcoded to
generate two filesystem trees (a "-runtime" and "-devel" tree per
architecture), you can use whatever build system
you want (deb/rpm/ebuild), and put the results in an OSTree branch.

I haven't actually tried writing the code, but it'd basically be a matter
of running debootstrap (http://wiki.debian.org/Debootstrap) or whatever
equivalent, then running "ostree --repo=repo commit -b
my-deb-based-fs /path/to/debootstrap".

And second, while OSTree does emphasize constructing filesystem trees
on a build server, there's absolutely no reason you couldn't do it on
the *client*, as "package systems" do.  You could even build from source
if you wanted.

Look at it this way: a set of packages (as exist in
Debian/Fedora/Gentoo) when installed, generate a filesystem tree.  The
emphasis of OSTree is on *named* filesystem trees, whereas with packages
one can only speak of
"I have this set of packages on my computer".  Now it's true Debian has
metapackages and such, so there's an intermediate state.

It's a question of emphasis, but I do think different emphasis can produce
qualitatively different results.

I discuss some of this here: https://live.gnome.org/OSTree/Packages

Also, http://arstechnica.com/science/2011/11/over-time-linux-package-dependencies-show-predatorprey-relationship/
is a kind of interesting read.

> The other major doubt I have is about the paradigm "everything in etc is
> a bug". 

Yeah.

> What I see is that in addition to maybe becoming a "big" task to patch
> all the needed software, one of the benefits of forgetting about
> packaging systems like dpkg or rpm would be that software would be
> coming clean from the sources (git repositories). If patches have to be
> created for all the software with any file in /etc, it seems to me that
> we are getting rid of the debian/ subdirs to get the "load" of having to
> track that software now and in the future to patch it correctly.
> Obviously, I suppose that even some software would merge those patches
> upstream, but I doubt that most of them would accept them.

Yes, it's the highest-risk section of the project.  However...the set of
software that installs things into /etc is significantly smaller than
the total set.  These patches will be intrusive, but I think manageable.

We should be able to do it incrementally too.  I'll post something on
the /etc plan soon.

> Now, I have to say that I'm not that experienced in building and
> packaging, nor in general systems tasks.
> 
> I'm a regular Debian user and often packager and I've been doing system
> tasks in the past, but not regularly since some years. Also, I was a rpm
> user but my knowledge in that is quite dusty.

dpkg and rpm are pretty much the same at the binary level; totally
different source languages, but they make the same tradeoffs.  I can
pretty confidently say this having spent years working in both =)

> So, regarding your question about "what do you plan to work on", I have
> to say that my main target, as I was saying, would be to start the GNOME
> OS Installer.

Cool.  It's a challenging task for sure.

> Checking these mockups and some other info about the "First Time"
> settings, I understand that one of the main duties of the Installer
> would be to use OSTree.

Let's discuss this in a separate thread.

> Hence, I'm also ready to help on improving OSTree.
> 
> Talking with Adrián, it seemed clear to us that a way of boosting our
> participation and the help we can offer you would be if you could
> actually identify well defined tasks in which we could start helping
> you. This is: I think I may ask you to take some time to think on tasks
> for your new slaves :D

Hah =)  Yeah, I'll update the TODO file.   The main major open tasks are:

* /etc
  I'm working on this (albeit slowly)
* GRUB/kernel management
  Adrian has an outstanding branch for this...but we also should move towards
  building a kernel in the build system too.
* Application installation
  This deserves some research...it's a very interesting area.
* Smoke testing / integration testing
  Right now the system is a "build -> put on internet" mode,
  but the OSTree model makes it easy to have many different trees at different states,
  say "built", "smoketested", and then increasingly complex (read: slower)
  integration tests.

  trees/built/gnomeos-3.6-i686-devel
  trees/smoketested/gnomeos-3.6-x86_64-runtime
  trees/integration-phase1/gnomeos-3.6-x86_64-devel

  etc.  The hard part of this is writing a test system that e.g. boots
  a tree in qemu and runs the tests.  Ideally we'd have bare metal
  tests too but that'd be difficult for the GNOME sysadmins.  (Assuming
  of course they even have the resources for smoke testing in qemu). There's
  prior art for this in various projects, like Autotest, but it needs
  integration work.  

However, one thing that helps significantly working in the FOSS world
is a strong sense of self-motivation and direction.  If you have that,
access to the source code, and a belief in the goals of the project,
then you can go wherever your keyboard takes you =)