Debian just had an exodus to Slackware, so I think the proof is in the pudding of how the demographics against systemd are what they are. People have tried it, find it annoying, hate it because it's so needlessly complex, and just refuse to deal with the absurdity surrounding it. People know what works for them, and they know what they like. Sure we've had stuff come along before that were annoying packages, but this one truly takes the cake and ice cream both.

Further to this, from my limited understanding of the Debian project, they never really committed themselves to Linux (as in the kernel) either. IIRC, they once regarded it as a temporary placeholder until GNU HURD was ready.

Isn't it funny how things can change?

Both links were very interesting reads. Thanks for posting them!

I'm trusting Pat and his thoughts about systemd.

However, I don't want to see PulseAudio and Avahi/Zeroconf being pushed as default components of a base Slackware install for example.

If that ever happens, I will switch to something like Archlinux.

Don't get me wrong, I like Slackware a lot and it's the OS I use for my studies because of its stability. :)

A few things:

Desktop oriented? Not useful for servers? Yet the only advantage I have found that is clearly real is for virtual-server farms.

If Mr Volkerding accepted SystemD it would force me to re-evaluate it from scratch. No guarantees, but it's the only case where I would, at this point, reconsider allowing Mr Poetterings software to run on my machine.

Third, I've been relying on the linux kernel since '94 and I am not about to go over to the *BSDs as long as it is still viable. They are good systems, and they have my respect, and I am happy someone else is using them so they continue to be developed.

A couple of more general points - I dont at all mind people trying to use *nix to create a system that clueless users can use. I suspect most of the projects trying to do that are worse than useless - because they dont have any understanding of clueless users - but it's still their right to try. What really chafes me though is when they start demanding upstream changes that cause me problems. SystemD is a perfect example for anti - because it does not actually solve any sort of technical problem, does nothing to make things easier for the clueless user, it's all just an excuse, just politics, just a move for Redhat stock to move up. If it has any relation to the clueless user that relation is exploitation, not service.

I used to be neutral-to-positive towards RH and systemd has changed that. I no longer own any of their stock and I am rooting for their bankruptcy.

My thoughts are this: what do people want a desktop/server to do and how can slackware get us there? Desktops come and go, but ultimately, what do people want from them? I'm not advocating creating new desktops, but using what is available now, what do you (the collective you) want slackware to do for you? Instead of discussing what has gone on previously and using what is available now, what would you like to see slackware do for you? This is a pretty large and knowledgeable community, just saying that "systemd sucks and I'm going to leave" isn't really doing much to improve anything. Not thinking of any one desktop or window manager, what would you change, and what would you keep the same? And then thinking of desktops and window managers, how would/could you get there? I have no IT background and am no developer, but have come to love the linux and slackware community because anything is possible because of the knowledge-base it draws from. If it can be conceived then there is a way to make it happen.

The next problem of going to systemd, I see anyway, is that it becomes anti-teaching of core UNIX fundamentals that translate well across operating systems, while pushing it's own fundamentals that aren't cross-platform and Linux proprietary.

You can easily learn everything possible in Slackware, migrate to FreeBSD, and have a good idea of what to expect on some level with minimal re-education.

By striking out core UNIX fundamentals such as learning scripting, basic plaintext file configuration reading, and low-level service startup methods, it hinders the educational process of learning not just GNU/Linux on the whole, but a set of core skills transferable to any flavor of Linux, BSD, or UNIX.

I, for one, used what I knew from Slackware to work FreeBSD. It took a few reading sessions of the handbook and other documentation, but the transition was smooth because a lot of the core UNIX fundamentals translated easily into FreeBSD. For me, the statement, "You learn Slackware, you learn GNU/Linux", wasn't just limited to GNU/Linux. To me, Slackware went a bit further in being, "You learn Slackware, you learn core UNIX cross-platform fundamentals."

Really and truthfully, other than the obvious, how different is FreeBSD in design layout to Slackware? There are some differences, but overall there are a lot of similarities.

We need to keep a system design framework that is less proprietary and more cross-platform, maybe even more inclined to be POSIX-like (if such a term does exist) educationally. If that principle is abandoned, then I honestly see no reason to stay around to learn something that limits education and only harms educational growth.

I don't know if Patrick ever intended Slackware to be an educational tool, but it has gracefully been accepted as one.

I agree. That is one major aspect of the break with the Unix-y foundations that is implicit in many other arguments on the subject, but not often noted explicitly.

I have in fact made a few notes for (yet another) LQ post I hope to put together in the next few days, but perhaps it is just as well to point it out here where it already has some exposure. The main idea I am developing is how the switch to systemd will, and has to some extent already devalued the storehouse of knowledge available on LQ and other places.

What first brought this to mind was that I recently responded to a question about how to force fsck on reboot. I responded by pointing out shutdown -F, and how it creates the {/etc}/forcefsck file detected on startup - simple, elegant, flexible, unixy goodness.

After posting I wondered whether systemd would support that same paradigm, and searching the systemd docs online it appears that it does not... so I edited my post to say that it might not apply to systemd based systems.

Then I realized that whole classes of answers will now need to be qualified as pre- or post-systemd, meaning at least two answers for many questions.

This really creates a needless schizm in the available resources. For example, I often search for quick answers on various GNU/Linux topics and frequently find an answer to a 13+ year old thread that is still perfectly applicable to my current systems. In fact where init and runlevel related questions are concerned, the older posts are usually the best and most useful.

But for new users, with new systemd based distros, there will exist a discontinuity of useful information, and a profusion of "old" posts that no longer apply and will only confuse them and require further filtering.

The discontinuity of usefulness of accumulated knowledge will, I think, become another major disruption in our sphere.

And what a waste! One more way that the change to systemd discards the best of what has gone before instead of building on it...

Indeed, it's actually a subject I've rarely thought about until today about how well Slackware and distributions on par with it, like Gentoo, LFS, and CRUX all offer some level of "teaching" core UNIX fundamentals, not just GNU/Linux.

I think about the other aspects of systemd and what it involves, but the educational aspect was one I had not thought about to heavily. Usually it's been the overt complexity, the author being a total prick, and the fact that it's taking Linux down a dark path it shouldn't go.

I never actually thought about the educational aspect until this topic actually asked about switching to another distribution, and I thought about "how could I insert myself into XYZ system with minimal re-education?", and that's when it hit me. You'd have to already know some level of cross-platform fundamentals of UNIX to even start out on another operating system.

You're right, at least several decades worth of knowledge fills books, videos, audio files and portable media, websites, wikis, etc. All that is being cast into the proverbial pile all waiting to be willingly burned.

I've been experimenting with the most recent stable FreeBSD and I've run into some of the same issues I've had with Debian/Arch/etc. Everything is fine for a week or two and then some package installation/upgrade/removal doesn't go as planned. In my case it was related to trying to get Dillo running under FreeBSD (which should be simple), but Dillo locks up X after 10-20 seconds of usage. This occurs whether I install the binary Dillo package or build it via ports. It's probably bad luck on my part, but I just never experience anything similar happening in Slackware.

The only thing that would make me potentially jump ship from Slackware would be forcing some type of automated dependency resolution on the package manager, but I think I could live with systemd (although I prefer the tried-and-true init scripts).

At the moment I happily dual boot Slackware with OpenBSD. If Slackware is forced to adopt SystemD I'll continue to use it. As I've stated before on several occasions I trust Pat's judgement.

If the responses in this thread are representative, it sounds like most Slackware users will simply trust Patrick and continue using Slackware if systemd is ever adopted.

For those thinking of switching, most are eyeing FreeBSD. I confess to sizing up NetBSD as a possible fallback position, myself. (Two of my friends are NetBSD devs, so I'd have a lot of help getting up to speed.)

An alternative might be to fork Slackware, following its evolution on the most part, but based on sysVinit and the classic services (crond, inetd, pm-utils, etc) systemd seeks to replace.

I mean no offense to Patrick or the dev team by raising the possibility, and such an effort would depend heavily on their ongoing work. I'm just curious how many Slackware users who are considering jumping ship to a BSD might prefer a systemd-free Slackware-derived Linux distribution.

Presumably for some of us (myself included!) part of the appeal of Slackware is that Patrick + co are well-known and well-liked, with a long-established methodology marked by pragmatism, conservatism, and proven best practices.

Authors of such a fork would be comparatively unknown, and some users might prefer a BSD over putting their fate in the hands of strangers, at least until the "new guys" demonstrated themselves worthy of trust (if ever; Patrick's example sets the standard pretty high).

This is all extremely hypothetical, of course. As has already been pointed out, the upcoming 14.2 release looks to be systemd-free, which means we'll have a Linux/classic Slackware supported until at least 2020.

I don't know if I can say it for those of us who who are anti-systemd or not, but it's not that we don't trust Patrick. We trust Patrick, just not the upstream developers who change things on whim out of amusement or want rather than general need.

The problem comes from the cascade of having to viciously relearn everything we've known for years now, some of us 10+ or more years in UNIX and UNIX-like systems, in short amounts of time off of documentation that either doesn't exist yet, is still being drafted since systemd is still being actively developed (added onto in reality). For many of us having to tear down our own knowledge-bases and pulling a proverbial Yoda laden, "You must unlearn what you have learned" only to start all over from scratch on the key structural point of the entire operating system and environment, is aggravating to say the least (you might even dare get a few people willing to pull a virtual Linus Torvalds saying "F*** YOU" to Nvidia but with a redirect to Lennart and systemd).

Yes there are wikis but what system administrator with more than 20+ years in the field suddenly wants to have to drop everything he's known for all this time, and then suddenly relearn everything from scratch and try to make sense of it all on a package that has no signs or reasons to be "finished" yet developmentally? Yes there are wikis, courses, videos, etc. but gained practical knowledge isn't easily replaced as a book on a shelf. Unlearning is a process and it's not often the easiest process for people. Not everyone is going to have the time, willingness, and overall patience to learn a new system.

It is funny that you mention that because I had the opposite experience with BSD. Before Switching to Linux I never had my system freeze at all with with OpenBSD and FreeBSD. I used both for like 9 years. FreeBSD, for example, handles extreme network loads better than Linux. The other day I had Slackware Freeze on me, several times, for a significant amount of time. I suspect it had something to do with swapping and maybe the flash plugin for firefox.

Anyway, based on the responses of a significant amount of Slackware users saying they would stick with Slackware if Patrick switched to Systemd (meaning they don't give a shit about the Unix philosophy) and the fact that Slackware froze on me made me decide to install OpenBSD, on my Thinkpad, and stop using Slackware.

If even most Slackware users can't respect the Unix philosophy then that means Linux is now hopeless since Ubuntu is like a windows-clone so mainstream Linux distros don't respect the Unix philosophy either. I am clearly in the wrong community I belong back in the BSD community. The BSD community still respects the Unix philosophy.

In the beginning, Linux was pretty cool. It was free (always a plus), had a rapid development cycle, a moderately knowledgeable user base, and a funny mascot.

Then the pinheads arrived.

I'm not a pinhead so I'm switching back to OpenBSD.

As noted in another thread, you seem to have arrived with an agenda other than intelligent discussion.

This issue is divisive enough without pot-stirrers...

Respect for others is another character trait that Dennis Ritchie built the Unix philosophy upon - it isn't all about the technology.