I did give Ubuntu a spin last summer in a production environment. I liked the long term support, the documentation and the fact that every package under the sun was available. What I didn't like was all kinds of weird malfunctionings, freezes and bugs all over the place. NFS shares mysteriously disappeared and clients had to be restarted, printing ceased to work once in a while. After a few weeks of pulling my hair out, I just wiped everything and reinstalled Slackware on the servers and the desktops.

I'm still not sure about CentOS. Version 7.0 is 64-bit only, but I still have to care about a lot of 32-bit hardware. Their new installer is, well, the opposite of the Slackware installer. It needs at least 1 GB RAM, and it took me a whole afternoon to figure out how to do RAID with that abomination. I loved CentOS 5.x, I sort of liked CentOS 6.x, and 7.x... it's a mess.

Now if only Patrick Volkerding could hear the voice of reason and implement PAM (and Kerberos while we're at it), Slackware would be perfect for a business setup.

1 members found this post helpful.

Just a short -and subjective- feedback on Linux distributions around here:

RHEL - all the corporate visibility (at least in north america). Recruiting is easy. Certifications, professional training, etc. It's everywhere. Synonym of linux in many places.

CentOS - Same as above for smaller (or cheaper!) companies - you get trained people but don't pay for support. Scientific linux plays the same role in some limited circles.

Suse - an old glory. Used to be pushed by IBM, so considered in many shops as respectable, but clearly not mainstream. A strong (but dwindling) fanbase. RHEL certification almost applies, so... risk is acceptable for some managers.

Debian - In every (large enough) company, there are a couple of debian servers. Installed and managed by a couple of sysadmins who run tons of RHEL boxes, but who like debian, maybe have it at home or even contribute to it, and have enough clout to force debian on some corporate boxes (or VM now).

Gentoo, Slackware: In many places, one finds a sysadmin who runs Gentoo or Slackware at home, and boasts about compiling everything himself or using the oldest distro... but no corporate interest in any form. As long as the guy is certified and handles the RHEL boxes and doesn't pollute the malleable minds of junior sysadmins...

Ubuntu - Aaaah, this one at least is known. Mostly for home use. Despised by sysadmin veterans, but suprinsingly used by corporate developers. Need the Android dev kit? need a proprietary cross-compiling env for some obscure SoC? Want the new fantastic Eclipse plug-in? All on-line recipes and tutorials will assume you have Ubuntu on your desk.

I don't claim for any accuracy, or statistical significance or anything. Just some feed-back from various colleagues at various clients.

I don't know much about Linux usage in Europe. Would think that Debian mindshare is higher and RHEL lower, but I've no evidence to sustain this.

Niki's approach is very interesting. IIUC, his typical customers are small enough not to be polluted by internal IT teams and could prove to be a fertile ground for Slackware. I wish him all the best.

+1 for PAM.

1 members found this post helpful.

Me too. Especially in talking about evolution with a bunch of creationists.


Cheers

Deleted. Sorry.

RESTORED:
The dropbox package in extras-14.1-32bits has "x86" arch which makes the package invisible to slackpkg on 32 bit systems. If I am right there are no other packages with "x86" arch in mled, mles, and extras repositories.

Why? Your bug report was valid.

@kikinovak,
Thanks.
I tried to reproduse it some time ago and saw dropbox in "slackpkg search dropbox" output. But I did not pay attention to arch field and decided that was wrong somehow and need more investigation.
Sorry once more.

While we both complain about the absence of PAM and Kerberos in Slackware, I think posting derogatory remarks is not the way to go if you want to change things, ivandi. You do have impressive technical skills, so the best thing would be to add a little diplomatic sense - and some patience - to it.

Here's how I would go about it. You've done some incredible work with implementing PAM and Kerberos in Slackware. Why not, for example, setup a package repository for 32-bit and 64-bit Slackware, that can be defined in slackpkg+, with a set package priority? Then you publish a little document (very short) explaining to folks how they can "PAMify" their Slackware installation by editing a single line in slackpkgplus.conf.

By doing this, there's a fat chance some folks here would use your work... and after some time, when everything works well, it would be merged into the official distribution.

On a side note: I have a very clear idea about what would be the perfect Linux distribution. It would be a strange mix of the old Red Hat Linux (the one that stopped being developed at version 9.3) and the actual Slackware, based on RPM and Yum (I will get flamed for this, but what the heck), with a release cycle of one new version every two years, and support for 7 to 10 years. There would be two different desktop environments: a beefed up Xfce, and a trimmed-down and sanitized KDE desktop. Unfortunately this perfect distro doesn't exist, so in the meantime I use the one that sucks less and try to adapt to its shortcomings (even if I can also rant on occasion).

Cheers,

Niki

sounds OK for me, except that yum needs to be replaced with zypper

Hmmm... It seems to me that it is still wrong.
Some time ago slackware user NK reported at Russian linux forum that 'slackpkg search dropbox' didn't found dropbox package from mled extras repo. He used 32 bit system. I could not reproduce this on Slackware64. When I run Slackware 32 in VirtualBox VM with his slackpkgplus.conf and old repository state I stil can not reproduce the bug (note "x86" arch is ok):So, yes, dropbox package had "x86" arch, but no, this didn't hide it from slackpkg. Something goes wrong somewhere else...

Some time ago, I had some weird results with slackpkg and slackpkg+. After a while, I found the culprit. I'm using Squid as a transparent proxy, and the errors came from stale meta-information in the proxy cache. The solution consists in simply emptying Squid cache and starting fresh.

@kikinovak,
this is another case. I ask him to send me /etc/slackpkg and /var/lib/slackpkg content and use these on my VBox 32 bit system. And I cannot reproduce the bug, so content is ok and any existing cache can not affect.

It seems to me something wrong with slackpkg, slackpkg+ or any routine called from on that system.

PS. The real cause is described here: http://www.linuxquestions.org/questi...ml#post5313424

You may be interested in papyros shell I think http://papyros.io/

"Papyros is a modern operating system. Alpha coming soon."

and it has separate Papyros-shell slax.org mentions it for their new version maybe.

Which is also not even in alpha stage. So I doubt it would fit into enterprise environment.

More information here. Most interesting part about it is that it's a Wayland compositor (according to readme).