Wandering Thoughts archives

2017-01-30

Why having CR LF as your line ending is a mistake

In my entry on what we still use ASCII CR for today, I mentioned in passing that it was unfortunate that protocols like HTTP had continued to specify that their line ending was CR LF instead of plain LF, and called it a mistake. Aneurin Price disagreed with this view, citing the history that CR LF was there first as a line ending. This history is absolutely true, but it doesn't change that CR LF is a mistake today and pretty much always was. In fact, we can be more general. The mistake is not specifically CR LF; the mistake is making any multi-byte sequence be your line ending.

The moment you introduce a multi-byte line ending sequence you require every piece of code that wants to recognize line endings to use some sort of state machine, because you have to recognize a sequence. A CR by itself is not a line ending, and a LF by itself is theoretically not a line ending; only a CR LF combined is a line ending, and you must recognize that somehow. This state machine may be as (apparently) simple as using a library call 'find the sequence \r\n' instead of a library call 'find the byte \n' (or \r on old Macs), or it may be more elaborate when you are attempting to read an IO stream character by character and stop the moment you hit end-of-line. But you always need that state machine in some form, and with it you need state.

If you have a single byte line terminator, life is much easier. You read until you find the byte, or you scan until you find the byte, and you are done. No state is needed to recognize your end of line marker.

(There's also no ambiguity about what you should do when you see just one byte of the line terminator, and thus no disagreement and different behavior between implementations. Such differences definitely exist in handling CR LF and they lead to various sorts of problems in practice.)

The decision by Unix and Mac OS to have a single character represent logical end of line in their standard text format regardless of how many ASCII characters had to be printed to the terminal to actually achieve a proper newline is the correct one. It simplifies and quietly slightly speeds up a huge amount of code, at the minor cost (on Unix) of requiring some more smarts inside the kernel.

(This is also the right place to put the smarts, since far more text is processed on typical systems than is ever printed out to the terminal. The place to pay the cost is at the low-frequency and central spot of actually displaying text to the user, not the high-frequency and widely spread spot of everything that processes text line by line.)

PS: The relevant Wikipedia page credits the idea of using a single character for logical end of line and converting it on output to Multics, which picked LF for this job for perfectly reasonable reasons. See the Newline history section.

WhyCRLFIsAMistake written at 21:39:07; Add Comment

2017-01-27

Conversations, conversational units, and Twitter

A while back, Glyph wrote an article more or less decrying 'tweetstorms', which are more or less multi-tweet sequences of remarks on Twitter and suggested that they should be blog posts instead (he later added an important followup). On the one hand I sort of agree with Glyph. Twitter doesn't make it very nice to read long sequences of tweets, and when I wind up trying to follow such things I generally wish I could get them in a blog post, even if it was just a copy of all of the tweets. On the other hand, I think that 'no tweetstorms' is going too far, because it conjoins an arbitrary limit (Twitter's 140 characters) with what I think people want, which is basically one remark in a conversation.

(I admit that my ox is mildly gored here.)

Twitter is not exactly a conversation, especially when you are starting a series of tweets from scratch, but it is close enough that there's a definite crossover. In my own Twitter usage, sometimes I can get what I want to say into a single tweet, but sometimes really covering it requires elaboration or what I need to say is simply larger than 140 characters. But what all of these cases have in common is that they are what I consider a single conversational unit, for lack of a better term. Each of them is a single small-scale thought, and so they're all the sort of thing I might say as a remark in a back-and-forth conversation.

I think that people are happy to both read and make genuine remarks on Twitter, even if they go over 140 characters and thus have to be done through several tweets. In a normal, natural conversation, you should be reasonably short but no one expects you to speak in a single short sentence and then stop. A big tweetstorm is different, though; it's not a remark, it's a speech, and people can tell. If you're going to make a speech, that's when you should get a blog.

In practice it's probably more like the distinction between writing a single paragraph or a big multi-paragraph thing. Short runs of tweets are basically a single paragraph spread out across several tweets, while a big tweetstorm would almost always clearly translate to multiple paragraphs if written out in pretty much any other form.

(I find Twitter's 140 character limit interesting and even sort of fascinating because it so clearly affects how people write on it, myself included. And sometimes this includes not writing things when I can't find a good way to fit them into the confines of a tweet or three. I'm sure that all mediums affect what and how we write, but for me it's rare to feel it so clearly. For that matter, having the character count for pending tweets directly visible affects how I write them.)

ConversationalUnitsAndTwitter written at 02:16:22; Add Comment

2017-01-15

Some notes on 4K monitors and connecting to them

For reasons beyond the scope of this entry, I'm probably going to build a new home machine this year, finally replacing my current vintage 2011 machine. As part of this (and part of motivating me into doing it), I'm going to persuade myself to finally get a high-resolution display, probably a 27" 4K monitor such as the Dell P2715Q. Now, I would like this hypothetical new machine to drive this hypothetical 4K+ monitor using (Intel) motherboard graphics, which means that I need a motherboard that supports 4K at 60 Hz through, well, whatever connector I should have. Which has sent me off on a quest to understand just how modern monitors connect to modern computers.

(It would be simple if all motherboard supported 4K at 60 Hz on all the various options, but they don't. Just among the modest subset I've already looked at, some motherboards do DisplayPort, some do HDMI, and some have both but not at 4K @ 60 Hz for both.)

As far as I can tell so far, the answer is 'DisplayPort 1.2' or better. If I wanted to go all the way to a 5K display at 60 Hz, I would need DisplayPort 1.3, but 5K displays appear to still be too expensive. Every 4K monitor I've looked at has DisplayPort, generally 1.2 or 1.2a. HDMI 2.0 will also do 4K at 60 Hz and some monitors have that as well.

(That 4K monitors mostly don't go past DisplayPort 1.2 is apparently not a great thing. DisplayPort allows you to daisy-chain displays but you have to stay within the total bandwidth limit, so a 4K monitor that wants to let you daisy-chain to a second 4K monitor needs at least one DP 1.3+ port. Of course you'd also need DisplayPort 1.3+ on your motherboard or graphics card.)

Adding to the momentum of DisplayPort as the right choice is that there are also converters from DisplayPort 1.2 to HDMI 2.0 (and apparently not really any that go the other way). So a motherboard with DisplayPort 1.2 and support for 4K at 60 Hz over it can be used to drive a HDMI 2.0-only monitor, if such a thing even exists (there are probably HDMI 2.0 only TVs, but I'm not interested in them).

I assume that having HDMI 2.0 on motherboards helps if you want to drive a TV, and that having both DisplayPort 1.2 and HDMI 2.0 (both with 4K at 60 Hz support) might let you drive two 4K displays if one of them has HDMI 2.0. The latter feature is not interesting to me at the moment, as one 27" display is going to take up enough desk space at home all on its own.

(As usual, searching for and comparing PC motherboards seems to be a pain in the rear. You'd think vendors would let you easily search on 'I want the following features ...', but apparently not.)

Driving4KMonitorsNotes written at 03:04:18; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.