Fixing a 20-year-old bug in Enlightenment E16

> Sadly, the hang was deterministic:

Huh, someone's in it for the thrill of the hunt, I see...

This is a flash from an almost forgotten past. I'm happy people are still using and even improving Enlightenment.

I used to run Enlightenment in the late nineties and early 2000s, first by itself, then with Gnome bar. At some point Gnome turned hostile on power users and I switched to KDE, leaving also Enlightenment behind, as well as any extensive customization of my desktop. At that time, the ubiquitous themes.org also got in disarray, and I feel it was a bit an end of an era of design and theming experiments on the early Linux (and *BSD) desktop.

Whenever I try something else, I always seem to keep going back to E16. Back in the day, it worked well in Gnome 2.x; these days I tend to use it in XFCE, but it feels a bit less integrated.

Fun post! Very happy to see a 20-something year old find and fix bugs in an X11 wm from before they were born. Gives me hope.

There was some kind of editing snafu though, the loop header in the big (first) code block reads:

    for (i = 0; i < 10; i++, nuke_count++)

But the references to it in the text, and updated versions in the patches, show it as just

    for (;;)

That was confusing me a bit.

Oh, people are still using Enlightenment.

My last time I used it was still in the 1990's, before I settled into Afterstep and soon afterwards Windowmaker.

In what concerns my use of GNU/Linux, it was CDE on others.

Apparently nothing big came out of Enlightenment and Tizen.

The amount of abuse I hurled at Carsten Haitzler (Raster) during our time at VA Linux (where he worked on E as well as other stuff) was a complete sitcom unto itself; at one point he debated making a "zeruch insult generator" just to streamline the verbal abuse process.

I loved using the environment but would regularly harangue him for being glib on resource usage. It really was otherwise very ahead of the curve.

I love Enlightenment still, even the new ones. The most important component of it to me is Terminology. What a gorgeous and functional Terminal emulator.

I am still waiting for e17. I stuck to e16 for a long time until ubuntu got a thing which was much more convenient than gentoo.

I had the classic setup with the apache helicopter on the background and virtual desktops with preview. On MacOS however.

To this day i am still using a single screen, with virtual desktops ordered the same way.

Funnily, E16 was considered a rather eye candy but heavy WM/environment back in the i486 / early pentium days, now it is considered lightweight!

> It’s themable, hackable, lightweight

Certainly wasn't considered lightweight back then :-)

I never saw the appeal of Enlightenment, but a very nice write-up regardless.

E16 was the hook that caught me and landed me, flopping and writhing, on the decks of Linux - I saw a black and white printout of someone’s desktop, and immediately set about figuring out how to get this unbelievable coolness working on my laptop. By the time I was done I was muttering modelines in my sleep, and had already committed my first patches to a kernel module.

I wonder how many other teenagers got catfished into becoming software devs and sysadmins by the siren song of rasterman.

I used that same theme back in 2003. Makes me want to reinstall E16

Enlightenment is pretty cool. Some years ago though I realised that I just want the computer to be a fast and simple workstation at all times. That's when I kind of stopped using KDE (and GNOME3 but I did not use it to begin with, it always felt like an opinionated smartphone-UI pushed onto the desktop).

I think only few people use Enlightenment, so the resources to fix bugs must also be small.

Whenever I try something else, I always seem to keep going back to E16. Back in the day, it worked well in Gnome 2.x; these days I tend to use it in XFCE, but it feels a bit less integrated.

I love Enlightenment still, even the new ones. The most important component of it to me is Terminology. What a gorgeous and functional Terminal emulator.

I am still waiting for e17. I stuck to e16 for a long time until ubuntu got a thing which was much more convenient than gentoo.

I had the classic setup with the apache helicopter on the background and virtual desktops with preview. On MacOS however.

To this day i am still using a single screen, with virtual desktops ordered the same way.

> Sadly, the hang was deterministic:

Huh, someone's in it for the thrill of the hunt, I see...

I wonder about the sadly.

Luckily the hang was deterministic.

This is a flash from an almost forgotten past. I'm happy people are still using and even improving Enlightenment.

same, especially compiz era after good drivers and accelerated compositing became ubiquitous was wild

Fun post! Very happy to see a 20-something year old find and fix bugs in an X11 wm from before they were born. Gives me hope.

There was some kind of editing snafu though, the loop header in the big (first) code block reads:

    for (i = 0; i < 10; i++, nuke_count++)

But the references to it in the text, and updated versions in the patches, show it as just

    for (;;)

That was confusing me a bit.

In the article just before that code:

The loop is of paticular interest to us. Abridged:

Oh, people are still using Enlightenment.

My last time I used it was still in the 1990's, before I settled into Afterstep and soon afterwards Windowmaker.

In what concerns my use of GNU/Linux, it was CDE on others.

Apparently nothing big came out of Enlightenment and Tizen.

I was also a huge fan of WindowMaker. Simple, effective, stylish without getting in the way. Also allowed me to have a vertical taskbar, which I stuck with even on Windows until Win11 has taken that from me - because Mac is the arbiter of taste and everyone must copy it.

Enlightenment always had a pretty weird value proposition. In the very beginning, there was "fvwm-xpm" and early "E" prototypes. They were graphically crazy with a heavy focus on shaped Windows. There's still nothing quite like that weird steampunk/Brazil-ish theme they had. Probably for a reason.

Then they went both visually rather tame and scope-creepy (own graphical libraries etc.). At the beginning I was hoping that we'd get some kind of Amiga-influenced design sensibilities on X (basically a more "artsy" MUI), but that never manifested.

Funny, I was also one of those people who switched from E to WindowMaker. At the time I had no idea it resembled NeXTStep, but it was great.

After that I changed to KDE 3 which was a major milestone at the time. I think GNOME at the time was technically superior though.

Then shortly after I realized that desktop on Linux wasn't really going anywhere, so I switched to macOS (OS X at the time).

I loved using the environment but would regularly harangue him for being glib on resource usage. It really was otherwise very ahead of the curve.

I still remember how cool I thought raster was with his vaio and everything. This was the future! Transparent eterms and tasteful backgrounds everywhere.

It's a delicious irony that E is now a super-lightweight system compared with the mainstream environments that plauge our RAM chips today.

Funnily, E16 was considered a rather eye candy but heavy WM/environment back in the i486 / early pentium days, now it is considered lightweight!

And detractors of Emacs used to claim that it stood for "Eight Megabytes And Constant Swapping" meaning that even on a then-huge machine with eight megabytes of RAM Emacs would use up all the memory. Now it is a tiny program compared to things like Visual Studio Code.

one of the more interesting things to think about is the big push to rendering all window manager stuff through a gpu, because we were sure we needed drop shadows and geometry transforms for windows....

Now, what we actually do in a window manager could easily be done in software in realtime, just farmed out to some cpu core.

I wonder how many other teenagers got catfished into becoming software devs and sysadmins by the siren song of rasterman.

Modelines are one of those skills that I thought would get obsoleted, but in fact taught me the mechanics of video timing that I was able to use in unrelated contexts. Such as years later where I was asked to fix a driver for a point of sale system which had a 1024x200 (or thereabouts, extremely wide nonstandard ratio) secondary screen.

Me too! Looking at my old windows 98 machine and then at slackware Linux with enlightenment lured me to Linux and began a lifelong journey!

I think only few people use Enlightenment, so the resources to fix bugs must also be small.

I used that same theme back in 2003. Makes me want to reinstall E16

same, especially compiz era after good drivers and accelerated compositing became ubiquitous was wild

In the article just before that code:

The loop is of paticular interest to us. Abridged:

It's a delicious irony that E is now a super-lightweight system compared with the mainstream environments that plauge our RAM chips today.

Now, what we actually do in a window manager could easily be done in software in realtime, just farmed out to some cpu core.

Me too! Looking at my old windows 98 machine and then at slackware Linux with enlightenment lured me to Linux and began a lifelong journey!

> It’s themable, hackable, lightweight

Certainly wasn't considered lightweight back then :-)

I never saw the appeal of Enlightenment, but a very nice write-up regardless.

No kidding. Last time I used Enlightenment back in the late 90s, both KDE 1.x and GNOME 1.x were orders of magnitude more usable on my lowly Pentium MMX 166 with 16 MB of RAM.

I wonder about the sadly.

Luckily the hang was deterministic.

Sadly as in "Oh dear, I better start debugging this" I think.

Yeah, I got introduced to it via some friends that were former Amiga users.

Win 11 has some niceties, however many of those could have been provided on Windows 10 as well, for example the security stuff like VBS and secured kernel were already available, even if disabled by default.

I still remember how cool I thought raster was with his vaio and everything. This was the future! Transparent eterms and tasteful backgrounds everywhere.

I remember fondly of a raster talk at FOSDEM about 20 years ago: playing videos inside a terminal. Amazing!

it’s not a valid enlightenment screenshot without a digital blasphemy wallpaper.

(digital blasphemy is still around and still selling art.)

> tasteful backgrounds everywhere.

Certainly not everywhere. I definitely remember plenty of tasteless ones, some deliberately so and others just cases of other people's taste differing from mine!

Funny, I was also one of those people who switched from E to WindowMaker. At the time I had no idea it resembled NeXTStep, but it was great.

After that I changed to KDE 3 which was a major milestone at the time. I think GNOME at the time was technically superior though.

Then shortly after I realized that desktop on Linux wasn't really going anywhere, so I switched to macOS (OS X at the time).

Kind of similar story, eventually I ended up on GNOME, as I favoured Gtkmm over how KDE was at the time, but then GNOME 3.0 happened, and my travel netbook got migrated into Unity, and when it went away, XFCE.

Due to similar realisation, my main working devices became Window 7 with Virtual Box/VMWare Worstation, nowadays WSL.

No kidding. Last time I used Enlightenment back in the late 90s, both KDE 1.x and GNOME 1.x were orders of magnitude more usable on my lowly Pentium MMX 166 with 16 MB of RAM.

Yeah, I got introduced to it via some friends that were former Amiga users.

Sadly as in "Oh dear, I better start debugging this" I think.

I remember fondly of a raster talk at FOSDEM about 20 years ago: playing videos inside a terminal. Amazing!

> tasteful backgrounds everywhere.

Certainly not everywhere. I definitely remember plenty of tasteless ones, some deliberately so and others just cases of other people's taste differing from mine!

it’s not a valid enlightenment screenshot without a digital blasphemy wallpaper.

(digital blasphemy is still around and still selling art.)

Due to similar realisation, my main working devices became Window 7 with Virtual Box/VMWare Worstation, nowadays WSL.

Same for me. Slackware (I guess 4.0) and E16 was my first proper Linux installation. Learned so much during that time.

SuSE 5.1 for me, as it was what I could easily get the CD-ROMs for, as bandwidth was just a single 64k ISDN at school.

> because we were sure we needed drop shadows and geometry transforms for windows

As screens get larger, the amount of pixels you need to push to composite windows gets larger-squared. It makes sense to move the pixel pushing away from the CPU and more importantly away from CPU-RAM and on to a separate RAM bus.

The "single buffer with invalidation" model of Win16 (I cannot remember how it works in X) saves memory at the cost of more redraws. The composition model allows you to do things like drag window A over window B without forcing a repaint of window B every frame.

It also allows for better process isolation. I think in both Win16 and X11 you could just get a handle to the "root window" and draw wherever you wanted?

SuSE 5.1 for me, as it was what I could easily get the CD-ROMs for, as bandwidth was just a single 64k ISDN at school.

Same for me. Slackware (I guess 4.0) and E16 was my first proper Linux installation. Learned so much during that time.

Same for me. He definitely contributed to my fondness and wonder of Linux back then.

> because we were sure we needed drop shadows and geometry transforms for windows

It also allows for better process isolation. I think in both Win16 and X11 you could just get a handle to the "root window" and draw wherever you wanted?

eh, there is nothing a gpu can do here within the concept of composition that a cpu could not also do. the gpu simply has buffers that it compsits, the cpu can do that as well. with the benefit of less complexity leading to not needing to worry about driver crashes. on sane architectures its all the same ram anyway

Same for me. He definitely contributed to my fondness and wonder of Linux back then.

> eh, there is nothing a gpu can do here within the concept of composition that a cpu could not also do.

True, but which is more efficient?

> on sane architectures its all the same ram anyway

Opinions differ. The main benefit of splitting RAM is not having to share the bus. As I said, this lets you use the CPU for CPU things without having to spend precious DRAM bandwidth shovelling pixels.

> eh, there is nothing a gpu can do here within the concept of composition that a cpu could not also do.

True, but which is more efficient?

> on sane architectures its all the same ram anyway

The editor in chief of this blog was born in 2004. She uses the 1997 window manager, Enlightenment E16, daily. In this article, I describe the process of fixing a show-stopping, rare bug that dates back to 2006 in the codebase. Surprisingly, the issue has roots in a faulty implementation of Newton’s algorithm.

Introduction⌗

Some may find it weird, but I actually greatly enjoy using Enlightenment E16 as my window manager. It’s themable, hackable, lightweight (24MB peak RSS!), amenable to heavy keyboard users like myself, and most importantly - it looks goregous:

E16 desktop

E16 first came to be in 1997, thanks to Carsten Haitzler, and it has been in development ever since. Most have moved to E17 and other newer versions; a community of hardcore enthusiasts still uses E16, and I am one of them. The codebase is quite old, and it has accumulated a lot of technical debt over the years.

Bugs always come out of the woodworks in a time scramble and this one likely sensed a prime opportunity: I was doing a lot of last-minute work on a couple of slides for a course that I will be teaching. I had a couple of PDFs with lecture slides and an exercise sheet typeset in LaTeX. At some point, I opened one of them in Atril, and the entire desktop froze.

The bug⌗

I killed the X11 session from a TTY. Sadly, the hang was deterministic: every time I opened that specific PDF.

Attaching gdb to the live process showed every sample parked in imlib2’s font cache, under the same e16 caller:

#0  __strcmp_evex ()
#1  __imlib_hash_find (hash=0x55bc9c111420, key="\001\001\001\001\001")     object.c:172
#2  __imlib_font_cache_glyph_get (fn=..., index=0)                          font_draw.c:30
#3  __imlib_font_get_next_glyph (... utf8="Kickoff.pdf — Introduction...")  font_main.c:218
#4  __imlib_font_query_advance (...)                                        font_query.c:89
#5  imlib_get_text_advance (...)                                            api_text.c:231
#6  Efont_extents (...)                                                     text_ift.c:87
#7  _ift_TextSize (...)                                                     text_ift.c:156
#8  TextstateTextFitMB (ts=..., textwidth_limit=291)                        text.c:350
#9  TextstateTextFit (...)                                                  text.c:559
#10 TextstateTextDraw (... text="Kickoff.pdf — Introduction...")            text.c:638
#11 ITApply (...)                                                           iclass.c:930
#12 ITApply (...)                                                           iclass.c:884
#13 _BorderWinpartITclassApply (ewin=..., i=2, force=1)                     borders.c:179
#14 EwinBorderUpdateInfo (ewin=...)                                         borders.c:300
#15 EwinChangesProcess (...)                                                ewins.c:2141
#16 EwinEventPropertyNotify (ewin=..., ev=...)                              ewins.c:1438
...
#21 main (...)                                                              main.c:320

Re-attaching repeatedly showed the program was not deadlocked. __imlib_font_cache_glyph_get was being called with different glyph indices (0, 20, 73, 81, 82, 87, 88, …) each time. So the inner font-measurement was making progress; the loop was somewhere outside it.

After some fudging, I found out that Frame 8 (TextstateTextFitMB at text.c:350) was the constant. That’s a ts->ops->TextSize(ts, new_line, 0, pw, &hh, &ascent); call inside the middle-ellipsis truncation loop that tries to fit a string into textwidth_limit = 291 pixels by nuking characters out of the middle - used when rendering the title of the PDF, that happened to also be the title of the window, too long for the decoration to contain.

Dumping the frame’s locals across many samples revealed a clean two-state oscillation:

nuke_count = 8   nc2 = 36   wc_len = 81   len_n = 76
nuke_count = 11  nc2 = 35   wc_len = 81   len_n = 73
nuke_count = 8   nc2 = 36   wc_len = 81   len_n = 76
...

I always saw two trial truncations, forever, same text each time.

The problematic function⌗

We start at the lowest common denominator - there is likely a logic bug here.

static void
TextstateTextFitMB(TextState *ts, char **ptext, int *pw, int textwidth_limit)
{
    char           *text = *ptext;
    int             width, hh, ascent, cw;
    char           *new_line;
    int             nuke_count, nc2;
    int             len, len_mb;
    wchar_t        *wc_line = NULL;
    int             wc_len, len_n;

    if (EwcOpen(ts->need_utf8 || Mode.locale.utf8_int))
        return;

    len = strlen(text);
    wc_len = EwcStrToWcs(text, len, NULL, 0);
    if (wc_len <= 1)
        goto done;

    wc_line = EMALLOC(wchar_t, wc_len + 1);
    if (!wc_line)
        goto done;

    if (EwcStrToWcs(text, len, wc_line, wc_len) <= 0)
        goto done;

    new_line = EMALLOC(char, len + 10);
    if (!new_line)
        goto done;

    width = *pw;
    nuke_count = ((width - textwidth_limit) * wc_len) / width;
    if (nuke_count < 2)
        nuke_count = 2;

    for (;;)
    {
        if (nuke_count >= wc_len - 1)
        {
            len_mb = EwcWcsToStr(wc_line, 1, new_line, MB_CUR_MAX);
            if (len_mb < 0)
                len_mb = 1;

            strcpy(new_line + len_mb, "...");
            break;
        }

        nc2 = (wc_len - nuke_count) / 2;

        len_mb = EwcWcsToStr(wc_line, nc2, new_line, len + 10);
        memcpy(new_line + len_mb, "...", 3);
        len_mb += 3;
        len_mb += EwcWcsToStr(wc_line + nc2 + nuke_count,
                              wc_len - nc2 - nuke_count,
                              new_line + len_mb, len + 10 - len_mb);
        new_line[len_mb] = '\0';
        len_n = wc_len - nuke_count + 3;

        ts->ops->TextSize(ts, new_line, 0, pw, &hh, &ascent);

        width = *pw;
        nc2 = textwidth_limit - width;
        cw = width / len_n;

        if (nc2 >= 0 && nc2 < 3 * cw)
            break;
        if (nc2 > 0)
            nuke_count -= (nc2 <= 2 * cw) ? 1 : (nc2 + cw / 2) / cw;
        else
            nuke_count += (-nc2 <= 2 * cw) ? 1 : (-nc2 + cw / 2) / cw;
    }

    Efree(text);
    *ptext = new_line;
  done:
    Efree(wc_line);
    EwcClose();
}

The loop is of paticular interest to us. Abridged:

for (;;)
{
    if (nuke_count >= wc_len - 1) { /* degenerate: single char + "..." */ break; }

    nc2 = (wc_len - nuke_count) / 2;
    /* build new_line = first nc2 wchars + "..." + tail wchars */
    len_n = wc_len - nuke_count + 3;

    ts->ops->TextSize(ts, new_line, 0, pw, &hh, &ascent);
    width = *pw;
    nc2 = textwidth_limit - width;
    cw = width / len_n;

    if (nc2 >= 0 && nc2 < 3 * cw)
        break;                                    /* fit, within 3 chars */

    if (nc2 > 0)                                  /* room to spare */
        nuke_count -= (nc2 <= 2 * cw) ? 1 : (nc2 + cw / 2) / cw;
    else                                          /* too wide */
        nuke_count += (-nc2 <= 2 * cw) ? 1 : (-nc2 + cw / 2) / cw;
}

This is a Newton-style search that estimates how many more/fewer wchars to nuke based on how far off width is from textwidth_limit, using cw = width / len_n as the derivative (average pixels per char). Seeing clever and crafty solutions like this is delightful. But to anyone who has ever implemented Newton’s method, this code screams something obvious: “Where is your iteration limit?!”. Newton’s method can fail to converge, and it can also overshoot and diverge - all depending on the starting point, the nature of the function, and the quality of the derivative estimate. In this case, the method was oscillating between two points forever.

To make matters worse, the exit tolerance (ε\varepsilon) is tight - accept only nc2 between [0, 3*cw). This also explains why ordinary short titles never tripped it - on shorter strings or with wider cw, the <= 2*cw branch kicks in and the step becomes 1, which converges.

The fix⌗

I have made three defensive changes, applied symmetrically to both the multi-byte and ASCII loops:

Capped iteration counts at 32. Past the cap, if the current trial fits nc2 >= 0 we just accept it; otherwise bump nuke_count by 1 and retry. This guarantees termination in bounded time and picks the first fitting trial once the Newton step has been shown to oscillate.
We now floor nuke_count at 1 inside the loop, so a negative correction can never produce the degenerate tail-overlaps-head string.
Floor cw at 1, so a pathological zero-width measurement cannot turn the step formulas into a divide-by-zero.

Patch (against e16 1.0.30)⌗

--- a/src/text.c
+++ b/src/text.c
@@ -255,7 +255,7 @@ TextstateTextFit1(TextState *ts, char **ptext, int *pw, int textwidth_limit)
     if (nuke_count < 2)
         nuke_count = 2;

-    for (;;)
+    for (int iter = 0;; iter++)
     {
         if (nuke_count >= len - 1)
         {
@@ -263,6 +263,8 @@ TextstateTextFit1(TextState *ts, char **ptext, int *pw, int textwidth_limit)
             memcpy(new_line + 1, "...", 4);
             break;
         }
+        if (nuke_count < 1)
+            nuke_count = 1;

         nc2 = (len - nuke_count) / 2;

@@ -276,9 +278,18 @@ TextstateTextFit1(TextState *ts, char **ptext, int *pw, int textwidth_limit)
         width = *pw;
         nc2 = textwidth_limit - width;
         cw = width / len_n;
+        if (cw < 1)
+            cw = 1;

         if (nc2 >= 0 && nc2 < 3 * cw)
             break;
+        if (iter >= 32)
+        {
+            if (nc2 >= 0)
+                break;
+            nuke_count++;
+            continue;
+        }
         if (nc2 > 0)
             nuke_count -= (nc2 <= 2 * cw) ? 1 : (nc2 + cw / 2) / cw;
         else
@@ -335,7 +346,7 @@ TextstateTextFitMB(TextState *ts, char **ptext, int *pw, int textwidth_limit)
     if (nuke_count < 2)
         nuke_count = 2;

-    for (;;)
+    for (int iter = 0;; iter++)
     {
         if (nuke_count >= wc_len - 1)
         {
@@ -346,6 +357,8 @@ TextstateTextFitMB(TextState *ts, char **ptext, int *pw, int textwidth_limit)
             strcpy(new_line + len_mb, "...");
             break;
         }
+        if (nuke_count < 1)
+            nuke_count = 1;

         nc2 = (wc_len - nuke_count) / 2;

@@ -362,9 +375,18 @@ TextstateTextFitMB(TextState *ts, char **ptext, int *pw, int textwidth_limit)
         width = *pw;
         nc2 = textwidth_limit - width;
         cw = width / len_n;
+        if (cw < 1)
+            cw = 1;

         if (nc2 >= 0 && nc2 < 3 * cw)
             break;
+        if (iter >= 32)
+        {
+            if (nc2 >= 0)
+                break;
+            nuke_count++;
+            continue;
+        }
         if (nc2 > 0)
             nuke_count -= (nc2 <= 2 * cw) ? 1 : (nc2 + cw / 2) / cw;
         else

Reproducer⌗

Any window whose WM_NAME is long enough that the middle-ellipsis search falls into the overshoot regime reproduces this. The one in the wild:

Kickoff.pdf — Introduction to Information Theory Session 1: kickoff & first topic

(81 wide chars including the em-dash, a ~291px border title slot, font roughly 3px/char average.)

A philosophical detour that nobody asked for.⌗

Newer is not necessarily better. Fresh software carries brand new bugs for you and the maintainers to enjoy, now empowered by the barrier to contribute being much lower thanks to Large Language Models. But sometimes stable maintainers do absurdly dumb things too:

On the 3rd of April 2026, I remarked that fgetxattr(54321, NULL, NULL, 0); apparently crashes yesterday’s 6.6.y lts kernel. A call that should just return -1 and set errno to EINVAL because the path is invalid, but a stable maintainer patched it out wholesale.

Then, the awful commit was reverted, on the 8th of April. No CVE has been assigned despite an obvious Denial-Of-Service attack vector being introduced.

If this is what happens by mistake on a daily basis1, what happens when the supply chain is compromised and a malicious actor intentionally introduces a bug? The mind boggles. Back when the XZ backdoor was introduced, I was scrolling through news on my Debian Sid laptop with some code compiling in the background. I learned of a backdoor in XZ Utils, potentially introduced by a state actor in version v5.6.0. Thinking back to the fact that I do, indeed, run a bleeding edge distro and update often, I immediately ran apt list --upgradable | grep xz-utils. Sure enough, the stains on my laptop from the coffee I spat out through the nose2 were pretty tough to deal with.

On the other hand, the amount of bugs in private checkouts of crusty old software maintained by competent developers will monotonically decrease. If I need a feature, I will implement it. If there is a problem, I only have myself to blame. There is no supply chain to compromise, and if a determined, targetted state actor wants sudo privileges on my machine - they will find a way to get it anyway. Oh, also, eI probably wasn’t going to use whatever features that my XFWM updates (the WM I used to use before!) were going to bring.

Der Notfall ist der Normalfall. ↩︎
5:30am in the morning is not my wordsmith’s prime hour. ↩︎

Hacker Times