Am I the only person who prefers systemd? Maybe because it's the only init system I've managed to get my head around. Other init systems seem so complicated. A config file vs a bash script is far easier and they all seem to require forking. I only use Linux for servers so I may be unaware of a sane init system that works like systemd but isn't systemd. Until something like that appears, I'll stick to systemd.
Shall we fork Debian?
131–140 of 284 posts
Re: Shall we fork Debian?
#132.....
> Why don't you do that [i.e. vote against systemd] 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.
.....
In that case, you don't have the time and patience to operate and maintain a worthwhile and ongoing Debian fork.
In that case, there is no substance to the "question" you're raising, because you wouldn't actually do what you're calling for.
In that case, you're just a handful of guys (or maybe even just one guy) who spent $10 on a domain name... to get more attention for your Slashdot/Reddit/HN post than it otherwise would have had if posted straight to Slashdot/Reddit/HN directly.
Re: Shall we fork Debian?
#133How does forking Debian solve anything? The issue is that Gnome, KDE, and other software requires systemd. You need to fix/maintain their compatibility with other init systems. Then it is easy for Debian user to switch init systems.
You listed two desktop environments, neither of which are of interest to sysadmins. Eg. I run an Openstack cluster and do not care if there are gnome or kde packages available. I don't particularly like systemd and would be happier not having to deal with the compatibility and/or conversion issues for what I perceive as minimal benefit.
I'm kind of irritated about having to learn a whole set of new things. I do recognise that there are some benefits for my use case in systemd. The desktop stuff aren't the only things that systemd brings.
More than that though, is the fact that it's going to be the new default everywhere. So while you say
I don't particularly like systemd and would be happier not having to deal with the compatibility and/or conversion issues for what I perceive as minimal benefit.
I think you (and I) will actually face more work in trying to avoid systemd than convert to it. You'll be fighting against your distribution's default and the default of every bit of third party software targeted at your distro. From what I have seen most conversions are fairly painless.
So from my position that sits somewhere between "ambivalent" and "that's kind of nice", going with the flow seems the easier path.
Re: Shall we fork Debian?
#134From the source: ..... > Why don't you do that [i.e. vote against systemd] 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. ..... In that case, you don't have the time and patience to operate and maintain a worthwhile and ongoing Debian fork. In that case, there is no substance to the "question" you're raising, becaus…
On another point: why the hell would you have a choice in init systems? As a user of the OS, I care that the proceses start, stop, and keep running. I don't care how. A purist in me might care, but I am not going to futz with installing different init systems for no good reason.
Re: Shall we fork Debian?
#135Am I the only person who prefers systemd? Maybe because it's the only init system I've managed to get my head around. Other init systems seem so complicated. A config file vs a bash script is far easier and they all seem to require forking. I only use Linux for servers so I may be unaware of a sane init system that works like systemd but isn't systemd. Until something like that appears, I'll stick to systemd.
[Unit]
Description=Apache 2 HTTP Web Server
After=network.target
[Service]
Type=forking
EnvironmentFile=/etc/conf.d/apache2
ExecStartPre=/bin/echo performing: /usr/sbin/apache2 -k start $APACHE2_OPTS
ExecStart=/usr/sbin/apache2 -k start $APACHE2_OPTS
ExecStop=/usr/sbin/apache2 -k graceful-stop $APACHE2_OPTS
ExecReload=/usr/sbin/apache2 -k graceful $APACHE2_OPTS
PIDFile=/var/run/apache2.pid
StandardOutput=syslog
StandardError=syslog
Restart=always
[Install]
WantedBy=multi-user.target
WantedBy=http-daemon.target
This is the sysvinit file for apache from debian. #!/bin/sh
### BEGIN INIT INFO
# Provides: apache2
# Required-Start: $local_fs $remote_fs $network $syslog $named
# Required-Stop: $local_fs $remote_fs $network $syslog $named
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# X-Interactive: true
# Short-Description: Start/stop apache2 web server
### END INIT INFO
set -e
SCRIPTNAME="${0##*/}"
SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
if [ -n "$APACHE_CONFDIR" ] ; then
if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
DIR_SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
else
DIR_SUFFIX=
fi
elif [ "${SCRIPTNAME##apache2-}" != "$SCRIPTNAME" ] ; then
DIR_SUFFIX="-${SCRIPTNAME##apache2-}"
APACHE_CONFDIR=/etc/apache2$DIR_SUFFIX
else
DIR_SUFFIX=
APACHE_CONFDIR=/etc/apache2
fi
if [ -z "$APACHE_ENVVARS" ] ; then
APACHE_ENVVARS=$APACHE_CONFDIR/envvars
fi
export APACHE_CONFDIR APACHE_ENVVARS
ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin"
if [ "$APACHE_CONFDIR" != /etc/apache2 ] ; then
ENV="$ENV APACHE_CONFDIR=$APACHE_CONFDIR"
fi
if [ "$APACHE_ENVVARS" != "$APACHE_CONFDIR/envvars" ] ; then
ENV="$ENV APACHE_ENVVARS=$APACHE_ENVVARS"
fi
And so on...Re: Shall we fork Debian?
#136I'm a devop, not a system administrator. I setup and administered a number of single machine web services for my customers along the years, almost all of them with Debian plus some Ubuntus recently. Database, application server, web server. Nothing fancy. I also use Ubuntu as my primary desktop (some sort of gnome fallback DE) after I removed a lot of cruft if comes with by default. From my experience what I need on…
I consider this a good idea. Servers and desktops are two different things so why not have two different Debian versions?
This way Debian Server could be kept small and simple while the systemd developers could continue without any restrictions. If they go too far then we could use the Debian server and add our own desktops to it.
Re: Shall we fork Debian?
#137From the source: ..... > Why don't you do that [i.e. vote against systemd] 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. ..... In that case, you don't have the time and patience to operate and maintain a worthwhile and ongoing Debian fork. In that case, there is no substance to the "question" you're raising, becaus…
I came here to say exactly that. "We don't have time to work with the Debian folks on a solution, but have time to create our own distro." Right. Then again, they should go for it. If nobody but them uses it, that's that. If it gains traction, cool. On another point: why the hell would you have a choice in init systems? As a user of the OS, I care that the proceses start, stop, and keep running. I don't care how. A p…
Why the hell would you have a choice in kernels?
Why the hell would you have a choice in filesystems?
Why the hell would you have a choice in sound systems?
Why the hell would you have a choice in desktop environments?
Re: Shall we fork Debian?
#138I'm a devop, not a system administrator. I setup and administered a number of single machine web services for my customers along the years, almost all of them with Debian plus some Ubuntus recently. Database, application server, web server. Nothing fancy. I also use Ubuntu as my primary desktop (some sort of gnome fallback DE) after I removed a lot of cruft if comes with by default. From my experience what I need on…
systemd has a number of features which are of interest to server operators, especially those who use containers, which may well be many of us before long. Running systemd as pid 1 does not imply running a desktop environment. I have plenty of VPS customers running systemd as pid 1 in 512MiB RAM. Running systemd as pid 1 doesn't imply having every single binary and subsystem of systemd running. I would encourage you t…
Actually, I find it's funny how anti-systemd people nowadays claim that "systemd is a init for desktop systems" since Gnome adopt something unrelated to the _init_ part of systemd that is the systemd-logind (that actually is a substitute of ConsoleKit that was deprecated god knows how many years ago). systemd has lots of features that makes sense on servers too. You may or may not need these features on your server, but systemd (as a init system) is still a better init system than sysvinit.
Re: Shall we fork Debian?
#139Re: Shall we fork Debian?
#140Am I the only person who prefers systemd? Maybe because it's the only init system I've managed to get my head around. Other init systems seem so complicated. A config file vs a bash script is far easier and they all seem to require forking. I only use Linux for servers so I may be unaware of a sane init system that works like systemd but isn't systemd. Until something like that appears, I'll stick to systemd.
I don't think you're wrong. I imagine all these people saying systemd is so awful are just worried that their hard-earned sysvinit knowledge will become obsolete and that new users won't have to go through silly bash scripts (that are totally secure of course - no chance of security vulnerabilities in something as ancient and wtf-free as bash). Instead they'll have something sane like this: [Unit] Description=Apache…