Novatel Merlin U740 using only Windows 7 onboard tools

I have lost the install CD of my Novatel Merlin U740, an older PCMCIA UMTS card. As a consequence I got no “Mobilink Connection Manager” after installing Windows 7 on my notebook. Fortunately I found this guide by Novatel Wireless which explains how to connect using only on-board tools in Windows Vista, by setting up a dial-up connection. It still works in Windows 7. The important part is to set the APN as part of the driver’s initialization string.

The telephone number you have to set is *99#, which should be provider-independent.

The following settings are for yesss.at only:
Username: web
Passwort: web

Remember to set the APN as part of the driver’s connection string in Window’s “Device Manager” as described in the PDF.

Again, for yesss.at this is: AT+CGDCONT=1,"IP","web.yesss.at"

For this to work properly, the SIM must not have a PIN set, as otherwise the SIM will be locked and the dialer cannot dial out. For me this is ok, as it is a pre-paid card which can hardly be abused if it gets stolen, but your situation might be different, so please consider the security implications. (I suspect that it should be possible to unlock the SIM card somehow using the AT+CPIN=1234 command, but I did not research how to separate several initialization strings, as it did not work immediately.)

The solution works quite well for me, even under Windows 7. Disadvantage is that there is no way to tell the signal strength and exact mode of operation (despite the color-coded status led on the Merlin U740).

tr.im to be shut down

To emphasize my demurs against URL shortening services which I have mentioned before, here comes the prove that my thesis is correct: the URL shortening service tr.im is going to be shut down by end of this year. As Robert Scoble put it, this is a “shortcoming” of the Twitter platform, where the shutdown most likely will be felt most.

This is the first time I am aware of actual knowledge/data-loss which will occur due to the shutdown of such a service.

Update: tr.im announced that they will stay in business, due to an overwhelming response. But still, the final shutdown of such a service sooner or latter can and will happen. And even worse would be the continuation of such a service where all the URLs would be redirected somewhere else…

http://blog.tr.im/post/160697842/tr-im-resurrected

URL shortening services soon to be under siege?

I have already written about my opinion about the problems of URL shortening back in 2005. Yesterday, Jeff Atwood pointed out other issues like commercialization. Today, another threat has come true: hackers have manipulated the URLs of shortening service cli.gs.

Given the huge amount of information hidden behind such shortened URLs, and given the popularity and number of these links, especially nowadays on Twitter, these services could see themselves being under permanent siege of hackers/crackers. Being able to manipulate hundred of thousands if not even more vastly distributed and popular URLs to point to a given site could be used for both, generating (lots of?) ad-revenue, or as a new form of DDoS-attack.

At the moment there seems to be no way around using these services (especially with services like Twitter), but in the medium/long run a solution has to be found if we don’t want to lose lots of valuable information.

Windows Vista Home/Business/Enterprise has a telnet client, too

For some unknown reason, Microsoft decided that only the “Ultimate” version of Windows Vista ships with the telnet client installed by default. It can, however, be easily installed on all the other versions as well.

  • Open the Control Panel
  • Select “Programs”
  • Select “Turn Windows features on or off”
  • Scroll through the list, select “Telnet client”
  • Press OK
  • Wait (for surprisingly long)

That’s it, voila, the telnet client is now installed on your Windows Vista Non-Ultimate.

How to force Git to consider a file as binary

If you are using Git on Windows and follow my advise on how to get past the problem with the “suspicious patch lines”, you might run into problems if you are using Encapsulated PostScript (.eps) files in your repository.

PostScript files are almost plain-text files, and if you set core.autocrlf and core.safecrlf, they might cause problems with the EPS binary encoded parts, as they might be detected as text-files and therefore remove any CRLF and replace it with single LF, which can mess up the whole image.

To force Git to consider a file binary which it would consider as text-file otherwise, the easiest way is to add a .gitattributes file to the directory containing the file or to any parent directory. In my case, I normally add a .gitattributes file in the root of the repository, containing

*.eps -text -diff
*.jpg -text -diff
*.png -text -diff

In the file you set attributes to a path (or a pattern), or unset them (with the minus sign).  The text attribute is the attribute which tells that end-of-line normalization should be applied to a file. If you unset it, Git won’t mess with the line endings in the file and consider it binary.

More details can be found on the gitattributes man page.

My initial git settings for any repository

This is my cheat sheet for the settings I use for my git-repositories (list to be edited continuously):

Global settings:

git config –global user.name Martin Carpella
git config –global user.email xxx@yyy.invalid
git config –global color.ui auto

Per-repository settings:

git config core.autocrlf true
git config core.safecrlf true

Per-repository .gitignore for Visual Studio/C# projects:

bin
obj
*.user
*.suo
Thumbs.db

Missing dictionaries on OpenOffice.org 3

I just upgraded to OpenOffice.org 3 and I really like it. But there was a small, but very anoying problem: OO.org seemed to be unable to find any dictionaries. I found out rather quicky, that starting with OO.org 3 dictionaries are only available as extensions. Well, basically this is no problem, but the English (at least the US and GB variante) are supposed to be bundled with the installer and are not available as seperate extension.

It seems there is a little bug with the installation on Vista under certain circumstances which causes the extensions not being registered properly with OO.org.

To solve the problem, follow the same following steps:

  • Locate your OO.org “install” directory of your installation, usually it is C:\Program Files\OpenOffice.org 3\share\extensions\install” [Updated 2008-12-21 to include “extensions”, thanks to the anonymous commenter!]
  • Manuylla install the appropriate dictionary extension (“dict-en.oxt”, “dict-de.oxt”, “dict-fr.oxt”, “dict-it.oxt”) by either launching the oxt directly or by chosing Tools -> Extension Manager.

For me this worked after restarting OO.org totally (i.e. closing down all Writer, Calc, …).