RobWords? Yep, RobWords. He’s got some interesting video’s!

I agree that adding a tag or warning might be useful. But it’s also an option to just block it for a week or so. Like you would do if you read the webcomic directly on their website. Hope you’re doing well in any case!

Put that thing back where it came from, or so help me…

Extrapolated from the relevant information in the post (a single data point), that is a solid hypothesis.

I hear the GOAT is even better.

No need. Only the average Dutchman. And he’s only average, so…

Something like tac | head | tac, I guess? Yes, that’s a valid use case indeed :)

I mean… it’s nice that it exists and all, but I can’t really think of many useful usecases.

Heh, no, but they do have a nice set of man pages and other documentation online. I prefer NixOS. Easier keeping track of configuration, easier rolling back of (and experimentation with) new stuff.

So, split.

Edit: although there’s also tac, which could fit the bill as well.

Hayds

I don’t think their “No” was a disagreement, but a confirmation of your second line. https://ell.stackexchange.com/questions/88502/how-to-agree-with-a-negative-statement-with-yes-or-with-no Sometimes, language can be a tricky tool to wield.

That fills me with determination.

Was the solution there to just boot an older/previous kernel?

I wonder if there is a point where the graphs of “perceived effect on the water” cross for both this experiment and homeopathy, and what that means.

Probably understood that in the wrong direction. Ze (eng. phon.) would be spelled more like “sie” (ger. phon.) and would sound like “the” with a German accent. They would become either dey (eng. phon.) or zey (eng. phon.), spelled like “deej” or “seej” (ger. phon.), or even without the y (or j) at the end.

I think. I’m neither native German or English.

As Flatfire mentions, another issue can arise if plugins can modify the config. I assumed config to be read-only for the software, only editable by the admins, and never by the tools themselves.

I’d try to share the config space as much as possible. Options 1 and 3 make sense then.

What feels “right” to me, when using NixOS and its module system, is that all config has the same shape, and is therefor easily moved to a different section, or to a section that is shared by a subset of plugins.

Con: It could lead to bad practices like strengthening dependencies between plugins (if they hard code to use a specific config option of another plugin).

Pro: But if you can discourage that, or use “deprecated pointers” to the new location of an option, the ease of moving shared config options to a more generic level can make it easier to maintain the total configuration. Developers of the separate plugins can build on what others have already done, and even synergize functionality (add a convenient integration if they see another option configured).

If some options are “secret”, though, and you don’t want those shared, they should either be in their own config (easier), or you’d need some access control on the configuration storage/file for each plugin (more work). Allowing a plugin to have a separate file for credentials, for instance, could be a good choice.

Excuse me, sir, this is a well-respected barbershop.

That’s why you feed that flame once in a while.