Lowarch and archlinux-i586

Don’t look now, but if you have an i586 machine (particularly an old one), you might be able to make a little progress in returning your machine to the fray. proc on the Arch forums has taken the initiative to recast the Lowarch project, and described some success in creating current packages tuned to that architecture.

If we’re lucky (because I too am in the same boat), that could mean a proper revision of Arch for i586s, for the first time since around late 2006. And considering that some of these old machines are becoming hard to find, it might be an opportunity to put your antique back on the front line again.

Of course first, you’ll have to scrape that centimeter of dust off the case.

Back to BMP

This is just nuts. Audacious will compile for me, but won’t run — I get segmentation faults. Alsaplayer won’t build any more; I think the newer compilers will need some adjustments at the code level from the Alsaplayer team, and I doubt they’re around any more. XMMS is GTK1, which I don’t want right now. RealPlayer is proprietary, so I try not to use it. Consonance won’t stream audio, I don’t think. cplay and friends are console-based, which I also don’t want now.

So for the first time in years I’m using Beep Media Player again.

Which is not bad, of course. It looks just like it’s predecessor and its antecedent, and will play ogg files and mp3 files and stream over the Internet. So it does the job just as well.

Still, it seems like a step way, way backward, to the days of Dapper Drake when I used to use it over any other media player. Boy was that a long time ago.

P.S, note to self: Must try Goggles music manager, just because it’s FOX-based.

The beauty of AUR

In my not-so-important opinion, one of the shining stars of Linux is Arch Linux, and one of the crowning points of Arch Linux is the AUR, which is so delightfully simple and and the same time terrifyingly powerful, that I am at times amazed that it isn’t a fixture in every distro, across the board.

After you use it you can’t help but marvel at the obvious common-sense of it — a collection of scripts and instructions for building up-to-date software that the Arch developers don’t maintain, with the more popular packages “ascending” to a precompiled state, as part of a community repository.

But probably the coolest part is the easy interaction between the users who maintain AUR titles, and the people who make use of their efforts. As an example, today I noticed that the home page for Xpad, which I consider a must-have application, announced version 3.1 a few days ago.

It’s not exactly the most sought-after program, so I could understand when the AUR page for Xpad still showed 3.0 as the most recent version. Rather than manually editing the posted PKGBUILD for it (which I could always do), I logged in, clicked once to flag the package as out-of-date, and eight hours later Xpad was among the software updates for my system.

Cool, huh?

Of course, it’s not always so clean and easy, but that’s a good example of how the people who use Arch work together to keep each other apprised of updates and improvements — and problems, of course.

I occasionally go a little overboard in my appreciation for simple things like this — I mean, after all, it’s just a web interface for a database of text files, with a few convenient buttons here and there to make the task of nudging the maintainer a little easier. There are plenty of script-driven, source-centric distros out there. So if I’m overdoing it, let me know.

But I haven’t run into a distro yet that makes it this easy to build something from scratch (more-or-less reliably), and take on software from the community, and facilitate user management of that software, and offer the chance for titles to become part of the precompiled repositories. If someone has made this even simpler or easier, I haven’t heard about it. But I’d be happy to try it, and see if it stands up to Arch.

New solutions to old puzzles

I spent most of the day building Crux 2.4 (yes, 2.4) off the i586 ISO on my 100Mhz laptop — and that should be enough to figure out why I said “most of the day.” I was curious this time, as I have been in the past, about squeezing it all into 810Mb.

Which is technically impossible, but can be done with a couple of tricks. Like I mentioned, the first and most important thing was to shave the swap partition down to 128Mb, and leave the remainder as root-and-boot-and-home. With ext2 as the file system and no root user reserved space, it fits, but only slightly.

It’s not possible to compile the kernel — or for that matter, to even decompress it, and have enough space for a graphical system. So I have two ways around that: First, leave out the graphical system. It’s a little extreme, but on a machine this slow, it’s almost preferable. If I get a little more memory I might not have to suffer constant paging in X, but that remains to be seen.

The other option is to hook another drive into the chrooted system during installation, and do all the compiling from there. That I also mentioned before.

But another nifty trick is to do basically the same thing with the ports folder: Hitch the root drive in the Inspiron to that folder, and build packages on the host system drive. Or even better, create a symbolic link into the existing ports tree and then there’s no need to have two trees on the same drive.

I have an added complication, but only because I use an Intel PRO/2200BG wireless card in this laptop. I can’t get network access from the installation CD, because the firmware has to be compiled separately from the kernel, and I don’t know of a way to inject it into the live system.

Which makes the building of a piggybacked system a little tricky. The next best solution I have for that is to boot into the existing, ready system, and chroot from that into the modular drive. That way the kernel on the Inspiron configures the wireless network, and the hosted system only needs to assign a network address to it with dhcpcd eth0.

And the added benefit is that I can download source packages, build them for the Pentium and install them in much less time than it would take otherwise.

This time I put together two different systems on the Pentium — one Openbox and one full-blown IceWM system. Here’s the latter.

Both of them are particularly slow on this hardware; I enabled antialiasing this time and the results are terrible. Constant thrashing at the hard drive, two- and three-minute startups, and so forth. It is possible, like I mentioned, that more memory would make the delays somehow bearable, but I’m not holding my breath just yet.

I have a plan for this machine, believe it or not. It’s going to take a little effort, but I have a feeling this one will be a winner. Now all I need is enough time to put all the pieces together. …

Hallelujah: siliconmotion 1.7.0 and xorg-server 1.5.3

I have two machines with Silicon Motion Lynx video cards in them, and since the jump to xorg-server 1.5.3, neither one has been able to use its proper XF86 video driver. If I wanted the new xorg-server, I had to use the vesa driver, and if I stayed with the 1.4.2 version of xorg-server, I had to fall back to xf86-video-siliconmotion version 1.5.1.

Neither of those was a bad choice. But holding back on the core video elements of your system, update after update … well, it’s a bit like having a grain of sand in your mouth. It’s always grinding, no matter what you do, and you can’t quite put it out of your mind.

Arch bumped up to siliconmotion 1.7.0 today though, and I decided to go for it. I keep backup packages of the server and the driver, in case these things don’t work. But the new driver seems to be the solution, and my Lynx card is happy after the update.

So this is me, running the proper version of both xorg-server and xf86-video-siliconmotion, for the first time since around September or so.

Now all I need is for Xorg 7.4 to be able to detect the Chips and Technologies card in my ancient laptop. And I can retire to the riviera.

A Crux port for Zim

I use Zim a lot, as you might have noticed in my screenshots. It’s great for everything, and I strongly recommend it if you have any kind of hierarchical documentation that changes regularly or needs to be kept up to date. I use it to keep notes as I tinker with things; I can add and adjust pages to remind myself of commands I used or steps I took when I tried something.

I’ve been reluctant to put together a Crux port for Zim because there were a few dependencies that trickled down into Perl land, and all I know about Perl is how to spell it. Beyond that, I’m completely lost.

So in short: Fear of messing something up kept me from doing this before now. But I breathed deeply, put on the first season of Kung Fu, stuffed up my courage and waded into the mess. And I think this time I’ve got a winner.

Zim needs librsvg, which you can get out of the Xfce repos without drawing any other packages. It also needs shared-mime-info, which is in opt and may already be installed on your system. After that you need Perl’s File-BaseDir, File-DesktopEntry and File-MimeInfo.

# Description: Use the Freedesktop.org base directory specification
# URL: http://search.cpan.org/dist/File-BaseDir/
# Maintainer: 
# Depends on: perl

name=p5-file-basedir
_realname=File-BaseDir
version=0.03
release=1
source=(http://search.cpan.org/CPAN/authors/id/P/PA/PARDUS/$_realname-$version.tar.gz)
build () 
{ 
    cd ${_realname}-${version};
    perl Makefile.PL 
    make OPTIMIZE="$CFLAGS"
    make install DESTDIR=$PKG
	# Remove perlcrap
	find $PKG \
		\( -name '.packlist' -or \
		-name '*.bs' -or \
		-name 'autosplit.ix' -or \
		-name 'perllocal.pod' \) -delete

	# Remove empty directories
	find $PKG -depth -empty -exec rm -rf {} \;
}

# Description: Object to handle .desktop files
# URL: http://search.cpan.org/dist/File-DesktopEntry/
# Maintainer: 
# Depends on: perl

name=p5-file-desktopentry
_realname=File-DesktopEntry
version=0.04
release=1
source=(http://search.cpan.org/CPAN/authors/id/P/PA/PARDUS/File-DesktopEntry/$_realname-$version.tar.gz)
build () 
{ 
    cd ${_realname}-$version;
    PERL_MM_USE_DEFAULT=1 perl Makefile.PL 
    make OPTIMIZE="$CFLAGS"
    make DESTDIR=$PKG install
	# Remove perlcrap
	find $PKG \
		\( -name '.packlist' -or \
		-name '*.bs' -or \
		-name 'autosplit.ix' -or \
		-name 'perllocal.pod' \) -delete

	# Remove empty directories
	find $PKG -depth -empty -exec rm -rf {} \;
}

# Description: Perl/CPAN File::MimeInfo module - Determine file type
# URL: http://search.cpan.org/dist/File-MimeInfo/
# Maintainer: 
# Depends on: p5-file-basedir p5-file-desktopentry shared-mime-info perl

name=p5-file-mimeinfo
_realname=File-MimeInfo
version=0.14
release=1
source=(http://search.cpan.org/CPAN/authors/id/P/PA/PARDUS/File-MimeInfo/File-MimeInfo-$version.tar.gz)
build () 
{ 
    cd ${_realname}-${version};
    perl Makefile.PL 
    make OPTIMIZE="$CFLAGS"
    make DESTDIR=$PKG install

	# Remove perlcrap
	find $PKG \
		\( -name '.packlist' -or \
		-name '*.bs' -or \
		-name 'autosplit.ix' -or \
		-name 'perllocal.pod' \) -delete

	# Remove empty directories
	find $PKG -depth -empty -exec rm -rf {} \;
}

If those all look remarkably alike, that’s because I followed the example of a Perl port that was in contrib. It seemed like the best idea.

Now Zim proper.

# Description: A WYSIWYG text editor that aims at bringing the concept of a wiki to the desktop
# URL: http://zim-wiki.org/
# Maintainer: 
# Depends on: p5-gtk2 librsvg p5-file-mimeinfo 

name=zim
_realname=Zim
version=0.27
release=1
source=(http://www.zim-wiki.org/downloads/$_realname-$version.tar.gz)
build () 
{ 
    cd ${_realname}-${version};
    perl Build.PL destdir=$PKG
    perl Build
    perl Build install
}

That should do it. I know Zim is a bit esoteric, and installing a package in Crux takes a bit of work and time, so you might want to try it in another distro before going through all that. For me, it’s well worth it.

The irony of this is, I had been keeping Arch on one machine almost exclusively because I use Zim on that, and it was just easier to install it in Arch than it was to build all the interlacing ports. And it turns out it wasn’t that bad after all.

“Because a man can see, he does not look.”

P.S.: Thanks again, Colin.

What the … ? urxvt-tabbed?

Strange what happens when you hit a key at the wrong time. I pressed the tab key by accident last night, and found this.

Where did that come from? I’ve been using rxvt-unicode off and on for years now, mostly because it can display antialiased fonts and pseudotransparency, but more recently because it can display Japanese text too. I never knew there was a tabbed version … or rather, I never bothered to look for one.

Serves me right. I’m guilty of running three or four terminals at a time and wringing my hands because I wished it would show tabs, and here all along (or at least sometime recently) tabs were a possibility. Once again, I’m late to the party.

Personally, I prefer Sakura still, just because I think Sakura is a little more considerate of graphical environments. urxvt-tabbed doesn’t seem to have any configurable points from the program itself. In other words, if you want to adjust pseudotransparency or set other options, you still have to do that from the .Xdefaults file. Sakura, on the other hand, has a nifty right-click menu that gives you the chance to change things while it’s running.

But this is very useful, and good to have on board. Arch has this in it by default; the Crux version will comply if you include gtk-perl when you build it. Ubuntu … I haven’t looked yet.

And that, again, was my original mistake.

There is no setup.py uninstall

Seems there’s no way to uninstall a Python application that you’ve installed with python setup.py install, short of manually scraping out the files it creates. I spent a short while this morning looking for some sort of python setup.py uninstall, but apparently it doesn’t exist.

Until the Python gurus can cue me in, I used this roundabout way to gut a misbehaving Python program from my system. After installing it and finding that it didn’t do what I wanted, I “reinstalled” it again with the same command, plus one flag.

python setup.py install --record files.txt

I got a nice clean list of files and their paths, which I could then conveniently “uninstall” with this:

cat files.txt | xargs rm -rf

It seemed to do the trick.

Goals and resolutions

Considering the short list I had for goals in 2008, I did pretty well. I did manage to get my hands on a very obscure, slow machine, as well as a high-end computer for a short while. I also managed to properly configure my router to allow torrent and rsync traffic, and tried — and rescinded — a new look for this site.

Actually, the only thing I didn’t tackle last year (and ironically, it might have been the most important thing) was to learn more about GPG so I can start encrypting my e-mails. I tinkered with encryption a few times, but I never fully implemented it. I have the general idea, and I can actually encrypt things if I want to, but I don’t use it on a daily basis.

So that will be the first goal for 2009, use e-mail encryption on a regular basis. Not so much as a learning experience, but as a matter of necessity. It makes all the more sense considering I send most of my traffic over an unprotected wireless network. Even if the walls are too thick to allow the signal to reach the opposite side of the building, there’s no telling who’s listening at close range.

Next, I think it’s time for me to branch out a little bit. I am going to take another turn at Gentoo, mostly because the last time I spent any time with it, I had very little experience building things from scratch. I have a feeling now that, after a year of using Crux off and on, I can handle a source-focused distro. What I remember doesn’t scare me.

After that, I think it’s time to take a look at BSD. My brief run-in with FreeNAS was sufficiently impressive to make me wonder if that side of the fence isn’t worth checking out. Most of the Linux distros I prefer tout “BSD-style (somethings),” whether it’s package management or initscripts, so clearly BSD is doing something right. I would like to find out what it is.

Finally, I don’t think I’ve been fair to my OLPC. Sequestering it in the closet because of one sticky key is hardly a balanced treatment. I regularly use hardware with much more serious defects than that, and I don’t dump them in the closet and pout. And besides that, I got a few helpful e-mails from another OLPC user, and my curiosity has piqued again.

One addendum: I may, actually, be on the lookout for another machine again, something in the same vein as the 2Ghz Pavilion I had for a short time last year. I do think something with some compiling power might be useful, although I was thinking the same thing last year, and it ended up as a zero-sum event. We’ll see. It won’t be “new,” just “newer.” You know what that means. …

A Crux port for Dwarf Fortress

Silly me, I waxed poetic about Dwarf Fortress the other day, but never posted the Crux port I used to install it on my system.

Be aware that this doesn’t mention the dependency on GL libraries — libgl in the original Arch PKGBUILD — that you should add depending on your hardware. I use the proprietary hardware driver from Nvidia, which is why this doesn’t include it.

# Description: Dwarf Fortress is a single-player fantasy game.  You can control a dwarven outpost or an adventurer in a randomly generated, persistent world.
# URL: http://www.bay12games.com/dwarves/
# Maintainer:  
# Depends on: gtk libsdl sdl_image 

name=dwarffortress
version=v0.28.181.40d5
release=3
source=(http://www.bay12games.com/dwarves/df_28_181_40d5_linux.tar.bz2)
build () 
{ 
    cd df_linux;
    install -d $PKG/usr/bin/;
    cp -r $SRC/df_linux/ $PKG/usr/bin/;
    echo "#!/bin/sh" > $PKG/usr/bin/dwarffortress.sh;
    echo "cd /usr/bin/df_linux" >> $PKG/usr/bin/dwarffortress.sh;
    echo "./df" >> $PKG/usr/bin/dwarffortress.sh;
    chmod -R 777 $PKG/usr/bin/df_linux;
    chmod 777 $PKG/usr/bin/dwarffortress.sh;
    install -D $SRC/df_linux/readme.txt $PKG/usr/share/licenses/dwarffortress/readme.txt
}

Thanks once again to the Arch community for putting together a working PKGBUILD, and to Colin Zheng, for making the transition between Arch-ese and Crux-ese much, much easier.