I wonder if that dip in Windows in April, going down to like 62%, and the correlated boost for “Uknown” operating systems to 13% might somehow simply be Windows not being recognized properly and categorized as unknown?

It seems a bit far-fetched to me that a bunch of Windows users would for 1 month suddenly all decide to use ReactOS, FreeDOS, BSD, Solaris, Illumos, Haiku, Redox, and Plan 9.

Why do you think you need to update packages on Arch every single day?

It was just a bit of hyperbole regarding the amount of mental effort it takes to keep your system up to date, I don’t actually mean every single day. I mean if you don’t keep Arch up-to-date on a regular basis, packages tend to break, and then you need to re-install the OS or jump through a few hoops to repair the broken packages and their dependencies. Diligent regular updates is not a terrible mental burden, but a burden none-the-less, so using point release OS like Mint or Ubuntu are just easier.

I don’t think ST works on Wayland except through the ordinary Wayland X11 server they have to suppor legacy software. You might want to ask the Suckless people what their opinion is of Wayland and whether they will support it in the future.

Or you can use any other terminal emulator that does support Wayland, I only recommend ST because it is the simplest one and is specifically designed to be easy to hack.

As far as I understand it, Guix will download pre-built binaries for most packages from a cache by default, and the Guix OS distribution makes sure the x86_64 binaries for the latest package descriptions are always cached, so you should usually not have to locally build packages.

But of course you can easily tweak the default configuration of packages you install and trigger a local re-build of those packages, since changing the configuration of any package causes a cache miss.

So usually people do install Linux software from trusted software repositories. Linux practically invented the idea of the app store a full ten years before the first iPhone came out and popularized the term “app.”

The problem with the Mullvad VPN is that their app is not in the trusted software repositories of most Linux distributions. So you are required to go through a few extra steps to first trust the Mullvad software repositories, and then install their VPN app the usual way using apt install or from the software center.

You could just download the “.deb” file and double click on it, but you will have to download and install all software security updates by hand. By going through the extra steps to add Mullvad to your trusted software repository list, you will get software security updates automatically whenever you install all other software updates on your computer.

Most Linux distros don’t bother to make it easy for you to add other trusted software repositories because it can be a major security risk if you trust the wrong people. So I suppose it is for the best that the easiest way to install third-party software is to follow the steps you saw on the website.

I guess it depends on your goals. If this is just for yourself, the solution you are using now sounds just fine, use Alacritty as the GUI.

If you want to package it as an app all wrapped up in a single binary that you might want to distribute to other people, you could just write a simple C program that imports both FZF and a tiny terminal emulator like ST (the Suckless Terminal), and configure ST in the C program to launch FZF with your unique FZF config, instead of launching /bin/sh. You could even dump your configs as constant strings into your C program so you don’t need any external config files.

So I think Guix (and Nix) is the most technologically advanced package manager in existence, and I hope someday all package managers work like Guix.

One other very interesting feature about Guix (which I don’t think Nix is doing yet) (which Nix also does) is that they have implemented a fully verifiable bootstrap, meaning every step of building the kernel, including the steps taken to build the C compiler toolchain, are produced by code that is simple enough for a group of humans to check for correctness and safety. Also, every step of the build process exists in the package repository, with no reliance on externally built binaries for anything, not even the C compiler toolchain. They accomplish this with a multi-phase bootstrap process, where a smaller, simpler C compiler is used to build GCC.

Do I use Guix? Well, no. Simply put, it is not quite to the point where it just works on a lot of the computer hardware that I own. With a bit more work, with a few more developers, and a bit more money invested, Guix could pretty soon become as reliable and useful as Debian or Fedora. But it is not quite there yet. And frankly, I have other more important things to do than worry about debugging problems with the operating system I am using.

Using Scheme instead of a purely functional language like Nix as the Nix/Guix expression language is a bold choice I am not sure I agree with.

Scheme is the most functional of all non-purely-functional languages that I know of. What’s more, the parts of Guix in which packages are defined are quite pure, even using monads for some things, so it is really not too different from the Nix language.

This is fascinating to me. Do you have any links or suggestions for this workflow to learn more?

I am glad you asked, because I actually wrote a series of blog posts on the topic of how Emacs replaced my old Tmux+Bash CLI-based workflow. The link there is to the introductory article, in the “contents” section there are links to each of the 4 articles in the series. The “Shell Basics” (titled “Emacs as a Shell”) might be of particular interest to you.

If you have any specific questions, or if you have recommendations for something you think you would like to learn from one of my blog posts, please let me know. I would like to write a few more entries in this blog series.

I used to use the command line, Bash, Awk, Sed, Cut, Grep, and Find (often piped to one another) quite often. I can recall that the few times I used Awk was usually for collating lines from logs or CSV files.

But then I switched to using Emacs as my editor, and it gathers together the functionality of all of those tools into one, nice, neat little bundle of APIs that you can easily program in the Emacs Lisp programming language, either as code or by recording keystrokes as a “macro.”

Now I don’t use shell pipelines hardly at all anymore. Mostly I run a process, buffer its output, and edit it interactively. I first edit by hand, then record a macro once I know what I want to do, then apply the macro to every line of the buffer. After that, I might save the buffer to a file, or maybe stream it to another process, recapturing its output. This technique is much more interactive, with the ability to undo mistakes, and so it is easier to manipulate data than with Awk and shell pipelines.

Nyxt is Common Lisp bindings to WebKit, so not exactly a Chromium fork, but uses the same web rendering and JavaScript engine as Chromium. The important thing is that you can program it using Common Lisp as well as JavaScript.

Woah, woah, woah… there is a Wayland compositor called DWL and a status bard called DTao that can be scripted using Guile Scheme?! Holy shit!

Now I know exactly what I am going to do as soon as my Linux distro swtiches over to Wayland.

And kudos also for using Nyxt and Emacs. The Lisp runs strong in this one.

Non-gentoo user: “Welp, Gentoo is now just another Arch fork LMAO!”

To be fair, you can still build packages and fine-tune the builds with the Emerge system flags, which is sort-of Gentoo’s killer feature. It is just that they have recognized that most people will install probably 99% of all software without changing the default flags, and so why not give them those packages pre-built.

So I guess this make Gentoo more similar to Nix OS or Guix OS but without the high-tech package manager and dependency resolution.

It can even start the receiving daemon if it is not yet running.

We have a tool for that, it’s called an init system.

The init system is for trusted system services that can talk directly to hardware. Unless you are working on a single-user system with no security concerns of any kind, you might consider using init to launch persistent user land or GUI processes.

DBus is for establishing a standard publish/subscribe communication protocol between user applications, and in particular, GUI applications. And because it is standard, app developers using different GUI frameworks (Gtk, Qt, WxWidgets, FLTK, SDL2) can all publish/subscribe to each other using a common protocol.

It would be certainly be possible to establish a standard place in the /tmp directory and a standard naming scheme for sockets and temporary files so that applications can obtain a view of other running applications and request to receive message from other applications using ordinary filesystem APIs, but DBus does this without needing the /tmp directory. A few simple C APIs replace the need for naming and creating your temporary files and sockets.

Now I can see why people like openSUSE.

Yeah, I have definitely run across lots of Arch packaging bugs. They seem to give up making packages backward compatible after some length of time, that or their testing procedures are not as thorough as that of openSUSE. It is understandable, making a rolling release backward compatible for long periods of time can be fairly challenging. Although Nix OS and Guix OS have solved this problem.

There are Vim emulator apps for Emacs, and you can use them with TRAMP mode for remote file editing as well. Doom Emacs and Spacemacs both provide extremely good Vim emulation that work consistently throughout all Emacs modes, including TRAMP mode.

This is probably not a solution you would want, but I will mention it anyway…

Emacs has a built-in app called “TRAMP mode”, what it does is it works as back-end for all of Emacs’s own built-in text editing and file browsing commands, then it uses ordinary SSH and POSIX shell commands on a remote host as the primitive APIs for this back-end. You could say it uses SSH and a POSIX shell as a RPC mechanism.

What this means is you can use the ordinary Emacs editor with the entirety of your usual Emacs configuration, but all filesystem changes (including editing files, directories, and running shell processes) occur on the remote host via SSH. In order to activate it, you just use Emacs’s special TRAMP URL scheme as the file path you want to edit, and it works seamlessly, (especially if you setup your SSH agent so you don’t need a password). An example of such a URL would be /ssh:user@remote-host:/etc/hosts.

Every day is something of an exaggeration, but if you don’t keep a rolling release up-to-date regularly (like once a week), packages start to break. And this gets to be a problem, especially if I don’t keep a computer always on, or if I keep postponing updates because my laptop is not connected to the Internet at the schedule time. There are a dozens reasons why I miss regular updates, but the point is, it should not bork my system if I do miss updates for a while.

I had a huge problem with Arch because of the rolling release deal. I just can’t handle the responsibility of updating packages every single day, even with automation.

When I install an operating system, I want it to just work, and I want their repositories to have lots and lots of software. Most distros do this, but none do it as well as one of the major Debian-family distros like Ubuntu or Mint. Fedora is quite nice as well, and I could probably daily drive it without issue, I just see no reason to change over to it since Ubuntu has me totally covered. And it is basically like this for me with every other distro: I have to think, “why would I switch? What benefit would it provide me over what I have right now.” The answer is always “nothing important,” so I stick with Ubuntu.

I considered using Guix because its package manager is truly a revolutionary new technology. But using it as a package manager, I can see a lot of the packages and default configurations just aren’t quite to the point of “just works” yet. Still, I hope someday to switch to Guix as my daily driver.

Do you need inlining if you just use fixed monad transformers?

I am not sure what you mean by “fixed” monad transformers, if you mean writing your own newtype where the functor variable is the only type variable, essentially what you are doing is hand-inlining the monad transformer, and so no, if you inline by hand, then the compiler doesn’t need to do it.

Haskell inlines all newtype definitions automatically, so if your monad transformer has all of the type variables bound (except for the functor variable, because that is a special case the Haskell compiler is specifically designed to handle) the compiler will usually reduce those to ordinary lambda expressions automatically, and lambda expressions usually optimize to the most efficient machine code.

The only time the compiler cannot reduce a newtype to an efficient lambda is if the non-functor variables, e.g. the state type variable or the exception type variable, are unbound. Those values could become anything at all at its call site, limited only by the constraints set by the type context. So the type context information, a lookup table of type class instances, must be associated with that lambda expression, and in order to do that, the compiler must create a closure around those values. Creating closures allocates values on the heap, and this is much, much slower than efficient lambda expressions, and no faster than allocating a data constructor as with Free Monads.

Alexis King did a presentation on it where she explains all of this extremely well, if you are interested: https://youtu.be/0jI-AlWEwYI

It is a bit long, but at 17:40 or so she starts talking about strategies for how monads and effects can be implemented in the GHC intermediate code, and compares Free Monads and effects to monad transformers. At 21:15 or so she begins to explain how newtype types can be optimized away completely, newtype constructors don’t exist at all in the low-level code, they are a “zero-cost abstraction.” On the other hand, data constructors (used for Free monads and effects) always allocate something on the heap which is an order of magnitude slower.

Then at around 27:45 she begins to show how newtypes with type variables cannot be inlined across module boundaries for the reason I explained above (type context tables associated with closures), and so monad transformers cannot be optimized across module boundaries.