Shall we fork Debian?
debianfork.org
debianfork.org
.....
> 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.
The process is oriented towards supporting the development and maintenance of packages in Debian, which is probably as it should be, but it means that the viewpoints of people who actually use Debian -- and the vast majority of these are systems administrators with hundreds to tens of thousands of machines in their datacenters -- are not part of the organization.
Many decisions are based on the results of people installing the popcon package -- it's a popularity contest that sends the list of installed packages back to debian.org, and for that reason it systematically overcounts individual desktops and systematically undercounts servers in places which have even the vaguest notion of a security policy.
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.
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?
P.S. What happens for packages in Debian for FreeBSD and Hurd where systemd isn't available?
Unless you actually want to use one of these kernels that are not Linux. Hurd has nerver made it into a stable release and kFreeBSD is on the verge of being dropped as well.
There is only so much manpower and supporting every possible init system on every possible architecture on every possible kernel is getting out of hand.
For us, we care about all that stuff, because we are engrossed in it daily. For everyone else, they will never touch or understand and / or should never need to understand what a kernel, filesystem, sound system, or desktop environment is. To them, the computer is a tool, not an environment, and to use it is to press buttons to get some tangible result you want from it, and the buttons you have are not buttons you are going to know how to change.
So I want a choice in kernel, filesystem, etc because I care about the semantics, performance, ethics, and implementation of these things because I interact with, code for, and code against, them on a near daily basis. Everyone else does not know they exist, and thus don't care, so choice is irrelevant to them, in the same way the existence of Linux as an OS "choice" does not matter to them - if it is not on the notebook on the shelf at Best Buy, it might as well not exist.
If the higher ups at Debian really think they're going to be a player in desktop and are making decisions along those lines, then they must be seriously oblivious to the niche that Debian has actually settled into post-Ubuntu.
Choosing between them depends more on technical and project requirements.
Whilst I am not a fan of SystemD, it is important to remember that it came from RedHat.. you know, the people famous for servers.
SystemD will be a good init for Server, as it will be for Desktop. i am pretty critical of SystemD, but something is better than Sysvinit. I'd have favoured Upstart, but that doesn't matter... SystemD won, people need to deal with it. This is a good evolution for Linux.
Your general point is correct, but the analogy you're using is incorrect.
It's not tool/environment, but rather, it's tool/appliance.
The fundamental cultural shift going on between many anti-systemd and pro-systemd people is that the former want the computer to be a tool, something that with proper discipline and skill can yield great things, whereas the latter want it to be an appliance - something that you fire and forget, and is meant to be inflexible and that "just works".
The problems, as always, are that tools have learning curves and often need to be composed into more complex configurations to yield more powerful results. Whereas appliances, although they "just work", they work only for predictable and formulaic configurations that the appliance explicitly expects, and proceed to break down and reveal their opaque innards when used for more esoteric or unusual situations.
In summary, the anti-systemd side wants to do things with their computer, and the pro-systemd side wants their computer to do things for them.
This is why there will never be a consensus. It's also why systemd opponents will often resort to stupidity like defending the messy hairball of SysV initscripts, while proponents will just casually look at unit file configuration being outwardly simpler and not think of the bigger picture.
Typically, you run servers for a company, the developers wrote a web application and the whole point of the server is to serve that app. You need init scripts to start, stop monitor this app. The choice of init system makes a big difference in your daily life.
* you can continue to use sysv init scripts with systemd
See item #4 on http://0pointer.de/blog/projects/the-biggest-myths.html
Because systemd isn't just an init system?...
From my experience what I need on a desktop is very different from what I need on a server. On a server I don't care about displays, keyboards, backlighting, sound, USB disks, mics, scanners etc. On my desktop they are very important. There are a number of companies offering Linux VPSes with 512 MB RAM and they can be good to host a low traffic web service. Good luck running a modern Linux DE on a 512 MB machine. Not impossibile but not very productive.
So I can imagine having very different init systems for desktops and servers if this means that the server won't be encumbered by a number subsystems which are of no use to it. Furthermore binaries instead of scripts and opaque log files leave a bad taste in my mouth. They make me figure a future with a Windows like event viewer to browse the log files, over a terminal based ssh connection. I'm quite concerned about it. It will waive one of the biggest advantages of a Linux server over a Windows one.
A fork, or an alternative init system, could be a good solution. We should run this experiment, pick what we like and don't harass the people on the other side. We will see the results after some years. The satisfaction of the admins will decree the winner.
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 to try it before deciding it's something you won't find useful.
Avoiding it looks like it's going to be significant effort and you'd want to know for sure that you're justified in that before embarking on that course of action.
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.
* it automatically cares about starting it
* it automatically puts the programs stdout into the journal (from which I can filter the output of my specific program without having to syslog() everything)
* it allows me to run the program as user with one line in the INI unit file
* it allows to make the users home directory read-only (or even inaccessible), so in case someone takes over, there is only so much they can break
* it can create a private /tmp for my program
Given that targeting sysvinit for all the various sysvinit-compatible systems out there can be an exercise in frustration (OpenRC, Debian, the *BSDs, all of whom have subtly different flavors for starting and stopping processes) better left to individual maintainers, it's nice that I can write a unit file and pretty much have it work on any system that's running systemd.
[1] I'm aware that some people might argue additional complexity doesn't belong in an init. That's fine. You're probably right.
Yet the oddly amusing part is how systemd isn't difficult to learn. The only valid complaint against systemd IMO is its departure from Unix philosophy, but for some parts of the nix ecosystem, I can't help but think that boat sailed long ago.
I was hugely resistant to systemd when Arch first switched, but I learned to appreciate it (the simplicity of unit files won me over). This came about a year and a half into my journey with Arch Linux when I was still learning that the easiest way to use the distribution isn't to fret over change but to embrace it. Otherwise you'll be implementing fragile workarounds that break every time you update.
Though, journalctl still annoys me.
Sure, I can understand some of the hate directed to systemd simply on the merit that it does* do things differently--but it's hard to believe that the vitriol and insults from the anti-systemd camp are likely to help anyone's cause.
Personally, I like it, it works, I've not encountered the stability issues or other bits of weirdness some folks seem to insist regularly occurs (maybe it's distro-specific), but I'm also OK with being a statistical outlier. Or perhaps the anti-systemd crowd is disproportionately noisy.
This is what I say when people complain that systemd "isn't Unix". Neither are package managers, but I don't see anybody saying we should revert to passing around tarballs that unpack onto root (other than Patrick Volkerding).
> [...] the easiest way to use the distribution isn't to fret over change but to embrace it. Otherwise you'll be implementing fragile workarounds that break every time you update.
I'm thinking about putting together a talk about exactly this, tentatively titled "MacGyver-Driven Development". It's my response to people who respond to any criticism with "Yeah, but then you can just put some tools on top of it": relying on tools only adds another dependency that makes your system more fragile and resistant to change.
The proper way to develop is to keep what you do as small and environment-agnostic as possible. That way, when tides do change, you don't have to fight them or work hard to embrace them; you can just go with the flow, and just change the few parts that touched the changing dependency.
Even if this claim were actually true -- what's wrong about that? Why should someone move to a new immature system if his current one works perfectly for him? If an Apache server works perfectly for me why should I invest time and effort to switch to nginx just to get the same thing?
I consider a fork a good idea because it would split Debian development into a safe area of old-fashioned reliable technology, and a testing area of new technologies like systemd. If those new technologies have proven their reliability _then_ the moment has come to think about exchanging old stuff. It is too risky to throw a reliable system overboard and to force all people into an immature new technology.
I wonder what's the problem with the systemd proponents. If other people prefer SystemV why don't they simply let them go?
You are free to fork Debian and modify it as you wish.
Torvalds is likely to require you to hammer out all the details and debugging in a separate tree. This even more so if it is replacing a tested, stable and maintained subsystem.
As such, it is the Systemd proponents that should be doing a fork. And run it alongside stable for a time to demonstrate that it works. Then people can move over at their own pace.
Binary log files are as easy to read as ASCII with the right translator. Tagged binary formats are easily and trivially self-describing, and as resistant to corruption as ASCII.
The problem is, people think they'll be able to understand corrupt ASCII logs, but in reality basically never deal with them. They deal with truncated logs - which, well guess what, can be handled just as easily as for binary logs.
Given that journald can be configured with a log size of 0, and to output everything straight to syslog, this is such a non-complaint it's absurd. Especially when the hot thing in syslog management is usually to stream everything into a database of some kind to make it easy to search!
EDIT: Oh yeah, and this is assuming you're not compressing your logs. Which you probably are. In which case, they're already a very complicated, very corruptible non-binary format for which you have to use a fairly complicated read app (zcat) to access.
The advantage of human-readable logs is that the semantics and rules of the language it's written in serve as a built-in forward error-correction measure. It's easy to see that the string "the qu()&!`8zwn fox jumps over the la" is a corruption and truncation of "the quick brown fox jumps over the lazy old dog", especially if you're already used to seeing the original string under normal operation. By comparison, it's much harder to tell whether or not an arbitrary byte string is corrupt, and journald does not make use of any forward error-correction measures to assist in this.
> Given that journald can be configured with a log size of 0, and to output everything straight to syslog, this is such a non-complaint it's absurd.
If I'm using journald in this configuration, then why does journald need to exist at all? It's literally dead weight, and adds another point of failure to my logging facility.
> EDIT: Oh yeah, and this is assuming you're not compressing your logs. Which you probably are. In which case, they're already a very complicated, very corruptible non-binary format for which you have to use a fairly complicated read app (zcat) to access.
When compressed log corruption recovery is a concern, tools like parchive [1] are used instead of gzip/zcat.
It's more of an issue with whatever is written to disk by running processes. As you point out, it's debatable whether or not unicode/ascii vs "binary" is a sensible distinction ... I'd say taking a hex-editor to a mangled but mostly ascii text file is easier than some (any) binary format, but perhaps you know of some easy-to-use tool that will take a file-description and give you back data? Things like figuring out integer encoding and offset for timestamps across different files etc... is much easier with a rather redundant ascii timestamp than some binary number?
If your filesytem eats your files... well then that's a different problem.
So any tool which can read a journald journal can happily do so until it hits hard corruption - which is about as well as you ever do with syslog. I'll gladly trade an unlikely and really narrow recovery profile, for smaller, easily machine readable, well-defined log files (in the sense that, to write an entry, someone wrote down the exact struct somewhere, and had to keep using it that way. No regex's which fail in some case which happens once every 1 million lines of log file). Especially since the compatibility layer is just "forward text logs to syslog".
Reference: http://www.freedesktop.org/wiki/Software/systemd/journal-fil...
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.
However regarding servers I agree with the Unix veterans that Unix(-like) systems should be faithful to the KISS philosophy which made Unix so great. The IT world has become very complex, and we should not make it more complex than necessary. Debian and its derived distris took over the server world, and (AFAIK) it accomplished that with SystemV not with systemd. So SystemV is not that bad.
Unit files are surprisingly powerful and simple and follow KISS quite well (they're easier to maintain). systemd is also not quite as monolithic as some are wont to believe.
> Debian and its derived distris took over the server world, and (AFAIK) it accomplished that with SystemV not with systemd. So SystemV is not that bad.
This just seems disingenuous. It's almost like arguing we didn't need nginx because the web server market was won by Apache, not nginx.
systemd has its warts, I won't deny that, but it seems that most of those opposed to it are opposed strictly on the merit that it's new and different.
So I can imagine having very different init systems for desktops and servers if this means that the server won't be encumbered by a number subsystems which are of no use to it.
systemd is about choice ;-) Only use the subsystems that you need. For example, if you'd want to save some memory and time, you could use systemd-networkd instead of shell scripts and dhclient.
systemd is used in constrained environments like phones and embedded systems because it's fast and solves problems (e.g. watchdog chaining).
Manifestly described by the idea that people without time to interact with Debian, are going to instead launch their own Linux distro.
The whole point of free licenses is to let half educated monkeys type away on keyboards because every so often you end up with Apache or Linux out of it, of course you also get pulse-audio and systemd but no system is perfect. If people like it more than Debian it will replace Debian, like Ubuntu nearly did before they went with unity and a whole bunch of other terrible decisions, if they don't it will die, and if it sticks around as a project with some users, like every other debian derivative, it will be a wonderful resource to find bugs.
But people who want to take part in a debate should expect be held to account for the things they say, and in the case of systemd a lot of people are spreading a lot of misinformation. That's forgivable, I make stupid mistakes and misremember things all the time, but it's sure starting to seem like there's a very casual disregard for the truth and with it, any possibility of solid debate.
Not to mention the usual crowd of trolls who are just happy to have something that'll start an argument.
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
#!/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
Besides all the sysvinit alternatives (like depinit) that have popped up throughout the years, fixed most of its deficiencies and were promptly ignored, even having a shell-based boot doesn't mean you need to resort to the antipatterns that Linux distros have been doing - look at what the BSDs do with /etc/rc.subr and rcorder(8). Though, to some extent, this can be blamed on sysvinit's flawed abstractions.
If anything, making a "systemd or sysvinit" dichotomy only tells me you're unknowledgeable.
Debian used a really open process to decide the new default init system where every developer could propose any init system provided that someone offered to maintain it.
Since SysVinit, systemd and Upstart where the only ones with a credible maintainership (OpenRC didn't work on Debian until a few week after the discussion started) the discussion was centered on those three.
So it's not like other init system were ignored, it's just that noone bothered to do the actual work to make them suitable replacements.
My hypothesis is that systemd was the first to provide enough benefits to motivate people to implement the switch in Debian.
From a distribution maintainer the fact that systemd tackles many loosely related problems is an actual benefit, since now said maintainer just need to coordinate with an upstream project instead of having to maintain dozens of special snowflake systems (eg. to set the hostname). This is what most systemd critics fail to accept.
Oh, and the shell is nice but it's one of the worst languages to implement anything non-trivial, http://www.dwheeler.com/essays/filenames-in-shell.html is enough for me welcome the idea of getting rid of it in the boot process. :)
What? Systemd will only handle the starting and stopping of services. How's that doing more than one thing?
This seems to me a technically better solution.
... systemv sucks enough that I'm in the middle of re-working our firmware at work to use systemd instead (I do like socket activation and supervisor stuff), but of all the systemd features one could like, "do one thing and do it well" isn't one of them.
you don't need to use systemd-networkd, it's a separate program - but it's better than debians /etc/network/intefaces adn RH /etc/sysconfig/network-scripts/if* - so I do welcome the consolidation it'll bring to distros.
you can still run normal cron you don't need to run the kms console daemon either
http://svnweb.freebsd.org/base/releng/10.1/etc/rc.d/inetd?re...
http://svnweb.freebsd.org/base/releng/10.1/etc/rc.d/power_pr...
so what?
Also: Usage: $0 [0x00|0x01]. That is the real unix way these people is proposing.
The idea is that rcNG makes things simple, but it doesn't stand on your way if you want something more complex or in this case you want to make it harder to use than it needs to be.
(you can't - it doesn't take custom EXEC commands)
Sure it does! It's a belt-and-suspenders approach that ensures that human error won't cause your system services to become unavailable. Why use a computer unless it automates tedious tasks for you and remembers to do things that you might forget?
The Gentoo OpenRC BIND 9 init script runs named-checkconf every time you try to start or stop the BIND service or reload its configuration files.
This automatic check has saved me a bunch of time and mental overhead over the years. The auto-check has also prevented some downtime when I -inevitably- fat-fingered something in a config file.
If it doesn't do this automatically, there's still the option of adding the configtest in the ExecStartPre option.
And that blob is going to be harder to debug, never mind fix, on a production system. While your manager is breathing down your neck about getting it back up ASAP.
http://www.freedesktop.org/software/systemd/man/systemd.serv... and http://www.freedesktop.org/software/systemd/man/systemd.unit...
After a lot of years of maintaining and editing and writing configuration files for more Linux daemons and applications than I can remember, my least favorite are the ones like the top example, that have a pile of predicates and values. They require careful reading of documentation to look for any traps and gotchas (the documentation always has a fine print section buried deep within it somewhere that says, "oh, by the way, you can't foo with a bar setting because that will cause a baz to foom"). You have to either memorize a bunch of variables specific to a single application, for a ton of applications, or you have to spend time referencing documentation (and re-reading it for those gotchas) every time you open the config file. There's also the nuisance of new predicates in later versions, hidden and undocumented predicates, and on and on.
It's just a pain in the ass. Really, as much as I love Postfix otherwise, it is the poster child for why this approach sucks monkey. Here's the documentation for Postfix: http://www.postfix.org/documentation.html ... let me know when you've read and understood all of it. :-)
But the sysvinit file on the other hand is easy. It looks uglier, but only to people that aren't accustomed to shell scripts. I can take one look at it and know what most of it does, because all other shell scripts do similar things.
And here's the best part! If the shell script seems to be broken for some reason, I can debug it! I can stuff some stdout or stderr in there; I can call my own binaries or reference other shell scripts; I can do programmer-y things to it!
The default response here is usually, "well, we'll just keep the configuration file simple then." But that never happens. I would bet a donut that, years and years ago, some Postfix developer said, "the sendmail configuration system sucks, we'll do our own, and we'll just make sure it stays simple."
But software never gets simpler. It's a steadfast law, a more universal rule of reality than the arrow of time. Software only moves in one direction, and that's towards more complexity. The safe bet is that ten years from now, those systemd configuration predicates will have exploded 10-fold, with lots of hairy edge cases and gotchas and hidden or poorly documented interactions, because that's what always happens. A shell script on the other hand will still be editable; the Apache sysvinit script you posted doesn't do anything that a shell script couldn't do 15 years ago.
I'm really beginning to think this whole systemd thing is actually a culture war between two different generations of sysadmins. The older, bearded generation wants to stay with the thing that has always worked out for them in the end, and the younger, nicer-smelling generation wants to do something new because they haven't made enough mistakes yet.
[Unit]
Description=A network traffic probe similar to the UNIX top command
Requires=network.target
ConditionPathExists=/var/lib/ntop/ntop_pw.db
After=syslog.target network.target
[Service]
Environment=LANG=C
ExecStart=/usr/bin/ntop -i eth0 -w 3000
Type=simple
StandardError=syslog
[Install]
WantedBy=multi-user.target
> And here's the best part! If the shell script seems to be broken for some reason, I can debug it! I can stuff some stdout or stderr in there; I can call my own binaries or reference other shell scripts; I can do programmer-y things to it!
systemd captures stdout/stderr and the exit code you rarely need to run it outside of systemd. Most of the time the ExecStart command would do the trick.
> I'm really beginning to think this whole systemd thing is actually a culture war between two different generations of sysadmins. The older, bearded generation wants to stay with the thing that has always worked out for them in the end, and the younger, nicer-smelling generation wants to do something new because they haven't made enough mistakes yet.
Or alternatively they've seen the millions of issues you can get with sysvinit scripts that aren't perfect and decided we can do something better.
For my custom processes I've ripped out all the chroot, fork, and setuid code added in a couple lines for systemd watchdog and status support calls. I'm not going back.
Granted, journalctl with a filter is longer to type than cat. Someday I'll add nice alias to my shell rc.
No. I even gave a talk about how I came around to liking it at linux.conf.au this year. And I am a veteran *ix sysadmin.
Something I have noticed is that most of the loudest anti-voices have no actual technical arguments against it, and generally haven't even run a system with it for a month; you can tell because so many of them clearly don't even know the most basic syntax.
It is a great compromise between a shell script and a configuration file.
Here is example of a simple use:
http://svnweb.freebsd.org/base/releng/10.1/etc/rc.d/bsnmpd?r...
But when you need more control, you still got it:
http://svnweb.freebsd.org/base/releng/10.1/etc/rc.d/motd?rev...
Using the same argument, forking would seem like a horrible idea if there isn't active maintainers.
If a fork would reduce the time spent arguing about the init system (which 99% of users don't care about), it could even prove beneficial for Debian.
[It seems unlikely the fork would attract the critical mass of devs/users to succeed on its own though.]
But a switch to a different init system shouldn't break your system so badly that it no longer boots. And yet that's what happens if you rely on keyscript to unlock your drives in /etc/crypttab.
Apparently the answer is to write a different custom C program for every possible permutation of obtaining key material to feed to cryptsetup: http://lists.freedesktop.org/archives/systemd-devel/2014-Aug...
... which is somehow more clean than a 4 line keyscript.
... and certainly lends credence to the idea that systemd just isn't unixy.
cryptopts=source=/dev/<disk>,target=sdc5_crypt,keyscript=/lib/cryptsetup/scripts/passdev,key=/dev/<other_disk>:/somdir/root.key
Anf then in /etc/fstab use the /dev/mapper/<target> (sdc5_crypt in the example above) as the root device, as before.
Then you need to make sure the initramfs contains all the tools needed to support this (that was done automatically with /etc/crypttab, it's "manual" with the kernel option). To do this, add under /etc/initramfs-tools/hooks a script file to load what's needed in the initramfs: cryptsetup, passdev, the needed kernel module. You can roughly copy the existing /usr/share/initramfs-tools/hooks/cryptroot and simplify it.
I've seen other distro documenting the kernel approach instead of /etc/crypttab for the root filesystem. It may become the standard way in the future, and there's no reason it couldn't be fully automated. There's some coordination between several components so it may take a bit of time to converge to an accepted and supported way thought.
The fact remains though that a wheezy dist-upgrade is going to ruin your day badly enough to spend some time digging up your iDRAC/whatever creds (admittedly, nobody is going to dist-upgrade their prod servers without testing first... or are they? :P)
Only in the future it may use kdbus for some purposes (eg. uploading firmware blobs), but this will only affect internal interfaces.
On the other hand, systemd does not require the D-Bus daemon when you're launching systemctl it as root, the D-Bus daemon is only needed to route the call when used by unprivileged users. When used as root, systemctl connects to the PID1 socket directly and D-Bus is basically just a serialization protocol (and systemd does not depend on libdbus either).
To be fair, udev communicates with the kernel via netlink. All the userspace notifications are done via dbus. So dbus was already part of the equation whether people realize it or not.
I gave a cursory glance to the systemd/src/udev files and found no mention of dbus.
You mentioned smart cards... what system would handle when you connect a smart card after boot?
By default nothing happens when you insert a smartcard; if the keyscript tries to run without the smartcard it will retry, timeout, and eventually fall back to askpass. If there's a LUKS keyslot with a backup passphrase which can be entered by a human operator at the tty, this also serves as a disaster-recovery mechanism so that you can afford to lose the LUKS keyslot associated with the token/smart card.
I'm sorry. I wasn't clear. I was asking about the work that gets you to the point where the volume appears. You don't necessarily have a device file for the volume, so something needs to be ready to handle that logic when the device is inserted, then when it has figured that out, you have to notify the automounter that it is time to go to work (or not), etc.
Now add logic so that all of this magically gets powered down all the time to conserve power (and then figure out what you do with the filesystem when that happens).
Now handle the case where you have a bad connection so it is constantly flapping as inserted & not.
Now handle the case where it gets ripped out with no warning.
Now handle the case where you have a smartcard and you are using it to provide the key to decrypt another smartcard...
I also do appreciate the systemd features for mobile and desktop devices.
But the sysvinit mechanisms aren't rendered completely irrelevant by systemd; the sheer stupid dumb luck of the the thing is actually deterministic and repeatable in my experience. systemd migrations have exposed hidden dependencies I hadn't previously had to worry about between services, which is good in one way, but not necessarily good in other ways (transient intermittent failures which never occurred under sysv).
Yes, it's unfair to blame systemd for poorly defined services - I do like the concept systemd is offering in that respect. But if I have servers in the rack which have smart cards in them that I know are always attached except for very rare events where a sysadmin will be dealing with things, I don't think there's harm in a 4-line shell script failing maybe once or twice in a server's lifetime if it means not having to maintain bespoke C programs for years and years
Racy code has issues with race conditions. Any error in setuid executables can be very dangerous, so they are strongly discouraged. However, once you've decided that you have to write a setuid program, there's no particular reason to not write it in a scripting language.
As a datapoint, the KDE folks think that using scripting languages for setuid executables is okay:
/usr/lib/kde4/libexec/fileshareset: setuid Perl script, ASCII text executable
This isn't even remotely controversial. There is a reason that the setuid bit is ignored for unix shell scripts.
The pro-systemd brigade only seems to be a small minority of Debian devs (though they're extremely loud, and trollishly persistent).
I've thought for a long time that they must have a place where they all hang out in secret and share links to discussions where they need a pro-systemd response / a handful of downvotes.
In this way they give the impression that their numbers are much larger (the reasoning here is that for any given post or discussion, if the number of "ambient" / "organic" critical comments or downvotes that it receives is a proxy for how critical the community at large is, so by sharing links they make it seem like there's a broad base of support for systemd).
This kind of thing seems to happen periodically, where a person / group of people railroads a decision using methods that are outside the "accepted" set of methods for OSS development, namely meritocratic discussions.
Who knows what their motivations are. It probably varies per person. Having "I designed and implemented a new init system and got all the major distributions to adopt it" on a resume is a huge demonstration of "impact", which is something that really pays off in a lot of companies / organizations.
"Impact" isn't always "progress", though.
And generally more convincing, probably due to actually understanding both sides under debate.
There's a whole lot of "I don't/do like it" and "It did/didn't work for me" but not a lot of explanation of why they do or don't like it, or what didn't work, and I'm interested in those details.
Yes I want a better init system and process manager setup. But personally, I'm not sure that goal is worth losing Unix distro compatibility.
I would love a system that works the same across OSX, BSD's, Illumos and other newer experimental OS's etc.
It's all a bit overdramatic anyway - there are heaps of Debian forks; they're called 'downstream distros'. Ubuntu is one.
Probably because they (experienced Unix veterans) realized that it makes much more sense to test the demand of a fork (that's what they made the website for) than to continue any useless discussion about systemd. Some systemd proponents obviously have serious problems to make a sober discussion anyway (interestingly also in a prominent German forum).
Notice: "If SystemD will be substituting SystemV in Debian, we will fork the project and create a new distro: Pure Debian by Veteran Unix Admins. We hope this won't be necessary, but we are well prepared for it."
They are not eager to make a fork but I think they will actually do it if necesary.
Until I saw that line, I was thinking: well quit talking about doing it, and just do it!
The idea of a non-systemd distribution in general is something I've been expecting to pop up for a while. And if the vocal people online represent a real desire not to switch, then one really should exist. Beyond that I'm rather uninterested in such a project one way or another.
The trouble here is that the bulk of the work is just maintaining a changeset to debian packages. They haven't even spun up dak and friends, so I'm assuming this is DOA for now. It seems like a lot of hot air to pressure debian, or at the least attract contributions that can maintain their fork. Is "fork" a scary word to any DD, considering debian is already the upstream distribution for other, more popular, derivatives?
There's already plenty of them.
The author is essentially making a threat, that there will be a fork of Debian if the project does not give in to his demands. Then he states that he is totally not just speaking for himself, but for a much larger group, and in fact claims to have the majority on his side. I have a hard time evaluating the seriousness of these claims, as there is no intend to back up any of this.
As far as the arguments go, there is nothing new here. The concerns have been stated before, and have been heard, too.
I find it very difficult to get behind a movement whose primary complains are that the status quo is "a slap in the face to the _____ philosophy" and "betrays the _____ philosophy" and so on. If you want to sway me, you have to tell me why your way is better. The alternative is "offensive" to you? I cannot begin to describe how much I don't care. You can tell a lot about a movement by those they stand with, and you've listed your them as "Harbinger of the Linux Apocalypse", a boycott, and finally something that does nothing but mock those it disagrees with. I mean you may be bringing up valid points but curb the drama, eh?
So I'm all for a fork. That is the point of open source, no? Go on and make a fork and if it's awesome people will use it, otherwise people won't. And maybe then we can curtail the endless arguments about this in Debian. But in spite of the title this article, it really didn't read like it was asking if we should fork Debian. It read like it was asking people to pressure Debian to follow the authors' agendas, with a threat (?) of making a fork if it didn't.
This. The point of this site seems to be the author begging Debian not to make him fork, because that would be such an imposition on him. It's the same threat as a child threatening to run away from home (except that parents have a reason to care about their child's life).
In light of that, forking is a more civilised approach than bullying and threatening the author.
Yes, but it is sad that the more straightforward approach of contributing back to the community isn't taking hold.
If you are worried about mission creep... you help stamp out a very clear mission. If you are worried about bloat, you contribute patches. If you are worried about a nasty hairball... you contribute code reviews. If you consider C code less readable than Unix shell... please don't reference the Unix Philosophy as the principle behind that thinking.
This is the talk you mean right? Have you actually seen the talk? Yes, Lennart interrupts the talk but everything he says is correct, while the presenter just spreads random FUD.
The presenter clearly shows that he doesn’t understand most of the stuff he talks about, talks about 3 year old bugs that already got fixed, etc.
Yes, it’s not the nicest way to interrupt a talk, but the presenter should have expected some kind of reaction, given the controversial headline.
People like Lennart put their heart into their software. If you shit all over it and spread random FUD, you can expect some response. What would you have done?
Also he doesn’t “take over the stage”. He comes up after the talk has ended, because people on IRC asked him to.
If someone talks shit, he should be challenged as soon as possible, preferably in front of the same crowd they are talking shit in front of. If you take the opportunity to talk in front of a lot of people, you should also take the responsibility to be properly prepared, and be ready to face the consequence of not performing adequately.
Let's get this straight: he's not on a soap box (a term that refers to people who shout at passers by on the street), but rather at a conference at which he was invited to speak. The audience came into the room to hear him give his talk. Lennart rudely interrupted this.
> I heard this argument before, there was an article about book reviews, and that authors who interacted with reviewers (by writing on their own blogs about them or on twitter) would be labeled Bad Behaving Author and be shunned by the review community.
That's not my argument at all. I specifically suggested he _should_ respond with a blog post. Don't put me in the same group as those people. I encourage anyone to share their views on their own blogs, in comment sections, and on Twitter.
> If someone talks shit, he should be challenged as soon as possible, preferably in front of the same crowd they are talking shit in front of.
I disagree that it is appropriate to interrupt and shout someone down just because you think they are "talking shit". The definition of "talking shit" is subjective. If someone is interrupted before they can make their point, then the observer does not have the ability to judge whether they are right or wrong. It instead becomes a matter of whoever has the best rhetorical tactics. (Or who can shout the loudest.)
My job involves giving a lot of talks, and if someone were to engage with me like this I _would_ be prepared: I'd be prepared to tell them to wait until I have finished my talk and address their comments afterward. This has happened many times, and it worked out fine for all involved. It's called civility.
I was actually there and the talk was so much better for this. Also, I don't think the Chaos Communication Congress is that much like a business conference. It is hackers and people who care about software, not so much for proper manners.
If I remember correctly, Lennart specifically came to the congress because there were rumors before that this talk will be bashing Lennarts software, so it was no surprise to see him show up.
IMO this is the attitude that encourages toxic behaviour in the open source community. Hackers should not be exempt from standards of civil discourse.
While at first I felt a bit sorry for him when I read that post, after I learned about what exactly was that "hitman threat" I lost any remaining respect to Poettering. That's just grabbing attention and playing victim. He deserves negative response for that.
Most people are already working on things that make them happy. The frustration here is that the tools they depend on are changing... in a way that they don't like.
They also have limited time for projects. Any time spent fixing other peoples projects is time they don't spend on their own projects.
I left the Linux desktop world nearly 10 years ago, for these kind of reasons. I use a Mac as my desktop, because I don't have to fight with it. 99% of everything works, and the other 1% breakages are ones I can live with.
Choice is widely regarded as actually making people more unhappy.
EDIT: It's also an ironic comment, since a frequent criticism of systemd is that it's trying to be too much like Apple's launchd.
My choice is to use a (mostly) closed system, because it meets my needs.
Other people don't like systemd because they feel it removes their choices.
There is no contradiction in the two approaches. There's also no irony.
If Unix had started out with something like systemd, fewer people would be complaining about it now. It's the change that people don't like. And the apparent removal of choice.
So there you are, happy with a radically non-traditional Unix environment (no X, launchd is one of the patterns systemd is copying, etc).
Absolutely, in that almost anything is. :)
But specifically, at this point I'd really welcome the anti-systemd ranters to just do some work that makes them feel happy, such as making a new distribution that has the exact init system they want.
I suspect that Debian would love for them to do that as well. Debian is in general welcoming of downstream distros since the downstream distros—if given proper care and feeding—often feed back useful improvements to Debian.
The problem here is that no one is actually doing a fork (yet). Some of the same loud, uninformed minority have just created a ranty web page that presents a skewed view of history and makes threats. It's just more of the same interminable mailing list snarks but in web page format.
Trying to put out and support an entire distribution may serve to broaden their minds as to the delicate position the distribution is in with regard to integrating upstream work into a coherent whole.
Sadly I'm not convinced that any enlightenment is going to be achieved because the people behind this web site admit that they haven't even got the time to become involved enough in Debian to have a vote, so I don't know where they're going to find the time to launch a non-toy distribution.
Not so convinced by this. "Those days are dead and gone and the eulogy was delivered by Perl." -- Rob Pike
Systemd in debian would have an easier time making friends if it didn't usurp PID1 for roles that are currently outside PID1, and if it didn't encourage software which is currently init-system agnostic to grow a dependency on a specific init-system implementation.
Like what exactly? This is a non issue. systemd has very little actually running in PID1.
Also, critique starts with "We like controlling the startup of the system with shell scripts that are readable".. How on earth is a systemd service file less readable then a hundreds of lines bash script?
Also relevant: http://www.itwire.com/business-it-news/open-source/65684-deb...
A admin needs to know a dozen languages and codes in bash most of the time, they have a hand written folder with glued in scraps next to their terminal which explains why they did what, how and why. This folder has entries like "reboot three times, do an rain dance and run godHelpYou.bash as root" because that's the only way that you've found out how the libraries actually talk to each other.
For people like this "do one thing and do it well" is the only way that you can beat the impossible complexity of a modern machine back into a running computer even some of the time. When you have a single point of failure which is a black box you're just back to windows land: restart the service, reboot the computer, reinstall the system.
From this point of view devs look like a tribe of monkeys building a shit pyramid over your village. They just keep flinging more shit at the top thinking they are the greatest ever monkeys. When the shit pyramid collapses and buries everything you know and love under a few meters of shit, probably killing someone in the process, these monkeys just shrug say a few words about how that was the best shit pyramid anyone had ever build and start making a new one one or two valleys over.
For the developers, on the other hand, it might mean that some use case that is important for the admin is simply not yet implemented. The solution, as so often, is... drumroll to report a bug! Developers care about their users. Just talk to them.
Also, admins should realize that "reducing complexity" is a goal that they share with the developers. systemd is all about reducing complexity by implementing functionality the right way, on the right layer. For example, with systemd it's way easier to write a daemon, because it takes care of
* daemonizing: just stay in foreground
* logging: just output to stdout/stderr. journald will collect everything, and if you want, forward it to a classic syslog service
* startup: no more shell scripts required, just a simple service file
* supervision: just add "Restart=on-failure" to your service file. It also supports software watchdogs.
If start-via-systemd doesn't work, hack around it with a script and report it as a bug or write to the mailing list.
An init system should have a verbose mode that tells you exactly what steps are being taken to start a service and what the result of each step is. Maybe this will come later, but -given the guy's history- it won't be written by Poettering.
Don't get me wrong, I love to bring out strace and will use it to solve all sorts of problems, but it really shouldn't be necessary use it near the start of troubleshooting.
And don't get me started on binary log files.
As was said before, buster, your attitude is the problem. It's the same as the systemd developers and those within the community.
SysVInit has served me thus far with no issues.
I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out.
took me some time to figure out it was systemd.
the firewall wrapper for iptables gives you an insecure default config and is hard to fix via config management "add a service that means port 3128 TCP, now allow incoming connections"
My config management system creates files and pushes them out, I'm not in the habit of running idempotent commands repeatedly.. I'd rather check if something is correct before correcting it.
Why on earth does it need to do that?
You should be laying down a base initial configuration at the time that the machine was provisioned. The basic example of this is the sudoers file. The default setup for Ubuntu/RHEL is different enough that it was causing problems and the solution was simple - force defaults.
Surely the systemd equivalent would be delving into the source code for dash, or god help you dash... I know which one I'd prefer--not that I've ever hard to do either, fortunately!
? You end up diving in to the service file vs. the script.
> And don't get me started on binary log files.
Having worked with binary and plaintext log data for the better part of a decade now, I have to say that pretty much the entire set of claimed advantages of plaintext log data is very wrong, and we've wasted a ton of productivity & efficiency because of it.
If you really are sure of its superiority though, just put a little stub in front that converts the binary log to a human readable format that still needs a program in order to present to the user...
> SysVInit has served me thus far with no issues.
Speaking of attitude... there are two ways to look at that datapoint...
That's a good thing, because if you find a bug, it will be fixed for everybody, not just for your one-off init script.
your attitude is the problem
The attitude here is to fix problems at their source. Instead of using the hammer for everything, sometimes coming up with a new tool is a better idea.
Generally I agree with this at a broad level. But, there is still the problem of: I need this running now. To do that, I need to compile and run a custom systemd, and hope that my patch gets accepted upstream, and that in a few months my distro finally adopts it and puts it in the standard package.
Generally speaking I really like systemd and am excited to get some time to update my installed stuff to use it, but the above is a real concern.
At the worst case though, this reduces systemd to a shim-launcher for SysV init, which is the situation you find yourself in now or when using Upstart, which tons of Ubuntu users already have been.
Have you tried adding "touch" commands in ExecStartPre/ExecStartPost? Systemd also gives you a hint of why something didn't start via "systemctl status $servicename".
FWIW systemctl start docker works fine after the system has booted. It's configured to require network.target, and even though I can see network target scroll by during boot, it's still not being noticed.
The work-around is to make multiuser want docker, then I've got docker starting at bootup.
Other symptoms that would indicate this was the problem would have been that 'systemctl status lxc-docker.serivce' would have said "Loaded: loaded (...; disabled)" and "Active: inactive (dead)". i.e., systemd never started the service because nothing ever wanted it.
Oh dear, that seems to be the case... https://github.com/docker/docker/commit/053c3557b3198466ecfb...
If you start a "normal" service using a command that double-forks and immediately exits (like a `--daemon` flag), systemd will see that the process has exited to mean that the service has finished, and will terminate any of its child processes (as you want runaway dependencies culled when a service crashes). This sounds like the behavior you describe.
Even the docker page tells you to use the docker package for Jessie: https://docs.docker.com/installation/debian/
Perhaps the sponsors of the linked site are doing bug reports on packages like systemd-shim and others. Perhaps the upstream project members involved are ensuring that they have init scripts for systemv available. They could add a question with links along those lines easily.
There may be some people opposed to systemd, but there have been votes that saw systemd as the clear winner for the default init system. Why should the majority of users who are FOR systemd bending to some users who don't like systemd out of some philosophical view? Instead of behaving like a little child, people can work on letting Debian run fine without systemd (which IS the fact today, i can simply switch between sysvinit and systemd just by installing a package).
And in the end, you should remind yourself that this is only about the default for one linux distribution. You will still be able to use sysvinit if you like. There is choice. The majority wants systemd. The minority wants sysvinit. Only because the opposers are loud and make a lot of noise about this doesn't change the fact that they are a relatively small number. Changing the default is the only sane thing to do.
Arch switched to systemd about a year ago. When official distro packages are shipping with systemd service files by default, it means there is drastically less effort required on your part to maintain a systemd-based environment. It would take an experienced and dedicated crew to translate the systemd service files of dozens of upstream packages to Runit for instance. The enterprise level support just isn't there, whereas with systemd it is.
That being said, I like writing systemd service files. I just wonder what would happen if more distros pushed for, e.g. uselessd or Runit as the standard init system.
> uselessd (the useless daemon, or the daemon that uses less... depending on your viewpoint) is a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism. Basically, it’s systemd with the superfluous stuff cut out, a (relatively) coherent idea of what it wants to be, support for non-glibc platforms and an approach that aims to minimize complicated design.
Bash scripts? Unless I'm really mistaken, startup scripts need to be written towards the POSIX shell. It's kind of like bash scripts except you pretend the year is 1985 and no bash versions released after that exists.
> […] it can be helpful to monitor and update the Wikipedia page about SystemD.
So they are basically suggesting to manipulate Wikipedia in order to paint a worse picture of systemd?
If someone wants to write another Ruby (or whatever programming language) implementation, would you bash her/him ? Would you say "leave me alone, I'm very happy with MRI" ?
- I think they're wrong about systemd, but if they're right, Debian can merge their fork back in, they can say "I told you so", and we can move on.
- It gives us a place to point the anti-systemd people. Rather than spending their energy trying to fight the system, they can spend their energy productively on this fork.
- This puts the burden of maintaining the SysV scripts on the fork, rather than the package maintainers, as it would be for Ian Jackson's proposal to maintain freedom of choice[1] Maintaining the scripts probably isn't hard for most; testing them probably would be. It would require maintainers to keep a SysV init system up and running on their machines.
1: https://lists.debian.org/debian-vote/2014/10/msg00001.html
It isn't necessarily an efficient allocation of resources, but open-source does not seek to achieve that: it values choice instead.
PS: I love the 'how long are your beards?' line. Obviously, I'd rather Debian didn't fork and that we kept choice for server people in one of the larger Linux distros just on an 'ecological diversity' basis.
You can do a window manager on top of X with systemv right now in Jessie [3], the '--no-install-recommends' option to apt-get is helpful. But the result will be seriously old-school. Its rather fun for surfing in cafes and wasting time on forums but for my day to day work (not programming) I prefer a full fat desktop like KDE/Gnome.
[1] https://lists.debian.org/debian-security-announce/2014/msg00...
[2] http://www.phoronix.com/scan.php?page=news_item&px=MTc4NTE
It may happen that systemd ends up being a good thing, or it may happen that something else takes the place that Debian and Red Hat currently occupy in the server space. That thing may very well be something other than Linux, and I don't care if it is anymore.
SysV init has many problems and can be improved upon, but solutions that increase complexity exponentially and are impossible to reason about when problems arise aren't the solution.
It worries me to see people justifying increased complexity pretenfing it matters for servers. Two examples:
1. I don't care how long my servers take to boot, that doesn't happen very often and when it does, who cares about cutting 30 seconds on the operating system side when the POST itself takes twice as long?
2. I don't care about too much hardware detection magic. Once a server is installed, at most it will get a memory upgrade sometime along the way, and replacement disks coming in and out of it will be transparently handled by the RAID controller. Most often it will just get scrapped in the exact same configuration it had on day one.
The systemd approach is not unlike the Windows approach. I've managed Windows servers for may years and I've also had to deal with at least an order of magnitude more boot issues that with SysV-like init systems.
Frankly the only bus i can see being much of a issue on desktop is USB. And that is mostly if you are relying on a ethernet dongle or similar that ended up moving from port 1 to port 2 between boots.
Yes, this means your desktop may not get connection until you sort out the new name of the port. But that is a niggle, not a world ending scenario that require the full replacement of everything between the kernel and the desktop environment.
All in all, systemd looks like a solution in search of a problem. And if it has remained Poettering's personal project and distro variant i don't think many would have raised a stink (and those that found it interesting would have adopted it on their own time).
Or even multi-user desktops. Or removable storage.
In Linux, everything got a lot better when we added udev - which gave us event driven mounts. And then we wrote a bunch of hacks to make sysV init minimally event driven enough to properly wait for it to finish it's work.
systemd simply dispenses with the fiction that SysV init is in anyway actually suitable for bringing up a modern computer, and replaces it with centralization of what we now know are the actual, useful services pretty much all modern computers need to provide. Even embedded systems are likely to be using network mounted and accessible storage.
If there’s anything this debate shows me, it’s that people have VERY different experiences with SysV init.
We could also move on from the accusations of "betraying the Unix philosophy". You know what else is the Unix philosophy? User-based security model. Fixed-length strings without overflow checks. World-readable passwords, badly hashed. Unencrypted remote shell with host-based trust. Maybe systemd is good, maybe systemd is bad, but accusing it of merely changing things is not a valid argument.
Onto debianfork.org ... if history is any indication, naming it Pure Debian is only going to cause a world of pain for everyone. Forkers really need to stop trying to name their projects $superiorAdjective $projectName. That's never going to go over well with $projectName.
And if they do fork Debian, I sure hope they don't set the default UI font to Georgia 40. (I know it adapts to browser width. I don't like setting my browser to 200px width to read a webpage comfortably.)
And that's the issue. See my earlier comments:
No. IMHO Debian is less a distro than a democratic experiment - and systemd shows it is working. If you don't like systemd (and I vastly prefer my FreeBSD world) get on board with the democratic process - it is always messy, frustrating, driving you insane slow. That's how you can tell it is working
Don't fork.
Edit: Matthew Vaughn is an actor not a Dev.
They can't even spell things correctly. It's System V instead of SystemV and systemd instead of SystemD
> only few of us have the time and patience to interact with Debian on a voluntary basis.
But a fork is less work I guess?
> Pure Debian by Veteran Unix Admins
Pretty funny thing to say as GNU and Linux are pretty un-unixy to begin with.
They link to mobile wikipedia
"Unless you meet our demands, we shall fork".
More like
"You gotta do what I say, or I am going to scream shout and bang my hands against the wall for a while".
or
"Please someone, fork Debian in the way we want it, and spend your time and energy maintaining it, because we cant be bothered to".
Also, disagreeing with the direction of Debian is not a risky move. Why not sign your names to it? Is this again because you wish to avoid any personal responsibility and work?. If you are well known in the Unix/Linux/Oss community signing your name would give weight to the hissyfit.
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.
This I can't wrap my head around, why does Gnome for example need systemd? There are standard ways on GNU/Linux to do everything it needs in a unix fashion (by deferring to small specialized tools):
shutdown
reboot
whoami
uname
mount
...
Here's a good summary of the issue: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...
A bad thing about systemd and where we are now is the ever-changing API that is mentioned, which hampers alternatives to systemd.
But, that is where we are now, Debian isn't in much of a position to change that, and forking probably isn't going to help with that. Debian wasn't ignorant of that either; these issues were discussed at length in the tech committee debate that originally settled on systemd being the default for jessie.
It's big, gnarly, essentially undocumented, and contains a bunch of features to support tricky cases like multiseat machines (systems with two or more sets of keyboard, mouse and monitor, each with a different user) that are rarely used but still need to be supported because the API's designed around them. Even the systemd developers don't think a reimplementation is feasible.
http://dvdhrm.wordpress.com/2013/08/24/session-management-on...
http://dvdhrm.wordpress.com/2013/08/24/how-vt-switching-work...
http://dvdhrm.wordpress.com/2013/08/25/sane-session-switchin...
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.
1) No desktop features are of any interest to me.
2) My position is between "that sucks" and "ambivalent"
But I do think that going with the flow is a much easier way. This isn’t a fight worth fighting if your concern is maintaining running systems. Of course it might be worth while to stay on an LTS release till the very last moment, to let all the bugs shake out.
Postgres and Apache? Seriously?
But when systemd is the default init system on almost every Linux distribution, new software will have the systemd integration written first and tested most.
[1] http://fedoraproject.org/wiki/Server/Product_Requirements_Do...
[2] https://fedoraproject.org/wiki/Cloud/Cloud_PRD?rd=Cloud_PRD
I'd be running it on my desktops. All I need is a way to spawn chromium and emacs and consoles (I like konsole, but if it drags in too many dependencies I'll put something else on).
If/When chromium depends on systemd (WTF, a web browser / page renderer logically SHOULD depend on your init system, of course) then I'll use another browser... somehow.
Elias Probst:
"Reading the comments shows a lot of misconceptions about +Martin Gräßlin's proposal [to use systemd features to make Plasma startup under Wayland a little bit simpler]:
* KDE SC will still allow to use the old-way to startup a KDE session, as it will still ship the X11-way of doing it for [BSDs]. If you want to use a modern Wayland/systemd stack you're fine by using the defaults. If you don't want to: use the old X11/script startup stack.
* KDE SC won't enforce using systemd as init-system by this change. Instead, it will use parts of systemd which are completely independent from the init-system being used to handle the startup of the KDE session. If systemd is being used as an init-system, that's a plus because of some systemd integration effects, but that's all about it."
via: https://plus.google.com/+MartinGr%C3%A4%C3%9Flin/posts/GMtZr...
[0] http://mail.kde.org/pipermail/kde-windows/2014-October/threa... [1] http://mail.kde.org/pipermail/kde-mac/2014-October/thread.ht...
Yes, really.
So I went searching, and found this Page. It probably isn't complete, and probably comes at this from a single perspective though. http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems
I am interested in any other comparisons that you believe is a good representation of both sides. I just want to fully understand the two before making a choice.
Edit: Removed references to there only being 2 options, there are multiple init systems.
Edit: Additional comparison from the perspective of someone involved with Systemd - http://0pointer.de/blog/projects/why.html
and
A Unix.StackExchange question asking the same thing with a variety of answers. http://unix.stackexchange.com/questions/5877/what-are-the-pr...
Go read the arguments, there are many reasons why they decided to switch. A big part of it is that Gnome/KDE and other upstream software is already dependent on systemd, so keeping SysV means extra effort to fix that.
C is very insecure for daemon coding with all other options why no use go for example?
What do you think the current init system is written in? That's not a reason to keep sysv.
What's sysvinit written in?
What are bash and dash written in?
What are coreutils written in?
(inb4 someone says "assembly/ELF")
* These folks seem clueless. The cite Eric Raymond. Enough said.
* I like classic init. I'm actually not a big fan of systemd, but I clearly recognize something needs to be replaced. The system needs to handle parallelism and dependencies. It's essentially the same problem in a hundred different domains (from luigi, to things like make/ant/paver/rake, to things like supervisord). Each systems seems to solve it worse than the one before it.
Personally, I'd actually go with forking make, since it's the one everyone knows and the most Unix-y, modify it to:
* Handle long-running task and task restarts
* Handle parallelism
* Clean up some of the issues around modularity
I don't care what init system is used. I care about a GUI workstation experience.
This whole UNIX experience is long lost in GNU/Linux distributions.
Just go out and install an Aix, HP-UX, Solaris, Tru64, DG/UX... system and see what the real UNIX experience looks like.
It was a kind of pun to state my disaproval to level of fragmentation the linux community has gotten into.
Okay this SystemD saga might or might be AS important as some people tend to think. But fragmenting the community so much and having people working to 10 different, unstable solutions instead of 3 stable ones, its a waste of resources IMHO.
Isn't it possible to do this with patches, similar to how the linux kernel has RT patches?
...are they trolling?
But I won't be surprised to see them come slinking back in four months with their tails tucked when nobody's actually maintaining any software for the fork.
Fork off and die.
p.s.: it's systemd, not SystemD.
Go ahead fork it.
I'm confident systemd will modernize Linux servers and desktops alike. And if by next year there is something better, systemd will be replaced.
Just take a look at device filessystems. Anyone remember devfsd? Let me cite wikipedia:
"While devfs was a step forward, it had several disadvantages of its own.[2] Since Linux version 2.5 devfs has been succeeded by udev."
Unfortunately people seem to have confused "this DEVFS implementation" with "The idea of DEVFS" and thrown the baby out with the bathwater.
For comparison FreeBSD has had DEVFS for 14 years and had a prototype for a good number of years before that.
And yes, I wrote that DEVFS for FreeBSD :-)
There are some fundamentally different and sometimes conflicting requirements regarding the startup process on a server and on a desktop machine and I think systemd which is obviously desktop driven will be the catalyst for a split between server and desktop distros.
I don't think classical desktop environments have much future personally, but that's just my gut feeling.
Server will definitely move further into modularization of services, and that will make init systems there less and less interesting.