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: <495FEEAF.5020005@zytor.com>
Date:	Sat, 03 Jan 2009 15:03:11 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Leon Woestenberg <leon.woestenberg@...il.com>
CC:	Rob Landley <rob@...dley.net>,
	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.

Leon Woestenberg wrote:
> 
> I agree with Rob that the amount of required dependencies should be
> kept to a minimum.
> 
> If we only use 0.5% of a certain language (or: dependent package),
> then rather implement that 0.5% in the existing language.
> 
> Dependencies very quickly become dependency hell. If A requires B,
> then A also inherits all (future) requirements of B, etc. etc.
> 
> In my daily software development work with Linux and GNU software in
> general, 10% of it is spent fighting/removing these extremely "thin"
> or false depencies, so that it is usuable in embedded devices.
> 

First of all, I largely consider this a joke.  All real-life embedded
kernel builds take place on hosted platforms; anything else seems to be
done "just because it can be done", as a kind of show-off art project.
Cute, but hardly worth impeding the rest of the kernel community for.

We're not talking about general platform dependencies here, but build
dependencies for the kernel.  A platform that can build the kernel is
not a small platform.

Second of all, these patches are not fullworthy replacements.  The
original patch using bc had less dependencies, but bc failed on some
platforms, mysteriously.  The new patches have *more* environmental
dependencies than that ever did.

Third, if someone actually cares to do it right, I have a smallish
bignum library at http://git.zytor.com/?p=lib/pbn.git;a=summary that
might be a starting point.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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