×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linus Pooh-Pooh's Real-Time Patch

timothy posted more than 9 years ago | from the standoffish dept.

Operating Systems 262

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

262 comments

Pooh-Pooh's? (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10517278)

Who talks like that? Seriously.

Re:Pooh-Pooh's? (1)

airrage (514164) | more than 9 years ago | (#10517469)

I think it's actually POO-POOs, but who's spel checkin'.

Also, it seems to me that I saw that in a War Games once, that they wanted to get the men out of the loop and let computers start making decisions on their own. Basically, in the movie, that was a bad idea.

Peace Out.

Better link (5, Informative)

Anonymous Coward | more than 9 years ago | (#10517285)

Direct link to they story. [com.com]

Re:Better link (2, Interesting)

Anonymous Coward | more than 9 years ago | (#10517387)

And a link to the Slashdot story [slashdot.org] where we discussed the real-time patches on Saturday.

[OT] Knoppix 3.7 out (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10517390)

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 [hs-harz.de]. Check out the official forums etc for confirmation of md5s etc (and remember to use testcd). Use Coral cache [nyud.net] to avoid before that link to avoid /.ing

Anyone finding this suspicious? (2, Interesting)

swordboy (472941) | more than 9 years ago | (#10517650)

Here's something that Montavista has contributed to the Linux kernel - PRAMFS [sourceforge.net]. A quote (emphasis mine):

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 /var/log, or a user address book in a cell phone or PDA.

[...]

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, [intel.com] (hint, look for Ovonic). Samsung appears to be working with PRAM [zdnet.co.uk] as well.

So this MontaVista file system is a PRAM-File System, maybe...

Re:Anyone finding this suspicious? (4, Informative)

tchuladdiass (174342) | more than 9 years ago | (#10517872)

Actually, it does exist, sortof. If you look at how a Sharp Zaurus sl-5500 is set up, you have 64 meg of ram which is split by the kernel, part of which is used as ram and part is mapped as a block device. This second part survives system reboots and resets (but goes away once the internal battery dies).

A really much better link (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10517681)

Direct link to the story [com.com]

No, this is not a troll, just checking to see if redirector abuse works.

Wrong Link (0, Redundant)

hendridm (302246) | more than 9 years ago | (#10517290)

The 'appears' hyperlink in the summary is pointing to the wrong link. I think the author intended this article [com.com] instead.

Re:Wrong Link (0)

Anonymous Coward | more than 9 years ago | (#10517718)

I tie for first with this notificate and send a couple letters to the editor. He gets +5 Informative, I get -1 Redundant. I guess the mods don't like karma whoring. Overrated? Maybe. But why would first occurance of a comment be marked redundant?

Patents ? (2, Interesting)

Anonymous Coward | more than 9 years ago | (#10517294)

Wouldn't a real time patch violate software update patents

Re:Patents ? (2, Interesting)

ryanmfw (774163) | more than 9 years ago | (#10517344)

It's not a *real time patch*, it's a *real time* patch. It doesn't change the kernel while running, it changes the behavior of the kernel to be a real time one. I'm a little hazy on the difference, but I think it mainly has to do with scheduling, and that it will give high priority tasks all the time they need.

Re:Patents ? (3, Funny)

valkraider (611225) | more than 9 years ago | (#10517418)

and that it will give high priority tasks all the time they need.

DOS did this back in the 80's....

Re:Patents ? (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10517707)

Yes but DOS also managed to do it without annoying GUI's and interdependant libraries and drivers. I'd still be using DOS if I could get decent software for it.

Anyway WTF do we have shared libraries. It's nothing but headaches when there's version incompatibilities or trying to find a lib that a program needs to run. All it does is save a few meg of redundant code...200 Gig HDs under $100, that's not a very good reason.

Re:Patents ? (4, Informative)

tchuladdiass (174342) | more than 9 years ago | (#10517898)

Shared libraries also save ram -- multiple programs using the same shared library all point to the same copy that is in memory. Which also ends up giving a speed boost (more memory free).

Re:Patents ? (3, Interesting)

Rosco P. Coltrane (209368) | more than 9 years ago | (#10517354)

Perhaps Victor Yodaiken might want to pull another one of his lame patent stunts [linuxdevices.com] on Montavista. That'd be rather amusing actually...

Re:Patents ? (3, Informative)

pavon (30274) | more than 9 years ago | (#10517533)

Uhm, no. He has given an irrevocable, royalty-free licence [fsmlabs.com] for it's use in GPL'd software. Montavista RT Linux is GPL'd. Besides if you read the patent you will see that it is for something that has nothing to do with Montavista's code. Yodaiken's approach was to run the linux kernal as a process of a smaller realtime kernal, and it is that technique that he patented. Montavista is modifying the Linux kernal itself to be run-time, which is a much more difficult task, and would not infringe on this patent whatsoever.

Re:Patents ? (5, Informative)

d_jedi (773213) | more than 9 years ago | (#10517356)

RTFA.

A hard realtime operating system is one where calls to the operating system are guaranteed to be executed within a certain timeframe.

Story Link Wrong (-1, Redundant)

Anonymous Coward | more than 9 years ago | (#10517299)

The first link should probably go to this C|NET story [com.com], rather than some random search results.

is Linus ever in a hurry? (2, Funny)

Anonymous Coward | more than 9 years ago | (#10517301)

- i don't think so!

Might not be in a hurry.... (3, Insightful)

ryanmfw (774163) | more than 9 years ago | (#10517311)

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.

Re:Might not be in a hurry.... (5, Informative)

Elwood P Dowd (16933) | more than 9 years ago | (#10517416)

He might not be in a hurry, but I'd be surprised if he doesn't realize how this could help Linux.

I'd be shocked if he didn't realize exactly how this patch would impact Linux. From the article:
"Almost nobody wants hard real-time, even in embedded devices," Torvalds said in an e-mail interview. Adding the feature makes the operating system more complex and burdens the process of "locking," in which the operating system assures that different processes don't step on each others' toes when vying for the same resources.


Asked whether MontaVista's proposed software could be accepted into the main kernel, he said, "I personally think it's too intrusive, at least at this point," though it might be possible to merge the patch into the kernel in smaller pieces.
Iduno what else there is to discuss...

Re:Might not be in a hurry.... (0)

Anonymous Coward | more than 9 years ago | (#10517458)

Adding the feature makes the operating system more complex [..]

As if Linux wasn't one of the bloated kernels already.

Re:Might not be in a hurry.... (4, Insightful)

ajs (35943) | more than 9 years ago | (#10517586)

As if Linux wasn't one of the bloated kernels already.

People throw around bloat with great abandon, and usually without any real rationale behind the term. In this case, you have the creator and current maintainer of one of the world's most complex pieces of software which handles millions of different configurations across hundreds of devices and architectures saying, in effect, "this patch would make the kernel too complex." That speaks to me of a level of complexity which I cannot even reasonably grasp (and I can grasp a hell of a lot of complexity).

Personally, I'd love to see RT linux for real (as opposed to semi-real-time features like low-latency and preemptability), but not at the cost of the stability of the OS. Let it mature the way PCMCIA did. Linus didn't accept that right off the bat either, and we were better off for it in the long run, as I think the PCMCIA subsystem had to work hard to maitain itself coherently while not shipping with the OS, and/or not being updated regularly.

As for bloat... I've yet to see anything that is not modularly removable from the kernel which was not essential to a modern OS. There are many cases where I'd love to drop old hardware, but that's not usually realistic. There are many modules which I have no use for, but I can always turn those off. There are many features for hardware I don't use, but removing them would be unfair to people on those platforms.

What bloat did you have in mind?

Re:Might not be in a hurry.... (4, Insightful)

metlin (258108) | more than 9 years ago | (#10517496)

I'm guessing that maybe he has his own reasons that he does not want to divulge?

Especially given the current sue-happy folks who're looking at suing everything that is Open Source, maybe Linus is just playing it safe.

For all you know, he's trying to see if there are any IP violations before accepting them into the code-base. You never know.

Re:Might not be in a hurry.... (0, Troll)

Audacious (611811) | more than 9 years ago | (#10518065)

Reminds me of Bill Gates and the quip about nobody needing more than 64MB of memory. ;-)

Re:Might not be in a hurry.... (4, Insightful)

irokitt (663593) | more than 9 years ago | (#10517460)

Not stability, complexity and responsiveness. Adding real-time elements to the mainstream kernel means that priority tasks get executed first, but the average time taken to finish a task is significantly higher. The result would be an excellent system for medical equipment or ilk, but it would make a sluggish desktop or server, and most Linux devices now are desktops or servers. And the complexity of adding this in would only be justified if it benefitted a lot of people. So Linus is waiting to see how things look a little later. It should be possible to create a custom kernel that uses these features, but they don't belong in the vanilla kernel yet.

Re:Might not be in a hurry.... (5, Funny)

skraps (650379) | more than 9 years ago | (#10517563)

Maybe he's just waiting for the right time, not the earliest time.

Sooo.. Linus is real-time, but Linux is not.

(yes, my jokes are that lame.)

Re:Might not be in a hurry.... (4, Insightful)

richg74 (650636) | more than 9 years ago | (#10517602)

He might not be in a hurry, but I'd be surprised if he doesn't realize how this could help Linux.

I'd suggest the reason he is not in a hurry is that he does realize how this could help Linux, and also how it could hurt Linux. Adding real-time capability is not a free lunch.

As the original C|NET article suggests, there is a class of applications that need real-time capability (which, BTW, is mostly about being able to say that interrupt X will be handled in not more than N time units). But for most applications, real-time capability is neither needed nor really desirable: having it comes at a cost in average processing efficiency.

Incidentally, telecoms is mentioned as a possible application. I don't know enough about cellular telephony to say if it fits, and maybe there are some VoIP applications where it would make sense. But for conventional circuit-switched telecoms (e.g., a telephone switch), it really is not needed.

It is the scope and magnitude of the patch (5, Insightful)

dmaxwell (43234) | more than 9 years ago | (#10517605)

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".

Re:Might not be in a hurry.... (1)

jd (1658) | more than 9 years ago | (#10517851)

The only way it would help Linux is if it could be totally compartmentalized, such that:


  • "Regular" users could disable it in its entirity (and not be burnened by it slowing the rest of the system down) AND where...
  • "Power" users who specifically need Hard Real-Time could enable it in its entirity AND where...
  • The kernel is not so heavily bloated with the multiple ways of doing things that the kernel becomes less reliable AND where...
  • The different paths are sufficiently independent, such that if the paths are not maintaine in sync, it won't break the kernel


Frankly, I'm not certain the above is achievable for any of the real-time solutions out there. (And there are a lot.) The solutions involve way too many changes to way too many components.


Linus is open to being persuaded. Look at the DevFS idea, for example. There have been numerous occasions when Linus has been persuaded that a solution is good enough to be included. Sometimes that's been good, sometimes (as with DevFS, which now seems to be abandonware) it's not so good.


What I'd like to see is for the Real-Time OS developers to focus on making Linux much more modular, and much more reconfigurable as a live system. Why? Because then those changes which are simply too complex to ever make it into the kernel could be used in practice. Simply install them as kernel modules which can be hot-swapped with the standard scheduler, et al.


This would be good, all-round, as it would mean that there'd be less pressure to build absolutely everything into the kernel (I believe the kitchen sink patches are in the pre-release 2.6.x tree). The emphasis could then be on development, rather than politics.


It would also mean "rival" solutions could all exist. One of the things that killed FreeS/Wan was the addition of a lot of the KAME/USAGI code into the Linux kernel. Now, there's no doubt USAGI is a good system, and I hope that any outstanding parts get merged in soon. However, if the OS internels were less rigid, it wouldn't have mattered. FreeS/Wan could have been hot-swapped in to replace the USAGI components, without disturbing the kernel and without requiring highly complex patching.


Personally, though, I think the real-time work is going in the wrong direction. As I posted before, there are many patches out there. Those that cover the same ground aren't interoperable, and those that cover different ground don't cooperate.


Real-Time work is largely suffering from the Not Invented Here syndrome, with developers focussing more on what they can do in-house, rather than on what is being done by other groups. Everything is proprietary. Some groups are even distributing the bulk of their work as closed-source, with only minimal hooks and basic components as GPL.


Real-Time is an interesting goal, but if this is the best they can offer in the way of friendly, cooperative environments, I think kernel developers should put more of their time into things like the VAX architecture patches for Linux.


After all, there's probably a lot more VAXes out there that would benefit from Linux than real-time specialists who would find Linux preferable to VxWorks or some other specialized hard Real-Time OS.

Re:Might not be in a hurry.... (2)

StateOfTheUnion (762194) | more than 9 years ago | (#10517936)

I would agree . . . there are lots of applications in manufacturing that depend on realtime applications. Though safety and mission critical apps are still on more fault tolerant Sun, HP-Risc, and big IBM boxes, many of them are moving to the kludgy WinTel monopoly because of easy of maintanence and lower hardware cost. Windows has really made huge inroads on the client side of these large control systems . . . and they are slowing taking over the server side OS.

I think that Linux has a real opportunity here because the mission critical systems are almost all Unix based. It wouldn't be that big a leap to migrate to Linux; customers are already UNIX skilled. However, the Linux community seems to have done very little to convince people like Honeywell, Foxboro, Yokogawa, Fisher-Provox and ABB (The leaders in large scale manufacturing digital control systems) that Linux would be a suitable alternative in their marketplace.

Yeah right (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10517327)

Making real progress with smartphones, yep right after symbian, Nokias proprietry, palm, windows ce.

MontaVista Rocks (-1, Troll)

$criptah (467422) | more than 9 years ago | (#10517340)

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 :)

Re:MontaVista Rocks (3, Funny)

Rosco P. Coltrane (209368) | more than 9 years ago | (#10517386)

I guess Linus does not realize the full potential of what real time functionality can do to Linux.

Yes, I'm sure he has no idea...

Re:MontaVista Rocks (0)

Anonymous Coward | more than 9 years ago | (#10517417)

The OP just wanted to let everyone know that he worked for IBM (as a Janitor, dusting off MontaVista CDs, no doubt).

Re:MontaVista Rocks (3, Insightful)

d_jedi (773213) | more than 9 years ago | (#10517398)

While useful for certain applications (if I press the "abort" button on a missile, I want it processed NOW and not 5 seconds after it explodes..), I don't see what a hard realtime operating system would do for desktop systems.. then again, maybe I'm completely missing the point?

Re:MontaVista Rocks (3, Insightful)

Anonymous Coward | more than 9 years ago | (#10517481)

You are missing the point insofar that Linux doesn't aim just for the desktop and/or server market, but also, as stated above, for the embedded market where hard real time often is simply necessary. Or why else do you think OSs like QNX still exist? :)
Whether this "aim for everything"-attitude is a good one for the Linux kernel as a whole remains unquestioned for now.

Re:MontaVista Rocks (1)

tesmako (602075) | more than 9 years ago | (#10517716)

They don't let me in on the secret "Where we should aim Linux"-meetings anymore after I accidently spilled cola all over Alan Cox's beard, so I am not really up to date with the grand plan for where Linux has been decided to head.

So thanks for the inside scoop.

Re:MontaVista Rocks (1)

starm_ (573321) | more than 9 years ago | (#10517812)

Its usefull for all kinds of things. Robotics for example. Anything that has real time behaviour. Lets say you want to build your own segway that runs on Linux, you will need the motors of the segways to react immediately to inputs from sensors and user otherwise you risk crashing. I have worked on robotics projects where we where controling a robots arm with a PC. The fact that it wasn't real time was a real anoyance. We couldn't garanty that the robot would be able to hit a moving ball for example. I once wrote a program that generated music in real time from input from a sensor array. Again the fact that the PC wasn't real time was an anoyance. You could never implement a keyboard with a PC that doesn't have at least near real time characteristics. Otherwise you would get audible delays.

Re:MontaVista Rocks (4, Insightful)

Zapman (2662) | more than 9 years ago | (#10517538)

After digging around some (see the posts above), Linus seems to feel that the patches are too intrusive, which I can certainly understand. Hard Real time promises are not good in the general case, which is why most OSen don't bother. For the cases that require them, traditionally there are specialized OSen (QNX for example) that have the functionality needed. I'm not sure about this, but I believe that there are some specific hardware requirements for true RT. The scheduler is also radically different.

It would not suppise me at all if this lives a long and fruitful life outside of the standard kernel, as a stand-alone patch set. That's not even a bad place to live, especially since the requirements are rather esoteric.

Re:MontaVista Rocks (1, Funny)

Anonymous Coward | more than 9 years ago | (#10517897)

Thank you Zapman Webster!

I just wasn't aware that the plural of OS was OSen.

Linus is right. (4, Insightful)

Power Everywhere (778645) | more than 9 years ago | (#10517363)

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.

Re:Linus is right. (5, Insightful)

Rosco P. Coltrane (209368) | more than 9 years ago | (#10517451)

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.

There are many good reasons for contributors to merge their patches into the kernel. For one thing, it means you don't have to play catch-up with the kernel releases and manage the patch on top of it, and also you get to offer your code for free review and testing.

As for why Linus is always reluctant to accept new code in the kernel? simple: Firstly, if he accepted all (good or less good) ideas into the kernel, the damn thing would make coffee already, and I don't blame him to want to narrow the kernel's focus. But most importantly, just look at the size of the flippin' tarball already and you'll see why he doesn't want to include forever code that'll serve less than 0.5% of all Linux users.

Re:Linus is right. (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10517678)

There are many good reasons for contributors to merge their patches into the kernel. For one thing, it means you don't have to play catch-up with the kernel releases and manage the patch on top of it, ...
Well, it would be easy to "play catch-up", if the kernel developers would finally abandon Bitkeeper for something free, like GNU Arch [gnuarch.org].

Hmmm... (2, Insightful)

temojen (678985) | more than 9 years ago | (#10517461)

What makes you think it wouldn't just be annother kernel config parameter to most people?

Re:Hmmm... (2, Insightful)

Mysticalfruit (533341) | more than 9 years ago | (#10517939)

Because it's not.

It's not just adding support for a filesystem. It's fundimentally changing how the kernel creates and schedules userland processes and kernel threads, prioritizes I/O, allocates memory and handles interupts. This in turn has a ripple effect on how applications work.

Re:Hmmm... (1)

Coryoth (254751) | more than 9 years ago | (#10518055)

What makes you think it wouldn't just be annother kernel config parameter to most people?

From what I understand of it, the issue is that it is a big chunk of code that touches and changes the core kernel code in many many places (which naturally has a lot of flow on effects down the line). That makes it a lot harder to make it a single config switch. I understand Linux is not fundamentally opposed, just opposed to trying to merge the patch in its current form in. I series of smaller modularised patches that can be incrementally merged in (and have simple config switches added for them) is probably the way to go (and what Linus is suggesting they do).

Jedidiah.

Re:Linus is right. (3, Insightful)

johannesg (664142) | more than 9 years ago | (#10517463)

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.

Aren't they just being good citizens by offering up their patches for inclusion? You know, like that GPL thing says they should?

agree 100% (-1, Flamebait)

bani (467531) | more than 9 years ago | (#10517601)

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.

re: removing token ring (1)

ForsakenRegex (312284) | more than 9 years ago | (#10518061)

...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.

Re:Linus is right. (plz, don't tergiversate Linus) (1)

faragon (789704) | more than 9 years ago | (#10517694)

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?

Pooh != Poo (0, Redundant)

valkraider (611225) | more than 9 years ago | (#10517368)

Heffalumps and Woozles. Heffalumps and Woozles!

Re:Pooh != Poo (0, Offtopic)

genner (694963) | more than 9 years ago | (#10517548)

Glad you posted. I was confused for while.
+1 sad.
This is actualy true, don't modas funny please.

Pooh goes apeshit by A.A. Milne (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10517615)

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 CHAGIG THE DRAGGN" (spelling had never been one of Pooh's strong points).

"That's odd", though Tigger, "there are no dragons in the 100-acre wood only heffalumps. What is that silly bear up to now?"

Not even Tigger would have imagined what Pooh was up to at that moment. That morning Pooh had woken with a splitting headache and a rather snotty nose. So he had taken a large dose of the white powder and a little while later had a brilliant idea! He left the house with a container marked insecticide in big red letters. He took the container and went to Eeyore's favourite patch of thistles.

"This will serve that manic depressive donkey right" laughed Pooh aloud, "always cheating at Pooh-sticks, cheats never prosper", Pooh said to himself.

Then he hid behind a tree to watch the unsuspecting Eeyore eat himself to death - sheer poetic justice thought Pooh as he dumped the nearly dead body of Eeyore in the same grave as C.R. and Piglet.

"Shouldn't cheat should you?", shouted Pooh as Eeyore's eyes stared with disbelief. "You're lucky I didn't chop you up into little bits and feed you to Tigger!", laughed Pooh manically, before he covered the makeshift grave over.

Pooh didn't return to the house until dinner time as he was totally spaced out all morning. So when he returned to his house he was in an awful mood and all he needed to make him absolutely mad was the sight of Tigger and Roo bouncing up and down outside his house singing "bouncy, bouncy, fun, fun, fun, fun, fun, the wonderful....".

"'Wonderful'?", thought Pooh aloud, "My foot, you'd think the writer of this shitty story could think up better lyrics for a song than that, and to think, they released the sound-track album on cassette and CD; a lot of people are going to get ripped off." This lightened Pooh's mood somewhat, but the respite was brief.

"What was that you said?", asked Roo.

"God does he never stop asking pathetic questions?", Pooh thought furiously. "I'm going to have to deal with these prats as well. Is there no-one in this place with intelligence apart from me?" Pooh asked despairingly."

Pooh felt himself extremely lucky as Roo had to go home for his afternoon sleep and that left Tigger at his mercy. Even better, Tigger suggested that himself and Pooh go and play Pooh-sticks; Pooh had smiled slyly as an idea formed in his overactive brain, and agreed.

"What an opportunity", Pooh whispered to himself as he followed the innocent Tigger to the bridge.

Once on the bridge, and the rather pointless game of Pooh-sticks was under way, Pooh thought he'd much rather push his stick up Tigger's arse, rather than throwing it into the stream. Tigger was leaning over the side of the bridge looking for his stick. So he did not see Pooh's wide horrific grin as he outstretched his arms and moved toward Tigger with the intent of pushing the stupid cat into the stream.

"Cats hate water, tee hee, he'll drown."

There was a loud splash as Tigger hit the water and started to struggle as his head was covered by water, he gulped and choked. Pooh was holding on to the rail of the bridge and jumping up and down with excitement and was joyously shouting at the drowning Tigger.

"Why?", spluttered Tigger as he slowly started to turn blue with the cold, which Pooh found hysterical, after all a blue Tigger? How absolutely silly.

"I'll tell you why you bastard", screamed Pooh, "It serves you right, hiding behind doors and jumping out, and scaring the shit out of people." Tigger did not hear Pooh's answer as he was already floating downstream face down in the water, dead. "Good riddance", laughed Pooh, and looked at his watch. "Still time to get that little dick-head Roo before he wakes up."

Pooh sneaked to the sleeping form of Roo's mum and saw Roo's ear poking out of her pouch.

"Now I've got you, you little git", Pooh thought, smiling, as he threaded a needle with extra strong cotton. He was jolly grateful for Piglet's sewing lessons now, because he would be able to sew up Roo nice and tightly, so he would not be able to get out and his mum would not be able to rescue him. So very slowly and carefully Pooh began to sew Roo into his pouch and thereby suffocating the annoying idiotic twit. After the deed was done Pooh made his way back to his house wondering how Roo's mum would take the death of Roo. Badly, hoped Pooh, as he began to cough uncontrollably and felt general nausea overcome him.

By the time Pooh got home he had puked up several times and was very desperate for some more of the white solution. He trembled as he picked up the syringe and gave himself the remaining amount. An awfully large amount, one might say, for a small little bear like Pooh. In fact too much, Pooh died of an overdose, but he died with a smile on his face: he was dreaming that he was the only teddy bear made with a willy and dreamed how he surprised Eeyore one day - but that's a story for another day.

The apostrophe is your friend (0)

Anonymous Coward | more than 9 years ago | (#10517389)

And it's unnecessary (and wrong) in this story's title.

Blackadder quote (Sorry, I couldn't resist) (4, Funny)

lxs (131946) | more than 9 years ago | (#10517409)

Gen. Melchett: Is this true, Blackadder? Did Captain Darling pooh-pooh you?

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 ... by pooh-pooh!

Linus "appears to be in no hurry to accept" (4, Insightful)

chance2105 (678081) | more than 9 years ago | (#10517428)



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 ...

Re:Linus "appears to be in no hurry to accept" (0)

Anonymous Coward | more than 9 years ago | (#10517621)

Sounds to me like the fork has already happened. The only thing Linus can do is unfork it.

Re:Linus "appears to be in no hurry to accept" (5, Insightful)

augustz (18082) | more than 9 years ago | (#10517663)

The article and reporters may enjoy "fueling steam", they tend to enjoy stiring up controversy.

Linus saying it looks too invasive at the moment for him to roll-in without other testing? NO ONE is going to fault him for that. Linux has gotten where it is because people can actually use it, in contrast to plenty of other experimental efforts.

No one is going to think he is arrogant for doing his jobs. These patches can work their way into some feeder kernels first, and the usual cycle can work itself out.

Too many uninformed folks like to say, "Fork!" or "Arrrogant!" without ever having actually maintained any type of code base.

What the dear poster probably doesn't realize is that there are ALREADY real time Linux kernel varients in use out there, moving stuff mainline is hardly a fork, if anything montevista is trying to get out of the separate kernel maintenance business.

Am I missing something obviou here?

Real Time enhancements as a fork (5, Insightful)

Anonymous Coward | more than 9 years ago | (#10517443)

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!

Re:Real Time enhancements as a fork (1)

ArsonSmith (13997) | more than 9 years ago | (#10517773)

Simple fix:

[ ] Real time scheduler
[x] regular schedular (suggested for desktops and servers)

Probably because it's not "integrated" enough? (2, Insightful)

Anonymous Coward | more than 9 years ago | (#10517445)

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?

Wrong, not insightful (0)

Anonymous Coward | more than 9 years ago | (#10517635)

This article is not about RTLinux.

From LKML (3, Informative)

OverlordQ (264228) | more than 9 years ago | (#10517477)

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.

Links to better KernelTrap articles/email threads (4, Informative)

dominator (61418) | more than 9 years ago | (#10517544)

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 [kerneltrap.org]

Linux: Realtime Preemption [kerneltrap.org]

Another unexplained submission? (3, Funny)

retinaburn (218226) | more than 9 years ago | (#10517553)

First we had a post on Hibernate [slashdot.org] with no explanation. Then a post on OQO [slashdot.org] and now we have one on 'Linux'. When will the madness end?!?!? ;)

Re:Another unexplained submission? (0)

Anonymous Coward | more than 9 years ago | (#10517669)

They expect you to follow a link to the project page to get an explanation of what the hell they're talking about. That's much too hard to do, unfortunately!

Re:Another unexplained submission? (1)

Ziviyr (95582) | more than 9 years ago | (#10517763)

I'd complain more about "Parrot" than "Linux", also, there are comments here pertaining to "Windows".

Really, do I look like a fecking dictionary?
Someone explain all this stuff!

I had a feeling about this (1)

C_Kode (102755) | more than 9 years ago | (#10517556)

When this was first [slashdot.org] 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.

Poo Poos? (5, Funny)

Swamii (594522) | more than 9 years ago | (#10517611)

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??

Re:Poo Poos? (1)

Ziviyr (95582) | more than 9 years ago | (#10517711)

Its the kind of smooth it over headline about a penguin fanatic who shrugged off putting something in his branch of a free, open, and readily forkable bit of software.

Billy G isn't doing Windows for the kudos of it, hes making money and stimulating an economy of babysitting a broken closed and not readily fork and fixable bit of software. And he has enough money that he can prolly buy you off if you dare suggest he Poo Poos anything.

All things being equal, this wouldn't be noteworthy.

Apples to Oranges (0)

Anonymous Coward | more than 9 years ago | (#10517857)

How much control does Bill Gates have over the NT kernel?

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.

There are TONS of non-mainstream things there (2, Interesting)

MoralHazard (447833) | more than 9 years ago | (#10517631)

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?

Answer: (4, Informative)

warrax_666 (144623) | more than 9 years ago | (#10517945)

Is the maintenance really that much more challenging?

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)

Can this be a config parameter? (-1, Redundant)

kbahey (102895) | more than 9 years ago | (#10517652)

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?

Re:Can this be a config parameter? (2, Interesting)

ceswiedler (165311) | more than 9 years ago | (#10517980)

The existence of the code in the main kernel, regardless of whether it is enabled at compile time, affects everybody. It's not like you're going to have a single place with

#ifdef REAL_TIME_KERNEL

...lots of code

#endif

It's going to change a lot of things in a lot of places. Ideally, it will make infrastructure changes which benefit everyone, by abstracting certain elements of the code, which then makes its own specific features fit in nicely. Unfortunately, this is very difficult to do with real-time scheduling.

good for linus (1, Insightful)

Anonymous Coward | more than 9 years ago | (#10517656)

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.

Real time Linux could win the house. (2, Informative)

grunt107 (739510) | more than 9 years ago | (#10517691)

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.

Alternatives? (3, Interesting)

Tellalian (451548) | more than 9 years ago | (#10517723)

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 [fsmlabs.com] or DIAPM's RTAI [rtai.org]?

Smartphones?? (1)

flibberdi (800264) | more than 9 years ago | (#10517757)

"Linux is already making progress in smartphones."

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.....

Real Time OS (1)

michaeldot (751590) | more than 9 years ago | (#10517761)

Is a Real Time OS any relation to a Real Soon Now OS?

Or is the latter an exclusively Microsoft concept?

It is not only embedded systems that will benefit (1)

AccUser (191555) | more than 9 years ago | (#10517792)

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... :-)

The rah-rah supporters are missing the real issue (5, Insightful)

The_Laughing_God (253693) | more than 9 years ago | (#10517803)

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.

Re:The rah-rah supporters are missing the real iss (1)

erikharrison (633719) | more than 9 years ago | (#10517987)

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)

What is it needed for? (2, Interesting)

El (94934) | more than 9 years ago | (#10517920)

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.

I would hardly call this "pooh-poohing." (4, Insightful)

ZuperDee (161571) | more than 9 years ago | (#10518007)

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.

Re:I would hardly call this "pooh-poohing." (1)

genner (694963) | more than 9 years ago | (#10518032)

Your new here aren't you?
Welcome to slashdot, we don't do "rational dialogs"
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...