I think your perspective is totally correct, thank you for sharing it and checking my vitriol.
The only thing I would challenge is that the pain of inconsistency (from distros to stacks, e.g. systemd, etc.) is exactly what I believe drives people to desire/aspire to automation and strive for the consistency.
That inconsistency, while absolutely frustrating at times, also forces users (often against their will) to understand the core concepts behind the software they're using or managing rather than memorizing GUI workflows.
In my opinion, a number of Windows folks seem to take consistency for granted, and become all too reliant on it. They get comfy and have little clue how to overcome adversity when it rears it's ugly head.
I don't think that sort of laziness is unique to the Windows world, but I do think Windows makes it easier to fail upwards. It's much harder to hide incompetence in a Linux environment, at least in my experience.
In other words: if you'll excuse my reductiveness, what doesn't kill, gives strength. Or at least hardens one's resolve.
Honestly my biggest gripe boils down to how easy RDP makes it to form bad habits, and how there is little (short term) consequence for operating in reactive ways which lack reproducibility because "I'll just pop into the server and click around for a sec"
Windows with RDP is faster, and it is easier. System admin that way (mostly) works. Best of all, for the majority of those who grew up in the PC age, it's familiar.
But I unfortunately don't trust a lot of my colleagues past and present not to abuse it.
> It's much harder to hide incompetence in a Linux environment, at least in my experience.
curl | bash enters the chat.
Seriously, though, junior sysadmins (or devs pretending to be sysadmins) are gonna do what they do regardless of the underlying substrate. For Windows sysadmins it might be clicking-around doing one-off "fixes". For Linux admins it's shitting-up production boxes with compilers and dev tools or adding sketchy untrustworthy package repos.
> Honestly my biggest gripe boils down to how easy RDP makes it to form bad habits, and how there is little (short term) consequence for operating in reactive ways which lack reproducibility because "I'll just pop into the server and click around for a sec"
> Windows with RDP is faster, and it is easier. System admin that way (mostly) works. Best of all, for the majority of those who grew up in the PC age, it's familiar.
It's the same w/ SSH on Linux machines, though. Junior people think it's easier to make one-off changes. Senior people realize that every one-off change is a gamble with the future. It's part of the culture and maturity of the individual and of the organization they're working in.
If an org has sysadmin(s) what are devs doing in production? I'm not referring to juniors or devs, although shit obviously rolls down hill.
My point is that whatever is done over SSH is at the very least repeatable with relative ease even if it's incorrect.
SSH has a command history. RDP means recalling what guis were clicked through and which options were selected. Neither is particularly scalable and both are imperfect but only one of those is faulty by default.
In the case of ssh at least I can copy and paste (then fix) some idiot's commands into a script as a starting point for automation. What are my options after a whackamole RDP session?
How is logging in to a Windows box with RDP and clicking around different from logging in to a Linux box with SSH and messing around in a trial-and-error fashion with text files though?
Things like „oh this doesn’t work with SELinux enabled, so let’s just disable SELinux“ for example.
I‘ve seen both and I wouldn’t necessarily say I‘ve seen the former more often.
There’s probably as many incompetent Linux admins as there are incompetent Windows admins. At least in my personal experience.
There's no difference in the tasks you you described. I'm not saying it's not possible to do bad work over SSH, I'm saying it's in fact more punishing. If something is 500 keystrokes to do in Linux, you're incentized to do it in an automated fashion to avoid repetitive cli shenanigans. If the same thing is 2 clicks over RDP, who's going to bother scripting that? I'm not opposed to easy, I'm in favor of reproducibility and self documenting scripts.
There's no such incentive with windows because it's so "easy" and things like powershell's double hop and other similar quirks can actually make certian things more difficult to automate.
My point is, at least you can easily translate random CLI poking into scripts. more often than not, an RDP session doesn't lend itself to scripting.
The only thing I would challenge is that the pain of inconsistency (from distros to stacks, e.g. systemd, etc.) is exactly what I believe drives people to desire/aspire to automation and strive for the consistency.
That inconsistency, while absolutely frustrating at times, also forces users (often against their will) to understand the core concepts behind the software they're using or managing rather than memorizing GUI workflows.
In my opinion, a number of Windows folks seem to take consistency for granted, and become all too reliant on it. They get comfy and have little clue how to overcome adversity when it rears it's ugly head.
I don't think that sort of laziness is unique to the Windows world, but I do think Windows makes it easier to fail upwards. It's much harder to hide incompetence in a Linux environment, at least in my experience.
In other words: if you'll excuse my reductiveness, what doesn't kill, gives strength. Or at least hardens one's resolve.
Honestly my biggest gripe boils down to how easy RDP makes it to form bad habits, and how there is little (short term) consequence for operating in reactive ways which lack reproducibility because "I'll just pop into the server and click around for a sec"
Windows with RDP is faster, and it is easier. System admin that way (mostly) works. Best of all, for the majority of those who grew up in the PC age, it's familiar.
But I unfortunately don't trust a lot of my colleagues past and present not to abuse it.