What irks me more about this blog post than the systemd part
- which has been discussed in-depth countless times in the past, with valid arguments for and against - is the decision making and risk assessment process.<p>I've run large-scale infrastructure on both Debian and RHEL, with and without systemd. I've been involved in many distro decisions in the past. The init system was never a major consideration, and I've always been able to work around whatever issues I've had with both sysv and systemd.<p>Here's some considerations which were important for my team the last time we had to make a choice:<p><i>- Vendor stability and long term support</i><p>If you're running a business, you'll want long term stability guarantees - both from a technical, and a business point of view. Running a small community distro with few - if any - commercial users is a huge liability. Yes, you always have the option to fork it or take it over, but unless you're in the business of building a Linux distro, it's almost certain to be a bad business decision since your competitors are spending their time on their products instead.<p>Anyone who doesn't appreciate long term vendor stability hasn't yet been burned by the lack of it. Your Gentoo wizard left the company? Too bad, good luck maintaining your infra now (I've actually seen that exact scenario play out not once, but twice!). A few core maintainers left for another project and you're left building your own packages? D'oh.<p>Having a mature and well-funded organization or a large community of commercial users (in the case of Debian) supporting your distro is extremely valuable, even if you aren't the ones paying for it.<p><i>- Ecosystem</i><p>The ecosystem is also really important. It's often the main motivation for using a particular distro. Development tools, third party package repos, 3rd party enterprise software, troubleshooting resources, documentation and much more depend on a healthy ecosystem.<p>With Devuan, this isn't as much of an issue, but it's still sufficiently different from Debian in sometimes subtle ways that it will nullify some of the advantages of being in a common ecosystem.<p>This also includes hiring - you'll have a harder time staffing your company if you're using exotic stuff and you'll unnecessarily spend your time training them. Ever wondered why companies like Google publish so many papers, talk about their infrastructure and even publish books about it[1]?<p>It's because it means they can - by advancing the state of the industry - hire people who are already familiar with their architecture and concepts. This is a real problem for them - Google, for instance, is in some cases so far ahead of others that they have to spend a significant amount of resources to bring their new hires up to speed. I don't know about Amazon and Facebook, but I'm sure they have similar problems.<p>[1]: <a href="https://landing.google.com/sre/book.html" rel="nofollow">https://landing.google.com/sre/book.html</a><p><i>- Security</i><p>Security follows the supply chain. Your security is only as strong as your distro's - no matter how good your security controls and processes are, if your distribution vendor is compromised, you won't stand a chance unless you have a world-class security team.<p>Likewise, your customers fully rely on you - if you're compromised, they will be, too.<p>Security is much more than signing your packages and publishing security advisories. In fact, those are merely the results of a properly implemented security management framework - risk assessment and mitigation needs to be an integral part of your vendor's (and your) processes. Where do they keep their PGP keys? Who has access to it? Is is stored on a HSM or just sitting on a server somewhere? Is there a process for revoking it? Is there a change review process? Does the build system verify source code integrity? Is there two factor authentication for production? Do the team members keep their SSH keys on a smart card? This list could go on for miles.<p><i>- Quality Assurance</i><p>Even with the main distros, QA quality varies wildly. In my personal experience, Red Hat has by far the best QA, followed by Debian and then (with some distance) Ubuntu. I've had particularly bad experiences with Ubuntu, a sentiment shared by many operations people I've talked to (the worst one being the grub timeout bug that made me spend a few days pressing the return key a lot - basically, they removed the default timeout in a minor update and all my machines sat there waiting for someone to manually continue the boot process).<p>Attention to details, even if it's minor and seemingly insignificant, really helps productivity if you sum it up at the end of the day - each bug your vendor catches and each quirk they document is time you won't have to spend with debugging.<p>With smaller distros, this is even worse - in some cases, they don't even <i>have</i> proper QA.<p>Now, let's assume that the issues they had with systemd were as significant as they say they are (I'm doubting it, but unfortunately, they didn't talk about any particular ones), it still might very well have been a better business decision to stick with Debian and spend their time fixing the issues they had instead of migrating to Devuan, which is a HUGE liability compared to plain Debian.