K.Mandla's blog of Linux experiences

One week at 100Mhz: Slow is as slow does, Mrs. Blue

I’m slowly learning to adapt to my 100Mhz system, and even though there are a few curious points that I’ve had to learn — like the hardware issues I described yesterday — I’m actually quite surprised that I get as much done as I do.

My initial, personal reaction to this little experiment was that I would either go completely crazy waiting to open e-mails, or lose my marbles with nothing to do outside the console. I know, I endorse console applications at every opportunity and practically shove them down the throat of anyone who visits here.

But as far as relying on them for day-to-day use, constantly and without any graphical backups … well, this is a new experience, I must admit. I accept and recommend terminal applications as alternatives or options over GUI-based ones, but as far as forcing myself to live at the console (albeit inside X), I’m taking a dose of my own medicine.

And pushing them at 100Mhz with only 16Mb of memory is a bit extreme — but necessary. I have to prove out loud that these are useful and viable. Walk the walk, not just talk the talk.

So in that sense, not only are the programs themselves presenting a learning curve, but the hardware is confounding things too.

One-hundred megahertz is slow, no matter how you look at it. Things were very different back in 1996, and I have the hardware experiences to prove it. Probably the biggest impediment is just overall web access speeds.

Wikipedia, for example, takes forever to load a page in elinks. It’s not even necessarily loading slowly, but there is some sort of end-of-page flag that elinks is waiting for, and Wikipedia takes forever to send it. So in the mean time, I sit and wait for elinks to surrender control to me again, just so I can read about the Battle of the Somme.

Other web-based stuff is also a drag. Posting pictures on Imageshack is a rather painful process, because the easy click-and-copy-and-paste routine that you and I both know and love … suddenly becomes an exercise in cut buffer wrangling, shift-click-dragging, and timing the right and left button clicks on a two-button ball mouse so that the highlighted text is pasted into place. But only as much as is visible at a time, of course. :roll:

elinks also doesn’t seem to have a “Copy link to clipboard” feature like Firefox et al. has. I can highlight a link and then shift-click-drag to highlight the address in the status bar, but there’s no provision to cut-and-paste a link. Which I sorely need for my plog boasts. The ones you see above were actually hand-typed. :(

On the other hand, GMail in HTML mode in elinks is the food of the gods. My account pages come up quicker in elinks at 100Mhz than it ever does at 1Ghz with Firefox. That I blame on Firefox’s fat butt, which can’t even render strict HTML without pausing for a cookie break.

And alpine makes things a lot quicker too. As an example, I use alpine to access a work e-mail account at home, and I can relay e-mails with prewritten text and signatures much faster with alpine than I ever could with Sylpheed. It’s hard to explain, but alpine’s insert text feature is a huge leap past cutting and pasting in a regular GUI environment.

So slow is relative, in one sense and in another. These console applications are often so much faster than their graphical counterparts that even a machine running at a tenth of the speed can outperform … for my money, that is.

But not everything is wine and roses, of course. I have a few sad points to report, but I’ll save that for later. You’re probably already bored reading this. Sorry, with so few of the distractions of a graphical environment, I find it a little too easy to write. :roll:

My sojourn with console only applications seems to have gone much better than yours sounds so far. True I was using a 500Mhz computer with 384Mb of ram. But I spent it with no X and it was much longer than one week. I think I lasted about a month or so. I must say that I like screen better than any tiling window manager. The thing that ultimately brought me back to X was Flash. I need Flash for music discovery. I’m basically always listening to and finding new artists. Anyways, keep it up. ^_^

I’ve noticed Elinks being slow at looking up new websites, even with an 2GHz+ dual-core and IPv6 completely and utterly disabled. But (and I’m not entirely sure what went right here) this last time I fiddled with /etc/resolv.conf and /etc/hosts, I somehow eliminated the problem, and sped up website lookups in all web browsers.

I think it has something to with

a) Manually configuring eth0, instead of relying on DHCP. However, I’ve done this in the past with little to no effect on Elinks.

b.) Commenting out the “domain” and “search” lines in /etc/resolv.conf, as well as the “nameserver 192.168.x.x” line.
I’m guessing this forces everything to go to the ISP’s nameserver first, instead of searching on the home IP, and then scanning the domain for nameservers.

Perhaps, if you use pdnsd or something similar, you should leave the “nameserver 192.168.x.x” line in there, as pdnsd seems to archive DNS addresses on your computer for faster lookup. I don’t know, haven’t tried it.

I did have DHCP set up before manually configuring everything, and I took the nameserver lines it generated when I set everything up manually.

—————————————————————-

DISCLAIMER: All of the above are taken from personal experience and tinkering on Debian 5.01. Although this *should* work with all Linux distros, or at least those using SysVInit system, it may not for you. 192.168.x.x is a generic address, and the two x’s will be numbers specific to your computer.

Actually I’ve seen that too with newer sites, on my “fast” machine too. There must be some sort of flag or end token that elinks is waiting for (if we’re talking about the same thing — a long lag late in the loading sequence). I wonder if there’s some setting that will chop that down. … :|

I tested it, and it´s definitely the resolv.conf change that did the trick of eliminating the elinks delay…although I´m pretty certain that DHCP will overwrite the change since it rebuilds that file every time it starts. DHCP daemons use ¨too much¨ memory and boot time anyhow. ;)