Not in character encoding it isn't... Well, it is and it isn't... You send 0x000A to a 8 bit character set, you'll get null followed by a carriage return, instead of just a null -- on little endian systems. Big endian it's the other way around. Null could be bad, as most C strings are null terminated. Could result in the entire rest of the file not even displaying if you sent the word-length version to the wrong encoding.
Oh, and it would help if we were to say what the characters ARE instead of just spouting off their numbers. Carriage return (0x0D - /r) and Line feed (0x0A - /n)... which stem back to the typewriter, teletype and serial terminal days.
TECHNICALLY by what the characters mean in ASCII, line feed should ONLY move the cursor down without setting it to beginning of line, which is why DEC PDP, CP/M, TOS, and anything DOS based requires both /r/n. CR+LF.
Apple (from the II right up to MacOS-9), old Trash-80's, use carriage return only... This was mostly done originally to save that one byte.
Naturally like everything else *nix, they use the one that makes the least sense, linefeed only. This actually makes *nix incompatible with a lot of older terminals unless you tell it what the terminal is and have software translate it.
Thankfully across most systems the unrecognized character is usually ignored -- and at worst you just get double-spacing... so CR+LF works on 99% of the world. Unless you're messing around with old Sinclairs it's unlikely to be an issue - though it is why most editors still let you chose how newlines are handled.
quote for truthiness: