Here is my list, which is biased towards Linux. Almost all the books mentioned here are dated and primarily written for 2.6 based kernels. Although many concepts are still applicable and in certain subsystems, the code will be as is with minor changes. So, despite them being old they are still good references.
* Design and implementation of the FreeBSD operating system: Good and thorough deep dive in FreeBSD OS. Must have.
* FreeBSD Device Drivers: A Guide for the Intrepid: Didn't quite read it all but looks fine for FreeBSD.
* Mac OSX internals - a systems approach by Amit Singh: It was good back in days but now outdated.
* Linux Device Drivers, 3ed : Very dated but still good to grasp Linux device drivers in general. The code examples are bit silly but good enough. There are some GitHub repos which have updated code for latest kernels.
* Essential Linux Device Drivers by S Venkateswaran: It complements LDD3 book quite nicely. Has some real device examples and very exhaustive. Must have.
* Linux kernel development by Robert Love: Very good for short/quick intro. Best for preparing before interviews ;)
* Professional Linux kernel architecture by Wolfgang Mauerer: As other book, its dated but some of the explanations about interrupts, PCI, etc are good. His callgraph approach was very handy in understanding things.
* The Linux programming interface by Michael Kerrisk: Not really about OS but next thing close to it - system programming (the real system programming). Must have.
* Understanding Linux virtual memory manager by Mel Gorman: As other books, it's dated but still one of the best available to get a handle on memory management under Linux. Must have.
* Understanding the Linux kernel: Dated but still my go to book to refresh certain subsystems. Must have.
* Linux Kernel Programming by Michael Beck: Mentioned for historical reasons, else most out dated book here (2.4 based). Horrible editing and English but heck! I loved it back in the days :)
* Linux kernel networking by Rami Rosen: Never read it but quite dated.
* Understanding Linux network internals by Christian Benvenuti: A real bible of Linux networking. If nothing else, your jaw drops at the effort author made to write this book. Dated but unlike more generic Linux kernel things, network stack is still same in its core. Must have.
* The Linux kernel primer: A top-down approach for x86 and PowerPC Architecture: Very dated book but good to read from PPC perspective. Lot of things have changed since its publication.
* See MIPS Run by Dominic Sweetman: dated but gives good idea about MIPS internals and how Linux uses it.
* IA-64 Linux Kernel: Design and Implementation: Its dated not just w.r.t code but also w.r.t. hardware. Nonetheless, it gives a good insight into IA-64 architecture and Linux from non-x86 perspective.
* Definitive guide to Xen hypervisor: this is the only book on virtual machine which is not just from user perspective. While best way to learn VM is through reading architecture spec and code, this book still satisfied me w.r.t. virtual machine internals.
Every other book on amazon about Linux kernel is more or less useless. For more academic book, "Operating systems - three easy pieces" is good.
The problem with the Unix lowest-common-denominator model is that it pushes complexity out of the stack and into view, because of stuff other designs _thought_ about and worked to integrate.
It is very important never to forget the technological context of UNIX: a text-only OS for a tiny, already obsolete and desperately resource-constrained, standalone minicomputer. It was written for a machine that was already obsolete, and it shows.
No graphics. No networking. No sound. Dumb text terminals, which is why the obsession with text files being piped to other text files and filtered through things that only handle text files.
While at the same time as UNIX evolved, other bigger OSes for bigger minicomputers were being designed and built to directly integrate things like networking, clustering, notations for accessing other machines over the network, accessing filesystems mounted remotely over the network, file versioning and so on.
People brought up on Unix look at that and see needless complexity, but it isn't.
VMS' complex pathnames are the visible sign of an OS which natively understands that it's one node on a network, that currently-mounted disks can be mounted on more than one network nodes even if those nodes are running different OS versions on different CPU architectures. It's an OS that understands that a node name is a flexible concept that can apply to one machine, or to a cluster of them, and every command from (the equivalent of) `ping` to (the equivalent of) `ssh` can be addressed to a cluster and the nearest available machine will respond and the other end need never know it's not talking to one particular box.
50 years later and Unix still can't do stuff like that. It needs tons of extra work with load-balancers and multi-homed network adaptors and SANs to simulate what VMS did out of the box in the 1970s in 1 megabyte of RAM.
The Unix was only looks simple because the implementors didn't do the hard stuff. They ripped it out in order to fit the OS into 32 kB of RAM or something.
The whole point of Unix was to be minimal, small, and simple.
Only it isn't any more, because now we need clustering and network filesystems and virtual machines and all this baroque stuff piled on top.
The result is that an OS which was hand-coded in assembler and was tiny and fast and efficient on non-networked text-only minicomputers now contains tens of millions of lines of unsafe code in unsafe languages and no human actually comprehends how the whole thing works.
Which is why we've build a multi-billion-dollar industry constantly trying to patch all the holes and stop the magic haunted sand leaking out and the whole sandcastle collapsing.
It's not a wonderful inspiring achievement. It's a vast, epic, global-scale waste of human intelligence and effort.
Because we build a planetary network out of the software equivalent of wet sand.
The point is that it was 1885 and the design was able to support buildings 10× as big without fundamental change.
The Chicago Home Insurance building wasn't very impressive, but its design was. Its design scaled.
When I look at classic OSes of the past, like in this post, I see miracles of design which did big complex hard tasks, built by tiny teams of a few people, and which still works today.
When I look at massive FOSS OSes, mostly, I see ant-hills. It's impressive but it's so much work to build anything big with sand that the impressive part is that it works at all... and that to build something so big, you need millions of workers, and constant maintenance.
If we stopped using sand, and abandoned our current plans, and started over afresh, we could build software skyscrapers instead of ant hills.
But everyone is too focussed on keeping our sand software working on our sand hill OSes that they're too busy to learn something else and start over.
What helps with solving problems like math and algorithmic problems is to go through a lot of problems to see different patterns and strategies of solving problems. I'm talking about going through thousands of problems. That is very effective.
> why am I not building lasting friendships with them?
I find the biggest problem is the lack of time to dedicate to it. Specifically, in my order of priorities it comes in behind a lot of other more important things that I don't have enough time for as it is.
I've noticed this has become a far more important equation with age, how I allocate time. When I was ~16-24 years old I burned up enormous amounts of time doing stupid shit. Time seemed inexpensive, plentiful, unlimited. And of course typically when you're young you have fewer responsibilities anyway. Now I'm far more certain about what matters and what doesn't in terms of ordering how I burn up what remains of my lifetime. As you get older you learn all of this, you learn what matters for yourself, and properly you allocate time accordingly.
Sometimes I think I'm getting grumpier as I get older, but it's not actually that at all. I dislike doing things I don't want to do more as I've gotten older, because I've acquired a far greater understanding of the value of time. How fast it seems to zip by, how scarce it is, how little of it we get relatively speaking. Stupid things that rob me of time, are a far greater annoyance with that understanding, that appreciation. When you're young, you can think you understand the value of your time; when you're older, you feel it in your bones, you walk around wearing the expense of time across decades.
Watching time vanish when you're 18, you don't think much about it. Time is infinite as far as you're concerned. Watching time vanish when you're 40 gets a lot more concerning. You become very aware of how quickly a decade seems to slip by. Blink, a decade goes by, you're 50; blink, blink, you're dead.
Your body also starts to deteriorate in accelerating fashion after anywhere from your mid 30s to your mid 40s, depending. You begin to notice that at 40 as well. Your memory isn't as sharp as it was at 20. You don't recover from damage as quickly. The physical aspect just reminds you that much more of the clock and how you're allocating your time. You can hear the little rusting springs in your telomeres as they keep getting shorter.
Chat rooms don't matter so much when you're 40 and you've spent a collective year or two of your earlier life hanging out in chat rooms (webchat broadcasting system, IRC et al.), bullshitting with people. You've got N years remaining to do things that really, really matter to you, and then you're going to die. And you're going to be dead forever. More chat rooms, to chat about things that you've chatted about 497 times in the past? No. Fuck no. On to the next, something more valuable, something more interesting, a new experience perhaps.
I too mentally miss the good 'ol days of being 18 and hanging out on IRC chatting about things that seemed super fascinating to me at the time. It's one part fantasy, one part longing to be young again, to feel young again (it's the reversal of the experience dulling concept of repetition, that people long for; every time you do something, it fades, exactly the same way many drugs do; repetitive experiences fade in the same way; we long toward the past in part due to that sensation of everything being vigorously new, exactly as drug addicts always miss the early addiction when the high was far better, before repetition eroded it).
We long for the early Internet / Web, because we've done so much Internet'ing, and every time you do it, it fades. It's not the old Internet that people actually miss. The problem is the experience repetition dulling everything, and that can't be rolled back; people miss the glorious experience of a new big world to explore online for the first time, that excitement. You can tell that that's the case, because people half my age experience the same sensation of missing what to them is the 'old' Internet (eg when they first started hanging out on Minecraft socializing online, or similar). Same concept, same longing, different Interwebs, same dulling over time due to experience repetition. Young people today will be longing for the exciting early days of TikTok, when they were doing dumb dance clones and it was stupid and silly and they'll miss the hell out of it, because it was all so new to them; like I might have missed hanging out on ICQ in its early days. And when those young people are 40, they'll still be able to go online and create short videos of themselves doing dumb dances, but they won't really want to, the repetitive experience effect will have dulled it all, it will no longer be new and exciting, and that can't be fixed, the life experience queue moves in one direction.
If you're fortunate, you get to decide what the meaning, the purpose, of your life is. The purpose of my life will always be to seek out new experiences, pursue new things that I find interesting. And that means not burning much more of my life in chat rooms, I already did plenty of that.
Interviewed with about 28 companies for almost 3 months, without a single offer! I was starting to get really worried about money and burned out from interviewing. In the past I've never interviewed with more than 2 or 3 before getting an offer
I now this is incredibly privileged. I'm not humble-bragging, just observing the change in the market.
As things usually turn out, during the last week of the 3-month search I received 3 different offers all at once.
For reference and if it matters: I've got 14 years of experience.
A few years ago I registered a short (five letter) nonsense word as a .com domain for a side project. I ended up using a different name so I let the .com expire. It was instantly registered by someone else.
But I just checked, and it’s available now. (Not squatted.)
I think some people run systems to buy up domains that expire, in case the expiration is a mistake. Then they can make a few bucks selling the domain back to the dummy who let it expire accidentally.
There’s a limit to how much you can make doing this, though, as any big company probably has a trademark on their domain. And if they do, they can just ask ICANN to seize it from you.
I think that’s different from someone who registered a common word (or many) and holds onto them, hoping to sell them to people who want them.
The domain squatting business is kind of like poker. You have a slow bleed of costs from annual domain fees (the ante in poker) and few deals to offset that (winning a hand in poker). Over time you have to either score some big deals, or eventually cut your costs. This limits the utility of squatting random nonsense domains for very long.
Coming from Scala I'd like to see successor ML become a reality. Whether it's 1ML, Ponyo, Ur (without the /Web), or another ML derivative that's not OCaml (petty, but the crufty syntax makes Scala seem elegant in this regard) isn't all that important.
As it stands every year Rossberg publishes a paper on latest 1ML enhancements; Harper does the same wrt to PLT, and by proxy SML. Meanwhile, nothing's really happening AFAICT in terms of the ML torch really being taken up and carried forward (beyond OCaml and Haskell).
Perhaps a charitable donation from an SV unicorn founder or two, corporate backing of some form, or academic backing similar to EPFL for Scala could really get the ball rolling.
Moving forward we've got OCaml and upcoming modular implicits; Haskell and the new module system, Backpack; and Scala's transition to Dotty -- basically a lot to look forward to, but would love to see SML in the mix, such a beautiful language...
* Design and implementation of the FreeBSD operating system: Good and thorough deep dive in FreeBSD OS. Must have.
* FreeBSD Device Drivers: A Guide for the Intrepid: Didn't quite read it all but looks fine for FreeBSD.
* Mac OSX internals - a systems approach by Amit Singh: It was good back in days but now outdated.
* Linux Device Drivers, 3ed : Very dated but still good to grasp Linux device drivers in general. The code examples are bit silly but good enough. There are some GitHub repos which have updated code for latest kernels.
* Essential Linux Device Drivers by S Venkateswaran: It complements LDD3 book quite nicely. Has some real device examples and very exhaustive. Must have.
* Linux kernel development by Robert Love: Very good for short/quick intro. Best for preparing before interviews ;)
* Professional Linux kernel architecture by Wolfgang Mauerer: As other book, its dated but some of the explanations about interrupts, PCI, etc are good. His callgraph approach was very handy in understanding things.
* The Linux programming interface by Michael Kerrisk: Not really about OS but next thing close to it - system programming (the real system programming). Must have.
* Understanding Linux virtual memory manager by Mel Gorman: As other books, it's dated but still one of the best available to get a handle on memory management under Linux. Must have.
* Understanding the Linux kernel: Dated but still my go to book to refresh certain subsystems. Must have.
* Linux Kernel Programming by Michael Beck: Mentioned for historical reasons, else most out dated book here (2.4 based). Horrible editing and English but heck! I loved it back in the days :)
* Linux kernel networking by Rami Rosen: Never read it but quite dated.
* Understanding Linux network internals by Christian Benvenuti: A real bible of Linux networking. If nothing else, your jaw drops at the effort author made to write this book. Dated but unlike more generic Linux kernel things, network stack is still same in its core. Must have.
* The Linux kernel primer: A top-down approach for x86 and PowerPC Architecture: Very dated book but good to read from PPC perspective. Lot of things have changed since its publication.
* See MIPS Run by Dominic Sweetman: dated but gives good idea about MIPS internals and how Linux uses it.
* IA-64 Linux Kernel: Design and Implementation: Its dated not just w.r.t code but also w.r.t. hardware. Nonetheless, it gives a good insight into IA-64 architecture and Linux from non-x86 perspective.
* Definitive guide to Xen hypervisor: this is the only book on virtual machine which is not just from user perspective. While best way to learn VM is through reading architecture spec and code, this book still satisfied me w.r.t. virtual machine internals.
Every other book on amazon about Linux kernel is more or less useless. For more academic book, "Operating systems - three easy pieces" is good.