What is the difference between the superuser and the regular user? The superuser (also known as root) has some extra privileges on the Linux system. (Ward, 2014) For example, if you are a regular user and you try to modify some system files, you will most likely not be able to save them and get “Permission denied” error. That’s because system files are only accessible by the superuser.
So the superuser is the most powerful user on the Linux system. Other users aren’t as powerful (meaning they can’t modify some files and can’t execute some commands). But guess what – that is good. “How can that be good?”, you might wonder. Well, imagine you downloaded a malicious piece of software that tried to modify your system files and you are logged in as a regular user. When the malicious piece of software tries to modify some system files, it can’t, because a regular user can’t modify them, you are running the program as a regular user and thus the malicious program can’t modify the files. I am not an expert in information security, but I remember this example being tossed around in some of my college classes, so I decided to put this in.
Hope this helped clarify the difference between the superuser and other users.
References
Ward, B. (2014). How Linux Works: What Every Superuser Should Know (2nd ed.). No Starch Press. Pages 9-10
User space is the space that “normal” processes use. System space (aka kernel space) is the space that only the operating system can use.
See, every program has to be stored in random access memory (RAM). That means that the operating system also has to be stored in RAM. (Ward, 2014) So the operating system uses the RAM, user programs (your normal every day programs such as Mozilla Firefox) use the RAM, everyone uses the RAM! Now, the thing about the operating system is, because of security reasons and because of potential issues, it limits the user processes to a part of RAM called user space and the operating system resides in a different part of the RAM. If any process (process being another word for a program you have started on your computer) tries to access any part of the memory which is not its own, it can’t. The operating system makes sure of it. The figure below should help clarify things.
Figure 1 – System and user space (my own illustration)
Hope you learned something useful!
References
Ward, B. (2014). How Linux Works: What Every Superuser Should Know (2nd ed.). No Starch Press. Pages 8-9
This quick post serves one purpose – to tell you that users are the people who use the computer. More specifically, every user has (or at least should have) a user account associated with him/her. That means that multiple people can use the computer and it is desirable that each one of them has their own user account, because Linux makes sure that users can’t access each others stuff.
As described on page 4 in (Ward, 2014), the kernel, which is the core of the operating system, deals with the following four things:
Processes
Memory
Device drivers
System calls
Let’s look at each one in turn.
Proccesses
The kernel starts, pauses, resumes and terminates processes. The kernel is also responsible for giving processes the hardware they need to execute the thing they were programmed to do. That’s why we need hardware – we need hardware to actually perform the calculation the programmer intended it to do. The kernel decides which process gets what hardware at what time, as there are multiple processes running at the same time on the computer. For example, you most likely have a web browser open, as well as a File Explorer, as well as something else.
Memory
The kernel makes sure to:
give memory to a process
check if the process is only accessing its own memory and not some other processes memory
clean up the memory after the process terminates
When I say memory here, I mean RAM, that is, random access memory. Think of RAM as storage space – every program is stored in RAM as it is executed. The kernel makes sure to give each process enough RAM and to free up the RAM when the process terminates so other programs can “step in” the newly vacant storage space.
Why is it important for the process not to access other processes memory? Well, if it writes to some other processes memory, it could overwrite some data which may be really important for that process, which would be bad. There are other reasons, but since I am not a professional at information security at this point, I feel unqualified to talk about it.
Device drivers
The kernel manages the device drivers. Remember those things you have to install every time you install a new Windows on a computer that enable you to use some hardware (i.e. your speakers)? Well, two things about that. Number one, you (in most cases) don’t have to install drivers on Linux as they come preinstalled, so switch to Linux (subtle nudge into the Linux world, eh?). Number two, device drivers make it easy for programmers to talk to the hardware.
How is that? Let’s say I wanted to write some files to a hard disk. If I had a Samsung hard disk drive (HDD), and you had Seagate, the code for writing to Samsung HDD vs writing to Seagate HDD would most likely be different since they would have different hardware responsible for the task of writing to the HDD. Operating system allows me not worry about the details of the hardware. So instead of saying to the operating system “Write this to Samsung HDD” or “Write this to Seagate HDD” I just say “Write this to the HDD”. The operating system takes care of the specifics of the hardware.
System calls
System calls “call” the kernel to do something for them. For example, from my program (which is, let’s say, Firefox), I first tell the operating system to “write something to the HDD”. Then, the kernel takes over and writes it to the HDD for me and gives me some feedback on how did it go. Was it successful? Was it a failure? If it failed, why? Those are some things that the operating system handles for me.
In addition to this explanation, there are some terms frequently used when talking about process management. I list those in the References with relevant links if you are interested. Those are:
Wikipedia defines operating system as “system software that manages computer hardware, software resources, and provides common services for computer programs”. (“Operating system,” n.d.) In simpler language, operating system is the “glue” which enables applications such as Mozilla Firefox (from here on just Firefox) to communicate with your computer hardware.
Why would Firefox, or Microsoft Word, or any program, for that matter, have to communicate with your hardware? Well, let’s take the example of Firefox. Firefox has to somehow display the web page you request. How does it do that? Well, there are two solutions to this issue. The first one is believing in magic and just saying “It’s magic.”. But this post should help take some magic away.
Think of it like this – Firefox (a user process) exists on a certain “level” of your computer, as depicted in Figure 1.
Figure 1 – Operating system “levels” (modeled after Figure 1 on page 3 of (Ward, 2014))
In order to communicate with other “levels” of your computer, Firefox has to call certain operating system functions. So metaphorically it knocks on the operating systems door and asks – “Hey operating system, fetch me the data I just received in the network card, will ya?”. “Why wouldn’t Firefox access your network card directly?”, you may ask.A fair question. Two reasons:
It would be very difficult to program software that way; every software developer would have to deal with low-level hardware and that would be tedious. Also, imagine if someone wrote some code to deal with a certain piece of hardware and then someone else had to write it all over again for their program – that would mean every programmer has to start from scratch (literally) every time he writes some code
Imagine you are running two applications (let’s call them Firefox and Firefox2) and that both are trying to send some data over the network concurrently – uh oh. The data sent from Firefox and Firefox2 could mix together, creating some data that doesn’t resemble anything Firefox or Firefox2 tried to send.
This is why you call the operating system functions to interact with the hardware. They take care of the nitty-gritty details of communicating with hardware and make sure that there are no things such as two applications overwriting each others contents.
Put another way, operating systems are a layer of abstraction that eases programming in the upper layers of abstraction and makes programmers life more simple. They are the thing we take for granted today, but they are very, very, very challenging to make (program). Writing an operating system is super hard. I have never done it, but I imagine it is very difficult, since I have wrote some lower-level software and that was hard. So thank you operating systems (and operating system software engineers) for making our life easier. Hopefully after this post we will appreciate you more.
What is about to follow is a theoretical underpinning to the Linux operating system. I know that some people (myself included) don’t like to learn theory for its own sake; even learning theory that I may use in some abstract point in the future is something I don’t like to do.
However, these theoretical points are important. So make sure to pay attention when we talk about them in the following posts.
In this article, I will overview the Linux tutorial series. I will start this off by saying that I structured the post series so that you first learn the fundamental big-picture concepts and the most practical, day-to-day commands and then go deeper into the Linux system to understand it. As I stated in the introduction, there are checkpoints before each of the major parts of the post series, so don’t worry – this is just a big overview of the journey that lies ahead.
We start off with some basic questions – what is an operating system, how is operating system’s memory divided etc. Those concepts are essential for everything Linux. Then we will look at the basic commands you will use on a daily basis. This part is a bit boring, admittedly, but power through it. Then we will talk about some stuff you will also use almost daily, such as pipelines – a way for you to chain commands.
After that, we will talk about command types and how to find files. You will look for files often, so that’s why we cover that. Then we will talk about command history (so you can access what you have written before – way before) and variables.
Then we will talk about text editors. This part is optional for you if you are a “regular” desktop user, but I would advise you to read it if you are a computer professional, such as a software engineer.
Next up come processes – an extremely interesting part of the post series. You’ll learn what processes are and how to manipulate them. Then we will talk about file permissions, then compression and package management and then some more about files. You are in for a treat!
After that, we will talk about the boot process and the user space startup process. Very useful to know to paint the bigger picture of the Linux operating system. Then we have a whole bunch of topics we graze over, including computer network related commands and building a program from source. Finally, we talk about shell scripting.
I hope you are ready! Fill up your backpacks, put out the campfire and join me on the journey to Mt. Linux!
in the post series about to follow I will try to explain the fundamentals of Linux to you. What do I mean by “the fundamentals”? I mean explaining:
how Linux works as an operating system
commands you will use in your day-to-day
I won’t go into too much detail because when I was learning Linux, I was also focused on the big-picture, “what are the fundamentals” view. I can Google the details if needed. But if I lack the fundamentals, I will have a hard time using Linux in my day-to-day life.
But before we begin, you may ask yourself: “OK, but who are you anyway?”. Fair question. Now it’s time for me to take a trip back down to memory lane and tell you about me and my story with Linux so far.
Who am I?
My name is Mislav Jurić. I am a 23 year old Croatian, currently a Computer science master’s degree student. I worked as a software engineer on autonomous driving. I have started experimenting with web development since I was 14 and I went further into computer science from there. The reason why I am studying computer science is because my huge interest is artificial intelligence (AI). I have written a paper on AI safety, which is currently under review.
As I said, my primary interests include artificial intelligence and computer science. Why the heck am I talking about Linux? Because I use it in my day-to-day and I used it in my software engineering job as my operating system. Which brings us to …
My Linux story so far
I switched from Windows to Linux in 2017. if I recall correctly. Before that, I experimented with some versions of Ubuntu, but I would be using them for a couple of weeks, then switch back to Windows. When I switched to Linux for good, I switched to Debian 9. I used Debian 9 over the graphical user interface (GUI), almost never touching the command line. I understood some basic commands, but I kept delegating my to-do task “Learn Linux” into the future.
This was all fine and good until Debian 10 came out. When I was installing Debian 10, I had trouble configuring my touchpad and I remember looking for and blindly following the solutions to enabling my touchpad I found on Google. But I didn’t understand what I was doing. Someone could tell me to change something very vital to my operating system and I would maybe do it, because I had no idea about how Linux worked and what the commands were changing within the ecosystem of Linux.
When I finally fixed my touchpad (it turned out I just had to enable it by pressing Fn + F7 on my keyboard), I told myself that it was time to get serious with Linux and to read books about it to understand its workings. Another reason was that I was using Linux on my software engineering job.
I have learned about Linux by reading 3 books on Linux; namely (Ward, 2014), (Shotts, 2019) and (Barrett, 2016). I think those books gave me a very good perspective on how Linux works (that is literally the title of (Ward, 2014)) and what commands are essential. A side note: (Shotts, 2019) is available for free online (check the link in the References section). Also, when I reference (Shotts, 2019), I use page numbers that you have to type into your PDF reader.
I also worked as a software engineer and I used Linux daily on my job, as well as coming back home to my Debian laptop. So, I have experience using Linux both at home and in a professional environment.
Why this post series is different from other Linux courses/posts/tutorials?
I will list five reasons why this post series is different from other Linux courses/posts/tutorials. Here are they, alongside their explanation:
Paints the bigger picture – There are a lot of Linux tutorials, but I failed to find one that paints a bigger picture about Linux. By “bigger picture about Linux” I mean what are the various Linux pieces of the Linux operating system and how do they fit together. This is really important to understand so that you know what you are changing when you are changing something some tutorial is telling you to change. For this reason, in this post series I will talk about operating system related topics in a few places because they are the context you need to understand certain parts of Linux.
Focus on the fundamentals – There are a lot of Linux tutorials that go super deep into a topic. While using Linux in my day-to-day, I found that I don’t actually need the level of depth a usual tutorial or a book chapter provides. That’s why in this post series I will focus on the fundamentals you will use in your day to day – no more, no less.
Saves time – while reading the aforementioned books on Linux would be great, as I stated in the point above, you won’t be using a lot of the material you read. In this post series, I tried to “trim the fat” – to remove all of the things that are not relevant for your day-to-day use and general Linux understanding, but to still provide you with the entire puzzle piece which comprises Linux. This post series will save you time. You can always read more in-depth if you want or are interested in a particular part of Linux.
References (citations) – I provide references for almost all of my claims. That means that you can actually take the book (or the website link) in the references and follow it and see where I got my knowledge from. I feel that this is missing from a lot of tutorials and can lead to misinformation. This way, you can rest assured that what you are learning has been taken from a credible source and you know which source it is exactly. If you want to double-check something, refer to the references and see for yourself.
Computer science theory which deepens your understanding – I know, I know. Probably right now you are thinking: “Theory? No, thank you.”. But theory is important. Since Linux is an operating system, understanding how operating systems work helps a lot! Also, understanding why and how certain other things work is important. In this post series, I will go into the relevant theory when the need arises. Do not skimp on these parts – they will most likely be the parts that will cause the “Aha” or “Oh, I get it now” moments later on.
Who is this post series for?
This post series is for a broad audience – including, but not limited to:
someone wanting to switch from Windows to Linux for everyday use
a software developer who lacks solid Linux understanding
a wanna-be system administrator
a wanna-be hacker (information security expert)
someone wanting to learn more about Linux and actually understand what is going on under the hood
I think all of these groups will massively benefit from the posts coming down your way, because you will learn the fundamentals of the Linux operating system. Then you can expand into particular topics on your own, if you wish. The groups that will benefit the most are the Windows-Linux switchers and software developers. If you read the posts in this series, you will know that you are capable of using Linux in your day-to-day efficiently and you will understand what is going on “under the hood”.
Note: As was pointed out to me in a reddit post I made about this tutorial series, the material of this tutorial series doesn’t go in too much depth (at least at the beginning). Therefore, I think this tutorial series will be most useful for someone wanting to switch from Windows to Linux for everyday use. As this tutorial series progresses, the material discussed is more technical in nature, so if you’re a software engineer, a good strategy to watch this tutorial series would be to use checkpoints to determine whether you want to watch a particular part of the tutorial series and/or to skim or skip the parts you already know. As for the system administrators and information security experts, notice that I put the word “wanna-be” in front of it. What I meant by that was that anyone who is just starting their sysadmin or hacker journey is most likely going to benefit from this tutorial series. In short, if you already feel comfortable with the basics of the Linux operating system, this tutorial series will most likely not be of a lot of use to you. However, you can still skip or skim certain parts of it or use it as review material.
How this post series will be structured
This post series will be structured around introducing you to Linux fundamentals. After some meaningful segments of Linux have been covered, there will be so-called Recaps, where we review what we have learned and then there will be the so-called Checkpoints, where we motivate the topic we are going to talk about. I think both Recaps and Checkpoints are really important to make sure you got the main points and to get you motivated for the upcoming material, as well as to point out the most important parts of the upcoming material. Just to note: Recaps are not a substitute for not reading the posts. Read the posts as they are in the sequence and you are in for a joyful Linux-learning journey!
Ending notes
I am by no means a Linux master and in my opinion, my computer science career hasn’t even started (as I am still a computer science master’s degree student at the time of writing this). I still have so much to learn about all things computer-related. However, I am confident that this post series will paint a wholesome picture of Linux. If I ever need to use a particular piece of Linux in more depth (due to my job or curiosity), my working knowledge will expand and I could write another series of posts related to that part of Linux.
I encourage you to give me feedback and engage with me. I would like to know if you like the material, if you like the way the material is presented etc. Just remember – your feedback is more than welcome.
Hope you will enjoy reading this as much as I enjoyed writing this!
Talk soon!
References
Barrett, D. J. (2016). Linux pocket guide (3rd ed.). O’Reilly Media.
