Where the split comes from
Both conventions trace back to physical typewriters and early teleprinters, where moving to a new line genuinely required two separate mechanical actions: a carriage return, sliding the print head back to the left margin, and a line feed, advancing the paper up by one line. Early computing systems modelled line breaks on that same two-step process. Unix, developed later, simplified it to a single line feed character and never looked back. Windows inherited the older two-character convention through DOS, and kept it for backward compatibility ever since, which is the entire reason the split still exists decades after typewriters became irrelevant to computing.
What actually goes wrong
A plain text file with the wrong line ending for its destination usually still opens and reads correctly, because most modern text editors quietly handle both. The failures happen in tools that read the file's structure literally rather than just displaying it. A shell script written on Windows and transferred to a Linux server can fail with an error like "bad interpreter" or simply do nothing, because the shebang line's trailing Carriage Return becomes part of the interpreter path the system tries to run. A config file parsed by a strict tool can silently misread a value that has an invisible extra character stuck to the end of it. In version control, a file whose line endings flip between commits can show every single line as changed in a diff, even when the actual text content did not change at all, burying a real edit under thousands of lines of noise.
How to tell which one a file uses
Line endings are invisible in almost every ordinary view of a file, which is exactly why the problem is confusing when it appears: the text looks completely normal on screen. Most code editors show the current file's line-ending convention somewhere in the status bar, and it is worth checking rather than assuming, particularly for any file being moved between a Windows machine and a Linux server or a Mac.
Converting deliberately, not accidentally
The fix, once you know which ending a destination expects, is a straightforward conversion: every CRLF pair becomes a single LF, or the reverse. What causes real trouble is an editor silently converting a file's line endings as a side effect of opening and saving it, without telling you, which is how a file quietly picks up the wrong convention for its destination days or weeks before anyone notices the symptom.
Handling it directly
The code editor on this site shows the current line ending in the status bar and lets you convert deliberately between LF, CRLF and the older CR, so a file picks up exactly the ending its destination expects, on purpose, rather than by accident of whichever editor last touched it.