><i>In fact, in some cases it's worse. It took tremendous effort to get 3D accelerated Doom to work inside of X windows in the mid 2000s, something that was trivial with mid-1990s Microsoft Windows. Below is a screenshot of Processing running for the first time on a Raspberry Pi with hardware acceleration, just a couple of years ago. And it was possible only thanks to a completely custom X windows video driver. This driver is still experimental and unreleased, five years after the Raspberry Pi shipped.</i><p>That's because of Open Source OSes though, which vendors don't care about and volunteers aren't enough and able to match the work needed for all things to play out of the box. Nothing about this particular example has anything to do with OS research or modern OSes being behind.<p>><i>Here's another example. Atom is one of the most popular editors today. Developers love it because it has oodles of plugins, but let us consider how it's written. Atom uses Electron, which is essentially an entire webbrowser married to a NodeJS runtime. That's two Javascript engines bundled up into a single app. Electron apps use browser drawing apis which delegate to native drawing apis, which then delegate to the GPU (if you're luck) for the actual drawing. So many layers.</i><p>Again, nothing related to modern OSes being inadequate. One could use e.g. Cocoa and get 10x what Electron offers, for 10x the speed, but it would be limited in portability.<p>><i>Even fairly simple apps are pretty complex these days. An email app, like the one above is conceptually simple. It should just be a few database queries, a text editor, and a module that knows how to communicate with IMAP and SMTP servers. Yet writing a new email client is very difficult and consumes many megabytes on disk, so few people do it.</i><p>First, I doubt one of the reasons "few people do it" is because it "consumes many megabytes on disk" (what? whatever).<p>Second, the author vastly underestimates how hard it is handling protocols like IMAP, or writing a "text editor" that can handle all the subtleties of email (which include almost a whole blown HTML rendering). Now, if he means 'people should be able to write an emailer easily iff all constituent parts where available as libraries and widgets', then yeah, duh!<p>><i>Mac OS X was once a shining beacon of new features, with every release showing profound progress and invention. Quartz 2D! Expose! System wide device syncing! Widgets! Today, however Apple puts little effort into their desktop operating system besides changing the theme every now and then and increasing hooks to their mobile devices.</i><p>Yeah, and writing a whole new FS, a whole new 3D graphics stack, memory compression, seamless cloud file storage, handoff, move to 64-bit everything, bitcode, and tons of other things besides. Just because they are not shiny, doesn't mean there are no new futures there.<p>><i>A new filesystem and a new video encoding format. Really, that's it?</i><p>Yeah, because a new FS is so trivial -- they should also rewrite the whole kernel at the same time, for extra fun.<p>><i>Why can I dock and undock tabs in my web browser or in my file manager, but I can't dock a tab between the two apps? There is no technical reason why this shouldn't be possible. Application windows are just bitmaps at the end of the day, but the OS guys haven't built it because it's not a priority.</i><p>There's also no real reason this should be offered. Or that it should be a priority. If every possible feature someone might thing was "a priority" OSes would be horrible messes.<p>><i>Why can't I have a file in two places at once on my filesystem? Why is it fundamentally hierarchical? Why can I sort by tags and metadata?</i><p>Note how you can do all those things in OS X (you can have aliases and symlinks and hard links, can add tags and metadata, and can sort by them). And in Windows I'd presume.<p>And it's "fundamentally hierarchical" because that's how we think about stuff. But it also offers all kind of non hierarchical views, Spotlight and Tags based views for one.<p>><i>Any web app can be zoomed. I can just hit command + and the text grows bigger. Everything inside the window automatically rescales to adapt. Why don't my native apps do that? Why can't I have one window big and another small? Or even scale them automatically as I move between the windows? All of these things are trivial to do with a compositing window manager, which has been commonplace for well over a decade.</i><p>Because bitmap assets. Suddenly all those things are not so "trivial".<p>There are good arguments to be made about our OSes being held back by legacy cruft (POSIX for one) and new avenues to explore, old stuff that worked better than what we have now, etc.<p>But TFA is not making them.