Thanks to the great Mārtiņš Možeiko, the RAD Debugger is now available on the Arch Linux AUR! aur.archlinux.org/packages/r…

I have posted two updates about RADDBG on Linux, and all I can say is that, while the majority of responses have been very positive, the rest make it obvious why it has taken so long for the Linux ecosystem to provide a ~viable consumer desktop experience (for Windows to decay so much that there is not really any alternative). There is no coherency in the design of the platform. There is no sane team calling the shots, so the user base spends their time bikeshedding over what should be trivialities. Everybody has an opinion about everything. Window managers (X11? Wayland? X11 on Wayland?), to package managers, to libc versions, to the right folder to use for X/Y/Z, to which shell interpreter to use, to how to ask the user for a file path (libportal? zenity?), to how to show the user a trivial message box, and so on. And this is just the beginning—the trivial stuff that most people reading this will get, without needing a ton of extra context. If your users or developers are debating about any of this, YOU FAILED. The platform SUCKS. It will only succeed when centralized teams (e.g. shipping hardware using the Linux ecosystem) steer the ship and make decisions. Then, people write to that, and that becomes the actual standard.

Basic native desktop UI integration on Linux (file pickers etc.), + "immediate-mode program installation". It is important to me that distribution of RAD Debugger binaries is as simple as possible, so I keep everything packaged as a single standalone executable. But some systems, like the default Ubuntu environment, require extra files in order to "install" an application (e.g. so that they show up when searching in the program launcher, or to show their icons in the desktop environment UIs). Other similar "installation" steps exist on Windows, for example. Installation and uninstallation has always felt to me like a bunch of unnecessary work, which is why on Windows, people package "installers" and "uninstallers" as extra utilities, which wrangle all of the extra crap that a program needs to be "installed". But the important thing to the user is, obviously, just a single boolean: is the program "installed", or is it not? So it seemed to me that the simplest way to offer this functionality was to expose a checkbox as a regular program setting, found in the regular program UI. When it is checked, RADDBG ensures all of the appropriate configuration files are written. When it is unchecked, it ensures all of those files are deleted. Thus, you just get the single binary, run it, and optionally check the box if you want extra integration into your desktop environment.

Technologies that layer require layered skillsets, because each additional layer is not by itself sufficient. In computing, we say this is due to “leaky abstractions”, though historically we recognized that no perfect “non-leaking” abstraction exists. Therefore, there is always value in people who understand the internals of something otherwise considered opaque. The same principle is true for LLMs, both for the implementation of the LLMs themselves, and the implementation of the code they generate.