Need to let loose a primal scream without collecting footnotes first? Have a sneer percolating in your system but not enough time/energy to make a whole post about it? Go forth and be mid: Welcome to the Stubsack, your first port of call for learning fresh Awful you’ll near-instantly regret.
Any awful.systems sub may be subsneered in this subthread, techtakes or no.
If your sneer seems higher quality than you thought, feel free to cut’n’paste it into its own post — there’s no quota for posting and the bar really isn’t that high.
The post Xitter web has spawned soo many “esoteric” right wing freaks, but there’s no appropriate sneer-space for them. I’m talking redscare-ish, reality challenged “culture critics” who write about everything but understand nothing. I’m talking about reply-guys who make the same 6 tweets about the same 3 subjects. They’re inescapable at this point, yet I don’t see them mocked (as much as they should be)
Like, there was one dude a while back who insisted that women couldn’t be surgeons because they didn’t believe in the moon or in stars? I think each and every one of these guys is uniquely fucked up and if I can’t escape them, I would love to sneer at them.
(Semi-obligatory thanks to @dgerard for starting this.)
Does anyone else get tired of “read documentation and edit this text file to configure your app” Unix shit? I have no problem with the underlying configuration being a text-file (makes for a straightforward API), but do I really need to navigate to https://mpv.io/manual/master/#configuration-files and go through the rigamarole of figuring out which options I need to edit/include[0] because I misplaced (read:
sudo rm -rf /
) my config file?[0]: And there is always so much implicit bullshit. “By default, we summon Cthulhu on Tuesdays and Thursdays if the variable
summon_octopus_guy
is unset.” It’s a fucking config file, my friends, can we just be explicit?Personally I think it’s fine to have implicit defaults if you can make them sensible. Maybe ideally have a system-wide config like
/etc/someapp.conf
with all the options included and set to defaults out of the box and then allow overrides in~/.config/someapp/someapp.conf
where you only need to specify whatever you want to differ from the system conf file.I personally disagree. I think in the era of “a megabyte is big,” this made sense, but in my opinion after parsing a config file with missing config data, we should print something indicating they are missing then error out. The existence of a reference config file with all options included would definitely help, but I think it’s no coincidence that there is no such config for mpv — why bother creating and maintaining one if the program will use the default value anyway?
tl;dr explicit is better than implicit
I dunno, MPV has like a million config options and I’ve set like three of them in my config. I would not prefer to maintain an enormous config file where I need to include a bajillion options I don’t care about just to play a video. Would I have to update my config every single time MPV adds, removes or renames an option, too?
At the end of the day you shouldn’t have to maintain anything in order to use a program, in my opinion (at least ideally). I think a “everything must be present in the file” type of config would require
lessno extra maintenance (assuming devs don’t do anything too silly). Additionally, while noting that my primary programming language is TeX and also that I am a dipshit, this just strikes me as an API-design problem. Alternative solutions could be:I have thought about doing #3 for Sway (a sort of Sway-config editor). This does give me an idea, though: define a meta-format for specifying the variables, default values, allowed values, etc., for an arbitrary[0] program’s config file, and create a program that reads a meta-format file and presents a GUI for editing the config.
tbh i just lost my config file, forgot what i changed, and now i have to read documentation (and figure out which file the mpv flatpak uses for config)
[0]: maybe not too arbitrary
I’d kinda love this even if I’m editing config files in a text editor. emacs could use this with a major-mode or LSP to provide suggestions, validity checking, various rendered versions of the config, and guarantee interoperability with graphical tools (so that changes you make in an editor don’t get trampled by the UI, and vice versa)
I need an excuse to learn Rust and have wanted to do a “parse, don’t validate / make invalid states unrepresentable” project for a while. I will definitely share it if I get anything done.
definitely! that sounds like a great first Rust project.
Oh yeah. I recently wanted to configure something in pipewire… the idea was simple: just creating a boot-persistent audio loopback, i.e. connecting an audio input to an output. I gave up for now after looking at the config examples for that in the documentation. How can such a simple thing need such complex configuration?
As for losing configs, I’ve started to put all my hand-edited config files in a git repo on my NAS so at least I only have to figure out things once.
Surely it’s better to specify those defaults in the config file and have the system just fail if the necessary flags aren’t present. Having worked in support I can vouch for the amount of suffering that could be avoided if more systems actually failed if some important configuration isn’t in place.
Completely agree. I think this may just be an extension of the “you gotta know what you’re doing to code correctly in C” old school bullshit.
This is my biggest gripe with that nonsense. If you make it hard to do something well, you won’t end up with an elite series of uber-coders because there aren’t enough of those people to do all the programming that people want to be done. Instead you’ll see that much more software engineering done really goddamned badly and despite appearances at the time it turns out there is a maximum amount of shitty software the world can endure.
What’s great is even the very best “just use valgrind lol, lmao” folks make these errors all the time. It’s basically impossible to write correct C code generally — the best we can do is verify subsets of code (c.f. Rust’s
unsafe
keyword). The memory-safety CVEs in EXT3/4 are proof of this, IMO, as if there were anyone able to write correct C code today, it would be Ted Ts’o.