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-127843-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1R1iGB-000770-0L
for garchives@archives.gentoo.org; Thu, 08 Sep 2011 17:19:31 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id E548021C146;
Thu, 8 Sep 2011 17:19:21 +0000 (UTC)
Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181])
by pigeon.gentoo.org (Postfix) with ESMTP id B117E21C070
for <gentoo-user@lists.gentoo.org>; Thu, 8 Sep 2011 17:18:26 +0000 (UTC)
Received: by wyg36 with SMTP id 36so1017254wyg.40
for <gentoo-user@lists.gentoo.org>; Thu, 08 Sep 2011 10:18:25 -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=WdPvuSmPBawhJkZgv4W/n5lgJGUU9E0/taQO7LcIGrs=;
b=YvFd2KiDGvlJRft6Ym6VVuB9scLJVdz3hWjzotOy5xdNrubkIz9V0qmhVCvp7+Ni7P
QV4n0sr1ATTb8VH76HiVwvrDDPUh2TmcaL6ZIoE5jSqMnWzWnEmF/PNxrah8sRlpIQuc
ShNOwWXxOahiGrO/5Ywv/uqHDTZws2qyCI4LI=
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.216.71.76 with SMTP id q54mr90023wed.83.1315502305702; Thu, 08
Sep 2011 10:18:25 -0700 (PDT)
Received: by 10.216.39.140 with HTTP; Thu, 8 Sep 2011 10:18:25 -0700 (PDT)
In-Reply-To: <2110889.rUh24Q481G@pc>
References: <201108191109.34984.michaelkintzios@gmail.com>
<2799076.QhjHdal4hI@pc>
<CADPrc83uAXv37LP-bVSsNrqrRAfH_SO4ZzrkMxW9Q_Q5hK2+Sg@mail.gmail.com>
<2110889.rUh24Q481G@pc>
Date: Thu, 8 Sep 2011 13:18:25 -0400
Message-ID: <CADPrc83dY_4j9AB01s5UYFA30oR=TDnnKFbPD67Jin79wFUyyg@mail.gmail.com>
Subject: Re: [gentoo-user] /dev/sda* missing at boot
From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= <caneko@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: c4f0534497df5c4af55c0f13bd092184
On Thu, Sep 8, 2011 at 1:01 PM, Michael Schreckenbauer <grimlog@gmx.de> wro=
te:
> Am Donnerstag, 8. September 2011, 12:34:50 schrieb Canek Pel=C3=A1ez Vald=
=C3=A9s:
>> On Thu, Sep 8, 2011 at 12:06 PM, Michael Schreckenbauer <grimlog@gmx.de>
> wrote:
>> > Am Donnerstag, 8. September 2011, 11:13:58 schrieb Canek Pel=C3=A1ez V=
ald=C3=A9s:
>> >> On Thu, Sep 8, 2011 at 4:09 AM, Michael Schreckenbauer
>> >> <grimlog@gmx.de>
>> >
>> > wrote:
>> >> > Am Mittwoch, 7. September 2011, 23:33:35 schrieb Canek Pel=C3=A1ez =
Vald=C3=A9s:
>> >> >> I don't see any problem with an initramfs larger than the
>> >> >> kernel. It
>> >> >> will handle a lot of stuff. But if you don't want to change your
>> >> >> /boot partition, then don't upgrade to new kernels.
>> >> >
>> >> > How about accepting the fact, that there are a lot of things out
>> >> > there
>> >> > "you don't see"? Get over it. People have told a lot of valid
>> >> > reasons.
>> >> > They might not seem valid to you, but that's not their problem.
>> >>
>> >> Relax man, I keep saying that is *I* who don't see a valid reason.
>> >> That doesn't mean there is no valid reason; I thought that went
>> >> without saying. Sorry if it sounded like I was invalidating all you
>> >> guys reasons.
>> >>
>> >> My primary point was that, I *you* have your reasons to keep a
>> >> separated /usr, then by all means do it. You will only need an
>> >> initramfs.
>> >
>> > That's the point. You *need* an initramfs. You know KISS?
>>
>> If it's so "simple", write the code for support the option of not
>> having an initramfs. If it's not that simple, then what KISS are we
>> talking about?
>
> We already *have* the situation of not requiring initramfs for separate /=
usr.
> Mission accomplished.
> It's the upcoming change, that violates KISS. If udev cannot work properl=
y
> with separate /usr, fix udev not the FS-hierarchy. What next? Put /home i=
nto
> initramfs, because udev decides it cannot work without /home mounted?
Then don't upgrade. Keep doing only security updates.
Want the new cool stuff? Roll with the change.
>> >> > Have you *ever* thought about machines, that are not x86 or
>> >> > x86_64?
>> >> > Here's an intersting read:
>> >> > http://permalink.gmane.org/gmane.linux.gentoo.devel/72769
>> >>
>> >> No, I haven't thought about them, because I don't use them. What it
>> >> has to do with anything?
>> >
>> > Well, I linked a mail. MIPS is mentioned. As I read it, there are case=
s
>> > with MIPS, where the initramfs *has* to be built into the kernel *and*
>> > the kernel- image is size restricted. That's the problem with an
>> > initramfs bigger than the kernel itself.
>>
>> That's a MIPS restriction. Then with MIPS you will need to put /usr in
>> /, and problem solved.
>
> Solved? You call "no separate /usr on MIPS" a solution?
> How about existing installations? Ah, yes, don't upgrade.
There you go.
>> But no, everyone wants everything, and exactly
>> the way they want.
>
> It works now.
Exactly, and if you don't upgrade, it will work as long as you want.
>> Well, then they will need to write the code to support it, because no
>> developer is forced to support every single architecture in the whole
>> damn world, in every possible configuration available.
>>
>> >> >> Change happens.
>> >> >
>> >> > That's right. And sometimes these changes are simply bad ideas.
>> >>
>> >> If so you think, then write the code to support the *really good*
>> >> ideas.
>> >
>> > Ah. Criticism is only allowed, if you are writing the code. Not in my
>> > world, sorry.
>>
>> By all means, criticize as much as you want. What I meant by "If so
>> you think, then write the code to support the *really good* ideas" is
>> that you have the *option* to do that. You can of course complain
>> forever: that will not mean that anybody (and in particular the
>> developers) will listen.
>
> Not listening to users is a very bad idea.
No, they listen to users. They just don't listen too every user,
because that's impossible. Maybe I'm wrong, but I think your setup is
in the minority of use-cases. Who they should listen to?
>> Of course not. But, as with anything Open Source related, the ones
>> that write the support code will prevail. The complainers (if they
>> only complain) will not change anything.
>
> You keep talking about "complainers".
If someone complains and doesn't code, it's a complainer. By
definition. If someone complains and code, it's creating alternative
technologies.
> I'd say, we discuss things, as do the
> gentoo-devs on their list.
I agree. I'm subscribed to both.
>> My point is: if everything would be the other way around, and the
>> Gentoo (or kernel, or udev) developers decided that the True One Way
>> (TM) to do things were to separate / and /usr, I would do it. I did it
>> when me moved from ipchains to iptables, and that was particularly
>> painful because every single damn script just stopped working.
>
> Ah yes. What option was lost, when this switch happend?
> Nobody (I think) complains about some config changes. It's the removal of=
sane
> and valid options.
You cannot keep *EVERY* option supported. It's impossible. They grow a
lot really fast. You have to mark some things as "not supported".
Don't like it? Try alternative technologies.
>> But such is life: i didn't write the code. If I wanted to keep up with
>> development, I needed to change my way of doing things. I have rolled
>> with the change every single time since I started to use Linux in 1996
>> (damn, I'm old), and sometimes it bite you in the ass in the long run
>> (hello HAL!)
>>
>> But most of the times is for a good reason, and everything kinda
>> improves. And since I'm not writing code, just taking advantage of
>> getting it for free (as in beer and as in speech), I usually trust
>> developers. It usually pays off.
>
> How's needing an initramsfs for separate /usr an improvement?
With the initramfs you can do a lot of really cool stuff. I know it's
shallow, but I really like my plymouth-based splash screen.
>> Of course, sometimes it doesn't (hello devfs!), but what are you going
>> to do? Look a gift horse in the mouth?
>>
>> In the long term, trusting the developers usually it's the way to go.
>> Been here a long time, I stick to my guns. Don't like it? Well,
>> complain if you want, but if you don't writing some code it would
>> probably be for nothing.
>
> Yeah, "probably", that's why we discuss things.
Again, we can discuss (or complain) until the sun is red. As long as
we don't give code back, it's basically academic.
Regards.
--=20
Canek Pel=C3=A1ez Vald=C3=A9s
Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n
Universidad Nacional Aut=C3=B3noma de M=C3=A9xico