2013-08-11
The feature (or features) I really want added to xterm
I recently mentioned that there were
only a few features that could attract me away from xterm. Since a
commentator asked about them, today I'm going to try to talk about them.
The big feature that I would like is for widening and narrowing the terminal window to properly reflow text. In other words, if I have lines that wrapped around and I widen the terminal window I want the lines to no longer wrap around. Today if you do that you just get a big blank space on the right. Similarly if I narrow a window I don't want the lines truncated, I want them re-wrapped.
(Mac OS X terminal windows do this. I have envied them that ever since I saw it in action many years ago.)
There are technical limitations and caveats about this but it's perfectly possible to do it in many common situations (ones where the output has been simply printed to the screen instead of placed with cursor addressing). Xterm actually goes part of the way to this today in that its line selection for copy-and-paste sometimes recognizes that a logical line spans more than the physical on-screen line.
The other interesting feature is signposted by gnome-terminal doing a much more restricted version of it: g-t will recognize URLs, underline them if you hover the mouse over them, and then give you a context sensitive popup menu that lets you do things with them. I would like a generalized version of this where you can provide something like regular expressions to match and context menu entries to add for each match.
There are probably more exotic things you could add to a terminal emulator if you wanted to; for instance, there's no reason why a terminal emulator couldn't directly render pictures if asked to. I can't say I actively want such features, though, partly because I'm not sure that we have a good idea of how to use them in a Unix command line environment.
(Also, I'm not interested in giving up what I consider xterm's core features for me. Trying to list those is something for another entry.)
PS: it's likely that there are other features that would pull me away
from xterm that I just haven't had the vision to imagine. I try to
always remember that the really great features tend to be the ones that
you didn't even realize that you wanted before you heard about them.
2013-08-04
What's changed in Unix networking in the last decade or so
In an earlier entry I mentioned in passing that a number of things had changed in Unix networking since the classic Stevens work was written. Today I feel like trying to inventory at least some of them:
- IPv6 is growing in importance. If you care about this (and you should)
there is a whole exciting world of issues with dual binding, detecting when the machine has useful
IPv6, and so on.
Note that real IPv6 support may require examining hidden assumptions in your code.
- along with IPv6 has come a number of new interfaces that are now the
correct way of doing things, such as
getaddrinfo(). There are some subtleties here that deserve to be carefully covered in any good modern networking book. - people now care about handling a lot of connections at once in an
efficient manner. This has created both new interfaces (such as
poll()andepoll()) and new asynchronous server approaches. - similarly, threading has become a big issue and there are a bunch
of issues surrounding good file descriptor handling in the face
of threading. Overly simple code can have any number of inobvious
races where your code winds up manipulating something other than
it expected because other threads have created and destroyed file
descriptors behind your back.
- practical protocol design now requires considering how your new
thing will interact with firewalls, which have become ubiquitous
in the past decade.
- TCP congestion control and window management algorithms have evolved over the past decade in ways that affect TCP performance in real world situations.
- there is a whole area of protocol performance on the modern Internet,
where you care about things like DNS lookups, keeping the sizes
of things down so that you can fit them in one packet, and so on.
My impression is that most of this is new in the past decade.
- at least Linux has added support for doing various interesting things over local Unix domain sockets.
Although it's not quite within the scope of a work on basic (Unix) socket network coding, I think that any new book on this should at least say 'do not attempt to design your own cryptographically secure communication protocol'. Some discussion of SSL/TLS may be in order since it's become so pervasive.