
Shall we fork Fedora? - rmi_
http://forkfedora.org/
======
p8952
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)

~~~
23david
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/b...](https://github.com/inthecloud247/runit-for-
lfs/blob/master/blfs-servicescripts/services/sendmail/run)

------
cwyers
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?

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

------
n0body
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
Flakeyness of Arch? What do you mean by this? It seems to be very reliable for
me.

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

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

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

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

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

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

~~~
n0body
why not one that uses systemd?

~~~
therealidiot
perhaps just freedom of choice, knowing that you aren't just being forced to
do something

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

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

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

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

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

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

