From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B3DF2138334 for ; Wed, 7 Aug 2019 10:11:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6EA7DE0830; Wed, 7 Aug 2019 10:11:45 +0000 (UTC) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CF55EE07F2 for ; Wed, 7 Aug 2019 10:11:44 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id t16so635952wra.6 for ; Wed, 07 Aug 2019 03:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=aZ27xSD9vs5lv4AqC4MjkmNY/wFVBfyXotPJOXRp5Ps=; b=lpKPwvIbHpwo6wAtmw6y4f0MEsZ32I2RQ5P5C+0sn9KoCzX0kiPDoMmtbCYhG4jG/k +aTJmfoTuD0nm6lUvz4mM298E6FmRoMLsqTapimKMENFOnT5amiTn31pNmeq3zvF5dkc KDzFbc5wt2MDtayifN4EB5Ua3HwI0kkryY0jenggFX3UYIIhD2yN4e/estQAwuFUOFwA AK3/kJHy7ODqKOtWQ9xTC6Hxh2ArcoXj80t+tBn/9KaXrs0tGeULKuyXnp+JKX5I0NTq Cg303woZ7MRr4RN4MCecOrMhKapcbp11rEh+uNDKvueaV5aLsnSDh/icTOTSWFdAjaRy GCPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=aZ27xSD9vs5lv4AqC4MjkmNY/wFVBfyXotPJOXRp5Ps=; b=XRFOCgTxbYla4oEwb4FIybocWbPI/udYrS8tbEyKX2ImdnsbySo8wRczDM+y0/uFrf 8e0c0j2A9OXIQiuEGCI7Jn0nlPXzXSatCcARewjpHXS0fr4h+r9okCsca3Ip4IwMn8eH pfjIpOqDhrhzJ2C+epdj+iLREV4Dq87iz1+QpP4eGaE6ATBEdLDiTaACgXOA+NPv6Ua8 yWaiouEIVH+vH153GO9X6gjrCW579o7dQun5z1ch7RApQxNkcB4qctPmdEM3Fb4Coo9S LE7/uSnD/VOO0ezKCgUduB2fGv7zcTDlsqRQAGvQeT9p9BXPd6byW9Uta47N20t5kJQN Neow== X-Gm-Message-State: APjAAAVaX8K32l/c6Xpjyh/u+jsOWNG6SB9mI8H+3cVRlcZPxHggG1d/ S2kDwZ3AYn5uhYadLKEhe5TmcHEQ X-Google-Smtp-Source: APXvYqzM/GILBRE+LLyYNaH2XOqjQZBnAADLKfm+xS2wGn25JtfoyL/wTSiSv4QjHsiu4qhc0+HYaA== X-Received: by 2002:a5d:4108:: with SMTP id l8mr9663917wrp.113.1565172703303; Wed, 07 Aug 2019 03:11:43 -0700 (PDT) Received: from localhost.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by smtp.gmail.com with ESMTPSA id w23sm98558900wmi.45.2019.08.07.03.11.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Aug 2019 03:11:42 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org, gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: USE flag 'split-usr' is now global Date: Wed, 07 Aug 2019 11:11:40 +0100 Message-ID: <8048352.jXIC93lEPp@localhost> In-Reply-To: References: <11147c49836aa1983da6a4a546fdf116@dyndn.es> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2273873.eXrIC3IaTI"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Archives-Salt: 76d82489-7ee0-4366-b757-9e29cd76ee6f X-Archives-Hash: 107d7d33c38f71913d3362e1c592388c --nextPart2273873.eXrIC3IaTI Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" On Wednesday, 7 August 2019 01:31:03 BST Rich Freeman wrote: > On Tue, Aug 6, 2019 at 7:41 PM Grant Taylor > > Sadly, I think people have thrust additional (IMHO) largely unnecessary > > complexity into the init process just to be able to support more exotic > > installations. I may be wrong but I thought the udev-usr-initrd complexity was deemed a necessity/ when bluetooth input and audio devices became more widespread. The fact systemd gradually mushroomed to take over the OS is another more loosely related story. > > Then, they have said "We want to be consistent in how we > > boot, so we need to use this more complex thing everywhere." To which, > > many greybeards have responded "I don't need nor want that on my simple > > server." This is the main rub of these architectural /solutions/ being pushed onto the wider community by what amounted to corporate lobbyists, for /problems/ many of us never had. > Initramfs is popular because it is way more flexible: > > 1. You can build a fully modular kernel so that you can use the same > kernel on every system but not be loading countless drivers for > hardware most systems don't use, while still being certain of being > able to boot any particular system. Unless you have no use for this. Just as many *Gentoo* users do not need their kernel image blessed by Microsoft, RHL shims and what not. > 2. You have more access to labels/uuids/etc for finding the root > filesystem so that when one of your hard drive fails the kernel > doesn't just dumbly use the next one in sequence, assuming they're > even always identified in the same order. I may be missing something here ... but I think this is not related to the use of an initrd. You probably won't even need a separate bloat-loader like grub2 for this, at least not on UEFI systems. Just add the root PARTUUID on your kernel line, inside the kernel. > 3. You can use "exotic" installations like iscsi and so on, which > seems pretty useful in an enterprise setting. > > > If you /actually/ /need/ a micro installation to make your main > > installation available, then go for it. But if you don't /actually/ > > /need/ a micro installation, well Occam's Razor / Parsimony. I have not performed sociological research to confirm this, but I'd say to those of us identifying with the above statement Gentoo is a good fit. For those in an enterprise setting, there are many other cookie-cutter corporate solutions applicable. > Except then you're tailoring your bootloader to individual systems. Yes, I don't *have* to use Gentoo on a large server farm, put a SLA in place linked to contractual payment thresholds, hack my own monitoring system and get 3 layers of insurance signed off. Tailoring my bootloader(s) is something I do in my home-office environment, including 3 servers. > Most sysadmins will prefer the Ubuntu/RHEL/etc approach where the same > kernel/bootloader/etc works everywhere, vs tailoring their boot > process to every individual host. Yes in (large) corporate deployments. Some of them on Azure too. > > > They're a really elegant solution to the problem. > > > > I wouldn't use the words "elegant" or "solution". "kludge" comes to mind. > > What could be more elegant? It minimizes the complexity of the > kernel, which is why Linus generally prohibits the kernel from having > any more advanced root mounting logic, and why pretty much every Linux > system out there uses one. I think the whole issue is a difference in use cases and where corporate money has been used to provide a narrowly focused solution to address corporate requirements, without particular attention/interest/care to what are statistically edge use cases. Such edge use cases, e.g. separate /usr, no initrd or kernel images signed by Microsoft, different choice of bootloaders, etc. have been more concentrated on Gentoo than the one-size-fits-all binary distros. RHL calls these "bespoke" deployments. Yet when changes in udev brought about the necessity of an initrd in order to keep running a separate / usr fs, I recall quite a number of gentoo user voices in this M/L alone objecting to the changes. What is an edge use case for Fedora, is/was not so much of an edge use case in Gentoo. Gentoo did not *have* to follow upstream changes, but yet again this could probably bring its ultimate stagnation/demise as devs would be spread too thin to keep developing Gentoo in a deviating path from the rest of the Linux trajectory. Having used and still using other binary distros I'm grateful Gentoo's still here, but would really prefer it did not bend itself out of shape to accommodate solutions to problems I and others do not have, or when we do we may not even use Gentoo to solve them. -- Regards, Mick --nextPart2273873.eXrIC3IaTI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEt7MNaGaS6HvTUrEz6WnU8jC95dcFAl1Ko9wACgkQ6WnU8jC9 5ddN7Q/+OZIKoMCiHauBxbexPAnerkmIEy7cfoLzoFFx4S3CFWH4SNoJO0XHizIU A9H+yo06YIeYHAP/PhRmUaPfYgTa8V8YL/hQvhQG1nJn25jdZ7UsX8XAQf343bwm tljpJSX+kOaUbhsimf0sCG+LOqU1kcYoWas7i8WqjP00BsOU0hz7OpHF288A3F51 /R/Ik2WTUOvUaTAjZgI1shMWVw/p5UYynUv3pGoYIrhbIRcB1wuEZaHpqt0x6j5L +sPxZARpvY+9tcjHWSDfCCnrsJS5nG8GjT/JR+CS1DoAiDNEQ6u6O5uxbtH9Bbfo RzAfCpiSTNh3NMtbZHs0n/vjboWbrRt6cpjBvaALBpv3gi9jEXCX7B1r+lpIPXCQ VXfq00wOaJXikH3wzIEpoAhSe/wUVS8X4zhKkESPCdlhys7RFm253IBUw3wSjH5U w2NpOzZ22XqUpANhKrWLiEUoyHw0nWtaPdDYS++j1QfLoOafSlGSg4DKZhxFOg/u DQPnKi871dsXC+tvys1fw9BJmEBYR4Xcei531Nb2Rs4fV+bzShZefblKe8UI/ofZ rku6x7VWZJVY4Ei08ZFfuhrO2wmh/pCOx+pUVNgFbTDFJTwDR5CFrfW3tWkBOcuP b0+Ps9ffjjj5C6o4J0pyebk8hILYzfZOXT+bYwrtSVcVwFiSN3M= =jX2E -----END PGP SIGNATURE----- --nextPart2273873.eXrIC3IaTI--