Shall we fork Fedora?
forkfedora.orgIt's probably a bad idea to start (another) discussion on this topic, but...
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
OpenRC is interesting. Also compare with a runit example of managing sendmail from the runit-for-lfs project:
https://github.com/inthecloud247/runit-for-lfs/blob/master/b...#!/bin/sh sv check slapd postgresql mysql >/dev/null || exit 0 exec /usr/sbin/sendmail -bs -bd -q5m startAgreed, there is only one argument provided by this page and it's based on a false pretense, a straw man. Making this page very ineffective.
From the debianfork.org page, which this is apparently mocking:
"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?
Short answer, because I've said it before: You can't vote on Debian issues without becoming a Debian Developer; that title requires a multistep process that takes between months and years. Debian publishes the stats at nm.debian.org, and there is general agreement that the length of the process is a problem, but not on how to solve it.
I don't doubt that there's a barrier there, and it could possibly (probably?) made easier to overcome. But it still strikes me as a smaller barrier than that of having to maintain a full-fledged fork, especially one that focuses on a low-level dependency like systemd, rather than focusing on higher-level stuff like the desktop environment.
from the page:
[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.
love it.
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
So I'll prefix this by saying that I haven't used systemd for anything important yet, but have it running in a VM to see what the impact will be when the distro's force us to switch.
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.
I have use cases like a) Only power the 3G module and bring up ppp when I am within certain GPS coordinates.
You could create targets for all of your states, and use a small daemon to switch between them (using systemctl isolate).
I've used Arch as my primary OS for over a year now, and I've never had any major problems. What flakiness have you experienced?
> I've used Arch as my primary OS for over a year now, and I've never had any major problems. What flakiness have you experienced?
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.
I'm still technically an Arch newbie having only been using it for 2-2.5 years. Gentoo was my primary for a number of years prior, so I've never felt Arch was overly flaky--leastwise not in comparison with the extraordinary breakage in Gentoo that can occur if you're not careful (but hey, it happens). So, I think it's important to keep in mind that the "feeling" of instability and flakiness is probably taken relative to some benchmark or experience that is difficult to divine from a few short sentences. In my experience, Arch has been quite stable and usable. It's not without its warts, of course, but I think it's one of the drawbacks you have to live with if you're using a rolling release distribution. (I don't know how Aptosid seems relative to this since I only use it on a laptop infrequently, but I'd imagine it's not impervious to odd breakage either.)
> 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.
The usual "Arch is unstable" convinced me to put up a very simple jekyll blog [0] with all the arch related problems I run into from here on out.
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)
nice, i had one the other day where convert would take 5 seconds to resize a jpeg. i downgraded it and it was fine. i probably should have filed a bug, but i had work to do, and had already wasted enough time waiting for images to resize!
Hmm, perhaps I haven't been around long enough to experience breakages like this, then. I began using Arch before the switch to systemd, and I use it with vanilla Gnome. The only thing that came close to a breakage was the recent move of java-common, but the email that went out from the mailing list included instructions for the upgrade that made it completely painless. Although I could definitely see that causing grief if you hadn't caught the email before upgrading.
> [3] I'm running Wheezy on another machine, and shellshock still hasn't been fixed there, whereas Arch had it patched within hours.
Debian patched Wheezy for Shellshock within hours as well. You should verify that your box has the Security repository enabled.
Flakeyness of Arch? What do you mean by this? It seems to be very reliable for me.
Personally, Arch has been really unstable for me, although I have a newer ATI graphics card and am trying to go it with the open-source drivers, so that's my problem.
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 is, but every now and then a software update will break something, or something will conflict. it's fine, but i find overall stability is a little bit of an issue, which i didn't use to mind, but these days i do. even simple things like making sure my machines are on the same versions of things, or expecting to install something and it just work™
What a puerile attempt at trivialising someone's concerns. Why do you think a file length is important? What you are demonstrating is the very lack of control that people are complaining about. Well done, you've replaced the standard functionality with an ini file. What about non-standard functionality? Flexibility? Transparency? The logging concerns? The dbus concerns?
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.
I have been using the tried and true ostrich technique to avoid the topic (the whole systemd debate). But honestly it feels like the file on the right is a whole lot more opaque. If (or when) it goes horribly wrong, I am not certain I would know where to start, as compared to a simple script file where I would walk it / debug it.
As an outsider, it frightens me how many flamewars Linux people can start over a single program. How many years has this systems soap opera been going on now?
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?
The debate around systemd is not only technical, but also highly political. Systemd is a shift towards the "aggregation" of many separate projects/components of the linux core userland (udev, polkit, wayland, logging, session management, etc) in a way that's highly incompatible with everything else. Some people like this new way forward (or don't care much), some do not. The attitude and the history of some developers of systemd do nothing to help (same thing for their "wakeup calls").
And this is even before talking about systemd proper in a technical-ish way...
As a 'devops', I've been sometimes saddled with the unfortunate task of bridging the communication gap between Sysadmins/TechOps and Devs.
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.
The argument presented is very weak. Yes, the service file is smaller and simpler, but I actually understand perfectly the init file, whereas to understand how systemd processes the service file I'd have to actually read all of systemd's source code.
Programs have many bugs. I'd rather debug that shell script than debug systemd.
Sure, debug that shell script, but then don't forget to propagate the fix to all the shell scripts.
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.
So does rc.subr under freebsd. Or openrc under gentoo.
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.
Trying to work out which linux dist to switch to. Obviously one that doesn't use systemd. So what choices do I have?
Not too many options surprisingly...
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
Slackware or Gentoo is an option.
It seems Debian may stay init-system flexible at least. So there may be an option there.
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.
i saw an openrc version of manjaro posted in their forums recently.
why not one that uses systemd?
perhaps just freedom of choice, knowing that you aren't just being forced to do something
I wish Fedora had PPA's, I had to ditch it for Ubuntu, got fed up of having to compile everything I wanted to use.
There's Fedora Copr [1].
Can you give a few examples, please? I've been using Fedora as my primary home and work OS, since v14 and was gradually upgrading it and so far I never needed to compile anything.
Example:
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.
As much as I love the Fedora folks, I think this is going to backfire. It comes off as even more condescending than the Debian-fork it mocks, and condescension is already one of the gripes people have.
NB not taking a position, just making a prediction
I rolled my eyes at the title after watching "Linux Sucks 2014" last night. I was pleasantly surprised to see an example comparison of init files.
I'm not sure it's exactly a fair comparison though; the right-hand file is shorter and simpler largely because they've split the work of the old init script across at least three files: the one shown, /etc/mail/make (which presumably now contains the messy preparatory work that made up most of the old init file), and sm-client.service. You could do that with traditional init if you wanted.
And the only thing keeping that from happening with traditional init is someone submitting a patch against the package to split up the functionality of the init script into more distinct subunits.
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.
One of the things which also bothers me about systemd is that it sort of "hides" things though layers of abstraction, compared to the shell scripts at least. For example, it is not immediately clear to me what effect "Type=forking" will have. It might not be so bad in this example, but it seems like this can wind up being quite complicated in some cases.
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.
This is unfair. You can actually do a shared shell library that other services use and also have just a few lines service definitions.
I'm hoping by the time CentOS 6.5 is EOL this systemd situation will be all worked out.