&ot Journeys' End

Journeys' End

We walk many paths, many roads
Till death halts our steps.
Every day a new adventure,
A new journey of self discovery.

20080731

iwconfig not setting essid?

If iwconfig wlan0 essid blah is seemingly not working when connecting to a open wireless network, then try

  1. iwconfig wlan0 essid blah
  2. iwconfig wlan0 key open
  3. iwconfig wlan0 enc off

The above seems to work for me by turning off encryption. It would appear with encryption enabled, iwconfig won't work for a open network because of some magic or other. If it still doesn't work, then try stick the above in your /etc/network/interfaces and prefix the commands with "wireless-", like so:

allow-hotplug wlan0
iface wlan0 inet dhcp
wireless-essid blah
wireless-key open
wireless-enc off

Hope this help some people, it drove me nuts!

Cheers,
Steve

Labels: , ,

20080724

grub, xfs, debian

Running grub-install with a XFS partition will likely fail - there is a reason lilo is used when XFS is root! The issue is grub-install creates the stage files in /boot/grub, which grub then expects to find when it accesses the disk directly using its own file system drivers. For most file systems sync is sufficient to force this to be true, but not with XFS - unless grubs's XFS drivers replays the journal, grub won't find the files. The detailed why of this is covered in this thread. To get around this, one needs to effectively replace sync with mount -r -o remount /; mount -w -o remount /. A quick a nasty way to get grub going with XFS partition is as follows:

  • init 1 # need single user mode to be able to remount root
  • cp /usr/sbin/grub-install /tmp # make a copy of grub-install to butcher
  • vim /tmp/grub-install
  • # now butcher grub-install as follows:
  • # 1. find the line that says "Sync to prevent GRUB from not finding stage files
  • # 2. deleted everything after sync
  • # 3. add exit 0 after sync for good measures
  • /tmp/grub-install # invoke our amputated grub-install to just produce the stage files
  • mount -r -o remount / # flush everything by mount as read only
  • mount -w -o remount / # remount since grub needs it to be rw
  • grub # invoke the grub shell
  • root (hdx,y) # manually specify the disk x partition y where /boot/grub/* is located
  • setup (hdx) # install grub into the disk x's MBR. DO NOT specify a partition number, XFS's sector 0 is NOT reserved for boot loaders!!
  • quit # exit grub
  • reboot # should work now

Cheers,
Steve

Labels: , , ,

20080716

unoffical libfg repository

I have set up an unofficial git respository for libfg patches and new swig generated python interface, as Gavin Baker (the author) appears to be busy with other things. This is a maintance only repository as far as libfg goes - I don't plan on adding any more features (since all the ones I need are there already). I will however work to produce a more pythonic interface to libfg, as the swig generated interface is a straight port of C api into Python.

Currently the repository contains the following fixes and enhancements:

  • RGB565 and RGB555 patch by Adalbert Prokop
  • fg_new_compatible_frame patch by echoline
  • mmap fix by me
  • swig generated Python interface by me

If you have a patch against libfg, please post it at the libfg project's page first, and then to me if Gavin does not respond. I do not intend to take over development of libfg, and it is my hope Gavin will in the future make this obselete/redundant.

Cheers,
Steve

Labels: , , , , , ,

20080705

Another holiday, another webapp

Thats right, another webapp! This time using google's app engine, so feel free to abuse it, somewhat :P

Rank'em is its name, and it basically lets you create a collection of Things then allow other people to rank each Thing against each other, producing an overall ranking of Things.

Have fun and let me know what can be done better.

Cheers,
Steve

Labels: ,

20080505

Death by *nix

chown state: you
chmod o+x you
./you

Cheers,
Steve

Labels: , , ,

20080428

{} I <3 thee

Firstly, I am the kind of guy who likes tabs over spaces, because I don't like forcing my particular preferences on to other people. To wax poetic, I like to give other people the freedom of choosing how they want their code indented. This of course brings me into the firing line of python programmers, for whom the 4-spaces-per-indentation-level is equivalent to the Ten Commandments handed down from Mount Sinai. Officially, python doesn't care, but thats like saying officially the Church accepts evolution.

I was editing a working python file written by some one else today, and wanted to convert it to tabs (yes yes, I know all about leaving files as I found them etc. Silence). So I ran unexpand -t 4 on the file. This simply replaces 4 spaces with one tab. This should have given me a working and correct python file though now indented with tabs. Naturally (Moore's law and all) this is not happened. The newly tab-indented file was riddled with errors because the original file was not indented properly so the simple conversion did not work. And as I go about fixing the errors python threw at me, I realised to my horror that information about the structure of the code was corrupted. Because python interprets code structure based on indentation, if your indentation is incorrect, your code is incorrect.

In comparison, a brace using language like C would have made the corrections trivial, because the braces explicitly specify the code structure. Python's argument that everyone indents anyway and thus braces are redundant is flawed - braces are not redundant because braces represent the separation of content from presentation, something that has been hammered into developers. In ignoring this, python has allowed a new class of errors - changing the appearance of code will now change the function of the code. I really can't see how this is a good thing.

If nothing else, python's integration of presentation and content, and thus presentation and program correctness makes it a far less robust language than brace using languages. Less robust in that a mangled python file is unrecoverable unless you actually read the code to figure out its structure, and that incorrectly transcribed python will likely run anyway with no syntactic or runtime errors.

Consider for example, the following code:

for n in names:
    foo(n)
    bar(n)

If you were transcribing the code and accidentally did not indent bar(n), the code now does something complete different yet no syntax or runtime error will be thrown. Now if the above code used braces, then it would have no effect. And if you forgot the brace, a syntax error will be thrown.

To be fair, python is a lovely language, and I do love it and use it extensively. Whitespace-as-syntax stance appeared at first to be a great idea, and one which now appears to be short sighted and naive. If nothing else, at least an interpreter which disallows incorrect space-indent files, that way tab->space and space->tab conversions would work correctly all the time.

Let me now put on my flame retardant undies, and you can flame away

Cheers,
Steve

Labels: , , , ,

20080328

eeepc, likes and dislikes

Likes:

  • nice and small
  • all the hardware works, including sleep/suspend
  • runs debian based OS by default
  • can run an external monitor at decent resolution

Dislikes:

  • uses fastinit which only boots into single user mode, so user "user" is always logged in. Endless frustration playing with X11 startup in vain to get a multiuser login screen
  • when kmixer shows a speaker with a cross on top, it means built in speakers will be used. When it is a speaker with no cross on top, it means headphone jack will be used. Talk about counter-intuitive.
  • keyboard truly sucks

Cheers,
Steve

Labels: , , , ,