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.
>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...
Libc and linux kernel are good solutions to well defined problems: a standard C library, and a kernel. They pretty much do what is expected, sometimes they do more, but not by much.
Systemd? It is not a good replacement for an init system for the users. Instead, it is an OS functionality accretion for the benefit of distributors, a baroque monstrosity that provides mediocre buggy solutions to too many problems that have nothing to do with init. It boots nondeterministically (socket activation is not such a universally great idea), sometimes hangs randomly, it disrespects the user when ignoring keyboard input while waiting 90s or indefinitely for some condition, or launching zillions of bogus hog processes for every user login event. Some of these can be mitigated on a production server, but bad taste remains.
>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
> That's subjective. I've talked to a lot of Windows users who all say Linux is a terrible solution for them.
That's a different statement. I said those linux parts are good solutions to a libc library and unix kernel. Not good solutions to needs of Windows users.
> Most users don't touch the init system that much.
Most BFU users don't touch the init system. If you're a developer/administrator/power user, you do. Yes there is more BFUs (website users, android users) than power users, but that does not mean that the latter group should be pushed to not care about their init system.
> Those are all optional
Not in practice; some of those options are integrated and others are chosen by the distributions. It's hard to reconfigure the system to opt out of journald or user session control.
> You don't have to use socket activation. It's there if you want it and you don't need to strictly order services.
Yes, but that won't solve the problem entirely, systemd is non-deterministic init system where you can't fix the boot order reliably.
> Not sure what this means or what keyboard input you were pressing. In systemd the keyboard shortcut to force reboot is pressing Ctrl+Alt+Del 7 times
Ctrl+C, Ctrl+Z. I mean I don't always want to reboot because something went wrong in the boot process and systemd is stalling. I want info from my init what went wrong, and the option to fix the problem in the shell if possible. This is often not allowed by systemd when it could.
> Not sure what this means either. You can disable those.
It means systemd launches bogus processes slowing down the system. It's well known, it's in the trackers, yes I can and i do disable them.
The point is this sucks and neither the systemd developers neither the distribution(rhel and derivatives) care to fix this.
> Should glibc also be optional? What about the Linux kernel? What about apt-get?
In my opinion, yes, they should absolutely be optional. Whether or not that is feasible today does not change the advantages of each component of the system being optional and replaceable. It is more failure tolerant both from a purely technical perspective, and also from an organizational perspective.
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.
I'm not saying that every distro should support every piece of software that's out there, that would be wasteful and very difficult.
What I am saying is that, ideally, every component in a distro (or any important software, really) should have at least two options, so that if one option fails for whatever reason, the user has a choice to swap it and keep working. This is already true with many components of a distribution.
This is how I am writing my application. It is not fully there yet, but I plan for every dependency to have an alternative. I also favor dependencies with long streaks of no breaking changes, having been previously affected by breaking changes in dependencies I was using.
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...
True. However, my objective is to internalise the tooling that routinely use, the scope of systemd is beyond what I need. Also, I find constantly looking up unique directives fatiguing and would rather use that energy elsewhere. I find working with the same general tooling results in faster & easier mental recall across a broader range problems that I tackle. Just my experience, no doubt different for others.
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.
Just a reminder holding grudges isn't good for your mental health.