Qt4 Programming in Ubuntu
I am beginning to go in the direction I had mentioned previously on this blog: using Debian as server and Ubuntu as desktop. To learn how to do Qt programming, I decided to install Kubuntu in a virtual machine. So I grabbed Kubuntu Intrepid and installed it in VMware. But I just didn’t feel comfortable using KDE 4.x. So I installed Ubuntu. Programming should not be a problem; I just don’t know (yet) how to run my own Qt-based application in Gnome. By just running the application once it’s compiled, it works; you don’t need to install anything else (as far as I know). So far I have installed build-essential, libqt4-dev, libqt4-dev-tools, and qt4-designer.
sudo aptitude install build-essential libqt4-dev libqt4-dev-tools qt4-designer
As I start to program, I will provide updates. To learn Qt programming, I will be using the following resources: How To Create a Linux Desktop App In 14 Minutes For Beginners (Using QDevelop and Qt4); C++ GUI Programming with Qt 4; Introduction to Design Patterns in C++ with Qt 4;
To setup my environment, I chose to create a folder for each exercise I would be doing. For example, if it was my first exercise, I did the following:
mkdir /home/me/exr1
cd /home/me/exr1
I also use vim as my editor. So I followed a simple formula: all exercises in their own folders, and each exercise’s main() function in main.cpp. So I created a main.cpp file in exr1 directory.
vim exr1.cpp
Once you have written your code and want to compile and run it, do the following steps:
qmake -project (create a project file)
qmake (create a make file appropriate for your system, which is Ubuntu in this case)
make (compile your project using the make file created in previous step)
./exr1 (run the application)
Since after every change I would have to run the above commands again and again, I created an alias for them in bash.
vim /home/me/.bashrc
And add the following line to the .bashrc file
alias runexr1="cd /home/me/exr1/; qmake -project; qmake; make; ./exr1;"
I opened a new terminal window so that the new alias is now available. And each time I would just run runexr1 after making changes to the file. It would not only do all the compilations, but also execute the application.
Manage Services in Debian
In Red Hat Enterprise Linux (RHEL) and similar distributions, we get the chkconfig and service commands to manage services. In Debian, we also have similar but not the same commands.
Control Services at Boot
When the computer boots, the init process is the parent process that starts all other processes and services. All services started at boot are put in /etc/init.d/ and init just reads these scripts and starts the services. To control which services should run in which runlevels, the /etc/rcn.d/ (where n stands for run level number) directory contains symlinks to the scripts in /etc/init.d/ directory. For example, if a service needs to be started in runlevel 4, /etc/rc4.d/ would have a symlink to its corresponding script in /etc/init.d/ directory. For more details, check out Debian Policy Manual - System run levels and init.d scripts.
To manage which services should run in which run level, use the update-rc.d command. This is equivalent to the chkconfig command in RHEL. Some example of using the command are as below (Debian notes):
Insert scripts into /etc/rcn.d/ directory for a particular service, script for which must exist in /etc/init.d/: update-rc.d service defaults
Disable service at boot time: update-rc.d service stop runlevelnumber
Disable service at boot but is less permanent, as upgrading package or distribution reverses this command: update-rc.d -f service remove
Enable service in all run levels: update-rc.d service start 20 2 3 4 5 . stop 20 0 1 6
If you are looking to use the chkconfig command because it seems easier, then you need to install sysv-rc-conf package.
sudo aptitude install sysv-rc-conf
However, instead of chkconfig, you will use sysv-rc-conf command.
Control Services While System is Running
But how do you start and stop a service without affecting whether it starts or not at boot time? In RHEL we have service command, and in Debian we have /etc/init.d/.
Start service: /etc/init.d/service start
Stop service: /etc/init.d/service stop
Restart service: /etc/init.d/service restart
Reload configuration: /etc/init.d/service reload
Force reload: /etc/init.d/service force-reload
Some great resources to check out are: Making scripts run at boot time with Debian; Remove unwanted startup files or services; Securing Debian manual – Appendix A – The hardening process step by step; Getting started with your Debian server;
Types of Repositories
Many linux distributions divide their repositories into different parts based on certain criteria. It could be for support, policy, or anything else. I have tried to understand what kinds of repositories are out there for some distributions, and have always had a hard time remembering what is what. So I will provide a brief introduction here and link to more information. I hope you find this a good stepping stone to complete understanding.
Ubuntu
Ubuntu has four types of repositories: main, restricted, universe, and multiverse. Main contains free software which the Ubuntu distribution fully supports. Restricted may hold software which may not be free (or open source) but Ubuntu supports it. Universe contains open source software but it is not officially supported b Ubuntu. There is no guarantee for even security updates. Multiverse contains software which is absolutely not “free” and the advice is to use this at your own risk.
Debian
Debian has three main types of repositories: main, contrib, and non-free. There is a third-party unofficial apt repository and a multimedia packages repository.
Fedora
Fedora has three main types of repositories: base, updates, and extras. Base contains software which make up the actual Fedora distribution on a disc. Updates contains updates to the packages in base. Additional software is provided in extras. Apart from these official types of repositories, there are some third-party repositories which are not officially supported by Fedora project. These include, but are not limited to, RPMforge, Livna, Fresh RPMs, and ATrpms.
CentOS
CentOS has many types of repositories: os, updates, extras, addons, centosplus, and contrib. As with Fedora, the same third-party repositories may be used. There is another repository, called Extra Packages for Enterprise Linux (EPEL) which aims to provide packages not included in the main CentOS repositories. And then there are additional repositories.
Debian sources.list Demystified
I have always had a hard time trying to figure out how to configure sources.list in Debian or its derivatives, like Ubuntu. To learn this thing myself, and to give a basic introduction to all, this post is being written.
Debian uses dpkg, apt-get, aptitude, and other programs to install and maintain software packages. These applications, in turn, use the /etc/apt/sources.list file to figure out which repositories to use and where they are located. Depending on how you configure sources.list, the selection of software available to you will vary. So it is important to learn more about this critical piece of your Debian experience.
The format of sources.list file is thus: deb uri distribution [component1] [component2] [...], and these parts are explained below. There is one source on one line, and the most important source comes first. As you add more sources on more lines, their importance decreases based on their location (from top to bottom).
deb
You have two choices here: deb and deb-src. deb means that you want binary packages, and deb-src means you want source packages. Usually both are used, on their own lines, of course.
uri
This is where you specify the location of the repository. It can be local (file:/), CD (cdrom:/), FTP, HTTP, SSH, RSH, and copy.
distribution
You have the following choices, written here in descending order of stability and ascending order of new versions of software available: stable, testing, unstable, and experimental.
component
Component or category has three choices: main, contrib, and non-free. These are “kinds” of packages as sorted based on the Debian philosophy: Debian Policy Manual – The Debian Archive.
Examples
deb http://ftp.us.debian.org/debian/ stable main contrib non-free
deb-src http://ftp.us.debian.org/debian/ stable main
deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main
Conclusion
This was just a basic introduction to get you started. To learn more, check out sources.list manpage; How to Have a Pleasant Installation (for Debian Newbies); use aptitude instead of synaptic and why;
Why I am Leaning Toward Debian
I am looking at various options for a Linux distribution these days. Some of them I discussed in my previous post on how to choose a Linux distribution. I also discussed CentOS. Here I would like to point out some factors why I am leaning toward Debian.
Open Source
Debian is a true open source platform. They do not like to provide proprietary stuff, which can cause problems sometimes, but if you can live with it, Debian is for you.
Very Good Server
Debian is generally accepted to be a very good distribution for servers. Packages are well tested and remain stable in production. Since Debian is conservative in updating packages, usually software you are using may be not exactly the latest one. If you like this kind of stability, then Debian is for you.
Lots of Options
Debian has lots of packages available. Anything you need has a very likely chance of being available in here. Debian also supports a wide variety of architectures giving you options to your heart’s content. If you don’t like the Linux kernel, maybe you can use some others that Debian offers. If you prefer one desktop environment over another, go ahead and use it.
I was surprised to learn that RHEL only supports ext2 and ext3 file systems. If you want to use something else, say JFS, it is not supported out of the box. Debian, on the other hand, supports many file systems. Add another category to the options list from Debian.
Apt-get
There are many forms and formulations of apt-get, such as aptitude, dpkg, synaptics, and maybe others. This is a great package manager and it is very easy to install and remove packages. It takes care of all dependencies and you don’t have to worry about them.
If you want to install a third-party rpm package built for Red Hat Enterprise Linux (RHEL) ecosystem, you can do so in Debian easily. So if there is an application you need which is officially supported on RHEL only, you can still use it, albeit without the ‘official’ support.
Auto Upgrades
You can upgrade your computer at simple package level (as new updates become available, sudo apt-get upgrade) or upgrade your whole OS with a simple apt-get command (sudo apt-get dist-upgrade). Could it be easier?
Ubuntu
Ubuntu is a distribution derived from Debian. It aims for user-friendliness and keeping up with changes in technology. It is a perfect compliment for your Debian servers on your desktop. Dell is selling computers with Ubuntu pre-installed. If you know Debian, you know Ubuntu. Combining both gives you best of both worlds.
Conclusion
Debian gives you options with complete freedom to do with them what you want. It is a stable, conservative distribution which is great for servers. If you want to use it on desktops, use their testing and unstable branches, or try out Ubuntu, Linux Mint, or SimplyMEPIS. So sticking with Debian ecosystem gives you everything you need out of an open source OS.
Useful Resources
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.
1 comment