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

Not surprising

[glwillia]

Recently, embedded systems has been one area where Linux really excels, and where the power of Open Source really shines. Especially things like the Isamu robot: would that have been possible with a closed-source OS like Windows CE, VxWorks, or QNX, no matter how good they may be? And, thanks in large part to things like the MOSIX project, Linux is ready to handle the real-time demands of applications such as these, where infallible reliability, several megabytes of RAM and a low-power microprocessor are the norm. I think the pundits are right, in a sense: Linux will invade the home and workplace. Not on the desktop, necessarily, but in all the systems you see and don't really think about, and that you don't interact with via keyboard and mouse. We're already starting to see this, as this article demonstrates.

Limited applicability?

[Anonymous Coward]

The Linux wristwatches and in-car computers are pretty cool, but notice the absence of applications for embedded Linux in any life-critical/medical devices.

One of the touted benefits of open source software is the ability to more widely distribute the tasks of detecting and fixing bugs.

On the flip side, though, if open source software fails critically, there is no single person or corporation to blame; no recourse or remedy.

That alone, it seems, would be enough for major corporations (with mission critical applications such as life support and the like) to avoid a serious investment in Linux or any software sans accountability).

Yes, I realize that most EULAs disclaim software publishers of any meaningful warranty anyway, but at least Microsoft's ass could be dragged into court if someone died because of a BSOD.

Mydata Hydra-Speedmounting SMT machines...

[Anonymous Coward]

I work with Mydata Electronic component Surface Mounting machines. I do belive that they even place "Linux Inside" stickers on the outside of these machines...

Just think... A linux controlled machine, making motherboards for other Linux based computers. ;)

Take that Bill Gate$...

space station

[nilstar]

Don't forget about those wonderful gadgets running up on the international space station.... the article seems to forget about that... but look at http://www.sheflug.co.uk/featuresoft.htm for articles on things such as "control the docking of the ATV".

Re:Is there any "real" use

[Jburkholder]

>Is there any "real" use

The fact that there are actual shipping products that use Linux in embedded devices indicates that there are "real" uses. Try reading the article.

>Yes, but linux is a rather "large" OS.

I would tend to disagree with this.

Distributions of Linux tend to be very large. The size of the "operating system" is a very variable thing.

Of course, the kernel itself can be built to suit and can be made quite small. If you are building an embedded device, the list of stuff (outside of the kernel) you don't have to package on your system would trim down the size considerably:

no source code
no development libraries
no development tools
no X

probably only the one application for which the device exists instead of the hundreds that included in a typical distro.

"Linux" can be made small enough to fit on a floppy disk and run completely on a ramdisk (LRP).

My example is my 386 with 4 meg and 100 MB drive running my cable modem' masq box. I'm running a kernel with everything stripped out but the bare essentials. I'm using Debian with just the barest set of packages installed. This machine is a single-purpose device with a very small OS. If I had the time or needed to, I could probably make this even smaller.

The beauty of using Linux for these purposes is that you can trim it down to just the functionality to want/need to get it to fit into your device. At least, doing so is a lot cheaper than rolling your own OS.

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.