question for Slackware developers about systemd
 

EDIT: removed speculation paragraph and reformed questions so they are more clear.

Assuming Slackware contines to pass on systemd, my questions are:

1) How do you propose to keep an updated udev? Lennart talks about preventing udev w/o systemd here: http://lists.freedesktop.org/archive...st/006066.html. Will you stay with udev-182, help with eudev, mdev, or possibly hotplug2?

2) consolekit. continue using the unmaintained version?

3) What is Slackware's plan of action if more developers decide to require the entire systemd stack? Not include packages that require systemd? Or see if there's a way to "emulate" systemd? One problem I see is if Lennart's kdbus implementation gets widely adopted.

For the record, I am against systemd for many reasons but that is a separate discussion. Thank you for your contribution to the Linux community.

See this thread:
http://www.linuxquestions.org/questi...ds-4175484413/

I'd hate to try to speak for Pat, but I'm pretty sure that the answers to all of these questions are "TBD."

The issue isn't that developers are requiring systemd, but that certain upstream components are being abandoned that are being picked up by the systemd developers. Gnome's possible systemd dependency is that the developers want to use logind. Right now, they use ConsoleKit, which was abandoned. There's a page on Debian's site that documents the dependencies of systemd: http://people.debian.org/~stapelberg...endencies.html

If systemd is a requirement, then it certainly doesn't mean the end of Slackware. There was a user who demonstrated it could already be done in one thread before it got derailed by the circlejerk. He provided Slackbuilds to test it out.

That said, waiting and listening is the best advice. systemd's ultimate test will be when RHEL 7 is released and it starts being used in the enterprise.

The LQ's search feature comes handy.

Here is is the list of results for the query "please Mrs. Computer kindly display one URL for each thread in Slackware forum and its sub-forums whose title includes the word systemd"

The Debian vote was based on false premises: systemd vs. upstart. The premises should have been systemd, upstart, or remain with system V.

I guess my post is misunderstood. I'm not asking if it's possible to use systemd with Slackware, I'm asking if Slackware's developers will decide to integrate it at some point or continue to go against mainstream. Are they willing to help out with eudev or will they integrate mdev? If they do decide against systemd, that's good news for me personally.

slackware as i seen it has always been about good, clean, proven software
so i leave it to you to speculate if systemd fits there

only PV can tell, and i trust whatever he decides
the thoughts of slackers all around have been stated already by them so..

As has been stated previously many times in other threads on this topic Slackware is managed by only one person, Mr Patrick J. Volkerding, who usually doesn't make public his plans in advance.

In other words, IMO the only place where you'll get an accurate information is here.

ConsoleKit might not be maintained, but since it's abandoned anyone could still maintain the project with patches or even take over and keep development going.

If anything... yes it's all To Be Determined. Slackware uses a very simplified and easy to manage INIT system based off BSDInit and SysVInit concepts. I don't think Patrick is going to just abandon it outright. Whatever the course of action is, Patrick will do his homework, thoroughly research things, redevelop a lot ahead of time, thoroughly test it, and then repeat as needed until it's perfect.

Remember Slackware doesn't just outright adopt things that are unproven and still problematic, and things that do get too problematic are quickly dumped off.

I like this well-known phrase: "Think different!" Slackware can benefit from that decision.

Also Unix is not restricted to Linux.

My thoughts exactly. I like to think that, maybe, he's kicking the tires on udev alternatives during this long quiet after the 14.1 release. Though, udev-182 has been pretty good so far. Supposedly bugs have been found in it, but I haven't seen reports here of anyone actually running afoul of those bugs. We could do worse than to stick with udev-182 for another year or more while pondering alternatives.

As far as udev alternatives go eudev is still developed by Gentoo but I haven't heard how far along its development is, but the github was updated a few days ago.

There's also mdev as well used by Busybox. Now here's the thing with mdev, it's not as comprehensive and it's mostly for embedded systems, but it could show promise, though I think to use mdev, you still need backup tools like Hal, hal-info, and maybe hotplug to fill in the rest.

There's also the hotplug2 project used by OpenWRT. Don't know much about it except its a lightweight udev alternative.

I haven't seen anyone attempting to port these to Slackware yet so unless otherwise, someone could port these to Slackware and help thing along.

As the OP already stated, his question is not about someone but about what Slackware developers intend to do. So your quoted post is off topic IMO.

Point of Order: Logical Fallacy, Argumentum ad Populum, aka Argumentum ad Numerum

What is the point of trying to prove a fallacious premise?

EDIT: reformed original post. Ignore this post.

You will know if/when he so decides. The answer to the next question: "when will he decide?" is: "when he will be ready " ;)

Please forgive me my ignorance, as well as the needless extension of yet another systemd thread, but shouldn't it be possible to start systemd so that hard dependencies (such as udev) are satisfied, and then have systemd launch the classic init?

No. Because systemd run everything in its very own cgroup container, so, launching another init from systemd pid1, you'll end in something similar with a LXC container.

Hmm ... I think it might soon get harder and harder to hold out. It since looks like Ubuntu just folded as well. That doesn't leave many distros not on the systemd bandwagon. Just us and Gentoo? Or have I missed others?

http://www.markshuttleworth.com/archives/1316

CRUX developer Fredrik Rinnestam also expressed that he is against systemd: http://article.gmane.org/gmane.linux...ux.devel/2292/ (It's from 2012, though.)

So... where does that leave us? That is, what is the alternative? FreeBSD?

As did the members - in similar strong terms :)

the kernel is all we really need
and the kernel has a rule that goes something like "don't break shit"
combined with the mentality of "every bug is of same importance" i don't think Linus will allow systemd devs to break the kernel (i know one tried)

also ofc, where there's a will there's a way

Kernel plus Busybox - and you have what runs the majority of all Linux machines worldwide...

Fortunately Slackware project does not suffer from similar BS like executive committee, regulations, voting, bigmouth promises like "guaranteed" release cycle you can "rely" on, big-corporate money back-up and arising own interests from etc.
Just the long-term almost 10 years positive experience matters. The rest are just words, noise..

I didn't become involved in many endless debates about this RedHat's cancer. Yep, I don't like it and personally see no one serious reason which can justify so wide and deep system changes its adoption causes.

I'd wish Slackware would avoid it as far as all important upstream software included in distribution allows to be packaged without too much hassle.

This is a major intervention and for our business it does mean even to ditch Linux completely. Fortunately there are still free BSD systems, however narrower hardware support complicates things a bit for the lasting contracts but they are already being solved.

It seems they considered developing udev but only time will tell
Quote from Pat:

One thing I completely dislike about systemd is that literally it acts as a locked hypervisor to the GNU OS. There's no shell interaction with systemd at all because it's completely self-contained unlike every other init system out there that interacts with the system shell. There's near-zero administrator level inside of systemd unlike bsdinit, sysvinit, runit, s6, upstart or any other init system.

I think honestly people have gone insane over this software being viable. The guy from CRUX made a good hint. Mdev is a step back in time, but maybe that's what needs to be done. Maybe this is a metaphor and clear message to say in order to see where we stand, we have to take a step back to see not just our present but our future as well.

Maybe it's time those distributions that don't want systemd need to start working together.

Systemd reminds me of the question, if everyone jumps off the bridge to their deaths should you jump as well? The answer clearly... Is NO.

On the switching to *BSD argument, if you feel the need to do so, start learning now. Don't forget there's also Solaris, Illumos, and other UNIX branded distributions also.

RHEL7 will have systemd, and it's made my RHEL/CentOS/ScientificLinux-using sysadmin friends grumpy. They don't want to talk about it, and they don't want to think about it, because they don't want to be "angry all the time" (an exact quote from one of them).

It's made me think this might be an opportunity for a Slackware-for-the-Datacenter project. Eventually some of these professionals are going to look around for viable systemd-free alternatives for their business. I don't think there currently are any. It would be very nice to have one to offer them.

Offer Slackware you must young padawan! Then and only then a Jedi shall you be! Mmm!

They'll have to convince the suits, many of whom think that RedHat ::= Linux.

Yeah, I also remember reading Christoph `20h' Lohmann's rant on systemd when Arch switched to it: http://thread.gmane.org/gmane.comp.misc.suckless/11928/focus=11934

Yeah! And I loved his last sentence:

When your beloved opinion leaders raise that type of arguments, I can gently ask if the anti-systemd movement isn't in fact an commie fest?

What do you think is missing to become "Datacenter material"?
in other words: for any "non SMB" sysadmin to consider Slackware as an alternative to a systemd riddled distro, what do you think needs be done?

Slackware does great as a server distro, but a datacenter requires different tools for the enterprise use-cases, and to scale, some of them enumerated here: http://www.linuxquestions.org/questi...4/#post5100969

Think, for instance, of fifty 40U cabinets full of 1U blanks, with ten more full cabinets arriving monthly. Now, are you going to plug a keyboard, monitor, and dvd into each blank to install Slackware, or even open all their cases to clone their disks? Something like Spacewalk is a necessity, so you can just power the blanks up and have them network-install to different personalities while the admin monitors from their office workstation.

To justify the transition to their suited overlords, administrators will need to enumerate the company's use-cases and show that Slackware will jfw for them. That means Slackware not only needs to make the tools available, but also have documentation explicitly describing the use-case, stating that Slackware will work, and providing instructions for doing so. Fortunately that requirement dovetails nicely with another recently-started Slackware project. :-)

Enterprise-ready Slackware is doable, it "just" needs a hell of a lot of work.

I dug up some notes from the last time I was thinking about "Datacenter Linux", transcribing/annotating:

To bootstrap the larger system, the admin would need to conventionally install Slackware onto a system, and then install the DCL package, making it a "boss server". It would then provide installation services over the network so blank servers could use it to network-install to some flavor of boss or worker node (the differences being the authentication keys they were given, whether they copy all of the boss-specific data, zeroconfd configuration, and which Chef/Puppet recipes they use).

The package would:

* Put the slackware installation files in $DIR/slackware/$VERSION (could copy them from dvd or .iso file, make a symlink from elsewhere on the disk, or acquire them over the network),

* Copy the slackbuilds and their source tarballs to $DIR/SBo/$VERSION, and perform the equivalent of "sbopkg -r" (the initial copy could be distributed with the DCL package),

* Copy the boot image(s) for PXE to $DIR/pxeboot/$VERSION,

* Install the DCL-specific libraries, modules, scripts, cgi, and daemons,

* Initialize the inventory database,

* Configure/start named,

* Configure/start httpd,

* Configure/start nagios (or munin?),

* Configure/start dhcpd and tftpd, for PXE,

* Configure/start zeroconfd.


When a blank server boots, it is presumed the vendor or VAR has set its boot order to boot off local disk before network (PXE), so that if it has no operating system installed it will attempt PXE-boot and:

* Negotiate PXEboot with boss node via DHCP,

* Load a boot image via tftp and boot from it (this will just be Slackware with a few extra scripts installed, some of which are called from rc.local to continue the process described here),

* Wait for a zeroconf pulse (a UDP broadcast packet) directing it to the right boss node, or for a human to give it an IP address,

* Announce self to boss node (via https), and get a response setting its clock and telling it to either try again periodically (and how often, and with what stagger) or with instructions for network-installation,

* Receiving instructions ("obtain your net-install script and other things from <url>") might take a little while, because the admin may have configured the boss node to keep blanks in limbo until the administrator can look them over, choose a personality, and click "OK". When the blank announced itself to the boss node, the boss node made a notation in its inventory database, causing the blank node to appear as an entity in the admin's web-app control panel.

* Once instructions are received, the blank node fetches ssh keys, password hash, installation configuration file, recipes, and a network-install script via https and runs it,

* The network-install script partitions the blank's disk(s), creates filesystems, and https-copies the Slackware installation files from a boss node.

* Slackware is installed (like we do manually, but with no human input, only the installation configuration file obtained from the boss node),

* DCL-specific files/scripts are installed, along with a central configuration management tool like Chef,

* The node reboots itself, booting from its local filesystem this time,

* Chef takes over from there, receiving instructions from the boss node and running the recipes necessary for the new worker-node's personality, as well as installing/starting things every node must have (like nrpe, for Nagios checks). Depending on its personality, the node might become a new member of a load-balanced webserver pool, or a slave node in a replicated MySQL instance, or a GlusterFS data brick, or whatever.

* Slackbuilds and their sourceballs would be obtained from the boss node(s), so a hundred nodes wouldn't have to reach over the internet a hundred times to install a package. An sbopkg-equivalent tool will need to be written which operates without human input (sbopkg's "-e" option doesn't cut it; there are too many conditions under which it would block forever seeking input).

* Parallel-ssh tools (or their equivalent, like gexec) would be provided for additional central administration (besides Chef).

I think Slackware already has an automated way to install packages (even third party): slackpkg+
With a pxe server and slackpkg+ (using templates), you can turn any standard slackware install into a specialized system.
All that is needed is have a "datacenter specific" package repository.

As long as Spock has a goatee in your universe, yes.

The whole idea about systemd just seems like painting a pretty picture in front of you while tying your hand behind your back. In principle.

Having hard dependency on a specific startup scheme is another example of simply trampling on people.

If it has advantages for certain folks, it can be done elegantly. If other folks don't need it, don't want it or is counter-productive to them, things still must work and work properly.

Not to mention :
http://ewontfix.com/14/

I'm not flaming, it is about choice, and hard dependency on systemd is about taking it away.

Seriously? And this hard dependency kick your freedom of choice?

Lets see...

A GNU operating system, like Slackware, can run technicaly on three kernels: Linux, kFreeBSD and Hurd. See Debian GNU/Linux, Debian-GNU/kFreeBSD and Debian-GNU/HURD.

BUT, on that P.O.V., Slackware operating system make the Linux kernel as hard dependency. You aren't unhappy by that strong limitation of your freedom of choice?

I wonder what Slackware would be like with a BSD kernel?

Now SystemD is taking over networking management duties out the box with its latest release has its users crying now.


http://www.phoronix.com/scan.php?pag...tem&px=MTYxMTI

And doth the Kraken yet groweth another tentacle.

Okay, while I abhor systemd's philosophy but can see where it has potential, this seems to be a step too far in my opinion.

If systemd-networkd is going to internally manage networking within the systemd hypervisor, then what purpose does dhcp-client, dhcpcd, network-manager, and such bring to the table, and with systemd fairly much being ran as a locked hypervisor with no console, how will it affect static ip addressing or will it force dynamic addressing? Can systemd even be built without networkd? How will it be configured?

For servers with certain functions using dynamic addressing isn't an option as some require static ip addresses to operate. For end users and workstations it's not so much an issue, unless you're on a static ip managed network then I can see a potential problem.

Not sure how much of questionability this addition will raise but sinking a tentacle into the networking infrastructure is not something PID-1 or any init system should be concerned with in any regards. One more possible failure point in my opinion.

My recommendation for Slackware's future would be to drop the entire "desktop" stuff and give Slackware a reliability advantage as a server OS by not having the whole freedesktop.org mess on board.

In my opinion the GNOME/KDE/Xorg/Wayland stuff won't survive beyond 2020, anyway. So hunting their dependencies would be a waste of time in the long-term perspective.

Amazing! :doh:

Now, please enlight me, how droping the "desktop" crap will grow the Slackware reliability advantage as a server OS?

At this rate, they will be running Linux as a "plugin" on their systemd OS before long.

Everyt time I think there might be a way forward with it, I see something like this and repeat: not on my machines!

Ok, why in the hell are people adopting this monster

Simple: Remove all that buggy, unreliable and abandoned code (i. e. systemd/udev, ConsoleKit, HALd etc.), which is only required for running soon to be stale freedesktop.org stuff, but nothing else. Just look at BSD. Linux doesn't need that code, because the "free desktop" won't happen anyway. Red Hat and Canonical only need that illusion to keep developers volunteering code to them for free.

Maybe we could go a little farther and get a desktop without that stuff. For instance it's easy to display (and type, with a proper IM) CJK characters in a tty with just vga or a frame buffer with fbterm + fontconfig + a true type font like wqy.{zen,micro}hei plus web browser relying on it and lib{ungif,jpeg,png}.

So we could try two opposite paths:

• integrate systemd in Slackware as BartGymnast tries to do,
• only use vga or frame buffer drivers and don't create devices on the fly. I'm not sure it'd be easy to watch videos then, but who needs to do that on a {lap,desk}top nowadays anyway?

Agreeing with jstn, to an extent. Reducing the number of dependent parts in a system makes the system more reliable, and there's cruft in the system which just isn't needed.

Consider: Any task a system needs to perform requires that some set of subtasks be performed.

If each subtask has a probability of performing its role correctly, then the probability that the entire task will be performed correctly is the product of these probabilities.

So, if we suppose P (for some value between 0 and 1) is the probability that any given subtask performs correctly, let's look at the probability of tasks of differing complexities being performed correctly:

Task of 1 subtask: P

Task of 2 subtasks: P * P (both subtasks have to perform correctly)

Task of 3 subtasks: P * P * P (all three subtasks have to perform correctly)

As you can see, the probability of performing a task of N subtasks correctly is proportional to P**N. The probability of success goes down exponentially with complexity.

To illustrate, let's hang a high chance of success on a subtask performing correctly, 0.99 (so 99% likely to perform correctly).

Task of 1 subtask: P**1 = 0.99**1 = 0.99

Task of 3 subtasks: P**3 = 0.99**3 = 0.970

Task of 5 subtasks: P**5 = 0.99**5 = 0.951

Task of 15 subtasks: P**15 = 0.99**15 = 0.860

Task of 30 subtasks: P**30 = 0.99**30 = 0.740

Task of 45 subtasks: P**45 = 0.99**45 = 0.636 only 63.6% chance of success! 36.4% chance of FAILURE!

This is admittedly a simplification, as real-life subcomponents have complex failure modes and not just a simple probability of failure, but it illustrates a simple truth: The fewer components a system has, the fewer opportunities it has to fail. This is why following the KISS Principle produces more robust systems.

So, clear out the unnecessary components, or replace them with simpler equivalents, and the robustness of the system improves.

Add components, or replace them with more complex equivalents, and the robustness of the system suffers.

I wouldn't abandon hope of keeping Slackware useful as a desktop, though. There's a chance that eudev is a suitable replacement for udev (haven't checked it out myself yet, but I hope someone on the Slackware dev team is), and might enable Slackware to continue providing its server and desktop features without systemd.