Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Agreed. Also, what software doesn't need refinement? I think he said it best when he brought up how people say systemd is buggy. "It's software." Perfect answer there as well.Great talk. I"m a fan of SystemD but as others have said it needs refinement. I really liked his answer to the question about how the SystemD devs and Linux community but heads and don't bother listening to each other. "A lot more sympathy on both sides." Perfect answer.
Personally, I love systemd over the old SysV init method. I think the days of individual init scripts for every service being a viable option are over. As he discussed, back in the old days a Unix system didn't have a lot going on, but nowadays a normal desktop system can have hundreds of processes. Doesn't seem smart to run a system with that much going on without a service manager. Sure, systemd might be grabbing things up that it doesn't need to, and we can have a discussion about that, but overall I think it's great, and something that Linux definitely needed.
I've heard they're even going to incorporate a Word Processor in a future release!!!However, like many, I've always been a little concerned with how systemd seemed to be encroaching into seemingly unrelated things (e.g., networking). But at least I have a bit better understanding as to why after watching the talk.
Not to mention, that as the guy in the video states, systemd is effectively establishing an official system layer within a Linux system. I would argue that services like networking, device detection and configuration, etc are all part of a "system" layer. I wouldn't call myself a systemd expert, but in what I know of it so far, nothing that has been integrated into it at this point fails to make sense to me.Its easy to understand why the systemd folks have included other systems into their package. For things like networking to work properly they either have to be part of the project or follow a very exact standard to they can interact properly. We all know how that would likely go.... multiple bigs like Ubuntu and Red Hat squabelling over specifics and SystemD having to tend multiple code paths.
So in a way SystemD militantly taking over all services is for the greater good. lol
Not to mention, that as the guy in the video states, systemd is effectively establishing an official system layer within a Linux system. I would argue that services like networking, device detection and configuration, etc are all part of a "system" layer. I wouldn't call myself a systemd expert, but in what I know of it so far, nothing that has been integrated into it at this point fails to make sense to me.
While I understand your concerns, one thing to keep in mind is that systemd isn't this monolithic beast. Take networking for example. Sure, it has networkd that handles network connections, it's still just a daemon within systemd. It isn't required for systemd to operate. Plus, networking is still actually implemented at the kernel level, systemd is just the user facing side of the whole networking equation. But, I think that the concern that one systemd daemon going down will cause the whole thing to potentially crumble is a little hyperbolic due to how systemd is designed. Systemd, like the GNU utilities is really more of a collection of tools into one meta package that manages system level services. At least, that's how I think of it. I also like that it adds some much needed standardization to Linux. Now, if say a distro thinks they can develop a better networkmanager, they have a common target (networkd) that then means that they're work is inherently highly portable amongst distros running systemd. At least, that's how I understand it. Correct me if I'm wrong.I think it is all trade offs, the more you include in this "system layer" the more bloat you get. For instance, not all systems need network interfaces or the rest of the services that come with that. That is rare, but it is still a thing. The more you start incorporating into the all encompassing systemd, the more difficult it becomes to build a system or even perhaps compile a kernel without it. Also it starts removing some choice as well. One of the great things about Linux is being able to pick and choose what you want to use. The more things you make a core component, the less choice you have. For instance, as I mentioned before, now that udev is part of systemd, there were some things that changed, some stuff was lost, some stuff was better, but certainly a lot of development we had done prior was thrown down the drain. On the positive note, they have seemed to be fairly attentive to issues and resolving them.
EDIT: Another small note, part of my potential issue with the way things are going with systemd, is that once it gets large enough, making an update to one portion of it, might start to require you to reload all of it, potentially forcing you to reboot your system.
While I understand your concerns, one thing to keep in mind is that systemd isn't this monolithic beast.
No but a blender and two extra blades are included.I've heard they're even going to incorporate a Word Processor in a future release!!!
I kid of course.
Systemd violates the unix philosophy of simple pieces of software doing one thing & doing it right. It replaced tons of legacy mature/stable systems with a huge cluster**
With that being said, I'll roll with it but expect to see tons of problems that have already been "solved"
The funny thing is, systemd's design would anger probably at least 95% of GNU/Linux users (probably including you too) IF it was anything but the init system.
I know some of you think the "Unix Way" is just a meme, but it's actually the reason you can do shit like pipe terminal commands into each other. It's THE reason you have components you can wrap your brain around which can all be pieced together and managed in a simple and flexible way. That's what the Unix Way does.
You want another great example of the Unix Way? Ironically systemd is a GREAT example of the Unix Way. Not in its design though, but in its mere existence.
Have you ever realized how absolutely amazing it is that a new piece of software as fundamental as PID 1 could be swapped out in all of our major distros (even "stable" ones) in only a few years time?
The significance of that cannot be overstated. And yet, although systemd owes its success to the Unix Way which made it so easy for them to step in, it undermines the Unix Way in its own design.
Do you think 20yrs from now when systemd is old and busted that it will be so easy to swap it out with something better? Well not only is the scope of this thing which needs to be replaced now massive compared to what it used to be, but you'd also probably have to rewrite a lot of other software, or beg the developers to change their dependencies. It doesn't matter if systemd works. You didn't start using GNU/Linux because it "works" did you? You started using it because it allowed you to be the master of how your data flows, and it allowed you to combine things in ways nobody else on GNU/Linux was doing to get exactly what you want.
Quit being led astray by the "just works" argument when it comes to systemd just because init systems aren't something you care to play around with and customize all that much. That shouldn't matter, and we should stick to the tried and true design principles that have served us so well all these years.
I have NEVER heard any Linux/Unix/BSD admin complain about text logging. Until now. First for everything I suppose.The video touches on this. Systemd solves a lot of stuff that hadn't been properly tackled before. There was Upstart (a good start, but limited) and launchd (open-source IIRC, but too locked-in to macOS).
Fact of the matter is, Linux has outgrown almost all of the utilities that have been replaced by systemd. A simple init that jump-starts a bunch of chained scripts that run serially is no longer sustainable. An init that isn't aware of the network state (and vice-versa) is no longer adequate. A logging system that is simply a text dump of each app using its own format is more difficult to work with.
Systemd's utilities are basic, single-function apps that perform their intended job and nothing more. Only now, they're all coming from a single modern project and designed to work together, instead of a disparate set of developers with their own needs and goals scattered across multiple projects and platforms. Many of those were outdated and/or were created to solve the problems of 20+ years ago that may no longer be relevant.
I have NEVER heard any Linux/Unix/BSD admin complain about text logging. Until now. First for everything I suppose.
It's really one of those things, I believe, that you don't realize could be much better until you see an actual improved implementation. Regular text logs are OK, but you often have to grep around different files and archives to find what you're looking for. Being able to run 'sudo systemctl status <service>' and get the exact log messages that show why a service failed is great.
Examples of what journalctl can do.
And more.
When you manage tons of servers (as I do at work) you log to a centralized syslog server anyhow.