Yeah I'm considering switching to FreeBSD or even OpenBSD (if it would be possible to play some of my games on it). I don't want to switch really, but if systemd is going to be the default init system from here on and it continues to be plagued by bullshit like this then I don't really want to be bothered by it. (FYI I currently use Arch Linux, one of the early adopters of systemd).

Speaking of FreeBSD, weren't they supposed to be adopting launchd? What's the progress on that?

Someone with better freebsd knowledge should chime in, but until then... It is my understanding that the launchd port was one guys google summer project, he worked on it for the summer, put it aside for a couple years and picked it up recently.

The fbsd wiki on launchd: https://wiki.freebsd.org/launchd

Googling tells me that they have been working on porting it and apparently it is more or less done but not yet the default.

And I really, really wish Ubuntu had held out with upstart instead. We need the alternative.

You don't cavilierly fuck with PID 1, and that's precisely what the systemd folk appear to be doing.

I'm really hoping Linus's rant makes an impact on them.

They're fucking around well beyond PID 1. Default binary log formats. This odd binary messaging bus with god awful reverse domain names, a shifting binary protocol format that injects itself into the kernels standard text-based messaging formats.

I find the whole dependency system completely bizarre, because to truly implement it, you have to hook into _everything_ and make it part of this odd binary mess they've created above.

I really don't understand the route they are taking, I see the system becoming less capable and more fragile with this type of engineering being encouraged.

They also took over core dumps.

   ulimit -c unlimited 

It just fails siliently now. The priesthood have determined that it is better to run:

   systemd-coredumpctl

This annoyed me because if I wanted to do internet searches to achieve simple things I would be using another OS.

Oh, I know. Which again is why I'm as concerned as I am.

> it'd be a shame for people to go back to other operating systems purely because "it broke one day, something about systemd".

FWIW, exactly this happened to me on an upgrade one day on another Linux distribution, after a few other headaches. The switch to systemd broke smbd/nmbd, at the time there were not yet tools for spitting the new binary log format into text, and trying to data mine that logging system to figure out what the hell broke was a real adventure.

I was so skeeved I immediately dumped that and fled to Debian, because it had a reputation for stability.

Imagine how excited I was when Debian voted to adopt systemd.

I, also, have started looking at the BSDs again recently. herbstluftwm looks pretty nifty.

I still use multiple OS across my laptops.

GNU/Linux support has improved a lot since my first installation in 1995, but it is still hit-and-miss on laptops.

That's exactly my experience as well.

As you said, you haven't used the Linux desktop in many years. It's come a long way in that time.

For example, editing your xorg.conf is virtually a thing of the past these days. I haven't touched it in years and run a fancy triple monitor setup.

right up until a ubuntu kernel update breaks the binary gpu driver, and you spend the next two days trying to figure out which binary or open source driver allows you to run everything the way you were at the beginning of the week. Repeat this every 6 months.

Why not give it another try now then? I have used it for years and, unlike windows, I never had to reinstall it just because something broke. And things only broke when I messed around with them, but it was always fixable. If you also use virtual machines or linux containers you will never break anything.

I intend to dual boot next time I upgrade laptops, so we'll see. I absolutely loved the customizability of the desktop environments.

But I hated worrying about graphics drivers, updates, xorg.conf, automake, and finagling my system configuration to get source tarballs to compile.