Linux distro and documentation for a Windows power user wanting to become a Linux power user without spending a lifetime in the process?

Distro

TL;DR: Mint is good for you.

There are many choices and many of them are good. As long as it is somewhat popular and not a specialized distro it should be good enough. Don't worry about it too much, you can change most things later, like the desktop environment, if it turns out the distro defaults are not good for you.

it seems that Linux Mint could be a good trade-off

Yes, Linux Mint is a good choice. The good thing is that it is easer to install proprietary drivers than in some other distros. The other good thing is that it is based on Debian and can use the popular *.deb packets. This is useful when a program (version) is not found in the official repositories.

Documentation

I need something that "understands" the usual workflow of a Windows power user and tells me "OK, In Windows you would have used this tool. Now you could use this other, which is similar, but if you really want to do better, just use this command on the prompt because it can also do this, and doesn't have this other limitation".

Sorry, but that doesn't work when you want to become a power user. As soon as you go into the details, Linux can work very different than Windows.

This things work different in Linux:

• The file hierarchy and mounting filesystems is completely different.
• What belongs to the OS and what not. On Linux you have only the kernel and all other things, like a displayserver, job scheduler, file manager, shell, DHCP-client, the init-process... are userspace programs that are not part of the OS and can be changed. Even the bootloader is its own software the can be changed. On Windows all this is part of the OS and can't be removed.
• How to configure applications: On Linux most applications and the kernel itself, can be configured in textfiles. Most of them either in /etc/ or $HOME/ (/home/<yourUserName>/.<somewhere>).
• How to access hardware. On Linux you can access a lot of hardware by accessing (a) file(s). Some of them are in /dev/ or /sys/ (and other places). On Windows, this is possibility very limited.
• How permissions work is very different.

Therefore i don't think there is a resource that has exactly what you are asking for. And there is a lot of knowledge you have to learn.

How to become a Linux power user

Here is what you should know or learn to understand Linux and to become a Linux power user:

• How the command line, such as bash, works. How to pipe one command to a other command, redirecting and the difference between stdout (FD 1) and stderr (FD 2), how arguments are split, ctrl-commands,...
• The function of some command line programs. Like grep, sed, ps, kill, ssh, rename, strace, mount, column, head, tail, dd, man, top, pkill, sudo/doas/su ....
• Learn to use a powerful text editor that also works on the command line. Such as vim, neovim or emacs. And maybe some other tools, like tmux, would also be helpful.
• Learn how to write shell scripts.
• Configuration of your tools. Tools like vim, tmux and bash can be configured, automated and extended a lot. Configure them to your needs.
• How the Linux filesystem is organized and how it works. How file systems are mounted, what special directors exist and what they are used for. How unix file permissions work.
• Knowing a non-specialized scriptable programming language, such as python, can be very helpful.

And you need a lot of patience, time and the willingness to search for solutions and try new things.

Some other notes

"common knowledge that a Linux power user should know that a Windows user would never think about"

Here is a incomplete list of topics:

• What a package managers are there and how they work. And solving problems with them (probably the most common problem i run into).
• What different config files, such as /etc/fstab (to mount drives), /etc/passwd, /etc/shadows do.
• What the virtual filesystems mounted at /dev/, /proc/, /run/, /sys/ are and what they can be used for.
• That you can choose different login managers, desktop environments, ...
• What different shells there are (and which one you want to use).
• The init process and how to handle services (Mint uses systemd).
• Boot managers and what command line arguments the kernel accepts.
• The difference between userspace and kernelspace (not to be confused with the permission level).
• The different file systems (ext3, ext4, btrfs, ...)
• Frame buffers for the console.

For example, what's the Linux equivalent of the "ctrl-alt-canc" that can bring a Windows system out of a problematic situation, allowing you to run the process manager.

ctrl-alt-F1 (or a other F1-F6 key) to switch to a console, login and then use ps, top, kill, pkill or whatever you need to solve the problem. ctrl-alt-F7 to switch back.

e.g. sometimes a GUI is the right tool for the job, like when you need to select one-by-one a bunch of files in a directory that are not apparently related and that need to be copied or processed by the same tool

You can choose any normal file manager on Linux you like for that. If you need to manipulate them in a bit more involved way, you may create a folder, open a (GUI) file manager and move the files to change to this folder. Then you can use the command line to manipulate them all and move them back when done.

You can also create a shellscript with a for-loop and do something like this:

for file in file1 file2 file3 file4
do
  doSomething "$file"
done

posted 8 months ago

CC BY-SA 4.0

7mo ago

H_H‭

59 reputation 3 2 9 9

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 7 months ago

CC BY-SA 4.0

7mo ago

Karl Knechtel‭

106 reputation 2 3 13 5

Please, correct me if you think I'm wrong!

What you're asking is at cross purposes with the Linux movement. Linux is fundamentally different from Windows because its development model is different. It needs to be highly modular because there is no big company managing development (Red Hat and Fedora are the closest thing). So it cannot be like Windows, because that requires having a Microsoft. Also, expert Linux users are not interested these days in making Linux resemble Windows.

Your only choice is to bite the bullet and accept that it will take a few years of struggle before you become proficient. Trying to find Windows-like distros and programs will only superficially help at first, but it will quickly make it even harder to learn, because the quality of "Windows-style Linux programs" is quite low. By the way, I'm talking here about using Linux as your main OS for everything, not dabbling. It has to be your main OS, it's like taking a Japanese language class vs. moving to Japan.

During this "acclimatization", you will be unable to independently solve many problems. Instead, you will rely on copy-pasting commands from forums and using packages or scripts other people wrote. Certain aspects of Linux like drivers, graphics, sound, networking, printing are just too complicated to pick up right away. So I would recommend that you make sure to start with a popular distro. A good indicator is the number of packages. This narrows it down to:

• Debian: Reliable, but quirky and software is often out of date
• Ubuntu: Bad distro but proprietary vendors think Ubuntu=Linux so it gets great support (eg. drivers)
• Manjaro/Endeavour: Add user friendly GUI tools to Arch, but they're buggy and can break you system. Usually you have to ask for help on Arch forums anyway, and those people absolutely seethe when they realize you're "not using real Arch"
• Fedora: Has a company actually hiring engineers to develop the distro, so a bit less chaotic

Do not start with Arch or NixOS. Although these are good distros, they target expert users and you'll be very overwhelmed.

Another big factor is choice of desktop environment, because usually it will take care of some annoying things like networking or sound. Note that in Linux, you can easily install multiple DEs and switch between them.

• KDE/Plasma: Explicitly inspired by Windows 7 UI
• Cinnamon: Spiritual successor to Gnome 2 (because the current Gnome 3 is awful) which is also very similar to Windows XP
• Xfce: Lightweight but usable, similar UI patterns to Windows. By default has a Dock and top bar like Mac OS, but you can change those easily.

Even with a DE, get used to dealing with the CLI. Everything in Linux is designed CLI-first. The GUI is often just an afterthought. Get comfortable browsing and reading man pages as this is primary documentation for most programs. Yes, many man pages are very complicated and hard to read - unfortunately you will often just have to live with it, as many expert users insist nothing is wrong with them and refuse to improve. I also find https://github.com/tldr-pages/tldr helpful. But generally, get into the habit of checking a program's manuals and online help channels before you install it - know what you're getting into.

20-30 years ago the Linux community had aspiration of becoming a popular desktop OS, and commercial OS design was more conservative, so the migration was easier. These days Linux evolves more according to the needs and wants of existing Linux users. They've given up on beating Windows/Mac OS. Meanwhile, Microsoft and Apple have stepped up their "innovations" which makes their OS even more different and harder for users to switch. I think the trend will continue, so if you're interested in Linux, I would recommend isntalling it (in dual boot mode for emergencies) and using it as default now. Later, you will only acquire more Windows-specific habits which make it harder to migrate.

I made this answer superficial because it's impossible to cover it all in detail. I have a proposal to improve matters, but the admins must create a new section first for that. Maybe you can support the proposal. But in the meanwhile, I'd recommend asking more questions about individual specific things on https://linux.codidact.com/. Likely those questions will also be too general, but we can hopefully give you some pointers on yet more questions to ask and that second set will actually be answerable.

posted 7 months ago

CC BY-SA 4.0

matthewsnyder‭

816 reputation 23 27 109 26

I don't know any type of document like that, but I've been using both for 10 years now. I'm by no means a poweruser at windows, maybe in linux.

The best advice I can give you is, that the flow is the same. The programs you use in linux, usually don't have a UI (it depends how deep you are going, if your trying to change icon border color its a config file somewhere, no UI at all). Linux power users are more of like programmers then powerusers, because usually the tools to do X aren't default on the operating system and you need to spend some time searching github for the right tools and troubleshooting them for your specific purpose (especially if you want an UI) or creating them yourself. It is more of a "Here is an axe, build your house" rather then a "Here are all the pieces for an house, assemble them yourself" if that makes any sense to you.

posted 8 months ago

CC0

8mo ago by samcarter‭

Or4ng3h4t‭

1 reputation 0 1 0 0