linux-kernel - Re: 2.6.25-rc8: FTP transfer errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1207869029.19683.13.camel@localhost>
Date:	Fri, 11 Apr 2008 01:10:29 +0200
From:	vincent-perrier <vincent-perrier@...b-internet.fr>
To:	David Miller <davem@...emloft.net>
Cc:	jesper.juhl@...il.com, tilman@...p.cc, lkml@....ca,
	yoshfuji@...ux-ipv6.org, jeff@...zik.org, rjw@...k.pl,
	linux-kernel@...r.kernel.org, linux-net@...r.kernel.org
Subject: Re: 2.6.25-rc8: FTP transfer errors

I am an end user, I do not know precisely what bisecting means, but I
have spent some time on bug 8895, I suppose I have totally bisseced it,
but it seems that it has been lost. 
It is clearly a bug and I am still patching every kernel to avoid the 
fib6 crash, obviously I am the only one to get it.

It is true that kernel developper's time is more important than user's
one, but staying modest and respectfull of the brainless bisesting
users is a must! Our time is just as yours, not extensible.

Anyway, keep on the good kernel work, we all need it.


On Thu, 2008-04-10 at 15:46 -0700, David Miller wrote:
> From: "Jesper Juhl" <jesper.juhl@...il.com>
> Date: Fri, 11 Apr 2008 00:09:11 +0200
> 
> > You can't expect users to know how to debug a problem or even bisect
> > it.
> 
> [ The person you are replying to was being sarcastic, BTW. ]
> 
> That's not the case we're talking about in this specific instance.  In
> this particular case the user is more than capable of bisecting, he
> just isn't willing to invest the time.
> 
> And I'm supposed to be willing to invest the time to analyze the TCP
> dumps or whatever to diagnose the problem?  And I guess I should do
> this for every single networking bug report or issue?  Who is
> going to clone me and the rest of the core networking developers
> so that this is actually tenable?
> 
> That's ludicrious, I don't have a reproducer, this person does.  And
> if they bisect, we'll know _exactly_ what change introduced the
> problem.  Then I can use my brain to figure out the correct way
> to resolve the problem.
> 
> Bisecting is a mindless activity that saves developers tons of time.
> 
> What people don't get is that this is a situation where the "end node
> principle" applies.  When you have limited resources (here:
> developers) you don't push the bulk of the burdon upon them.  Instead
> you push things out to the resource you have a lot of, the end nodes
> (here: users), so that the situation actually scales.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> &#0;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/