From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Installation Date: Sun, 21 Jan 2018 20:38:20 -0800 Message-ID: <87372yzewz.fsf@gmail.com> References: <87mv1c4kp7.fsf@gnu.org> <87k1wgh4hf.fsf@elephly.net> <877esfbgtx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1edTsN-0007xM-2D for guix-devel@gnu.org; Sun, 21 Jan 2018 23:38:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1edTsL-0002LU-T9 for guix-devel@gnu.org; Sun, 21 Jan 2018 23:38:31 -0500 In-Reply-To: <877esfbgtx.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 18 Jan 2018 11:29:30 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: Guix-devel --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Ricardo Wurmus skribis: > >> Ludovic Court=C3=A8s writes: >> >>> G=C3=A1bor Boskovits skribis: >>> >>>> I believe, that we could make a powerful extension to guixsd if we cou= ld do >>>> an installation from an installation description. >>>> >>>> I think this installation description should look like the operating-s= ystem description we >>>> already have. >>> >>> In what way would it defer? :-) >>> >>> =E2=80=98operating-system=E2=80=99 *is* an =E2=80=9Cinstallation descri= ption.=E2=80=9D >> >> I guess it would differ from what we have currently in that it would >> also specify partitioning information, which is not handled by >> =E2=80=9Coperating-system=E2=80=9D. >> >> Does it make sense to extend =E2=80=9Coperating-system=E2=80=9D such tha= t disk >> partitioning information could be included and (*holds breath*) acted >> upon automatically? > > I suppose only =E2=80=98guix system init=E2=80=99 could actually use that= information. > > Perhaps we could have a separate partitioning description, and users > could optionally run: > > guix system init --partitioning=3Dpart.scm config.scm > > ? > > Is it really an improvement over writing a Parted script, which is > something people can already do? > >> Acting on partitioning info is a little scary because it can easily lead >> to data loss upon reconfiguration. Small bugs could lead to very big >> problems, so maybe this should not be default behaviour. > > It=E2=80=99s definitely scary. > > Ludo=E2=80=99. Currently, I can only imagine two possible ways this might be used: 1) Somebody wants to frequently change the hard drives, partitions, and/or file systems in their computer(s). 2) Somebody wants to initialize the hard drives, partitions, and/or file systems in their computer(s), but doesn't need to update it later. In the case of (1), who really does this? I know of no developers or users who actually need to change these things frequently. And when changes to these things ARE necessary, it's usually easier to just blast everything away and start fresh (restoring what you need from a backup later), rather than trying to figure out the right way to safely modify things in place. Since changing these kinds of things on a system that's already in use is a rare and dangerous activity, I'm not convinced that Guix needs to provide support for this use case. In the case of (2), anybody who frequently needs to provision systems will probably have a use case for this, so it might make sense to add a feature for first-time initialization only. Maybe a company wants to provision many GuixSD systems for employee laptops. Maybe somebody needs to provision many GuixSD servers in a datacenter. I think that if somebody really needs to do this sort of provisioning frequently, they're probably going to implement their own custom workflow to accomplish the task. Can Guix add a feature to make their life easier? Maybe. For example, maybe we can fields to the declaration which are only acted upon by "guix system init". The intended workflow would be: boot a GuixSD installation image, then run "guix system init" per the manual (perhaps via a script, or even a "guix-provisioning-service" started by Shepherd...!), and Guix will do everything it does today to initialize the system, but first it will also destructively initialize the hard drives, partitions, and file systems according to what is contained in the specified declaration. THIS could be nice! Of course, someone who is provisioning systems like this already has the option of creating custom scripts and tools to initialize the system's drives, partitions, and file systems, but wouldn't it be nice if Guix could do this on their behalf, also? If these details were all defined in the declaration, then (1) the user wouldn't have to implement those kinds of tools themselves, and (2) it would reduce the possibility of writing an declaration that contains incorrect information about disks, partitions, or file systems because all that information would be contained in a single file. I think the key here is that if Guix provides a way to manipulate disks, partitions, or file systems, it should only be allowed when initializing a new system - not reconfiguring an existing one. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlplar0ACgkQ3UCaFdgi Rp0tihAAp9UyaqHbT+yGdU31lgQerG6d04/S3zPvaosgjglQ7Kpap/bCMRInLLK7 3WwZXNHhb8feqqaBhPHf6WYOnZ75yEaNwRC8uJ9aXMGAlUa1A326owVH3S5BxKZO jMtxDMcjfPaCS/TYOXVMGtTpTJPXQwisvxPziYdr2rWjPK6DD3FqoSdBgBLkcpAA gsdetJVMe+4/lOH3C3DzN1Bkhqn4iesT6RxPMWZudUw5RfyXQtaUGiZWse9GjV/Z mx6au/+gIgfzryMXU+PueVEaNm4hsnZYVNkCNuKTIoXOqRSuOEcp2cW4l1qrwYrt 8+uf/gAQH3LM15P77d764mmJ30bUbYXZ0hpNPrLGGd5JiWGYEdjgZne1Aqh61koV LNXb/Y5r+Ab2rMYYqWmfi9sXJJbaz39IluqEVhnX4dIH5gOlSQt4zZXBII6unpCY HWOQ+vzpY8TNyv4JclO3Z2GgZyRPbHPUqD1SMuH4XCBSUpuCrI7KWA1T0fAqpIe6 4+fynvsNhL1lLn61OlfSNumhnOej43yK6OmExYlA6PXELBCQ4JQcvOy/o98Vnbzf 80jcQqSSI49AoYP6+yhYbbTTwGZLgtQGtIEWntm4B7jevUTcjvLMZWBFHK3DkICT rDAnK9KWV/yO9v25Jq3Jidp89luLpU571Vn1FXLw+anoOf8t5LY= =tXoh -----END PGP SIGNATURE----- --=-=-=--