In this podcast episode I recorded before having an actual name for this podcast, I interview Roko Jelavić. He is a former MIRIx event organizer in Zagreb, Croatia and a software developer who worked in areas of “regular” software development, machine learning and blockchain. We talk about blockchain, Artificial General Intelligence (AGI) and the theory of everything, among other things.
Find it here:
Hope you enjoy! Let me know what you thought about this podcast episode.
I wanted to clarify a term, which is Linux distribution. Linux distribution is an operating system made from a software collection that is based upon the Linux kernel. (“Linux distribution,” n.d.)
What does that mean? That means that all Linux distributions have the same kernel (which, as we discussed, is the central part of the Linux operating system), but they differ in the software which comes supplied with them.
Which Linux distribution should you pick? I can only recommend what I used so far – either Ubuntu or Debian. There are a lot of others, so feel free to pick the one you like. I prefer Debian over Ubuntu, but again, feel free to pick the one you like.
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.
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.
Hope you learned something useful!
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:
Let’s look at each one in turn.
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.
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.
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 “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.
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!