In this tip, we'll have a look at a few of the more ancient bits of crusty stuff and identify their purposes, if not their actual origins.
Perhaps the most common abbreviation in Linux is "rc," short for "runcomm" -- short in term for "run command." Today, "rc" is a suffix added to any script-like file that is called during the startup stage of a program, or of Linux in general. Thus /etc/rc is the master script for Linux startup, and .bashrc is the script that runs when the bash shell starts. The "." prefix on .bashrc is a naming standard designed only to hide user-specific administrative files from user files; the "ls" command doesn't list such files by default, and "rm" doesn't delete them by default. Many programs demand that startup files or profile files begin with a period or have an "rc" suffix, but there's nothing magical about either from the file system's perspective.
The "etc" in "/etc/bin" really does stand for "etcetera." In early Unix systems, the most important directory was the "bin" directory (short for "binaries" -- compiled programs), and "etc" was for trivial stuff like startup, shutdown and admin. The list of things you need for running Linux is: a program binary, etcetera, etcetera -- in other words, a sole vital item, plus some less important bits and pieces. Today, "etc" holds system-wide configuration files that you'd almost never do without -- hardly unimportant.
Most large subsystems that run on Linux today, like GNOME or Oracle, use their own "bin" directories (or /usr/bin or /usr/local/bin) as a standard place for compiled programs. It's common now to see scripts in those directories too, since "bin" directories are frequently added the PATH of a user, making their run-able programs available. So run-able scripts are often stuck in bin as well.
Perhaps the most confusing jargon in Linux relates to terminals. TTY is an old abbreviation for a TeleTYpe. Teletypes, or teletypewriters, were originally printer-keyboard combinations that read and sent information over a serial line, not too different from an ancient telegraph machine. Later on, when computers only ran in batch mode (when card readers were the only way to get your program loaded), a teletype was the only useful "real time" input/output device available. Eventually teletypes were replaced with keyboard-and-screen terminals, but the operating system still needed a program to watch the serial port where the terminal or TTY was plugged in. That's what a getty "GEt TTY" process is: a program watching a physical TTY/terminal port. A Pseudo-TTY (a fake TTY, a "PTY") is the terminal equivalent of a virtual network computing (VNC) server. When you run an xterm or GNOME Terminal program, the PTY acts as a TTY for the virtual or pseudo terminal that the xterm represents. "Pseudo," meaning "duplicating in a fake way," is really a more descriptive term than "virtual" or "emulated." It's a shame that it has fallen out of fashion in computing.
Also left over from TTYs is the "stty" command, for "set tty", and an /etc/inittab ("initialization table") file that configures which gettys are on which serial ports. In modern times, the only terminal directly attached to a Linux box is usually the console, with its special TTY that's named "console." Of course, the "console" TTY goes out the window as soon as you start up X11, which doesn't use a serial protocol any more. All the TTYs are stored in the "/dev" directory, which is short for "[physical] devices." Once upon a time you had to configure each such device file by hand when you plugged a new terminal into the set of serial ports on the back of the computer. These days, the install process for Linux (and Unix) just creates in that directory every device file that it can imagine. That way, you rarely have to create one.
The further you move from the hardware, the more obscure the naming is. Fortunately, today's higher-level software blocks on Linux have readily understandable names free of history and hardware. For example, there's... umm… err... Pango. Right.
If this inspires you, then consider reading the magnificent, but somewhat U.S.-English-focused history provided by Eric S. Raymond's Jargon File. It doesn't explain all the terms used in Unix, but it gives many glimpses (some almost scatological) into those formative days.