Slashdot Mirror
Papers On Real-Time And Embedded Linux
An anonymous reader writes "LinuxDevices has once again published the proceedings of the annual Real-Time Linux Workshop. This one, the seventh, was held in France earlier this month, at the University for Science and Technology of Lille (USTL). The papers span a range of topics, from fundamental real-time technologies to applications, hardware, and tools. Enjoy!"
OS wars...
I recently installed FreeBSD 6.0 on my laptop.
It sucks.
No cpu scaling in the kernel [even with cpufreq], the ports tools are shit compared to gentoo, etc.
I'm not saying Linux distros are perfect but Gentoo is way more functional and easier than FreeBSD. I don't know what the other distros are like but sucks to their asmar!
Tom
Someday, I'll have a real sig.
Because those better alternatives provide more freedom for Microsoft to take the code, repackage it, hack it about as they wish and sell it to the masses, giving fuck-all back to the community. This would likely bother a few of the developers in question.
For the love of God, please learn to spell "ridiculous"!!!
It mostly comes down to whether you want to have the freedom to stop anyone else using your modifications, or you want to stop anyone denying anyone else that freedom. (One of) The main thing(s) that stops most companies forking proprietary versions off BSD-licensed code is that they then have to repeat any patching, fixing, and improving done on the trunk. (Or repeatedly re-fork, as Firefox has done - and yes, that's not a closed-source project, but it's still a good example for this point.) If you're using a BSD distribution, I'm not sure it can be directly compared to using individual GNU/Linux/etc packages. Maybe it should be compared to one of the linux distros, where again you can go to that project's devs and community for assistance if you need it, rather than going direct to the individual programs and projects.
It's not a festival of mediocrity because it doesn't beat the user over the head with "user-friendliness" (read: dumbed down). I much prefer KDE to Windows or OS X and I have used both, especially Windows. And I, unlike other Linux zealots, actually liked Windows. I personally feel that KDE fits the way I want to use the computer. I don't feel like I'm fighting with it. And it doesn't insult my intelligence. That may not fly for your average user, but they can stick with Windows for all I care. It's a personal choice.
Some people are perfectly OK with other people benefiting from their work, and these tend to be BSD developers. Others are control freaks who fear that somebody else might use their code for private ends, and these are the people who prefer the GPL. Achieving Zen may not be for everybody, but an irrational possessiveness, it seems, is the source of much unhappiness in this world. The developers in question may find themselves happier by learning to surrender their ego. Accept impermanence; accept that the act of giving, nay, the very act of living, involves a loss of control along with a lessened responsibility. Only then can one understand the true beauty of BSD.
Why do embedded developers continue to imprison themselves in the GPL trap by using Linux,
Because Linux has a much bigger developer comunity and you can get commercial support targeted at embedded development from several vendors. Giving better freedom getting developer resources.
And the GPL "trap" as you call it, does not really matter even in embedded development. The interesting part of the product, or the part you may want not to GPL, will reside in userspace anyway making the GPL of the kernel irrelevant.
And that's part of what some people forget. Linux is great. It can be used for just about anything you can think of, given some tweaking. But for some things, while it is CABAPLE of doing everything, it's not necessarily GOOD at it. In general terms, what's better for the gamer? Most games are only available on windows. Some notably excellent ones are available elsewhere, but most aren't. Yet. For an older/smaller/cheaper mobile phone, desktop-intended OS's aren't ideal. Symbian was designed to be fast and simple. An embedded system may need a custom-written system to give it speed or timing features it needs.
That's a rather negative view of the GPL. I'd point out, for example, that helping companies like Microsoft by supplying them with good code allows them to become yet more powerful and do even more damage to the rest of the computing world. In my recent job I had to use Win2K for compatibility reasons. This is due to Windows' massive predominance within the business world, which in turn is partly the fault of, for example, the people who produced the Berkeley TCP/IP stack, as they helped Windows to achieve (moderate) network stability and thus compete more effectively, greasing the tracks of MS's meteoric rise to monopoly.
I'm aware that this is an extremely bad example as BSDing protocols is generally a good thing for uniform adoption. My point is that using the GPL is often an indication of a desire to protect the community of developers rather than of "irrational possessiveness" - possessiveness maybe, but hardly irrational. In this particular case, the "loss of control along with a lessened responsibility" of which you speak includes an increased ability of the more evil proprietary software companies to undermine your developer community - thus there's no short-term incentive for them to play nice. I personally am not quite advanced enough along the Zen path to take this with a smile and a nod and carry on helping it happen.
For the love of God, please learn to spell "ridiculous"!!!
For an older/smaller/cheaper mobile phone, desktop-intended OS's aren't ideal.
I wouldn't say that Linux is a desktop-intended kernel. It certainly didn't start out that way, and wasn't intended to.
Many of the distributions are intended for the desktop. And many are intended to be run as servers. And a fair few are intended to be run in embedded systems.
The Linux kernel has a lot of developers working on making it suit their specific needs. In this way, it can be all things to most people and most things to (virtually) all people. Probably its greatest advantage is the portability of code that's written for it. A telnet daemon written to run on my K7 Athlon can be recompiled to run on someone's Linux-based PDA. Or an ethernet-enabled PlayStation 2. Or my brother's DSL router/modem. That's why cross-scale development of the Linux kernel is important.
tasks(723) drafts(105) languages(484) examples(29106)
I suppose I'll get modded as troll (again) for saying so, but from what you've said, I'd guess you're one of the people who's not an RT programmer.
Real-time programs do need to react in real time. A typical example is that the program needs to react within X microseconds of an interrupt happening. A hard real-time requirement is exactly that -- no "seem that they do" about it. For example, a navigation system for an aircraft must react within the right amount of time to input from the pilot, radars, etc. A late reaction carries the possibility of killing hundreds of people (conceivably even thousands with particularly bad luck about where it lands).
Every system has some delay -- the questions are 1) how much?, and 2) how much does it matter if it misses its window by some small amount? A hard real-time system is one where you have an absolute maximum delay, and you must never miss it. A soft real-time system is one where you may be able to get away with slightly greater delays on rare occasion -- the "softness" of the real time being determined largely by how large the delay can be, and how often it can happen. The situations above with brakes or aircraft navigation are about as hard of real-time as you can get -- excessive delay is likely to cause deaths. A router or mail server has substantially softer requirements. If it misses receiving part of a packet very often, it won't work well -- but as long as it's not very often, it's probably not a problem, and endangering lives is pretty far-fetched even at worst.
Also note that real-time does not necessarily mean much about being fast. Years ago, I worked on some software to control some of the operations in a sewage plant. In most cases, the computers' requirements on the reaction times were measured in entire seconds and sometimes even minutes -- but if it missed a deadline, millions of dollars in damage could be expected, and endangering lives was possible as well. Ridiculously slow by most standards, but hard real-time nonetheless.
So -- the essence of real-time is not about "high speed" it's about "dependable and predictable speed". Real-time requirements are specified not only in terms of "How fast?", but "How serious is too slow a reaction?" -- and the latter is often what really dominates.
--
The universe is a figment of its own imagination.
The universe is a figment of its own imagination.
For the umpteenth time: embedded != small
Sure, a digital camera is an embedded device, but so is an MRI scanner.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
"How about if you try to look into facts before shooting your mouth off?"
I'm not an expert in RT java, but I've written code with required timing accuracy to 1 cpu cycle which I think qualifies me quite well to comment on RT issues.
"What's important is that if you have a specific architecture you need to know, exactly, what delays occur and that they have upper bounds."
The issue isn't speed, it's accuracy. Hard RT systems have lower bounds as well as upper bounds. Being early is no better than being late.
"The same would be true with a Asm or C RT system"
Sure, but the difference is that in Java you have another layer to deal with so determining the timing is more complex.
"The main reason you'd want to run Java RT is because first off, it's faster to write correctly."
This is a matter of opinion even for conventional programs. For a RT system, I think you have the burden of proof for this claim.
"RT applications are said to be so because of the requirement for them to react in *real time* even though that is not the actual case. It just needs to seem that they do."
I though the traditional definition of a real-time was a system that had temporal requirements as well as functional requirements. That is, it should perform the operation as specified and at the right time.
Also, real-time system does not need to be small. There are real-time systems that run Pentium processors with several GHz, it's all about the temporal requirements!
I know not what course others may take; but as for me, give me liberty or give me death!
When you say that real-time software is a dying art you are totally wrong. The move is from specialized hardware and/or mechanics to software-based solutions where the time-to-market for adding a new feature is smaller than for specialized hardware. If real-time software was a dying thing why does a modern car contain so many micro-processors running real-time software?
I know not what course others may take; but as for me, give me liberty or give me death!