Panel 1: A fire creature in a knight's armor is sitting in a train, with his feet, also covered in armor, put on the opposite seat. From outside the scene somebody sais "your tickets please!" -- Panel 2: A ticket inspector appears and sais "what the hell" -- Panel 3: The inspector points on the fire creature's legs and sais "No shoes on the seats please" the fire creature answers "But…" -- Panel 4: The inspector sais "Shoes off or feet on the floor!". The fire creature puts its feet on the floor and sais "As you wish." -- Panel 5: The fire creature took its shoes off, its feet consist of fire. The fire inflames the opposite seat, which burns and smokes.

External Content not shown. Further Information. Hotels, hostels and cafés often have public wifi hotspots which require a log in that is given to guests. The usual behavior then often is that the first website that one tries to open is being redirected to some login page. Mostly, this login page requires javascript, cookies and all the other shitty stuff. And often, these wifi connections are unencrypted.

Many websites, apps and other stuff one has to use have the default behavior to automatically reconnect to some host if they are disconnected. They can easily get confused, depending on the redirection mechanism which is used. Sometimes you are explicitly redirected through a HTTP proxy - that is, you at least get an explicit HTTP redirection header. Sometimes they just use a transparent proxy, so it appears as if the requested IP address would answer. Sometimes it just answers the first DNS query with a wrong IP, which in turn can confuse nscd(8).

Except for advertisement (which I really cannot stand anyway – if I pay for a hotel, then I want to have wifi included, without additional ads), the only reason for doing this that I can think of is to identify people for legal reasons. But then, please just let everyone sign a contract on paper, and just use wpa2-psk. This is a solved problem. The configuration is easy, and it works.

If you really want to send messages to the user, at least write on your tickets which website they have to visit in advance, and reject all other connections beforehand. Yes, this might sound a little less user-friendly at first sight. But visiting a website is something every internet user should know anyway, while leaving apps and programs in an indefinite state can really mess systems up.

External Content not shown. Further Information.

Popular Culture:

Nerd Culture:

Science, Software, Hardware:

Zeroth World:

Comics/Images/Audios/Videos/Games:

Quotes:

External Content not shown. Further Information. With all the new social networks, Jabber is getting less and less popular, and it has gotten a lot harder to convince even people with computer experience to get an Jabber account and be online on it.

In fact, there are some problems with the XMPP protocol.

Probably the worst one is the fact that I haven't seen any server that correctly handles multiple clients, and doesn't lose messages when used on a mobile phone. My server has tcp keepalives activated and pings in regular intervals – which increases the traffic but also makes it sigificantly less probable to lose messages on connection loss. There are proposed solutions to this, which will hopefully be more widespread some time in the future; for now, this problem exists.

Another severe problem came up when Google dropped its XMPP federation support. I still don't quite understand why they did so, but keep this in mind: A Google account ist not a full Jabber account anymore!

Yet another argument I often hear is that Jabber is not widespread. "None of my friends use it." – well, then convince them to use it. Be the first to have an account and spread it.

It's not like it costs anything or is complicated. It's not hard to have a jabber account and be online from time to time even though you don't use it much. If you worry about the system resources and the traffic, I can assure you that your Facebook- and Whatsapp- and Whatnot-apps are probably worse.

It is not even about destroying Facebook, Microsoft, Google, etc. – it is about limiting their power. It is about having a fallback solution when they decide to become evil – so they have a pressure not to become evil.

It's your little part for the freedom of the internet, for your freedom. Is that really too much?

Popular Culture:

Nerd Culture:

Science, Software, Hardware:

Zeroth World:

Comics/Images/Audios/Videos/Games:

Quotes:

All panels show a person sitting at a bus stop, having an internal monologue. Panel 1: "Hm... The bus is delayed." -- Panel 2: "I have read that some old people's homes have fake bus stops..." -- Panel 3: "...so the demented people who wander around sit down and wait for the bus, until a nurse brings them back." -- Panel 4: "Apparently, they really believe that they are waiting for the bus." -- Panel 5: "Just like me." -- Panel 6: "Oh my god, what if I was one of them? What if this was just a clear moment, but all of my memories are of a distant past?" -- Panel 7: "And I am only remembering this situation while in real I am an old person who just wanders around cluelessly until the nurse puts me back into my place?" -- Panel 8: "How can I be sure?"


(Source: Gifbin)

As for most computer scientists, I always think about the features I would include into a programming language. Though I will probably never actually implement one (it is a lot of work, and there are plenty of languages already there), thinking about it can lead to interesting questions and insights. One such insight is that any practical language should have an exception system – which, however, should only be used in actually exceptional situations.

Why exceptions at all?

In theory, everything is embeddable in an Exception monad (or a sum type). But some exceptions can always happen, for example OOM. Or a system signal.

There are lots of algorithms that only work when everything goes right. A parser that returns a cototal AST, which is consumed lazily by an algorithm, for example. (Update: Seems like for such cases, Iteratees are better-suited.)

Verification of such algorithms can be tedious when one always has to cope with the possibility of failure. Abstracting very uncommon failures away into exceptions should be possible in a type-safe way. However, of course, they bloat the type system. Therefore, an Exception-system should mainly contain the possibility to safely unroll the call-stack and return the program into a safe and well-defined state.

For example, Lisp's way of communicating across the borders of stack frames and defining restarts is elegant and well-suited for rapid prototyping, but too general for formal verification. Such constructs should only be used with sophisticated monads, or given as parameters, but do not really fit into strictly typed languages, I think.

Criteria for exceptions

Exceptions should only be thrown in exceptional situations. I worked out the following three three criteria:

  1. The problem must be something unlikely that usually does not happen.

  2. Not unrolling and aborting would leave the program in an indefinite state.

  3. The program cannot really do anything about it, or at least doing anything about it is not in the domain of the current subroutine.

Examples

These are not sharp criteria. There are many cases where it is debatable. In the end, they are more guidelines for API design. I came up with these when thinking about several examples:

  • The filesystem gets out of memory: While writing a file, that is something unlikely. One should close and maybe delete the file afterwards. The program cannot do anything about it, since this is something the system has to cope with. However, when using fallocate(2), returning an error is a well-defined behavior, and should not result in an exception.

  • The program runs out of memory: Also something unlikely with sophisticated memory management. However, this exception may be thrown by custom allocators, but not by explicit calls to malloc(3) and the like. Because malloc(3) returning NULL is well-defined behavior. If your custom allocator cannot allocate, then it may throw an exception. malloc(3) itself or similar raw abstractions over it should not.

  • End-of-File while reading: Files are usually finite. This is nothing unexpected. It can, of course, be unexpected when parsing something. But then, this is a parser exception, not an exception about the EOF itself.

If you have any opinion about it, feel free to let me know.

Snail sitting on a Grape.

Meh. So much work. From now on, I will try to have comics every two weeks. This sounds more realistic.

Popular Culture:

Nerd Culture:

Science, Software, Hardware:

Zeroth World:

Comics/Images/Audios/Videos/Games:

Popular Culture:

Nerd Culture:

Science, Software, Hardware:

Zeroth World:

Comics/Images/Audios/Videos/Games:

Quotes: