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: <20090112094121.GD28564@linux-sh.org>
Date:	Mon, 12 Jan 2009 18:41:22 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	"Mark A. Miller" <mark@...ell.org>
Cc:	Bernd Petrovitsch <bernd@...mix.at>,
	Leon Woestenberg <leon.woestenberg@...il.com>,
	Rob Landley <rob@...dley.net>,
	"H. Peter Anvin" <hpa@...or.com>,
	Embedded Linux mailing list <linux-embedded@...r.kernel.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: PATCH [0/3]: Simplify the kernel build by removing perl.

On Mon, Jan 12, 2009 at 03:18:53AM -0600, Mark A. Miller wrote:
> On Mon, Jan 12, 2009 at 2:20 AM, Paul Mundt <lethal@...ux-sh.org> wrote:
> 
> Paul:
> I initially wrote a rather details response to your e-mail. But
> instead, I shall quote a previous e-mail of yours:
> 
> > I will repeat again that no one has provided a
> > _single_ reason for why they are unable to provide perl within their
> > constrained environment. Until that happens, this entire thread is a
> > joke.
> 
> And I did so. And you have disregarded it. That makes me question the
> logic of your fervent vehemence against such "Perl is perhaps not a
> good idea in the kernel build infrastructure" people like myself.
> 
You have done no such thing. You have provided an example as to why you
personally find perl objectionable, and in your previous mail you even
noted that you have patches for perl to fix the build issues, so there is
no fundamental reason why you are _unable_ to provide perl in your
environment. It all comes down to the fact you don't want to be bothered
to put the effort in to getting perl setup in your environment, which
quite frankly is no one's problem but your own.

Personally I think perl (and python for that matter) is a terrible
language and I wouldn't use it for anything of consequence, but again,
that is my personal opinion and has nothing to do with regards to the
build system and whether it was the better tool for the job as perceived
by the people that elected to implemented infrastructure using it. I
choose not to use it for my own projects, but I have no qualms with those
that do.

The kernel does not need to provide justification for every change that
goes on as long as there is a reasonable attempt not to break things for
other people. The onus is (and always has been) on you to demonstrate why
perl is an unreasonable dependency to push on embedded developers, and
you have failed utterly at demonstrating this in any sort of coherent
fashion.

I will repeat, there has not been a single coherent argument against what
makes perl inherently incapable of being supported. Every single thing
you have presented as a rebuttal has been your personal preference, which
in this case is simply irrelevant.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ