Slackware 9 Server, good idea??
Iíve been using slackware for sometime now, and its blazing fast. I love it. Although at work all my servers are running Red hat.
What are some of the pro and neg thing of having Slackware as my server??
I can't think of any.. I use Slackware as my server or server needs.. the one thing about Redhat is that it comes with support if bought cause its commercialized, etc.
Its widely accepted and known also, more people use Redhat so its a widely accepted number one choice for corporations to use it as well.
But I say, use Slack as your server, I do and I'm running three domains and FTP server off one Slack server, running without flaws as well.. .
It's choice. Some prefer the easy implementation of the networking RPM's made specifically for RH, also the cornicopia (he he) of information within How-To's that are specific to RH. However, that's for those who need it ;) IF you are running slack, have very little problem and understand how to setup a server (or can read from a search) then there's really no difference or reason to use RH over Slack as a server (or vice versa). It's simply choice.
Advantage of Slackware: Is installable on just about everything but toasters (or maybe even there...), and doesn't eat up resources.
This advantage comes from *not* having the comfort of a sophisticated (but maybe less flexible) package manager, like RPM or apt-get. If you choose slackware you have to know about package dependencies yourself, and if you have to apply patches and keep your system up-to-date by hand. You have an active responsibility to check, if there are updates for relevant packages and to decide if you you want to apply them.
With distros like SuSE or Red Hat you have a lot more comfort. As a SuSE user, I have learned to like the YaST Online Update: SuSE provides patches, that can be applied automatically by this tool. The advantage is that package dependencies are checked by the system A patch for something not installed will never be applied. (There are certainly better examples for what the package management front end can be useful).
But this means that there is an additional abstraction layer. You put the responsibility to some degree on your distributor, giving away a bit of control, at the same time. In some cases you can't simply apply patches from the original sources, but you have to wait until the package maintainer of your distributor provides a suitable package for your distribution.
In practice, this last point is only really a problem with smaller distros, though. Mandrake, Red Hat and SuSE are all very quick to provide the relevant packages, once there's a security update. It may take them quite a while if the update is not security relevant, though....
My suggestion would be: If you have no more than three servers it doesn't matter that much, which distribution you choose. If it's a server farm you have to manage with more than three machines, then you might benefit from the package management of other distros. Some (like SuSE) come with ready-made solutions for automatic remote installations in the RPM front-end. You prepare a master installation, and deploy that on hundreds and thousands of machines by just pressing a button.
Of course, you can achieve everything a package manager does, by scripting. Your own scripts will then do *exactly* what you want them to do, while a package manager front-end abstracts you from what's going on behind the scenes.
You can install RPM on Slackware, too, but the front-ends like SuSE's YaST will probably only work well on the distributions they are made for.
And you can, of course, use scripts on SuSE and Red Hat, but this is harder *with* a package manager like RPM than without.
The choice of a distribution is the starting point. The best choice is the one that takes you to your goal in the shortes time with the least effort. If your goal is maximum flexibility, than Slackware is probably what you want. If you need to manage a large network, you'll probably better off with Red Hat or SuSE or Mandrake or Debian (and there are others...).
However, the fine thing is, that is not really a *wrong* choice, as you can reach your personal goal with each of them; just the length of way, number (not height!) of hurdles to take and speed differ.
Excellent reply! In response to the package-management issue, Gentoo seems like the happy medium there. However, gentoo will take FAR longer to setup, but once there, the package-management system (portage) keeps the system up to date, and at the same time maximizes the resources of the system (optimized for architecture et al).
But I don't quite agree, that Gentoo is intermediate. It's something different, and in my personal opinion it is not quite that useful for servers. It is far easier, much quicker and much less riscy for a production server to keep it running a "traditional" distribution like Slackware, SuSE, Red Hat or Debian. It's just less work to apply a binary patch instead of having the sources and everything depending on it recompiled for every security update.
(On the other hand: All the BSD's have a similar concept, and most of them are certainly stable and secure...)
But Gentoo is excellent for developers, though! (And again: You can get anywhere with Gentoo, just as with other distros).
BTW, there's a very interesting alternative to Gentoo: Rock-Linux.
It uses Bash instead of Python, meaning that you can use the scripts on *every* distro. It differs from Gentoo in that it is actually a distribution build kit, with some pre-built targets (ready-made mini-distros).
Excellent! Thanks for the link. That actually was something I was dreading on a project I am getting ready to jump on, and rocklinux looks like it might be the answer I need...
Server is such a general term that it is tough to make any decision or recommendation without a contextual reference. In that regard, it's a little bit like "Enterprize," or "E-commerce." Each tends to mean something different to different speakers and listeners.
I can tell you this, in the context of small business and small networks: Most network services are, in and of themselves, not particularly demanding of machine resources. There is a tendancy, I think, to confuse the hardware requirements to provide a service with the hardware requirements to install an operating system, or to compatibility with processor specific optimizations.
For example, if you are setting up a web server for a firm that needs only to serve static content, and that has no more than a T1 pipe, a 486DX 66 with 16~32 MB core memory is more than adequate to the task. But if you try to set this up using RedHat 9, the workarounds required to get RedHat and Apache running aren't worth it, and once installed with a non-stock kernel (so that it will even run on a 486), the performance won't be that great because of other processor optimizations. It is obviously impossible with Windows 2003 if you were foolish enough to try.
But that same 486 will not only work, it will work well, with Slackware 9 or something like Debian stable.
I also find that when we miove up the ladder to run somewhat more powerful hardware, let's say PII or PIII, with faster drives and lots more memory, that installing Slackware versus RedHat is the equivalent of a minor processor upgrade and another stick of RAM. This performance edge that I believe Slackware offers may well evaporate when multi-processor, 2 GHz and better machines are used, but then I don't see much of that class of hardware in typical small business and departmental deployments, and so I haven't had an opportunity to compare performance between the two distros on that class of server hardware.
But I DO also observe more annoying hangs with the standard releases of RedHat than I see with Slackware. Maybe RedHat's AS and ES versions are different, but they're priced at several thousand dollars per machine, and don't address the sort of 15 client Samba server, or departmental print server deployment I'm talking about here. For this sort of use, I find Slackware more reliable and considerably less hungry for machine resources than contemporary RedHat releases.
So, while RedHat may, or may not, prove the better choice for a Fortune 500 data center, I firmly believe that Slackware is superior in the typical small business server roles: file and print (including samba), web, ftp, mail, firewall, dhcp, dns, etc., and makes a darned nice workstation OS as part of the deal.
I agree with most of what you say. And I do like Slackware, and for the environment you mention it certainly *is* a good choice.
When I talked of servers it was servers as opposed to desktop machines like office clients or developer workstations. I think it doesn't matter if you have only a few users or hundreds of thousands of them, and it doesn't matter if it's serving files, static or dynamic web content, or reports from a TeraByte data warehouse --- the requirement is always that servers have to be *availabe*. This means up-time and responsiveness are more important than for desktop machines. It doesn't sacrifice the whole business of a company when a computer mainly used for writing letters with OpenOffice.org crashes occasionally. But the crash of a much used file or database server is a different story....
So the hardware you choose may depend on what the server computer actually serves, and to how many users.
But the requirement of stability is independent of this, and I don't see a difference between large and small companies, except one: The number of server to manage is normally much larger in big companies. In such an environment the administrative tools included in distributions from SuSE and Red Hat *are* and advantage.
So it's not stability where Red Hat and SuSE score over Slackware --- it's just that they have more useful tools doing things that you have to do on your own in Slackware. As I tried to point out in my previous point, each approach has its advantages and disadvantages, just meaning more or less work for the administrator to get to a certain point.
I can't see a difference in performance or stability betwwen Slackware 9 and SuSE 8.2, by the way, so far. Not all distributions are as stable as these. Slackware is a top-notch distribution regarding the basics. But so is SuSE, and the latter is more comfortable in a wide range of environments. But I use Slackware, where SuSE won't fit (on an old P1/120 laptop, eg).
And I wouldn't expect any big performance differences, as the software used is mostly the same. A speed increase can be achieved by compiling the kernel and software packages from the sources, but that holds for any distribution. Ok, there's one think making a SuSE kernel slower a bit: It comes with a lot of drivers not compiled into a standard slackware kernel.
Now it's up to the user to choose for their
- desktop (with super-fancy mulitmedia hardware): Start with Slackware and compile the missing drivers into the kernel yourself, or just use SuSE?
- server (with a headless web server, no multimedia hardware): Start with SuSE and compile a new kernel with all the unused drivers switched off, or just take Slackware?
(Most of what I said about SuSE should apply to other United Linux distros and Red Hat and Mandrake as well, BTW).
So the choice can be made on what's closer to the final goal, which is a good thing. I doubt that there is a Golden Hammer. You can do everything with every distribution, but you will have to invest more or less time and effort.
I like them both, SuSE *and* Slackware. And Knoppix is cool, and RockLinux is what I'll try next. I like OpenSource because it means freedom of choice and healthy competition, as this example shows. 8-)
I've only ever used Slackware, but one thing I've noticed is that all the
upgrade scripts I've ever come across do things in a way where you don't
have to disrupt the machine or interrupt service. I believe the developer
writes his scripts with the server market in mind.
The main reason I don't use SuSE, isn't because of any inherent problem with the distribution, but rather, a problem with experimentation prior to rollout. I'm not primarily an adminstrator, as far as my work is concerned, but as it happens, I am never-the-less the only administrator, and I'm not terribly confident.
So before I try anything on a production server, or before purchasing any hardware, I try it out on obsolete gear. Slackware and Debian permit me to experiment using equipment that doesn't let me try out the more "full featured" distributions, and when I do, sometimes I'm astounded. That's why one of my latest experiments (an auxillary mail server) ended up in production running on a 486SX with Slackware 9. The machine was an excellent find ( free and almost pristine condition) despite its age, and while it doesn't loaf along like it's Slack 9 powered partner, I discovered (by accidently creating a mail loop :-) ) that it can handle (ahem) <I>thousands of email messages</I> in an incredibly short time. Talk about your accidental benchmarks.
To Ken (bender647): Absolutely right. Slackware is famous for stability, and the scripts are suitable for servers; but it's still up to you to check any dependencies, and there are fewer tools for a number of things. The good thing is that you are totally in control over your system(s).
So nothing I said was to suggest that Slackware is not well-suited for servers. All I said is that the increased flexibility comes at a cost, but this is true for almost anything in life.
So to make it clear: I have seen distributions crash on a regular basis, but none of Slackware, SuSE and Knoppix. And these are my favourites, anyway.
To buhead1: Good strategy, to be conservative, and good and customer-friendly attitude to check out if there's an inexpensive solution available before urging them to invest in big iron. 8-)
That I talked so much of SuSE is mainly because this is what I know best --- it wasn't meant to urge you to try it out in a production environment (although SuSE 8.2 is worth a look for people who don't know it; it's very mature). Stick to what you know to be reliable. And don't waste time trying to get anything else than Slackware running on an 486SX (which means that even have to use math emulation in the kernel, don't you?).
Talking about benchmarks: I haven't done any real benchmarks, I just can report my impressions on a subjective basis. Here is what I found remarkable:
- Clever partitioning has as much an effect on the overall performance of the system as compiling your own kernel, if not more. Eg, if you have two harddiscs, it's good to have the swap partitions for disc1 on disc2 and vice versa. But don't make a science of it, except speed is all you are interested in.
- ReiserFS appears to be faster than Ext3, but it only cares about Meta-data, not about the data themselves (but I haven't seen a loss of date on a ReiserFS partition in five years...).
- Knoppix is incredibly fast, given that it runs from a CD-ROM. There's hardly a noticeable difference in the start-up time of biggies like OpenOffice.org, once the desktop is running (OK, KDE takes its time, but once it's there, it's fast).
- Compile your own kernel on every machine that you want to run Java programs on. They won't *run* faster, but the start-up time are decreased significantly --- you can feel it! (Holds for any distribution).
- Put lots of memory into your machine if it is to run Java programs. Java is not slow, when it has enough memory. It doesn't need a P5-4GHz, but it needs RAM. (Holds for any distribution).
- Compile multimedia applications like MPlayer, the speed increase is significant. (Holds for any distribution). With other programs the speed increase is hardly noticeably, most of the time (but certainly measurable).
- Funny thing: Some web applications are more responsive when you use them from a remote machine instead of on the localhost. SQL-Ledger is an example.
- If you have no users connecting directly to a machine consider to install a headless X server like Xvfb instead of XFree86. This takes considerably less resources and has the added security advantage that it can (and should!) be run under a non-privileged user account.
- Once again Java: If your machine serves Servlets and JSP pages, but doesn't run Java applications, make sure, use Java 1.4.x (no matter what version the software is originally written agains!) with the server option. You'll be amazed how fast Java can be...and memory consumption is decreased, also. If you can, do so in combination with a headless X server.
(So you won't guess it: I am a Java developer... 8-))
I tend to like Slackware for my desktop, and Slackware or Debian for servers. I always feel weighed down by other distributions. I recommend Mandrake to new users who have plenty of hardware to run Linux on, but I no longer care to use it myself. If you plan to compile some software yourself, but want to stick with a binary distribution, I can't recommend Slackware along with checkinstall enough. It just works the best for this. Yes, you have to keep track of dependencies yourself, but I don't find this to be a problem when I am compiling from source. Just to make myself clear, I have no problem with Red Hat or Suse (although I have never run Suse); they are solid choices. This is simply a matter of personal taste and what you want out of your distribution.
As a side note, if you are interested in alternatives to Gentoo, besides Rock Linux there are also Sorcerer Linux and its two spinoffs, Lunar Linux and Source Mage. The spinoffs to Sorcerer were created, I believe, because there were people who wanted to create a community to develop Sorcerer while the main developer wanted to keep it essentially a one man show, or possibly didn't like some of the things they wanted to do with it. Because of the conflict that ensued, development stalled altogether for a while and the two spinoffs emerged from some of the community minded developers. After this happened, development of Sorcerer picked up again. It may seem odd, but I heard of Sorcerer Linux well before I ever heard of Gentoo. I don't know when the two projects were started, but it was interesting to see Gentoo suddenly become so big while a lot of people are still unfamiliar with Sorcerer.
Here are the sites:
I agree completely.
Nevertheless I'd like to point out that it's not only dependencies and package management where other distributions support users and administrators with their added tools. This is just the most obvious thing.
(The following is about SuSE, but you'll find similar things in Red Hat, Conectiva, Mandrake and Turbo Linux).
SuSE's abstraction has the advantage of keeping the whole system upgrade-safe. For example, you never touch httpd.conf for your Apache web server directly. It's created from entries you make elsewhere. This ensures that you can apply a patch RPM or a new version of the Apache RPM from SuSE without thinking about possible changes in the structure of the configuration files. You are shielded from it completely. If necessary the system creates a new version of the config file from your existing configuration parameters for you. This is just comfort, and with their 8.x series they finally did it right, so it's become really an advantage.
The real good thing is, however, that you can decide for yourself at any time to leave this track and configure everything by hand, just like you do with Slackware. But once you do so, there's no way back. In practice, most SuSE users choose a compromise. Some things (servers, programs) are configured by hand, for others it makes sense to stick to the mechanisms SuSE provides.
The disadvantage is: In order to fully exploit the automatic you are bound to stick to RPM packages from SuSE, at least for low-level software like web servers. And it may take a while before a SuSE RPM is available when a new version of a program is released.
And then: RPM for Red Hat is not quite the same as RPM for SuSE. Don't try to use the RPMs for Jakarta-Tomcat on SuSE, eg. Of course, nothing would stop you from installing a tar ball.
For native programs checkinstall is available for SuSE, and it can be used to automatically create an RPM package that is then recorded in the RPM package management database.
Another example is kernel patches. For Slackware 2.4.21 is already available. SuSE instead decided to backport the latest ptrace bug patches to 2.4.20. This is, of course, easier for them as their kernel contains a lot of SuSE specific patches. To ensure that things like ALSA aren't compromised they have to be careful with providing new kernel versions. Kernel compilation is no longer as easy as it used to be (two or three years ago there would hardly go anything wrong, but this is no longer true, and SuSE Linux users are wide spread from absolutely novice users to long-yeared gurus). So there's good reason for the way they make their decisions, but in the end it means that users can't make use of possibly interesting new features in 2.4.21.
Slackware is faster here. And I use it on an old P1/120MHz laptop as a "desktop" (no X, though) and server system, and I *like* it. There's no difference in quality between Slackware and SuSE: Both are very, very good, mature, and well thought out, although with totally different concepts.
BTW: It may be accidental, that Slackware and SuSE are my favourites, but it may also be because they are distant relatives. The first SuSE versions were based on Slackware... ;-)
So I agree fully with you: If you want to stick with a binary distribution, but compile a few things yourself, then Slackware is your distribution of choice.
And I think it's time to thank the Slackware team for one thing: Their quality assurance is up to everyone else's. It is almost always a safe bet that you can apply a patch from Slackware without being afraid that you compromise your system. I think that's not guaranteed for all the other 200+ distros around. It's certainly what you expect from Red Hat and SuSE, but it's much harder for free projects with limited resources like Slackware. But they make it, somehow!
Regarding non-binary distributions: Yes, Sorcerer et al. are interesting, but the development stale and the fact that their future looked uncertain for quite a while, helped Gentoo to excel. Gentoo hasn't had a fork, the development continued, and, perhaps most important, the tone on the mailing list is much friendlier. It looks to be more like a community, instead of individualists that openly show their disgust for each other.
Regarding Rock Linux: It's not like the other source distributions. In fact it isn't a distribution or meta distribution. It's a distribution build kit. Now, there are distributions built with Rock available from the Rock web site, of which the desktop distribution dRock is the most complete.
|All times are GMT -5. The time now is 11:16 AM.|