Slashdot Mirror
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).
DaimlerChrysler unveiled its newest concept car at the North American International Auto Show in January, 2001: the Dodge Super8 Hemi "all-American sedan." The vehicle's Infotronic system is based on four Ethernet-networked PC-compatible computers -- all running on embedded Linux.
"yeah honey, I need a ride home again... 1337 h4x0rZ again... yeah..."
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:
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
>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.
Actually, I work on a team that is using Open Source (modified GPL) software for our RTOS that does run in a Hospital Point of Care device. The company that manufactures this device is a very big player in this market.
I think there were several concerns about going with Linux as our embedded OS - We were looking for something more along the lines of an RTOS, with guaranteed task handling. There were also concerns about having to GPL our software. While we don't mind giving back to the community any OS changes we make, our application code is what gives us a competitive advantage, and publishing it just doesn't make good business sense.
You've also mentioned that businesses wouldn't want to purchase Open Source software because there is no accountability. Actually, for the our project, we get the best of both worlds. OAR Corp provides support for the RTOS, and we get to look directly at their work, instead of getting a "black box" binary solution. Works very nicely. And we can make any changes we need directly. Very cool.
So, yes, companies are starting to use Open Source in places that you may never hear of, or realize.
-jerdenn
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?