Nexus 10 is here

After what must have been the fastest delivery in the history of online shopping, my brand new shiny Google Nexus 10 has arrived. It’s black in color, packing 32 gigs of storage, very fast, and with a beautiful screen.

The wait is finally over.

So far I have only managed to update it to the Android 4.4.2, install and configure all the apps I use, download and watch an episode of the Vikings, and login to every single social network.  It is too early to say much yet, but so far I’m loving it. Colors, performance and the battery life seem to be perfect. 

Tablet shopping

I got tired of waiting for Google to release the second generation of Nexus 10.  At the same time, I am still scared of all the available choices from other vendors.  Today I ran out of patience and ordered the tablet.   With keyboard.  And a case.  And also a couple of games – Call of Duty “Ghosts” and Grand Theft Auto V, which were on the pending list for the next Amazon order.

Clearly, waiting is not my game…  I’ll let you know what I think of these once they arrive and I play with them for a bit.

Why are there different representations for newlines in Windows, Linux, and Mac?

Why are there different representations for newlines in Windows, Linux, and Mac?

This is a good question albeit one with a boring answer. Different systems evolved different encodings for newlines in the same way they evolved different behavior for myriad other things: Each system had to standardize on something and interoperability in the days before email let alone the Internet was unimportant.

There are several ways to represent newlines. ASCII-based systems use some combination of carriage return and line feed. These derive from typewriters: A carriage return (CR) resets the typewriter carriage’s horizontal position to the far left and a line feed (LF) advances the paper one vertical line. For a typewriter, you need both, so some systems (DOS, Windows, Palm OS) adopted CR+LF as representation of a newline. Other systems, such as Unix, noted a computer didn’t have a carriage to return so a sole line feed was sufficient. Still others, such as Mac OS prior to OS X, adopted only a carriage return—arguably, this choice doesn’t make any sense, as a bare carriage return would swing the typewriter carriage back to the left but not advance the page. Still other systems used LF+CR, inverting the ASCII characters used in Windows.

Systems not based on ASCII, of course, did their own thing. IBM mainframes built around EBCDIC, for example, used a special newline character (NL). Perhaps oddest of all, VMS utilized a record-based filesystem where newlines were first-class citizens to the operating system. Each record was implicitly its own line and thus there were no explicit newline representation!

But none of this mattered, because these systems never had to interoperate with each other—or, if they did, they had to make so many other conversions that newline representation was the least of their worries.

Today, most Internet protocols recommend CR+LF but dictate compatibility with LF (CR and LF+CR are left out in the cold). Given the centrality of the Internet, the ubiquity of Unix, which heralds LF, the primacy of C and descendant languages, which (somewhat) map their newline to LF, and the fact we really only need one character to represent a newline, LF seems the clear standard going forward.