It's better to start in the shallow end

Even the "friendliest" Linux distributions usually don't get in your way very much, or try to force you to do things in a specific way to the extent that Windows does.

I'm using the Cinnamon edition of Linux Mint - I think it's easier to think of this as "Linux Mint with the Cinnamon desktop environment". The Mint team describes this as "The most modern, innovative and full-featured" of three options they offer. There's a lot of evangelism I could offer here comparing the experience to Windows, in summary it's much more streamlined overall (lower RAM usage for just the core system; much lower disk usage for the system essentials; much slower accumulation of cruft, which can also be cleaned out more easily; and a much less obtrusive system update manager) despite appearing "full featured". But more importantly, it's trivial to get to a terminal window from within the GUI, even without knowing about lower-level "recovery" interfaces. Between this and the general design of Linux, the "friendliness" doesn't inhibit you from acquiring power-user skills. Instead, the elegant design offers affordances to start experimenting and looking for ways to take control of the system and be more of a power user.

About dual-boot

You may want to have a recovery drive around that can boot Windows, just in case something goes seriously wrong and you need to be able to turn on the computer and access a web browser to do research. In theory, the live boot media that you use to install Linux can also do this, but in a crisis situation you may find Windows more familiar. More importantly, if you do this in the obvious way, that drive will likely have old files lying around that you might find useful.

On the other hand, I messed something up initially and didn't manage to set up dual boot properly the way I wanted... and ended up not caring. From personal experience I would say that it's not worth the additional effort, as long as you're confident you have a way to drop into the BIOS and boot Windows in an emergency.

Major differences

Rather than a specific documentation source, a new Linux user coming from Windows mainly needs to understand the paradigm shift. With Linux, when you need to reach for the documentation, it will be in a very specific context; and if the built-in documentation (the man command, a -h or --help command-line option or help subcommand, or a README file) doesn't suit your needs, the best next step is almost always to do a specific web search.

If you really are totally lost in terms of "what are the most important command-line programs I need to know about, and their basic purposes?"... that's probably also a question better suited for a search engine nowadays. If your question feels hand-wavy to you, that's because it is; proficiency isn't built overnight, and you need to have tasks to accomplish before you can learn how to accomplish them.

(That said: as "glue" between other commands, you'll definitely want to be familiar with xargs.)

Here are some of the things I've run into, both in 2021 when I made the shift that you're now contemplating, and over the years using Linux on other peoples' computers, that I think are most important for you and everyone else in a similar position:

Getting programs

Linux has much more of a culture of compiling OSS from source; pretty well any distribution will include GCC and possibly other C compilers (and just the compiler, not a gigantic bloated IDE like Visual Studio), and Linux versions of programs are much more likely to provide source distributions with Makefiles that "just work" for most Linux users (while also allowing you to tinker).

For the cases where this either isn't supported or most users prefer a precompiled binary, you'll normally want to use the package manager built in to your distro. Mint is based on Ubuntu, which in turn is based on Debian; this results in a stack of command-line options (apt, which wraps apt-get, which uses dpkg specifically for installation) and graphical options (Synaptic which is a normal GUI program, and aptitude which uses Curses in the terminal).

Cleanup and maintenance

As I mentioned, you'll probably be impressed with how much less space is taken up for operating system essentials, and how much longer you can go before feeling the need to clean up old unused stuff. However, you'll want to make sure you understand how to do that cleanup. In my experience, these are the most important commands to understand and research:

• apt-get autoremove, or your package manager's equivalent (after removing packages, use this to clean up dependencies that are no longer required by any other packages. In particular, this removes old kernel versions left behind after system updates)
• apt-get autoclean, or your package manager's equivalent (use this to clean up caches left behind by the installation process)
• journalctl (use this to clean up old system diagnostic logs; they do get sizable eventually)

You may also want to research an up-to-date tutorial or best-practices guide for setting up initial disk partitions etc.

Shell vs Batch

There are many different shell languages which makes it easy to run into gotchas because a certain feature only works in some of them, or works subtly differently. However, Bash appears dominant nowadays and is a fine starting point if you aren't going to be forced to work on very restricted hardware. It's important to have a solid understanding of the default .bashrc/.bash_aliases setup that gets used when you log in as well as every time you start a new shell.

It's also important to understand that shell-scripting languages, collectively, work very differently from batch script. I find that overall the language is much more elegantly designed; it isn't full of reserved names like NUL and CON and PRN, instead if you want to output somewhere special then you describe it as a path to a file, just like normal. Many syntax elements work by actually having "programs" (whether they're built-in or actually separate executables) with interesting names; for example, [ is actually an alias for the test command which is what allows square-bracketed "if conditions" to work.

Configuration and "workflow"

Configuring things in Linux leans much more towards the ".ini files scattered everywhere" approach, rather than the "central binary registry requiring a custom editor" approach. This makes it a lot easier to do tasks like making a new user account and cloning preferences settings; you can have a script that actually just copies a bunch of files into the right places, and it just works. You aren't forced to edit the Registry, nor to work through endless "friendly" GUI settings interfaces manually. I know you explicitly made a point about not needing to be told this part, but it really is important, and becoming a Linux power user requires considering the implications of this design. The "equivalent workflow" that you're asking about, in many cases, is "seriously, just open a text editor and edit the [colourful adjective of choice here] config file". In a lot of cases you don't "use this other tool" or command-line invocation; you just edit a file.

For example, rather than "desktop shortcuts" being totally opaque, the modern Linux equivalent is a .desktop file which is actually a plain text file. You can edit it with any text editor and the format is very INI-like. It's part of the XDG specifications that you will want to become very familiar with as a power user. (Linux also generally makes it more convenient to work with symlinks, and is more built around the idea that it's normal for users to create them.)

This also includes a few simple applications of - well, actually programming. For example, I set up my .bashrc so that I have a function that can check an environment variable for additional commands to run. That, in turn, allows me to make a .desktop file that sets an environment variable and then runs bash, so that I can get a new terminal window that automatically runs some commands when it opens. Then I made a Python script that can ensure that .bashrc specifies that function, and creates a .desktop file for a specific auto-run command.

For another example, I have a Python script that sets up new Python project folders (doing the initial Git and Poetry work). It's designed to use hidden files and folders (with a leading . in the name) in a way that cooperates with some Bash aliases I wrote, which expect the setup script to put certain things at specific (relative) paths.

Executable text files

Windows makes a very clear distinction between "applications" and "documents". If it doesn't actually contain compiled code, then it's dependent on something else that does in order to open and interpret the contents. The process for associating those "documents" with "applications" is strongly dependent on a registry that only cares about a filename extension, and lets the application do any further checks after that.

On Linux, files are mainly just files. "Executable" means that the appropriate execution permission bit is set; it says nothing about the actual format or contents of that file. The application loader will try to figure out whether it's actual compiled code (in e.g. the ELF format) or a "script" (based on a shebang line, and defaulting to the scripting language of the current shell), based on the first few bytes of the file contents. While it's possible to associate files with executables based on a filename extension, this is a separate system built on top.

"Text files" and "binary files"

On Windows, text files are expected to use a carriage-return-plus-linefeed sequence to indicate the end of a line. On Linux, only a linefeed (called "newline" by programmers - ASCII 10) is used, and opening files "in text mode" therefore doesn't actually do anything different at the C level. (In Python, selecting "text mode" for a file uses a "universal" newline mode by default, and in 3.x it also enforces that I/O uses strings rather than byte-sequences, applying an encoding transparently when reading and writing.)

Linux doesn't really distinguish text and binary files to nearly the same degree, and as noted before, it doesn't have a particular prejudice that "text" files "shouldn't" be executable. When you migrate data from an NTFS partition, everything will likely be marked executable by default; this can cause some annoyances. Similarly, text files opened in Linux text editors may show spurious ^M or other markings from the extra carriage-return characters. There are tools available that help with both issues.

Text encodings and paths

Windows has a long legacy of using code-page style encodings, and then bolting on a "Unicode" API based on UTF-16. The old Linux paradigm (to my understanding) was to not care about the text-vs-bytes distinction, and make sure to stick to ASCII if you needed to be unambiguous. Modern systems assume UTF-8 by default, as much as possible, throughout all levels of the system.

However, filenames and paths on Linux are still fundamentally byte-sequences (that just are explicitly not allowed to contain 0x00 bytes), and file names are still fundamentally byte-sequences that can't contain 0x00 or 0x2f (ASCII forward slash) bytes. While the system will try to interpret the bytes as UTF-8 for display, it will accept bytes that aren't valid UTF-8, displaying them as fallbacks, and it will require byte-by-byte-exact matches to identify files and paths.

Speaking of which: those are the only bytes strictly prohibited in Linux paths and filenames. DOS places many more restrictions, and Windows Explorer even more; Linux does not need to, because the shell syntax has an elegant escaping mechanism. On the other hand, for POSIX compliance reasons it's a good idea on Linux to stick with a (very) restricted set of characters where possible.

Filesystem organization

There are a lot of differences, but I think these two are most important: Linux does not use drive letters (every device is treated as part of a single filesystem tree; processes have only a single current working directory within that filesystem; devices need to be explicitly "mounted" to represent paths within the filesystem), and typical "installers" organize things differently.

On Windows, a program installer will generally give the application, along with all its non-shared resources, a separate folder within a central "Program Files" folder or else a user-specific directory for programs. On Linux, generally the actual applications go in /usr/bin or other similar folders, directly, side-by-side. The corresponding resources go in /usr/lib, and they're much more often intended to be shared.

This, in combination with the "shebang line" system, has profound implications for working with the PATH. For example, Python scripts on Windows couldn't specify the interpreter version to use until a separate tool was developed; the installer associates the .py file extension with this launcher instead of any particular Python executable. If every Python added itself to the PATH, only the first one would be relevant to the behaviour of python at the command line, and PATH would get polluted and over-long - so the installer doesn't do this by default. But this in turn means that python often won't find a valid installed Python, and could find Microsoft's offer to install it for you instead - which has vexed very many people.

Typical look-and-feel differences

It's very common for the default setup on Linux to:

1. assign special meaning to middle-clicks: basically, "duplicate the selected text here" (it is not a copy-and-paste, in that it does not affect the clipboard);

2. emulate middle-clicks with a simultaneous left- and right-click.

I found myself making tons of misclicks because of the second, and don't find the first useful, so I did some research and disabled both.

Many years ago, I recall that it was also very common in Linux window managers that the window with focus was not necessarily in the foreground. I found it extremely annoying and counter-intuitive. That doesn't seem to be how modern versions work, however.

Finally: Cinnamon does not support right-dragging (right-click context menu options open as soon as you press the right mouse button). I suspect this is also the rule rather than an exception, although I haven't looked into it.

posted over 1 year ago

CC BY-SA 4.0

1y ago

Karl Knechtel‭

154 reputation 4 3 20 5