Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@madcap @katnjiapus Or to put it differently and perhaps more concisely: "fiddling with all the subtle knobs and tradeoffs to get a perfect security profile" is the job of security experts and, especially, designers of systems who then package these decisions into simple-to-reason about policy options/defaults.

This is not something to expect from your everyday server admin, they should only need to select the simple-to-reason about policies - and if you feel that the available policies in existing systems aren't good enough, then that is best addressed by contributing to those systems, not by trying to tell individual server admins to deal with a highly complex landscape of unfamiliar security options.

@madcap @katnjiapus Sure, fail2ban has other usecases, but in this case I was talking about SSH only - other usecases would fall under "application-specific needs" (because modern applications generally handle rate-limiting themselves, and do not need an external tool for this).

For "SSH only from home/office IP", a similar problem applies - it is very easy to lock yourself out if, for instance, your ISP suddenly changes your IP. These sorts of measures are not free to add, so before adding them, you need to understand very well what the tradeoffs are.

There are a million things you could do that theoretically, in some rare edge cases, some tiny amount of the time, might slightly help security - usually more by coincidence than anything else. Using fail2ban against SSH exploits is one of those cases; it is vanishingly unlikely to actually do that under real-world circumstances.

Stacking a ton of those "might as well" measures together is not actually good security policy - you just end up adding a lot of complexity (and therefore new ways for the system as a whole thing to fail, through human error or otherwise), with very little to show for it. It can easily end up making things worse.

So unless server security is your expertise, you should just stick with a small set of known-good security policies (like key-only auth) that has a clear and unambiguous security benefit, and leave it at that, honestly.

@mos_8502 From what I understand, if the contacts are sufficiently worn out along the way, chaining power strips (or any other sort of chaining of multiple imperfect connections) can cause some types of breakers to respond dangerously slowly.

@vkc That's not normal, no. If they refuse to cooperate, I believe you can ask ICANN to step in and force the transfer.

@nora As someone unfamiliar with their Discord, is there anywhere I can read more about this?

@cephie (I ended up addressing this one in my other reply, with the Firefox example)

@cephie "do you see customisability mostly as a means to paper over shortcomings in design, then?"

Only partly. In theory, customizability *should* be about allowing someone to nudge and shape their system so that it's perfect for them. *In practice*, however, I find that in Linux-land it is almost always used as a means to paper over design shortcomings.

This is pretty obvious from how unnecessarily difficult a lot of things are to set up, with very little standardization between projects going on, even on points that absolutely could be standardized.

"What's meant to happen when folks run up against limitations if they find themselves not in the "most people" category?"

This is why there *should* still be avenues for customization - but crucially, this is an edgecase, and it should be treated as such, instead of being treated as the main case like it is now.

As a simplified example, if you're building a desktop environment, you could take roughly two approaches:
1. Add extensibility at every layer of the stack, so that every bit of internals of the DE is customizable, whether at a low or a high level.
2. Add extensibility at one well-specified point in the stack; either you use the whole DE as-is, or you use none of it, or you replace a few specific components in it wholesale, but that's the end of your options.

If you're trying to maximize customizability, then on paper approach 1 sounds optimal; you can change anything very easily! It optimizes for people wanting to customize.

But the flipside of that is that your reliability suffers (a lot of variable moving parts), you cannot do architectural reworks *at all* anymore (because all the extensibility surfaces are 'locked in' architecturally), and it becomes extremely difficult to reason about how the codebase works, and therefore to maintain it.

That is why approach 2 makes more sense; you optimize for the common case of "I just need my computer to be a tool", make maintenance vastly simpler and the code vastly more reliable, and leave sufficient space for the tinkerers to replace parts that they don't like.

That customization will require a bit more work in approach 2, but this is IMO a reasonable burden to place on the tinkerer; because the alternative in approach 1 is that the burden of customizability is placed on the *common case* user instead.

Firefox used to do approach 1 for its extensions. It single-handedly held them back from being able to speed up their browser for years, until they eventually replaced the extension API with one that followed approach 2. Suddenly, Firefox became vastly more usable for most people.

"Perhaps there's a zealous push toward "customise all the things!" (even those things that are dangerous, or don't make sense) that i've missed,"

Pretty much. Any time anything vaguely usable is suggested, an extremely vocal contingent of angry nerds descend on whoever is doing it to complain about how it isn't perfectly interoperable with their bespoke setup, practically starting a misinformation campaign. See: systemd, pipewire, and so on.

@cephie In the end, the 'perfect' environment is going to be a balance between usability and customizability; and most importantly, it matters *where* the customizability is.

GNOME's approach of "just strip everything down even when customizability would be trivial to support" is not that balance, but "always make everything customizable at any cost" also isn't.

And I just don't see *any* desktop environments in the Linux space doing very well at striking this balance; it's always one way or the other. Leaving very little real-world choice despite the apparent landscape of options.

@cephie No worries, I understand; that's also why I mentioned that there *are* people who genuinely need customizability; because this isn't a reason to drop customizability entirely either.

It's more criticizing a pattern I've seen in Linux-land where a lot of usability issues are explained away by saying "well, you have options!" as if that justifies it, and I feel that this is at least in part a feedback loop - where the "ensuring customizability" often comes at the cost of being *able* to make things work well.

(This is all entirely separated from what GNOME is doing, which IMO has very little to do with usability, and a lot with Branding(tm). If GNOME actually cared about usability, they wouldn't be hard-coding poor UI font choices, for example. So please don't let that affect your view of 'usability' in general)

@cephie To summarize it more bluntly: if desktop environments were good, you wouldn't notice them, and "how to make sure they suit my needs" would not be a thing you'd be thinking about in the first place, it'd just *be there*

@cephie I think so - to try and rephrase it in the context of your description, my argument is that "making an environment that suits me in a personal way" would not be such a common requirement if desktop environments actually did a good job of being suitable for a lot of people's needs, but they don't really. And so this is a thing that people end up trying to solve themselves.

And I think that at the root of this is not just "the existing desktop environments don't suit common needs", but also "I do not *trust* that they will, now or in the future" - which is something I feel I also see in your comment about "ever-shrinking customisability"; it speaks of a concern that things will get worse, instead of better.

And I think that applies to a lot of people, and that it would be much less of an issue if desktop environments provided a better experience that suits more people's needs out-of-the-box, and builds their trust better.

This - sometimes bordering on aggressive - drive for total customization in the Linux userbase is, to me, simply a symptom that people's needs are not being met.