Unintegrated desktop linux is painful, and the fixes for it so far have mostly been hacks. Systemd actually attempts to create some kind of modern cohesive system which is a good thing.
Maybe you don't see the downsides to the lack of integration because you're just used to putting up with them.
I think mostly people adopted Linux to get away from paying a lot of per-seat license fees for everything, and to get away from having to buy some vendor's medium iron hardware rather than just using commodity x86 chips.
I don't agree with everything he says (the invasion of desktop linux seems completely unsubstantiated) but there are a couple of problems he points out that worry me, and I think we should pay attention.
Maturity: it certainly feels rushed that in less than four years systemd went from nothing to the default init system in most Linux distributions (if I'm not mistaken). For something so basic and important you'd think a good amount of testing and bugfixing should happen before that. We are taking our time with btrfs and Wayland, so why the rush with systemd? We certainly could endure some more years with the previous init systems. And this comes from an Arch Linux user, I like my software as fresh as I can I get away with, but it still seems odd.
Compatibility: this troubles me the most, you see hard dependencies appearing like what we currently get with Linux, systemd and GNOME. When people talk about this they are usually referring to the BSD family. That's a legitimate concern, but think about this: if in the future appears a brilliant programmer who designed a free kernel which runs circles around Linux, what will we do if everything is so tightly coupled? We have to consider the possibility that we won't be running the Linux kernel forever and be prepared to switch if something better appears.
>Maturity: it certainly feels rushed that in less than four years systemd went from nothing to the default init system in most Linux distributions (if I'm not mistaken). For something so basic and important you'd think a good amount of testing and bugfixing should happen before that
Maturity should not be confused with age. There is certainly positive correlation between the two, but it's not necessarily that strong. A piece of software that has been around for four years and been used by everybody will be more mature than software that has been around for ten but was only used by a small community.
There is also a chicken-and-egg problem here: software needs get widely adopted _before_ it can become mature.
Lol no. On many levels. MacOS does implement separate daemons, but they're all very tightly integrated, communicating over a common protocol. The core components hardly run in isolation, nor are they interchangeable. You don't, for example, just replace launchd with some other init system. You don't just say "hey, screw Aqua I want to use something else." (You can run other WMs through X11, but only on top of Aqua) Darwin is a bit more BSD-like, but nobody actually uses Darwin without the rest of MacOS.
And seriously, systemd isn't one single daemon either. It's a collection of daemons running that communicate over a common protocol. It isn't all-or-nothing, either. Only a few of the daemons are considered "core" and the rest are optional. And, because they use a common documented protocol, even the core components can be replaced. You don't hear about alternatives because nobody has really written any, but it doesn't in any way prevent you from doing it.
I think the legitimate concerns about systemd are things like losing portability of stuff like Gnome to BSD and systemd's short history, but it isn't one giant monolith executable or anything like people say.
> Lol no. On many levels. MacOS does implement separate daemons, but they're all very tightly integrated, communicating over a common protocol.
What common protocol? Mac OS X doesn't have dbus. It recently acquired XPC, but XPC is NOT a system bus -- it's simply an IPC library. It's neither required, nor universally used, nor is it terminally glued to the remainder of the OS.
> You don't, for example, just replace launchd with some other init system.
You don't? Says who? All launchd does is serve as an inetd/cron-esque daemon. The system daemons themselves continue to vend standard sockets and mach ports, and launchd itself does not pervade their externally vended interface.
> You don't just say "hey, screw Aqua I want to use something else."
Actually, you can. The display stack is driven by IOKit; XDarwin can run directly atop said stack.
Likewise, none of the "Mac-like" features that you want -- for example, automatic network configuration -- rely on any sort of centralized entity that pervades all daemons. There's a seperate system -- SystemConfiguration -- that provides that functionality, abstracted through a set of well-defined APIs and modular and distinct from the remainder of the system.
> * It's a collection of daemons running that communicate over a common protocol.*
Hence it's really rather monolithic, because to play in the systemd universe, everything has to conform to systemd's tightly coupled design.
What you're describing is all quite similar to how systemd operates. Your definition of "monolithic" seems to be that the components communicate with each other. My definition is that the components are difficult to replace. Systemd makes it easier to replace components, because the requisite interfaces are clearly defined.
MacOS is quite tightly integrated, it's what Apple does. Darwin is a bit different, as it's much more BSD-ish; with that I agree. But MacOS is a lot of stuff on top of Darwin and replacing any part of that would require tons of very MacOS specific code to do. Apple most definitely does not intend for their users to be able to replace logind or Aqua or pretty much any core service.
Probably a better way to phrase it would be to consided how much effort it'd take to run Aqua on BSD. You'd have to port basically everything that is MacOS. To me, that is what a monolithic system means.
Oh man no, go take a look at the launchd sources and see how much is hard coded in for how Apple wanted it - likely when you run into something unexpectedly not working how you wanted or expected.
Yes and no. It's true that OSX uses a variety of separate daemons, that run in different pids.
However they are all "required", "packaged together", "part of one source tree" and "shipped by a single vendor". In this respect they are a lot like systemd.
In fact it is arguably a lot more integrated. Both Python and Ruby are OSX dependencies. systemd isn't even close to that much of a power-grab.
GNU/Linux requires vi, perl, python... also as dependencies, but they're separate programs, the thing with systemd is that nothing can be separated, you use ALL components at the same time or change OS. Bear in mind that systemd is being integrated with the Linux kernel, so you have to update the kernel in sync with systemd.
> Bear in mind that systemd is being integrated with the Linux kernel, so you have to update the kernel in sync with systemd.
I'm just feeding a troll or someone who is really ignorant, but here I go.
No it isn't, and no you don't. Systemd is closely tied to some Linux-specific features, but it generally isn't part of the kernel. And you don't have to update the kernel in sync with systemd. Systemd lives in userland, by definition.
It does impose a minimum kernel version in order for systemd to work, which is something like 2.6.39 (May 2011 vintage). They have bumped up the minimum version a couple times as they needed new features, but you don't have to upgrade both together. I routinely upgrade one or the other separately on multiple systems and distros.
And it bears repeating again... systemd is not one single executable or process. And not all of the components are required, you can turn all but a few core ones off. And the core ones could be replaced if you wanted to, because there's a documented interface that you can implement.
Also, Vi, Python and Perl aren't "required" for GNU/Linux. They're common, but definitely not required. Vi is required if you want to comply with the Single Unix standard, but that is not the same thing. GNU/Linux just refers to pairing the Linux kernel with GNU userspace utilities; it doesn't necessarily dictate any specifics. There are further standards like LSB that attempt to do so but again not relevant. On top of that, Vi, Python and Perl aren't even GNU projects, which is true of a ton of other programs common in Linux distros, which is one reason I personally find the term "GNU/Linux" a bit onerous.
Also, Vi, Python and Perl aren't "required" for GNU/Linux.
By that definition nothing is ever required. There's the same argument in my comment history, someone said, udev is not required for GNU/Linux. technically, chromium doesn't "require" blink. It's not required, you can use chromium and receive raw html, right? But in that case OSX doesn't "require" Python either, just delete the files, done :)
So again, I'm saying, I want a GNU/Linux system. (Yes, it's not required, I can install MS-DOS, HURD, HP-UX or Android.) That means POSIX, LSB... That's what 99%+ of programs targeting GNU/Linux expect.
Tell me, have you actually used systemd? Because you're completely misunderstanding the first two points as they're overtly not the case. Particularly the first point, as what it is saying is that they are willing to use newish features in the kernel, not that you are forced to always be running the latest bleeding edge kernel to have an up to date systemd.
The second point has some validity, but is a distortion. Of course you couldn't plug ConsoleKit in as a replacement for logind, because ConsoleKit was never designed for that. What you can do with logind is implement a simple compatibility layer with the standard systemd interfaces and then use it; this is what Ubuntu is doing. What is mandatory to use systemd's services is to implement its protocol for communicating between the services. This is why some of the services are "core" ones- because they're implementing the basic functionality common to the other modules. They can still be replaced, as long as the replacement obeys the same interfaces. This is however a problem for BSD, as the easiest way to use the systemd components is to implement the interface, but that does require features that are only present on Linux.
> By that definition nothing is ever required.
And yes, that was exactly my point. The term "GNU/Linux" is meaningless and doesn't require anything specific. What you might want out of a GNU/Linux system is probably totally different than what I do. You might want Emacs, but I'm a Vi guy. I don't want Emacs and you might not want Vi. How do we settle this? Committee vote? Mud wrestling?
They're saying that after the kernel release with those features comes out they will make a release that depends on those features, not that the kernel and systemd must always be updated together.
networkd is still under development but if you're running a version of systemd that has it, it's already very nice so long as you don't need wifi. Right now I'd recommend it over NetworkManager for users who don't mind config files instead of using a GUI if they have access to it. It just works and it's automatically triggered by udev right when the hardware appears on the bus and sets everything up without the pile of shell scripts that is the status quo right now.
Unintegrated desktop linux is painful, and the fixes for it so far have mostly been hacks. Systemd actually attempts to create some kind of modern cohesive system which is a good thing.
Maybe you don't see the downsides to the lack of integration because you're just used to putting up with them.