Quote of the week [LWN.net]

Outside of servers it's no longer worth the effort of upstreaming. We're seeing the evolution of a different model of contribution both inside and outside of the kernel, where you have a lot of forking of trees, people taking code from each others forks and when needed getting together to create trees for their shared ends (eg Linaro), or where everyone by habit goes direct to the "pre-merge" trees - eg for graphics. Everyone does it, they talk about doing it "for now", "temporarily" or they don't talk about it because it's against the myth of the one upstream but they all do it because it's economic necessity.

Development cycles are getting faster, and the kernel is now relatively so slow to evolve that a phone or IoT product can be developed, released, discontinued and obsoleted before the driver is accepted upstream - by which time it's just a liability (although the style police will patch it for ten years without anyone ever using or testing it)

— Alan Cox

to post comments

Quote of the week

Posted Oct 8, 2015 10:45 UTC (Thu) by davidarusling (guest, #80637) [Link] (3 responses)

An interesting point from Alan. I agree with the economic neccessity. Getting the next phone out can gain a company $Bn in revenue. Moving to an upstream first or upstream in parallel is hard work. You change the way that the teams operate. This risks your next product and, for a while at least, is more effort. However, I believe that this is the way to go and, when I talk, I talk about moving from open source as a duty to open source as the way that software is developed in the 21st century.

Another barrier is the legal team. Company culture believes that every line of code has value and that it may reveal something of underlying patents. This is wrong, most code is utterly boring and reveals nothing.

None of this is an excuse, I believe that the ARM community needs to change. I worry where I accept a compromise against this aim, but I'm a pragmatist. I'm happy that the power management work is progressing upstream but not happy where BSPs contain forked kernel trees. I'd say that we've come a long way, just not far enough yet.

Quote of the week

Posted Oct 8, 2015 19:16 UTC (Thu) by sjj (guest, #2020) [Link] (1 responses)

Very good points. I think there are definitely different engineering cultures between for example server / web application developent and embedded development. Partly because they tend to work on different levels of the stack, but compare CoreOS with Hardkernel (odroid). Haven't most GPL enforcement issues been embedded systems, routers and so on?

For some of us greybeards it may come as a surprise that there are people now working in the industry who are younger than Linux. Free and open source software is very natural to them, it's always been around. At the same time, companies built on top of free software have learned how to create "open core" applications: generate goodwill and engage outside innovation through Community Editions, but keep more advanced features for paying customers. From an idealist position this is at least questionable, but from a pragmatic point of view, I think it still advances the state of the art.

On the larger issue of the future of free software, we are getting shut out from seeing the insides of The Computer Of The Future. For example, AWS is built on Linux, but we don't get to see their code. They take and modify FOSS but only give us an API. Are their modifications to Xen pushed upstream? Presumably Kinesis is Kafka, and Aurora is a re-implementation of MySQL, etc. Tivoization, round two?

Quote of the week

Posted Oct 8, 2015 20:42 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> For example, AWS is built on Linux, but we don't get to see their code.
Be thankful for it :)

Releasing internal Amazon or Google software is impractical. Internal corporate software usually depends on scores of internal services, which in turn depend on other services and so on. Maintaining and running your own versions of all dependencies is doubleplusunfun.

The better way is to make sure that API specification is correct and make independent API reimplementations.

Quote of the week

Posted Oct 10, 2015 23:16 UTC (Sat) by kiko (subscriber, #69905) [Link]

Alan is spot-on. There are myriad vendor trees out there that will never be merged; there is just not enough short-term incentive to do so.

But in the long run this motivates the SoCs to avoid having to touch kernel code as much as possible. If they can cram functionality into firmware, reuse an existing driver or simply drop features, they will -- just witness how attracted vendors have been to ACPI, as painful as that is. There may be a technical solution to each area of vendor variation, but unless Linaro takes it on is anybody motivated to build it?

Linaro promoted a lot of catch-up in the past 5 years. The real question is whether the gap that exists between unmergeable kernel trees and mainline is widening or closing.

Quote of the week

Posted Oct 9, 2015 1:17 UTC (Fri) by dps (guest, #5725) [Link] (6 responses)

There is a nasty security vulnerability in cacti 0.8.8c, which I have fixed as part of my day job. I will neither confirm nor deny any information about the bug but reveal that our product is affected. I don't know if or when the fix will will be upstreamed or bug reported, assuming nobody has reported it already.

There is even a business case for upstreaming the fix: it would eliminate the need to maintain a private patch. However convincing the suits required that the work be in there in enlightened self interest could be difficult.

I can confirm that there is some code which not only depends on servers you can't reach but is also awful and the people responsible for maintaining it know that. There is definitely a database which is unlikely to be worth real money but it is strictly forbidden to reveal the contents without explicit approval, which I think would be very difficult to get.

Quote of the week

Posted Oct 9, 2015 9:57 UTC (Fri) by jonnor (guest, #76768) [Link] (2 responses)

Why haven't you filed a bug with patch?

Upstreaming a bug fix

Posted Oct 11, 2015 3:46 UTC (Sun) by giraffedata (guest, #1954) [Link] (1 responses)

Why haven't you filed a bug with patch?

I think he's saying that the patch is copyrighted by his employer (as work for hire) and possibly a trade secret and that he doesn't believe his employer would easily give him permission to distribute/divulge it. The trade secret angle might make him afraid to reveal the bug even without a patch.

Upstreaming a bug fix

Posted Oct 15, 2015 13:05 UTC (Thu) by oldtomas (guest, #72579) [Link]

Perhaps we should nudge WikiLeaks towards hosting a "meta" bug tracker

Quote of the week

Posted Oct 10, 2015 18:12 UTC (Sat) by robert_s (subscriber, #42402) [Link]

"There is even a business case for upstreaming the fix"

I would consider it quite irresponsible not to do so.

Quote of the week

Posted Oct 15, 2015 8:14 UTC (Thu) by smowton (guest, #57076) [Link] (1 responses)

May I suggest you should invent a fictitious use case that would plausibly lead to discovering the bug and report it without a patch? No need to reveal potentially legally difficult code, just pose as a someone that found it but doesn't themselves know how to fix it.

Quote of the week

Posted Nov 7, 2015 15:29 UTC (Sat) by ghane (guest, #1805) [Link]

> May I suggest you should invent a fictitious use case that would plausibly lead to discovering the bug and report it without a patch?

Assuming that the original reporter was forbidden, either in this case or in general, from reporting this publicly, how would using a fake name be any different legally? And using a fake name might even make him ineligible to claim whistle-blower status later.

I would not encourage him to break a contract he has. It is not a good situation that he is in, but wearing a fake moustache is not going to make things better (for him, for us it will).

Quote of the week

Posted Oct 15, 2015 11:00 UTC (Thu) by moltonel (subscriber, #45207) [Link]

It's interesting to relate Alan's observation with the observation (by Ars Technica and others) that the vulnerability-patching status of Android devices is terrible. The industry is adopting more and more a "sell and forget" approach, which makes upstreaming costly but also leaves end-users in the ditch when a bug is found but nobody cares, forcing them to buy a new product instead.

As a company, if you're planning on providing firmware updates for the realistic lifetime of a device, upstreaming your patches is probably more cost-effective.
As a consumer, if you're hoping to use your smartphone or router for more than a couple of years, you should prefer companies that upstream their patches as it is a sign of long-term device support.