20+ years in industry as a UNIX and Linux admin. Informed but potentially biased.
Linux admins have tended in my career to be more expensive. They tend to be more week rounded as engineers. Linux by it’s nature, especially in the past, required you to be a DBA, network admin, server admin, developer all in one. They can often fix problems quicker than the support engineer elsewhere can read the ticket.
That means you pay more per engineer, MBAs don’t like this. This is a critical problem. You pay less overall in staff costs because you need less staff, MBAs don’t understand this. MBAs like support contracts so they can offset blame.
A small, concise, tight nit, well payed admin team who have ownership and care about a product will be cheaper, and have more uptime than the alternatives. But they’ll also be obstinate, high payed, entitled and ready to jump ship if you mistreat them. That means you need actual diplomacy and social skills to manage them well.
A small tight nit team with product ownership will need a kick up the arse at times to change “what ain’t broke”. So when product requirements need a radically different solution that can take time to change.
There is a reason that industry breaking startups in the early 2000s had their corporate backbones on Linux.
Even then, not having to move your hands means not spending time… Moving your hands.
This is useful for people who want to spend time learning to be enforcement at what they do. In the same way that holding a Nintendo controller “weird” is useful for Tetris speed runners.
If you are as efficient as you need to be using a shower interface, then great. Other people need (or more likely want) to be more efficient than that.
Maybe I’m a luddite, but I still don’t understand why people want to spend their time arguing with Claude code and fixing it’s bugs. Rather than just learning to write productive coffee themselves. But, people do. That’s their choice, and I let them to it.
If prefer to spend my time learning him and code, than Claude and idiosyncrasies, and then whatever to comes next, and next again.