The Linux kernel doesn't matter. What matters is understanding the history, philosophy, and purpose of the unix environment.
You needn't become a religious zealot committed to the unix philosophy, but if you don't take the time to understand it, you'll never get the most out of the environment.
While I agree on the importance of "the history, philosophy, and purpose of the unix environment", saying that the Linux kernel doesn't matter seems a bit harsh at best. It seems to me that the Linux kernel is the most successful Unix-like kernel in the history of computing. It certainly matters for its ubiquity alone.
Also, a "book on linux" is going to look very different if it's based on Debian as opposed to e.g. NixOS. Linux distros come in all shapes and sizes and no matter what level you're operating on (just using the GUI, light sysadmin, deep systems programming, down to kernel hacking), they may appear as totally different paradigms.
I would recommend simply daily driving Linux. If you're still using another operating system, ween yourself off of that. Additionally, there are a bunch of obvious projects that are low hanging fruit for just getting to grips with Linux. Want a personal website? Spin up a VPS or a cheap laptop and build it from scratch. Set up your own personal email. Get certbot running. Write a simple server in C that can do request/response of TCP. Write an i2c driver for some random micro you have lying around. Whatever you are interested in making/doing, just go do it.
Resist the urge to google everything. `man` has more information than you think it does.
and 2. i think it's gnome devhelp.
there's an app too.
it's too bad distributions themselves promote googling everything.
A very basic starting point would be linuxjourney.com.
It is also important to be aware that there are no guarantees that programs provide output that maintains determinism. This is important because computation often fundamentally breaks with violations of determinism.
ldd for example has several determinism errors in its output which breaks the required 1:1 unique input to unique output map property, as a result piping it to any program will result in non-deterministic outputs that break automation. * Note: PAX ended up fixing this properly in their repo package back in 2018 iirc, the ldd maintainers never accepted the changes upstream and its unfixed to this day.
Lower intermediate might be RHCSA material and tearing down existing distros by package and identifying functional blocks and implementation/integration details.
LFS is more upper intermediate, and requires some background knowledge of using freestanding code and their relevant toolchains, and common problems you might face in software compilation (i.e. circular dependencies, first/second pass libstd++).
The modern editions of this book are primarily focused on Linux with some side notes for the BSDs.
and/or https://debian-handbook.info/ ?
Which obviously is specific to Debian, but up date.
Debian in itself is an acceptable distro, anything that's out there, exists for Debian.
Today I would heavily supplement it with answers from GTP4o (or perhaps Sonnet 3.5).
For me, it was Linux in a Nutshell (942 pages in the current edition) because I wanted a reference made of paper instead of pixels.
Later for deep background, Design of the Linux Operating System https://archive.org/details/DesignUNIXOperatingSystem but I picked up an used print copy for <$10.
Those were the best books for me. You are not me. Good luck.
