Red Hat's Open Decision Framework | Hacker News Reader

Red Hat's Open Decision Framework

github.com

91 pointsalxsanchez19 comments

This title has the highest irony-per-word ratio I've ever seen.

What's the deal with this? Has been on the front page all day, but only one comment?

And why is that? Is this supposed to be some dig against Red Hat for not being open in some way?

From what I get, tho I'm only very lightly skimming the news about Linux every once in a while, Red Hat is responsible for stuff like systemd, in which they try to shape the Unix-like ecosystem, breaking standards and conventions, single-handedly with as much democracy as you'd have in Iran. I guess the GP comment references that situation.

Red Hat isn't responsible for systemd, Poettering started it and was later hired by Red Hat, which at some point adopted systemd. Red Hat doesn't have the power to force distributions to use systemd or to make other projects depend on it.

> Poettering started it and was later hired by Red Hat, which at some point adopted systemd.

Almost right. He worked at Red Hat already, but Red Hat wasn't interested in his ideas for a new init system (they were moving to Upstart, which is used in RHEL 6), so he decided to work on it on his own time, and Red Hat eventually decided there were problems that needed to be fixed with init, and adopted it[1]. I can't find a hire date for Poettering, but it's possible what you are thinking of is PulseAudio which was started in 2004, and was also controversial in the beginning (there's a trend here with Poettering...)

> Red Hat doesn't have the power to force distributions to use systemd or to make other projects depend on it.

Exactly. Systemd was adopted by many distros because they thought it was the best choice. There's no way for Red Hat to to force it on other distros, and of things that might be susceptible to market forces in Linux, I wouldn't count the init system as one. Almost all software will only interface with it through a startup mechanism, if even that, and that's generally minuscule compared to the rest of the software development. It's likely smaller than the distro specific packaging config in the vast majority of cases too.

I'm not sure where this myth started, but I don't think I've heard it put forth from anyone that has a clue about how the distributions operate. It's interesting that it's so pervasive.

1: https://www.linuxvoice.com/interview-lennart-poettering/

> I can't find a hire date for Poettering, but it's possible what you are thinking of is PulseAudio which was started in 2004, and was also controversial in the beginning (there's a trend here with Poettering...)

People complain about Poettering because he's Poettering and about his projects because they are his projects. It's very rare that I see anyone providing any valid criticism, that is not some Red Hat conspiracy bullshit, the Unix philosophy "This is the way it's always been and that's by definition perfect" argument or the portability (read: I don't want obscure-OS-that-nobody-cares-about-or-invests-any-resources-in left behind so please don't take advantage of innovation in the kernel) argument.

What should be controversial is how incredibly shitty and unfairly Poettering is treated by the community.

Indeed. The way everyone was ready to assume the worst interpretation of his words in the evivarfs fiasco[1][2] was telling.

1: https://news.ycombinator.com/item?id=10999335

2: https://news.ycombinator.com/item?id=11152880

There's pressure for distros to adopt the Red Hat's init system, regardless of its quality, for compatibility purposes. For example when Gnome 3, which has significant ties to Red Hat, started depending on systemd, other distros had to a) switch to systemd, b) use a shim, or c) follow a forked version of Gnome.

B and c are a lot of slogging work that they'd rather not do, so it's a pretty strong argument to fall in line with what Red Hat wants; especially when it's likely that the projects that did what Gnome did will continue to increase in number, and that systemd is difficult to maintain compatibility with, and becoming more so.

That pressure is not from Red Hat. That pressure is from projects that see a benefit to using systemd, and so then do so. Gnome wanted better power management and session tracking. So did KDE. Systemd offered that, so instead of having to maintain their own code paths to do that, which may or may not work as well, they can offload that task to systemd. Really, what the GUIs care about appears to be mostly handled in logind, and there are various projects in the works (available?) to provide that bit of functionality.

Err, things like upower existed as independent projects before systemd. But now upower is just a wrapper around systemd-logind (of all things).

Okay, I just looked into this. upower used pm-utils upstream. According to upower devs, pm-utils was a dead project, so they switched to what was working, systemd[1]. I'm not sure specifically why pm-utils was discontinued, but given that the page says it's stuff for HAL, and other things I found in my search note that HAL was being discontinued, I think that's likely a reason. Note: pm-utils looks to have not been actively developed since at least late 2012. That's as far as I went back in the mailing list archives to find something indicative of that[2]. The last release was in July 2010. I can see why projects that relied on it wanted to migrate to something better, or at least maintained. Also note that pm-utils was a collections of shell scripts that ran different commands, such as mount, etc, and echo'd values into the proc filesystem. That may have also influenced decisions one way or another.

1: https://lists.freedesktop.org/archives/devkit-devel/2015-Dec... (upower was previously called DeviceKit, according to their site, which is why it's the devkit-devel mailing list).

2: https://lists.freedesktop.org/archives/pm-utils/2012-March/0...

No longer developed because of lack of manpower, because manpower moved to systemd (i keep seeing the same names show up over and over), or because pm-utils were basically done bar some odd hardware quirk or other (in the end hardware is analog, so quirks will happen no matter what)?

I can't shake the impression that user space devs are deathly afraid of their project going "maintenance", and thus either abandon it or depreciate it for a new take on the same problem space (that in turn gets to the same point etc etc etc).

> No longer developed because ... pm-utils were basically done bar some odd hardware quirk or other ... ?

I doubt it's this one. There's one or two messages to the mailing list each month or two month about a bug in some chipset or another.

> I can't shake the impression that user space devs are deathly afraid of their project going "maintenance", and thus either abandon it or depreciate it for a new take on the same problem space (that in turn gets to the same point etc etc etc).

Or perhaps it was an underserved portion of the ecosystem, and the people maintaining it left, or decided they wanted in on what systemd was doing, and as project eventually (5+ years later!) swicth away from it to the next (only?) thing which should get new features, being actively developed, that just happens to include systemd. You can either see that as "systemd is eating everything" or "systemd filled a need, and projects had been waiting for that". Whichever one is more true probably requires a deeper look into the details, but that people assumed it was the former (IMO because of mob mentality, not because of any careful thought on the details), that's the story that survives unless someone spends some effort to refute it.

I just wish there was some official announcement on the pm-utils list, and not just this "its dead Jim" on the upower list when people inquire about continued support.

As for people still reporting bug, that does not contradict my mention of "maintenance". Pm-utils may well have been feature complete, and whacking bugs introduced by new hardware would then file under maintenance.

All in all it feels like non of the decisions are being made on the lists, and rather being decisions either via direct emails or via corporate channels.

Red Hat is also responsible for having lots of people on their payroll developing software that Red Hat bashers happen to rely on, but keep forgetting about when releasing their Red Hat hate.

As for systemd, I guess it breaks GNU/Linux standards and conventions, given that commercial UNIX systems have for a long time adopted similar ideas.

Commercial UNIX that then got trounced by Linux, or as RH-ites themselves put it: "we won!!!".

Haters gonna hate.

Is this Red Hat's attempt to hide their systemic Not-Invented-Here syndrome that results in monstrosities like Systemd?

Reply on news.ycombinator.com