all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: guix-devel@gnu.org
Subject: Re: GuixSD bootable ISO-9669 image
Date: Tue, 16 May 2017 10:31:36 +0200	[thread overview]
Message-ID: <874lwlb3tj.fsf@gnu.org> (raw)
In-Reply-To: <20170514232507.382d5472@scratchpost.org> (Danny Milosavljevic's message of "Sun, 14 May 2017 23:25:07 +0200")

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Fri, 12 May 2017 17:33:21 +0200
> ludo@gnu.org (Ludovic Courtès) wrote:
>> Then users should pick the right one, usually the macro, and get an
>> error when they pass an invalid UUID.
>
> Note that the directory /dev/disk/by-uuid doesn't contain any marker about what kind of uuid it is. So it would make things complicated for the user.
>
> I wouldn't expect anyone that isn't a programmer to know that fat32 uuids are different from btrfs uuids.
>
> If we have different uuid macros, we should have *-uuid macros for *every* possible filesystem type, whether the uuids differ or not - at least then there's a pattern for the user to learn.  Not like 3 macros and 14 filesystem types so you'd have to have a mapping function in your head.
>
> But really, I myself use uuids only for file-system entries to be bus independent so I can plug known disks on whatever slot I want and they'll be mounted at the same place regardless.  I guess another use case is for the Guix LiveCD to find itself - for the same reason.  Not sure what the complication of bytevectors, multiple macros etcetc buys us.  The user is probably copy&pasting the uuid from /dev/disk/by-uuid anyway.  It's not like you type in uuids (ever).

The user interface (the ‘uuid’ macro for instance) and the internal
representation (bytevectors) are two different things.

The internal representation is fine, we don’t want to represent
something that’s literally a “byte vector” as a Unicode string, and have
parsing errors that could happen anywhere.

As for the user interface, I get your point.  We certainly don’t want to
make the user’s life unnecessarily difficult.

Honestly, I was under the assumptions that DCE UUIDs was all that
mattered: it works for ext2 and btrfs, right?  I would think that people
would rarely add FAT32 or ISO9660 UUIDs to the OS config.  That’s why I
though that having a separate macro for these two “special UUID types”
is okay.

What the macro buys us is expansion-time or system-instantiation-time
checks.  When someone uses /dev/disk/by-uuid/something-obviously-wrong
on another GNU/Linux system, they don’t get an error until they try to
boot the thing.  Here we have an opportunity to do that check before the
system is instantiated.

WDYT?

Ludo’.

  reply	other threads:[~2017-05-16  8:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-18 14:17 GuixSD on servers [Fwd: [rtracker.1984.is #131647] A question about VServer system specific requirements] ng0
2017-04-18 15:16 ` Chris Marusich
2017-04-19 20:59   ` Ludovic Courtès
2017-04-23  4:52     ` Chris Marusich
2017-04-24  5:11       ` GuixSD bootable ISO-9669 image (was: Re: GuixSD on servers [Fwd: [rtracker.1984.is #131647] A question about VServer system specific requirements]) Chris Marusich
2017-04-27 13:42         ` GuixSD bootable ISO-9669 image Ludovic Courtès
2017-04-27 17:08         ` GuixSD bootable ISO-9669 image (was: Re: GuixSD on servers [Fwd: [rtracker.1984.is #131647] A question about VServer system specific requirements]) Danny Milosavljevic
2017-04-27 20:00           ` Danny Milosavljevic
2017-04-28  8:18             ` Danny Milosavljevic
2017-05-02 12:37               ` GuixSD bootable ISO-9669 image Ludovic Courtès
2017-05-02 12:53                 ` ng0
2017-05-03  6:26                   ` Mark H Weaver
2017-05-02 20:09                 ` Danny Milosavljevic
2017-05-02 21:11                   ` Ludovic Courtès
2017-05-07 19:37                     ` Danny Milosavljevic
2017-05-08 14:14                       ` Ludovic Courtès
2017-05-11 23:30                         ` Danny Milosavljevic
2017-05-12 15:33                           ` Ludovic Courtès
2017-05-14 21:25                             ` Danny Milosavljevic
2017-05-16  8:31                               ` Ludovic Courtès [this message]
2017-06-06  9:35                                 ` Danny Milosavljevic
2017-06-08 12:25                                   ` Ludovic Courtès
2017-05-02 20:12                 ` Danny Milosavljevic

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

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

  git send-email \
    --in-reply-to=874lwlb3tj.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=dannym@scratchpost.org \
    --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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.