You can't kill slackware!

1 members found this post helpful.

That's not a fight you're going to win. Dependency resolution is one of those things that people either don't mind going without or absolutely refuse to go without. Even if in practice once you get the software you need sorted and you go months at a time without ever needing to mess with dependencies.. it won't matter. Telling somebody to manually install one when they're used to a package manager doing the work for them is going to be off putting, and you'll get responses often along the lines of "I have better things to do with my time". Frankly, having had times where I simply could not get software I wanted to use running without hours of troubleshooting.. I am in no position to critique this.

Slackware gets a pass because it's the only distro that has never randomly broke on me without it being my fault and it being obvious what I did wrong. I've tried nearly a dozen other distros where I boot it up for the first time in a few months, update it, and all of a sudden everything is broken. Not so much with Slackware..

They have only themselves to blame.
We have slackbuilds, where a package adapts to the system and not vice versa. Which, with the multitude of "soft" dependencies out there, is the only sane approach; if a program or library can link to a dozen different things for the fun of it, it is for me to decide which part of the menagerie is relevant to what I need it for.
People who want software on "their" systems be mismanaged by third parties, have a multitude of unstable distros to choose from.
Reliability and stability.
Among ourselves. Common users are trained out of the very concepts.

4 members found this post helpful.

12 pages so far, and the OP hasn't chimed in yet. Perhaps I underestimated.

I think slackware takes a pragmatic approach - so it's not one of the little projects founded on ideology, which usually tend to be based on some other distribution's hard work, which is in turn based on the funding and developers on the corporate payroll. Slackware has a philosophy and cuts out the middle man, so the developers at least develop.

While I don't necessarily believe elogind is the answer either, I believe the decision to adopt it was a pragmatic one, not one one born out of some preference for systemd - as systemd itself is still not included.

Unless that is, you count udev. Again I don't think you'll find this "every last remnant..." ideology is widespread. Even Devuan left remnants of systemd in, but then later worked to remove everything possible just to appease some fanatics among the user base. And even the fanatics can't get along, as is the very nature of fanatics...

I don't think the Devuan people who actually do the real development like the association with some of these people - people who bring their political and ideological soapboxes to every thread, but users are users and they likely feel that they have to suffer them for now. Like trying to find the best way to ask that embarrassing obnoxious relative that it's time to leave...

I find it hypocritical that you deemed to lecture me from your pedestal in the echo chamber, regarding supervision suites, but then blasted the slackware developers and project with expletive filled rants.

4 members found this post helpful.

I feel like I have to comment here because it took a lot longer than I expected it to. But eventually Maynard's knack for interesting time signatures won me over, and now I'm a big fan of Tool.

8 members found this post helpful.

Maynard seems to be kind of an asshat, but by Dosh, what a vocalist.

It is updated every couple of days. The main thing is happening in the -current branch right now.

Is this a troll post?

You should install it if you are a technically minded person, who would not mind some fiddling to get your perfect setup. Maybe wait for the stable 15.0 to come out.

Thing is: Slackware is the most stable OS I have ever used. Most times, the only reason I update my non-system software is out of habit or boredom. Things never break on the stable branch, and very rarely on -current.

Can you explain how are you running steam using flatpak without multilibs?
Here are asking for 32bits
Edit: found the problem, i forgot apply this options inside my kernel now are everything ok.

Attached Thumbnails

 

I tried using the flatpak, but ran into issues if my NFS shares were active (which they almost always are). I found I needed to shut down the NFS server to be able to run the Steam flatpak.

More recently, I found out about conty, which works great on 14.2 (after some back and forth with the dev) and steam works great without multilib being installed.

1 members found this post helpful.

Welcome to the official Slackware forum, sematik! Agreed!

Chiming in because I decided to check after having switched away for a couple of years now.

Slackware to me is a really complete, rock-solid base I can build anything on top of, and modify the inner workings of with little to no resistance. Other distros tend to either move quickly enough that they're a pain to modify or just make it very difficult to.
The -current branch undermines this use for me: I have to keep a close eye on development to avoid falling behind too much, packages I modify need to be repatched more frequently, and software I configure in a certain way changes its behaviour from under me. All of these things are things I can avoid through the stable slackware releases.
Unfortunately, with 14.2 being so old, many programs are starting to depend on newer libraries and tools than the system provides, and hardware is starting to require newer versions of core system components. This means upgrading these components to their -current versions, and dealing with possible breakage, but after a while this becomes unmanageable, and prevents me from using newer versions of some tools I need.
Slackware would be perfect as a bi-yearly release. I can deal with three years, but five is a bit much for a desktop system.

As for the website, since that was brought up in this thread, I feel like you could just copy the ChangeLog.txt headers that volkerding writes on occasion and just put them up on the front page. Those tend to be the primary means of communication regarding major changes and general development progress, and it was quite unintuitive to me as a newbie to find them hidden on a mirror (I didn't discover the link on the homepage until later) and buried under a slew of package upgrades. Contrast this to archlinux.org and gentoo.org/support/news-items/ (the latter of which shows up during updates).

3 members found this post helpful.

Back when I started with Slackware at 10.0 we did have bi-yearly releases or once a year or so. I run OpenBSD and it follows the twice per year release schedule which is nice.
The Linux ecosystem has become increasingly complex over the last 19 years that I have run Linux. I can only imagine what it must be like to maintain a distro. Slackware will be released when our maintainer decides that 15.0 meets his standard for excellence. There are other distros that have releases that are unusable. I can wait. Slackware 15.0 will be amazing.

1 members found this post helpful.

Regarding gaming on Slackware and dependency resolution -

I watched a YouTube video by a regular Linux advocate entitled something like "the 5 best gaming distros". First place was Manjaro and a close 2nd was by PopOS. So I installed both on my Main boxen, mirrored my Steam games and installed the latest versions they had available for WINE and Vulkan. I played the same games from the same drives for many hours on each for overall feel and also used several benchmarks.

Slackware beat them both and not by a little bit, 11% and 13% respectively on average. Some of that may simply be my own lack of understanding to turn off autostart services but that should be minimal since I used KDE on each and System Settings offers excellent transparency and control. I figure the major reason is that I used stock kernels and nvidia drivers offered by Manjaro and PopOS while my kernel and drivers on Slackware are a newer version and customized for performance.

Automated dependency resolution commonly restructures so much of the base system that I strongly suspect this is also a factor in reduced performance. Naturally Slackware wasn't even mentioned let alone tested but I did comment with my results and concerns.

8 members found this post helpful.

So elogind is only necessary if you wish to run KDE/Gnome? I can forego installing it if I use a window manager like flux or ice, correct?