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 62D721381F3 for ; Sun, 29 Sep 2013 22:47:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2E098E0E53; Sun, 29 Sep 2013 22:47:42 +0000 (UTC) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DB413E0DD7 for ; Sun, 29 Sep 2013 22:47:40 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id my13so1730029bkb.35 for ; Sun, 29 Sep 2013 15:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lWavYDgzL4+bnD2hrt1O+GgRwGUTh7ojWlUVdAA6H9k=; b=Vqr7rIa2WdtVSDk03s4DDThOYSaNXdWrlc+H2i5GfXMxBfxzY0CM5jm9ACFvAxN0q9 ubl5qcWlzDHStGc+yBVWPVlMnUrFbm1CAwTv5Pvhj5OqzLCt0kUrF0HDfyRDEm5G0Y5Y hoPfsLJwzWc7V7Loyvx+FPQLebGc2lJ4rF6Dq9dUmYOEYCs3dlLmWtHDxRFIN+rd+oMk QLzqXC8BxeUOkaF6dHAMIuS8utbNP9GXjL0wJ1i0RbklzeH+8gPKQyaBOyTBnWt9rn8s CEy7OQxYubjm1tY3qduphFvcBOLtlBuAJ3FeDm3GoprMggE3wgoRA7ajPXerGb4Lp8aK Xmkg== X-Received: by 10.205.14.197 with SMTP id pr5mr16283382bkb.6.1380494859337; Sun, 29 Sep 2013 15:47:39 -0700 (PDT) Received: from [192.168.178.21] (p3E9E68D2.dip0.t-ipconnect.de. [62.158.104.210]) by mx.google.com with ESMTPSA id a4sm10514082bko.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Sep 2013 15:47:38 -0700 (PDT) Message-ID: <5248AE0A.5070603@googlemail.com> Date: Mon, 30 Sep 2013 00:47:38 +0200 From: Volker Armin Hemmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim References: <5246079E.7090406@gmail.com> <524761B4.60805@gmail.com> <20130929052937.GA30380@waltdnes.org> <201309290925.06893.michaelkintzios@gmail.com> <5247E4C2.5040502@gmail.com> <52480720.7070704@googlemail.com> <52480902.9040305@gmail.com> <52481602.6020305@googlemail.com> <52484363.7020309@gmail.com> <52484F5F.5090408@googlemail.com> <5248581F.7060902@gentoo.org> In-Reply-To: <5248581F.7060902@gentoo.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 69813c68-6bbd-4eb9-8c0e-11c118c69492 X-Archives-Hash: e8aeed5186b8790d173d1e06203c7e77 Am 29.09.2013 18:41, schrieb Francisco Blas Izquierdo Riera (klondike): > El 29/09/13 18:03, Volker Armin Hemmann escribió: >> Am 29.09.2013 17:12, schrieb Greg Woodbury: >>> On 09/29/2013 07:58 AM, Volker Armin Hemmann wrote: >>> >>>> things were broken way before that. As much as I hate systemd, it is not >>>> the root cause of the problem. >>>> >>>> The problems were caused by people saying that seperate /usr was a good >>>> idea, so / would not fill up and similar idiocies. The problems were >>>> caused by people saying that lvm is a good idea - for desktops. Those >>>> people who are fighting against the kernel auto assembling raids are to >>>> blame too. >>>> >>>> Systemd is just another point in a very long list. >>>> >>> The usr filesystem was separate from root from the very early days of >>> UNIX. Disks were *tiny* (compared to today) and spreading certain >>> things across separate spindles provided major benefits. Certainly, >>> the original need to require a separate usr went away fairly quickly, >>> but other benefits continued to encourage a seperation between root >>> and usr. >>> >> in the very early days /usr did not exist in the first space and was >> only created because someone added a harddisk. >> >> Not really a good reason to keep it around. > I'm going to show the lack of sense of this argument: > in the very early days linux did not exist in the first space and was > only created because someone got a 386. > > Not really a good reason to keep it around. wrong analogy and it goes down from here. Really. > > in the very early days GNU did not exist in the first space and was > only created because someone jammed a printer. > > Not really a good reason to keep it around. > > in the very early days Gentoo did not exist in the first space and was > only created because someone added a processor. > > Not really a good reason to keep it around. > > in the very early days hardening did not exist in the first space and was > only created because someone added security. > > Not really a good reason to keep it around. > > in the very early days Gnome did not exist in the first space and was > only created because someone got a graphics card. > > Not really a good reason to keep it around. > > I'm sure you'll be able to figure out the pattern there. > > Ohh and BTW, /usr was not just added because someone added a harddrive, > in most cases it was used to allow machines contain a very small system > on / which was enough to just boot and mount a networked system (/usr) > containing most of the software. This allowed for cheaper deployment of > machines since the hard drive could be smaller as it wouldn't need to > have all the data locally. Yeah, if this sounds familiar is because this > was later moved to initramfs. no, network'ed file systems came a lot later. Initially /usr was added because one harddisk was full. Really, that is the whole reason for its (broken) existance. > >>> The var filesystem was for variable system data, and was never >>> terribly big and its inclusion on the root volume happened. The home >>> filesystem became traditionally separate because data expands to fill >>> all availab;e space, and users collect *things* >> and a seperate /home does not create any problems. >> /var is much more prone to accidentally fill up then /usr ever was. > You are jst getting it wrong, /var was kept locally as the data there > was supposed to change from machine to machine. no, you just don't understand what I wrote. People told other people to keep /usr seperate so / may not fill up by accident. That advise always was murky at best. Outright stupid is a good description too. /usr is not prone to much changes. So if your / fits the contents of /usr just fine, there is pretty much no risk. /var on the other hand tends to explode - but a lot of people never got told to put /var on a seperate disk. If you ever realized that a tens of gigabyte logfile just made your box unbootable, you learnt a lot that day. >>> Networking made it possible to have home entirely off system, and >>> diskless worstations ruled for a while as well. >>> >>> By the time Linux came along, it had become common for boot volumes to >>> not be mounted during normal system operation, but the three >>> filesystem layout was common and workable. As Linux continued to be >>> like Topsy (she jest growed!) fragmentation started to occur as >>> "distributions" arose. The "balkanization" of Linux distributions >>> became a real concern to some and standardization offorts were >>> encouraged. >>> >>> The "File System Standard" (FSS) was renamed to the Filesystem >>> Hierarch Standard (FHS) and it was strongly based on the UNIX System V >>> definitions (which called for seperation of usr and root.) POSIX added >>> more layers and attempted to bring in the various BSD flavors. >>> >>> THe LSB (Linux Standards Base) effort was conceived as supersceeding >>> all the other efforts, and FHS was folded into the LSB definition. Yet >>> even then a separate root and usr distinction survived. Then things >>> started falling apart again - POSIX rose like a phoenix and even the >>> Windows/wintel environment could claim POSIX compliant behavior. The >>> fall of the LSB effort really became evident when the FHS was gutted >>> and certain major players decided to ignore the LSB recommendations. >> too bad POSIX is much older than LSB or FHS. > Too bad separate /usr is much older than initramfs. too bad that initramfs and initrd are pretty good solutions to the problem of hidden breakage caused by seperate /usr. If you are smart enough to setup an nfs server, I suppose you are smart enough to run dracut/genkernel&co. >>> As a result, the GNOME Alliance has shattered. The main GNOME army >>> marches on its unfathomable path, and various large chunks have broke >>> off in their own directions (e.g. Cinnamon and Mate) seeking to remain >>> flexible and not incompatible with the KDE and other lesser DE folks. >>> >>> It is truly layable at the feet of the GNOME folks, the breakage of >>> the root and usr filesystem separability is all derived from the GNOME >>> camp. >>> These changes may not, in fact, be deliberate or intended to "defeat" >>> Microsoft, but Ockham's Razor cuts and intentionality is the simpler >>> explanation. >> that gnome is very hostile when it comes to KDE or choice is not news. >> And their dependency on systemd is just the usual madness. But they are >> not to blame for seperate /usr and the breakage it causes. > True, fingers here should be pointed into another direction like systemd. systemd is not the first package to break. >>> To come back to the thesis: robustness and flexibility are required >>> for good "health" and we are witnessing a dangerous challenge. >> what? that you need an initrd? That is so bad? > It may be, there is people which may not have enough free space ob /boot > for example. and now we are deeply into kidding territory. How small is that boot? 3mb? >> Are you kidding me? > I doubt it, instead you seem to be just trolling, see your own arguments well, I haven't seen any arguments from you so far. So who is the troll again? >>> [PS} If anybody cares, I was trained in both Computer Science and >>> Biological Science. and I can expand on the parallels if so desired. >>> >> no thank you. But if I might add one: you are making an elephant out of >> a gnat. > To me it looks like youu are making a gnat out of an elephant. what is the elephant? Running an extra command on kernel updates? >