Hacker News new | past | comments | ask | show | jobs | submit login

> Yep, this is true. The only thing I concluded from this page is "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork".

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.

I was hugely resistant to systemd when Arch first switched, but I learned to appreciate it (the simplicity of unit files won me over). This came about a year and a half into my journey with Arch Linux when I was still learning that 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.

Though, journalctl still annoys me.

Sure, I can understand some of the hate directed to systemd simply on the merit that it does* do things differently--but it's hard to believe that the vitriol and insults from the anti-systemd camp are likely to help anyone's cause.

Personally, I like it, it works, I've not encountered the stability issues or other bits of weirdness some folks seem to insist regularly occurs (maybe it's distro-specific), but I'm also OK with being a statistical outlier. Or perhaps the anti-systemd crowd is disproportionately noisy.




> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: