More like "Oh, you've changed your fundamental structure. Screw you guys, I'm taking my yearly donation fund and going home!" I know the value of an operating system. I normally take half the price of what I would pay for a commercial server UNIX licenses and dump that into a donation fund that gets split among the OS projects I use. If a project uses systemd and doesn't offer an alternative, they don't get my money for further development, and I'll use legacy versions of their software until I can find something to replace it with. Simple.

So... Is there a yum or apt based distro available that hasn't drunk the systemd Kool-Aid yet and has no foreseeable plan to? I've been looking for a distro to sink my yearly OS donation fund into since the Debian dried up and CentOS looks like shakey ground. At least something to tide me over until Devuan actually puts out a stable OS so that I can see how it will work for my needs.

What is so hard to lock down?
HTTPd: Only run it on 80 or 443 on the system.
FTPd: only use port 21.
SSHd: only use port 22.
SMTPd: Only use port 25.
BIND: Only use port 53.
Close off every other port on the server that you don't need. If the ISP blocks the above ports, use port forwarding on the router to get around it and leave your daemons running on the standard port. There's still a good majority of us that use Linux for servers. These are the people who do not need or want systemd. These are also the people that the big distros are not listening to and making systemd a one size fits all. Keeping systemd on a desktop distro is fine by me. Keep it off my servers.

Ok...I think you're confused here. We're talking about where the global configuration files are going. We're not talking about where the packages or the user's own files are going. What you're talking about, Linux itself has no problem doing. If you want the "more careful" approach, all you have to do is build each package from source, ensuring that you point the $PREFIX environment variable to where you want that package to install. If you want to break FHS, there's nothing in Linux that stops you. When I built my LFS system, $PREFIX was heavily used to direct packages to /usr, /usr/tools, /usr/games, /usr/bin, or wherever else I wanted the package to install to using the ./configure script for the source code before running make.

Global configuration files (what the AC above was actually talking about) , however, you don't generally want to have placed anywhere but /etc. This makes system administration considerably easier because the location of the configuration files are now known across systems.

• Where do I go to disable root from logging in to my box through ssh? /etc/ssh/sshd_config
• Where do I go to change a vhost in apache? /etc/apache2/apache2.conf
• Where do I go to fix an acl problem for my dns server? /etc/bind/named.conf.options

See the pattern? If I need to configure something, I don't need to think through "ok, where did this package install its config? /usr/config? /opt/conf? /svr/<appName>/conf?" All I have to do is know the name of the daemon that needs to be configured and then I can do ls /etc...and there will either be an <appName>.conf file or a directory for <appName>. If it's not <appName> then at the very least it would be <daemonName>. Easier on the Admin which is always a good thing, especially in larger administrative environments.

Don't forget Florida. We're double hung from both sides!

If I sign up for this list, does that give me the right to operate Interceptor Drones and Airsoft AA Auto-Turret Miniguns on my property to enforce the No Fly Zone against any potentially bad actors?

As far as hardcoding the install prefix, I can agree with you; there needs to be a way for users to change the install target. I disagree that global configuration files need to have the $Prefix as well, and I'm against that idea. A global configuration really needs to be placed in /etc as a matter of convention. If a daemon/application has multiple configuration files that require a global position where multiple users must be able to access them(ssh, apache, etc.) then a directory should be created for that daemon/app underneath the /etc directory (/etc/apache, /etc/ssh...). It's precisely the known convention because that's what system administrators are used to; having to re-learn the location of where these files are placed from system to system or even version to version is a training nightmare in a professional environment and wastes time most often in situations where time does not need to be wasted. Maybe you were thinking more of /etc$PREFIX or /etc/$PREFIX

The Matrix had no sequels you insensitive clod!

Yes, I understand that there were movies that held the name of "The Matrix" with many of the same actors, but I and many geeks like me have banished them from memory much like there was never a "Highlander II"