the people I am familiar with, not going to name names, agencies etc... most use Slackware for development/workstation, CentOS as a testbed then RedHat for mission critical. If its not mission critical then its not RedHat. Mind you, some also use Fedora, and a few use Ubuntu, but as I said most that I can think of use Slackware for their development stations.

Let me guess...

There is a category of developers who, they like or not, should bite in Linux as development stations, even they have no intention to learn Linux.

It is about the PHP developers, who need also to run a LAMP stack, and a server like environment for their work.

And, which PHP developers are probably very happy that Slackware does not ship PHP7 as alternative, not even as "volunteers-supported" SBO package...

Here's what this "insane rush" looks like.

The Fedora distribution can be considered roughly as a "beta" for RHEL/CentOS.

The RHEL maintainers freeze a Fedora release at some point. FC6 for RHEL5, F12/13 for RHEL6, F19 for RHEL7.

Then the whole distribution is tested for bugs for a minimum of 18 months.

Then the corresponding RHEL x.0 release is published.

Starting with this, you are guaranteed to have ten years of low-risk updates, which means no new features will be introduced, with only a handful of exception (which concern mostly desktop components or, as was the case recently, Docker).

Since RHEL 7.0, CentOS is following shortly thereafter with releases, because Red Hat has decided to sponsor this project by paying a salary to this fine group of volunteers led by Johnny Hughes and Karanbir Singh. At the time, the long stretch between RHEL 6.0 and CentOS 6.0 had caused some bad blood on the ML, but that was the only glitch I can remember.

As for the "stability problems" you mentioned, I don't know what you're talking about. CentOS is currently running on most webservers on the planet, and it's also the most popular distribution on the top 500 supercomputers in the world.

From what I understand, you just don't like RHEL/CentOS, that's it. But at least get your facts straight.

Niki

2 members found this post helpful.

Seems that we have more flexible rules here. I could install and configure Slackware on my system in our research institute and it happily works with our Windows server. There are some difficulties tough, I can't use it for paperless communication with colleagues due to lack of MS Office (wine is not helpful for RTL languages). That's why I have virtualbox on my system and occasionally use a sandboxed bare Windows 7 for such tasks. For the first attempt I installed Xubuntu, but it didn't boot after the first major update. Now I am on Slackware and it can handle all off network related tasks (Internet, mapping network drive, network printer, etc).

2 members found this post helpful.

You work in Iran, if I remember correctly. I appreciate the irony.

Yes, I know that is absurd.

Thanks for the lesson, but I'm more than familiar with RH clones, having used Scientific Linux since before you were even a member of LQ.

EPEL is a great third-party repo for RHEL & clones, with very clean packages. Like the base RHEL/CentOS repos, it's strictly free software. I'm using it for stuff like OpenVAS, Nikto, Glances or SquidGuard.

Nux is indeed a one-man show, but a very clean one. Lucian does some excellent work, and his repo offers all the patent-encumbered multimedia stuff & extra apps as well as a custom version of Freetype with Infinality.

On servers I usually just use the base and EPEL repos, whereas on desktops, I use a combination of base, EPEL, Nux, Adobe and then some additional third-party repos for stuff like owncloud-client or VirtualBox.

All these repos are very (!) clean, and the last glitch I had was when EPEL introduced some MP3-related stuff (after the patent expired) and Lucian had to remove a handful of conflicting packages from Nux.

Regarding the tedious volunteers-versus-professionals debate, I have two things to add. Red Hat is a major contributor to free software, and strictly adheres to the GPL (or else, there would be no CentOS or similar spinoffs). And secondly, Noah's ark was an amateur's work, and the Titanic a professional project. (Tongue in cheek.)

Cheers,

Niki

Once you get paid, you aren't a volunteer any more.

6 members found this post helpful.

<pissing contest mode on>

Then you'll enjoy this book about RHEL/CentOS/SL Linux administration basics. It's a bit obsolete now, since it's based on RHEL/CentOS 5.x. But the South French Motorway Company still uses it for their Oracle Linux training.

</pissing contest mode off>



Cheers,

Niki

5 members found this post helpful.

I have used Slackware to run dns and email servers in late 90s, and early 2000s before online services providers. For a small size company, it was very nice, until the day, regulatory requirement force you to start a compliance program because your company had been bought out by another public company.

First few year, very nice IT budget, tons money spent("wasted") on brand name servers and proprietary software (sucks). Every time there was update; it broke somethings; Nightmares, lost sleeps. Eventually; my job was gone with online service provider. I used to run a script to backup emails and burn CDs. before I was out.

When everything runs smoothly, there is not much thing to do. Good old days.

1 members found this post helpful.

The behavior exhibited in this thread (and elsewhere recently) needs to stop, immediately. LQ strives to be a friendly community where challenging each other is done with mutual respect and reasoned debate. If you can't participate under those parameters, then you'll need to participate somewhere else.

--jeremy

2 members found this post helpful.

Thank you everybody for sharing! I hope this thread is helpful to somebody. (For those who do not read entire threads, I am the original poster. )

I am impressed with the ways many Slackers are using Slackware in business. I use Slackware at home, but I use different distros at work. I nonetheless enjoy what I do at work because fundamentally I am still using Linux based systems. Just lots of fun.

Perhaps a summary of suggestions related to using Slackware in business?

There is interest for "enterprise ready" support with Slackware. My focus in this thread was primarily how people are using Slackware in business or if not, why not. Perhaps a new thread would be good for discussing how to implement something "enterprise ready."

Some thoughts about such a new thread:

A cornerstone to the discussion is PAM/Kerberos. The issue has been divisive and volatile in just about any related discussion the past few years. Opinions are split down the middle.

An easy presumption is anybody supporting an "enterprise ready" Slackware will proceed with a PAMified package base. Unless or until Pat decides to support PAM/Kerberos, the only option for an homogeneous PAMified enterprise ready Slackware would be a Slackware derivative or a chaperoned collection of packages. The key is "homogeneous" because people are using Slackware in business without PAM/Kerberos. The folks needing Slackware to meld into a mixed OS environment or support scalable central authentication are the ones who want PAM/Kerberos.

Even with a PAMified base, several points of concern remain to be "enterprise ready.".

A second cornerstone is a lack of accessible non stock binary packages. slackbuilds.org is a wonderful addition to the Slackware environment but never was intended for supporting binaries. There are binaries available by notable Slackers, but from a business perspective, managing access to multiple repos requires sweat equity.

A third cornerstone is a lack of an "official" repository for non stock binary packages. Some have suggested individual Slackware packagers could consolidate efforts by moving their repos to the same place.

A fourth cornerstone is a lack of an enterprise policy with respect to maintaining non stock packages.

Other items of note:

* Without compensation, most Slackers think non stock binary packages should not be maintained by Pat.

* Whether by Pat or others, perhaps a subscription-only model to pay for the additional time and support of providing an "enterprise ready" Slackware?

* There is no known policy for kernel patching and updates.

* Most Slackers want additional packages with minimal dependencies, often seen as problematic with other distros.

* Installing necessary dependent packages should be an automated part of the installation of any non stock package (Salix folks do this already, as do other distro package managers).

* Within each release cycle, most non stock packages should be updated only for security and major bug fixes.

* Exceptions to the security patches only goal should be allowed for certain packages. For example, LibreOffice or packages that must be continually updated to support the software's purpose, such as youtube-dl or smplayer, which often break thanks to Google shenanigans.

* Perhaps a policy guideline to the "certain packages" exception is minor point releases. For example, updating VirtualBox 5.0.38 to 5.0.40 would be acceptable, but not to 5.1.x.

* Anybody wanting bleeding edge versions of packages would resort to the common practice of compiling.

* For business users, a method is needed to ensure non stock packages are updated in a timely manner.

* Possibly provide click-and-pick options in the Slackware installer, such as web server, file server, desktop, etc.

* Perhaps provide a click-and-pick option in the Slackware installer for PAMified packages? Or perhaps enable such an option with a subscription activation key?

* For desktop users, add an update notifier.

* Improve quality control for detecting peripherals. What are other distro maintainers doing in that area that Slackware isn't?

* Support with scaling deployments, but perhaps that is something for SlackDocs? For example.

* Something more concrete with respect to release EOL policies.

Again, thanks everybody for sharing!

6 members found this post helpful.

You have a very interesting blog. I like it!

Pshaw, thanks!