Final Chapter: Thus Ends...

The reason why gdb would not work on Ubuntu: a deliberate policy by the OS developers. Cheers, guys. At least the stack overflow(s) make finding why easier.

There is a lot of good looking "web stuff" around. 

Sublime Text 2 is good in part because of packages (installation, usage). Also as it works in Linux, Windows, and OSX.

Nostalgic returns to operating systems of the past require the opening of disk images as floppy drives are in the past (as indeed, the disks...). A RISCOS disk module to make disk images appear as mountable disks exists, and is useful in ARCEM.

Once again, I content myself to computing on OSX and Windows, leaving Linux again except on the Raspberry PI. The usability issues are never addressed adequately. Its an open question if the pain points of the past are addressed before it becomes irrelevant e.g. CD/DVD burning may finally work well, but do I care any longer? Some old and fun rants on Linux usability (or the lack thereof).

The Nature of Code is a fascinating book. 

IDE testing is not so often blogged about.

Word games are popular, but need dictionaries! Here is a game with swedish and english dictionaries in Sqllite DB files. (May be a good game, don't know!)

Sleepless Nights

To quote a colleague

I want gdb to die in a fire. If thats possible.

A sentiment I can only agree with, to be honest. However, it remains in its spread of variably buggy obsolete forms embedded within the development tool chains of too much of the world to avoid. Some notes on living in the land of the clone of the Unix tools from the 1980s. A link to a GDB reference card. Programmable systems (debuggers like GDB, editors like emacs, typesetting systems like LaTeX) have been universally dire in user experience, in _my_ experience. The intended bonus of programmability becomes a curse of necessity; the burden is placed on the user to make the tool usable in the first place. In essence, I want to write programs to solve _my_ problems; not to solve problems in the tools I use; and _not_ to write programs in the debugger while debugging the interesting program or to debug program errors in a document processor.

A set of optparse documentation for common tasks since, as it notes,

we start new project so seldom, it is difficult to remember all those recipes that we come up with, every time we add a new command line option. This article is an attempt to bring together such recipes.

Python can query its environment for the functions in the current module (which is done slightly differently than for _other_ modules). This is useful for auto-testing, saving the need to write out a function list explicitly. Can embed these gist things into a blog post, too.



After the GDB rant, I confess I don't program gdb much and have not (yet) needed a .gdbinit file to customise GDB in a semi-permanent manner. However, I have some user defined commands to not forget in case I need to stay in GDB a little longer...



JGrowl implements growl style notifications in a web page. Cool, if not immediately useful. Also, drop shadows via CSS.

Can fork multiple threads (well, processes) in bash and then join (wait) for the completion of them. Good for parallelism of shell script controlled processes.

cmd_A &
cmd_B &
wait