Slashdot Mirror
Upside Article On Embedded Linux
Paddy wrote to us about
today's Upside article on embedded Linux, and what it can/does mean for Linux. Talks a bit about Lineo, and the possibility of kernel forking - good summary of the landscape.
← Back to Stories (view on slashdot.org)
Some things to remember about the embedded market:
1) The present 8 bit processors work fine for many tasks. So why have all the bits needed for an OS when an 8051 or z80 will do the job.
2) The embedded market lives and dies (at least as far as management is concerned) by IP (Intellectual Property, not Internet protocol
Given 1 and 2, any of the 'modern' Oses (WINCE, QNX, EPOCH, Embedded NT, *BSD or even Linux) need 32 bits and relying on a GPLed code base opens you legally up to releasing part of your IP to 'the community'.
Even if you don't HAVE to release your code, do you, as a manufacturer, want to have to go to court to prove you don't have to a jury of your peers, is someone demands the code?
Most companies that have IP they want to defend don't want to take that risk, even if the cost of GPL is $0 per seat, and WINCE is $35.
There *IS* a choice to the GPLed Linux in the Open Source OS arena. It's BSD. And, the BSD license *DOES* protect the IP of others.
If the goal of the Open Source world is to promote Open Source, then why the drum beats for Linux, when, for the embedded world, BSD is a better choice to protect what the embedded world considers its most valuable asset - IP?
If it was said on slashdot, it MUST be true!
Don't bother digging deeper. Please, don't.
Now... if I could just get embedded linux installed into my wife, life would be great!
Remember, an operating system is no more reliable than the hardware on which it runs.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
Why would you prefer VxWorks over Linux in critical applications? It began life as BSD after all.
Yes, but if a group of people fork the Linux kernel, do they have the right to attach the Linux name to their new kernel and gain instant credibility and attention?
In my opinion, they should change the name a little. But that would be Linus' decision.
It seems to me that they are going to put some proprietary glue into their embedded distro.
From talking with them, it didn't sound like it would be GPL'd.
Its my understanding (someone from Lineo can chime in here and correct me), that they will
sell "their" linux with a Royalty fee for each system deployed.
That is the pre-historic business model currently used by several of the embedded O/S companies.
The problem with making Linux into an embedded system is that it is a PITA to strip it down to a reasonable size (I know, I am doing it now).
For those of you craving a more in-depth analysis of the embedded Linux field, I apologize for leaving so much on the cutting room floor.
The forking issue came up both because of last week's uproar over TurboCluster and my background reading on RTLinux, an "extension" of the Linux kernel that brings the real time capabilities to the fore.
Basically, I wanted to see what Linus thought about such "extensions." Apparently, he seems to approve. As a reader mentioned above, the GPL allows forking. This only becomes a Unix-style problem when the bulk of embedded developers -- a more commercially-minded group than PC hackers, apparently -- suddenly decide to branch off and start their own kernel group.
As for knocking the depth of Upside's content, what can I say? This is an interactive medium. If I get a ton of e-mails today and tomorrow begging me to dig deeper, I won't feel like I'm kicking so many readers out of the sandbox just by using the RTOS acronym.
Later, Sam Williams Upside Today
As other posters have stated, the embedded market is a realtime (or more properly, low latency) market, which Linux does not support well. Fortunately, the drive to finer grained semaphoring to support ever larger SMPs also, quite accidently, goes a long way to making Linux a low latency kernel .. which is exactly what the embedded device world needs.
If Linus wants to stop his software from forking then he should have placed restrictions upon users to prevent such. However, since he chooses to use the GPL, he chooses to allow forking. Hence, the choice has been left, by Linus, up to the user. So let the user make the choice!
We can always choose to ignore a user who forks software in a manner we don't like.
The beauty of it is -- and incidentally this points out why we don't need to get worked up about forkin' forks -- when you get all said and done you can telnet/ftp into any one of them. At the other end of the wire they all can pass, to varying extents, what we might call the Penguin test of OSes: If it BOOTPs like a penquin, and if it NFSes like a penquin, it's going to play well with everyone, except possibly certain dain bramaged miscreant DHCP clients out of Redmond.
sync;sync;sync
"Only entropy comes easy" --Lewis Mumford
Indeed. That's why I love the Mac. It lets me get my work done without worrying about what's happening under the hood... But the MacOS is not meant for the embedded market. At least here, Apple's done something right! :)
Is it me or does it seem like this article is a bad anthology on Linux embedded systems. It sounds as though the author was taking stabs in the dark about what linux really means to this market. Linux is small, Unix the father to linux is based entirely on the premise of forking. This should seem obvious because of the fact that you can run seven apps(20 max) on the same desktop and not get the Windows blue screen of death.
Embedded systems is the next wave, but definitely deserving of more than a page of text. Just Slashdot alone has several articles pouring in regarding cheap hardware becoming ideal embedded devices(the router/mp3 player, the tiny web server). The market deserves just as much attention as the desktop market because the desktop phenomena is 20 years old and soon to hit the performance peek. Wake up, progress is all about expanding.
Putting in proprietary glue is the obvious knee-jerk reaction of those who don't understand what they're doing. It's this same mentality which has given rise to the superflous number of companies in the embedded market who sell their silly little BS OS's. Now ask yourself this. Suppose there's a product of any real market significance. And your company decides to go the proprietary route. That immediately leaves you vulnerable to a company which goes the completely open route. You should get a job with Microsoft if you don't think this is a problem. Let Darwinian evolution rule in the marketplace. It seems to be doing just a fine job of things right now.
I develop for WinCE and not being able to build on the target is a big pain in the tush. Even something like profiling which I used to take for granted is non existent. Mayhaps it's time for a job change :0).
The hardware is great... it's just the damn internal logic errors in the current os!
GIHM -The light at the end of the tunnel is only the oncoming train.
Where is Embeded BSD. In many ways the GPL is a pain for the embeded market. I if I write a cool Smart Media Divice driver do I have to realse it to the rest of the world? Under GPL I think I do. Under BSD I think I don't. Don't flame me I don't even have BSD I am a Linux user but I can see why an embeded company might not want to live with GPL.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
There are a number of valid reasons to fork the kernel. No OS, no matter how good is likely to be the master of everything. The embedded environment is very different from clustered supercomputing is different from workstation.
If you're controlling a VCR, and take a 25% cut in speed to cram your code into the next smaller sized EPROM, you'll be very happy (as long as it's still 'fast enough'). If you are doing clustered supercompution, you'll prefer the speed over the space savings.
For a desktop, you'll probably prefer versatility over a few K of memory and you'll probably be willing to sacrifice maximum speed in order to have a more responsive system (which will actually feel faster on a desktop even though it's slower on batch jobs).
Some of the above are doable with tuning parameters, and by configuring compile-time options. Whenever possable, that is the best thing to do.
The balkanization of Unix was a very different issue. In that case, each proprietary vendor forked the code and closed it. Then they made just enough changes to 'justify' preferring their minor varient over the competition. In truth, most of those 'differences' could have been handled with a few tuning parameters and an ifdef or two in the source.
In short, those were NOT technically justifiable forks, they were business decisions meant to benefit ONLY the corperates who did it.
It is a mistake to lump those two things together.
Everyone seems so worried about kernel forking, but isn't that the point of GPL? That anyone can look at the code and make what changes they choose to make?
:-)
Nothing is intrinsically special about Linux Torvalds. He concentrates on controlling the kernel for the main branch. But if there needs to be a separate branch for embedded systems, cluster systems, and other specialized systems, so be it. I don't want to see Linux become a "jack of all trades, master of none" in the name of not kernel forking.
I say, for it and keep specialized code from cluttering my kernel
Jeremy
Looking for a Python IRC bot?
I like where it's going, I like what it could be in the future, yup, I just like it! Now... if I could just get embedded linux installed into my wife, life would be great!
GIHM -The light at the end of the tunnel is only the oncoming train.
Having an open platform to develop on is one thing.
But developing on the same platform as your target is another. No emulators, no conversions, it's the same thing.
That is what the developers want. Portability
Personally, I don't think that anybody would want to go out and have to pay $300 for a copy of Office Pro 2000, and then have to spend another $150 (or something like that) for Office Pro 2000 Windows CE version.
In this competition, I have to give the advantage to Linux.
Articles like this one have been posted before... to sum it up:
- Linux has freely available code -> modified to your embedded system's use.
- Linux has networking support built in.
- Linux also is a very generalized kernel, so things have to be whittled away, no problem, see point #1.
The only thing that was interesting about this article is that they start to mention WinCE and Microsoft, but then never follow up on comparing Linux vs WinCE.-- adraken
The cost is in retrofitting changes that go into one tree into the other tree.
Thus, if there turns out to be a Lineo Fork , the folks at Lineo will find that they either:
For instance, if they fork, and ext3 and XFS filesystems are introduced in the Torvalds Branch , it may be as costly (in terms of programmers' time) to introduce those into an independent fork as it was to implement them in the first place.
The folks building embedded systems may not care right now about IP6 or USB or k001 journalled filesystems; if they branch out now, when the support for such things is tentative, it may wind up being difficult-to-impossible to take the code that emerges a year from now and add it in then.
The overall point here is not that Forking is bad and evil and must never happen, Bad! Bad! Bad! The point is rather more like Forking results in there being substantial costs attached to synchronizing the functionality of the varying versions. Forking is EXPENSIVE which can be rather bad.
Linux may be free of charge, but development of code is most definitely not free of cost. And code forks are perhaps the ultimate example of this.
If you're not part of the solution, you're part of the precipitate.
The author seems to misunderstand the point of real-time operating systems, which is not to be fast (though, of course, that is always nice), but to have a guaranteed response time.
So in a real-time OS you have pre-emptive scheduling and an upper limit on the time it takes to context switch. This way you can guarantee that an important signal ("this patient is about to die, doctor") is serviced (page the doctor, or whatever) in real-time and in the appropriate time (i.e. before the patient dies.)
Do the current Linux kernel have this feature? There is no reason why it couldn't have: good ol' VMS had basic real-time features built in (pre-emptive scheduling), you could add the rest (I think the product was called ELN and was described as "the best kept secret in DEC"), and you could still use it as a "normal" operating system.
Hi!
I don't think that embedded Linux stands to do much in terms of affecting the perception of Linux. I for one, don't care what OS my car uses, my Microwave uses, or my VCR uses. If i need to know or care, then obviously it wasn't implented correctly.
So far as the kernel forking. Who cares? If the kernel forks in order to make concessions to the embedded market, it's still GPL'ed, so other developers won't be left out in the cold. It'd actually be better if it forked in this way, rather than following mMicrosofts footsteps with Win32, where we've now got WinCE, Win9x, and WinNT, which are largely incompatible with each other, serve completely different markets, yet have the same interface and API's tying them together...
With all that, it'd definetly be a boon for developers of embedded devices, supposing the could cut away enough fat from the kernely to make it competitive with other embedded OS'es. Though the cost savings probably won't be enough to make it back to the customer, i'm sure they'ed appreciate having an open platform to develope on, rather than needing to learn the semanics of a new OS when they switch projects...
Part of the vision of the Founding Fathers is that the people should be free to overthrow the government - by force if need be. They were quite convinced of the benefits of doing this, having just done it themselves.
However the fact that much of the constitution (and some early amendments) has clauses supportive of rebellion doesn't mean that anyone wants to really see one.
It is the same principle. The ability to fork is good. Using that ability is bad and only justified if it not forking is going to be worse...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
(Hey, watch that innuendo...)
What they would need is someone like Linus in a "master control" position to make sure that all the feature development that's relevant to the forked code gets moved over. It's no good if suddenly you need a feature from 6 months ago in a segment of code that's already mutated 3 more times. You also need someone like Alan Cox that can field cross-project patches into a pipeline for the master control person. The problem you'll run into quickly is two-fold. You dilute the quality of people working on the main thread/fork and you end up with competing personalities/styles between forks. Tread carefully.
Everything they write is recycled garbage or meaningless fluff. Don't pay attention to anything they say and you'll be much better off.
The primary war seems to be between Windows 98/NT and Linux, and the secondary war is about Windows CE and embedded Linux... although for some uses the full Linux distributions can also go head to head with CE.
Actually I am VERY interested in possible embedded uses of Linux; I've spent most of the last ten years designing industrial control software....
--------- Webmaster, http://www.cpureview.com and
The same could be said of your computer. If you have to know what operating system its running, it wasn't implemented correctly. However, most of us power users out there would like to know. If only I could reprogram my VCR so that I could actually use it.... Then I would patent one click recording of my favorite shows.
Forking is a symptom that Linux is reaching a stage where its own weight prevents it from moving further. Basically there are two thing that can happen:
- a fork, from then there are two incompatible versions of linux that will grow further apart in the future since they are maintained by people with different interests
- no fork, this means accepting that linux is unfeasible in certain domains
Probably a fork will happen. Why? because linux is not flexible enough to efficiently provide a solution for both domains (without forking). A few years ago the linux kernel was a big fat monolith with everything compiled into it. The situation has improved over the years but not enough. It's still a monolithical system. An even more modular system would perhaps have prevented a fork since the embedded version of linux could then choose to leave out a few modules or choose to provide custom implementations of a few modules.
Jilles
'People like Linux, because they can basically have the same environment for both embedded applications and development. You don't want to cut it down too much or you lose that advantage," Torvalds says.'
Having helped to build such a distribution, all I can say this is exactly the point. Developers can run his program on exactly the same platform that will be used for the product. The only difference is that the product does not have development tools (such as gcc) on it.
This eliminates the need for cross-compiling and uploading the code to the embedded board, making life a lot easier. Also, developers can use a standardized platform they are familiar with.
I agree that a fork in the Linux kernel would not be good, but would it necessarily be bad? New technology spawns new hardware, which spawns new drivers. In essence, this process spawns a new kernel. It's as simple as that. The (in my opinion, unwarranted) concern seems to be on whether or not the kernel forks. We should instead be worried about keeping up. The Linux development team is vast. I firmly believe that Linus, Alan and company can handle the changes that will ensue. Linux has always been hailed as a very adaptive operating system, I believe that philosophy will stand true in this case as well. Viva el Linux!