On Tue, 18 Dec 2012 17:55:16 -0500 Michael Mol <[email protected]> wrote:
> On Tue, Dec 18, 2012 at 9:33 AM, Alan McKinnon > <[email protected]> wrote: > > On Tue, 18 Dec 2012 09:08:53 -0500 > > Michael Mol <[email protected]> wrote: > > > > > > This sentence summarizes my understanding of your post nicely: > > > >> Now, why is /usr special? It's because it contains executable code > >> the system might require while launching. > > > > Now there are only two approaches that could solve that problem: > > > > 1. Avoid it entirely > > 2. Deal with it using any of a variety of bootstrap techniques > > > > #1 is handled by policy, whereby any code the system might require > > while launching is not in /usr. > > This is the solution I favor. Systemic structure which allows > dependency leakage is indicative (to me) of lack of foresight and > proper component role limitation, and ought to be fought. > > > > > #2 already has a solution, it's called an init*. Other solutions > > exist but none are as elegant as a throwaway temporary filesystem > > in RAM. > > I find virtually nothing elegant about a temporary filesystem in RAM. > It duplicates code that already exists on the system, and it > represents and additional maintenance step in system upgrades. It > seems almost a given that if someone is keeping multiple kernel images > on a system, they're not updating the initr* for each when binaries > that would be found in each are upgraded or rebuilt. You could level the same criticism at boot loaders... The also duplicate functionality in the main system they launch (albeit read-only at least in legacy grub) in the fs drivers, are only used briefly at boot-time and have to be maintained. True, the bootloader doesn't contain a *copy* of the main system files which is where the parallel breaks down. init* may well suck, but they suck less than any other possible solution. And they come with one more benefit - the community has agreed on how they work so they form a standard of sorts > > In Debian, Ubuntu and others, this is handled by a post-install hook > where the initr* image is rebuilt. To me, this honestly feels like a > hack. In something like Gentoo, I'd rather see package placement > driven by whether or not it will be needed to get all mount points > mounted. If that means i18n databases under something like /boot/data, > that seems reasonable. To me, the only cases where initr* feels like > the right solution are things like netboot or booting from read-only > media. Let's not forget the prime reason why init* exists - so that binary distros can boot and still have all kernel modules required at launch time compiled as modules. Bootstrap code and operation is ugly, always has been and always will be. It also tends to be inflexible unless you use a slipstreaming technique (my invented description of how init* works). I still think the solution is elegant given the real-world requirements imposed on systems. > > > > > I should be clear that I do not necessarily support Lennart's > > solutions, but I do support his perception of the problem (at least > > partially). We cannot support situations where *launch* code is > > haphazardly scattered in location X and this must always work for > > all values of X. We already have a remarkably parallel situation > > in /boot - in order to boot at all, the code running at that point > > in time needs to be able to find stuff, and it finds it (by policy) > > in what we will later call /boot. I see this /usr debate as the > > same thing on a larger scale. > > -- > :wq > -- Alan McKinnon [email protected]
