malloc uses mmap for large memory blocks, not sbrk.
I think the question being asked is, given a certain stack, what is the minimum number of flips required. 2(n-1) is of course an upper bound, but that is not the minimum.
In my case, it is because the people running those 10 servers want to have their freedom to set different kernel parameters, to install different OS packages, to run their own Apache server with their own hostname all looking at port 80, and to hold root account without fighting each other. Most importantly, top efficiency is not a concern as the servers are not heavily loaded.
If your OS isn't sharing duplicate memory blocks already, you're using a shitty OS. (Linux already shares dup read only blocks for many things, like most modern OSes).
That depends on how the memory gets duplicated. If it is duplicated because it comes from the same library or because it is the result of forking a process, you're right, every OS does that. But if it is because the memory content comes from independent processes doing independent things and the result happens to be exactly the same, it is new. In the former case, if two processes are sharing some memory, one process decide to write over it, and the other does exactly the same write, then the result is two unshared pages. In the latter case, they will also become unshared at that moment, but after a while the OS will notice that they are the same again and make them share again.
I think that there is not a lot of use cases of KSM actually apart from the VM use case. That's why nearly no OS provide that service until today. And even if Linux provide that, it is likely that most people running a Linux desktop will not enable the feature because it wastes clock cycles to ask the OS to constantly scan through your memory to find pages to deduplicate.
Hmm... if the instruction set structure is really such that I cannot make out a sufficiently small table and register the prefixes of instructions into it, I'll write a nice code generator to generate the "nightmare of branches" and then forget about it. I hate to maintain crap... the instruction set is going to change at exactly the day when you forget how the branches work!
Both of the problems are valid, but again, what you call "DM" is good enough for Microsoft to suck money, so there is no incentive for them to invest in engineering method to do what you call "WM".
Look at the competition. They are (1) Linux, and (2) BSD (including Mac OSX). Both are very generic OS, serving a wide variety of settings including the desktop, the server, laptops, and handhelds and at times embedded systems like routers. Both don't care that average user will use only a tiny fraction of the OS. This is general in software: things get generalized to all similar areas. There is no point for MS to create a "WM" from scratch, if MS need one it simply disables the unneeded features from Vista. Because it costs essentially nothing to Microsoft to make a new copy of Vista. Making a "WM", in contrast, means engineering efforts.
Incidentally, I'd call "just disable some feature of Vista" a good enough solution: it is good enough because the average computer has the capability to run Vista anyway (or so MS think), so they don't create a "perfect" solution to match the average desktop usage exactly.
I think Emacs shortcuts make a good amount of sense. Most short-cuts comes from the first characters of their respective commands, the more commonly used commands are used with just Control while the less commonly used ones are prefixed with C-x or C-c. If you ask me, vi commands make much less sense, and at times even Firefox shortcuts falls behind! (Who know why "bookmark this page" is Control-D?!)
The moment it gains the menu bar and mouse control, it ceases to be a valid criticism. You don't like Control-F? You have the arrow keys. You don't like Control-x Control-s? You have Menu File Save. You don't like Meta-F, Control-V and Meta-V? You can use you mouse to scroll and move to wherever you want. The Control and Meta are just one more way you can access the Emacs windows, albeit a very effective one. The other editors would have forced you to move your fingers to your mouse, in Emacs you can remain in your most efficient posture as long as you can remember all those key binding, otherwise, fine, use the menu just as every other editor would want you to.
Who the hell say that you have to use the best tool for each task you need to perform? Emacs is definitely not be the most decent calendar, but it can be a sufficiently effective one for those who already type into their Emacs windows day and night.
Once you start using one tool, you start getting the habits from it, and when you do another task, you want that habits to remain valid. For whatever reason, many Emacs users expects a cursor to be available on everything, expecting Control-F and Control-B to move that cursor, and expecting Meta-F and Meta-B to do that more quickly, and type Control-x k Return to remove it and continue working on something else without touching the mouse even once. I've yet to see a single other calendar that allows exactly that simple thing.