kikinovak,

I'm glad for your letting us know of this change, although the first place I looked for info (after slackpkg+ started to fail on your repos) was the project's website and nothing was found.

I used packages from your repos (mostly libvirt related) as I always found them to be of highest quality.
Thank you very much for your effort in making Slackware better. I'll miss you and your work.

I also agree with you that Slackware is not suited for enterprise (personal opinion).
When your business depends on it, you sometimes have to use the tools that fit the needs, not the ones you'd like to use.

Good luck.

3 members found this post helpful.

When it comes to software in business there are two rules: the first is stability; the second, predictability. Businesses need to trust that software will run reliably, and they need to know its lifespan will not be curtailed on a whim.

Slackware has existed almost as long as Linux itself. It is, therefore, both stable and predictable -- stable as software, and predictable as a project.

Although kikinovak kicks up a great fuss about software in the enterprise, his MLED fails the predictability test quite spectacularly. Based on Slackware, it was undoubtedly stable, but as a project, it was obviously unpredictable, bordering on volatile.

Overnight, kikinovak abandoned his enterprise clients who had committed to MLED. No warning, no explanation at his website. After many years vaunting the project, he then tore it down overnight, leaving his customers stranded. That might be fine for a personal project, but it is far from acceptable for businesses, at least here in Ireland.

So you're quite wrong to say Slackware is not fit for the enterprise. Its track record says otherwise. If anything is not fit for business use, it's MLED.

2 members found this post helpful.

I never said that, and I think Slackware is great for businesses. It's just that one of the main reasons for me to switch was that I get a similar end result with much less work (and more time for climbing).

The website and package repos disappeared overnight after a fatal server crash in NFrance's datacenter in Toulouse. It took me a few days to setup a new server - in a different datacenter - and restore everything, because I had several websites, mail accounts and other things on that machine.

As for "abandoning my clients", I don't know what you're talking about. My clients are fine, I've moved all their installations to CentOS over the last few months. If you had read my initial blog post, you would have understood that MLED has become way too time-consuming and almost impossible to manage. And since I do value things like spending time with my charming girlfriend or going climbing with my buddies, I decided to move on and use something that gave me a similar result with much less work.

Isn't that the way free software works?

Niki

3 members found this post helpful.

Once you label your project an "enterprise" product then your girlfriend and hobbies no longer come into it. Anyway, the main point I was making is that Slackware, unlike almost every other Linux distribution, has been stable and predictable for 24 years, Patrick Volkerding's personal life notwithstanding; it is, therefore, at the very least equally suitable for business use, where predictability trumps marketing slogans.

You forgot a third rule: manageability.
Caves have also existed for as long as "places where humans take shelter".
Yet, we take shelter in houses now.
Should we use caves instead of houses?
Older does not mean better.
The fact that Slackware is the oldest linux distro still maintained today does not mean it is the best one for all purposes.
It is indeed the best tool for some projects (again, my biased opinion), but not all.
Yes and no. The only part of MLED that failed was the maintainer (kikinovak himself) who failed to predict the workload required for the job.
Had he used other tools (like Spencer said here) it would have probably not failed.
Even for a small business like kikinovak's "one man show" it is quite difficult to use Slackware.
It is just too much work.
For example: securely maintaining the same user list across 100 desktops is a full time job.

As for the "track record": citation needed.
It is quite easy to use Slackware as a single server and it works well.
It is not so easy to add 1000+ packages of "unsupported" software to Slackware by hand, testing and maintaining them.

Your boss will not risk the company's future on your availability.
What if you are on vacations, or sick leave, or leave the company?
Will the next sysadmin be able to cope with your workload?
What if the company grows and instead of 100 desktops you now have to support 1000 or 10000?
For enterprise, the workload must be similar for either 10 or for 10000.
With Slackware as a base, it simple isn't. It simply does not scale well.

Yes, just not your business

1 members found this post helpful.

Right except that time where we went 2 years between releases because of Patrick's health issues. I am not saying that to criticize Patrick or Slackware in any way. Just to allow for the fact that there is risk in a one man show. Its not like anyone's Slackware systems suddenly quit working during that time. It was a period where building third party software got hard because a lot of libraries and things were very dated.

I have no problems recommending Slackware to business for certain functions. There are use cases like kikinovak where it might not be the best tool.

I'm a sysadmin, not a priest.

3 members found this post helpful.

Here is a slightly modified quote from Laurence J. Peter in The Peter Principle: Why Things Always Go Wrong:

2 members found this post helpful.

My TWO cents...

Even in a small office, or a school, the Slackware acts like this classical anti-social kid who talks with no one.

I really hope that in a bright day, the Slackware developers will figure out what big UN-favour do to Slackware, not arming it with LinuxPAM and Kerberos.

And please do not suggest me to do it myself, because that would be equivalent with forking Slackware.

And usually a small company would do not have the will to fork and maintain, and be responsable for a Linux distribution.

Yet, LinuxPAM and Kerberos are NOT your well know public enemy SystemD, they do their job almost invisible, with no significant speed-up of system boot and they even not ask you to change the init files.

They would just do their job silently, and their would be much much much more easy to be integrated than that desktop environment developed from scratch and called by its mother, with love: Plasma5.

Noted and makes sense. Best of luck to you and your business.

Cheers from Sunny or Rainy Philippines.

1 members found this post helpful.

Indeed, but I remember CentOS not releasing updates for an extended period as well. An enterprise will assess the risks attending all candidates for adoption and choose that candidate least likely to surprise. Lack of PAM support is not a surprise; an enterprise with 1,000 workstations can work around that, and they have the IT staff on-site to do so. The sudden adoption by an enterprise OS of something like systemd is a surprise, and I don't think many enterprises were happy to have that trap sprung on them for no compelling reason.

Nobody likes a sneer.

If you're talking the time between 14.1 and 14.2 (which is the only time there went more than 2 years between releases -- prior to that, there was at least 1 release per year going back to its initial release), there were never any reports I saw of health issues. In fact, for almost the whole development time, there was constant movement in the changelog. However, there was a period of 47 days between 5 Mar 2015 and 21 Apr 2015 that saw no updates in both -current and stable's changelogs. There was a lot of speculation on why there were no updates, but no official information was ever provided on the delay other than what was in the changelog (which is quoted below -- and I think the closest we'll have to why there was a gap is highlighted in red):

There was a period between 10.0 and 10.1 where Pat was battling an illness, but that happened back in November of 2004. He was eventually diagnosed with Actinomycosis, but he has been able to continue providing updates, including 10.1 which was released in February of 2005.

While it is true that there is risk in a one man show, it has been stated elsewhere (my memory fails me and I'm too lazy to search) that if Patrick decides to stop working on Slackware (or, heaven forbid, he is unable to), that there is a succession plan in place. There are some great people who work very closely with Patrick who share similar ideals, so it is likely his vision would remain, even if he didn't.

3 members found this post helpful.