4 ms·
Redhat-steered projects act an awful lot like they're trying to make it really hard to compete with Redhat without picking the same projects they do—so, being a
by yamtaddle 4y ago
Redhat-steered projects act an awful lot like they're trying to make it really hard to compete with Redhat without picking the same projects they do—so, being at their mercy, unless you have a lot of resources to maintain forks against a maybe-hostile upstream. Been like that at least since the whole Systemd thing. Maybe that's not what they're doing, but it sure looks like it.
As a user I find this frustrating because I actually wouldn't mind some consolidation in Linux, especially in the GUI layers, but tend to hate RedHat's taste in these matters.
- traverseda 4y agoIt is essentially the same "embrace, extend, extinguish" policy that microsoft used to use. The fact that the underlying code is open source apparently doesn't matter too much. If someone else did come up with a compelling alternative init system just make systemd a soft dependency of your desktop environment, and make sure that patching that out requires a lot of active maintenance and ongoing work.
- deleted 4y ago[deleted]
- 411111111111111 4y agoI never noticed they pulled the plug on systemd for the extinguish, when did they do that? And how exactly was any of it an embrace? Redhat was a Linux distribution provider from the start, they didn't take something over in order to destroy it. They just created systemd and provided help to distributions if they were willing to use it. The distributions were fully aware what they were doing when they abandoned Sysvinit, it wasn't a backhanded tactic by redhat. A recent example of something close to EEE is vscode, which is now getting "refactored" to utilize non-open source plug-ins for everything, effectively extinguishing it from a free perspective.
- traverseda 4y agoThat's not how EEE worked. From wikipedia 1. Embrace: Development of software substantially compatible with a competing product, or implementing a public standard. 2. Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the "simple" standard. 3. Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions. Systemd is part of "Extend", and what they're extending is the linux ecosystem. Sure, those extensions might make things better in the short term and for some uses cases, but they're now owned by IBM so good luck!
- 411111111111111 4y agoDid you even read what you've quoted there? Redhat didn't embrace a competing product, redhat has been a Linux distribution from the start. They extended it by adding systemd, yes. I said as much before too. They didn't extinguish Linux as their extension continues to be open source and ready to fork. If you're going to argue from the perspective of sysvinit instead then neither embrace nor extend happened. Whatever redhats goal were, it wasn't EEE
- traverseda 4y ago> Did you even read what you've quoted there? Yes, and I think it's pretty obvious to anyone who is familiar with the history. EEE is about a set of anti-competitive practices, ones that are definitely and obviously being used here. Whether they do that with malice aforethought is unknown, and nothing there is illegal by itself, but it is a pretty clear thing they're doing. Microsoft didn't embrace office document editing software, microsoft word was one of the first document editing suites. And yet that is one of the examples in the wikipedia article: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish#Examples_by_Microsoft https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... Did microsoft extinguish document editing software? No, they just used their market position to make sure that their implementation was the most dominant. Another key example is "Breaking Java's portability". Do you want to talk about how the move to systemd has effected the various BSDs? Here's a talk about it: https://papers.freebsd.org/2018/bsdcan/rice-the_tragedy_of_systemd/ https://papers.freebsd.org/2018/bsdcan/rice-the_tragedy_of_s...
- sph 4y agoWhat's Red Hat got to do with this? Sure, they're a big GNOME contributor, but so is Canonical or Purism or Endless or, until recently, System76.
- traverseda 4y agoAnd that's always the rub, isn't it? It's next to impossible to prove that most of the people in key decision making positions work for Redhat or are Redhat alumni.
- UI_at_80x24 4y agoRedhat is the main force that created systemd. And so their heavy-handedness into Wayland isn't surprising.
- sph 4y agoThat's a complete non sequitur. They mishandled A so necessarily they must have mishandled B as well. What kinda argument is that? And systemd is controversial in that a vocal minority says it was a disaster. I don't think it is, definitely not compared to Wayland.
- throwaway09223 4y agoHave you ever worked with RedHat? This is just how they are, across the board. (And maybe now we should be saying the way IBM is, who's history is even worse...) > And systemd is controversial in that a vocal minority says it was a disaster. Not a minority, and some of the loudest voices are the experts whos opinions matter most. I am one such expert. Most technical people I speak with about systemd are largely ignorant as to the design considerations.
- kaba0 4y agoYeah, no. Most actual experts very much prefer systemd due to it actually solving the problems inherent in booting up a system with all the services, and resolving the dependencies between them, instead of just being hacky bash scripts that only work on a single machine (if at all). The only people who have problem with systemd is “old-timers” that just refuse to learn anything new, and just blindly believe that the old status quo was better.
- Vinnl 4y agoI mean, as an engineer, I don't need to assume malicious intent (not saying you do) to understand how this happens. It's much easier to support a single code path rather than options for everything. It's the same reason I tend to shy away from premature abstractions: every option is a drag on future code built on top of it.
- dTal 4y agoNote that Red Hat's business model is charging money to be Linux experts. It's against their interests for non-Red-Hat Linux to be viable, or for Red Hat to be comprehensible without their services.