Taras Glek

First, Rust is a handful of people working on a research project. Electrolysis was "put on hold" because there were better ways to make Firefox a more responsive browser, now. That's projects snappy and supersnappy. See https://wiki.mozilla.org/Performance/Snappy and http://taras.glek.net/ and https://bugzilla.mozilla.org/show_bug.cgi?id=718121 -- the final bug being what I think will make Firefox a great browser again.

The behavior of fsync is a battle of OS developers and OEMs versus application and database developers. Gaming the implementation of fsync to do less than fully fsync makes benchmarks look amazing, improves user perceived latency, and reduces flash wear. On the other hand, it corrupts data - but that's rare, "the hardware is failing anyway", etc. That's how you end up with stuff like OS X's "no really, fsync" param [1], or Motorola shipping nobarrier on their phones. [2] [1] https://github.com/google/leveldb/issues/203#issuecomment-55007291 [2] http://taras.glek.net/post/Followup-on-Pixel-vs-Moto:fsync/

I agree re simplicity of the old way of doing things. There's another benefit that most cgi-bin systems had: lack of build step or exotic runtime requirements. Eg, you'd drop some html into public_html folder and an executable into cgi-bin dir. I would performance engineer some scripts into C++ binaries and just checkout the source & run make to produce binaries in-place. This approach made it easy to use local dev tooling to test/debug stuff instantly via oldschool emacs TRAMP/sshfs. There is a system that replicates the simplicity of what we lost (while letting you use fancy modern JS frameworks): https://www.smallweb.run/. It also offers a path to cloudflare-like edge computing migration without any code change via deno deploy. With smallweb, one drops a bunch of files into own dir (eg, you could give a dir to each student), which results in https://<dir>.domain.name running stuff ondemand in that dir. No build step, no exotic runtime to transpile into, full ability to use local dev tooling to test/debug stuff instantly. It's still early days for smallweb, but it's specifically designed with the philosophy of "edit some files and stuff runs..while remaining compatible with standard deno way of doing things". I love the concept of cloudflare workers[1], their fancy state management, bindings, etc, and the fact that they took inspiration from cgi-bin. However, the fact remains that it's an exotic system with weird restrictions (hello changing your apps around 500mb chunk…

The title is "Why Google Pixel lags 10x more than Moto Z" but the content is just a microbenchmark of fsync() without anything resembling a measurement of UI lag or that the 10x slowdown in fsync() actually means a 10x (or any) increase in said lag. The author's previous blogpost (http://taras.glek.net/post/Laggy-phones-and-misleading-benchmarks/) contends that 4K writes are a good proxy for phone lag, but has no evidence or measurements either, just the author's contention. It could all well be true! And it's great the author's dug up some concrete areas the pixel team could potentially improve at (dumb question: couldn't the pixel be updated to use most of these FS tweaks? could an in-use pixel FS be converted to use f2fs?). But I don't think the author has done a good job demonstrating an actual relation to UI lag or anything to do with the phone's perceived performance. disclaimer: googler, but I do iOS things.

Glad you asked! One of my favorite topics. ;) COM is essentially a formal way of using C++ vtables [1] from C and other languages, so you can create and consume components in any language, and call back and forth between them. It's a way of expressing a rational subset of how C++ classes work and format in memory, in a way that can be implemented in other languages. It was the outcome of the C / C++ / Visual Basic language wars at Microsoft. The original 16 bit version of Visual Basic version 1 through 3 had a plug-in extension mechanism called VBX -- Visual Basic Extensions [2]. They were extremely popular and became a victim of their own success, after a whole industry grew up around them, and people started using them for all kinds of things they weren't intended for, and wanted to use them from other languages and frameworks like Borland. Microsoft had to do something about that to mitigate the success disaster of VBX, so they invented COM. At the time, Microsoft was transitioning from Win16 to Win32, so they came up with the 32 bit COM definition, also known as OCX's, or OLE Controls, which they later called ActiveX, because COM was so hard to search for, and they wanted to take the spotlight away from Java with a new buzzword. So they brewed up a bunch of ugly C macrology that enabled C programmers (or Visual Studio wizards) to define COM interfaces in header and implementation files that just happened to lay out memory in the exact same way as vtables of C++…