From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-user+bounces-127856-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1R1kQd-0001uw-QO
for garchives@archives.gentoo.org; Thu, 08 Sep 2011 19:38:28 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id C098B21C1AB;
Thu, 8 Sep 2011 19:38:18 +0000 (UTC)
Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53])
by pigeon.gentoo.org (Postfix) with ESMTP id ECEBC21C050
for <gentoo-user@lists.gentoo.org>; Thu, 8 Sep 2011 19:37:21 +0000 (UTC)
Received: by bkbzs8 with SMTP id zs8so1297909bkb.40
for <gentoo-user@lists.gentoo.org>; Thu, 08 Sep 2011 12:37:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=tzWwu/0mLevsWPmZ89sjuRjl6R+7xAKWhL5dDh4YNlQ=;
b=i/cSnYgSglUf/ifO3u2TfOOgkwII12WWD2YAAqo+1h08d0pfvoSm7wG+y0Oh3eDoTN
TcLpHQzv5JKxx8+oDJrJayFd/r+OU6T9gEb4MLTWv+Ls+wYNF0RKh4fJeycCEhxhIJT1
k6rfS0ePOJK0pb9Y9I2gL6gMX/zNu4KxUElsU=
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.204.148.67 with SMTP id o3mr796063bkv.258.1315510640997; Thu,
08 Sep 2011 12:37:20 -0700 (PDT)
Received: by 10.204.155.79 with HTTP; Thu, 8 Sep 2011 12:37:20 -0700 (PDT)
In-Reply-To: <CADPrc82jySYbNgPvABxPxPJnjsKY4v3EzoksVSm6aUKZ2s8jhw@mail.gmail.com>
References: <201108191109.34984.michaelkintzios@gmail.com>
<2799076.QhjHdal4hI@pc>
<CADPrc83uAXv37LP-bVSsNrqrRAfH_SO4ZzrkMxW9Q_Q5hK2+Sg@mail.gmail.com>
<2110889.rUh24Q481G@pc>
<CADPrc83dY_4j9AB01s5UYFA30oR=TDnnKFbPD67Jin79wFUyyg@mail.gmail.com>
<CA+czFiDdg=Lqcwn3t8ouRytaLBdtWsoNosey=UfwvA-XNa+ZoQ@mail.gmail.com>
<CADPrc82jySYbNgPvABxPxPJnjsKY4v3EzoksVSm6aUKZ2s8jhw@mail.gmail.com>
Date: Thu, 8 Sep 2011 15:37:20 -0400
Message-ID: <CA+czFiCPRQdiUNi6fkuGaiCn3YwYygO1HGs8a-6ijv_smXqQuw@mail.gmail.com>
Subject: Re: [gentoo-user] /dev/sda* missing at boot
From: Michael Mol <mikemol@gmail.com>
To: gentoo-user@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt:
X-Archives-Hash: 3f3c3ed94993265fd48f87663485bde6
On Thu, Sep 8, 2011 at 3:00 PM, Canek Pel=C3=A1ez Vald=C3=A9s <caneko@gmail=
.com> wrote:
> On Thu, Sep 8, 2011 at 1:45 PM, Michael Mol <mikemol@gmail.com> wrote:
>> This isn't a discussion. This is a bunch of people offering
>> displeasure, ideas and/or thoughts, and one person saying, "hey,
>> nothing I can do. I trust the devs."
>
> I disagree: I'm not saying trust the devs and shut up. I'm trying to
> explain why *I* trust the devs and why *I* think is for the best for
> someone else to do it. Nobody needs to agree with me, of course, I'm
> just trying to explain my POV.
>
>> A discussion is when there's an interchange of ideas, arguments,
>> counterarguments, and the fleshing out of a new framework of thought.
>> That kind of point/counterpoint is *vital* for architectural
>> foresight. All I keep reading from you is, "if you think that will
>> work, go write it." *No* writing for a problem of this scope is
>> warranted without some extensive discussion, noting of edge cases and
>> planning around the same.
>
> Sorry you read that way; I keep trying to explain why I don't find a
> separated /usr a necessity and why I don't think an initramfs is such
> a big problem.
The rhythmic baseline of your explanation is "and you can use an
initramfs for that." I haven't seen much in argument for why initramfs
isn't a problem apart from your expectation that the *kernel* will
eventually require it, and dracut theoretically solve the problem of
updating initrd. (Which sounds nice, but it's yet another moving part
in the system, and another point of failure.)
>> People have been pointing out edge cases, use cases which are being
>> disregarded, etc, and pretty much all they're getting back is "I don't
>> see those as valid."
>
> And I have =C2=A0tried to explain why it's not economically feasible to
> support every architecture and every set of configurations.
Which I think has been firmly explained in at least two different
threads; dev time is not infinite, sure.
> Yeah, the only two solutions I see is either roll up with the change, or
> maintain it yourself.
If those are the only two solutions you see, I suspect you're not
looking hard enough. If udev's problem is that it's running arbitrary
programs, then perhaps a recognizable constraint needs to be made on
what programs udev should run. I thought the primary reason we had
/{,s}bin and /usr/{,s}bin was to differentiate between system-vital
programs and other programs.
> That people don't like the answer doesn't mean is not true.
There's also no solid evidence that it's true, either. I remember when
sysfs came about. Linux Journal's diff -u column described it as a
herculean effort accomplishing something the majority of kernel devs
thought impossible or not worth the time. I rather like sysfs, but at
one time, it was the thing very few people thought was in the possible
set of solutions.
>> Granted, you're kinda painting a target on your
>> back by being the only one defending upstream's decision here
>
> Someone has to. I've been using Gentoo almost eight years now, and I
> usually don't participate in the dicussions, but I have seen in the
> last years a trend to criticize the devs without actually considering
> the alternatives.
People are beginning to consider alternatives, but you've shot them
down without offering improvements, suggesting adjustments or even
pointing out specific flaws. As a result, you come across as something
akin to a fanboy with your mind already made up, which just seems
*bizarre*.
>
> Sometimes the devs do stupid things; but most of the times they really
> think and come to a solution. And the affected users usually just see
> how that solution affects them in the short term, instead of trying to
> see the big picture and how affects the whole distribution, the
> community, and the technological path that Linux is following.
For being irritated that people aren't seeing it, you haven't been
clarifying it much.
>>, but
>> when someone pointed at an already-existing alternative, you simply
>> said, "I doubt that'll be the solution."
>
> And I doubt it. But I also said that they are more than welcome to try
> wathever they want. I think the way I think; that's the whole point of
> me trying to communicate it here.
That much is appreciated, but you didn't say *why* you doubt that'll
be the solution. Downvotes aren't debate, nor are they discussion.
They're expressions of dissatisfaction.
>> As for me, this will be a royal inconvenience, and may require the
>> rebuilding of my primary machine. Still, I can deal. It'll mean
>> learning how to build initramfs*, how to make sure it contains the
>> needed tools, and probably a half-dozen other things I didn't even see
>> coming when I set up this box last fall.
>
> I compile my own kernels (no genkernel for me). I don't use modules
> (except for the stupid scsi_wait_scan), and I didn't used an initramfs
> until I started using systemd. The arguments for using it convinced
> me, and I made the switch in all my machines.
>
> I don't see why it would require to "rebuild" your primary machine,
> but I don't know your configuration. I know that any sane
> configuration would only require to install dracut and modify a line
> in grub. Maybe a kernel rebuild.
My / isn't large enough to hold /usr.
>> * I've avoided it for ten years it was a grossly unnecessary
>> complexity for my systems. Now it sounds like it'll become a
>> necessity.
>
> Apparently. But is not "grossly" unnecessary: udev need it, and udev
> solves a kinda complicated problem. Maybe mdev can solve it in a
> simpler way.
>
> But again, I doubt it.
One question: Why? Are there specific technical reasons to your
doubts, or is it simply confidence that the devs are more likely to
have made a good choice than a bad choice?
--=20
:wq