I see the light. I just hate seeing dead horses in my thread.

I am well aware that the lack of PAM is a sore spot for you. That is not my focus in this thread. My focus is how people are using Slackware in busines or why not. If the reason for not using Slackware is a lack of PAM then that is all people need to offer. Thanks for understanding.

Okay, my turn I guess.

I use Slackware in my home LAN. I am happy being a "Slackware shop" at home. I have used other distros at home (refer to my sig) and at work I support other distros, but at home Slackware satisfies my needs. At home I use MATE, SSH, VNC, NFS, Samba, Apache.

At home I use a CentOS VM to remotely administer work systems. Using CentOS in the VM was a response to what is used at work because eventually the owner and other employees will use the VM. At home my VM is hosted on Slackware.

I have a single isolated Ubuntu MATE system at home that is a host to running Windows 7 and 10 as virtual machines using raw disk access. Like my CentOS VM, I maintain the single Ubuntu MATE install rather than Slackware as a way to keep abreast for work skills.

I routinely use VirtualBox on my home Slackware server, office desktop, and laptop. I tinker with other distros or work related projects, but my base everywhere at home is Slackware.

At work (WISP) we use Proxmox (Debian). We use CentOS for containers and bare metal backup systems and NASes. Three office systems run Windows. We have a spare office desktop running Ubuntu MATE and used for web surfing and tinkering.

At work we use BIND, Apache, Wordpress, Postfix, MariaDB, RADIUS, Nagios, Rsnapshot, Samba, NFS, Webmin. We run a mail server and outsource the spam filtering. We use SSH and Webmin to remotely admin systems. There is no centralized authentication anywhere in the infrastructure.

Could Slackware be used in this business? Windows prevails in the office, especially QuickBooks and Outlook. Those requirements exclude any distro. Nothing like Proxmox exists with Slackware. For the containers or backup servers? From a technical perspective, yes. From a business perspective, probably not. The owner (computer savvy and a network expert) is a "time is money" person. The owner would not forego the convenience of large upstream package repositories and updates. Being a debranded Red Hat, the owner looks at CentOS with perceived name recognition, which is perceived to mean large scale upstream enterprise support. I do not place merit in the idea that Slackware is a risky one person project because there are several developers on the team. Developers who likely would take the reigns if anything happened to the BDFL. But perceived name recognition is missing.

There is a familiarity issue. The owner's first Linux based system was Mandrake. Then later CentOS 6. As Mandrake originally was a Red Hat derivative, the change to CentOS made sense.

One challenge with using Slackware at work would be package selections and management. The stock Slackware is maintained with security packages and there are ways of being notified. So far so good. Additional packages require slackbuilds.org. This is where the availability of binary packages ends. Not all software is available at slackbuilds.org. Even if the business owner was willing to build packages from slackbuilds.org and use the RSS feed for receiving update notices, there is no policy about when maintainers update packages. Even if security patches are merged timely at slackbuilds.org, the end-user bears the brunt of ensuring the package is rebuilt and updated. Not all slackbuild.org packages are updated. There is potential for security patches slipping through the proverbial cracks. While there is high degree of professionalism with the slackbuilds.org maintainers, there is no "enterprise" policy.

A quirk with slackbuilds.org is whether maintainers update packages. Some maintainers like keeping pace with latest releases and some don't. In a business environment I think the general approach is security patches only during each release cycle. This pretty much the way Debian and CentOS releases are maintained. If slackbuilds.org was to be meaningful in that area then a similar policy would need to be adopted.

Package dependencies, especially with large scale administration, is something that falls into the "time is money" area. I dislike many of the dependency choices made by upstream Debian and CentOS packagers and I prefer not having dependencies in Slackware, but the Debian and CentOS package management system makes this easier for business users.

sbopkg would be a technical option for keeping systems updated as well as dependencies, but not something the owner would embrace. The availability of binary packages is too alluring to a business owner opposed to compiling.

I am thankful Slackware is not a member of the kernel-of-the-week club. Yet as a business owner, likely I would want a distro that keeps pace with kernel patches. Peace of mind and all that.

I understand the owner's perspective. Large repositories and a single "yum update" or "apt-get upgrade" avoids dependency issues and updates systems.

At home I maintain a local mirror of the stock Slackware repository. Years ago I wrote my own shell script to keep all of my Slackware systems synced, but in a large scale work environment I would look into configuration management tools. I cannot envision maintaining more than a handful of Slackware systems otherwise.

Regarding Slackware on the desktop, the Salix folks have a fair foundation, especially with the additional GUI tools. In a business though I don't know that the extra GUI tools provide benefit because anybody managing multiple desktop systems likely would do so with configuration management tools. Further, in order to offer users a GUI package manager, the Salix folks deviate from the stock Slackware with package management by using slapt-get. I know of no issues with slapt-get, but on a large scale using two different package management systems would be a "mild" administrative inconvenience.

From a single desktop perspective, updating my home Ubuntu MATE and CentOS VM is simple with desktop notification utilities. Salix has something similar but is a notification app only rather than a combination updater like in CentOS and Ubuntu. In a small business environment where commonly there are no skilled IT folks, having some kind of notification applet is a must. Point-clicky and all that.

At one time the Salix folks discussed hosting binary packages from slackbuilds.org. I don't know how that project is going. If I remember correctly, during each release cycle they would update packages only for security patches. I don't know how they would plan to monitor upstream for those patches.

Upstream support with CentOS is 10 years. That is not noteworthy to our work flow because Debian is used in Proxmox and the support cycle is shorter (~3 years) than Slackware (~5 years).

In summary, in my specific case at work, the lack of PAM is a non-issue but package selection, management, and security patching would be a steep hill to climb.

5 members found this post helpful.

I wouldn't say that.

Besides PAM, which I need for centralized authentication, I miss many other tools.
Granted: most of them are on slackbuilds.org, but that is not a repository of packages and maintenance falls to the sysadmin who, in my case, simply does not have the time.

Here is my "wish list" for enterprise Slackware:

• Unattended install - Manually install slackware (even with the precious help of tagfiles) is still a chore.
• PAM - because central authentication (I have zero interest in connecting to windows AD)
• Virtualization tools - libvirt is a must have for managing more than 2 our 3 VMs, but Slackware does not even offer basic stuff like qemu...
• Cluster filesystems - adding high availability to DBs or VMs or even websites is of great importance to a business. I used OCFS2 with Slackware due to ease of configuration (I had a cluster of 5 nodes only) and built in support (FS only, had to compile the tools).
• A list of dependencies - I'm not talking about automatic dependency management in the package managers. I would like to have a more modular Slackware (which, at the moment, is a "full install" monolith) and have a smaller footprint that could scale better in containers and VMs.

In my view, slackpkg+ was the best thing that happened to Slackware in recent years, as it greatly expands the base distro to include packages from repositories made by trusted community members like alienbob, rworkman, willy, kikinovak (to name a few).
This tool is the stepping stone to expand Slackware to the size of any of the bigger distros.

If only Slackware included slackpkg+, with pre-configured repos that PatV trusts (ie: Slackware team members).

Better still, make an official repository (lets call it "extra") filled by members of the Slackware team (the guys with @slackware.com in their email address hehehe) with things like plasma5 and libvirt, that already exist in their personal repositories.
Sure, this means PatV relinquishes some control, but also decreases his workload as he shifts package maintenance of things like kde or xfce to guys like alienbob and rworkman.
Just a thought... don't kill me

2 members found this post helpful.

Debian's official support cycle is one year after the following release. Which means if you install a brand-new production server three months before the next stable release, you get one year and three months of support, that's it. And that's the one single reason why I don't use Debian.

I'm a retired elementary school teacher; I don't use Slackware in a business setting. My home LAN consists of three Slackware64 14.2 work stations, one Slackware64-current laptop, an OpenBSD 6.1 laptop, a CentOS 7 box, and a Windows 10 Pro laptop. I found the other thread about migrating from Slackware to CentOS to be very interesting.
I had one Slackware work station that had a lot of difficulty communicating with my HP P2015 laserjet printer. As an experiment I migrated that unit to CentOS 7 with KDE two days ago. I was pleasantly surprised to see that my HP printer was auto-detected and set-up during the installation process with no effort required on my part.
I am a die-hard Slacker, but, CentOS has a use case for me on my home network. I'm happy with it.

3 members found this post helpful.

This is also what I prefer, generally speaking, and is consistent with Slackware proper. A few exceptions are acceptable, IMO, for major bug fixes and really big enhancements of packages that are on the top of the food chain, so to speak, i.e. are not a dependency of another package.

slapt-get with dependencies resolution is used by Salix, Slackel, Slint and probably other Slackware spin-off with no major issue that I am aware of. We have had an issue in Slint recently but due to an issue now solved with spkg, not to slapt-get itself: slapt-get can be used with genuine Slackware package management tools as back end as with spkg. Of course the weak link is most often the quality of dependency information provided, rather than the tool itself.

In Salix, Slackel and Slint at least each WM and desktop is equipped with a notification applet, salix-update-notifier. Clicking on the system tray notification brings up the application gslapt, GTK version of slapt-get, which proposes to apply the updates. Very simple to use.

The answers are in this post blog from George Vlahavas.

1 members found this post helpful.

I was working as a consultant for several years until very recently, and I set up several workstations with Slackware as a result. My usual combo was RHEL on servers, Slackware on workstations; the former because it makes server admin so easy, and the latter because it's a stable environment that you can configure and pretty much forget. These were all within multimedia environments (small VFX studios, independent artists, college radio stations, and so on).

I can't work as a consultant now due to foreign resident visa constraints, but I do volunteer for some educational ventures. For http://makerbox.org.nz, I maintain the Slackware systems provided to students learning coding, stop motion animation, graphic creation, and so on (it's a mixed environment, depending on the venue, but the company's assets run Slackware). Given more time, I'd setup and maintain more Slackware desktops at more non-profits without hesitation, but residency requirements keep me pretty busy at the day job.

I've never had a problem with setting up Slackware as a workstation for any client. Sometimes I have to do a little extra work to make simplified installers (http://nixstaller.sourceforge.net/news.php has been great for that), but otherwise it's a great machine to hand a business that doesn't WANT their employees or volunteers to be able to mess the system up, and wants the system to just Stay The Same, and keep working. The pace of Slackware major releases are JUST right for my clients. Frankly, I wouldn't have a proprietorship without Slackware and SlackBuilds.org (or I'd be a lot busier maintaining custom packages for something like CentOS, I guess).

The next best thing after Slackware and SlackBuilds.org to happen to my consultancy has been AppImages. Self-contained application distribution. They're big (400 MB sometimes) but I can post them to my website, tell the client to download it, put it on a thumbdrive, and drag onto each machine - install DONE. It's the easiest, best, most "user-friendly" application deployment I have yet to experience on Linux (outside of micro-managing things with Ansible or similar). I hope AppImages continue to take off.

4 members found this post helpful.

In an ideal word the third party repositories would include only packages with full dependencies information (at least all deps beyond a full Slackware information, not only the first level), that should be available from the same third party repository or at least from another "trusted" one. Furthermore if a package is available from several third party repositories, these packages should have the same version and content. But we do not live in an ideal world yet.

It never hurts to ask, but I won't hold my breath until that happens. And even if that happens I will continue using slapt-get rather than slackpkg+.

I have been saying this almost the 2 years I've been using Slackware/MLED. In some people minds, its being spoonfed if you don't do every single thing on your own. And then there is convenience, which is what the majority of consumers want. I don't mind paying for anything, but when I do pay, its for convenience. Your post have made my day. Thank you

About a couple years ago, I got 13 desktops from a company who had upgraded. As bad as I wanted to put Slackware on them and donate them, they ended up with Windows, because the center I donated them to, linux would have been too much for them. So I gave them convenience, Virus scanner, fully updated/patch system etc...Again, I really like Slackware, but is it fit for the majority? The movie 300 is a great example, because even though the 300 gladiators/soldiers put up a good fight, they still lost by the majority. You can only win when the odds are even or greater, not less than.

1 members found this post helpful.

There is already a binary repository from SBO: https://packages.slackonly.com/

1 members found this post helpful.

PROBLEMCHYLD,

those 300 brave Spartan aristocrats probably would be very unhappy to heard someone calling them gladiators (who was slaves, denied to wear weapons outside of arenas)...

1 members found this post helpful.

A quirk with slackbuilds.org is whether maintainers update packages. Some maintainers like keeping pace with latest releases and some don't. In a business environment I think the general approach is security patches only during each release cycle. This pretty much the way Debian and CentOS releases are maintained. If slackbuilds.org was to be meaningful in that area then a similar policy would need to be adopted.

Package dependencies, especially with large scale administration, is something that falls into the "time is money" area. I dislike many of the dependency choices made by upstream Debian and CentOS packagers and I prefer not having dependencies in Slackware, but the Debian and CentOS package management system makes this easier for business users.

55020 offers slackrepo which can create binary packages from SBo and can keep them up-to-date, as well as the dependencies. It can also set up a slackpkg+ compatible repo so you can keep things up-to-date on the clients. It also supports other package managers which have support for dependencies listed in the repo (so, if you try and install one program from there, it will pull in all the other dependencies). Unfortunately, I can't think of any package managers off the top of my head that support that. I'm pretty sure one of them is slapt-get.

The nice thing with slackrepo is you can have it build all of SBo if you want... then you set up a cron job to update it after every SBo update to have it automatically rebuild all updated programs, as well as any dependencies or parents. But, this does run into the limitations of SBo in that the updates may not be just security related and could bring more bugs than benefits.

55020 also offers dusk, which will monitor kernel.org and will provide new kernel packages within a few hours of a new kernel becoming available. He makes those packages available on his website or you can use his script to have them generated locally.

One way to help mitigate difficulties with this would be to maintain your own Slackware mirror that you set all clients to update automatically using slackpkg(+)... maybe with a cron job. But you don't set this mirror up to directly mirror official Slackware mirrors. Instead, you manually check these packages on a testing system/VM before you manually push them to your own mirror. This way, you monitor what packages go to the computers and it isn't just a blind update from Pat (especially when things like openssh are updated that could potentially prevent you from logging in remotely). For those different packages, you can just manually install them, or even tweak the packages and/or doinst.sh before you push the package to your local mirror.

With managing your own mirror, it wouldn't be as bad to set up a cron job to automatically update the system (say every Sunday evening... depending on the work schedule).

Just so it's out there... there is no official timeframe that versions of Slackware will be supported. When the 12.x releases were EOLed, the message stated that they had at least 5 years of support. But 13.0 was released almost 8 years ago, and it's still getting updates. But Pat may decide tomorrow that 14.1 and earlier releases are EOL (although, I don't see that happening). This is another difficulty of trying to use Slackware in the workplace. Many companies want to know how long they'll receive security updates for, and Slackware has no official support duration.

I don't use Slackware at work (in fact, I'm stuck using Windows), so I don't know how much I could add to this conversation short of the lack of official support timeframes being provided.

@Darth, I think earlier upnort was implying that s/he knows that PAM is important for many in the workplace. I don't think s/he was dismissing that. I think upnort was looking for the things besides PAM, since everyone knows that many businesses would need PAM integrated to make Slackware useful in the workplace.

1 members found this post helpful.

If someone wants to help monitor security updates for SBo, one approach could be to take this list prepared by the awesome people in the pkgsrc security team, monitor it for updates, and use the repology API to generate notifications, for example to the SBo mailing list and/or maintainer.

5 members found this post helpful.

Thanks a lot David for these links. That's exactly what I needed!