K.Mandla’s blog of Linux experiences
A brief note if you’re running the VICE emulator in Ubuntu with the instructions I posted years ago: The updates for Ubuntu to 9.10 and for VICE to version 2.2 seem to play nice together.
Nice to see that it still works, more than three years after I figured it out. I wish I could always be so lucky. 
I have a long history with console music players, going back well into the early days of my Linux experiences. I staked out an early preference for cplay, which unfortunately was akin to betting on a losing horse, since cplay has since vanished. But these days I am a staunch moc supporter — now there’s a console music player with a serious future.
But there are a lot more than just two console music players out there in the wild. Take a casual walk through Arch-plus-AUR with a sprinkle of Google in there, and you can come up with at least six more working options, plus references to just as many more that are hard to find. Take a look.
At the top left is Orpheus, and opposite it is Herrie. Center left is mp3blaster, next to cmus. And at the bottom left is ncmpc, next to mcplay. (Sorry about the jpg artifacts. Your bandwidth is precious.)
I can’t practically examine every single one here, but I can tell you a little about each one’s style and approach. Much in the same way as graphical music players, some maintain libraries of your music titles, while others rely on file browsers and playlists. Both styles have their fans; I for one happen to resent music “managers” and prefer browsers and lists.
Orpheus, for example, would probably be my player of choice if I didn’t have moc to enjoy. Nicely colored and easy to figure out, it has a clear playlist and straightforward commands to add things. Good use of screen space and a built-in search function. Technically it’s a few years out of development, but that doesn’t keep the Arch version from working.
Herrie would probably be my third choice, since it also has a playlist/browser approach, but Herrie’s style seems somewhat cumbersome at times. Although the default keybindings and controls are similar to cplay, I don’t like that titles seem to be removed from the list as soon as they are finished playing. Sometimes I like to hear a song again, and a queue-system like that is less attractive.
mp3blaster was the first console-based music player I ever remember trying, and it doesn’t seem to have changed much in the time since then. It is actively developed though, or at least received a stable update in the last year. From a strictly superficial standpoint, it’s probably the most obvious to figure out, since all the keypress options are labeled on-screen — all the way down to accessing your audio card controls. On the other hand, it seems a little cluttered now, which is probably a side effect of having worked with moc for so long.
cmus is opposite of mp3blaster in that screenshot, and it’s easy for me to understand why it has a following. Keystrokes mimic a lot of vim commands, it uses a library system to access files, and it has a quick, clean feel about it. Personally I got a few screen artifacts while running cmus, particularly while accessing files inside folders with unusually long names. Not that that is a dealbreaker, but in addition to the fact that I don’t like music managers, it’s enough to keep me happy where I’m at.
I have ncmpc in that screenshot but it’s not configured, which is why you see error messages there. ncmpc is a terrifically terse frontend for the mpd system, but it’s only useful if you can get both of them installed, configured and handshaking. That last part has always been the stumbling block for me. 
The last one you see there is mcplay, which looks and behaves almost keypress-for-keypress the same as cplay. That’s intentional, with the code-level distinction of being written in C, as opposed to the original’s Python. Whether that’s a good thing or a bad thing depends on which language you prefer to use. To me, there’s no difference.
Many of these players reach back to the early part of this decade, and some of them might even have their roots in this one.
That’s mjs, the MP3 Jukebox System, a program so old it was intended for use on Pentium I and Cyrix machines. The code is still available, and its predecssor — a program called mms — is still in some RPM archives. mjs will compile in Arch, although I got some strange screen colors while I was running it in rxvt-unicode, and I couldn’t get it to connect to my audio hardware. However, if you need an extremely lightweight player that can handle mp3 files, this might be the winner. Be prepared to dig around in its guts though.
Also on the list, but not in a working state for me, were jinamp, benmp3 and pytone.
If you’re willing to work with the old XMMS audio player, you have several CLI interfaces that might be useful to you.
Left to right that’s …
These might be useful over ssh, in a situation where you have a remote machine that can handle the oh-so-taxing graphical demands of XMMS and GTK1.2, but want to control it from the console. Being terribly honest, I don’t know if I personally would bother with any of them, since a machine that can handle XMMS can likely do fine by itself without a CLI prod.
Also be aware that some common video applications have audio playback capability. Here, top to bottom, are alsaplayer with the -i text flag, MPlayer playing audio files, and VLC‘s ncurses interface — which I must admit, I find very attractive.
The first two are rather primitive, with little in the way of interaction that doesn’t fall outside their normal keypress playback. The vlc version is just as useful as — and probably more flexible than — most of the console applications you see above.
This isn’t all of them, of course; it’s just not possible to scrape up all the audio players out there, even at the console level. This is a rough list, and if you’re looking for something to run light and take up little space, it might be helpful. Otherwise, if I’ve forgotten one, remind me of it. 
A long, long time ago, someone mentioned to me that it was possible to zip up an entire installation, and transplant it into another hard drive. I only halfway believed it at the time, since it seemed rather far-fetched and I was but a newb (I still am). But it sat in the back of my mind like an emergency exit, in the odd chance that I might need to use it … even if it sounded preposterous.
But you know what? You can do it. It works fine. In fact in some situations, it’s easier than actually installing a full system.
I wanted to move the entire installation from my Thinkpad to a different hard drive. I was using the 120Gb Western Digital Scorpio that fell out of the sky into my hands, but I have a faster-yet-smaller hard drive — a 7200rpm 60Gb Hitachi — that I would prefer to use. I don’t need 120Gb of storage, and the space would be better spent in an rtorrent slave or in an external case.
But the Scorpio had a Crux installation on it — a six-month old console-only installation, and not one I was keen on rebuilding just to swap drives. I like the idea that it’s at least a half a year old, and that it hasn’t needed any maintenance other than regular updates.
Cloning was not an option, since the cloning tools I am familiar with don’t seem able to “scale down” an image to fit the drive — Clonezilla, which is a gift from heaven in the category of backup tools, gives me errors if the partitions don’t match quite right. And technically I don’t have space to mirror the drive to, since the only other drive I have is my storage volume, which is where the real-life important stuff lives.
So I began to wonder if I could really unload all the files, then copy them back, and still have a working system. I read it on the Internet, so it must be true. …
And this time it is. Here’s how:
First, offload all the files, by directory. I usually have a three-way partition split, with a separate /boot, root and /home. (Why? Don’t interrupt.) Jump into a live environment (any live CD will do) and make three new folders on a destination drive — in my case, it was the storage volume — and label them hda1, hda3 and hda4 … although really, the names don’t matter.
Mount them so you can write to them, maybe putting them in /media/…/hda1, hda3 and hda4. Just to keep things clear in your mind, you might want to make a /media/destination and /media/source folder, to avoid accidentally putting the wrong stuff in the wrong place.
Next, rsync is your friend. You’re three quick steps away from mirroring all the files.
rsync -a --progress /media/source/boot/ /media/destination/hda1/
rsync -a --progress /media/source/home/ /media/destination/hda4/
Now the last one is a little funny.
rsync -a --progress /media/source/ /media/destination/hda3/ --exclude=proc --exclude=sys
I left out files in /proc and /sys since most of those are generated by the running system, on the fly. And those trailing slashes are important. rsync is a really fantastic tool — one of my favorites — but it’s very precise about what you ask for. If you leave off a slash, it will insert an entire directory inside another, rather than making the two folders identical. Which is what it’s supposed to do, but not what we want.
One other thing: If you’re like me and you build your own kernels, remember that the kernel source code might only be 60Mb or so, but once it’s decompressed, configured, compiled and finished, that darn tree can take up an easy 500Mb. Before you go transferring your entire installation to an external drive across USB1.1 
, you might want to take out some of the unwanted stuff. I am speaking from experience here. 
Wait patiently while the text scrolls by. … And once that’s finished, then you can swap the drive and reverse the process. I used the same partition arrangement with a slightly smaller /home directory, then rsync’d everything back across. It took a while, but after it was done and all the files were in place, I did a filesystem check and reinstalled grub (I use the command-line interface to install grub. I’m cool that way 
) and rebooted.
And what to my wondering eyes should appear … but the same system I was using a few hours earlier, with all the stuff still in place, all the files and all the network connections and framebuffer support and so forth and so on, just like I left it on the other drive. No boot problems, no file inconsistencies, no error messages, nothing. It didn’t even know it was on a different drive.
So it’s true, you can actually copy an entire Linux installation between drives, and it’ll work. If you feel daring and want to try it for yourself you can give it a whirl, but make sure you save all the important stuff before you begin. Remember, you read it on the Internet, so it might be true. …
About a month ago, foo left a comment asking a fairly straightforward question: Are terminal applications becoming less prevalent, as Web-based services and cheap, powerful PCs become more common?
The answer I gave then was just off the cuff, but in the month since foo asked it, the question has been rolling around in my head. And then today, Xyzzy left a note mentioning that the home page for fttps has gone offline — taking with it the source code for that application and others — only a year after Blice originally posted there.
There’s no real correlation between the two events, but for someone like me who prefers life at the CLI, it does seem worrisome. In the time since foo’s original comment, I began making a list — three lists actually, one for console projects which were still very active, one for projects that had obviously sputtered and died, and one where the programs had achieved code Nirvana. That last one is my way of saying what I originally suggested in my reply to foo — that perhaps in some cases, there just weren’t any more features to add and weren’t any more bugs to chase.
For example — and all of these are footnoted with the phrase “to the best of my knowledge” — rtorrent is still under heavy development, and that’s probably the strongest example to the contrary. At the time of this writing, there had been an update to the trunk source code within 25 hours — in other words, on or very near Christmas Day. Most people I know who are even remotely influenced by Western culture are sitting at home, stuffing their faces with leftovers in the hours that follow Christmas Day.
So for a program — a console program, no less — to be getting updates that recently and in that particular bracket of time suggests to me avid pursuit. Midnight Commander is another example; The prerelease version I put together was stamped “stable” less than 48 hours ago — again, on or around Christmas Day. There are others, and I could cite any heavily used console application as an example to the contrary — vim. irssi. Even centerim is quite active, with the 4.22.9 update less than two weeks ago.
But for every one that I mention I have to acknowledge that there are some that have no pulse. I mentioned beeswax a while back; there’s a program with potential that doesn’t seem to be moving forward. cplay is a classic example of a popular but evaporated application; that one is so dead even the home page has disintegrated. Raggle gets mentioned as a newsreader a lot, but apparently stalled in 2005. Again, there are plenty of examples.
And those perfect programs, the ones that don’t need updating? My list gets a little fuzzy in there.
It is true though, that a lot of the software I use on a daily basis is 3 or 4 years old, and sometimes it’s hard to tell a hiccup from a year-long break. hnb, which I’m looking at right now, is a release from March 2003 — and I will admit wholeheartedly that that’s old. I won’t argue with you if you accuse me of using outdated software because that, friends and neighbors, is a dusty old program. Is there an update coming? Who knows.
But that doesn’t make it any less useful or stable. It only becomes an issue when it stops compiling or running, because the software that supports it is developing out of pace. So I can only assume that one day, perhaps in the not-so-distant future, I’ll get segmentation faults from hnb when I try to start it, sort of like I do from elmo.
But again — and this is the third qualification in a row now — any project, console or graphical, always runs the chance of finding a new direction or new leadership. And that’s the best thing anyone can hope for, for any “dusty old program.” Elmo got lucky a month ago and found someone willing to adopt it, and perhaps even something like cplay will too, if Daniel finds the time and desire to flesh it out further.
The phenomenon isn’t confined to console applications either; I’ve been begging and pleading with the Internet for years for some talented coder to pick up the corpse of ObMenu and keep it up to date with the changes in Openbox. It hasn’t happened yet and the home page is the same one I’ve been looking at since late 2005, but that doesn’t rule out the possibility. iDesk is another that could probably benefit from a little encouragement, since it’s been the same codewise as it was when I first found it in Ubuntu in November 2005.
I’m not a coder, so in that sense, it’s completely pointless and even a tiny bit rude for me to suggest that certain programs need attention. I’m not in a position to fix anything, so my opinion amounts to nil.
But I do know, and believe in, this: Open source software has many beautiful and amazing advantages over the closed-source model. And only one of those benefits is the idea — no, the proven principle that, 10 or 20 or even 50 years down the road, someone might pick up some crusty old tarball off a backup server somewhere in a forgotten university somewhere on the planet, take a look at the source code and add a new spark of life to an otherwise lusterless, forgotten application.
Old programs don’t die, they just patiently await reincarnation.
Like I mentioned a few days ago, I have an ever-lengthening list of console applications (mostly console applications, in truth) I want to try out in the next few days, once my holiday break starts. Some of the smaller ones I’ve already started tinkering with, and I have a new screensaver now, as a result.
Meet clockywock, which stands as a sister program to my uber-favorite tty-clock.
It looks innocent enough, considering that it does a fair job showing an easily readable analog clock on the console. The animation is smooth at 550Mhz against the framebuffer, and while it’s a bit touchy distinguishing between the hands at particular times, it’s visible at a distance and scales itself to whatever space you give it. It’ll run in screen, in a corner of screen or as a blanker for screen, if you tell it too.
Configuration is easy too — just press a random key, and you get a very discreet options box.
As configurations go, this is a bit unusual, since you roll between keys to change the characters for each hand. If that’s not convenient enough, you can hand-edit (get it? hand-edit! 
) the .clockywock file and change them directly.
And as if all that wasn’t enough, clockwock has an alarm and a snooze function. So you can use it … well, you can use it like an alarm, of course. 
(I didn’t get any sound out of clockywock personally, but I have a rather oddball system, so it’s possible that’s my fault.)
If I could make any suggestions, it would only be the addition of color. I think it would be far easier to read clockywock at a distance if you could, for example, set the hour and minute hands to different colors, or maybe use solid blocks of individual colors instead of console characters. Perhaps it’s possible to do that with escape characters in the .clockywock file; I’m not sure I’m interested enough to pursue that.
As it stands this is another solid example of a console program that fills a function — in this case, something as simple as a clock display — does it cleanly and simply, and doesn’t require a wagonload of dependencies to get the job done. A gold smilie for clockywock: 
I’m always intrigued when I can see that a project has a new owner. And so in the same way I was excited when I saw that axel had a new leader, I am happy to see that someone has picked up the elmo project.
I tinkered with elmo earlier this year, although I never got it fully working against the four web-based e-mail accounts I have. It’s a shame, because while alpine is a perfectly good e-mail reader, there’s never anything wrong with trying something new.
My most recent attempts to build it, however, have met with segmentation faults in both Arch and Crux, which tells me that there is some sort of inconsistency between the freshest code, which was released in August 2004, and … and … something else. Earlier versions will build and run, but only under a blank, default configuration. Once I give it the connection information, it crashes again. It’s strange.
So I hope elmo — the project, that is — makes some strides under the new management. There are other e-mail alternatives that work — mutt, or alpine to name the two biggest I know — but more options are always good. It’s all about freedom.
This might look like it’s the result of my run-in with Yakuake earlier this week, but I’m afraid it’s part of a larger, more dangerous trend — the circular motion that has brought me back to Musca.
Yes, I’m afraid it’s true. I used IceWM for most of the month, and I even put Openbox on the 600m today, but what has drawn me back around is the desire (need?) to use more applications without losing space on the screen. After four or five years at 1600×1200, I’m afraid even 1024×768 isn’t good enough for me if I have to use GUI-based applications.
And more often than not, it seems like GUI-driven stuff is an obstacle, not a convenience. There are always some things where a GUI is still just the easiest way to do things — I renamed about 120 audio files yesterday in the space of seconds with EasyTag, whereas it was taking me the better part of an hour just to get them arranged properly at the terminal. But for other things, it’s just not convenient to swing around the mouse to find one particular button to do a job.
Midnight Commander is quicker and faster than emelFM2 now. Building the Openbox menu seemed like a huge chore, even after I brought in menumaker to do most of the heavy lifting. dmenu-xft is a far better option, if I have to take into consideration the time it took me to click-click-click through ObMenu, instead of just typing in the name of the application.
And Musca is the best splicing of a graphical and console environment, for my purposes. I know Awesome, xmonad, dwm, etc., are all good stuff, but they seem like overkill for me — too many features when all I want is to split the screen four ways and nudge things around a little bit. Each tiling manager has its fan club, but Musca is clean and fast and simple enough to win me over.
It’s a little odd that the applications and window manager I used for months on a Pentium machine running an out-of-date version of X have pulled me back. Although the upside of migrating a software arrangement intended for a 120Mhz machine to a 1.4Ghz machine is an bewildering amount of speed. …
I am trimming out my local ports folder, and I want a place to dump a few extraneous ones. I’ve mentioned most of these over the past few months, and some of them are very useful. Others are just for backup purposes, or were scalped-slash-updated from elsewhere.If you’re a Crux user, this might be somewhat interesting to you. If not … sorry.
Here’s conky-cli.
# Description: Conky command line, without X11 dependencies
# URL: http://conky.sourceforge.net/
# Maintainer:
# Depends on:
name=conky-cli
version=1.7.2
release=1
source=(http://downloads.sourceforge.net/conky/conky-$version.tar.gz)
build ()
{
cd conky-$version;
touch ./data/conky_no_x11.conf
./configure --prefix=/usr \
--sysconfdir=/etc \
--disable-lua \
--disable-double-buffer \
--disable-x11 \
--disable-xdamage \
--disable-own-window \
--disable-xft \
--disable-hddtemp \
--disable-portmon
make
make DESTDIR=$PKG install
install -D -m644 COPYING $PKG/usr/share/licenses/conky/LICENSE
}
# Description: Fe is a small and easy to use folding editor.
# URL: http://www.moria.de/~michael/fe/
# Maintainer:
# Packager:
# Depends on:
name=fe
version=1.8
release=1
source=(http://www.moria.de/~michael/$name/$name-$version.tar.gz)
build() {
cd $name-$version
./configure --prefix=$PKG/usr --disable-nls --disable-sendmail
make DESTDIR=$PKG install
rm -rf $PKG/usr/share/locale
}
# Description: HOZ is a file splitter. Its file format is the same as the one used by the 'Hacha' software
# URL: http://hoz.sourceforge.net/
# Maintainer:
# Depends on:
name=hoz
version=1.65
release=2
source=(http://downloads.sourceforge.net/$name/$name-165.tar.gz)
build ()
{
LANGUAGE='EN'
cd $name-165
mkdir -p $PKG/usr/bin
make LANG=-DHOZ_LANG_${LANGUAGE} BIN=$PKG/usr/bin/$name cli
}
# Description: ncurses bandwidth monitor
# URL: http://headhunter123.he.funpic.de/showtopic.php?forum=programme.for&index=1
# Maintainer: headhunter at c-plusplus dot de
# Packager:
# Depends on: ncurses
name=net-monitor
version=1.0
release=1
source=(http://headhunter123.funpic.de/net.tar.gz)
build() {
cd net
make PREFIX=/usr
mkdir -p $PKG/usr/bin/
cp monitor $PKG/usr/bin/
}
# Description: A small note taking program for the terminal.
# URL: http://sourceforge.net/projects/tnote/files/
# Maintainer:
# Packager:
# Depends on: python
name=tnote
version=0.1.1
release=1
source=(http://downloads.sourceforge.net/project/$name/$name/$name-$version/$name-$version.tar.gz)
build() {
cd $name-$version
python setup.py install --home=$PKG/usr
}
It’s almost Christmas again, and that always throws me into a strange mood. This time I’m thinking again about my main, production machine — a Celeron Thinkpad that will turn 9 years old next month. Maybe you can tell by the screenshots scattered here and there on this blog, but it runs without X or any of its sub-libraries. In fact, it’s been that way for at least nine months by my calculations, ever since I grew so frustrated with inconsistencies between xorg-server and the siliconmotion driver that I rebuilt the entire thing from scratch without them.
I’ve mentioned this several times in the past, but I think it’s worth repeating again that, with the exception of one small point, this computer has handled all the major day-to-day tasks of my personal and online life for the better part of a year. That includes:
And maybe even more important,
And to round things out,
And best of all it runs the most commonplace of these tasks, concurrently, on around 18Mb of memory. That’s only about 10 percent of the maximum that will fit in this machine.
And what’s the “one small point” that the system “failed” at? It’s here. But I take responsibility for that, and don’t blame the machine.
I’m not going to pretend I’m some sort of superperson because I can tolerate life without a graphical environment — quite to the contrary: I don’t mean to imply any kind of “I’m so cool and you’re not” tone at all. In fact, I’m quite confident that anyone with the least desire to shift toward this sort of setup could do it.
But that’s the limiting factor, right there — your desire. It’s not the machine or the software that determines whether or not this is feasible, in any shape or form. It’s completely up to you. Whether you pull one or two console applications out of the list and run them against the entire Gnome desktop, or carve your entire system down to fit inside 16Mb and trumpet your enlightenment … it’s up to you. You determine your own level of involvement.
The lessons to be learned are ones I’ve repeated several times over, so I won’t spend much more electronic space harping away at the same points: You can speed up your computer by reducing the system load. You can avoid bloat by learning to use clean, fast software with few dependencies. You can reduce your system requirements by reducing the system load. You can reduce your need for overpowered technology by using lighter, faster software. You can save money by preserving and maintaining out of date hardware, and continuing to use it. You can make a social and environmental impact by refusing to contribute to the corporate and materialistic philosophies of greed that otherwise run rampant in the greater part of culture today … by using the same hardware you’ve had, and learning to use it better.
There’s an odd little aphorism that’s quoted infrequently in my culture: “A bad workman blames his tools.” I would like to add to that one, by suggesting that a bad workman blames his tools, but a worse workman goes out and buys new tools, thinking it will make him a better workman. Now this time I am implying something. Happy holidays. 
I’m probably not the first person to think of this, but it is amusing all the same.
That’s screen, running in a vertical split inside Yakuake. In case you’ve not used it before, Yakuake is a drop-down terminal emulator that works in the same fashion as a few famous first-person shooter games. Ordinarily it’s not something that is particularly entertaining to me (mostly because of the KDE underpinnings, which might be avoidable), but for some reason I thought it might be nice to anchor a screen session in there.
Like I said, I’m not the first person to think of it (I never am the first person to think of things), but now that it’s in place, it’s rather fun. As you can see I run a Windows XP-Classic-esque desktop in Arch, and while it’s a complete mismatch for that look, it is very nice indeed to be able to poke one button and check rtorrent or htop. Press the same key again, and it rolls back up into the heavens, out of the way and out of sight.
Of course, Yakuake as it stands supports multiple terminal instances anyway, so screen is hardly necessary there. Terminal emulators are just too darned flexible these days. Adding screen or dvtm or both to a tabbed emulator is multiplying your work potential in a mind-boggling way. …
I’ll probably uninstall Yakuake as soon as I get finished writing this, but it’s a curious idea. Rather than kicking out a terminal window every time I need to check rtorrent and then detaching it when I’m done, this can just show it continuously. My console “screensavers” work just fine, mouse controls are supported in mc, the vertical and horizontal splits work … everything as it ought to be.
Just appearing, and disappearing, in roller-blind fashion. Cool.
Recent Comments