Systemd Creator Lands At Microsoft (phoronix.com) 209
Yesterday, Phoronix reported that the lead developer of systemd, Lennart Poettering, left Red Hat. "It turns out he had joined Microsoft and [is] continuing his work on systemd," writes Phoronix's Michael Larabel in a new report. He continues: While some may not always align with his views or approaches to handling some things, there is no overstating his enormous contributions to the Linux/open-source world and his dedication to advancing the ecosystem over the years. This may take many by surprise but let's not forget Microsoft has over time employed a number of Linux developers and other prominent open-source developers... Microsoft currently employs Python creator Guido van Rossum, GNOME creator Miguel de Icaza had been employed by Microsoft from 2016 when they acquired Xamarin to earlier this year when he left, Nat Friedman as part of Xamarin-Microsoft served as GitHub CEO following Microsoft's acquisition, Gentoo Linux founder Daniel Robbins was previously employed by Microsoft, Steve French as the Linux CIFS/SMB2/SMB3 maintainer and Samba team member works for Microsoft, and Microsoft employs/previously-employed a large number of upstream Linux developers like Matteo Croce, Matthew Wilcox, Shyam Prasad N, Michael Kelley, and many others beyond just the usual immediately recognizable names to Linux enthusiasts/developers. It was also just earlier this year that Christian Brauner as another longtime Linux kernel developer joined Microsoft. Christian Brauner is Berlin-based like Lennart and moved on to Microsoft after the past half-decade at Canonical working on the Linux kernel, LXC, systemd, and more.
Wow what a shock! (Score:4, Funny)
Spank my ass and call me Shirley!
It's official. Systemd is Microsoft Linux. (Score:3, Insightful)
This may take many by surprise
Doesn't surprise me one bit. Systemd is way more like Windows than it was ever Unix.
Microsoft LOVES brain-draining the competition. It's how they killed Borland back in the day.
Re:It's official. Systemd is Microsoft Linux. (Score:5, Funny)
Microsoft LOVES brain-draining the competition
That's not what is happening here.
Re: (Score:2)
Re: (Score:3)
If Linux is the competition, then yes it is.
I think you missed the joke about what constitutes a "brain". Because we all know Slashdotters think Poettering is a genius and unsung hero of the Linux community.
Comment removed (Score:5, Insightful)
Belonging (Score:5, Insightful)
That's exactly where he belongs to.
Re: Belonging (Score:5, Funny)
Re: (Score:2)
Yep. My opinion of the man (not the projects mind you) has never been high, and it's not getting any higher.
What a fucking sellout. But no real surprise.
Not surprising (Score:5, Insightful)
Re:Not surprising (Score:4, Interesting)
What I find interesting in all of this is Poettering's history. He implemented the Apple Bonjour protocol for Unix not Apple's XNU, a sound stack that mimicked Apple's Core Audio, and an init that nearly matches 1 to 1 with Apple's launchd. And last I checked nobody was spot checking macOS' UNIX creds.
I'm not someone who's absolutely thrilled with systemd, but at some point every single comment thus far on this story has just been contempt culture. [aurynn.com] I'd invite everyone to watch The Tragedy of systemd. [youtube.com] Which puts together a historical look at how we arrived at systemd and why it won.
I get people love their rc scripts and by all means, that's the point of open source to be able to do it your way if you want. But some of the hate that has come onto systemd isn't well founded. It's akin to how folks here kept looking at Java like it was the same Java from the 1990s. And this, "it's Microsoft like" argument, is also one that's not well founded. If one looks at launchd and systemd the similarities and the inspiration for systemd is right out the gate apparent. But you've got your +5 insightful because it feeds the contempt culture here, not because it's an actually good argument.
Re: (Score:3)
He implemented the Apple Bonjour protocol for Unix not Apple's XNU
Avahi implements DNS-SD, and mDNS, collectively known as zeroconf. Bonjour is Apple's implementation of the same. Avahi does not implement Bonjour, and Bonjour does not implement Avahi.
a sound stack that mimicked Apple's Core Audio
No- PulseAudio is nothing like CoreAudio.
Every OS has its own Sound API (or 6). This necessarily requires some kind of software mixer (that may do its work via a hardware mixer- but that's not important).
Prior to Pulse, this was provided for by ALSA or OSS, which were too close to the hardware, and thus had audio sharing pr
Re: (Score:3)
I want to know why your opinion on this should be considered when your understanding of the history is so wrong?
You may refer to the links I've provided which provide further links thereof. Outside of that, this conversation is done.
Re: (Score:2)
Re:Not surprising (Score:5, Interesting)
Prior to Pulse, this was provided for by ALSA or OSS, which were too close to the hardware, and thus had audio sharing problems. Pulse was simply a natural way to solve that problem.
Jack already had that covered, but had yet to handle dynamic changes in hardware configuration which would have been something to work on/fix and all sorted.
At the time though this was rejected in the name of purposefully having higher latencies in order for (at that time) netbooks and other power constrained devices to stay in low power modes longer. There is a whole lot more to it along with some pretty horrible architectural/code issues with pulseaudio that the jack developers already had sorted.. but that's a whole bag of worms in itself. Poettering was not a specialist in the audio space and would not take even useful suggestions.
Pulseaudio made audio go from working at high quality to about a decade of pain before the thing became usable/stable.
Thankfully pulseaudio is now being replaced with pipewire, which takes the jack approach but has dynamic configuration of new hardware/latency config etc along with it.
The coder involved in it's development is being mentored by the jack developers, and it's great to have the flexibility we enjoy with jack available even to programs that want pulse-like backends.
Re:Not surprising (Score:5, Insightful)
Jack already had that covered, but had yet to handle dynamic changes in hardware configuration which would have been something to work on/fix and all sorted.
Not really. JACK was never a good choice for a system sound server.
It necessarily required large amounts of CPU time to do its work. It is great for its intended purpose though- Pro/low-latency audio server.
To this day, a misbehaving client can still stall the entire audio pipeline, and it requires strict formatting of PCM data.
None of this should be taken as a dig against JACK- which is a great piece of software for its intended purpose.
Pulseaudio made audio go from working at high quality to about a decade of pain before the thing became usable/stable.
Heh. No argument there, Pulse was a fucking pain in the ass. However, from a software developer perspective, it's great.
And in its current form, it's also pretty great. I haven't had to remove it in years, now.
Thankfully pulseaudio is now being replaced with pipewire, which takes the jack approach but has dynamic configuration of new hardware/latency config etc along with it.
Na, Pipewire takes the best of both worlds, really. It provides JACK-level latency without the obnoxiousness of programming JACK. I.e., it's a low-level consumer system audio server. And as a bonus, it supports Pulse (so all the software that has standardized on Pulse still works)
The main thing actually driving Pipewire though, is its requirement for Wayland screen-casting/sharing, which is why it coincides with the switch to Wayland as the default display server on most distributions, now.
The coder involved in it's development is being mentored by the jack developers, and it's great to have the flexibility we enjoy with jack available even to programs that want pulse-like backends.
Couldn't agree more.
Re: (Score:2)
It's not quite jack-level on latency. It's sufficiently slower that the recommendation is to stick with Jack for pro work, pipewire for everything else.
Re: (Score:2)
Of course, PW is not a perfect replacement for JACK in functionality, so that's one very big reason to stick with JACK, or, I imagine more likely, PW + JACK with JACK being the audio backend for PW (that way you still have sane mixing for non-professional clients)
Re: (Score:2)
For me, the big improvement in audio on Linux so far is that ALSA no longer seems to have a problem with sharing. I have gotten best results for a long time by ripping pulseaudio out by the roots.
Will look at pipewire.
Re: (Score:2)
Prior to Pulse, this was provided for by ALSA or OSS, which were too close to the hardware, and thus had audio sharing problems.
I'm curious what problems people have. I don't have PulseAudio on my system and everything works including pluggable devices. When I try to look for "what problems pulseaudio solves", the only relevant answer is a blog post from 2008 calling PulseAudio "a solution in search of a problem" https://jeffreystedfast.blogsp... [blogspot.com] Apparently at the time it was marketed to be the solution for sound mixing, but this seems to not be a problem anymore.
Re: (Score:3)
You are however still limited to however many hardware channels you have (ALSA doesn't have a software mixer)
Yes it does, and it has for literally decades. It's called dmix [opensrc.org]. It's used by default for cards without a hardware mixer, though you can also set it up manually if you want to handle more streams at once. It does "only" support up to 24 bit audio, but that doesn't seem like a big problem for most people :)
The only problem solved by pulseaudio is network transport of audio. And it used to be really bad at that.
Re: (Score:2)
> every single comment thus far on this story has just been contempt culture.
It's hard to tell these days which ones are just trolls with no value to contribute to society and which are honestly old men yelling at init.
I don't get why the latter don't just run and contribute to Slackware, which has been fantastic since forever.
https://linux.slashdot.org/sto... [slashdot.org]
Shit, my video camera runs init out of ash and busybox and nobody is complaining.
Re: (Score:2)
Shit, my video camera runs init out of ash and busybox and nobody is complaining.
I may be totally off-base here, but I suspect the "choice of what init major distributions end up using" has a bit more complaint-generation capacity than your video camera.
I mean shit, my home fileserver doesn't even run a desktop and nobody is complaining.
Re: (Score:3)
> nobody was spot checking macOS' UNIX creds.
Everybody gave up trying to hold MacOS to any UNIX standard long ago. It has no UNIX creds to be checked. The only connection to UNIX was using BSD as a starting point.
And systemd need to die. The only job an init system should do is start the daemons that the system needs, and optionally monitor and restart them if they fail. And for such a simple task, shell scripting is more than adequate.
Re: Not surprising (Score:4, Informative)
Re: Not surprising (Score:4, Interesting)
The SUS is worth precisely dick.
Cygwin can be made SUS compliant with little work. Have fun playing with that.
Re: (Score:2)
Wrong.
It means Apple paid for *testing*, and it passed.
FWIW multiple Linux distro vendors have paid for testing as well, and the distros passed, which means that *Linux is a UNIX*.
Currently only Huawei's distro, but previously others passed too.
https://www.opengroup.org/open... [opengroup.org]
Re: (Score:2)
It means Apple paid for *testing*, and it passed.
No, technically, you pay for the test itself. You then run it, and list off your excuses for the reasons it fails, or the non-standard things you have to do to your OS for it to pass. This is called a conformance statement.
A random Apple conformance statement for you to go over. [opengroup.org]
Further, "not implemented" (Not Applicable) technically is a valid answer to any POSIX noncompliance for SUS.
It's a bullshit certification.
Re: (Score:2)
https://www.opengroup.org/open... [opengroup.org]
https://www.opengroup.org/open... [opengroup.org]
Re: (Score:2)
Re: (Score:2)
He lost me once he began running executables out of /lib.
Re: (Score:3)
He does _what_?
The more I read about his crapware, the happier I am I have it on none of my systems.
Re: (Score:3)
And last I checked nobody was spot checking macOS' UNIX creds.
It's in the name. macOS doesn't end in in an 'x' and thus doesn't get checked. But for some reason Linux sounds like Unix and thus has to be just like Unix in every way and needs to preserve the philosophy and anyone who dares speak against the "Unix way" must get hung drawn quartered tarred feathered and above all get accused of being an MS plant.
Yet those same idiots will happily should "Android is Linux, Linux is therefore a roaring success". It's like people completely switch off their brains when these
Re: (Score:2)
I suspect that had he taken Launchd and recoded it, he could have done a much better job of it. Systemd service units are, IMHO, an example of incremental design and implementation. That is, they didn't start life with all that they have now - things like ExecPre got added on later because Lord Poeterring didn't think anyone should ever have the need to run more than one thing in a service unit. Another example would be environment variables and files - the syntax for which is, well, weird and proprietary.
About that video you linked to (Score:2)
I'm not someone who's absolutely thrilled with systemd, but at some point every single comment thus far on this story has just been contempt culture. [aurynn.com] I'd invite everyone to watch The Tragedy of systemd. [youtube.com] Which puts together a historical look at how we arrived at systemd and why it won.
It's 47 minutes long, so hard pass from me and probably others on that. Good luck to those who want to watch it. I'd rather do something else with that time.
Re:Not surprising (Score:4, Interesting)
http://0pointer.de/blog/projec... [0pointer.de]
Myth: systemd is monolithic.
If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries are separated out so nicely, that they are very useful outside of systemd, too.
A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.
Re:Not surprising (Score:5, Insightful)
Unless you can mix and match those 69 pieces with other systems, they are really a monolith split into libraries.
Re: (Score:3)
Can I pick and choose which of these 69 binaries to implement?
Re:Not surprising (Score:4, Funny)
Myth: systemd is monolithic.
Reality: systemd is monolithic. There are just some clueless morons that keep insisting it is not, all with bogus arguments.
Re: (Score:3)
"Do one thing. Do it well."
Re: (Score:2)
Windows13 'The Judas Edition' (Score:5, Funny)
Image a lovebaby between Windows11 and SystemD.
Just when you think it could not get any worse.
Re: (Score:2)
He will be working on Microsoft's Linux offerings. They already have their own distros that use systemd, used in their Azure cloud.
Re: (Score:3)
That crap with the incompetently secured MS backdoor into it? Yeah, smart choice for a Linux system.
Re: (Score:2)
We have that already. It's called Service Manager and it's a sane way for an OS to track and manage its core running services which doesn't involve blindly firing off 150 line long scripts and hoping to dear god the result shits a PID file out somewhere.
Sometimes.. (Score:2)
Good let him wreck their sh*t (Score:5, Interesting)
Good let the little cretin wreck their sh*t. My systemd-free gentoo boxes are doing great without any of his ideas.
Re: (Score:2)
I don't understand why everyone rides his dick so much. My Gentoo box is systemd-free as well and everything works great. You'll really gonna jump to Linux then give up your freedom so easily?
Re: (Score:2, Insightful)
The hatred is ridiculous. He didn't sneak into your boxes and install his software.
Some influential distros decided that his stack was superior. If you don't agree, don't use them. It's free software. You have plenty of options.
Re: (Score:3)
Some influential distros saw that SystemD was swallowing a huge amount of Linux functionality which had nothing to do with launching processes. Even worse, applications that depended on that functionality would require major changes to be compatible with SystemD as well as the traditional initialization systems. Those distros recognized the gargantuan amount of technical debt that would be accumulating as SystemD continued expanding into so many
lol (Score:5, Interesting)
I made this joke in jest yesterday and now it's true. That's the funniest shit. I guarantee he's going to continue to fuck with Linux via WSL now.
I remember on April Fool's someone made a Reddit post saying that systemd had a new key-value pair store for all applications to store config values in like systemd-stored instead of messy /etc/, and tons of people actually defended it. They were arguing a systemd Windows Registry on Linux was a good idea and didn't even understand the irony. We'll probably get that for real now, and even more Poettering ego, clout, and bullying developers at conferences.
Re: (Score:3, Informative)
They were arguing a systemd Windows Registry on Linux was a good idea and didn't even understand the irony.
Windows registry is a good idea that was implemented badly. There is libelektra ( https://www.libelektra.org/ [libelektra.org] ) that is basically a better version of registry for Linux and it's pretty neat. Unfortunately, it has the chicken-and-egg problem, so its adoption is slow.
Re: (Score:2)
The registry is a good idea, just not the way Microsoft implemented it.
A standard format for application configuration, instead of text files all needing different parsers. A standard place to store it, so that user profiles can be easily made portable and network accessible without having to copy lots of little files around. Per-application permissions so that apps can't spy on each other, similar to Android and iOS.
Microsoft's problem is that they started with none of the benefits and all of the downsides
Re: (Score:2)
>A standard format for application configuration, instead of text files all needing different parsers. A standard place to store it, so that user profiles can be easily made portable and network accessible without having to copy lots of little files around.
Aww, man, I wish we had something like a standardized way to store configs in a text file. Maybe we could call it INI or something.
And I just LOVE having all of my configs in one binary like blob, that way a single error on a single sector of my memory
Huh (Score:3)
I don't know why, but this didn't surprise me at all. Somehow it seems very, very fitting.
Interesting language ... (Score:4, Insightful)
"there is no overstating his enormous contributions to the Linux/open-source world and his dedication to advancing the ecosystem over the years" is a very interesting way to say "He f*cked it all up and set us back a couple decades."
Seriously, maybe it's time for a look at the post-Linux world. What a train wreck it's become.
When knuckleheads like Poettering have me pining for the halcyon HP-UX days, something is really, really wrong.
Re:Interesting language ... (Score:5, Informative)
"Seriously, maybe it's time for a look at the post-Linux world. What a train wreck it's become.
FreeBSD welcomes you. We have cookies, and never had systemd.
Re: (Score:2)
FreeBSD welcomes you. We have cookies, and never had systemd.
You also have no market share.
Re: Interesting language ... (Score:2)
Re: (Score:2)
When I can use a juniper firewall to play games and do CAD design I'll be interested.
It's like you're trying to emphasise how little market share FreeBSD actually has with the only examples you have being ... not computers.
Re: (Score:2)
I have it on good authority that FreeBSD doesn't actually exist. After all Slashdotters are all in rage about the fact that they are forced at gunpoint to use systemd and therefore hate the person who programmed it. So it couldn't be possible that alternatives exist.
Re: (Score:2)
My perception, though, is that even FreeBSD has a more limited hardware support to the point it brings inconvenience for home usage.
I haven't tried FreeBSD for years, but I admit it crosses my mind every time I have to deal with issues caused brought by systemd.
Re: (Score:2)
Re: (Score:2)
Harvey OS is where it's at. Or where it will be anyway.
Maybe he ALWAYS worked for Microsoft? (Score:5, Insightful)
Would actually explain a lot.
Hey Lennart, can we go back to initd now? Feel free to take systemd with you. We'll even let you take AppImage and snap if you promise not to bring them back.
Re:Maybe he ALWAYS worked for Microsoft? (Score:5, Insightful)
I'd be happy with some very small utilities that do SystemD's functionality, and have been rigorously audited and vetted. UNIX is about small utilities which do narrow tasks in scope. Not huge code blobs which handle everything from the boot process, to network connectivity.
Plus, binary logging has its own issues. That needs to be tossed and we go back to simple text logs. Less corruption that way.
Re: (Score:2)
Hey Lennart, can we go back to initd now?
Why did you simp for Lennart? Why did you ask his permission? What's wrong with you? Lennart has had zero impact on your ability to use initd. There are many options for you to keep using it, and if your favouite distro of choice doesn't offer it, then maybe you should direct your humiliating begging comment at your distribution maintainer.
Re:Maybe he ALWAYS worked for Microsoft? (Score:4, Informative)
At this point, the best solution for pretty much all the gripes ./ers have about Linux can be solved by installing FreeBSD.
Or just Devuan...
Too bad... (Score:2)
Too bad James Gosling didn't land at Microsoft after leaving Oracle...it'd be intriguing to see what the technical impact and technology would be...
Maybe Java# or JC# ??
Or if Bjarne Stroustrup landed at Microsoft...
Josh K.
Wait a minute, I need some clarification (Score:2)
I need some clarification.
Is this saying that systems is *not* a Microsoft in invention in the first place???
Re:Wait a minute, I need some clarification (Score:4, Funny)
I need some clarification.
Is this saying that systems is *not* a Microsoft in invention in the first place???
I thought it was a Red Hat invention. Remember, they make their money by selling customer support. Can't do that if the software works properly. ;)
If systemd is so bad... (Score:5, Insightful)
...why was it officially adopted in lots of respectable linux projects (like Arch and Debian) ??
Genuine question - I'm not smart enough of a sysadmin to have a strong conviction about it. But, if it is so objectively horrible, against the principles of open source, etc etc, how come it made it so far out into lots of really good distros?? Doesn't make sense to me.
Re:If systemd is so bad... (Score:5, Insightful)
...why was it officially adopted in lots of respectable linux projects (like Arch and Debian) ??
Genuine question - I'm not smart enough of a sysadmin to have a strong conviction about it. But, if it is so objectively horrible, against the principles of open source, etc etc, how come it made it so far out into lots of really good distros?? Doesn't make sense to me.
This has some of the motivations [tecmint.com]. I think the two general reasons are that systemd can handle parallelization, so it's a lot faster, and it has more features available.
I think the speed is a big factor for users and I suspect the cloud, my modern distros boot a LOT faster than previous versions. As for the extra features I suspect there's a bunch of stuff there various devs were clamouring for but I don't know the specifics.
According to the distros their enterprise customers also really wanted systemd... though that's harder to judge second hand. Certainly a lot of the old-school sysadmins seem to hate it though I'm not sure how many of those are actually administering enterprise systems.
Either way, people who dislike a change are almost always louder than those who like it so it's hard to tell the actual popularity just based on community reputation.
Re: (Score:3, Insightful)
my modern distros boot a LOT faster than previous versions.
Your modern distros probably run on extremely fast Nvme SSDs and high core-count CPUs that until fairly recently weren't really that common. I'd say they started trickling in at about the same time the whole SystemD transition was set in motion.
I'm running several non-systemd systems and frankly can't feel a difference speed wise for better or worse.
Re:If systemd is so bad... (Score:5, Insightful)
systemd or something like it makes deploying your own services far easier. You just write up a configuration with the command(s) to start/stop/reload, etc. and what to do on failure, and off you go. It can accommodate a variety of service lifecycles (fork and daemonise, run in foreground, accept sockets), trigger events, dependencies and so on. This is far better than trying to deal with an ad-hoc mess of shell scripts that all do things in different ways.
Which brings me to the crux of the matter: it isn't that us enterprise admins want systemd per se - we want a reliable, modern service management framework. systemd is a lousy implementation of some good ideas. But we'll take it because there don't seem to be any better options at the moment in Linux land.
Re:If systemd is so bad... (Score:5, Interesting)
Re: (Score:2, Informative)
But, if it is so objectively horrible, against the principles of open source, etc etc, how come it made it so far out into lots of really good distros??
It's not against the principles of open source, it's against the principles of Unix. Linux distros have never been particularly good about adhering to those principles.
Re:If systemd is so bad... (Score:5, Informative)
It's because it's a genuinely better way to manage system services.
It's faster. It has explicit dependencies which enables parallelism. It integrates cgroups natively.
It unifies service configuration language. This is the thing that many people say they hate about it. Rather than any executable being able to do whatever it wants there's a model for how to describe your service and the things it will execute.
The biggest problem with it is that it's not seamlessly compatible with existing init scripts. If you don't have any existing custom init scripts, then this doesn't matter. In my life I've only written a few custom init scripts, and in almost every single one of them I went looking for something like libdaemon to help me simplify certain steps. systemd integrates all of that stuff and puts it into one manual.
Ultimately the people that hate systemd for legitimate rather than cargo-cult reasons it's because they didn't feel like they needed all of the extra features and functionality that systemd offered, so the cost of migrating seemed like a waste of time to them.
I've recently had to make unit files for systemd and, compared to my experience doing init scripts to cover the same workload about five years ago, it has been an amazing experience. I have no interest in going back to the old way.
Re: (Score:3)
Systemd does have a decent compatibility layer for init scripts. You can put a script in /etc/init.d and ask systemd to reload. It'll generate shims for the scripts it finds in there. If you write LSB compatible init scripts, there's a very good chance they'll "just work". You can even specify dependencies inside of (or on) your init.d services.
Re:If systemd is so bad... (Score:4, Interesting)
Re: (Score:2)
For the same reason a lot of horrible systems, products and implementations succeeded: Their makers realized that you should pour more money into marketing than into engineering if you want something to succeed.
This isn't capitalism, this is consumerism. Not the better product prevails but the one that gets the most coverage and clout.
Re:If systemd is so bad... (Score:5, Informative)
Some general points here. [lwn.net]
SystemD, like most things, isn't entirely bad, or entirely good.
As for the bad sides of things, if it kept to _just_ an init system, a lot of it's detractors would go away. If systemd developers response to breaking systems when you enable debugging [freedesktop.org] wasn't effectively "tough shit, we do what we want" (including breaking other projects).. people would probably respond to them better.
It's concerning when projects with developers that have attitudes like that begin to subsume all of the areas around them, much like systemd has.
Slowly piece by piece as more parts of the system are overcome by it (login, network) it becomes harder to harder to avoid.
If they're willing to tell the linux kernel devs to sod off when they break the kernel, what chance do smaller projects have of getting things fixed when they through some dependency break their own project. It's definitely a risk management consideration.
Re:If systemd is so bad... (Score:5, Interesting)
Because systemd is a good idea, very badly implemented, but it's the only comprehensive implementation.
The basic idea is to specify what you want running (and dependencies between them) and to keep them running. This is also the idea of Solaris SMF and goes back to at least OS/400 in the early 1990s (maybe earlier). It is an excellent idea and far superior to the traditional UNIX idea of "start a background process and hope it keeps running".
Systemd's implementation is bad in almost every way (buggy, complicated, opaquely monolithin, needlessly duplicates existing services, really bad runtime deadlock evaluation, counter-intuitive restart behaviour, etc). The lead developer is also very hard to deal with which is another problem because it impedes collaborative improvement of systemd.
But the initial idea is so good that lots of distros took the only available implementation of it for Linux: systemd.
That's why we're all stuck with this pile of crap, but our systems are more reliable now.
Re:If systemd is so bad... (Score:4, Informative)
Yep. Systemd is a poor and confusing reinvention of JCL.
I would take issue with your "more reliable" comment, though. Systems may be more reliable to run, but require considerably more effort to fix when they do inevitably go wrong.
Re: (Score:2)
There's whole books been written on this topic: https://en.wikipedia.org/wiki/... [wikipedia.org]
I'm not being funny here. The core issue of systemd hate is an intrinsic inability to cope with change.
Re: (Score:3)
There's whole books been written on this topic: https://en.wikipedia.org/wiki/... [wikipedia.org]
I'm not being funny here. The core issue of systemd hate is an intrinsic inability to cope with change.
Bullshit. This is a direct lie and a tired old often used one. The (and your) dishonesty already nicely manifests itself in the term "systemd hate": Because the systemd proponents do not have a technological leg to stand on, they try to emotionalize everything. Everybody against it is obviously not really against it, but just afraid of the new. Yeah, suuure. A classical tactic to sell something that is bad. Also a classical tactic used by scammers. Make people fear they may be missing out. Here is a hint: W
Obviously ... (Score:4, Funny)
He's completed his mission and has now returned home ...
Re: (Score:3)
Just like the stooge Microsoft planted at Nokia a few years back, you mean?
That's surprising? (Score:3)
Never watched any alien invasion movies? The invader always returns to his home planet after the mission has been accomplished.
Why does Solaris SMF never get mentioned ? (Score:4, Informative)
Re: (Score:3)
The short answer is no. Why? Because Larry Ellison owns it and he won't release any code for free,
Sw33t (Score:2)
Monolithic. (Score:2)
People seem to forget this.
Synergy attacks again (Score:2)
systemd + system32 = system32d
Re: (Score:2)
Just because in 2 years windows will have an kernelD.dll, gdiD.dll, userD.dll and the audio system will resemble the pulseaudio, it don't mean Poettering is trying to take over the thing.
It's just because his way is the best way, obviously.
Re:The 3 E's (Score:5, Funny)
TFS says he's continuing work on systemd. I think that makes it probably more likely that he'll now be introducing the following services to Linux, each of which will consume 100% of one CPU core at all times: LinuxModuleInstallerWorkerD, MicrosoftOfficeClickToRunD, MaliciousSoftwareRemovalToolD, SearchIndexerD, CortanaD, XBoxStatD and RegistryD.
Re: (Score:2)
Nothing stops him/can stop him from porting systemD to windows as well
Re: (Score:2)
Re: (Score:2)
Windows is shitty enough without extra help
Not strictly true: I believe even incompetent Microsoft programmers want to make good code deep down, and it might happen if top engineers, managers and execs don't actively maintain the shittiness level. Microsoft has a reputation to uphold and somebody needs to do it.
Re: (Score:3)
And I want to make good food when I cook, it's still not something i'd make anyone but myself suffer through.