[lsb-discuss] [fedora-arm] ARM summit at Plumbers 2011

Fri Aug 26 21:36:41 UTC 2011

I would relly like the dscussion to go on widely as it is now.
Otherwise I would probably not follow this interesting discussion.

best regards
keld

On Fri, Aug 26, 2011 at 10:02:09PM +0100, Luke Kenneth Casson Leighton wrote:
> russell, good to hear from you.
> 
> can i recommend, that although this is a really wide set of
> cross-posting on a discussion that underpins pretty much everything
> (except gnu/hurd and minix) because it's linux kernel, that, just as
> steve kindly advised, we keep this to e.g.
> cross-distro at lists.linaro.org?  i'll be doing that from now on [after
> this] perhaps including arm-netbooks as well, but will be taking off
> all the distros.
> 
> so - folks, let's be clear: please move this discussion to
> cross-distro at lists.linaro.org, and, if it's worthwhile discussing in
> person, please do contact steve, so he can keep the slot open at the
> Plumbers 2011 summit.
> 
> On Fri, Aug 26, 2011 at 5:35 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote:
> >> As such refactoring consolidated larger and larger chunks of kernel
> >> code, new designs would gravitate towards those consolidated
> >> implementations because they would be the dominant references.
> >
> > Don't bet on it. ??That's not how it works (unfortunately.)
> >
> > Just look at the many serial port inventions dreamt up by SoC designers -
> > everyone is different from each other. ??Now consider: why didn't they use
> > a well established standard 16550A or later design?
> 
>  *sigh* because they wanted to save power.  or pins.  or... just be
> bloody-minded.
> 
> > This "need to be different" is so heavily embedded in the mindset of the
> > hardware people that I doubt "providing consolidated implementations"
> > will make the blind bit of difference.
> 
>  i think... russell... after they are told, repeatedly, "no, you can't
> have that pile of junk in the mainline linux kernel, Get With The
> Programme", you'd think that, cumulatively if they end up having to
> maintain a 6mb patch full of such shit, they _might_ get with the
> programme?
> 
>  and if they don't, well.... who honestly cares?  if they don't, it's
> not *your* problem, is it?  _they_ pay their employees to continue to
> main a pile of junk, instead of spongeing off of _your_ time (and
> linus's, and everyone else's in the Free Software Community).
> 
> 
> > ??I doubt that hardware people
> > coming up with these abominations even care one bit about what's in
> > the kernel.
> 
>  then don't f******g make it _your_ problem, or anyone else's, upstream!! :)
> 
>  this is the core of the proposal that i have been advocating: if it's
> "selfish", i.e. as bill and many many others clearly agree with "if
> the bang-per-buck ratio is on the low side" then keep it *out* the
> mainline linux kernel...
> 
>  ... and that really is the end of the matter.
> 
> the sensible people that i've been talking to about this are truly
> puzzled as to why the principles of "cooperation and collaboration"
> behind free software are just being... completely ignored, in
> something as vital as The Linux Kernel, and they feel that it's really
> blindingly obvious that the "bang-per-buck" ratio of patches to
> mainline linux kernel need to go up.
> 
>  so the core of the proposal that is the proposed
> "selfish-vs-cooperation patch policy" is quite simple: if the patch
> has _some_ evidence of collaboration, cooperation, refactoring,
> sharing - *anything* that increases the bang-per-buck ratio with
> respect to the core fundamental principles of Free Software - it goes
> to the next phase [which is technical evaluation etc. etc.].
> otherwise, it's absolutely out, regardless of its technical
> correctness, and that's the end of it.
> 
>  the linux kernel mainline source tree should *not* be a
> dumping-ground for a bunch of selfish self-centred pathological
> profit-mongering corporations whose employees end up apologising in
> sheer embarrassment as they submit time-pressured absolutely shit
> non-cooperative and impossible-to-maintain code.
> 
>  you're not the only one, russell, who is pissed off at having to tidy
> up SoC vendors' patches.  there's another ARM-Linux guy, forget his
> name, specialises in samsung: two years ago he said that he was
> getting fed up with receiving yet another pile of rushed junk... and
> that's *just* him, specialising in samsung ARM SoCs!
> 
> we're just stunned that you, the recipient of _multiple_ SoC vendors
> piles of shite, have tolerated this for so long!
> 
> anyway - i've endeavoured to put together some examples, in case
> that's not clear: i admit it's quite hard to create clear examples,
> and would greatly appreciate help doing so.  i've had some very much
> appreciated help from one of the openwrt developers (thanks!)
> clarifying by creating another example that's similar to one which
> wasn't clear.
> 
>    http://lkcl.net/linux/linux-selfish.vs.cooperation.html
> 
> this should be _fun_, guys.  it shouldn't be a chore.  if you're not
> enjoying it, and not being paid, tell the people who are clearly
> taking the piss to f*** off!
> 
>  but - i also would like to underscore this with another idea: "lead
> by example" (which is why i've kept the large cross-distro list)  we -
> the free software community - are seeing tons of nice lovely android
> tablets, tons of nice lovely expensive bits of big iron and/or x86
> laptops, and only in very small areas (OpenRD Ultimate, GuruPlug,
> Pandaboard, IMX53QSB, Origen) are our needs for actual hardware which
> _we_ want (and i'm *not* being presumptious here - i'm inviting people
> to *say* what they want) just aren't being met.
> 
>  who wants a bloody 800x600 VIA VunnnderMedia ARM9 350mhz tablet, to
> do linux kernel and gnu/linux distribution development on, _anyway_???
>   and who the hell wants only 512mb of RAM (iMX51).  and who in their
> right fucking mind dreamed up that 1024x600 LCD panel size?
> 
>  so here's what i propose:
> 
>  we, The Free Software Community, want Our Figureheads (linus, bruce,
> alan, russell) to call us to arms (so to speak), to band together a la
> KickStarter http://kickstarter.org (or other), so that we can create
> the hardware platform(s) that *we* want, and, in the process, can take
> the opportunity to sort out the Linux Kernel mainline tree in the
> process (learning by doing, doing by leading, leading by example etc.
> etc.)
> 
>  apart from anything - and this goes to you, linus and russell - i
> think that you would be much happier taking a break from doing git
> patch conflict management, _actually_ getting down and dirty with some
> real device driver writing, and i think you'd be much happier doing
> that knowing that the device you were writing those kernel drivers for
> was something that actual real free software developers really really
> wanted.
> 
>  now, as i said above: i don't _dare_ to presume that i know what
> actual real free software developers want, in terms of hardware, but
> there's a small sampling on the debian-arm mailing list... let me drop
> you roughly in the middle of it, here:
> http://lists.debian.org/debian-arm/2011/08/msg00045.html  mostly that
> was focussed around those little engineering boards (panda, IMX53QSB,
> origen etc.) but my aim here is to get people to think:
> 
>  what hardware, which is fully free-software-compliant, that you would
> buy and recommend to others, that could also be attractive in
> mass-volume, do _you_ want to see, that would be useful to _you_?
> 
>  i'm getting fed up of seeing stuff come out of factories that's
> completely useless.  or gpl-violating.  and/or requires
> reverse-engineering.
> http://lkcl.net/linux/ideal-vs-reality.of.product.development.html for
> some background.
> 
>  as a free software developer, what hardware do YOU want?
> 
>  answers on this one to arm-netbooks at lists.phcomp.co.uk (subscription
> required, please remember)
> 
>  and, lastly - linus, russell, alan, bruce: there are people out there
> who would really appreciate if you could take up this call.  not just
> me.  we'd like to see you using your skills, and actually be happy and
> enjoy doing nitty-gritty linux kernel development, to the benefit of
> the free software community, instead of turning into patch
> junkies^H^H^H^H^H^Hmonkeys^H^H^H^H^H^H^Hmanagers.
> 
>  l.
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss