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.
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.
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.
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.
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é).
Also certain types of power tools for mac probably need use Quartz directly as well.