I am only at the first page, but already I must recommend this work
https://0xax.gitbooks.io/linux-insides/content/
as unmissable, and "I should have read this as a child" - that is, for those who feel a lack of solid ground until they know exactly what makes the machine work.
Why did you link the same link?
I did not: within the praise, I made the _anchor_ explicit and highlighted (not just linked with an hidden locator); the "monospace" feature was used for that purpose (in fact, it did not even seemed linked initially, nor it is now monospaced. Maybe it changed in the editing?).
The purpose: to enable reading the anchor - in this case you want to see it, not just click on it. This is a case when you want '0xax' and 'gitbooks.io' and the rest well in front of you. For mnemonics.
Similarly to why an possibly apparently gratuitous post of praise was issued: to note, "this one can be really worth it, comparatively - here is a mark that facilitates that you check it and not miss it".
> I did not
Well, it's the same link. I only asked because it looks like you were intending to paste a different link (or anchor) than the original link; It's confusing for readers.
Maybe he is a GPT-3 bot? :-)
I would really avoid such jokes, belter.
To call a human - and within HN you do find very refined ones - a machine (and in particular machines devoid of intellect, and which outstand for being devoid of any intellect), is insulting.
There is a risk to use it in occasions where actually refined thought is called "machine-like", which is insulting, diminishing, and destructive.
And it has been used in occasions in which some dismissed perfectly valid and refined information because they could not understand it.
And also in face of the above, the contribution of such statement with regards to "joke" value is either low or requiring more explicitness of any productive content.
I would restrict comparisons between humans and machines there where it is productive.
This is a gold mine. Thanks.
I read some of this to try to determine how it would compare to a classic operating systems design book - like maybe "The Design and Implementation of the 4.4 BSD Operating System".
Looking at the Paging [1] chapter, the _Linux Insides_ book has a clear, very technical, description of the meaning of every bit in pointers used for virtual addressing. It includes details like what bits you need to set in order to enable a particular paging mode, so it's really enough detail to actually _do_ something.
I don't think I'm the target audience, but it was interesting to look at.
[1] https://0xax.gitbooks.io/linux-insides/content/Theory/linux-...
This looks like a really good resource, but why is it so difficult to find a somewhat up-to-date description of networking in the Linux kernel?
It seems like the least documented (at a high level, anyway) part of the kernel - if anyone knows a good resource I'd love to hear it.
I guess it's so complicated that no one wants to write it. I can feel it when compiling Linux kernel from source. The number of options in networking part seems humongous.
This probably the only book dedicated on the networking in the Linux kernel but maybe a bit outdated at the moment[1].
For general networking operation this new book looks promissing [2].
[1]Linux Kernel Networking:
https://link.springer.com/book/10.1007/978-1-4302-6197-1
[2] Linux for Networking Professionals:
https://github.com/PacktPublishing/Linux-for-Networking-Prof...
This is already outdated, right? Nobody boots up from legacy BIOS anymore, so everything up to and including "transitioning to 64-bit" is wrong. UEFI boot is simpler, but still worth digging into. And what about AARCH64 and other platforms where there are no CPU modes to go through?
> Nobody boots up from legacy BIOS anymore
Not true at all. Plenty of people still use BIOS boot (in the data center) for things like PXEBOOT.
But UEFI does have PXE...
Who wrote it? Perhaps everyone already knows them (except me)? What expertise do they have? This Github user shares the same Twitter account:
And they say they are an "Elixir developer at @travelping":
I understand the curiosity but why does it matter? They clearly made an effort to stay anonymous. Is it the challenge in doxxing?
The front page of the book directly links to https://github.com/0xAX/linux-insides/blob/master/CONTRIBUTI..., which makes it abundantly clear that this is the author of the book.
> They clearly made an effort to stay anonymous.
The word you're looking for is "pseudonymous", which is a very, very, very different thing.
Again, why do you care?
I don't understand your question. Obviously the source is a critical factor in evaluating information, which I'm sure you know, so what do you mean?
Previous discussions:
"Linux Inside – How the Linux Kernel Works" https://news.ycombinator.com/item?id=14422605 (564 points | May 27, 2017 | 31 comments)
"Inline assembly in Linux" https://news.ycombinator.com/item?id=11606518 (158 points | May 1, 2016 | 33 comments )
Full list here: https://hn.algolia.com/?q=0xax+linux+insides
Anyone else read this title to the tune of "Intel Inside"?
> The basic usage is the same as other mailing lists powered by mailman.
Would be nice if this section was more detailed. Mailing lists can be quite confusing for the uninitiated.
Holy cow!!! This is amazing. Do you offer training videos also?
Man I always want to read about this stuff but it always comes across super dull. I really think the standard Computer Science curriculum needs to focus more on writing. Seems to me that if programming is mostly about communication we should focus more on learning to write in a more engaging style.
To me, it seems one of the best written pieces I have ever read, fitting to its purpose.
One suspect: some people may read that «engaging» as "glamorously captivating": that would alienate readers interested in that content - the opposite effect. The contextual text has to be lean and respond to the questions the intended reader may have. It is engaging because, as it rarely happens, it gives precisely the information you want, without adding noise (which has an discouraging effect).
Any examples of tech documentation that you find more appealing? I'm trying to improve in this area.