5 Linux rookie mistakes

Linux enthusiasts share some of the biggest mistakes they made.
146 readers like this.
magnifying glass on computer screen, finding a bug in the code

Opensource.com

It's smart to learn new skills throughout your life—it keeps your mind nimble and makes you more competitive in the job market. But some skills are harder to learn than others, especially those where small rookie mistakes can cost you a lot of time and trouble when you're trying to fix them.

Take learning Linux, for example. If you're used to working in a Windows or MacOS graphical interface, moving to Linux, with its unfamiliar commands typed into a terminal, can have a big learning curve. But the rewards are worth it, as the millions and millions of people who have gone before you have proven.

That said, the journey won't be without pitfalls. We asked some of Linux enthusiasts to think back to when they first started using Linux and tell us about the biggest mistakes they made.

"Don't go into [any sort of command line interface (CLI) work] with an expectation that commands work in rational or consistent ways, as that is likely to lead to frustration. This is not due to poor design choices—though it can feel like it when you're banging your head against the proverbial desk—but instead reflects the fact that these systems have evolved and been added onto through generations of software and OS evolution. Go with the flow, write down or memorize the commands you need, and (try not to) get frustrated when things aren't what you'd expect." Gina Likins

"As easy as it might be to just copy and paste commands to make the thing go, read the command first and at least have a general understanding of the actions that are about to be performed. Especially if there is a pipe command. Double especially if there is more than one. There are a lot of destructive commands that look innocuous until you realize what they can do (e.g., rm, dd), and you don't want to accidentally destroy things. (Ask me how I know.)" Katie McLaughlin

"Early on in my Linux journey, I wasn't as aware of the importance of knowing where you are in the filesystem. I was deleting some file in what I thought was my home directory, and I entered sudo rm -rf * and deleted all of the boot files on my system. Now, I frequently use pwd to ensure that I am where I think I am before issuing such commands. Fortunately for me, I was able to boot my wounded laptop with a USB drive and recover my files." Don Watkins

"Do not reset permissions on the entire file system to 777 because you think 'permissions are hard to understand' and you want an application to have access to something."Matthew Helmke

"I was removing a package from my system, and I did not check what other packages it was dependent upon. I just let it remove whatever it wanted and ended up causing some of my important programs to crash and become unavailable." Kedar Vijay Kulkarni

What mistakes have you made while learning to use Linux? Share them in the comments.

Tags
User profile image.
Jen leads a team of community managers for the Digital Communities team at Red Hat. She lives in Raleigh with her husband and daughters, June and Jewel.

14 Comments

Linux, IOS, & Google's Android are all flavors of UNIX Server...The same mistakes can be made when configuring the Partitions, System filesystem, and User Permissions..The trick is to use the Correct/Very Specific Syntax to create what you want...I've made a mess of an operating system/Hard Drives & CPU Machine Language by trying to simplify/Generalize CLI commands during the process many times...Thank God for Reformatting. I love Linux/Android Flavors. Won't give Apple's Greedy system the time of day!

Really annoying is, that the r is so near on the e. Take a look 3 times, before you press enter for crontab -e

Oh no! As often as I make typos, I am amazed I've never managed this one.

In reply to by Alex Vienna (not verified)

Another rookie mistake can be relying on the built in package manager of your chosen distro, it is appealing and seductive, making adding or removing applications easy (as it should be). Unfortunately the program versions available in repositories far too often lags behind the latest versions, sometimes a long way behind.

Actually, I think rookies should stick with the package managers until they understand how and why to use other means to update. This helps you avoid the "dependency hell" we all used to go through with some regularity.
(Dependency hell = the situation where some newer version of a program requires updates to libraries that are then incompatible with other programs you're using and breaks them. This is the rookie mistake of thinking that the absolute latest version of something is the best.)

In reply to by peter_cheer

I would say the real rookie mistake is going out looking for an exe-style installer for a program without realizing that the package manager is there to keep you alive.
As for latest versions of things, getting into adding independent and COPR repos is the way to go as far as possible.

In reply to by peter_cheer

Even when you're no longer a rookie, you are not exempt from rookie mistakes. I did a Fedora upgrade using a plugin, and thought I didn't need to backup my system. The upgrade failed miserably and the computer was nonbootable. Fortunately I was able to run a rescue disk and copy my needed files from the hard drive. Of course, I tell myself I'll never do that again, but will I?

I once uninstalled python modules sudo apt purge python* and my terminal couldn't work or run anymore most of the application.... it was messy.

I have rebooted the wrong host :( I have also been in the wrong directory when either deleting or changing perms recursively. Ouch.

PLEASE: Set your PS1 to the $HOSTNAME: <$PWD> $USER

Before you run any command that could cause an outage or destruction, ask yourself what user am I, what directory am I in and what host am I on.
Which goes back to ^^ - check your PS1 regularly BEFORE running the command. It will save you alot of time and embarrassment :)

Great article! Today I was setting up a new backup device and working on some scripts. All was going well until I accidentally deleted all the backups I'd just made.... so, I had to do them all again!

Just some weeks ago I was trying to make a script which would find and hopefully remove all my firefox bookmarks older than 10 days... After I managed to get the command seemingly right... It looked something like this:

$ find $HOME/_Backup/firefox_autobak -mtime +10 -type f -name *.html.xz -delete

It was working just fine... Then, I was reading foruns and the manual page and thought that I _should_ move the -delete option to somewhere before the search string, just so the cmd would look more correct and beautiful.. I was at my home folder... And so I made a test with the cmd something like:

$ find $HOME/_Backup/firefox_autobak/ -mtime +10 -delete -name *.html.xz

AND... suddenly I noticed it was trying to remove some files that were read-only and was able to Cancel the process... BUT, somehow, that find command deleted my vim custom delek.vim colorscheme, .profile, .history, plus my Pictures, Videos, Public, Desktop & Music folders...

I still today would like to know why moving that flag within the cmd caused so much havoc with my home folder . Fortunately, I keep my data in other non-XDG folders which were not affected, and my .profile was very short and I could find an old backup which was almost up-to-date.. And later a found a much nicer colorscheme to vim than my custom delek, so mostly it was just a hugging scare...

Now I always cd into the folders I want to manage files just to avoid rookie mistakes... And to keep up-to-date Backups always

That is because in find the options are not just flags to turn a feature on or off like some other commands. It's more like a filter or pipeline. It's processed left to right and the entire expression is evaluated to true or false for each file.
So, you first expression (-mtime +10 -type f -name *.html.xz -delete) says:

if the has been modified more than 10 days ago, then true
if still true and it's a file, then true
if still true and the name matches the pattern, then true
if still true, then delete the file

Your 2nd expression (-mtime +10 -delete -name *.html.xz) says:

if the has been modified more than 10 days ago, then true
if still true then delete the file
if still true and the name matches the pattern, then true

In reply to by Jamil Soni N (not verified)

I had to learn (the hard way!) to never do ANYTHING regarding updates (Fedora...OpenSuSE) without making full backups first. I was a newbie back in 2002 / '03 and thought Linux was "just" like Windows...in that if you update/upgrade....you'd have a way to revert it if anything went wrong. Well? 17 years later, I can tell you I've lost a LOT of data I held dear! I have 3 laptops and a desktop...and I have TWO 4 TERABYTE External hard drives that I use for backups every MONTH. So now?...no matter how hosed one of my systems might get from an update?...I can easily put all my settings, configuration files and photos, videos documents etc. back. (As a side note?..I tend not to upgrade as much anymore...I'm JUST getting ready to move from Fedora 28 to 30...and to update both my OpenSuSE laptop and my Ubuntu desktop!) I guess once you enter into the world of Linux you "earn" your badge of honor by going through the process of destroying everything?...seems the best of the best in System Administration all have nightmare stories....I can only say thank goodness I've never made these mistakes on "corporate" hardware...its always been my personal machines! Whew!

I have performed the command I'm about to describe as I was completely wiping out the software on my system so someone else could take it and use it as needed. I was in a computer operating system organization, so we could easily obtain daily system builds or stable software releases easily.

Therefore, NEVER do this unless you intend to destroy the software on your system and you want to watch the system become unusable.

Command: sudo rm -fre /

On the UNIX system I was using, the e option would show information about the progress of the command, in this case until the system itself became unusable. So it was cool to watch because we had easy ways to rebuild the system software from scratch. Most people will never want to perform the command: sudo rm -fre / because it removes all of the software.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.