Tips for getting better at Linux.
from pineapple@lemmy.ml to linux@lemmy.ml on 29 Dec 23:19
https://lemmy.ml/post/24186309
from pineapple@lemmy.ml to linux@lemmy.ml on 29 Dec 23:19
https://lemmy.ml/post/24186309
I am a Linux beginner/amateur and I have sort of had enough of copy and pasting commands I find on the internet without having a good understanding of how they actually work.
I guess my end goal is to be able to comfortably install and use arch Linux with my own customization’s and be able to fix it when things go wrong.
What tips/ideas do you have for getting better at navigating the terminal, and getting a better understanding of how the os works. What is a good roadmap to follow? And how did you, advanced Linux user, get to the stage your at now?
Edit: my current distro is bazzite just in case you were interested and thanks for all the replies you are all really helpful.
threaded - newest
Just install Arch, when You follow wiki it’s not that hard. if You will make mistakes during the process, You will gain better understanding of how things works while fixing errors.
This. The arch wiki is a treasure trove of information. The more you do, the more you’ll learn.
Also, don’t blindly copy paste configs for editors or window managers. Just slowly build them up based on your own use. It’ll be painful initially but worthwhile in the long run
I think I will try something like manjaro first see what it’s like and then move onto arch.
That was exactly how I did it some years ago. After 4 or 5 times fixing the X-server after an update (thanks nVidia!) I switched over to Arch. Installed Arch following the Wiki for about 2 hours… failed and started the process of installation again (in about 1.5 hours :P) and succeeded. By failing and trying again I’ve learned a ton. My advise for less frustration: go with Team Red. In my experience AMD graphics cards are much more linux-friendly.
see this post for my experience with amd lol.
Read through it… strange.
Certainly a worthwhile endeavour. But I’d recommend doing it in a VM or a secondary machine before jumping right in on your main computer.
+1 for installing Arch. If you have enough knowledge of Linux to understand what Arch is and why it is, comparatively, a more involved installation. Then you’re probably ready to install it. As was mentioned in another content, long as you know the basics, it’s not as hard as you might think. Also as suggested in another comment installing in a VM or spare hardware is good practice.
As for learning, take the time to understand the commands you’re copy/pasting. Read the man page, see what the flags you’re pasting in to. That might sound daunting at first, and you might not always be able to completely wrap you’re head around it. But you’ll learn more and more over time.
+1. and yes use the wiki not the install script.
I think theres value to anyone with a genuine interest if they just have a go at an archinstall - I think they can setup most things of interest in a Qemu(vm), or a spare partition, or even a usb or something. Theres nothing to lose but time. I’d recommend the user knows enough about their disk setup and their incumbent boot manager so as not to screw up their main os. Though i’m very tempted to say that’s a rite of passage.
Of course everyone already has a regular backup(s) which contains some sort of list or script for all the software, configs and tweaks they normally do. If not - well another rite of passage.
One thing you could do is start trying to understand those commands.
Read the man pages or the documentation to figure out what the commands are actually doing. Once you have the “what” , you can dig deeper to get to the “why” if it isn’t obvious by that point.
After enough of that, you’ll go to copy/paste and already understand what it’s doing without needing to look it up again.
Then from there, it’s a matter of building the instinct to be able to say “I need to do X, so I’ll use commands Y and Z.”
man command
and just read through it. If you want less text, usecurl cheat.sh/command
(learn how to use aliases) or the toolstldr
andcheat
Note: use the man for these tools and often multiple tools do the same thing
Not a good idea if the goal is to learn more about Linux. Fish is not compatible to and is different to Bash in some ways, that it would be hard once not using Fish. Also getting help or sharing scripts with others will be problematic, when having a problem and researching it. For someone coming in to Linux and wanting to learn about it, I highly recommend to learn about Bash first and use it at least for months before even thinking about a custom shell. I used Fish too (and I miss some features), so its not like I wouldn’t know what it is.
Alpaca is nice. GPT4All is also another one (and one that I prefer). Either way, both are good. But again like previous point, I do not recommend to install and use Ai modesl (LLMs) to learn about Linux and to get used to it. Especially the smaller models often hallucinate and lie with false claims. If you don’t know it better and are currently learning, this could be a problem. I highly discourage from installing and learning with an Ai model alongside when you are new to a topic like Linux. Its also not like there wouldn’t be enough good material out there anyway.
Fish is just a shell, you can still write and execute bash scripts
Fish is rewritten in Rust btw
Also the syntax is waay better, it should totally replace bash
My point is that Fish is not standard Linux tool. If the goal is to learn more about Linux, it makes more sense to learn about Bash first. I’m not against Fish. For a newcomer its just confusing when researching stuff or reading others scripts in Bash and constantly think about the differences in Bash and Fish. Or if you want to share a script with someone who does not have Fish. I’m not saying Fish is bad or anything like that. I’m just saying for a newcomer its not a good idea to ignore Bash and learn Fish first for someone who is interested into learning more about Linux and its eco system. Fish itself has the better language, no doubt about it and is actually better than Bash. But the quality is not my main concern in the reply.
As I said. Fish can just be a shell. I only write bash scripts. All bash scripts have
#!/bin/bash
at the beginning so it doesnt matter.I dont know about fish errors. If something doesnt work, I enter
bash
and then run it again. I enterexit
when I am done.That does happen but the workaround is easy
Apart from that, instant suggestions, history, arguments and available commands already help a lot.
That’s the exact problem. You deal with two languages. I did that too BTW. Now for someone who is experienced, its fine. But for someone who just started learning about Linux and scripting, its not ideal, as it adds unnecessary complications and friction for a learning process that is already complicated. Because learning Bash is a must do in my opinion. Regardless what custom shell you use.
After that learning process and getting familiar, one still can decide to use Fish as the interactive shell. But that’s AFTER the initial learning process of the basics of Linux.
I dont get why you shouldnt use fish to run your daily commands, and bash for the scripts. I rarely do anything fancy in the terminal that would be bash specific.
I just learned about Fish from another Lemmy post and here it is again!
discuss.tchncs.de/post/27617255
See if your library has "How Linux Works" - https://www.amazon.com.au/How-Linux-Works-Brian-Ward/dp/1718500408
For one, stop copying and pasting commands and start learning about the basics of the shell.
Here’s a basic tutorial from UC Berkeley: computing.stat.berkeley.edu/tutorial-using-bash/
Things you’ll want to focus on:
Then once you learn to do some basics, I would hammer repetition. Just force yourself to do things you would usually do via GUI by command line. I started with the basics of updating my system way back in the day with
sudo apt-get update && upgrade
Just type type type type all those commands until remembering them is muscle memory.
For learning purposes, also try not to use aliases. Because using alias would undermine the learning process of knowing what and how its been done. I recommend (as you said) typing it out over and over again and use aliases on a later stage of your Linux learning only (maybe after weeks at least).
Exactly, shortcuts like aliases or tab completion really should be saved for after you’ve familiarized yourself, so you’re less likely to make a mistake or tab complete to the wrong command etc.
Just don’t copy paste the commands. Really! Just take the time to understand what the command does, read the manual, and rewrite it yourself instead of pasting it. That alone will help a fair bit and can start guessing what it should be.
After a while of doing that it stops being a “paste this command to make the service run” and becomes “ask systemd to enable and start the service”. You start associating editing files in
/etc
with “will probably need to slap a sudo in front of that one”, you start mentally replacing nano/vi/vim/emacs/nvim/sed with your preferred way of editing the file, because you absorb the concept of “this command edits a text file”.It sounds a bit nerdy, but dedicate some time just to learning a specific command once in a while. Start with something straightforward like
ls
. Read through theman
pages and try out all the different options for it. After a while, you’ll master quite a few commands and will be able to string them together to perform more complex tasks. It’s definitely easier learning the system piece by piece like this. I used to learn by just jumping right in to a complex task, but I ended up with just a superficial understanding most of the time. Now days I try to be more deliberate about reading all the documentation and actually learning the tool/command/etc.Also, Arch has the
archinstall
script that greatly simplifies the install process if you need it. You’ll definitely learn more doing it manually though. I’ve been using Arch as my daily driver for a year now and I love it.Command line cheat sheet (with bonus vim controls):
<img alt="" src="https://lemmy.world/pictrs/image/4e689ec5-6bf4-4137-b8c0-975d09438684.png">
That’s kind of awesome, thanks!
And stop copy/pasting them. Type them out so you get used to them. It gets quicker the more you do it.
(͠≖ ͜ʖ͠≖)
Wait I did this to my main drive everything went black is this suposed to happen? will it start working again?
in case you aren’t joking, rm -rf / (albiet with a warning now) will delete allll the files on your system, so everything going black is the expected result.
rm is remove, the - is to indicate that you want to pass arguments, and r&f are recursive (delete stuff in the folders in this folder) and force (don’t ask for confirmation). The slash afterwards designates the root folder, the folder with everything in it.
So “rm -rf /” means “remove, recursively and forcefully, everything in the / directory”
@Blisterexe @pineapple , after making a snapshot of VM. Sometimes, I do it just for fun and then roll back to the snapshot. Fun times.
it is a fun command to see happen, i agree
Install TLDR pages from your package manager to get easy access to the most useful information
tldr.sh
If you’re not already, use it as your main system. Don’t dual boot. Stop using windows and mac. When you run into something you need to do, figure out how to do it on linux. It will be slow going at first, but after a few months you will pick up more productivity than you had before.
Another commenter recommended the fish shell, but I disagree because fish is not posix compliant. Almost all of the shell script examples that you will find assume posix compatibility and will usually have to be modified to run with fish. Once you get comfortable with a posix-compliant shell, then maybe consider fish or another “modern” shell.
On the topic of shells, read the bash manual. It’s long and informative. You don’t have to memorize it, but be aware of the different concepts there, and refer to it when you need to. It’s pretty horrible as a programming language, but it’s what glues most of Linux together.
I am still dual booting because some games I play just don’t work properly but other than that I am doing everything I can on Linux.
To be honest, this is my recommendation as well. If you kill Windows and can’t play your favorite games, then its more likely to give up Linux.
I learned a lot by using a less common distro (solus). When I would have a problem, the solutions I could find on forums or arch wiki wouldn’t apply to my distro directly, and I would have to look into the solution for long enough to understand what needed to change in order for the solution to work.
You can probably do this on any distro, just by not using commands you find online until you understand what they’re doing and why that might fix your problem. Arch wiki is a great resource for any distro, even though it won’t always be accurate for the distro you’re on.
I have been using Linux since the early 90s. I don’t know it all. I read man pages. I use -h or --help. I read the arch wiki. I read docs. I read source files and examples. Lots of reading. You will never know it all. There is too much information.
You need to know how to find information. It can be tricky. Knowing how to ask the right questions often requires you to know a bit of the answer.
Stumbling about trying to find answers is training the skills you need.
I think it helps if you have a programming background and IT support experience. Not just because you will understand more concepts and terms but because you have already developed some of those skills but some people come from other backgrounds and pick things up really quickly because they have well developed research skills.
Explainshell.com is pretty useful for understanding shell commands you might find on forums.
Incrementally over time by reading the documentation and/or manuals of the commands I need to run and looking up how others solve the problems that I need to get other ideas about things (even, periodically, for things that I already know how to do to see if anyone has found a better way to do it or if a new tool has come out that helps). And trying things out/experimenting with different ways of doing things to find out what works well or not.
To be honest I’ve been using Linux for years and I still paste commands all the time. The only difference is that now when I am trouble shooting I know what command I need just not the options and how to use it
Another book rec: pragprog.com/…/small-sharp-software-tools/
Attempt an Arch install entirely from memory. You might want to try this in a VM, in case something goes wrong, but just do it. If you can’t quite remember what to do,
man
andls /bin
are your friends.Sorry man I said I was a beginner I have never installed arch before that was more like an end goal I am not there yet I should have said i’m just running bazzite atm.
Sure, maybe I was a little ambitious. But my point is mistakes can bring learning, so it might be worth it to try something “hard”. Trying things in a virtual machine is also often a good idea.
Arch Linux Handbook on internet Archive
More than anything, what leveled up my Linux knowledge was switching to Gentoo back while I was in college.
Before that, I used SuSE, and I switched specifically because I felt like I wasn’t learning anything really about Linux just by using point-and-click tools like YAST.
I’ve used Arch for the last… 7-ish years? (Though now I’m basically in the process of switching back to Gentoo. In terms of learning Linux, Arch is… close to as good as Gentoo for that purpose. Not quite as good, but pretty close.)
As for the best approach for learning, though, you know how they say the best way to learn a language is “immersion”? As in, to move to where they speak the language. In the same way, if what you’re going for is to learn, just take a dive. Install Arch over top of your current OS and don’t look back. Just commit to it.
Also, use the most minimal stuff you can. Skip KDE and use dwm. Skip the login manager and start your GUI from the command line. Don’t install a file manager and instead use Bash directly. (It’s more than capable.) Don’t install anything you can do instead with a Bash one-liner or a small Bash script. If after you’ve gotten pretty used to minimal stuff you still want something that the heavier alternatives offer, you can of course switch, but if your aim is to learn, avoid using the kind of stuff that tries to be “user friendly” by hiding all the internal implementation details from you. (Instead use the stuff that is user friendly by virtue of having so few moving parts that understanding how it works under-the-hood is trivial.)
And, don’t settle for “it’s fucked beyond repair.” If it’s fucked, google your ass off. If that doesn’t work, ask on the official Arch forums or here or wherever. (Don’t worry, they don’t bite.)
thanks for the required motivation! i started to settle, i will try arch today after i am done with my exams.
CC: @pineapple@lemmy.ml
Good luck! I’m honestly a little jealous of you getting to start this journey for the first time!
Is bash ultimately better than dolphin or another file manager? I always thought that it just seamed slow having to read things out with no icons and having to type the filename instead of double clicking. And I have been avoiding installing applications through terminal because I can’t find how to properly uninstall them including all data (the fedora software center does this really easily) I have also had some trouble going further back that my user folder in the terminal I still havn’t figured out how to do that. Lastly what are some “user friendly by virtiue of having few moving parts” distro’s that you recommend?
Google “tab completion”
Legend
Yes. (Disclaimer, some statements contain opinion.)
OP was specifically asking how to learn more about Linux. And it’s nearly unquestionable that OP is going to learn more about how Linux works if they use the lower-level tools rather than take-you-by-the-hand point-and-click-adventure programs your grandmother could probably figure out.
So, again, this is just me spouting my own preferences here, but I don’t often touch the mouse. Moving my hand from keyboard to mouse takes time. I can use a keyboard shortcut to open a terminal, cd into the proper directory (using tab complete and
set -o vi
to make things quicker still), and start dealing with files much quicker than I could navigate a menu to get to, say, Dolphin, wait for it to load (if you use a minimal terminal, it should load basically instantaneously), and then start navigating.Not sure I can help you there. I’ve never used Fedora. I used CentOS once for a short time, but it was a long time ago and I basically don’t remember it at all.
Like, to the parent directory of your home directory?
cd …
should always go to the parent directory of your current working directory. (/
is its own parent, I believe, so you can’t go any further up the chain than that.)Gentoo and Arch. I’ve never used Void, but it sounds to me like Void is very minimal (has few moving parts) while also being much less of a learning curve than Gentoo and Arch.
When I say “few moving parts”, I mean, roughly speaking, fewer lines of source code. KDE (just for instance) is a huge beast. It tries to accomplish user friendliness by adding layers upon layers of abstraction, in the process obscuring what’s really going on at lower levels from the user. It… doesn’t really work. What it gains you in reduced learning curve becomes an obstacle the moment something goes wrong or you want to peek under the hood. Ubuntu (just as another example) installs tons of stuff to try to shield you from the nitty gritty details. But again, that causes more problems than it solves unless you’re dead set against ever looking under the hood for any reason.
The term “user friendly” tends to mean “my grandmother can use it without having to learn anything in the process.” In the comment about “user friendly by virtiue of having few moving parts”, I didn’t mean “user friendly” in the same sense. I don’t think “user friendly” in the more common sense id mutually exclusive with “fewer moving parts.” At least not in theory. But in practice, that does seem to be the trend.
Yes I am op.
and thanks for the reply. So I guess I should just skip anything with a desktop environment like manjaro and just figure out how to install bare arch?
Yes
cd …
was what I was looking for thanks!You can try Slackware.
Or LFS for a full zero-to-hero experience.
Ha! That’s what I get for posting on Lemmy at 2:00 am. Lol.
You can certainly start with a bare Arch install and install on top of that a graphical environment. (Without a graphical environment, you wouldn’t be able to run a full-featured browser like Firefox or Chromium or whatever, for instance. I’d think if you intend to use this system as your daily driver – and I’d recommend you do for learning sake – you’ll probably want a graphical environment.) But, yeah. I’d say Arch isn’t that unapproachable to install without going the Manjaro route or the “archinstaller” route.
With Arch, everything’s just packages. The difference between non-graphical Arch and graphical Arch is just that non-graphical Arch doesn’t have any graphical system packages installed.
Now, I keep talking about “graphical systems”. There are two ways to go with that. There is X11 which is mature but a bit dated. And there’s Wayland which is the new hotness but support for it is still a bit lacking, so some features like screen grab may not be supported by all programs and some programs won’t work as straightforwardly on Wayland. (Basically, any time a program grabs an image or video of any portion of the screen of your graphical environment, that uses the “screen grab” API. Wayland does that differently than X11, so a lot of programs aren’t updated to use Wayland’s way yet.)
I guess I’d probably lean toward recommending X11 at this point. I personally use a Wayland compositor (Sway, specifically), but I don’t think running Wayland is going to teach you much that X11 won’t, and running Wayland at this point is likely to introduce frustrating wrinkles. If after you have your Linux “sea legs” you want to try switching, that’s always an option as well.
As for minimal X11 environments, first off, I’d say avoid things that describe themselves as “desktop environments”. They’re likely to hide details from you. Prefer “window managers.” Tiling window managers tend to be more minimal, but if you want to go with a more draggy-droppy, mouse-driven window manager that feels more like what you’re probably used to (but also doesn’t hide details), I’d recommend IceWM.
And, finally, as far as a “bare Arch install”, the place to start is the install guide on the Arch Wiki. It goes step-by-step on how to do things. And take the time to understand the commands you’re running as you’re running them. There are a lot of links in the install guide to more in-depth articles. For instance, the “partitioning” section links to an article called “partitions” that goes in depth on what a “partition” even is.
There’s a lot to learn, but it also pays off. Both in terms of just having the power to do the stuff you want with your own systems and in terms of benefits to your career. And it’s just plain fun!
Thanks, I guess I will go with x11 with a tiling window manager, I’ve had enough of windows being on top of each other and I like the idea of using my mouse the least amount possible. One last question most apps and packages don’t support pacman sometimes the only option is to install with apt and you download a .dev file is there a way to get around this?
Great question!
So, first off, if I knew what app(s) specifically you have in mind, that’d help me answer better, but in general:
makepkg -sf && sudo pacman -U <something>.tar.xz
. You can also get some helper scripts that do some of those steps for you for convenience. Definitely worth having the experience of doing it manually a few times first, though, I’d say.) Even if the only way to get the software in question from the publisher is in .deb form, you may still find a package on AUR that will unpackage the .deb and package the result up into an Arch package.$HOME/install/<softwarename>
. This can work even if the software is only available as a .deb file. You can just extract the .deb without installing it with the commandar x <blah>.deb
and atar -xf data.tar.gz
and then put the files from within that .deb file where you want them.Thanks for the reply and I will definitely use some of the less advanced options for now.
When you are doing stuff in the terminal write it down somewhere else also, on a piece of real life paper or in a simple text document or whatever works for you.
In general I found taking notes while trying to do things in the terminal helped me learn.
I will be using your example of Arch as a great stepping off point, because honestly imo the best way to learn is by having a project to work on
RTFM - Read The Fucking Manual. Read the docs, read the code comments if need be. In the case of installing an OS, use the installation guide as a starting point; Arch’s is on their wiki, and links to several other sections that go more in-depth about what each step does and why it does it.
DuckDuck it - if you don’t understand what something is or why you’re doing it, search it. If you understand it completely, search it anyway and check the docs because no you don’t, you just don’t know how little you know. If you know why we do something and what function it fulfills, but not how… Then you’re a power user.
Using your example of commands from the internet, break the command down into as many parts as you can, and figure out what each part does. If there’s punctuation marks, don’t assume you know what those are doing.
man [command’s name]
is your friend.Do all of the above as often as possible, no matter how slow it makes progress feel. Learning these things the proper way now will save you from days, weeks and months of troubleshooting in the future. I mean it, literally at every step of the process.
secondary sources are invaluable, but for this it might help to get into the best way to self-educate. The only gospel are the docs and/or manual that were written by the code/OS maintainers - primary sources - everything else is opinion.
Here’s a source i agree with on the best way to self-educate, but keep in mind even Artem is still just a secondary source.
That being said, here’s a few secondary sources that helped me understand how OSes work and why:
nand2tetris: build an operating system starting with logic gates and working your way up from there. It has a offshoot site that’s slowly being rolled out, that implements it all in a gamified interface: nandgame
os-tutorial: build an OS from scratch
Linux From Scratch: Learn everything about Linux by building your own distro from the kernel up.
Unfortunately everything that taught about the behind-the-scenes aspects of OSes in general—and Linux in specific—were either projects like the above, or just seeing what came up in a DuckDuckGo, Youtube, forum, or wiki etc. search. Below are just resources that teach you about the “power user” level of knowledge, not “super user” but not your average user either.
Fireships’ 100+ Linux Things you Need to Know: it’s not particularly good on its own, but it does introduce a lot of concepts and vocab for you to then look up elsewhere
freeCodeCamp.org offers a lot of courses that will go over using Linux. None go too in-depth on the fundamentals of Operating Systems, but they will still introduce most of what you need to know for day-to-day use. I don’t want to link them all, but just search for
linux freecodecamp
on youtube and find one that piques your interest. The longer, the more in-depth—you don’t have to watch it all in one sitting.I use searx. Ok but seriously very helpful I will look into that.
great idea, I’m gonna give it a go
Using
tldr
to learn commands. It gives you the information you are probably looking for in the man page but it’s not buried among lines and lines and lines of arcane stuff and it’s formatted in a readable way with helpful examples. Saved my sanity more than once.I’m not saying “don’t read the man pages”, they are great way to get a deeper understanding of commands. But when you are just wondering what a command does and how it’s commonly used, then a two lines summary + example is much more helpful than an essay going in minute details over everything.
Since it takes a lot less time than hunting the same info in the man page, you can run it before every command you are not familiar with, without too much hassle. Then if you want more info you can check the man page.
erasure edit: ok nvm, thanks
My advice would be look up The Missing Semester it’s a free online MIT course on how to use the terminal and it will govern you a better understanding of how to use it and Linux more generally. Really helpful to find your way around and give you an intuitive sense of what you’re trying to achieve.
Then beyond that installing arch is easy with archinstall but it’s probably more helpful to learn about the components of desktop Linux and what they do so that you actually know what you’re doing.
on the tailend of a convo in in a discord recently I added a command to the “customize chatgpt” section to allow chatgpt to have a custom “man” like command similar to linux, but that works for all code or commands.
This makes chatgpt give me a Linux command or code snippet formated in a table explaining what each piece of the command does.
.
Start running servers if you haven’t already. Use an old computer, or an SBC or VPS and setup some Linux servers. There’s lots of different ways to do it, so mess around and break shit over and over. You can’t help but learn that way, though I would highly suggest you take notes/documentation. This is a habit I’m trying to develop after too long :)
Why? I have been using Linux for nearly two decades and I am perfectly content with a low-config distro and desktop environment. You don’t have to use Arch but if you insist get a Steam Deck.
I just want to get a better understanding on linux and I think arch is the way to do it. I love computers and I want to know them well.
Do you want to know how it works internally or how you can administer it more effectively? The two are very different. I was always more interested in the former than the latter and at one point read through Linux kernel 0.1 source code. I want to know how a kernel and a file system works but I can’t be bothered with configurations and shell scripts. The good thing about Linux whatever you want, the resources and the source are available.
Good luck.
Here is a bunch of random tips to become more comfortable with the terminal.
Do absolutely everything that you can on the terminal.
When you install something, enable the verbose if possible and snoop around the logs to see what is happening.
If an app or an install fails, look at the logs to see what is the issue, and try to fix it by actually resolving the error itself first instead of finding the commands on the internet to fix your issue.
Instead of googling for your command options, use the help menu from the application and try to figure out how to use the command from there.
Just use it and fix things when they break. There’s no magic bullet - just experience.
You learn by doing and by failing. Like we learned to walk, to write, to drive, to kiss, to speak a foreign language, or even to lace our shoes (and, yep, even that was a heavy trial and error process for toddler-us back then).
Learning takes time and efforts. Perseverance, and humility. There is no shortcut to learning anything that is worth learning, not just Arch. But the reward is also so much worth it. Einstein had to learn calculus, Da Vinci had to learn how to hold a paint brush, and Tolstoy like Flaubert had to learn to write and I’m willing to bet they all made mistakes while they were learning their respective craft.
Even without referring to geniuses: the first time I tried to install Arch I ran away screaming and swearing I would never touch that thing again. The second time, I had already managed to read a good chunk of the relevant part of the wiki and used it constantly at each step of the process. I still failed at it but at least I understood why I failed and I felt incredibly more… in charge, despite me failing. The third time, I managed to have it running, and to install most the packages I wanted. That was great. There was no fourth time as, as much as I love Arch (which is a lot), I quickly realized using it that constant updates were not what I wanted from my OS and apps (I’m an old-ish user with very basic needs, I’m not even that much of a geek to be honest). So, I switched to the complete opposite of Arch (Debian, another great love of mine I must say). Still, learning and using Arch taught me a lot about Linux in general and about… myself.
This is really good advise and it all boils down to one attribute. Patience.
Don’t get disheartened when something does not work the first time. Take a step back. Look at what went wrong and then try again, hopefully without doing the same mistake again.
Learn the basic tools of Linux and Bash/Posix. cd, ls, cp, mv and rm are some very basic tools, but it is what we use 80% of the time.
Thx. Yes, patience is key. As is the ability to
Failing is fine because it’s not about us, it’s not personal. It never is. It’s about learning something and about the process.
I ran Gentoo for several years. It wasn’t Linux From Scratch but it did required a lot of manual work. It also had great documentation. It forced you to learn all of the pieces encompassing the entire OS.
Arch seems to be the modern equivalent.
Gentoo’s still around and quite modern. And USE flags are addictive.
Linux is like kung-fu, mastery comes through practice
Learn the ways of Linux-fu
I’m going to go against the grain a bit and suggest studying for a certificate. Find one that looks interesting, and just prepare for it. You don’t necessarily have to get the certificate, but training for it will give you a good foundation for running your systems.
hackr.io/blog/best-linux-certifications
Haven’t seen anyone mention overthewire.org/wargames/bandit/ yet. It’s a Linux shell game where you need to solve problems using shell commands that only requires an ssh client on your machine: you ssh into the first server, solve a problem, and the solution points you to the next server. It starts easy (e.g. read out this file using
cat
) but gets hard quickly. But you can always look up solutions when you’re stuck. It gives a good idea what certain commands are used for and how they can be combined in powerful ways.This reminds me of a site called hackerslab back in the 2000s. I think you had to ssh in to some Korean server and try to get the password for the next level.
I can tell you how I learned linux. be prepared to cringe.
I installed Linux before going to school, I figured that if I used Linux as my main OS I would be less tempted to dick around and play games
I eventually found a coop part time job as a dev. I used my own Linux machine, and being the star eyed young person I was I used arch.
this is the cringe part:
I learned systemd, Linux kernel modules, dkpg, obviously more familiarity with bash and shell stuff
so moral of the story is… dive in?
Purely just send.
You ain’t gonna learn to swim in the wading pool, take a leap and break something.
It’s like any job - you can be talked to about x, y or z until the cows come home but until you stub your toe on a specific issue it’s mostly just fluff.
I’ve committed unencrypted secrets to codeberg, deleted boot partitions without rebuilding (nixos), tested most Linux distros until I got comfortable.
Dumb mistakes are bound to happen (I feel mostly to me) but you don’t learn without seeing the repercussions. Linux isn’t scary - closed source crapware is; no matter how “user friendly” it’s made out to be.
Edit: formatting
“I take full responsibility for my Arch system.”
For getting better at terminal I would suggest looking into alternative shells. Bash is fine, but it’s not exactly user friendly by default. Something with more robust auto completion like zsh or saner defaults like fish could make the learning experience easier. You can always come back to bash later.
For understanding how the OS works I would start by reading about the file system layout, then look into the init process.
I got to the point I am at through a series of projects of increasing complexity. First I ran a web server on my machine to copy files over the network. Then I used a spare PC to make a simple SMB server. Later I made it into a HTPC pirate box, for streaming stuff downloaded off Usenet to my Xbox. At some point I ran a minecraft server (before docker came along and trivialized this), and got into a bunch of sysadmin and programming stuff and that’s pretty much it.
Just out of curiosity, do bash script work in zsh? Or are they totally different things and are not cross compatible?
Depends on what it is. If it’s meant to be mainly used in the shell I will usually use whatever language the shell uses. Anything that’s run automatically usually gets done in bash for compatibility, and stuff more complicated than a few loops and some piping gets done in something easier to work with like python.
programming.dev/c/linuxupskillchallenge
I’m annoyed with myself for not thinking of doing this
If you are beginner in Linux, try beginner-friendly Arch-based distro: EndeavourOS, CachyOS, Manjaro
You can learn Arch without too much hassle while using one of them
EndeavourOS is great ! While it’s easier to install than Arch (I guess?) and give you tools to maintain your system, it’s still in need of daily maintenance to keep your system healthy and operational.
You learn things but at slower pace and with less headache as a beginner. I’m very thankful EOS exists and give you a glimpse on how to configure/maintain and evolve with the Arch ecosystem !
Learn FreeBSD.
Learn Linux.
/s
I’d recommend reading man pages. They’re a great way to understand the programs that are on your system. The Arch Wiki and the Gentoo Wiki both provide additional information that may be of use to you.
Running an OS as a virtual is liberating. Dive in, make mistakes, fix them (or not and have to reinstall or redo from the last save). No real consequences for exploring.
This course by the Linux Foundation goes over the basics and I thought it was pretty good. I was a long time user of Linux when I came across this and wanted to see how much I really knew. It’s very easy to follow and well structured
…linuxfoundation.org/…/introduction-to-linux/
If you’re in the position to take certificates then that’s a another way of learning a lot. At least it has worked for me. I’ve over the last half year taken RHCSA and RHCE from RedHat - though paid by work. Theses in specific are expensive, but I’m sure there are other ones that are cheaper. This would also allow you to ‘show off’ your skills in an official way should you need to, for applying for certain jobs etc…
I at least find this way to be helpful as you have to motivate yourself to learn and pass an exam to get the certificate. It might not be for everyone though.
If you want to get better at Linux terminal and standard unix commands I would try overthewire.org/wargames/bandit/
It’s an interactive tutorial which will help build basic skills. There are a million guides and walkthroughs for this, but I would try each level on your own first before you look at a guide.
Switch to rolling distro, it will break so many things with each update you’ll learn stuff by fixing it. Also you can check overthewire.org/wargames/bandit/
I thought rolling releases were still pretty stable to things really break that often?
They can be really stable. I think your milage severely varies on how much you know what you’re doing and how careful you are in respect to certain things.
Personally I’ve been using Arch for 5 years and I haven’t really had any problems with things breaking on updates.
I’m late to the party but have you seen Linux Journey? linuxjourney.com
Thats really cool thanks.
The tldr cli (tldr.sh) is a great way to get familiar with options of differ programs.
Very useful, even for someone who has been using Linux for many years. Sometimes you just forget or need that tool you rarely use.
tldr
can be much handier than parsing a man page when you’re in a pinch.I use the tealdeer implementation, but any is fine really.
Install harder distros (preferably on bare metal) and use them. If you need to fix something, google it. This helped me a lot.
I still find Tealdeer useful even now, it helps me get working with commands I know little about, more so than a manpage
Oh that’s pretty cool! Basically a better version of tldr?
Read and do! If it’s just a toy you play with sometimes, you might find learning harder. I find that making it your daily driver will motivate you to improve and fix things and in doing that you’ll learn.
start from
man man
and learn to use man pages. Get used to lookup man pages for any topic before checking on the internetThis is it. You’re likely not going to get away from needing help from time to time. Instead of focusing on trying to know everything, focus on knowing where to find what you need. It’ll click from there with time.
Learning to read manpages is honestly the best advice. They are pretty dense in information, so maybe that’s why some people go to great lengths to run circles around them looking for inferior sources of information.
With arch, I’d recommend just jumping in the deep and and installing it, looking things up on the wiki when something goes wrong. Just do it in a virtual machine or on an old laptop or something to start with. I broke my previous distro (mint) by doing some really stupid stuff, and I decided to just go fuck it and install arch. I don’t think I’ve ever learned as much about linux as that weekend.
I suppose that I was already pretty comfortable with the terminal since I was studying computer science at the time so I had a lot of reason to use it. I think the best way to use the terminal is to force yourself to use it, programming is great for this but you can try e.g. sorting your photos or mp3 files or something as practice too.
.