Windows NT Kernel Contributor Explains Why Performance is Behind Other OS
blog.zorinaq.com
blog.zorinaq.com
From the outside I always assumed the constant flood of new, half-baked features instead of fixes and improvements to old ones was caused by interns and junior devs looking for glory - sad to hear that's actually partly true. I always considered frameworks like WPF (or Flex, for that matter) 'intern code' - not that interns necessarily wrote them, but they reek of not-experienced-enough engineers trying to solve problems by writing a bunch of new code, instead of fixing existing code.
It really is too bad, though. There are parts of the NT kernel (and even the Win32 API) that I consider a joy to use - I love IOCP, despite its warts, and APIs like MsgWaitForMultipleObjects are great tools for building higher-level primitives.
Plus, say what you want about GDI (there's a lot wrong with it at this point), but it's still a surprisingly efficient and flexible way to do 2D rendering, despite the fact that parts of it date back to before Windows 3.1. Some really smart people did some really good API design over time over at Microsoft...
See, in Windows, processes are first class kernel objects. You have handles (read: file descriptors) that refer to them. Processes have POSIX-style PIDs too, but you don't use a PID to manipulate a process the way you would with kill(2): you use a PID to open a handle to a process, then you manipulate the process using the handle.
This approach, at a stroke, solves all the wait, wait3, wait4, SIGCHLD, etc. problems that plague Unixish systems to this day. (Oh, and while you have a handle to a process open, its process ID won't be re-used.)
It's as if we live in a better, alternate universe where fork(2) returns a file descriptor.
You can wait on process handles (the handle becomes signaled and the wait completes when the process exits). You can perform this waiting using the same functions you use to wait on anything else, and you can use WaitForMultipleObjects as a kind of super-select to wait on anything.
If you want to wait on a socket, a process, and a global mutex and wake up when any of these things becomes available, you can do that. The Unix APIs for doing the same thing are a mess. Don't even get me started on SysV IPC.
Another thing I really like about NT is job objects (http://msdn.microsoft.com/en-us/library/windows/desktop/ms68...). They're a bit like cgroups, but a bit simpler (IMHO) to set up and use.
You can apply memory use, scheduling, UI, and other restrictions to processes in job objects. Most conveniently of all, you can arrange for the OS to kill everything in a job object if the last handle to that job dies --- the closest Linux has is PR_SET_PDEATHSIG, which needs to be set up individually for each child and which doesn't work for setuid children.
(Oh, and you can arrange for job objects to send notifications to IO completion ports.)
Yes, Windows gets a lot wrong, but it gets a lot right.
Update: And I forgot to mention the font parsing security issues (look up Duqu), and the issues with user mode callbacks too.
Okay, you're in charge. Are you sure you can't find a better way to deploy shareholder capital than using it to remove win32k?
Could that be why developing an OS inside of a shareholder-owned corporation is inherently hobbled compared with developing it as an open source project?
True, but resource allocation is distributed between volunteer contributors, sponsored contributors who may have different sponsors, downstream consumers of a project, and people involved in project governance. That can make it easier to try new approaches.
Not all commercial projects are run like Windows, and it seems to me that most of their conservatism doesn't come from lazy or shoddy or shortsighted developers and managers, but rather their large number of hardware and software partners who take dependencies on undocumented implementation details (see Raymond Chen's blog for a virtually infinite supply of such anecdotes).
Genuine question (because I really don't know) -- how do Linux GUI frameworks work without kernel-mode callbacks? What do they use instead, when they need to send messages to other windows?
Asynchronous communication is achieved using syscalls like select and poll which take a set of file descriptors (files, special files, sockets) and block the calling thread until some descriptor from this set has new data available for reading, starts accepting writes or signals an error.
GUI toolkits repeatedly poll the X server descriptor, parse incoming messages and call application-defined callbacks.
That sounds like it's basically the same thing as Windows (GetMessage or MsgWaitForMultipleObjectsEx anyone?)... only that now you don't have the ability to use SendMessage, and need to rely exclusively on PostMessage instead.
Is that correct?
In all boils down to message-passing: in Windows, the win32k is the trusted third party that mediates interactions between different window-system clients. In the X11 case, the X server and the window manager work together to do the same job. The architecture are fundamentally similar.
Why does Windows need kernel-to-user callbacks in the first place then? Now I'm thinking it shouldn't even be necessary at all...
Wouldn't that completely avoid needing to call back into user-mode from kernel mode?
Except for the 64 handle limit, which makes it largely useless for anything that involves server applications where the number of handles grows with the number of clients. So then you'd spawn "worker" threads, each handling just 64 handles. And that's exactly where your code starts to go sour - you are forced to add fluff the sole purpose of which is to work around API limitations. What good is the super-select if I need cruft to actually use it in the app?
And don't get me started on the clusterfuck of the API that is IOCP.
> Yes, Windows gets a lot wrong, but it gets a lot right.
Oh, no, it doesn't.
Specifically, what Windows does not get is that it's other developers that are using its services and APIs, not just MSSQL team that can peek at the source code and cook up a magic combination of function arguments that does not return undocumented 0x8Fuck0ff. I have coded extensively for both Linux and Windows, including drivers and various kernel components, and while Windows may get things right at the conceptual level, using what they end up implemented as is an inferior and painful experience.
The problem with Windows is that there isn't any such super-select, unlike on Linux (see epoll, signalfd, timerfd...). You should take a look at my SO answer which lists six different ways to use sockets in Windows: http://stackoverflow.com/questions/11830839/when-using-iocp-...
And expecting a modern OS to have an uncomplicated O(1) API for monitoring sockets is clearly too much to ask.
- To send data, user calls Socket::send(const char *data, size_t length). This starts sending the given data; the buffer must remain available while data is being sent. IOCP implementation will initiate I/O using WSASend() or similar.
- When send operation is complete, the socket implementation calls a Done() callback of the user, and from that point on, the user is allowed to call Socket::send() again. With proper implementation, send() can directly be called from the callback.
This interface is very easy to implement on Linux. But on Windows there's a complication, because it's non-trivial to just stop an IOCP I/O operation that is in progress, in case you decide you don't need the socket any more and want to red rid of it NOW. If you just forget about it, there could be a crash when you release your buffer but Windows is still using it. A simple solution is to CancelIo() the socket and do blocking GetQueuedCompletionStatus()s until you get an event inidicating the completion of the pending I/O operation - taking care to queue up any unrelated results you may have gotten, for later processing. However, a more efficient solution is to use reference counting or similar with your buffers, so they only get released when Windows is done with them.
I didn't say it's easy, but it's possible.
> I can't really use IOCP, because I need keep things reasonably portable
LOL!
You outright dismiss the solution because it isn't "portable". What does "portable" mean here? Portable in a particular platform?!
Portable between what exactly? IOCP has been there since Windows NT 3.51 -- it's "portable" between the Windows-es.
Your epoll, signalfd, timerfd, etc. are Linux functions They're "portable" between the Linux-es.
i.e. The "portable" solutions you like are just as non-portable as the "non-portable" solutions you outright dismiss, making Microsoft's Windows designers look like idiots.
You're never going to find a solution while considering the Linux platform to be the "portable platform" and Windows to be the weird kid on the block.
Sadly, you're not the only person who thinks like this.
So "LOL!" yourself, bud.
It's funny, you mention "epoll, signalfd, timerfd" as an example of a portable API, and then when I point out they're Linux APIs, you suddenly start talking about "a scalable variation" of the BSD sockets API. As for your "scalable variation of BSD sockets API", why don't you tell us the name so we know what you're referring to? Are you talking about Kqueue for example, or something else?
> an abstraction that is both simpler
I/O completion ports are just read-write queues... you ReadFile(), and when it's done, an item goes into the queue. (You can insert your own tasks into the queue, too, if you want.) Now just pop off the next item in the queue and off goes your thread. What part of that was so complex compared to your portable API (which for some reason you didn't feel was appropriate to mention the name of)?
> and more universal
Can't reply to it without knowing what "scalable variation" you're referring to, and why you didn't actually mention it as an example of portability when you were actually talking about the subject. Is portability actually a concern for you or no? (If it is, why did you bring up non-portable examples?!)
It wasn't me who mentioned it.
My comment remains essentially unchanged, though, with the same question as before:
What's this great portable API you're referring to?
Don't leave us hanging... what examples are you referring to?
For WINE, if you are going to write an emulator that runs Microsoft code (like the .net framework, or notepad.exe), you need to find the correct behavior of these undocumented APIs by trial and error.
For a developer on Windows, it is perhaps frustrating that MS identifies and solves problems with it's platform, but doesn't publicly release these solutions to you.
I work for some random company that makes an SDK, although I mostly make products using it. Many of our best features are hidden - we don't ship the header files with the SDK, but the symbols are there in the binaries. Someone doesn't think they are useful enough to justify the testing expense for a full release. I guess MS have the same thing.
Wine Is Not an Emulator.
tl;dr: compatibility layer
WINE is a translator that allows Windows programs (those that have an .exe extension) to talk to other Operating Systems.
or perhaps:
Many people need wine if you want them to work. A windows program on Linux is no exception.
I'm sure the aforementioned freshmen would like a no-bullshit explanation for why "emulator" hurts the WINE people's feelings but "translator" does not. It's always been a mystery to me.
Hah! Not really possible, especially considering that the project used to be called windows emulator:
http://www.faqs.org/faqs/windows-emulation/wine-faq/
Which is true, it doesn't emulate another hardware architecture's calls, just the kernel and OS magic needed.
In that regard, think of say a console game or arcade game emulator on a computer- that will have to emulate the whole architecture of said game system as well as the game.
Contrast that to a game program for the the x86 architecture, but not for windows- you could run it natively on windows providing you change everything the game asks for that's part of the Gamesystem380 system into something windows understands, and vice versa.
"undocumented APIs" != "a magic combination of function arguments"
Any function that's not documented can be called an undocumented API, any program has them -- Linux, Windows, whatever.
But you were talking about the argument combinations being undefined, not the functions themselves. What are some examples of that?
Ever since the monopoly rulings against Microsoft, they have had extremely strict internal controls preventing non-OS code from using undocumented APIs. If a DLL or EXE does not ship on the Windows client install disk, it cannot reference APIs which are not documented in MSDN. Full stop.
You're referencing an API that inadvertently didn't get documented, but everyone knows about it, has blogged about it and lots of articles mentioning to use it? Too bad. Either stop using the API or delay release by 3 months for the next MSDN update.
That said, if you're writing an app you might be able to go higher level and use XPC services, which can be much less pain.
When Windows Phone 8 came out, the native renaissance was full speed inside Microsoft, C++ with DirectX became the official way and XNA was canned while Microsoft left MonoGame and Unity pick up the C# developers still willing to invest into the platform.
The sad thing is that this is not a native vs managed issue, because even C# gets compiled to native code when targeting Windows Phone 8. Just plain product management decision to kill the product, which was being sold as the way to develop Windows Phone games.
I have no insider information to suggest otherwise, but don't you think that a replacement will be released with the new console?
Right, I find it likely that XNA was killed to work on a better toolkit for all three.
Sadly those videos seem to no longer be online after MSDN was redone.
Maybe someone can correct me if I am wrong.
This is unfair and unfounded accusation. If you look at the time frame, all the major platform were working on their first hardware accelerated UI toolkits and went through the similar teething problems (Cocoa anyone?). WinForms was a dead end, there was no fixing to do. WPF has turned out well enough, and WinRT has evolved into something very efficient (e.g. by using ref counting rather than GC).
> Plus, say what you want about GDI (there's a lot wrong with it at this point), but it's still a surprisingly efficient and flexible way to do 2D rendering
Not anymore. I get it that some love to use antique APIs and computer systems just for the sake of being retro, but when every computer ships these days with a GPU, using GDI is not even close to pragmatic.
Since the Win32 UI stack uses GDI, it was hardware accelerated before WPF even existed.
Here is a good discussion of the topic:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff72...
Excerpts:
> When the GDI DDI was first defined, most display acceleration hardware targeted the GDI primitives. Over time, more and more emphasis was placed on 3D game acceleration and less on application acceleration. As a consequence the BitBlt API was hardware accelerated and most other GDI operations were not.
> In order to maintain compatibility, GDI performs a large part of its rendering to aperture memory using the CPU. In contrast, Direct2D translates its APIs calls into Direct3D primitives and drawing operations. The result is then rendered on the GPU. Some of GDI?s rendering is performed on the GPU when the aperture memory is copied to the video memory surface representing the GDI window.
> Existing GDI code will continue to work well under Windows 7. However, when writing new graphics rendering code, Direct2D should be considered, as it takes better advantage of modern GPUs.
Ah you mean by causing cache stalls when doing increments/decrements after each assignment and allowing for cyclic references?
[1] https://developer.apple.com/library/mac/documentation/Genera...
.NET still does GC, it is only the WinRT APIs (something like COM) that manage resources through ref counting. There is some cool interop magic that makes this somewhat transparent to the programmer.
Apple's ARC is a compiler hack. It only works if you happen to use set of Cocoa libraries that are recognized by the compiler and allow for some magic incantation.
You cannot make any Objective-C library ARC aware.
ARC is a good solution for Objective-C, because Apple never managed to have their GC working safely in all situations, given the underlying C type system.
> .NET still does GC, it is only the WinRT APIs (something like COM) that manage resources through ref counting. There is some cool interop magic that makes this somewhat transparent to the programmer.
True, but C++ does not and you still have the performance penalty of reference counting.
The only way to have reference counting with good performance is do what Parasol or Objective-C do, by removing unnecessary increment/decrement operations thanks to dataflow analysis.
Which is something that you cannot do just by using the WinRT runtime and need to rely on the cleverness of the compilers.
Actually, are you aware that reference counting tends to be presented on the first chapter of many CS books about garbage collection as poor man's GC?
I don't understand. How does ARC rely on more than what NSObject provides? I'm coming from the C++ shared_ptr world and ARC does not feel much different so far (less explicit, but easier to optimise).
Just read this document.
https://developer.apple.com/library/mac/#releasenotes/Object...
You need to write code with lots of special cases to be able to have ARC active and not fall into strange compiler errors.
Most of the restrictions (bridge casts and naming methods) are interoperation with non-ARC code, and from working on Java/JNI I can assure you GC<>manual interaction was worse.
It is of course still quite possible to get abandoned memory through retain cycles.
Not very relevant. For UI code, responsive resource allocation and de-allocation is much more important than saving a few % CPU cycles.
> Actually, are you aware that reference counting tends to be presented on the first chapter of many CS books about garbage collection as poor man's GC?
Yes! Sometimes the conventional wisdom doesn't hold in the end, or it doesn't hold for all use cases. But I should have been more clear that ref counting is GC, whereas what I refer to as GC involves sweeping reference roots periodically to identify garbage.
> Not very relevant. For UI code, responsive resource allocation and de-allocation is much more important than saving a few % CPU cycles.
I beg to differ. I consider missile control radar systems of military applications a bit more important than UIs.
There are military applications using real time GC systems, which I can list here if you want.
I also have a German magazine here (Making Games Magazin 1/13) that explains how Witcher2 for the Xbox 360 makes use of a GC.
Anyway one thing I do agree, automatic memory management, regardless of the form, should be the any of any programming language.
Pure manual memory management should be treated like Assembly. It will never go away and should only be used for the very few cases where there is no other way around the problem at hand.
I should have mentioned that the primary reason WinRT seems to use reference counting is for interop reasons: its much easier to great a UI toolkit that is programmable in both C# and C++. Note that WPF never had a C++ interface, while WinRT has one without the need for any bridge code.
Reference counting has some interesting applications where it is more appropriate trace-based GC. Heck, sometimes we want old-fashioned arenas (Pascal!), it would be nice if our languages could give us some choices.
Manual memory management is annoying but sometimes necessary. I can see why native programmers don't want to give it up as it constitutes the primary performance difference these days between native and managed languages.
As for not allowing cycles, I consider that a feature. The headache of memory management doesn't go away with GC. You still have to avoid inadvertently keeping references to objects through the undo stack & so on. Unintentional strong refs creep through GC code just as easily as memory leaks creep through code with manual memory management. Almost universally, I find that GC'd projects large enough to have memory management best practices implicitly do away with this freedom at the first opportunity by calling for acyclic or single-parent object ownership graphs. These restrictions primarily make it easier to think about object lifecycle -- the fact that they allow refcounting to suffice for memory management is icing on the cake.
The Rust compiler does this. Even so, 19% of the binary size in rustc is adjusting reference counts.
I am not exaggerating this. One-fifth of the code in the binary is sitting there wasted adjusting reference counts. This is much of the reason we're moving to tracing garbage collection.
All of those optimizations that you're talking about (for example, packing reference counts into the class pointer) will make adjusting reference counts take even more code size.
> As for not allowing cycles, I consider that a feature. The headache of memory management doesn't go away with GC.
The fact that memory management is still an issue doesn't mean that we shouldn't make it work as well as we can.
In large software projects, cycles are a persistent issue. Gecko had to add a backup cycle collector over its reference counting framework, and observed memory usage decreased significantly once it was implemented.
Hopefully in future versions of PyPy an even better garbage collector. :-)
This means each increment/decrement is a virtual method call with the corresponding invocation costs.
This is why the .NET runtime caches the WinRT objects, and even re-uses them instead of making a 1:1 use like C++/CX does.
Am I understanding you correct; are you implying that you think XNA was created by juniors? Would you say that because of this, it's a good thing XNA is being killed?
Cause personally I think it's been a terrible decision by Microsoft to kill XNA. A lot of indie game developers have relied on XNA and I really feel Microsoft can use the indie support. Sure, big name games might be a priority, but personally I feel most _interesting_ work is being done by indies. Indies tend to be less concerned with proven formulas and seem to see it more of a creative outlet for themselves[1]. I think it's a good thing frameworks like Monogame[2] exist, so developers can still put their existing XNA knowledge to good use - and not just limited to the Windows platform, but e.g. iOS and Android as well.
The Monogame website might not show very impressing examples, but a game like Bastion[3] was ported to other platforms using Monogame, showing very high-quality work can be created with XNA.
[1]: http://www.youtube.com/watch?v=GhaT78i1x2M
[2]: http://monogame.codeplex.com
[3]: http://supergiantgames.com/index.php/2012/08/bastions-open-s...
I will say all of the ex-Microsoft folks I've encountered at Google Seattle have been fantastic.
On a related note, it's stupidly easy to get code accepted by another team at Google.
Also we're hiring.
Insult to injury? ;)
It does take a ferociously long time to get through the initial screening if you just send them a CV, and I'm sure a lot of people fall through the cracks - my suggestion would be to find a Googler or Xoogler and ask them to recommend you, I understand you get a lot more traction that way. Chin up.
I find it doubtful that your lack of education alone is what's keeping you from getting a callback. Do you have a portfolio linked from your resume? Have you got friends that work for these companies that are willing to go over your resume with you?
Bah... my friends keep referring me, but recruiters never seem to like it... ;-)
Unless that other team is Android. Though then you could submit to AOSP directly (assuming the issue you are addressing wasn't fixed internally 4 months ago, but how would you know?).
He's also slightly off-base on some of the technical criticisms: there are often good reasons for doing things a certain way, and these reasons aren't always immediately apparent. Besides, change _does_ happen: Arun Kishan (who is smarter than I'll ever be) broke the dispatcher lock a while ago (see http://channel9.msdn.com/shows/Going+Deep/Arun-Kishan-Farewe...) when nobody thought it could be done.
One of the issues the author seemed to be alluding to is that the loss of experienced developers makes it really hard to keep track of "line 123 of foo_dispatch.c does this because of vital business reason xyz or compatibility reason uvw" and "line 123 of foo_dispatch.c was written while I was hungover and trying to make a deadline--it looks clever, but feel free to junk it.".
This issue is compounded when you are hiring safe, and you have a culture where making gross fuckups while trying to make progress is discouraged. It is neither good nor bad--after all, I too enjoy using stable software--but there is a price to be paid if devs don't feel comfortable making breaking changes.
Now, once you set up a system where people play it safe more than they innovate, you'll get a situation where all of the best programmers will want to leave because it's boring, and you're left with mediocre programmers who aren't good enough to be bold and innovative. This is exactly what the OP describes.
(That's literally the explanation for PowerShell. Many of us wanted to improve cmd.exe, but couldn't.)
Ahh, I was wondering about that. So, I guess I'll just keep using cygwin.
On another note, I recently asked a friend who works at Microsoft how work is going. His reply: "Well, it's calibration time, so lots of sucking up to the boss." Must be hard to get much actual work done when you're worried about that all the time.
I do wonder, however, whether 'boo! MS's rating system is suboptimal, to say the least!' is a very useful comment here (which might by why we haven't seen Michael write here yet)
It's useful, sure, but nice? I'm not convinced.
How about an empty recycle bin command? Why, certainly, you can do that:
$Shell = New-Object -ComObject Shell.Application
$RecBin = $Shell.Namespace(0xA)
$RecBin.Items() | %{Remove-Item $_.Path -Recurse -Confirm:$false}
Every time you have Win32 spilling over in Powershell, it looks like crap (0xA).
Though I don't use Trash/Recycle myself, to contrast, I like the simplicity of
rm -rf ~/.local/share/Trash/info ~/.local/share/Trash/files tell application "Finder"
empty the trash
end tell dbus-send --print-reply --dest=org.gnome.Nautilus \
/org/gnome/Nautilus \
org.gnome.Nautilus.FileOperations.EmptyTrash gci \'$Recycle.Bin' -Force -Recurse | ?{-not $_.PSIsContainer} | Remove-Item -Forcebut there is no way in hell they can/ever will or want to write powershell.
Absolutely basic stuff, like "find the path of this file" (%~dp0 in batch) is a 5 line copy-paste. Why? It's lovely that I can pipe .NET objects places, but every time i want it to actually do something, I end up in copy-paste hell.
As an intern I find this slightly offensive. ;)
I thought you just needed to do something like: $(ls $PSCommandPath).Directory
(Not that that isnt longer than %~dp0; but I am curious what the 5 lines actually does)
function Get-Script-Directory
{
$scriptInvocation = (Get-Variable MyInvocation -Scope 1).Value
return Split-Path $scriptInvocation.MyCommand.Path
}
[1] http://stackoverflow.com/questions/5466329/whats-the-best-wa...
Sidenote: if something like node.js, entirely designed for fast asynchronous networking, despite all its callback hell and whatnot, is a better and more user-friendly Windows scripting host than Powershell, some people really should start to worry.
Maybe if Powershell had something like npm, including its (simply perfect) install-to-current-directory-by-default, people could fix all the holes MS left behind. I might even start to like it then.
It might have been better to rewrite his post into your own words, and take out some of the unnecessary detail, rather than literally repost.
We didn't delete it. It was deleted by whoever posted it.
No, they do not. Specifically, I have showdead on, and when trying to view the comment in question, I see only "[deleted]".
then
>We occasionally get good people anyway
Uh... nine-to-five-with-kids type here. Thanks for the stereotyping... from your safe corporate nest.
Otherwise an insightful post.
I understand the reason this fiction is maintained: people with kids need the job even more than people without, and have an interest in denouncing people who claim kids make you less productive. There's also the second order effect in which "with kids" is correlated with "older".
The net of it though is that devs with kids tend to assign work a lower priority, to take fewer risks, to need more money, and to be older and hence less familiar with new technologies (and too busy to learn in their free time).
Society doesn't have a good answer for this situation yet. In times past, technology didn't move so fast that experience was mostly obsolete (and hence useless) in a decade's time. A 40 year old farmer with kids in 1713 would probably have much to teach a young whippersnapper. The same isn't true for a 40 year old programmer with kids in 2013.
For the idea that parents and older programmers have different priorities, that may be true, but you downplay experience way too much. That said, trying to find 150% dedicated younglings, that don't spend a lot of time on side projects and just enjoying life is not that easy either
"Maturity" is an ambiguous and contextual concept that doesn't usually mean anything - people should be rated by objective attributes like experience, productivity and so on. One could also say that a younger person with more and harsher life experience can be more "mature" than someone older and with kids (think someone who raised his/her little brothers by mistake after the parents got killed or something like that), but with less impacting experience but it would be just as meaningless because of the ambiguity of "maturity" (how much is life experience relevant to a programmer?). Raising children teaches one useful "life things", but so does starting a business, travelling around the world or working for the red cross in Africa. Adding insult to injury, managers tend to use "maturity" when referring to employees as "ability to take orders and act predictably even if not particularly creative" which basically makes it an "antiquality" for a small fast startup.
I'm 28, which means I'm young enough that even people like you believe I can learn new tricks. As far as I can tell, my brain is still fully functional. That said, most of what I use every day, I learned over ten years ago. Computer science never gets old. The notion of indirection is never obsolete. The mental machinery required to navigate up and down in an abstraction hierarchy is universal. Sure, I learn new APIs every day, read about new programming paradigms (hey, functional reactive programming is cool), and so on, but I learned all the basics way back when.
Would you say that all my older experience is worthless? If your hypothesis were correct, I should be able to say that what I'm learning now is more important than what I learned in 1998, and that's just not true.
Most of the assumptions you've made don't apply to me, a 40 year old father of two. It may very well apply to some people similar to me. This is the problem with stereotypes and the problem with people perpetuating them. Oversimplifications are a shoddy mental crutch to deal with the complexities of reality.
The older you get, the more experienced you become, the better decisions you make, the more valuable you become.
At 22, I was a great tactician. I could code faster than anyone else.
At 32, I'm a moderate strategist. I code slow than when I was at 22; but my productivity is far higher.
At 52, I hope to be a great strategist. The potential is frightening.
3 hours of sitting thinking about a problem, then 30 minutes of coding. I would never have done that at 20, I'd have opened an editor and started typing because I was still learning the intricacies of the platform.
In my late teens/early twenties, I just implemented the first thing that I could think of.
Back then it was much easier.
Actually, I have noticed that other developers around my age still think like I did when I was in my twenties. Maybe it's because I've been coding since I was 10 (22 years!) and full time since I was 17, and most came in after university?
Then there is the argument about blindly learning to code from BAD code on the internet, whereas we had to learn from books! :)
I hope the explanation for your post is that you're 17. This blatant generalization is idiotic and useless. Reading that reply is a denial of service attack on productive thought.
This is brilliant!!
What? New workers enter the workforce.
To a first approximation, all this new "web technology" is just a way of doing what you could've done on an internet-connected NeXT machine 20 years ago, only more brain-damaged and frustrating to work with.
The only place technology has advanced in that time period is in domain-specific areas (which of course requires experts, not young whippersnappers), and infrastructure (the world looks a lot different for computers with pervasive 4G--the software is just an adaptation of proven concepts to uses enabled by innovative hardware).
Programming is applied mathematics, and that hasn't changed substantially since people were developing software on punch cards.
That wouldn't have been possible without the web. The web technologies you decry are more irritating in many ways than any one specific proprietary system from 20 years ago, but that ignores some of the huge benefits of openness and standards and platform independence.
I can write a program and have it run without modification on my phone, on an embedded computer running sensors, on a tablet, on my laptop, my desktop computer, my hifi, my network hard drive, a huge server being rented to me on the other side of the world. I can even make it easily distributable so it can run safely on other peoples computers who don't fully trust me. It's unimaginable that any proprietary system from 20 years ago would have been able to produce that state of affairs.
Speed of interpreted Javascript has improved by two orders of magnitude on the same hardware in the last ten years, and you don't see technological advance? I can't think of another field that has advanced so quickly.
I don't want to diss other fields, but an awful lot of the most valuable improvements in infrastructure in the last ten years have been about standardization and bringing technology that existed years ago to the masses.
On top of that, the inconvenience of the Web platform is real but also overhyped. Imagine you're writing a network app in another platform. It's extremely unlikely you have access to an integrated network analyzer as good as chromes. How many other systems allow you to completely modify the look of your application while it's running just to see how it looks by playing with the developer tools? Having a repl that allows you to interact with the running system has been standard on the Web platform for ever.
I'm not even sure what you're looking for. What would constitute new technology if 100x speed ups don't? Almost all of software is implied in the concept of the Turing machine so complaining that you can't achieve anything you couldn't have in the past with large, expensive, proprietary systems and specialized knowledge seems unfair. It's been true since Babbage at least.
That's what Java was about. According to http://en.wikipedia.org/wiki/Java_(programming_language) it appeared 1995 - 18 years ago.
Java failed badly at its dream and ended up adopting an entirely different niche to what was expected.
But you're right, I shouldn't have said 'unimaginable'. I suppose it's just about possible that if java had 'won', we might have ended up with something not massively dissimilar to what I described.
Given that list, what would you consider obsolete now? It's been 2 decades, not 1, mind you. Asm? Well, the last time I touched this sword for a reason was 2005 and it was SSE assembler, something that compilers were not able to generate efficiently then (and to the large extent still not able).
char *strlwrmmx(char *buffer,int len=-1)
{
if (len==-1) len=strlen(buffer);
unsigned __int64 a=0x4040404040404040; // 0x40='A'-1
unsigned __int64 z=0x5B5B5B5B5B5B5B5B; // 0x5B='Z'+1
unsigned __int64 c=0x2020202020202020; // conversion offset for lowercase->uppercase
asm {
mov edi,buffer
mov ecx,len
convblock:
cmp ecx,8
jl rest
movq mm4,c // Eight copies of conversion value
movq mm2,a // Put eight "A" characters in mm2
movq mm3,z // Put eight "Z" characters in mm3
movq mm0,[edi] // Get next eight characters of our string
movq mm1,mm0 // We need two copies
pcmpgtb mm1,mm2 // Generate 1's in MM1 everywhere chars >= 'A'
pcmpgtb mm3,mm0 // Generate 1's in MM3 everywhere chars <= 'Z'
pand mm1,mm3 // Generate 1's in MM1 when 'A'<=chars<='Z'
pand mm1,mm4 // Generates $20 in each spot we have a l.c. char
paddb mm0,mm1 // Convert uppercase chars to lowercase by adding $20
movq [edi],mm0 // Store back in buffer
sub ecx,8
add edi,8
jmp convblock
rest: // convert any left characters one by one
cmp ecx,0
je done
convchar:
mov al,[edi]
cmp al,'A'
jb skip
cmp al,'Z'
ja skip
add al,0x20
mov [edi],al
skip:
inc edi
loop convchar
done:
}
return buffer;
}The indexer had to chew huge amounts of text, so the quicker the lowercasing, the better.
Where do you think bad, old developers come from? Well, they started off as untalented young developers. Right now now there are young developers who are awesome and others who suck and will one day become crappy, old developers.
I could go on about stories where youth and inexperience led to disasters. They would be just as one-sided as talking about old developers who are out of touch. Who do you think it is that's creating all if the tools that you use?
It's about the work.
Somehow, despite having kids, I manage to learn new technologies, even insofar as I was able to write a book about it (Dart in Action). The only reason I had time to do that is because I try to keep my day job between 9-5.
2. People with children have a better understanding of what responsibility is.
3. People with children usually spend less time on dating and going to bars :)
4. We tend to be more time efficient
Were you parents rubbish slackers because they made the mistake of having you? Or did they work so hard they forgot to bring you up well?
Having kids can put a lot more structure into a life that was missing it before. 20-somethings without kids are usually the ones late in in the morning, missing standups, or the ones working while hung over.
I'm sure that it is possible to get someone who is so dedicated to their work that they have no life at any age. Whether or not this is a good idea for your company is a different question.
I know of very few other jobs were you are supposed to spend so much of your spare time reading up on new stuff as the IT-business. A few of my friends are physicians and they to spend their spare time reading up on new stuff. Others, not so much.
I don't think this is a sustainable way of doing business in the long run.
Your whole post drips with resentment-fueled bigotry and ignorance, making me wonder if you're fighting for attention at your workplace or whatever, feeling unloved. Here's an internet hug. Hugz.
Many years back I -- a new graduate employee -- was chatting with my boss, who was a part owner of the company/president. He had five kids, or maybe even six. He asked me when I was thinking of having children (it was still too early for me, but just as a conversational thing), and my honest answer was that I didn't know how he could afford it.
He then told me about an Arabic parable or the like that each child comes with a bag of money.
That seemed counter intuitive to me, but my life has proven it out. I now have four children, and I would wager good money that I know more current technologies, in much more depth, than you do.
If you have the capacity, having children has a profound ability to make you focus: While I am the same intellectual being, like the vast majority of developers I was absolutely pissing time away before children, and I doubt I passed even 5% productivity. Slashdot was the Reddit of the time, and doing asinine, meaningless implementations for days on ends was just a normal day. And I know this is the case for most developers.
Now I don't have time for the bullshit. I focus specifically on the things that yield success, in the most efficient manner possible. I'm still only maybe 15% productive (still piss away a lot of time), but the result is my own company, a lot of success, etc.
Its hard to remember life before kids, but one thing I know for sure: I wasted a huge amount of time.
I work far more effectively at 39 than I did in my 20's. And my ability to focus took a massive boost after becoming a father.
I still waste time, but I've never been more productive. I work full-time, have my own company in my spare time, and my child at every moment he's awake.
I can see how an empathetic person having children would increase their focus to succeed, but what is the limit on the number of kids? How would one know when to stop having kids? Why did you stop at four kids? Are you going to have more?
We didn't expect our third child, or the fourth for that matter. That's life though, and I'm a very roll with it sort of person and am extremely pleased with how things have turned out.
Of course I am speaking from a very privileged position of happening to have the right sort of mind at the right moment in history in the right situation where I can talk about pissing most of my time away and still achieving what many would consider a lot of success. This obviously doesn't apply to all careers or all people.
I am not young. I've been attending funerals recently, and meeting family members I have not seen for 30+ years. None of us were comparing notes about our productivity.
The first was in search and distributed systems, at Google, and the blueprint for their systems was created by two mid-career engineers out of DEC.
The second was the evolution of the smartphone, at Apple, an old company that is known for keeping its engineers for a long ass time.
The most innovative computer language we have was designed in the 50s, and every time I meet an old-time hacker, there's something I can learn from them.
The real lie is that a kid out of college who starts a company is automatically considered an innovator. Rehashing an idea one more time in a slightly more marketable way or creating an app that goes viral has nothing to do with innovation.
In the pop culture age, we constantly confuse the Britney Spears' of the world with real talent, and the Summly's of the world with real innovation.
As people get older, they get more experience, which is good. They are also more likely to have a family. Is that supposed to be bad?
I've seen a number of open-source projects where you get all the personal glory for your additions but there is nobody who takes the responsibility to tell people "no". These projects, almost universally, turn into bloated messes over time. Open-sourced computer games seem to fall down this path more easily, since everyone and her little dog too has ideas about features to add to games.
I just listened to an episode of Roguelike Radio from the mid-30s (maybe the one with Red Rogue or Thomas Biskup) and Andrew / Keith (IIRC) go on and on about how all the "major" roguelikes are just accretions of features.
This rings very true to me; I grew up playing Nethack [0], and Slash (and then Slash'Em) just got silly with all the things they were adding. Light sabers ? In my roguelike ? Come on, fhgwgads. Nethack at least has a mysterious Dev Team who ostensibly are the guardians of quality... but they _did_ bring Sokoban back from Slash'EM into vanilla.
[0] since Nethack was my first roguelike, I didn't realize until lately just how crappy it is in many ways, most notably that it's very difficult to win before you've figured out all the sources of instadeath (whether you've figured them out by spoilers (written or source-diving) or through (really frickin hard-won) experience).
In particular, brogue's food clock is excellent in that if I forget about it too long and go back to my natural "explore everywhere, kill everything" tendency, the food clock _will_ kill me.
[0] something that jumped out at me is just how much modern roguelike development is windows-first (or even windows-only), and how much of it is distributed primarily as runnable binaries vs source. I had to bend way over backwards to get PrincessRL running: I ended up installing a 32-bit ubuntu userspace virtualbox instance so that mono could run the prepackaged binary.
But I digress. POWDER feels very much a designed roguelike, not something that evolved.
I started to understand better how Microsoft works, after getting into the Fortune 500 enterprise world.
Many of the bad things geeks associate with Microsoft are actually present in any development unit of big clunky Fortune 500 companies.
That always wipes the smug grin of their faces.
While I agree with you, nothing could wipe the smug grin off these persons' faces. They are beyond reality, and I'd be much happier with America if something so simple could give the "socialists are universally lazy" rabble whenever labor rights are mentioned in any sense.
Linux does this motherfucking bullshit too. "Oh, systemd is piss slow? We'll bung d-bus straight into the kernel, right along side the over 9000 other IPC mechanisms. Everybody uses d-bus these days, it's an Essential System Component. What? Systemd is a crap idea to start with? People like you should be committed."
Besides: you guys have systemd, which if I'm going to treat it the same way I treated NTFS, is an all-devouring octopus monster about crawl out of the sea and eat Tokyo and spit it out as a giant binary logfile.
The author isn't far off. He's over the top on some things, but on the whole it's a good take on some of the reasons Microsoft culture is toxic.
My take:
1. The review system needs to be fixed. They have to stop losing good engineers.
2. They have to somehow get rid of a bunch of toxic people. Many of these are in management. It's hard.
3. They have to stop treating Windows as "the thing we put in all the other things".
Windows is a fine OS; it could be better, and the OP points out a lot of reasons why it isn't. But it's not a great fit for embedded systems, nor game consoles, nor anything where you're paying for the hardware.
But I keep coming back to the review system rewarding the wrong people, causing good people to leave. The underlying backstabbing and cutthroat culture needs to go; it's hurting the bottom line, and I'm surprised the board has been willing to let it happen.
That's exactly the problem that's plaguing Google Chrome right now, although probably for a different reason, as many senior developers still seem to be on board. Google keeps adding new features at high pace and doesn't care what brakes in the process. The amount of unfixed (albeit mostly minor) bugs is huge.
That Microsoft discourages individual junior developers from cowboying, is a point in their favor. Optimization for its own sake is not what benefits their users - real research does.
I thought Microsoft refusing to update their decades behind, ancient C compiler was just to piss me off and make life difficult cross-platform developers that need to work in C. Interesting to see this applies to their own employees too.
Microsoft's position in the market is already big enough that they'll never really be proven wrong on C unless they relent. But they're also not large enough to kill it outright.
I just remembered Microsoft wrote this scathing document: C++ for Kernel Mode Drivers: Pros and Cons http://msdn.microsoft.com/en-us/library/windows/hardware/gg4...
I didn't find an actual pro. Makes sense that a Microsoft Kernel developer would also be frustrated by their lack of modern C support.
One of the reason businesses have trouble really innovating is that it's hard in a business to work on long-term things when markets are very short sighted. Only mega-corps, monopolies, and governments can usually do that... or hobbyists / lifestyle businesses who are more casual about hard business demands.
That being said, MS is surely cash-rich enough to think long term. So this doesn't apply as much here.
I've also found that of all things optimization almost gets you looked down upon in most teams -- even young ones. "Premature optimization is the root of all evil," and all that, which is usually misinterpreted as "optimization is naive and a waste of time." It's seen as indicative of an amateur or someone who isn't goal-focused. If you comment "optimized X" in a commit, you're likely to get mocked or reprimanded.
In reality, "premature optimization is the root of all evil" is advice given to new programmers so they don't waste time dinking around with micro-optimizations instead of thinking about algorithms, data structures, and higher order reasoning. (Or worse, muddying their code up to make it "fast.") Good optimization is actually a high-skill thing. It requires deep knowledge of internals, ability to really comprehend profiling, and precisely the kind of higher-order algorithmic reasoning you want in good developers. Most good optimizations are algorithmic improvements, not micro-optimizations. Even good micro-optimization requires deep knowledge-- like understanding how pipelines and branch prediction and caches work. To micro-optimize well you've got to understand soup-to-nuts everything that happens when your code is compiled and run.
Personally I think speed is really important. As a customer I know that slow sites, slow apps, and slow server code can be a reason for me to stop using a product. Even if the speed difference doesn't impact things much, a faster "smoother" piece of code will convey a sense of quality. Slow code that kerchunks around "feels" inferior, like I can see the awful mess it must be inside. It's sort of like how luxury car engines are expected to "purr."
An example: before I learned it and realized what an innovative paradigm shift it was, speed is what sold me on git. The first time I did a git merge on a huge project I was like "whoa, it's done already?" SVN would have been kerchunking forever. It wasn't that the speed mattered that much. It was that the speed communicated to me "this thing is the product of a very good programmer who took their craft very seriously as they wrote it." It told me to expect quality.
Another example: I tried Google Drive, but uninstalled it after a day. It used too much CPU. In this case it actually mattered -- on a laptop this shortens battery life and my battery life noticeably declined. This was a while ago, but I have not been motivated to try it again. The slowness told me "this was a quick hack, not a priority." I use DropBox because their client barely uses the CPU at all, even when I modify a lot of files. Google Drive gives me more storage, but I'm not content to sacrifice an hour of battery life for that.
(Side note: on mobile devices, CPU efficiency has a much more rigid cost function. Each cycle costs battery.)
Speed is a stealth attribute too. Customers will almost never bring it up in a survey or a focus group unless it impacts their business. So it never becomes a business priority.
Edit: relevant: http://ubiquity.acm.org/article.cfm?id=1513451
Optimizing the right thing is good, but figure out what that thing is first.
But in what timeframe? The article seems to imply they are thinking only about short term value and ignoring medium and long term.
The fundamental assumption of the article - that the Windows kernel should strive toward the Linux kernel management model is patently absurd.
FOSS is free as in "free to break software that depends on your code."
I think a good analogy is centralized government economies vs private enterprise economies. The less people you have making key decisions and the more isolated you are from the effects of bad decisions, the easier it is to evolve and improve.
Obviously open source has a lot of failures and took a long time to catch up in certain areas. But things like the Linux kernel have become a massive, unstoppable force that's evolving quicker and more efficiently than ever before. Microsoft simply can't compete with the hundreds of companies and tens of thousands of developers working on it.
I think this is a little unfair; the specific example is the Linux kernel where enormous emphasis is placed on never breaking userland.
It's also for experienced programmers who dink around with macro-optimizations. For example, designing an entire application to be serializable-multi-threaded-contract-based when there's only a handful of calls going through the system. Or creating an abstract-database-driven-xml-based UI framework to automate the creation of tabular data when you have under a dozen tables in the application.
premature optimization is the root of all evil is a really really important mindset, and I agree it doesn't mean to not optimize, and many developers seem to take it that way.
X+1 = How many transactions your business does today
Y = How many transactions your business needs to do in order to survive
Y/X = What the current application needs to scale to in order to simply survive. This is the number where people start receiving paychecks.
(Y/X)4 = How far the current application needs to scale in order to grow.
The goal should be to build an application that can just barely reach (Y/X)4 - this means building unit tests that test the application under a load of (Y/X)4 and optimizing for (Y/X)4
Spending time trying to reach (Y/X)20 or (Y/X)100 is what I'd call premature optimization.
Disclaimer: (Y/X)4 is no real point of data that I know of, just something I pulled out as an example, anyone who knows of actual metrics used please feel free to correct.
'Optimization hinders evolution.'
I've got the wrong closure over HN.
66. Making something variable is easy. Controlling duration of constancy is the trick.
http://www.cs.yale.edu/quotes.html
Archive.org's backup of the [behind a paywall] ACM article:
http://web.archive.org/web/20080513191245/http://www-pu.info...
And if optimization always hinders evolution, boy should Windows be evolving... I mean... the NT kernel should have smashed through all kinds of antiquated paradigms by now. It should be doing memory deduplication, disk deduplication, fast JIT compilation of binaries for alternative architectures. It should support live process migration between machines, joining of systems together efficiency to form larger super-systems, a better permission model obviating the need to rely completely on virtualization for true privilege isolation in enterprise environments. It should have truly efficient network filesystems supporting disconnected operation, sharding, etc.
Oh wait... it's stuck in the 90s... never mind. And it's slow.
Linux, which optimizes a lot, has at least some of the things I mentioned above.
"Premature optimization is the root of all evil" is a deeply nuanced statement that is nearly always misunderstood. "Optimization hinders evolution" is probably likewise. They're quotes cherry-picked out of context from the minds of great craftsmen who deeply understand their craft, and alone I do not believe they carry the full context required to comprehend what they really mean. I think they have more to do with maintaining clarity and focusing on higher-order reasoning than they do with whether or not to try to make things run faster. (And like I said, the most effective optimizations are usually higher-order conceptual algorithmic improvements.)
Windows isn't slower at running Windows apps, fitting into a Windows infrastructure (Active Directory, management tools, Exchange etc), using Windows device drivers, working with NTFS volumes and their features, backwards compatibility, printers etc.
It all comes down to what the goals of the users (or purchasers) are, and I doubt anyone buys Windows because of "performance" in the sense being talked about. But they do care about the "performance" of items mentioned in my previous paragraph.
Linux has been able to optimise because of being open source and vehemently ignoring closed source. Open source means for example that the Linux USB stack could be optimised and all affected code due to API changes could be updated. This and other topics are covered really well in Greg Kroah-Hartman's OLS 2006 keynote - http://www.kroah.com/log/linux/ols_2006_keynote.html - see "Linux USB Code" about halfway down for that specific example.
I'm not an experienced programmer, and I'd use that approach anyway, simply because it makes sense (is there any alternative that isn't worse?). What does that mean? (Oh, and I'd skip XML. I abhor violence.)
Just bite the bullet and render them by hand. It'll take less time than writing the abstract whatever-driven autogenerated UI framework, making it lay things out nicely, handle all the corner cases and auto-wiring of stuff which might not be needed in all cases, and tweaking the generated code to look good for all the data.
For small applications, dynamic form generation infrastructure dwarfs the actual business logic. It means writing a lot of code which isn't solving your business problem.
Your project has an extra layer of 'meta'. It's harder to debug. It decreases flexibility. Validation is hard for multi-field relationships. Special-casing that one form can require major infrastructure changes. The approach tends to be slower and buggier than the naive approach for all but the most form-heavy applications.
Also, why would an extra layer of 'meta' make it harder to debug and decrease flexibility? I would have thought that it would enforce more structure by centralizing certain functionality, thus making it correct-by-design instead of relying that you'll follow conventions in multiple places consistently, and increase flexibility by separating aspects that you'd otherwise have to "weave-in" throughout the code and later change in multiple places.
Yes, it's an interesting problem. That's exactly what makes it fly paper ;)
Less flexible: suppose your framework is doing dynamic form generation on top of wxPython. You could have a date picker as a radio box item if you wanted. However it would probably not a be a good use of time to support that in your MDA system.
Harder to debug: Usually, bugs in the auto-form-generation infrastructure are "trickier" than the bugs you would get if you just wrote the forms.
A lot of the use cases for dynamic form generation are adequately served by automatic scaffolding in django/rails/turbogears or on the enterprisey side, technologies like Oracle forms and its successors.
And for those corner cases, code them as one-offs but within the templating system, and keep the benefits of any logging etc from the system.
> It's also for experienced programmers who dink around with macro-optimizations.
The hilarious thing is that everyone seems to think everyone else's optimizations are premature.
Don't believe me? Just go ahead and ask someone an optimization question, like maybe on StackOverflow. Those who respond might not know you, but I'll be damned if their first reply isn't to tell you that you probably shouldn't even be optimizing in the first place, because obviously if you'd thought about it more carefully, you'd have realized it's premature.
Do you have to spend all your time and resources architecting the system poorly the first time, just to "prove" that you are wrong -- even though you knew it would happen before you even started coding?!
That's like telling an engineer to prove (by actually building it and subjecting it to a lot of stress) that the bridge he designed would be prone to collapsing before helping him find a better design!
So where does he back up the claim that NT kernel performance is, in fact, "behind other OS"?
EDIT: redacted information. Still, when that information we present, how would anyone be able to confirm it?
> The NT kernel is still much better than Linux in some ways --- you guys be trippin' with your overcommit-by-default MM nonsense
What's wrong with the overcommit-by-default behaviour? Or how/why the NT kernel is supposed to do better?
A lot of people seem to think you're screwed when you're out of memory and so think killing the process is acceptable, but I've worked on code bases where it's actually handled somewhat gracefully. (Although, on NT, if you run out of nonpaged pool you start to get weird, random I/O failures.)
vm.overcommit_memory = 2
see https://www.kernel.org/doc/Documentation/vm/overcommit-accou...
I guess there's another, somewhat social aspect of making that the default: everyone else coding on the platform assumes the behavior is the other way, so I suspect when you set that flag to off, your other software starts crashing on null pointer dereferences because no one thinks malloc can fail.
"Unicode-enabled functions are described in Conventions for Function Prototypes. These functions use UTF-16 (wide character) encoding, which is the most common encoding of Unicode and the one used for native Unicode encoding on Windows operating systems. Each code value is 16 bits wide .. New Windows applications should use UTF-16 as their internal data representation."
ugh
With all of these facts being true (I hope), today things are such that the Windows world mostly (but not completely -- they sometimes assume two-byte characters) correctly implements UTF-16, while the Linux world correctly implements UTF-8.
Working for several different Fortune 500 companies this has been my experience many times. I have worked on products where I made a large number of incremental improvements that never got incorporated into the released product. Taken on their own the improvements don't change things much, but in the aggregate they make a significantly better product. Why didn't most of my incremental improvements get incorporated into the product? Every change, no matter how minor, is perceived by management to be a highly risky proposition. Product managers won't get promoted because the product is 4% better, but they could potentially get fired if that same incremental improvement had an unforeseen negative consequence.
Once the short term sales mindset gets power, hit products are viewed as cows to be milked and not as things that need continued maintenance and improvement. As an engineer in such an enterprise you watch helplessly as your competitors slowly but steadily pass you, and then someday upper management wonders why the magic money machine broke down. Some large enterprises avoid this fate but they seem to be the exception.
Now the problem is not so much the kernel, but all the cruft a Windows-based OS drags along with it. The most visible symptom is the amount of storage used up by stuff that adds little or no readily apparent value to Windows RT.
Windows OSs are heavy compared to Android and other Linux-based OSs. That means inexpensive tablets and phones won't run Windows, and Windows is shut out of mobile device markets in India, Africa, and other developing areas. These markets are how Yulong (who??!!) became a top 10 mobile OEM.
OS X didn't change the world by bringing some great new underlying architecture to the table. In fact, their kernel and filesystem are arguably getting long in the tooth. The value that OS X brought to the table was the fantastic Carbon and Cocoa development platforms. And they have continued to execute and iterate on these platforms, providing the "Core" series of APIs (CoreGraphics, CoreAnimation, CoreAudio, etc.) to make certain HW services more accessible.
There's very little cool stuff to be gained in the windows world by developing a new kernel from scratch. A quantum leap would not solve MS's problem. The problem is the platform. What's really dead and bloated is the Win32 subsystem. The kernel doesn't need major tweaking. In fact, the NT kernel was designed from the beginning such that it could easily run the old busted Win32 subsystem alongside a new subsystem without needing to resort to expensive virtualization.
Unfortunately, the way Microsoft is built today it have a fatal organizational flaw that prevents creating the next great Windows platform. The platform/dev tools team and the OS team are in completely different business groups within the company. The platform team develops the wonderful .NET platform for small/medium applications and server apps while the OS team keeps crudging along with Win32. Managed languages have their place, but they have yet to gain traction for any top shelf large-scale windows client application vendors (Adobe, even Microsoft Office itself, etc.) Major client application development still relies on unmanaged APIs, and IMHO the Windows unmanaged APIs are arguably the worst (viable) development platform available today.
What Windows needs is a new subsystem/development platform to break with Win32, providing simplified, extensible unmanaged application development, with modern easy-to-use abstractions for hardware services such as graphics, data, audio and networking. This is starting to come to fruition with WinRT, but the inertia in large scale apps is unbelievable.
A lot of the justification for being exceedingly conservative about performance improvements was based on the difficulty of doing testing that is sufficient to leave no doubt that changes don't cause regressions nor any side effects bearing on compatibility.
I'm surprised that hasn't changed, or that the value equation about possibly breaking customer software hasn't changed. By now this approach must be a very entrenched culture.
Linux on the other hand is a disaster. The kernel devs are so determined to break binary compatibility, I haven't been able to run with ATI's proprietary binary drivers for years. While AMD was a good open source citizen and released the specs, the open source drivers for my card are useless for anything other than 2D.
Great words for concluding a video game intro
NTFS is highly reliable and Microsoft wants to build on that success with ReFS. In years of working with NTFS I've never had a serious filesystem wreck (although I did have one that was never quite the same after I made a few hundred million small files)
The NTFS story isn't that different from the ext(2|3|4) story on Linux. ext-N filesystems are boring and not particularly fast, but they're reliable. I've tried other filesystems on Linux but have often had wrecks or noticed data corruption.
I like boring filesystems.
Whee. Talk about a downer to start my day.
Besides, even if everything is as bad as they say and you absolutely cannot work in that environment, interning is the perfect time to discover that without as significant commitments. It will also prove to be a valuable lesson that you can then take to other companies.
Chin up, I'd love to work even at Microsoft.
in the post PC era Kernels are not as hot as they were in 2000
Azure is the new Windows.
Growing pains, all around.