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-dis...@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-dis...@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 > <li...@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-netbo...@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-disc...@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
