sprash

It was/is mostly the same practice except for the cases where it really counts. Window managers in general, xdotool, all kinds of input mapping and automation or the fact that you can write a screenshot tool in less than 500 LOC are only possible if you talk to X directly. And there the possibilities are almost limitless. And thanks to the xcb library it's actually somewhat convenient to use.

Also certain types of power tools for mac probably need use Quartz directly as well.

It means that Wayland is the worst and most idiotic graphics API ever conceived. Talking to Wayland's "asynchronous object oriented protocol" directly is a fucking disaster [1]. Secondary and partly duplicated infrastructure in form of a dbus infested maze of "Desktop-Portals" is necessary to do things as simple as taking screenshots.

As such it essentially cements the GTK/Qt duopoly. Both are extremely subpar low-quality bloated toolkits that are also responsible for the fact that the Linux desktop is still not a thing in 2026.

1.: https://www.p4m.dev/posts/29/index.html

Yes but the Nvidia NV-1 preceding the Vooodoo was much more impressive. Using NURBS you could display perfectly round objects. Also it had forward texture mapping which significantly improves cache utilization and would be beneficial even today.

It was just way harder to program for. Triangles are much simpler to understand than bezier curves after all. And after Microsoft declared that DirectX only supports triangles the NV-1 was immediately dead.

The original rc-style sysvinit scripts of arch were neither brittle nor buggy. Everything could be configured with "rc.conf" and writing own services was dead simple. All of this was possible with many orders of magnitudes of less complexity.

Example: Windows can only be resized when the client finished drawing the new resized window. Otherwise you would get "visual artifacts". So typical operations dealing with window management can not be async when the insistence on the nonsensical "every frame is perfect" mantra is upheld.

This also means low-performing clients can make the whole Desktop stutter/freeze and it is one of the many reasons the Wayland architecture is beyond idiotic. High responsiveness is obviously far more important than avoiding the occasional artifact.

> Why?

CLI applications typically read text from stdin and write text to stdout. The tcl model of "everything is a string" makes exactly the right abstraction to create GUI frontends for CLI applications rapidly and keep them simple at the same time.

Tcl/Tk to this day is the best tool to make GUI frontends for CLI applications. Besides that, in the past I used it in production for intranet database entry applications. It has since been replaced by Flask. In my opinion the higher complexity of the Flask version is no way justified and we should have kept the much simpler ~2k LOC Tcl/Tk solution.

It is obviously not dead but it should be dead: Almost all of the technical and economic progress made in the last century was achieved with macroscopic quantum effects. Particle physics spends a lot of energy and material resources to measure microscopic effects. The priorities are esentially inverted. At this point it is not even about discovery. Experiments are relegated to precision measurements. What practical use will it be if we know the mass/charge distribution/polarizability of some particles more precicely by a few percent? About nothing.

Playing around with 68k assembly is actually much more fun. These days all the logic is absolutely dwarfed by caches in terms of chip area. This means using RISC does not really make as much sense today as it did in the 80s. That's why the most popular architectures are still CISC (assuming ARM64 can not really be called RISC).

Personally I would be more interested in a fully orthogonal instruction set like 68k but without the insane addressing modes and a better binary format.

It is already possible today. There are access control hooks provided via XACE. Nobody uses them because the attack scenario is basically non-existent. If you run untrusted malicious apps having full access to your home directory you have big problems anyways. Not giving them access to e.g. the screen coordinates of their windows won't help you much then.

All the major arguments in that decades old talk are invalidated with the introduction of DRI3.

So far so good. The feature set is bit random though. Things i personally miss is function overloading, default values in parameters and tuple returns.

> And not individuals who work at Microsoft does not count.

How in the world does this not count? People act in the interest of those who pay the bills.

It is irrelevant who invented Rust. The relevant fact is that it can be used as a tool to divide the community because of its very opinionated design. Systemd was equally opinionated and also caused huge division. Who is paying the bills of Poettering these days: Microsoft.

The Halloween documents show that Microsoft is playing these games for a long time now. Who knows in which way they have advanced their psyops. Just because we can't read their E-mails anymore doesn't mean they stopped doing it.

It's not dead. It's being murdered. Microsoft, Apple, Gnome and KDE are making the experience worse with each update. Productive work becomes a chore. And the last thing we need is more experiments. We need more performance, responsiveness, consistency and less latency. Everything got worse on all 4 points for every desktop environment despite hardware getting faster by several orders of magnitude.

This also means that I heavily disagree with one of the points of the presenter. We should not use the next gen hardware to develop for the future Desktop. This is the most nonsensical thing I heard all day. We need to focus on the basics.

Unpopular take: Windows 95 was the peak of Desktop UX.

GUI elements were easily distinguishable from content and there was 100% consistency down to the last little detail (e.g. right click always gave you a meaningful context menu). The innovations after that are tiny in comparison and more opinionated (things like macos making the taskbar obsolete with the introduction of Exposé).

The current main contributor is 100% corporate sponsored mostly through fronts like Igalia.

The only real Wayland community effort is Hyprland. The author of that has been banned from contributing to Wayland by the corporate sponsors of Wayland.

Hence there is no community.

Also the whole "there is no Wayland" "it's just a protocol" spiel has been played so often that I believe Wayland apologists are mostly bots.

Desktop Linux needs standardized and stable infrastructure. X11 delivers on that perfectly.

Wayland despite receiving huge amounts funding has actually far more moving pieces. Even for the simplest tasks you have to deal with a dbus infested portal maze, many parallel infrastructure effects and high fragmentation. The API is atrociously stupid and cumbersome.

Besides that the modesetting driver of xorg also sits "properly on top of kernel abstractions". How is this in any ways a relevant criterion. What matters is that Wayland clearly makes the wrong abstractions for Desktop applications and the vast amount of parallel infrastructure required to do even the simplest tasks shows that.

Always the same lies. People "stepped up" in the and as a result were outright banned from the gitlab (instead of e.g. just rejecting pull requests). Current maintainers refuse to do any release management and instead treat every merge into master as a new release. This kind of sabotage makes development or contributing very difficult. Also the people that used to maintain X11 (e.g. Keith Packard) had nothing to do with building Wayland.

Wayland on the other is just a insanely stupid API. Everybody advocating for Wayland should be forced to write a simple client at least once without relying on behemoths like GTK or Qt.

There is no X11 bitrot. Just a lack of funding. If funding for Wayland stopped today, Wayland would die much quicker than X11 because there is essentially zero community involvement whereas for X11 there are enough people that care to keep it alive for free.

This is pretty low level access. The phone you are going to pair it with and is providing network access is definitely more closed than this.

> complete walled garden

Not really. You can build your own apps [1].

1.: https://github.com/even-realities/EvenDemoApp

A full terminal emulator including firmware and 8080 emulation but with small trivial GL shaders that can be disabled exists here: https://github.com/larsbrinkhoff/terminal-simulator

The long term play is to drive out community participation and bring in corporate control in the apt/Debian ecosystem.

This was true before they switched to systemd. Now the pstree and mounts are as polluted with noise as any other distro.

This rare 22-segment display is the most interesting I've seen so far. It can display the full 7-bit ASCII range including special characters: https://www.youtube.com/watch?v=D2cyZoCat_U

> I think MGR has the greatest potential for a comeback because of its unique architecture

I think so too. But this time with modern drawing primitives. Instead of lines an circles we need shaders and textures.

In the end, even the most modern UI is nothing more than a terminal: Low bandwidth input from keyboard and mouse events and low bandwidth output (like draw checkbox at x,y). The rest is done by some drawing or blit routine which can be entirely managed on the GPU.

If you use Cairo on X11 rendering automatically happens with the XRender extension. This is a rather efficient wire protocol that supports sub-pixel coordinates, transparency, gradients and more. No off-screen rendering required. (Some of the older gtk2 theme engines worked that way and allowed beautiful UIs with fast remote capabilities.)