Notices by Chris Siebenmann (cks@mastodon.social)

It's my further view (not expressed in my original toot) that it's not enough for command line tools to suppress their fancy output if they're not being run through a tty. I want to be able to run them from a regular shell session, in a pty, without the fancy output, for a variety of reasons.

I may be running them under `script' to capture their output but still leave them interactive. I may be working over a slow or saturated network link and I don't want to get all that extra text. Etc.

Every command line tool that pretty-prints progress bars and live status reports and all that stuff as it goes along in ways that constantly print characters and require a cursor-addressable display (or ANSI code support or etc) should have a way of turning all that off and printing things a line at a time with no fancy progress bars.

This rant is brought to you by dnf5, but it's not the only offender. At least 'apt' isn't the only way, you can use 'apt-get' and so on.

Thesis: DNS Is not meaningfully a database, because it's explicitly designed and used today so that it gives different answers to different people. Is it implemented with databases? Sure. But treating it as a database is a mistake. It's a query oracle, and as a query oracle it's not trustworthy in the way that you would normally trust a database to be, for example, consistent between different people querying it.

Am I sticking a 🇨🇦 in my profile on various places these days? Yes, yes I am, at least in places that don't already mention something about my location. Although this is my unhappy face about things that don't accept emoji (or at least that emoji) in displayed names, profiles, etc etc.

It has been '0' days since I saw programmers not understanding camera sensor technology and thus not understanding why RAW files exist. You cannot have a file format that simultaneously has truly raw sensor readings and that has no camera-specific information embedded into it that's necessary to interpret those raw numbers. You have to pick one, because camera sensors don't all have the same spectral response characteristics.

I think the best public April Fools joke in computing in the past 20 years has been GMail. Yes, I know, it wasn't a joke. That's why it's the best joke.

Me, still an innocent: "Surely paying people must be a known thing, how many professor FTEs do we have?"
Admin person: snaps open a large multi-page PDF with the circles and arrows (tm Arlo Guthrie).

Me, an innocent: "So, how many professors are there in our university department?"
Admin person with a thousand yard stare: "Well, it depends on what you mean by 'professor', 'in', and 'department." <unfolds large and complicated chart>

One thing I heard a long time ago and that has stuck with me ever since is that when you make a process difficult to get through, the people you get at the ends are the ones that are most passionate and motivated, and this passion and motivation is not necessarily for good. I originally heard this as applied to bug reporting systems, but colour me unsurprised that this applies to email anti-spam measures too, where the spammers have the motivation and energy.

In re: https://toad.social/@grumpybozo/114213600922816869

Current status: trying to figure out how POSIX fsync() interacts with POSIX mmap() if you're being standard-perverse, for reasons.

(Spoiler: POSIX isn't designed to withstand people being standard-perverse.)

I am apparently going to need a Linux 'secret(s) provider' (something that handles org.freedesktop.secrets). Gnome-keyring is not what I want, in fact I would like a 'secret provider' that stores secrets in memory only and throws them away almost immediately. Most options are heavyweight, but there's pass-secrets¹ which uses pass², except that pass wants to use gpg and this is my face. Life is too short to wrestle with the greased gpg pig.

¹ https://github.com/nullobsi/pass-secrets
² https://www.passwordstore.org/

This is my face as I'm trying to find an X program that will show me some text in a given XFT font family and size, so I can see just how big it is. xterm will do fine for monospaced fonts, but if I want to see what 'Sans-11' actually looks like, apparently this is a bit non-obvious.

(Am I going to have to write this myself in Tcl/TK or Python/TK?)

@mhoye I think all security warnings are an extremely hard problem, because they're almost always false positives (most people aren't getting attacked, thank goodness). It's really hard to be sure it's not a false positive so you throw up the alert, but then people get alert fatigue and etc etc.

(We sort of went through the same thing with browser HTTPS warnings until browsers made it really, really hard to get past them and everyone accepted that sites shouldn't screw up certs.)

@b0rk I ticked off 'the shell' in my set of answers because of technical knowledge: a shell with readline handling is handling Ctrl+C itself when you're editing a command line. Many shells/readline environments will react to Ctrl+C this way by 'interrupting' the command line you're editing and giving you a new top level prompt (which is handy if eg you're writing a multi-line 'for' or 'while' or etc and change your mind; you can Ctrl+C to throw the entire thing away).

@atoponce I look forward with dread to discovering all of the little quirks of GNU coreutils behavior that are not actually duplicated in uutils. ('100% compatibility' is nice in theory but I don't believe it's going to be achieved in the first major release, not even by 26.04 LTS, and I don't think Canonical will care.)

@mos_8502 @NanoRaptor My university did select SGI over Sun in the mid 90s for a servers + basic colour workstations RFP (that's how I wound up using an Indy for a while), but I don't know how important the workstation price was and there turned out to be extra factors (... which is a story in itself, about how salespeople will sometimes lie a *lot* and how useless contracts are in practice).

@gray17 @wollman @b0rk I think there may be a collection of reasons on Unix's original very small machines:
* general context switch overhead between the kernel and user processes.
* user programs could get line-based input so only had to wake up infrequently, not every character for even lower overhead.
* there were no shared libraries, so basic line editing took less overall code space in the kernel than a copy in every application.
* the kernel's a central point so everyone did it the same.

@mos_8502 I wonder how much of this behavior in GTK and QT came from them being developed at a time when I think the general attitude everywhere was 'if you need things on screen to be bigger, get a bigger display' (at least in the Windows world, I think). My somewhat vague memory is we spent a long time with (maximum) achievable CRT resolution basically fixed, little to no GUI scaling for various reasons (eg bitmaps everywhere), and varying sized CRTs.

Thesis: most desktop GUIs are not opinionated about how you interact with things, and this is why there are so many GUI toolkits and they make so little difference to programs, and also why the browser is a perfectly good cross-platform GUI (and why cross-platform GUIs in general).

Some GUIs are quite opinionated (eg Plan 9's Acme) but most are basically the same. Which isn't necessarily a bad thing but it creates a sameness.

(Custom GUIs are good for frequent users, bad for occasional ones.)

@drscriptt I want my uncommitted change to be added to an existing local commit (which in git rebase terms is a fixup of a prior commit). In theory git-absorb is good for this, in practice it didn't go.