LWN: Comments on "Linux in consumer electronics"

Linux in consumer electronics

clamiam — Fri, 19 Oct 2007 02:24:28 +0000

I knew about Tivo, but I was really surprised when setting up a Hitachi plasma TV for my
parents.  I was leafing through the manual when I came across the GPL!  It appears that this
model uses Linux as well as several bits of GNU software.

The article mentions that upgrades "would be handled by service centers", however this TV is
unique in its upgrade method.  You simply call Hitachi's support line (they're pretty nice, in
my experience) and request an upgrade card.  A few days later, you get a bubble-envelope with
an MMC card and a smaller, self-addressed, stamped bubble-envelope.  Just click the card into
the slot on the back of the set and hit the "upgrade" entry in the menu, and you're done.
Then put the MMC card into the smaller envelope and drop it in the mail.

The best part about this is the little notice they send along with the card.  It says
something to the effect of "PLEASE RETURN THE UPGRADE CARD AS SOON AS POSSIBLE.  Customers who
do not return the card in a reasonable amount of time will receive lower priority when
requesting future upgrades."

Linux in consumer electronics

oak — Thu, 11 Oct 2007 19:17:14 +0000

Big reason for using uClibc instead of glibc would be need for static binaries, static glibc binaries are huge and not even really static...

Linux in consumer electronics

k8to — Thu, 11 Oct 2007 18:35:18 +0000

It seems my choice of phrasing was not clear enough, here it is with an addition:

What the proprietary vendors had -- in comparison to completely home-grown solutions -- were superior centralization of management, a broader driver market, superior development tools, and .. *sometimes* focused technology for niche areas.

newlib is another alternative

JoeBuck — Thu, 11 Oct 2007 17:25:36 +0000

newlib is a small C library developed by Cygnus Solutions (now part of Red Hat) for their embedded systems customers, back when they were in that business (many pieces are of BSD origin).

Linux in consumer electronics

daney — Thu, 11 Oct 2007 16:52:22 +0000

The last time I checked (for mipsel-linux) the sizes of glibc an uClibc as reported by 'size' were about 1200KB vs. 750KB which is considerable if you have a 10MB RAM budget. When you go to 20MB and consider paging and the afore mentioned over-commit, the size difference starts to become less important. Other things to consider are binary compatibility between versions and availability of a high performance thread library (NPTL).

If you are concerned about memory consumption you should also look at the pre-linker which reduces the number of dirty pages in shared libraries. Support for this may be better in glibc.

The different C libraries have different strengths, you have to decide on a case by case basis which is better for a given situation.

Linux in consumer electronics

tbird20d — Thu, 11 Oct 2007 16:01:09 +0000

Using glibc in the most RAM-constrained devices is indeed odd. Sony started looking at glibc alternatives some years ago, and at least a few products have already shipped with something else. A few Sony products have shipped with uClibc, and some have shipped with our own minimized C library (which is even smaller than uClibc).

If you look at our Linux download site, and can't find the C library package, that's an indicator that we're using our own C library on that product. One example is the DSC-T100 still camera. For that product, you'll see that the list of open source user-space components is very small (only 5 packages).

Linux in consumer electronics

nix — Thu, 11 Oct 2007 10:56:04 +0000

Using glibc on an embedded platform with a 10Mb memory budget strikes me as... strange. This is explicitly not the environment it's targetted at: why not use uClibc, which *is* explicitly meant to play well on embedded systems?

Linux in consumer electronics

alex — Thu, 11 Oct 2007 09:04:19 +0000

Linux has pretty good driver support. Certainly for any mid-sized project (for example embedded systems with mini-PCI buses) it makes choosing devices easy if they have a Linux driver. Sure Windriver would write a network driver or a SCSI driver for vxWorks but we would pay a lot for it and if we wanted to switch devices in a later design we would have to pay again.

Linux in consumer electronics

k8to — Thu, 11 Oct 2007 06:12:44 +0000

From my experience working at a proprietary OS vendor, the driving factors were:

1 - desire for source code access on its own terms
2 - the way projects come about, buying a package to build something doesn't work for projects that sort of accidentally emerge
3 - wanting complete control over their projects, whether or not they have the skills to make that a reality
4 - seeing linux as a way to cut costs from continuing to maintain their existing home-grown OS (this was the majority of the market not ten years ago)
5 - ability to fix bugs that crop up

A lot of these are similar/overlapping ideas but they're different sorts of decision making processes that get you there. Proprietary platforms really were never competitive in terms of market share to the make-it-ourselves mindset.

What the proprietary vendors had were superior centralization of management, a broader driver market, superior development tools, and .. *sometimes* focused technology for niche areas. Linux defeats the first two outright, and tools vendors can easily sell stuff for developing on Linux. It's only the niche technology stuff that would still have you using something else.

Well, that and targets that are "too small" to run linux. No one's rearing to run linux on a 16bit microcontroller.

At least, that's my perspective.

Linux in consumer electronics

felixfix — Thu, 11 Oct 2007 01:57:34 +0000

I'd guess the most important reason for choosing linux is source code, so they aren't beholden to capricious proprietary vendors. I worked on one firmware project where the vendor drove us crazy with their lack of support. Even worse would be if the vendor goes out of business or takes their product in an unwanted direction, or, worst nightmare of all, strikes up some exclusive deal with a competitor. I could easily imagine Microsoft doing that if you annoyed them with, say, public criticism.