[gentoo-user] Apologize to everyone for my nonprofessional

[gentoo-user] Apologize to everyone for my nonprofessional

[Lavender]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

First of all I think I should apologize for my poor English , you must be very painful to read my letters.
I'm a Chinese student and my English is not very well , actually  it's suck. So I will pay attention to making
letters more clear to understand. 
 
To be honest, I'm not good at writing e-mails as most Chinese does . We almost don't use e-mail . I know
the letters I send don't have a clear subject and its contents are verbose , so I'm really sorry , I won't do that
any longer.
 
Michael Mol , you're right , I should reply in time, but you know it is 11:00 pm here when it is 7:00 am or 8:00 am in
your place , maybe I went to bed and forgot this next morning . But it's not an excuse for me , so I will note it .
 
You said there're no line-breaks in my letters , I'm not very clear about this, can you send a screenshot for me ? 
It is all normall in my mailbox . 
 
At last I want to explain why I don't try some methods you provide . I like to reach the essence of one thing , I want 
to know exactly why it should be this but not that . So the letters I reply become more and more simple , I will control myself to reply
clearly.

[-- Attachment #2: Type: text/html, Size: 1596 bytes --]

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]

On Fri, Oct 14, 82011 at 11:43 AM, Lavender <448463782@qq.com> wrote:
> First of all I think I should apologize for my poor English , you must be
> very painful to read my letters.
> I'm a Chinese student and my English is not very well , actually  it's suck.
> So I will pay attention to making
> letters more clear to understand.
>
> To be honest, I'm not good at writing e-mails as most Chinese does . We
> almost don't use e-mail . I know
> the letters I send don't have a clear subject and its contents are verbose ,
> so I'm really sorry , I won't do that
> any longer.

Very much appreciated!

>
> Michael Mol , you're right , I should reply in time, but you know it
> is 11:00 pm here when it is 7:00 am or 8:00 am in
> your place , maybe I went to bed and forgot this next morning . But it's not
> an excuse for me , so I will note it .

Hey, we've all got lives outside this mailing list. Except Dale, perhaps. :)

>
> You said there're no line-breaks in my letters , I'm not very clear about
> this, can you send a screenshot for me ?
> It is all normall in my mailbox .

This one came across fine, but see the attached screenshot. (Not sure
if the list will filter it. If the attachment doesn't make it through,
I'll link to the file)

>
> At last I want to explain why I don't try some methods you provide . I like
> to reach the essence of one thing , I want
> to know exactly why it should be this but not that . So the letters I reply
> become more and more simple , I will control myself to reply
> clearly.

I hope your experiences on this mailing list help you refine your
language skills. Sounds like you're reasonably motivated. :)


-- 
:wq

[-- Attachment #2: No-line-breaks.PNG --]
[-- Type: image/png, Size: 30282 bytes --]

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Dale]

Michael Mol wrote:
> Hey, we've all got lives outside this mailing list. Except Dale, 
> perhaps. :)

A'right now.  I'm going to start on hal and /usr being on / again.  :-P

Dale

:-)  :-)

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:

> A'right now.  I'm going to start on hal and /usr being on / again.  :-P

Jeez, 43 years on and you're still going on about it...


-- 
Neil Bothwick

"Be strict when sending and tolerant when receiving."
 RFC 1958 - Architectural Principles of the Internet - section 3.9

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Dale]

Neil Bothwick wrote:
> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
>
>> A'right now.  I'm going to start on hal and /usr being on / again.  :-P
> Jeez, 43 years on and you're still going on about it...
>
>

Dang, I was only a year old when hal came out?  That just doubled my 
age.  It's closer to what I feel like tho.

I'm still not happy with /usr being required tho.  That is still 
standing on a bad nerve.  Don't worry tho, I got plenty of those bad 
nerves.  :-P

Dale

:-)  :-)

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Oct 15, 2011 5:49 AM, "Dale" <rdalek1967@gmail.com> wrote:
>
> Neil Bothwick wrote:
>>
>> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
>>
>>> A'right now.  I'm going to start on hal and /usr being on / again.  :-P
>>
>> Jeez, 43 years on and you're still going on about it...
>>
>>
>
> Dang, I was only a year old when hal came out?  That just doubled my age.
 It's closer to what I feel like tho.
>
> I'm still not happy with /usr being required tho.  That is still standing
on a bad nerve.  Don't worry tho, I got plenty of those bad nerves.  :-P
>

Do you know that there's a plan to move /var/run to / also? ;-)

Rgds,

[-- Attachment #2: Type: text/html, Size: 904 bytes --]

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

Pandu Poluan wrote:
>
>
> On Oct 15, 2011 5:49 AM, "Dale" <rdalek1967@gmail.com 
> <mailto:rdalek1967@gmail.com>> wrote:
> >
> > Neil Bothwick wrote:
> >>
> >> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
> >>
> >>> A'right now.  I'm going to start on hal and /usr being on / again. 
>  :-P
> >>
> >> Jeez, 43 years on and you're still going on about it...
> >>
> >>
> >
> > Dang, I was only a year old when hal came out?  That just doubled my 
> age.  It's closer to what I feel like tho.
> >
> > I'm still not happy with /usr being required tho.  That is still 
> standing on a bad nerve.  Don't worry tho, I got plenty of those bad 
> nerves.  :-P
> >
>
> Do you know that there's a plan to move /var/run to / also? ;-)
>
> Rgds,
>


Now someone on here swears up and down that /var isn't going to be 
required on /.  I'm telling ya'll, /home is coming.  We are going to end 
up where we can only have one drive in our Linux boxes for the OS and 
its relatives.  That or we will ALL have to start using the pesky init* 
thingy.

I got 7 acres of land here, complete with trees.  If someone can find 
the dev that started this mess, I can find some rope.  Just saying.  
;-)  Oh, I live half a mile from the river too.  Makes for a good dump 
site.  lol

I noticed the other day that when LVM tries to start, it fails.  I have 
/var on a separate partition here.  It was complaining about something 
on /var missing.  So, you may be late in reporting this.  I think it is 
already needed for LVM if /usr or /var is on a separate partition.

< sighs >

Dale

:-)  :-)

[-- Attachment #2: Type: text/html, Size: 2453 bytes --]

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

On Oct 15, 2011 1:58 PM, "Dale" <rdalek1967@gmail.com> wrote:
>
> Pandu Poluan wrote:
>>
>>
>> On Oct 15, 2011 5:49 AM, "Dale" <rdalek1967@gmail.com> wrote:
>> >
>> > Neil Bothwick wrote:
>> >>
>> >> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
>> >>
>> >>> A'right now.  I'm going to start on hal and /usr being on / again.
 :-P
>> >>
>> >> Jeez, 43 years on and you're still going on about it...
>> >>
>> >>
>> >
>> > Dang, I was only a year old when hal came out?  That just doubled my
age.  It's closer to what I feel like tho.
>> >
>> > I'm still not happy with /usr being required tho.  That is still
standing on a bad nerve.  Don't worry tho, I got plenty of those bad nerves.
 :-P
>> >
>>
>> Do you know that there's a plan to move /var/run to / also? ;-)
>>
>> Rgds,
>
>
>
> Now someone on here swears up and down that /var isn't going to be
required on /.  I'm telling ya'll, /home is coming.  We are going to end up
where we can only have one drive in our Linux boxes for the OS and its
relatives.  That or we will ALL have to start using the pesky init* thingy.
>
> I got 7 acres of land here, complete with trees.  If someone can find the
dev that started this mess, I can find some rope.  Just saying.  ;-)  Oh, I
live half a mile from the river too.  Makes for a good dump site.  lol
>

Hey, good idea! Perhaps we can start from udev's dev? :-D

> I noticed the other day that when LVM tries to start, it fails.  I have
/var on a separate partition here.  It was complaining about something on
/var missing.  So, you may be late in reporting this.  I think it is already
needed for LVM if /usr or /var is on a separate partition.
>
> < sighs >
>

Well, I don't know about the rest of /var, but bug #381783 explicitly said
that 'some people' are thinking of making /var/run a symlink to /run...

(not me! I swear! Please don't hang the messenger...)

Rgds,

[-- Attachment #2: Type: text/html, Size: 2556 bytes --]

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Fri, Oct 14, 2011 at 11:56 PM, Dale <rdalek1967@gmail.com> wrote:
> Pandu Poluan wrote:
>
> On Oct 15, 2011 5:49 AM, "Dale" <rdalek1967@gmail.com> wrote:
>>
>> Neil Bothwick wrote:
>>>
>>> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
>>>
>>>> A'right now.  I'm going to start on hal and /usr being on / again.  :-P
>>>
>>> Jeez, 43 years on and you're still going on about it...
>>>
>>>
>>
>> Dang, I was only a year old when hal came out?  That just doubled my age.
>>  It's closer to what I feel like tho.
>>
>> I'm still not happy with /usr being required tho.  That is still standing
>> on a bad nerve.  Don't worry tho, I got plenty of those bad nerves.  :-P
>>
>
> Do you know that there's a plan to move /var/run to / also? ;-)
>
> Rgds,
>
>
> Now someone on here swears up and down that /var isn't going to be required
> on /.

/var != /var/run
/var != /var/lock

/var/run is going in /run, but /var/run (by definition) only contains
things like PID files and runtime sockets. In the same vein, /var/lock
also is going into /run/lock. I have acknowledged this from the very
beginning, and I have been pointing out that implying that because
those two (really small and bounded) directories of /var are going
into /run and /run/lock, it doesn't mean that the whole /var will go
into /. That is disinformation.

Nobody has even proposed that /var should go into the same partition
as /. *Nobody*, and the simplest proof of that is that nobody has
produced a single proof to the contrary. Not a single email, blog
post, or wiki entry from any system developer even mentions the
possibility of requiring /var to be in the same partition as /.

Whoever says that /var will be required to be on the same partition as
/ is either wildly speculating, or spreading FUD.

> I'm telling ya'll, /home is coming.

That is just ridiculous.

>  We are going to end up where we
> can only have one drive in our Linux boxes for the OS and its relatives.

And so is this: more FUD.

> That or we will ALL have to start using the pesky init* thingy.

More FUD: the current proposal (from Zac, the principal coder of
portage, and someone who actually wrotes code and know what he is
talking about) is this:

http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml

It basically removes the need for a "pesky init* thingy", although for
the life of me I cannot understand why someone will not see the
technical advantages of actually using an initramfs.

> I got 7 acres of land here, complete with trees.  If someone can find the
> dev that started this mess, I can find some rope.  Just saying.  ;-)  Oh, I
> live half a mile from the river too.  Makes for a good dump site.  lol
>
> I noticed the other day that when LVM tries to start, it fails.  I have /var
> on a separate partition here.  It was complaining about something on /var
> missing.  So, you may be late in reporting this.  I think it is already
> needed for LVM if /usr or /var is on a separate partition.

Again, get the facts right. If you use LVM you will need to use an
initramfs. If you only use a separated /usr you will be able to use
Zac's proposal.

In no case whatsoever you will be required to have /var on the same
partition as /. Nobody has ever proposed that. /run and /run/lock are
not /var.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 12:34 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Fri, Oct 14, 2011 at 11:56 PM, Dale <rdalek1967@gmail.com> wrote:
>> Pandu Poluan wrote:
>>
>> On Oct 15, 2011 5:49 AM, "Dale" <rdalek1967@gmail.com> wrote:
>>>
>>> Neil Bothwick wrote:
>>>>
>>>> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
>>>>
>>>>> A'right now.  I'm going to start on hal and /usr being on / again.  :-P
>>>>
>>>> Jeez, 43 years on and you're still going on about it...
>>>>
>>>>
>>>
>>> Dang, I was only a year old when hal came out?  That just doubled my age.
>>>  It's closer to what I feel like tho.
>>>
>>> I'm still not happy with /usr being required tho.  That is still standing
>>> on a bad nerve.  Don't worry tho, I got plenty of those bad nerves.  :-P
>>>
>>
>> Do you know that there's a plan to move /var/run to / also? ;-)
>>
>> Rgds,
>>
>>
>> Now someone on here swears up and down that /var isn't going to be required
>> on /.
>
> /var != /var/run
> /var != /var/lock
>
> /var/run is going in /run, but /var/run (by definition) only contains
> things like PID files and runtime sockets. In the same vein, /var/lock
> also is going into /run/lock. I have acknowledged this from the very
> beginning, and I have been pointing out that implying that because
> those two (really small and bounded) directories of /var are going
> into /run and /run/lock, it doesn't mean that the whole /var will go
> into /. That is disinformation.

I finally found the link (got confused by gmane interface):

http://article.gmane.org/gmane.linux.gentoo.user/246892

Quoting myself (from more than one month ago):

"Saying that proposing /run and /lock to be available at boot time
means that in the future a separated /var partition could be not
supported is, in my book, disinformation. /var/run and /var/lock (by
definition) are almost empty (in space). /var/lib usually stores whole
databases. The difference is important and relevant."

Stop the fear mongering. If you jump into using an initramfs, then
every single configuration on the planet (and on the future) will be
supported, and it actually has its advantages to use said initramfs.
If for irrational fear of using an initramfs, and your system is
simple enough (where "simple" does not include LVM, NFS, and stuff
like that), then you will be able to use Zac's proposal.

In either case, /var will be always possible to have on a separated
partition, and that is actually the recommended setup.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Michael Schreckenbauer]

Hi Canek,

On Saturday, 15. October 2011 00:50:22 Canek Peláez Valdés wrote:
> On Sat, Oct 15, 2011 at 12:34 AM, Canek Peláez Valdés <caneko@gmail.com> 
wrote:
> > On Fri, Oct 14, 2011 at 11:56 PM, Dale <rdalek1967@gmail.com> wrote:
> >> Pandu Poluan wrote:
> >> 
> >> On Oct 15, 2011 5:49 AM, "Dale" <rdalek1967@gmail.com> wrote:
> >>> Neil Bothwick wrote:
> >>>> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
> >>>>> A'right now.  I'm going to start on hal and /usr being on /
> >>>>> again.  :-P>>>> 
> >>>> Jeez, 43 years on and you're still going on about it...
> >>> 
> >>> Dang, I was only a year old when hal came out?  That just doubled my
> >>> age. It's closer to what I feel like tho.
> >>> 
> >>> I'm still not happy with /usr being required tho.  That is still
> >>> standing on a bad nerve.  Don't worry tho, I got plenty of those
> >>> bad nerves.  :-P>> 
> >> Do you know that there's a plan to move /var/run to / also? ;-)
> >> 
> >> Rgds,
> >> 
> >> 
> >> Now someone on here swears up and down that /var isn't going to be
> >> required on /.
> > 
> > /var != /var/run
> > /var != /var/lock
> > 
> > /var/run is going in /run, but /var/run (by definition) only contains
> > things like PID files and runtime sockets. In the same vein, /var/lock
> > also is going into /run/lock. I have acknowledged this from the very
> > beginning, and I have been pointing out that implying that because
> > those two (really small and bounded) directories of /var are going
> > into /run and /run/lock, it doesn't mean that the whole /var will go
> > into /. That is disinformation.
> 
> I finally found the link (got confused by gmane interface):
> 
> http://article.gmane.org/gmane.linux.gentoo.user/246892
> 
> Quoting myself (from more than one month ago):
> 
> "Saying that proposing /run and /lock to be available at boot time
> means that in the future a separated /var partition could be not
> supported is, in my book, disinformation. /var/run and /var/lock (by
> definition) are almost empty (in space). /var/lib usually stores whole
> databases. The difference is important and relevant."

and you still did not look into /var/lib to see, what is actually in there?
My systems has directories alsa, bluetooth, hp and many more there that are 
not databases at all.
Stop spreading this misinformation, please.

> Regards.

Best,
Michael

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 1:35 AM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> Hi Canek,

Hi Michael.

> On Saturday, 15. October 2011 00:50:22 Canek Peláez Valdés wrote:
>> On Sat, Oct 15, 2011 at 12:34 AM, Canek Peláez Valdés <caneko@gmail.com>
> wrote:
>> > On Fri, Oct 14, 2011 at 11:56 PM, Dale <rdalek1967@gmail.com> wrote:
>> >> Pandu Poluan wrote:
>> >>
>> >> On Oct 15, 2011 5:49 AM, "Dale" <rdalek1967@gmail.com> wrote:
>> >>> Neil Bothwick wrote:
>> >>>> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
>> >>>>> A'right now.  I'm going to start on hal and /usr being on /
>> >>>>> again.  :-P>>>>
>> >>>> Jeez, 43 years on and you're still going on about it...
>> >>>
>> >>> Dang, I was only a year old when hal came out?  That just doubled my
>> >>> age. It's closer to what I feel like tho.
>> >>>
>> >>> I'm still not happy with /usr being required tho.  That is still
>> >>> standing on a bad nerve.  Don't worry tho, I got plenty of those
>> >>> bad nerves.  :-P>>
>> >> Do you know that there's a plan to move /var/run to / also? ;-)
>> >>
>> >> Rgds,
>> >>
>> >>
>> >> Now someone on here swears up and down that /var isn't going to be
>> >> required on /.
>> >
>> > /var != /var/run
>> > /var != /var/lock
>> >
>> > /var/run is going in /run, but /var/run (by definition) only contains
>> > things like PID files and runtime sockets. In the same vein, /var/lock
>> > also is going into /run/lock. I have acknowledged this from the very
>> > beginning, and I have been pointing out that implying that because
>> > those two (really small and bounded) directories of /var are going
>> > into /run and /run/lock, it doesn't mean that the whole /var will go
>> > into /. That is disinformation.
>>
>> I finally found the link (got confused by gmane interface):
>>
>> http://article.gmane.org/gmane.linux.gentoo.user/246892
>>
>> Quoting myself (from more than one month ago):
>>
>> "Saying that proposing /run and /lock to be available at boot time
>> means that in the future a separated /var partition could be not
>> supported is, in my book, disinformation. /var/run and /var/lock (by
>> definition) are almost empty (in space). /var/lib usually stores whole
>> databases. The difference is important and relevant."
>
> and you still did not look into /var/lib to see, what is actually in there?
> My systems has directories alsa, bluetooth, hp and many more there that are
> not databases at all.

So?

> Stop spreading this misinformation, please.

Which one? That /var is not going into /? It's not disinformation, it
is th true. If not, please be so kind of showin one single developer
reference that says so. One. Single. One.

Email, blog post, wiki, you choose it. But one single one.

Otherwise, stop speculating about an imaginary future, and stop
spreading disinformation and FUD.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Michael Schreckenbauer]

On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
> > /var/lib usually stores whole
> > databases. The difference is important and relevant."

> My systems has directories alsa, bluetooth, hp and many more
> there that are not databases at all.
> 
> So?
> Which one? That /var is not going into /?

No. That /var/lib contains databases. Is this so difficult to get?
On my system /var/lib/alsa contains data, that alsa uses to restore mixer-
levels. So *my* /var/lib is used during boot and *my* /var/lib has to be 
mounted by the initramfs. That's the situation on nearly every gentoo system 
using sound (systemd might handle this different, I have no idea)
Got it? Your system is not the center of the world.

> Regards.

Best,
Michael

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
>> > /var/lib usually stores whole
>> > databases. The difference is important and relevant."
>
>> My systems has directories alsa, bluetooth, hp and many more
>> there that are not databases at all.
>>
>> So?
>> Which one? That /var is not going into /?
>
> No. That /var/lib contains databases. Is this so difficult to get?

I get it; it's just not relevant.

> On my system /var/lib/alsa contains data, that alsa uses to restore mixer-
> levels.

Yeah, it does.

> So *my* /var/lib is used during boot and *my* /var/lib has to be
> mounted by the initramfs.

No, it doesn't. What are you talking about? Look at /etc/init.d/alsasound:

depend() {
        need localmount
        after bootmisc modules isapnp coldplug hotplug
}

Look at the first need from alsasound depend: it says, that it goes
after localmount. If you have /var in NFS (a very weird setup for a
desktop machine) maybe it will cause problems: but then it would be
fault of OpenRC (or the alsasound init script). If /var is on a
different partition, localmount will mount it and *then* alsasound
will execute.

And it makes sense: the volume restoring doesn't matter until
immediately before running gdm and going into the desktop; of course
you can mount /var before that.

>That's the situation on nearly every gentoo system
> using sound

Yeah, and as I explained, thanks to need localmount there is no problem.

>(systemd might handle this different, I have no idea)

Yeah, it does more intelligently: as I said, the volume restoring is
only needed just before starting X.

> Got it? Your system is not the center of the world.

No, but I start to think you don't know *your* system. Check the
alsasound init script.

The /var directory doesn't need to be on the same partition as /. Period.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Michael Schreckenbauer]

On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
> On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer <grimlog@gmx.de> 
wrote:
> > On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
> >> > /var/lib usually stores whole
> >> > databases. The difference is important and relevant."
> >> 
> >> My systems has directories alsa, bluetooth, hp and many more
> >> there that are not databases at all.
> >> 
> >> So?
> >> Which one? That /var is not going into /?
> > 
> > No. That /var/lib contains databases. Is this so difficult to get?
> 
> I get it; it's just not relevant.
> 
> > On my system /var/lib/alsa contains data, that alsa uses to restore
> > mixer- levels.
> 
> Yeah, it does.
> 
> > So *my* /var/lib is used during boot and *my* /var/lib has to be
> > mounted by the initramfs.
> 
> No, it doesn't. What are you talking about? Look at /etc/init.d/alsasound:
> 
> depend() {
>         need localmount
>         after bootmisc modules isapnp coldplug hotplug
> }
> 
> Look at the first need from alsasound depend: it says, that it goes
> after localmount. If you have /var in NFS (a very weird setup for a
> desktop machine) maybe it will cause problems: but then it would be
> fault of OpenRC (or the alsasound init script). If /var is on a
> different partition, localmount will mount it and *then* alsasound
> will execute.
> 
> And it makes sense: the volume restoring doesn't matter until
> immediately before running gdm and going into the desktop; of course
> you can mount /var before that.
> 
> >That's the situation on nearly every gentoo system
> >
> > using sound
> 
> Yeah, and as I explained, thanks to need localmount there is no problem.
> 
> >(systemd might handle this different, I have no idea)
> 
> Yeah, it does more intelligently: as I said, the volume restoring is
> only needed just before starting X.
> 
> > Got it? Your system is not the center of the world.
> 
> No, but I start to think you don't know *your* system. Check the
> alsasound init script.

*lol*
Now, this is getting ridiculous. I don't know my system? Have a look into
/lib/udev/rules.d/90-alsa-restore.rules
to realize, that this is a hack, that restores alsa-levels *twice* on systems 
that have /var/lib on /. The levels are supposed to be restored by *udev* not 
the script.

> The /var directory doesn't need to be on the same partition as /. Period.

> Regards
> .

Best,
Michael

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
>> On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer <grimlog@gmx.de>
> wrote:
>> > On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
>> >> > /var/lib usually stores whole
>> >> > databases. The difference is important and relevant."
>> >>
>> >> My systems has directories alsa, bluetooth, hp and many more
>> >> there that are not databases at all.
>> >>
>> >> So?
>> >> Which one? That /var is not going into /?
>> >
>> > No. That /var/lib contains databases. Is this so difficult to get?
>>
>> I get it; it's just not relevant.
>>
>> > On my system /var/lib/alsa contains data, that alsa uses to restore
>> > mixer- levels.
>>
>> Yeah, it does.
>>
>> > So *my* /var/lib is used during boot and *my* /var/lib has to be
>> > mounted by the initramfs.
>>
>> No, it doesn't. What are you talking about? Look at /etc/init.d/alsasound:
>>
>> depend() {
>>         need localmount
>>         after bootmisc modules isapnp coldplug hotplug
>> }
>>
>> Look at the first need from alsasound depend: it says, that it goes
>> after localmount. If you have /var in NFS (a very weird setup for a
>> desktop machine) maybe it will cause problems: but then it would be
>> fault of OpenRC (or the alsasound init script). If /var is on a
>> different partition, localmount will mount it and *then* alsasound
>> will execute.
>>
>> And it makes sense: the volume restoring doesn't matter until
>> immediately before running gdm and going into the desktop; of course
>> you can mount /var before that.
>>
>> >That's the situation on nearly every gentoo system
>> >
>> > using sound
>>
>> Yeah, and as I explained, thanks to need localmount there is no problem.
>>
>> >(systemd might handle this different, I have no idea)
>>
>> Yeah, it does more intelligently: as I said, the volume restoring is
>> only needed just before starting X.
>>
>> > Got it? Your system is not the center of the world.
>>
>> No, but I start to think you don't know *your* system. Check the
>> alsasound init script.
>
> *lol*
> Now, this is getting ridiculous.

Indeed, it is getting ridiculous.

> I don't know my system?

No, you don't.

> Have a look into
> /lib/udev/rules.d/90-alsa-restore.rules
> to realize, that this is a hack, that restores alsa-levels *twice* on systems
> that have /var/lib on /. The levels are supposed to be restored by *udev* not
> the script.

Yeah, but it doesn't run when udev *starts*. It runs when a card is
*added* to the system; that is the reason for the ACTION="add" part.
It's inteded to be used for USB cards (like external speakers with a
little sound card incorporated), so its volume is restored *at insert
time*.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Michael Schreckenbauer]

On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
> On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer <grimlog@gmx.de> 
wrote:
> > On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
> >> On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
> >> <grimlog@gmx.de>
> > 
> > wrote:
> >> > On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
> >> >> > /var/lib usually stores whole
> >> >> > databases. The difference is important and relevant."
> >> >> 
> >> >> My systems has directories alsa, bluetooth, hp and many more
> >> >> there that are not databases at all.
> >> >> 
> >> >> So?
> >> >> Which one? That /var is not going into /?
> >> > 
> >> > No. That /var/lib contains databases. Is this so difficult to get?
> >> 
> >> I get it; it's just not relevant.
> >> 
> >> > On my system /var/lib/alsa contains data, that alsa uses to
> >> > restore
> >> > mixer- levels.
> >> 
> >> Yeah, it does.
> >> 
> >> > So *my* /var/lib is used during boot and *my* /var/lib has to be
> >> > mounted by the initramfs.
> >> 
> >> No, it doesn't. What are you talking about? Look at
> >> /etc/init.d/alsasound:
> >> 
> >> depend() {
> >>         need localmount
> >>         after bootmisc modules isapnp coldplug hotplug
> >> }
> >> 
> >> Look at the first need from alsasound depend: it says, that it goes
> >> after localmount. If you have /var in NFS (a very weird setup for a
> >> desktop machine) maybe it will cause problems: but then it would be
> >> fault of OpenRC (or the alsasound init script). If /var is on a
> >> different partition, localmount will mount it and *then* alsasound
> >> will execute.
> >> 
> >> And it makes sense: the volume restoring doesn't matter until
> >> immediately before running gdm and going into the desktop; of course
> >> you can mount /var before that.
> >> 
> >> >That's the situation on nearly every gentoo system
> >> >
> >> > using sound
> >> 
> >> Yeah, and as I explained, thanks to need localmount there is no
> >> problem.
> >> 
> >> >(systemd might handle this different, I have no idea)
> >> 
> >> Yeah, it does more intelligently: as I said, the volume restoring is
> >> only needed just before starting X.
> >> 
> >> > Got it? Your system is not the center of the world.
> >> 
> >> No, but I start to think you don't know *your* system. Check the
> >> alsasound init script.
> > 
> > *lol*
> > Now, this is getting ridiculous.
> 
> Indeed, it is getting ridiculous.
> 
> > I don't know my system?
> 
> No, you don't.
> 
> > Have a look into
> > /lib/udev/rules.d/90-alsa-restore.rules
> > to realize, that this is a hack, that restores alsa-levels *twice* on
> > systems that have /var/lib on /. The levels are supposed to be restored
> > by *udev* not the script.
> 
> Yeah, but it doesn't run when udev *starts*. It runs when a card is
> *added* to the system; that is the reason for the ACTION="add" part.
> It's inteded to be used for USB cards (like external speakers with a
> little sound card incorporated), so its volume is restored *at insert
> time*.

Nonsense. Action "add" is used for every device in your system, built-in or 
plugged in later. So this rule is not only used for hotplug-USB-soundcards, 
but for every soundcard in your system.

See /etc/udev/rules.d/70-persistent-net.rules for example:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="...", 
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

> Regards.

Best,
Michael

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
>> On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer <grimlog@gmx.de>
> wrote:
>> > On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
>> >> On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
>> >> <grimlog@gmx.de>
>> >
>> > wrote:
>> >> > On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
>> >> >> > /var/lib usually stores whole
>> >> >> > databases. The difference is important and relevant."
>> >> >>
>> >> >> My systems has directories alsa, bluetooth, hp and many more
>> >> >> there that are not databases at all.
>> >> >>
>> >> >> So?
>> >> >> Which one? That /var is not going into /?
>> >> >
>> >> > No. That /var/lib contains databases. Is this so difficult to get?
>> >>
>> >> I get it; it's just not relevant.
>> >>
>> >> > On my system /var/lib/alsa contains data, that alsa uses to
>> >> > restore
>> >> > mixer- levels.
>> >>
>> >> Yeah, it does.
>> >>
>> >> > So *my* /var/lib is used during boot and *my* /var/lib has to be
>> >> > mounted by the initramfs.
>> >>
>> >> No, it doesn't. What are you talking about? Look at
>> >> /etc/init.d/alsasound:
>> >>
>> >> depend() {
>> >>         need localmount
>> >>         after bootmisc modules isapnp coldplug hotplug
>> >> }
>> >>
>> >> Look at the first need from alsasound depend: it says, that it goes
>> >> after localmount. If you have /var in NFS (a very weird setup for a
>> >> desktop machine) maybe it will cause problems: but then it would be
>> >> fault of OpenRC (or the alsasound init script). If /var is on a
>> >> different partition, localmount will mount it and *then* alsasound
>> >> will execute.
>> >>
>> >> And it makes sense: the volume restoring doesn't matter until
>> >> immediately before running gdm and going into the desktop; of course
>> >> you can mount /var before that.
>> >>
>> >> >That's the situation on nearly every gentoo system
>> >> >
>> >> > using sound
>> >>
>> >> Yeah, and as I explained, thanks to need localmount there is no
>> >> problem.
>> >>
>> >> >(systemd might handle this different, I have no idea)
>> >>
>> >> Yeah, it does more intelligently: as I said, the volume restoring is
>> >> only needed just before starting X.
>> >>
>> >> > Got it? Your system is not the center of the world.
>> >>
>> >> No, but I start to think you don't know *your* system. Check the
>> >> alsasound init script.
>> >
>> > *lol*
>> > Now, this is getting ridiculous.
>>
>> Indeed, it is getting ridiculous.
>>
>> > I don't know my system?
>>
>> No, you don't.
>>
>> > Have a look into
>> > /lib/udev/rules.d/90-alsa-restore.rules
>> > to realize, that this is a hack, that restores alsa-levels *twice* on
>> > systems that have /var/lib on /. The levels are supposed to be restored
>> > by *udev* not the script.
>>
>> Yeah, but it doesn't run when udev *starts*. It runs when a card is
>> *added* to the system; that is the reason for the ACTION="add" part.
>> It's inteded to be used for USB cards (like external speakers with a
>> little sound card incorporated), so its volume is restored *at insert
>> time*.
>
> Nonsense. Action "add" is used for every device in your system, built-in or
> plugged in later. So this rule is not only used for hotplug-USB-soundcards,
> but for every soundcard in your system.

Yeah, you are right. Sorry. I forgot about the little numbers udev uses:

10-dm.rules
11-dm-lvm.rules
13-dm-disk.rules
60-persistent-storage.rules
70-persistent-net.rules
90-alsa-restore.rules

So, the same way that in the alsasound init script "need localmount"
guarantee that /var is mounted, the 60-persistent-storage.rules
guarantees that /var is mounted before the 90-alsa-restore.rules
restores ALSA's volume.

Again, there is no problem. Yeah, the rule is executed at udev
execution time... but after the persisten-storage rule. So, you see,
no problem. No need for /var in the same partition as /.

You guys keep speculating. As of *now*, there is not a single line of
code that prevents a system from booting correctly if /var lives in
another partition, no matter if the system uses an initramfs or not.
As of *now* nobody is discussing, proposing, or even mentioning
(except for you guys) about requiring /var to live in the same
partition as /.

And that's that.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Michael Schreckenbauer]

On Saturday, 15. October 2011 03:34:27 Canek Peláez Valdés wrote:
> On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer <grimlog@gmx.de> 
wrote:
> > On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
> >> On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer
> >> <grimlog@gmx.de>
> > 
> > wrote:
> >> > On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
> >> >> On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
> >> >> <grimlog@gmx.de>
> >> > 
> >> > wrote:
> >> >> > On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
> >> >> >> > /var/lib usually stores whole
> >> >> >> > databases. The difference is important and relevant."
> >> >> >> 
> >> >> >> My systems has directories alsa, bluetooth, hp and many
> >> >> >> more
> >> >> >> there that are not databases at all.
> >> >> >> 
> >> >> >> So?
> >> >> >> Which one? That /var is not going into /?
> >> >> > 
> >> >> > No. That /var/lib contains databases. Is this so difficult
> >> >> > to get?
> >> >> 
> >> >> I get it; it's just not relevant.
> >> >> 
> >> >> > On my system /var/lib/alsa contains data, that alsa uses to
> >> >> > restore
> >> >> > mixer- levels.
> >> >> 
> >> >> Yeah, it does.
> >> >> 
> >> >> > So *my* /var/lib is used during boot and *my* /var/lib has
> >> >> > to be
> >> >> > mounted by the initramfs.
> >> >> 
> >> >> No, it doesn't. What are you talking about? Look at
> >> >> /etc/init.d/alsasound:
> >> >> 
> >> >> depend() {
> >> >>         need localmount
> >> >>         after bootmisc modules isapnp coldplug hotplug
> >> >> }
> >> >> 
> >> >> Look at the first need from alsasound depend: it says, that it
> >> >> goes
> >> >> after localmount. If you have /var in NFS (a very weird setup
> >> >> for a
> >> >> desktop machine) maybe it will cause problems: but then it would
> >> >> be
> >> >> fault of OpenRC (or the alsasound init script). If /var is on a
> >> >> different partition, localmount will mount it and *then*
> >> >> alsasound
> >> >> will execute.
> >> >> 
> >> >> And it makes sense: the volume restoring doesn't matter until
> >> >> immediately before running gdm and going into the desktop; of
> >> >> course
> >> >> you can mount /var before that.
> >> >> 
> >> >> >That's the situation on nearly every gentoo system
> >> >> >
> >> >> > using sound
> >> >> 
> >> >> Yeah, and as I explained, thanks to need localmount there is no
> >> >> problem.
> >> >> 
> >> >> >(systemd might handle this different, I have no idea)
> >> >> 
> >> >> Yeah, it does more intelligently: as I said, the volume
> >> >> restoring is
> >> >> only needed just before starting X.
> >> >> 
> >> >> > Got it? Your system is not the center of the world.
> >> >> 
> >> >> No, but I start to think you don't know *your* system. Check the
> >> >> alsasound init script.
> >> > 
> >> > *lol*
> >> > Now, this is getting ridiculous.
> >> 
> >> Indeed, it is getting ridiculous.
> >> 
> >> > I don't know my system?
> >> 
> >> No, you don't.
> >> 
> >> > Have a look into
> >> > /lib/udev/rules.d/90-alsa-restore.rules
> >> > to realize, that this is a hack, that restores alsa-levels *twice*
> >> > on
> >> > systems that have /var/lib on /. The levels are supposed to be
> >> > restored by *udev* not the script.
> >> 
> >> Yeah, but it doesn't run when udev *starts*. It runs when a card is
> >> *added* to the system; that is the reason for the ACTION="add" part.
> >> It's inteded to be used for USB cards (like external speakers with a
> >> little sound card incorporated), so its volume is restored *at insert
> >> time*.
> > 
> > Nonsense. Action "add" is used for every device in your system, built-in
> > or plugged in later. So this rule is not only used for
> > hotplug-USB-soundcards, but for every soundcard in your system.
> 
> Yeah, you are right. Sorry. I forgot about the little numbers udev uses:
> 
> 10-dm.rules
> 11-dm-lvm.rules
> 13-dm-disk.rules
> 60-persistent-storage.rules
> 70-persistent-net.rules
> 90-alsa-restore.rules
> 
> So, the same way that in the alsasound init script "need localmount"
> guarantee that /var is mounted, the 60-persistent-storage.rules
> guarantees that /var is mounted before the 90-alsa-restore.rules
> restores ALSA's volume.

My 60-persisten-storage.rules creates device nodes. It does not mount 
anything. Is your's different?

> Again, there is no problem. Yeah, the rule is executed at udev
> execution time... but after the persisten-storage rule. So, you see,
> no problem. No need for /var in the same partition as /.

So my devices nodes for harddisks exist, when alsa restores it's levels. Does 
not solve anything.

> You guys keep speculating.

We are speculating?
*You* were wrong about the assumtion that /var/lib contains databases.
*You* were wrong about the assumtion how action "add" works.
And *you* are wrong about the assumption, what 60-persistent-storage.rules 
does.
Yet you claim, that *I* don't know my system.
I'd say, do your homework, then we can talk.

> Regards.

Best,
Michael

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 3:45 AM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Saturday, 15. October 2011 03:34:27 Canek Peláez Valdés wrote:
>> On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer <grimlog@gmx.de>
> wrote:
>> > On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
>> >> On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer
>> >> <grimlog@gmx.de>
>> >
>> > wrote:
>> >> > On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
>> >> >> On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
>> >> >> <grimlog@gmx.de>
>> >> >
>> >> > wrote:
>> >> >> > On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
>> >> >> >> > /var/lib usually stores whole
>> >> >> >> > databases. The difference is important and relevant."
>> >> >> >>
>> >> >> >> My systems has directories alsa, bluetooth, hp and many
>> >> >> >> more
>> >> >> >> there that are not databases at all.
>> >> >> >>
>> >> >> >> So?
>> >> >> >> Which one? That /var is not going into /?
>> >> >> >
>> >> >> > No. That /var/lib contains databases. Is this so difficult
>> >> >> > to get?
>> >> >>
>> >> >> I get it; it's just not relevant.
>> >> >>
>> >> >> > On my system /var/lib/alsa contains data, that alsa uses to
>> >> >> > restore
>> >> >> > mixer- levels.
>> >> >>
>> >> >> Yeah, it does.
>> >> >>
>> >> >> > So *my* /var/lib is used during boot and *my* /var/lib has
>> >> >> > to be
>> >> >> > mounted by the initramfs.
>> >> >>
>> >> >> No, it doesn't. What are you talking about? Look at
>> >> >> /etc/init.d/alsasound:
>> >> >>
>> >> >> depend() {
>> >> >>         need localmount
>> >> >>         after bootmisc modules isapnp coldplug hotplug
>> >> >> }
>> >> >>
>> >> >> Look at the first need from alsasound depend: it says, that it
>> >> >> goes
>> >> >> after localmount. If you have /var in NFS (a very weird setup
>> >> >> for a
>> >> >> desktop machine) maybe it will cause problems: but then it would
>> >> >> be
>> >> >> fault of OpenRC (or the alsasound init script). If /var is on a
>> >> >> different partition, localmount will mount it and *then*
>> >> >> alsasound
>> >> >> will execute.
>> >> >>
>> >> >> And it makes sense: the volume restoring doesn't matter until
>> >> >> immediately before running gdm and going into the desktop; of
>> >> >> course
>> >> >> you can mount /var before that.
>> >> >>
>> >> >> >That's the situation on nearly every gentoo system
>> >> >> >
>> >> >> > using sound
>> >> >>
>> >> >> Yeah, and as I explained, thanks to need localmount there is no
>> >> >> problem.
>> >> >>
>> >> >> >(systemd might handle this different, I have no idea)
>> >> >>
>> >> >> Yeah, it does more intelligently: as I said, the volume
>> >> >> restoring is
>> >> >> only needed just before starting X.
>> >> >>
>> >> >> > Got it? Your system is not the center of the world.
>> >> >>
>> >> >> No, but I start to think you don't know *your* system. Check the
>> >> >> alsasound init script.
>> >> >
>> >> > *lol*
>> >> > Now, this is getting ridiculous.
>> >>
>> >> Indeed, it is getting ridiculous.
>> >>
>> >> > I don't know my system?
>> >>
>> >> No, you don't.
>> >>
>> >> > Have a look into
>> >> > /lib/udev/rules.d/90-alsa-restore.rules
>> >> > to realize, that this is a hack, that restores alsa-levels *twice*
>> >> > on
>> >> > systems that have /var/lib on /. The levels are supposed to be
>> >> > restored by *udev* not the script.
>> >>
>> >> Yeah, but it doesn't run when udev *starts*. It runs when a card is
>> >> *added* to the system; that is the reason for the ACTION="add" part.
>> >> It's inteded to be used for USB cards (like external speakers with a
>> >> little sound card incorporated), so its volume is restored *at insert
>> >> time*.
>> >
>> > Nonsense. Action "add" is used for every device in your system, built-in
>> > or plugged in later. So this rule is not only used for
>> > hotplug-USB-soundcards, but for every soundcard in your system.
>>
>> Yeah, you are right. Sorry. I forgot about the little numbers udev uses:
>>
>> 10-dm.rules
>> 11-dm-lvm.rules
>> 13-dm-disk.rules
>> 60-persistent-storage.rules
>> 70-persistent-net.rules
>> 90-alsa-restore.rules
>>
>> So, the same way that in the alsasound init script "need localmount"
>> guarantee that /var is mounted, the 60-persistent-storage.rules
>> guarantees that /var is mounted before the 90-alsa-restore.rules
>> restores ALSA's volume.
>
> My 60-persisten-storage.rules creates device nodes. It does not mount
> anything. Is your's different?
>
>> Again, there is no problem. Yeah, the rule is executed at udev
>> execution time... but after the persisten-storage rule. So, you see,
>> no problem. No need for /var in the same partition as /.
>
> So my devices nodes for harddisks exist, when alsa restores it's levels. Does
> not solve anything.
>
>> You guys keep speculating.
>
> We are speculating?
> *You* were wrong about the assumtion that /var/lib contains databases.
> *You* were wrong about the assumtion how action "add" works.
> And *you* are wrong about the assumption, what 60-persistent-storage.rules
> does.
> Yet you claim, that *I* don't know my system.
> I'd say, do your homework, then we can talk.

I got that points wrong, I admit. I repeat, 3am here ;) I apogolize
for saying that to you Michael; I shouldn't have, even if I would have
been right (and I wasn't). Again, no excuse, but it's (actually) 4am
here now.

It doesn't change the fact that a) the system doesn't need /var/lib to
boot (ALSA does, and it's only for the cosmetic reason of restore the
volume, easily fixable latter in the boot process), and b) that nobody
is proposing that /var should go in the same partition as /.

In the end, my point is that either you would need an initramfs, or
Zac's proposal, or /usr in the same partition as / (depending on the
complexity of your setup). In any case, the fact is that, *as of now*,
a /var inside / is not necessary for boot. The fact is, *nobody* is
proposing nothing similar. And the fact is, with the *current* stack
(and yeah, that includes the latest versions of systemd and udev and
all the other crazy stuff), /var can happily live in its own
partition, without an initramfs.

Those are facts, and nobody can deny them. If you say that you fear
that /var could no longer be allowed to be on its own partition in the
future, well, you can analyze the situation that way, but there is not
a single fact (or evidence) that supports that. The whole /run and
/lock thing is proof that the developers want to keep /var on its own
partition.

And therefore, all speculation about forbidding a separated /var is
that. Speculation.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Michael Schreckenbauer]

Hi Canek,

On Saturday, 15. October 2011 04:04:05 Canek Peláez Valdés wrote:
> I got that points wrong, I admit. I repeat, 3am here ;) I apogolize
> for saying that to you Michael; I shouldn't have, even if I would have
> been right (and I wasn't). Again, no excuse, but it's (actually) 4am
> here now.

ok. For me it was lunch time, so I had an advantage here :)

> Regards.

Best,
Michael

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 3:34 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
>> On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
>>> On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer <grimlog@gmx.de>
>> wrote:
>>> > On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
>>> >> On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
>>> >> <grimlog@gmx.de>
>>> >
>>> > wrote:
>>> >> > On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
>>> >> >> > /var/lib usually stores whole
>>> >> >> > databases. The difference is important and relevant."
>>> >> >>
>>> >> >> My systems has directories alsa, bluetooth, hp and many more
>>> >> >> there that are not databases at all.
>>> >> >>
>>> >> >> So?
>>> >> >> Which one? That /var is not going into /?
>>> >> >
>>> >> > No. That /var/lib contains databases. Is this so difficult to get?
>>> >>
>>> >> I get it; it's just not relevant.
>>> >>
>>> >> > On my system /var/lib/alsa contains data, that alsa uses to
>>> >> > restore
>>> >> > mixer- levels.
>>> >>
>>> >> Yeah, it does.
>>> >>
>>> >> > So *my* /var/lib is used during boot and *my* /var/lib has to be
>>> >> > mounted by the initramfs.
>>> >>
>>> >> No, it doesn't. What are you talking about? Look at
>>> >> /etc/init.d/alsasound:
>>> >>
>>> >> depend() {
>>> >>         need localmount
>>> >>         after bootmisc modules isapnp coldplug hotplug
>>> >> }
>>> >>
>>> >> Look at the first need from alsasound depend: it says, that it goes
>>> >> after localmount. If you have /var in NFS (a very weird setup for a
>>> >> desktop machine) maybe it will cause problems: but then it would be
>>> >> fault of OpenRC (or the alsasound init script). If /var is on a
>>> >> different partition, localmount will mount it and *then* alsasound
>>> >> will execute.
>>> >>
>>> >> And it makes sense: the volume restoring doesn't matter until
>>> >> immediately before running gdm and going into the desktop; of course
>>> >> you can mount /var before that.
>>> >>
>>> >> >That's the situation on nearly every gentoo system
>>> >> >
>>> >> > using sound
>>> >>
>>> >> Yeah, and as I explained, thanks to need localmount there is no
>>> >> problem.
>>> >>
>>> >> >(systemd might handle this different, I have no idea)
>>> >>
>>> >> Yeah, it does more intelligently: as I said, the volume restoring is
>>> >> only needed just before starting X.
>>> >>
>>> >> > Got it? Your system is not the center of the world.
>>> >>
>>> >> No, but I start to think you don't know *your* system. Check the
>>> >> alsasound init script.
>>> >
>>> > *lol*
>>> > Now, this is getting ridiculous.
>>>
>>> Indeed, it is getting ridiculous.
>>>
>>> > I don't know my system?
>>>
>>> No, you don't.
>>>
>>> > Have a look into
>>> > /lib/udev/rules.d/90-alsa-restore.rules
>>> > to realize, that this is a hack, that restores alsa-levels *twice* on
>>> > systems that have /var/lib on /. The levels are supposed to be restored
>>> > by *udev* not the script.
>>>
>>> Yeah, but it doesn't run when udev *starts*. It runs when a card is
>>> *added* to the system; that is the reason for the ACTION="add" part.
>>> It's inteded to be used for USB cards (like external speakers with a
>>> little sound card incorporated), so its volume is restored *at insert
>>> time*.
>>
>> Nonsense. Action "add" is used for every device in your system, built-in or
>> plugged in later. So this rule is not only used for hotplug-USB-soundcards,
>> but for every soundcard in your system.
>
> Yeah, you are right. Sorry. I forgot about the little numbers udev uses:
>
> 10-dm.rules
> 11-dm-lvm.rules
> 13-dm-disk.rules
> 60-persistent-storage.rules
> 70-persistent-net.rules
> 90-alsa-restore.rules
>
> So, the same way that in the alsasound init script "need localmount"
> guarantee that /var is mounted, the 60-persistent-storage.rules
> guarantees that /var is mounted before the 90-alsa-restore.rules
> restores ALSA's volume.
>
> Again, there is no problem. Yeah, the rule is executed at udev
> execution time... but after the persisten-storage rule. So, you see,
> no problem. No need for /var in the same partition as /.

Mmmh. I got that one wrong; the persistent-storage rules just creates
the necessary symlinks, doesn't mount anything.  (It's 3 am here, so I
should get sleep).

However, my point remains: the system boots correctly even if that
rule fails. It's not only non-fatal, it's pretty trivial and easily
fixable by the init system (like OpenRC and systemd does).

Even if this ALSA rule "requires" /var/lib, it doesn't means that it
requires /var in the same partition as /.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Joost Roeleveld]

On Saturday, October 15, 2011 03:34:27 AM Canek Peláez Valdés wrote:
> On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer <grimlog@gmx.de> 
wrote:
> > On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
> >> On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer
> >> <grimlog@gmx.de>
> > 
> > wrote:
> >> > On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
> >> >> On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
> >> >> <grimlog@gmx.de>
> >> > 
> >> > wrote:
> >> >> > On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
> >> >> >> > /var/lib usually stores whole
> >> >> >> > databases. The difference is important and relevant."
> >> >> >> 
> >> >> >> My systems has directories alsa, bluetooth, hp and many
> >> >> >> more
> >> >> >> there that are not databases at all.
> >> >> >> 
> >> >> >> So?
> >> >> >> Which one? That /var is not going into /?
> >> >> > 
> >> >> > No. That /var/lib contains databases. Is this so difficult
> >> >> > to get?
> >> >> 
> >> >> I get it; it's just not relevant.
> >> >> 
> >> >> > On my system /var/lib/alsa contains data, that alsa uses to
> >> >> > restore
> >> >> > mixer- levels.
> >> >> 
> >> >> Yeah, it does.
> >> >> 
> >> >> > So *my* /var/lib is used during boot and *my* /var/lib has
> >> >> > to be
> >> >> > mounted by the initramfs.
> >> >> 
> >> >> No, it doesn't. What are you talking about? Look at
> >> >> /etc/init.d/alsasound:
> >> >> 
> >> >> depend() {
> >> >>         need localmount
> >> >>         after bootmisc modules isapnp coldplug hotplug
> >> >> }
> >> >> 
> >> >> Look at the first need from alsasound depend: it says, that it
> >> >> goes
> >> >> after localmount. If you have /var in NFS (a very weird setup
> >> >> for a
> >> >> desktop machine) maybe it will cause problems: but then it would
> >> >> be
> >> >> fault of OpenRC (or the alsasound init script). If /var is on a
> >> >> different partition, localmount will mount it and *then*
> >> >> alsasound
> >> >> will execute.
> >> >> 
> >> >> And it makes sense: the volume restoring doesn't matter until
> >> >> immediately before running gdm and going into the desktop; of
> >> >> course
> >> >> you can mount /var before that.
> >> >> 
> >> >> >That's the situation on nearly every gentoo system
> >> >> >
> >> >> > using sound
> >> >> 
> >> >> Yeah, and as I explained, thanks to need localmount there is no
> >> >> problem.
> >> >> 
> >> >> >(systemd might handle this different, I have no idea)
> >> >> 
> >> >> Yeah, it does more intelligently: as I said, the volume
> >> >> restoring is
> >> >> only needed just before starting X.
> >> >> 
> >> >> > Got it? Your system is not the center of the world.
> >> >> 
> >> >> No, but I start to think you don't know *your* system. Check the
> >> >> alsasound init script.
> >> > 
> >> > *lol*
> >> > Now, this is getting ridiculous.
> >> 
> >> Indeed, it is getting ridiculous.
> >> 
> >> > I don't know my system?
> >> 
> >> No, you don't.
> >> 
> >> > Have a look into
> >> > /lib/udev/rules.d/90-alsa-restore.rules
> >> > to realize, that this is a hack, that restores alsa-levels *twice*
> >> > on
> >> > systems that have /var/lib on /. The levels are supposed to be
> >> > restored by *udev* not the script.
> >> 
> >> Yeah, but it doesn't run when udev *starts*. It runs when a card is
> >> *added* to the system; that is the reason for the ACTION="add" part.
> >> It's inteded to be used for USB cards (like external speakers with a
> >> little sound card incorporated), so its volume is restored *at insert
> >> time*.
> > 
> > Nonsense. Action "add" is used for every device in your system, built-in
> > or plugged in later. So this rule is not only used for
> > hotplug-USB-soundcards, but for every soundcard in your system.
> 
> Yeah, you are right. Sorry. I forgot about the little numbers udev uses:
> 
> 10-dm.rules
> 11-dm-lvm.rules
> 13-dm-disk.rules
> 60-persistent-storage.rules
> 70-persistent-net.rules
> 90-alsa-restore.rules

These only matter when there are conflicting rules in these files. The rule in 
the "lower" number is used. Higher numbers are then ignored.

> So, the same way that in the alsasound init script "need localmount"
> guarantee that /var is mounted, the 60-persistent-storage.rules
> guarantees that /var is mounted before the 90-alsa-restore.rules
> restores ALSA's volume.

Wrong, see above.

> Again, there is no problem. Yeah, the rule is executed at udev
> execution time... but after the persisten-storage rule. So, you see,
> no problem. No need for /var in the same partition as /.

Wrong, /etc/init.d/alsasound is a fix for that.
Udev should handle the situation where filesystems are not available yet and 
keep those in a retry-queue for when all filesystems are available.

> You guys keep speculating. As of *now*, there is not a single line of
> code that prevents a system from booting correctly if /var lives in
> another partition, no matter if the system uses an initramfs or not.
> As of *now* nobody is discussing, proposing, or even mentioning
> (except for you guys) about requiring /var to live in the same
> partition as /.

/var will be required. alsasound is a workaround for this.

--
Joost

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Mike Edenfield]

On 10/15/2011 4:42 AM, Canek Peláez Valdés wrote:

> Which one? That /var is not going into /? It's not disinformation, it
> is th true. If not, please be so kind of showin one single developer
> reference that says so. One. Single. One.
>
> Email, blog post, wiki, you choose it. But one single one.

I don't think anyone is claiming that there are *currently* 
plans to require /var, either on / or via initramfs.

The claim being made is that /var suffers from the exact 
same problem that /usr does, with regard to udev, namely 
that arbitrary programs running from within udev rules could 
(and some do) require /var to be present to function. Thus, 
the arguments being applied to /usr *currently* can be 
applied equally to /var, once it becomes an issue.

The classic example being given is a bluetooth keyboard: to 
make a bluetooth keyboard available, udev executes a rule 
which requires /var/bluetooth to be present. (Certain other 
rules similarly require data from /var, such as sound cards 
or printers.)

The extremely logical deduction being made is as follows:

Some udev rules require /usr to be preset to properly 
execute. The solution favored by the udev maintainer is to 
simply make /usr always required for udev to run. Running 
udev without /usr present will become unsupported.

Similarly, some udev rules require /var to be present to 
properly execute. The solution that will be favored by the 
udev maintainer, when such an issue is raised, is most 
likely going to be similar to the solution proposed for 
/usr: the mandating of /var being present before udev runs. 
Running udev without /var present will most likely become 
unsupported.

Programs designed to run out of /bin expect to be run 
without any other locations present. Programs designed to 
run out of /usr/bin generally assume that the rest of the 
system, including /var, is available for use. You can't have 
one without the other.

--Mike

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Dale]

Canek Peláez Valdés wrote:
> On Fri, Oct 14, 2011 at 11:56 PM, Dale<rdalek1967@gmail.com>  wrote:
>> Pandu Poluan wrote:
>>
>> On Oct 15, 2011 5:49 AM, "Dale"<rdalek1967@gmail.com>  wrote:
>>> Neil Bothwick wrote:
>>>> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
>>>>
>>>>> A'right now.  I'm going to start on hal and /usr being on / again.  :-P
>>>> Jeez, 43 years on and you're still going on about it...
>>>>
>>>>
>>> Dang, I was only a year old when hal came out?  That just doubled my age.
>>>   It's closer to what I feel like tho.
>>>
>>> I'm still not happy with /usr being required tho.  That is still standing
>>> on a bad nerve.  Don't worry tho, I got plenty of those bad nerves.  :-P
>>>
>> Do you know that there's a plan to move /var/run to / also? ;-)
>>
>> Rgds,
>>
>>
>> Now someone on here swears up and down that /var isn't going to be required
>> on /.
> /var != /var/run
> /var != /var/lock
>
> /var/run is going in /run, but /var/run (by definition) only contains
> things like PID files and runtime sockets. In the same vein, /var/lock
> also is going into /run/lock. I have acknowledged this from the very
> beginning, and I have been pointing out that implying that because
> those two (really small and bounded) directories of /var are going
> into /run and /run/lock, it doesn't mean that the whole /var will go
> into /. That is disinformation.
>
> Nobody has even proposed that /var should go into the same partition
> as /. *Nobody*, and the simplest proof of that is that nobody has
> produced a single proof to the contrary. Not a single email, blog
> post, or wiki entry from any system developer even mentions the
> possibility of requiring /var to be in the same partition as /.
>
> Whoever says that /var will be required to be on the same partition as
> / is either wildly speculating, or spreading FUD.

So /var/run and /var/lock isn't on /var?  Even if they will be linking 
to another location, the link has to be there for whatever program to 
follow.  If /var isn't mounted yet, there is nothing for the program to 
find.

When I saw the messages about LVM and /var, that caused LVM to fail to 
start.  I wouldn't put / on LVM and wouldn't expect it to work without a 
init thingy either.  Thing is, based on it failing, you can't have /var 
on a separate partition and expect LVM to start.  So, if you use LVM for 
/usr and/or /var, you have to have a init thingy even if / is on a 
regular file system.


>
>> I'm telling ya'll, /home is coming.
> That is just ridiculous.

I would have said the same thing about /usr a year ago.  I'm not saying 
it is coming next week but . . .

>
>>    We are going to end up where we
>> can only have one drive in our Linux boxes for the OS and its relatives.
> And so is this: more FUD.
>
>> That or we will ALL have to start using the pesky init* thingy.
> More FUD: the current proposal (from Zac, the principal coder of
> portage, and someone who actually wrotes code and know what he is
> talking about) is this:
>
> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml
>
> It basically removes the need for a "pesky init* thingy", although for
> the life of me I cannot understand why someone will not see the
> technical advantages of actually using an initramfs.

I'll have to read his link later.

>
>> I got 7 acres of land here, complete with trees.  If someone can find the
>> dev that started this mess, I can find some rope.  Just saying.  ;-)  Oh, I
>> live half a mile from the river too.  Makes for a good dump site.  lol
>>
>> I noticed the other day that when LVM tries to start, it fails.  I have /var
>> on a separate partition here.  It was complaining about something on /var
>> missing.  So, you may be late in reporting this.  I think it is already
>> needed for LVM if /usr or /var is on a separate partition.
> Again, get the facts right. If you use LVM you will need to use an
> initramfs. If you only use a separated /usr you will be able to use
> Zac's proposal.
>
> In no case whatsoever you will be required to have /var on the same
> partition as /. Nobody has ever proposed that. /run and /run/lock are
> not /var.
>
> Regards.

No one proposed that /usr was required until just recently.  Saying it 
won't happen really puts you in a bad spot when or if it does.  If you 
know this for sure and certain, I want your crystal ball.

Just for the record, I don't want a init thingy because it is yet one 
more thing to fail when booting.  I was forced to use one when I was on 
Mandrake and I hated it.  It isn't the only reason I switched but it was 
one reason.  Now that same reason is coming to Gentoo.

Dale

:-)  :-)

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 1:37 AM, Dale <rdalek1967@gmail.com> wrote:
> Canek Peláez Valdés wrote:
>>
>> On Fri, Oct 14, 2011 at 11:56 PM, Dale<rdalek1967@gmail.com>  wrote:
>>>
>>> Pandu Poluan wrote:
>>>
>>> On Oct 15, 2011 5:49 AM, "Dale"<rdalek1967@gmail.com>  wrote:
>>>>
>>>> Neil Bothwick wrote:
>>>>>
>>>>> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
>>>>>
>>>>>> A'right now.  I'm going to start on hal and /usr being on / again.
>>>>>>  :-P
>>>>>
>>>>> Jeez, 43 years on and you're still going on about it...
>>>>>
>>>>>
>>>> Dang, I was only a year old when hal came out?  That just doubled my
>>>> age.
>>>>  It's closer to what I feel like tho.
>>>>
>>>> I'm still not happy with /usr being required tho.  That is still
>>>> standing
>>>> on a bad nerve.  Don't worry tho, I got plenty of those bad nerves.  :-P
>>>>
>>> Do you know that there's a plan to move /var/run to / also? ;-)
>>>
>>> Rgds,
>>>
>>>
>>> Now someone on here swears up and down that /var isn't going to be
>>> required
>>> on /.
>>
>> /var != /var/run
>> /var != /var/lock
>>
>> /var/run is going in /run, but /var/run (by definition) only contains
>> things like PID files and runtime sockets. In the same vein, /var/lock
>> also is going into /run/lock. I have acknowledged this from the very
>> beginning, and I have been pointing out that implying that because
>> those two (really small and bounded) directories of /var are going
>> into /run and /run/lock, it doesn't mean that the whole /var will go
>> into /. That is disinformation.
>>
>> Nobody has even proposed that /var should go into the same partition
>> as /. *Nobody*, and the simplest proof of that is that nobody has
>> produced a single proof to the contrary. Not a single email, blog
>> post, or wiki entry from any system developer even mentions the
>> possibility of requiring /var to be in the same partition as /.
>>
>> Whoever says that /var will be required to be on the same partition as
>> / is either wildly speculating, or spreading FUD.
>
> So /var/run and /var/lock isn't on /var?  Even if they will be linking to
> another location, the link has to be there for whatever program to follow.
>  If /var isn't mounted yet, there is nothing for the program to find.

The link goes the other way around. /run and /lock are the real
directories, /var/run is a link to /run, /var/lock is a link to
/run/lock. When the initramfs (or the init system) mount /var, they
make the link.

> When I saw the messages about LVM and /var, that caused LVM to fail to
> start.  I wouldn't put / on LVM and wouldn't expect it to work without a
> init thingy either.  Thing is, based on it failing, you can't have /var on a
> separate partition and expect LVM to start.  So, if you use LVM for /usr
> and/or /var, you have to have a init thingy even if / is on a regular file
> system.

Yes, as I said in my last mail, if you need LVM, you need an
initramfs. Remove the LVM, and you can have /var  (and /usr for that
matter) withouth an initramfs. Where/when did I say something
different?

>>> I'm telling ya'll, /home is coming.
>>
>> That is just ridiculous.
>
> I would have said the same thing about /usr a year ago.  I'm not saying it
> is coming next week but . . .

You can speculate all you want. Fact is, nobody has proposed that, and
there is not even a single email suggesting that it will be necessary.
On the contrary, the requirement for an initramfs or a /usr inside the
same partition as / has been being discussed years ago; if you had
followed the developers lists, you wil had hear about it months before
it happened.

Nothing similar has happened with /var, least of it /home.

>>>   We are going to end up where we
>>> can only have one drive in our Linux boxes for the OS and its relatives.
>>
>> And so is this: more FUD.
>>
>>> That or we will ALL have to start using the pesky init* thingy.
>>
>> More FUD: the current proposal (from Zac, the principal coder of
>> portage, and someone who actually wrotes code and know what he is
>> talking about) is this:
>>
>>
>> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml
>>
>> It basically removes the need for a "pesky init* thingy", although for
>> the life of me I cannot understand why someone will not see the
>> technical advantages of actually using an initramfs.
>
> I'll have to read his link later.

Please do.

>>> I got 7 acres of land here, complete with trees.  If someone can find the
>>> dev that started this mess, I can find some rope.  Just saying.  ;-)  Oh,
>>> I
>>> live half a mile from the river too.  Makes for a good dump site.  lol
>>>
>>> I noticed the other day that when LVM tries to start, it fails.  I have
>>> /var
>>> on a separate partition here.  It was complaining about something on /var
>>> missing.  So, you may be late in reporting this.  I think it is already
>>> needed for LVM if /usr or /var is on a separate partition.
>>
>> Again, get the facts right. If you use LVM you will need to use an
>> initramfs. If you only use a separated /usr you will be able to use
>> Zac's proposal.
>>
>> In no case whatsoever you will be required to have /var on the same
>> partition as /. Nobody has ever proposed that. /run and /run/lock are
>> not /var.
>>
>> Regards.
>
> No one proposed that /usr was required until just recently.

http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1337

That was on February 25, this year. *Eight* months ago. And the stable
udev in Gentoo still "supports" (it really doesn't, but whatever) a
separated /usr.

> Saying it won't
> happen really puts you in a bad spot when or if it does.  If you know this
> for sure and certain, I want your crystal ball.

It's called an "educated guess". Of course I could be wrong; but I am
more than willing to bet a nice expensive dinner with anyone that it
is not going to happen in the next ten years. Any takers?

> Just for the record, I don't want a init thingy because it is yet one more
> thing to fail when booting.  I was forced to use one when I was on Mandrake
> and I hated it.  It isn't the only reason I switched but it was one reason.
>  Now that same reason is coming to Gentoo.

No is not: if you are talking about Mandrake and not Mandriva, then
you did not used an initramfs. You used an initrd, and it was
completely different.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Michael Schreckenbauer]

Hi Canek,

On Saturday, 15. October 2011 02:02:13 Canek Peláez Valdés wrote:
> On Sat, Oct 15, 2011 at 1:37 AM, Dale <rdalek1967@gmail.com> wrote:
> > Canek Peláez Valdés wrote:
> >> On Fri, Oct 14, 2011 at 11:56 PM, Dale<rdalek1967@gmail.com>  wrote:
> >>> Pandu Poluan wrote:
> >>> 
> >>> On Oct 15, 2011 5:49 AM, "Dale"<rdalek1967@gmail.com>  wrote:
> >>>> Neil Bothwick wrote:
> >>>>> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
> >>>>>> A'right now.  I'm going to start on hal and /usr being on /
> >>>>>> again.
> >>>>>>  :-P
> >>>>> 
> >>>>> Jeez, 43 years on and you're still going on about it...
> >>>> 
> >>>> Dang, I was only a year old when hal came out?  That just doubled
> >>>> my
> >>>> age.
> >>>>  It's closer to what I feel like tho.
> >>>> 
> >>>> I'm still not happy with /usr being required tho.  That is still
> >>>> standing
> >>>> on a bad nerve.  Don't worry tho, I got plenty of those bad
> >>>> nerves.  :-P>>> 
> >>> Do you know that there's a plan to move /var/run to / also? ;-)
> >>> 
> >>> Rgds,
> >>> 
> >>> 
> >>> Now someone on here swears up and down that /var isn't going to be
> >>> required
> >>> on /.
> >> 
> >> /var != /var/run
> >> /var != /var/lock
> >> 
> >> /var/run is going in /run, but /var/run (by definition) only contains
> >> things like PID files and runtime sockets. In the same vein, /var/lock
> >> also is going into /run/lock. I have acknowledged this from the very
> >> beginning, and I have been pointing out that implying that because
> >> those two (really small and bounded) directories of /var are going
> >> into /run and /run/lock, it doesn't mean that the whole /var will go
> >> into /. That is disinformation.
> >> 
> >> Nobody has even proposed that /var should go into the same partition
> >> as /. *Nobody*, and the simplest proof of that is that nobody has
> >> produced a single proof to the contrary. Not a single email, blog
> >> post, or wiki entry from any system developer even mentions the
> >> possibility of requiring /var to be in the same partition as /.
> >> 
> >> Whoever says that /var will be required to be on the same partition as
> >> / is either wildly speculating, or spreading FUD.
> > 
> > So /var/run and /var/lock isn't on /var?  Even if they will be linking
> > to
> > another location, the link has to be there for whatever program to
> > follow. If /var isn't mounted yet, there is nothing for the program to
> > find.
> The link goes the other way around. /run and /lock are the real
> directories, /var/run is a link to /run, /var/lock is a link to
> /run/lock. When the initramfs (or the init system) mount /var, they
> make the link.
> 
> > When I saw the messages about LVM and /var, that caused LVM to fail to
> > start.  I wouldn't put / on LVM and wouldn't expect it to work without a
> > init thingy either.  Thing is, based on it failing, you can't have /var
> > on a separate partition and expect LVM to start.  So, if you use LVM
> > for /usr and/or /var, you have to have a init thingy even if / is on a
> > regular file system.
> 
> Yes, as I said in my last mail, if you need LVM, you need an
> initramfs. Remove the LVM, and you can have /var  (and /usr for that
> matter) withouth an initramfs. Where/when did I say something
> different?
> 
> >>> I'm telling ya'll, /home is coming.
> >> 
> >> That is just ridiculous.
> > 
> > I would have said the same thing about /usr a year ago.  I'm not saying
> > it is coming next week but . . .
> 
> You can speculate all you want. Fact is, nobody has proposed that, and
> there is not even a single email suggesting that it will be necessary.
> On the contrary, the requirement for an initramfs or a /usr inside the
> same partition as / has been being discussed years ago; if you had
> followed the developers lists, you wil had hear about it months before
> it happened.
> 
> Nothing similar has happened with /var, least of it /home.
> 
> >>>   We are going to end up where we
> >>> can only have one drive in our Linux boxes for the OS and its
> >>> relatives.>> 
> >> And so is this: more FUD.
> >> 
> >>> That or we will ALL have to start using the pesky init* thingy.
> >> 
> >> More FUD: the current proposal (from Zac, the principal coder of
> >> portage, and someone who actually wrotes code and know what he is
> >> talking about) is this:
> >> 
> >> 
> >> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda14148849872
> >> 9fe8.xml
> >> 
> >> It basically removes the need for a "pesky init* thingy", although for
> >> the life of me I cannot understand why someone will not see the
> >> technical advantages of actually using an initramfs.
> > 
> > I'll have to read his link later.
> 
> Please do.
> 
> >>> I got 7 acres of land here, complete with trees.  If someone can
> >>> find the dev that started this mess, I can find some rope.  Just
> >>> saying.  ;-)  Oh, I
> >>> live half a mile from the river too.  Makes for a good dump site.
> >>>  lol
> >>> 
> >>> I noticed the other day that when LVM tries to start, it fails.  I
> >>> have
> >>> /var
> >>> on a separate partition here.  It was complaining about something on
> >>> /var missing.  So, you may be late in reporting this.  I think it
> >>> is already needed for LVM if /usr or /var is on a separate
> >>> partition.
> >> 
> >> Again, get the facts right. If you use LVM you will need to use an
> >> initramfs. If you only use a separated /usr you will be able to use
> >> Zac's proposal.
> >> 
> >> In no case whatsoever you will be required to have /var on the same
> >> partition as /. Nobody has ever proposed that. /run and /run/lock are
> >> not /var.
> >> 
> >> Regards.
> > 
> > No one proposed that /usr was required until just recently.
> 
> http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1337
> 
> That was on February 25, this year. *Eight* months ago. And the stable
> udev in Gentoo still "supports" (it really doesn't, but whatever) a
> separated /usr.
> 
> > Saying it won't
> > happen really puts you in a bad spot when or if it does.  If you know
> > this for sure and certain, I want your crystal ball.
> 
> It's called an "educated guess". Of course I could be wrong; but I am
> more than willing to bet a nice expensive dinner with anyone that it
> is not going to happen in the next ten years. Any takers?

I would. But given the way udev people "solve" those issues, I don't.
If something on /var is needed during boot in the next ten years, they will 
propose to move it to /. They do it with /run, they do it with /lock, they 
will do it the same way the next time such an issue arises.

> Regards.

Best,
Michael

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> Hi Canek,
>
> On Saturday, 15. October 2011 02:02:13 Canek Peláez Valdés wrote:
>> On Sat, Oct 15, 2011 at 1:37 AM, Dale <rdalek1967@gmail.com> wrote:
>> > Canek Peláez Valdés wrote:
>> >> On Fri, Oct 14, 2011 at 11:56 PM, Dale<rdalek1967@gmail.com>  wrote:
>> >>> Pandu Poluan wrote:
>> >>>
>> >>> On Oct 15, 2011 5:49 AM, "Dale"<rdalek1967@gmail.com>  wrote:
>> >>>> Neil Bothwick wrote:
>> >>>>> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
>> >>>>>> A'right now.  I'm going to start on hal and /usr being on /
>> >>>>>> again.
>> >>>>>>  :-P
>> >>>>>
>> >>>>> Jeez, 43 years on and you're still going on about it...
>> >>>>
>> >>>> Dang, I was only a year old when hal came out?  That just doubled
>> >>>> my
>> >>>> age.
>> >>>>  It's closer to what I feel like tho.
>> >>>>
>> >>>> I'm still not happy with /usr being required tho.  That is still
>> >>>> standing
>> >>>> on a bad nerve.  Don't worry tho, I got plenty of those bad
>> >>>> nerves.  :-P>>>
>> >>> Do you know that there's a plan to move /var/run to / also? ;-)
>> >>>
>> >>> Rgds,
>> >>>
>> >>>
>> >>> Now someone on here swears up and down that /var isn't going to be
>> >>> required
>> >>> on /.
>> >>
>> >> /var != /var/run
>> >> /var != /var/lock
>> >>
>> >> /var/run is going in /run, but /var/run (by definition) only contains
>> >> things like PID files and runtime sockets. In the same vein, /var/lock
>> >> also is going into /run/lock. I have acknowledged this from the very
>> >> beginning, and I have been pointing out that implying that because
>> >> those two (really small and bounded) directories of /var are going
>> >> into /run and /run/lock, it doesn't mean that the whole /var will go
>> >> into /. That is disinformation.
>> >>
>> >> Nobody has even proposed that /var should go into the same partition
>> >> as /. *Nobody*, and the simplest proof of that is that nobody has
>> >> produced a single proof to the contrary. Not a single email, blog
>> >> post, or wiki entry from any system developer even mentions the
>> >> possibility of requiring /var to be in the same partition as /.
>> >>
>> >> Whoever says that /var will be required to be on the same partition as
>> >> / is either wildly speculating, or spreading FUD.
>> >
>> > So /var/run and /var/lock isn't on /var?  Even if they will be linking
>> > to
>> > another location, the link has to be there for whatever program to
>> > follow. If /var isn't mounted yet, there is nothing for the program to
>> > find.
>> The link goes the other way around. /run and /lock are the real
>> directories, /var/run is a link to /run, /var/lock is a link to
>> /run/lock. When the initramfs (or the init system) mount /var, they
>> make the link.
>>
>> > When I saw the messages about LVM and /var, that caused LVM to fail to
>> > start.  I wouldn't put / on LVM and wouldn't expect it to work without a
>> > init thingy either.  Thing is, based on it failing, you can't have /var
>> > on a separate partition and expect LVM to start.  So, if you use LVM
>> > for /usr and/or /var, you have to have a init thingy even if / is on a
>> > regular file system.
>>
>> Yes, as I said in my last mail, if you need LVM, you need an
>> initramfs. Remove the LVM, and you can have /var  (and /usr for that
>> matter) withouth an initramfs. Where/when did I say something
>> different?
>>
>> >>> I'm telling ya'll, /home is coming.
>> >>
>> >> That is just ridiculous.
>> >
>> > I would have said the same thing about /usr a year ago.  I'm not saying
>> > it is coming next week but . . .
>>
>> You can speculate all you want. Fact is, nobody has proposed that, and
>> there is not even a single email suggesting that it will be necessary.
>> On the contrary, the requirement for an initramfs or a /usr inside the
>> same partition as / has been being discussed years ago; if you had
>> followed the developers lists, you wil had hear about it months before
>> it happened.
>>
>> Nothing similar has happened with /var, least of it /home.
>>
>> >>>   We are going to end up where we
>> >>> can only have one drive in our Linux boxes for the OS and its
>> >>> relatives.>>
>> >> And so is this: more FUD.
>> >>
>> >>> That or we will ALL have to start using the pesky init* thingy.
>> >>
>> >> More FUD: the current proposal (from Zac, the principal coder of
>> >> portage, and someone who actually wrotes code and know what he is
>> >> talking about) is this:
>> >>
>> >>
>> >> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda14148849872
>> >> 9fe8.xml
>> >>
>> >> It basically removes the need for a "pesky init* thingy", although for
>> >> the life of me I cannot understand why someone will not see the
>> >> technical advantages of actually using an initramfs.
>> >
>> > I'll have to read his link later.
>>
>> Please do.
>>
>> >>> I got 7 acres of land here, complete with trees.  If someone can
>> >>> find the dev that started this mess, I can find some rope.  Just
>> >>> saying.  ;-)  Oh, I
>> >>> live half a mile from the river too.  Makes for a good dump site.
>> >>>  lol
>> >>>
>> >>> I noticed the other day that when LVM tries to start, it fails.  I
>> >>> have
>> >>> /var
>> >>> on a separate partition here.  It was complaining about something on
>> >>> /var missing.  So, you may be late in reporting this.  I think it
>> >>> is already needed for LVM if /usr or /var is on a separate
>> >>> partition.
>> >>
>> >> Again, get the facts right. If you use LVM you will need to use an
>> >> initramfs. If you only use a separated /usr you will be able to use
>> >> Zac's proposal.
>> >>
>> >> In no case whatsoever you will be required to have /var on the same
>> >> partition as /. Nobody has ever proposed that. /run and /run/lock are
>> >> not /var.
>> >>
>> >> Regards.
>> >
>> > No one proposed that /usr was required until just recently.
>>
>> http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1337
>>
>> That was on February 25, this year. *Eight* months ago. And the stable
>> udev in Gentoo still "supports" (it really doesn't, but whatever) a
>> separated /usr.
>>
>> > Saying it won't
>> > happen really puts you in a bad spot when or if it does.  If you know
>> > this for sure and certain, I want your crystal ball.
>>
>> It's called an "educated guess". Of course I could be wrong; but I am
>> more than willing to bet a nice expensive dinner with anyone that it
>> is not going to happen in the next ten years. Any takers?
>
> I would. But given the way udev people "solve" those issues, I don't.
> If something on /var is needed during boot in the next ten years, they will
> propose to move it to /. They do it with /run, they do it with /lock, they
> will do it the same way the next time such an issue arises.

You keep speculating and speculating. When you have some evidence to
sustain your claims, we talk.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Michael Schreckenbauer]

On Saturday, 15. October 2011 02:21:18 Canek Peláez Valdés wrote:
> On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauer <grimlog@gmx.de> 
wrote:
> > Hi Canek,
> > 
> > On Saturday, 15. October 2011 02:02:13 Canek Peláez Valdés wrote:
> >> On Sat, Oct 15, 2011 at 1:37 AM, Dale <rdalek1967@gmail.com> wrote:
> >> > Canek Peláez Valdés wrote:
> >> >> On Fri, Oct 14, 2011 at 11:56 PM, Dale<rdalek1967@gmail.com>  wrote:
> >> >>> Pandu Poluan wrote:
> >> >>> 
> >> >>> On Oct 15, 2011 5:49 AM, "Dale"<rdalek1967@gmail.com>  wrote:
> >> >>>> Neil Bothwick wrote:
> >> >>>>> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
> >> >>>>>> A'right now.  I'm going to start on hal and /usr being
> >> >>>>>> on /
> >> >>>>>> again.
> >> >>>>>>  :-P
> >> >>>>> 
> >> >>>>> Jeez, 43 years on and you're still going on about it...
> >> >>>> 
> >> >>>> Dang, I was only a year old when hal came out?  That just
> >> >>>> doubled
> >> >>>> my
> >> >>>> age.
> >> >>>>  It's closer to what I feel like tho.
> >> >>>> 
> >> >>>> I'm still not happy with /usr being required tho.  That is
> >> >>>> still
> >> >>>> standing
> >> >>>> on a bad nerve.  Don't worry tho, I got plenty of those bad
> >> >>>> nerves.  :-P>>>
> >> >>> 
> >> >>> Do you know that there's a plan to move /var/run to / also?
> >> >>> ;-)
> >> >>> 
> >> >>> Rgds,
> >> >>> 
> >> >>> 
> >> >>> Now someone on here swears up and down that /var isn't going
> >> >>> to be
> >> >>> required
> >> >>> on /.
> >> >> 
> >> >> /var != /var/run
> >> >> /var != /var/lock
> >> >> 
> >> >> /var/run is going in /run, but /var/run (by definition) only
> >> >> contains
> >> >> things like PID files and runtime sockets. In the same vein,
> >> >> /var/lock also is going into /run/lock. I have acknowledged
> >> >> this from the very beginning, and I have been pointing out that
> >> >> implying that because those two (really small and bounded)
> >> >> directories of /var are going into /run and /run/lock, it
> >> >> doesn't mean that the whole /var will go into /. That is
> >> >> disinformation.
> >> >> 
> >> >> Nobody has even proposed that /var should go into the same
> >> >> partition
> >> >> as /. *Nobody*, and the simplest proof of that is that nobody
> >> >> has
> >> >> produced a single proof to the contrary. Not a single email,
> >> >> blog
> >> >> post, or wiki entry from any system developer even mentions the
> >> >> possibility of requiring /var to be in the same partition as /.
> >> >> 
> >> >> Whoever says that /var will be required to be on the same
> >> >> partition as / is either wildly speculating, or spreading FUD.
> >> > 
> >> > So /var/run and /var/lock isn't on /var?  Even if they will be
> >> > linking
> >> > to
> >> > another location, the link has to be there for whatever program to
> >> > follow. If /var isn't mounted yet, there is nothing for the
> >> > program to
> >> > find.
> >> 
> >> The link goes the other way around. /run and /lock are the real
> >> directories, /var/run is a link to /run, /var/lock is a link to
> >> /run/lock. When the initramfs (or the init system) mount /var, they
> >> make the link.
> >> 
> >> > When I saw the messages about LVM and /var, that caused LVM to
> >> > fail to
> >> > start.  I wouldn't put / on LVM and wouldn't expect it to work
> >> > without a init thingy either.  Thing is, based on it failing, you
> >> > can't have /var on a separate partition and expect LVM to start.
> >> >  So, if you use LVM for /usr and/or /var, you have to have a init
> >> > thingy even if / is on a regular file system.
> >> 
> >> Yes, as I said in my last mail, if you need LVM, you need an
> >> initramfs. Remove the LVM, and you can have /var  (and /usr for that
> >> matter) withouth an initramfs. Where/when did I say something
> >> different?
> >> 
> >> >>> I'm telling ya'll, /home is coming.
> >> >> 
> >> >> That is just ridiculous.
> >> > 
> >> > I would have said the same thing about /usr a year ago.  I'm not
> >> > saying it is coming next week but . . .
> >> 
> >> You can speculate all you want. Fact is, nobody has proposed that, and
> >> there is not even a single email suggesting that it will be necessary.
> >> On the contrary, the requirement for an initramfs or a /usr inside the
> >> same partition as / has been being discussed years ago; if you had
> >> followed the developers lists, you wil had hear about it months before
> >> it happened.
> >> 
> >> Nothing similar has happened with /var, least of it /home.
> >> 
> >> >>>   We are going to end up where we
> >> >>> can only have one drive in our Linux boxes for the OS and its
> >> >>> relatives.>>
> >> >> 
> >> >> And so is this: more FUD.
> >> >> 
> >> >>> That or we will ALL have to start using the pesky init*
> >> >>> thingy.
> >> >> 
> >> >> More FUD: the current proposal (from Zac, the principal coder of
> >> >> portage, and someone who actually wrotes code and know what he
> >> >> is
> >> >> talking about) is this:
> >> >> 
> >> >> 
> >> >> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda14148
> >> >> 849872 9fe8.xml
> >> >> 
> >> >> It basically removes the need for a "pesky init* thingy",
> >> >> although for the life of me I cannot understand why someone
> >> >> will not see the technical advantages of actually using an
> >> >> initramfs.
> >> > 
> >> > I'll have to read his link later.
> >> 
> >> Please do.
> >> 
> >> >>> I got 7 acres of land here, complete with trees.  If someone
> >> >>> can
> >> >>> find the dev that started this mess, I can find some rope.
> >> >>>  Just
> >> >>> saying.  ;-)  Oh, I
> >> >>> live half a mile from the river too.  Makes for a good dump
> >> >>> site.
> >> >>>  lol
> >> >>> 
> >> >>> I noticed the other day that when LVM tries to start, it
> >> >>> fails.  I
> >> >>> have
> >> >>> /var
> >> >>> on a separate partition here.  It was complaining about
> >> >>> something on
> >> >>> /var missing.  So, you may be late in reporting this.  I think
> >> >>> it
> >> >>> is already needed for LVM if /usr or /var is on a separate
> >> >>> partition.
> >> >> 
> >> >> Again, get the facts right. If you use LVM you will need to use
> >> >> an
> >> >> initramfs. If you only use a separated /usr you will be able to
> >> >> use
> >> >> Zac's proposal.
> >> >> 
> >> >> In no case whatsoever you will be required to have /var on the
> >> >> same
> >> >> partition as /. Nobody has ever proposed that. /run and
> >> >> /run/lock are
> >> >> not /var.
> >> >> 
> >> >> Regards.
> >> > 
> >> > No one proposed that /usr was required until just recently.
> >> 
> >> http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1337
> >> 
> >> That was on February 25, this year. *Eight* months ago. And the stable
> >> udev in Gentoo still "supports" (it really doesn't, but whatever) a
> >> separated /usr.
> >> 
> >> > Saying it won't
> >> > happen really puts you in a bad spot when or if it does.  If you
> >> > know
> >> > this for sure and certain, I want your crystal ball.
> >> 
> >> It's called an "educated guess". Of course I could be wrong; but I am
> >> more than willing to bet a nice expensive dinner with anyone that it
> >> is not going to happen in the next ten years. Any takers?
> > 
> > I would. But given the way udev people "solve" those issues, I don't.
> > If something on /var is needed during boot in the next ten years, they
> > will propose to move it to /. They do it with /run, they do it with
> > /lock, they will do it the same way the next time such an issue arises.
> 
> You keep speculating and speculating. When you have some evidence to
> sustain your claims, we talk.

My evidence is /run and /lock as stated in the mail you quoted.

> Regards.

Best,
Michael

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 2:32 AM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Saturday, 15. October 2011 02:21:18 Canek Peláez Valdés wrote:
>> On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauer <grimlog@gmx.de>
> wrote:
>> > Hi Canek,
>> >
>> > On Saturday, 15. October 2011 02:02:13 Canek Peláez Valdés wrote:
>> >> On Sat, Oct 15, 2011 at 1:37 AM, Dale <rdalek1967@gmail.com> wrote:
>> >> > Canek Peláez Valdés wrote:
>> >> >> On Fri, Oct 14, 2011 at 11:56 PM, Dale<rdalek1967@gmail.com>  wrote:
>> >> >>> Pandu Poluan wrote:
>> >> >>>
>> >> >>> On Oct 15, 2011 5:49 AM, "Dale"<rdalek1967@gmail.com>  wrote:
>> >> >>>> Neil Bothwick wrote:
>> >> >>>>> On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote:
>> >> >>>>>> A'right now.  I'm going to start on hal and /usr being
>> >> >>>>>> on /
>> >> >>>>>> again.
>> >> >>>>>>  :-P
>> >> >>>>>
>> >> >>>>> Jeez, 43 years on and you're still going on about it...
>> >> >>>>
>> >> >>>> Dang, I was only a year old when hal came out?  That just
>> >> >>>> doubled
>> >> >>>> my
>> >> >>>> age.
>> >> >>>>  It's closer to what I feel like tho.
>> >> >>>>
>> >> >>>> I'm still not happy with /usr being required tho.  That is
>> >> >>>> still
>> >> >>>> standing
>> >> >>>> on a bad nerve.  Don't worry tho, I got plenty of those bad
>> >> >>>> nerves.  :-P>>>
>> >> >>>
>> >> >>> Do you know that there's a plan to move /var/run to / also?
>> >> >>> ;-)
>> >> >>>
>> >> >>> Rgds,
>> >> >>>
>> >> >>>
>> >> >>> Now someone on here swears up and down that /var isn't going
>> >> >>> to be
>> >> >>> required
>> >> >>> on /.
>> >> >>
>> >> >> /var != /var/run
>> >> >> /var != /var/lock
>> >> >>
>> >> >> /var/run is going in /run, but /var/run (by definition) only
>> >> >> contains
>> >> >> things like PID files and runtime sockets. In the same vein,
>> >> >> /var/lock also is going into /run/lock. I have acknowledged
>> >> >> this from the very beginning, and I have been pointing out that
>> >> >> implying that because those two (really small and bounded)
>> >> >> directories of /var are going into /run and /run/lock, it
>> >> >> doesn't mean that the whole /var will go into /. That is
>> >> >> disinformation.
>> >> >>
>> >> >> Nobody has even proposed that /var should go into the same
>> >> >> partition
>> >> >> as /. *Nobody*, and the simplest proof of that is that nobody
>> >> >> has
>> >> >> produced a single proof to the contrary. Not a single email,
>> >> >> blog
>> >> >> post, or wiki entry from any system developer even mentions the
>> >> >> possibility of requiring /var to be in the same partition as /.
>> >> >>
>> >> >> Whoever says that /var will be required to be on the same
>> >> >> partition as / is either wildly speculating, or spreading FUD.
>> >> >
>> >> > So /var/run and /var/lock isn't on /var?  Even if they will be
>> >> > linking
>> >> > to
>> >> > another location, the link has to be there for whatever program to
>> >> > follow. If /var isn't mounted yet, there is nothing for the
>> >> > program to
>> >> > find.
>> >>
>> >> The link goes the other way around. /run and /lock are the real
>> >> directories, /var/run is a link to /run, /var/lock is a link to
>> >> /run/lock. When the initramfs (or the init system) mount /var, they
>> >> make the link.
>> >>
>> >> > When I saw the messages about LVM and /var, that caused LVM to
>> >> > fail to
>> >> > start.  I wouldn't put / on LVM and wouldn't expect it to work
>> >> > without a init thingy either.  Thing is, based on it failing, you
>> >> > can't have /var on a separate partition and expect LVM to start.
>> >> >  So, if you use LVM for /usr and/or /var, you have to have a init
>> >> > thingy even if / is on a regular file system.
>> >>
>> >> Yes, as I said in my last mail, if you need LVM, you need an
>> >> initramfs. Remove the LVM, and you can have /var  (and /usr for that
>> >> matter) withouth an initramfs. Where/when did I say something
>> >> different?
>> >>
>> >> >>> I'm telling ya'll, /home is coming.
>> >> >>
>> >> >> That is just ridiculous.
>> >> >
>> >> > I would have said the same thing about /usr a year ago.  I'm not
>> >> > saying it is coming next week but . . .
>> >>
>> >> You can speculate all you want. Fact is, nobody has proposed that, and
>> >> there is not even a single email suggesting that it will be necessary.
>> >> On the contrary, the requirement for an initramfs or a /usr inside the
>> >> same partition as / has been being discussed years ago; if you had
>> >> followed the developers lists, you wil had hear about it months before
>> >> it happened.
>> >>
>> >> Nothing similar has happened with /var, least of it /home.
>> >>
>> >> >>>   We are going to end up where we
>> >> >>> can only have one drive in our Linux boxes for the OS and its
>> >> >>> relatives.>>
>> >> >>
>> >> >> And so is this: more FUD.
>> >> >>
>> >> >>> That or we will ALL have to start using the pesky init*
>> >> >>> thingy.
>> >> >>
>> >> >> More FUD: the current proposal (from Zac, the principal coder of
>> >> >> portage, and someone who actually wrotes code and know what he
>> >> >> is
>> >> >> talking about) is this:
>> >> >>
>> >> >>
>> >> >> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda14148
>> >> >> 849872 9fe8.xml
>> >> >>
>> >> >> It basically removes the need for a "pesky init* thingy",
>> >> >> although for the life of me I cannot understand why someone
>> >> >> will not see the technical advantages of actually using an
>> >> >> initramfs.
>> >> >
>> >> > I'll have to read his link later.
>> >>
>> >> Please do.
>> >>
>> >> >>> I got 7 acres of land here, complete with trees.  If someone
>> >> >>> can
>> >> >>> find the dev that started this mess, I can find some rope.
>> >> >>>  Just
>> >> >>> saying.  ;-)  Oh, I
>> >> >>> live half a mile from the river too.  Makes for a good dump
>> >> >>> site.
>> >> >>>  lol
>> >> >>>
>> >> >>> I noticed the other day that when LVM tries to start, it
>> >> >>> fails.  I
>> >> >>> have
>> >> >>> /var
>> >> >>> on a separate partition here.  It was complaining about
>> >> >>> something on
>> >> >>> /var missing.  So, you may be late in reporting this.  I think
>> >> >>> it
>> >> >>> is already needed for LVM if /usr or /var is on a separate
>> >> >>> partition.
>> >> >>
>> >> >> Again, get the facts right. If you use LVM you will need to use
>> >> >> an
>> >> >> initramfs. If you only use a separated /usr you will be able to
>> >> >> use
>> >> >> Zac's proposal.
>> >> >>
>> >> >> In no case whatsoever you will be required to have /var on the
>> >> >> same
>> >> >> partition as /. Nobody has ever proposed that. /run and
>> >> >> /run/lock are
>> >> >> not /var.
>> >> >>
>> >> >> Regards.
>> >> >
>> >> > No one proposed that /usr was required until just recently.
>> >>
>> >> http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1337
>> >>
>> >> That was on February 25, this year. *Eight* months ago. And the stable
>> >> udev in Gentoo still "supports" (it really doesn't, but whatever) a
>> >> separated /usr.
>> >>
>> >> > Saying it won't
>> >> > happen really puts you in a bad spot when or if it does.  If you
>> >> > know
>> >> > this for sure and certain, I want your crystal ball.
>> >>
>> >> It's called an "educated guess". Of course I could be wrong; but I am
>> >> more than willing to bet a nice expensive dinner with anyone that it
>> >> is not going to happen in the next ten years. Any takers?
>> >
>> > I would. But given the way udev people "solve" those issues, I don't.
>> > If something on /var is needed during boot in the next ten years, they
>> > will propose to move it to /. They do it with /run, they do it with
>> > /lock, they will do it the same way the next time such an issue arises.
>>
>> You keep speculating and speculating. When you have some evidence to
>> sustain your claims, we talk.
>
> My evidence is /run and /lock as stated in the mail you quoted.

That is no evidence: as I have been saying from the beginning,
/var/run and /var/lock are not /var. I keep mentioning databases
because those use a lot of space. Needing them at boot time would be
absurd.

/run and /lock are tiny dirs, and perfect candidates for tempfs, and
then linking them from /var.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Dale]

Canek Peláez Valdés wrote:
> On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauer<grimlog@gmx.de>  wrote:
>>
>> I would. But given the way udev people "solve" those issues, I don't.
>> If something on /var is needed during boot in the next ten years, they will
>> propose to move it to /. They do it with /run, they do it with /lock, they
>> will do it the same way the next time such an issue arises.
> You keep speculating and speculating. When you have some evidence to
> sustain your claims, we talk.
>
> Regards.

Can you point to where a dev has said that /var, /home or any other 
changes will NEVER happen?  I would start with the dev that caused all 
this if it were me.  I would like to hear that from him for sure.  Let's 
see if you can prove your claim then we'll talk.

Like I said, a year or so ago, I would have thought anyone saying /usr 
would need to be on / to boot or a init thingy was losing their mind.  
It is just not the way Linux is supposed to be.  Yet here we are.

Dale

:-)  :-)

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 2:37 AM, Dale <rdalek1967@gmail.com> wrote:
> Canek Peláez Valdés wrote:
>>
>> On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauer<grimlog@gmx.de>
>>  wrote:
>>>
>>> I would. But given the way udev people "solve" those issues, I don't.
>>> If something on /var is needed during boot in the next ten years, they
>>> will
>>> propose to move it to /. They do it with /run, they do it with /lock,
>>> they
>>> will do it the same way the next time such an issue arises.
>>
>> You keep speculating and speculating. When you have some evidence to
>> sustain your claims, we talk.
>>
>> Regards.
>
> Can you point to where a dev has said that /var, /home or any other changes
> will NEVER happen?

Of course not, but this is the same as any accusation: the people
making the accusation has to provide the evidence. YOU are the one
making the accusation, YOU provide the evidence.

>  I would start with the dev that caused all this if it
> were me.  I would like to hear that from him for sure.  Let's see if you can
> prove your claim then we'll talk.

*I* don't have to prove anything because I'm talkin about the facts
*right now*. You guys are the ones speculating about an imaginary
future.

> Like I said, a year or so ago, I would have thought anyone saying /usr would
> need to be on / to boot or a init thingy was losing their mind.  It is just
> not the way Linux is supposed to be.  Yet here we are.

Says who? I say it is exactly the way Linux is supposed to be. And
/usr doesn't *need* to be on /; just get an initramfs and you can have
it in an NFS from the other side of the planet.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Dale]

Canek Peláez Valdés wrote:
> On Sat, Oct 15, 2011 at 2:37 AM, Dale<rdalek1967@gmail.com>  wrote:
>> Canek Peláez Valdés wrote:
>>> On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauer<grimlog@gmx.de>
>>>   wrote:
>>>> I would. But given the way udev people "solve" those issues, I don't.
>>>> If something on /var is needed during boot in the next ten years, they
>>>> will
>>>> propose to move it to /. They do it with /run, they do it with /lock,
>>>> they
>>>> will do it the same way the next time such an issue arises.
>>> You keep speculating and speculating. When you have some evidence to
>>> sustain your claims, we talk.
>>>
>>> Regards.
>> Can you point to where a dev has said that /var, /home or any other changes
>> will NEVER happen?
> Of course not, but this is the same as any accusation: the people
> making the accusation has to provide the evidence. YOU are the one
> making the accusation, YOU provide the evidence.

So you say it will never happen and you know that.  Ooooook.  Sounds 
like you have a real good crystal ball there.

>
>>   I would start with the dev that caused all this if it
>> were me.  I would like to hear that from him for sure.  Let's see if you can
>> prove your claim then we'll talk.
> *I* don't have to prove anything because I'm talkin about the facts
> *right now*. You guys are the ones speculating about an imaginary
> future.


I'm talking about what can likely happen in the future based on what has 
already happened.  Until recently, /usr didn't have to be on / with or 
without a init thingy.  Now it does.  See the point yet?



>
>> Like I said, a year or so ago, I would have thought anyone saying /usr would
>> need to be on / to boot or a init thingy was losing their mind.  It is just
>> not the way Linux is supposed to be.  Yet here we are.
> Says who? I say it is exactly the way Linux is supposed to be. And
> /usr doesn't *need* to be on /; just get an initramfs and you can have
> it in an NFS from the other side of the planet.
>
> Regards.

Oh for a very long time, /usr could be on a separate partition and no 
init thingy was required.  That changed right?  What change is going to 
happen next you reckon?  That is my point.  /usr is required today, /var 
is the only directory left except for /home.  I figure something on /var 
is next and then some ultra smart dev will find something that needs 
/home eventually.

I can't prove that it will for certain happen but I can say that is the 
way things are going based on the change that just happened.  You can 
not say it is never going to happen either.  You have no more proof than 
anyone else on this list.

Dale

:-)  :-)

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[pk]

On 2011-10-15 11:02, Canek Peláez Valdés wrote:

> Yes, as I said in my last mail, if you need LVM, you need an
> initramfs. Remove the LVM, and you can have /var  (and /usr for that
> matter) withouth an initramfs. Where/when did I say something
> different?

I assume you mean: "if you need LVM for /, you need an initramfs"?

Best regards

Peter K

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Claudio Roberto França Pereira]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

Wow. Just wow.

GREAT way to confuse and welcome the poor-English Chinese guy.

Welcome Lavender. You are now officially recognized as a human being, not a
bot.
We'll be glad to help you with Gentoo.

Please ignore all the FUD and discussion about /var needing (or not) to be
in the root partition, and the need for an initramfs. It's just bullshit for
us end users currently.

[-- Attachment #2: Type: text/html, Size: 412 bytes --]

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Michael Schreckenbauer]

Hi Claudio, hi Lavender,

On Saturday, 15. October 2011 13:46:31 Claudio Roberto França Pereira wrote:
> Wow. Just wow.

:)

> GREAT way to confuse and welcome the poor-English Chinese guy.
> Welcome Lavender. You are now officially recognized as a human being, not a
> bot.
> We'll be glad to help you with Gentoo.

you are right. We hijacked this thread for our own discussion. I apologize for 
this. I'll stop posting on this topic in this thread right now.

> Please ignore all the FUD and discussion about /var needing (or not) to be
> in the root partition, and the need for an initramfs. It's just bullshit for
> us end users currently.

Best,
Michael

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

On Sat, 15 Oct 2011 13:46:31 -0300, Claudio Roberto França Pereira wrote:

> Wow. Just wow.
> 
> GREAT way to confuse and welcome the poor-English Chinese guy.

Good point. Sorry Lavender, please feel free to start another thread...
which may or may not get hijacked.

> Please ignore all the FUD and discussion about /var needing (or not) to
> be in the root partition, and the need for an initramfs. It's just
> bullshit for us end users currently.

It is not bullshit, it is relevant to many Gentoo users. However, it is
not relevant to this topic.


-- 
Neil Bothwick

mpeg@11..

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]

On Sat, 15 Oct 2011 00:34:10 -0700, Canek Peláez Valdés wrote:

> /var != /var/run
> /var != /var/lock
> 
> /var/run is going in /run, but /var/run (by definition) only contains
> things like PID files and runtime sockets. In the same vein, /var/lock
> also is going into /run/lock. I have acknowledged this from the very
> beginning, and I have been pointing out that implying that because
> those two (really small and bounded) directories of /var are going
> into /run and /run/lock,

Putting the contents of /var/run and /var/lock on the root filesystem
makes sense.

> Nobody has even proposed that /var should go into the same partition
> as /. *Nobody*, and the simplest proof of that is that nobody has
> produced a single proof to the contrary. Not a single email, blog
> post, or wiki entry from any system developer even mentions the
> possibility of requiring /var to be in the same partition as /.

The stated reason for requiring /usr on / is that udev can run
*arbitrary* scripts and commands. If they are arbitrary, they could
require access to anywhere, including /var or /home. That's the problem
with this approach. Instead of saying "it can run stuff from anywhere, so
anywhere must be mounted before udev is run" the fact that it is trying
to run these arbitrary commands before filesystems are mounted should be
addressed.

> Whoever says that /var will be required to be on the same partition as
> / is either wildly speculating, or spreading FUD.

It's not wild speculation, it is logical extrapolation of the current
approach.

> It basically removes the need for a "pesky init* thingy", although for
> the life of me I cannot understand why someone will not see the
> technical advantages of actually using an initramfs.

We understand its advantages in some circumstances, but  I cannot
understand why someone will not see the technical disadvantages of
actually using an initramfs.


-- 
Neil Bothwick

It is impossible to fully enjoy procrastination
unless one has plenty of work to do.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 2:53 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Sat, 15 Oct 2011 00:34:10 -0700, Canek Peláez Valdés wrote:
>
>> /var != /var/run
>> /var != /var/lock
>>
>> /var/run is going in /run, but /var/run (by definition) only contains
>> things like PID files and runtime sockets. In the same vein, /var/lock
>> also is going into /run/lock. I have acknowledged this from the very
>> beginning, and I have been pointing out that implying that because
>> those two (really small and bounded) directories of /var are going
>> into /run and /run/lock,
>
> Putting the contents of /var/run and /var/lock on the root filesystem
> makes sense.
>
>> Nobody has even proposed that /var should go into the same partition
>> as /. *Nobody*, and the simplest proof of that is that nobody has
>> produced a single proof to the contrary. Not a single email, blog
>> post, or wiki entry from any system developer even mentions the
>> possibility of requiring /var to be in the same partition as /.
>
> The stated reason for requiring /usr on / is that udev can run
> *arbitrary* scripts and commands. If they are arbitrary, they could
> require access to anywhere, including /var or /home. That's the problem
> with this approach. Instead of saying "it can run stuff from anywhere, so
> anywhere must be mounted before udev is run" the fact that it is trying
> to run these arbitrary commands before filesystems are mounted should be
> addressed.

With an initramfs you can have everything mounted by udev execution
time. But forget about that.

It's arbitrary (basically) on executables and libraries. If an script
needs something more (from /var, lets say), then the rule should be
written in such a way that it can be called after that directory is
mounted. If you try to put the same restriction with *executables*
(not data, like in the ALSA case), then you need to start moving every
executable to /, because that's the only way to guarantee that it
would be available aearly on boot time (if you don't use an initramfs
and have /usr separated).

That sucks. /bin and /lib were the original hack, for this very
reason: some executables were needed early at boot time, and they put
them there so they were available. The initramfs solves this problem;
at some point, /bin /lib and /sbin will no longer be necessary.

So yeah, the udev rules can execute arbitrary code, but the should not
run stupid code. There is a difference.

>> Whoever says that /var will be required to be on the same partition as
>> / is either wildly speculating, or spreading FUD.
>
> It's not wild speculation, it is logical extrapolation of the current
> approach.

You don't have enough data to extrapolate.

>> It basically removes the need for a "pesky init* thingy", although for
>> the life of me I cannot understand why someone will not see the
>> technical advantages of actually using an initramfs.
>
> We understand its advantages in some circumstances, but  I cannot
> understand why someone will not see the technical disadvantages of
> actually using an initramfs.

Care to explain?

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 2427 bytes --]

On Sat, 15 Oct 2011 03:10:37 -0700, Canek Peláez Valdés wrote:

> It's arbitrary (basically) on executables and libraries. If an script
> needs something more (from /var, lets say), then the rule should be
> written in such a way that it can be called after that directory is
> mounted. If you try to put the same restriction with *executables*
> (not data, like in the ALSA case), then you need to start moving every
> executable to /, because that's the only way to guarantee that it
> would be available aearly on boot time (if you don't use an initramfs
> and have /usr separated).

Anything needed for early boot is already in /. The problem is that udev
is trying to run all its rules at that early stage, when it should not.
This currently causes some actions to fail because /usr is not mounted
yet. The solution is not to mount /usr early, because that only deals
with one case, but to make sure that udev does not run actions until the
full system is available. This has been stated many times by several
people in the previous threads.

> So yeah, the udev rules can execute arbitrary code, but the should not
> run stupid code. There is a difference.

Excluding stupid makes it non-arbitrary.

> >> Whoever says that /var will be required to be on the same partition
> >> as / is either wildly speculating, or spreading FUD.  
> >
> > It's not wild speculation, it is logical extrapolation of the current
> > approach.  
> 
> You don't have enough data to extrapolate.

I do, the statement about running arbitrary code means that it could
require access to anywhere.

> >> It basically removes the need for a "pesky init* thingy", although
> >> for the life of me I cannot understand why someone will not see the
> >> technical advantages of actually using an initramfs.  
> >
> > We understand its advantages in some circumstances, but  I cannot
> > understand why someone will not see the technical disadvantages of
> > actually using an initramfs.  
> 
> Care to explain?

Again? It's already been covered many times before. You expect people to
blindly accept your POV that an initramfs is a good thing, yet refuse to
see the circumstances where others believe it is not. For one thing,
implementing this in a stable, running system without interruption is a
non-trivial task.


-- 
Neil Bothwick

Where do forest rangers go to "get away from it all?"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Jonas de Buhr]

Am Sat, 15 Oct 2011 12:31:24 +0100
schrieb Neil Bothwick <neil@digimed.co.uk>:

> On Sat, 15 Oct 2011 03:10:37 -0700, Canek Peláez Valdés wrote:
> 
> > It's arbitrary (basically) on executables and libraries. If an
> > script needs something more (from /var, lets say), then the rule
> > should be written in such a way that it can be called after that
> > directory is mounted. If you try to put the same restriction with
> > *executables* (not data, like in the ALSA case), then you need to
> > start moving every executable to /, because that's the only way to
> > guarantee that it would be available aearly on boot time (if you
> > don't use an initramfs and have /usr separated).
> 
> Anything needed for early boot is already in /. The problem is that
> udev is trying to run all its rules at that early stage, when it
> should not. This currently causes some actions to fail because /usr
> is not mounted yet. The solution is not to mount /usr early, because
> that only deals with one case, but to make sure that udev does not
> run actions until the full system is available. This has been stated
> many times by several people in the previous threads.

correct. 

> > >> It basically removes the need for a "pesky init* thingy",
> > >> although for the life of me I cannot understand why someone will
> > >> not see the technical advantages of actually using an
> > >> initramfs.  

why would anyone *want* an initramfs? its a clumsy workaround for
limitations that should be overcome with better solutions.

> > >
> > > We understand its advantages in some circumstances, but  I cannot
> > > understand why someone will not see the technical disadvantages of
> > > actually using an initramfs.  

either you read your schopenhauer or you are good at spotting
bad/unfair arguments ;)

> > 
> > Care to explain?
> 
> Again? It's already been covered many times before. You expect people
> to blindly accept your POV that an initramfs is a good thing, yet
> refuse to see the circumstances where others believe it is not. For
> one thing, implementing this in a stable, running system without
> interruption is a non-trivial task.
> 
> 

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Alan McKinnon]

On Sat, 15 Oct 2011 00:34:10 -0700
Canek Peláez Valdés <caneko@gmail.com> wrote:

> /var != /var/run
> /var != /var/lock
> 
> /var/run is going in /run, but /var/run (by definition) only contains
> things like PID files and runtime sockets. In the same vein, /var/lock
> also is going into /run/lock. I have acknowledged this from the very
> beginning, and I have been pointing out that implying that because
> those two (really small and bounded) directories of /var are going
> into /run and /run/lock, it doesn't mean that the whole /var will go
> into /. That is disinformation.

It's tirely feasible to need to create a lock file before /var is
mounted, so it makes perfect sense to put those directories on /.

Even better is to create them as a tmpfs so you don't even need disk
drives to get a minimallt usable system.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Alan McKinnon]

On Sat, 15 Oct 2011 00:34:10 -0700
Canek Peláez Valdés <caneko@gmail.com> wrote:

> It basically removes the need for a "pesky init* thingy", although for
> the life of me I cannot understand why someone will not see the
> technical advantages of actually using an initramfs.

I'll use your own opening comment as a reply:

using != requiring

The benefits of an initramfs are insufficient to *require* an initramfs.

Now, we've been over this and thrashed it to death already. You had
your say and the majority consensus around here is that we do not like
it.

DROP THIS SUBJECT. RIGHT NOW. PLEASE.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[Joost Roeleveld]

On Saturday, October 15, 2011 12:34:10 AM Canek Peláez Valdés wrote:
> > I noticed the other day that when LVM tries to start, it fails.  I have
> > /var on a separate partition here.  It was complaining about something
> > on /var missing.  So, you may be late in reporting this.  I think it is
> > already needed for LVM if /usr or /var is on a separate partition.
> 
> Again, get the facts right. If you use LVM you will need to use an
> initramfs. If you only use a separated /usr you will be able to use
> Zac's proposal.

Get your own facts right.
I use LVM for everything except / and I do NOT need to use an initramfs.

It has worked this way for years and making an initramfs mandatory for this is 
a REGRESSION.

--
Joost

[gentoo-user] 回复： [gentoo-user] Apologize to everyone for my nonprofessional

[Lavender]

[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]

It's my fault, there're no line-breaks because I wrote the letters 
exactly like what the screenshot shows . I will write just like
this letter. No more questions , good evening and tomorrow is
a nice day !
 
 
------------------ 原始邮件 ------------------
发件人: "Michael Mol"<mikemol@gmail.com>;
发送时间: 2011年10月14日(星期五) 晚上11:52
收件人: "gentoo-user"<gentoo-user@lists.gentoo.org>; 

主题: Re: [gentoo-user] Apologize to everyone for my nonprofessional

 
On Fri, Oct 14, 82011 at 11:43 AM, Lavender <448463782@qq.com> wrote:
> First of all I think I should apologize for my poor English , you must be
> very painful to read my letters.
> I'm a Chinese student and my English is not very well , actually  it's suck.
> So I will pay attention to making
> letters more clear to understand.
>
> To be honest, I'm not good at writing e-mails as most Chinese does . We
> almost don't use e-mail . I know
> the letters I send don't have a clear subject and its contents are verbose ,
> so I'm really sorry , I won't do that
> any longer.

Very much appreciated!

>
> Michael Mol , you're right , I should reply in time, but you know it
> is 11:00 pm here when it is 7:00 am or 8:00 am in
> your place , maybe I went to bed and forgot this next morning . But it's not
> an excuse for me , so I will note it .

Hey, we've all got lives outside this mailing list. Except Dale, perhaps. :)

>
> You said there're no line-breaks in my letters , I'm not very clear about
> this, can you send a screenshot for me ?
> It is all normall in my mailbox .

This one came across fine, but see the attached screenshot. (Not sure
if the list will filter it. If the attachment doesn't make it through,
I'll link to the file)

>
> At last I want to explain why I don't try some methods you provide . I like
> to reach the essence of one thing , I want
> to know exactly why it should be this but not that . So the letters I reply
> become more and more simple , I will control myself to reply
> clearly.

I hope your experiences on this mailing list help you refine your
language skills. Sounds like you're reasonably motivated. :)


-- 
:wq

[-- Attachment #2: Type: text/html, Size: 2882 bytes --]

Re: [gentoo-user] Apologize to everyone for my nonprofessional

[du yang]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

On Saturday 10/15/11 00:05:35 CST, Lavender wrote:
> It's my fault, there're no line-breaks because I wrote the letters
> exactly like what the screenshot shows . I will write just like
> this letter. No more questions , good evening and tomorrow is
> a nice day !
>  

A little tip about your mail client.
It handles mail thread references incorrectly, and changes mail titles.

Maybe you could try a mail agent like gmail which does a good job for mailling lists.
-- 
oooO:::::::::
(..):::::::::
:\.(:::Oooo::
::\_)::(..)::
:::::::)./:::
::::::(_/::::

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]