Slashdot Mirror
The ~200 Line Linux Kernel Patch That Does Wonders
An anonymous reader writes "There is a relatively miniscule patch to the Linux kernel scheduler being queued up for Linux 2.6.38 that is proving to have dramatic results for those multi-tasking on the desktop. Phoronix is reporting the ~200 line Linux kernel patch that does wonders with before and after videos demonstrating the much-improved responsiveness and interactivity of the Linux desktop. While compiling the Linux kernel with 64 parallel jobs, 1080p video playback was still smooth, windows could be moved fluidly, and there was not nearly as much of a slowdown compared to when this patch was applied. Linus Torvalds has shared his thoughts on this patch: So I think this is firmly one of those 'real improvement' patches. Good job. Group scheduling goes from 'useful for some specific server loads' to 'that's a killer feature.'"
Compiling the kernel isn't a useful benchmark. How well does it deal with running Adobe Air?
Considering that UI lag was always my big problem with anything Linux-based (hell, it even seems to affect Android phones), this might be one small patch for the kernel, one giant leap for userspace...
Of course, how many years from now will that filter into the distros? My guess:
Gentoo: soon
Debian Unstable: 2Q 2011
Ubuntu, Fedora: 1Q 2012
Debian Stable: 2015
RHEL: 2020
Oh, no! You have walked into the slavering fangs of a lurking grue!
That's not a kernel patch... That's a bash script that forcibly installs BeOS!
I guess it's somewhat objective and dependent on your hardware anyway but even with lots of programs open on my main machine I don't notice any slowdown... I think if linux is really gonna pull ahead of the pack they aught to take a gamble on a new, useful interface. Something like 10gui. The risk could even be mitigated by having a choice to load either type of desktop at the beginning with a quick video to demonstrate the difference. :)
check out the Mp3 Garbler I built!
I thought a few years ago, there was a desktop friendly scheduler rejected because Linus thought the server environment was more important. The details escape me.
Is this a typo?
"... slowdown compared to when this patch was applied." - Shouldn't that be something like "... slowdown compared to the performance before the patch was applied"
http://xkcd.com/619/
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
Isn't it awesome when a new version of your OS performs *better* than the last one on the same hardware?
# cat
Damn, my RAM is full of llamas.
They mention the "Con Kolvias" scheduler in TFA, but they don't seem to want to refer to it by its real name:
http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler
It doesn't scale well past 16 cores, which is why Linus doesn't want to include it in the main kernel. But it's included in custom kernels for mobile devices, such as CyanogenMOD for my Android phone.
No matter how many different flavors of Linux I installed, it just never seemed as snappy as Windows. There was always a sluggishness about it, nothing I could really put my finger on, but it was definitely there and it bothered me. I'm very glad to hear that a solution is in sight.
I hope the people at Ubunto get this out as an update as soon as possible.
any chance of backport of this e.g. to .35 kernel for use in ubuntu maverick? i could use that :)
or even to .32 for use in 10.04 LTS..
This is my Sig, this is my Gun. One is for Slashdot and one is for Fun.
Typically when you get this sort of speedup, it's by rewriting a tiny piece of code that gets called a lot. Sometimes you can get this sort of thing from a single variable, or for doing something odd like making a variable static.
The patch being talked about is designed to automatically create task groups per TTY in an effort to improve the desktop interactivity under system strain.
I guess this works because the task loading up the machine will have been launched from a konsole, and thus be tied to a specific tty (the make -j64 example given later), so a tty-based scheduler can appropriately downgrade it.
But what if the "loading" task has been launched directly from the GUI (such as dvdstyler)? It won't have a tty attached to it, and will be indistinguishable from all the other tty-less tasks launched from the GUI (such as the firefox where you browse your webmail), or worse, Firefox itself creating the load (such as happens when you've got too many Facebook or Slashdot tabs open at once...)
shouldn't that read "and there was not nearly as much of a slowdown compared to when this patch wasn't applied"?
This has been brought up by others on slashdot before, but Linux tends to be either (A) fine and happy, or (B) pushed into a thrashing state from which it can never recover - like it takes 8 or 10 minutes to move the mouse cursor across the screen. Since there is relatively no warning before this happens, it makes a hard reboot just about the only option.
Will this patch help with that issue? Like the threads below say, once a modern (KDE/Gnome) desktop Linux starts swapping, there is so much new data produced per second by the GUI that it's basically game over. I'd like to see a fix for this: it's the single biggest cause on Linux that makes me do a hard reboot. I just don't have the patients to see if the thing will recover in half an hour or so, even though it might.
http://ask.slashdot.org/comments.pl?sid=1836202&cid=33998198
http://ask.slashdot.org/comments.pl?sid=1836202&cid=33999108
http://www.linuxquestions.org/questions/linux-kernel-70/swap-thrashing-can-nothing-be-done-612945/
When doing benchmarks, do them seriously.
okok... i know its phoronix...
A single *atypical* workload as a benchmark, without a full characterization does not make me consider to use a kernel path on my system which is reported in the style of an UFO-sighting....
I wonder if nicing the kernel compilation would have had a similar effect....
This is not the scheduler that the grandparent would be referring to though. BFS has been around for about a year, and has as far as I know never actually been pushed for inclusion.
The previous scheduler that Con wrote was rejected in favor of CFS which is currently in use by the kernel. CFS is at least partly based on ideas from Con, and he was also credited for them.
....would make it 2x faster! LOC is the #1 metric for programming.
With make -j64, this is ok: The make will have been started from a terminal (it's not important whether it's a Linux (console) terminal or within an X window), whereas most other GUI programs won't. So they can be distinguished from each other.
But in case of dvdstyler, it won't have a tty if it has been started directly through the menus, and so the scheduler cannot put it in a different group than all the other GUI apps (which also lack a tty).
Of course, if you start dvdstyler from the command line (from a konsole), this won't apply.
You can easily check which tty (if any) a program has associated by doing a ps auxww and looking at the 7th column (where it will say ? for "no tty" or name the tty (such as pts/9)
Con Kolivas worked on his staircase scheduler and various performance patches for years. They were routinely demonstrated to be a major improvement. Linus kept saying he was concerned the tradeoff of desktop performance would come in other environments, even though that wasn't true.
Since benchmark after benchmark showed staircase was vastly superior to what was in mainline, Linus then went to go after the guy rather than the code. He said Kolivas couldn't be trusted to support his code, and thusly it would never be accepted mainline. Reality was that Kolivas had been responding to criticism and updating his patchset for over 3 years, constantly improving it. In addition to the LKML, he also maintained his own support mailing list.
I'm a Linus fan 95% of the time, but it was a really shitty move, and it drove Kolivas away from contributing. He quit coding for a while. Then after Linus argued for years how this was a bad idea, suddenly the mainline kernel developed the Completely Fair Scheduler overnight, which was very similar to Kolivas' Staircase scheduler. Linus never admitted he had been a dick for years arguing against the thery of the scheduler rewrite. He then pushed the brand new, untested scheduler into mainline.
CFS is better than what we had before, but it still lost in benchmarks to Staircase, and it was new, untested code.
Now, Kolivas came out of retirement with a new scheduler called Brainfuck that is even faster, but he has no intention of ever tryint to get it in the mainline kernel.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Turn off swap, if you can. The cost of memory is now less than the cost of the stress and lost uptime due to swap-paralysis.
I have 4G of RAM on my desktop (I doubled the RAM for $60 after I bought it) and the only time my system swaps is when I have mmap()'ed an 8G file.
Similarly, on my 512M netbook, I don't exceed RAM with crazy things like "make -j64 bzImage". Even with wear-leveling, swapping to SSD is bad form. I'd rather swap over NFS to spinning platters, than to SSD.
Obviously you've never compiled a kernel passing -j64 to the make process. If you had, you would know that all your CPUs would be pegged (indeed -j7 pegs all 8 cores on my laptop.) Of course that is not the benchmark part. The point is that with an "all your processors are belong to kernel build" condition, group scheduling allows there to be essentially no perceived slowdown for interactive GUI/Window manager based computing. You probably should have figured out that you were missing something when Linus Torvalds didn't object to the benchmark and the results. Seriously, this is a major point to understand: When it comes to the kernel, in a fight between your knowledge and Linus', Linus wins.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
10gui just _looks_ nice to the naive, and probably OK for people who only can cope with a few windows open at a time. But I don't see how it's actually going to be faster in task switching than using alt-tab, or clicking on task bar buttons.
:) ), IM windows, editor, email, virtual box machines, file managers, it all starts to add up. I find opening and closing stuff only to reopen them again is usually a waste of time - why close an app if you're not running out of memory and you can still remember which task button raises it? So if a colleague on IM says: "hey can you restart XYZ again?" I don't have to ssh in, and etc. All I need to do is just click on the correct task button, press up arrow, confirm its what I want, press enter.
;) ) or some other competitive gamer, or watch a skilled person handling a Point-of-Sale machine.
The 10GUI interface would just get in my way a lot.
I often have about 30 windows open (I have a double height taskbar) - ssh sessions, browsers for work, browsers for nonwork (e.g. slashdot
Sad to say, I find Windows XP/7 is so far best for handling stuff like that. Even better than OSX.
I tried doing the 30+ windows thing on OSX, using Expose. But it's just slower - more steps to get from one window to another. In contrast, on windows I can just click on the desired task button and that's it, no need for two clicks, or click then pause or other bullshit. Keep in mind, I'm not saying Windows is the best possible, there's still room for improvement. For instance, it'll be nice to be able to "alt-tab" from one browser tab to another browser tab (so much so that sometimes I open new browser windows just to be able to alt-tab between them).
KDE when I last used it was stupid. They sort tasks top to bottom first then only left to right. So if you have a double height taskbar and you close one button in the middle, all the buttons to the right of the closed button change position! That is so stupid.
If you think it's ridiculous to have 30 windows open, keep this in mind - nearly any crappy GUI can seem cool and easy for a workload that only has 3 windows open. It's when you need to juggle lots of tasks at the same time that's where the GUI either adds value or gets in the way. On-topic analogy: it's just like an O/S, a crappy kernel can seem good when you only have 3 concurrent processes. It's when you have 30 concurrent _running_ processes that you find out whether the kernel's IO and CPU scheduling is good, mediocre or poor.
I would prefer a GUI that's good for the naive/noob users, but at the same time provides short-cuts that can speed things up immensely for users that are willing to learn them.
GUI designers should not assume that users are not able to learn "fancy" stuff. Just watch an experienced Starcraft player (actions per second and all that
A great UI should be able to hyper-augment humans. To paraphrase a perlism, a great GUI should make simple things trivial, and difficult things easier.
Desktop GUI designers should not be saying "most people don't do difficult things so let's just handle the simple case".
Actually Linus lost track of many such things because too self centered or ego driven (which happens to most of us when you such success and things to deal with but anyways)
This very patch is a prime example, if it goes *default* in the kernel.
It's a patch that favors *only* Linus's usage of linux: Browse the web while his kernel compiles. Now imagine you start your video from a tty (mplayer blah_1080p.avi) and it takes 95% cpu to be smooth, then you start your browser.. uho.
In BeOS I could^H^H^H *can* (haiku, too) start 5 videos on and old PC, browse the web and:
- the browser is smooth like butter
- the 5 videos are a bit choppy (no miracles but that the point) but they all run at the same speed
Now _that_ is what I want a desktop scheduler to be like.
With more criticism he could see that some would want this auto grouping option, but the majority wouldn't. Now what does that tell us?
It tell us that it's _either_:
A/ Not the best solution (i.e. our scheduler sux)
B/ Grouping should be smarter or more easily configurable (it's currently configurable in the previous kernel version and can do just what this kernel patch does!)
Obviously they didn't apply the patch to their web server first...
Occassionally, yes. But usually when Linus flames someone on the LKML he is entertaining, and is right. This was an instance where Linus just seemed to be a dick for no reason.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
So is Linus a dick?
I'm pretty sure this is a well-known and widely-accepted fact, even by the man himself. This is almost certainly why the submitter quoted him as saying, "Good job." That's unusually high praise coming from Linus.
Kernel benchmarks are always a point of contention. But interbench and all the standard benchmarks did show a marked improvement with the CK patchset and the Staircase scheduler.
If Linus didn't really believe it was an improvement, then why did he eventually call on Ingo to write a very similar scheduler?
Linus didn't want to admit he was a jerk who made a flippant personal decision rather than focusing on the best code.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
I think part of the reason that Linus is more accepting of this change rather than replacing the entire scheduler (like Con Kolivas pushed for) is that Linus likes small, neat patches. And I think Linus gets offended when someone wants to rip out large sections of the kernel and replace them.
I often wonder how much old, legacy code there is in the kernel that is just overlooked. Anytime you carry code for that many years, you're bound to have some legacy systems that can due to be replaced.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Its explained in the BFS FAQ http://ck.kolivas.org/patches/bfs/bfs-faq.txt
Why "Brain Fuck"?
Because it throws out everything about what we know is good about how to design a modern scheduler in scalability.
Because it's so ridiculously simple.
Because it performs so ridiculously well on what it's good at despite being that simple.
Because it's designed in such a way that mainline would never be interested in adopting it, which is how I like it.
Because it will make people sit up and take notice of where the problems are in the current design.
Because it throws out the philosophy that one scheduler fits all and shows that you can do a -lot- better with a scheduler designed for a particular purpose. I don't want to use a steamroller to crack nuts.
Because it actually means that more CPUs means better latencies.
Because I must be fucked in the head to be working on this again.
I'll think of some more becauses later.
BFS makes the classic trade offs which Linus and almost all others absolutely agree is a bad decision for core inclusion. BFS trades performance for latency. Basically you get really good interactive performance in exchange for massively losses in over all throughput and efficiency. Furthermore, BFS sits on a horribly slippery slope in that the level of *inefficiency* scales wonderfully with core count. Basically, the more cores you add, the more time BFS spends BF*cking around.
Basically BFS only makes sense on single or dual core systems which will primarily be used as a desktop. After that, it better be a dedicated desktop system because compared to the stock kernel, performance is going to royally suck, despite latency being fairly good. But then again, BFS was never really designed to address scalability - its always focused on latency and a superior interactive desktop experience. By most measures it works, but at a heavy cost.
Was I the only one thinking about Amigas and Alphastations?
Amigas had so much offloading that you could pull the CPU out and still move the mouse pointer.
Did you mount a military-grade, variable-focus MASER on an unlicensed artificial intelligence?
Its been fairly well documented as to what happened. Linus is an egotist; as are many smart people, including others on the LKML. It seems Con has a fair ego himself with somewhat gruff interpersonal skills. The combination put him at odds with a lot of people. Generally speaking, people with large egos, don't like others who know more than they do, especially when its their pet project. Furthermore, Linus already had some people he trusted, who also had their ego's hurt by Con's work.
So the line was drawn. Linus and his trusted lieutenants on one side and Con on the other. Linus with his lieutenants, all with hurt egos from a slightly abrasive developer who clearly understood the problem domain better than all of them, simply decided he preferred his pride and undue ego over that of Con's potential contributions.
Not surprisingly, this type stuff happens ALL THE TIME amongst developers. I can't tell you how many times I've seen personal pride and ego take priority over extremely well documented and well understood solutions. Not to mention, frequently, the same documentation which explains why its a good decision, also explains why the decision of pride is an incredibly bad decision; with a long history of being very dumb. Despite that, egos frequently rule the day. So its hardly surprising that Linus isn't immune.
I have Arch Linux running on an old single core Athlon based machine, and about two months ago I compiled the Arch kernel to use BFS, because I had heard it was good for the type of machine I was using. My experience pretty much agrees with what you're saying here. I wish I would have read something this honest about it before I bothered to set it all up and compile the kernel.
At first glance it really seems to improve system responsiveness in regards to user input. However this comes with a gigantic trade off. As an example: If I had a standard definition xvid file playing, the video would literally pause while the system loaded other programs like Firefox, Nautilus, etc. To me that is unacceptable. User input is nice, but if it's choking the entire rest of the system, it isn't something I want to use. The standard scheduler that comes with the kernel might not be perfect, but it will continue playing video while it opens up other apps.
All the little sister chips could do most of the work. Which is what killed the Amiga. It was a cluster of ASIC chips, and that doesn't scale well to incremental performance upgrades the way a new, faster x86 chip every six months does. Who's going to design a whole new set of ASICs every six months? Nobody in their right mind.
Indeed, I find that Linux has an almost miraculous ability to convert users into developers. I've encouraged several friends over the years to use it, and out of those that have actually done it, most have not just stuck with it but have even surpassed me in some ways. It can take a teenager or young adult who knows barely anything about coding or even much about computers and can turn them into a coder or admin in no time. My theory is that people follow a sort of a path:
1. They use a bloated (but more immediately user-friendly) distribution like Ubuntu.
2. They hear about other users with lighter software and try it out. It requires a bit more configuration to be the way they want it to be. In the process, they learn more about their system and they learn many useful things.
3. The drive for improved performance and usability leads them to learning more and more and doing deeper and deeper configuration until they know a great deal and are very comfortable with their system.
4. The "scratch that itch" (ESR) effect comes into play; they see deficiencies in existing software and go out to make their own.
5. Before long, they are contributing to several projects, have a technical blog, and are advanced users.
It seems to be some sort of natural progression and it's interesting to see it happen over the period of several years. More significantly, Linux seems to turn a higher percentage of basic users (even those of the luser variety) into developers and advanced users. This seems to be why Linux progresses at such a fast pace; its users actively encourage other users to involve themselves on a deeper level.
Yet Another Tech Blog
(but so much more, including game and movie reviews)
http://yanteb.peasantoid.org
Back in the 80's and 90's many DOS users followed the same path. BYTE, PC Magazine, and even PC Computing provided essays on "how it works" and source listings for 8086 ASM and BASIC programs. But somewhere around the time of Windows 95, things seemed to change and it became expected that the "average user" had no interest or time in learning how anything works. I remember that desire to Not Know Or Care as one of the major friction points between the DOS user base and the Windows (and Mac for that matter) user base.
I know Linux wants to be POSIX compliant, but I don't see any harm in changing nice like so:
1. Store the original nice value of a process in the kernel's process table.
2. Allow priority to be lowered by anybody.
3. Allow priority to be raised by anybody as long as it does not surpass the original nice level.
4. Require superuser to go beyond the original nice level (and reset the saved value if they do).
That would be no more dangerous than the current system, but would allow apps to lower their priority temporarily when they go off to perform 'batch-like' processes, restoring it when they return to interactive mode.
Posted from my Android phone. Oh, I can change this? There, that's better...
I've been a Windows user since Windows version 1.01 (that used real mode DOS, and text based graphics). Windows has never, ever, ever been "snappy". At least not out of the box. There used to be third-party utilities (eg Norton Desktop), that made the experience better. But, it does depend on what you use it for. If you don't have tens of thousands of files to maintain, and only use it to watch pr0n and for email, and that Christmas letter. Then yes, you will probably have snappy performance.
If however you use it for business, and write dozen of documents a day and have millions of lines of code in thousands of files, and are creating videos and music, then you will not see snappy Windows performance. That said, unless you've been using the -ck kernel patch (I downloaded and stored on my own server when CK left in storm), you've not seen snappy performance in any full blown WM in Linux either. Now, it looks like they finally got a kernel patch that can compete with Con's 6 year old patch. Congratulations Linus! It only took you and your crew six years to duplicate the work of one man that you bullied out of the kernel group!
Running Linux since 1991! Wow it's almost been 20 years since I attained enlightenment!
Or he is less willing to solve problems than you are. Ever thought of that?
Look, you want easy entertainment, you get a DVD player and a TV. You want to get a bit beyond that, you get a gaming console. You want to run with the Internet, you better be willing to learn how to use a PC.
It never ceases to amaze me how smart my parents can be when I'm not available, and how dumb they can degenerate to when I am. It's not even instant Alzheimers, it's like they suddenly can't even read. Could all that just possibly be... laziness?
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Part of the problem was the jump in difficulty. Windows 286/386/3.0 was difficult enough to program that to do anything useful required more than just basic skills. Also BAT worked sorta well as a scripting language there no scripting language for windows.
Basically the difficult shot up suddenly when it came down again with things like visual basic the paradigm had changed. Incidentally its still fairly hard in windows to manipulate hardware.
You either missed it, or are conveniently "failing to mention it", but the idea was Linus' to begin with, and he wasn't expected such great results. There are reasons why Con's patches weren't used and this one is used. I'm not about to debate it here, as it has been beaten to death already, and with logic like "fuck Linus" you clearly have me outclassed in any such debate.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Let's get back to reality instead of pretending it's a clash of supermen with instant insight. I think the reason was the patch submitter only looked at a small subset of the effects of his patch and did very little testing to the extent that he only even had linux on his development machine and only used it to do his patches in the free time he had. You don't know if your own cooking is any good if you don't eat it yourself. To be blunt it was about a respected expert in another field (medicine) finding that with his part time hobby it takes time and work to produce something experts in another find acceptable as a finished result and then getting upset about not getting the level of respect he gets in his own field.
I have to say that I went rougly the other way: I started with Linux because I was highly discontent with the then-current Microsoft offerings, finding them unwieldy and unstable. I started way back on Slack 6, where the first step of the installation process was compiling your own kernel and gcc three times to get them pure :-)
Later I switched to RedHat (3 or 4, I think), and was also messing in some code - mostly for my own benefit, can't recall ever committing anything because I didn't think the changes I made were useful for enough people to be included.
These days, I just run Ubuntu - I've been through the whole trial-and-error config file thing, it's given me a good understanding of many things, but now I just want something that simply works so I can get on with other stuff.
These days, the MS offerings (well, some of them) are at least a lot more stable, although I personally still find them unwieldy - I guess I'm no longer used to having my OS babysit me. I even occasionally recommend that a friend who needs a reinstall sticks with windows, depending on his needs, although I always offer them Linux, too. I flat out refuse to support windows boxen, though :)
What a depressingly stupid machine.
It's been fairly well documented but you still seem to ignore the reality of what happened.
http://kerneltrap.org/node/14008
Read all that then tell me that Linus has an ego here. It seems to me that Linus is the only level headed guy and you're just trying to distort what really happened.
- He choose CFS over SD because SD behaviour was inconstant among users' computers
- Con would argue with people sending him problems rather then accept them as problems with his code
- Linus didn't want code in the kernel that would only work well for certain users
- Linus didn't want code maintained by someone that was so hostile to others' critique
- Linus states that he believes the desktop is an important platform
This is the great battle with distributions like Ubuntu. There's a fine line between auto-configuring and helping the user make decisions (or making decisions for the user) and preventing the user from making decisions on their own.
Yet Another Tech Blog
(but so much more, including game and movie reviews)
http://yanteb.peasantoid.org
In 1980, The IBM mainframe operating systems included "Performance Groups". Workloads were classified into Low CPU interactive and High CPU background and also some must complete performance group(s). It like being born again to see it coming to Linux as a new patch. Now I would love to see a "VM CMS" environment under the linux kernel
Leslie Satenstein Montreal Quebec Canada
But somewhere around the time of Windows 95, things seemed to change and it became expected that the "average user" had no interest or time in learning how anything works.
It was a combination of Windows 95 being comparatively idiot-friendly along with an absolutely massive influx of idiots when public access to the Internet started to take off, and the web began to come into its own.
Those two things happening at about the same time changed the world in a lot of ways. For example, the terms "top posting" and "bottom posting" came into existence right around this time, as millions of new users exposed to email for the first time got their hands on Outlook Express, with its completely broken editor that made formatting a message correctly almost physically impossible.
When I really think about it, the biggest difference between being an old-school DOS hacker and being a modern Linux hacker was that in the DOS days we had BBSes, and those of us with net access had Gopher and Archie. I got out of development around 1995 not simply because everyone demanded GUI applications, and early Windows development sucked, but also because when I first got on the web, I found a good many alternatives to every application I had ever developed. You think KDE vs. GNOME is a big waste of resources? One of the DOS applications I actually made money on was a utility that has a close equivalent as part of the GNU toolchain, and I abandoned development when I realized there were about six alternatives that predated my own, and were further along.
We DOS hackers were working alone for the most part, or in small, isolated teams. The web changed all that, and then sites like SourceForge took it all to the next level. Now, collaboration is easy.
Use linux if you want to know why your computer works. Use mac if you don't want to know why your computer works. Use DOS if you want to know why your computer doesn't work, and use windows if you don't want to know why your computer doesn't work.
"People don't want to learn linux" hasn't been a valid excuse since '03.