Quote of the week [LWN.net]

How many times have you seen some code coming out of a "GPL code release" from one of the many (mostly embedded) vendors that was actually useful to be contributed back to an existing Free Software project, or even that spawned a new Free Software project? I for my part am certain to say: Zero. The actual number might be close to zero, but very small anyways.

-- Harald Welte

to post comments

Quote of the week

Posted Nov 2, 2006 3:01 UTC (Thu) by sepreece (guest, #19270) [Link] (2 responses)

I don't know the full context of the quote [note to editor - it would be nice if the weekly quote linked back to its source].

I started to write notes about how and why the device makers' needs and interests differ from the community deelopers, but I think people generally already understand that.

On the other hand, I think the device makers are also getting more attuned to the community and that you will see more people from the device makers participating directly in projects and providing improvements at times and in ways that you will find useful. Remember, they're new to the community.

And, remember that the device makers tend to have the same complaints about the community that the community has about them. New features tend to do things they don't care about and to compromise quality attributes they care about in favor of ones they don't, and the community tends to reject changes that matter to the device makers because "they don't matter to laptops."

So, can we learn to live together and cooperate on making things better for all of us, respecting each others' differing needs and priorities, or would you rather the device makers just fork an embedded-centric kernel and be done with it?

Linking back

Posted Nov 2, 2006 3:02 UTC (Thu) by corbet (editor, #1) [Link] (1 responses)

It does link back to the source - click on the name.

Linking back

Posted Nov 2, 2006 15:13 UTC (Thu) by sepreece (guest, #19270) [Link]

Thanks! I hadn't noticed it was a link.

From a usability perspective, it might be better to put the name of the source ("Harald Welte's blog" in this case) after the person's name, and make that the link - I tend to expect person-name links to link to mailto URLs.

Vendor code quality

Posted Nov 2, 2006 8:00 UTC (Thu) by ldo (guest, #40946) [Link] (3 responses)

Would it be inflammatory to suggest that these vendors are simply providing code of a similar quality to the closed-source stuff they usually write?

Vendor code quality

Posted Nov 2, 2006 15:10 UTC (Thu) by sepreece (guest, #19270) [Link]

No, that's not inflammatory. It's generally exactly right - they're writing code for their own purposes, to their own standards, and with their own quality constraints (which may be better or worse than community standards, but are generally driven by different concerns).

Quality is a tricky issue - it has to be evaluated in terms of the viewer's needs and priorities. That is, it's more about fitness for purpose than about any absolute metric. Device makers' code may look like poor quality to Harald [and, perhaps, you], but the device makers would probably complain just as much about the quality of the community kernel code. Harald says "Fails basic portability - doesn't support SMP"; embedded users say "Fails basic code quality - pervasive bloat and lack of performance."

Harald complains that manufacturers use old versions. Yes, they tend to qualify a part (software or hardware) once and use it as long as they can, because they know it works. If you plan to build essentially the same device for several years, why would you change working parts? In addition, manufacturers typically need to stabilize the software six months or more before first product ship. That's not sloppy, that's giving themselves time to assure themselves and their dealers that the product works before starting volume production.

Harald complains, among other things, about failure to support SMP. Typical embedded devices don't have SMP concerns; trying to validate changes for SMP behavior would require extra work on hardware of no interest to the embedded developer, for no obvious payback.

Putting a cynical spin on this, since the community has taught the embedded developers that there is no interest in taking back changes that only benefit embedded users, what incentive is there for embedded developers to conform to the community's coding style, etc.?

However, as I said in my initial note, I believe many of the large manufacturers that are using Linux are beginning to shift toward engaging the community directly and aiming their code at the mainstream. I think you'll see that improve. However, I also expect the actual devices that ship to still be using kernels that the mainstream developers consider archaic.

Vendor code quality

Posted Nov 2, 2006 15:18 UTC (Thu) by NAR (subscriber, #1313) [Link]

Would it be inflammatory

A little :-) Anyway, there are issues like coding style which might have nothing to do with user-experienced quality (number of bugs, performance, etc.), but would still make the code hard to maintain by other people used to other coding styles.

Bye,NAR

Vendor code quality

Posted Nov 3, 2006 9:49 UTC (Fri) by lutchann (subscriber, #8872) [Link]

It's the same mind-set, anyway. The consumer embedded industry operates a lot more like the proprietary software industry than the open source world, because it's entirely volume-driven. The pressure to secure sales overrides any considerations of good software engineering practices. You're going to sell a lot more units if you can be the first 802.11e-capable WAP on the market than if you spend time writing good code. But it's actually worse, because as soon as the product ships, you outsource maintenance to a junior programmer in China who makes $5k/year and the real development team moves on to the next big project. After all, how many people buy support contracts for their $30 wireless router?

So, yeah. It kind of sounds like Harald is going through the same "culture shock" that other open source developers go through when they start looking at typical proprietary code for the first time. There's not much to say about that--looking at code written by people who like to code is infinitely more fun than looking at code written by people who just want to take home a paycheck every week.

Quote of the week

Posted Nov 2, 2006 15:09 UTC (Thu) by job (guest, #670) [Link] (2 responses)

I think Nokia did fairly well with the release of the 770 tablet.

Quote of the week

Posted Nov 2, 2006 17:40 UTC (Thu) by mrfredsmoothie (guest, #3100) [Link] (1 responses)

That's mild praise indeed. In fact, though, because of various bits of proprietary hardware and software (important userland software), one cannot build a modified maemo environment that has fully equivalent functionality to the binary distribution supplied by Nokia.

Quote of the week

Posted Nov 2, 2006 20:20 UTC (Thu) by net_bh (guest, #28735) [Link]

But aren't you free to replace those components with your own since you know what interface they provide?

uClibc NPTL

Posted Nov 2, 2006 16:58 UTC (Thu) by arafel (subscriber, #18557) [Link]

As one counter-example, Broadcom is paying for NPTL to be added to uClibc. So it might not be a direct code release, but there's no arguing that it's something useful being added to a free software project.

Quote of the week

Posted Nov 2, 2006 17:26 UTC (Thu) by gmaxwell (guest, #30048) [Link] (1 responses)

I read Harald's blog post and the biggest point I got out of it is:

Linus is wrong about the GPLv3's take on DRM.

It's clear from Harald's post that in his expirence the code submitted from embedded vendors is worthless. The result is that the license conformance is only useful to the users of the devices (who can then fix the bugs, update them, etc).

Without a prohibition against technical measures which make it impossible for the owner of a device to replace its software, the Linux kernel might as well be X11 licensed for all the good that it does the world.

There is nothing wrong with non-copyleft licenses, but Linus isn't saying that non-copyleft is enough from embedded vendors.. he's saying that the Source is enough.

Quote of the week

Posted Nov 2, 2006 18:54 UTC (Thu) by yokem_55 (subscriber, #10498) [Link]

That is what I got out of his comments as well, but Harold did not explicitly state this. This may however be a result that under existing German law, tivoization would likely be frowned upon with the GPL V2 as is.

Quote of the week

Posted Nov 2, 2006 21:44 UTC (Thu) by jzbiciak (guest, #5246) [Link] (2 responses)

There is one important thing this code contributes back, even if it's not suitable for mainline: Documentation. Often, aspects of the hardware aren't documented well, but the details may be divinable from a working (if crummy) implementation.

Just a thought.

Source vs Documentation

Posted Nov 2, 2006 22:57 UTC (Thu) by ldo (guest, #40946) [Link] (1 responses)

>There is one important thing this code contributes back, even if
>it's not suitable for mainline: Documentation. Often, aspects of the
>hardware aren't documented well, but the details may be divinable from
>a working (if crummy) implementation.

The OpenBSD developers, at least, would not agree with you:

Although this is a fairly decent vendor driver for a change, it is no substitute for having the proper hardware documentation.

Source vs Documentation

Posted Nov 3, 2006 5:16 UTC (Fri) by proski (guest, #104) [Link]

You are probably reading Brad's words too literally. "it is no substitute" doesn't mean "it cannot be used as substitute" in this context. It merely means "it is not nearly as good for us".

In fact, having any code from Broadcom is better than relying solely on the reverse engineered documentation. If nothing else, it can confirm or invalidate the assumptions made during the reverse engineering process.

Still useful to have the code

Posted Nov 9, 2006 7:10 UTC (Thu) by Cato (guest, #7643) [Link]

As a user of DD-WRT, a flashable Linux image for wireless routers such as the WRT54G, I think GPL code releases from embedded code vendors are very useful:

1. To the direct user community - this is quite large, and could be even larger if packaged up for easier purchase by Joe Consumer (e.g. buy a WiFi router with DD-WRT pre-installed, which the creator of DD-WRT is already doing)

2. To the free software community - simply spreading free software onto embedded devices helps people understand how useful Linux and free software can be. Many DD-WRT and OpenWRT users don't have any other Linux boxes at home, and mainly use Windows, so this is another inroad against proprietary software taking over the home network.

3. To the spread of open networking - FON, who sell very low cost wireless routers with embedded Linux as a way of building a vast network of WiFi hotspots, could not exist without GPL releases of wireless router software. The benefits of FON could be immense in terms of breaking the hold of telecoms companies on the last mile of the access network.

Quote of the week

Posted Nov 10, 2006 20:55 UTC (Fri) by katalix (guest, #41610) [Link]

Companies developing products with Embedded Linux fall into two
camps:-

1. Ex-RTOS users. After switching to Linux, these companies tend to
work the same closed, way. They don't involve the community in
anything they do. Sometimes they can't because they have NDAs with
their hardware suppliers, but most don't because they're unable to
adjust to Open Source development methods. These companies hack all
sorts of junk into open source code they inherited, just to make it
do what they want in their product. They have no interest in issues
their changes might cause to other users or architectures. There is
little point in contributing their changes back to the community
because even they know no-one else will be interested. They dump
GPL source tarballs on their website when their product is released
only to conform with GPL.

2. Linux-aware embedded users with no RTOS baggage. These companies
are often start-ups or established companies that have made a firm
commitment to Open Source development methods. They actively work
with the community to have their work integrated back into the
official sources and use the community as their support network. If
these companies have existing RTOS code, they don't ask their
developers to "make it work on Linux". Instead they redesign and
reimplement it such that it wouldn't look out of place if released
as an open source project. If some of their reimplemented code was
derived from GPL, they work with the community to contribute it
back _during_ their product development and as a result get useful
feedback about better ways to implement what they are trying to do.

I think most of the "GPL source releases" referenced by Harald's
original post come from companies in the first camp. They are rarely
useful, especially when the product's hardware isn't readily available
to individuals. When companies actively work with the community during
their project, it is contributed in the same way as any other GPL code
so we don't see it as coming from embedded vendors. We only notice the
junk coming from companies in the first camp and perceive that all
embedded vendors work that way with Linux.

I recently published a white paper on "Best Practices in Embedded
Linux". There's a forum on the website where anyone is welcome to post
comments.

http://www.katalix.com/doc/embedded_linux_best_practices.pdf