two small git tips

the impact of git and github in the programmer community continues to amaze me. it appears that almost all major open source projects have made the switch to git at this point. naturally, i got interested too and started using git for my latest software project. however, coming from subversion, i found it not that convenient at first. here are two small tips that helped me become more comfortable with git, effectively making it behave more like subversion.

shorter status messages
the first one is about the status command. i find the default output of git status overly verbose. luckily, there is a more concise version: git status -s (for “short”). its output looks similar to the output of what you get from subversion. run the following command to configure git to always show the short status report:

git config status.short true

commit in one command
the second tip concerns the committing of changes. the normal workflow of making changes and committing them to the repo requires only two steps with subversion (modify a file, commit), while we need three steps with git (modify file, stage (“add”), commit). it seemed unnecessary and inconvenient having to issue separate stage and commit commands for the same action that required only one step in subversion. while there may be good reasons why git keeps those two steps apart, i wished for a shortcut. and in fact, there is one. if you use commit with the -a option (for “all”), it will directly commit all changes without the need for staging them first. a typical command may look like this:

git commit -am "implemented XY"

with these two measures, i found git to be much more usable.

managing passwords

internet life — 25. Jun 2014

modern (online) life requires having lots and lots of accounts. you need user accounts on all of your computing devices, work related accounts, and accounts for numerous internet services and online shops. as each of these accounts requires a username and a password, you will over time necessarily end up with dozens of such username/passwords pairs, and keeping track of them can be a headache.

as it is obviously impossible to remember all of them by heart, you will need some way to manage the passwords. there are actually two aspects to this: one is how to choose good passwords, the other is how to store them safely so that you can a) look them up if you need, but b) minimize the risk of misuse by others.

a strategy which i used myself for a while, and which i am guessing is rather common, is to use ‘reusable’ passwords. the idea is to have a small amount of passwords for different levels of security that could be used for a variety of services each. so maybe you have one password for your e-mail account, and another one for social media that you would reuse across services like facebook, twitter, linkedin etc., and a third one for various online-shops. this approach is obviously convenient from a practical point of view but very bad from a security point of view. if one of your accounts is ever compromised, all the others that share the same password will be too. for example, if twitter gets hacked, you will need to consider not only your twitter account as hacked, but all your social media accounts, and you will have to manually change passwords on all of them. it also means that any one of those services (e.g. a malevolent insider at the company) could access all your other accounts, as they could successfully use the username/password pair which you provided to them on other sites. bottom line: reusing passwords is a bad idea.

another approach that i believe to be rather common is to store passwords in your e-mail account. often when you sign up to a service, the service will mail you the username/password pair as a confirmation. because of this, the users get more or less accustomed to looking for passwords in their mailboxes, and may be tempted to start storing other passwords there by emailing them to their own accounts. this is convenient from a practical point of view as many people are usually logged into their e-mail account throughout the day anyway and the keyword based search function makes it fast and easy to look up passwords. thanks to the convenient search functionality, it is possible to choose unique and strong passwords for each service (instead of reusable easy-to-remember passwords). however, this approach has some severe security problems and i would not recommend it. one problem is that your e-mail password becomes a single point of failure — if it ever gets compromised, all other accounts will be compromised too. second, e-mail is by nature a very insecure communication channel and provides almost no privacy at all. as the latter is really a crucial point, i want to take some time to illustrate why e-mail is as insecure as it is.

imagine a town square full of people. you are standing on one side and you want to communicate with someone at the other end. so you take a sheet of paper, and you write down the name of the recipient as well as your own name on the top of the sheet and the actual message below it. then you give the paper to the person standing next to you. the message will subsequently be passed along between the persons standing on the square, with each person passing it on to one of their neighbors, depending on what seems most likely to lead to an efficient delivery. if there is a congestion somewhere in the network (e.g. because one individual is temporarily unable to pass on messages), the message will be rerouted through an alternative path. eventually, the message will reach the recipient, and they can return their response to you in the same way.

note that this system of message delivery has a couple of important implications with regards to security:

  • it is not predictable which way the message is going to take, as it depends on the state of the network at the time, and it is therefore not possible to know who might have access to it along the way.
  • as there are no envelopes, there is nothing that stops the people who pass along the message from reading it. the messages are being transported in plain text. this means not only that anyone can read the message, but also that neither the sender nor the recipient will be able to tell whether anyone has read it (let alone who read it).
  • a person who is positioning themselves in a good, central spot may gain access to a lot of messages passing through, and could — without anyone ever noticing it — make copies of all them. (in fact, that’s exactly what the NSA is doing).

it becomes very clear from this illustration that e-mail is by definition insecure. the only reasonable conclusion is this: do not send any sensitive information through e-mail!

(note: it is true that there are increasing attempts to encrypt individual sections of the path that an e-mail travels on. however, as of now, there is no way to guarantee that the e-mail will in fact be encrypted all the way between the sender and the receiver. the only exception is if you have proper end-to-end encryption with a strong encryption mechanism, e.g. PGP, which is however too complicated for practical everyday use.)

it follows without further explanation why storing passwords in an e-mail account is a bad idea.

an alternative that is sometimes recommended is to use a password manager application. this could be a desktop or a smartphone application. the idea is to have a central ‘password vault’, where all the passwords are stored and where you can look them up if you need to. this vault is protected by its own password, which should be extra-strong, obviously. it would appear that this is the best solution mentioned so far: it greatly reduces the burden on your brain, as you have to remember only one password (which grants access to all others), thereby allowing you to assign unique and strong passwords to each one of your services. as a downside, there is once again a single point of failure: if your password vault is ever compromised, all other accounts are compromised too. for example, if you run your password vault app on your android smartphone, there is a risk of being infected by malware, as android is a main target for malware these days. so imagine for a second that someone could manage to infect your device with malware, which could then perhaps plunder your password vault… not a situation that you want to be in. another point to consider is that you will strongly depend on your password vault app, and the device it’s running on. for example, if you keep it on your smartphone, and your smartphone is for some reason unaccessible (empty battery, stolen, lost, hardware failure), you won’t have access to any of your passwords.

so considering this, and keeping in mind what we have recently learned about the far reaching surveillance by secret services etc., it may be worth considering another, more old-fashioned approach: writing down passwords on paper. your ‘password vault’ would in this case not be an app but a physical paper notebook in which you’d write the passwords using a pen. the single most important ‘feature’ of this approach is that it is completely offline, which means no worries whatsoever regarding hacking, NSA spying, malware etc. the solution is reasonably convenient, as all the passwords are kept in one place and can be looked up when they are needed. the passwords can be unique and strong without a need to memorize them all. a notebook is mobile enough that you can bring it along if need be (although it would be better to keep it at a secure place at home, perhaps even in a safe). the downside (and of course there is always one) is that the passwords have to be written in plain text, which means that any unauthorized access to the notebook means that all your accounts are compromised (again: a single point of failure). however, it would pretty much require someone to break into your apartment/house and physically steal the notebook, which is probably a low risk compared to having your computer compromised. also, if there was a burglar in your house you would most likely know about it and be able to react, while having your smartphone or computer compromised may go unnoticed for a long time. such a password notebook would certainly be a sensitive item, and would need to be handled as delicately as your real-life purse and key-chain, both of which should not fall into the wrong hands either.

conclusion: there is no perfect solution, each solution will have to be a compromise between convenience, security and practical considerations. in light of the above, i would say that a ‘password vault’ solution is better than the alternatives, and that some good arguments speak in favour of an ‘offline solution’. avoid sending passwords (or other sensitive information) by e-mail. in any case, it is worth taking some time to think about your password management strategy now, as it may save you some headaches later down the road.

regarding the other point, that is how to choose a good password, i would definitely recommend to use a password generator. i have been using a small unix tool called makepasswd ever since i discovered it. just type this command into a unix/linux console and it will spit out a reasonably strong password, e.g. ‘1dYriCgeR’. so for any new service that you sign up, you use makepasswd to produce a good password and store it in your password vault. this way you don’t have to worry about inventing a password that is easy to remember, as you have the possibility to look it up when you need to. (there are also many online password generators, which i would not recommend to use, as it is not clear whether they are trustworthy and they might have potential security risks of their own. it is much better to produce the password on your local machine.) if you want to continue inventing your own passwords (rather than using a generator), you should absolutely read this XKCD comic.

links
EFF on emails
c’t zeigt Auswege aus dem Passwort-Dilemma

giving up on e-mail bottom-posting

e-mail,internet life — 15. Oct 2013

like many other people i have been using e-mail daily for many years now, and in all that time i’ve been mindful to use the bottom-posting style. bottom-posting was considered good e-mail etiquette at the time when i started using e-mail, it was listed on every “e-mail etiquette” guide, and i still believe that it is better than top-posting. consider this:


Because it messes up the order in which people normally read text.
> Why is top-posting such a bad thing?
>> Top-posting.
>>> What is the most annoying thing in e-mail?

(source: jefftk.com)

so here’s the rules that i’ve been following until now:

  • write your answer below the previous text, in order to preserve the natural direction in which we read text (top to bottom)
  • reply inline where appropriate to make it clear which statement you are replying to
  • trim anything unnecessary from the message (e.g. signatures, irrelevant text) to help the recipient focus on the important parts

however, times are changing. many people still stick to bottom-posting today, but the trend towards top-posting is evident. actually, it seems to me that the battle against top-posting has pretty much been lost at this point. this is, i think, mostly due to the fact that large webmailers like gmail, yahoo and GMX default to top-posting. update: it may also have something to do with the fact that people are used to seeing the newest content first on blogs and other webpages </update>. if you simply hit the reply button in those webmailers, it will “push” you to top-post. i don’t know about other webmailers, but i’d assume it’s the same. thunderbird still defaulted to bottom-posting when i last checked it, but it’s clearly in the minority here.

unfortunately the situation is still unresolved and people keep mixing styles. i often see messages like this one or this one, where people intermix bottom- and top-posting. that’s just terrible. mixing styles makes it impossible to read the conversation in an ordered and logical way.

another aspect of this discussion is that most mailing software nowadays shows e-mails in a threaded view. that reduces the need for quoting overall, since the previous messages are easily available, usually shown above the current message or at least easily accessible by “unfolding” the previous messages. considering that trend, it seems almost unnecessary to quote at all.

with that in mind, i’ve recently started to transition to a different set of e-mailing conventions:

  • do not quote (neither top- nor bottom-posting), send only the actual message
  • clean up the message as much as possible, delete everything besides the actual message. you don’t even need to keep the “person X wrote on sep. 7th…:”-line, because the information about author and time/date of previous messages is already there
  • if you need to answer to specific points (e.g. replying to each item on a bullet list), stick to bottom-posting (top-posting is nonsensical when answering inline)

needless to say, this approach has some drawbacks, too. it means for example that adding people to a discussion after a certain amount of messages has already been exchanged doesn’t work well anymore, because the new recipient cannot follow up on the previous discussion. the approach also assumes that the recipient has a threaded view in their e-mail client, which is probably true in most cases but not necessarily true in all cases. if someone still uses an unthreaded, strictly chronological view, they will not see the previous messages in the conversation and they may feel somewhat lost without the context. this may be more common than you’d think – for example my university uses lotus inotes for webmailing, and it does not appear to have a threaded view. still, i feel that overall this style – although not ideal – is more appropriate for today’s e-mail habits.

and please, whatever you do, do not intermix the different styles. if an e-mail conversation already has top-posted replies, stick to that, even if it’s not your preferred style. if the conversation started out with bottom-posting, stick to that. do not under any circumstance follow up a previously bottom-posted e-mail conversation with a top-posted answer, or vice versa.

links:
http://www.jefftk.com/p/abandoning-bottom-posting
http://en.wikipedia.org/wiki/Posting_style

web-based RSS reader alternatives

geeky,life — 21. Apr 2013

the announcement that google will be closing down its RSS reader didn’t go down well with a lot of people, including me. i use the RSS reader daily. i have subscriptions to ca. 30 feeds, mostly for general news (newspaper), tech/linux news and a few for work (some academic journals provide RSS feeds, i also have set up notificiations for a few web pages like job advertisement pages at universities etc. through page2rss ). i know we have no right to complain when someone stops providing a free service – still, it is annoying because it means that i have to look for an alternative. an essential criterion for me is that it needs to be web-based, because i use it from different computers and it needs to stay synced. the most promising alternative so far seems to be the old reader. i really like the minimalist approach. however, it seems it’s more or less a hobbyist project and we’ll have to see how they handle the large influx of new users. i’m also not convinced with their update speed yet. they say that they refresh the RSS sources at least once a day. but once a day is too slow. with google reader, i’m used to get updates within ca. 15 minutes. another alternative is feedly, but it requires a browser add-on and looks bloated. actually, i have more hope for a new reader that is being developed by digg. let’s see what they can cook up.

the question remains why google is suddenly closing down the reader. in the announcement, they are hinting at the possibility that it has something to do with their ongoing attempt to concentrate their activities around google+. but of course social media sites are not a full replacement for a full-fledged RSS reader. google also mentions that usage of their reader has been declining. i have a hard time believing that there is not enough demand, though, when i look at the user stats of the old reader before and after google’s announcement. this is more likely to be a business decision. google’s core business is ads. that’s why they don’t want you to read the news inside the RSS reader, they want you to read it on the webpage itself, where you’ll see the ads. of course in reality that won’t change anything because people will simply move to another RSS reader. besides, any sane person has an ad-blocker installed anyway.

update 30. july 2013:
google reader has been dead now for ca. 1 month. i’ve since more or less settled on using the old reader, however that was not a very long lasting solution, because they just announced that following a disastrously failed storage migration, they are going to close the service down to the public. well…
the good news is that in the meantime, the digg reader has been released as well, and i really like it. it’s quite basic but gets the job done, just what i need. so unless there are any bad surprises with the digg reader in the future, it looks like it will be my RSS reader of choice from now on.

update 9. october 2013:
the old reader has been brought back to live and after using it and the digg reader in parallel for a while, i’ve now more or less settled on using the former.

how to test webpages in IE7,8,9 on linux

ubuntu,webdesign — 2. Jul 2012

there is a free, legal and fairly easy way to test webpages/webapps in IE7,8,9 on mac and linux. i recently learned that microsoft provides virtualbox images created for this purpose. follow these instructions to install one or more VMs with IE. note: the script provided there gave me an error while trying to install a virtualbox extension pack. i had to download that manually from here and load it into virtualbox.

why is this a big deal? because i’m working 100% on linux and testing in IE has been a pain so far. while i do still have a winXP partition on my computer, having to reboot every time i want to test a change is extremely tedious. besides, IE9 doesn’t run on winXP and i’m most definitely not going to buy a vista/win7 license just in order to test IE9 compatibility. what’s more, windows to my knowledge never allowed to install multiple versions of IE alongside each other, so this is the first time i can actually test something in multiple versions of IE without rebooting and/or leaving my usual working environment.

html5 audio in the year 2012

audio,gamedev,html5 — 25. May 2012

html5 audio in 2012 is still in a rather sad state. true, there has been some progress. the <audio> tag is now widely supported across browsers and usable. however, anyone who has tried using it for a real life application like a game will have noticed that html5 audio is still pretty much unusable.

for one, there is the codec issue – there still isn’t a codec supported by all browsers, you need at least mp3 and ogg if you want to reach a signficant part of the userbase. if you want a single format that covers all major browsers, your only choice is WAV. i think this alone is enough of an annoyance to make working with the platform a headache.

second, the <audio> tag just doesn’t cut it for games. even for the most basic games (beyond tic-tac-toe) you need at least the following two features: immediate playback and support for overlapping samples. that’s because with games, you are usually dealing with short samples (sound effects) that need to be played back without delay, and they also need to be able to overlap. timing is crucial. the <audio> tag has not been created for that purpose, and it just won’t work reliably across browsers if you attempt to use it that way. a simple example with an html page that has a button and some javascript hooked up to it that plays a short sound via <audio> tag when clicking the button is enough to show the problem: when you click it a couple of times repeatedly it will give strange and unreliable results in different browsers. it’s just not good enough for games. there are a lot of people these days who say that html5 is going to kill flash on the web soon, but it makes me wonder whether those people have looked into audio at all?

the good news is that the w3 is working on a much more sophisticated web audio API. you can follow the discussion here. however, it’s still in draft version and currently only webkit has a (vendor prefixed) implementation. it seems to me that the w3 audio group is pretty much focusing on the web audio API now, so that’s probably where we are headed. mozilla’s own lowlevel audio data API appears to be on the way out. although there is one working implementation of the web audio API (webkit), it is clear that the specification process is far from over, with a large amount of issues recently brought up by the opera team. the group seems to be targeting 2013 for a first release of the spec (recommendation status), but some members have described this as very optimistic.

i’ve been playing around with the web audio API myself and i must say it makes a lot of sense and it has an impressive feature set. it provides all the functionality that i will ever need but is still fairly easy to pick up. for html5 games it really seems like the ideal solution. so here’s to hoping that it will reach a stable version soon and that other vendors will pick it up. with neither mozilla nor opera having started an implementation (as far as i can see), and no sign from microsoft whether they are planning to support it, it seems unfortunately that html5 audio still has a long road ahead.

in the meantime, you have three choices: 1) stick with the <audio>-tag and live with the poor results, 2) use the web audio API when available, otherwise fall back to the <audio>-tag, or 3) fall back to the flash plugin.

update: check out this talk about the web audio api from google i/o 2012.

doink spaltet sich

meta — 9. May 2012

seit es doink.ch gibt, hat die seite schon einige veränderungen erfahren. nun ist wieder einmal die zeit für eine grössere neuerung gekommen. schon seit einer weile war ich unzufrieden damit, dass die beiträge hier zu uneinheitlich waren. auf der einen seite stehen die themenbereiche germanische sprachwissenschaft, universität usw., daneben gibt es eine reihe von beiträgen zu ‘geeky’-eren themen wie html5, linux, webdesign usw. nun finde ich es grundsätzlich nicht gut, wenn die themen eines blogs zu weit gestreut sind. besser ist es, inhaltlich zu fokussieren und eine möglichst spezifische nische einzunehmen, ansonsten droht das bei vielen blogs zu sehende “kraut-und-rüben” problem.

da ich mich in jüngerer zeit wieder vermehrt mit html5 und webtechnologien beschäftige, schien es mir am besten, die beiträge zu diesen themen auszulagern. es ergab sich allerdings dabei das problem, dass ich den namen doink, den ich vor einigen jahren ohne bestimmte absichten gewählt hatte, eigentlich für die beiträge rund um html5 passender fand als für die themenbereiche germanische sprachwissenschaft usw. aus diesem grund habe ich am ende entschieden, statt den html5/webdesign-themen vielmehr die beiträge zur germanischen sprachwissenschaft auszulagern. diese sind neu auf swanrad.ch zuhause. auf doink verbleiben demnach nur die etwas ‘geeky’-eren themen. wer den RSS feed abonniert hat, soll also je nach interesse den feed von swanrad dazunehmen / denjenigen von doink entfernen.

zum neuen namen: swanrād ist ein altenglisches wort, das im heldenepos beowulf vorkommt (Z. 200). es bedeutet wörtlich ‘schwanen-strasse’ (engl. swan road) und ist eine poetische umschreibung für das meer.

einiges befindet sich zur zeit noch im umbau, ich bitte, gelegentliche 404s und irrtümliche RSS benachrichtigungen zu entschuldigen…

geography training with HTML5

educational,geeky,webdesign — 1. Mar 2012

i was having some fun with native ‘drag-and-drop’ in HTML5. as an exercise for myself, i designed a geography training app. head over to map-o-matic to check it out. needless to say, this works only with the latest generation of web browsers (works on firefox/chrome, doesn’t work on IE).

i mostly followed a tutorial over at html5rocks.com.

this was also my first time to translate a PHP webapp with gettext/poedit. pretty nifty :)

‘locate’ on ubuntu with an encrypted home dir

free software,geeky,linux,ubuntu — 5. Oct 2011

recently, i noticed that the locate command on my ubuntu system didn’t work as expected. it simply didn’t list files located in my $HOME dir, while it did still list files in the system directories. it took me a while to figure out that this behaviour was due to the fact that i decided to check the “encrypt home dir” option when i last (re-)installed the OS.

on second thought, it makes sense that it works that way, since the command to update locate‘s database (updatedb.mlocate on ubuntu) is run as a root cronjob, and as such it can’t access the filesystem while it’s encrypted. on the other hand, understanding this requires quite a bit of prior knowledge about how locate works, and i think it’s a bit rough to let the users figure this out all by themselves, without as much as a warning. the situation would be much improved if locate would at least spit out a warning that it can’t access the home dir, instead of the ominous silence, from which we usually conclude that no matching files exist on the disk.

after some googling, i found a good solution for this problem. this guide explains how to set up locate to store a separate, user-specific database inside the encrypted home directory. this also requires a user-specific cronjob. after following that guide, locate once again works just as expected on my system.

welcome to html5

geeky,webdesign — 13. Feb 2010

note: this will work only on very modern browsers (latest firefox, opera, safari). it will work partially on chrome (no audio), and it will not work at all on internet explorer.

update march 2012: major update! the game logic has been re-written from scratch (it was buggy), the game now has 5 levels, a reset button, fading effects, and even one very simple animation :) in addition, audio should now work on chrome.

Next Page »