I'm using the NIS+NFS combination for centralized authentication, but I admit it's not exactly industry standard (though it works very well, without the slightest hiccup).

I'd be interested in your alternative solutions for centralized authentication on Slackware. Unfortunately, it's only very sparsely documented.

Yes, would be nice to read a series of how-tos on Slackware in the Enterprise. :)

The difference between the big-shot enterprise class distributions and Slackware is probably similar to the difference between, say, the official Mercedes shop in the city and Tony, the local car mechanic in our little village. The official Mercedes shop has a digital workstation with loads of cables to plug into the engine and run all sorts of automated diagnostics. The shop itself looks like a hospital (or at least an expensive hairdresser), busy engineers walk around and talk to no one, they only sneer at my car, which is the dirtiest object in the shop. They tell me they can't fix my car, because it's too old. And anyway, the slightest job would have cost me a fortune. Tony, on the other hand, only has his toolbox full of screwdrivers, hammers and the likes. He greets my with his elbow, because his hand is full of grease. He smiles at my "good old Mercedes", which is the cleanest object in the shop. He's using his basic tools to look for the problem, and after a couple of minutes, identifies the source of the problem and replaces the spark plugs. His fee is ridiculously low.

As for HOWTOs on Slackware in the Enterprise, take a peek on http://docs.slackware.com.

I've been letting this comment fester in my mind for the past several days.

After I read your blog post I realized, okay, this is "doable" for computer geeks. For mainstream "mom and pop" users? Generally, no. Even after a tech support person does all the grunt work to get Netflix support configured, the end-user still has usability limitations. The conflict with pipelight and flash is one example. I don't envision most mainstream users understanding why, on Windows, they can toggle from Netflix to youtube and not miss a beat, but need various hops and skips to do the same with a pipelight configuration.

I greatly appreciate the hacking involved. Very much. Yet we geeks and computer savvy tend to take too much for granted. Those of us in that category will suffer much and invent work-arounds to deal with problems and challenges. The mainstream folks? Not going to happen. They will almost always choose convenience over security, technical merit, privacy, etc.

Thus, within the topic of this thread, I will stand firm with my original imaginary conversation. :)

Please elaboate. Just phrasing that it is hard to configure and unfit for Joe Average, is not sufficient.
There should be no conflict. In fact I am playing a youtube video in another Firefox tab right now, and yet another tab has a SilverLight page loaded. No Netflix account here, so I cannot test that.

Eric

Okay, perhaps I misunderstood the conflict between flash and pipelight/silverlight. That said, few people have your deep skill set and knowledge. I got bleary-eyed reading your blog entry how to get everything running. :) Until the entire package is mainstream in all distros, I don't see mainstream users going through all the compiling and configuration requirements. For mainstream users the package needs to be nothing but a download and install through their package manager.

For me personally, I'm not at all enamored by the Netflix flute from Hamelin. Yet if I ever started supporting Linux based systems for other users, preferably Slackware based like MLED, I know that home users (incorrectly) treat computers like an appliance. They expect these things to work just like their remote control.

In the end, the discussion is not that somebody devised a clever work-around to a problem. The discussion is the problem should not exist. :)

I consider myself to be an average, intermediate Slackware user. I was able to successfully use Alien Bob's blog to get Netflix up and running on Slackware 14.1. He has trouble shooting tips posted as well that are helpful. I was initially tripped up as I forgot to switch Firefox to Firefox/Windows.

Size It Down
 

For the Silverlight functionality write a script to do all the work.

I used to play Dungeons and Dragons Online, so there was a lot of heavy configuring trying to get it to work.

http://ubuntuforums.org/showthread.php?t=1263191&page=7

Heads up on Wine On 64
# For 32 bit applications - One time
WINEARCH=win32 winecfg

Scripting rules
http://www.linuxquestions.org/questi...ml#post4623382

I have not seen used Slackware at Enterprise level, yet ...

But I saw in-house distributions, Slackware based, and even the company where I work use such solutions. What's the point?

Slackware is not ready for the Enterprise.

For example , the lack of dependencies and automated updates is nice and it's nice to play all day along in the console. Tragedy begins when you HAVE TO do update, for today, for 400 servers. What must stay a minimum time off -line or in a "dirty state". Where even the boot time can be a tragedy.

Do we have to talk about OpenVZ image deployment and CPanel integration, distributed filesystems, and other cute stuff?

At this level, even pure optimization's of arch to i686 matter ... If I say the best solution for pure x86, on A.D. 2014 , is that pure i686, hundreds of "believers" from this forum will yell at me . But on the Enterprise, 31% speed gain, will enormous matter.

In a few words , I think Slackware is not usable in Enterprise, but it is a relatively simple distribution (around 1000 packages?), with a (relative) simple build system, and very stable , where you can develop a custom solution with a team of 3-5 members. Think of a LFS in steroids.

31% ?
thats kinda much, where did you get that number ?

cpu's have not changed that much since i686/486 as people seem to think
only major improvement are SIMD instructions (SSE, etc.) that are not used in the kernel (they are for encryption, compression and such but its a .config thing, not compiler)
and most common calculations are very optimized in glibc and some other shared libraries (for example x264 has its own routines)

amd64 implies SSE (at least SSE1), a couple other things are also implied with amd64

PS enterprise things like apache are bottlenecked in other places, not that i found people complaining about it

From my (and my team) experience.

RED: You hit right on the i686 advantage. :hattip:
GREEN: HTTPS, anyone?
YELLOW: Pages serving in a compressed (i.e. ".gz") form?

What would be your check list to change that?

use optimized libraries
i remember seeing the new kernel avx encryption for... some or other encryption scheme and it was... well beyond what i can do now
(had a whole research paper with it)

i mean no disrespect or anything, but cpu dispatching is fairly common in optimized programs
at the cost of a one 32-64 bit read when calling the function you get cpu specific code paths

edit: kernel encryption is good, but i dont see how to use it from userspace

PS "what i can do now" is mostly better then a compiler, not to brag :)

another edit:
amd64 is better anyway performance-wise as there are more registers for a compiler to play with

OpenVZ: You're right, Slackware needs more virtualization options. Xen is available as a Slackbuild, but it would be nice to have KVM and one or more LXC-based solutions.

CPanel: I have never seen CPanel used at any of my employers, nor in a quick poll of my sysadmin friends have they at theirs. It looks like a graphical configuration interface, akin to phpadmin, which no system administrator worthy of the title would deign to touch. How many companies consider CPanel a must-have (or even a nice-to-have)?

Distributed filesystems: GlusterFS works great on Slackware (same as it does on RHEL). I've been meaning to submit a Slackbuild for it.

All good things for a server distribution. Note that while the dvd ships with about 1000 packages, there are about 4000 more available as Slackbuilds via sbopkg (which is about as easy to use as "yum" in RHEL).

You're right that Slackware needs some work to close the gap with RHEL and its ilk for datacenter use, but it seems to me that you're overstating matters, overlooking existing solutions (like xen for virtualization), and not suggesting solutions.

Slackware offers efficient package management, it doesn't offer an enterprise deployment solution. Some people may confuse a dependency-solving auto-update package manager with an enterprise deployment solution.

Until something goes wrong...

In 2014 it is all x86-64 for enterprise Linux. RHEL7 x86 is 64 bit only. The i486/i686 discussion is a thing from the past. Slackware packages don't get rebuilt anyway.