Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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?

+7
−1

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.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

3 comment threads

What about Mac? (1 comment)
General comments (1 comment)
Do you understand German? (2 comments)
Post
+2
−0

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.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

Mounting different Filesystems (5 comments)
Mounting different Filesystems
H_H‭ wrote about 1 year ago

When you migrate data from an NTFS partition, everything will likely be marked executable by default

Most likely, they are non-executable by default. Which is more annoying but a security feature. (See also the mounting options exec noexec and umask for NTFS).

Modern systems assume UTF-8 by default, as much as possible, throughout all levels of the system.

Most levels don't care about encoding, they just thread it as a sequence of bytes without a '\0' inside it. It is only relevant when you display it or when you mount a filesystem that doesn't use a plain byte-string for names (like NTFS, FAT. See iocharset and codepage mount options for this filesystems)

Karl Knechtel‭ wrote about 1 year ago

They were executable-by-default when I did it - for example, double-clicking my old text files keeps giving me dialogs about the files being executable and asking whether I want to display or run them. But thinking about it more carefully, I "migrated" the partition by imaging it from an old drive and dumping it into a new Ext4 partition that I made with GParted, and I didn't know anything about fstab at that point. I would appreciate an edit that clarifies exactly how that works.

Re encoding, what I meant is mainly that the terminal will try to interpret the path as UTF-8 for display; desktop environments/window managers likewise; and UTF-8 is the preferred text encoding of the default locale.

H_H‭ wrote about 1 year ago · edited about 1 year ago

There is noexec and there is umask and fmask. They are independent from each other. You can give executable permission with fmask but set noexec, and the files will be listed with executable permission but you can't execute it. Maybe this is the reason? Maybe the executable flag was set (with umask or fmask) but also noexec, so that they can not be executed on the NTFS partition but as soon as they are copied, they can be executed. I don't know enough about it.

The same works with filesystems that do support unix permissions. You can mount a ext4 filesystem with noexe, you then still can set the executable flag of files but you won't be able to execute them.

Karl Knechtel‭ wrote about 1 year ago

fstab says the Ext4 partition is using the default options. I have no idea what the imaging and un-imaging(?) process actually does, nor do I really know what's implemented by NTFS itself vs. Windows when it comes to Windows file permissions.

H_H‭ wrote about 1 year ago

I was talking about the options of the ntfs partition not the one for ext4.

When for example fmask=0777 but noexe is set on a ntfs mount, you can not execute any file from that partition. However when you then copy a file from there to a other partition which supports unix permissions and doesn't have noexe set, you also copy the file permissions value of 0777, i.e. it is executable and you can actually execute it.