Well, I voted no, but I changed my mind. This weekend I tried to do a minimal installation of slackware, where I installed A and N, with the idea to build up a small installation. It did not work well for me. It was not enough to get a system with a working network connection. Before I knew it, I added a few extra gigabytes of stuff. One would think that if A contains the base system, and N the networktools, that there would be a system running with a working network connection. But perhaps it is my lack of knowledge. Though I have been using slackware for years, got openBSD servers installed and debian servers. So I am not a complete computer illiterate.

Compare that to debian, where a minimal install including network and some extra tools, is at least below 1GB. Even a full ubuntu installation with virtualbox and some other software is below 6GB. There is no justification for a desktop user to have an install of 10-12GB, where you haven't even installed any of your software, unless you absolutely want to have slackware installed. Realistically you can assume that the audience, that is interested in slackware, probably chooses it because they want more control with a DIY mentality. But when it comes to the software selection, this part is probably too hard for newcomers. Oldtimers probably have no issues with it because they have been using slackware for years, but I think it scares away a lot of new users, that see that the software sets (a, ap ..etc) in slackware make no real sense to them. Which is a shame imo. An influx of new users keeps a product alive, otherwise it will just die off.

It would not be a bad idea for slackware to have a similar installset like Salix(minimal, minimal+xorg+xfce, full),and then have some sane choices for a dev set ( with c/c++, python,java). That would keep the install size at a reasonable footprint. Salix just does that right, with many other things. Sticking to certain principles and methods that work is a good thing, but becoming stale is not.

Slackware is not for people who want a minimal install. Your complaint is like criticising a HGV for not being as light as a sports car. Apples and oranges.

What HGV? You mean a slow school bus...

And still you wonder why a handful of people bought it.

Heavy Goods Vehicle.
https://en.wikipedia.org/wiki/Large_goods_vehicle

Is HGV a UK only term?

Play safe and call it just a "mega-truck" or "heavy truck"

I haven't seen that anywhere in the manual nor on the website of Slackware. Also, there is a lot of gigabytes between a minimal install and 10-12gb. That's why I mentioned Salix way of dealing with this. It's better to explore ideas and keep an open mind, then to just state "Slackware is not for people who want a minimal install". That's just reasoning with blinders on.

Whether the website or docs say it, or not, it is what it is. And what it is, is not designed for a minimal install. Lack of dependency management alone should signal that to you. If you still can't see that then ask yourself why Salix even exists?

From Slackware-HOWTO on the install media
Unlike Salix, Debian and others, Slackware has no official binary repository. Instead, Slackware has SlackBuilds.org, which allows a user to download build scripts for third-party software. These scripts are tested and maintained for stable Slackware releases. So installing the development series is required for adding software to a Slackware install. I, like many others, make use of trusted third-party binary repositories to ease the installation of software with lengthy and involved compilation. e.g. LibreOffice, OpenJDK
The full install comes with a range of desktop environments and window managers, multiple web browsers, mail clients, IRC clients, editors, file managers, office software as well as server tools httpd, mariadb, mail server, DNS servers, Samba. This provides a solid base on which to build a system tailored to individual needs. When I compare 10-12GB with a working Windows 10 install, Slackware looks measly.
I see this thread as a way to explore the increasing calls for minimal install options for Slackware in specific situations, but the requirements need to be defined. History teaches that people who prune without knowledge of Slackware can get unexpected surprises.

I can see the need for a tailored "least MB on disk for working network install" TAG file.
But i just doubt there will ever be "minimal server" or "minimal desktop" - this is and will remain for individual users and fun to read threads here on LinuxQuestions.org.
Looking forward to those :hattip:

But, to play devil's advocate, how would you deal with installing additional packages since Slackware lacks dependency management?

As I've said before, the people who can deal with Slackware's lack of dependency resolution are perfectly capable of maintaining their own minimal system (although, they may not want to spend the time themselves to create one)... but the people who struggle with not having dependency resolution should not be running a minimal Slackware system. Having that available for new users wouldn't help Slackware, it would lead to many more "reviews" about how difficult Slackware is, how hard it is to add additional software, and how easy it is to break it.

@bassmadrigal many pieces of Slackware ecosystem are scattered around. Even after installing full Slackware they will have to deal with all what they think is missing. It is in fact very similar task to install only subset of packages to create own installation. Just someone help is needed.

In the defense of the idea (perfectly aware we maybe are dissecting a unlikely scenario):

While i can imagine there will be people who try it only to end up stranded, and things like that happened to me before, the point of minimal install - and use cases - are mainly two:

1. One wants to make a resource limited environment that is therefrom capable to be self-enhanced to an arbitrary level of complexity - the containers and virtual machines folks.

2. One is resource constrained in the installation phase and as soon as the install process is over, and control taken over by an installed system, said discomfort is alleviated - be it drivers, human interface, performance or any other handicap really - the folks on the marginal platforms (ARM, PowerPC, A390?) Slackware has been or is yet to be ported in the future.

Neither of those are people ho want to "fire and forget" the installation, and the big fat warning certainly applies, but still the group i "represent" here might be quite a game changer should Slackware come with some sort of official support or recognition for that niche.

Then there are those (most rare group) who try make the somewhat broader "bootstrap root" - the minimal system of Slackware packages able to compile each and every package of the whole.

I happened to read that thread here on LQ, and couldn't stop to be amazed how arduous that happens to become during some specific stages or advances of the source in question. I imagine those would benefit of having them someone "chewed up" at least the list of what packages are "in" for the time that particular release was current and relevant.

But, yes, we can't (and shouldn't) prevent the stray newbie come across that, tries to use it and come here (or where ever) complaining how it broke his boxen.

Then, again this might offload some of the pressure (and boxen breaking guilt!) -current was under all this time ;) instead.

True, but almost all 3rd-party solutions will provide some sort of dependency list on what is required to ensure that software runs properly on Slackware (although, these lists are only for other 3rd-party packages and don't include any official packages, since they typically only support full installs).

The problem is if they are provided with a minimal install (and what is considered a minimal install is a discussion in and of itself) and they want to install another official package, how are they going to know what other software it might depend on? Slackware doesn't provide required dependencies for packages, so there's no easy answer beyond searching unofficial resources (I know Salix provides a dependency list) or digging down and figuring them out themselves (run the program and hopefully decipher the output to find what program(s) are required to properly run it).

Resource limited devices (and by "resource", I only mean storage space, since nothing else will be run unless the user runs it themselves) are becoming less and less frequent. Yes, they still exist (and are probably still being produced), but with how frequent they are (and the users desiring to run Slackware on them), it is an extremely small group (even by Slackware standards -- in comparison to usage by the "big" distros like *buntus, Debian, Fedora, Arch, etc).

But does the group you "represent" only run devices with limited harddrive space or are they more driven towards the "only install what I use" mentality. That's a fine mentality to have and works great with many distros, but that mentality becomes exponentially harder when you use a distro without dependency resolution. As I briefly mentioned in the above thread, what is considered "minimal"? Is it just bootable? Bootable with networking? Bootable with X? Bootable with networking and X? If X is included, what WM/DE should be included? Some are perfectly happy with a basic WM like Blackbox, where others would prefer a more robust system like XFCE, while others would only choose KDE. And if we go back to what should be supported, are we shooting for a "desktop" (bootable, networking, X) or a "server" (bootable, networking, LAMP), or something in between? And what if someone wants a minimal server that provides X?

Pat has never wanted to state what Slackware should be used for. It is equally setup for both desktop and server usage. If you take some of those away, the users who want a mix of both (but "minimal") suddenly have to install software beyond what the "minimal" system contains, but then Slackware doesn't provide dependency resolution, so installing something new comes with potential problems.

Do you really think that users that aren't capable of slimming down Slackware themselves are capable of building it up from a minimal install to a working result with official packages?

Not to mention the extra burden on Pat himself to ensure that everything included in a minimal install works properly and that he stays up with the required dependencies as -current moves along its development track.

I'm glad you have brought that up.

in that thread where the containers and VM where discussed, and some other threads too, it seems, a quite universal conlcusion was reached of what belongs to the "minimal" install.

The system has to be able to perform only the following tasks:
1. boot (obviously)
2. bring up networking and serial ports if present
3. enable a remote login (be it via net & ssh, or via serial port)
4. have one tool that enables download from network (curl? wget?) via a supplied URL
5. have tools to install an locally referenced package

And that's all - eventually a bare minimal text editor - just to not use ed.

it fits about 128MB really

----

There is currently a trend to make ever more RAM constrained specialized ARM SBC systems that actually fall well within the territory where Slackware excels - LAN routers and servers.

One of them being 256MB ram falls just short of being able to run an Slackware install, for instance, but boasts an quad 1.2GHz CPU and twin Giga LAN ports. Its worth nothing that Slackware runs effortlessly once installed on such a machine - provided you serve IMAP and SAMBA without X.

----

The virtualization crowd really wants a "seed" - a same barren setup that once cloned can be custom fitted with whatever - emphasis on smallest memory footprint as it will be run in great many numbers. They then custom tailor scripts that install whats needed per use basis. And whatnot. Just something as barren as possible still able to log into and run #slackpkg install-new

---

All I say is, we're talking of an list of max 20-30 packages that, once established, isn't drastically changed across many releases. The lists should be answering "what can we omit and still be able to acquire a package and install it?".