The Google Chrome Comic (2008)
scottmccloud.com
scottmccloud.com
Anyone remember what it was like to open Chrome for the first time in '08 or so? It was incredible. The design was the embodiment of fresh, wide-eyed optimism.
Unfortunately, it hasn't quite worked out that way.
Now that I look it up, apparently the idea started with Safari, but it didn't get much press.
I think the biggest innovation in chrome was how rapidly they shipped. Chrome copy-catted on hardware accelerated rendering and porn mode, but shipped first in both cases.
P.S - I wonder is Sundar figured out how "shipping works at Google" yet.. (https://youtu.be/LRmrMiOWdfc)
But then I actually tried it as a secondary browser for about a week, and fell in love.
Not long after, I finally realized two things: 1. Speed is the killer feature, not just of chrome, but of any software. 2. The auto update feature, on every platform (such as iOS' app store) and browser, was the most ingenious of the two. As a web dev, my biggest worry was the potential chaos, some of which has happened, but waaaay less than I could have ever hoped. They truly did make the updates a first class experience from the developer to the different cases of users.
Now it has all the features, is still fast, and just generally is more awesome than the other windows browsers, and the other mac browsers, and from most of the Linux desktops I've seen, the other Linux browsers.
I know it's a privacy issue and I don't particularly like boosting Google's numbers, but I don't see myself switching away anytime soon.
Don't you still have the same problem with multiple processes, just moved to the kernel for them to deal with? It seems like if you kept everything in-process, you could use custom allocators and apply a sufficiently smart architecture so nothing stayed longer than necessary.
If they are non-contiguous in the kernel it is no barrier to making them contiguous in a process.