I think you either missed the point or are intentionally sidestepping the point. If I have a favorite band and they're reasonably large and I want to go see them live, it'd be a bonafide miracle if their show wasn't at a LiveNation venue. The local spots are simply too small to be a reasonable stop on tour for any moderately popular artist.
I agree that you should definitely go see local artists at local venues, but you can do that and still really want to take your dad to see Steve Hackett play a live show. It's not up to you to decide what enriches my life.
> Come to think of it, if there is a latching door on the detergent tray, your dishwasher definitely has a prewash cycle, or else they’d skip the door entirely
Alec also mentions this briefly in the linked video; if manufacturers could avoid the cost of a latching mechanism, they absolutely would. Its presence means a pre-wash cycle exists.
Extreme aversion to NIH syndrome, perhaps? I agree that it's weird. Sure, don't try to roll your own crypto library but the amount of `require('left-pad')` in the wild is egregious.
Your argument highlights its own flaw; changing your editor opens up a world of tooling that's certainly adequate for most use cases you can throw at it, but it also requires either discarding or (worse) un-learning all of the tooling that you've learned for your current editor.
For example, I'm perfectly content to use nvim as my primary editor, and this was born out of having to develop for and administer literally tens of thousands of linux servers professionally. I have all the plug-ins and configuration necessary for productivity on my development machines, and when I'm on a remote system ad hoc editing a configuration it already has a built-in lightweight version of the editor I'm already used to.
If I switched to Emacs locally, I'd still have to maintain a working knowledge of vi and context switch when in a remote shell. Changing to Emacs would require more cognitive bandwidth when the whole purpose of "switching for org mode" is to reduce mental load.
I've built a setup that orchestrates updates for any number of remotes without needing a permanently hosted registry. I have a container build VM at HQ that also runs a registry container pointed at the local image store. Updates involve connecting to remote hosts over SSH, establishing a reverse tunnel, and triggering the remote hosts to pull from the "localhost" registry (over the tunnel to my buildserver registry).
The connection back to HQ only lasts as long as necessary to pull the layers, tagging works as expected, etc etc. It's like having an on-demand hosted registry and requires no additional cruft on the remotes. I've been migrating to Podman and this process works flawlessly there too, fwiw.
I wish there were better coupling between TST and STG (Simple Tab Groups). Automatic nesting of TST is great, but sometimes I'd like to just move a whole tree into a named group. Maybe I'm just doing it wrong.
Hey just want to take the opportunity to say thanks for your efforts with releng. I'm always pleasantly surprised by how quick and effective you folks are with getting updates built, validated, and shipped when upstream has a release.
This is just categorically wrong. Alma is no longer a 1:1 binary copy of RHEL due to the licensing changes RedHat made in 2023, but it is absolutely still binary compatible.
I agree that you should definitely go see local artists at local venues, but you can do that and still really want to take your dad to see Steve Hackett play a live show. It's not up to you to decide what enriches my life.