Re: Self-contained Guix tarball

[Pjotr Prins]

On Tue, Apr 21, 2015 at 10:11:29AM +0200, Ludovic Courtès wrote:
> The important thing is that currently, the DB is authoritative.  So it
> cannot be corrupt (that would be equivalent to having lost /gnu/store
> altogether), and thus it cannot be repaired.

The point really is that it is not so hard to achieve rebuilding the
database. Anyone on this list thinks that should be possible? I am
asking the big systems guys :)

> What *can* be repaired is the store: for instance, if a store item is
> tampered with.  The daemon has code to do it, but the Guix client tools
> do not expose it yet.

There are other tools that do that. It would be a nice feature, even
so.

> I don???t think it could work the way you envision it.  What kind of
> deployment do you have in mind?  For whole system deployment, one can
> obviously use ???guix system???.

It can work if we rebuild the database from a store.

> >> I suspect this would make GC inefficient (lots of disk seeks to
> >> determine references/referrers compared to queries of the SQLite
> >> database.)
> >
> > Yes, Nix switched to using sqlitedb because of the GC.
> 
> I think it???s been there ???forever??? (at least since I started contributing
> in 2008.)

I remember the switch to sqlite and questioned it in my mind at the
time.

> > It is also useful to search current versions of installed packages
> > quickly. Even so, I think it should be viewed as an index. The state
> > of the machine is what is *sitting* in the store. That would be the
> > correct design.
> >
> > Meta information can go out of sync. Therefore we should not assume
> > they are in sync.
> 
> Again, the store can go ???out of sync,??? but the DB itself is
> authoritative currently.

Yes. It should be. But it would be good to rebuild from an existing
store consisting of packages. All I am saying :)

> >> Another (opposite :-)) option is to make /gnu/store a read-only bind
> >> mount on GuixSD.  Commit 3392ce5 does that.  This will prevent
> >> accidental modifications of the store.
> >
> > That is a good solution for end-users. Not for administrators. So
> > adminstrators will circumvent it.
> 
> Well, administrators won???t be able to circumvent it accidentally, at
> least.

True.

> I understand this framework really constrains what sysadmins can do, and
> in particular prevents them from doing ???quick-and-dirty hacks.???  I think
> we should strive to find the UIs that allow for quick hacks while not
> compromising the store???s integrity.
> 
> WDYT?

The Unix way is transparency and dirty hacks. That is why systems guys
and gurus generally don't like systemd, for example, even if it has
great features. I think that is a nice comparison. Another one would
be the Microsoft settings management infrastructure. 

To make guix loved by system deployments you have to cater for quick
and dirty. If everything has to be handled by an opaque daemon - even
if it is FOSS - they are not going to like it enough. I am speaking
for myself here (of course), but I know enough systems guys (and
girls) and how they think. One of the great features of Guix is its
store and that it is easy to grasp how it works. Handling everything
through a daemon makes sense from a user perspective - but you should
also allow for short-cuts. As unintuitive as it may sound, it is the
Unix way ;)

It may also allow for people creating other store-based tools in time.

Anyway, just raising the point now. We should not be against dirty
hacks out of principle or purism. That will hurt acceptance in my
opinion.

Pj.