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]
Date:	Wed, 5 Jun 2013 23:38:52 +0100
From:	Luke Kenneth Casson Leighton <lkcl@...l.net>
To:	Tomasz Figa <tomasz.figa@...il.com>
Cc:	linux-arm-kernel@...ts.infradead.org,
	"jonsmirl@...il.com" <jonsmirl@...il.com>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	debian-arm@...ts.debian.org,
	Linux on small ARM machines 
	<arm-netbook@...ts.phcomp.co.uk>, debian-kernel@...ts.debian.org
Subject: Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

On Wed, Jun 5, 2013 at 10:52 PM, Tomasz Figa <tomasz.figa@...il.com> wrote:
> Hi Luke,

 allo tomasz :)

 ok - much of what you say is duplicated by what russell said, so in
effect the same reply is relevant, but there's been some cross-over.
i'll summarise below and cut all but the key question below:

> I tend to disagree with your view. Is it really our task to convince such
> companies to work with open source community?

 their sheer overwhelming success provides us with mass-volume
ultra-low cost hardware.  to not make an effort to accommodate them
would in this specific instance be a huge missed opportunity,
responsibility for which currently falls on the shoulders of the sunxi
community, where that small community is in no way considered
"authoritative" as an upstream source and thus every single GNU/Linux
Distro is left in a position of forcing people to follow insane
non-standard build procedures that are *way* outside of the capability
of the average person.

 so by the linux kernel developers intransigent position, the reach of
free software as a whole is greatly reduced.  simple logical
unavoidable conclusion.

 please feel free - linux kernel developers - to maintain this
intransigent position for as long as you find it useful to you to do
so.  btw, that is a sincere statement, devoid and completely free of
all and any implicit or explicit additional statements and
implications.


>> > Device tree on ARM's goal is to achieve a single kernel across
>> > vendors, not just a single kernel for a single vendor.
>>
>>  you'll be aware that i've mentioned a number of times and have
>> discussed at some length why this is a goal that is completely
>> impossible to achieve [*1].  sadly.
>
> I tend to disagree on this as well, but it's another story. Have read one
> of the discussions on this topic and it seemed to look more like lobbying
> for one of the standards being promoted by some company,

 yeahh, that's rather unfortunate.  i went to some lengths to avoid
mentioning eoma [*1] until there was a natural point at which it
became difficult *not* to bring it up, not least because i didn't hear
anyone else presenting any actual real workable solutions.

but, you have to bear in mind a couple of things:

a) i'm a free software developer and advocate.  "business", "lobbying"
etc. do not come naturally to me.  my associates scream at me
regularly.

b) i've been thinking about this incredibly hard problem for at least
4 years and almost *all* of my background in computing of the past 30
years leads me naturally towards actually coming up with a solution

c) i'm actually really, really really and truly going about *actively*
implementing that solution rather than just complaining about it *and*
i'm inviting free software developers to participate, why, because see
first sentence of a) above.

l.

[*1] which is an open standard, not a proprietary locked one.
--
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