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 A7500138334 for ; Wed, 7 Aug 2019 00:15:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E07B9E088D; Wed, 7 Aug 2019 00:15:05 +0000 (UTC) Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) (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 6256CE087E for ; Wed, 7 Aug 2019 00:15:05 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id n4so721033pgv.2 for ; Tue, 06 Aug 2019 17:15:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Ay/OxWfStahaLY9OcFPk+5bZCy6M9SPkq15amwO3jBA=; b=ZsMTqFp34tz27TwNlW106z0C+lAFwDaX44h2mUb+YdLKTaX8pdSRw4L7CBli63czyi unihUvPy7562WckugVpWM/wPSAbgHB1KR/F6gB7x1FtEEJhCQ3YNnaYrR5AeRbWDZvjh BpYNSu2XZnd/5+QAN9VZhXWUw7/FgJdwoO1OKpNGvq8JEpjN8FjbcPh407X/AgMxL4E1 sfaxKYv7zDM79676geM/MrM7Uf9k/dODq+tpEj7FsUGwgeW3bsQZQmGu/bv69A/PyBzN bw8XfEpcdsOAeVHPusNHq5erOKmkqUJID6p4SOZWHrjPPKaTxBJ1xGvlk24mOYyks2W8 1JmA== X-Gm-Message-State: APjAAAWauQA/OTxe06RJQvsdy6yGJtD0reY622/SQmNZqrUAppDD3OEL zBtRUg/+xTD5f4O4h2NXmtg9r3pcLuZrJrjht9p/1DVE X-Google-Smtp-Source: APXvYqz6AvOO76ebl+p/wV2f00ipS1UEFG4Ha2AmocJzzqKaDSWOaS9qsn+EX+w2D97wlDUQ6ApdaZ6IRQ85FeLDm/Q= X-Received: by 2002:a17:90a:9903:: with SMTP id b3mr5696866pjp.80.1565136903772; Tue, 06 Aug 2019 17:15:03 -0700 (PDT) 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 References: <11147c49836aa1983da6a4a546fdf116@dyndn.es> <2332946.CxK0Tlp8m7@localhost> <86327492-b40a-fa37-83b3-c58b571b9685@spamtrap.tnetconsulting.net> <1589750.hRPUKH7mkQ@localhost> <7264cb95-6c1f-560b-e04e-2b9303e1485e@spamtrap.tnetconsulting.net> <20190806233908.4hofcmthqkxgddg3@matica.foolinux.mooo.com> In-Reply-To: <20190806233908.4hofcmthqkxgddg3@matica.foolinux.mooo.com> From: Rich Freeman Date: Tue, 6 Aug 2019 20:14:52 -0400 Message-ID: Subject: Re: [gentoo-user] Re: USE flag 'split-usr' is now global To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 9783e58f-9a80-4f2c-9221-994f8dc57bd4 X-Archives-Hash: 2329b9ae1e6ec5077d49afc51835bc91 On Tue, Aug 6, 2019 at 7:39 PM Ian Zimmerman wrote: > > On 2019-08-06 12:28, Rich Freeman wrote: > > > > Arguing against this trivial (and IMHO, elegant) solution is tilting > > > at windmills. Specially if it is for ideological reasons instead of > > > technical ones. > > > Some of the solutions I've seen tossed out in this thread are more > > complex than just building your own initramfs from scratch. > > > > An initramfs is just a userspace bootloader that runs on top of linux. > > Nobody has any problem with conventional bootloaders, and if you want > > to do anything with one of those you have to muck around in low-level > > C or assembly. > > There is a difference, and that difference is the reason I dislike > initramfs, not one of the other possible reasons you hypothesize. The > difference is that real Unix processes (not just kernel threads and not > just PID 1) survive from the initramfs stage into the "real Unix" > stage. It's like being able to trace matter back before the Big Bang. They only persist if you allow them to. Most implementations I've seen don't leave anything behind. Typically an initramfs will unlink everything inside, kill any stray processes (if it even forks anything in the first place), and then will exec the new init from the previous init. That starts up init as PID 1 with nothing else running, and no trace of the initramfs remaining. But, sure, you can stick a fork bomb in an initramfs and have it create 10GB of junk in the ramfs as well so that you boot up a crippled system if you really want to. Unless something has changed the kernel is actually built with an empty initramfs built-in by default which loads no matter what. So, the framework of an initramfs is always there, and the only thing that changes is whether it does anything. -- Rich