Archive for the 'Linux' Category

Quick interlude: AssaultCube

Just a brief note right now: I’ve had a quick run at AssaultCube, and found it worthy.

I like that the original Cube/Sauerbraten game has gotten a makeover and gotten a little more … focused. It retains its speed and playability, and adopts a much more … focused … theme.

Give it a try. :)

Kubuntu, for better or worse

My two days with the Kubuntu 11.04 beta have been a mixed bag, with some trivialities that needed addressed, but mostly positive experiences.

I can honestly say that after about 48 hours of learning what equates to what in k-series software, there’s quite a bit I like, and some things I don’t.

For one thing, I feel a preference for KPackageKit over the obtuse Add/Remove software tool in Gnome Ubuntu, although I don’t really know if they equate or not.

KPackageKit seemed to be better prepared to find and install things, while the Gnome add-remove tool used to be vaguely useful, but took a giant step backward a year or two ago. Nowadays I just go straight to Synaptic.

Rekonq, if that’s the right name, almost supplanted Firefox for me, except that I had problems with its ad blocking system, and I unfortunately prefer an ad-less Internet.

I did, for a short while, use them side-by-side though, and didn’t find either one to be tangibly superior.

On the other hand, I had major problems with the screensaver in Kubuntu. Enabling any screensaver would behave as normal until I moved the mouse or otherwise tried to waken the desktop.

At that point the machine would fall back to a tty screen, flicker twice, then return to the login screen — killing everything that was running in the background, as well as the network connection.

After the first or second stunt, I just disabled the screensaver altogether.

Every desktop comes with its eccentricities though, and my homemade ones are no exception. And years of experience have taught me that 90 percent of these weirdnesses come at my own hand.

I still think, as I have long thought, that anything KDE comes up with is heads and shoulders above Gnome in terms of attractiveness and flexibility.

And so long as the Gnome philosophy says I can’t be trusted, then I’ll probably continue to avoid it. That, and its unnecessary weight, are the least attractive points about it.

So Kubuntu wins points this time around. Next, I’m going to revisit an old acquaintance.

I am cringing, even as I type.

The other *buntus

Guilty as charged, I generalize too much. I sling mud at Ubuntu without taking care not to splatter the other Ubuntus in the process. So I’m going to amend that over the next few days.

Some will call me a glutton for punishment for starting off with Kubuntu. Others will slap themselves soundly on the forehead and mutter, “Out of the frying pan, into the fire.”

And both will be right; straight Ubuntu might swallow a mighty chunk of memory just to get off the ground, but Kubuntu 11.04 gobbles it greedily.

But I won’t harass Kubuntu as much as Ubuntu for being a memory hog … even though my system is consuming as much as 290Mb on cold boot. :shock:

(That’s on the core duo, of course. I dare not run it on anything else. :roll: )

No, I’m not prejudiced, I just always seem to remember KDE eating up more. So I expected it. It’s not delightful, but it wasn’t a surprise either.

But I’m going to go back and really rub vanilla Ubuntu users’ noses in it, and repeat what I said years ago:

It’s already got all the effects, the gloss, the shimmer, the bling and the splash. It came prepackaged with everything you see above … and more.

So if you’re working hard to prettify Gnome — either as a developer or as an end user — why are you fighting it? What you really want is KDE.

Next stop is the purported lightweight of the family. :twisted:

Information, please

Some of the best console programs don’t do much except offer up information … in abundance. Technically that makes them tools and not so much applications, at least from my limited viewpoint.

sox bills itself as the “Swiss Army knife of sound processing programs,” and whether or not it lives up to that billing is for you to decide.

It does usually come with a nifty tool though — soxi, which will give you a rundown on the information available for an audio file.

It’s not terribly verbose, although it does show many of the key points, and will probably suffice for most purposes.

If you want more detail though, mediainfo might be a better solution.

Quite a bit more, I think you’ll agree. And if you look close you can see the twofold (threefold? fourfold?) beauty of mediainfo — that it’s not limited to audio files. It’s smart enough to sense an image file too, and give the information it can about that.

Torrent files are terribly contorted, and if you want to find out what it’s doing or where it’s going, it’s a bit inconvenient. Or maybe I’m just too used to *nix-ish plain configuration files.

torrentinfo can help with that though, deftly carving through the knot and surrendering the important stuff.

And a bonus — color! ;)

The last one here is not so much a tool as a perl script, although it does an admirable job. This is boxinfo.

Don’t be disappointed. boxinfo sends its best work to an html file which, when opened, looks something like this.

Nicely formatted, easy to read, with everything from hardware details to environment variables, arranged in clean tables.

So what’s the use in all these tools? After all, cuing each one from the command line any time you run into a mystery file … well, that’s not very convenient.

Ah, grasshopper. You must learn to think a little more creatively than that. Imagine what wonders you can achieve if you tie these simple information tools into your favorite file manager. Click on a file, see all the information available about it. … :shock:

P.S.: A big thank-you to persea, who did 90 percent of the legwork for this, and suggested a three-way partnership between ranger, atool and mediainfo. But persea can explain that to us. … :mrgreen:

Why Tron Legacy fails for me

I had the opportunity to see the recent Tron movie last night. Already you’re probably wondering what this has to do with Linux on old computers, but bear with me. I can make this work.

I never held out any hope that the new movie would eclipse the old for me. I put the DVD in the tray knowing full well that my fondness for the original, which I saw in theaters probably three times when I was a kid, had doomed the new version from the start.

And that was more or less the case. I don’t point the finger at any one person for its failure to enthrall me. The actors were fine. The effects were up to par. The music was great (and I dare not say any less than “great” for fear all of the Internet’s love for Daft Punk will come down on me like a ton of bricks :roll: ).

But it didn’t have nearly the charm or charisma (or camp) of the original. I can encapsulate my explanation by saying simply, that you had to be a kid in the early 80s to really appreciate the original.

The new one had every advantage the old one didn’t — technology has finally caught up with what the imagination demands. But ironically, after all these years, we’ve seen just about every trick Hollywood has to offer.

Even bullet time CGI is a decade old now. Glossy light cycles and actors collapsing into marbles? It was only a matter of time.

Which means the only thing left to save it was the story. And that failed, tragically. Nothing in the story was the least bit innovative for me.

They would have been better off just remaking the original, and putting to into place the effects we all just dreamed about, nigh-on 30 years ago.

Long on technology, short on creativity. That’s all it takes to be a big-budget Hollywood movie any more. It’s not about a good story, it’s about dazzling people with computerized glitter.

But I hardly blame Hollywood. Public conception of technology isn’t about function, it’s about flash. It’s not about quality, and what does the job, it’s about what impresses coworkers, costs the most, or sparkles when you hold it up in the sun.

Function and quality take a back seat to glitz and gloss, whether it’s a cellphone, a microwave oven, a laptop computer or the operating system you run on it.

So no, I don’t blame Disney for tearing off one more chunk from the corpse of Tron, spritzing it for the younger generation and offering it up for public mastication.

They’re just doing what the crowd wants. Maybe one day there will be a Tron movie that can engross us on the basis of its creativity and imagination, like the first one did.

But I don’t expect it. Our toys get simpler and shinier, and our movies get simpler and shinier. Our lives … well, let’s only hope they’re improving in different ways.

I’d hate to think there was less quality, and more superficiality, in life today.

Now if you’ll excuse me, I’m going to watch the original, one more time. On my 10-year-old laptop. :twisted:

How little I know

I do not know everything. Of course, knowing that I don’t know everything only means that I know how little I know, and that I know that I don’t know something when I see it.

Setting aside grammatical parlor tricks, this is an issue because the giant list of software that I found a few months ago is populated with a lot — and I mean a lot — of stuff that I just … don’t know.

Perhaps an example would be a better way to explain it. Arch has arpwatch in AUR, which comes bundled with arpsnmp — both of which are on that list.

But for the life of me, I can’t figure out how to use it, or why I would want to. Hence, no screenshots. :(

I’m still pretty much a desktop user (even though my desktops are rather bizarre ;) ), which means one of two things to me: Either I will never need arpwatch/arpsnmp, or I already use them and I am oblivious, because they’re buried deep under layers of other software that shroud them from view.

Both are possible, and both are fine with me. But what that means is that arping, arpoison and arpspoof are likewise mysteries to me. Maybe I will never in my life need them, and maybe I use them every day and just don’t know it.

And so I’m back to where I started, admitting exactly how little I know.

And a vim mystery

As if that wasn’t bad enough, I am having a hard time figuring out why it is necessary to include Mercurial, gtk2, gpm, libxt, libsm and desktop-file-utils in the construction of vim.

This all comes about because, in the process of stripping the guts out of ConnochaetOS and converting it to a framebuffer speed demon, I realized that vim choked without gtk2.

And libxt, and almost all the rest of that stuff above. And the dependencies, of course.

Mystifying, but I am no expert. I tried to rewrite (with considerable effort) the vim PKGBUILD to omit all that stuff, use the 7.3 tarball, and lose a little weight.

It’s not going very well though. Big, complex applications like this always seem to spin out of control and turn ugly when I write my own PKGBUILDs. I do better with simpler stuff.

I’ve searched AUR for something like a “vim-nogui” or Debian’s vim.tiny, but there are quite a lot to skim through. I’ll keep trying and keep searching. Maybe something has already been done. :|

Arch madness

What is this — Ubuntu? Something is going on here. I must have made a mistake somewhere.

Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...

Targets (66): libdrm-2.4.25-1  libgl-7.10.2-2  ati-dri-7.10.2-2
              eventlog-0.2.12-2  filesystem-2011.04-1  fixesproto-5.0-1
              intel-dri-7.10.2-2  libtasn1-2.9-1  libtiff-3.9.5-1
              libxfixes-5.0-1  mach64-dri-7.10.2-2  mesa-7.10.2-2
              mga-dri-7.10.2-2  ncurses-5.9-1  r128-dri-7.10.2-2
              savage-dri-7.10.2-2  sis-dri-7.10.2-2  sudo-1.8.1-1
              tdfx-dri-7.10.2-2  xf86-input-acecad-1.4.99_git20110318-1
              xf86-input-aiptek-1.3.99_git20110318-1  xf86-input-evdev-2.6.0-3
              xf86-input-keyboard-1.6.0-2  xf86-input-mouse-1.7.0-2
              xf86-input-synaptics-1.4.0-2  xf86-input-vmmouse-12.7.0-2
              xf86-input-void-  xf86-video-apm-1.2.3-3
              xf86-video-ark-0.7.3-3  xf86-video-ast-0.91.10-3
              xf86-video-ati-6.14.1-1  xf86-video-chips-1.2.4-2 
	      xf86-video-cirrus-1.3.2-6  xf86-video-dummy-0.3.4-4
              xf86-video-fbdev-0.4.2-4  xf86-video-geode-2.11.12-3
              xf86-video-glint-1.2.5-2  xf86-video-i128-1.3.4-3
              xf86-video-i740-1.3.2-6  xf86-video-intel-2.14.903-1
              xf86-video-mach64-6.8.2-6  xf86-video-mga-1.4.13-3
              xf86-video-neomagic-1.2.5-4  xf86-video-nv-2.1.18-3
              xf86-video-r128-6.8.1-6  xf86-video-rendition-4.2.4-4
              xf86-video-s3-0.6.3-5  xf86-video-s3virge-1.10.4-5
              xf86-video-savage-2.3.2-2  xf86-video-siliconmotion-1.7.5-2
              xf86-video-sis-0.10.3-4  xf86-video-sisusb-0.9.4-4
              xf86-video-tdfx-1.4.3-6  xf86-video-trident-1.3.4-4
              xf86-video-tseng-1.2.4-4  xf86-video-v4l-0.2.0-8
              xf86-video-vmware-11.0.3-3  xf86-video-voodoo-1.2.4-4
              xf86-video-xgi-1.6.0-3  xf86-video-xgixp-1.8.0-3
              xkeyboard-config-2.2.1-1  xorg-server-common-
              xorg-server-  xvidcore-1.3.1-1  xz-5.0.2-1

Total Download Size:    15.68 MB
Total Installed Size:   80.15 MB

I am going to need to scope out the Arch Forums and figure out why I suddenly have software installed for almost all the video hardware ever created. On a laptop. With Intel graphics. :|

I can’t ever remember, in the five years or so that I’ve used Arch Linux, getting as much unnecessary crud as that in an update. I must be dreaming. …

A built-in diary

Since I’m mentioning small, built-in bonuses to some established programs, I have another I can point out.

A few months ago I wrote about Ben Winston‘s tiny journal tool, aptly called jn.

I discovered the other day that Vimwiki has a built-in function that’s not far off from that.

Entering \w\w from vim’s control mode drops you straightaway to a diary page prenamed for today’s date.

Diary entries are kept in a subfolder inside your wiki data folder, and have their own index page, which looks sort of like this.

= Diary =
| [[2011-04-11]] | [[2011-04-10]] | [[2011-04-09]] | [[2011-04-08]] |

The table grows from left to right, meaning your newest entry is always on the left. Rather convenient, really. ;)

Bonus points for cmus-remote

I am a lukewarm cmus fan. Just like I am a lukewarm vim fan. Both programs, if I must be honest, are adequate, but somewhat eccentric.

I overlook those eccentricities because they get the job done, and in some cases because they add a few noteworthy fillips.

For example, cmus is one of the few players I have found that is light enough to run at less than 150Mhz. That alone is why I use it on most of my machines.

But cmus in Arch also comes bundled with cmus-remote — which in lieu of running cmus in a session of screen and joining that session as a second user, allows me to control the player via the command line.

To wit: cmus-remote -u pauses the player, and restarts it after I answer the phone.

Or even better, just cmus-remote followed by

vol 20

Any of those commands, typed directly into stdin, is piped into the active cmus session, and controls the player remotely.

Tack that on to an ssh session and you don’t need a multiplexer to reach across the room and turn down the volume.

It’s true that a proper, full-featured screen session across ssh would give me direct control and a few more features, but in a pinch, this’ll do.


Visit the Wiki!

Some recent desktops

May 6, 2011
Musca 0.9.24 on Crux Linux
150Mhz Pentium 96Mb 8Gb CF

May 14, 2011
IceWM 1.2.37 and Arch Linux
L2300 core duo 3Gb 320Gb

Some recent games

Apr. 21, 2011
Oolite on Xubuntu 11.04
L2300 core duo 3Gb 320Gb

Enter your email address to subscribe to this blog and receive notifications of new posts.

Join 405 other followers


This work is licensed under the GNU Free Documentation License. Please see the About page for details.

Blog Stats

  • 3,958,212 hits



Get every new post delivered to your Inbox.

Join 405 other followers