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.