Slashdot Mirror
MontaVista Rolls Out Fully Preemptable Linux
A couple people wrote with a link to an article about MontaVista. They've introduced "a fully preempetable Linux". It's based on kernel 2.4, but the timing is interesting, considering 2.4 isn't completed yet - and if this had come out earlier, perhaps some of this could have been included. The article's a bit press releasely, but has some good info.
I am currently a user of QNX OS and it's preemptive real-time capabilities are absolutely astonishing. For the sake of Linux I would hope that this company holds off on production of its distribution until the kernel is at least stable, if not fully released. If a big "oops" is made too early in the game, many people or just going to stay with their OS of choice, which isn't at the time most likely Linux, because having confidence in what OS you stick on your real-time hardware is no laughing matter at all.
This article points out an area in which Linux has one major weakness over traditionally developed operating systems such as Windows, Solaris or even BeOS, and that is that essentially one man has control over the entire operating system, and it is his somewhat capricious wishes that govern the addition of new features and the acceptance of patches.
Whilst I'm sure Linus Torvaldes is a competent, possibly even brilliant programmer, his quirks make the entire project too reliant upon him - his disdain for CVS springs to mind as an important example. Were he to be hit by a bus tomorrow then development would be stunted as people like Alan and Inigo fight over the "hot seat", and the open source movement would fail without Linux.
What Linux needs is to be incorporated under law as a non-profit organisation which can then be run by Linus at CEO/CTO. This way they can implement a professional approach to things like source code control, copyright and trademark infringements, and reviewing new proposals for the kernel, like the one rejected by Linus for specific preemption points.
Unless this happens, the Linux operating system is left vulnerable, and if its creator should leave for any reason, its progress would most likely shudder to a halt.
---
Jon E. Erikson
Jon Erikson, IT guru
This was discussed on the kernel mailing list a few months ago (before MontaVista did their implementation of it) and it seems likely that a preemptable kernel will be available (or the default) in Linux 2.5 for _uniprocessor_ systems .
The problem, though, is that the approach taken doesn't work on multi-CPU systems. The overhead of synchronization between CPUs is prohibitive when doing preemption in the manner that MontaVista describes.
2.5 is the next -DEVELOPMENTAL- version of the kernel. They'd like to see it as the base for new development. Good lord, people...
This show the power of open source. These guys proposal was regeted so they decided to add in themselves. If they improvments are good enough it will be incorparted in the next version of linux. Got to love it.
Somebody has to be first.
In Antartica, when the penguins are ready for a swim to go get some yummy fishies, they all cluster around the edge of the ice. No penguin wants to be the first one in, because there might be penguin-eating seals in the water. If only some brave penguin would jump in first, then they could watch to see if he suddenly turns into a bloody chunky cloud in the water.
I guess Montavista is one of the brave penguins.
Basing their code on 2.2 would mean it was outdated before it was of any use - afaik 2.4 has big extra support for SMP, which is essential for their pre-emptive solution.
It's not as though 2.4's contents are unknown, they have probably been working with 2.3 builds all the way through. they mention they have been in contact with linus torvalds, i'm sure that for something this big he would have provided them with as much information about 2.4 as soon as possible.
Integration into 2.5 makes sense, not 2.6, so this can be tested and refined within the full linux kernel development environment, and then subsequently released into 2.6 as part of the full stable kernel.
i really look forward to this, this is _good_ corporate involvement with useful goals.
fross
> Can someone explain what difficulties these people at MontaVista must have overcome? What is
> it about the linux we know that makes it not fully preemptable?
Current Linux only switches processes when the kernel explicitly decides to. (in other words, when a system call finishes all its work, or when a system call decides that work will take so long that it is time to give another process a chance to run)
This patch makes Linux able to switch between processes every time that an interrupt hits, even if it is in the middle of a system call.
The trick is to avoid deadlocks. Consider the following case: process A enters a system call, and the system call takes a lock. Then, an interrupt hits and process B is scheduled, preempting A. Now B does a different system call. This call disables interrupts and tries to take the same lock. It can't get it, though, because process A already has it. But since interrupts are disabled, process A will never get a chance to run again.
Your machine hangs hard.
The solution to this problem chosen by MontaVista is to simply disable all preemption whenever _any_ lock is taken by the kernel. The disadvantage to this approach is that:
- even when it is not possible for a set of locks to conflict, preemption will still be disabled.
- all locks become slightly slower (because every lock operation must now disable preemption too)
I know what preempting is, but I don't understand what makes something "fully preemptive". Why is "fully preemptive" better than, er, I guess, "partially preemptive", and what do these terms mean? Anyone care to elaborate? What will be gained by making the kernel "fully preemptive", and what state is the kernel in now that keeps it from being "fully preemptive"?
Well I can't claim to be an expert kernel hacker, but I have had to use Linux for what was essentially real time interactivity, relying on controlled conditions to provide me with CLOSE ENOUGH. The fact that Linux IS reliable and predictable and has been for some time, has allowed alot of folks to use it as if it was a fully multitasking system, and in many ways that sort of quality of service (having programs not freeze because of other programs) is what I think
drew me to Linux in the first place.
For a time I explored BeOS and the BeBox in particular, but the slowness of that development and the abandonment of the hardware left me cold. Still it had some interesting ability that other OS's don't have involving streaming media, and anything that brings such things (Rendering in a window continuing smoothly while window was being dragged as one example) is a good thing for the user community as well as for the embedded.
While people DO seem to throw alot of hardware at problems to make operations smooth, with my Athlon 500 and 256 ram I cannot run an IE 5 session without getting skips out of winamp. This sort of performance depresses me so much I have already begun to switch over to Linux on the machine for normal use, despite it being purchased for windows development (necessary evil).
I don't know how long it will take to get this sort of performance up, and I know that the danger of RTOS functions is that a badly programmed high priority thread can cause havoc, but if there were proper guards against such things, it would probably be enough to make Linux my OS of choice for interactive exhibits (which it is close to being as it stands).
As to why we are already talking about 2.4, what I really want to know is why 2.5 is meaningful, when it is an unstable track and thus unlikely to be seen until 2.6 in most desktops. What does this mean? If we are talking about something that is done now that is not going to be in a stable release for another year, but with 10 and 100 fold improvements, does that mean we are going to have to start supporting development kernel releases for clients because the feature set is too important to miss? It hasn't been the case for me since 1.3.. I really DON'T want to be doing kernel catchup in the modern era.
If this is important technology, then why can't we postpone 2.4 a little and move it in?
What kinds of schedules are we really talking about?
Is 2.4 expected this week? Is this RT stuff expected this year?
Unlike with Windows and Mac, I don't think that many people are sitting on the edge of their seat waiting for 2.4. I don't think it is keeping folks from choosing Linux. I am not sure I can understand the purpose of rushing forward if there is good technology that can become PART of the mainstream kernel without causing radical change in usage.
Or is this not so important after all?
Ingo did a preliminary patch for this a while ago, as part of his low-latency work. It appears that MontaVista has picked up the ball and run with it. Integrating a patch like this is going to require a lot of QA, so it should go in early in the 2.5 cycle -- this is definitely not something that one throws in at the last minute.
:-/ Anybody have a good reference to lockless data structure, algorithm, and design techniques?
It will be interesting to see how much the preemption infrastructure impacts performance (throughput) on a uniprocessor.
On a perhaps related note, I've been thinking about the growth of locks in the kernel. Many of these will have little contention, and locking is a pessimistic approach that incurs overhead. Plus, more locks means more locking discipline required.
Nothing has been "rolled out". This is not a product launch. This is the prototype release of preliminary code for a development kernel. The 2.4.x series isn't here yet, and neither is MontaVista's code.
Read the article, as there are several paragraphs in there talking about where this code will be going. They're hoping to get it incorporated into 2.5.x NOT 2.4.x.
Francis Hwang
Do domain names matter?
Well, 2.4 is pretty stable, and even if it does go weird I still have a 2.2 one in lilo to drop back to, it doesn't do any harm to try it...
~ppppppppö
> At the very least, the final say on all things
..fork the code, but this wouldn't be of
..
> to do with the kernel should be handed to Alan
> Cox,
Hmm. a few things spring to mind..
Don't you think Alan should have some say in what "should be handed to" him? The last I heard, he wasn't terribly happy that he was even seen as second in command, never mind first.
You don't think Linus should be in charge, but what makes you think others would be happy if someone else were?
The only reason Linus is still in charge is because he is bloody good at his job. Do you really believe Linux would have got this far if he weren't?
>
> benefit to the vast majority of Linux users
It would if it was better. Do you really think anyone would hold back on forking the code if they thought they could do a better job than Linus? I know I wouldn't
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
I like the sound of it.
:)
While I generally prefer FreeBSD, one of the reasons is exactly the desktop responsiveness spoken of. On the same machine, I find FreeBSD far more repsonsive than Linux when using X under load. On Linux, I can feel the lag in system response at a load of about 3--even though that load is from doubly niced makes and there's plenty of physical memory left. Under FreeBSD, I've gotten to loads of 10 without any noticable degradation in response.
NOw if anyone can find a way to quantify this . . .
As a rule, I avoid the comments on moderation. However, this morning I"ve noticed a cross a few threads that it seems to be a bad crack day. A couple of troll/flamebaits here, a couple more elsewhere.
Seems a couple of folks who drew moderation today took the "I am your God" comment a bit too literally, and must smite all unbelievers . . .
and push a penguin :)
Of course, the penguin that gets pushed gets the best herring.
Then again, the second mouse gets the cheese . . .
which reminds me, I better go check the traps in the attic. I could have four-day dead mice by now . . .
It is fairly stable now, true. And it doesn't do any harm to try.
Oh, except when it randomizes your hard drive and suddenly all your data gets eaten because of the truncate() bugs. But apart from that, its okay to try.
Ah, theres also the random oopses. Thats the other thing I forgot, Apart from the truncate() bugs and random oopses, its okay to try.
Whoops, I forgot the memory leaks. you have to reboot quite a lot 'cos of the memory leaks. But... apart from the truncate() bugs, the random oopses, the memory leaks its okay to try.
Eek. theres the memory corruption. It scribbles on your memory. If you can put up with truncate() bugs, random oopses, memory leaks and random corruption then it's definitely stable.
Seriously folks, get linux2.4.0test8-pre6 and test it as much as you can and submit ____proper____ bug reports of any problems. But I would _not_ reccomend using it near "real" data yet - even if you do have 2.2 to srop back to like the previous poster does. remember: fsck is not magic.
(BTW, the truncate() bug is fixed now AFAIK and I made most of the other stuff up for a laugh.)
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
MontaVista, recall, is an embedded linux company. Since embedded systems don't need SMP, that's not where their focus is. It'll be interesting to see if they try to add support and what actually gets into the official kernel.
Btw, I happen to work at MontaVista Software (not their main office right now, which is why I'm kinda' out of the loop and don't have more to say about this), and can attest that they're really cool folks! <grin>.
...even most people who think they do.
With CPU speeds being what they are today (and constantly increasing), the number of cases in which the regular schedular can't handle things correctly is really very low.
On the other hand, some of the improvements done for RT purposes (eg. finer-grained locking) help other people too (eg. SMP users).
Uh, the development kernel set's numbered 2.5 (which would be the next "unstable" version of the kernel).
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
The rep Ready Systems had some years ago with people buying real time systems is that if it visibly works in the demo, it will probably work in the product you buy. If the salesdroid talks about it working, it won't. Perhaps that's just in the Southeast US, but their reputation where I work was far from enviable.
In VxWorks one of the things we learned to do early was get the hell out of interrupt level as quick as you could. The driver I ported to VxWorks for an FDDI board, for example, basically shuffled stuff onto a ring buffer that fed the process (at high priority task level) that did the actual work. That's because interrupt level was honest-to-god interrupt level.
Please forgive my ignorance here, but is that the way people are writing Linux drivers? If not, then you're going to have a massive job of driver rewriting before preemption is actually usable for (e.g.,) cyclic schedulers like we use in training simulators and some kinds of hardware-in-the-loop simulations.
Simply turning off preemption every time a process or a driver takes a lock is a far, far cry from usable preemptive scheduling. If I need a 60 Hz scheduling event, then I bloody well need it at 60 Hz, and a pause for a few dozen milliseconds for a filesystem sync (etc., etc.) is right out.
And there was a need for a number of parallel utilities in VxWorks. For example, printf() takes a semaphore, so it's unusable at interrupt level and you have to use another function to print things out at interrupt level. Note the way VxWorks did it: it doesn't let you take a semaphore at interrupt level, which is just the opposite of what Ready is suggesting. Why? Because they believe real-time is important, and it's at the core of the philosophy behind the operating system, not an add-on.
Unless I've badly misunderstood this, it looks like preemption in Linux is going to be a toy.
Anyway, Linux only has a few years of development left. The system we run 10 years from now will be Free Software and will contain a lot of the same tools, but might well have a different kernel. I'm surprised that people don't consider this more.
Thanks
Bruce
Bruce Perens.
RMS's loss would cut the heart out of the free software movement
HAHAHAHAHA!
I'm not even convinced he played a significant role in any major trend except promoting the TLAs: FSF, GNU, GPL, and RMS. That, and injecting a lot of moralistic nonsense into what are essentially economic and engineering issues.
Free software is not like free speech. It is like public domain text: nice to have, but not a fundamental property of a free society. Going around convincing people that it is essential is harmful both to them and to the people who have rational reasons for releasing free software.
If he was never born, the major difference would be that Emacs wouldn't be around. If he died today, nothing would really change. He hasn't really done anything significant in a long time, he just goes around as a figurehead of the "free software movement" who is hated by half of the people involved in free software.
--------
This was in kernel traffic either last week or the week before. I think that it was not added cause it was either alot of changes or it was messy code. I think also that Linus has his wants and not wants in the kernel.
I wonder if this is the start of the forking of Linux that so many have said woudl happen. May the best kernle win.
I also wonder if they are releasing there changes to the kernle as Open Source under the GPL? ;-)
~~~~~~~~~~~~~~~~~~~~
I don't want a lot, I just want it all
Flame away, I have a hose!
Only 'flamers' flame!
The simple way to get an idea of the difference is this:
;-), and hats off for the developers!
- Linux does fully preemptive multitasking, which means that CPU time is shared by multiple processes, that each process gets his part, and that if some process waits (e.g. for I/O), his "part" will be used to run other processes in. So all in all, this is a fine "time-sharing system".
- The kernel however, doesn't do this internally (yet!). If you do a kernel call, e.g. write to a device, the kernel call is the _only_ thing that runs at that moment. If it has to wait for something, it just _waits_. Only after the call has returned, Linux starts looking at the scheduling system again.
A fully preemptive kernel means (anyway in this context), that it is also preemptive internally, so if kernel code has to wait for something, other tasks can be performed. As you might understand, a fully preemptive kernel must be _very_ sophisticated. I'm glad we're gonna get it (well, if Linus permits it, anyway
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
The SMP support already allows multiple processors to execute much of the kernel code already, except within locks. In principle, any code that is not in a lock and runs on SMP can be made preemptible on a single processor. So this is not a hugely revolutionary step, but rather evolutionary.
I'm glad that someone is taking the effort to actually do this.
Molog
So Linus, what are we doing tonight?
So Linus, what are we going to do tonight?
The same thing we do every night Tux. Try to take over the world!
I havn't been following the kernel very closely recently, but Mandrake 7.2 beta is just out and includes the 2.4.0-test? kernel, so it's got to be reasonably stable!
Did you know that Linus owns the name Linux? He could simply not allow anyone to use the name. The software wouldn't change but it would no longer be buzzword compliant. Not that he would do that of course....
I'm using 2.2, and noticed the same thing with 2.4.
.)
:)
It's stock debian potato with proposed-upgrades and security, except for the cvs version of lyx.
I'm not using KDE; plain old X is fine for me. I need to see how long it will take to get my new machine once ordered; I don't want to spend too much time on this one. However, if 2.4 will work better with my eepro network card . . . I have to have a script force-reloading the netwrokd with five second pauses, and I still need to power down to completely reset the card once a day (warm boot doesn't do it).
The card stayed up under FreeBSD, but I don't have the disk space for the compiles (make world and make lyx together take more space than I have . .
hmm, now that I think of it, I used to run X at a -2 nice on macbsd to solve some of these (and xfs at +2 or some such
remember: fsck is not magic.
:(
Depends on your technique.
Oh wait, that wasn't a euphamism, nevermind
Fist Prost
"We're talking about a planet of helpdesks."
-Jaron Lanier
... out of seeing the handful of posts NIT-PICKING the numeric versioning system thing.
And, since I haven't posted here for awhile, and so dislike people who nit-pick an issue simply to look intelligent, allow me to take the very same sentance and explain it to you:
"MontaVista would like to see this technology, or similar technology, utilized as a foundational feature of Linux 2.5,"
"... this technology, or similar technology", referring to the preemptive structure changes and coding they have been working on. Very cool, and I think everyone can follow it this far.
"... utilized as a foundational feature", meaning they would like to see these largish to major changes made early on, either all theirs, part theirs, worked on by them, others, or a better way, whatever works out to be the Best Thing for Linux. Again, seems fairly clear to me.
"... of Linux 2.5", meaning they would like to see it begin incorporation in Linux 2.5. This seems proper to me.
As I see it, it was stated correctly, a new, and fundamentally large change such as this would be inculded in a DEVELOPMENT kernel. Hence, the term DEVELOPMENT.
A large change like this would NOT get directly incorporated into a STABLE kernel series.
You're beef seems to be more of a grammatical one than anything else. Would Montavista stating it this way have satisfied you - "MontaVista would like to see this technology, or similar technology, utilized as a foundational feature at the beginning of Linux 2.5,"? Probably not.
Long ago, I read the explanation of the versioning system being used in Linux, and understood it. And ever since, I've gotten a chuckle out of anal-retentive grammatical nazi Slashdotters like yourself who feel the need to try and show the world that they know it too.
Get over it.
And now that I'm guilty of doing the exact same thing I so dislike here, I'm moving on before I end up conditioning myself to be guilty of it more often.
I see you've tried 2.4.. on what hardware setup? 2.4.0-test6 on my K6-III 400 w/ 128 mb of ram produces a very noticeably different behaviour under load (as compared to 2.2.16 and 2.2.17).
:)
For me, the difference was that make -j 27 (which help get a ludicrous load) didn't destroy interactiveness. I was able to type, etc, as if nothing else was happening on the system. This partially has to do with the atomic timeslice going from 200ms to 50ms, and partially from the general updates to 2.4. If you've not tried -test6, I suggest you do
--
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
So - if MontaVista's kernel is fully preemptive it should be interruptible at any time. This means that there are no times when you can't serve an interrupt, or am I wrong?
It's not interruptible when interrupts are disabled. So interrupts are disabled to protect critical regions in this type of kernel.
"Fully preemptible" means always preemptible by default, except when it isn't. The alternative is non-preemptible by default, except at certain well-defined preemption points. There have been some kernel patches proposed that add more preemption points, but I believe that a fully preemptible kernel is cleaner, more maintainable and higher-performance, when it's done correctly. SGI's IRIX works this way, for example.
The hard realtime patch (which this isn't), last I checked, requires you to have a specific high priority to be able to change the scheduling mode. So you need to have root permissions when you set up your scheduler, or have someone (some daemon?) who has such permissions renice you. Normal users can't use it, so it's not a security risk.
I'll try to answer/respond to the most significant questions and points made here. 1. 2.5 is the next "development kernel", and is clearly the right place to initiate a fundamental kernel change such as preemptability. 2.6 is the right place for commercial usage, obviously. 2. Preemptibility means the systems can and will stop a process running in kernel mode and switch to a higher priority newly executable process. For more, including specifics of what our prototype does and how we want to advance it...read our white paper! Here isn't the place to repeat those details. 3. We are not dogs, but after a few beers or missed shots on the pool table we do howl alot. 4. We actually did initial work on 2.2.14 but our primary goal is proving out this technology, providing to customers who may need it, and offering back as a technology for 2.5 (->2.6). Hence, 2.4 was and is the proper base, given that we think we can have production ready software early next year, "long after" 2.4 is cooked. We feel releasing a prototype on 2.4-test software is okay. 5. A preemptable kernel is not a rate monotonic scheduler! We also offer a scheduler that sits on top of (runs before) the standard Linux scheduler that does a good job of selecting/dispatching real-time processes very quickly and with fixed overhead. It's not rate monotonic, it's a simple priority driven scheduler. 6. I won't engage in arguing the pro's and con's of "one man's control of an OS". It is the way it is. MontaVista lives with it and is trying to work with it. We think a preemptible kernel design, leveraging the SMP locks, is a good next step for the Linux kernel and benefits all "market segments" (types of users). We want to prove it with real software, and this is our starting point. We are "releasing early, releasing often", amen. 7. "these guys proposal was regeted"...I reget to tell you that you misunderstand. What was "rejected" was a set of patches that injected preemption points, which is a fundamentally different technology than what we've implemented. We have not proposed or submitted anything as of yet, beyond making our current prototype available. 8. Fross, THANK YOU. 9. Inclusion in 2.4 is absurd, it's time for it to stabilize, finalize and start getting deployed. 10. Most of the systems that Hard Hat Linux get designed into aren't serving "multiple users". They are control oriented environments. In such environments, having a design ability to assure that high priority tasks get cycles very quickly, with assurance, and all the cycles they want until they are "done", is critical. We are trying to enable that capability. Superuser privileges usually protect real-time priorities from casual mis-use on multi-user systems. 11. RTAI and RTLinux are "sub-kernels" which provide a lower level multi-tasking environment, a small set of services (mostly around synchronization and passing data to/from higher level Linux processes), and which virtualize interrupt off/on operations in Linux. Basically, they provide a multi-threaded interrupt handling environment with better worst case interrupt off characteristics. There are limitations to such an environment. A preemptible Linux kernel attempts to improve PROCESS responsiveness in Linux proper (as opposed to attached a small underlying, separate multi-tasking environment). They are quite different. They are not in conflict, and even with excellent preemption performance, a system can still benefit from improved interrupt responsiveness via use of RTLinux. 12. MontaVista did not request/support the request for preemption point inclusion in Linux. The perspective of our real-time team is that preemption points are NOT a desirable long-term technology, and we don't support their inclusion in Linus's kernel. 13. Everything MontaVista develops on our own dime is released as GPL or LGPL software. Everything to date anyway, and we don't see that changing anytime soon. Even most of what we've been paid to develop user professional services has been GPL/LGPL licensed (with our customers approval of course), as it's turned out. We are dedicated to the values of open source. We're a Linux company for gosh sakes! 14. Minimizing throughput impact on a uniprocessor is important. There are opportunities for throughput improvement under busy workloads...very simple workloads won't improve and could degrade, the questions are how much, and is the tradeoff worth it in order to get responsiveness/consistency of high priority behavior. Exploring, proving and educating in this area is an important component of our prototype work. 15. No our prototype doesn't yet support SMP. The cost of synchronizing across processors using the SMP locks shouldn't be more than synchronizing across processors using the SMP locks...don't know where you are coming from suggesting what we are doing will be prohibitively expensive on a multiprocessor! We'll share an SMP version when we get one put together (but it's not highest priority for us, our first order target for this thing is uniprocessors, which are far more prevalent in the embedded market segments.) 16. This is available for an IA32 platform. If you think that's an obscure platform...I guess you live in a parallel universe where Motorola hardware got selected by IBM back in the early 80's for their PC, or something! We'll productize on all supported MontaVista platforms (21 different boards across 4 different architectures as of our 2.1 release 2 weeks ago...). 17. I'm not aware Ingo did fully preemptable kernel work, and if Ingo did any work on such a system, we weren't aware of it and did not base this on any such work. 18. Preemptible is not interruptable. We've separately and previously done characterization work on interrupt off times in Linux. See our real-time project area on our web pages (www.mvista.com). Interrupt off times in Linux are surprisingly good, with one exception (child process exit with many children)...and of course ignoring arbitrary drivers that can misbehave. 19. Time to go howl... Sorry to be long winded. I hope this helps to clarify a few things. -Kevin
Let's get something straight. The GPL doesn't prevent Linux from being subject to reality. A sucessful fork of the kernel would be a nearly impossible task. There would be little developer support, it would encourage other forks, etc. Additionally, the Linux project is prone to the same power struggles, ego trips, jockeying that everything else is. If Linux suddenly gave up the project without a clear line of sucession (god damn that sound medieval) then there would be a power struggle. Similarly, the GPL doesn't make Linux imprevious to egos. The bit with Alexander Verio posted in earlier Slashdot stories confirms this. Really, all the GPL makes it easier to do is use the code. Beyond that, you've got the same problems with power and introducing a new OS (forking) that you do with every other project. All it takes is a look to the BSDs' past to prove that OSS is not the "grand unified solution to everything."
A deep unwavering belief is a sure sign you're missing something...
I've never had an MP3 player skip on me in NT, what's your point? The person I was responding too said nothing about audio latencies. He said that he couldn't listen to an MP3 and surf the internet at the same time with NT. That statement is patently false. True, WindowsNT won't give you millisecond latencies (and neither will regular Linux), but hell, it wasn't designed to. It was designed to be a fast (as in interactive speed) workstation OS, and in that segment, it more or less suceeds.
As for Mp3 playing being implemented under any OS, that's also false. It's not if you can play an MP3 without skipping, but how many you can play, and what load the system will take before it starts skipping. Linux starts skipping at a lot lower load than does NT, which handles a lower load than BeOS. That's just the truth of it. You can totally max you the processors in BeOS and still have the system stay responsive, while doing something proc intensive (like gunzipping the kernel archives, which can fit into main memory) will cause the system to become unresponsive.
A deep unwavering belief is a sure sign you're missing something...
I haven't tried 2.4, that should have said 2.0. I guess it's time to give it a try and see what I get . . .
I wish them luck - the more realtime capabilities are available in Linux, the more applications can use it instead of either specialized embedded system OS's or close-enough Windows products.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Yea, you can also say that BeOS network performance kicks ass or that it's OpenGL is faster than Windows OpenGL. However, given that those two products are in Beta, they mean nothing until they're actually implemented in the mainstream. Same thing with the eostoric Linux patches. While Ingo's patch may be fine and good, it is really marginal until it is implemented in a production kernel.
A deep unwavering belief is a sure sign you're missing something...