CentOS and command line
 

I have heard from numerous users that Redhat is like another Microsoft and keeping things GUI and taking power from User etc.I haven't been able to find much difference then per say slackware that uses BSD init system.I find both systems quite stable and I guess slack requires more configuring. However, I still don't understand why its not good for power users from posts I put. I also didnt find System V init system too complicated as the init is split into run levels with different file for each service. So is this just a MYTH that Redhat is against KISS Principle and is anti-Terminal? Isn't it possible to use same commands in Redhat? I'm confused. I keep switching from 1 distro to the other. Good thing I did not format my centOS.

I have that feeling about Ubuntu, but not RHEL/CentOS.

RH is nothing like MS, nor is it like Canonical (the company that owns Ubuntu, or at least is the financing behind it). Canonical is trying hard to make Linux function more like MS Windows, RH on the other hand is making a very stable and reliable server platform. Not to mention they give tons and tons of code back to the Linux community.

I support roughly 3500 RH type servers across the US as a living and I do it 100% via ssh, without X11 forwarding so no GUI for me and there is NOTHING I can not do. We support RH7, RH8, FC5, FC7, CentOS 5.4, and now CentOS 6.2. So yes I am very comfortable in saying that there is no "MS Windows" movement from the RH camp when it comes to tools. In fact all of our RH7/8 boxes are without GUI and only some of our FC5 boxes have GUI running at all. The only reason we run GUI on FC7 and newer is the software we support now provides graphics and scanning of documentations.

RHEL vs Slack
 

Disclosure: I kinda-sorta maintain RHEL servers at work (by which I mean it's not my primary duty, but nobody else is doing it), and run Slackware at home and for my home business.

What I've found is that yes, you can in theory do the same things with RHEL as you can with Slackware. They're both open OSs built on virtually the same open source, so you can do anything you can do in one also on the other.

Where it can get complicated is with the package managers and the "glue" scripts.

Package managers: Slackware has a few options of various complexity. At its simplest, it's just unpacking a tarball over the root, maybe running a maintenance script to update config files, and voila. In some cases, these managers track package dependencies, but in others it relies on you to do that yourself. This tends to make it pretty straightforward to try a package, and if it doesn't work due to dependency or versioning problems, pull down the source and compile yourself.
RHEL has one package manager, yum, which uses an official repo that's often lagging behind (for stability reasons) and unofficial repos that you'll inevitably need to do anything useful :P yum performs extensive version and dependency tracking, uses a database for journaling installation activities, and is generally more powerful but also complex. I've run into innumerable dependency hells when trying to install some package that relies on some other package that doesn't have the exact right version, leading me to forcibly install things or open the rpm manually to copy the files out to the file system (bypassing yum altogether) or building from source. Of course, the moment you've started with these workarounds you've effectively destroyed the legitimacy of the yum database and then you have to start compensating for your workarounds by other workarounds.

I prefer Slackware's simpler approach to package management, especially since I tend to build from source anyway in most cases.

Glue scripts: By which I mean little scripts or programs intending to make things "easier", for example, X-Windows initialization scripts or scripts making changes to system files. Again Slackware takes a minimalist approach and relies on you knowing what files to change to configure your system. RHEL often makes use of "best guess" scripts to try to "fix" your experience without user intervention. Sometimes these scripts do the wrong or non-optimal thing, but more frequently, the scripts just obfuscate advanced features and even overwrite files you've manually tweaked. Plenty of symbolic links and spaghetti bash code exists throughout, for compatibility's sake, which makes it hard to track down when RHEL did something automatically which you'd like manual control of.

I prefer not to get a network connection or X until I've configured it manually to work, over having RHEL overwrite my manually tweaked fstab every time it starts Gnome.

When it comes down to it, both are very capable server operating systems, and I can see how RHEL would fare better in an enterprise environment that's more about executing packaged, stable, tested software in a predictable manner than in an R&D environment where you're tweaking every aspect of the system to make it work perfectly for your purposes. But so far, everything I can do in Slackware I can also achieve in RHEL - it just takes a bit more work to do it "right" (i.e. the Redhat way) and sometimes I have to jump through uncomfortable hoops to get there.

Thank you this was a great read. What do you say about its Simplicity compared to Slackware. Have you ever tried it? I see many users talking about BSD init simplicity over Sys V. but if that is the only difference I could care less as a matter of fact I see an advantage with sys v init as the files are kept shorter. Also the new systemd is going to be replacing the Sys V there are some who hate it and some who love it... rarely did I find anything in between. I personally never booted up with systemd myself so I can't say. I would love to study for RHCSA if I can pass the test through command line only. Is that possible to do? I am trying to stick with a good distro based on server side development (starting with Python). But I guess I need at least an RHCSA to get a job. 3500 Servers through 1 workstation? Wow that sounds quite impressive you must be well versed. I guess I can definitely take your word on Redhat.

Thanks for your non biased views. Yes, those links do get on my nerves as well... definitely agree. Ubuntu is even worse in that aspect. I am stuck between the 2. But do like some aspects of Slack... But it seems on the Professional Enviornment I will have to adopt to RHEL. I also think that if you take time to understand YUM there should be a way to fix those dependencies no? It does have quite a large amount of docs about it. I guess it comes to the aspect of "AUTOMATION" in RHEL where as in Slack you are on your own and you need to CONFIG yourself. So when it comes to the KISS Principle it can be debatable. I mean if its Automated would that not make your life Simpler? Less stuff to configure? But I can agree both distros are quite Rock Solid. I love both in different ways.

I don't think any mainstream distributions are really "anti-terminal". Red Hat and other distributions just do things in a different way. I don't believe really that it's against "KISS" or anything and I wouldn't think about those things too much. If you learn how to use Linux, you will find your knowledge roughly translates to whatever distribution (or other kind of Unix) you're working on. What I mean is, you'll have an idea of where to look for things and will be able to work out how to configure stuff, even if it works slightly different to the system you're used to. I'm using both Slackware (home) and CentOS (work).

You mean couldn't care less.

As a fellow grammar Nazi, I salute you.

+1

I'm always puzzled by the people who think that do-it-yourself dependency resolution is better than leaving it to the computer. Surely one of the points of computers is that they can do boring routine jobs without making mistakes? I worked my way from Fedora 1 to Fedora 14 and yum never once let me down. The rpm system has never let me down in CentOS 6 either, although I have had to pull a few tricks out of the hat to install stuff from EPEL, RPMfusion, atrpms, CentOS 5, Fedora 13, Fedora 17, and Mandriva 2010! There's nothing home-compiled on this computer and it's all in the data-base.

The problem is that people don't know how to use "Yum" which has many commands... I am slowly converting to CentOS. Thanks for your advice. Can I use/setup the Fedora Repos for CentOS. Also how do you compare Fedora to Redhat? I am into basically server side programming as my end goal but perhaps I can use the new cool things in Fedora desktop. For example Sync my desktop with Google Contacts/etc which i am dependent upon. My first use of Fedora felt quite alien so I simply replaced it with Slack at the time without giving much thought to it.

i personally have never used slack, but know a lot of people who do and really like it. i have personally only ever used Debian (not ubunutu) and the RH line of Linux distros for servers. Both are great, but I have found the RHE line (this includes CentOS) to be very mature and stable. This is just how RH looks at its release date and support life.

as for RHCSA to get a job, not needed, I am no were near good enough to pass that test, nor have i studied for it.

I am versed in what I support. Daily I touch between 20-40 servers a day, the other technicians do the same. Our company has roughly 3500 Linux servers in the field that we maintain and support. Again all of them are of a RH flavor, thus the reason I run F17 as my workstation. Just makes for simplicity from my perspective. The commands I issue, for the most part, on my box are the same I issue on the clients.

As for the newer systemd on F17, I am not comfortable with it yet, just because I have been using the older system foo <command> for over a decade. In the end to me they are one in the same. also the init.d string that many other distros use, like Debian, is really all the system and systemd are calling. RH has just provided a nice "easy" script for people to use to assist in administrating their services.

In short the more you know about Linux the better. The distro does not matter in the end. There are some basic differences like locations of specific files but that is easy enough to google.

Pick a distro, stick with it, but dont get married to it.

I agree RHEL and SLack are both great. 1 is more geared towards Automation while the other gives user more chance to config and tune. I will give Fedora a try again. I am guessing you are happy with it since you use it on your workstation. I wonder if RHEL 7 will adopt systemd. Is there a way to fix up broken dependencies through yum?

This is a fair point, however, I don't think anyone is saying that it is objectively better to have to do extra work. What I do think is that for people who want both full control over and knowledge of what is happening it their systems, a tiny bit of effort tracking dependencies yourself is preferable to running into dependency conflicts after your have let your package manager take over your system.

My first experience with dependency hell was as a slightly-more-than-casual user on Ubuntu. Like most in that group, I didn't have a crystal clear vision of what each and every package on my system did, simply because through installing most things with Synaptic or the "software center," I didn't have to. Once, on a computer I used only for browsing and media and therefore had very little installed on in the first place, I tried to install Virtual Box, and ran into a whole slew of dependency conflicts I had to learn how to interpret on the spot. This required that to run, but this conflicted with this version of that, but something else required that version of that to run, and something else definitely needed to go but couldn't even be removed . . . Just like that I was thrust into the middle of a hopelessly intertwined mess of a system that I was supposed to untangle thread by thread. Predictably, I broke it.

Shortly thereafter, I started using Slackware, and even though I am still quite new to it, I can say that this sort of thing would never have happened to me on my current system. When you have to configure things manually to get them to work, you learn what everything does and can then resolve conflicts. Maybe if you are already a Linux champion to begin with this doesn't matter (and in that case you can choose the tools that do the things you already know how to do automatically), but for relative newcomers like myself and the OP who want to learn, it matters a whole heck of a lot.

@ Mercury305: If learning is what you're after, I would go with Slackware in a heartbeat and never think twice about it. I learn more each week with Slackware than I did in a month with the other distros I've tried. A better learning tool for Linux I have never found.

there are, typically it is just a matter of chasing down the foo.rpm file the getting it on the system and installing either via rpm -ivh or -Uvh. this can be a very long process.

As for fixing it in yum repose yes, but typically it is created when running 3rd party or EPEL repos. On a server you typically want to be very careful what repos you point to so you can avoid dependency hell.

Dependency resolving is in the first place always done by humans, namely the distro's packagers. They put the information about the dependencies into their packages and decide which optional dependencies they compile their packages against. The only thing the computer does on the end users machine is to parse the dependency information and download the needed packages (and starts from the beginning with those packages). So Slackware users are more their own distro's packagers than mere human dependency resolvers.
If that is better for the person using the machine is a pure subjective thing.