External Content not shown. Further Information. I use instant messaging a lot, since many years, and had a lot of different software running, with its own genuine problems and advantages.

In the beginning, it was the time when ICQ became popular, and I used the official ICQ client under Windows 98. It made typewriter sounds on every character that one typed. It was the first software I can remember that did not exit on close, but minimized to tray by default.

However, it had a lot of eyecandy, and needed a lot of my 64 MB RAM, and crashed often. So, at some point, I switched to Miranda IM, which was much better. At that time I got to know IRC, and joined a few IRC channels through Miranda IM. I only had a dial-up connection, which probably had some package loss and a high latency, so it was often the case that Miranda IM warned me that some message could not be sent. When "retrying" to send the message, it sometimes arrived multiple times.

At some point I switched to Linux. At that time, it was not as easy as today to get a working ICQ Client under Linux. So in the beginning, I used ICQ2GO which is now called Web-ICQ. Nowadays, it uses JavaScript. But at that time, it used a Java Applet - which also swallowed a lot of RAM and did not have the Quality under Linux that it has today, and also crashed often. This became even worse when they ported it to Macromedia Flash, which really was a pain at that time (it still is a pain sometimes).

I do not know exactly in what order I used which clients after that. For a long time, I used SIM, but for some reason I did not keep using it, not sure why, probably there was a lack of compatibility with a linux distro I wanted to use (since other software sucks too).

Kopete used to be the standard messenger under KDE, and I liked it, but at that time, it had one problem: Others received my messages, but sometimes, their messages did not arrive. I still have no idea why, and I am not really interested, but they apparently fixed it. Then there was GAIM, which was later renamed into Pidgin. It has a lot of flaws, but sort of works. Furthermore, at that time I started using Jabber, and sooner or later arrived at Psi, which is a pure XMPP client, but supports transports. But the transports … sucked.

At some point, I discovered BitlBee. And used it with Irssi. From that point, I mostly used either Pidgin or BitlBee. When I started studying, it was the first time when I really had the problem of syncing many computers. Mostly I used Pidgin on every computer, and synced the directories - this was not perfect, but sufficient.

And there we almost come to the current setup: A central server with a tmux session. I tried Centericq and Finch, but they did not convince me, so I preferred BitlBee and Irssi. Though, I missed notifications via libnotify, which are sent by some other clients.

We are now approaching the part where I try to "fix" software problems myself. Of course, Irssi is scriptable, and there is a setting to let it execute a command when receiving messages. But instead, I wanted a more general solution for other purposes. So I thought it might be possible to tell some terminal emulator to execute a command, when a BEL character arrives. Apparently, such a terminal emulator does not exist, so I experimented with terminal stuff myself. I found the forkpty(3) function, and I am able to write such a piece of software now, but I lost interest.

In the meantime, I began using mobile internet, which … sucks in some places, so it happens that connections get lost. Directly using Pidgin and other clients, message loss occurs, but running BitlBee on a server with a good connection works well, and thanks to the tmux session, I can always reconnect a broken ssh connection. But as reconnecting gets on my nerves, I switched to mosh. So until I got a smartphone, my instant messenger software stack consisted of bitlbee behind irssi behind tmux behind mosh. Yes, that sounds complicated, but one fundamental principle of Unix is todo one thing and do it right, and every part of this software stack does its job pretty well - at least on personal computers.

On my small smartphone, it is a pain to use terminal applications. There is the Hacker's Keyboard, which I use, but which does not show the relevant keys in portrait mode, and makes the terminal half as big while typing, even in its experimental transparent mode. There is an app called Transparent Keyboard, which really is a transparent overlay keyboard, but the keys are too small on my screen, so this is not an option for me. Both keyboards are probably very useful on large displays, but on my display, this is unusable.

In my opinion, terminal applications have a completely different UI model than most other apps on Android. They usually focus on the keyboard, while smartphone UIs focus on the touchpad. So it is legit not to use the system's input method, but having an own one. I would suggest a semi-transparent overlay keyboard over the whole terminal: Most terminal applications do not support mouse input, so there is never a reason to actually touch the terminal window itself. On the other hand, relevant information is shown in most of the text window, so it is desirable that this text window uses most of the screen. So I guess this is reasonable.

So recently, I am using Quassel. It has several advantages over IRC bouncers like bip, and fits my needs comparably good. But it also has some problems. One thing is that currently, the Android client does not do compression. A workaround that works fine for me so far is to turn off SSL encryption in Quassel, and tunnel the traffic through a compressing ssh connection, which I generate with ConnectBot. ConnectBot is also not completely flawless: In some configuration it always needed huge amounts of processing power, thus lowering my battery, which is why I do not touch the current settings at all. And well, it hangs up occasionally, and sometimes Quassel refuses to connect to the forwarded port for no apparent reason. And it still takes ages to connect, even though I set the backlog length to 1 already. Quassel seems to always send, besides its whole core configuration, all messages that arrive in all channels you joined. However, on a mobile internet connection, I want traffic to be reduced as much as possible. It would be nice if only state changes ("highlighted", "unread messages", etc.) of channels in which I only idle around were sent, and the messages are only loaded on demand. The usual behaviour of IRC chatters is to idle in a lot of channels and only occasionally look into them.

Besides that, I recently began to join some XMPP Groupchats, which does not really work properly in BitlBee, at least in my version. It has problems with unicode nicknames, and does not restore these chats after I log out of a session. However, I have workarounds for this, and on the whole, BitlBee works well for me. But it is still an IRC gateway to different chat systems, which inherently comes with some compatibility problems, one of them being the fact that IRC messages cannot contain line breaks, while most IM protocols allow this. Especially when pasting text, the other side gets the text chunked into its lines, and this is really annoying. The solution it provides is the paste_buffer and paste_buffer_delay setting, in which you can set a time in Milliseconds that indicates when two consecutive IRC messages are packed into one single IM message. So when you paste a long text into your IRC client, and it sends them sufficiently fast, this is a good approximation … except that Quassel will not let you send pasted text reasonably fast, due to a "feature" called "flood control", which apparently cannot be turned off. This is a desirable feature on public networks and channels, in the sense that it protects you from accidentally flooding. Well, it does not really protect you, it apparently just delays the messages a bit, which is - in my opinion - even worse than just sending them directly. It forces without warning. Irssi asks you for an affirmation when it notices that a lot of messages are typed in at once, if I remember correctly, one has to confirm with Ctrl-D. It warns without forcing. That is an important rule, I shall call it Uxul's 5th rule:

Good software warns without forcing. Bad software forces without warning.

However, both pieces of software have their unique advantages and disadvantages.

In the end, one question remains: What to do about it? While my current setup works fine for the moment, it is not satisfactory on the long term. So let me discuss a few alternatives I or other people came up with:

Buy a new phone

I will probably buy a new phone with a larger display sooner or later, and thus solve some of the problems. But I do not consider solutions of the form "throw hardware on your problems" as good. I am pretty sure that I will run into other software problems with a new phone.

Irssi ConnectBot

There is a fork of ConnectBot, called Irssi ConnectBot, which I would probably use on the aforementioned hypothetical new phone. However, it makes use of input buttons my phone does not have, and it uses swiping, and I hate swiping and gestures in general, because they often fail when you have stubby fingers. Furthermore, it confuses my configuration of ConnectBot, when installed parallely.

Writing or patching an existing terminal emulator…

…in the way I described above might be worthwile even for other applications, but both getting an own implementation stable and understanding another implementation are a pain and take long. This is probably a nice project for it own sake, but not for this specific problem.

Irssi-Proxy with bouncer

There is an Irssi extension called irssi-proxy, where Irssi exposes its connections, so a second client can access them. Then I could just run a bouncer on these exposed connections so I get the backlog. However,

Writing an own new IRC Client

Years ago I programmed an IRC Bot with Java, using TCP sockets, but implementing the IRC protocol myself. It is a comparably simple protocol. A suspendable web-based client would be perfect, as it could be made accessible on both PCs and phones with little effort. I considered using Common Lisp, Hunchentoot and cl-irc, and producing a simple web-based client should be very easy. On the other hand, it would produce one more piece of software that is poorly maintained and has its own unique flaws, without really adding any value. The better alternative would be …

Writing a Web-Frontend for Quassel

The advantage of Quassel is that it already has a lot of infrastructure for distribution of configuration settings and their meanings. And once running, there might be enough interest to keep such a project alive, even in times when I can not actively do so.

Writing a Web-Frontend for Irssi

Irssi is scriptable. There already exists a frontend for it, but it looks anachronitic (the link for the current development seems to be dead). However, the Irssi-API looks nice, signal-based, sufficiently nice to make such a project possible.

Writing a purple-based Web-Client

…and probably failing like the many people before. But it might be worthwile for its own sake, as an exercise to learn libpurple, and knowing an advanced multi-protocol chat library might be an advantage in many ways. There is this nice introduction to libpurple. Of course, I am not the first one with that idea, there is at least WebPidginZ which I did not try yet due to the lack of time. Furthermore, there is the Broadway Backend for GTK, so maybe Pidgin will run on it.

Just wait and use workarounds until somebody else does the work

This is the most probable thing I will do. And probably also the most probable thing most other people do. And therefore, probably the reason for all of that mess.

External Content not shown. Further Information.

Deutsch:

• Diejenigen, die gestern gegen Kernenergie, heute gegen Stuttgart21 demonstrieren, agitieren, die muessen sich dann auch nicht wundern, wenn sie uebermorgen irgendwann ein Minarett im Garten stehen haben, Meine Damen und Herren! - wtf?
• Bildung in der Elitefalle
• Die erste Mobilmachung der Wissenschaft
• Virtuelles Mädchen entlarvt 1.000 Pädophile - wenn sie die Technik haben, ein Mädchen virtuell darzustellen, warum nutzt man die Technik dann nicht lieber um Pädophilen eine Alternative zu geben, dass sie garnicht erst nach echten Menschen suchen, anstatt so eine Hexenjagd zu veranstalten?
• Mini-Leber aus 3D-Drucker überlebt und arbeitet 40 Tage lang
• High-Tech-Löffel für Menschen mit neurologischer Erkrankung
• Bangladesch hat offiziell ein drittes Geschlecht annerkannt
• Wie man sich 1900 die Zukunft vorstellte - das meiste davon ist zumindest so ähnlich eingetreten.
• Putin träumt von "eiserner Seidenstraße" die auch durch Nordkorea gehen soll- wohl, damit er die nordkoreanischen Sklaven besser nach Sibirien bringen kann.

English:

• Apple Invades New Holocaust Film with Jarring iMac Product Placement (via) o/ ⌘

Mathematics and (Computer) Science:

• Screaming carrier - lolwut?
• Nordkorea nutzt Free-to-Play-Games für DDoS-Attacken - wenn dabei gute Spiele entstehen, meinetwegen.
• The Apple IIe Becomes a Lisp Machine
• Use Your Smartphone as a Microscope for Less Than $10 - we definitely are a science fiction society.
• DIY LED light bulb (via) - why not.
• A Simple Block Driver for Linux Kernel 2.6.31

Comics/Images/Videos:

• Palestinian vs. American Child
• Klingon Rickroll - great! Also: Klingon Style
• I want this bike. Well, maybe with these wheels instead. (Seriously, if you know where to get one, please tell me!)
• 3 Weeks After Halloween
• Simple Answers
• It’s Getting Harder to Impress People
• Suffocation
• In France during the 17th and 18th centuries the name "Firefox" would apparently cause different associations than today.
• Nice Picture of Bowser
• Jackass
• American Politics Explained
• Motivation
• Away From Gay
• Clever Dragon Slayer of Wawel
• Welt ist Grausam

Quotes:

• I laughed so hard ...

External Content not shown. Further Information.

Deutsch:

• Streit um "Spongebob"-Grabsteine
• "Vater des Döners" ist tot
• Erdbeben zerstört Riesen-Gummiente
• Jäger verwechselt Islandpony mit Wildschwein - warum darf man überhaupt noch wilde Tiere schießen?
• McDonalds erwägt 3D-Drucker in Filialen einzurichten - allerdings nur für Spielzeug, nicht fürs Essen.
• Pistole aus 3D-Drucker feuert erfolgreich 50 Schuss ab - ich sehe allerdings nicht wirklich, warum das jetzt so viel schlimmer ist, als eine CNC-Fräse.
• Neuer Ekel-Trend: Tierbabys am Schlüsselbund
• Kernaussagen
• Kampagne "Draußen" (via)
• Unbekannte überkleben Verkehrsschild und einige Autofahrer gehen daraufhin in die Radarfalle. Wtf?

English:

• Josephene Myrtle Corbin, the Four-Legged Woman
• 3D-Print Your Own 20-Million-Year-Old Fossils
• Grashopper with gears
• Dad Calls Cops on Son to Teach Him a Lesson, Cops Shoot Son Dead
• GUI Gallery (via)

Mathematics and Computer Science:

• ANSI C Yacc grammar from 1985
• Preprocessor magic:Default Arguments in C
• Cyclone is a safe dialect of C (via) - yet another one.
• Introduction to GNU epsilon
• Lisp for C++ programmers
• Südkorea: Internet Explorer ist gesetzliche Pflicht - "Besonders für Apple-Kunden gestaltet sich ein Online-Einkauf sehr umständlich." - na wenigstens eine gute Seite hat das Ganze.

Comics/Images/Videos:

• The Paradox Axe
• I don't like thing
• Crazy Morphing Table Surface
• Zoo Breeding Program
• On Achievement
• Mewwy Chwistmas
• Squint
• Dead Pixel (original)
• Facial Recognition Creates The Greatest Student ID Ever
• Invention
• Freestyle Finger Snapping (via)
• Good Ol' Days
• NSFW Tricycle
• NSFW: Theater

Quotes:

• Raising a child ...
• Depression is like trying to peel a potato ...
• McDonald's does actually serve breakfast after 10:30 if you bring a gun.
• Before you judge a man, walk a mile in his shoes...
• If Internet Explorer is brave enough to ask you ...
• Wenn dein Handy nass wird...
• NSFW ... when it rains

External Content not shown. Further Information.

A common pattern in discussions on programming languages is that somebody asks why there is no language that has $feature. And then I answer that there is one. And people who know me already know the most probable answer: Common Lisp.

One notable example comes from Fefe's Blog (German), who ignored my answer (maybe he did not read it or find it interesting).

So his question was whether it was possible to extend some programming language such that the argument that a string argument which is passed is actually constant, and not generated at runtime, such that people cannot generate SQL strings on the fly but must use an abstraction library. His example of the desired behaviour:

int SQL_statement(constexpr string& s);

SQL_statement("select * from table"); // ok
SQL_statement("select * from table where name='" + userinput + "'"); // compiler error

So here is the Common Lisp code I proposed:

(defun sql-statement-unsafe (str)
  "Unsafe function. In a production environment, this would not be
  exported from the namespace. In our case, it just outputs the string."
  (format t "~A" str))

(defmacro sql-statement (str)
    (assert (constantp str))
    `(sql-statement-unsafe ,str))

(sql-statement (format nil "~d" (random))) ; compile-time error
(sql-statement "hallo") ; no error

Well, furthermore, gcc has an extension __builtin_constant_p. And I guess the same can be done with C++11 static assertions meanwhile, but not sure, how.

External Content not shown. Further Information.

Deutsch:

• Gericht verbietet Telekom-Drosselung im Festnetz - wenn sie es Flatrate nennen, dann sollen sie auch eine Flatrate anbieten!
• Offener E-Book-Reader mit Android - wurde auch Zeit, ich verstehe ohnehin nicht, warum diese ganzen Hardwarefirmen sich so sehr an Softwarehersteller binden, statt einfach die Gerätespezifikationen offenzulegen.
• Steinmeier behält Doktortitel - sowas gibts also auch. Steinmeier zum Wissenschaftsrat!

English:

• Microsoft to can Skype API, third party products will not work - fortunately, with WebRTC, there will soon be enough alternatives.
• Why Lisp macros are cool, a Perl perspective (via)
• Tracing Malloc
• What is Truth?
• Gitosis for Mercurial
• Hg Git
• Is Perl syntax better than randomly chosen syntax?
• How to get C like performance in Java (via)
• Falsehoods programmers believe about time (via) - if it contains numbers, we can f**k it up.

Comics/Images/Videos:

• Alicia Keys Sings "Gummi Bears" Theme Song (via) - wo bleibt die Version von Bushido?
• NVIDIA Kepler real-time raytracing demo at GTC 2012 (via) - beeindruckend.
• If Arithmetic Were Debated Like Religion
• Armed Gunman
• Dictators
• Coke Strikes Back
• NSFW: This Is How They Do Fireworks In Glasgow

Quotes:

• what does your robot do, sam?
• The average human body
• If you de over the age of 90
• My dad and I have the best father/daughter relations

As I did a lot of work with thin clients in my previous job, I am still interested in remote-controlling computers. In my opinion, thin clients are a nice thing in theory, because it should be easier to bundle all the computing power in a central server cluster than in many heavy computers, but on the other hand, when I see the Raspberry Pi and the plenty of pretty small and energy-saving desktop computers, I do not think that thin clients will have a bright future anymore.

On the other hand, one may want to provide one's workers or students a way to log into their accounts from outside, and use some graphical applications. Or one does not have a license or simply does not want to run some proprietary software on all users' computers. Or one just wants to assist somebody else configuring his computer.

There are plenty of protocols. Sufficiently expensive versions of Windows come with an integrated RDP server, Max OS X comes (or at least came when I used it) with an integrated VNC server, and some proprietary Apple Talk stuff, if I remember correctly. Linux has X11. The oldest of these protocols. With its twenty years of experience, it is the king of them!

As if! Under Windows, I could run multiple sessions at once. Lock them locally, so nobody can access it on the screen, and reattach them remotely, and vice versa, seamlessly. With X.org, I have not found a possibility to do so yet. The problem is that xscreensaver is an X client itself. I always hoped that using chvt(1) to remotely switch to another tty and grab the keyboard there to forbit using Ctrl-Alt-F7 to switch back, until the password is entered, would be a solution, but I never found the time to actually configure this. And I guess that with the rise of Wayland, at least at the moment it is not really worthwile investing time in X11 for a setup that might be obsolete soon.

However, X-Forwarding through SSH is too slow. So here are some personal notes on how to run a vnc server under Ubuntu, to remotely start sessions. Please do not copypaste them, read the documentation and think about what you do before doing it. These are personal notes I share with the world in the hope that it will make it easier for them to use these tools.

Firstly, make sure that the packages x11vnc, xdm and xvfb are installed - besides, of course, your usual desktop environment. Also, tmux or screen is useful for remote configuration. You will be asked whether xdm should become the default display manager during the installation, be careful not to accidentally change the setting you had before.

For me, xdm is not the default display manager, and I want to keep it that way for now. If xdm is your default display manager, adapt the following steps appropriately!

The file /etc/X11/xdm/Xservers configures which X-Servers are started automatically by xdm. I commented out the default line containing ":0", as my default display manager already uses this display - if you are running xdm as default display manager, you probably want to leave it there.

I added the following line:

:1 local /usr/bin/Xvfb :1 +extension DPMS +extension DAMAGE +extension MIT-SHM -extension RANDR +extension XTEST -nolisten tcp -screen 0 1000x700x24

I deactivated the RANDR extension, as x11vnc cannot handle it properly. I set the screen size to 1000x700, as this fits to my laptop screen, and 24 bit colors, as I get strange errors with some parts of texts "blackened out" for the default 8 bit depth, and Xvfb refuses to use 32 bit depth. The DAMAGE extension seems to be useful, at least according to x11vnc(1). And XTEST is something one just wants to have.

Now the problem is that the initscript will not start xdm, if it is not the default window manager. However, as I mainly use this for accessing my own computer remotely, I have root access, and I prefer not to overcomplicate things and start it manually in a tmux session whenever I need it. So I run

# xdm -nodaemon

to keep it in the foreground. If everything works, now one can start x11vnc. Firstly, we need to know xdm's auth file.

# ls /var/lib/xdm/authdir/authfiles/

should reveal its name, for me, this time it is /var/lib/xdm/authdir/authfiles/A\:1-oWmG8O. VNC itself does have some encryption methods, but still the easiest way to encrypt the traffic is probably an SSH tunnel, and many VNC viewers natively support SSH tunneling. We will therefore use the -localhost option, and tunnel the traffic. I furthermore set the port to 5901, because I prefer this. However, if multiple users have accounts on your machine, you should use password authentification. I often use pwgen to generate random passwords. For this time, my password is xPexeG2b0JeYTC1ZvzSh (I usually use one-time-passwords and generate them every time, and just copypaste them). x11vnc can read password files, so we just create one and set the apropriate rights using

# echo "xPexeG2b0JeYTC1ZvzSh" > mypwd
# chmod 0400 mypwd

Now I can start x11vnc:

# x11vnc -passwdfile mypwd -localhost -rfbport 5901 -ncache 20 -flashcmap -display :1 -auth /var/lib/xdm/authdir/authfiles/A\:1-oWmG8O

The -ncache option makes x11vnc use a larger virtual frame buffer inside the vnc viewer, as an image cache. If this gets on your nerves, you can deactivate it.

Now using the -L localhost:5901:localhost:5901 option for ssh, we can tunnel our connection, and access it on the client with our favourite vnc viewer, which ever that is. I have no clear favourite, but currently I mostly use TightVNC. The problem is that this viewer (and maybe other viewers?) recognizes the local connection and optimizes for quality rather than bandwidth. To prevent this, one can do

$ xtightvncviewer localhost:1 -encodings "copyrect tight hextile zlib corre rre raw"

The number :1 must be replaced by your rfb-port minus 5900. If I find the time, I will maybe try to write some code to automate the process of starting and connecting.

As always, suggestions on alternatives and simplifications are appreciated!