I won’t explain what Awesome is: if you’re here, then you probably already know. If you’re don’t, this is an article to skip. This article also assumes you’ve messed around just a little - you know how to change the layout, switch between tags, and so forth.

Awesome’s “tile” layouts can do a whole lot - enough that I only ever use tile and max. Do yourself a favor and open your rc.lua file and comment out all the layouts except the tile, top.tile, max, and float layouts. If you’re just starting out, this will make it easy to learn to use a tilling layout - having all the others there is just confusing until you’ve mastered one and you know what behavior to expect from it.

The tile layouts have a primary area and a secondary area. There are four different tile layouts with the primary area either on the left, right, top, or bottom. Once you pick one of those, you can control how many windows are in the primary area - the rest fill the secondary area. You can split the secondary area into divisions and increase or decrease the number of divisions; it will fill each division with windows in a round-robin style, placing the new window in the primary area - if the primary area is full, the oldest window gets pushed into the secondary area.

Of course, if you open a window and specifically want to move it to the secondary area, it’s as simple as giving focus to that window and moving it down the stack.

This might sound complicated, but the keybindings are quite natural once you learn them (kind of like vim). All the window manager shortcuts start with the [mod4] (“windows”) key. It’s that with j/k to cycle up and down the stack, add [shift] to shift the position of the window in the stack. It’s the [mod4] key with h/l to increase/decrease the size of the primary area; add [shift] to that to increase/decrease the number of windows in the primary area or [ctrl] to increase/decrease the number of subdivisions (I remember “C”ontrol “C”olumn, even though it’s not columns if you’re using a layout with the primary on the top or bottom).

You might wonder how one could use tile mode for everything: what if you’re coding away (which usually involves several terminals open), then you need to open gitk - one of those tiny panes is way too small! Well, you don’t need to change the whole layout for that; you can toggle properties on individual windows to add either fullscreen [mod4]+f, maximized [mod4]+m, or floating [mod4]+[ctrl]+[space].

Your job will likely require you to do things you’ve never done before. This means you need to be able to research things on your own. To start with, learn to use man, the unix manual command. To start with, you can find out how to use man by opening a shell, typing man man and pressing [Enter]. That’s the manual page for the manual. Unfortunately, it doesn’t go into the generic syntax that all man pages follow. I’ll outline that here.

 Structure

A man page typically has several secions; some examples include NAME, SYNOPSIS, DESCRIPTON, OPTIONS, EXAMPLES, EXIT STATUS, FILES, BUGS, SEE ALSO, COPYRIGHT, andAUTHOR. Not all those sections are in every man page, and there are some sections of man pages that I haven’t listed. At a minimum, all man pages should have Name, Synopsis, and Options, in that order. There’s no rule that says a man page must have those things - the author can put anything in there, but usually, that’s the structure of a man page.

The NAME Section

The NAME section is very simple. It looks like this:
man - format and display the on-line manual pages
It simply shows the name of the utility followed by its purpose.

Impelmentations

I’ll take a sidebar right now to point out that you might see different content on your man pages. There are sometimes many implementations of the same utility, and they can work a bit differently; because of this, there are different man pages for those different implementations.

As an example, see the man pages for the BSD project’s find and from the GNU project’s find. There are some options like -readable and -printf that the GNU version provides that the BSD version does not. And that leads to…

BSD and GNU utilities

And here’s a sidebar within a sidebar to talk about the GNU and BSD projects and general differences between them. There are many Unix and Unix-like operating systems that existed before Linux was even conceived. One of those is BSD, the Berkely Softwre Distribution; it is a full Unix operating system, including a kernel and a suite of utilites. Another of those is GNU, which stands for GNU’s Not Unix. GNU was a project that also had a kernel (actually, they had gone through several kernels, none of which the project was satisfied with) and a suite of utilities.

When Linux started becoming useful, the GNU project decided that the Linux kernel was indeed sufficient for their needs until they get a proper kernel; because of this, they worked on making their entire software suite work on the Linux kernel. Because of the early marriage of the GNU utilities with the Linux kernel, most utilities in a Linux distribuion are GNU utilities. Also because of this early marriage, the GNU project insists that the proper name for the operating system that has a Linux kernel with GNU utilities is “GNU/Linux”; some people get very upset if you refer to Linux without the “GNU/” prefix in front (unless you are only referring to the kernel). I think that’s absolutely rediculous: it’s ugly, it’s difficult to say, and it’s confusing; just call it “Linux” and be done with it. I can build an entire Linux system without a single GNU utility by substituting other utility suites (such as Busybox), and it’s most definitely not GNU/Linux at that point.

Anyway, there is a generic pattern that the BSD utilites are simpler and the GNU utilities offer more features. Some people prefer one over the other. There is a Unix philosophy that says software should do one thing and do it very well - some people think the BSD utilities follow this philosophy better than the GNU utilities and that the GNU utilities are unnecessarily complex. People who prefer the GNU utilities can point out circumstances where a feature (such as find’s -printf can save several lines of complex shell script that would be needed to compensate for the missing feature. Most people find it doesn’t really matter - they just use the tools that are on whatever system they are using. Additionally, there are other people for which it doesn’t matter particularly that a utility has or doesn’t have a feature - the problem for them is that they are charged with writing scripts that use those utilities and those scripts have to work on multiple systems with varying utility suites - and that can be a real pain, especially when utilities have the same option name for different features or different option names for the same feature. Most of the scripts I write do not have to work on multiple systems, but every once in a while, they do, so I’ve adapted the policy of trying to be aware of common problems and avoiding them in all my scripts so that surprises are less common. Answering questions on the Unix & Linux Stack Exchange is a good way to find these problems. I usually test my answers on a Linux system with GNU utilities, a BSD system, and a Linux system with Busybox utilities - even so, sometimes there is a problem with my answer on an Oracle system, for example. Usually, people will point out the problem in comments and that is a great learning experience.

The SYNOPSIS Section

The synopsis section describes the invocation syhntax. It looks like this:
man [-acdfFhkKtwW] [--path] [-m system] [-p string] [-C config_file] [-M pathlist] [-P pager] [-B browser] [-H htmlpager] [-S section_list] [section] name ...

The italicized words are placeholders - those are phrases that you have to replace. The straight leters are literal - you would actually type that as part of the command. Any part in square brackets [...] is optional. Here, you can see that to invoke this command, you must type “man” and a name; everything else is optional. When we typed man man, we replaced name with man, and we did not use any options.

Sometimes, the Synopsis will not list out all the options as demonstrated above, they will simply say [OPTIONS] and later (in the OPTIONS section) list out every option. Additionally, sometimes only the most common options or only the short options are shown in the synopsis.

The OPTIONS Section

The OPTIONS section lists al the options, explains what they do and what arguments each option might take.
-P pager Specify which pager to use. This option overrides the MANPAGER environment variable, which in turn overrides the PAGER variable. By default, man uses /usr/bin/less -is.

Here, -P is the option, and it takes an argument, pager. This particular option is for specifying what program to use to display the man page. more is another pager utility that is commonly available on Unix systems. You could call this command like so: man -P more man to view the man page using the more pager. The more pager has fewer features than the less pager, so a funny joke is less > more.

Sometimes, an option will have more than one name - usually a short name and a long name, those are shown like so:
-k, --apropos Equivalent to apropos. Search the short manual page descriptions for keywords and display any matches. See apropos(1) for details.
This option can be invoked using either -k or --apropos.

By the way, that particular option mentions another command, apropos that is very useful. It can be used if you don’t know the name of a utility, but you have some idea of what you want to do. For instance, maybe you want to rename files, but you tried rename banannas.jpg karen-holding-bannanas.jpg and the shell complained that rename wasn’t found. Try apropos rename, and you’ll see one of the available man pages is mv (1) - move (rename) files - that sounds perfect!

Conclusion

Once you learn how to read and understand man pages, a whole world opens up. If you’d like an excersize to help you learn to read man pages, go to sprunge.us and learn how the command they suggest works. Use only man pages to figure it out - then, also using only the man pages, figure out how to do the same thing using the wget utility.

I know someone who is a Linux enthusiast who recently landed a job where he is expected to do serious work around Linux. I offered some advice, and when I was done, though it may be worth sharing here. If he’s pretty nerdy like me, he’s probably wondering how he can get started right now, even though he doesn’t officially start for a couple of weeks. Below is the e-mail I gave him; it has suggestions to follow, particularly for someone who has a short time between after that first Linux job before actually starting. My next post will probably be suggestions to follow if you haven’t yet got that job, but are looking.

Learn POSIX or Bash Shell Scripting

If you want to get a head start, we do a lot of shell scripting, so you can have a look at these guides for getting started with shell scripting:

1. Greg’s Wiki: BashGuide
2. commandlinefu.com one-liners explained
3. Advanced Bash Scripting Guide

Super hard-core nerdery and installing Gentoo

You previously mentioned compiling Gentoo. It has the reputation that you have to be super hard-core nerdy to be able to install it, but to be honest, I’d highly recommend against it; it’s mostly a waste of time, and the system it produces (if overlays are involved) can be quite fragile. The things you learn doing that are very Gentoo-specific, and not really useful for dealing with Linux in general. The best way to learn Linux is by using it. With distributions like Fedora and Ubuntu, you’re not really using Linux, you’re using Fedora or Ubuntu, which are using Linux. They hide much of the parts of Linux that we really use in our work. I would highly recommend installing Arch Linux, which is a pretty pure Linux system - you will learn how Linux works without all the extra stuff that is Gentoo-specific, and it’s pretty quick to setup and start using. If you want to go even more raw, Slackware is there, and the Slackware book is awesome.

Finally, the ultimate step (as far as building a Linux system goes) is Linux From Scratch. This is what separates the children from the grown-ups. You start out even more basic than Gentoo starts, and the skills you learn with this actually are generically useful. However, the system you end up with in the end isn’t that useful because you will spend a lot of time either maintaining it or developing tools to maintain it for you, and at that point what you end up with is your own distribution.

EETimes.com is reporting that according to ABI Research, ARM will overtake the Netbook market by 2014. This is exciting for a couple of reasons. ARM is just an IP supplier; it’s still up to foundries to make the chips. Also, the nature of ARM devices is that they can be easily modified by third parties. This means the CPU market will be much more diverse than it has been for a while. The other exciting reason is that Windows (except for Windows mobile, which is worthless) doesn’t currently run on ARM architectures. We will most likely have much more Linux out there. Either that, or Microsoft steps up their effort on ARM architectures, which is also exciting.

There is much discussion of i4i’s U.S. Patent #5787449 and their request for an injunction of the sale of Microsoft Word. Unfortunately, many people have the wrong idea of what is happening. The patent deals specifically with the implementation of a certain feature in word - the ability to add your own custom XML schema and tags to a document. This is not about the .docx format, and it isn’t about the feature itself; it is about the feature’s implementation.

XML documents are structured documents. The structure is represented by tags within the content such as the following:
<document id = "112358"> <type>book</type> <title>A guide to writing guides</title> <author>Jane Doe</author> <publisher>McPublisher</publisher> </document>
This code is meant to be machine and human readable. Typically, a person will view the document with a special program that transforms the document into a more presentable format and shows the relevant information, formatted in a way that is easier to read, without the tags in the way.

A challenge comes when it is time to edit the document. A person could certainly edit the code directly; it is, after all, meant to be accessible to both humans and machines. This method, however, can lead to errors. It is also taxing on the person to have to enter the tags manually. It would be much better if the person could edit it the way it looks when it is presented nicely.

There are a couple of ways that might immediately come to mind about how a computer program might be written to do this. The first is to display the document in a well-formatted way, and have the tags be present in the document, but not visible to the user. The other way this could be accomplished is to have the document represented internally in a different way - the content is in one piece like this:
112358 A guide to writing guides Jane Doe McPublisher
and the structural information is in another piece, separate from the content. One might imagine a list of tags and pointers that point to character locations of where they belong:
document 0 title 9 author 37 publisher 48 ...
The second piece is a map that assigns certain tags at certain locations in the document.

It is apparently Microsoft’s Custom XML feature that implements this mapping method and that may be infringing the patent. The patent actually doesn’t specifically reference XML, it is more generally for any separation of document and its structure. However, the company specifically makes software that deals with XML in this manner, and this is what they are looking for an injunction for. I will be very surprised if the patent is ultimately found to be valid; there must be some prior art for this method.

I hope that this explanation helps to clear some confusion surrounding the issue. If you have an observation to add, please leave a comment below.