[microcolonel]

For what it's worth, I don't think Lennart is against non-Linux systems; he just doesn't care. And as an avid OpenBSD user, as well as an avid Linux user, I can't blame him.

Linux has great APIs like cgroups, inotify (in my opinion considerably more useful than the equivalent use of kqueue), and others. OpenBSD is the other unixy system which I think offers something valuable and unique, and it has its own APIs to offer that.

I'm interested to hear how you got the impression that systemd is/was buggy. I have run systemd on a variety of systems, including pre-systemd-support Debian a few years ago; I was always shocked by how reliably it would bring up the system, consistently name the devices, and provide a convenient interface to the logs.

I have been running systemd consistently on my workstations since Archlinux shipped it in 2012, and I have never run into a bug or poorly-documented feature as long as I have been using it.

[marios]

I think inotify is broken. If 'broken' is too strong a word, then it's at the very least misnamed.

It stands for inode notify, except there are edge cases where it doesn't actually report inode events. Consider this scenario:

  cd /tmp
  mkdir test
  touch test/somefile
  ln test/somefile linktothefile
  inotifywait -m test

Basically, you're monitoring a directory that contains a single file. There's also a hard link to the file, but it's outside of the watched directory. Since it's a hard link, they have the same inode number (you can verify this with ls -i).

If you append data to the file using the "test/somefile" reference, inotify reports the events as expected. If you do the same through the hard link, you get nothing. IMO this is wrong since you accessed the inode. inotify is more of a "report events on a file/directory" rather than a "report events on inode" mechanism.

[merb]

OT: well that problem is outlined in some articles about inotify. Probably most people don't care. Since they only want to watch a directory and their subdirectories and not edits from hard links.

[digi_owl]

He has in the past advocating ignoring everything unix about Linux when developing for it.

[MertsA]

No, he advocated for making design decisions based on what's best for Linux, not a compromise for other operating systems.

[grandinj]

that's not a very charitable view. He simply does not get bogged down in debates about what constitutes the true "unix approach", and prefers to focus on building the best system that can be built using the facilities Linux has to offer.