Slashdot Mirror
Linus Pooh-Pooh's Real-Time Patch
An anonymous reader submits "Speaking with CNet via email, Linus Torvalds appears to be in no hurry to accept the latest real-time patches from embedded specialist MontaVista into the mainstream kernel, at least not "at this time." Nontheless, MontaVista's new open-source real-time Linux project could broadly expand commercial opportunities for the open source OS, especially in telecom initially, where real-time Linux will likely play on "both ends of the wire." For example, Linux is already making progress in smartphones."
Who talks like that? Seriously.
Direct link to they story.
The 'appears' hyperlink in the summary is pointing to the wrong link. I think the author intended this article instead.
Wouldn't a real time patch violate software update patents
The first link should probably go to this C|NET story, rather than some random search results.
diggity diggity!!
- i don't think so!
I learned something new!
Real Time Operating Systems. Now you know!
He might not be in a hurry, but I'd be surprised if he doesn't realize how this could help Linux. Maybe there are some stability problems with it, but then, I doubt that too. Does anyone have any experience with it? Maybe he's just waiting for the right time, not the earliest time.
Hurricane Ivan: A 17th century prison collapsed. All of the inmates escaped.
Making real progress with smartphones, yep right after symbian, Nokias proprietry, palm, windows ce.
I used to work for IBM and work with embedded MontaVista products. Those guys simply rock... I guess Linus does not realize the full potential of what real time functionality can do to Linux :)
Linus is right not to accept this patch into the main kernel tree. What this would amount to is shoehorning Linux into a shoe it's too large to fill, and there is absolutely no reason burden all other Linux distros with this mess. Come on, MontaVista, don't try to cock things up for the rest of Linux just because you're too lazy to patch the kernel yourself.
BLING BLING. Meet the architecture that's changing everything.
Heffalumps and Woozles. Heffalumps and Woozles!
Linus' job is to say no. Here, he even gives rationale.
There are no trails. There are no trees out here.
And it's unnecessary (and wrong) in this story's title.
Knoppix 3.7 is out (kind of), a copy was distributed with the German PC-Welt magazine. It's in German but you can use lang=whatever as a boot option as normal. Has nifty new firewalling, and a 2.6.7 kernel. http://www2.hs-harz.de/~u17462/knoppix/knoppix_v37 .iso. Check out the official forums etc for confirmation of md5s etc (and remember to use testcd). Use Coral cache to avoid before that link to avoid /.ing
Gen. Melchett: Is this true, Blackadder? Did Captain Darling pooh-pooh you?
... by pooh-pooh!
Cpt. Blackadder: Well, perhaps a little.
Gen. Melchett: Well then, damn it all, how much more evidence do you need? The pooh-poohing alone is a court-martial offence!
Cpt. Blackadder: I can assure you, sir, that the pooh-poohing was purely circumstantial.
Gen. Melchett: Well, I hope so, Blackadder. You know, if there's one thing I've learned from being in the army, it's never ignore a pooh-pooh. I knew a major: got pooh-poohed; made the mistake of ignoring the pooh-pooh -- he pooh-poohed it. Fatal error, because it turned out all along that the soldier who pooh-poohed him had been pooh-poohing a lot of other officers, who pooh-poohed their pooh-poohs. In the end, we had to disband the regiment -- morale totally destroyed
Imagine what a free common system might be a better starting ground for telecom equipment -- I can see devices brought to market quicker. What does that do to people like other RTOS developers?
Zhrodague.net - I do projects and stuff too.
Is it just me, or does this article sound like it's fueling steam for a fork of Linux development? If not adding steam for a fork, I have to say it's arrogant
I believe that it's appropriate to have a fork for realtime enhancements. I remember HP's philosophy in the 80's was to have a Real Time OS and a Business OS. They have competing goals. No need to blend them and end up with a compromise!
RTLinux takes executive hold of the system and runs the Linux kernel as a mere user process.
Perhaps Linus objects to this topsy-turvey approach and would prefer Linux to be re-written so it's actually completely preemptible, capable of handling interrupts with RT guarantees all by itself, etc?
What makes you think it wouldn't just be annother kernel config parameter to most people?
Dunno if this is even slightly relavent at all but this is from one of the other people doing Prempt things with the kernel.
finally, i went for correctness primarily, not latencies. I checked
out the MontaVista patches and they categorize roughly 30 spinlocks
as the ones that are necessary to be 'raw'. Unfortunately this is
inadequate, my patch excludes 90 such locks and it's still probably
not a 100% correct conversion. The core kernel needs changes in the
locking infrastructure to get rid of most of the these 90 non-mutex
locks.
Your hair look like poop, Bob! - Wanker.
From the email threads and writeups on KernelTrap, it seems as though Linus (and his Lieutenants) have some issues with the invasiveness and maintainability of the patch, which are reasonable concerns from the maintainers.
Ingo Molnar - a RedHat employee/kernel hacker - has some patches that are similar in scope but different (and most likely preferable from a performance and maintainability viewpoint) in approach.
Read about them here and form your own opinion:
Linux: Real Time Kernel Prototype
Linux: Realtime Preemption
First we had a post on Hibernate with no explanation. Then a post on OQO and now we have one on 'Linux'. When will the madness end?!?!? ;)
When this was first mentioned I had a feeling this *patch* wasn't approved. It was spoke of as if it had all but been accepted.
I cannot wait till this functionality does finally make it into the kernel though.
with that justification, we should rip out everything which a majority of users don't use. this includes (but not limited to): i2o, arcnet, tokenring, hippi, slip, 10gbe, touchscreens, most of the "miscellaneous filesystems", voluntary kernel preemption, etc.
all this crap just shoehorns linux into a shoe it's too large to fill. no reason to burden all other linux distros with this mess.
besides, hardly anyone uses linux on embedded devices anyway. linux doesn't belong there.
Historically, Linus has never liked merging in great glops of code that touch the kernel in many places. It is disruptive to his maintenance of the kernel and it is disruptive to his lieutenants and their sub projects. The article even hinted at how Linus expects those with a major patch like this to handle things. Montavista needs to break this up into bite size chunks that can be slowly merged into the kernel and gives everybody time to get up to speed. Since it can have a major effect on how the kernel operates, it needs to at least be a compile-time option.
Linus has even told IBM "no" on occasion. Not hurrying things like this is far better for the quality of Linux than any feature a contributor may want in. Linus isn't flatly refusing Montavista. He most certainly isn't flatly refusing a major feature like hard real time. He is expecting Montavista to participate the way other developers are expected to participate. In particular, Montavista doesn't get to disrupt the work of hundreds of developers because their gargantuan patch was simply dumped in the main dev tree.
This isn't petty dictatorship. The kernel devs are a battle scarred lot who don't just chuck things in because it would be "cool".
What kind of smooth-it-over headline is this? Poo Poo? If this were Bill Gates instead of Linus, we'd say he's "blatantly ignoring", "throwing aside", "totally dismissing". But Poo Poo??
Tech, life, family, faith: Give me a visit
Everything was rather quiet in the hundred acre wood. The trees whispered to each other as the wind rustled their leaves. Under a large oak tree, there lived Pooh bear. From inside Pooh's house, there came a steady bang...bang... bang!, that was making his honey jars rattle on the sideboard. The light came through the window, and in the evening sun Pooh raised the axe once more and brought it down on the tattered remains of Christopher Robin.
"Why...won't... he...fit..." puffed Pooh to himself as the axe came down once more.
There was a small pile of earth, and a hole next to it, which Pooh had hidden with his favourite rug. Christopher Robin, selfish prat that he was, didn't quite fit in the hole Pooh had dug, so instead of making it wider he had decided to hack Christopher Robin's legs off.
"A far more sensible idea", thought Pooh, and hummed a little song to himself as he cut the last tendon and rammed the rest of the body in the hole, finally covering it up with the rug.
"Always too bossy", thought Pooh, "Always too bossy, always grabbing me by the paw and saying 'Come on Pooh lets have an adventure' or 'Pooh you are silly!' in that affected cutesy spoilt brat voice, and his stupid little shorts - bastard!"
Pooh had waited all afternoon for Christopher Robin to come round, humming a little tuneless song to himself whilst gazing blankly into the fire and fondling the oaken handle of the axe. When C.R. had finally turned up, squeaking in his child-actor voice "Come on Pooh! Open Up!", Pooh had answered the door normal as anything, talked about the weather, and then went to the cupboard and fetched the axe. While C.R. had sat there, prattling on about what a silly bear Pooh was and how he had very little brain (which wound Pooh up no end) Pooh had raised the axe high and brought it down with a satisfying thud on Christopher Robin's skull, cleaving it virtually in two, with just some muscle fibre in place to keep the pieces upright, and freezing C.R's eyes wide in horror that Pooh, lovable Pooh, could do such a thing! Pooh giggled a little and wiped some saliva from his mouth with a shaky paw. Then Pooh, calm as anything, had mopped up the blood, washed the axe and begun to dig the hole.
Piglet had wondered why Pooh had not called for him that morning, to have his tea and biscuits, and so he decided to visit Pooh instead. He admired the evening sun, blood red, and listened to the birds singing. Pooh watched him get nearer and nearer, and plugged in the drill.
Piglet had no time to realise what had happened - the drill pierced his skull, sending a beautiful fountain of blood all over Pooh's orange hide. He rubbed the blood in and all over himself, licking, licking, always licking. Then he pulled Piglet inside and put him in the cupboard. The syringe lay on the sideboard, and Pooh picked it up, paws shaking and sweating, and filled it full of solution of the funny white powder that had been given to him by a strangely spaced-out Rabbit. It was a strange effect at first, and Pooh thought he had seen many strange things, but then experienced a euphoric feeling of power. It made him irritable, and C.R. and Piglet had everything that was coming to them, no doubt at all. When night had fully fallen, Pooh dragged the bodies out and buried them in a makeshift grave.
"Adios, dear 'friends'", Pooh giggled, "Things are going to change around the 100-acre wood now I'm in charge" he laughed hysterically and went indoors.
The next day Tigger and Roo made their way happily to Pooh's house, to see if he knew where C.R. and Piglet were, as no-one had seen them since yesterday. They were sure Pooh would know, as he had had tea with Piglet yesterday and was meant to be playing Pooh-sticks with C.R. in the morning.
When they reached Pooh's house the door was wide open and Pooh was nowhere to be seen. Tigger and Roo looked inside Pooh's house and noticed a large hole in Pooh's floor and a notice was stuck on the wall with a large blob of congealing honey "OWT CHAG
Tigger said to be hopping mad in protest; Piglet leading soft-spoken sit-in. Honey at 5:00.
-Rob
Marriage doesn't have to suck!
Has anyone ever taken a look at some of the stuff available in the 2.6 configuration options? Do a 'make menuconfig' and browse through the "General Setup" and "Processor Type and Features" submenus. A bunch of it is wholly useless to 99.9% of the installations out there.
But it's there as an option, if you want it, like most everything else. Have a tulip ethernet card? Include the driver. If you don't, leave it out. Old BIOS doesn't do ACPI? Leave it out. Don't need a keyboard driver because it's an appliance system? Leave it out.
Why the hell not just include the real-time business as options? Is the maintenance really that much more challenging?
This article is not about RTLinux.
Here's something that Montavista has contributed to the Linux kernel - PRAMFS. A quote (emphasis mine):
/var/log, or a user address book in a cell phone or PDA.
Many embedded systems have a block of non-volatile RAM seperate from normal system memory, i.e. of which the kernel maintains no memory page descriptors. For such systems it would be beneficial to mount a fast read/write filesystem over this "I/O memory", for storing frequently accessed data that must survive system reboots and power cycles. An example usage might be system logs under
[...]
2. If the backing-store RAM is comparable in access speed to system memory, there's really no point in caching the file I/O data in the page cache. Better to move file data directly between the user buffers and the backing store RAM, i.e. use direct I/O.
They've described that they want to use this stuff in a cell phone or PDA, yet have described an NVRAM technology that does not exist (as fast as system memory?). Methinks that they're working with Intel on some new fangled NVRAM, (hint, look for Ovonic). Samsung appears to be working with PRAM as well.
So this MontaVista file system is a PRAM-File System, maybe...
Life is the leading cause of death in America.
I understand where Linus is coming from, he does not want complexity and intrusiveness in the kernel. He has a point there.
However, can't this be a configuration parameter defaulting to no? (REAL TIME KERNEL [n])
This way, it does not interfere with normal kernel operations, unless someone does enable it and recompiles.
Or am I missing something?
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
Much as I think Linus is often an arrogant blowhard who often goes off about things he doesn't know about (microkernels, his original views on SMP, and his theory on solaris's /dev/poll implementation just to name a few), I would have to side with Linus here. Hard realtime is a different beast than soft realtime, and even if these patches work perfectly now, Linus doesn't want to be in a position to have to ensure that some update to a SATA or network driver or whatnot causes hard realtime to break. Validating the realtime response of the system is NOT a simple task, and has to be engineered in from the start. Linus knows Linux isn't built that way, and doesn't want to set the expectation that it will.
No, this is not a troll, just checking to see if redirector abuse works.
Having smart appliances and energy controls securely networked would be a boon to Linux. The real-time kernel would allow speedy monitoring of these type of devices.
I understand that you can be a bit afraid about stability and throughput of your DB2 system, but, as many other things, these characteristics can be enabled/disabled, still disabled as default, still compiled in the main branch.
About my, probably unfortunate, sensationalistic acusation for tergiversation: Linus was not saying about a "definitive no", as the "hard real time" capability has been discused by him long time ago, simply it was not developed nor designed, just as some kind of pray, waiting for HRT to fall from the skies. If MontaVista people got it, I understand that Linus don't get in a hurry, of course! Just because hurry it is never a good consultant/counselor (Napoleon one time said to Josephine: "dress me slowly, because I'm in a hurry", or similar).
"Hard real time" possibility it's a huge step ahead, making Linux a 4x4 in computer engineering, reaching almost not only every CPU and architecture, but also every reachable problem solvable using a Linux capable CPU. It's amazing, or may be not, what do you think?
At the risk of sounding redundant, how is MontaVista's implementation significantly better or different from pre-existing real-time Linux interfaces, such as FSMLabs' RT Linux or DIAPM's RTAI?
From Series 60 Developer Platform 1.0/2.0: Basics paper:
Symbian C++ APIs enable extremely efficient multitasking and memory management. Memory-intensive operations such as context switching are minimized. Symbian OS is primarily event-driven rather than multithreaded. Multithreading is possible but is avoided because it potentially creates several kilobytes of overhead per thread. Conversely, a primarily event-driven approach doesn t need any context switching and can have an overhead as low as a few tens of bytes. Special attention has been given to designing the Symbian OS to be robust and reliable. Among the user requirements that were kept in mind when the Symbian OS was developed were that user data should never be lost and that the device should never have to be rebooted (there isn t a boot sequence when the device is turned on). This has been achieved by:
Effective memory management that prevents memory leaks Releasing resources as soon as they are no longer needed
Effective error-handling framework that handles out-of-memory errors properly
Secure data storage
Careful and device-specific power management
I know that there allready exists Linux smartphones, but how do they perform in "real life"?
As far as I know, it's not even possible to develop Symbian mobile apps on linux (lack of emulators), which is a drag, so come on, give us Linux smartphones, or Mr Symbian, release some emulators for Linux (a lá suns java-WTK) or else.....
Is a Real Time OS any relation to a Real Soon Now OS?
Or is the latter an exclusively Microsoft concept?
A couple of years ago I worked on an embedded linux project, and we used the linux real-time and pre-emptive patches on the target. We actually applied the same patched to kernel of one of the development workstations to see if we could notice any difference, and within 15-minutes of booting, those that could were recompliling freshly patched kernels. The responsiveness of the system was so much better - start-up, multi-tasking, windowing, everything.
:-)
Never looked back, especially since they made us all redundant, and closed the site...
Any fool can talk, but it takes a wise man to listen.
There's a hard, probebly irremediable fact about Real Time Operating Systems: the price for being able to [i]guarantee[/i] a specific response time is a [i]slower overall response time[/i]. "Realtime" isn't magic (though, as with all buzzwords, people tend to act like it is). It still must heed all the inherent limitations of the hardware.
Imagine that you run a pizza shop that MUST meet a certain delivery time guarantee or fail (go out of business--an RTOS MUST meet the guarantee to "be in business" at all). Before you were an RTOS, you could afford to promise pizzas in 15 minutes, with a 90%+ success rate, but if your head will roll if you fail at all, you won't advertise anything better than 30 -or even 60- minutes. I mean, what happens if a custom pizza gets ruined in the oven? You need time to make a new one.
You'll also need more hardware for the same tasks (more delivery cars), restrict services (smaller delivery area, fewer options), and institute effort-intensive safeguards to assure that no pizza order slips through the cracks. As I said: RTOS isn't magic; adding NEW performance demands won''t magically enable you to do more with less. Quite the contrary, it usually means doing less with more -- but presumably doing it better (assuming that the new requirement *is* better for your specific needs).
Would you embrace a hardware technology that slowed down your computers, and offered little or no benefit for most (or all) of the tasks you do? There are plenty of examples in he market, and we rightfully shun them as "unnecessary for us". That's the choice Linus faces: most users won't experience any benefit, so why include it in the kernel and make everyone pay the (performance and complexity) price?
I applaud the availability of a Real-Time patch or variant (I've wanted one for a long time, and I've used Wind River for those applications), but for most people or even 99% of my applications, it's pure downside, even if reworking the kernel to allow its inclusion only decreases performance or complicates programming by 1%.
Sure, in time --maybe a couple of years-- it may be streamlined until the RTOS burden is miniscule. Until then, Let the Real Time people deal with the issues and limitations inherent in their task. 99.99% of us don't need the unnecessary baggage in our OS. It'd be like mandating infan/child car seats in all cars, whether they carry kids or not.
None. Whatsoever. He's just a suit with lots of money as far as the kernel maintainers are concerned.
Linus has a far different job (he's also not a CEO so he's harder to make fun of, because he's more like us).
Also, Linus is right.
What can an RTOS do that Linux can't that wouldn't be better handled in hardware? If responding to a given event is really THAT time critical, then perhaps you shouldn't be handing the event all the way up to your systems software for a response... In my experience, most problems that people claimed demanded "real time" to solve could be more easily solved by adding more buffers.
"Freedom means freedom for everybody" -- Dick Cheney
Yes. All the other obscure things which only 0.1% of everybody uses, they are small isolated pieces of code (like some random driver). What we're talking about here is adding lots of highly non-trivial code to the core of linux (you know the kernel/ subdirectory of the kernel source) which only 0.01% of people will actually need/use. So, yes.
I also think it would be quite arrogant of the RT people to expect this to be added without serious thought (and possible reworking). (NOTE: I'm not saying they do/did expect it to, just that it would be arrogant to do so)
HAND.
It seems to me that Linus probably wants RTOS capabilities in the mainline. The issue is that most patches for it are excessively intrusive.
Some of Ingo Molnar's work is just to push down kernel latency in a general way, which is acceptable and more incremental in the mainline, while laying down an archetecture that makes it easy for a hard RT patch to be maintained, with minimal impact on the kernel.
Linux will never default to being a true RTOS across the board, forever and ever amen. So, while you're right on the money that some people hunger after RTOS when it isn't what they want, it doesn't change that some people really _do_ want RTOS in the kernel. Linus is rejecting it because of technical issues with the patch (dangerously intrusive, MontaVista can simply maintain the patch external for those who really need it, and did I mention that it's intrusive?), not because he thinks that a real time Linux is a bad idea (though it certainly is for me as a desktop user)
Here, have a cookie.
My other first post is car post.
Linus merely said "not at this time," and gave his rationale. To me, this hardly qualifies as "pooh-poohing." Therefore, I'd say the article headline is misleading, and designed merely to stir up emotions rather than foster rational dialog.
...but this IBM audio cassette I listened to said it was "the way of the future". We have to keep the future in the kernel...for the children.
"A man talking sense to himself is no madder than a man talking nonsense not to himself."
If you want hard real time and protected mode, you need an architecture like that of QNX, where almost everything runs in user space. File systems, drivers, and networking are all user programs, intercommunicating by message passing. The kernel only handles CPU dispatching, memory management, and message passsing.
In an architecture like that, everything in user space is preemptable, without any extra work in the system services. There are no long latencies in the QNX kernel; they were all taken care of years ago.
As Linus points out, though, few consumer embedded devices really need hard real time. Most media-related stuff can paper over delays with buffering. A classic comment is, "You run your web server on Linux. You run your nuclear reactor on QNX".
Automotive systems, though, really need it. QNX is big in that market.
Here is the LKML thread discussing this (including explanation of why it isnt accepted into mainline).
I swear, people who get their submissions accepted don't know how to link. Seriously, wtf is up with the first link to http://news.search.com/search?q=red+hat&search.x=0 &search.y=0?
there is not one mention of Real Time or Linus on that page. Come on, can't you learn to link to the story?
Here's how you should have linked the first line:
"Speaking with CNet via email, Linus Torvalds appears to be in no hurry to accept..."
I find it ironic that you linked "appears" in correlation to Linus to a page that had "Linus" appearing nowhere in the page.
If the patch sits around on Linus' desk for a while, then it's a good thing for MVista, since they are the ONLY people with hard real time linux.
Seems like a good selling point to me.
Want hard realtime ? - Then either pester Linus or buy MVIsta.
I know which I'd choose.
Should we be worried that Linus is apparently capable of defecating C code?
Huh? Oh.
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
Could you explain what a spinlock is? Also, what is a non-mutex lock? Please excuse my ignorance.
It is impossible to enjoy idling thoroughly unless one has plenty of work to do.
- Jerome Klapka Jerome
Speaking as someone who actually downloaded and tested these patches, I would not worry too much. This stuff is all very rough around the edges, though it has amazing potential.
If the patches were mature and worked well, and Linus rejected them, it would be news. For now he is just saying "Show me the money". Nothing new, the burden of proof is on people who introduce new features like this to prove them stable, and it just hasn't happened, yet.
mean, what happens if a custom pizza gets ruined in the oven?
Sue the oven manufacturer and issue a press release, duh!
Or, if you want a Free Software system, try the Hurd (Scheduled for completion circa 2047).
Linus has pooh-poohed other important patches in the past as well. That doesn't mean it doesn't go into the kernel, it just means that one needs to demonstrate the advantages of it to Linus and show it doesn't cause other problems.
We are currently successfully using Timesys Linux in an embedded product and are having great success (despite problems with Timesys). Realtime support is essential for telecom and networking applications. It also is quite useful for multimedia, so that video appears smooth and not jumpy. Granted, realtime is often not very useful for a general purpose computer, but in the embedded world, it is extremely useful.
-Aaron
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Yes - you would notice the difference, but I suspect that would have been due to the pre-emptive patches, not the real-time patches.
(The RT side would have been idle if it was never given a RT task to do on the dev workstations.)
FWIW, I believe preemptive is in mainline now.
I could be wrong, but from memory, only specalised software can use the RT side of things, but pre-emptive improves latency for all Linux processes.
No, it usually takes a few hours.
Not that this wasn't entirely predictable.
The other thing everyone seems to be missing:
Hard Real Time means you presumably give a damned about your system working consistently 100.00000000000000% of the time. It must NEVER break in any way.
Frankly, even if your timing routines are able to provide this real time assurances, I dont think the linux kernel itself is designed with the sort of bulletproof internals Hard Real Time implies. Linux is stable, yes, but it is not thoroughly audited enough to form the basis of a Hard Real Time system. Kernel panics DO happen, and then your hard real time timing is for naught.
There is no price to pay for running a good real-time OS in terms of efficency. There is a monetary cost (licensing fees).
.2 ms if you are running a control app that needs higher frequency. Then you have more overhead.
/net/bob/* ~"
:)
Folks who say otherwise are just quoting the silly wickipedia and have never worked with a good real time OS (like QNX - www.qnx.com).
For example, on QNX the scheduler runs every 10ms by default. You can increase the frequency, say to 1ms, or
Oh - you get to set real priorities for your processes, and scheduling disiplines per process (FIFO, RR, "fair", etc.)
There is nothing in the definition of a real-time OS that requires it to be slower or less efficient than a non-real-time OS.
QNX transfers disk data at platter speeds, and has done so forever. Network data at the rate of your network.
It is just a far superior OS than Linux, and I use both professionally and have written device drivers for both. It lacks 3rd party software and driver support - and some people won't understand why that doesn't mean it is inferior as an OS to Linux.
Want to write a device driver? In QNX just write a user mode program, use the language of your choice (C, C++). Debug it with DDD or your favorite debugger. You're not stuck in kernel mode using C like in Linux.
Want to access the serial port on another machine without writing any network code? Open "/net//dev/ttyS0" instead of "/dev/ttyS0". The OS handles it transparently for you.
Same with any file/device. Copy all the files from machine "bob" to your home directory on your machine? "cp -r
Need more processing power? Just move some of your processes to another machine, no need to rewrite your code to use a network protocol - the built in msg passing works with a global namespace and connects you to the right process on the right machine.
The GUI system is unbelievable, designed for networking from the ground up. You can move a window accross machines on the network, or have multiple people sharing the same desktop, or different portions of the same desktop, or multiple sessions (a-la traditional windowing systems). Without writing any special networking/gui code.
QNX is free for non-commercial use. Read about it. Use it. Don't be a wickipedia fool, badmouthing real-time operating systems
It's been around for 20 years. It was the best when it was multitasking on my 286 and it still is the best now on a P4/3GHz.
People throw around bloat with great abandon, and usually without any real rationale behind the term.
My OS is full-featured. Yours has feature creep. His is bloated.
This is a bummer. I work in telecom and we won't be porting our stuff to linux anytime soon if there is no support at least for a high resolution timers like Solaris' gethrtime().
And you [i]need[/i] to realize that Slashdot doesn't accept forum tags!
See subject. Problem solved. What's Linus holding out on anyway? Remember that he also was initially opposed to a pre-emptible kernel space, yet that eventually became a compile-time option too.
generally speaking linus is a fairly well rounded individual. He would include things in and not include things that have some sort of reason behind it. Its not generally a "i dont like you its not going in" thing if its better for the community.
I poo pooed some partially digested corn this morning.
Next time you design a reactor, you go ahead and do it your way.
If you were blocking sigs, you wouldn't have to read this.
Go on, Mr Don't Know The Difference Between Embedded and Realtime. List them.
If you were blocking sigs, you wouldn't have to read this.
I love how all these InstaExperts spring up on the rare occasion that Slashdot runs a tech story.
Beyond the level of a lightbulb and switch, the concept of a Real Time Operating System is spurious. Better to say Very Low Latency Operating system. There's always a delay in reacting to an input, and it's always buffered in some way. Even a lightbulb and switch buffers the signal along the length of the wire from the switch to the bulb. More complex systems, like a phone PBX that has to respond to signals coming down the wire buffers them in a DSP before actually responding to them. If the operating system (in the sense of the executable running on the CPU as we're discussing here) had to respond in 'real time' to every signal on the line or even from the DSP, then you'd be dropping calls or missing other scheduled tasks.
All OSes involve a compromise. An 'RTOS' is only more interruptable by degree than an already fairly low latency OS like Linux. Linux has some way to go yet, but it's already good enough for a lot of systems. And - gasp - even an 'RTOS' can and does miss inputs.
If you were blocking sigs, you wouldn't have to read this.
here, and I don't see where it "specifies" anything about fair use.
If you mean that making fair use of GPL'd source offers you a defence against charges of copyright infringement, you're correct, but that's not even remotely what the GPL says.
If you were blocking sigs, you wouldn't have to read this.
here. It's work in progress. The patch, as submitted, is based on the wrong tree, needed further patching even to make it work with a stock kernel, busts 4k stacks and spits error messages. The submitters make it clear that there are a lot of versions to come.
Their intentions and goals are good, but it's a long way from ready for inclusion. It's a step along the road, but they need to submit a final and fully debugged version that doesn't bork anything, and with less marketdroid spin and more comprehensive testing and performance metrics.
If you were blocking sigs, you wouldn't have to read this.
Ingo's patches have been developed out in public view with participation from many other people. Rather than just dropped as a PR bomb shell. If you think RedHat isn't a "RealTime" company TimeSys' Scott Wood has been involved as well.
i think computer is something that can do many ... if you ... ... i'm sure every os vendor / ...
different things, it's programable
want realtime smart people build a circuitry that
does nothing but that. see a switch for a light
bulb. so if you want that missile abort NOW and not
in 5 sec you BUILD curcuitry for just that, if
you're smart
of course everybody wants a responsive computer to
use, but why are we buying biger/faster computers
more ram etc.? maybe this software realtime thingy
is a bit over-hyped
creator are working hard to make their OSes
responsive / interactive.
real realtime doesn't exist! not with computers,
that operate binary-ly / serial
Can we settle on "Deterministically Low Latency OS"?
Almost. However, the initialism "DLL OS" brings to mind shared library version conflicts.
And Michael Eisner wouldn't say "Pooh Pooh" either; instead he'd say "money money".
...obvious S misses you!
Are you saying that if someone in another article said "Pooh" and meant "Poo" and people commented on it, that it would be relevant in THIS article?
NOTE TO ALL MODERATORS: I'm not necessarily talking about rarities like equating Milne's Winnie-the-Pooh to feces, no matter how many people have grown tired of watching a small child watch a Disney movie dozens of times. I'm talking about the first post/you fail it, Goatse, Tubgirl, GNAA, In Soviet Russia, In Japan, BSD is dying, Stephen King is dying, Natalie Portman, underpants gnomes style business models, and other well-understood Slashdot trolling phenomena.
What do you want, LiveJournal crap? Here's the last 24 hours of Team Overbot.
If you want that level of detail, join the team. We have papers, videos, and photos on the Overbot web site for those casually interested.Received rev. 2 front connector panel for motion controller interface board. It fits the connectors perfectly. Rechecked interface board on vehicle by jacking up the rear two axles (It's a 6x6, remember) and running the engine. Driveshaft encoder, tach, and throttle control tested and work. Ordered more boards, new optoisolator parts for boards (the old ones didn't source enough current to drive the big solid state relays) and matching front panels. We should have final interface board hardware working in a week. This will finish all chassis control gear except transmission control.
The roughness in the laser rangefinder tilt head drive turns out to be an out-of-tolerance shaft. The shaft and motor have been removed and sent out for rework.
The bogus readings from the laser rangefinder simulator turned out to be a wierd behavior in Blender. We have a workaround and have reported a collision detection bug.
Tomorrow is trash day. Empty trash.