> Yet the oddly amusing part is how systemd isn't difficult to learn. The only valid complaint against systemd IMO is its departure from Unix philosophy, but for some parts of the \*nix ecosystem, I can't help but think that boat sailed long ago.
This is what I say when people complain that systemd "isn't Unix". Neither are package managers, but I don't see anybody saying we should revert to passing around tarballs that unpack onto root (other than Patrick Volkerding).
> [...] the easiest way to use the distribution isn't to fret over change but to embrace it. Otherwise you'll be implementing fragile workarounds that break every time you update.
I'm thinking about putting together a talk about exactly this, tentatively titled "MacGyver-Driven Development". It's my response to people who respond to any criticism with "Yeah, but then you can just put some tools on top of it": relying on tools only adds another dependency that makes your system more fragile and resistant to change.
The proper way to develop is to keep what you do as small and environment-agnostic as possible. That way, when tides do change, you don't have to fight them or work hard to embrace them; you can just go with the flow, and just change the few parts that touched the changing dependency.
This is what I say when people complain that systemd "isn't Unix". Neither are package managers, but I don't see anybody saying we should revert to passing around tarballs that unpack onto root (other than Patrick Volkerding).
> [...] the easiest way to use the distribution isn't to fret over change but to embrace it. Otherwise you'll be implementing fragile workarounds that break every time you update.
I'm thinking about putting together a talk about exactly this, tentatively titled "MacGyver-Driven Development". It's my response to people who respond to any criticism with "Yeah, but then you can just put some tools on top of it": relying on tools only adds another dependency that makes your system more fragile and resistant to change.
The proper way to develop is to keep what you do as small and environment-agnostic as possible. That way, when tides do change, you don't have to fight them or work hard to embrace them; you can just go with the flow, and just change the few parts that touched the changing dependency.