0) That's not the init systems job.
1) That's not the init systems job. Use something like http://cr.yp.to/daemontools.html
2) Less modular than any init system out there. Having *everything* (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it.
3) See 1.
4) Never bothered me, but fair enough.
5) That's not the init systems job.
6) Not if the path's differ. E.g. are debianized.
7) So was sysvinit.
8) That's not the init systems job.
9) It actually is.
I can understand the issue that people have with systemd swallowing more and more functionality, but this fact is just false.
dhcp is in /usr/lib/systemd/systemd-networkd, which is not the systemd binary running as PID 1 (/usr/lib/systemd/systemd/systemd).
chris@raspberrypi /usr/lib/systemd $ ls -la systemd systemd-networkd
-rwxr-xr-x 1 root root 907340 Apr 14 23:10 systemd
-rwxr-xr-x 1 root root 329604 Apr 14 23:09 systemd-networkd
chris@raspberrypi /usr/lib/systemd $ ./systemd --version> 0) That's not the init systems job.
For modern Linux, there is nothing but hotplug. And I mean that very literally. Oldest Unices only worked on systems where all the hardware was brought up on boot, before the rest of the system. Then hotplug was added on top of this. Init systems didn't evolve to accommodate this, instead different systems were developed to handle it. However, the Linux kernel has constantly evolved towards eliminating old-style static boot, with right now, on normal bootup, almost all devices are hotplugged. This is why sysvinit doesn't work properly anymore. Being hotplug capable is definately the init system's job.
From that perspective -- the perspective of systems which boot once, and boot again maybe next year if the UPS didn't keep them up when the power flickered, and the perspective of the systems where there are definitely not usb drives or random pieces of unknown crap plugged into user accessible ports, the idea of hotplug at all is the least of concerns, and the idea of boot time is laughable.
Essentially, it seems like systemd is chasing Windows of 16 years ago, where computers took 5 minutes to boot Windows, where device drivers and such were a mess, and things were constantly entering and leaving systems.
No, you don't understand me. Even if actually hotplugging things is completely uninteresting to you, your init system still has to somehow be able to deal with the fact that on a modern box, all your devices show up in essentially random order with random delays. sysvinit currently handles this by putting a completely arbitrary sleep call in the beginning of the boot process. Just last week I had to deal with a server where due to circumstances that sleep wasn't enough, which lead to the ethernet devices getting initially wrongly named, which was bad because the mountains of script doing network configuration there happily treated the external network as the internal one and the internal one as the external one.
Even if hotplug is a feature you don't care at all about, due to design decisions made by the Kernel team, if you want to run a modern Linux kernel your machine will have to fully support hotplug properly or it's going to (rarely and non-replicably) fail in interesting and imaginative ways.
That nevertheless doesn't have anything to do with hotplugging devices, nor does it suggest that we should create an init system which handles dhcp, qr codes, and, no shit, takes core files and jams them into its binary log.
In the end djb's daemontools are nothing more than an init system on top of an init system. So why not include it in the main init system?
What do you mean by that? That it isn't PID 1? Apparently it can be made to run as PID 1. But you can keep the (in my opinion) brilliant design of daemontools and use successors such as s6 are designed to run either as PID 1 or as a plain old daemon (which is nice if you've not got full control of a machine).
http://www.skarnet.org/software/s6/index.html
I've been using s6 to manage a few things, and some features I like are:
- allow a group to manage (stop/restart) certain processes using Unix file permissions
- arrange things in a tree. My toplevel s6-svscan starts a second s6-svscan which starts a handful of related processes. These all inherit the same user and environment vars which makes config easy.
http://skarnet.org/software/s6/why.html
The big feature s6 has that runit lacks seems to be the ability to wait without polling on some event (process started). I haven't used this much myself, but even given that some process has started, it doesn't necessarily mean that it's initialized and ready to do what you expect.
It is a suite of tools for managing the system state. Going from runlevel 0 to runlevel 3 is just one such transition.
systemd is referred to as monolithic because it is developed in a single repository, but it is in fact extremely modular. "PID 1" is only one of the ~70 binaries which make up the systemd suite.
Saying "That's not the init systems job" seems dogmatic and short sighted when there's currently no other approach which offers the hotplug, service management, security and performance features that systemd brings to the table.
I'm not saying that isn't possible -- ZFS is an example of a tool that gobbled up lots of others, and it's almost better -- for my use-cases not being able to grow a raid-array is a bit of a deal-breaker, as is the requirment of having roughly 4GBs of RAM available -- for many use-cases it isn't. But having disk management, filesystem management and managing disk encryption in one tool is great.
Beside that, I recommend you'd take a look at http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... and possibly http://www.freedesktop.org/software/systemd/man/.
See other replies.
0: udev did that. They merged udev in. Now systemd does it. I'd rather see them play nice by communicating with other projects than controlling everything on their own.
1: Apart from internal watchdog, the features he listed are also available in upstart. (others are not, but his list is actually common)
3: This is a strange claim when talking about an init system that effectively starts managing devices.
6: Not sure why it's on the good things list - it already happened before for rc/init/upstart. It's inevitable rather than new awesome - we'll all have to rewrite the configs once again.
8: Why is that part of systemd? Ubuntu was happily running with it being a separate daemon. If it doesn't depend on systemd why is it included (same for udev really). Convenience for developers is not a great answer here.
There seems to be a lot of exaggerated claims going both ways - at least that shows not everyone is happy about the change. Hopefully the next project that replaces init will be what many claim systemd is right now...
Which certainly means he has the right to merge udev in, but it doesn't necessarily make it a nice thing to do for the rest of the community.
Those that have become dependent on udev without believing they'd be hitching their cart to a horse that replaces the init system, cron, at, syslog, etc. now have to go through the process of building systemd to rip udev out, and keep their fingers crossed that it doesn't get harder (or outright impossible).
Lots of projects in the open source community get split up as they get bigger. One of the other commenters on here mentions all of the openstack stuff, which I think is a great example.
From my anecdotal experience in watching the open source community over the last 14 years is that most people, when working on multiple projects, keep them as multiple projects, unless they are /really/ duplicating functionality, and thus, effort. Even then, they might not merge them. See: All of the work Brendan Gregg does for performance engineering tools. He's constantly writing small patches to improve KTap, Systemtap, Sysdig, DTrace linux ports, etc. Despite the fact they're all competing projects. Granted, he's not in charge of any of them, and I can't read his mind, but would someone who likes merging projects together sit there and spend so much time constantly improving projects that are competing with each other? I doubt it.
I'm not sure why the same maintainer matters for merging. Take openstack as a counter-example. It's mostly the same pool of contributors working on a number of related projects. Not only have they been split into components (nova, nova-volume, nova-network -> nova, cinder, quantum projects), common functionality has been split into separate library projects of their own (oslo-messaging, oslo-logging, etc.) with their own releases, versioning, leadership. This is what I really like and it's exactly the opposite of what systemd is doing (merging device, network, logging, etc. into one system).
If systemd is modular (doesn't require logind) and logind is standalone (requiring only systemd as a library) - what's the point of bundling them. (apart from making it harder for others to use) Systemd owns too much at the same time and I believe it's going to lead to problems in the future.
"I don't think we ever disagreed enough for me to refuse patches from them - it was very much a case of they had different ideas to me, and couldn't contribute them because of the CLA
If the CLA wasn't there, we'd've just tugged and pulled and fought about patches like normal projects, and Upstart would have turned out much like systemd - I'd've been okay with that :)"
The CLA is absolutely why systemd exists. systemd didn't fork because there was no benefit to anyone in sharing code -- Upstart wouldn't take their patches. There are technical differences, but those could have been handled in code (like Scott says) if the CLA hadn't existed.
This does not make sense to me. They could fork it if it was good enough. If they started from scratch, then CLA wasn't the main issue. It's like "the corner store didn't have the milk I like today so I had to start my own farm".
If there was no CLA, the folks who went on to develop systemd could have decided that the benefits of collaborating with an existing project were greater than the benefits of writing systemd from scratch. And everyone involved seems to agree that that's what would have happened. Yes, as a purely technical matter, the systemd people decided starting from scratch was better than forking Upstart. But the reason it was a purely technical decision was their refusal to sign the CLA, which meant the ONLY considerations were technical. But there are other considerations that could have swung the decision the other way if not for the CLA.
I do (rarely) install Linux on some new PC but I think I stopped installing Arch after this changes. I mean what's the point installing Arch if there is no very elegant and beautiful rc.conf? What is that killer feature that Arch offers, apart from being rolling release?
> I mean what's the point installing Arch if there is no very elegant and beautiful rc.conf?
rc.conf removal had nothing to do with systemd, I think. And was removed prior.
> What is that killer feature that Arch offers, apart from being rolling release?
Vanilla upstream packages.
I'd be interested to know if the systemd boot process (which can be 2 seconds or quicker) has enough advantages to make the other changes worth it.
When I first used Arch in 2006, rc.conf held a lot of configuration. From what I understand, it held even more configuration options prior to that. Since that time and until the removal of rc.conf, there was a steady removal of features from rc.conf.
Anecdotal evidence can be dismissed by anecdotal evidence -- A variation of Hitches' razor
Switching to systemd broke _my_ entire Arch _experience_. Before systemd I knew exactly what gets executed, when and why -- which is exact reason why I switched to Arch many years ago. I don't know the same thing after systemd introduction.
As a general point for everyone: Just because it's _also_ an init system doesn't mean it's not allowed to provide the binaries for doing a whole lot of other stuff. :)
Why can't we have an independent organisation that defines a spec for all the relevant APIs and tools for managing a system, and systemd just be one implementation of that spec? Actually, it could be a suite of specs, so people could pick and choose which ones solve their problems, and build alternatives for others.
> [...] by the same people, with the same ideas, and the same gatekeepers [...]
Isn't this exactly what made the Linux Kernel great? A consistent vision.
I agree with you on a few points though, the systemd team should be more cooperative and start being conservative on the API changes. If the API is defined clearly, it shouldn't be hard to make proper replacements for parts of it.
I disagree strongly that there should be an independent Organisation to define that spec, because that would quickly be overrun by bikeshedding and all the other problems stemming from design by comittee. Very often in the Open Source world, specs have been defined by the first people arriving at the scene, so to speak. It all works over dbus, no? That is a fairly simple protocol to implement. I think it's an elegant IPC solution.
Anyway. cheers!
Sure, but even today, the Linux kernel has competition. I can run most things on Windows or OSX or FreeBSD or Solaris, even if the technical details are different. I worry about a monoculture forming around systemd, as seems to be happening now; I can't find a modern distro that uses anything else (aside from Gentoo, which I can't take seriously for production work), and it's starting to be assumed that systemd is the only init system that anybody will use.
You can still use Windows, OSX or FreeBSD.
> $ ls -al /etc/systemd/system
and look at its contents. It is not that hard. It changed everyone's experience. Some people just hate change. Others deal with it.
While it did make desktop / laptop users experience a little bit more complicated, from what I have read it makes things much easier on the sysadmins who are working with lots of daemons on the servers.
Also try the other options to systemd-analyze, such as "critical-chain", as well as systemd-cgls to get a view of how the currently running processes relate to specific service files.
Together it should give you a view of what gets executed when (to the fraction of a second) and why.
Maybe on Arch this is simpler, on Fedora systemd-analyze dot produces a nightmare that no human mind can navigate.
> -- Try a shell pipeline like 'systemd-analyze dot | dot -Tsvg > systemd.svg'!
EDIT: there are 1101 edges in the graph produced on my machine.
Funny thing. For me systemd has turned that around. I had no idea what was going on in my system, but systemd allows me to easily visualize it, control it and optimize it.
systemd may not be the ultimate init system which all Unix/Linux versions will end up using, but I have no doubt a future init-systems will take a queue from all these things which systemd has done well.
I don't know if it didn't break for the majority but for me it certainly did on many installations.
Like being good solid rolling release distro is not good enough? Frankly I prefer my distros to be free of any "killer features".
That may not sound like much, but it's pretty awesome. I use it as a reference on a few things even when dealing with other Linux distros.
e.g. The page on SSH basically starts with how to restrict users who can log in and disabling root. https://wiki.archlinux.org/index.php/Secure_Shell
Haven't used Arch in a while - not dealt with a non-company Linux box for a while. But it remains my go-to Linux (for development purposes) for good reasons.
Before installing Arch, I was a die-hard Kubuntu/KXstudio[2] user. Now I have the ability to build all the KXstudio packages from git (Cadence, Carla, and Claudia make JACK the greatest thing ever), without all the Ubuntu/Debian cruft underneath.
Another benefit (post-snowden) is that Arch is not an incorporated entity in any of the "Five Eyes" countries. Julian Assange has come out to publicly state knowledge of intentional flaws being added to both Open Source/Free Software projects, and specifically namedrops Debian as compromised. The threat vectors one should analyze are which governments would have access to which corporations. RedHat is a registered corporation in Delaware, USA. Canonical is registered in City of London. If one pays attention to Moxie Marlinspike's convergence demo at DEFCON 19, you can see how it'd be trivial for a government agency such as GCHQ/CCSE/NSA to spoof Canonical's or RedHat's SSL certificates. Gentoo and Arch have no corporate influences, and thus are the only relatively safe Linux distributions left, IMO.
So, AUR, Advanced customization, and potentially increased security are bigger reasons, for me, to switch to Arch than pacman.
Dmd is the gnu daemon managing daemons.
Im planning at least to provide more documentation, when I learn guix and dmd more.
I'm a huge fan of Lisp-based languages, but this thing actually wants people to use Lisp for creating service files!
http://www.gnu.org/software/dmd/manual/dmd.html#Service-Exam...
Not even data-based lisp like Clojure's data format (the one that Light Table uses for its configs, forget the name), but full-on lisp!. That would be a maintenance nightmare for sys admins.
Not to mention that it seems rather sparse in basic features... I couldn't find any example in the manual for setting users & groups or permissions. These are fundamental.
I love the fact that the configuration is written in Guile. Data is code and code is data after all. I think you're exaggerating the maintenance nightmare. In fact, the Guix project has already proven that newcomers who don't really know s-expression style syntax can write software packages.
The only way to actually manage such a DSL/Schema is to provide a way to "break out" of it into a general purpose language - that's what systemd does by allowing you to run shell scripts in the case you're not using a "standard" service, and it's also what the Nix expression language does in order to build software.
It's far easier to just provide a fully capable language up front - and abstract the common patterns into functions or macros to simplify the usage for users. sysv has worked well with just shell scripts for years, despite it being a sub-standard general purpose language - although various hacks like the LSB init headers have been added to provide some kind of structure to them - a problem that will be better solved with records in Guile.
As for maintenance, I see it as a big plus - with a language like Guile you have access to a useful REPL and debugger - no need to roll your own debugging interface or inspect log files. On top of that, having a dynamic language makes it easier to develop and test patches for new requirements - you're not forced to recompile and restart your DSL.
https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
Summary: