Re: ZFS on Guix
Hi guix-developers, > Now, my understanding is that `/etc/` directory is recreated at each `guix > system reconfigure`. Thus, if ZFS maintains information in `/etc/zfs/` then > on a reconfigure the information is lost. > > If so --- for Guix, what should I use instead? > Okay, a `guix system reconfigure` doesn't remove files in `/etc`, at best I **think** it just copies/overwrites data, but if the `etc` directory of the built system doesn't have a file, it will not be overwritten if something else writes to `/etc`. Is my understanding correct? On the other hand --- is it "properly Guix" for a system component to write to a file in the `/etc` directory? Where should I put this kind of not-quite-configuration cache file? Thanks raid5atemyhomework
Re: Cuirass logo - artwork.
Here is my proposal: https://luis-felipe.gitlab.io/media/2021/01/cuirass-logo-proposal-2021-01-09.png Column 1 is a text-based logo where the S characters are supposed to represent integration. Column two is the same logo but uses an icon instead of the S characters to represent the same concept. Variants A, B, and C only differ in the shape of the S characters. What do you think? --- Luis Felipe López Acevedo https://luis-felipe.gitlab.io/
Re: ZFS on Guix
Hi guix-developers, I just found out that ZFS on Linux maintains a file `/etc/zfs/zpool.cache` which contains information on ZPOOLs (i.e. ZFS-managed RAID arrays). I just didn't encounter this file before on Guix because the file is created if and only if the directory `/etc/zfs/` exists, and that directory is not created by the ZFS installation process on Guix (because I'm the one making the ZFS installation process on Guix right now and I didn't know about this directory). Now, my understanding is that `/etc/` directory is recreated at each `guix system reconfigure`. Thus, if ZFS maintains information in `/etc/zfs/` then on a reconfigure the information is lost. If so --- for Guix, what should I use instead? As it happens, ZFS uses this directory for at least these things: * `/etc/zfs/zpool.cache` - a binary file containing information about what ZPOOLs were created on this system. The `zpool` command updates this file! * `/etc/zfs/zpool.d/` - a directory of scripts that can be used to extend the `zpool` command; the ZFS release normally installs a bunch of files it has in those directories. * `/etc/zfs/vdev_id.conf` - a sysad-managed configuration file that is used to indicate the paths. * `/etc/zfs/zed.d/` - a directory of scripts that are executed when particular events are detected by the ZFS Event Daemon (which I didn't know about, and which should also be installed and started as a Shepherd service as well). Sysads are supposed to link or copy files from `/libexec/zfs/zed.d/` (which are provided by the installation) to enable/disable particular zedlets, and can add other events here. The ZFS release normally links some of the files in `/libexec/zfs/zed.d/`. * `/etc/zfs/zfs-functions` - a shell file containing functions that some bits of ZFS `init` scripts / `initramfs` scripts use, and maybe more. I think Guix can safely ignore this, though somebody (most likely me) will have to read it through to understand how ZFS actually implements some of its magical abilities. Of these, many are stuff that we might plausibly generate by adding more fields in `zfs-configuration`, though the ZED and its zedlet system would bring in the possibility of writing Guile GEXP to create scripts for particular events. However, I'm not so sure about `zpool.cache` file. For one, it doesn't contain text data so it's not easy to generate it ourselves. On the other hand I've got ZFS working without it, by just using `zpool import -a` to have ZFS scan for all devices. The problem with this technique is if Guix is used on a system with several dozen or hundred devices in various ZPOOLs; this would slow down boot while ZFS is checking all arrays and figuring out which device goes into which array, whereas a `zpool.cache` file would let ZFS know about all pools created or imported on the system and would not need to scan their labels and reassemble their arrays and so on. Another is that for a complex enough setup, a storage device might be connected to the hardware by hostile parties (for example, by network-addressable block devices, or USB) that contains a ZPOOL with a `mountpoint=/gnu/store` (or other sensitive directory) property, which, if auto-imported via `zpool import -a`, could let particular subdirectories of the filesystem to be subverted. How best do I handle this? Thanks raid5atemyhomework
Re: Snapper DBus woes
On Fri, 08 Jan 2021 13:54:06 -0500 "Leo Famulari" wrote: > Can you share with us the full error messages you got? And a more > full description of what you tried? > > On Thu, Jan 7, 2021, at 20:16, raingloom wrote: > > Hiya folks. > > > > I'm trying to finish up that Snapper package that Pierre Neidhardt > > abandoned and am also running into DBus issues. > > Could someone who knows DBus look into it? I really think we should > > get this package working on Guix sooner rather than later, because > > right now there is no way to protect against an accidental `rm -rf > > $HOME` without a full backup. > > This is my branch: > > https://git.sr.ht/~raingloom/guix-source/tree/raingloom/snapper > > > > That part is taken care of now. Turns out I needed to add a service that extends D-Bus and run snapperd from there. Now I just have to figure out how to actually create a snapshot.
Re: 04/06: services: hurd-vm: Avoid circular dependency with (gnu system images hurd).
Hi! On current master, the disk-size setting on a childhurd has no effect, leaving very little disk space to do development. I am suspecting this commit > commit 859b362f81598830d7ff276b96a8724aee3c4db7 > Author: Ludovic Courtès > AuthorDate: Mon Dec 7 12:38:25 2020 +0100 > > services: hurd-vm: Avoid circular dependency with (gnu system images > hurd). > > * gnu/services/virtualization.scm (hurd-vm-disk-image): Use > 'lookup-image-type-by-name' instead of referring to 'hurd-disk-image' > from (gnu system images hurd). > --- > gnu/services/virtualization.scm | 15 ++- > 1 file changed, 6 insertions(+), 9 deletions(-) > > diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm > index eaf0bbd..f435630 100644 > --- a/gnu/services/virtualization.scm > +++ b/gnu/services/virtualization.scm [..] > @@ -913,14 +912,12 @@ that will be listening to receive secret keys on port > 1004, TCP." > (define (hurd-vm-disk-image config) >"Return a disk-image for the Hurd according to CONFIG. The secret-service > is added to the OS specified in CONFIG." > - (let ((os (secret-service-operating-system (hurd-vm-configuration-os > config))) > -(disk-size (hurd-vm-configuration-disk-size config))) > -(system-image > - (image > - (inherit hurd-disk-image) > - (format 'compressed-qcow2) > - (size disk-size) > - (operating-system os) This system-image included (size disk-size), and here > + (let* ((os(secret-service-operating-system > + (hurd-vm-configuration-os config))) > + (disk-size (hurd-vm-configuration-disk-size config)) > + (type (lookup-image-type-by-name 'hurd-qcow2)) > + (os->image (image-type-constructor type))) > +(system-image (os->image os disk-size goes unused. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Cuirass logo - artwork.
Mathieu Othacehe writes: > At first I thought that all the performance issues we had were caused by > unoptimized SQL queries. Turns out it was only half of the problem. > > As we have multiple processes accessing the database (cuirass, > cuirass-web, cuirass-send-events and now remote-server), we are falling > into the architecture model that is very badly supported by SQLite: many > readers and many readers across several processes[1]. > > I also noticed that SQLite doesn't handle I/O pressure on the hard drive > the database is sitting on. I had to mount the database file on a tmpfs > directory to get around this issue[2]. > > Finally, SQLite doesn't offer any real monitoring solution, requires > periodical vacuuming and is really hard to configure[3]. > > As stated on SQLite website: "SQLite does not compete with client/server > databases. SQLite competes with fopen()." > > I've been running Cuirass using a PostgreSQL database, and without any > particular tuning everything works smooth, which makes me regret to have > waited so long to leap the breach. > > Thanks for you interest, Very interesting, thanks for sharing your experience. Worth a blog post in my opinion ;) Cheers! signature.asc Description: PGP signature
Re: How would packaging Steam-proton games be received?
O Ye of little Faith, please read: https://puri.sm/posts/the-future-of-software-supply-chain-security/ (It really is worth a read ;) On +2020-12-31 14:53:24 -0500, Leo Famulari wrote: > Hi Josh, > > I'm replying off-list, because this subject has been discussed s > many times without reaching a different conclusion, and because I worry > about starting a flamewar on the mailing list. > > On Thu, Dec 31, 2020 at 02:12:16PM -0500, Josh Marshall wrote: > > So a separate channel would work for non-free software? I know the stuff > > is fundamentally gross. I'd still like to have a better way to get out of > > an ecosystem that is basically entirely all non-free software and a > > transition to fully free becomes possible. > > If we think about free software in terms of the "4 freedoms" [0], > channels are a fully-supported way to help people take advantage of the > "zero-eth freedom", which is the freedom to use the software (Guix) as > one sees fit. > > Personally, I think that ensuring an operating system is 100% free > software (and with no DRM support) hampers the success of the free > software movement by driving away users. > > If we lived in a world with free software support for common hardware > (ahem, WiFi, Bluetooth, LTE) and for popular software use cases (popular > games and apps, commercial and educational software), then offering a > totally free system would be a viable approach. > > But, that world doesn't exist. Even though some people who are happy to > use 10+ year old computers for very limited use cases might think it > does... many of them don't even use mobile phones... they don't > understand contemporary computing at all, from a practical perspective. > > Nevertheless, the GNU Guix project has made a commitment to working > within the FSDG, and we are basically stuck with it barring some > cataclysmic change. > > I think that maintaining a harmonious atmosphere within Guix will help > it continue to grow, and channels can satisfy the need for things that > don't fit the FSDG. If Guix becomes large enough, it could be > transformative for the free software movement. > > [0] > https://www.gnu.org/philosophy/free-sw.en.html -- Regards, Bengt Richter
