Ok, just do it. Then we will see. Or who is supposed to do it?

Okay.

1 members found this post helpful.

I think the more pertinent question is - how small would the core team allow the userbase to get before revising Slackware's ethos? I agree with the OP, largely. One can only resist change for so long and I think Slackware will need to move on at some point if it wants to usher the next generation of users in. It will have to do something because all it has at the moment are nostalgic ex-Unix users, curious hobbyists [of which I self-define] and some 4chan and Reddit users who use it to look cool. Those numbers will dwindle more and more as the older generation dies out [sorry, but it's true], and it can't have escaped the notice of the forum that the gap between Slackware releases is ever-widening most likely due to the difficulties of retaining Slackware's model in the 2020s.

That said, Slackware has had, up till now, a cast-iron ethos of not automating dependencies. It's part of its identity and its raison d'etre. However, it is horribly inefficient. As I said in another thread recently, it took me two hours - me, as a relatively experienced Slackware user - to recently update an old system's kernel and all its packages. I found it frustrating. In Debian this would have taken about five minutes. The other thing that I was surprised at, which I had forgotten about, was the length of time Slackware took to boot up and shutdown.

Remember when Debian switched over its init? Who can forget the fights, the arguments, the recriminations; it was brutal. But I think they did the right thing, they just did it sooner than a lot of people were expecting.

The arguments for not automating dependencies are "it is just not needed", "it gives you more control", "it's more Unix-centred" and "it's more stable". These are all totally valid arguments, though, in the case of stability, OSs like Debian are perfectly stable these days. Slackware currently exists as a relic of a mostly bygone computing era and to say that "Slackware is Linux" is no longer as accurate as saying, "Slackware is the traditional form of Linux". As time goes on, Slackware will have to make a choice, of either sticking to its guns and facing a smaller and smaller userbase as it antiquates and risks irrelevance and deprecation, or changing something about its identity in order to remain relevant to new users. Maybe 16.0 is a good time to think about this... or maybe not. For me, Slackware is just an enjoyable experiment which I play around with on older machines, but I cannot use it as my main system anymore.

"They can live in my new world or they can die in their old one." - Daenerys Targaryen

2 members found this post helpful.

No dependency checking? That's fine. I'll do it my self. It's not like I'm superbusy. I have the time with me.

2 members found this post helpful.

I can imagine that.

Easily horrified? Nervous wreck? Take slow, deep breaths...calm down.

2 members found this post helpful.

You're missing point. Say OP will establish such system I will test it. It can be useful for custom installation. It is not easy to establish kind of minimal Slackware installation. It is not to go pro- or anti- Slackware ethos. Just some people can find this useful. So no need to kill this at the beginning. If OP is capable to do such thing, we'll see. Myself I can promise I will test it.

Edit: We are not Faith Purity Guardians here. Let allow people to do something. We'll see.

Lysander666, I am puzzled by your comment about boot times. I do agree that systemd does shutdown quicker but why would anyone care about that? Just hit Power Down and leave since you are apparently not using your PC any longer. However I have tried numerous systemd distros, Debian (both Stable and Testing), Arch, Manjaro, PopOS, Ubuntu, CentOS, OpenSuSe and a few other oddballs. None of them always boots faster than Slackware in my experience and if anything hangs at all on systemd's parallel arrangement it can take agonizingly long to boot and even longer to suss why.

If you are experiencing slow boots with Slackware I'd like to suggest building a custom kernel with "make localmodconfig" and turning off any services you don't actively use. Surely one can theoretically do that in any distro, even those using systemd, but it is a vastly more complicated process and still, once accomplished, boot time will sometimes hang on some device that doesn't respond in what systemd considers a timely fashion.

In fact, I'll be right back with an actual timed comparison... BRB

###
EDIT
###

OK. Back. I just booted consecutively this Slackware Current to compare with OpenSuSe, which incidentally I rather like at least compared to other systemd distros. Slackware booted in 12 seconds to runlevel3. One of the reasons I "rather like" OpeSuSe is that it isn't impossible or a royal PITA to boot to multi-user terminal... but then maybe that too is evidence that I'm some sort of "throwback, nostalgia ridden" dude Anyway, OpenSuSe took 25 seconds, a little more than twice the time. Granted it shutdown in half the time of Slackware but (and this may be just an odd artifact of my machine or BIOS/UEFI settings) rebooting from Slackware was flawless and rEFInd came up perfectly as it is supposed to but rebooting from OpenSuSe, while it did launch rEFInd, it came up with no USB active, no keyboard or mouse. I had to push the power button to be certain BIOS/UEFI would properly recover and it did and bingo! 16 seconds later I was at my Slackware Desktop.

Similarly while fixing a severely damaged Win10 hard drive belonging to my Brother ( I'm working on him as well as his install ) I installed that drive on my system to verify it would succeed in booting. It did boot successfully (and I sent him the new drive with the repaired system on it) but shades of days past, while it got to Desktop quite quickly, I could do nothing for about a minute while it continued to load stuff.

My Son wasn't so lucky as BitLocker encrypted his entire disk and being a corporate laptop the key from several years ago was no longer available. He had to plunk down almost 140 bux for a new iso while losing everything he had amassed over 5 years.

I only mention the Windows items not actually mentioned in this thread to point out that

CONVENIENCE COMES AT A PRICE! Unfortunately we most often don't get to see the cost until we are forced to pay for it. No thanks. I'll stick with "ancient" Slackware's horrific old ways.

1 members found this post helpful.

I think Pat is not totally closed to fundamental changes, think of PAM, for example. Systemd and dependency checking (DC) are two other "controversial" changes I can think of but I feel that there isn't sufficient amount of push in their favor. DC would be the more benign of the two but although many of us would admit that it is a convenience, almost none of us suffers enough inconvenience to want to take risk by making a change.

I sometimes install this and that popular distro on a spare partition to see how they work, or sometimes because I need some Qt5 software which I can't run on Slackware 14.2. Their installation and management tools are a lot better than what you would find 10-15 years ago and the experience is much smoother, but to my surprise, so far none of them provided the stability I have in Slackware. It really gets on my nerves when some "automated" thing fails and then you have to do all sorts of weird workarounds to get it fixed because the system was not designed to be managed manually in the first place. Slackware is so solid and it matters so much to me that I would rather have that little bit of inconvenience than seeking adventures.

2 members found this post helpful.

The absence of a tightly coupled dependency graph in Slackware allows experimentation. One experiment could be to write a package manager that provides dependency resolution. In fact Salix Linux has added just that (along with other things).

"Linux is a space of freedom", and perhaps we should preserve the 'biodiversity' a little?

Recuperation has an odd logic of its own. Perhaps Slackware will become popular with a certain segment of younger people, in the same way that lava lamps, radiograms and bright primary coloured oven-ware have. Or perhaps not - things do have a life cycle after all.

2 members found this post helpful.

I am fine with the way things are at the moment: my Slackware installation provides a relatively broad base of software, which I manage with slackpkg. On top of that I install whatever I need from SlackBuilds.org via sbotools, which provides an automated dependencies resolution. For me that's a nice compromise.

Yeah. How long do you cut a piece of string? Answer: Long enough to be useful.

8GBs is nothing these days. Stop acting otherwise. Anyway, you have it wrong. It's 16Gb and 1,560 packages.
Go back to Debian and you can deselect to your heart's content.
Yeah, the fact that Slackware is unique is a positive thing, isn't it? Otherwise, itd be just like all of the others. Where's the fun in that? You want Crux, go use Crux.
Gee, I wonder.

1 members found this post helpful.

For some people it is a horribly frightening concept that Slackware allows you to break your own system where you then have to confess "it was I who broke it" instead of pointing to the distro's management tools and sighing horrifically relieved "it was not me, it was the stupid software".
Think this: what is the appeal of Slackware Linux? I think: it allows you full control.
What will remain of that appeal if you make it more like Debian, SuSe, RHEL, Manjaro? Nothing.

21 members found this post helpful.

There's more than one kind of dependency checking. The OP mentioned Crux. I used Crux for many years and liked it a lot. It does have a form of dependency check but one that is quite different from the Debian/Red Hat model which most people here are familiar with. There is no central dependency database. Instead the pkgmk script (the Crux equivalent of a slackbuild) has a section at the end where the writer of the script lists those dependencies that he/she has used for the build. The package manager uses this section to identify any extra packages that need to be downloaded.

Now Crux is source-based but in principle a similar kind of thing could be used in some kind of Slackware derivative. This would avoid the Achilles' heel of Debian-style dependency, the database, which is always in danger of becoming corrupted due to a bad or interrupted update. Believe me, when apt goes bad, it really is a pig to put right again.

It would also preserve the great advantage of the present Slackware system, the fact that you don't need to install a load of bumf to make a package work. If you don't like Patrick's build, you can download the source and the slackbuild and redo it with your own parameters. This wouldn't be possible if a dependency database was introduced. But it would be consistent with a distributed dependency system in which it was up to the builders what to put down as the dependencies of their packages.

9 members found this post helpful.

You could not be more wrong there pal.
How old are we talking? I just updated to kernel 5.11.11 in about 2.5 minutes flat.
Because you're a Debian user at heart. You don't get Slackware and you never will. That has always been the case with Debian users. Slackware vs Debian is an age old fight. But it's OK. I flounder using Debian.
How about: The whole system is on the iso. You don't need dependency resolution if you follow the recommendation and run a full install, because there is nothing to resolve. It has all been done for you. If you want to add stuff, by all means do it. The tools are provided.
Does every Linux distribution have to be the same? Gawd, what a dystopian future you're aiming for.
Great. Good for you. I not only use it as my main system, but I also use it on practically every computer in my life. It powers my NAS & media centre, it powers my OpenVPN server, it powers my off-site backup machine, it powers my laptop and work computer. There are not enough Slackware boxes in my life.
"Here's a nickel, kid. Get yourself a better computer." - Condescending Unix user

6 members found this post helpful.