xilun666
This is not the case. Most computers are tiny; the kind of "you've only got 1kB built-in and non-expandable memory" tiny (yet only if you're lucky). And most of those computers are indeed programmed correctly, despite using a number of classical trick like xor linked-lists (the program is small, so really checking it, even if it contains tricks, is doable).
He does not take into account at all that you can just modify copies of his stuff. Not his own (unless he planned to do a kind of wikipedia like repository for his code, freely modifiable by anybody without even registration).
And also: copies are naturally free in the digital age.
Also, i'm not fond the whole "i'm a good programmer, you are only allowed to look because you could be a bad one and do a mess in your own copy -- and oh I forgot: I happen to like free software, but not when I write the program" thing.
Give us their names, so we never deal with them ;)
fire in the hole.
At the beginning you're are not even conscious that you can, but once you've discovered the power it gives you, you will branch twice a day just because you can (and more if you need).
The two stage commit approach of git is interesting but not fundamental IMHO. "stash" is really cool.
The kind of features git gives me makes me use it even when I code alone.
The programmer you are describing are a kind of programmer who makes lousy programs. I've read enough of those programs to say: they are not pretty -- they do not work well in large scale -- and they cost a LOT.
The article starts with an obvious observation, being that scheduling (in its largest meaning) often is crap in real (Windows?) systems.
It concludes with complete meaningless bullshit where applications, now renamed, would have a dedicated CPU. What the point? Doing hard real-time? What does that even concretely means for "runtimes" of have a "dedicated" CPU (wich, given the complexity of modern architectures, would not really be in a strict fashion) and to do resource management thanks to metadata inserted by the compiler?
What is really needed is more effective ways for applications to sends tips to the kernel about what is going on, what should run at high priority, what should be cached, what should not be, and so over.
Forbidding some programs to use some cores because you have many makes little sense as a way to re-architecture an operating system. Because it already happens anyway on current designs (not really forbidden, but when you have few services consuming less than 1 percent of 1 core in the background, and/or running with extremely low priority they will be near to unnoticeable, and truly unnoticeable from the point of view of the user).
To get a responsive word processor no matter an anti-virus is loaded or not, a simple solution can work really well now; priorities of scheduling. Given that really background priorities are among the rare things that works fairly well under windows (like 10x better than with a vanilla Linux kernel), if the "architect" is experiencing random slow down of Word because of his "antivirus", its because his "antivirus" is total utter crap, not because a new "architecture" of OS is needed.