Archive for the 'Linux' Category



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

player-pause
player-next
status
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.

Sam and me

Yes, I’ve seen the article by Sam Varghese about the Ubuntu 11.04 beta. Thanks to the two or three folks who sent the link.

It’s not a particularly ringing endorsement. But neither is it particularly precise in its criticisms. It seems Sam has two or three gripes about the beta, and lumped them all together in one muddy package.

I’ll probably do the same, albeit with different gripes.

Right now it’s time for me to admit I’m not an Ubuntu user. I gave it many years of my early Linux life, but my goals and its path diverged, and I seek a different direction now. So be it.

But I’m not wholly in Sam’s camp either. I did use 10.10 for three or four days this week, in order to try out Azulejo. Ten-ten didn’t irritate me to any degree, although it does seem a little too automated at times. ;)

I’ve tried the 11.04 beta in its live version, but haven’t installed it. I really didn’t care for it — with the “strongly dislike” inflection — and probably won’t be visiting Ubuntu for a while to come.

I can agree with Sam that it feels like a cellphone interface but more than that, it’s just unintuitive for me. I don’t want my computer to behave like a cellphone, I want it to behave like a computer.

And as I’ve mentioned before, Ubuntu is pushing to carve out a niche as the Facebookendsterwitterspace operating system, which I find disappointing.

All of those things are swirling about and making Ubuntu’s direction less and less appealing. So perhaps Sam and I have that in common.

Ultimately I have to come to the same conclusion as he does — that someone out there will find this to be the greatest thing since sliced cheese, and cleave to it instantly.

I applaud that, even if I don’t join the group hug. Ubuntu’s gone far off the course it introduced to me, five years ago, but that’s no surprise. It will appeal to some, and their way is the right way. Selah.

Notes from all over

I have a few notes that were forwarded to me from … well, from around the world, I guess. Since they all bear repeating on a wider front, I’ll go ahead and paraphrase them here.

  • Raymond sent a note mentioning the XFCE release of Linux Mint, which I can confirm is based on Debian testing now.

    I’m still in the process of downloading it but I’m excited to see how it looks — and compares — to other full-figured XFCE-based distros.

    My own disappointment with Xubuntu aside, things done right in XFCE can be quite effective … as I have learned first-hand.

  • Ben Winston jotted a note just today to underscore his satisfaction surfraw, when used in conjunction with the Duck Duck Go search engine, and to be honest I have to second that emotion.

    It’s exceptionally fast when juxtaposed with elinks, which can render a text-only page at 150Mhz at a rate that rivals my core duo with Firefox.

    Add to that the convenience of using surfraw, and it’s literally information at your fingertips. Looks like I’ll be changing my home page. …

  • One more, and this one comes with a plea for help. Allex has gotten hold of another Datamini laptop; you might remember Remy’s astounding refurb job from a year or so ago, and Allex’s sounds similar.

    As it is though, Allex needs a little help pinning down information about The New Toy:

    There is a green box with “Datamini” and 2 small black words “AT Laptop”. There is also a white sticker at the back which states the model no “LA-20″ and serial no “C10604″.

    It is pretty heavy, bout 6kg and has dimensions of bout 36cm x 30cm x 6cm. It comes with two drives for floppy disks on the right hand side. 4 ports at the back, “Power”, “Serial”, “Parallel”, “Display” along with a carrier handle and 1 more port on the left side, marked “KBD”.

    If you have any experience with those models or if you have a suggestion on how to glean information from those machines, Allex could use the help.

And there you have it. If anyone can offer a little help to Allex, I’m sure it would be appreciated. In the mean time, I’m going to take XFCE Mint Debian for a spin. … :mrgreen:

Too many variables

I’ve more or less completed my transition from a framebuffer-based Debian 6 installation on the 120Mhz Pentium to a framebuffer-based ConnochaetOS system on the 150Mhz Mebius.

It took a considerable amount of time, mostly because a lot of the software I was using in Debian isn’t really available in ConnochaetOS, at this point in time.

Which means I have to build it on a surrogate system, and then transplant it into the Mebius. Much like this, to start with at least.

It probably sounds worse than it is: yaourt in Arch can grab PKGBUILDs, which I can build in a chrooted system on the core duo. After that, I just sync a package directory over my home network.

I suppose if I really wanted to measure the improvement in speed between Debian and something Arch-aligned, I would have done this in two or three steps.

I should have built one system again and compared it speed-wise, then changed machines and built the same system twice, and so forth.

Because the net result of moving to a slightly faster machine and more memory and a different distro and a framebuffer driver specific to the video card … has been a giant burst of speed.

“Giant” being relative of course, since we’re talking about 15-year-old computers here.

But yes, boot times are considerably faster. The framebuffer refresh rate is vastly improved. Applications snap between “windows” in screen. I get no artifacts.

And so on. It doesn’t really match my Crux systems for overall snappiness, but in terms of ease of setup and minimal maintenance, this is very pleasing.

But too many things changed at once, and I don’t dare suggest one distro or another has improved things for me.

In the mean time I’m fishing around for a new home for the 120Mhz machine, and the 133Mhz machine. I’m overstocked on outdated computers and I am anticipating newcomers. Time to make space.

Azulejo: Quick window tiles

It’s an odd coincidence, but I got an e-mail a day ago asking about making the leap from Gnome to a tiling window manager.

Late last week there was a thread on the Ubuntu Forums mentioning Azulejo, a little utility that allows you to tile windows in Gnome or other desktop environments.

It works much better than the old tile package, which isn’t really around any more, it seems.

Basically there are four or five main window arrangements, and you can bounce between them at the press of a key … or two, if you’re willing to count the Super_* key.

You also have the option to stretch and expand windows, and rotate them through the arrangement. In a small way it sort of reminds me of dvtm, or maybe Awesome.

It’s not a true-blue tiling window manager by any stretch of the imagination, but it does give you a taste. And it comes at a very light cost, in terms of dependencies.

Of course, if you’re running this up against Gnome, the dependencies probably won’t bother you. :roll:

jnettop: Another network monitor?! Why not?

I only have a few minutes today, and so I’ll just tack down one more network monitor I scrounged up the other day. This is jnettop.

It would be unfair of me to make light of jnettop for being one in a long list of network monitors for the console.

After all, I don’t know who was first and who followed who, and it may be that jnettop can trace its history back into the early days of network monitoring.

Be that as it may, there are a lot of options out there for network monitors, and jnettop is just one of them.

When I finally break down and acknowledge the overwhelming obviousness (and need, although I dread saying that) of a CLI-app-a-day blog, one whole month will be devoted just to network monitors.

All the same, I won’t make a recommendation for, or slur against jnettop, since it does much the same job as its brethren, but displays the information in a slightly different arrangement.

Like many things in life, you’ll have to examine this one and weigh it on its merits, and then decide if you’ll use it over the others. Beware, the list is long. … :shock:

A bash loop, for pacman

So long as I am mentioning rather esoteric bash solutions to even more esoteric file management problems, here’s one just for Arch Linux.

I’ve been transforming my Debian-based system into a ConnochaetOS-based one, and wanted to strip out a lot — a lot — of packages in one fell swoop.

pacman didn’t like my primitive attempts with wildcards though, and so as a means to yank anything that contained a particular string — like xf86, for example — I did this:

for i in `pacman -Q | grep xf86 | cut -d' ' -f-1` ; do pacman -Rcsn ${i} ; done

grep strains through pacman’s list of installed packages, and gives the list that includes anything in xf86.

Of course, pacman’s output includes version numbers, so those are trimmed off with cut, setting the delimiter to a single space.

Not great, not fancy, but for the most part, a solution.

Create large files of random information

I wanted to test that mischevious hard drive, to avoid problems when I move stuff on to it.

The plan was to fill it with dummy files and if there was an issue at the 40Gb point, I would know up front. Which would have been better than finding out a week later.

To that end, the weak-sauce tip for the day becomes this one: Creating a series of 2Gb files made of random gibberish, just to take up space.

for i in {1..20} ; do time dd if=/dev/urandom of=test-{$i}.file bs=268435456 count=8 ; done

The results, after a considerable amount of time (/dev/zero is faster), will be twenty files all 2Gb in size, filled with gunk. Good gunk, that is.

A little tip there: The block size multiplied by the count gives you the size of the file. So what?

So simply setting the block size to one gigabyte (or gibibyte, since I seem to be drawing flak on the issue these days :) ) might cause memory errors on a machine with only 512Mb or less. It did for me.

The size of the file in my case wasn’t really important I guess, but I did get that quick primer for performing this stunt on low-memory machines. Reduce the block size, magnify the count, get the same results.

Oh, and the hard drive? It’s fine. I filled it all the way to the brim, and Arch didn’t complain. Good to know.

APM, and the value in Linux

I have to offer a public thank-you to Alex, who pointed out the APM discussion on the kernel mailing list. I’ve been through the majority of the replies and find it very interesting.

It’s certainly not a life-changing debate, but there are a couple of points that stand out for me.

To start, as mentioned early on in the string, there isn’t much activity around APM support, which suggests two possibilities: Either the code has reached pristine condition, or no one is using it.

If the latter is true, then there does seem to be a rationale for dumping it.

But there does seem to be support for a lot of hardware that is far older than the APM bracket, and it’s still in the kernel. Which makes cutting it seem a bit arbitrary.

Losing it wouldn’t make a machine unusable, it would just make it difficult to use with newer kernels. And when that happens, then we have reached the definition of obsolescence.

I have to admit up front that I rarely, if ever, rely on software-driven power management of any kind, when I build my own kernels. So whether it’s there or not is immaterial … to me.

But that doesn’t mean it wouldn’t be useful to someone else, using something similar or even older. And I think Ingo summed it up well by saying, “Our general compatibility with old hardware is an asset that we should value.”

I think that’s the real value in Linux. People watch their perfectly functional, favorite computers slowly become “unusable,” as big-name operating systems gleefully abandon them.

Where’s the first place they go? Linux, because it has the reputation of supporting outdated machines … often better than the original manufacturer intended.

Keep it, I say. Dropping it only means alienating a smaller bracket of potential users, or committing a small pocket of hardware to final unusability.

And who knows? Maybe APM really has reached code Nirvana. It’s not impossible. :mrgreen:

A little more information

I did a bit of a disservice the other day, when I dropped that bland note about the drive size issue between different versions of Linux.

Invariably if I make a note like that and don’t give a little more information, months from now I’ll be scrounging around trying to remember why that happened and what I did to get around it.

So as a service to myself, and to anyone else who might run into the same problem, here’s a little more information.

First, yes, the Debian 5 installation routine (specifically off the business card installer) can properly report and partition the drive to its correct dimensions.

And yes, both Debian 6 and Arch Linux can’t, at least not in their current renditions. I don’t think this is a bug, I think it’s a combination of lesser issues, and the fact that the drive was probably supposed to be 40Gb. :)

However, both ‘Six and Arch can manage the drive after it has been partitioned, and access areas beyond that imaginary 40Gb limit.

Their internal partitioning routines still try to cut it off at 40Gb, but so long as those stay out of the way, there doesn’t seem to be a problem.

Which means the obvious shortcut is to prepartition the drive using the Debian 5 installer, break away and go back to one of the other miscreants. ;)

The only problem I’ve had with this, after two or three attempts apiece, is a single Grub 18 error in Arch. If you don’t know, that’s when the Grub configuration files are located beyond what the BIOS can access normally.

And that’s an error I’m used to, after working with very old machines for years. It’s easy enough to get around, with a small 64-96Mb partition at the front of the drive, just for /boot.

So that’s as much information as I have now, and unless I stumble over something that’s related or relevant, as much as I’m likely to ever have.

If there’s a fix or a bug report out there that seems to match it, let me know. But I probably won’t be filing a bug anywhere entitled, “Drive size misreported on a magical hard drive that was mispackaged as three times the advertised size but only in some distros and not in others.” :mrgreen:


Welcome!



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

License

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

Blog Stats

  • 3,963,101 hits

Archives


Follow

Get every new post delivered to your Inbox.

Join 405 other followers