Ubuntu, RHEL, similar distributions, obfuscated and bloated?

Question

I have a decent amount of experience with the various Linux distributions, having used most of the main ones, Redhat, Debian, Slack, SUSE, Gentoo etc, since 1998. Personally, I prefer slack or arch, or in some cases Debian because of the minimal base, and having a better understanding of things on your system without having to rely on helper programs.

Now, throughout the experienced community, with people who prefer things like Gentoo, Slackware, Arch or even BSD or LFS, some other distributions, such as Ubuntu, Fedora, RHEL, SUSE, and to an extent Debian have a reputation of relying on distro specific config tools or methods, making it hard to have an understanding of the system underneath.

Personally, I am sure I remeber several instances of warnings not to edit config files by hand, or that it was made very hard to do so.

Indeed, there is a saying that if you learn Ubuntu, then you will learn Ubuntu, as where if you learn Slackware, you will learn Linux. This could, for the purposes of the argument, also be applied to RHEL, SUSE etc.

I was talking to an Ubuntu fan recently, who disputed this. He said that the configuration files were all there and able to be understood and edited by hand, just as on Slack or Arch, except thatyou also had the extra helper stuff if you wanted it.

So then I wonder, how justifed is the view that you if you learn Ubuntu or RHEL or whichever, you will learn that specific system rather than Linux, and that it is made hard to administer everything by hand if you have an understanding? Is there any truth to this?

Answer 1

Your question doesn't really feel like a question. I'll bite, though, because I'm brazen like that.

I can't speak to Debian and derived distributions because I've never used them in any capacity other than playing around. Never had any interest in them.

RedHat and RedHat-derived distros have been my main "Linux of choice" for a long time. I don't like to have unnecessary software on computers in production roles. This means that I "strip down" CentOS (and all RedHat and derived distros) boxes to a bare minimum of RPMs. That also means editing configuration files "by hand" and removing tools meant to manage the configuration files for me.

I like the RedHat "contrivances" for specifying parameters on network interfaces, static routes, and iptables configuration so I generally leave all that in place. For a machine that's going to function as a firewall, web server, DHCP server, or other "headless" activity I strip out all the X-related RPMs (using --nodeps, if necessary, to force removal), and any RPMs that aren't necessary or related to the machine's role. I can always add them again if I need them.

I see one of my CentOS 5.2 VMs here that's showing 113 RPMs on an "rpm -qa | wc -l". The OS is taking up roughly 600MB. It's certainly not "slim and trim" compared to older distros, but it's lightweight for CentOS.

(The RPM dependency tree has gotten crazier and crazier on the RedHat-derived distros over the years. I'm actually at a loss right now to remember one of the dumber dependencies, but they've been driving me increasingly crazy as the version numbers of up on the RedHat-derived distros.)

Answer 2

Well there are two layers of understanding here. Understanding Linux and understanding a distributions way of doing something are two things. To be a good Linux admin you have to have a good grasp of how Linux works but you also need to have a good understanding of how the distribution you're running does things.

This is no different than the way that a network admin would need to understand how to configure and manage their equipment as well as need to understand the network layers, their purpose, and protocols.

At the end of the day Linux is a tool just like math. Once you understand a concept and how to apply it there's nothing wrong with using a calculator.

Answer 3

If you get right down to it, everything past the kernel is a convenience.

Take network interfaces for example. Redhat provides the system-config-network-gui and system-config-network-tui which are scripts which write the config files in /etc/sysconfig/network and /etc/sysconfig/network-scripts.

But these are really config files which feed scripts like 'ifup' and 'ifdown', which are called by scripts at boot time. The 'ifup' commands themselves are wrappers to the 'ifconfig' command.

Which itself is a convenient program which lets you manipulate values in the kernel.

One could make the argument that if you are not writing your own C program to use the kernel-provided APIs directly, you are not learning 'linux'.

None of these conveniences above the kernel are mandatory -- RedHat also provides the 'ip' command which does the same thing as the 'ifconfig' command. And there are probably scripts, and GUI wrappers, which build off that convenience instead.

So it all depends on where you want to draw the line. No matter what you learn, you are going to be learning something which is not universally applicable everywhere, even on Linux.

But convenience isn't a bad thing. Standardization isn't a bad thing. It is the reason why many tools vendors prefer (or only support, depending on the vendor) specific flavors of RedHat-family distributions: because that way they know that when the customer has a problem, they can reproduce the environment the customer is using in their labs so they can see what is going on. They don't have to worry about any of six million subtly conflicting "optimizations" that will make any Gentoo machine more or less unique.

Answer 4

The way I look at it is simple - a sysadmin setting up a server, or a user bringing a workstation up, require things that work out of the box, with minimal effort. That is why windows is so popular in spite of the myriad issues it has.

So basically, anything needed in production computing is easily available in RHEL simply by installing from sources. and you can be sure that every package you are installing has been through QA and is production ready. All that after a simple installation, that doesn't involve satisfying billions of dependencies and compiling everything from source.

Yes, such a system might seem bloated to people used to LFS approach, but with the modern computing power, an extra module in the kernel taking a .00001 of a percent is not a problem.

My early Linux experiences involved a lot of compiling and even more CPAN installations, up to the point where I came across Debian - every perl package was available via apt, and they automatically got updated whenever I required an update. So as someone who has a few hundred servers to tend to, I am definitely against compiling everything from source and building and customizing every possible package. I'd rather rely on the major distros' QA teams.