Slashdot Mirror
Interest in Embedded Linux Remains Low
burnin1965 writes "According to EE Times interest in embedded linux remains low. I was surprised to see their headline considering I just purchased a Sony TV which runs linux and I assisted my brother in setting up an Actiontec DSL modem which runs linux. A few years back I had only heard of devices that ran embedded linux and now that they are starting show up everywhere interest is low? The survey did bring up three issues which should be addressed by the embedded linux community, whether those issues are misconceptions or actual problems. 1) Incompatibility with software, applications, and drivers. 2) Performance or real time capability. And 3) support."
Netcraft confirms it, it must be true!
My D-Link DSL604t is Linux based too, and so is my PDA..
--
I would have said that 17% of designers using embedded Linux is quite respectable. I wonder what their target penetration was.
If I'm going to make a million of something, I'm willing to spend a lot of money on engineering to save fifty cents per unit. I'm willing to spend the extra effort required to use Linux.
On the other hand, if I'm making ten units of something, engineering time is my largest expense. In that case, I don't particularly care about license fees or the cost of the tools, I just want to get the job done as fast as possible.
So, consumer goods will use Linux but most developers don't design those. Most developers work on projects that won't be produced in large numbers. Therefore most developers will continue not to use Linux.
Only 17 percent of embedded systems designers are currently using embedded Linux, and 66 percent say they are either not interested in using it or do not expect to be using it anytime soon
So, reading this backwards, a third of embedded systems developers are interested in embedded Linux and/or expect to be using it soon.
Compared with where the market was five years ago this is huge. Of the other two thirds, a large percentage goes to TRON and probably VxWorks. And if you want vendor-provided qualified platforms and support, you can get that from the same folks who make VxWorks.
Surely a change in survey results from a year ago is something to be curious about but there's no indication it's a trend.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I developed an embedded device using NetBSD. I would love to use Linux, but the agressive stance of the GPL license (Linksys!!) keeps me away. I know many others that share the same view.
Linux won't take over the embedded world, mainly becuase embedded is a commercial market. Who wants to invest money in developing a product, only to have the open source community go after you? And you get bashed for trying to earn a living.
Before you flame me, I did make a good portion of the code used in my embedded device available to the BSD community. I won, they won. Nobody twisted my arm.
I'm posting AC, STOP KARMA WHORING!!!
TDT
Nothing is going to change the fact it is a Sony.
Yes; using ".." and "." is nothing Linux-specific at all. It has been the UNIX way of listing "Parent directory" and "Current directory" for ages (and probably in other OSes as well), so using their presence as an indication of Linux usage is quite worthless.
Perhaps this is just a wake up call to companies who support embedded Linux to perhaps spend more on advertising and marketing (i.e. "hello world, we support Linux embedded because we made a pile of decent kernel patches so we can be trusted.")
Compatibility testing, and wedging in those RTOS kernel patches and supporting those where appropriate can't be a bad thing either.
READY.
PRINT ""+-0
My feeling is the latter. My Netgear ADSL modem / firewall uses embedded Linux. If not for a "debug mode" hidden in the advanced settings which enables you to SSH into a busybox shell, I wouldn't know nor care. The thing just works and it works very well. I expect millions of people are running Linux in their homes in their modems, TVs, audio / DVD players, washing machines or elsewhere and simply don't know it.
Issue 1 is not a big problem. The programming model is well-understood, so at the application level there really isn't a lack. However, there is little support for specific stuff that hardware vendors may want to do (like say a CDMA RIL) and the implementation of those features is pretty difficult.
The second issue is a real concern. User experience is significantly degraded when the interrupt latency is longer than the expected reaction time. There are ways to reduce the interrupt latency in Linux, but the side effects are undefined.
Support is only an issue because it is so expensive. Likewise, there are only a few top-tier Linux vendors who can offer good support. Montavista, for example, is one of the premier (if not the premier) embedded Linux vendors, but they can't support everyone who wants to build a Linux-based embedded solution. They pick and choose their support contracts, and anyone not selected needs to find someone else with the relevant support capabilities.
Are cell phone counted? Say this to motorola :)
My WLAN AP / router runs Linux. My nokia 770 internet tablet runs Linux. Many many media player type devices run Linux.
'Once scientists, even the dim-witted social scientists, get muzzled, the Western Civilization is finished.' - oldhack
A lot of DVD players probably are Linux based, though.
Only 17 percent of embedded systems designers are currently using embedded Linux, and 66 percent say they are either not interested in using it or do not expect to be using it anytime soon
I don't care what operating system the designers use.
Its whether the products they produce run on Linux thats important.
liqbase
Which question were people answering? Are you intending to use an "embedded linux" or just "linux" in a small standalone device? We use a "standard" linux in several standalone devices. We have no need for, nor do we want to use a "specialist" distribution because we do want to be locked in. It is no coincidence that one of the more fertile areas of cpu support development in the kernel, at the moment, is for ARM devices.
Most embedded applications dont even need an OS.. thats overkill for them and would only serve to raise the end cost. You dont need linux in your Microwave for example.
---- Booth was a patriot ----
Did Micro$oft fund the study? The position taken in the article seems to be wishful thinking given the penetration that is already in place.
1) Incompatibility with software, applications, and drivers.
OK this is embedded on a "device". Chances are very good the device is packaged and marketed for its outstanding functionality. That functionality may not include being able to run Excel.
2) Performance or real time capability.
OK so one of my Linux boxes uptime is like 2 years. It's running on a Pentium 2. It's fast. Windows mini ME edition wouldn't be fast on it.
3) Support.
You embed it, be prepared to support it.
Is embedded systems a worth dominion for open source projects?
Unlike the desktop space, the embedded systems space has a multitude of vendors, and a huge variety of configurations to choose from.
There is hardly any motivation to build upon embedded linux.
...without knowing it. as i've pointed out before you can download sources for Sony devices from here: http://www.sony.net/Products/Linux/Download/search .html
anyone got anything on the list? [hint: try under the 'game' section]
One issue that prevents linux being used in automotive systems is the ability of a vendor to accept liability (and be in a position to defend it meaningfully).
Auto companies get sued all the time (rightly and wrongly), as to their major suppliers (Delco, Denso, Bosch etc.). If a supplier's part is defective, a class action against the supplier may result. If the supplier is big like Delco they'll be in a position to defend against that action, and have enough money and insurance to survive if they lose the action.
But linux comes largely from little guys like Montevista. Even if they do accept liability, they're still too small to survive a huge automotive-defect class action. So GM or Toyota or BMW would be left holding the bill. The major automotive electronics suppliers will accept liability, and are big enough to be credible partners in a litigative society. Microsoft sells (very limited) automotive electronics products, and are again credible (from a business perspective).
IBM could sell automotive linux, as could HP, but they don't (or rather they want to supply technology to automotive electronics partners).
Now why don't guys like Denso install linux - at least partially because they all want to be little microsofts, to "own the car", and open systems and generic technogies prevent that - they think they benefit from wacky proprietary OSes and weird undocumented software stacks.
Well whoose fault is that? Not the Linux people, maybe if they wrote their own linux driver it would work? Its the product developer's job to make sure somthing is compatible.
Admiral Trigger Happy
could never benefit from an OS?w ave.html this one surely could.
http://www.beyondconnectedhome.com/products/micro
every day http://en.wikipedia.org/wiki/Special:Random
This, sadly, is very much an pointy-headed-boss driven decision. From the perspective of the HW/SW teams its just plain stupid. The problems are probably pretty representative why those 66% aren't looking into Linux.
Its gross overkill. Linux architecture is for general-purpose multi-user information processing loads. It does a whole bunch of things that are simply ballast for an O.S. that is there simply to control some special-purpose hardware and run a simple on-screen-display. Bigger micro, larger flash footprint, more on-chip RAM gobbled. This really really hurts in a genuinely cost-competitive marketplace. If you're building an Net appliance type of thing of course Linux is almost a turn-key solution. For embedded control... its the wrong kind of OS.
Licensing is a pain if you have non-trivial know-how you don't what to gift your competitors realised in your Firmware. You end up doing really vile hacks like doing stuff in user space via 'dummy drivers'. Debugging becomes fun fun fun....
The abstract machine doesn't fit. In the embedded control space sometimes the cleanest solution really is to do direct HW access. However, the hard kernel/userland divide of Unix O.S. makes doing this in a systematic, safe, way rather clumsy. You end up writing around a bazillion special-purpose HW-dependent ioctl's where what you really wanted was some selective access to the I/O bus. Then you need a HW workaround with hard real-time requirements and the 'fun' really starts.
In short Linux is a fine information processing
well yeah, i know that. i thought that UNIX wasn't really that high on the embedded list of OS's though....not nearly as much as linux. i was going on one of the characteristics that linux _would_ have and _windows_ wouldn't
hardly what i would call worthless
Please mod parent as "flamebait".
Nobody is _that_ stupid, so it must be flamebait.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Are you nuts? .. is parent directory
./exec_file knows
. is current directory
in Windows too.
And . is hardly worthless, as anyone who has had to type
Don't know if any /.ers are familiar with the mixing console industry, but Midas are doing some pretty neat things with Embedded Linux on their new digital console (XL8).
Could not open
Well, TFA tells us haow many are using Linux, 17%, and are thinking about it, etc. But how can we make any conclusions form this when it isn't even hinted at what the other 83% are using? Some version of Windows? QNX? DOS? Is Linux at 17% the largest or much smaller than the others? Maybe the EETimes readers have the context, but I don't.
It's not just a case of features, but of mindset. A lot of embedded programmers prefer writing their entire software stack with direct access to the metal. To do otherwise takes a big adjustment in mindset, and a lot of companies simply don't have the time for it and therefore Linux.
The article talks about the number of designers who are working on Embedded Linux projects. It says nothing at all about Embedded Linux's market penetration.
If, for example, you have 1000 projects using an embedded OS of some kind. Let's say 900 of these are going to be either small-run, specialised devices, or flops. The remaining 100 are consumer items, mass-produced and sold around the world. If Linux's 17% happens to account for a large proportion of the top 100 projects, their market penetration is huge. If it's 17% accounts only for small-run projects, then it's not doing that great.
A better heuristic, IMO, would be how many units are being produced with embedded Linux, rather than how many designers are using Linux.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
Just FWIW, I recently bought a Sony TV. It included a copy of the GPL. You can get the code for all the GPLed software the thing runs.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Auto companies get sued all the time (rightly and wrongly), as to their major suppliers (Delco, Denso, Bosch etc.). If a supplier's part is defective, a class action against the supplier may result. If the supplier is big like Delco they'll be in a position to defend against that action, and have enough money and insurance to survive if they lose the action.
But linux comes largely from little guys like Montevista. Even if they do accept liability, they're still too small to survive a huge automotive-defect class action. So GM or Toyota or BMW would be left holding the bill. The major automotive electronics suppliers will accept liability, and are big enough to be credible partners in a litigative society. Microsoft sells (very limited) automotive electronics products, and are again credible (from a business perspective).
Firstly, it's Montavista. Note the 'a' in the middle.
Secondly, why would they accept liability - they are just providing a development kit and support. The hardware design and manufacture and the programming of the system is down to the customer - if there is a defect in these it's got nothing to do with Montavista. If you run into a bug in the kernel, well that is what your QA department is for. Auto suppliers are liable for errors in parts they manufacture, not for how you use them.
>Incompatibility with software, applications, and drivers
What software he is talking about ? Almost all software that is available for desktop Linux can run on embedded Linux, which is a few orders of magnitude more software than is available for other embedded operating systems. Regarding drivers - almost all HW vendors that work with embedded products supply linux drivers.
>Performance or real time capability
95% of embedded applications do not need hard real time capability. And average performance is once again typically higher than that of other embedded operating systems.
> Support
I'm really tired of hearing that one. Everybody and their mother is providing Linux support now. Take Windriver, for instance.
Trying to create a trend or perception where there is none. Witness all those smarmy "the suit is back" articles.
In addition to accepting paid and free propaganda, trying to create public hysteria to influence political outcomes, the MSM survives on renting reader's eyeballs to advertisers. Whatever it takes to do that, they will do. Slashdot itself has fallen into that same cycle, with regular articles about "political" subjects sure to get 800 replies (and corresponding ad impressions) but with no valid technical content.
New SuperSig:
Make the requirements to vote the same as to own a gun.
Simply go to the polling place, fill out a Form 4473, show your ID, and the poll worker will check with the FBI database to make sure that you're not prohibited from voting. If everything is working correctly, you will be allowed to vote in a few minutes.
If the GCA/Brady system doesn't violate the rights of gun owners, then what possible objection could there be to implementing the same system for voting?
Robert Racansky
So, how long HAS it been since you last used a DOS prompt? Practically every OS uses '.' and '..'. You have to get extremely obscure to find an OS that doesn't. Even the developer CLI for old classic Mac OS used that convention. Even most mainframe OSes use that convention. I'd actually like to use this opportunity to put forth the challenge to all geeks out there to start naming OSes that DON'T use that convention.
The reason most players have '.' and '..' is probably because they're using DOS, not Linux, since PC-DOS is free, easy to program for, and offers absolutely no barrier between programs and the hardware.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
QNX on the other hand, will practically send an engineer on site to hold your hand while you get your BSP running. Support is cheap and the runtime licenses are down in the noise threshold.
Sure, QNX has a few issues. So does VxWorks. But Linux is a real lose, and I've tried.
Frankly, if I was starting from scratch and rolling my own BSP, I'd choose NetBSD. Embedded friendly license, code purity, and it probably already has your processor arch.
Well, . is worthless in Windows and MS-DOS (and OS/2?) as their shells are clever enough to look in the current directory for executables.
Always slightly annoys me when I use *nix stuff, as it never seems to work (at least by default) on them.
10 PRINT "LOOK AROUND YOU ";
20 GOTO 10
You forgot toasters!
But they are mostly behind schedule
"A new survey released at the Embedded Systems conference reveals that more than half of all current embedded design projects are running behind schedule."
"The survey -- dubbed the "2006 State of Embedded Market Survey" -- indicated that some 55 percent of current embedded design projects are late or have been cancelled."
How accurate can any survey be when over half the projects are late and/or are being canceled? Bad mojo in the field of EL and not a good time to take a survey on Embedded Linux me thinks. As was stated in the blurb, EL is everywhere....
The numbers aren't that far off from 2005, but what about the years before that? Project running behind schedule are a bit less from 2005, but cancelations are also a bit up. Dunno, maybe I'm just looking for something to weaken the argument that EL is losing ground. I've always seen it as the grass-roots to keep pushing what I see as the future of operating systems, Linux....
"All great things are simple & expressed in a single word: freedom, justice, honor, duty, mercy, hope." --Churchill
I've know of two:
VMS
RiscOS
return 0; }
http://www.paulgraham.com/submarine.html
>the only reason i'm going on this is the use of ".." to go back a directory >and the inclusion of "." which has no use - just like the linux explorer :) i
I think you must be confused. I saw Os/2 using that terminology too.
So it must be running embedded OS/2. Casue the OS/2 explorer uses that terminology.
I'm sure that linux and windows could probably also use that format...
doh
found that 34 percent of respondents were not interested in using Linux.
66% are using or are somewhat interested?
So that's a good thing.
He who knows best knows how little he knows. - Thomas Jefferson
This one goes high:
<URL:http://bink.nu/Article6663.bink>
Perhaps this is just a wake up call to companies who support embedded Linux to perhaps spend more on advertising and marketing (i.e. "hello world, we support Linux embedded because we made a pile of decent kernel patches so we can be trusted.")
That's specious and spurious reasoning at it's best.
Many (and I use that term loosely) companies use Linux, but why would you want to trust a company? How would using Linux make them trustworthy?
Besides, if Linux was adequate (which it is), it wouldn't need advertising.
Are posts such as yours the song of linux fanboyism? I'm really new here.
I thought the same thing, but they talked to developers not end users. Surely linux has not become so simple that even the guy building the product doesn't know he's using it!
The article talks only about the number of programmers using embedded Linux. It fails to mention the percentage of shipped devices that use embedded Linux. It could be that the embedded world is more specialized, requiring more specialized function from an OS. The devices that can use a more general purpose OS (DVRs, webcams, ADSL routers, etc.) don't need many programmers, but ship a lot of units.
s/clever/broken and insecure/
you are an idiot. why does every fucker on here not actually READ WHAT I PUT. I SAID WINDOWS USES IT MORON.christ, how many more do i have to say this to.
From what I've heard, the PS3 will use the Linux kernel.
OK, I am a firm beleiver in embedded Linux, extreme SFF computers and/or "OS-on-a-chip". After review of the Article and posting it appears most ppl think of embedded devices as strictly "consumer" type products. Rightful so as the article did not address "who" (read end-user) target the embed was targeted for. Yet there are hundreds products on the market for Industrial control applications and thousands of consumer products. If the the designers surveyed where from the industrial controls sector then yes Linux embedded devices and their use is low. If from a consumer product stand point then the article is flawed. Multi embedded Linux systems in an automated industrial enviroment would be much better, far more reliable, much more expandable and more easier to manage then the "old" tech in use today, namely the PLC. Look at it. A famous named PLC offers 16k-32k of program storage, communicates via a modified 485 or Ethernet with a $1200.00 piece of hardware. Takes a $1000.00+ software bundle to program it (just One class). OH I forgot... Starting price NEW for an expandable controller is as much as its ID number. I have seen PLC rack add $15000.00 to a project (single piece of equipment) and that is not a very big rack at all. Don't forget the software - PLC, Scanner, HMI, Ethernet Interface and wares for a computer to talk to it.(another $5g) For that kind of cash you could put in embeds to control the whole process and be redunant. Bottom line . . . That is really what it is about. IMO PLCs are relics from the past that need to be trashed and embedded PCs is the now and future
you are an idiot. reread my post. I SAID WINDOWS USES IT MORON.jesus
also, you mention how people would use dos because it is free. HELLO, LINUX IS FREE RETARD.also, when you use an explorer in windows, there is no ".." and "." in the explorer.dos does not have a graphical explorer.
linux does and has this attribute. i bet you are just some idiot windows fanboy who's never seen a bash shell
If you have a single application device, it really does not need a comprehensive, separate "OS". If and when you need process management and memory management and sharing of I/O resources between modules/processes, you need SOME libraries/headers to do that. If you want to have layers of abstraction (say, high level I/O or media codecs) to help in development, you need also some libraries for that.
But up to a point you are free to use per application designed common libraries and run-time systems, you don't need to have a general purpose interface/protocol between "applications" and the "operating system". This is what many light-weight embedded toolkits are: just run-time systems and shared libraries with shared data structures. They are far simpler and smaller than any version of Linux, and more tailored to typical needs here.
But if you want to have a user extendable system and an ecosystem of independent code modules and libraries all running smoothly on a variety of hw versions, with standard programming interfaces, then Linux probably is a reasonable choice. (Though I would go with Plan 9 or Inferno.) This kind of system needs more expensive hw and is more complex, but it is also kind of easier to build, because it is more "common" and more "standard". With the cost of hw falling, this type of system is going to be more and more the most cost effective way to engineer the life cycle of several product generations, when design time and itellectual property costs are bigger than costs of general purpose processors, DSPs and memory.
Anssi Porttikivi / app@iki.fi
doh indeed. christ how many idiots do i have to explain this to. i said WINDOWS USES IT. GO REREAD WHAT I SAID. i was talkiing about the GRAPHICAL LOOK AND FEEL whicj resembles linux highly, and windows not at all
This is interesting stuff, as Linux, although behind Windows embedded in certain device types like smartphonse, is constantly gaining market share, and clearly leads in devices like firewall, router and wifi appliances.
-FreakGeek
If you think imaginary property and real property are the same, when does your house become public domain?
"Who wants to invest money in developing a product, only to have the open source community go after you? And you get bashed for trying to earn a living."
3 562391
I know that Tivo and Cisco (Linksys) hate the GPL. I mean, if you look here http://www.tivo.com/linux/linux.asp you can see that Tivo thinks the way to stay in business is to hold the source code close. And of course, using open source, GPL'd software is a way to drive Linksys out of business http://www.wi-fiplanet.com/tutorials/article.php/
If your business model depends on closed source, then you are increasingly a dinosaur. It's like the employee who thinks he has job security by keeping what he does a "secret" from his boss. It only works for a little while.
There are already a surprising large amount of drivers around that actually works well on embedded devices as well, as long as you behave nicely and issues ordinary shutdowns. And if there isn't a device driver around - it's not that hard to write one!
Another problem is that the size of the kernel and support applications sometimes are a little large for an embedded solution.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
you'll find it clever when you're administrating a server and you are trying to look inside someone's home directory, and when you type 'ls' instead of listing the directory contents it actually runs a custom script in their directory which does something nasty with full privelages.
Although I remember coming across a distro where . was in the path by default for all users except root. I still think it's better off that . is not in the path at all.
being vague is almost as cool as doing that other thing...
A year or so ago I sat in on a marketing seminiar by a purveyor of their own embedded linux (This one looked like lots of it had been lifted from Snapgear linux)
It had been rumored that the company had financial backing from a LARGE chip manufacturer. It was very professional and it looked like they had spent a lot of money on the marketing material. It didn't look like a sandle wearing kernel hacker had put it together and I was quite impressed with the demo. But marketing isn't just about fancy demos and expensive looking pens with laser pointers in them.
At the end an attendee stood up and asked "How is licensing your linux based software stack going to be cost effective for us?" No answer was given at the meeting.
My boss made a phone call to them later because the company was going through a software crisis (I was leaving). They wouldn't speak to him unless he paid $100,000US up front. And they still wanted a large per unit license fee after that. He certainly couldn't see any "value proposition" and considering this news, I imagine not many people have since.
I work for a company that uses embedded linux. We also have a division that uses embedded windows. I can tell you for sure that the linux product is much easier to configure, is much more intuitive, and work a whole lot better for what the product is designed to do.
I am d3matt
Great point. Embedded developers need to ask what they want from an OS. Threading? There are several lighweight OS independant packages out there. pt threads is my favorite. Maybe you just need a round robin processing loop. Device driver frameworks for chip peripherals? Posix-like drivers are also easily developed without an OS. If you get to the point where you must run multiple processes and you need interprocess communication or full blown networking and have a larger device (ARM, PPC), then yes reach for Linux or an RTOS.
A related decision is whether to use C or C++. If you are writing programs of a few 1000 lines there is no point in using C++. Your code's organizational requirements simply don't demand it. Many embedded C++ compilers are very buggy compared to their C counter parts. Hopefully your processor is supported by GCC. It is a lot easier to get stdio working (putc, getc) on a new UART than iostreams (streambuf). Try it sometime. STL doesn't make much sense when you are trying to optimize for space and speed.
an ill wind that blows no good
WANG VS (now probably Getronics VS)
I can only speak for the industry I work in but we are rapidly porting all our applications to embedded Linux platforms. Our systems run an RTOS but with the abundance of Linux savy programmers in the world it makes very good sense to use a widely deployed system.
TT
Well I just recently purchased a KuroBox and let me tell you there seem to be no design what-so-ever! I still purchased it and am trying to have some fun learning though...
i was going on one of the characteristics that linux _would_ have and _windows_ wouldn't
What could you be referring to?
i know windows _can_ use the same format (ie ".." and "." both work on it) but it's obviously not that due to the inclusion of the superflous "."
Now, for the finishing blow:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
H:\>dir
Volume in drive H is Storage
Volume Serial Number is 38F8-EFBC
Directory of H:\
03/31/2006 06:58 PM
03/31/2006 06:58 PM
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
Related to that principle, to avoid licensing fees for WinCE, you'll be willing to write your own drivers for a large-scale product, especially since it's one you designed and manufactured yourself. Microsoft doesn't write drivers for Sony televisions, after all.
I just tried that with Windows XPs cmd.exe, and the dir command takes priority over a dir.bat or a dir.exe, unless you specifically use the file exentsion or a path.
Of course the way Unix works is a bit different (like the way commands like ls are programmes in their own right rather than part of the interpreter), but you could surely at least set it so that the current directory has the least priority out of the directories checked.
10 PRINT "LOOK AROUND YOU ";
20 GOTO 10
But the "it's nothing to do with us" part is the point. Ford /want/ someone who will accept legal responsibility for what they're supplying, even if (as with linux) the great majority of components come from elsewhere, and the supplier has only moderate knowledge and skill of them. Little outfits like Montavista aren't, quite reasonably, in a position to do so. But when you ship a car, /someone/ has to, and if the supplier can't or won't, Ford has to. Ford doesn't like that, and Ford's insurer really doesn't like that. So Ford buy from QNX or WindRiver or MS or Moto or Delco, who can and who do accept liability.
If you run into a bug in the kernel, well that is what your QA department is for.
If Ford buy a kernel from Montavista, they don't care where it came from, and they expect Montavista to have QAed their product. The fact that Montavista didn't write it isn't Ford's problem. Automotive suppliers like Delco aggregate components from sub-suppliers too, but they accept liability (in the first instance) if their aggregate goes wrong: they can't turn around and say to Ford "oh, we didn't make these capacitors, talk to our supplier CapCo". Delco might, at some later point, turn around and sue CapCo, but Ford has no relationship with CapCo, no responsibity for QAing CapCo's capacitors, and no desire to go chasing CapCo when things go wrong.
Little embedded/RT linux companies like Montavista just can't accept liability - they'd be mad to do so. That's the big legal downside of open source and free software - if you didn't pay for it, you've no-one to blame when it breaks. So you see better linux adoption in markets where liability is less of an issue (e.g netgear is willing to take the risk of the kernel they're using having a bug, because the potential exposure is only moderate).
Linuxdevices, a magazine/site devoted to the use of Linux in embedded systems, responds to the EE Times in this article:l
http://www.linuxdevices.com/news/NS4718792784.htm
All is not as it seems.
I have done embedded design for more than 20 years. I have been subjected to many goofy surveys than were written by marketing suits who were clueless about how to ask proper questions. The typical survey says "Will you be doing an embedded design in the next 6 months? Y/N" and then it gives some kernels to choose from. The category of "hand rolled" is always the winner (~50%). This is because most embedded designs are quite small (8 and 16 bit) and buying a canned kernel is too much bother. Linux is not an option on these little processors (gross overkill and no MMU protection anyway).
The survey should ask "Will you be doing a 32 bit embedded design and if so, what will you use as a kernel?" If the design does not require TCP/IP networking, I still would seriously consider hand rolled as an option. When you make the kernel yourself you are not dependant on the support of the kernel provider.
I've never done an embedded Linux design, but I sure would like to. My only concern would be the complexity of dealing with the GPL (I ain't no lawyer). I'm accustom to hiding the source to prevent knock-off designs. In government research designs I willingly release the full design, but in commercial design it sets off alarm bells in my mind. I'm not sure what the reaction of a customer/employer would be if I told them I was going to release their code to the internet. I'll have to figure that part out.
also, you mention how people would use dos because it is free. HELLO, LINUX IS FREE RETARD.also, when you use an explorer in windows, there is no ".." and "." in the explorer.dos does not have a graphical explorer.
linux does and has this attribute. i bet you are just some idiot windows fanboy who's never seen a bash shell
Your ignorance is actually stunning. The Windows explorer doesn't have current directory and previous directory shortcuts listed because they're superfluous in a GUI interface. They're only useful in a command line context and would be screen clutter otherwise.
I'm well aware of the fact that Linux is free. I'm also well aware of the fact that I never said that it wasn't, merely that being free was one of the virtues of DOS as well. DOS offers no memory protection, and there is thus no need to interface with a kernel to get access to the hardware. This is the primary virtue of using DOS in embedded systems. The other main virtue is the fact that there's no multitasking, so your program has complete control of the hardware with the OS being little more than a good API to handle some common low-level tasks. Many systems do not need the full feature set of Linux.
Also, based on your ignorance of DOS and lack of ability to post in a civil fashion, I can safely say that I've been programming for UNIX longer than you've been using computers. Dropping to the command line was a frequent thing for users to do in Windows 95 & 98, so if you've never done that, then don't patronize me, kid.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
as an embedded developer for a Fortune 100 company, is that we can't move to Linux _fast enough_. My group is writing firmware to run on a custom 802.11 access point, currently using vxWorks, but we've been trying to move to Linux for well over a year now for a number of reasons:
- Many of our developers have Linux experience, especially in the kernel
- There is support for every networking protocol under the sun
- There is a large base of software already out there
- Licensing fees (vxWorks costs per processor
Most of the engineers on my team would _love_ to be working on Linux.
As a developer who has used Linux in several different embedded applications, I don't really see GPL as a problem.
The main intellectual property resides in the controller applications and since I do not use any GPL code in them I don't have to make them public.
The small changes I've made to device drives and utilities I have shared with the respective developers and thus it is a win-win situation where we can benefit from FOSS and FOSS gets back some contributions.
You poor poor man. You posted early, with an on-topic statement which, while being less than inscrutable, was likely correct although for the wrong reasons. I myself modded you Interesting - I too mused on the validity of whether '.' and '..' were strictly the criteria upon which the embedded OS might be determined - but I took your general point. My Alba DVD-65 definitely has a crapulent-but-functional 'Linux feeling' about it, in fact a higher-level zealot is welcome to inform me of what system is embedded in said DVD player.
I'm sorry that by posting in your support, I cost you the mod-point I allocated you, but I just think it's ridiculous that you are now locked in a scrum with dozens of *NIX/Linux fans screaming at you. And funny. Very very funny.
I had forgotten about VMS, but I never knew RiscOS didn't. What did it use instead?
Status VOS uses 'this "OS Rosetta Stone" when trying to remember the one for VOS (since I unfortunately worked with it at my first job).
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
My Experience (and my current job) says that the post is wrong.
We're developing an embedded medical device with millisecond lantency needs.
We get to use a 192MHz arm chip which is more then enough to use a linux kernel and drive our application. It's not hard real-time like a rocket control but it's more then enough for us.
Kernel and framework support for the popular embedded boards and chips (arm) is growing extremely fast, so much so that its better (for us) to use the latest distributed kernel then attempt to get Montavista to support us. Performance is more then enough so why shouldn't people use linux in the embedded devices. It's makes a hell of a lot more sense then trying to hack around a properitary kernel and toolchain.
The big win for linux is the similarity between using desktop linux and the embedded device. Also all of the services (ftp, NFS, ethernet, ping) which are available on desktop linux are also available on embedded with just one recompile. Setting up the toolchain was the hardest thing to do (and gdb still doesn't work 100%) but after that, everything WORKs exactly as before....
And don't even get me started on Qte
Cheers,
Ben
PS. For the hardware complainers who don't know what ioperm is for, try looking it up.
You get direct access to registers.
But it makes lots of sense in network appliances (NATs, firewalls, routers, print servers, etc) and certain consumer electronics. The latter includes things with disk storage for DVR functionality and network connectivity for services or content/conditional access. In many cases the choice of Linux in this segment is determined by the chip vendor; they may only offer reference software and tools on Linux. This is true for at least a couple of dominant vendors today.
EET should look at Linux penetration in market segments where it makes sense. Not just numbers, but also why. E.g., "everyone already knew it here", "cheapest", "chip vendor mandated", "allows us to use a gcc tooolchain", etc. I'd also like to see the numbers as a percentage of all shipped units as well as a percentage of market share (in US$).
Embedded Linux, even as ucLinux with uclibc etc is still fat for an embedded OS. Others like ecos, freertos etc are a much better fit. And so are the nice commercial offerings like qnx palmos and vxworks. You just have to add expensive ram and flash to make it boot linux in any form, and it cant be a 16-bitter. The only reason you see Linux being used is for hardware support and its nice networking, which is almost matched now by ecos' offerings.
I think for most small devices Linux is just too big. However it works better on routers and PVRs where space is not an issue. I will not buy a Linux watch or cellphone anytime soon, unless the battery can support it.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
I have concerns over the difficulty with GPL and embedded Linux. Linksys is an example where they failed to understand this issue and got in trouble but were able to correct it in the end. I purchased a version of what I thought was a Linux router from Linksys, only to find they had replaced Linux with something else to make a more un-reliable product (my old 486 Linux-based router would work for a year or more without issue, this embedded non-Linux Linksys router locks up every week or so). Most of the issues with GPL seem to actually be perceptual and not real, but with drivers it is a problem. Maybe what is needed is some type of exception for linked-in drivers only on embedded systems (there is a GPL exception for loadable drivers).
These are problems at the GPL-proprietary problem space boundary. Pure GPL advocates hate ALL proprietary, closed software. However, ALL need to recognize the reality of commercial products. If I develop a device and an interface to it, I may want to protect that interface or system internals for a while so my competitors don't steal my design (time to market is very crucial).
Not everything can or should be open (yes, some will really flame this statement, but it is a fact -- try opening up the control code for a nuclear bomb or a missile guidance program). There may be limits on something due to a patent, due to a competitive advantage, due to sensitivity (think classified data collection or processing), or export restrictions (bomb control software).
For market studies, what we really need are some breakdowns:
It would be nice to see the above also broken down by product volume and by product cost:
I personally have dabbled in developing on Embedded Linux PDA's and enjoyed it. But it seems as the hardware vendors out there (at least based on what's available in the U.S.) aren't leaning toward Embedded Linux as the platform of choice. A shame because it has so many available packages to make the hardware shine. Embedded Linux PDA's can function as anything you can imagine --- Samba client/server, FTP client/server, VNC client/server, SSH client/server, DB client/server, HTTP client/server, telnet client/server, etc. The Windows Mobile PDA's I have played with don't have nearly that toolset available that I could tell. At least for free :-)
That's because the "dir" *command* isn't really a command file - it's an embedded command (or function) of the cmd.exe or command.com
/s/b/p
go to the root directory of your windows installation.
do a
dir dir.*
and see for yourself.
Who is general failure, and why is he reading my hard drive?
Of course I realise that. Indeed, I said it myself:
Of course the way Unix works is a bit different (like the way commands like ls are programmes in their own right rather than part of the interpreter)...
10 PRINT "LOOK AROUND YOU ";
20 GOTO 10
You expect it to work as well or better than your Play Station. If it came from Microsoft, you probably would not expect the same. There are levels of hell in the non free world.
Friends don't help friends install M$ junk.
Most people dont give a rats ass which OS runs on their embedded hardware. Only linux fan-bots care if the latest gadget has their favorite OS on it. Most of the rest of us, just want the damn thing to work without hassles.
My employer builds chip testers that run on Linux.
It could be said that those testers test the chips that run imbedded Linux.
Kinda makes the circle complete, huh!
Those testers were given an award as the Best In Test 2005.
So it could be said that Linux is the BEST test OS!!??
Dying? Feh!
17% means one in six embedded systems designers is using Linux.
That's despite the fact that, with fairly recent additions to the kernel, Linux has only really been ready for the embedded market for the last few years.
Plus, as an Open Source product, Linux will continue to improve in its abilities, and it will continue to have a price advantage.
I'd say that the 17% usage statistic, at this early point in its development, is a major success story for Linux. It would appear that Linux's future in the embedded market is quite secure.
"Toaster" is a racist term.
We call ourselves "Cylons".
Are you alive?
The lie evaporates when you invert the numbers and statements as you did. It's a tremendous success that more than half of SMB are interested in Linux. Compare Microsoft's huge marketing budget to that of all the free software advertising combined. It's like comparing your house to Texas. In this case, the sample was skewed too:
the survey, conducted through email solicitation from subscribers to EE Times, Embedded Systems Design and Embedded Systems Design Europe, as well as registrants for the Embedded Systems Conference, are based on 1,217 respondents
Those running Linux probably filtered the "solicitation" out as spam. Those attending the conference may not be the best cross section of the industry.
The "no interest" lie not working and it backfires. People don't trust Microsoft, especially those who know better and are in a position to make decisions. Embedded developers are in that group. Many might not have time to play around with something new, but they have indeed heard about and are very interested in a high quality, zero cost operating system. In the end, the lies just taints the liar.
Friends don't help friends install M$ junk.
Embedded Linux is show up everywhere that I've encountered. Linksys routers, cell phones, PDAs. I was even surprised to find it in Quantum DLT Tape Libraries, controlling the robotic arm, etc.
--
Luck is just skill you didn't know you had.
That's not funny. I was looking at appliances the other day and saw a computerized toaster with a flourescent display.
Not a toaster oven, where a microprocessor controller makes sense, but a typical sliced-bread toaster with four slots.
WTF? How does the failure rate of that toaster compare to a conventional toaster with a mechanical thermostat or timer?
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
17% of embedded market is absolutely amazing imho. Unlike PCs, there are many choices for an embedded operating system. Most commercial embedded OS vendors could not even dream about reaching such high audience. I've read somewhere (and I agree) that if you need a filesystem and/or a TCP/IP stack you should consider Linux for an embedded system.Maybe I would expand this to include a USB host. If you don't need TCP/IP stack/Filesystem/USBhost then my personal favorite is Labrosse's microC/OS-II (amazing collection of CPUs that will run this, starting with 4K-ROM 8-bit processors to PowerPC type processors, not many OSes can claim such diversity).
Look, if I'm writing a hard real-time DSP application, I'm going to go with something which runs on an ARM7, I'll write my code in C with an "operating system" that consists of a polling loop to keep the chip asleep as much as possible. If I need multiple processes with process isolation, I'll look at NetBSD, or, perhaps, at Windows CE. If I'm looking for a network appliance which will run on a Linux friendly CPU in a standard configuration with next to no ASICs, then, I'll look at Linux alongside CE or NetBSD.
Considering the amount of quality that is in a conventional modern name-brand toaster (since most are made in China) and how frequently they fail, the answer may surprise you. I've been in search of a good quality simple toaster that sells for under $100 for quite some time. Haven't found any yet - and the quality seems to be getting worse all the time. Even the expensive cuisinart stuff is crappy quality made in China. Nothing against China, but most products that companies have made there to save costs end up sucking.
Procrastination -- because good things come to those who wait.
I'd guess the numbers don't reflect reality -- developer reality. They probably reflect economic reality (where numbers are easier to track). There are three companies I know of, just off the top of my head, that use embedded Linux in their products (and have worked at two of them, myself). If you asked their PR department, "Do you use Linux in your products?" you'd probably either get a blank stare or a dismissive "No. Our products work with Windows." i.e. Only Engineering has a clue.
In other news, Trolltech has just released the Qtopia platform for mobile embedded Linux I don't think the guys at TrollTech haven't done a market study before investing in the development of this new platform.
You know what else has a . in it? withnail420@gmail.com
Also, what kind of "graphical look and feel" does Linux have? I think you need to go eat a bag of hell. Why don't you go to fark.com? It's full of idiots like you. I think the discussion there is more your level.
If 17% use Linux that means 83% don't. How is that 33% of the market? Of course it would be nice if it was 1/3 of the market but that hasn't happened yet.
Dang it. I failed to Preview AGAIN (and didn't notice that the first post to correct this didn't go through). What I meant was:
Status VOS uses < for the parent directory as does Multics apparently. I found this "OS Rosetta Stone" when trying to remember the one for VOS (since I unfortunately worked with it at my first job).
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
However, what's NOT being reported by the EE Times is what's significant here.
If you look at the linuxdevices.com survery, the number of systems using linux is about 20-25% IIRC. Say it's 20%. This is in line with the survey.
But the REAL interesting thing here is that Linux has come from virtually nowhere in the past 5 years, to now actually become one of THE dominant Embedded OS's in the marketplace, if not the single most dominant one.
Contrast this to VxWorks. About 5-6 years ago, WindRiver was crowing that they had the dominant OS, with about a 33% marketshare. According to the linuxdevices.com survery, that has now dropped to about 12% IIRC, and is fading. Witness, in fact, WindRiver's huge adoption of Linux recently (and their large hiring of Linux developers).
Microsoft's OS's are each well behind Linux; and even combined, still add up to slightly less marketshare (or at best, comparable) than Linux.
So, the bottom line is that Linux has come from absolutely nowhere in the past 5 years to become one of the key players in the embedded space. Completely contrary to the EE Times article. Shame on them for their attempt to completely distort the truth here.
Linux in the embedded space is only going to keep on growing; the advantages with it over the closed-source solutions are just too huge.
The best way to predict the future is to create it. - Peter Drucker.
If I were making a microwave oven, I probably wouldn't be interested in using linux either.
How many said they weren't considering it because they didn't think they needed any os?
-- Should you believe authority without question?
Traditionally speaking an embedded system is usually one that requires real-time functionality. This is not inherently supported in the linux kernel. The organization (FSMLabs) that brought real-time functionality has a patent on its technique and as you would expect they require purchasing licenses to use their software. There is currently an open source project, RTAI, that was a byproduct from the original real-time linux project but up until fairly recently they weren't able to including certain scheduling techniques because of the patents. Anyway, long story short there are legal risks involved; companies generally don't like this.
Here is the catch. WinCE (so well named!) has better out-of-the-box driver support for all sorts of random peripherals than the PPC, ARM, and MIPS ports of Linux (last I checked). I ran across a lot of this in working on my wearable project. At the time I found that the version of PPC linux that ran on one of my boards had _very_ broken support for USB keyboard/mouse/HID devices, and the next version up broke the vendor supplied framebuffer drivers for the NTSC out. What do you do there?
I agree with the parent poster in that volume is the answer. For me, when I've got a finite amount of spare time, hardware goes "stale" with alarming speed, and all of that jazz, I'd rather use something with better out-of-the-box driver support. I ended up going back to a much less power-efficient x86 solution just so all my bloody drivers would be there.
The same goes for J. Random industrial automation project, where you have maybe ten or twenty units in the field. If they have to pay their geeks for a couple hundred hours to fix broken drivers or start from scratch for all of the standard peripherals that some $x/seat version of WinCe will take care of, it's silly. That $x/seat means a lot more when you ship thousands or even millions of the devices.
This is a real pisser because what we need the most is for the embedded HARDWARE companies to take Linux a little more seriously (this is happening, but at a snail's pace). Most of those SOC (System On a Chip) widgets (y'know, a CPU, and a handful of common IO peripherals like an LCD/CRT video controller, USB master and slave, a couple GPIO banks, and IDE/CF controller, and variety of I2C and RS232 ports rolled into one wafer) manufacturers are writing drivers for all those builtins for CE, and although you get the datasheet, it's still a lot of (tedious) work to write those same drivers for Linux.
Maybe (a temporary) hack would be if somebody could figure out a way to wrap the CE drivers for any given arch and run them under Linux. Ick! Bleh!
---
Play Six Pack Man. I
I think many are confused by GPL and propriety software, first you just need to make sure you only link against LGPL libs. GNU C and C++ libs are LGPL so your covered there. Ah but what about the kernel!! it is GPL, if you open the COPYING file in the root of the kernel source you will see Linus has added the following clause to allow accessing the kernel with system calls even if its from propriety software, see below qoute: "NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. Linus Torvalds"
internet == low ?! routers ? etc ? adnausium internet devices for reliability ? phome devices for reliability ? internet is small ? where is the beef?
The survey did bring up three issues which should be addressed by the embedded linux community, whether those issues are misconceptions or actual problems. 1) Incompatibility with software, applications, and drivers. 2) Performance or real time capability. And 3) support."
;-)
The points are somewhat valid. I've used a few embedded style solutions such as GeeXboX.
Firstly, they rely on being minimalistic first and foremost. This means removal of unnecessary things which could use up more space and resources such as X.org for many of them. They remove a lot of things not absolutely required for the product. To that end, the first point, incompatibility applies. A lot of other software will fail to function correctly or even perhaps to run at all. Usually the saved resources are worth it, but, it does make it a LOT harder to integrate major changes such as using a new program for some part or other. This encourages the reuse of already in place stuff. For example, for the sake of maintaining the current setup, interface, software, etc, GeeXboX is using mplayer for TV rather than some of the other more popular utilities such as MythTV and one that I thought looked pretty promising to replace a lot of GeeXboX's functionality, FreeVO.
Well, my first point kind of brushes on the second point made above on performance. In fact, #2 is way off base with a real embedded linux solution. Due to the minimalistic nature of the systems, they actually perform BETTER at what they were made to do. It's only things they were not where they will do worse. For example, GeeXboX's official requirements are listed as:
* x86 Pentium-Class CPU or above (P2-400 should be quite enough) or Macintosh G3 (G4 highly recommended)
* a VESA 2.0 compliant graphics card (for x86 PC only).
* an ALSA compatible sound card.
* at least 64 MB of RAM
* CD-ROM or DVD-ROM drive
* Motherboard which supports booting on CD-ROM (should be ok for everyone
* Keyboard, Joystick or Remote Controller, using a Lirc-compatible IR (InfraRed) receiver (check http://www.lirc.org/ to build yours), e.g. Miro PcTV's one or ATI Remote Wonder.
In fact, those little $100 laptops should be able to boot GeeXboX and play current gen DVDs... And easier things like MPEG4 (DivX, XviD, etc) need less. I have played 640x480 mid to somewhat high bitrate encodes smoothly on a Pentium 2 running at 233MHz (though I did overclock to 266MHz after initial tests for better results on some slightly higher bitrate things.) No, performance is not an issue.
To address number three, support is kind of both ways. First of all, most of these projects have bustling communities where users can help each other and on a few occasions the devs themselves will actually help (GeeXboX is a good example of one like this.) On the other hand, since support is 100% unofficial, a more unusual problem can result in few to no responses forgotten in the back pages of the forums with no solutions. Simpler problems often result in a tired canned response because they are sick of having to answer the same question over and over and aren't exactly being paid to do so. Some projects lack the huge communities and dev interaction and you end up with far more unanswered questions and unsolved problems. Also, if you want a new feature or whatever, the answer sometimes painfully enough ends up being told that if you want so-and-so, you should do it yourself. Since the person asking usually lacks the technical expertise to actually do this (hence the request thread rather than a "I've started adding so-and-so to the distro and need feedback" style thread.) Then again, some requests are admitedly ridiculous or against the goals of the project such as the people requesting X in GeeXboX, or, for an example of ridiculous, one person actually asked for a Gamecube
The last time I read about embedded linux, it sounded like it was going to be a really big deal. The 2.6 kernel has soft real time support. It's not true real time because kernel threads can't be preempted. But there are check points at which the kernel will give up control. It's supposed to be far more responsive than the 2.4 kernel. I had to deal with this issue when writing asterisk modules. The ztdummy module required the 2.6 kernel (I think) because of real time support. But anyway, I read that companies and developers had already started developing embedded linux apps for the 2.6 kernel well in advance of its release.
Another (much lesser known) one...
SAM Coupe - used "^" to go up the hierarchy.
Coming soon - pyrogyra
I've designed an embedded system used in a military application. It had to fit in a small space, so parts count was an issue. I went with a high-density FPGA with several hardware state machines to do the heavy lifting, and an embedded processor (compiled into FPGA logic) to run the show and handle the Ehternet interface.
When it came time to choose an OS, I chose eCos. The program was sufficiently complex to make an OS-free design too difficult, but I didn't need what Linux delivered. Also, to run Linux, I would have needed an 8 MB flash chip. With eCos, I could fit 3 images each of hardware and software on two 2 MB (16 Mb, biggest serial flash I could find short of RS-MMC) serial flash chips. Also, eCos starts up in far less than a second, while Linux took about ten seconds to get in gear. In addition, drivers are easier to write for eCos (they have to do less to make the OS happy). And eCos is a real-time OS, so I didn't have to worry about getting into a fight with my scheduler. Lastly, eCos is GPL, same as Linux.
It's running like a champ now. As a bonus, eCos comes with a lightweight HTTP server, which serves web pages by calling C functions (effectively, every page is a CGI; did I mention that I don't need a filesystem?). This is incredibly useful for unit testing and in-system debugging. I can also reprogram the whole thing with just a web browser and a TFTP client.
I don't think EE times is trying to distort the truth here. EE Times is an industry magazine aimed at developers and engineers. The devices that embedded OS systems lend themselves to have experienced an explosion of popularity in the last 5 years. Before that, embedded OS were limited to more microcontroller applications -- and having propgrammed a few of those myself I would have used anything that was avaialable, cheap, and would solve my problems for that application. As an engineer I don't care about marketshare for product development. I might consider it an issue for support for ME -- but my final end product just needs to work. Period.
That embedded linux has EARNED 17% marketshare (which I personally find hard to believe if you include microcontrollers -- and I've got my Nokia 770) in 5 years is a non-story in EE Times. That it HAS that much IS the story. And that, frankly, shouldn't be much of a surprise either.
If you the smallest Linux you could go for uclinux. The downside is you loose memory protection and some other nice to have features.
Yes Linux is a bit heavy for some embedded products. It may be that Linux just isn't suited to that application. Sounds like there could be room for a new OSS project to address that market.
It could be a very liberating project. the embedded market doesn't need to be as backward compatible as a server or desktop does. It doesn't need as much hardware support, and it doesn't have to have a friendly pretty installer.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
It seems to me that the utility range for embedded linux is narrow. If you're running on a full PC platform and presenting a UI on a monitor, or doing a task for which an off-the-peg solution exists, you'll want and chances are you'll have no other sensible choice but to use windows (eg: cash machines, point-of-sale). If you're doing hard realtime or running on a very small device, Linux won't cut it. Palmtops are suited to running Linux, but the users probably don't want it. Embedded Linux seems to me to have staked out a niche in dedicated but soft-realtime devices that are sub-PC but still pretty beefy. Examples: DVRs, MP3 players, high-end phones.
Nine-tenths of embedded anything will now and forever be running hand-hacked C or assembler over bare metal, or an "OS" that amounts to little more than a runloop and a deterministic thread-scheduler.
It's absolutely no suprise that many embedded system developers don't plan on, or don't want to, use embedded Linux. If you wan't to use the least amount of resources possible, you will design everything in hardware, and keep it that way, that's why it's an embedded system, it's designed for a single task, and there's no reason for it to change. However, if you plan on designing some sort of resuable control component, such as a common controller for some sort of networking device(such as D-Link does, and others), then embedded Linux is not a bad idea, since you can change it to work in multiple tasks, and keep production costs down. However, by writing up all my VHDL, and designing my own circuits, I can produce smaller and faster devices without the need of an OS. A good engineer should be able to come up with a good datapath on their own.
quotestaken out of context. and you still miss my point. the point i'm making is not about the shell. the point is about the explorer, the graphical way of looking through files. i can't be arsed ton show you the screen shot where windows doesn't have either ".." or "." in it but linux does. i'm bored of this now, fuck off
I'm sorry, but not only are they not publishing the whole story, they are deliberately putting a negative spin on it. That is, they explicitly imply no one is using Linux, when the truth is it's one of the most (if not THE most) widely used embedded O.S.. Had they been interested in publishing the whole truth, they would have mentioned this fact. And the fact that its marketshare growth has been explosive.
Instead, they refrained from mentioning what past surveys had found, as well as the growth of Linux. By doing so, and implying that few are using Linux, it's clearly aimed at generating FUD.
And, while you may not care about this for your own work, there are many, many PHB's out there who do read this stuff, and challenge their engineers' selection of O.S.. I daresay it's the sad norm in the business; at the least, it's all too typical. And articles like this add fuel to the fire.
Microsoft is well-known for having shills who are employed at various rags. They've used this tactic before with trade publications; this has been reported in the past on Slashdot. I've even seen it first hand.
It's a pity that Dylan McGrath has decided to appear as one, instead of going after what the real story is. But, I guess journalistic standards aren't of interest for some. A pity it applies to the EE Times.
The best way to predict the future is to create it. - Peter Drucker.
Your ignorance is actually stunning. The Windows explorer doesn't have current directory and previous directory shortcuts listed because they're superfluous in a GUI interface. They're only useful in a command line context and would be screen clutter otherwise.
ah i see in your next reply you state what i was saying to your first. anyway...
cheers, glad someone is enjoying it :) i hate being misunderstood and usually end up posting after i've been out on the lash when i reply to stuff. all these people just jumped on me to nitpick so that they could try and make themselves look better. are they really that hard up for knowledge that they want to lecture me about ".." and "." ?
crazy and petty. but now that i know someone else see's the ridiculousness of it too makes it less coronary inducing
Now, do us all a big favor and kill yourself.
My D-Link DSL604t is Linux based too, and so is my PDA
/. audience--mostly younger males in IT. These folks think embedded means what controls their DVD player, television set, TiVo, PDA, router, etc.
These comments speak volumes about the bulk of the
While those are certainly a major portion of the embedded market, a large part of the embedded market (perhaps even larger than the consumer electronics segment) is outside the realm of consumer electronics. Think industrial automation, automotive control systems, logistics (barcode, RFid, etc).
Take the industrial automation market--GE, Siemens and Rockwell(Allen Bradley) are the GM, DaimlerChrysler and Ford of that market (the big three). Look at their lines of PLCs(Programmble Logic Controllers). How many of their PLC processors run Linux? EXACTLY ZERO. You have to understand the history of this market. Although PLCs are basically specialised computers, the design philosophy is based on a very different set of priorities. Things are kept simpler, more robust and hard real-time is usually essential. Customers demand 25 years or more for support and spare parts availability (the 7-year lifespan of Windows products is laughable in comparison). Change is slow and evolutionary.
Linux is capble of the task (there are a handful of smaller players offering RTLinux-based PLCs) but automation people are reluctat to change what works and suspicious of unconventional design choices. Just look at the most common way of programming PLCs--ladder logic. Yes, to this day typical PLC programmers are most comfortable using a graphical language that mimics engineering drawigs of electromehanical relay circuits commonly used before ENIAC blew its first valve, with little symbols for contactors and switches and coils.
This industry is also notoriously proprietary. Every vendor has invented its own, closed-design protocol stack and one were compatible with each other (like home computers of the 1980s). It took about a decade longer than the PC industry to wake up and participate in more open standards like Devicenet, Controlnet, FOUNDATION FieldBus etc
Contrast this to the history of Linux: it was wide open from the start, has evolved and advanced very rapidly, and certain aspects of it change often over time. This doesn't always give Linux a technical disadvantage, but it does mean it is a harder sell to the control systems crowd.
I'm sure that PLCs don't sell nearly as fast as iPods or cellphones ut they sell for a lot more money per unit, and they sell for a much longer period of time, but I'm willing to bet that is a big reason Linux remains a minor player in the embedded space. I think it is gradually changing though--for example companies partnered with Rockwell are producing Linux-based modules that fit in Allen Bradley PLC chassis for data collection and so on, and with the emergence of commodity IT technology on the factory floor (in the form of Windows-based operator interfaces, MSSQL and Oracle databases to collect process data, etc) engineers have been forced to face the instability and "paradigm shift" anyways. I think that the market is reaching a point of being more comfortable with looking at more "radical" alternatives like Linux.
A lightweight, open-source OS for embedded applications already exists: it's called eCos. Haven't used it myself, but from what I've read, it looks promising. YMMV, etc.
If Ford buy a kernel from Montavista, they don't care where it came from, and they expect Montavista to have QAed their product. The fact that Montavista didn't write it isn't Ford's problem. Automotive suppliers like Delco aggregate components from sub-suppliers too, but they accept liability (in the first instance) if their aggregate goes wrong: they can't turn around and say to Ford "oh, we didn't make these capacitors, talk to our supplier CapCo". Delco might, at some later point, turn around and sue CapCo, but Ford has no relationship with CapCo, no responsibity for QAing CapCo's capacitors, and no desire to go chasing CapCo when things go wrong.
But if Ford are asssembling circuits from the capacitors, it is their responsbility to ensure the circuit works. MontaVista won't supply Ford with a working engine control module (i.e. hardware with a custom software component). Either Ford produce one, or they get another supplier (who might then be MVs customer). In either case, the responsibility for the module is not MVs. Bear in mind that MV supply software, and in most cases software is supplied without warranty no matter who is supplying it (yes, I am aware there are exceptions, but in the normal business world this is the case). This in itself makes it very different from a company that supplies manufactured products.It was like a profusion of Comic Book Guy clones all swooping down upon you, saying 'I sure hope someone got fired for that one.' Scary stuff indeed. Makes me feel a little sick sometimes, other times, I just laugh and laugh and laugh at them. Somewhere between their precious tendency to brand anyone they don't agree with as Troll/Flamebait, and their constant attempts to turn otherwise good topic questions into Linux questions, well, there is entertainment.
Despite being having an international audience, I really do think that Slashdot, by virtue of its American roots and large American membership (snigger), shows the very worst aspects of our so-called friends across the pond, in sharp relief. I've come to the conclusion that the Americans are much more narrow-minded and prone to Group-Think and herd-mentality than their European cousins. Maybe that's because we aren't indoctrinated into an ideology which pushes the innate superiority of our parent nation down our throats. Somehow, as a Brit, it is hard to delude myself into thinking my country is better than the rest of the world, but hey, USA - A-OK, OK?
Why is this relevant? Because it makes their Linux zealotry all the more ridiculous. In nations like South Africa, the likes of Ubuntu are making a real, but limited, difference to the lives of people. In Slashdot-America, Linux usage is to me a bourgeois fallacy: it changes very little indeed. The same people defending the rights of Free software, by and large (excluding the Richard Stallman's of this world), will not spend any real team defending freedom here in the physicality. Some of them still won't vote. Plenty of them will still drink coffee from Starbucks. You get me..
So, in summary - you were reasonable, but factually incorrect - and the Slashdot community embarrassed themselves in my eyes by condescending upon you disproportionally. This thread, to me, typifies the car-crash TV that Slashdot is capable of being in its darkest moments.
Enjoy your social life Know1 - that in itself will annoy plenty of people around here.
true enough. but the amount of times I've typed ls or something similar is numerous. or for instance, when running a long command, typing the first few letters, hitting tab, and then pressing enter, can cause something other than what you expect to happen
there are quite a few ways that something can be run you didn't expect. Best off without it, especially for superuser accounts
being vague is almost as cool as doing that other thing...
i know what you mean about americans...especially american linux zealots as someone who has lived a double windows/linux life. don't even get me started on the bsd crowd. i've often thought and still do that one of the biggest barriers to linux acceptance is some of the people who are meant to promote it. i'm thinking some irc channels in particular.
all i do is just keep telling myself "it's only the internet, it's only the internet", and as you said, at least i do have real life friends... i see you occasionally have problems with malicious modders too, i'll have to not rise to the bait anymore myself...look after yourself mate,might see you in another thread
You're right that the price tag is not a significant influencing factor in getting embedded Linux uptake. Compared to WinCE, Linux development is **way** faster for numerous reasons. First off, the Linux code that runs on an embedded device is the same as on a PC or IBM mainframe (obviously low level driver/CPU stuff is different). This makes for better consistency. WinCE != WinNT and has different features/bugs.
Secondly, the open source means you can get in and fix/tune things when you want to instead of having to convince MS there's a problem then wait for them to fix it on their timescales. Being able to see the code helps debug problems far quicker. Theres a lot more open discussion on Linux than there is on most other OSs.
Linux build times are pretty quick. The time it takes from when I modify a line of code to having it running on a target (ie. make -> download reboot target) is only a few seconds. My WinCE builds take 20+ minutes to do the same thing. This means less builds in a day.
Linux has a bunch of v cool debug things like procfs.
These things add up to making Linux development far faster than WInCE. Some of these concepts carry across to other RTOSs too.
In application space, I will forst get an app going on a PC before tyring to get it working on an embedded device. This development is far faster and easier to debug than on a target. Having consistency of OS from host to target reduces migration issues.
These are some of the factors that make Linux cheaper, not just the price tag.
Engineering is the art of compromise.
Those running Linux probably filtered the "solicitation" out as spam. Those attending the conference may not be the best cross section of the industry.
:)
I missed my opportunity to do a counter-study at LinuxWorld this week!
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)