Two unusual signs

Either someone is baiting me, or the tide has turned and the command line is regaining some prominence. Of course it probably never lost much prominence to start with, just suffered a little bad-mouthing, which no one ever died from.

But any time I spot two threads in the same day in the Ubuntu Forums — the Ubuntu forums mind you, where you’re more likely to meet complaints about the CLI than a notes of support for it — that poll its popularity or ask about X-less systems, then something is afoot.

There’s not a lot to be gleaned from a terrifically unscientific poll of command-line use, or a random callout for anyone running without X. In fact, had they occurred anywhere else — the Arch Forums, for example, or even the Debian forums — and you could probably safely overlook them altogether.

Arch Linux users, after all, are notorious command-line freaks who boast of their keyboarding prowess with screenshots of bizarre window managers like xmonad and Musca. And the elite of the elite of Debian peer down through the clouds that surround their aeries and wonder why you’re still using a mouse. Is your keyboard broken, perhaps?

I kid. I know it’s unusual to find an Ubuntu user who veers clear of X, since stripping away most of the graphical element of Ubuntu is stripping away most of Ubuntu … meaning that what’s left resembles other distros more than it resembles Ubuntu. You could call that the common denominator between all Linux systems, and it would be a warm, happy moment.

But … all things being equal, it’s nice to see some recognition of the command line, with a large percentage of that aforementioned terrifically unscientific poll going toward “daily use.” And it’s nice to hear about a few other people, in the midst of so many Ubuntu devotees, voicing a preference for such a large chunk of it omitted.

What it all means in the grand scope of things … I have no idea.

Something old, something new: Console file managers

I should know better than to mention console programs any more, because as soon as I do, someone tosses out another one and I have to try it. Curiosity gets the better of me and I can’t help myself.

Such was the case with ranger, an unusual file manager mentioned for its similarities to vifm. Take a look and you’ll see why I used the word “unusual” to describe it.

 

The directory tree shifts to the left as you explore in ranger. Moving up or down the list and then stepping to a new directory shifts the panes left or right accordingly. Right now there don’t appear to be much in the way of lines or boxes as visual guides, but this is still a work in progress from what I can see, so maybe they’ll appear later.

Moving your selection bar over a directory shows you a preview of what’s in that folder, and jumping to the right shifts the entire display to the left. And as you can see, file types are displayed in different colors, with a breadcrumb path along the top and file information at the bottom, along with a disk space count.

It takes a little while to get used to ranger, because the principle at work here is quite innovative. This is the only file manager I know of that scrolls horizontally, in columns, as you browse a file tree.

Like vifm, ranger uses vi-style keystrokes and commands to handle most chores. F1 shows you all the important commands, as well as how to get out of ranger … but saying it follows vi’s style might be enough for you to figure that out.

I’m going to keep an eye on ranger, mostly because it’s innovative, but also because it might turn into something very unique in the field of console file managers. At a time when it seems like everything has been done, and most efforts are actually rehashes of tried-and-true techniques, something new is worth watching.

Shifting gears only slightly, here’s something that has a history going back all the way to 1995: fdclone.

I know of fdclone obliquely, admitting only that I found it on a hand-me-down computer a year or two ago, and wondered what it was. If I understand it correctly, fdclone is an effort to mimic an ancient file tool called “fd,” which was popular in Japan as far back as 1989. So when we talk about software with a long lifespan, fdclone is a contender.

The layout here is very Norton Commander-ish, which appeals to some of us and is a turnoff for others. If you don’t have support for Japanese character sets you might see some oddball fonts at work, as you can see in my screenshots. As far as I can tell there’s no color at work here, and the keystroke labels you see on the screen might take a little time to get used to.

This is certainly no worse than most other console file managers, even if it seems rather bland by comparison. As you can see the tree mode is intuitive and easy to manage, and there is documentation in English as well as instructions on how to configure and build it.

And when you consider it reached version 3.00e in February 2010, this is not something that is going to expire any time soon. Fifteen years is a tremendous lifespan for any project. (P.S.: Ubuntu users have it in their repos; Arch/Crux users must build this one by hand.)

There you have it: Two file managers for the console, separated by about 15 years in the histories of their inceptions. As always, if you know of any others that I should explore, I would be happy to try.

Eagerly awaiting 2010

I don’t have many bookmarks, but I do have a few threads that I keep an eye on, for ideas about new software. This gargantuan thread in the Ubuntu forums was interesting for a while, but it has devolved into a list of Gnome-based software suites, which don’t interest me.

On the other hand, Archers are incorrigible speed freaks, and so the “light and fast awards” threads are great sources of ideas. Best of all, there has been one every year for the past four years — 2006, 2007, 2008 and 2009 — which means you’ll probably need a whole weekend to pick through all the suggestions there.

Add to that a small bonus — a thread that somehow involves Ubuntu, on the Arch forums. It seems a little oddball at first, but the ideas that are tacked on there are quite good.

In the meantime, I am eagerly awaiting the 2010 “light and fast awards,” so I can add still more ideas to my already-huge list of software to try. If you see it, send me a link.

The KDE 4.3 migration has begun …

I wasn’t the first person to say it, but I’ll agree with Mazza558 — I see a lot more KDE desktops in the screenshot threads for both Ubuntu and Arch forums these days. True, the Arch forums have always had a strong KDE presence, what with the fantastic effort that is KDEmod and/or the Chakra Project. I have never heard of an Arch user who hasn’t at least acknowledged that KDEmod is a stroke of genius.

But skimming through the screenshot threads suggests another trend, although I’m not part of it so I won’t make any predictions. If KDE is picking up speed, I say it’s high time … if this is just an illusion, I still say it’s high time — for KDE fans to make a concerted effort to show how much more beautiful KDE is — by default — than that ugly gobstopper called Gnome.

And you can quote me on that.

Putting the Pentium back to work

It’s been a few months since I worked with my old Pentium laptop. The ambient humidity has fallen a little bit since the local rainy season ended, and as a result the hardware eccentricities on a 13-year-old laptop have evened out a little. In other words, I’m not afraid I’ll send spontaneous pulses of electricity through the thing, just by turning it on.

Initially I wanted to rebuild the graphical desktop I created about six months ago, for no other reason than morbid curiosity. I found the Musca window manager on the Arch Forums the other day, and I was thinking that might be even more appealing than Awesome … since Musca apparently weighs in at an emaciated 600Kb+, while running. It sounded perfect for a machine that has only 16Mb of memory to start with.

But it was not to be. I’ve tried two different installations, building each one by scratch on a surrogate machine, and neither one would reach the graphical desktop. X complains every time that there is inadequate memory to start anything graphical, which is odd, since I have proof of the opposite.

But hey, I had wondered the same thing, often for weeks at a time, way back in February. How in the world did I get it working so many times in the winter? Beats me. Maybe it’s the humidity again.

But anyway, I took the hint and decided what I could really use is a dedicated machine for passing files back and forth between the other two. And a host for the only two torrents I actually feel “responsible” for — the old Lowarch ISO and the short-lived Ubuntu GTK1.2 Remix. And a Crux ports server. And … and … and …

So I rebuilt the thing, this time using the freshest software cut-to-fit a Pentium Classic, and set it up with ssh, nfs, rtorrent, screen-vs, cron and so forth. I’m keeping it on a wired connection this time, mostly because I don’t see any real improvement between the quirky ASIX-based Corega card I found, or the ancient Linksys WPC11 card I sometimes use. The internal hardware freaks out when it sees transfers above 256Kbps or so anyway. That’s so low that nothing is lost or gained by using one card or the other.

And I like it in this role. It’s silent, it’s low-power, it doesn’t need a raft of side packages to do the job, and it makes me feel like an old, old machine is finally getting back to work, instead of sitting in the closet.

That’s my goal.

The wrong reasons to use Linux

Everybody has a list of reasons to use Linux; I have my own, more or less, spread out over the length and breadth of this blog. Still, aside from the misinformation spewed forth by Redmond, I believe there are “wrong” reasons to use Linux. Which is to say, I think there are things that attract people to trying Linux, but I would not use as a selling point. Up front though, I should say that whatever draws you to Linux is your business, and not my concern at all.

1. Compiz. You might read that and feel like you just got hit in the face with a glass of cold water. After all, Compiz is way cool. It’s smooth, clever, innovative, years ahead of the competition and best of all, free-as-in-beer. What’s to dislike?

   I don’t dispute any of that. I also think it’s cool and smooth, and even cooler and smoother because you can get a vastly superior desktop experience on hardware so outdated, Vista’s requirements are suddenly a joke. I mean, I even tried to run it on an ancient GeForce2 card with only 16Mb of memory once, and got somewhere near an end result.

   No, my concern is simple — Compiz is flair. It’s shiny-glossy-pretty, but doesn’t necessarily make using a computer any more successful. And for as many people as I have seen scrap Linux because they couldn’t get Compiz working … well, again, I just think that’s the wrong reason to switch.

   I would much prefer people moved to Linux because they can pick up a window manager that allows them to rearrange and organize multiple desktops and wallpapers by theme, or even better, because they have a need for a desktop that’s lighter and faster than anything Microsoft or Apple sells now.

2. Speed. I’m going to split hairs here, and make a few distinctions. It is, after all, a little ironic that I would call out Linux on speed while writing a post on a blog dedicated to eking out the last smidgin of speed from outdated hardware.

   And it’s true, yes, that Linux machines can run faster and speedier and more efficiently than most other operating systems. Unfortunately that requires a degree of experience to achieve, and the average first-run-in with Linux is more likely to be with heavier, bulkier distributions.

   And judging by the occasional thread on the Ubuntu Forums or the Arch Forums, the speed of the included software is sometimes suspect. Firefox in Linux is regularly lambasted for being a sludge, when an identical system with Windows XP is generally snappier. Who’s at fault? Beats me.

   But that’s where I’m coming from when I say speed isn’t a good enough reason to use Linux. Distros like Ubuntu or Fedora and so forth are great introductions, but come with weight problems that don’t reinforce speed as a selling point. Over time and with the right software selections, it’s always possible to carve a system down to a true speed demon. But that usually requires a measure of experience and curiosity, and I think most Linux newcomers might lack one or the other.

3. Gaming. A year or so ago, I coached a World of Warcraft player through an Ubuntu-plus-Wine installation, which was a particularly hairy experience. In the end it worked, but not to the satisfaction of the player. Frame rates were lower than a native Windows system, the game felt laggy, and effects didn’t show like they “should have.” As you might imagine, within a week or so, Ubuntu was gone and Windows was back on, and to the best of my knowledge, it will probably never be back.

   I think it’s important not to hold out Linux as a solution to Windows gamers who want to get away from Microsoft. But notice that I said solution there. As an option I think it’s fine. But holding out Ubuntu or another distribution as a platform for Wine as a solution to running Windows Game X … is a mistake in my opinion. Invariably the experience falls short of what people want, and if they are gamers already, they’re unlikely to be willing to suffer any performance hit whatsoever, just to assuage their conscience on some other tertiary issue, like licensing.

   On the other hand, I heartily endorse Linux as a gaming platform for Linux games — that should go without saying. If you can get someone hooked on Neverwinter Nights or Tremulous or Warzone 2100, that’s a fantastic reason to keep a Linux machine in the house. But trying to shoehorn Linux into a machine and expect a hardcore Windows gamer to be happy … well, I’ll just say I’ve never seen it happen.

4. Duress. This is probably the worst possible reason I can think of — using Linux because you’re forced to. Even common-sense psychology dictates that forcing someone to use a tool they don’t know or didn’t elect to use is doomed to breed dissatisfaction. Spoon-feeding Linux to an unwilling user is, in my experience, a guaranteed turnoff.

   That might sound a bit hypocritical since one of the things I do in my spare time is polish an IceWM knockoff of Windows 2000, but the two ideas are not necessarily mutually exclusive. If ease-in-transition is an issue, it makes sense to create a desktop as similar as possible to what someone already knows. Transition is already a foregone conclusion.

   On the other hand, forcing someone to use Linux — or any operating system, really — is stripping out one of the core principles that Linux stands for: freedom. And in this case, freedom to choose includes the freedom to choose Windows or Mac OS or whatever. I would never allow someone to suffer through using Linux if what they really want is something else. It’s just not good business.

   (This is where I tip my hat and acknowlege that in a workplace, the rules are changed. If your job requires you use Linux or another operating system, it’s a different story. But it’s also no longer an issue of free choice, so I suppose I can dodge the bullet that way. )

And that’s where I’ll stop. It’s a delicate situation, trying to convince someone to use a different operating system. Linux and its brethren have a huge list of advantages, but pushing the wrong one on the wrong person is going to backfire catastrophically. Evangelize, by all means, but don’t make the wrong sale. You only get one chance to make a first impression.

uzbl is quite usable

I’m always excited when I discover a new browser. Firefox is like the obligatory pacifier for any open-source software discussion. Yes, I suppose it deserves a place in the list of free software successes, but I still feel slightly guilty whenever I use it, because of that little voice in the back of my head that whines, “Firefox, again?!“

Firefox is not the only, or the best option for most people. There are dozens — maybe even hundreds — of workable browsers out there, but Firefox is like the teacher’s pet — that annoying kid at school who wasn’t necessarily the brightest or most talented, but got all the attention anyway.

In any case, finding something completely new and original in the field of Web browsers is an added fillip to the joy of discovering a new application. I apologize if this is somewhat inconsiderate, but any one browser is generally arranged and works like every other. They all look the same to me.

So uzbl — I’m assuming it’s pronounced “usable” — blindsided me. Your father’s browser, this is not. This is, for all practical purposes, an Arch-only weapon, although I’m sure it can be installed in other distros. But the easy way to get at it, if you want it, is to install Arch and conjure it up through the magic of AUR.

And the end result? How about a box, with a page in it. So what, you say? So look closely: It’s a box with a page in it.

 

And that’s all. No buttons, no address bars, no back and forth controls, no home button, no reload button, no hotbutton bars, no rss dropdown menus, no up, up, down, down, left, right, left, right, b, a or anything like that. It’s a box with a page in it.

So where’s the joy in that, you ask? Well, look back at the original manifesto for uzbl, which reads a bit like the American Declaration of Independence. In short: Everyone else is doing it wrong, and we will do it right.

Right it is, too. vim-style keybindings, simple one-key url-entry commands, infinitely customizable through the configuration file (there’s a sample in the package that you really want to start with; no configuration file makes uzbl sort of … unusable ), and best of all … fast.

Wicked fast. Frighteningly fast. A speed Firefox can’t even dream of. I swear I have LCD image persistence from the speed of uzbl drawing up a page. Okay, maybe not.

Of course, a lot of that speed comes from Webkit, but part of it also comes from the fact that uzbl weighs about a buck-oh-five. Without all those knobby buttons and cutesy icons, there’s room to move fast.

All the same, this won’t appeal to everyone. It takes a little while to get used to, and of course, there are those oh-so-critical extensions Firefox addicts cling to, like security blankets. (One day someone will invent an extension that strips out all the other extensions, and everyone will realize how encrusted with extensions they had become.)

But if you enjoy a minimal environment, perhaps something tiled or even just exceedingly svelte, uzbl deserves a hero’s welcome. It’s light, it’s fast, it’s flexible to the nth degree, it’s unobtrusive, unforgiving and obviously designed by and for people who enjoy making their computers do exactly what they tell them to.

If you count yourself in the same group, check it out.

Running rtorrent as a daemon

A long time ago, I suggested rtorrent was something like an “rtorrent daemon.” That’s still true, of course — I don’t know of any torrent client that runs lighter and has the same range of controls as rtorrent.

I never really tried to set it up as a true daemon though, until I saw this thread on the Arch Linux forums, and its corresponding wiki page. It might not sound like it’s worth the effort, but it’s kind of nice to run the entire system in the background, unattended and preconfigured, and just drop torrents and run.

Mimicking the same concept in Crux was fairly easy; I needed to add a user called rtorrent, set up the proper subdirectories and then configure rtorrent’s rc file as I liked. The script shown in the thread and on the wiki needed scraped down a little bit, to where it’s really just a simple series of start and stop commands. (Oh, and the daemon needs either screen or dtach, depending on which you prefer.)

I don’t know if I’d go through the work of setting this up every time I wanted to install rtorrent, but I can see where this would be useful on a remote machine, or on a machine that sits by itself and does nothing but download. Oh wait, that was my original point, wasn’t it?

How can it all fit?

Sixteen megabytes is a pitful amount of memory, and I sometimes have to remind myself of that. I have grown too accustomed to thinking of that in terms of a “workable” amount of space, and it’s not. Even by my standards, it’s far less than what is practical, usable or functional.

And yet these Awesome-based console-application systems are regularly using up less than half of the 12Mb htop says I have left to use, and there’s no sign of it demanding more space any time soon. What’s the story? How does it all fit in under 16Mb?

I don’t know. It’s got to be one of those Russian dolls things. Just in the way of explanation, here’s a “baseline” system, freshly booted and with nothing but two instances of urxvt running (and yes, that is how sparse a Crux system runs. If you want to avoid all those sputtering little do-nothings in your htop report, start using Crux. It returns your hardware to you).

A lowly 5Mb of memory consumed, plus a few more in swap. I should mention that my swappiness is set to 60, but I don’t know if that will really make much difference when there’s only 16Mb to work with in the first place.

Now let’s add a little to the workload. Here’s calcurse, which I mentioned a day ago as a fantastic replacement for the GTK-based Osmo, if you’re inclined to go console.

It hardly makes a dent. Memory consumption went from 5Mb to 6Mb, which means the space consumed by calcurse is probably less than a full megabyte. Even the swap space usage is the same. But that’s probably only to be expected, since calcurse is not exactly a intense or vivacious application. Unless you’re adding to it, there’s not a lot to expect of it. It could probably easily float along on a Commodore 64, with a few modifications.

Let’s up the ante. Here’s alpine, in the middle of a valid and live e-mail polling session. In other words, not fake e-mails to myself.

That’s more like it. Six megabytes consumed, and this time swap space has to give up two more megabytes to keep the system from imploding! Ha! Now we’re really eating up resources!

Maybe. That’s still only a grand total of 3Mb over what the freshly booted system needed, and unless alpine is actively sending or receiving e-mails, there’s not a lot it really does. Something that requires constant effort might show a real drain on memory. Here’s irssi.

Not as bad as I thought, even with irssi’s constant relay between me and Freenode. Only 6Mb live memory used, and up to 9Mb of swap needed, and that’s with both #archlinux and #crux open at the same time. I suppose if I really wanted smoke to come out of the floppy drive, I should have jumped into #ubuntu too. That place is a mess.

After that though, I don’t know how much more I can tax this machine. Here’s snownews, which, like alpine, isn’t really very demanding so long as it’s not checking its feeds.

Not even twitching. And that swap space use, now, might even be cached programs that I already started. I don’t know, but I have a feeling looking at swap now isn’t much of an indicator of system demand.

Here’s Charm; Python might bog this down a bit. It’s a little slow to start (relatively speaking, of course), and that I blame on its Python underbelly. Prepare to be disappointed. …

At last, finally, I break the 7Mb mark. I still haven’t crested at two-thirds of the available memory, but at least now I can say I use more than half of the 12Mb I have on hand. And unused memory is wasted memory … or so the gurus say. Good thing I’m not a guru.

All right. I’m going for broke. I’m going to make this thing sweat if it’s the last thing I do. I shall force it to show a picture of itself, and in some sort of twisted backronymatic befuddlement, I will finally break 10Mb of usage. Here’s feh, displaying one of these screenshots on the host.

Survey says … no. No worse than anything else, really. It’s slow and I can blame that on the time it takes to scale down a photo to half its size, but it’s not exactly eating up my memory or causing rampant disk-swapping. I’m almost disappointed at this point.

Here’s mc, performing damage control, in a manner of speaking.

Still no singular chomp on my memory — that too seems to only take up a single megabyte. About the only thing I have left that might be a system demand is a browser, and I’m starting to worry that it won’t be very impressive. Here’s elinks, after signing into the Ubuntu Forums.

No luck there either. elinks tends to “hover” for a while, instead of opening pages very fast, but I wonder how much of that is elinks stripping out the visual garbage and stuffing it into /dev/null, and how much is just slow processor speed. The ‘forums are notoriously slow for me (it’s the design scheme), so elinks pausing for a second or two or three is only what I expect. (The Arch forums, by comparison, load exceptionally fast for me on a “normal” machine … well, on this machine too, I guess.)

But there’s not much of a drag on the system that I can blame on elinks. It might be slow, that might be the page, and it might be the processor. But it doesn’t seem to be anything I can say is because of low memory.

One last ace up my sleeve: cmatrix. This little monster has got to cause some sort of dent.

Bah. I give up. It’s taking up processor time, but not memory. The experiment is a failure, gentlemen. No one program is taking up much more than 1Mb at a time, and in that case there’s not much point in trying to find one program that will eat memory to a considerable degree.

I’ll go the opposite direction and open three or four at a time, and see what I get. Here’s snownews spawning elinks, with alpine, irssi and htop all running in their own rxvt-unicode instances. That will multiply the demands of rxvt-unicode several times over, and stack on a grand total of five applications. This should be good.

Well, I suppose that’s an “improvement,” in one way. Seventeen megabytes of swap consumed is definitely a high mark, but standing memory is still only requiring 7Mb. Since this is running freely and without paging, I can only assume that the bulk of what’s needed to do this can be done without disk access.

I suppose there’s something to be learned in this: That even if I dive into the guts of this machine, find the other memory bracket, install the 32Mb chip and successfully reassemble the thing, it might not lead to much of anything at all. As it stands now a running, active system doesn’t seem to need more than the 12Mb I have available, with a bit of swap space as insurance.

And going straight to console might speed things up a little bit because it takes less effort to display these applications in the native video environment, instead of under X. But the run speed isn’t going to improve drastically if I’m not ever paging out to the drive as a consequence of normal use.

The moral of the story: I have a lot to learn. But I knew that three years ago, when I put an Ubuntu CD in the drive and restarted my laptop. You just never stop being a newb.

Build up, don’t tear down

I found a nifty link to some more speedup tips for Arch. In fact, there’s a whole thread here that talks about ways to make Arch boot in a half or a third of the time it takes normally. If you use Arch and you’re not one of those people who runs a machine 24-7, you might find them interesting.

My own speedup tips for Arch are scattered around this blog, with most of them under the Howtos page, but all of them a couple of years old already. I still use Arch, but I don’t bother tweaking it for speed any more. My philosophy toward it has changed a bit.

I left Arch for Crux when I realized I was falling into the same habit I had begun a year before, when I started carving down Ubuntu in hopes of speeding it up. The problem is that both times, my perspective was a little off-kilter.

For my own part, building a system up from scratch is always faster than tearing out parts of another one. I don’t think I’m stepping too far out on the limb when I say that; it’s common knowledge that a Linux system crafted from the ground-up is going to outperform anything that was torn down.

It’s true for Ubuntu — a command-line system with desired packages added on top is going to run faster, probably, than one that was cut down from the complete version. The same thing is true for Arch: When I started recompiling entire systems with different CFLAGS, or building custom kernels, or carving out the default init scripts, I realized that it was time to look for a different brand.

Making Ubuntu into Arch isn’t any more promising, to me, than making Arch into Crux. The work you go through trimming away at Arch is sidestepped completely with Crux, and for some people that’s ideal. It’s true, it’s the difference between an intermediate distro and an advanced one, but if you’re doing all those things in Arch, then you’re ready.

If that sounds like you, I would recommend considering something that gives you more ground-level control, in such a way that you’re not taking extra time slimming things down when you could be building up from a pure core. And if performance is your goal, then the results will be very gratifying. After all, a 16-second boot in Arch is a grand thing on a dual core, but I get those numbers from a 550Mhz Celeron, just as a matter of course.

Think about it. If you want to ask questions, there are a few of us Crux experimenters floating around here, in addition to the standard Crux IRC and mailing lists. And what we don’t know we can research together. It’s part of the learning process.