What if Slackware dies?

[zolix]

Dear Salix Guys,

I would like to ask you about future of Salix.
Do you have plans for the situation if Slackware stops releasing new versions?
Or release cycle would be more longer than last time?
Since it would be a huge shame to let Salix die. It is too awesome to let it down.
Therefore I dare to suggest you to check how could Salix be migrated to other base than Slackware.
As Linux Mint has LMDE, perhaps Salix also could try other OS as base.
I would suggest Devuan as a possible target because of its huge repository and it gives you the freedom to keep your OS systemd free.
I just customized a a Devuan desktop to be similar:



What are your thoughts about this idea?

[DidierSpaier]

As the saying goes "You can destroy your now by worrying about tomorrow."

[djemos]

As the saying goes "You can destroy your now by worrying about tomorrow."

[zolix]

As the saying goes "You can destroy your now by worrying about tomorrow."

I think, preparation is not worrying but anticipation.
Wise sayings are cool but not fit for every situation in real life.

[DidierSpaier]

Yes, but the question is: who is going to do the work for an event that nobody knows when it will happen? Salix developer and contributors are busy enough as it is, I suppose.

[zolix]

Thank you for your valuable comment.
However I am also interested in the opinion of the developers.

[DidierSpaier]

However I am also interested in the opinion of the developers.

Fair enough. gapan?

[Papasot]

"Nothing lasts forever but the earth and sky" says an old great song (and I'm not sure about those either).
That being said, Slackware proved to be too good to die. It is the most "deathproof" distribution out there, and the one that it is still around after 30 years. Others come and go, Slackware is still here. Of course the crowd of casual GNU/Linux users don't know it is still alive - if they even know "Slackware" is a thing, that is. But that doesn't matter much, the crowd will always follow the hype.
I guess it's safe to say we don't have to worry much about Slackware.

[brocashelm]

No, Salix should not use Debian at all. If I want Debian, I'll use Debian (or Devuan in this case, because I don't like Systemd or other Poetteringware in general). What I like about Salix is that I get an even more old school GNU/Linux experience than Debian, due to being more Unix-like and featuring BSD-like services and initialization. Unfortunately, modern GNU/Linux systems have gone far and abandoned their old Unix ways of computing. Slackware is the last stand, even if that has also been subverted a tad by Poetteringware and Freedesktop-isms. I personally am more into Debian-based systems, but I like a Slackware alternative when I get a little too bored and want to "understand" GNU/Linux better.

Debian and Slackware are two totally different GNU/Linux distros. Debian was designed to be easier to use, ergo it provides a bit more of a modern computing experience (albeit not quite on the same level as Fedora or Arch GNU/Linux). Its package manager uses automatic dependency tracking and is also more minimal by spreading out the library and development sections into their own packages. Slackware's package manager relies on the sysadmin or power user to manually resolve the dependencies themselves, on top of packages being more bundled together than separate, so you'd have to install a lot more things to ensure the lowest chances of a system breakage. Salix's does handle automatic dependencies, but it's still different from Debian (despite similarities in command usage), and moreover, you'd still be stuck with certain "bad actors" (e.g. Wayland, Pulseaudio, JACK2, Avahi, Elogind) in order for Xfce, KDE Plasma, Mpv, Atril, and a host of other GTK and Qt programs needing them to even function. Also, the lack of support for multiple libraries (multilib) makes programs such as Wine tougher to install than their Debian or Gentoo counterparts.

There are a few things that keep me from fully adopting Salix or any other Slackware-based distro. While I can appreciate the lighter resource usage compared to Debian or Devuan, I can at least update those with the confidence that my systems won't break. Almost whenever I do update certain GTK or Qt packages, my Salix installs break (something to do with GSettings, but I have to always restore from backup). My Xfce session gets completely trashed, and my theme is replaced with a generic light one. I hate that very much, and that I haven't gotten a working solution thus far (I've asked a couple of times with no success) means I will just use Salix as a secondary distro (which isn't a bad thing at all, since I pretty much gave up on everything else outside of Debian), whereas Devuan remains on my main production systems. That's not to say that I don't appreciate all the work that went into developing Salix, and I still intend on donating to the project. If there is one request, it would be to restore Sourcery for Salix 15.0, since there are still a lot of packages that have yet to be added to Salix's repositories.

[Papasot]

No, Salix should not use Debian at all. If I want Debian, I'll use Debian (or Devuan in this case, because I don't like Systemd or other Poetteringware in general).

Who mentioned Debian in this thread? Debian is infected by systemd to the bone - not to mention other crapware from the same bunch of developers.

Slackware is the last stand, even if that has also been subverted a tad by Poetteringware and Freedesktop-isms. I personally am more into Debian-based systems, but I like a Slackware alternative when I get a little too bored and want to "understand" GNU/Linux better.

I lost you there. You clearly dislike systemd (and you do well)... why do you even consider Debian-based systems then? Granted, Devuan and antiX are Debian-based but without systemd. However that's not flawless and not the same with a distro that's not based on Debian in the first place (or Arch and the other fully systemd-infected distros).

Salix's does handle automatic dependencies, but it's still different from Debian (despite similarities in command usage), and moreover, you'd still be stuck with certain "bad actors" (e.g. Wayland, Pulseaudio, JACK2, Avahi, Elogind) in order for Xfce, KDE Plasma, Mpv, Atril, and a host of other GTK and Qt programs needing them to even function.

Salix dependency resolution works pretty well. Whenever you find something is missing there, report it. That's what I do, and it is usually fixed quickly.
JACK always sucked. It never worked without issues for me, and that on many distros. The others you mentioned are crap anyway. I can barely tolerate Elogind being a unavoidable dependency on Slackware, that's why I use FreeBSD as well.

Also, the lack of support for multiple libraries (multilib) makes programs such as Wine tougher to install than their Debian or Gentoo counterparts.

In my humble opinion, multilib is looking for trouble by design. But you can enable multilib if you wish. Highly not recommended though - on any distro.

While I can appreciate the lighter resource usage compared to Debian or Devuan, I can at least update those with the confidence that my systems won't break. Almost whenever I do update certain GTK or Qt packages, my Salix installs break (something to do with GSettings, but I have to always restore from backup). My Xfce session gets completely trashed, and my theme is replaced with a generic light one. I hate that very much, and that I haven't gotten a working solution thus far (I've asked a couple of times with no success) means I will just use Salix as a secondary distro (which isn't a bad thing at all, since I pretty much gave up on everything else outside of Debian)

None of the issues you mentioned ever happened to me - and I use Salix for 8 years. I'm not sure what exactly you are doing and causes that.

If there is one request, it would be to restore Sourcery for Salix 15.0, since there are still a lot of packages that have yet to be added to Salix's repositories.

You don't need Sourcery to compile packages from SlackBuilds... slapt-src is still there. Personally, I rarely (if ever) use SlackBuilds though. For the few packages I want up-to-date, I prefer building packages from source using my own SLKBUILDs.