As you can see, Amazon sells Kindle edition for higher price than a paperback. This book of course isn’t the only example for this ridiculous pricing method, and if one browses the Kindle store he will surely find more.

This really upsets me, as there is no honest reason to price an electronic edition higher than a real dead-tree paper edition. In both cases, the author and the publisher get their royalities and share of the profits. But the Kindle editions doesn’t have many related expenses, like storage, transportation (from the publisher to Amazon), and above all printing costs.

I don’t know who is to blame for this absurd thing, Amazon or the publisher (or even both). But the few things I know are that this bad for everyone, the customer because he pays more and Amazon/publisher as in the long run, this encourages piracy as the customer feels he’s being unfairly treated thus he will be more willing to play an unfair game as well.

ln -s gitg ui
./configure /pathto/below/gitg

The reason is that gitg will look for Glade UI files under $(datadir)/gitg/ui and in gitg’s source the UI files are in the gitg directory and not in ui.

You can see above a screenshot of gitg with spell checking enabled. Hopefully I’ll be done with the changes soon and they will be merged to upstream quickly.

Update: There are couple more things to do in order to get gsettings’ schemas right.

mkdir glib-2.0
ln -s ../data glib-2.0/schemas
glib-compile-schemas data/
XDG_DATA_DIRS=".:/usr/share/" ./gitg/gitg

For the schemas thing see glib-compile-schemas‘ man page.

Update 2011-12-17: Jesse (gitg’s maintainer) hasn’t responded to my email regarding the new feature, so I’ve open a bug (#666406) for it. If you’re willing to try the changes yourself, you can pull them from git://github.com/guyru/gitg.git spellchecker.

Andreas chose to put the sidebar above the content, which I prefer not to do. Furthermore as the sidebar was a “float” that came before the content, it caused additional inconveniences. E.g. if you had an element with clear: both it would be pushed bellow the sidebar. I’ve patched it a bit in order to fix those issues. You can find my modified version here: variant-whitespace.tar.gz

To make things worth, somewhere along the update to KDE 4.6, I got some of the data moved to ~/.akonadi.old. Being stuck with the InnoDB tables, I tried the following solutions without much success:

1. Loading the InnoDB tables to a MySQL server. Didn’t fare good, MySQL complained about weird stuff, and I gave up in search of simpler solution.
2. I booted a OpenSuse virtual machine with KDE and tried loading my old data. Apparently, my ~/.akonadi folder, contained nothing interesting and Suse’s KDE 4.6 refused to load the data ~/.akonadi.old after I renamed it.

So being upset about Akonadi I did some greping and found strings from my contacts and todo lists in the following files:

Binary file .local/share/akonadi.old/db_data/ibdata1 matches
Binary file .local/share/akonadi.old/db_data/akonadi/parttable.ibd matches
Binary file .local/share/akonadi.old/db_data/ib_logfile0 matches

I opened the files with vim, and found out the contained vCards and iCalendar blobs in them. So instead of directly storing them on the file-system, where they are easily accessible, they are stored in the DB files. I figured it would be easiest to just extract the data from the binary files. I’ve used the following script:

import sys
 
START_DELIM = "BEGIN:VCALENDAR"
END_DELIM = "END:VCALENDAR"
def main():
    bin_data = sys.stdin.read()
    vcards = []
 
    start = bin_data.find(START_DELIM)
    while start > -1:
        end = bin_data.find(END_DELIM,start+1)
        vcards.append(bin_data[start:end + len(END_DELIM)])
        start = bin_data.find(START_DELIM, end+1)
 
    print "\n".join(vcards)
 
 
 
if __name__=="__main__":
    main()

It reads binary files from stdin and outputs iCalendar data that is embedded in it. If you change START_DELIM and END_DELIM to VCARD instead of VCALENDAR, it will extract the contacts’ data.

This migration, had me thinking how important it is that application’s data should be easily portable. It’s a thing, I feel not many projects have high enough on their priorities.

Apparently, unlike Kontact, Evolution won’t ask you what every column means. It would just assume that the CSV is in some weird scheme. If you try to import the CSV, it would force the scheme on you CSV even if it looks completely different. The result – a complete mess of the fields in each contact.

I didn’t find the reference for how Evolution expects its CSVs to look like, and I didn’t want to analyse that either. So finally, I’ve set up a virtual machine, loaded it with OpenSuse KDE live cd and imported the CSV into Kontact and exported it as VCard which I imported to Evolution.

I believe, that the current CSV import in Evolution, just causes user frustration, as it doesn’t act as expected.

Other weird problems I’ve encountered in Evolution which I didn’t solve yet:

1. Evolution is that it gives me “Could not remove address book” when I try to to delete an existing address books. After restarting the program I’ve succeeded in deleting some of them but not all of them.
2. When I imported the VCard from Kontact, the contacts appeared in every address book (except one) and also appeared magically in new address books I’ve created. The contacts in each of the address books seems to be linked together. When I’ve tried to delete them from one address book, they’ve disappeared from the rest as well.

If you know how to solve these issues I would really like to hear.

The files scripts_ralcr/filesystem/readDirectory.php and scripts_ralcr/filesystem/readAndCreateThums.php take a path POST variable from the user and return a directory list of the directory path is pointing at. Of course it also comes with a directory-traversal so it would be easy to list whatever you want.

Finally, the file scripts_ralcr/filesystem/writeToFile.php simply allows you to provide via POST a path to a file (of course directory traversal is permitted) and content. The script will then write the content to the specified file. This allows a remote attacker to write arbitrary files on the server (which is especially useful after he dir listed everything to see what is available on the server).

I’ve followed the steps of responsible disclosure and contacted the author of these photo gallery before posting it. The author replied to me with:

i plan to solve them by the end of the year when i also plan to release a final version.
Till then, IMAGIN is not so popular for someone to exploit it.

I believe that saying that it isn’t popular enough for exploiting it is naive. Especially noting how obvious the vulnerabilities have been.

TypeError: character mapping must return integer, None or unicode

This is pretty unhelpful error message also occurs if you try any method that indirectly use altchars. For example:

base64.urlsafe_b64decode(unicode('aass'))
base64.b64decode(unicode('aass'),'-_')

both fail while the following works:

base64.urlsafe_b64decode('aass')
base64.b64decode(unicode('aass'))

While it’s not complicated to fix it (just convert any unicode string to ascii string), it’s still annoying.

<form>
...
    <input type="hidden" name="to" value="support@example.com" />
...
</form>

as it is likely that if the value of the “to” field changes the message will be sent to the modified address. The problem with this kind of functionality is that it allows a malicious user to send emails from your mail server. More specifically, it can allow spammers to user your benign server t send their spam (and as a side effect you might be flagged as a spammer yourself).

As this case is pretty obvious one doesn’t see many real-life uses of it anymore (but careless programmers used it more often n the past until they learned better). However one can achieve similar goals (spam-wise) by utilizing a common feature in contact forms: the “CC yourself” checkbox.


“CC yourself” is a convention used by some people when mailing, to verify that the email was indeed sent. It had found a place in many contact forms, as people wanted a way to make sure the form indeed works. But contact forms (as well as some mail servers) don’t verify that the email provided as the “from” is indeed owned by whoever fills the form. Combine that with the fact that many contact forms don’t employ CAPTCHAs (to make the form simpler to use), and you’ll get a situation much like the one discussed above.

In the first case there was a usability advantage to the programmer (who could easily re-use the form’s backend for other forms), which can be easily sacrificed for enhanced security. This time it’s worse as this is a usability feature for the user, which many people believe to be very convinient in contact forms.

I think there are several solutions possible:

1. Adding CAPTCHA to the form. This will make life for the spammers harder, but it also hurt the users by raising the bar for filling out the form. Also, nowadays, it getting harder and harder to find a strong yet easy for humans CAPTCHA.
2. Removing the “CC yourself” feature. this hurts the usability of the contact form.
3. Seperating verified users and unverified. Keeping the feature for registered users, but at the same time, removing it or adding CAPTCHA for unverified users. This seems like a good trade-off, but it requires more work and registration is not applicable for all websites.

In my opinion none of the solutions is perfect. It seems that once again spammers hurt the user experience for everybody else in order to fill our inboxes with unsolicited email.

The TiddlyWiki solution seemed great, and I’ve started using it. But as the title says, I merely looked over much simpler, yet as powerful, solution – a simple text file. Porting my rowing log to a simple, old-fashioned, text file provided me all the relevant features of TiddlyWiki, such as search, flexibility and working from usb-stick, while using less space and editable using a basic text-editor (or the powerful vim). Using reStructured Text, I got a nice readable journal that can be later processed into even nicer looking html files.

We all want to believe that we know to match the right tool for a task. But maybe, because we tend to adopt newer technologies and utilities all the time (because for a lot of tasks they do provide better tools), we end up over looking simpler, “old-fashioned”, solutions. If I take a moment now to look around, I can come up with several other places where new stuff is used instead of simpler solutions. Take a look around you, and I’m sure that you will be able to find some too.

So I wrote a patch for the he.po file that fixes the problem.

Index: he.po
===================================================================
--- he.po	(revision 28095)
+++ he.po	(working copy)
@@ -15050,15 +15050,15 @@
 
 #: src/Buffer.cpp:2902
 msgid "\\arabic{enumi}."
-msgstr "\\arabic{enumi}."
+msgstr ".\\arabic{enumi}"
 
 #: src/Buffer.cpp:2908
 msgid "\\roman{enumiii}."
-msgstr "\\roman{enumiii}."
+msgstr ".\\roman{enumiii}"
 
 #: src/Buffer.cpp:2911
 msgid "\\Alph{enumiv}."
-msgstr "\\Alph{enumiv}."
+msgstr ".\\Alph{enumiv}"
 
 #: src/Buffer.cpp:2928 src/insets/InsetCaption.cpp:293
 msgid "Senseless!!! "

While this patch is against the SVN trunk (LyX 2.0), it could also be applied manually to older LyX versions.
After yo apply the patch you should do the following (I assume that you are in the root of the LyX source tree):

cd po/
make he.gmo
cd ../
make install

Now restart LyX and you will see the numbering appear as it should.