Additionally Alan Cox weights in on how *not* to do changes, using GNOME 3 as an example.This is an excerpt from ELCE 2011 kernel development panel with Linu...
After being a pile of crap forced on us by a corporate giant for many many years. Make no mistake, they are doing embrace extend extinguish just like Microsoft.
I use Pipewire now but Pulseaudio is (and has been for years) better than both the Windows and Mac audio stack. It may have been bad once (yes, I remember the days of having to start Wine with some pulse env var so the audio doesn't crackle) but nowadays it doesn't deserve the level of hate it still gets.
It would have been fine if it wasn't forced. "We are the audio stack everyone should use" but when it doesn't work then it's an ALSA bug and alsa ppl should take the blame (even when it works fine with full alsa, like my audio card). And it was designed more like a networking stack then an audio stack.
Sure it was necessary at the time (so that hdmi, and later bluetooth, would work transparently), but the "i know best" attitude hurt its execution.
SystemD on the other hand brought nothing of value. Did way more harm then good.
Quit your bullshit, nothing was ever forced on you. This is Linux, free software and all that, if you're not happy then use a systemd-less distro and stop complaining about meaningless points. SystemD works very well for me (and the vast majority of the Linux community) and is very easy to use and understand
This. If you want to go back to the days without systemd and writing invit scripts manually, knock yourselves out. The rest of us will continue to live in the modern world of systemd, pulse audio (and now pipe wire).
Udev was changed to depend on systemd. No good reason for it. So it practically was forced. You can lie all you want, it won't change reality. SystemD was hyped up by comparing it with the worst implementation of sysV, at a time when no major distro other then fedora even used sysV. And that is not even the tip of the pile of dishonesty.
Just by saying that it is no better then alternatives of the time will get ignorant people like you to yell. That is how strong the hype was around it. How can you even talk about free software when RH can take a core component and make it hard dependant on whatever they want. Just like bluetooth has a hard dependency on PA.
I'm also free to say something sucks, just like you are free to lick their balls.
As someone currently actively supporting two commercial products, one using OpenRC and one using systemd to meet different requirements for different projects
Functionally absolutely the same
Makes it blatantly obvious you have no idea what you’re saying
As someone who wrote an init system for fun and knows how udev and practically everything else associated with bringing a modern computer to a fully functional state (including network mounts, if that is your nitpick) works, i can not know what you are nitpicking about without you saying it. Not that someone who is actively supporting two commercial products to meet different requirements would have any idea what i am saying.
PS It's all simple really, just that it seems magic to people without curiosity.
Sure - it’s primarily the way systemd uses cgroups
For example, systemd’s use of cgroups for process monitoring makes it trivial to support setting resource limits for us
One of the major issues we’re having with systemd, and the reason we’re using OpenRC on a different project, is the way Before and After with targets still cause all the services to start at the same time, causing resource contention
An alternative we’ve used once is to create a special target for the services that had to start early, even if the entire boot took longer, and use a process to then request new targets be started by systemd
This project we found it simpler to use OpenRC, though
Calling them “functionally the same” without taking into account how process monitoring works on different init systems is disingenuous
Process monitoring, in the basic sense, is seeing if a process is running. You mean how they handle dependency trees/graphs ? From what i just read sysD targets are groups that can have other groups in them (aka inherit, aka "services", aka compose). I wonder if that is the core of the problem. Not that i care, that's the hole they dug for themselves when they insisted only pid EINS can orchestrate cgroups (didn't use to be).
Either way, in the overwhelming majority of use cases they are practically the same.
Bdw, i didn't downvote you. I reserve it only for the most irrational fans, aka parroting fanboys.
Linux community is so inherently meritocratic that one can't meaninfully force anything upon any large group of them.
Thore particular two creations of Lennart took the world by storm precisely because they were so absurdly good that working on other stuff was a dead-end, obvious for all but such tiny fraction of people that even forming vacuous hate bubbles haven't rallied enough effort to foster and maintain alternatives.
It became trendy to hate Pulseaudio and call it bloat years after Nokia shipped a rather anemic phone where it already worked flawlessly. I need no further proof that there's no technical basis beneath the hate.
Linux community is so inherently meritocratic that one can't meaningfully force anything upon any large group of them.
Even for developers, there is a very substantial cost to any deviation from the herd and little time or money for these projects. Factually a handful of companies run the Linux userspace and a handful of people run those companies.
You can go your own way but existing market share and resources matter more than quality or merit.
As a Red Hat employee who had his all-around sensible Fedora Change to prevent it from falling too far behind RHEL (!) rejected, I think I can confidently claim that your statements smell of conspiracy theories.
Do Linux-involved companies have resources to develop the projects they like the most? Yes. Do companies dominate userspace development? I don't think so, in fact, they're all seem quite focused in their interests, and their involvement with a median package on your community distro desktop system isn't even minimal, it's none. Do the se companies at least all push for a united agenda? Absolutely not. Can they force a single random community distro like Debian to pick something over something else? No. 99% of the distros? Goes without saying.
It's not a conspiracy theory to imagine that IBM's vision for Linux compared to 2000s or 2010s era Linux is opaque, complicated, and enterprisey. It's who they are.
The grandparent comment
Linux community is so inherently meritocratic that one can’t meaningfully force anything upon any large group of them.
Is pure fantasy. Software projects are dictatorships of those willing to put in the work, not meritocracies. There is nothing immoral or wrong about this but we should be realists. The entire software ecosystem is dominated by oft shitty good enough solutions which people poured enough work into to solve problems well enough.
Anybody can have a vision, but it's the work that matters. I'll be worried when they become a player.
Software projects are dictatorships of those willing to put in the work, not meritocracies.
Most linux distros are slight variations on the best components available. Yes, one can put in resources, do a great job and now everyone switches to the fruits of their labor. No, it does nothing to stop another player from one-upping them and taking the lead with their next best good enough. In political terms, dictatorships are incompatible with voting with one's feet.