Slashdot Mirror
Debian Talks About Systemd Once Again
An anonymous reader writes: A couple of months ago the technical committee for Debian decided in favor of systemd. This is now a subject for discussion once again, and Ian Jackson says he wants a general resolution, so every developer within the Debian project can decide. After a short time, the required amount of supporters was reached, and the discussion can start once again.
I've been a Debian user for 14 years now, please do the right thing and get rid of systemD.
I've been trying systemD on another machine for about a month now, it's not terrible but it's not all it's cracked up to be either.
The part that I don't like (besides it going against the unix philosophy) is how fast it's taking over before the majority of the Linux community even had a chance to have their say. And what really gets me is, if systemd was just an init system, fine. But at the rate they are going there is going to be a systemd everything.
More to the point, as with the System V vs BSD init debate, this'll further help to separate the UNIX-method distributions from the desktop, automagic ones.
I learned on Slack and at the time just about all of the books that I could find were UNIX admin books, not Linux admin books. With Slackware in the 2.0 kernel days this wasn't a problem; the kernel-specific stuff was really the only differentiator from regular UNIX-style admin.
I expect Desktop-oriented distributions to increasingly obfuscate things from the user, in the manner that MacOSX does. And for most users that'll work fine. For those that want to tinker under the hood, hopefully distributions like Debian will continue to allow for a more UNIX-like method of doing things.
Do not look into laser with remaining eye.
Debian's offering of Gnome 3 and Systemd are not comparable. Gnome 3 is only the default desktop for people who just want to click through the installer. But you can completely avoid Gnome 3, and indeed many people do because they do e.g. headless server installations or choose another GUI. Systemd, however, is spreading through so much of the system that it may not be possible to avoiding installing it. Even if one hangs on to sysvinit as one's init system, programs like Gimp on Debian now end up pulling in systemd libs.
maybe systemD will cause a Fork in the Debian distro,
i like Slackware too, maybe Slackian_Debware
Gentoo users will make a Debtoo
Politics is Treachery, Religion is Brainwashing
I could see why a desktop user might want to have such a thing as systemd (not me though), or someone with no admin skills having a canned all-in-one solution for their little business or hobby website.
But for where Linux dominates, server and embedded systems, I don't believe it fits into the Unix way of doing things and makes admin harder.
I personally would like to see it (and its evil compatriot, firewalld) as options.
In RHEL 7 and downstreams, you can choose between LVM2, standard partitioning, or btrfs as ways to carve up your disks. It would be nice to have systemd as an option, so for laptops where parallel starting of daemons makes a nice speed increase, it is useful. For a server where one doesn't want many changes to the underlying OS unless it is something to be tested, it can be an option. If one is using containers, maybe systemd might be useful to have.
There are changes to Linux like SELinux and AppArmor which are must haves. These add significantly to the security of the OS. systemd does add security... but not really that much. One can specify that a program run with ulimits and possibly in a container, but a wrapper can do the same thing, and one thing that I get concerned about is one program having so many moving parts that touch everything on the system, even perhaps the TTY functions.
is for me that it isn't interoperable. Please correct me when I'm wrong, but AFAIK systemd never did anything to create standards their new functionality is compatible with. Instead they only support linux APIs. I recognize that their needs exceed POSIX, but their current approach "lets make everything a hard dependency" is -to be polite- hacky. It doesn't have to be an official ISO standard, a simple document that ensures exchangeability of components inside systemd, and perhaps even makes systemd cross-platform.
> In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place.
I'm not even convinced that it makes for a better-functioning OS. I've been a Debian user for 12 years, mostly running 'testing' distributions. When systemd first turned up, I let it run for a couple of weeks, but switched back to sysV after half of my startup daemons didn't. Tried it again a month or two later, but when it had trouble stopping Samba (and, worse, claiming that it would wait *five* *minutes* before killing the processes, I decided enough was enough, and now I'm in the process of switching all five of my Debian boxes to Gentoo. Now, granted, the testing distribution is for just that purpose -- testing -- but if I'm dealing with the kind of idiot that would claim that systemd results in faster startups, but thinks that a five-minute wait to shut down a process is acceptable, then I want no part of it.
Debian should listen to what its users want, rather than just its developers. We're not all technically ignorant.
this goes against much of the traditional Linux spirit of small self-contained bits that can be swapped out at will.
In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place.
Personally, that principle of having many swappable self-contained bits is one of the worst qualities on UNIX.
I've been using GNU/Linux for over a decade. I know my way around most distros, and I can usually figure out what I need to do to accomplish any task... usually. The biggest problem I face now is that distros have so many small components doing their small tasks that figuring out exactly which component is responsible for a given task is no small feat.
I understand and appreciate the programming simplicity that a small component brings, but from a user's (or admin's) perspective, the operating environment is now more cluttered. As distros pick and choose their preferred swappable components, the view gets worse. Sure, I know exactly what the "finger" command does, but it's not obvious that "pinky" is an alternative, because having a lightweight finger command is apparently an important thing. Some distros will even create symlinks or scripts to provide alternative common names for their chosen packages, but there's seldom a guarantee that the input or output will be the same. This is why the first step of many build processes is to examine the environment and figure out exactly what is available on the system, often using methods that uncomfortably remind me of browser-detecting JavaScript.
I'm not saying that systemd is the solution we need, or even that it is a solution. I've just dealt with far too many poorly-named packages to have excessive reverence for this archaic principle.
We should also keep in mind that Linux itself, as a monolithic kernel, defies the concept. By design, the kernel's one job is to interface with every piece of hardware on the machine. Is it really so far out of line to define systemd's one job as interfacing with every service provider in the OS?
You do not have a moral or legal right to do absolutely anything you want.
Debian's offering of Gnome 3 and Systemd are not comparable. Gnome 3 is only the default desktop for people who just want to click through the installer.
It's also what everyone previously using gnome2 on squeeze would get on upgrade to wheezy or above.
A fork of gnome 2 did eventually make it back into debian but it wasn't in wheezy and you still have to manually remove all the gnome bits and replace them with their forks.
Even if one hangs on to sysvinit as one's init system, programs like Gimp on Debian now end up pulling in systemd libs.
Pulling in libs related to things you don't use isn't really anything new.
The bigger question IMO is to what extent will systems that don't use systemd as init be supported going forward? Will users of other init systems be treated as second-class citizens. When the technical comitee chose the default init system they refused to rule on this issue and it looks like the current GR is what this is about.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
utmp.
I agree its bad, and its something the unix community has moved away from and avoided, but its not so much "anti-unix" as "What unix did when it was a teenager and would rather we didn't talk about in public, especially not in front of its kids"
And...that is where binary logging should stay, until it can be eliminated entirely.
binary logging is bad mm'kay.
"I opened my eyes, and everything went dark again"
And...that is where binary logging should stay, until it can be eliminated entirely.
I don't even know why I'd care if systemd uses a binary representation internally, as long as it can give me human-readable logs with only text tools.
Only showing binary logs with systemd tools is a misfeature of the type "exposing the implementation". Userland requires a UI, and it's bad UI, and frankly bad Unix.
Now then, I hear you can somehow configure systemd to echo a copy of its logs to rsyslog. But, and maybe I'm just a fool with poor GoogleFu, but I tried for a couple hours to get this working and only found company for misery on the mailing lists.
If any systemd fans can point us to a quick-n-easy HOWTO on getting text [r]syslog working under systemd, then by all means shut a few of us up. Tell us how there's plenty of documentation too, we'll all hang our heads and wander away.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Hello,
I have deployed some fedora 20 machines in the last 3-4 months, and so far I did not see anything that led me to cry foul against systemd.
Actually, the handling of the user sessions for house-keeping purposes seems much simpler now.
So I don't get all this hate. Maybe I did not look deep enough, time will tell.
Cheers
Zed: Nothing is ever easy
good call. Then, instead of one distro that's 5 years out of date, we can have two distros that are ten years out of date.
But seriously, systemd sucks. I don't understand why people would take a good operating system (and this has happened with Windows (vista and 8), OSX (Yosemite), and GNU/Linux (gnome, systemd)) and ruin it for the sake of ruining it.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Yes. I look at systemd as being the opposite in what I want; I deal with mostly daemon-serving boxes that do special purpose tasks. Those boxes don't need GUIs, and outside of storage don't really even need plug-and-play. They need to be repairable on the console without ever gaining physical access to the box, and everything needs to be crystal-clear with the configurations.
Do not look into laser with remaining eye.
Actually, there is no problem with systemd as long as you can avoid it easily.The fanbois shall have their toy, I have no issue with that. But forcing it on everybody, even those that actually have a clue about good and reliable system design, is just wrong.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
systemd-journald has long been capable of forwarding the logs to rsyslogd. /var/run/journal, which gets deleted at each reboot.
And systemd-journald can even be configured to keep it's binary log in
And Debian uses this configuration for default.
Unfortunately, if they acknowledged this, systemd haters would be left with one less thing to hate.
Other functions provided by the systemd package (eg, session managment by systemd-logind) are just a lot of work to implement, specially if you try to go for a more decoupled architecture.
Not that people aren't working on it though.