"Having had several issues with systemd, and really not liking the philosophy behind it, I am looking into alternatives. I really prefer something that follows the Unix philosophy of using small, focused, and independent tools, with a clear interface. Unfortunately, my favourite distro, Arch Linux, is very much pro-systemd, and a discussion of alternatives is liable to get you banned for a month from their forums. There is an effort to support openrc, but it is still in its infancy and without much support.
So, what are the alternatives, besides Gentoo? Preferably binary... I'd rather have something like arch, with quick updates, cutting edge, but I've already used a lot in the past Mandrake, RedHat, SourceMage, Debian, Kubuntu, and so on, so the package format or the package management differences don't scare me."
[ED Note: I'm imagining FreeBSD sitting in the room with the all the Linux distros he mentioned being utterly ignored like Canada in Hetalia.]
I'm sure the on Linux way is more comfortable to one familiar with that particular system just as the FreeBSD system is second-nature to me but essentially they're all doing the same thing.
I respectfully disagree. They are not doing the same thing at all. The key being: fixes are back-ported to a static version of a library. So imagine on your 2.1-RELEASE, there was a ports tree freeze. That is the 2.1-RELEASE port tree, forever. Now, during the supported lifetime, security issues, or major bugs occur in those ports. Critical fixes from the latest upstream source are backported down to the 2.1-RELEASE tree, for the supported lifetime of 2.1-RELASE. No major version bumps. One day, when your production schedule permits, you upgrade to 2.2-RELEASE, and now you've got all the api+config file changing updates in one fell swoop.
Right now, it's: upgrade to the latest upstream version, recursively.
It is true that interdependencies are an issue, but they are an issue with Linux as well. You either use an old version of a library for all your installed programs or you update the library and everything that depends on it when there is a change that breaks something. I've honestly had more issues with updating things on Linux when I've used it for things than I've had on FreeBSD, but of course YMMV.
I don't know if you've used Debian + apt, or CentOS and yum to use some canonical examples. The repos have stable versions of the software, and have major fixes backported, for a release (as mentioned above). That is, you run an old version, with non api/config fixes backported. Periodically, these repos are updated to more cutting edge software, so you aren't running things 2+ years old, but by and large, the software you run will be the same version until you update. So when you say more issues, how are you installing software and dependencies, on which distro?
Here are some examples of things that have been a pain over the years:
autoconfgettextgmakelibiconv*perl* omfgruby (if you use portupdate)php
Ports maintainers strive to maintain a given port's buildability on not only the current developers' branch (right now that would be 11-CURRENT) as well as the latest (10-STABLE) and previous (9-STABLE) 'stable' branches intended for the end-user.
I think by the way this is phrased, people might get the impression that they are testing things on old releases. They are testing build success, periodically, for supported releases.
Anyways, I think that this discussion illustrates pretty quickly my point. There is total failure to acknowledge that this is a problem. I believe it is, for my uses. I'm not saying They Should Fix That, because it's a volunteer project. I'm not going to do it. I'm saying this isn't even in the discussion when talking about 'fixing the ports system'.