Embrace and extend is a fundamental part of the OSS model. That's what you're supposed to do: pick some OSS, make some custom add-ons to it, then upsell it to your customers. The license encourages everyone to do this. Tons and tons of OSS companies are doing this. Microsoft isn't doing anything out of the ordinary here.
Just a reminder holding grudges isn't good for your mental health.
Of course they were influenced by the author of programs they use. They were also influenced by Linus Torvalds when they decided to use his kernel. I don't see any problems with this. That's what you do when you make something that you're proud of. You go around to other people and try to convince them to use it.
If you're only talking in hypotheticals then they're already optional and replaceable. Someone just needs to do the work to replace them.
You're missing that these parts have to get replaced for a practical reason. Not just because someone vaguely feels it would be more fault tolerant. For example, think of some other libc that's optimized for a certain hardware. Distros that don't support that hardware would have no reason to ever use that libc. If you say all distros should support it, then your opinion is really "all distros should support this random hardware that might be rare, expensive, highly specialized, hard to develop for, etc" and now that's a much more complex and demanding task you're asking someone to do, for very little benefit.
>Libc and linux kernel are good solutions to well defined problems: a standard C library, and a kernel
That's subjective. I've talked to a lot of Windows users who all say Linux is a terrible solution for them. I don't think most Debian developers feel they should suddenly drop everything and start making Linux exactly like a copy of Windows just to please those people. They voted on this several times, they wanted systemd.
>it is an OS functionality accretion for the benefit of distributors
There's no problem with this. Most users don't touch the init system that much. They interact with it primarily through the package manager installing service files.
>solutions to too many problems that have nothing to do with init
Those are all optional add-ons for users who are having thoes problems.
>It boots nondeterministically (socket activation is not such a universally great idea)
This is also only an option. You don't have to use socket activation. It's there if you want it and you don't need to strictly order services.
>sometimes hangs randomly, it disrespects the user when ignoring keyboard input while waiting 90s or indefinitely for some condition
>systemd should be an optional package on all distros.
Why? Should glibc also be optional? What about the Linux kernel? What about apt-get? You can technically replace those things but it's a ton of extra work, almost like shipping a completely different distro. At the end of the day, a distro decides what packages it wants to support and what it doesn't. The specific choice of supported packages is often what defines a distro and sets it apart from the rest. If they have limited manpower and choose to save themselves time by picking only one init, or libc, or desktop environment, or anything, that's their decision.
>but would any here really insist on forcing everyone else to use your methods and no others?
No. There are hundreds of Linux distributions to choose from, and anyone can make more distributions any time they want. No one is forced to do anything. Also, using Linux is optional to begin with.
>systemd, among other valid criticisms, is unmistakably fascist. For anyone but parent, don't just be thin-skinned and downvote my comment because you have allowed yourself to be insulted. Be courageous and disagree with me if you can. How is systemd not fascist?
You should stop and think a bit more before making these comments that you appear to be acknowledging as histrionic and insulting. By this definition BSD is also "fascist" due to only shipping BSD init, and the Linux kernel is "fascist" due to only shipping one set of drivers, and Devuan is also "fascist" for not supporting systemd...
That would be the distro's problem, not systemd. Any of those utilities are going to be optional, the distro has to consciously enable them and ship them in a package for it to make it to you at all. A lot of commenters seem to misunderstand that systemd is not forcing distros to do anything. All they really do is provide a set of tools for distro maintainers to choose from.
>But you can't choose your window decorations, themes, desktop panels independently anymore and get a somewhat matching look and feel. It's only Gnome island, KDE/Plasma island, and hacker-minimalist island.
Maybe take that as an indication those "spirits" are at odds and can't be reconciled? You can't have a system that's fully stable and predictable but also lets you swap out any component at a moment's notice to some unsupported third party thing. You either pick one or the other. In my opinion Linux has only ever been really worth it for companies willing to employ developers to work on it; you don't get any of that customization for free. At one point Linux companies were experimenting with things like desktop panels but then the market changed, they stopped and the money dried up. That's what happens.
You mean the distros broke it by not toggling that option. As you can read from the parent comment here, that "convention" was also broken and causes issues in Debian. There's no solution here that isn't going to break something, that's why the best systemd can do is ship a toggle and tell the distros to figure it out.
In lot of cases I've found systemd units much to actually be simpler and easier to maintain due to everything being in a simple declarative format. The old alternative is to have a lot of shell scripts that can get very complex, and to consult another few hundred man pages for various shell utilities...
That's a pretty negative way to make an innocuous statement: that it's expensive to make an OS. You can't expect Red Hat (or any other Linux company) to maintain backwards compatibility forever for every single possible project they've ever had an employee contribute to. They'll maintain some as long as their customers pay to support it for that long, but even that ends after a while. Yes, if you don't want to pay them for it, then you get to spend the immense amount of time and money needed to fork it; because shipping a full commercial operating system with millions of lines of code is a complex task with a lot of interlocking parts and no one wants to do it for free. It makes no sense to single out complaints towards random projects for this.
>It was killed because of the Red Had power behind Systemd.
That is an absurd, untrue conspiracy theory. Whoever told you that should be ashamed. The author of Upstart said that it died because of a restrictive CLA. Read the thread linked here for an explanation: https://news.ycombinator.com/item?id=27176807
To quote the relevant parts:
>I entirely agree with Kay and +Greg Kroah-Hartman that it was the CLA that caused systemd to be written instead of Upstart.
>But I don't need that self-affirmation anyway :) I wrote Upstart, I got paid for it, I moved on to do other things, something else came along and replaced it. If Upstart hadn't been under the CLA, and systemd hadn't've happened, all my code would have long since been rewritten by now anyway.
That isn't "political power" it's called knowing your audience and knowing what they want. The audience here is Linux distribution upstreams who also participate in Freedesktop. The other alternatives had ample time to talk to these people and copy the features of systemd and improve on them but they refuse to do it. They seem more interested in building for their own niche use cases and ignoring everyone else. That's a fine decision, but it's their decision. They can't say it's anyone else's fault.
Edit: If those other developers were really serious about trying to replace systemd they would be going around to every distro maintainer they can possibly find and asking them what systemd is doing badly and what they'd like to see in a better project. Then they'd have to think really hard about whether it's easier to fix those issues just by contributing to systemd, or whether a full replacement is warranted. Every now and then I see comments about writing replacements in Golang or Rust or some other memory safe language but there's no other interesting ideas there to warrant a rewrite. Maybe you do all this and conclude there are no major complaints from the big systemd users, and that's just how it is.
Just a reminder holding grudges isn't good for your mental health.