For me, systemd on Arch reduced my boot time from 45s or so to pretty-much-instant-on. Which is pretty damn nice for a distro where one tends to reboot a lot.

> 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.

It was possible to have < 5 second boot times in 2008 https://lwn.net/Articles/299483/

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.

See this prior NH submission [1], and inthe G+ post he mentions fairly early on why it's important to be very quick in the boot process, and how DHCP figures into that. (TL;DR using VM containers that can normally boot within 100 ms, getting the DHCP server to respond within 50 ms means on-demand container spin-up for a specific request is possible)

[1]: https://news.ycombinator.com/item?id=7510660

rc.conf was removed in Archlinux as a final step of the path to systemd and became obsolete when sysvinit became obsolete, not prior.

The removal of rc.conf was the final step, but they had been dismantling rc.conf piece by piece for years prior, even before systemd was released.

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.

I keep hearing bullshit about how systemd broke archlinux. But for the vast majority of us it did not. I had atleast 3 machines running ArchLinux at that point and had very little trouble porting all of them.

Anecdotal evidence can be dismissed by anecdotal evidence -- A variation of Hitches' razor

Then let me try to explain again:

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.

I understand what you mean. I had the same awe when I first started on Arch and really got to know all the bits and pieces. When I transitioned to systemd, I had to go through that again. It was actually very similar to what I did the first time around and I suggest you give it a shot too. systemd, while seemingly monolithic is actually a really cool suite of tools. The thing we need to keep in mind is that it's _not_ sysvinit, and it's not trying to be. It's trying to be a project that does more than that and does it transparently on all systems. You might like it :)

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. :)

The problem is that it's a suite of tools that are all developed under the same umbrella, by the same people, with the same ideas, and the same gatekeepers. It's rather difficult to fully replace parts of it, especially as the formal API to it is defined by systemd, and we're seeing more and more tools integrate with all that.

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.

Hmmm... I pondered this for a bit, and I arrived here:

> [...] 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!

> Isn't this exactly what made the Linux Kernel great? A consistent vision.

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.

> 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.

Yes, I can, but I used to have choice within the Linux ecosystem. Now I do not. Having choice taken away is not a good thing.

Just do

> $ 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.

It's not that bad. rc.conf had its own problems. Remember the archaic format of specifying your network setup in rc.conf, and how it required tons of special utilities to do things like intelligently connecting to available wifi points? Yuck.

Feed "systemd-analyze dot" to Graphviz and you get a dependency graph of the current boot.

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.

>Feed "systemd-analyze dot" to Graphviz

Maybe on Arch this is simpler, on Fedora systemd-analyze dot produces a nightmare that no human mind can navigate.

It is the same on Fedora and Arch. But you can visualize it as an svg. It says so right at the bottom when you run the command.

> -- Try a shell pipeline like 'systemd-analyze dot | dot -Tsvg > systemd.svg'!

You don't understand, the graph itself is a nightmare, in any format.

EDIT: there are 1101 edges in the graph produced on my machine.

> 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.

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.

It happened for me. It's not bullshit - Archlinux had the wonderful plan to make /lib a symlink, and that just broke a lot of stuff on my systems.

I don't know if it didn't break for the majority but for me it certainly did on many installations.

They have / had an explanation about what needs to be done on their home page. Their news bulletins and their wiki are as important as the distribution itself.

I know. It's not the point. My point is that I was in no way able to /not/ issue these tasks.

> What is that killer feature that Arch offers, apart from being rolling release?

Like being good solid rolling release distro is not good enough? Frankly I prefer my distros to be free of any "killer features".

It's Wiki is pretty killer.

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.

Seconding this: the killer app of Arch Linux is its community support.

> What is that killer feature that Arch offers, apart from being rolling release? Apart from that its pacman, just sick of the apt-get madness. And generally having far less default crap on you system.

Arch's killer feature, in my mind, is the Arch User Repository[1]. If the package isn't included in Arch's binary repos, the "yaourt" command will build the package (often from git) via a user-contributed script. You can set the make options to Gentoo's suggested -march for your CPU, and build really optimized packages. I'm experiencing <5 second boot times, lower RAM usage, and snappier WINE/WineASIO performance.

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.

1. http://aur.archlinux.org

2. http://kxstudio.sourceforge.net

Yeah. pacman is a killer feature. I always install pacapt [1] before dealing packages elsewhere.

[1] https://github.com/icy/pacapt