PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

It didn't do socket based activation at all. It didn't handle day 2 operations well (if you changed the configuration of some parent service and the children needed to be restarted, this was just as manual as sysvinit but with a clunkier format). overrides were terrible. Failing out on a depchain was problematic.

The debian politics never would have gotten there if Lennart (and others) didn't decide that it was easier/better to start from a clean slate instead of upstart's weird middleground of a "script" verb to kinda sort make transitioning from sysvinit scripts easier, but not a wholesale reconception of what an init system needed to be in 2015 or whatever year that was.

systemd was, in a sense, crowned because Redhat also tried upstart and had to suck lemons for an entire release/support cycle, wrote something better, and Debian followed on. Not because Redhat/others didn't try to make it work, or because of 7 people.

> But I think it's reasonably clear that I wasn't saying they were trying to build a moat around desktop linux, but around those enterprise offerings. One part of that is making their init system the defacto standard.

Frankly, no, it was not, or I wouldn't have written that. Those "enterprise offerings" have zero interaction with Pulse outside of some edge cases in SPICE for VDI.

The only "moat" that "they" were building (and by "they", you mean "individual contributors who happened to have a @redhat.com email address") was in making desktop Linux usable enough for their engineers to work on it day-to-day.

As I said elsewhere, RHEL6 used upstart. "They" made "their" init system the defacto standard by using upstart, finding a metric ton of things wrong with it (and upstart was used in the first place because maintaining complex sysvinit scripts and day 2 operations in horizontally scaling applications was such a nightmare that it was worth throwing away all of the accumulated man hours in those scripts), and writing something better.

Nobody forced the Debian steering committee, Arch, Gentoo, Slack, or anybody else to default to systemd.

> I don't think I can get into it without being rude, but I think that hasn't born out history. If an outsider does submit patches to scratch their own itch they can expect to at best be held to a much higher standard and at worst be treated quite rudely. I recognize that that's going to be subjective but there's definitely some bad blood between gnome and many third parties. Look at lxqt/lxde, appindicators, etc.

GNOME is what it is, and they had that reputation before Pulse.

We shouldn't conflate Pulse and systemd just because they were both Lennart any more than you conflate selinux and podman because they're both Dan Walsh.

This perception also grossly misrepresents or misunderstands open source. If an outsider does submit patches where? Which one of the 600 different projects are they submitting to? How many of them do you presume are controlled by black-robed @redhat maintainers?

OpenSSL, Apache/httpd, coreutils, glibc, and a bunch of other core projects have so few maintainers/contributors that we're lucky they move at all. There is not some "Linux@redhat" repo which it all goes to where patches from outsiders get gated. Open source is a reputation-based community. If a @redhat.com email happens to be a maintainer of a widely-used project, it is, broadly, because they earned it through contributions like anybody else.

Maintainers, once they get there, do tend to get less rigorous code review. That's true. But nobody hands you maintainer rights along with your badge, and the perception that things work this way is untrue both historically and today.

I personally wouldn't touch a non-systemd system if I didn't have to.

The thing they did to piss people off was breaking with UNIX tradition and not prioritizing simplicity. This makes them hated by enthusiasts, tinkerers, people who don't trust tech, etc, and loved or just passively ignored by corporate sysadmins, non-hobbyist everyday desktop users, general devs just trying to make modern software, etc.

It's kind of an unsolvable conflict. People who want simplicity are looking for something very different from people who want everything to just work and never require looking under the hood.

Fedora is approximately as "vanilla" as Arch. If any patch was in a Fedora package which you had to pull out, it's because upstream did not accept the patch for some reason, but the maintainer decided it was critical enough to diverge. This isn't/wasn't SOP.

The Linux kernel patches are, as above, not really where they make money, which is consulting. But there is no such thing as an "upstream stable release" which Red Hat contributes to in any meaningful way.

Kernel features which are going to go into Fedora go into mainline. Not the LTS release. RHEL's support policy has a somewhat strict SLA on kernel ABI/API, and their support cycle is much longer than upstream "LTS" which "everyone else" (whomever that is, because Canonical and SuSE have policies similar to Redhat) uses.

Patches are cherry picked from mainline not to the "upstream stable" release, but to whatever version of the kernel RHEL-whatever shipped with. 2.6.18 for RHEL5, 2.6.32 for RHEL6. Forever. It has been this way essentially forever is not a new change, has nothing to do with excluding the rest of the community and everything to do with the fact that it was the only way that nvidia/emulex/whatever_hardware_vendor would agree to support Linux AT ALL. They were not going to rewrite their driver for RHEL3.5. Just RHEL3, now and forever so the ABI had to stay the same.

The patchset is publicly available as part of the SRPM, and as a raw .patch file. It is not individual patches anymore because Oracle was cherry picking patches from their cherry picks to repackage Redhat's source and poach customers.

It was moved to a single, enormous patch file so Oracle's kernel engineers actually had to work to integrate their ksplice/RAC/whatever patches, but that's politics.