Shall we fork Fedora?
forkfedora.org
forkfedora.org
While the original (Debian Fork) made some ridiculous claims, this is not a fair comparison to make. As a neutral party I don't think I've seen anyone make the argument that SysVinit is any good, just that some other options may be better, and they should at least be an option.
When you compare systemd with something like OpenRC the obvious choice is less clear: http://pastebin.com/DfAL75Kd
#!/bin/sh
sv check slapd postgresql mysql >/dev/null || exit 0
exec /usr/sbin/sendmail -bs -bd -q5m start
"Why don't you do that yourselves? We are excluded from voting on the issue: only few of us have the time and patience to interact with Debian on a voluntary basis."
If you don't have the time and patience to contribute to a project like Debian, how are you planning to muster up the time and patience to run a full-on FORK of Debian?
[edit/clarification] Since this seems to be one of the most prominent critiques, we'd like to clarify this point. With lack of time and patience we refer to our possibility to be involved in a complex bureaucratic system like the one governing Debian. While we respect this way of working, we think that our time is better invested in new directions, also according to our expertise.
i just recently switched to fedora. i was on debian, then i went to arch because debian is too outdated, and i wanted systemd. but i don't enjoy the flakeyness of arch these days, i did when i was younger, but now there's more than just me using my computer, and when i do use it, i want to use it for work, not fiddling with stuff.
so when i was looking for a new distro, systemd was a requirement, there's no way i'm going back to sysv init, thought i'd give fedora a try, and so far i'm really liking it, everything works, and is upto date enough for my needs
anyway, systemd ftw. if you're against it and you've not used it, then that's stupid. if you're against it and have used it, fair enough, i can't fault that. i hate gnome, you can hate systemd. although the comparison isn't fair, as interaction with the init process if fairly low, but interaction with the de is high
In general, what people mean about Arch's flakeyness is the general maintenance involved with staying up-to-date, and reviewing all your pacnews/pacsaves.
It seems that for the "normal" use cases (i.e. laptop running gnome+vi, server running postgres) systemd will be simpler.
For embedded / single purpose applications, it seems that it will require a chunk more work. I have use cases like a) Only power the 3G module and bring up ppp when I am within certain GPS coordinates. b) switch the wifi between hostapd and wpa_supplicant depending on the state of a GPIO.
The fact there is no general purpose programming language in the .service files makes them simpler, but for anything out of the ordinary you will be writing bash/python anyway. And then it feels like systemd is just getting in the way.
The replacement daemons also seem a bit weak, compare timesyncd with chrony for example.
Sometimes all you need PID 1 to do is run the equivalent of rc.local and get out of the way (almost like slackware's rc.M)
So I guess my point is that not everybody is in the love/hate systemd camp, some of us are just careful and still sceptical.
You could create targets for all of your states, and use a small daemon to switch between them (using systemctl isolate).
I love Arch. I've been using Arch as my primary OS for over 4 years. I'm even wearing my Arch Linux hoodie at work today[0].
Every time someone mentions instability or flakiness on Arch (on HN or any other forum), I see comments like this, and it really makes me wonder - are we using the same distro?
Arch is great, but there's no pretending that it's the most stable distro. Anybody who uses Arch should be ready to handle unexpected breakages when updating, and be comfortable with addressing them by his/her self. A few miscellaneous problems I've had when updating:
* Haskell packages were moved to their own repository, though due to pacman issues, this meant that I (and a lot of other users) were left with broken packages. Since I used XMonad as my window manager, this meant I couldn't even start X11 properly! This is the sole reason I stopped using XMonad (went back to wmii, though now I use i3).
* Miscellaneous bugs which force me to boot from a USB and chroot to reinstall packages and/or reboot.
* The systemd migration was not very clean. I'm glad Arch switched to systemd, but the migration was tricky, and it also came within a few months of another rather tricky update (/bin) that broke things for a lot of people.
Some of these were mentioned on the Arch mailing list - but not all. And even then, the signal/noise ratio on the Arch mailing list is really poor if all you care about are potentially problematic updates[1].
I get that Arch is a distro that requires you to know what you're doing[2]. But I like to think that I know what I'm doing at this point, and I still run into issues every now and then.
Arch is a great distro, but let's not pretend it's perfect - it's not the paragon of stability, and that's why it's a great distro[3].
[0] http://www.zazzle.com/embroidered_arch_linux_fleece_jacket_e...
[1] I mean, seriously, some of the threads are about meetups at bars in Europe - I'm happy there's a thriving developer community there, but I don't want to have to sift through those messages just to figure out what I need to do in order to make sure my system still boots!
[2] At the same time, people oftentimes recommend Arch as a distro for beginners, which IMHO is really misguided - if you're not already very familiar with Unix-based systems, Arch has a pretty steep learning curve.
[3] I'm running Wheezy on another machine, and shellshock still hasn't been fixed there, whereas Arch had it patched within hours.
> Miscellaneous bugs which force me to boot from a USB and chroot to reinstall packages and/or reboot.
This one's a bit of a nuisance, but I seem to have only had it occur when mkinitcpio runs during an upgrade. I don't know if this was due to a bug in earlier versions, but I've since made it a habit to run mkinitcpio immediately after upgrading. I think that's culled about 98% of the mysterious breakages for me, usually related to the kernel upgrade process (or modules missing from initrd). Otherwise, it's been fire and forget.
Forgetting to merge new/updated configs is also a slight nuisance and can lead to breakage. This is partly why I like `yaourt -C`, but it doesn't always catch everything.
> The systemd migration was not very clean. I'm glad Arch switched to systemd, but the migration was tricky, and it also came within a few months of another rather tricky update (/bin) that broke things for a lot of people.
I had this experience, too, but in my recollection, it was mostly due to the fact that Arch was 1) an early adopter of systemd and 2) the full migration took effect during a time when there were unit files only for the most common services. Fortunately, nearly everything else I needed had been added to the AUR. One of the things I like most about systemd is the relatively low bar of entry to create new unit files for services that didn't exist. But, I will concede that some of the early helper unit files were a bit buggy, and the near-constant changes caused an unfortunate bit of havoc. I think that was largely fixed when netcfg was dumped for netctl. netcfg was a pain in the rear.
Which reminds me: If there's one thing I really missed coming from Gentoo to Arch, it was Gentoo's idea of configuring network devices. Until netctl, the only way to include some of the more unusual configurations in Arch required some magic (and lots of tweaking) with the netcfg scripts in order to get the right arguments passed to `ip` without netcfg going insane. Sigh. netctl is much more forgiving and better behaved.
> I'm running Wheezy on another machine, and shellshock still hasn't been fixed there, whereas Arch had it patched within hours.
Yeah, that was nice. Although I will point out that while the initial shellshock vulnerability was fixed almost immediately, the remaining vulnerabilities in bash weren't patched for a couple of days (still better than most everyone else). The final patch was rolled out about a week later when some of the "unofficial" patches were coming out from Redhat that actually did fix bash. Though, I gather from mailing lists linked from here that the disillusionment with upstream maintainers, confusion, and the 3rd party patches/patch sets/collections probably didn't help. That was messy.
I've only listed the last 2 problems now. As months go by the list will probably get longer and better reflect how much arch actually breaks (or doesn't)
Debian patched Wheezy for Shellshock within hours as well. You should verify that your box has the Security repository enabled.
I think one of my biggest concerns with systemd is that there seems to be little valid debate around it. The pro-brigade mock the anti brigade with little attempt to address their concerns.
Maybe I only see the outbursts, but it seems to me like there's way too much emotion and way too little honest discussion going on. Why is that?
And this is even before talking about systemd proper in a technical-ish way...
Although there are technical arguments here on both sides, I really hope that this 'SystemD vs Freedom Of Choice in Init Systems' discussion gets resolved in a way that doesn't create further divisions.
Programs have many bugs. I'd rather debug that shell script than debug systemd.
The shell script approach violates the DRY principle--it's probably super similar to some 50 other init scripts on the same system. systemd, in principle, removes the boilerplate so that the bug would only have to be fixed once.
I would not be surprised if all that boilerplate present in the shell script was now in /etc/mail/make now. No Fedora system around to check this right now, though.
Linux from scratch has a runit-for-lfs project here: https://code.google.com/p/runit-for-lfs/
github mirror: https://github.com/inthecloud247/runit-for-lfs
I've also been keeping an eye on voidlinux: http://www.voidlinux.eu
But consider FreeBSD, it may seem extreme, but if you're willing to make that move then their philosophy may be more in line with yours anyways. Their rc system is great and includes vastly simplified scripts using rc.subr, while still keeping everything as shell scripts. No bloated dbus or similar nonsense required.
Instead of having to compile software like Atom in every computer I own, I could just add a PPA repository and then install and update Atom (assuming the PPA remains maintained). It's not just Atom though, other software as well isn't as easily found on Fedora as it would be on the Ubuntu / Debian ecosystem.
NB not taking a position, just making a prediction
It's interesting to note that no patch has been submitted against the sendmail package, most likely because it's unnecessary. And the only reason that the logic was moved to separate subscripts called in ExecStartPre entries for systemd is because systemd doesn't have a language to express those things in, so they need to be subscripts in order to have that capability at all.
FreeBSD has a somewhat better simplification in my opinion using a common rc.subr file, which is included in many init scripts and can easily be reviewed by anyone editing an init script.