Website tells users to switch to Slackware in protest of systemd
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
it's geared for UNIX on the whole, is Bash scripted, works with pre-existing sysvinit scripting
Two of those belong together (Bash and SysV) and one doesn't: is this yet another Linux-specific project that is conveniently ignoring the BSDs? (Yeah, I know its INIT we're talking about, but still...)
Otherwise, I'm all for this!
P.S. Forgive me for starting the SystemD flame war again a couple of weeks ago, I honestly didn't mean to. Next time I'll let someone else do it.
Interesting work that you're doing with the Runit init script. I think it is a great idea to provide more choices for distros. Nice work!
I only run Slackware and OpenBSD so systemd is not something I think too much about.
It is pretty simple, I see the reality. If your init system does not come up with the functionality of systemd, which is nowadays widely used, it can neither render systemd obsolete nor make it useless.
On the other hand if your init system does everything systemd does - it's not an init system anymore.
Quote:
If your init system does not provide an alternative for systemd-logind then no major distribution will use it.
And I will continue to not use them and we'll both be happy.
Quote:
Consolekit is deprecated and as it seems no one will take it up, it will just rot away, viable alternatives for systemd-logind are mandatory for KDE and Gnome, at the latest when Wayland comes to the major distributions, and so on.
Looking at http://www.freedesktop.org/software/...d.service.html I do not see anything I need, and certainly nothing my init system should ever concern itself with. And Wayland? Why would I care? Gnome is worse than windows, I really do not care at all what it 'requires' it affects me not at all. KDE is a little better but if they go down that road I can live without that just fine too.
Quote:
Of course Runit will work with the leaner DEs and all the WMs, but telling the people that it can make systemd obsolete or useless when it is obvious that it can't unless those problems are adressed (and for that matter, the same is true for OpenRC) is simply wrong.
Well if your 'systemd replacement' has to have the same design flaws as systemd you have put yourself in a corner. And why do you say it needs to be 'replaced' btw? That implies it's already part of the system which seems like surrender before even getting to the battlefield.
DEs and Wayland aren't even finalized yet, and so far their actual used libraries within the system are still only speculatory at best. The X.org developers, rest assured, are not going to just toss out a Wayland implementation that only caters to the lowest common denominator. They're going to offer a system that aims at everyone and everything.
Wayland is just a protocol, what the actual compositor depends on is fully up to the developers of that compositor. Weston, the reference compositor implementation from the Wayland/X.org guys, is dependent on systemd-logind (or better, its DBUS interface).
Quote:
As far as KDE. KDE can bloat itself to hell and back for all I care. I don't even use it. It's a nice DE but it's functionality is no more or less useful than any other DE or WM out there. If it sells it's soul to systemd, and becomes another GNOME, I could care less. There's Trinity, Mate, Xfce, etc. And GNOME's a lost cause as far as I'm concerned and I use it's software, but not it itself.
So replacing a gigantic and, according to its maintainer, hard to maintain Bash script with a few calls to a DBUS interface is "bloating itself, selling the soul to systemd and becoming another GNOME"? Interesting view, especially when one can see how OpenBSD developers just go the pragmatic way and implement a replacement for systemd-logind for their OS, which practically removes the systemd dependency.
Quote:
Being obsoleted doesn't mean something newer has to come along. As far as ConsoleKit, it's deprecated only by it's developers, same as HAL, but neither are truly deprecated, as neither have both been effectively replaced in complete functionality by another stand-alone project. Udev still can't handle HAL's DRM, and ConsoleKit only functions as a stand-alone alternative to logind which does the exact same thing, and HAL can still serve as the functional alternative for consolekit and logind both (and does on FreeBSD). You could easily say logind should have been more accurately named systemd-consolekit. Being obsoleted can be done not by newer, flashier, or actively developed projects. If the older stuff that's stable, still works, and works well can still function, and can actually work better with a broader spectrum of systems, that's still, in a way, making the newer stuff, kind of pointless in venture, henceforth, obsoleting it in point-of-view.
I am not sure if I can follow that train of thought. Of course consolekit is deprecated by the developers, who else should do it? And that it works now does not mean that it will still work tomorrow. It is simply unmaintained and no sane project should base on unmaintained software, regardless if there are no standalone replacements or if other, older and also unmaintained projects, still work.
Quote:
Originally Posted by Arkerless
Well if your 'systemd replacement' has to have the same design flaws as systemd you have put yourself in a corner. And why do you say it needs to be 'replaced' btw? That implies it's already part of the system which seems like surrender before even getting to the battlefield.
I don't quite see why offering the same DBUS interface indicates that the underlying system must have the same design flaws. And where did I say that the init system needs to be replaced? Fact is that more and more developers use systemd, regardless if I or you think that is a good or bad thing, so there is a de-facto replacement of sysvinit already. If I would think that the battle against systemd is lost I would surrender and use it. All I say is that the battle will be lost if there won't be an alternative as attractive to developers as systemd is.
Two of those belong together (Bash and SysV) and one doesn't: is this yet another Linux-specific project that is conveniently ignoring the BSDs? (Yeah, I know its INIT we're talking about, but still...)
Otherwise, I'm all for this!
P.S. Forgive me for starting the SystemD flame war again a couple of weeks ago, I honestly didn't mean to. Next time I'll let someone else do it.
Runit works with several flavors of UNIX, not just Linux. It supports booting the BSDs completely and works with OS-X and Solaris as a service manager.
And Weston isn't the only compositor that is geared to work with Wayland. There's KWin, Lipstick, Enlightenment 0.19, Mutter, Clayland, Mazecompositor, and SWC so there's going to be enough choices to go around when it's officially released.
If you guys want to help, just head over to LFS's section grab a copy of the BLFS-Bootscripts from the LFS website, extract it, and start converting the BLFS Bootscripts to Runit Run, Finish, and Log scripts. I'll go ahead and let you know, we shouldn't need anything but the sysvinit bootscripts. Scripts like dhcpcd and dhclient/dhcpd-server don't require Runit and work through the network script in Stage 1.
All stage 2 run scripts do require a run and finish script at least. The run script acts in place of the sysvinit start section and the finish script acts as the stop section. If a script only has a start section, please let us know so it's shutdown can be triggered during the stage 3 script, such ALSA.
The end result we're aiming for is a full and comprehensive script set that only requires a symlink to /service from /etc/sv to activate the daemon for service management, or delete to disable it. The Runit smarden webpage will give you any hints needed for how to link dependencies. This script set and installation will be easily universal to any Linux system upon completion, including Slackware.
Not really. Seems to be your standard, run-of-the-mill resistance to change, combined with some conspiracy, and a call to action.
sysvinit is great...but is it so great that it should be in place forever?
SystemD is OK. It gets some things right, it gets some things wrong (like binary-based log files). I'm pretty sure the kinks will get worked out, and in 15 years, us old-timers can put up a fuss about how SystemD is the best, and SystemX is eeeeeeevil!
There are a lot of interesting links on that website, including technical ones.
Not really. Seems to be your standard, run-of-the-mill resistance to change, combined with some conspiracy, and a call to action.
It contains valid points, but lacks the aggressive 'marketing' of the systemd apologists/proponents...
Quote:
Originally Posted by GaWdLy
I'm pretty sure the kinks will get worked out, and in 15 years, us old-timers can put up a fuss about how SystemD is the best, and SystemX is eeeeeeevil!
If you're happy with your Red Hat distros, then please go ahead and knock yourself out.
For this thread to have any usefulness (if at all possible) it should be located in the forum of a distribution including systemd or planning to include it.
Or are you trying to convince Slackware users to use Slackware? That'd sound like flogging a dead horse to my ears.
Last edited by Didier Spaier; 05-28-2014 at 09:58 AM.
Reason: Wording modified.
I don't quite see why offering the same DBUS interface indicates that the underlying system must have the same design flaws. And where did I say that the init system needs to be replaced?
When you put it that way it sounds like we agree more. Offering a DBUS interface to a required function, to me, sounds like a very different thing from implementing a 'systemd replacement' that does everything systemd does. It does sound like the right way to handle this.
There's a big difference in my mind at least between a 'systemd replacement' that has to do everything systemd does, versus a system continuing to use an init which nonetheless implements isolated bits of functionality from systemd in appropriate ways. The first, I do not want. The second could be quite useful, but did not seem to fit your criteria for a 'systemd replacement.'
And yeah, I also think it's a bit wierd to talk about a systemd replacement when we have not adopted it to begin with. Redhat may need a systemd replacement - slackware self-evidently does not.
When you put it that way it sounds like we agree more. Offering a DBUS interface to a required function, to me, sounds like a very different thing from implementing a 'systemd replacement' that does everything systemd does. It does sound like the right way to handle this.
There's a big difference in my mind at least between a 'systemd replacement' that has to do everything systemd does, versus a system continuing to use an init which nonetheless implements isolated bits of functionality from systemd in appropriate ways. The first, I do not want. The second could be quite useful, but did not seem to fit your criteria for a 'systemd replacement.'
And yeah, I also think it's a bit wierd to talk about a systemd replacement when we have not adopted it to begin with. Redhat may need a systemd replacement - slackware self-evidently does not.
Maybe I should have made that more clear. When I talk about a replacement for systemd-logind I actually mean, as you have figured out already, a service that provides the same functionality, which in this case means: offers the same DBUS interfaces.
Sadly, many people you see on the web talking about how GNOME or other desktop environments are dependent on systemd don't know that those DEs are not actually dependent on systemd, but use the DBUS interfaces systemd components provide. Any service that provides these interfaces can be used as replacement for those systemd components, replacement not in the sense that systemd is suddenly deprecated, but to replace it where it either is not available (the BSDs, for example) or where it is simply not wanted. The Debian package systemd-shim, for example, is a patched fork of systemd to make sysvinit capable of running a fully featured GNOME on Debian. Sadly, this can only be an interim solution, for any new systemd version the systemd-shim maintainer have to catch up with their packages to the changes in systemd, the main reason that systemd in Debian Testing/Unstable is at version 208, while the systemd package maintainers want to push for the current 212 version.
For this thread to have any usefulness (if at all possible) it should be located in the forum of a distribution including systemd or planning to include it.
Or are you trying to convince Slackware users to use Slackware? That'd sound like flogging a dead horse to my ears.
I highly doubt that article is even aimed at current Slackware users. It's aimed mostly at non Slackware, CRUX, Gentoo, and other non-systemd distributions. He was just posting it to show what the website was aiming at.
A new "systemd-timesyncd" daemon has been added for
synchronizing the system clock across the network. It
implements an SNTP client. In contrast to NTP
implementations such as chrony or the NTP reference server
this only implements a client side, and does not bother with
the full NTP complexity, focusing only on querying time from
one remote server and synchronizing the local clock to
it. Unless you intend to serve NTP to networked clients or
want to connect to local hardware clocks this simple NTP
client should be more than appropriate for most
installations. The daemon runs with minimal privileges, and
has been hooked up with networkd to only operate when
network connectivity is available. The daemon saves the
current clock to disk every time a new NTP sync has been
acquired, and uses this to possibly correct the system clock
early at bootup, in order to accommodate for systems that
lack an RTC such as the Raspberry Pi and embedded devices,
and make sure that time monotonically progresses on these
systems, even if it is not always correct. To make use of
this daemon a new system user and group "systemd-timesync"
needs to be created on installation of systemd.
I actually can't see what would be wrong with that, it does not want to replace NTP servers and makes actually sense. When you have a logging facility you also should have the possibility to make sure that your timestamp is correct.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
- slackware self-evidently does not.
