From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: GuixSD bootable ISO-9669 image Date: Tue, 16 May 2017 10:31:36 +0200 Message-ID: <874lwlb3tj.fsf@gnu.org> References: <20170418141719.llp77itz7vyq5rij@abyayala> <87k26hwxt0.fsf@gmail.com> <8760i0m7vg.fsf@gnu.org> <87pog3u3ms.fsf@gmail.com> <87k26afl07.fsf_-_@gmail.com> <20170427190840.79bcaa76@scratchpost.org> <20170427220009.1d0d4607@scratchpost.org> <20170428101844.540ce399@scratchpost.org> <87efw7igen.fsf@gnu.org> <20170502220904.3f27ce9f@scratchpost.org> <871ss72cd2.fsf@gnu.org> <20170507213711.4eaec310@scratchpost.org> <87wp9rmo4d.fsf@gnu.org> <20170512013019.49c3d33d@scratchpost.org> <87o9uyqeda.fsf@gnu.org> <20170514232507.382d5472@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60154) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dAXtO-00011x-H0 for guix-devel@gnu.org; Tue, 16 May 2017 04:31:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dAXtL-0004Oh-Cp for guix-devel@gnu.org; Tue, 16 May 2017 04:31:42 -0400 In-Reply-To: <20170514232507.382d5472@scratchpost.org> (Danny Milosavljevic's message of "Sun, 14 May 2017 23:25:07 +0200") 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: Danny Milosavljevic Cc: guix-devel@gnu.org Hi Danny, Danny Milosavljevic skribis: > On Fri, 12 May 2017 17:33:21 +0200 > ludo@gnu.org (Ludovic Court=C3=A8s) 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 abou= t 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 filesys= tem 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 ind= ependent so I can plug known disks on whatever slot I want and they'll be m= ounted at the same place regardless. I guess another use case is for the G= uix LiveCD to find itself - for the same reason. Not sure what the complic= ation 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 ty= pe in uuids (ever). The user interface (the =E2=80=98uuid=E2=80=99 macro for instance) and the = internal representation (bytevectors) are two different things. The internal representation is fine, we don=E2=80=99t want to represent something that=E2=80=99s literally a =E2=80=9Cbyte vector=E2=80=9D as a Uni= code string, and have parsing errors that could happen anywhere. As for the user interface, I get your point. We certainly don=E2=80=99t wa= nt to make the user=E2=80=99s 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=E2=80=99s w= hy I though that having a separate macro for these two =E2=80=9Cspecial UUID typ= es=E2=80=9D 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=E2=80=99t 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=E2=80=99.