EDIT: I'm sure lots of work has been done, not trying to degrade that. Just sharing my experience on my projects, never worked with Chrome.

OS are much larger than kernel, I'd guess all the driver code exceeds the actual kernel.

People always think they code base is large, but having built most of the Call of Duties and many Unreal games, all the OS code I've worked on is trivial in size comparison. There is probably something bigger, but games seem bigger than many major apps in my experience.

Starting with a full build that initially takes hours and it shrinking to < 15-20 minutes and better seems pretty par for the course for truely large C++ projects. You don't get a fast build process for free, but if the team makes it a priority, alot can be done.

EDIT: Times mentioned were for a full build, often you rarely due a full build, incremental builds should be majority. Places that don't make incremental builds 100% reliable drive me crazy and waste so much developer time. This is common, but it's a lame excuse. Just do the work and fix it.

The author mentioned blinking cursor, so it reminded me of graphics issues. A more efficient CPU state has the possibility of slowing an app due to CPU-GPU sync points. A blocking CPU in an energy efficient state can reawaken slower from GPU done notifications, so FPS is lower. So both c-state and p-states can affect performance. General point was just utilization may not be utilization at max power.

I've worked on problems where utilization was 15% at lower power and it was a problem. But to compare different workloads, it'd be < 1% at max power.

Not to take away but the author's point, just an aside that utilization numbers can be a lot more complicated when there are dozens of energy states and the utilization might be utilization at a particular state rather than utilization at maximum power

Motorola rescued Metrowerks from the brink of Chapter 11 with the Apple/Metrowerks relationship already tense. Motorola also gave many long-time employees an excuse to leave (pre dotcom crash). PalmOS took so many people that lawyers were involved at the HR level between Motorola/PalmOS

I vividly remember the reaction of my fellow students. Given the mockery and jokes from my fellow students, you'd think they were watching a bad sci-fi movie. Most students discounted everything they saw, 'real men and real programmers used C'. I remember being so disheartened that it seemed we'd evolved so little in tools/languages from 1979 - 1995.

At the time, everything was Unix and C programming (DEC Alpha were just being installed on campus, Windows 95 had just been released). There were a lot of reasons Unix/C succeeded, there is a great classic paper about why C beat Lisp, and I agree with the author.

However, what always troubled me, is how my fellow students completely ignored any potential learnings from those videos. In many ways, those early Smalltalk programs were far more impressive than anything they had created, but they just wrote them off.

At GDC 2014, a post-mortem was presented on the classic game Myst. That was written entirely in Hypercard.

With regard to only this point, probably half if not more of the the top 15 grossing games on the Mac AppStore Games page today are either Carbon Apps or at minimum require the Carbon framework.

Remember SteamOS was born before Win8 was announced and Valve was scared where MS was going. Steam on Windows seems pretty safe, the pressure is off.

In addition, the release of a few Linux games such as Civ5 & Borderlands, have provided sales figures to those companies on whether the investment was worthwhile.

Many companies considered Linux primarily because SteamBox was an interesting market. While some companies were taking a wait-and-see audience, the slow play of SteamBox only makes more people take a wait-and-see attitude.

The OpenGL mess of "4.4 is good enough", while both AMD & Intel failed to deliver good drivers, is further muddled by OpenGL Next. Basically, accepting the OpenGL API needs a re-write and will become more Mantle/Metal/DX12 like. So will Intel & AMD deliver good-enough 4.4 drivers, or do we all wait for OpenGL-Next. Don't forget that AMD just did a 7% layoff, limited resources.

https://medium.com/@michael_marks/opengl-for-real-world-game...