unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Pjotr Prins <pjotr.public12@thebird.nl>
To: guix-devel@gnu.org
Subject: Re: Self-contained Guix tarball
Date: Tue, 21 Apr 2015 10:37:22 +0200	[thread overview]
Message-ID: <20150421083722.GA16564@thebird.nl> (raw)
In-Reply-To: <87zj61q4su.fsf@gnu.org>

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.

  reply	other threads:[~2015-04-21  8:38 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-10  8:46 Copying whole /gnu/store from USB does not work Pjotr Prins
2015-04-10 11:48 ` Ludovic Courtès
2015-04-10 13:14   ` Pjotr Prins
2015-04-10 13:41     ` David Thompson
2015-04-12 10:28     ` Copying whole /gnu/store from USB does not work (SOLVED) Pjotr Prins
2015-04-12 12:29       ` Ludovic Courtès
2015-04-12 20:07     ` Self-contained Guix tarball Ludovic Courtès
2015-04-13  6:54       ` Pjotr Prins
2015-04-13  9:57         ` Ludovic Courtès
2015-04-13 10:05           ` Pjotr Prins
2015-04-13 13:29           ` Mark H Weaver
2015-04-14 21:33             ` Ludovic Courtès
2015-04-13 15:47       ` Thompson, David
2015-04-15 21:31       ` Ludovic Courtès
2015-04-16  5:33         ` Pjotr Prins
2015-04-18 21:23           ` Ludovic Courtès
2015-04-19  8:18             ` Pjotr Prins
2015-04-19 20:09               ` Ludovic Courtès
2015-04-19 13:34             ` Taylan Ulrich Bayırlı/Kammer
2015-04-20 20:49               ` Ludovic Courtès
2015-04-21  7:03                 ` Pjotr Prins
2015-04-21  7:19                   ` Pjotr Prins
2015-04-21  8:18                     ` Ludovic Courtès
2015-04-21  8:44                       ` Pjotr Prins
2015-04-21 12:16                         ` Ludovic Courtès
2015-04-21  8:11                   ` Ludovic Courtès
2015-04-21  8:37                     ` Pjotr Prins [this message]
2015-04-21 10:08                       ` Ricardo Wurmus
2015-04-21 10:17                         ` Pjotr Prins
2015-04-21 12:08                           ` Andreas Enge
2015-04-21 12:12                       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150421083722.GA16564@thebird.nl \
    --to=pjotr.public12@thebird.nl \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).