Gadgets With Linux Inside

An anonymous submitter sends in a link to a quick reference guide of various devices and gadgets that are in some way running Linux. Cell phones, set-top boxes, web pads, internet radios, and some miscellaneous gizmos (definitely take a look at the "other" page).

Comments

Re:Is there any "real" use

[joe_bruin]

these devices ship with linux, it's their embedded os. linux is making enormous gains in the embedded world due to the fact that it is both royalty free to ship, the source is completely available, the development tools are both free and familiar, and there is a fair amount of developers out there who are familiar with the kernel/drivers (but you already know this, of course).

consider a device like the oh-so-popular tivo or something more obscure like the phatbox or other portable devices. the makers of these devices have the options of:

• paying a dollar to people like windriver (who effectively monopolized bsd, along with vxworks, psos, and others) or psion for every unit shipped
• a couple of large bills to for a development license (qnx, ...)
• a mighty sum for development tools (green hills, nucleus, ...)
• all of the above (microsoft windows ce)
• or, get it all for free by using linux.

under many of these options, i doubt these (probably very small) companies would have ever been able to afford to bring a product to market. and every dollar that doesn't go to a 3rd party at retail is a dollar that goes towards r&d for the super-tivo or whatever (or stays in your pocket).

yes, i'm preaching to the choir. let them sing.

joe

Problem With Embedded Development on Linux

[Greyfox]

The Evil Satellite TV company that hired me to help work on a set-top box with Linux Embedded had a reasonably good idea about the hardware, although they DID change archetectures completely about 1/4th of the way through the development process. However, the department that was doing the software had no concept about developing for Linux. most of the development team were Windows programmers who barely even knew what a process was. Although the general idea was to use GTK for all the work on the system, the Windows programmers ended up hacking out a rudimentary UI library based on GDK. In practise, no GTK was ever in use there. Their UI library was inflexible and relied entirely on pixmaps and hotspots. Everything inherited from everything else; if you wanted to change interface behavior on just one screen, you'd have to change the entire system and add a new method. It was some of the ugliest coding I've ever seen anywhere (And I've been around.)

Instead of sensibly using CVS, they required that version control be done using Microsoft Version Control software. They had an ancient version of VMware with I think 1 or 2 licenses (Certainly less than the number of developers using it.) and most developers rarely, if ever checked their code into version control. No developer system had exactly the same source code on it at any time. We ended up hacking a demo out by going from system to system picking up various pieces. By the time we were done, there were three or four different library versions on the demo box and it would only stay up 10-15 minutes before crashing and burning. That was enough to convince the VP that we had a workable product and that he shouldn't fire the entire department (Which would have gone a LONG way toward advancing that product.) I will be amazed if that set top box EVER sees the light of day.

Lessons learned:

1) Hire programmers who know your system.

2) If the system provides developer's tools, use them.

3) If you only have two programmers on your project who actually know the system and they tell you something isn't going to work, then that something is probably not going to work.

4) Inquire about process and ask what CMM level they're at. If they look at you blankly, thank them for their time and tell them you'll call them. Then don't call them. Ever.

5) Always check out a company's bathrooms during the interview process. Seriously. You can tell a lot about a company from its bathrooms. If it's not a bathroom you'd feel comfortable taking a dump in, chances are they guy you're talking to is full of shit.

6) If a company is using C++ or Java, ask the lead programmer about Design Patterns and MVC. If he looks at you blankly, thank them for their time and tell them you'll call them. Then don't call them. Ever.

7) If a company is doing Linux development and mandates the use of any Microsoft product on a regular basis, thank them for their time and tell them you'll call them. Then don't call them. Ever.

8) Ask the lead programmer if you can see a function he's written from scratch recently. If the code has any of that hungarian notation crap or the function is longer than three or four pages, thank them for their time and tell them you'll call them. Then don't call them. Ever.

9) If you think there's something major wrong with your process, don't slip into thinking that you can fix it. Unless you're the manager, you can't and chances are it's that broken because the manager's an idiot. Especially true if you start to realize the manager's an idiot. Start sending resumes at that point. Don't let them waste any more of your time. The Evil Satellite TV company wasted nearly a year of my life, and that's a year I'll never get back.

I'm sure there are more, but those are the main ones.