Hi all,
I'd like to share with all subscribers my experience with my first year on
this list.
Posting questions here is fruitless. They are offtopic by definition.
Who fscking care that I am trying to debug a kernel problem and my first
ksymoops compilation went astray? (I discovered that ksymoops needs bfd lib
from binutils a month later). We need no stinking decoded oops!
And we never were newbies, we were born with Linux in our blood!
Well, maybe the list is useful for bug reports? Maybe, here is an example:
>> BTW, don't go for 2.4.x, x>10. initrd is broken there and is still unfixed.
>Bullshit.
I've done a damn good investigation on that, I compiled over a dozen kernels
for that, I *know* where is the bug, I don't just moaning! Response: either
deafening silence or this "warm and encouraging" reply. We need no stinking
details of your problems.
You may think that this list is for patches. Well, partly.
Patches submitted here are ignored 50% of times. What's the use in explaining
to poster why patch is bad and how to improve it? He's expected to read minds
from distance. Or maybe we need no stinking new hackers, old boys are enough?
What this list is good for? I'll tell ya:
a) for discussions about proper name and abbreviation of kilobyte.
Oh, now I know how many _true _coders_ are there!
Just count that "KB/KiB" subj line in your lkml mail folder.
b) for telling patch authors that their patch should NOT be applied.
("Why we should turn off those bits in VIA chipset? They're documented
as 'debug, dont touch'". Who cares that with those bits set to 1
Athlons are oopsing like crazy.) It's so much easier to flame
that to _make_ patches, isn't it?
Ok, enough. Steam pressure is much lower now :-)
I wish in 2002 lkml signal/noise ratio to be much higher.
How about putting that in standard lkml sig:
-To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
-the body of a message to [email protected]
-More majordomo info at http://vger.kernel.org/majordomo-info.html
+Please make sure your posting is *useful* for linux kernel development
+To unsubscribe: read http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
OTOH, I must say that there are quite some good people there
I want to say "Thank you! Great coding!" to:
Linus, Alan Cox, Marcelo Tosatti (kernel maintenance)
(what about bug/patch tracking system, leaders?
it's sad to see good patches dropped and longstanding
bugs unaddressed)
Andrea Arcangeli (VM)
Robert Love (preemption)
Richard Gooch (devfs)
Trond Myklebust (nfs)
Al Viro (fs)
(but could you _please_ be less agressive Al? Your comments are useful,
but your emotions are always negative! What we have done to you?)
I don't remember all of you, definitely this list must be longer...
Happy New Year to everyone.
--
vda
You're not alone. Frankly, I just skim the subjects and some messages to figure
out whether or not to read further.
Don't get discouraged. There are way more readers who don't post than the vocal
minority who whine about coding styles or why Linus didn't pick up their patch. I
found this out a while ago. I wrote the original FreeDOS code and ran into this
constantly. I admire Linus for not letting it get him down; it did for me. I
eventually quit the project altogether, disgusted with the bozos.
Well, I know I'm going to get flames on this one. That's OK, it'll keep me warm
this Christmas. May everyone have a safe and happy Holiday Season.
Pat
vda wrote:
> Hi all,
>
> I'd like to share with all subscribers my experience with my first year on
> this list.
>
> Posting questions here is fruitless. They are offtopic by definition.
> Who fscking care that I am trying to debug a kernel problem and my first
> ksymoops compilation went astray? (I discovered that ksymoops needs bfd lib
> from binutils a month later). We need no stinking decoded oops!
> And we never were newbies, we were born with Linux in our blood!
>
> Well, maybe the list is useful for bug reports? Maybe, here is an example:
> >> BTW, don't go for 2.4.x, x>10. initrd is broken there and is still unfixed.
> >Bullshit.
> I've done a damn good investigation on that, I compiled over a dozen kernels
> for that, I *know* where is the bug, I don't just moaning! Response: either
> deafening silence or this "warm and encouraging" reply. We need no stinking
> details of your problems.
>
> You may think that this list is for patches. Well, partly.
> Patches submitted here are ignored 50% of times. What's the use in explaining
> to poster why patch is bad and how to improve it? He's expected to read minds
> from distance. Or maybe we need no stinking new hackers, old boys are enough?
>
> What this list is good for? I'll tell ya:
>
> a) for discussions about proper name and abbreviation of kilobyte.
> Oh, now I know how many _true _coders_ are there!
> Just count that "KB/KiB" subj line in your lkml mail folder.
>
> b) for telling patch authors that their patch should NOT be applied.
> ("Why we should turn off those bits in VIA chipset? They're documented
> as 'debug, dont touch'". Who cares that with those bits set to 1
> Athlons are oopsing like crazy.) It's so much easier to flame
> that to _make_ patches, isn't it?
>
> Ok, enough. Steam pressure is much lower now :-)
>
> I wish in 2002 lkml signal/noise ratio to be much higher.
> How about putting that in standard lkml sig:
>
> -To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> -the body of a message to [email protected]
> -More majordomo info at http://vger.kernel.org/majordomo-info.html
> +Please make sure your posting is *useful* for linux kernel development
> +To unsubscribe: read http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> OTOH, I must say that there are quite some good people there
> I want to say "Thank you! Great coding!" to:
>
> Linus, Alan Cox, Marcelo Tosatti (kernel maintenance)
> (what about bug/patch tracking system, leaders?
> it's sad to see good patches dropped and longstanding
> bugs unaddressed)
> Andrea Arcangeli (VM)
> Robert Love (preemption)
> Richard Gooch (devfs)
> Trond Myklebust (nfs)
> Al Viro (fs)
> (but could you _please_ be less agressive Al? Your comments are useful,
> but your emotions are always negative! What we have done to you?)
>
> I don't remember all of you, definitely this list must be longer...
>
> Happy New Year to everyone.
> --
> vda
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
This has been my expereince. Every question I ever ask goes unanswered.
> I'd like to share with all subscribers my experience with my first year on
> this list.
>
> Posting questions here is fruitless. They are offtopic by definition.
> Who fscking care that I am trying to debug a kernel problem and my first
> ksymoops compilation went astray? (I discovered that ksymoops needs bfd lib
> from binutils a month later). We need no stinking decoded oops!
> And we never were newbies, we were born with Linux in our blood!
>
> Well, maybe the list is useful for bug reports? Maybe, here is an example:
> >> BTW, don't go for 2.4.x, x>10. initrd is broken there and is still unfixed.
> >Bullshit.
> I've done a damn good investigation on that, I compiled over a dozen kernels
> for that, I *know* where is the bug, I don't just moaning! Response: either
> deafening silence or this "warm and encouraging" reply. We need no stinking
> details of your problems.
>
> You may think that this list is for patches. Well, partly.
> Patches submitted here are ignored 50% of times. What's the use in explaining
> to poster why patch is bad and how to improve it? He's expected to read minds
> from distance. Or maybe we need no stinking new hackers, old boys are enough?
>
> What this list is good for? I'll tell ya:
>
> a) for discussions about proper name and abbreviation of kilobyte.
> Oh, now I know how many _true _coders_ are there!
> Just count that "KB/KiB" subj line in your lkml mail folder.
>
> b) for telling patch authors that their patch should NOT be applied.
> ("Why we should turn off those bits in VIA chipset? They're documented
> as 'debug, dont touch'". Who cares that with those bits set to 1
> Athlons are oopsing like crazy.) It's so much easier to flame
> that to _make_ patches, isn't it?
>
> Ok, enough. Steam pressure is much lower now :-)
>
> I wish in 2002 lkml signal/noise ratio to be much higher.
> How about putting that in standard lkml sig:
>
> -To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> -the body of a message to [email protected]
> -More majordomo info at http://vger.kernel.org/majordomo-info.html
> +Please make sure your posting is *useful* for linux kernel development
> +To unsubscribe: read http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> OTOH, I must say that there are quite some good people there
> I want to say "Thank you! Great coding!" to:
>
> Linus, Alan Cox, Marcelo Tosatti (kernel maintenance)
> (what about bug/patch tracking system, leaders?
> it's sad to see good patches dropped and longstanding
> bugs unaddressed)
> Andrea Arcangeli (VM)
> Robert Love (preemption)
> Richard Gooch (devfs)
> Trond Myklebust (nfs)
> Al Viro (fs)
> (but could you _please_ be less agressive Al? Your comments are useful,
> but your emotions are always negative! What we have done to you?)
>
> I don't remember all of you, definitely this list must be longer...
>
> Happy New Year to everyone.
> --
> vda
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Lab tests show that use of micro$oft causes cancer in lab animals
On Monday 24 December 2001 06:23 am, Pat Villani wrote:
> You're not alone. Frankly, I just skim the subjects and some messages to
> figure out whether or not to read further.
>
> Don't get discouraged. There are way more readers who don't post than the
> vocal minority who whine about coding styles or why Linus didn't pick up
> their patch. I found this out a while ago. I wrote the original FreeDOS
> code and ran into this constantly. I admire Linus for not letting it get
> him down; it did for me. I eventually quit the project altogether,
> disgusted with the bozos.
>
I am one of those readers that don't post, well to now. I don't want to make
a fool out of myself, plus nothing yet has really piqued my interest and I
never went to University to do CS or CE, played too much Rugby instead (but I
want to go sometime perhaps), so my prgramming really is not up to scratch
yet. Perhaps this is reflected on others too. Not above beta testing of
course.
Whining occurs pretty much everywhere, not just here. As this is an open and
free development perhaps people feel free to be a little less professional in
their words, rather than just reporting facts. Linus seems to be very Hobbit
like, very humble indeed. Only Linus probably knows why it does not seem to
get him down.
> Well, I know I'm going to get flames on this one. That's OK, it'll keep me
> warm this Christmas. May everyone have a safe and happy Holiday Season.
>
Nope, they may let you freeze instead. Happy Christmas and New Year to
everyone, may 2002 be very much more successful than 2001. 2001 was probably
jinxed due to Arthur C Clark anyway...
> Pat
Matt
response to questions does vary drasticly, I've been reading the list for
almost 5 years now and while I seldom post most of the time I get an
immediate response (unfortunantly sometimes I can't folow up immediatly
with the requested info). When I don't get a response for a few days I try
to get more detail on the problem and repost, eventually I do get some
response.
one thing to remember about posting here. if you get a response that is
just wrong, argue back, point out why it's wrong. Everyone on this list
(up to and including Linus) makes mistakes and dismisses stuff to quickly
at times. some questions get asked frequently enough that they have a
canned answer (useing binary only modules and reporting a bug for example)
but most of the time there is a real answer eventually.
David Lang
On Mon, 24 Dec 2001, Matthew Johnson wrote:
> Date: Mon, 24 Dec 2001 08:11:28 -0800
> From: Matthew Johnson <[email protected]>
> To: [email protected]
> Subject: Re: Maybe I have a bad day or something
>
> On Monday 24 December 2001 06:23 am, Pat Villani wrote:
> > You're not alone. Frankly, I just skim the subjects and some messages to
> > figure out whether or not to read further.
> >
> > Don't get discouraged. There are way more readers who don't post than the
> > vocal minority who whine about coding styles or why Linus didn't pick up
> > their patch. I found this out a while ago. I wrote the original FreeDOS
> > code and ran into this constantly. I admire Linus for not letting it get
> > him down; it did for me. I eventually quit the project altogether,
> > disgusted with the bozos.
> >
>
> I am one of those readers that don't post, well to now. I don't want to make
> a fool out of myself, plus nothing yet has really piqued my interest and I
> never went to University to do CS or CE, played too much Rugby instead (but I
> want to go sometime perhaps), so my prgramming really is not up to scratch
> yet. Perhaps this is reflected on others too. Not above beta testing of
> course.
>
> Whining occurs pretty much everywhere, not just here. As this is an open and
> free development perhaps people feel free to be a little less professional in
> their words, rather than just reporting facts. Linus seems to be very Hobbit
> like, very humble indeed. Only Linus probably knows why it does not seem to
> get him down.
>
>
> > Well, I know I'm going to get flames on this one. That's OK, it'll keep me
> > warm this Christmas. May everyone have a safe and happy Holiday Season.
> >
>
> Nope, they may let you freeze instead. Happy Christmas and New Year to
> everyone, may 2002 be very much more successful than 2001. 2001 was probably
> jinxed due to Arthur C Clark anyway...
>
> > Pat
>
> Matt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Think of L-K as a very lossy communications path where lots of retries are
necessary. john
On Mon, 24 Dec 2001, David Lang wrote:
> response to questions does vary drasticly, I've been reading the list for
> almost 5 years now and while I seldom post most of the time I get an
> immediate response (unfortunantly sometimes I can't folow up immediatly
> with the requested info). When I don't get a response for a few days I try
> to get more detail on the problem and repost, eventually I do get some
> response.
>
> one thing to remember about posting here. if you get a response that is
> just wrong, argue back, point out why it's wrong. Everyone on this list
> (up to and including Linus) makes mistakes and dismisses stuff to quickly
> at times. some questions get asked frequently enough that they have a
> canned answer (useing binary only modules and reporting a bug for example)
> but most of the time there is a real answer eventually.
>
> David Lang
>
>
> On Mon, 24 Dec 2001, Matthew Johnson wrote:
>
> > Date: Mon, 24 Dec 2001 08:11:28 -0800
> > From: Matthew Johnson <[email protected]>
> > To: [email protected]
> > Subject: Re: Maybe I have a bad day or something
> >
> > On Monday 24 December 2001 06:23 am, Pat Villani wrote:
> > > You're not alone. Frankly, I just skim the subjects and some messages to
> > > figure out whether or not to read further.
> > >
> > > Don't get discouraged. There are way more readers who don't post than the
> > > vocal minority who whine about coding styles or why Linus didn't pick up
> > > their patch. I found this out a while ago. I wrote the original FreeDOS
> > > code and ran into this constantly. I admire Linus for not letting it get
> > > him down; it did for me. I eventually quit the project altogether,
> > > disgusted with the bozos.
> > >
> >
> > I am one of those readers that don't post, well to now. I don't want to make
> > a fool out of myself, plus nothing yet has really piqued my interest and I
> > never went to University to do CS or CE, played too much Rugby instead (but I
> > want to go sometime perhaps), so my prgramming really is not up to scratch
> > yet. Perhaps this is reflected on others too. Not above beta testing of
> > course.
> >
> > Whining occurs pretty much everywhere, not just here. As this is an open and
> > free development perhaps people feel free to be a little less professional in
> > their words, rather than just reporting facts. Linus seems to be very Hobbit
> > like, very humble indeed. Only Linus probably knows why it does not seem to
> > get him down.
> >
> >
> > > Well, I know I'm going to get flames on this one. That's OK, it'll keep me
> > > warm this Christmas. May everyone have a safe and happy Holiday Season.
> > >
> >
> > Nope, they may let you freeze instead. Happy Christmas and New Year to
> > everyone, may 2002 be very much more successful than 2001. 2001 was probably
> > jinxed due to Arthur C Clark anyway...
> >
> > > Pat
> >
> > Matt
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
At 09:23 AM 12/24/2001 -0500, Pat Villani wrote:
>Don't get discouraged. There are way more readers who don't post than the
>vocal
>minority who whine about coding styles
Agreed.
What was that subject? "Coding style (a non-issue)"? If it's such a
non-issue, why were there so many messages dedicated to it?
I am thankful that the two things I've posted to this list were responded
to in a friendly manner (one about APIC options locking up an Inspiron
8100, and another asking for an explanation on what 'cache coloring' means).
--
Stevie-O
Real programmers use COPY CON PROGRAM.EXE
The good thing about the list is that
if you do have the time to analyze the code and if you can provide a solution
for a problem there are chances that the solution will make it mainstream.
The bad thing about the list is that
if you either don't have the time (as your job may have priority) or if you
just don't understand the code (which can take a lot of time which in turn will
probably contradict that you need to do something for a living) good enough a
non detailed error report or even a error report pointing to a problem without
a fix will go /dev/null quite often.
My wish would be that core delvelopers and maintainers shouldn't forget that the
kernel is a complex thing and that nobody can ever be a crack in all
disciplines. It is just the amount of data a human mind can cope with, taking
into account that most of us can't make a living from lkml/the kernel, leave
alone other open source projects we (might) manage.
Maybe I'm having a bad day, too. To keep things reasonable I would suggest
(again, others have done before) some kind of bug tracking system, at least for
the current stable kernel series.
This would help especially in case of hard to track bugs (thinking of the
initrd problem, I was hit, too) where accumulation of information can lead to
an actual solution of the problem. It would also allow for easier corporate
decision ("is the bug we're hitting closed so can we use the kernel" and
please note that a certain amount of companies is for one reason or the other
not using distros).
Please note that I'm not saying problems aren't solved. I'm not calling people
rude (everybody can have a bad day). It is more or less that if you hit
sufficient noise (lkml traffic) with insufficient information (no time for deep
analysis) your problem reports will probably be lost. And this doesn't help at
all to kernel progress and stability.
I don't know if I'm getting flamed on this one, I don't really care. From now
on I'm back to straightforward Q&A for another year.
PS: Wouldn't it be an idea to set up lkml-political/lkml-philosophical to
discuss the virtues of KiB and MiB over KB and MB? And if not, isn't it
possible to set up lkml-technical?
On Mon, 24 Dec 2001, vda wrote:
> Hi all,
>
> I'd like to share with all subscribers my experience with my first year on
> this list.
>
> Posting questions here is fruitless. They are offtopic by definition.
Your attitude sucks rocks.
> Who fscking care that I am trying to debug a kernel problem and my first
> ksymoops compilation went astray? (I discovered that ksymoops needs bfd lib
> from binutils a month later). We need no stinking decoded oops!
> And we never were newbies, we were born with Linux in our blood!
>
> Well, maybe the list is useful for bug reports? Maybe, here is an example:
> >> BTW, don't go for 2.4.x, x>10. initrd is broken there and is still unfixed.
> >Bullshit.
> I've done a damn good investigation on that, I compiled over a dozen kernels
> for that, I *know* where is the bug, I don't just moaning! Response: either
> deafening silence or this "warm and encouraging" reply. We need no stinking
> details of your problems.
Excuse me? I took the time to build/boot a minix initrd for which I
had absolutely no use, just to verify your problem. That led to you
discovering that having cramfs configured in for some reason mucks up
your minix initrd load. Someone else discovered a corruption problem,
and some heavy-weight talent fixed it instantly.
Seems to me that your problem is resolved.. unless you really _need_
the cramfs and minix initrd combo. If that's the case, I suggest you
either grab kdb and do some work, or submit a polite bug report to the
cramfs maintainer and be prepared to wait patiently.
CRAMFS FILESYSTEM
P: Daniel Quinlan
M: [email protected]
W: http://sourceforge.net/projects/cramfs/
S: Maintained
> You may think that this list is for patches. Well, partly.
> Patches submitted here are ignored 50% of times. What's the use in explaining
> to poster why patch is bad and how to improve it? He's expected to read minds
> from distance. Or maybe we need no stinking new hackers, old boys are enough?
>
> What this list is good for? I'll tell ya:
>
> a) for discussions about proper name and abbreviation of kilobyte.
> Oh, now I know how many _true _coders_ are there!
> Just count that "KB/KiB" subj line in your lkml mail folder.
>
> b) for telling patch authors that their patch should NOT be applied.
> ("Why we should turn off those bits in VIA chipset? They're documented
> as 'debug, dont touch'". Who cares that with those bits set to 1
> Athlons are oopsing like crazy.) It's so much easier to flame
> that to _make_ patches, isn't it?
Take close look at the above and imagine how many people on this list
may now think you're an obnoxious son-of-a-bitch not worth speaking to.
> Ok, enough. Steam pressure is much lower now :-)
Enough indeed.
> I wish in 2002 lkml signal/noise ratio to be much higher.
> How about putting that in standard lkml sig:
>
> -To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> -the body of a message to [email protected]
> -More majordomo info at http://vger.kernel.org/majordomo-info.html
> +Please make sure your posting is *useful* for linux kernel development
> +To unsubscribe: read http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
This post was useful?!?
> OTOH, I must say that there are quite some good people there
> I want to say "Thank you! Great coding!" to:
>
> Linus, Alan Cox, Marcelo Tosatti (kernel maintenance)
> (what about bug/patch tracking system, leaders?
> it's sad to see good patches dropped and longstanding
> bugs unaddressed)
> Andrea Arcangeli (VM)
> Robert Love (preemption)
> Richard Gooch (devfs)
> Trond Myklebust (nfs)
> Al Viro (fs)
> (but could you _please_ be less agressive Al? Your comments are useful,
> but your emotions are always negative! What we have done to you?)
How very decent of you to hand out accolades with attached derision.
> I don't remember all of you, definitely this list must be longer...
>
> Happy New Year to everyone.
> --
> vda
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Mon, 24 Dec 2001, vda wrote:
> Who fscking care that I am trying to debug a kernel problem and my first
> ksymoops compilation went astray? (I discovered that ksymoops needs bfd lib
> from binutils a month later). We need no stinking decoded oops!
> And we never were newbies, we were born with Linux in our blood!
If you had bothered to look at the INSTALL file in the ksymoops source,
you would have found this :-
To compile and link ksymoops, you need bfd.h, libbfd and libiberty. On
most systems, these are all part of the binutils package so installing
binutils is all that is required. On Debian systems, bfd.h (at least)
is in a separate package, binutils-dev.
Since you are obviously incapable of reading a simple INSTALL file and
then have the gall to complain on linux-kernel while demonstrating your
own ineptitude, you get a free introduction to my kill file. vda meet
kill file, kill file meet vda. Goodbye.
On Monday 24 December 2001 14:23, Pat Villani wrote:
> You're not alone. Frankly, I just skim the subjects and some messages to
> figure out whether or not to read further.
Of course you do. I assume almost everyone here does. Why would you sit and
read hundreds of messages that you have no interest in?
*MatthewM*
--
Children aren't happy without something to ignore,
And that's what parents were created for.
-- Ogden Nash
----- Original Message -----
From: "Keith Owens" <[email protected]>
To: "vda" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, December 25, 2001 8:30 PM
Subject: Re: Maybe I have a bad day or something
|
| Since you are obviously incapable of reading a simple INSTALL file and
| then have the gall to complain on linux-kernel while demonstrating your
| own ineptitude, you get a free introduction to my kill file. vda meet
| kill file, kill file meet vda. Goodbye.
Very mature.
Cheers!
Mark Harrop
[email protected]
`\|||/
(@@)
ooO_(_)_Ooo___________________________
_____|_____|_____|_____|_____|_____|_____|
Epping, Melbourne, Victoria, AUSTRALIA.