Technician

It's actually a very interesting experience to be an IT administrator. You get to look at the computers from the practical side too - you actually see a SATA disk cable, don't regard digging in a power source and replacing a broken fan as anything exceptional, and so. You also meet a lot of Windows boxen and thankfully also plenty of Linux machines (with RedHat 9 or Fedora - though I have to admit I would sometimes (I mean, rarely - but still) like Windows more there).

Fedora TUI admin tools are a nice example how not to do a text user interface. It was apparently just coded to wrap up the graphics interface and "feel" the same way - except that you will frequently have only the keyboard at your disposal, and the nightmare begins. The controls are awfully awkward, you need to always tab to the submit button (but sometimes use arrows instead), moving between fields just feels strange and an urge slowly develops to get yourself a hammer. Big massive hammer. Especially in the case of the Disk Druid, shall it be condemned from the disk forests for all future times.

I don't know, Fedora seems to be just strange to me. I prefer KDE to GNOME (for irrational reasons), and Fedora is pretty gnomish. I wasn't able to find any notepad-style editor in the Redhat menu (the thing equivalent to the Start menu ;-). I want a shell as soon as the installation CD boots up - it doesn't give it to me until after it starts the actual installation program. The <kbd>yum</kbd> thing seems to have at least double startup time compared to <kbd>apt-get</kbd> on my Debian notebook, which has half the CPU clock of my work machine. I guess I could come up with more stuff...

The Faculty of Math and Physics I study and work at has its buildings spread all around Prague, which means you can read a lot of nice books during your study - what else to do in the trams and buses. I work in the building at Mala Strana, where is the computer science section of the faculty. At some evenings, instead of just taking a tram I like to go through the Mostecka street, over the Charles Bridge, then making my way through the Karlova street, finding myself at the Staromestske namesti (the Tyn Church looks absolutely stunning at the evening, myriad of small turrets and towers all lit in a yellow or white light, looking like an ancient middle-age castle from some fantasy movie - it is hard to take photos of it in the darkness with my crappy camera, though :[ ). Then I go through some lesser known streets to eventually arrive to Namesti Republiky, where I can already take the tram.

It's a very nice and refreshing trip, and marvelously beautiful and romantic too. The churches are monumental, the streets are narrow and darkness covers the cranky pavement (ok ok, it's not cranky - but it should be! :). Of course the only problem are the tourists. Before Christmas taking this trip would be suicidal, you would've drown in the avalanche of oddly speaking people. Few days after the New Year, it got very nice - the streets were almost empty, everything calm and silent. It's still acceptable now, but it's already getting worse, more people are in the streets and it probably won't get better until the early fall or so - and who knows, perhaps January is the only relatively tourist-free month? :-(

The Math Analysis exam is drawing near. I should get to work, I guess. ;-) I still need to consolidate the transcripts - I would also like to send them to the professor ASAP. That's a lot of work and learning still ahead, and I'm not idling too much at work neither these times. Well, we will see.

#

DTR (Dull Technical Rambling)

Do you hate it too that Advogato keeps escaping my (I mean, your ;-) cute markup like the <code><kbd></code> and <code><code></code> elements? It's annoying, but I'm too lazy to dig into mod_virgule to fix that (what a funny name, anyway). Advogato seems to be at its <span title="What's a better non-ambiguous word which would fit well here?" class="xe">vesper</span> anyway; the frequency of weblog postings at least dropped drastically compared to the last time I checked about half a year ago.

cdfrey recently talked about how painful web programming is. I agree that in general, web programming can be a PITA at least for the start. However, after you gain some experiences, you usually stabilize on some framework which suits you and actually makes your web programming not too painful at all. I for one eventually stabilized on a rather quite trivial framework consisting of few custom Perl modules I just carry around. They wrap the boring parts of page generation and the most boring SQL (if you just want a single row, something like <code>sql_load_record(dbh => $db, table => 'foo', bar => 'baz')</code> can make doing stuff really much more pleasant. mod_perl makes the Perl-generated stuff lightning fast, too. I also tend to separate functionality rigorously and have a special script for almost every page and action; I heavily modularize all the common parts, and I found this to be much more maintainable than a single big script with some smart multiplexing etc.

I will hopefully soon finally get back to my Graph-Layderer project - an attempt to create a general infrastructure for layouting and drawing graphics. It uses the famous spring algorithm, which also e.g. Graphviz's <code>neato</code> uses. However, my set of Perl modules aims to actually create something which is also at least a little visually pleasing, which you can't really say about Graphviz's output in general (read as: it tends to look like crap and frequently it all collapses and gets funnily mangled together; unless they made a dramatic improvement over the last year or so). It should be workable, I only need to make an actual interface for it and probably some script wrapper so that non-Perl programs can use it too. I'll need to check about the Perl Artistic License's compatibility with GPL, too.

But today I had another nicely unproductive day - I did almost nothing, and did that very slowly so it took all the day. The worst thing about me and those days is that instead of getting my ass from the chair and going for a walk if anything, I keep sitting at the computer and devastating my eyes. I'll need to have a serious long talk with myself.

#

A green-blue Gentoo blues

I feel the urge to teach! Pretty funny. Well. I would so much like to try it... I think I wouldn't suck at it (but I never really tried before) and I really love sharing my knowledge, more so in an interactive way. I will surely try to apply for teaching some practice classes for Unix next year. Teaching Programming practice classes could be interesting but OTOH I hate the idea of having to deal with massive amounts of Pascal code. Teaching Internet would be just boring, I guess. And teaching Discrete mathematics practices would be well over my head, at least so far. So my only hope for now is an unofficial thin-circle lecture on efficient bash (well, readline applications in general) and vim usage I was offered to someday hold on the campus. ;-)

I've been playing with Gentoo again. I've made my first ebuild, filing few bugs along the process. The ebuild tool is really awfully confusing for a newcomer. For some funny reason I kept writing <kbd>/usr/share/portage</kbd> instead of <kbd>/usr/portage</kbd>, so after some encouragement from <code>#gentoo-bugs</code> I decided to change my <code>PORTDIR</code> and see what will break. ;-)

There are some other rough edges I'm slowly discovering; on my TODO list I have an implementation of <kbd>emerge -T</kbd> which is like <kbd>-t</kbd> but shows the dependency tree with some asciiart, not just indentation (I find the indentation pretty hard to process by my optical brain centers). Also, when I'm doing a big many-packages emerge, I would like the summary of all package "installation notes" to be printed at the end, not scattered during the process where it is extremely unlikely I will ever read them. In the longer term, I want to investigate how well are the binary packages supported etc. I hope to finally learn at least some of the Python along the process. ;-)

BTW, in order to get dvifb to work, I had to restart gpm from inside the chrooted Gentoo system. But don't ever do that through the "standard" way - that will cause the dependencies to be triggered, it will happily remount your fstab (causing live filesystems to be remounted, bypassing the safety checks somehow) and so. I will try to make the system pretend those things were already done so that I can slowly restart all the stuff inside the Gentoo chroot so that I'm sure everything works when I do the final switch. I might try to switch bind to Gentoo tomorrow and also build my custom qmail ebuild (without dependencies on the other djb stuff like daemontools, which I dislike a lot).

Another BTW - if you also hate the bind9's host utility, you may find my comparison chart against bind8's host useful. On the new Gentoo system I just installed some standalone <kbd>host</kbd> utility whose output seems to be rather bind8-like. There are some glitches though, i.e. <kbd>-al</kbd> might not produce a valid zone. I might do some patches. ;-)

I will have to investigate all this funny trackback stuff, RSS feeds etc. (But it looks like at least those of my blog entries also forwarded to Advogato should have RSS feeds. Note however that I forward only articles which have prevailing technical contents which might be interesting/useful for the Advogato audience.) This weblog site could do with some CSS facelift, too. (Note to self: Remember to check why root.cz's CSS causes everything to be centered in ELinks.)

Also, please feel encouraged to tell me about any grammatical errors or awkwardness I will commit - please help improve my English! :-) (I will have to once write up about me, writing, English etc.)

Dum-tu-dum-tu-dim-ta-dum-dwamm-dum-tu-tam-dam. I should go sleep. Now.

#

Living on my console

I've read this very nice article calling for a console distribution few while ago, so I decided to followup on my blog. I think I have some things to say, using the Linux console (virtual terminal, virtual console, Linux terminal, call it how you like - just the thing your system scribbles its startup messages to; I'll further call it just "console") almost exclusively on my home desktop and exclusively on my notebook. Some popular console applications also originate from my software stable, namely ELinks, which I've originally created (read as forked from Links) and been maintaining until this autumn. So much for the self-advertisement. ;-)

I manage a Debian installation on my notebook and I simply refused to install X there. And sometimes it was pretty challenging to edge my way through the dependencies forest so that nothing I really want and is in fact for console doesn't depend on X too. It's basically impossible for SDL applications with both X and fb backends (unless I compile them myself). Eventually I gave up and let it install the xlibs. I still don't have any X server or so there, but so many things were linked to xlibs even though they had framebuffer frontend too, that I decided the disk space is worth it. The situation is generally getting better though - i.e. gnuplot-nox depended for some reason on gnuplot-x11, now it only suggests it. Of course it is more complicated with games, since even SDL-based ones which should work fine in framebuffer often depend on xlib (I'm sorry that I'm unable to come up with a specific example now since I have my notebook at work right now).

On my "desktop" home machine the situation is of course better just because I have a LFS-based own distribution there. So I get to decide what goes there and what does not and what links against what. As I said in my previous blog entry, I'm migrating to Gentoo which also has this sane dependencies advantage, so it seems things will go fine there, too.

So, how is life on the console for me? Well, I'm a programmer, not typical office computer user. So I never really needed any office suite for console since I simply doesn't use any. If I need to write something pretty-looking, I usually do it in TeX, and wvWare mangles most .doc files to some usable format successfully. Otherwise, I indeed can live fine with vim, Mutt, ELinks, irssi, mpg123 and ADOM ;-). I've been doing some TeX work lately and got some specs in PDF, but fbi (comes with fbgs so that I can watch .ps and .pdf files, too) and dvifb handle it all excellently. (Well, fbi still has a long way to come, because it is pretty much unusable for viewing i.e. photos since it does not support rotation well; I will start producing patches soon, I think.) Note that without a framebuffer (that is, if you have a video device w/o accelerated framebuffer), you can alternatively use dvisvga and zgv for these tasks.

So, am I ever using X? I don't have an X server on the notebook, so not there (and never needed it yet). On the desktop machine, I have to spawn Mozilla for some webpages - but much more rarely than you would say. (I usually went the ELinks-Links2-Mozilla path in the past but websites not working in ELinks didn't work in Links2 more often than not and since I got a faster machine this intermediate step really wasn't worth it anymore.)

Otherwise, long time ago (before I got a graphics card supporting framebuffer and VIDIX) I had to use X for movie playing movies, but CVIDIX is simply excellent so I don't need X for that anymore. X can be useful for debugging SDL applications (i.e. OpenTTD) - even though they run fine in framebuffer, it's difficult to gdb them there :-). And the only other thing I run X for is XMMS, since has a nice alarm plugin with fadein. I used to use mpg123 + <kbd>at</kbd> before, but this is more convenient; I could live without it, though. I also used XMMS for doing some transcripts lately. I patched mp3blaster's <kbd>splay</kbd> utility so that it does some seeking too, but it is not fine-grained enough for transcripts and I was just lazy to touch the patch ;-).

So, I live on the console and I'm happy. I don't mind using X when necessary, but it really isn't needed but very rarely. The writer of the original article wondered why an office suite isn't an itch for any console developers. I guess that if you are already "hardcore" enough to live exclusively on the console, you just won't need to do office stuff in office application, since you can usually mine the contents from the office formats and write own office-like documents in some markup. And regular users are scared of the console anyway. >:)

#

blm: Hi, I couldn't find your email at your homepage (which is apparently non-existant, looking too much default ;), so I hope you will read this through the recentlog or so. And this could be interesting for other people as well.

You say that noone wants you in their project, but that's not how most free software projects work (at least the bazaar-like ones, and I suggest you to prefer those especially when taking off). You do not ask people to let you join their team. You join it and integrate to it smoothly by sending patches. Most projects are based on meritocracy - your virtual "position" in the virtual team is based on your merit for the project. More you bring in, the more credit you get and the more people listen to you.

So, you do not look for projects with team willing to accept you. You look for projects which are exceptionally interesting for you, which give you some motivation for working on them (be it ideological, fascinating technically or scratching own itch).

From these, you choose those where you have clear idea what to contribute and of course you choose projects which aren't technically over your head, be it code complexity, insane coding style, being too low-level or the code is simply too big for you (it takes too long to update, compile or grep on your machine). But do not be too afraid; of course when you are newbie Perl coder you do not start by hacking Perl6 internals, but do not be afraid to peek into Mason. Remember, you get from the newbie level only by experience and hacking someone else's code is often much more valuable than coding something from scratch.

Actually, often the best way to start is to fix some easy bug. Do not get afraid by looking at the code. It could grin at you and make obscene remarks, but it can't harm you. It is laid on the canvas of your screen, waiting to be read, understood, grasped and touched by your fine coding hand. It is too big and takes too long to understand? Keep yourself focused.

First, be sure you skim over the documentation, both user and dev (if there is any). Then, you can look around briefly, but do not try to read everything, just try to see how is the code generally organized and how the grand scheme of things looks like; this step is optional. And then, do not look left, do not look right, look ahead and stay focused. Try to find the exact location of the code you will need to work on - grep the sources. Grep for the irritating error messages, grep for likely related keywords, patiently go through the results and identify the victim. Then look what causes it - be sure you at least generally grasp what the routine does (do not be afraid to look at the functions it calls, just do not descend too deep; grep - or better, use ctags), grep for the callers and work straightly towards the fix, not spending too much time on the non-involved code which is just distracting you. So, the synonym for getting oriented in the codebase and understanding the code is <kbd>grep</kbd>. You get used to grepping and the code holds no mystery to you.

So, you fix the bug (ok, we skipped a lot now, but that's already up to you; I told you to find something easy ;). Now you make the patch (google it if you don't know how to make a patch), the devs will prefer you to do that against the very latest version, preferrably from their CVS or SVN or whatever are they using; but usually, patch against the latest release will do too, if you are too afraid. So, you submit the patch and wait until it gets integrated. Do not be afraid to take the criticism; learn from it, absorb the conventions used by the project, be sure to look how they actually changed the patch before integrating it. Sometimes, the patch gets ignored; you either don't care and let it stay forever in the mailing list archives, googlable for anyone, or you care and push it; just do not push too hard, resent it once per week or so and eventually someone will at least tell you what's wrong. Again, absorb the criticism, adapt yourself and your patch. You don't like the way the project operates? First work your way up with the patches, you either see why is it good for the project or chagne it. Or, if you really think they are stupid, you care enough, your contribution is big, and the project is small, you can fork.

So, that's how it usually works. To sum it up - you choose the project which is exceptionally interesting for you and not over your head, and start by doing some simple patch. When understanding the codebase, grep is your best friend, and you focus only on the bit of codebase relevant to you. When submitting the patch, you learn from the criticism and do not get turned away by absence of a warm and enthusiastic response.