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.

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.

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!

(picture unrelated)

So there was a workshop in Alacati, Turkey, which I attended.

Here are some impressions about this part of Turkey I would like to share with everybody.

Firstly, the people were very friendly. Not only in the hotel, also in the town. Definitely something very important, and a big plus! They really care about foreigners asking for the way to somewhere.

Secondly, no offence, but I do not like most of the Turkish food. I had the impression that in some strange way everything tastes sour or like bacon, even sweets. One exception were honeycombs, which were not exceptionally good but still very interesting, as you usually do not eat them in Germany. I guess this will be something I will look for in Turkish shops here in Germany. But otherwise, I mostly just ate the usual stuff from the hotel, rather than traditional Turkish food.

UMTS and EDGE seem to be available almost everywhere. Better than in Germany.

The hotel was big and did its best to look impressive. However, small things like not having soap or light in the public toilets for days, or not getting hot water out of the showers, made it less nice. A little less "impressiveness" and a little more attention to detail would be better I guess. Still, I have already been in worse hotels, and the only thing I really missed was that in my room there was no WiFi.

They even had regular busses to the town of Alacati. And the Hotel's beach had a surprisingly high amount of sand in its waste.

Which brings me to the main point: Waste. Waste waste waste. Everywhere. The landscape could be quite beautiful. But there is waste everywhere you look. I have been to the city of Alacati, and it is also full of waste. I felt like in a third world country. On the other hand, when entering shops, it was like entering another world: It was clean!

Neither did I have the impression that the people are too poor there, nor did I have the impression that they are stupid. I guess that there just has to be some common system that prevents people from producing so much waste. They obviously know how to keep rooms and streets and beaches clean. Just somehow, nobody does it outside of the hotels and shops.

So, my first suggestion here would be to provide public bins. They should not be too expensive, and I guess that if there are sufficiently many of them, a lot of the waste on the streets would just go away: the people usually want their town to be clean, they just do not want to put too much effort into it. Walking a few meters to the next bin lowers this effort. And of course, maintaining public bins costs, but also has a value! The other thing is to maybe introduce deposits: I had the impression that a large part of all the waste on the beaches and in the town were - besides cigarettes - bottles and tincans. That is also something that maybe some conservative people would dislike, but most people would probably even appreciate. It worked in other countries, why should it not work in Turkey.

I guess these two actions would already be sufficient to drastically change the situation. And they are realistic and not too expensive.

In addition to that, to save the landscape, organizing troups that collect the waste there, and then charging penalties for leaving waste in the landscape, would be a next step. Such troups can, for example, be recruited from prisons, as other countries do, in exchange for an earlier release. Also something that is possible.

I hope I did not offend anyone, as this was clearly not my intention. I just wanted to give some constructive criticism. I think the landscape and the city of Alacati could become quite beautiful. Unfortunately, currently, in my opinion ... they are not.

It seems that 3d printing and scanning is slowly approaching the mainstream. There are some nice gadgets which are affordable. Maybe soon, we can just print our dishes out of disposable material, or the missing wrench of the right size. Probably a good thing.

On the other hand, we might run into a pattern that is very common: There will be a lot of people refusing this kind of technology on the one hand, on the other hand there will be a lot of people who overestimate this technology and try to use it even for things it is not ready for.

It has been similar with digital photography: I can remember photographers complaining about digital photography and its bad quality in general - which was a good point, the first digital cameras were really bad. Same for digital sound and digital television. Everything takes its time.

There are still people who refuse to use digital cameras, or listen to music from digital sound media, because they think it has worse quality.

The same might happen with the availability of 3d printers and scanners. While as soon as some point is arrived, a lot of people might use them, at some point it might become clear that your home-printed pottery, pralines, keys, fleshlights and snifter valves just lack of quality. And then, 20 years later, when the technology finally produces the desirable results, people will refuse to use it.

Anyway, 3d printing will hopefully make our lifes easier and more comfortable someday. Let's just wait until it happens.

Was mich lange beschäftigt hat, und noch immer manchmal beschäftigt, ist der Unterschied zwischen "Mensch" und "Tier". Menschlichkeit ist für mich etwas, das uns diverse Vorteile bringt. Die Vorteile menschlicher Intelligenz sind weitgehend unbestreitbar. Nun soll Albert Einstein aber die menschliche Dummheit als unendlich bezeichnet haben, der selbst in den Medien als einer der schlausten Menschen gehandhabt wird. Wie ist dies also vereinbar?

Man meint in beiden Zusammenhängen wohl üblicherweise etwas anderes: Dass der Mensch unter den Tieren dasjenige ist, das die größte abstrakte Intelligenz hat, und Fähigkeiten besitzt, die ihm einen schier unerreichbaren evolutorischen Vorteil gaben, ist kaum zu bestreiten, aber abstrakte Intelligenz ist nicht alles: Erfahrungen und Empathie sind wohl eher das, worauf Einstein anspielen wollte. In gewisser Weise macht uns unsere abstrakte Intelligenz erst "dumm" in diesem Zusammenhang: Obwohl wir die Fähigkeit haben, über uns selbst zu reflektieren, und gewisse Fehler nicht, oder zumindest nicht so häufig, begehen müssten, tun wir es im Kollektiv immer und immer wieder.

Hier drängt sich mir dann regelmäßig die Frage auf, inwieweit ein Mensch, der die ihm gegebenen Fähigkeiten nicht nutzt, und billigend in Kauf nimmt oder sich aktiv daran beteiligt dass man anderen Lebewesen erhebliches Leid zufügt, überhaupt einen moralisch höheren Wert hat, als eine Katze, die ihre Beute quält, weil es in ihrer Natur liegt, dies zu tun, und weil sie eben nicht diese Fähigkeit hat. Ist diese Katze nicht sogesehen moralisch mindestens gleichwertig, da sie immerhin wenigstens keine Fähigkeit die sie hätte unbenutzt lässt?

Diese Frage kam mir, als ich diesen Artikel über die Behandlung von Asylanten in der Schweiz las - beziehungsweise genaugenommen einen Kommentar darunter:

Die Schweiz ist den restlichen Europäern (...) voraus (...). Wo andere noch immer von Multikulti träumen und von Integration fabulieren, handelt die Schweiz konsequent in die einzig zukunftssichernde Richtung.

Die einzig zukunftssichere Richtung ist es also, Flüchtlinge zu internieren, und dann zu neun Zehnteln wieder zurückzuschicken? Liebe Schweiz, dann nehmt doch einfach garniemanden auf, dann machen wir uns wenigstens keine Illusionen. Aber um diesen konkreten Fall geht es mir garnicht, es gibt sicher genug Deutsche, und auch Sonstige, die diese Haltung teilen.

Es geht eigentlich immer um dasselbe. Zunächst will man die Gastarbeiterfamilien, die man sich vor ein paar Jahrzehnten ins Land geholt hat, wieder loswerden, jetzt, wo sie ihren Zweck erfüllt haben. Und dann will man keine Flüchtlinge aufnehmen, und ihnen nicht helfen. Schön ist auch ein weiterer Kommentar, in dem es darum geht, was denn der Unterschied dazu sei, Juden den Zugang zu öffentlichen Einrichtungen zu verbieten, wie man es früher tat:

Ganz einfach, die Juden der 20/30er Jahre waren bestens integriert, überdurchschnittlich gebildet und vermögend und haben finanziell zum gesellschaftlichen Gemeinwohl beigetragen.

Achso. Der Fehler der Nazis war also nicht, dass sie sonstiges Gewürm ausgegrenzt haben, sondern ausgerechnet Juden, die man doch besser als Leistungsträger hätte einsetzen sollen. Gut zu wissen.

Ich wende mich indes lieber wieder meinen Katzen zu.

The following was a nightly rant about ... well, Lisp and everything. Not to be taken too seriously, but hopefully giving some opportunities for discussions.

It started by my comment about my opinion on opinions, "I'll just wait until mine becomes trendy again ... because that is likely to happen someday." When my dialog partner answered "That sounds like a pep talk for Lispers", this is what I wrote:

Well, the bad habits of Lisp have spread. The good things are also slowly spreading. I have not heard the phrase in that context yet, though. The usual ideal is the "Smug Lisp Weenie". Well, many Lispers will argue that there is Clojure, and also Scheme is actively developed, even though mainly in incarnations like Racket. To me, Clojure is shit, and Scheme is rather a toy. Of course, Perl, Python, PHP and C++ are also toys to me. Anyway, this is probably already too deep. From a more superficial point of view, many people are just like "we are still up to date", arguing with the plenty of libraries that can be found on the Cliki or in QuickLisp. Today's Lisp suffers from the same disease as all software these days: Today's Lisp is most likely Clojure, especially since a lot of pseudo-companies are funding it. And it is just like modern software has to be: It runs on the JVM, but - of course - only on two implementations, if you want it stable. There is a Dalvik-port, but it is commercial. There is an LLVM-port, also commercial. Furthermore, most of the code is write-only. And it is purely functional ... except that that does not really work if you want to be compatible with Java ... very important for modern software: the components MUST NOT fit together semantically. And the most important point: It is in a permanent beta-state. There are releases, but they are virtually meaningless. You see: Lisp is totally up to date. Ah, one further point: Ignore all knowledge and expierience that has been made so far, and try to rebuild everything, with a huge mouthful of the inner platform effect. Or, in the spirit of the wise Pandaschnitzel: Lisp is not good. That is why it is not widespread.

These days the free software community has a lot of problems, for example, the problem of commercial social networking platforms that want to have their own closed protocols and make money with the users' data. Yes, I consider this a problem.

However, in the first half of the 00s, we had other problems: WiFi was new, and a lot of hardware existed that had no Linux driver. In those days, struggling around with ndiswrapper was usual. Especially, I can remember that Broadcom refused to support open source drivers. Meanwhile, they changed their policy, and Broadcom-Chips have become fairly well-supported under Linux.

Well, recently I bought a cheap old Laptop. I noticed that the WiFi-Card did not work under Linux. So I watched it up: It is an Inprocomm Ipn2220, and the recommended installation procedure is still ndiswrapper. As far as I see, it was built at a time when it was not normal yet that every WiFi-Card has a Linux driver. And the company was bought up before this, so nobody cared, as the chipset was not supported anymore. Well, I will probably just buy a small USB-Stick.

However, it is nice to see that while we have a lot of new problems, some of the old problems are gone: A WiFi card without a Linux driver - that sounds unbelievable nowadays!