Category: Linux

Linux is my primary operating system. I used it on the servers, desktops, laptops, netbooks, and even mobile phones since approximately 1997. I’ve tried a number of distributions over the years, and even created a couple myself. I still look around sometimes to see what others are up to. But most of my machines are running some sort of Red Hat – either a quick and easy Fedora Linux, or a stable and secure Red Hat Enterprise Server, or a cheaper CentOS alternative.

And while by now I am very comfortable in the Linux environment (both graphical and command line), I still discover a lot of new and interesting things about it. When I come across something worthy, I usually share it with the rest of the Open Software world, using this category.

The purpose of an operating system

I came across a good reminder of the operating system’s purpose in this Slashdot comment:

The point of an OS is to make the software independent of the underlying hardware. Windows lost that independence a LONG while ago (Windows NT / 95). Linux still has it because of the underlying design of the whole thing.

The same comment also brought back some memories of the times when I was working as a system administrator at what is now known as PrimeTel.

Move a Windows server – you can be in for a world of hurt unless you want to fresh-deploy it every time. Move a Windows-client, historically you’d be prepared for blue-screens because you have the “wrong” processor type (Intel vs AMD – requires disabling some randomly named service via the recovery console, for example), reinstalling the vast majority of the drivers (probably from a 640×480 safe mode) and even then can’t be guaranteed to get anything back and working – not to mention activation, DRM, different boot hardware (e.g. IDE vs SATA), etc.

Move a Linux server – unless your OWN scripts do something incredibly precise and stupid with an exact piece of hardware, it will just move over. At worst, you’ll have to reassign your eth ports to the names you expect using their MAC address (two seconds in Linux, up to 20 minutes in Windows and a couple of reboots).

It’s been a few years since I did that. But I remember vividly how we used to move servers from one piece of hardware to another, and since we used a mixture of Windows and Linux servers, the difference was obvious. With everything else being equal, we could migrate a dozen of Linux servers in two-three hours, moving them in parallel. Windows machines took days and had to be approached with very little concurrency.

tmux – Linux terminal multiplexer

I stumbled upon a very useful tool – tmux. It is a terminal multiplexer for Linux. If you are using Terminator or screen, you’d want to check it out. If you don’t use either of those, you definitely need to check it out.

With tmux, you can have a single shell in which you can create multiple sessions. You can split each session into a number of windows. You can detach from tmux and all your sessions and windows will remain open and running, much like with screen. Later you can attach back to them again or you can start a totally new instance. The interface is keyboard driven. It is simple and intuitive, but as with any other tool, you’ll need a bit of time to get used to it.

If you are a Fedora Linux user, all you have to do to try it out is: ‘yum install tmux‘. If you can read Russian, here is a quick introduction to most useful shortcuts. Check the official website for the rest of the documentation.

RFC 2142 : Mailbox names for common services, roles and functions

I’ve always relied on my mail servers having a complete and correct /etc/aliases file with all the necessary aliases. I never even thought about who puts them there and why. It was just one of those many things that just work. Today I discovered that there is actually an RFC 2142, which describes standard mailbox names for common services, roles, and functions. Here is the abstract:

This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. Mailbox names are provided for both operations and business functions. Additional mailbox names and aliases are not prohibited, but organizations which support email exchanges with the Internet are encouraged to support AT LEAST each mailbox name for which the associated function exists within the organization.

On Linux and Android relationship

Linux Weekly News did an excellent coverage of James Bottomley talk at LinuxCon Japan on Linux and Android relationship. I’ve read several opinions on the matter and this one seems to be the most balanced and objective. There is something to learn here for every open source developer and enthusiast.

The community should do better at fostering and embracing diversity, encouraging forks (which can create significant progress) and helping them to merge back. Currently, James said, the kernel gets a “C – must do better” grade at best here. We only take code from people who look like us; as a result, the Android merge attempt was more painful than it needed to be.

Companies, in turn, should aim for “control by acclamation” rather than control by total ownership. Linus Torvalds was given as an example; he has a lot of control, but only because the community trusts him to do the right thing. In general, if the community trusts you, it will happily hand over a lot of control; that’s why the benevolent dictator model is as common as it is. On the other hand, companies which try to assert control through walled garden development or by demanding copyright assignment from contributors have a much harder time with the community.

In summary, James said, Android was a fiasco for everybody involved; we all need to figure out how to do better. We need to find better ways of encouraging and managing forks and allaying licensing fears. Projects which create forks should be thinking about merging back from the outset. Then projects which (like Android) are a commercial success can also be a community success.

Fedora 16 will use Btrfs as default filesystem

Linux Weekly News notifies:

At the June 8 meeting of the Fedora engineering steering committee (FESCo), the group decided that Fedora 16 will ship with Btrfs as its default filesystem. Btrfs is a relatively new copy-on-write filesystem with many interesting features such as read-only and writeable snapshots, multiple device support for RAID, online filesystem defragmentation, and more, though it is still marked as experimental in the kernel. “AGREED: Feature is approved. Will add some base critera to the page to be met by feature freeze. This is just a swap of ext4 to btrfs for default, not change of lvm or other parts of default.“

As noted in the comments, Btrfs is marked as an experimental feature in the kernel. As also noted in the comments, many other features which were marked as experimental were brought into production and that seemed to work fine.

While I personally have no knowledge of Btrfs stability or readiness for production, I am slightly worried by that move. First of all, ext4 – current default filesystem – works fine for me and for everyone I know. Why fixing something that works? It seems that Btrfs is a better choice for server platforms. And while Fedora is mostly used on the desktop, it is still a testing platform for Red Hat distribution which is, in fact, a server-oriented line of products.

On another note, Fedora 15 upgrade was a bumpy ride. Again, not just for me, but for everyone I know. Switch to Gnome3, sysctl, and other changes didn’t quite work out of the box for many people. Btrfs might do the same. I think it’s better to push such a change at least to Fedora 17. Let people recover slightly. Focus instead on fixing things which are broken. Let people regain confidence in Fedora distribution and its upgrade paths. Please.