updated README.md, checking off for the day

README.md

@@ -1,10 +1,31 @@
 # **Axe OS**
 
-**Axe OS** is a from-scratch operating system, driven by Linux From Scratch and others like it.
+**Axe OS** is a from-source operating system, driven by [Linux From Scratch](https://www.linuxfromscratch.org/) and others like it.
 
-Instead of creating a full-fledged desktop system, it is more about simplicity and a lightweight module-based approach. It is intended for use with my C/C++, and Go code bases. Simplicity and control have been prioritised over completeness in this. 
+Instead of creating a full-fledged desktop system, it is more about simplicity and a lightweight module-based approach. It is intended for use with my C/C++.
 
-With the Docker runtime, any additional dependencies or utilities required in the future by the system can be built or downloaded inside Docker containers. This way, the host system is left clean; no need to install any dependencies.
+With the Docker runtime, any additional dependencies or utilities required in the future can be built, ran or downloaded inside Docker containers. This way, the host system is left clean; no need to install any dependencies.
+
+# Advice
+
+Here is a corrected version of your text. I have fixed the grammar, spelling, and flow while keeping your specific advice and technical perspective intact.
+My advice: Learn the Bash programming language. It is underrated, but it saves time and helps you avoid many of the pitfalls I fell into. The number of times I accidentally deleted my main OS or lost projects—and the amount of time I wasted because of it—is something you definitely want to avoid.
+
+
+I’ve even bricked a disk before. You might wonder how you can brick a disk: unsynced changes, multiple simultaneous writes, or overwriting—I’m not entirely sure of the exact cause, but my disk just stopped working. It wasn't even a hard drive; it was an SSD. So yeah, many things can go wrong.
+
+
+Depending on your needs, you might not need to build most of the tools I use. For example, BusyBox already includes awk, sed, patch, coreutils, findutils, diffutils, grep, tar, gzip, xz, bzip2, and more. The reason I build these tools separately on my side is for Docker. Docker requires specific compression and networking tools, so since I was going to build those anyway, I decided to build the others as well.
+
+
+When following  [LFS](https://www.linuxfromscratch.org/), you may notice they include a large number of packages. For some Python-related packages, you can just build Python with pip and then install the rest using pip. You don’t have to download and build every single one from source. The same applies to Meson and Ninja; you don't necessarily have to download the source code for them. This approach can really speed things up for you.
+
+The next choice you’ll face is the graphical stack: Xorg or Wayland. I avoid Xorg because of the massive number of packages I would have to build. It’s not that I can’t build them, but there are just too many to maintain. Xorg is slowly being phased out—not overnight, but it is happening. Another issue is connecting applications inside Docker to your host system; with Xorg, you have to expose more than is ideal.
+
+For the compositor, it is best to look for something written in C or C++ that uses dependencies you already provide or has very few (1–2) extra dependencies. While there are some good compositors out there, some are written in Rust and others in Zig. I’m not interested in building the Zig or Rust compilers right now, as that would require building LLVM, which is another beast entirely.
+
+
+If you are going to use a GPU for OpenGL or Vulkan, you will eventually need to build LLVM because Mesa requires it. However, I’ll be using software rendering for now. I will figure out the GPU side of things later because I don't plan on using Mesa; I intend to download the AMD, Intel, or NVIDIA drivers directly. I will work on that a bit later on.
 
 ## **Project Structure**