mirror of
https://github.com/maciejpedzich/maciejpedzi.ch.git
synced 2024-11-27 15:45:47 +01:00
Remove redundant posts and scripts
This commit is contained in:
parent
b38b9a02e2
commit
6c0d28f6aa
GPG Key ID:
CE4A303D84882F0D
@ -1,5 +0,0 @@
|
||||
#!/usr/bin/sh
|
||||
|
||||
docker stop my_website && \
|
||||
docker container rm $(docker ps -aqf "name=my_website") && \
|
||||
docker run -d -p 8505:80 --network=my_network --name my_website maciejpedzi.ch:latest
|
||||
@ -1,164 +0,0 @@
|
||||
---
|
||||
title: introduction to linux
|
||||
description: Notes from the first two units of Michael Hausenblas' "Learning Modern Linux" book
|
||||
pubDate: 2023-08-25T15:22:00.890Z
|
||||
draft: false
|
||||
categories:
|
||||
- learning modern linux
|
||||
tags:
|
||||
- linux
|
||||
- notes
|
||||
---
|
||||
|
||||
Hey folks! Here are my notes from the first unit of Michael Hausenblas' _Learning Modern Linux_ book.
|
||||
|
||||
## Operating System
|
||||
|
||||
**Operating System** is a piece of software responsible for managing your machine's memory, file system, communication with I/O devices, network stack, and more. It also provides a set of **system calls**, which allow programs to interface with the OS.
|
||||
|
||||
## Linux Distributions
|
||||
|
||||
**Linux Distribution**, commonly referred to as a **distro**, is an operationg system that consists of a Linux kernel, init system, package manager, etc.
|
||||
|
||||
## Everything is a file
|
||||
|
||||
In Linux, everything is treated as a file, including hardware and its abstractions.
|
||||
|
||||
### Linux Version
|
||||
|
||||
```
|
||||
$ cat /proc/version
|
||||
Linux version 6.3.1-arch2-1 (linux@archlinux) (gcc (GCC) 13.1.1 20230429, GNU ld (GNU Binutils) 2.40.0) #1 SMP PREEMPT_DYNAMIC Wed, 10 May 2023 08:54:47 +0000
|
||||
```
|
||||
|
||||
### CPU Model Name
|
||||
|
||||
```
|
||||
$ cat /proc/cpuinfo | grep "model name" -m 1
|
||||
model name : AMD Ryzen 7 5800H with Radeon Graphics
|
||||
```
|
||||
|
||||
### Total Available RAM
|
||||
|
||||
```
|
||||
$ cat /proc/meminfo | grep "MemTotal"
|
||||
MemTotal: 32193984 kB
|
||||
```
|
||||
|
||||
### Process Info (first six rows)
|
||||
|
||||
```
|
||||
$ cat /proc/$$/status | head -n6
|
||||
Name: zsh
|
||||
Umask: 0022
|
||||
State: S (sleeping)
|
||||
Tgid: 16378
|
||||
Ngid: 0
|
||||
Pid: 16378
|
||||
```
|
||||
|
||||
`$$` variable means **shell's Process ID**
|
||||
|
||||
## High-level overview of Linux architecture
|
||||
|
||||
We can divide the architecture into three layers:
|
||||
|
||||
- **User space (Userland)**, where programs, shells, and desktop environments operate
|
||||
- **Kernel**, which we'll get to in a later section
|
||||
- **Hardware**, so your CPU, GPU, storage media, I/O devices, etc.
|
||||
|
||||
While there's a single API between the userland and the kernel in form of the aforementioned [system calls](#operating-system), there are multiple interfaces between the kernel and hardware. These include:
|
||||
|
||||
- CPU interface
|
||||
- RAM interface
|
||||
- Device and network drivers
|
||||
- Block device drivers
|
||||
- Character device drivers, hardware interrupts, and other I/O device drivers
|
||||
|
||||
## Select CPU architecture types
|
||||
|
||||
### Determining your CPU's architecture
|
||||
|
||||
You can use `uname -m`. Here's an example output from my machine:
|
||||
|
||||
```
|
||||
❯ uname -m
|
||||
x86_64
|
||||
```
|
||||
|
||||
### x86_64 (amd64)
|
||||
|
||||
x86 was designed by Intel and it refers to the 32-bit instruction set. AMD later extended x86's instruction set by a 64-bit equivalent. Although Intel collaborated with HP to developi its own 64-bit instruction set called IA64, the former ended up adopting AMD's set and soon the _vendor-neutral_ name of `x86_64` was coined.
|
||||
|
||||
This architecture is utilised in the vast majority of personal computers, laptops, and servers. Despite its capabilites and wide spread, it's not really energy-efficient primarily due to the out-of-order execution.
|
||||
|
||||
### ARM (Advanced RISC Machines)
|
||||
|
||||
It was developed by Acron engineeers in 1985 with focus on minimising power usage. Nowadays, ARM processors power multiple portable devices like modern smartphones, but also video game consoles like PS Vita, or Nintendo Switch, and of course single-board computers like Raspberry Pi.
|
||||
|
||||
### RISC-V (RISC Five)
|
||||
|
||||
The newest player to enter the CPU market, RISC-V was developed by researchers from the University of California, Berkley. There are plenty of existing and in-development implementations from the likes of Google, Nvidia, Western Digital, or Alibaba Group, but these processors currently aren't as widespread as the former two.
|
||||
|
||||
## Process management
|
||||
|
||||
### Execution units
|
||||
|
||||
**Process** is an instance of a program that's being run in sequences of instructions independent of other code. These sequences are known as **threads**. Each process has a unique Process ID (PID), and can (but doesn't have to) consist of multiple threads.
|
||||
|
||||
In Linux, however, threads are implemented as processes which share resources with other processes. Threads are identified via a **Thread ID (TID)** in case of a single-threaded process, or a **Thread Group ID (TGID)** in case of a multi-threaded process.
|
||||
|
||||
Process can be organised into **Process Groups**, where each group has a unique **Process Group ID (PGID)**, and process groups themselves can be groupped into **Sessions**, which represent a user. As you may have guessed by now, each session has a unique **Session ID (SID)**.
|
||||
|
||||
Furthermore, the kernel contains a data structure called `task_struct`, which serves as an implementation basis for processes and threads, including their respective IDs, methods for handling different signals, and so on.
|
||||
|
||||
So here's how all these _execution units_ are ordered from the largest to the smallest:
|
||||
|
||||
1. Session
|
||||
2. Process Group
|
||||
3. Process
|
||||
4. Thread
|
||||
5. Task
|
||||
|
||||
### Process states
|
||||
|
||||
There are 4 main states a process can be in:
|
||||
|
||||
- **Running** - the process is active and currently being handled by the processor
|
||||
- **Sleeping** - the process is waiting for required resources to become available. This state can be divided into 2 subcategories:
|
||||
- **Uninterruptible** - the process doesn't react to any signals before the resources become available
|
||||
- **Interruptible** - it can respond to both signals and resource availability
|
||||
- **Stopped** - once a process enters this state, it frees all of its resources and sends a `SIGCHLD` termination signal to its parent, which will then free the child process once it receives said signal
|
||||
- **Zombie** - process can enter that state after sending the termination signal and before getting removed from the process table by its parent. It means that a process is pretty much defunct at this point
|
||||
|
||||
## Memory management
|
||||
|
||||
Both the physical and virtual memory are divided into **pages** of fixed length. Pages of the former are called **page frames**, whereas pages of the latter are known as **virtual pages**. Many virtual pages can map to the same **page frame**. Processes believe they work with huge and contiguous sections of virtual memory; so huge in fact, that they exceed the amount of memory that's actually available.
|
||||
|
||||
Whenever the CPU requests access to one of the virtual pages, the OS uses a **page table** to obtain the physical address that its virtual counterpart corresponds to. This mapping is a **page table entry (PTE)**.
|
||||
|
||||
Modern CPUs contain a cache of recently used PTEs called **Translation Lookaside Buffer (TLB)**. This is what actually gets searched before the page table, and if the requested mapping is found, then the page table never gets queried. Otherwise, the lookup will be performed on said table, but the found PTE will later be saved in the TLB.
|
||||
|
||||
Although the **default page size** is a mere 4 kilobytes, it's possible to increase it since the release of kernel 2.6.3. Furthermore, 64-bit Linux allows you to use up to **128 terabytes of virtual address space**, as well as **64 terabytes of physical memory**.
|
||||
|
||||
## Network stack
|
||||
|
||||
The Linux network stack consists of three layers:
|
||||
|
||||
- **Sockets** for abstracting communication
|
||||
- **Communication Protocols** in form of **Transmission Control Protocol (TCP)** and **User Datagram Protocol (UDP)**
|
||||
- **Internet Protocol (IP)** for addressing and routing packets so that they can be delivered to the right machine
|
||||
|
||||
Other protocls such as HTTP, FTP, SMTP, or SSH are implemented in the user space.
|
||||
|
||||
## File systems
|
||||
|
||||
File systems are used to organise files and directories in storage media (ie. your hard disk drives and solid-state drives). Linux supports many file systems such as ext4, btrfs, or NTFS. The Linux kernel provides a **Virtual File System (VFS)**, which allows programs running in the userland to interact with the filesystem.
|
||||
|
||||
## Device drivers
|
||||
|
||||
Device driver is a piece of software that runs in the kernel and is responsible for managing a physical device (such as a keyboard, mouse, gamepad, or even a GPU) or a pseudo-device (e.g. a pseudo-terminal), as well as providing a means of interfacing with said device for other programs.
|
||||
|
||||
## System calls
|
||||
|
||||
System calls offer a way for programs to request a service from the kernel, which will then execute a set of relevant architecture-specific instructions. Programs don't make use of syscalls directly. Instead, they utilise wrappers from the C standard library, which are available via `glibc` or `musl`.
|
||||
@ -1,155 +0,0 @@
|
||||
---
|
||||
title: shells and scripts part 1
|
||||
description: Theory behind working with Linux via a CLI and automating various tasks
|
||||
pubDate: 2023-08-28T18:24:05.514Z
|
||||
draft: false
|
||||
categories:
|
||||
- learning modern linux
|
||||
tags:
|
||||
- linux
|
||||
- notes
|
||||
---
|
||||
|
||||
Hey folks!
|
||||
|
||||
This post contains my notes from the third chapter of _Learning Modern Linux_ book written by Michael Hausenblas. Let's just jump into it!
|
||||
|
||||
## Ways of working with a CLI
|
||||
|
||||
There are two ways in which a user can work with Linux via a CLI:
|
||||
|
||||
- **Manual** via a terminal or a pseudo-terminal such as `tty`, where a human inputs commands and checks their output
|
||||
- **Automatic** by utilising shell scripts, which come in handy for repetitive tasks
|
||||
|
||||
## Terminal and Terminal Emulator
|
||||
|
||||
**Terminal** is an electronic device which generally consists of a keyboard and a monitor for inputting commands and data into a computer and inspecting the output of entered commands respectively.
|
||||
|
||||
**Terminal Emulator** is an application that mimics the behaviour of a physical terminal usually via a graphical user interface or a full-screen console.
|
||||
|
||||
## Shell
|
||||
|
||||
**Shell** is a program that interprets and executes incoming commands, handles input/output data and enables the user to enter these commands both manually and automatically via scripts.
|
||||
|
||||
## Streams
|
||||
|
||||
### Definition
|
||||
|
||||
**Streams** serve as a means of transporting input, output, and error data. In Linux and other Unix-like systems, every process has access to three **file descriptors**:
|
||||
|
||||
- 0 for `stdin`
|
||||
- 1 for `stdout`
|
||||
- 2 for `stderr`
|
||||
|
||||
### Redirecting to other destinations
|
||||
|
||||
By default, `stdin` is connected to the keyboard and the other two are connected to the screen. It's possible to redirect a stream elsewhere by adding `$FD>`, where `$FD` is an appropriate file descriptor (see: list above).
|
||||
|
||||
If you omit `$FD`, `stdout` will get redirected to the specified destination. If you want to redirect both `stdout` and `stderr` to the same destination, use `&>`. And if you want to ignore a certain stream, redirect it to `/dev/null`.
|
||||
|
||||
### Special characters
|
||||
|
||||
- `&` (ampersand) will run a command in the background
|
||||
- `\` (backslash) allows you to continue writing a command in a new line
|
||||
- `|` (pipe) allows you to pipe one command's `stdout` into the following command's `stdin`
|
||||
|
||||
## Variables
|
||||
|
||||
Shell variables, just like in pretty much any other programming language, are used to store a piece of data under a symbolic name.
|
||||
|
||||
We can specify two types of variables:
|
||||
|
||||
- **Environment variables** that are used to configure a value in some script from outside said code
|
||||
- **Shell variables** that are limited to the execution context of a given script
|
||||
|
||||
Here's how to create a shell variable:
|
||||
|
||||
```sh
|
||||
set NICE_NUMBER=69
|
||||
```
|
||||
|
||||
And here's how to create an environment variable:
|
||||
|
||||
```sh
|
||||
export ANOTHER_NICE_NUMBER=420
|
||||
```
|
||||
|
||||
Here's how to print a variable's value:
|
||||
|
||||
```sh
|
||||
echo $VARIABLE_NAME_HERE
|
||||
```
|
||||
|
||||
Select environment and shell variables:
|
||||
|
||||
- `PATH` - list of paths to search for executables to run
|
||||
- `HOSTNAME` - name of the device
|
||||
- `PWD` - absolute path to the current working directory
|
||||
- `USER` - current user's username
|
||||
- `$` - current PID
|
||||
- `?` - last task's exit code
|
||||
|
||||
Speaking of exit codes...
|
||||
|
||||
## Exit Codes
|
||||
|
||||
Every process is expected to return a status code after exiting. Code `0` means a **successful execution**, whereas every code greater than or equal `1` means some sort of a **failure**.
|
||||
|
||||
## Job Control
|
||||
|
||||
By default, every command you execute runs in **the foreground**, meaning it takes control over the keyboard and the screen. If you want to start a task in **the background**, you have to append a `&` to the command, or press `Ctrl+Z` while the task is running in the foreground.
|
||||
|
||||
## Modern command replacements and other utils
|
||||
|
||||
- [`exa`](https://the.exa.website/) as a replacement for `ls -l`
|
||||
- [`bat`](https://github.com/sharkdp/bat) as a replacement for `cat`
|
||||
- [`ripgrep (rg)`](https://github.com/BurntSushi/ripgrep) as a replacement for... well, `grep`
|
||||
- [`gtop`](https://github.com/aksakalli/gtop) as a performance monitor in your CLI
|
||||
- [`curlie`](https://github.com/rs/curlie) as a modern enhancement of `curl`
|
||||
|
||||
Feel free to check out [the modern-unix repo](https://github.com/ibraheemdev/modern-unix) for more examples.
|
||||
|
||||
## Navigation
|
||||
|
||||
Here's a list of some key combinations to help you navigate around your CLI:
|
||||
|
||||
- `Ctrl + A` moves the cursor to the start of the line
|
||||
- `Ctrl + E` moves the cursor to the end of the line
|
||||
- `Left Alt + F` moves the cursor forward by a word
|
||||
- `Left Alt + B` moves the cursor backward by a word
|
||||
- `Ctrl + U` removes all the characters on the left-hand side of a cursor
|
||||
- `Ctrl + K` removes all the characters on the right-hand side of a cursor
|
||||
|
||||
## File content CRUD operations
|
||||
|
||||
### Create a file
|
||||
|
||||
```sh
|
||||
touch cool-file.txt
|
||||
```
|
||||
|
||||
### Read a file
|
||||
|
||||
```sh
|
||||
cat cool-file.txt
|
||||
```
|
||||
|
||||
### Overwrite a file's content
|
||||
|
||||
```sh
|
||||
echo 'New file content' > cool-file.txt
|
||||
```
|
||||
|
||||
### Append content to a file
|
||||
|
||||
```sh
|
||||
echo 'Even more new content' >> cool-file.txt
|
||||
```
|
||||
|
||||
(There's no need to add a newline character manually)
|
||||
|
||||
### Delete a file
|
||||
|
||||
```sh
|
||||
rm cool-file.txt
|
||||
```
|
||||
@ -1,20 +0,0 @@
|
||||
---
|
||||
title: shells and scripts part 2
|
||||
description: Key elements and syntax of the Bash scripting language
|
||||
pubDate: 2023-08-29T09:30:22.058Z
|
||||
lastEditDate: 2023-08-29T09:30:22.058Z
|
||||
draft: true
|
||||
categories:
|
||||
- learning modern linux
|
||||
tags:
|
||||
- linux
|
||||
- notes
|
||||
---
|
||||
|
||||
Hey folks!
|
||||
|
||||
For this article, I've actually made notes from a different book, ie. _Linux - komendy i polecenia (commands and instructions)_ by Łukasz Sosna. THis time I'll cover the _practical part_, ie. Bash language's syntax and sample code snippets.
|
||||
|
||||
As always, these are just key takeaways, so if you're aiming to squeeze out every bit of knowledge possible, then I highly recommend you buy this and Michael Hausenblas' book.
|
||||
|
||||
## Variables
|
||||
@ -1,25 +0,0 @@
|
||||
---
|
||||
title: time to go deeper
|
||||
description: outlining and reasoning a plan to learn linux
|
||||
pubDate: 2023-08-23T10:36:51.379Z
|
||||
draft: false
|
||||
categories:
|
||||
- learning modern linux
|
||||
tags:
|
||||
- linux
|
||||
- planning
|
||||
---
|
||||
|
||||
It's been a while since my last proper blog post, and I haven't touched Michael Hausenblas' _Learning Modern Linux_ book yet. I thought I'd use this opportunity to return to blogging and note key takeaways from the aforementioned book.
|
||||
|
||||
Now, while I'm technically already using Linux for my main machine, I've had [my friend Eris](https://github.com/m1ndflay3r) assist me when preparing the Arch setup I've currently got up and running. Of course It wasn't a completely hands-off experience for me, and I'm not ungrateful for her helping me out. I'm not dissatisfied with the package either - it does a great job in every task between general usage, productivity, all the way up to gaming.
|
||||
|
||||
That being said, I believe it's high time I went deeper and got up close and personal with the OS. Having seen [a talk on deployment-as-a-service](https://www.youtube.com/watch?v=S6i4_jHhemc) from Brian, another friend of mine, I've realised that getting a more in-depth knowledge of the system that's used by the vast majority, if not all the servers that expose my websites to _the outside world_.
|
||||
|
||||
Better yet, the aforementioned book includes sections for networking and writing bash scripts for automating various tasks and coding up CLI tools, so I'll get to level up in those areas too. Overall, this should make me a more attractive hire even as a frontend developer, and also enable to branch out into DevOps, or even system administration in the long run.
|
||||
|
||||
Once I've finished this book, I'm looking to redo my Arch Linux setup, especially since I've recently got myself a spanking new 2 TB SSD with 7000 MBPS read/write speed. I might need to set up that system to dualboot with Windows, since PJAIT (the university I got accepted into) offers a wide array of software from Microsoft's devtools repository that I might have to use and that is next to impossible to use via Wine, such as Visual Studio or the Office 365 suite.
|
||||
|
||||
So there's that for the introduction I guess... once again, huge shout-outs go to Eris, Brian, as well as [noob404](https://twitter.com/Noob404yt) for being awesome devs (and more importantly - people), and for influencing my decision to go down this rabbit hole. This will very likely be a bumpy ride, full of head-scratching and pesky issues, but I've got sheer will and Arch Wiki on my side, so I should land relatively unscathed.
|
||||
|
||||
After all - what doesn't kill you, will try again... I mean, makes you stronger... or somthing along these lines.
|
||||
Loading…
Reference in New Issue
Block a user