I totally agree with you on that.

Technical excellence was never a part of systemd, and will never be: the design is just plain wrong.
However, even if features were very low on that list, or not part of the list at all, this was true a few years ago, but is most certainly not true anymore. Arguments made by systemd advocates are that systemd does this, and this, and that, and no other system does. Of course, it's wrong for systemd to try and encompass so many things - it's the very problem with systemd in the first place - but it exposes real needs; it addresses the right problems the wrong way. Given the hold that systemd has on distributions today, I do not see anything dethroning it without providing alternatives to what it does.

You might not want those features, I might not want those features, but distributions do, and they are the target, not end users. Technical users will always been able to work around bad mainstream software - I've been doing it for 15 years - but to have a real impact, distributions are where it's at nowadays. Lennart understands this very well.

Well, if it's not about features, then we already have everything we need. I'm very happy with s6. Some people are very happy with runit, others with sysvinit. Still, systemd is moving forward and threatening the whole Linux ecosystem; I want to do something about it. So far, competing with systemd on the basis of technical merit only has not been successful; that's why I want to identify the next step, and "more features designed the right way" sounds like a good option.

I used to think the same. Five or six years ago, I saw systemd and just laughed: it was obvious to me that nobody could ever possibly be interested in such a demented piece of software. It went so blatantly against all principles of good engineering that everybody would dismiss it and people would understand the value of minimalism and clean design on their own, right ? So I did nothing.
Boy, was I wrong, and here we are today with the systemd borg assimilating everything.
Sure, Unix will survive, and there will always be a place for minimalism and technical excellence. But I want more. I don't want to lose Linux; I don't want a mediocre, closed system taking over user PCs just like Microsoft Windows has done. I don't want history to repeat itself - and it can only be prevented with action.

Features are nothing without design; but I trust myself to come up with the appropriate design. I feel that the systemd opposition will be a lot stronger if it can show a plausible alternative to certain things systemd does; if not a piece of software, then at least a design document. Features may not have been the way systemd rose to wide adoption, but I think it is the way it is maintaining its supremacy, and this is where we have work to do.

But then again, if I come here, it is to hear other perspectives. In your opinion, what should be done ? "Nothing" isn't an option.

2 members found this post helpful.

I think s6 could use maybe the following, but this is just my humble opinion only:

A built-in init handling agent in s6-svscanctl or s6-svscan. Already s6-svscanctl can handle the functionality of utilities such as halt, shutdown, reboot, etc. when the proper calls are made to do so. Maybe adding a small init handler into s6-svscan or s6-svscanctl depending on which is PID1 would benefit to avoid writing a custom agent.

This would allow easier writing of Stage 1 and Stage 2 boot and service execution scripts without having to generalize an init script to boot with. A symlink to /sbin/init from s6-svscanctl regardless of if it's installed in /bin or /sbin would be all that is necessary. If s6-svscanctl detects a program trying to use init, it executes the init code, boots the system, and begins the process of loading the system and services in the various stages. Maybe even staticly built-in execline script handling as well might be useful.

The "configure-make" based installation is needed also.

Development of execline scripts for services from upstream for distributions but working with the distribution maintainers to co-develop said scripts rather than trying to write generalized scripts from upstream only. This could be centered around core-scripts only such as udev, getty tty services, networking, and system logging only. After that the distribution maintainers could write everything else in shell scripts or execline scripts.

But that's just ideas only. Nothing concrete.

However, whatever init system Slackware could migrate to, should be simple in design yet elegant in execution, easy to use and administrate, and shouldn't be burdensome to diagnose.

My favourite for root password recovery:

I have never tried that.

As I write this 55 people have voted, with 81% voting for "Other". I think that effectively shows that this poll is not grounded in reality and is based on poor assumptions about what is likely to happen on Slackware. Interestingly the next highest vote is actually Systemd at 5%.

I do not believe that OpenRC, Runit, s6, etc. have a snowball's chance in hell of being the next Slackware init. We'll stick with what we have got and Pat and the team will make it work somehow (despite the changes in the Linux landscape with regards to udev, kdbus, logind, etc.) or if that proves not to be possible, we'll end up with Systemd.

2 members found this post helpful.

Why not? I think it's the best option we currently have. Some one mentioned technical excellence. You don't maintain technical excellence by following trends. If somebody wants to use systemd, let them use another distro.

4 members found this post helpful.

For service supervision one can install e.g. runit or daemontools.

1 members found this post helpful.

Right now, it doesn't have to change. It isn't currently "inevitable", although with the way things are headed, it could eventually become inevitable if things don't change and their momentum continues. Much of the distaste with systemd is related to trying to be the one and only available init system (Linux has always been based on choice... Don't like KDE? You have Gnome, XFCE, Windownmaker, Enlightenment, etc... Don't like Lilo? Use grub. Don't like vi? Use vim, emacs, pico, kate, writer, etc). Also, in developing systemd, they are going against several Linux ideals, such as not having plaintext configuration files (they require their own tools to modify them), no plaintext logfiles (they are binary files that require their own readers, so if there happens to be corruption, the logs are likely completely lost), trying to group multiple separate important projects (like udev) into one big project, and trying to prevent any alternatives from working.

They are working to incorporate changes into it that would eventually force pretty much any modern Linux distro to move to systemd (or at least a systemd alternative that provides most if not all features but hopefully in following Linux ideals better, like skarnet is eventually hoping to do with S6). If systemd developers have their way, and no alternatives are made, then it would eventually be "inevitable" to switch to systemd. However, they still have roadblocks they are working through and there is opposition from Linus in regards to the kernel, so they do still have some hurdles to go through.

1 members found this post helpful.

I dont think the lack of votes for them is necessarily based on readers being intimately familiar with them and rejecting them, however. I voted other and I know what I was thinking. Happy with slack init as is, and will almost certainly be happy with whatever Pat moves to, when and if he changes, but I have only the vaguest idea of the differences between OpenRC, Runit, s6 etc. and I am not certain I like any of them. That doesnt mean they arent good pieces of software, just that since I see no need to move before Pat does researching them is a fairly low priority for me. If I suddenly developed a *need* for some capability that they provide, I would certainly give myself a crash course, but for now it's still a relatively remote concern.

What I would be looking for in that case would be one that is as simple and robust as possible in pid1 and implements the extra features as isolated optional and replaceable modules. I have no idea which of the listed init systems comes closest to that ideal, I would have to spend some time researching and testing to tell you that. So I chose 'other.'

2 members found this post helpful.

My thinking when starting the poll was that there is a current mentality that people should move away from init and to something new. I'm not saying this is right, because it is probably wrong, but this seems to be what the distro maintainers are thinking. As such, an alternative to systemd may mean that some distros will accept it as an alternative and its future development and acceptance would be assured. This would be a lot easier than the Gentoo folks trying to eek out an existence by maintaining a fork of much of systemd for use with one distro. I was hoping that pushing an alternative would make some distros accept it and help maintain it and allow its existence.

I'm just trying to think ahead here, because seeing the tactics systemd devs are using, this is warranted and a good idea. Sorry to ruffle feathers of people who don't want to change from init. Maybe it won't be inevitable, but you know "hope for the best, prepare for the worst".

I personly think that the reason many other distros made the switch was because of the complications of not moving due to associated componants, rather than needing or wanting more from their init. Of course this is not exclusively true for all distros but I certianly feel it played a large part.

It did but having less to maintain was another reason. With the switch to systemd, many distributions no longer needed to maintain large script sets. systemd already includes a sizeable support vector of unit files which are constantly being added to. There are some distributions that have their own unit packages, but by comparison those packages are a lot smaller than the script set packages.

There are benefits and drawbacks to this though.

1. No need for specific shellisms whether it be bash, dash, csh, or zsh.

2. Unit files are smaller like Runit run-files.

3. Upstream can produce uniform unit files.

4. However, less distribution specific units mean less customizations.

5. Less inclinations to learn proper scripting methods.

6. Avoids "bad scripting".

7. Offers little recourse of bad units from upstream.

I voted "other". "Other" should have been listed as one that just works. This discussion is above my paygrade as I am simply a competent Slacker user. I have used Slackware64-current ever since it came out, and have had relatively few problems. The problems I have had, I've been able to fix them. The init system and how it works is something I don't have much dealings with. I guess I should learn a new skill.

At Pat's will? So, paying customers hold no sway?
Okay then! Slackware has become RedHat sooner than I thought possible.

Thanks for adding nonsense to a nonsense thread. Back to Ignore.

Where I work, a global corporation, we have RedHat, Ubuntu, Debian, Arch Linux, and Slackware. Every one of these distros except Slackware have serious real-world useability issues. In fact Slackware is what is being migrated to because - "It just works". None of the others "just work" for engineers. Ironically with all the graphical bells and whistles of user friendliness - its Slackware, with its manual setup that is actually easiest to use - that's my opinion based on what I deal with daily.

2 members found this post helpful.