guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: playing nice with other OSs


From: Chris Marusich
Subject: Re: playing nice with other OSs
Date: Wed, 08 Feb 2017 03:52:11 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Federico Beffa <address@hidden> writes:

> Hi,
>
> I'm looking into the possibility of installing GuixSD in parallel with
> another operating system on a single machine (dual boot).  Looking
> into the code (gnu system grub) I see that the GRUB "linux" and
> "initrd" commands are hardwired into the code.  This appears to make
> the definition of a <menu-entry> for another operating system
> (GNU/Hurd, NetBSD, Windows, ...) impossible.  Am I right, or am I
> overlooking something?
>

I think it's possible, but only for other GNU/Linux distributions, and
only when not chain loading.  This could of course be improved, but I
think those are the current limitations.  See "(guix) GRUB
Configuration", if you haven't already, for details on how to define a
custom entry.

>
> If the above is correct and we want to make GuixSD play nicely with
> others, then I suppose that we will have to modify the <menu-entry>
> record.  I see two possibilities:
>
> * We could try to generalize the fields along the lines of linux ->
> kernel, initrd -> kernel-boot-helpers, ...
>
> * Define operating system specific records such as <linux-menu-entry>,
> <hurd-menu-entry>, <chainloader-menu-entry>, ..., where the content of
> the fields for the systems not handled by GuixSD would come from the
> user operating-system file configuration.
>
> I personally prefer the second approach. What do you think?
>

At first blush, I guess the second approach seems more intuitive to me.
I don't dual boot, so I don't have a vested interest in seeing this
feature implemented, but if it can be done reasonably, why not do it?

I suspect most people will not need to dual boot, so whatever solution
you choose, it might be wise to try and keep the code for the common use
case as simple as possible.  It would be unfortunate to wind up overly
complicating the code for the common use case in order to accommodate an
uncommon use case.

-- 
Chris

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]