Politics and Pragmatism in Using Linux Distributions

Recently I’ve been making decisions on which Linux distribution deserves my support when I write how-to or similar articles. I started my journey with Ubuntu. Out of all, this is the distribution closest to my heart and may be it always will be. I ventured into CentOS for work-related reasons and found it to be a workhorse. I forayed into Fedora on a netbook with some success. I have had to use a bit of SLES for more work-related stuff. And I have been attracted to, used, and migrated businesses to Debian. Both politics and pragmatism have played a part each time I used a distribution. And thus this post.

You can see from my recent posts that I have made a decision to go with Fedora. It was mostly for political (philosophical) reasons but also for pragmatism (cutting-edge technology, etc.). When the time came for me to choose something other than Debian or Ubuntu, I chose Fedora over openSUSE mainly for philosophical reasons. And I’ve been re-evaluating my decision ever since.

I am very happy I picked Fedora. It’s making bold decisions in the future direction of a Linux distribution, especially with the two most controversial and highly-debated steps: /usr unification and systemd. I have started using Fedora 17 alpha and find systemd a joy to use. I only care about systemctl enable/disable or systemctl start/stop as a user (or sysadmin) and it does exactly what I want it to. Much better than chkconfig, service or invoke-rc.d. The /usr unification hasn’t affected me so much so far. Package availability has also been excellent for the server use cases to which I have put Fedora 17.

Fedora seems like a good fit for me for now. But a second question still remains: which distribution should I recommend to others for home/workstation use when asked? My gut feeling is Ubuntu because they do a lot of good work for this sort of user. I’m also well-versed in it so I can provide ample support if required. But I also want to provide a different answer for users who don’t want to use Ubuntu. A very valid answer for this would be Linux Mint but it’s so similar to Ubuntu that it might not be an option in some cases. This leaves a few distributions that I would really like others to use (if only because they’ll come to me for answers most of the time).

The first distribution is openSUSE. Yes, I have some misgivings about the whole openSUSE, SUSE, and Microsoft triangle. But purely on technical merits is openSUSE good enough to replace Ubuntu as my default recommendation for others? This is a question I have asked myself and the one I’ll try to answer over the next few months. I’ve decided to be pragmatic about this particular case rather than political. I’m willing to be pragmatic if openSUSE can bring in new users to Linux like Ubuntu has done for a while. It’s a tall order but openSUSE looks like a good candidate from where I stand.

The other distribution I may recommend is Mageia. It’s on its way to the second release. These people have a very pragmatic, user-centric approach to their distribution and them being a community allays many misgivings I have about openSUSE. Technically they also appear to be sure-footed and thus deserve the support of people like me. Maybe Mageia can serve Ubuntu’s role of bring new users to Linux.

I wouldn’t recommend Fedora because of two things: (a) hardware support can mean using other repositories (such as RPMfusion); and (b) it’s too bleeding-edge to keep users on it for a while without too many issues.

Now that I have to give up my moral high ground, how does it feel? Very liberating, actually. When I use FreeBSD license instead of GPL, I consider the freedom of people over freedom of code. So why should I take such hard stances when it comes to Linux? People should matter more than code or a distribution. If Ubuntu or openSUSE are not ideal Linux ecosystem participants, they are productive and willing participants nonetheless. It may be about time I gave up on idealism and focus more on doing good for more people.

Install PyCrypto in openSUSE 11.4

I had a minimal install of openSUSE 11.4 and wanted to install the python-crypto package in it, related to my “AES Encryption with Python” blog post. But I received a strange error.

Problem: python-crypto-2.3-3.1.x86_64 requires python(abi) = 2.7, but this requirement cannot be provided
  uninstallable providers: python-base-2.7-8.10.2.i586[Updates-for-openSUSE-11.4-11.4-0]
                   python-base-2.7-8.10.2.x86_64[Updates-for-openSUSE-11.4-11.4-0]
                   python-base-2.7-8.4.i586[repo-oss]
                   python-base-2.7-8.4.x86_64[repo-oss]
 Solution 1: deinstallation of patterns-openSUSE-minimal_base-11.4-6.9.1.x86_64
 Solution 2: do not install python-crypto-2.3-3.1.x86_64
 Solution 3: do not install python-crypto-2.3-3.1.x86_64
 Solution 4: break python-crypto by ignoring some of its dependencies

I tried to check what is it with the patterns-openSUSE-minimal_base package that conflicts with python-crypto.

chinstrap:~ # zypper info patterns-openSUSE-minimal_base
Loading repository data...
Reading installed packages...


Information for package patterns-openSUSE-minimal_base:

Repository: @System
Name: patterns-openSUSE-minimal_base
Version: 11.4-6.9.1
Arch: x86_64
Vendor: openSUSE
Installed: Yes
Status: up-to-date
Installed Size: 1.0 KiB
Summary: Meta package for pattern minimal_base
Description:
This package is installed if a pattern is selected to have a working update path

But this was of no help to me. I tried to take a risk and remove this package. Choosing this route made it possible to install python-crypto but I still have no clue what repercussions there are after removing patterns-openSUSE-minimal_base. Following is the process I went through to install python-crypto.

codeghar@chinstrap:~> su -
Password:
chinstrap:~ # zypper install python-crypto
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: python-crypto-2.3-3.1.x86_64 requires python(abi) = 2.7, but this requirement cannot be provided
  uninstallable providers: python-base-2.7-8.10.2.i586[Updates-for-openSUSE-11.4-11.4-0]
                   python-base-2.7-8.10.2.x86_64[Updates-for-openSUSE-11.4-11.4-0]
                   python-base-2.7-8.4.i586[repo-oss]
                   python-base-2.7-8.4.x86_64[repo-oss]
 Solution 1: deinstallation of patterns-openSUSE-minimal_base-11.4-6.9.1.x86_64
 Solution 2: do not install python-crypto-2.3-3.1.x86_64
 Solution 3: do not install python-crypto-2.3-3.1.x86_64
 Solution 4: break python-crypto by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/4/c] (c): 1
Resolving dependencies...
Resolving package dependencies...

The following NEW packages are going to be installed:
  python python-base python-crypto

The following package is going to be REMOVED:
  patterns-openSUSE-minimal_base

3 new packages to install, 1 to remove.
Overall download size: 4.3 MiB. After the operation, additional 23.3 MiB will be used.
Continue? [y/n/?] (y): n
chinstrap:~ # zypper info patterns-openSUSE-minimal_base
Loading repository data...
Reading installed packages...


Information for package patterns-openSUSE-minimal_base:

Repository: @System
Name: patterns-openSUSE-minimal_base
Version: 11.4-6.9.1
Arch: x86_64
Vendor: openSUSE
Installed: Yes
Status: up-to-date
Installed Size: 1.0 KiB
Summary: Meta package for pattern minimal_base
Description:
This package is installed if a pattern is selected to have a working update path
chinstrap:~ # zypper install python-crypto
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: python-crypto-2.3-3.1.x86_64 requires python(abi) = 2.7, but this requirement cannot be provided
  uninstallable providers: python-base-2.7-8.10.2.i586[Updates-for-openSUSE-11.4-11.4-0]
                   python-base-2.7-8.10.2.x86_64[Updates-for-openSUSE-11.4-11.4-0]
                   python-base-2.7-8.4.i586[repo-oss]
                   python-base-2.7-8.4.x86_64[repo-oss]
 Solution 1: deinstallation of patterns-openSUSE-minimal_base-11.4-6.9.1.x86_64
 Solution 2: do not install python-crypto-2.3-3.1.x86_64
 Solution 3: do not install python-crypto-2.3-3.1.x86_64
 Solution 4: break python-crypto by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/4/c] (c): 1
Resolving dependencies...
Resolving package dependencies...

The following NEW packages are going to be installed:
  python python-base python-crypto

The following package is going to be REMOVED:
  patterns-openSUSE-minimal_base

3 new packages to install, 1 to remove.
Overall download size: 4.3 MiB. After the operation, additional 23.3 MiB will be used.
Continue? [y/n/?] (y): y
Retrieving package python-base-2.7-8.10.2.x86_64 (1/3), 3.8 MiB (20.6 MiB unpacked)
Retrieving: python-base-2.7-8.10.2.x86_64.rpm [done (772.4 KiB/s)]
Retrieving package python-2.7-9.10.2.x86_64 (2/3), 270.0 KiB (1.3 MiB unpacked)
Retrieving: python-2.7-9.10.2.x86_64.rpm [done (119.6 KiB/s)]
Retrieving package python-crypto-2.3-3.1.x86_64 (3/3), 279.0 KiB (1.5 MiB unpacked)
Retrieving: python-crypto-2.3-3.1.x86_64.rpm [done (119.3 KiB/s)]
Removing patterns-openSUSE-minimal_base-11.4-6.9.1 [done]
Installing: python-base-2.7-8.10.2 [done]
Installing: python-2.7-9.10.2 [done]
Installing: python-crypto-2.3-3.1 [done]

Other Resources

Some other pages that may help you are: pacemaker or python dependency problem with minimal opensuse 11.4; Bug 691055 – patterns-openSUSE-minimal_base excludes python – unresolvable conflicts; Python Development Pattern in openSUSE 11.4

Choosing a Linux Distribution

Recently I have had more time to work with Linux. I had been using Ubuntu in some way for two years when I needed to set up Linux on a few years old server. Since I was comfortable with Ubuntu, I thought I might as well go ahead and use it. But then I found out that there were other alternatives as well. This caused a headache which still isn’t resolved to this day. Which distribution is the best to get hands-on, real world experience with?

Comfort

You have to look at your comfort level when choosing a distribution. If you are familiar with something, even in passing, it would be an easier path to go with what you know. On the other hand, all distributions may be different but they have more in common than there are differences. So learning another distribution style is not as difficult as one might expect.

Hardware Support

If the distribution you choose is not able to function on the hardware you have available, you should not choose it. If you can get it to work, with or without a lot of effort, all the power to you. If, however, you can’t get it to work, you might as well look for another option. I went ahead with Ubuntu on the server because it supported all its hardware out of the box. I did not have to tweak anything or waste a lot of time. On the same server I was unable to install CentOS because Red Hat had dropped support for server’s RAID card in its current distribution.

Purpose

For what purpose are you using a distribution? Is it going to be for starting out, testing, development, or deployment? For all these scenarios, there are many distributions fitting them just fine. For starting out, a friendly distribution like Ubuntu could work. If you are testing Linux for its feasibility in your environment, just about any distribution would work. A distribution for doing development work should be fast moving with new technology so that you can use it to its fullest extent. If it’s for production deployment, being conservative in your selection is recommended.

Cutting Edge Technology

Some distributions strive to be on the cutting-edge. I count Fedora, openSUSE, and Ubuntu in this category. They release new stuff every few months. So you get to work with what’s new. For example, on Ubuntu, I found Django packages ready to install and work. Since I wanted a package and I found it, I was able to start working. I did not have to jump through hoops just to get to the point where I would be able to work.

Enterprise

Yes, an enterprise version would be more stable and maybe more secure. But it is also less likely to include new technology in an easily accessible format. Taking the example of Django, I have not found any tutorial on the web to install it on CentOS using an RPM package. All tutorials I have read ask you to download and install from source. Yes, it’s the traditional way to do things but if package management is the future, we should look for packages first and source code later. Now if I am developing and deploying an application developed with Django, I want to have the peace of mind that I installed a package that had been tested to work well with the whole operating system, and not something I installed without knowing how it would turn out.

To me this is the most important point after hardware support. I am willing to learn a whole another distribution if it is enterprise level with great hardware support but also keeps up with new technology. Since not one distribution will always fill these requirements, we have to look at the best tool for the job at hand.

Security

I was shocked to learn a few days ago that Ubuntu server’s default firewall policy was to accept all traffic. CentOS, on the other hand, has a pretty aggressive firewall policy. Combined with recent scandal of Debian and OpenSSL, it has dented my confidence in Ubuntu. It’s not that Ubuntu is insecure, it’s just the appearance of security in the ecosystem is absent (to me, at least). It’s also not that these things cannot be rectified by me, it’s that why would I need to take an extra step when a prudent decision could do it for me in the first place.

Another aspect I look to is being root. Does one have to actually be root or would sudo do? I like the sudo model better since it forces you to actually type your permission when doing critical work. Yes, if you are careful su and su - would work as well as sudo. But I like the added carefulness of sudo. So the first thing I do after installing a distribution is to see if it has sudo and then enable it for at least one user.

Support

Support is a very important part of decision-making process. Support may be of three kinds: distribution creator, third-party professional, and community and friends. Support includes help as well as software updates. One can get help from many sources, and community is an essential part of this support ecosystem. It can get you started and get you out of trouble. Almost all (ok, maybe all) distributions provide software updates. Then there is an extra level of support which we know as enterprise or corporate support (think Red Hat). It is provided by either the creators and maintainer of the distribution or from third-party entities.

For a home user, software updates and community support should be sufficient. For a business, however, ‘corporate’ support is essential on production systems. Businesses like to pay someone to get extra insurance in case it is needed. If a server is essential to business operations, it is very important that the team running the server knows what it is doing, has community support for minor issues, and corporate support when things go really bad.

Red Hat, Novell, and Canonical provide this kind of support as they create their distributions. Of course, if you have a good team running your servers, you may not need to get corporate support. But if your manager is a non-technical person, she will most probably require it. And if it’s not your money being spent, why argue?

Conclusion

This was meant to be a discussion of factors I would look into when choosing a distribution. Nothing more, nothing less.

Disclaimer: I have edited, and will edit, this post as new arguments come up.