Yes you absolutely can do it for some modules. For example, systemd-timesyncd can be removed and ntpd or chrony installed instead if you need more functionality than just simple client time syncing, such as when you need your own time source as well as syncing.

Likewise systemd-resolved is often left out and a caching local DNS server can be used instead, or left out entirely.

And I very well could remove systemd-networkd and systemd-container since I don't use containers, flatpak, or kvm.

Can I remove others? Possibly, but there's not a lot of reason to do so. These modules serve valid purposes and address actual technical shortcomings we had before, such as process cleanup which was often a problem before systemd-pam.

Shrug. It's not a boogeyman. No one's out to get you. It's not a government plot. There are many valid reasons why systemd has become a core Linux component. There are plenty of distros (and operating systems) that eschew systemd if you don't want or need features like containers and KDE or Gnome, etc.

that can run your old classic desktop environments like you always used to.

Yes I have done a timer file before, but it's been a long time.

Fortunately Cron still works fine, and will continue to do so. But I'd be hard pressed to remember all the cron parameters without a comment at the top of the crontab to remind me.

Shrug. It's sixes.

That's why systemd has been systematically making interoperability with grub and encryption more difficult, in no small part.

Oh cool so they fixed all the problems!

Simplification?

There was no simplification. It was all markedly more complicated and interdependent. That was literally the primary selling point of systemd, aside from "faster boot times".

What are the discreet benefits to the "1000s of containers at scale" scenario you mention which are satisfied with systemd which could not be or were not satisfied with init?

There was not a lack of uniformity before. In fact, it was more consistent and uniform before systemd at a system level.

The only benefit systemd provides is integration with eg. pulse audio - another one of this shmuck's horrible projects - and desktop integration. While that is potentially useful in and of itself, it didn't need to be done in such a massive, integrated, monolithic Microsoft-like fashion.

It'd be nice if people would use all this excess coding capacity as provided by AI to clean up the human written bloat slop they've been churning out for the past 20 years...

Because Youtube is about half AI slop these days. At least given the kinds of video topics I might be interested in. It's kind of discouraging. Some of them actually are now marked as AI generated. I generally stop watching channels that I find or suspect are AI, even if the material appears to be accurate. I just can't support creators who don't actually create.

Further to that systemd is highly modular. Most of it does not run in PID 1. On my fedora system there are half a dozen individual systemd module packages that can be used or not as the system needs and is designed. systemd is not at all monolithic.

All this systemd hate is pretty infantile and entitled, frankly. You're free to build Linux to not use systemd if you want. There are distros that eschew systemd and you can use them and contribute to them. And if a project embraces systemd you are free to fork that and roll back the changes if it's that important to you.

Meanwhile systemd's plain config files are way nicer to work with than any sysv init script I've had the mispleasure of dealing with. I am ambivalent regarding the journal. I still use rsyslog a lot and for the most part it acts as it did before. When debugging individual services the journal definitely is a big help especially because it logs stderr and stdout, although I don't like having to type journalctl all the time. It doesn't exactly roll off the fingertips.

Go right ahead. This is Linux after all. You are free to build it however you want.

So, "People With Disabilities Don't Exist" then?

My father was recently paralyzed by Guillain-Barré, so I'll let him know, thanks.

I guarantee there isn't a single city official in Kansas City that rides the city bus. If they did, they would have never voted in favor for this.

Also makes you wonder how many officials are getting kickbacks from SafeSpace Global for this.

Oh god. If I spent enough time digging through my ancient Slashdot posts, somewhere back there there are posts of me going, "While I loved the strategy behind Falcon 9, I'm really not keen on this plan to make Starship out of huge carbon fibre tanks, that sounds like a really failure-prone solution..." I'm glad they only spent like a year on that idea before deciding it was dumb; somewhere back there there's also a bunch of posts of me cheering their switch to steel ;) . SpaceX still keep having random COPV problems (most of which they don't even make themselves). Not too encouraging for the notion of the cold gas thruster add-on to the Roadster, where the plan is to replace the back seat with COPVs, so you have a COPV right behind your head.

Electron has been getting by on CF, and honestly I'm impressed, but they've also been only working with very small launch vehicles thusfar. We'll see how neutron goes...

Don't get me wrong, there's a lot to say about printing small rocket parts, such as for the engines. But they were printing basically sheet metal cylinders, which is such an immensely slow and inefficient way to go about it, and it left them with parts that were heavier and less aerodynamic (rougher surface). Crazy that idea ever got any funding.

The one seen over Moscow might have been, with a bit more thrust...