2020-09-07
Why Fedora version upgrades are complicated and painful for me
It's September and I still haven't upgraded any of my machines to Fedora 32 (which came out at the end of April). If I delay too much longer, I might run into Fedora 33 coming out and Fedora 31 dropping out of my upgrade path, so I really need to start getting moving on this. But, much like why updating my Fedora kernels is complicated, my Fedora version updates are a drag; complex, time consuming, and periodically painful. So I keep not getting around to it.
(In a normal year, I would have spent a slow afternoon at work to upgrade the work machine, in an environment where having it not work is not completely disruptive, then upgraded the home machine. That's not today's environment; now I'm at home, and my home desktop is also my DSL gateway.)
Normal people have sensible straightforward Fedora upgrade processes.
They start the upgrade in one of the official methods, go away for
a an hour or three, and it all works. Because my machines run such
an unusual and custom set of environments, I don't trust this process
and I also don't want to be without either my home desktop or my
work desktop for several hours. So the first complication of my
upgrades is that I do live upgrades using dnf and
during them, I watch dnf's output to see if there are signs of
problems with package updates. I can do other things during this,
but that's more than an hour where I am basically babysitting the
machine while distracting myself every so often. This is a time
sink and not a terribly pleasant way to spend my time, but it's
probably the least of the upgrade's pain. Doing upgrades in an
unofficial way on an unusual system configuration also raises the
risks that something will break during them, and I can never
completely test this in advance (for example).
(I capture all the dnf output by using script so that I can
also look at it later, but there's no good way that I know of to
scan through the result the way I could with a more straightforward
log file. Something like less will show me the raw output,
complete with progress bars being rendered and so on. And my terminal
windows only have so much backscroll.)
The next big complication is that I use ZFS on Linux for my home directory and other critical things, and it's of course not integrated with Fedora. This means there's always a risk of something going wrong with my ZFS setup during a Fedora version upgrade. To deal with this, I 'preflight' my Fedora version upgrades extensively on virtual machines (which helps deal with the 'will they work in general' issue). This takes its own set of time and preparation work, and is its own kind of little slog.
Finally, upgrading Fedora sometimes creates problems in my custom desktop environment (or non-environment) that I'll have to then sort out (for example). These range from somewhat modest, such as font rendering issues, to significant, such as sound not working any more. In extreme cases, my desktop environment won't start at all and I get to spend some time sorting things out. This means that I can only start the upgrade on a day when I feel that I have that kind of time left in the day, and I have to be up to dealing with various kinds of irritation about my environment exploding.
There really isn't anything that can be done about all of this, and it's really all a pain that I've set myself up for through my own machine setup choices. So some time, I just have to say that I'm spending this afternoon (or this day) on the work, and get it done (and I'm hoping that writing this entry will help push me forward on it).
(Sometimes I wonder if tracking Fedora Rawhide would make my life easier by spreading this time and effort out over a longer time, instead of concentrating it all in a few days. But Rawhide's potential for serious bugs discourages me. What I really want is a rolling release of 'stable' Fedora, with no big bangs of major releases, but this will probably never exist. There are sensible reasons for distributions to like the idea of major releases, but that's for another entry.)
URL query parameters and how laxness creates de facto requirements on the web
One of the ways that DWiki (the code behind Wandering Thoughts) is unusual is that it strictly validates the query parameters
it receives on URLs, including on HTTP GET requests for ordinary
pages. If a HTTP request has unexpected and unsupported query
parameters, such a GET request will normally fail. When I made
this decision it seemed the cautious and conservative approach, but
this caution has turned out to be a mistake on the modern web. In practice, all sorts of sites will
generate versions of your URLs with all sorts of extra query
parameters tacked on, give them to people, and expect them to work.
If your website refuses to play along, (some) people won't get to
see your content. On today's web, you need to accept (and then
ignore) arbitrary query parameters on your URLs.
(Today's new query parameter is 's=NN', for various values of NN like '04' and '09'. I'm not sure what's generating these URLs, but it may be Slack.)
You might wonder how we got here, and that is a story of lax behavior
(or, if you prefer, being liberal in what you accept). In the
beginning, both Apache (for static web pages) and early web
applications often ignored extra query parameters on URLs, at least
on GET requests. I suspect that other early web servers also
imitated Apache here, but I have less exposure to their behavior
than Apache's. My guess is that this behavior wasn't deliberate,
it was just the simplest way to implement both Apache and early
web applications; you paid attention to what you cared about and
didn't bother to explicitly check that nothing else was supplied.
When people noticed that this behavior was commonplace and widespread, they began using it. I believe that one of the early uses was for embedding 'where this link was shared' information for your own web analytics (cf), either based on your logs or using JavaScript embedded in the page. In the way of things, once this was common enough other people began helpfully tagging the links that were shared through them for you, which is why I began to see various 'utm_*' query parameters on inbound requests to Wandering Thoughts even though I never published such URLs. Web developers don't leave attractive nuisances alone for long, so soon enough people were sticking on extra query parameters to your URLs that were mostly for them and not so much for you. Facebook may have been one of the early pioneers here with their 'fbclid' parameter, but other websites have hopped on this particular train since then (as I saw recently with these 's=NN' parameters).
At this point, the practice of other websites and services adding random query parameters to your URLs that pass through them is so wide spread and common that accepting random query parameters is pretty much a practical requirement for any web content serving software that wants to see wide use and not be irritating to the people operating it. If, like DWiki, you stick to your guns and refuse to accept some or all of them, you will drop some amount of your incoming requests from real people, disappointing would be readers.
This practical requirement for URL handling is not documented in any specification, and it's probably not in most 'best practices' documentation. People writing new web serving systems that are tempted to be strict and safe and cautious get to learn about it the hard way.
In general, any laxness in actual implementations of a system can create a similar spiral of de facto requirements. Something that is permitted and is useful to people will be used, and then supporting that becomes a requirement. This is especially the case in a distributed system like the web, where any attempt to tighten the rules would only be initially supported by a minority of websites. These websites would be 'outvoted' by the vast majority of websites that allow the lax behavior and support it, because that's what happens when the vast majority work and the minority don't.