8·
4 months ago- ALWAYS avoid partial upgrades, lest you end up bricking your system: https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported
- The Arch Wiki is your best friend. You can also use it offline, take a look at
wikiman: https://github.com/filiparag/wikiman - It doesn’t hurt to have the LTS kernel installed as a backup option (assuming you use the standard kernel as your chosen default) in case you update to a newer kernel version and a driver here or there breaks. It’s happened to me on Arch a few times. One of them completely borked my internet connection, the other one would freeze any game I played via WINE/Proton because I didn’t have resize BAR enabled in the BIOS. Sometimes switching to the LTS kernel can get around these temporary hiccups, at least until the maintainers fix those issues in the next kernel version.
- The AUR is not vetted as much as the main package repositories, as it’s mostly community-made packages. Don’t install AUR packages you don’t 100% trust. Always check the PKGBUILD if you’re paranoid.
I’m not sure how familiar you are with computers in general, but I think the best way to explain Docker is to explain the problem it’s looking to solve. I’ll try and keep it simple.
Imagine you have a computer program. It could be any program; the details aren’t important. What is important, though, is that the program runs perfectly fine on your computer, but constantly errors or crashes on your friend’s computer.
Reproducibility is really important in computing, especially if you’re the one actually programming the software. You have to be certain that your software is stable enough for other people to run without issues.
Docker helps massively simplify this dilemma by running the program inside a ‘container’, which is basically a way to run the same exact program, with the same exact operating system and ‘system components’ installed (if you’re more tech savvy, this would be packages, libraries, dependencies, etc.), so that your program will be able to run on (best-case scenario) as many different computers as possible. You wouldn’t have to worry about if your friend forgot to install some specific system component to get the program running, because Docker handles it for you. There is nuance here of course, like CPU architecture, but for the most part, Docker solves this ‘reproducibility’ problem.
Docker is also nice when it comes to simply compiling the software in addition to running it. You might have a program that requires 30 different steps to compile, and messing up even one step means that the program won’t compile. And then you’d run into the same exact problem where it compiles on your machine, but not your friend’s. Docker can also help solve this problem. Not only can it dumb down a 30-step process into 1 or 2 commands for your friend to run, but it makes compiling the code much less prone to failure. This is usually what the
Dockerfileaccomplishes, if you ever happen to see those out in the wild in all sorts of software.Also, since Docker puts things in ‘containers’, it also limits what resources that program can access on your machine (but this can be very useful). You can set it so that all the files it creates are saved inside the container and don’t affect your ‘host’ computer. Or maybe you only want to give permission to a few very specific files. Maybe you want to do something like share your computer’s timezone with a Docker container, or prevent your Docker containers from being directly exposed to the internet.
There’s plenty of other things that make Docker useful, but I’d say those are the most important ones–reproducibility, ease of setup, containerization, and configurable permissions.
One last thing–Docker is comparable to something like a virtual machine, but the reason why you’d want to use Docker over a virtual machine is much less resource overhead. A VM might require you to allocate gigabytes of memory, multiple CPU cores, even a GPU, but Docker is designed to be much more lightweight in comparison.