This series is written by a representative of the latter group, which is comprised mostly of what might be called "productivity users" (perhaps "tinkerly productivity users?"). Though my lack of training precludes me from writing code or improving anyone else's, I can, nonetheless, try and figure out creative ways of utilizing open source programs. And again, because of my lack of expertise, though I may be capable of deploying open source programs in creative ways, my modest technical acumen hinders me from utilizing those programs in what may be the most optimal ways. The open-source character, then, of this series, consists in my presentation to the community of open source users and programmers of my own crude and halting attempts at accomplishing computing tasks, in the hope that those who are more knowledgeable than me can offer advice, alternatives, and corrections. The desired end result is the discovery, through a communal process, of optimal and/or alternate ways of accomplishing the sorts of tasks that I and other open source productivity users need to perform.

Saturday, April 28, 2012

Sixth installment: establishing wifi connections from the command line

Reader's Digest condensed version


Want to get on a wifi network fairly quickly and painlessly from the command line? Try network-manager's command-line cousin, cnetworkmanager. A command like sudo cnetworkmanager -C essid-of-network --unprotected (for unprotected networks) will do it. For further details on how I discovered this and for further remarks on cnetworkmanager's capabilities, read below.

Unabridged version


Trailing edge technologist that I am, I'm also a fan of minimalist desktops. I've used mainly ion2/3, dwm, and evilwm for day-to-day computing--though I've tried out many others like JWM, icewm, fluxbox, blackbox, twm, openbox, etc.

After my netbook's keyboard went on the fritz subsequent to having water squirted on it by a loved one (I can say she's a loved one in hindsight), I decided to dig out an old laptop and press it back into service. It is, of course, a single-core machine with a Celeron 2.4 Ghz CPU and only 512 MB RAM. So, another ideal candidate for a minimalist desktop.

I wanted to get the machine up in a hurry so I chose to install a lighter-weight *buntu on it--namely, Lubuntu. That variant uses the lightweight LXDE desktop.

After I'd gotten it set up and used it for awhile, I decided to try paring back the system resource usage yet further. The main means toward that end was to install the evilwm window manager which, though I understand it is not quite as lightweight as dwm, nevertheless looked like a good choice for this machine.

It took some trickery to be able to load into the evilwm desktop once the machine was booted. Lubuntu, you see, uses the LXDM login manager, and I was unable to create a valid menu entry for an evilwm session. So I used the quick and dirty method: cobble together an .xinitrc for evilwm, kill LXDM, then issue startx from the command line.

I'm in the initial stages of possibly replacing LXDE with evilwm on this laptop, but I've gotten at least partway there. I want to recount in this entry how I managed to get wifi connections working under evilwm. But first, a relevant digression.

I used to use command-line routines on another old laptop some years ago when connecting to wifi networks. That involved using commands such as iwlist and iwconfig, then issuing a dhcp request on the wifi NIC. At a certain point, however, my trusted command line routines stopped working for reasons I could not understand.

Searching for alternatives, I discovered wicd. I actually doubted it would work since, as I understood it, wicd was simply a series of python scripts that invoked the same command-line binaries I'd been unsuccessfully attempting to use.

But wicd did work, and to my delight, I even discovered that it had a curses, terminal interface: I thus needed not be bothered with using a pesky gui utility to employ wicd. I subsequently came to rely on wicd for establishing and managing wifi connections.

Getting back to evilwm; those who are familiar with that window manager will be aware how minimalistic it is: there are no taskbars, no system trays, no pop-up menus. No, all evilwm does is display the desktop background you specify and allow you to open graphical applications (invoked from a terminal or by using something like xbindkeys and gmrun).

That sparseness presented an issue with wifi connections once I started switching from LXDE to evilwm: you see, Lubuntu has set up this system such that it uses network-manager for managing wifi connections, and network-manager, in turn, expects there to be a system tray in which it can reside. Given that architecture, I could see no way in which I could use network-manager for my wifi connections while running evilwm.

My first assumption was that my old standby, wicd, would allow me to manage wifi connections under evilwm. So I installed it. But it would not, no way, no how, allow me reliably to connect to wifi networks.

I am uncertain why this problem exists. I read that it was related to some conflict with network-manager, and that the solution was to uninstall network-manager. But doing that did not resolve my problems: wicd would, for the most part, give me a "bad password" error and would not connect to the network: perhaps once in every thirty tries I could get on-line, but the other twenty-nine times, I would get the bad password error.

Short story long, I had to abandon wicd and look into other ways of connecting my laptop to wifi networks using command line utilities. My attempts at finding an alternative to wicd finally resulted in the discovery that there is actually a command line version of network-manager called cnetworkmanager.

The happy ending to this story is that cnetworkmanager's man page is fairly simple and easy to comprehend for the non-specialist. I was, in very short order, able to bring up my wifi network connection using cnetworkmanager. Below are salient details.

In order to find the name of your wifi network interface and, at the same time, scan for essid's of detected networks, the command cnetworkmanager -a -d run in a terminal does the trick (-a is the option that lists available networks, -d is the switch that tells you the names of wifi interfaces on the machine being used). With that information it is fairly simple--though super-user privileges are required for this--to a network as follows.

For WPA-encrypted networks, the command sudo cnetworkmanager -C essid-name --wpa-pass=password will do the trick. For unencrypted networks, sudo cnetworkmanager -C essid --unprotected does the job.

It's a bit clunky, but provides a workable solution that gets me by for now.

Wednesday, April 11, 2012

An explanation of html tags used at blogspot

This is just a sort of filler entry, for my own reference. It will contain an explanation of html tags blogspot posts use, and is intended to help me utilize sane editors for creating my blog entries rather than the ungainly blogger web interface. See below.

Here's a first paragraph. It consists in two sentences and, after the pariod, an extra carriage return so as to space the paragraph apart from the following paragraph.

Here's a second paragraph. It, too, consists in two sentences followed by an extra carriage return--as do all subsequent paragraphs in this test.
Here's a block quote. As all paragraphs should, it consists in at least two sentences.
Now, here's a paragraph after the block quote. Once again, we see two sentences.

Now, for a fourth paragraph that contains a link. The link is here.

Moving on to the fifth paragraph, we'll enter some bold, the italic, text. Here's the bold. Here's the italic. And here's some underlined text.

For the sixth paragraph, we'll change the font size. Let's try what they call a "large" font. Now, back to "normal" font.

In the seventh paragraph, we'll change the font face. There's not much to chose from, so here's arial. Now, back to the "default" font.

Now, we'll try inserting a numbered list, then a bulleted list. Here's the numbered list, in a new paragraph (apparently, the extra carriage return is not needed at the beginning or end of lists):
  1. item 1
  2. item 2
  3. item 3
Now, the bulleted list, in a new paragraph:
  • item 1
  • item 2
  • item 3
I'd like to insert a table, but I don't see any way to do that. So, let's try some strikethrough. Very impressive.

And, after this eleventh paragraph, a pseudo-list of a few lines of text, each on a separate line:

one
two
three

Finally, just for kicks, let's insert in this twelfth paragraph what they call a "jump break" (not sure what that is, but . . .) 

Monday, April 9, 2012

Addendum to the first installment: alternate screencast applications

As you may recall, in the inaugural entry for this blog I described a crude mock-up I'd cobbled together, using Linux utilities, for producing screencast video lectures along the lines of those found on the khanacademy web site. I recently had occasion to explore some alternate screencast applications, since ogv files ceased playing back sanely on one of my systems. That issue was ultimately addressed by "upgrading" the video card in my aging Pentium 4 computer (with an old 128 MB nvidia card I got for $15). But not before I investigated some alternatives to recordmydesktop.

Of course there are various options for screencasting in Linux: I've read about Istanbul, Byzanz, vnc2flv, and some others, for example. I've so far gravitated toward recordmydesktop because it "just worked" and because it can be used from the command-line. But because of the video card issue mentioned above, I did recently decide to explore a couple of other alternatives which I'll write about in this entry, namely xvidcap and ffmpeg.

I should mention at the outset that, as those who read the first installment of this blog will be aware, I need something that not only records a video of a part of the desktop (actually, a particular application window in my case), but that allows for sound recording as well: after all, these are lecture videos I'm producing. So any screencast application that does not have built-in sound recording isn't going to work for my purposes.

Screencasting with ffmpeg

Most readers of this blog will have heard of the indispensable video-manipulating program ffmpeg. It's possible to do a truly amazing amount of manipulation and creation of videos using that program. And, as it turns out, it's even possible to do screencasting with it (in fact, ffmpeg may actually be used "behind the scenes" by recordmydesktop--though I'm not fully certain about that).

Some recent research on the web resulted for me in some successful experiments in screencasting with ffmpeg. The main ingredient in this screencasting capability is a switch called x11grab. Run from the command line, an ffmpeg screen/sound capture session would be invoked something like this:

ffmpeg -f alsa -ac 2 -ab 48k -i hw:0,0 -f x11grab -r 20 -s 800x600 -i :0.0+227,130 -acodec libmp3lame -vcodec libx264 -vpre lossless_ultrafast -threads 0 output.avi
That command will output an avi file called, appropriately enough, output.avi that is 800x600 resolution and that grabs a portion of the screen that is 227 pixels from the left edge and 130 pixels from the top edge (about where I open the application I wish to record on this machine). The sound portion is transcoded into mp3 by libmp3lame--something I discovered reduces the final size of the file considerably.

I believe ffmpeg can output just about any video format, including ogg theora, as recordmydesktop does. In order for that to be implemented, the -vcodec argument needs to be modified to, in the case of an ogg theora file, to -vcodec libtheora, I believe, while the extension of the output file's name would need, obviously, to be changed to .ogv.

As those who are familiar with ffmpeg will know, I'm barely scratching the surface of the tip of the iceberg here as far as its capabilities go. In fact, ffmpeg's man page has got to be one of the most voluminous and daunting of them, and it's only within the last couple of years that I've begun to be able to make any sense of it. But don't presume that I mined the information above mostly from the man page: rather, I found a working sample command on the web, then went back to the man page to try and better understand how it works and how I might tweak it for my purposes. I'm really still on a very rudimentary level when it comes to understanding and using ffmpeg.

Now, though this ffmpeg solution works quite well, it's turned out to not really be usable for me. This is because, as great as it is, the ffmpeg process cannot be paused while it's running: you either have to stop it and resume anew if you have some reason to pause, or else you'll need to edit the resulting video and cut out  the extraneous portions. In case it's not apparent, it's really useful during a lecture to be able to pause and resume.

So, as well as it worked in my experiments, I decided that, until I can come up with some way to pause the process, then resume, ffmpeg is not going to work for me as well as recordmydesktop does.

Screencasting with xvidcap

Which bring my to the next screencasting application, xvidcap. There's a lot to like about xvidcap. It's a graphical application, but with a very minimal interface--just the type of gui application that appeals to me. It draws a nice, visible perimeter around the area you're recording, and the perimeter can be easily manipulated with the mouse to enclose whatever quadrangular area you'd like. And it does allow for pausing and resuming of the screencast.

A screenshot of xvidcap (running on someone else's machine)
Furthermore, it's able to output a few video formats, among which are mpeg and flv. It looks like a great application and I really wish I could use it. But there's a major problem with sound: you see, xvidcap was developed during an era when oss (Open Sound System) was the standard Linux sound server, but oss is now deprecated in favor of alsa (Advanced Linux Sound Architecture).

In theory, it's possible to emulate oss with alsa. That's what you'll read on the internet, anyway. But the fact of the matter is that, as Linux moves further and further away from the old oss architecture, emulation of it has become harder and harder. I spent quite a few hours trying to implement it on this system, so happy was I with what I'd seen of the video-capturing end of xvidcap. I tried a number of purported solutions I found in my web searches. But none of them enabled me to record sound alongside the video I was capturing with xvidcap. So, I've reluctantly given up on it for now.

Those are the two alternate screencasting programs I've toyed with lately, and with mixed results. Both seem to have their advantages as compared to recordmydesktop, but in the end, it looks as though neither is going to be able to displace it. If you have any sort of pointers for addressing either of the issues I experienced in my attempts to use those applications, I'd be most delighted to hear about them. So please do offer your input.

Segmenting video files

To wrap up this posting, I need first of all to confide that I finally did "upgrade" my old work PC. I replaced the aging Pentium 4 with a not-quite-so elderly dual core machine. So video recording, and especially playback, goes quite a bit more smoothly on this "new" machine.

One odd thing has cropped up regarding video, though. The problem is that, despite the fact that I use the same exact recordmydesktop command to record my screencasts, the resulting files are now almost twice as large as they had been on the old machine: instead of being on the order to 2 megabytes per minute, they're now closer to 4 megabytes per minute.

My suspicion is that the video hardware could be to blame, since I had a pretty old 32 megabyte ATI (PCI) video card in the old machine, while the newer machine has an nVidia 128 megabyte card (PCI-express). I've tried switching video card modules from nv to vesa, but that doesn't seem to affect the resulting video size.

This becomes a problem because I have a file size limit on the site where I must upload my lectures, and they're now routinely going to exceed the size limit. So, until I can figure out how to reduce the video file sizes back closer to what they were, I've had to come up with a work-around--namely to split the video files into parts that, individually, do not exceed the size limit. And for this, ffmpeg once again comes to the rescue.

In order to split my lecture files, I'm using the following command:
 ffmpeg -ss 00:00:00 -i in.ogv -t 00:30:00 -vcodec copy -acodec copy out.ogv
What that does is to start at the beginning of the file (the -ss 00:00:00 part), go 30 minutes into the file, then copy that section to a new file called out.ogv. So, for an hour-long lecture, after having done that to split off the first 30 minutes into a new file, the same command would be run again, except that-ss 00:00:00 would be replaced by-ss 00:30:00. Then, the two parts could be appropriately named (with part1 or part2 in the name, as appropriate) and uploaded.

That's all for this entry. If anyone has tips or recommendations about what's been discussed above or about anything else related to screencasting on Linux, please pipe in.

Afterthought: here's a link that offers some technical details on the sound hardware in my new computer: http://people.atrpms.net/~pcavalcanti/alsa-1.0.15rc2_snd-hda-intel.html#final . I was looking at that as I was trying to work out how I might get xvidcap functioning on this system.