Welcome to the Power Users community on Codidact!
Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.
Comments on Linux distro and documentation for a Windows power user wanting to become a Linux power user without spending a lifetime in the process?
Parent
Linux distro and documentation for a Windows power user wanting to become a Linux power user without spending a lifetime in the process?
I'm a very-long-time Windows user that has lots of experience with that OS and its predecessor (MS-DOS).
I can't call myself exactly a Windows system programmer, although I know some of the APIs and have dabbled a bit in Windows programming, but I'm definitely a power-user (e.g. able to get my hands dirty in many parts of the Windows registry, so to speak).
I tried to learn Linux several times in the past 10-15 years, but I always had some difficulty doing the switch. Now that M$ has really pulled one too much of its stunts against privacy and user control (I could barely stand Windows 10. I won't touch Windows 11 "cloudy mess" with a 10m pole), I'm really considering switching over.
First of all, I'm not scared of command line (I was a DOS power user well before GUIs existed on PCs), and I already used Linux (and Unix) systems in the past. So I have no problem installing a distro and be just an average user using Linux GUI(s).
Moreover, I know many Linux tools because I'm a sort of OpenSource buff, and I've always used lots of FLOSS applications under Windows, many of which are of Linux derivation (just off the top of my head: GCC, LibreOffice, TheGIMP, Inkscape, etc.). I even use GNUwin32, a port of Linux command line tools for Windows.
My big problem is that every time I use Linux I feel my hands tied because I don't know how to do things that come to me naturally in Windows. I'd like to be a Linux power user, but I lack the time to learn by trial and error every little bit of the system as I did for Windows in the past 20+ years (plus another 10+ DOS years)!
Moreover, when I searched the Internet for advice about Linux distributions for Windows users I was faced with one of these attitudes, both unsatisfactory for me (I'm dramatizing a bit, just so you get the gist):
-
So you know Windows and you can't make head of tail of Linux and don't even know what a prompt is? OK, try this distro for dumb Windows users.
-
Mmmh, so you are a Windows wizard and know how to use the command line? OK, here is this nifty Linux distro that lets you customize everything with the command line, even the icon border color or the speed of water in the kitchen sink.
The first approach is useless for me, since I already know how to use more Linux commands at the prompt that the average Windows user, and I can search the Internet for tech info.
The second is overwhelming, because it assumes that you already know the philosophy behind any aspect of Linux, and assumes you have unlimited time to learn new things.
What I would ideally like is an advice for a reasonably friendly distribution that can be combined with documentation targeted at Windows power users that can ease the transition.
For what I've read in the last couple of months, it seems that Linux Mint could be a good trade-off, because it is based on a friendly distro (Ubuntu), but it's privacy conscious and doesn't follow corporate shenanigans. Moreover it is also suitable for older systems, and that would be good since I have a couple of older laptops that have been upgraded with more RAM and a good SSD, but have a ~10yrs old processor, and they would make excellent machines to do the transition without messing with my "active" Windows system.
Please, correct me if you think I'm wrong!
The big problem is the documentation. I know under Linux the docs are abundant, but they always assume a wide competency about the system. I'd like to know if there are guides explicitly written for Windows power users that keep the "Windows mindset" into consideration (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).
To be more specific, I don't need something that tells me just "don't use the registry, just change that line of that config files". 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".
I would need something that also explains "common knowledge that a Linux power user should know that a Windows user would never think about". 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.
I know that this post is a bit hand-wavy, but I hope someone who is a power user on both systems could understand my problem and point me in a good direction.
Note: I posted here and not on Linux.Codidact because the community here is bigger and I hope there are more people that know both systems.
Post
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:
-
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);
-
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.
3 comment threads