Solaris internals

What Hacker News says

1. titzerJan 2022
   Yeah, I recognize that ownership helps with concurrency, and TBH most of the code I write isn't highly concurrent, especially at a fine-grained level. Nevertheless, I think all that ownership is going overboard to solve what is in effect a niche problem. (After all, 30 years ago, engineers at Sun architected the Solaris kernel with very carefully designed fine-grained locking with little more than C. "Solaris Internals" is still highly recommended.).

   There are a lot of other strategies for writing concurrent systems, like, for example, making most data immutable, coarse-grained sharing, shared-nothing multi-process architectures like actors, using race detectors and/or thread sanitizers, using good concurrent libraries (with lock-free hashtables and other datastructures).

   The difference between the number of concurrency bugs causing catastrophic failure and all other kinds of bugs causing catastrophic failure has gotta be at least 100 or maybe 1000 to 1. So forcing everyone to think about ownership because maybe they are writing concurrent code (then again maybe they aren't) so that "congrats your memory management problems are solved" seems like a Pyrrhic victory--you've already blown their brain cells on the wrong problem. Worse, you've forced them to bake ownership into the seams in every part of the system, making it more difficult to refactor and evolve that system in the future. [1]

   > Screw up how multiple Go threads access that nice GC managed memory and undefined and non-deterministic behaviour is inevitable result.

   You get race conditions, you don't get undefined behavior (nasal daemons). Go and Java have memory models that at least your program doesn't violate the source type system and you don't get out-of-thin air results. You get tearing and deadlocks and race conditions, not undefined behavior. At Google we used TSAN extensively in Chrome and V8 and similar tools exist for Java, and I assume so as well for Go.

   It's a broader conversation, but I don't think advocating that everyone write highly concurrent programs with shared mutable state, no matter what tools they have at their disposal, is pushing in the right direction. Erlang, Actors, sharing less, immutable data, and finding better higher level parallel programming constructs should be what we focus our and other's precious brain cycles on, not getting slapped around by a borrower checker or thread sanitizer. We gotta climb out of this muck one of these decades.

   [1] If you are instead saying that people should think about the design of their system from the beginning so that they don't have to refactor as much, then I agree; but just don't waste time thinking about ownership, or worse, architecting ownership into the system; it will alter the design.

   Show morethread
2. bromonkeyMay 2020
   I started learning kernel internals from these books, I highly recommend all of them.

   Operating Systems: Three Easy Pieces (free online) - Arpaci-Dusseau

   Linux Device Drivers, 3rd ed (o'Reilly) - Jonathan Corbet

   The Linux Programming Interface - Michael Kerrisk

   The Design and Implementation of the FreeBSD Operating System (2nd ed) - McKusick, McKusick, Watson

   Solaris Internals - McDougall, Richard, Mauro

   Show morethread
3. pjmlpNov 2018
   If you like to have insights into how some UNIXes got built, these books are quite interesting.

   "The Design and Implementation of the 4.4 BSD Operating System"

   "The Design and Implementation of the FreeBSD Operating System"

   "Mac OS X Internals: A Systems Approach"

   "Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture"

   "HP-UX 11i Internals"

   "IA-64 Linux Kernel: Design and Implementation"

   Show morethread
4. agaponJan 2014
   Not exactly the same thing but I found the following books quite useful for understanding how a lot of kernle code works: - The Design and Implementation of the FreeBSD Operating System - Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture

   Still, nothing beats reading the source code :-)

   thread
5. crackezJan 2024
   We used to have a piece of Java software called Scout - it did a lot of small memory allocations... Led to runtime of multiple days for some datasets. I was reading the book Solaris Internals. The edition I had was updated for the ultrasparc 3's, and I was reading that section that talked about memory pages and the new support for huge pages, eg 4GB pages. We switched on 4GB pages and the week long runs of Scout went to only a few hours. That performance gain was real money and time.

   That was an interesting trip down memory lane.

   Show morethread
6. avg_devJan 2024
   i didn't know what i was expecting when i started to read this but it wasn't that. i didn't know the author before the article but i thought it was really an amazing read. i think it speaks very well to the power of collaboration and a congenial and healthy work environment.

   as another commenter mentioned the thing about the branch prediction bit flipping in awk was quite something. the SE Toolkit to monitor kernel perf, which could run for years without issue - was something cool too. the guy who found and fixed a kernel bug offering the biggest performance win in Solaris 8 in the course of writing the first book in a series called Solaris Internals - wow. the description of "the can of worms project" in which they run workloads that look like what customers might use, things that that go beyond typical eng team benchmarks, and the meltdown prevention and heading off of customer issues, it's a great concept from my personal point of view. i appreciated the touching on other more human subjects like the capacity planning DB pricing calculator for customers and the bizdev, relationship, and product design points.

   i started off being jealous of what the guy was saying but i was so blown away by everything that i had forgotten that feeling by the end of the article. it was replaced with awe.

   Show morethread