If incompentence seems unlikely may I assume malice?

I've mentioned before that I generally keep my project source directories at work in a place where there are accessibly from the host (Windows) operating system, my msys working environment, and my WSL (linux) instances.¹ Some IT trouble recently has seem me migrate off my usual work machine onto a loaner and now back to the (freshly re-imaged) original. Which has meant re-building my working environments a couple of times.

Now, with one thing and another my re-imaged machine came back to me without a stand-alone X11 server,² so I though "Now'd be a good time to see if WSL2 really is better than WSL1; what with the wslg display adapter meaning that WSL2 doesn't need X11." Anyone familiar with this domain will know that WSL2 has been a thing for quite a while now, but the combination of (a) inertia and (b) reports that access to the host-filesystem access was slow on 2 had kept me from moving forward.

Anyway, I tried it today.

The virtual machine actual runs noticably faster which is nice, but "slow" doesn't even begin to describe the productivity bottle-neck that is access to the host filesystem. Holy deity-figure-on-a-pogo-stick, Batman! This performs like something offered as a minimum viable product from a failing startup run by kids who really should have stayed in school. A sloth dying in a tarpit moves faster than a cmake configure over that channel. I was longing for the heady days of running autoconf on a pentium. I had time to muse about the bandwidth of a stationwagon full of tapes as delivered by continental drift.

I'm following a colleague's lead and keeping a separate source tree for the WSL image and using rsync-spawned-by-cron to keep them tracking one-another.³

And now we get around to the question of incompetence versus malice. The famous adage tells us to set our Baysean prior in favor of "Incompetence", but this is a Microsoft product on it's second version number. Incompetence simply isn't what I would expect. The usual excuses just ring hollow: the people who put this together are not beginners, they had access to as much deep technical support as they needed, and they had a v1 product out in the world doing well so there wasn't a live-or-die deadline to meet.

On the other hand, Microsoft has more than a little history of trying to leverage their market share to try to kill inconvenient competitors.

---

¹ For that matter before some "security" upgrades broke all the non-Microsoft virtualization tools on Windows (VirtualBox we hardly knew 'ya), I would use those same files from my virtual machines, too.

² Probably an oversight on my part as I don't recall saying that I needed one.

³ The thing is that parts of the host filesystem (includind the bit where I keep the source trees) is auto-backed up by IT, a feature that's very handy for the biggest part of your daily work, eh?

Compatability history

Have you ever noticed how hard it can be to find out which versions of software (a) were compatible with which versions of software (b)?

Documentation for software that is meant to interoperate with other software generally says something about which version(s) of the counterpart it works with, but no one has any particular reason to keep a list of the history of that relationship.

What brought this on, you ask?

I'm trying to modernize my Emacs configuration file (for which there are many luxurious options) any have reasonably uniform behavior across the several systems I work on and home and work. Alas, customer requirements at work mean I need to deal with systems dating from 2014 (and we're happy they've finally gotten serious about migrating off that platform from 2010).

All those, aforementioned, luxurious ways to configure a modern Emacs system (Spacemacs, Doom Emacs, and other "distributions") require you to be using, well, a modern version of Emacs. By which they mean v25 is definitely out and v26,fi supported at all, will soon by unsupported.

So I'm trying to do it for myself. My strategy depend on several things:

• add-package to centralize the configuration
• straight as a way to get packages
• the identification semantic categories of behavior I'd like my emacs to have and the understanding that those behaviors could be provided by different packages for different Emacs versions
• a system for selecting implementations of those categories by Emacs version number

I expect to make the project publicly available pretty soon.

But let's say my category is language server services. Popular suppliers seem to be eglot and lsp-mode. If I want to use lsp-mode on a up-to-date Emacs I'll just let straight grab the newest release of the package. But the newest version relies on variable that are not in Emacs 26, so I need an older version, but how do I learn which tag straight should get for those system?

And the problem repeats for every behavior which isn't handled internally.

Which, I suppose, is why the big distributions tell you "Use a modern Emacs, already!", albeit usually in more diplomatic terms.

But ... I knew that. I just didn't understand the importance of what I knew.

Still more Randall Monroe greatness.

What with one thing and another I learned about the TEA project recently. Ambitious stuff, and I'm completely unprepared to talk about the project as a whole, but being a ex-academic, I wasted no time downloading the white-paper, and brought along a dead-trees version for flight as we took our spawn off to visit one set of Grandparents.¹ The paper concerns itself with a distributed crytographic ledger to be used for archiving and authenticating the open-source ecosystem but also to provide a framework for distributing donations across that ecosystem.

The point is that much of the open-source ecosystem is un-sexy tooling and infrastructure that only excites the people who use it to write other open-source software, but donation come from either users (who tend to direct them to sexy top-of-the-stack end-user stuff) and companies (who direct them to things they are specifically trying to improve). Very little money flows to underlying stuff that "just works" even if it requires on-going maintenance to preserve that state of operability. There is a reason Randall uses the word "thanklessly" in the comic. Anyway, the paper observes that to perform such a distribution you would need to know how much each project contributes to the ecosystem, and then that a package manager (such as apt, pip, npm, or homebrew) is exactly an encoded version of that knowledge.

I'm pretty sure my jaw hung slack for the several seconds it took for my mind to re-orient on my freshly remade understanding of the open-source ecosystem. Of course, the package managers already know that stuff. At least collectively.² And maybe missing the dependency links implicit in rarely used build options. But for the most part it's there.

---

¹ Between the pandemic and our commitments taking care of honorary Grandma we'd been able to avoid this for some time. Now we will, no doubt, have to do the other Grandparents soon as well.

² It is worth noticing that there are multiple classes of package managers and build dependency systems out there, handling independent (well, largely independent) and distinct (again, largely) ecosystems. To perform as envisioned the proposed tea protocol will need to be flexible enough to express relationships within and between all such groupings. Not easy stuff.

But what are the opinons?

I'm about to experiment with a piece of software (the meson build system). Now, I've read this and that and I've watched a couple of video presentation by the author who acknowledges that the software is opinonated and gives a reasonably convincing argument for why that is a good (or at least appropriate) thing for a build system.

Fine. I'll buy it for the interim. But .. what are the opinons? What rules does the tool enforce that I might not be used to from other tools in the same space? Is there a list? If so I can't find it. I'm not asking because I want to use them as a reason to reject this thing, I've commited myself in my own mind to trying it. But I'd like to get into the required mindset. Only there doesn't seem to be a single place to look.

Maybe type aliases are part of the happy medium.

Tension between conflicting goals is as much a part of software as it is of life in general. Today I am thinking in particular of the tension bewteen planning ahead and generality on one hand and KISS and YAGNI on the other. Plan too little and you either end up with multiple slightly incompatible implementations of parts of your design or you metaphorically paint yourself into a corner and have to redsign at a large scale. Plan too much and you both over complicate and waste time writing features you never use. Somewhere in the middle is a sweet spot that you aim for.

I've been working on reining in my tendency to overplan for some years, and I'm doing a lot better these days. Except for one one paricular case: making thing type-generic. If I'm writing a class and ask "Hmm ... what type of underlying data should this use?" and don't find an immediately obvious answer my first reaction is to type template <typename T>.

Looked at naively this is a good trade-off: the mental cost of writing and reading a simple template that just serves to defer the choice of underlying type is barely more than that for the untempalted code, and it increases the generality of the code. What's not to like?.

But there are hidden costs: increased compile times; latent bugs,¹ and the need to chose between explcit declaration of desired instances and header-only code. And of course, header-only code makes the compile time issue worse. Now I'm aware of techniques like thin templates, but that negates my claim that the template isn't any harder to write or read than the untemaplated option.

Today, while I was waiting on yet another overly long build I had a long overdue insight. In most case that template class starts something like:

template <typename T>
class Thing 
{
public:
   using part_t = T;
   //...

That is I've borrowed the habit of naming types related to my classes using type aliases (seen in the standard library and elsewhere). But here is the crucial observation: I could write Thing without templates and still use the type alias with a interim choice for the type:

class Thing 
{
public:
   using part_t = float; // Just pick something for now...
   //...

If I change my mind about the type fixing it is a one-line edit.² And if I find that I need multiple choices later coverting the class to a template is a straight forward refactoring step, but I don't pay the template costs until I actually make that call.

---

¹ Even latent compile time bugs. I've had to fix compile-time bugs in code that's been in the repositoy for months because we finally instantiated it with a type where the bug surfaced.

² As long as I am consistent in using the alias, but I'm trying to do that for readability anyway.

Counterproductive software policy

In the Time Before (tm) I used to make regular pilgrimages to one of my employer's offices nearly an hour away. On these and other drives where I have signficant blocks of time alone I listen to podcasts in the car.¹ Today I was dispatched to do the once-a-month in-person shopping that our household needs despite copious (not to say excessive) use of internet shopping and local grocery delivery. I feel there is enough driving in that to justify story time.

Now the default podcast app on my iPhone doesn't interface well with my car's bluetooth audio system. Sometimes it thinks it's connected and running but no sounds comes from any device and it can't be fixed without rebooting the phone. So I tried Radio Public which isn't ideal but works a lot better with the car.²

Of course, sometime I start driving without remembering to start the app. So ... "Hey, creepy Siri." ... "Start Radio Public." And then Siri tells me that she can't do that while I'm driving.

Of course, I'm trying to do it by voice because I'm driving: the point is to keep my hands on the wheel and my eyes on the road.

I appreciate that Apple is concerned about the role of phones in distracted driving, but surely voice control is less distracting (not to mention more leagally acceptable) than diddling the screen with your fingers.³ This particular policy seem to be defeat its own purpose.

Anyone know of a podcast app for iThings that I can control by voice while driving?

---

¹ Escape Pod, Clarkesworld, and Drabblecast if you care.

² It would be very easy to convince me that this is the car's fault, but so what? I can't easily upgrade the car's entertainment system.

³ I know, I know. Don't call you Shirley.