6 ms·

Shall we fork Fedora?

53 points by rmi_ 12y ago

n0body 12y ago
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
- monksy 12y ago
  Flakeyness of Arch? What do you mean by this? It seems to be very reliable for me.
  - n0body 12y ago
    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™
  - spb 12y ago
    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.
- klaasvakie 12y ago
  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.
  - andor 12y ago
    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).
- dead10ck 12y ago
  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?
  - chimeracoder 12y ago
    > 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_embroidered_shirt-231437232851326664 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.
hunt 12y ago
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.
- makomk 12y ago
  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.
  - thwarted 12y ago
    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.
  - ultramancool 12y ago
    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.
p8952 12y ago
It'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 http://pastebin.com/DfAL75Kd
- dmix 12y ago
  Agreed, 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.
- 23david 12y ago
  OpenRC is interesting. Also compare with a runit example of managing sendmail from the runit-for-lfs project: #!/bin/sh sv check slapd postgresql mysql >/dev/null || exit 0 exec /usr/sbin/sendmail -bs -bd -q5m start https://github.com/inthecloud247/runit-for-lfs/blob/master/blfs-servicescripts/services/sendmail/run https://github.com/inthecloud247/runit-for-lfs/blob/master/b...
jbb555 12y ago
Trying to work out which linux dist to switch to. Obviously one that doesn't use systemd. So what choices do I have?
- n0body 12y ago
  why not one that uses systemd?
  - therealidiot 12y ago
    perhaps just freedom of choice, knowing that you aren't just being forced to do something
- Xylemon 12y ago
  Slackware or Gentoo is an option.
- 23david 12y ago
  Not too many options surprisingly... Linux from scratch has a runit-for-lfs project here: https://code.google.com/p/runit-for-lfs/ https://code.google.com/p/runit-for-lfs/ github mirror: https://github.com/inthecloud247/runit-for-lfs https://github.com/inthecloud247/runit-for-lfs I've also been keeping an eye on voidlinux: http://www.voidlinux.eu http://www.voidlinux.eu
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- steanne 12y ago
  i saw an openrc version of manjaro posted in their forums recently.
- ultramancool 12y ago
  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.
giancarlostoro 12y ago
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.
- kolev 12y ago
  There's Fedora Copr [1]. [1] https://copr.fedoraproject.org/ https://copr.fedoraproject.org/
- octix 12y ago
  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.
  - giancarlostoro 12y ago
    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.
23david 12y ago
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.
cwyers 12y ago
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?
- Vendan 12y ago
  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.
- dsr_ 12y ago
  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.
  - cwyers 12y ago
    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.
kolev 12y ago
This is unfair. You can actually do a shared shell library that other services use and also have just a few lines service definitions.
4ad 12y ago
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.
- staticshock 12y ago
  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.
  - chronid 12y ago
    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.
notacoward 12y ago
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
skrebbel 12y ago
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?
- chronid 12y ago
  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...
e40 12y ago
I'm hoping by the time CentOS 6.5 is EOL this systemd situation will be all worked out.
lotsofcows 12y ago
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.
- MetaCosm 12y ago
  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.

53 points by rmi_ 12y ago

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

monksy 12y ago
Flakeyness of Arch? What do you mean by this? It seems to be very reliable for me.
- n0body 12y ago
  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™
- spb 12y ago
  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.
klaasvakie 12y ago
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.
- andor 12y ago
  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).
dead10ck 12y ago
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?
- chimeracoder 12y ago
  > 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_embroidered_shirt-231437232851326664 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.

hunt 12y ago

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.

makomk 12y ago
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.
- thwarted 12y ago
  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.
- ultramancool 12y ago
  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.

p8952 12y ago

It'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 http://pastebin.com/DfAL75Kd

dmix 12y ago
Agreed, 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.
23david 12y ago
OpenRC is interesting. Also compare with a runit example of managing sendmail from the runit-for-lfs project: #!/bin/sh sv check slapd postgresql mysql >/dev/null || exit 0 exec /usr/sbin/sendmail -bs -bd -q5m start https://github.com/inthecloud247/runit-for-lfs/blob/master/blfs-servicescripts/services/sendmail/run https://github.com/inthecloud247/runit-for-lfs/blob/master/b...

jbb555 12y ago

Trying to work out which linux dist to switch to. Obviously one that doesn't use systemd. So what choices do I have?

n0body 12y ago
why not one that uses systemd?
- therealidiot 12y ago
  perhaps just freedom of choice, knowing that you aren't just being forced to do something
Xylemon 12y ago
Slackware or Gentoo is an option.
23david 12y ago
Not too many options surprisingly... Linux from scratch has a runit-for-lfs project here: https://code.google.com/p/runit-for-lfs/ https://code.google.com/p/runit-for-lfs/ github mirror: https://github.com/inthecloud247/runit-for-lfs https://github.com/inthecloud247/runit-for-lfs I've also been keeping an eye on voidlinux: http://www.voidlinux.eu http://www.voidlinux.eu
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
steanne 12y ago
i saw an openrc version of manjaro posted in their forums recently.
ultramancool 12y ago
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.

giancarlostoro 12y ago

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.

kolev 12y ago
There's Fedora Copr [1]. [1] https://copr.fedoraproject.org/ https://copr.fedoraproject.org/
octix 12y ago
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.
- giancarlostoro 12y ago
  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.

23david 12y ago

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.

cwyers 12y ago

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?

Vendan 12y ago
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.
dsr_ 12y ago
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.
- cwyers 12y ago
  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.

kolev 12y ago

This is unfair. You can actually do a shared shell library that other services use and also have just a few lines service definitions.

4ad 12y ago

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.

staticshock 12y ago
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.
- chronid 12y ago
  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.

notacoward 12y ago

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

skrebbel 12y ago

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?

chronid 12y ago
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...

e40 12y ago

I'm hoping by the time CentOS 6.5 is EOL this systemd situation will be all worked out.

lotsofcows 12y ago

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.

MetaCosm 12y ago
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.