Chimera 1.72 on Ubuntu 8.04

This one turned out to be easier than I thought.

   

Of course, the reason it was easy is because dav7‘s instructions were fairly clear cut. The only real trick is hardwiring ./src/Makefile to point at the right directory, and after that it’s smooth sailing.

I needed the xorg-dev, imake and build-essential packages to finish it, and I put together a makeshift .deb file with checkinstall, and it seems to work. If you want to try it out, I put a copy here, along with some of the other curiosities I’ve been collecting lately.

Drop me a note and tell me if it works for you. Pages with PNG graphics are going to hang the browser, and of course it lacks any real protocols that postdate 1993 or so, but you might find it useful for some simple browsing, or for use on a machine with no graphical muscle at all. It’s a little clumsy at times and even just changing URLs is a bit of a pain, but what can you say? It works.

I guess I should say, if it doesn’t, let me know.

Stop everything! An xaw-based browser!

Edit: Unfortunately, the images originally included in this post are gone, because of hosting problems in late 2009. My apologies.

I would have posted this about five minutes ago, but it took me that long to pick myself up off the floor.

That’s Chimera, an xaw-based browser dating all the way back to 1993. Just typing that makes my jaw drop again. I had it in my head that there were no browsers between GTK1.2 and the console, and then, wouldn’t you know it, some wicked Archer comes up with a browser that needs only the X widget set to display Web pages.

Even better, there’s now a page on Wikipedia for it, along with a brief set of installation instructions for Arch Linux. Fantastico!

I’ll have to spend a few hours seeing if it will glob together in Ubuntu, and then possibly see about putting together a strictly X-based desktop. Oooh! Yes! This is what I call fun … !

Volwheel saves the day

Edit: Unfortunately, the images originally included in this post are gone, because of hosting problems in late 2009. My apologies.

I’m a tiny step closer to a nearly picture-perfect phony Windows 2000 desktop, thanks to a little application that surfaced on the Arch Linux forums about a year ago — volwheel.

I’ve mentioned it before, but little things like this are still what make Linux amazing to me. It seems like the simplest thing in the world to want — a volume control in the system tray, adjustable icon, somewhat convenient control over the sound levels. Aside from that, I have no expectations from it.

But to be honest, it’s such an exceedingly terse and efficient little program that I can’t help but wonder what people did without it. One preference menu, accepts input from the command line or the mouse, completely happy to run in IceWM’s system tray, and I couldn’t be happier with the ability to point it at the icon for the volume controller from the WinClassic2 theme‘s icon bank.

It has some nice touches too — it does dynamic icons (in other words, icons that change as the volume level changes), it has a jump-to-mixer button that triggers a terminal window and spawns alsamixer (or another application, if you prefer that), and it takes up about as much space as a mosquito.

My only regret is that I don’t really have a use for it outside of this one machine (the Thinkpad), and so it’s somewhat underused in my household. I just don’t use panels that much, which means I don’t use system trays that much, so I don’t have a need for a panel-tray volume control … that much.

But if you’re one of those people who likes a taskbar or a system tray on screen, you should really check it out. It’s got all the right features, weighs less than a feather and looks good … no matter what you think “good” is.

Arch vs. Crux

I find myself the oblique topic of discussion on the Arch forums recently. Although I guess the real issue is a comparison between Arch and Crux, so I’ll stop flattering myself.

I don’t have anything to add to the debate that I didn’t tack on to the end of the thread, so if you’re debating trying one or the other, you might skim through the pros and cons. If you’re a Crux user you’ll no doubt appreciate the immense load of precompiled software available to you. And of course if you’re an Arch user you might find the similar structure and sparse setup to your liking.

In the end, it’s all the same flavor, friends. Linux is Linux, I always say. Use what you like, and you’ll be happy.

Why must everything be newbie-friendly?

I love Ubuntu as much as the next person, and I won’t ever say a bad thing about it. (Okay, well, not too many bad things about it.) I cut my teeth on Linux with Ubuntu, and provided it never reneges on its core promises, I doubt I’ll ever be anything other than pretty-pleased with it.

But occasionally I see one unusual side effect of the Ubuntu phenomenon — the sudden press to make everything “newbie-friendly.”

Now before you start to bristle, I was a newbie once and I’m more than willing to admit it. I made any number of exceedingly dumb mistakes two-and-a-half years ago — and I still do. Some of them were classic newbie blunders. Overall I got lucky and had friendly hardware at the start, but if it hadn’t been for that, I’d probably have written off Ubuntu outright.

And to be honest, I was a newbie twice — and my earliest reaction was exactly that: I wrote it off as stupid. As far as I was concerned, Linux was a joke. That was almost eight years ago, so really, I’ve been on the high and the low ends of the Linux newcomer experience.

But pushing every distro to be newbie-friendly and out-of-the-box cookie-cutter-perfect strikes me as a bad idea. There are some very newbie-friendly distros out there, and I think every darn one of them is manna straight from heaven. But in my opinion there’s no need to start warping the intermediate-level distros and the advanced Linux systems to allow ground-level users to start with them.

Everyone finds their own level with Linux. You get essentially the same stuff with each version, and it’s mostly just core tools and packaging utilities that separate one version from another. You can make anything as complicated as you like — you can rewire and recompile your entire Ubuntu installation a la Gentoo and obfuscate things as much as you want. You have that freedom.

On the other hand, there are some distros that are intended for “mature” audiences, and by that I mean more experienced, more advanced users. Pushing Arch or Crux or Gentoo or (god forbid) Exherbo to be “newbie-friendly” sounds counterintuitive — and furthermore a huge waste of time.

Why recast Linux From Scratch to attract Windows emigrants when OpenSuse and PCLinuxOS do such a good job? Why try to prepackage Arch as a newcomer distro when Debian and Fedora already have that cornered?

Like I said, everyone finds their own level with Linux. People asking for a newbie-friendly version of a distro are asking a foreign community to adopt a new culture — one that is more convenient to them. To me, that sounds out of place, and possibly out of line.

If you’re not ready for Arch as it is, then you should stick with what you know. One day your desire will outstrip your ability and you’ll learn a lot of new things. But until gumption exceeds know-how, it’s best to leave other people’s distros the way they are, and learn their customs when you’re ready.

Adjusting rc.sysinit, adjusting udevadm

My Arch systems still feel considerably slower than comparable Crux systems. The battered Thinkpad, as an example, needs 25 seconds to reach an Arch desktop, while it boots quite easily to an identical Crux desktop in only 18. Seven seconds is probably splitting hairs for a machine that starts faster than most Ubuntu machines, regardless of the desktop or hardware.

But for me, it’s a bit of an obsession. So I’m always curious about little tweaks here and there to make Arch run faster or start quicker. The idea of carving down the rc.sysinit file seemed like a good one, except for me it didn’t make things faster, and using the one posted in the pastebin by Barrucadu actually made things start slower.

It isn’t hard to manage though, so if you want to try it for yourself, trim out parts of the file that don’t apply to your hardware. (You’d do well to copy the original first, because you can accidentally make your system unbootable.) I don’t know how much effect it will really have, since most of those sections are triggered with if-clauses. If you don’t have the hardware, it probably doesn’t run anyway.

On the other hand, I still get great results from setting the --timeout flag on the udev-uevents sequence, which is inside /etc/rc.sysinit, but now set at the /sbin/udevadm line. (I can’t give you the specific line number since it changes when some updates are performed.) Make that line look like

/sbin/udevadm settle --timeout 3

Be careful with that timeout, though: Making it too short keeps parts of the system from being appended … in other words, unbootable, again.

One more nifty trick is to tack an ampersand — & — on the end of the modprobe command, in the module loading loop.

/sbin/modprobe $mod &

It probably goes without saying that autoloading isn’t affected by that … I think. So make sure you’re manually loading the modules you want in your /etc/rc.conf file.

These two together cut about three seconds off the 25 I mentioned earlier. But apart from those two, I haven’t run across much lately that will make Arch run like Crux. Funny, but it was almost two years ago exactly that I started trying to make Ubuntu run like Arch. It’s all a matter of perspective, I guess.

A Thinkpad, a kernel panic, a workaround

For some strange reason that I can’t seem to figure out, I get kernel panics on the battered Thinkpad with the latest Arch installation ISO. I won’t bother reproducing the error text here, mostly because there’s too much of it, but also because the screen is shattered and I can’t quite see everything.

The puzzle is compounded by the fact that it doesn’t seem to happen on the smaller Thinkpad. Both machines are Celerons, with reasonably similar guts, but for whatever reason the kernel panic doesn’t happen on the slower one.

The good news is, if you’re like me or like some others, the previous ISO image — the 2007.08 version — boots fine, and it’s a brief step up from those packages to current. So you have that option, if you find yourself in the same boat.

pacbuilder-svn

I was interested, somewhat, by the pacbuilder tool that cimi invented for Arch Linux. It would have been useful to me about six months ago when I was considering Crux for a similar reason — I wanted something that would comprehensively recompile an Arch installation.

It’s not something I can use though, since it relies on rsync and my proprietary router won’t (or doesn’t seem to) handle rsync. I can compile the -svn version from the AUR PKGBUILD, but it does me little good.

It’s still interesting to me, but unless it reverts (because, as I understand it, rsync wasn’t originally required) to a version that doesn’t need rsync, I can only watch from the sidelines and cheer.

Dependence, entitlement, victimhood

I still believe that part of the beauty of Linux is your ability to dive in and customize things how you like. The average Linux user has a measure of freedom and flexibility that most Windows users can’t even comprehend, because they’re boxed in so tightly by their frame of reference that their imagination is limited and stunted. No really, I believe that.

Even better, with perhaps only a little bit of help, you can actually build and compile versions of software before they’re released. In effect, you’re getting a snapshot of a program, as it grows, organically and methodically. The measure of freedom offered there is beyond description. It’s almost like being able to taste a meal while it’s being cooked, and experiencing all the new flavors as they come together.

So it’s always a little alarming to see that freedom refuted or denied or even just ignored. It’s not a new phenomenon (dare I say it surges a month or two after every Ubuntu release?), but there’s sometimes a petulant undercurrent to complaints about software readiness, or the time it takes to get new software releases.

And it’s not just Ubuntu users who occasionally get sassy. Ubuntu has a reputation of drawing new Linux users, and with that comes a fair amount of dependence on packagers, maintainers and developers. Occasionally that dependency is coupled to an attitude of entitlement. And in a worst-case scenario, that entitlement borders on victimhood.

But I’ve seen it in Arch users too — the perspective that, as an end-user, someone is “owed” a better degree of “service” from the volunteers who make these things happen. Arch users tend to be a little more experienced and a little more tech-savvy, but it doesn’t immunize them against an occasional whissy hiss fit, as some of my American friends used to say.

Let me counter that occasionally juvenile behavior with an allegory and a quote. First: Demanding immediate software updates from volunteer crews — particularly when, like I mentioned, you have all the tools at your disposal to create your own software updates — is a little like having a kitchen full of food, and complaining because no one will make your dinner for you. Is something wrong with your feet? You can’t walk to the kitchen and cook something for yourself?

Sure, not everyone is a great cook. And maybe the software you “cook” up isn’t quite … perfect … but if it works and it satisfies the update you demanded, who’s complaining? You did it yourself, and you didn’t rely on someone else for once. Most cultures applaud a degree of independence. I will applaud you too.

But more importantly, Linux comes with no service guarantee, unless you purchase one as an outside deal. It’s not in any contract or any terms of use or end-user licensing agreement or stipulation prior to download. Very simply, you got something for nothing, and what you do with that nothing is up to you. Don’t moan over slow updates or substandard “leadership” when you have all the pieces you need to solve the puzzle yourself. Linus said it best:

The Linux philosophy is ‘Laugh in the face of danger.’ Oops. Wrong one. ‘Do it yourself.’ Yes, that’s it.

You want an update? Build it. You want better hardware support? Write it. You want solved bug reports? Troubleshoot it.

Perhaps I sound like that proverbial old guy yelling, “You kids get out of my yard!” but really, people: You’re sitting on a gold mine and complaining about the glare. March yourself into the kitchen and start cooking.

Either that, or be content that someone, somewhere, is cooking your dinner, and they’re probably doing it for free.

The Exherbo brouhaha

Don’t fault yourself as clueless just because you haven’t heard about Exherbo yet. The distro-to-be seems to have gotten some attention for making it clear that your help is not needed, thank you very much.

There are plenty of opinions on the viability and attractiveness of a not-yet-published distro manned by a staff that is outright uninterested in drawing users, and most of them can be summarized here and here. (I only point to those threads because I’m most familiar with those forums, and most of those users.)

But I feel the need to be honest. About six or eight months ago I was seriously considering doing the same thing with a rearranged version of Ubuntu, mostly for my own edification, but also because I got tired of pruning and tweaking the default system to my liking. The obvious solution was to cook up something of my own invention with the packages and tweaks I like, preset and preinstalled. That way I could save time on testing and probing, since the majority of the performance settings I like would be in place already.

To make a boring story short, I never did it. Things got rearranged, much like they always do in life, and that back-burner project got shelved, then tossed out. About the same time I got Crux to behave the way I liked it, I realized a customized version of Ubuntu wasn’t appealing any longer. No loss, in hindsight.

But what really dissuaded me from doing it was knowing full well that if I did cook up something personalized, I’d have to mention it obliquely, and mentioning it would oblige me to share it, and sharing it would make me somehow beholden to support it, and that would lead to any number of complications, enlargements, arrangements and transmogrifications. I could foresee the thing snowballing beyond what I really wanted to deal with, and it became less appealing for that reason.

I could see only two ways around that problem: First, skip it. That was ultimately what I decided on.

The other was to release it or offer it without any promise of support, without any desire to troubleshoot or take suggestions or notes of improvement, bug tracking, error trapping, wishlists, compatibility problems, usability issues, suggested package lists, translations, instructions or manuals. In other words, say, “Here’s a link. Download it if you want it. I offer no support, and I don’t want to hear suggestions or problems or complaints or offers to improve it. Don’t bother me. The end.”

Sound familiar?

I guess where I’m going with this little soliloquy is toward an acknowledgment that Exherbo’s initial nonchalance and seemingly aloof attitude (my favorite part is, “we have nothing to offer you, and you have nothing to offer us”) makes sense to me. Yes, it’s very un-ubuntu, and it doesn’t do much to attract users or developers. But to be honest, I was of the same mindset not but six months ago, and rather than take the time to follow that path, I decided to abandon it. I’m almost disappointed in myself now because it was a learning opportunity and I turned it down.

I believe the expression is, “It’s water under the bridge.” It’s in the past now. I take a middle-of-the-road stance on the Exherbo issue because I trust they know what they want, they know what they don’t want, and I can, in part, empathize. Aside from that, they have nothing to offer me, and I have nothing to offer them.