https://joshondesign.com/2017/08/18/idealos_essay
TL;DR: I disagree with most of this article, except the part where we should start over from scratch, learning the lessons of the past. To do this correctly would be to redesign a system as a microkernel, in a safe, modern language such as Rust.
This is clearly an opinion. Depending on your point of view, it is either true or false. You can, in fact, have a modern operating system with minimal bloat. Here is what you do:
- Reduce the number of available applications
- Reduce the complexity of graphical themes
- Remove all translations
- Remove debug symbols from all applications
- Use a simpler window manager
- Use command line tools instead of graphical tools
Incredibly, these are the exact things that would bring you back to 1990's memory and CPU usage (as well as 1990's style and usability). So, if these things have no value to you, go ahead and use a lighter Linux distribution, like Puppy Linux.
Sadly, we have reached a point where there is no longer constant flux in the critical base of computing that is the Desktop Operating System. However, this is not due to a lack of "innovation", but rather to a maturing of the technology and a development of new technology at higher layers. Also, perhaps the author is ignoring internal changes to X that have improved reliability, performance, and added capability. The entire Linux graphical community was focused on X for decades, and have built an extensive ecosystem on top of it. This ecosystem will not be easy to move to another base, and an attempt to move it will stifle innovation at the application level, even if it improves it at the display manager level.
This is going to have to be large, to cover all the claims of the author.
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.
Um, no. Application windows are not "just bitmaps". A screenshot of the window is a bitmap, not the window itself. The way it is displayed is using a bitmap, but that is ignoring its true nature. An application window is an interactive document, that can change in real time due to user input and application code.
This kind of document cannot be transferred between two applications, as it relies on the private application code to process input and generate output.
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? Database filesystems have existed for decades. Microsoft tried to build it with WinFS, but that was removed from Vista before it shipped thanks to internal conflicts. BeOS shipped it twenty years ago. Why don't we have them in our desktop OSes today?
The answer to this is quite simple. Because that design is a complete failure.
There is no reason the standard filesystem can't store metadata. There are plenty of desktop applications that store their own metadata and allow for more complicated search patterns. A generic method of storing arbitrary data is exactly what a filesystem is!. It turns out that having a side-channel for storing even more arbitrary data is not very valuable.
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.
So, let me tell you a bit about "native" apps and "web" apps. All that a "web" app is, is a collection of code running in a browser, which is a "native" app.
So, no, there is no reason you couldn't zoom any application, if that application implemented it. Note that zooming in a text editor, web browser, terminal, image viewer, document viewer, document editor, file manager, etc is usually implemented!
The only reason there are "native" applications that do not support this, although many fewer than the author would seem to imply, is that it is up to the application to support such functionality. Implementing such logic in the toolkit is incredibly heavy and seems meaningless. The only use case for having the window controls large in one application, but not in another, that I can think of is when you have multiple monitors of different DPI's.
I must confess, I lost my patience reading this section.
My computer has a mouse, keyboard, tilt sensors, light sensors, two cameras, three microphones, and an array of bluetooth accessories; yet only the first two are used as general input devices. Why can't I speak commands to my computer or have it watch as I draw signs in the air, or better yet watch as I work to tell me when I'm tired and should take a break.
The mouse and keyboard are still used as the primary input devices because they are so damn effective as primary input devices.
Why can't my computer watch my eyes to see what I'm reading, or scan what I'm holding in my hands using some of that cool AR technology coming to my phone. Some of these features do exist as isolated applications, but they aren't system wide and they aren't programmable.
Again, if this had any value as a general input device, I'm sure it would be utilized as such.
Why can't my Macbook Pro use Bluetooth for talking to interesting HID devices instead of syncing to my Apple Wait. Oh wait, my Mac can't sync to my Apple Watch. Another place where my desktop plays second fiddle to my phone.
I don't know what the hell you are talking about.
My can't my computer use anything other than the screen for output? My new Razor laptop has an RGB light embedded under every key, and yet it's only used for waves of color. How about we use these LEDs for something useful! (via Bjorn Stahl, I think).
Because RGB keyboards are freaking useless for almost anything? Displays are a truly generic, arbitrary method of information output, keyboards with fancy lights are incredibly limited.
Each application is its own application, what a shock! They do things differently? Who would have thought!
The reality is that if you want a standard config, preference, database, file format, search algorithm, key binding, etc - then you want a single application.
Computers are not built for 1984. The Desktop GUI has been under tremendous development since then, and likening it to the first version of MacOS is an incredibly disingenuous thing to do. Try running that first version of MacOS - can you do any of the tasks you need to do on a daily basis?
I create VR content. I remix images. I send messages to a dozen social networks. I make the perfect play list from a selection of 30k songs. I process orders of magnitude more data from more locations than I did only 20 years ago, much less 40 years ago when these concepts were invented. The desktop metaphor just doesn't scale to today's tasks. I need a computer to help me do modern work.
Have you heard of the command line? You could probably automate many of these tasks.
So now we come to the speculative part. Suppose we actually had the resources, and had a way to address (or ignore) backwards compatibility. Suppose we actually built something to redesign the desktop around modern work practices. How would we do it?
Not the way you want to.
We should start by getting rid of things that don't work very well.
Yes. Like the things you propose.
Traditional filesystems are hierarchical, slow to search, and don't natively store all of the metadata we need.
Hierarchy is good. They can be indexed, and metadata can be stored in files.
All IPC. There are too many ways for programs to communicate. Pipes, sockets, shared memory, RPC, kernel calls, drag and drop, cut and paste.
Don't you think there is a reason for this? Each method has its pros and cons, so it is good to offer multiple methods for applications.
Command line interfaces don't fit modern application usage. We simply can't do everything with pure text. I'd like to pipe my Skype call to a video analysis service while I'm chatting, but I can't really run a video stream through awk or sed.
Yes it does. This sounds like you do not understand the CLI. First, it is not pure text. It is binary data, that just happens to be nice ANSI text most of the time. You absolutely can pipe video to a network service, and your inability to do so should be what is discussed, rather than an assumption that it cannot be done.
Window Managers on traditional desktops are not context or content aware, and they are not controlable by other programs.
That is in fact the benefit of the window manager. Although, window managers are only programs, so you can easily make programs that take over the entire display and present a different interface.
Native Applications are heavy weight, take a long time to develop and very siloed.
Oy vey. Web applications are heavy weight, take a long time to develop, and are even more siloed.
So what does that leave us with? Not much. We have a kernel and device drivers. We can keep a reliable filesystem but it won't be exposed to end users or applications. Now let's add some things back in.
Ah, you have started at the wrong end. We do not have a kernel and device drivers. Why? Because the right place for innovation right now is at the kernel, where there are opportunities for immense security improvements.
Since this was the author's basis for the rest of the article, I would rather not continue my rebuttal past here.