Slashdot Mirror
Real-Time Linux Developers Unite On API
Markar writes "Developers and programers decided to support EL/IX by Cygnus Solutions as the API for Real-time Linux. Only one dissenter was counted after the vote was taken. The lone dissenter wanted to wait for further developements. PlanetIT is carrying more information. " You can also check out more information about the conference as well.
decloak, coward. Show yourself and prove this isn't just sour grapes...
Old news. The conference in question took place in December 1999, and has resulted in several gloating press releases at that time.
i don't know. but...penis.
the Linux kernel default of 100Hz resolution is insufficient for realtime needs. Yes, I can change the value and recompile (I did just that), but my customers are afraid to do so with their stock Red Hat 6.0 Linux boxes.
Lineo is a wash company anyways.. They violate the GPL, and are "hostile" as Linux re-packagers go. I wish that they would have also voted on adding a Free for all except on anything from Lineo/ Lineo must pay $22M to use our code. rider in the decision. Lineo = Linux sodomized for greedy people.
Offtopic? Methinks some moderator needs to put away the crack pipe.
this is a system for non-critical but needs to be accurate systems... Like manufacturing machine control,data measurement, etc.... it is NOT used for fly-by-wire, or anything where lives are at stake. This is the realm of the custom app that doesnt use any OS. The flight computers we have in airplanes now was developed for the Apollo program in the 60's and besides small refinements and tuning is what is still used. the overhead of an OS is stupid for something that is going to do one job, that only, and must not fail. Adding layers of anything just adds more things to fail.. NOTE: your car DOESN'T have an OS, it has a program that only does it's one job. RT linux is great for automation/robotics.. it is crap for flying an airplane with 600 people inside. (Unless you want those people to have a higher risk of dying because you wanted an "abstraction" layer)
Reaching into my history, I found this article. It had 40 comments already, then it disappeared. I think Slashdot should at least post their reasons when deleting articles like this. Or even better: if something is wrong with the article, add a correction. That way the people that already saw the article know what's going on.
I moved over to linux from the Amiga. When I started coding for linux, I was appalled at the crappiness of UNIX message passing. I want to be able to pass a 100Mbyte mjpeg from one program to another as a simple message, like I could pass huge(for the time) data sets from one program to another in AmigaOS with SendMessage()
Note that the entire AmigaOS is a house of cards built on (blazingly fast, but next to impossible to memory-protect in anything other than a cooperative (semaphore locking) fashion) message passing by reference.
Now maybe they will finally get around to porting Linux to a Vic 20
Who outside of the tiny circle within Cygnus knew about this "standard" before the decision process had begun?
The Linux community suffers because of fringe cliques declaring themselves the Voice of the Community.
I smelled this attitude as soon as the "Open Source Summit" became public knowledge - exclusion of the people really contributing code does a major disservice to everyone.
Maybe its time for a little revolution against these self appointed "leaders"....
this is very cool
Anybody know what happened to the Novell NDS article that was posted here earlier?
It means petrified in the sense of "frozen solid". That's why the grits need to be hot, to help everything un-thaw.You know, this has got me thinking. This should become a poll, favorite place to pour hot grits.
AC - For every question there is an obvious answer.
Not only is she in episode 2, but word has it she'll have sex with Anakin.
Favorite place to pour hot grits?
My favorite place to pout hot grits is down my pants!
No? So many things like..oh... Xfree86 and all the gui apps that people want to run on it seem so slow, jerky, and balky because, I have always suspected, the time sharing nature of Linux and something about its approach to multitasking make it seem that way. Which it is, from the point of view of a desktop user who just wants the windows to move smoothly around the desktop, sound and video to play in synch and so forth.
A start-over with a "hurry-up" version of Linux, which emphasizes getting a few things done on time, rather than ensuring the eventual execution of possibly hundreds-to-thousands of overlapping processes, might produce a better desktop for Linux enthusiasts who care about the desktop at all.
It has long been known that "reality" is based on the consensus views of groups of human beings. It has also long been understood, if rarely precisely formulated, that the human perception of time is variable. A host of factors, such as adrenal activity, endocrine system fluctuations, auditory stimuli like the roar of crowds or aircraft engines, extremes of snesory input of any kind, emotional and mental states (e.g excitement, boredom etc.) are known to influence the perception of time.
These variations are so strong that people devised so-called "objective" means of assessing the passage of time, such as sundials, hourglasses and clocks. People have abandoned their rolse as codeterminants of consensus reality and delegated their authority in determining time to these external aids, but the solution is not wholly satisfactory. Consensus perception of time is often at odds with the time keeping devices comonly employed resulting in emotionally and physcally damaging stress. Advanced OS developers recognizr the destructive role that system clocks are currently playing and have sought to introduce a more user-friendly "Real Time" system. The "Real Time" clock analyzes a variety of environmental factors and estimates the impact these might have on perceived time. Sensors like those used in the polygraph feed physical data about users into the system allowing what is called "near Real-Time" adjsutment of perceptual time. Some systems periodically poll users and add the results to a weighted, consensual time. Such a time index is considered more "real" than an abstract measure.
The powerful effect of perceptual variation in "Real Time" is partly responsible for the essential meaningless debate around "benchmarking" between proponents of the Pentium and PowerPC families of precessors.
not vms, probably vxworks. get it right you fucking zEalut.
I got to be anonymous because I'm using up my moderator points on trolls.
I can assure you that the "concensus" about the Cygnus API was done behind closed doors, by people that already have an financial investment in the Cygnus approach. It is marketing over substance.
Right tool for the job. That's like using the top of a screwdriver to pound in nails.
Then how come Slashdot doesn't know about this till now?
A real-time operating system is one that has to respond very quickly to incoming hardware events, usually with a constraint on the maximum time alloted to complete the response
Minor correction. Realtime systems do not necessarily have to respond very quickly to a event. That just have to respond in time. If could be they have a hour to respond... but(especially hard realtime) but they must respond within the time.
So there's really nothing wrong with my system except that it's been programmed to ignore me?
I see even classic Slashdot is now pretty much unusable on dial up anymore.
It sounds as though you're describing tolerance of faults in hardware, but isn't software fault tolerance an important something that has to be anticipated and designed for as well? So that one failing program doesn't freeze or crash the entire system?
I see even classic Slashdot is now pretty much unusable on dial up anymore.
On the Real-Time Linux mailing list, this entire load of piffle was discussed in February, when EETimes ran an article. I'm sure you can find archives somewhere around http://www.rtlinux.org/.
Poor Mr. Wilshire was misquoted in the original article, and if you search for his emails in the archives, you will see the thread. Well, since I can't be bothered finding the URL, I'll post his message to the list verbatim.
I have not asked permission to post this, so I hope that Mr. Wilshire will accept my apologies.
Date: Tue, 15 Feb 2000 11:05:25 -0800
... ...the other non-sense sniped... . .
From: Phil Wilshire
To: Nicholas Mc Guire , "rtl@rtlinux.cs.nmt.edu"
Subject: [rtl] Re: article on the Workshop
Nicholas Mc Guire wrote:
>
> Hi All !
>
>http://www.eetimes.com/story/OEG19991220S0029
>
> VIENNA, Austria - Developers of embedded-Linux systems
>
> also decided to back Cygnus Solutions' EL/IX as a common applications
> programming interface (API) for embedded Linux.
>
> Nearly 100 developers and programmers attended the grass-roots Real
> Time Linux Workshop here last week, and all but one voted to proceed
> with the use of EL/IX as their API.
>
>
>
> I conclude that there where two workshops in vienna
> on that peter and me organized and obviously a second one
> that we did not know of...
> It is simply stupid to belive that puting fals information
> out on the net will help push EL/IX as a standard API
> I guess a view people out there did not understand the
> ideas of open source and even less the intent and spirit of the
> realtime linux workshop in Vienna.
>
> since the article claims to be based on information from
> phil whilshire maby he could comment on it
>
> D'ehre
> Der Herr Hofrat
Willingly I will comment. There was some consderable misunderstanding in the way this article was presented.
I was NOT allowed to see the results of a brief telephone interview and much that was printed was a shock to me.
I do think that the statements about adopting EL/IX unchanged were inferred from another source.
My statement was that we would work together with CYGNUS to help develop EL/IX into something we all could use.
This is a warning to all of us not to accept telephone interviews and publication without prior approval of the result.
I have been waiting for this backlash in the community and hope that my true motives in all this are clear. If one of us make a mistake we are, in general, merciless.
I want Linux to succeed and I want Real Time Linux to succeed.
i have devoted many man hours in my own time to helping the community in many ways.
I want the Real Time Community to grow stronger and develop the way forward for this technology rather than leave it in the hands of commercial entities.
This includes Cygnus.
If they push EL/IX as the "Open Source" API and it bears no relationship at all to what is really needed then we all loose. We need to work together with everyone, Cygnus included, and produce what we need as an API. We also cannot present to the waiting users out there a confusing variety of API's. The Real Time Linux community is a very strong force we have what it takes to make this happen.
I apologise to the community for any misrepresentation . Those that know me will confirm that I am VERY careful in making any such statements. I will continue to be even more careful in the future.
I hope that we can resolve this with a simple public flogging.
regards
Phil Wilshire
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl " | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
... that other standardized API's will be elected. If that's one thing we can learn about M$ is the easy app development. Except we benefit from the Open Source: no hidden API calls.
Sounds like a good enough excuse to me. :)
Of course. A 'system' consists of both hardware and software, and both have to work properly. Some systems even go a bit farther and try to compensate for 'wetware' failures -- that is, if the human who is controlling the system gives an order that the system decides must be a mistake, it will disregard it.
The way they do it is to implement a small real-time kernel, then run the linux kernel as a real-time process under that kernel. Then, userspace, non-RT linux process can communicate with the RT processes via either a mem-locked shared memory segment or a FIFO.
Seriously, though, it's really good to see developers that can actually agree on standards, even at later stages in Linux development. Unlike certain commercial projects I can think of.
An API for embedded Linux will certainly help foster growth in the number of programmers that are willing to commit to it, for both OSS and commercial endeavors.
How is progress coming on the Real-Time aspect? I've been a little curious to see how that's implemented. It seems that it would require some serious revamping of the kernel.
Free music from Jack Merlot.
It's not VMS. VMS is in ALOT of places and has been for a LONG time.
OS/9 or Concurrent maybe?
You could look at http://www.rtlinux.com or at http://www.fsmlabs.com. EL/IX does not currently feature as part of our API roadmap. Tip: In the Linux world, one way to find out about Linux projects is to look in the MAINTAINERS file in the Linux source.
I suppose that the big question is, is this really a good move...
I think that they really have a lot to offer each other... but I wonder if real time linux won't just sort of be eaten as an entity by cygnus.
Eh...
> been for a LONG time.
But not for much longer - VMS is dead in the water and NT is taking over its workload fast.
This is one gaping hole that Linux should be targeting but doesn't seem to be.
> OS/9 or Concurrent maybe?
He was probably thinking of VxWorks, which is rather cool but can hardly be described as unix (as it often is).
I seem to remember some other attempt at a real-time version of an OS that crashed and burned pretty bad...I can't remember the name. May have been VMS, I don't know...anybody else?
what is the current state of real-time extensions in Linus's kernel source? Any Alan Cox diffs?
I have recently started playing around with an operating system called Amoeba. Originally developed in the Netherlands, Amoeba has some amazing features. Amoeba has all the right seeds to start up a new kind of distributed operatin system. It's ability to be implemented on multiple machines pooling CPU power sounds like an advantage in server clustering problems. Why run software to cluster when you can have an OS which has kernel supports clustering right away.. in a terrific fashion... Amoeba... check it out.
This really sounds like marketting hype from RedHat/Cygnus. I've heard nothing from Lineo and the other embeded Linuxes. What about Bluecat/Lynx? Where are the others? We should also remember that EL/IX was not developed as a standard Linux embeded API, but as a eCos/Linux API, eCos being Cygnus's own Free embeded OS.
Great. The realtime Linux world has settled on the EL/IX API. But what does it actually do? How does it affect the Linux kernel? Is EL/IX a library that sits on top of the kernel, or is it part of the kernel itself? Does it replace the standard system calls, or merely augment them (perhaps with calls for controlling the realtime-ness of a process)? From the point of view of an application writer, how different will an EL/IX Linux system be from regular Linux?
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Soft realtime (the announcement in the article regards hard realtime; see other comments for the distiction) generally does good enough. I'm in the habit of running my X server and window manager with realtime priority on slower machines (when I'm not doing anything else compute-intensive that I care about). It does make a big difference in that regard -- where the problem actually is CPU contention, anyway...
So, it's not a matter of starting over, just a matter of selecting another one of the existing Linux schedulers. (this operation is NOT, I repeat NOT synonymous with nice(2) -- see sched_setscheduler(2) and friends)
I actually wrote a set of tools that allow you to manipulate the realtime schedulers under Linux (soft realtime was introduced in Linux 1.3.something, if I remember correctly), and they're on freshmeat as rt-utils.
The homepage, and download links are out-of-date, but I'll get around to dealing with that soon. In the meantime, if you want a copy, drop a line to mental@rydia.net
DNA just wants to be free...
> Linux/programming/OSes etc. - but I still
> ahve no clue what the heck it is. Could
> someone please explain, in simple terms,
> what it is that all these articles are
> refering to?
A real-time operating system is one that has to respond very quickly to incoming hardware events, usually with a constraint on the maximum time alloted to complete the response. While a conventional OS (like Linux in normal operation) offers no guarantees on how quickly it will respond to requests (usually very quickly, but under high load a request could be deferred quite a while), a real-time OS usually offers guarantees on performance.
Real-time is subdivided into "hard" real-time (an absolute guarantee on system response, usually harder to accomplish) and "soft" real-time (an average-case guarantee with a certain degree of variance.)
Real-time processing is most common in things like embedded systems ("fly-by-wire" computers on airplanes, for instance, had better not take too long to process requests!), but occasionally real-time shows up in a userland/PC environment (audio processing, scientific equipment monitoring, etc.)
Hope this helps...
I keep seeing stuff about Real-Time Linux/programming/OSes etc. - but I still ahve no clue what the heck it is. Could someone please explain, in simple terms, what it is that all these articles are refering to?
-- Imagine how much more advanced our technology would be if we had eight fingers per hand.
-----------
"You can't shake the Devil's hand and say you're only kidding."
A real-time system is one that guarantees certain processes a certain amount of computation per unit of time, or that a certain process will finish by a certain time. This can be used to guarantee that a sound gets played without skipping, or that a video gets played without any pauses. People doing embedded stuff can use it to guarentee that their device does what it needs to do at the right time. Bad things can happen if an embedded system doesn't do something fast enough because of processor load. Basically, it is a system that is aware that somethings need to be done in a certain amount of time to be correct.
Fault tolerance is actually a much simpler concept than realtime, but just as hard to implement. :P
A fault tolerant system is a system in which the designers have anticipated some of the ways in which a system can fail, and designed the system to keep on functioning, at least at some level, in spite. An example of this would be redundant hardware -- if, for example, one power supply fails, the system has a backup power supply that will take over.
Fault tolerant systems are not necessarily realtime -- for example, a lot of servers have some degree of fault tolerance built in. Real time systems are not necessarily fault tolerant either, but in practice, since realtime systems are often used in places where a failure would be catastrophic (ie. the control system of an airplane) it would be a very wise idea to design some fault tolerance into them.
Real-time doesn't just mean guaranteed processor bandwith. The response time is bounded. This is important.
Consider an automated assembly line application such as a sorter. A reader reads a bar code and sends a package down 1 of 10 lines. If a timer is used to control when an actuator will push the box off the line, the timer better not pop too early or the box won't be there yet.
I know this example is contrived, but it is the best I could think of in a short time. The basic point is that in a real-time OS the computer not only has to respond within a specified time, but that time is bounded so that the computer can't respond before the specified time either.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
It's reminiscent of MERT, the first UNIX real-time variant, from the 1970s.
Since some people are asking what a realtime system/OS is, here goes:
A realtime system is a system in which the response time of the system to an external event is predictable and bounded. That is, if a user presses a button, a realtime system will guarantee that the system takes whatever action is associated with that button press in a given time, or less.
This does not necessarily mean that the system is fast or responsive. For example, the design spec could say that if the user presses the button, the system must respond in 5 seconds or less. As long as the system always responds within 5 seconds, it is still a realtime system, even though most people wouldn't think of it as such.
If the system fails to respond within the specified time frame, it is considered a design failure. As such, it is used mainly in things like industrial or vehicle control systems, where failing to respond within the specified time can have catastrophic consequences.
A realtime OS is simply an operating system designed for use in realtime systems. Because of strict constraints on response times, some harsh tradeoffs must be made -- ones that users of desktop and server operating systems would find hard to fathom.
For example, a realtime filesystem is very difficult, if not impossible, to design, because some filesystem operations can have a potentially unbounded completion time. Usually, any processor cache is disabled, because, although the cache greatly decreases the average execution time, it can actually _increase_ the worst-case execution time, and it makes it very difficult to determine how long a piece of code is going to take to execute.