From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E296E1381FB for ; Tue, 25 Dec 2012 03:58:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 488E4E07E0; Tue, 25 Dec 2012 03:58:36 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B5869E07BD for ; Tue, 25 Dec 2012 03:56:54 +0000 (UTC) Received: from mail-da0-f42.google.com ([209.85.210.42]:56380) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1TnLdO-001S4i-2Z for gentoo-user@lists.gentoo.org; Tue, 25 Dec 2012 10:56:54 +0700 Received: by mail-da0-f42.google.com with SMTP id z17so3385444dal.1 for ; Mon, 24 Dec 2012 19:56:52 -0800 (PST) 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 MIME-Version: 1.0 Received: by 10.66.79.195 with SMTP id l3mr68329880pax.82.1356407812748; Mon, 24 Dec 2012 19:56:52 -0800 (PST) Received: by 10.68.248.66 with HTTP; Mon, 24 Dec 2012 19:56:52 -0800 (PST) Received: by 10.68.248.66 with HTTP; Mon, 24 Dec 2012 19:56:52 -0800 (PST) In-Reply-To: <20121224204817.335033c6@khamul.example.com> References: <50CB1942.3020900@gmail.com> <50CB4A3C.1030109@gmail.com> <50CB5406.7040404@gmail.com> <8738z7hgsa.fsf@ist.utl.pt> <20121216171043.71084070@khamul.example.com> <20121217104621.735bf43a@khamul.example.com> <20121218163332.7956f31a@khamul.example.com> <87txrd6pb3.fsf@ist.utl.pt> <20121223182037.1553813f@khamul.example.com> <87bodk7lb6.fsf@ist.utl.pt> <20121224085528.56f535ec@khamul.example.com> <50D85167.9060309@gmail.com> <20121224204817.335033c6@khamul.example.com> Date: Tue, 25 Dec 2012 10:56:52 +0700 Message-ID: Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=f46d04287a17d975ed04d1a54d6e X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Get-Message-Sender-Via: svr-us4.tirtonadi.com: authenticated_id: rileyer+pandu.poluan.info/only user confirmed/virtual account not confirmed X-Archives-Salt: 73311935-b1d2-44a8-a86e-d3af0e62a5f6 X-Archives-Hash: 7c977e8d4644def6cd77a9351bb2e6c0 --f46d04287a17d975ed04d1a54d6e Content-Type: text/plain; charset=UTF-8 On Dec 25, 2012 1:55 AM, "Alan McKinnon" wrote: > > On Mon, 24 Dec 2012 06:58:15 -0600 > Dale wrote: > > The truth is simply this (derived from empirical observation): > > Long ago we had established conventions about / and /usr; mostly > because the few sysadmins around agreed on some things. In those days > there was no concept of a packager or maintainer, there was only a > sysadmin. This person was a lot like me - he decided and if you didn't > like it that was tough. So things stayed as they were for a very long > time. > The convention stuck for a loooooong time because it works, it's reasonable, and it does not place unduly restrictions on the SysAdmin. Even back when hard disks are a mote in the eyes of today's mammoths, you *can* make /usr part of /, there's no stopping you. Sure, other SysAdmins may scoff and/or question your sanity, but the choice is yours. YOU know what's best for your precious servers, YOU made the call. But with the latest udev, Lennart et al saw it fit to yank that choice out of the hands of SysAdmins, while at the same time trying to enforce a stupidly overbloated init replacement. > Thankfully, it is not like that anymore and the distinction between > / and /usr is now so blurry there might as well not be a distinction. > Which is good as the distinction wasn't exactly a good thing from day > 1 either - it was useful for terminal servers (only by convention) and > let the sysadmin keep his treasured uptime (which only proves he isn't > doing kernel maintenance...) > When you're in charge of over 100 servers as the back-end of a multinational company that has a revenue in excess of 10 million USD per day, even a temporary outage means the CIO, COO, and CEO breathing down your neck. There's an adage: If it ain't broke, don't fix it. > I'm sorry you bought into the crap about / and /usr that people of my > ilk foisted on you, but the time for that is past, and things move on. > If there is to be a convention, there can be only one that makes any > sense: > > / and /usr are essentially the same, so put your stuff anywhere you > want it to be. ironically this no gives you the ultimate in choice, not > the false one you had for years. So if your /usr is say 8G, then > enlarge / bu that amount, move /usr over and retain all your mount > points as the were. Now for the foreseeable future anything you might > want to hotplug at launch time stands a very good chance of working as > expected. > No. I prefer any mucking in /usr to have as small effect as possible to / That I what SysAdmins worth their salary do: compartment everything. Reduce interdependencies as much as possible. > The design of separate / and /usr on modern machines IS broken by > design. It is fragile and causes problems in the large case. This > doesn't mean YOUR system is broken and won't boot, it means it causes > unnecessary hassle in the whole ecosystem, and the fix is to change > behaviour and layout to something more appropriate to what we have > today. > The way I see it, it's /usr integrated into / that introduces fragility. Too much going on in / In case you haven't noticed, since Windows 7 (or Vista, forget which) Microsoft has even went the distance of splitting between C: (analogous to /usr) and 'System Partition' (analogous to /). The boot process is actually handled by the 100ish MB 'System Partition' before being handed to C:. This will at least give SysAdmins a fighting chance of recovering a botched maintenance. (Note: Said behavior will only be visible if installing onto a clean hard disk. If there are partitions left over from previous Windows installs, Win7 will not create a separate 'System Partition') So, if Microsoft saw the light, why does Red Hat sunk into darkness instead? > -- > Alan McKinnon > alan.mckinnon@gmail.com > > Rgds, -- --f46d04287a17d975ed04d1a54d6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 25, 2012 1:55 AM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> On Mon, 24 Dec 2012 06:58:15 -0600
> Dale <rdalek1967@gmail.com<= /a>> wrote:
>
> The truth is simply this (derived from empirical observation):
>
> Long ago we had established conventions about / and /usr; mostly
> because the few sysadmins around agreed on some things. In those days<= br> > there was no concept of a packager or maintainer, there was only a
> sysadmin. This person was a lot like me - he decided and if you didn&#= 39;t
> like it that was tough. So things stayed as they were for a very long<= br> > time.
>

The convention stuck for a loooooong time because it works, it's rea= sonable, and it does not place unduly restrictions on the SysAdmin.

Even back when hard disks are a mote in the eyes of today's mammoths= , you *can* make /usr part of /, there's no stopping you. Sure, other S= ysAdmins may scoff and/or question your sanity, but the choice is yours. YO= U know what's best for your precious servers, YOU made the call.

But with the latest udev, Lennart et al saw it fit to yank that choice o= ut of the hands of SysAdmins, while at the same time trying to enforce a st= upidly overbloated init replacement.

> Thankfully, it is not like that anymore and the distinction between=
> / and /usr is now so blurry there might as well not be a distinction.<= br> > Which is good as the distinction wasn't exactly a good thing from = day
> 1 either - it was useful for terminal servers (only by convention) and=
> let the sysadmin keep his treasured uptime (which only proves he isn&#= 39;t
> doing kernel maintenance...)
>

When you're in charge of over 100 servers as the back-end of a multi= national company that has a revenue in excess of 10 million USD per day, ev= en a temporary outage means the CIO, COO, and CEO breathing down your neck.=

There's an adage: If it ain't broke, don't fix it.

> I'm sorry you bought into the crap about / and /usr that people= of my
> ilk foisted on you, but the time for that is past, and things move on.=
> If there is to be a convention, there can be only one that makes any > sense:
>
> / and /usr are essentially the same, so put your stuff anywhere you > want it to be. ironically this no gives you the ultimate in choice, no= t
> the false one you had for years. So if your /usr is say 8G, then
> enlarge / bu that amount, move /usr over and retain all your mount
> points as the were. Now for the foreseeable future anything you might<= br> > want to hotplug at launch time stands a very good chance of working as=
> expected.
>

No. I prefer any mucking in /usr to have as small effect as possible to = /

That I what SysAdmins worth their salary do: compartment everything. Red= uce interdependencies as much as possible.

> The design of separate / and /usr on modern machines IS broken by > design. It is fragile and causes problems in the large case. This
> doesn't mean YOUR system is broken and won't boot, it means it= causes
> unnecessary hassle in the whole ecosystem, and the fix is to change > behaviour and layout to something more appropriate to what we have
> today.
>

The way I see it, it's /usr integrated into / that introduces fragil= ity. Too much going on in /

In case you haven't noticed, since Windows 7 (or Vista, forget which= ) Microsoft has even went the distance of splitting between C: (analogous t= o /usr) and 'System Partition' (analogous to /). The boot process i= s actually handled by the 100ish MB 'System Partition' before being= handed to C:. This will at least give SysAdmins a fighting chance of recov= ering a botched maintenance.

(Note: Said behavior will only be visible if installing onto a clean har= d disk. If there are partitions left over from previous Windows installs, W= in7 will not create a separate 'System Partition')

So, if Microsoft saw the light, why does Red Hat sunk into darkness inst= ead?

> --
> Alan McKinnon
> alan.mckinnon@gmail.com=
>
>

Rgds,
--

--f46d04287a17d975ed04d1a54d6e--