Reddit Reddit reviews The Systems Bible: The Beginner's Guide to Systems Large and Small

We found 5 Reddit comments about The Systems Bible: The Beginner's Guide to Systems Large and Small. Here are the top ones, ranked by their Reddit score.

Humor & Entertainment
Books
Humor
The Systems Bible: The Beginner's Guide to Systems Large and Small
General Systemantics Pr
Check price on Amazon

5 Reddit comments about The Systems Bible: The Beginner's Guide to Systems Large and Small:

u/initech__ · 2 pointsr/sysadmin

Lazy. That is the number one top quality you can find in a sysadmin. Here is a decent list why:

Lazy Admin

Also, learn systems theory and how complex systems operate, so that you don't stay a server monkey. And buy this book:

The Systems Bible

u/nicbrown · 2 pointsr/Coffee

There is a reason that so many commercial machines are designed around the E61 brew group, or are a close facsimile of it. It works.

An espresso machine involves systems thinking rather than just overcoming a series of hurdles. It is chemistry, plus engineering, plus systems interface for the end user.

Breville have have probably done the most, engineering wise, to rethink the budget espresso machine in recent years (as opposed to the 'classic' simplified commercial designs of Gaggia and Rancilio etc). It has been a long hard road, of thermoblock leaks, controller failures, pucks adhering to the brew group filter from back suction, and pumps vibrating the portafilter until it drops off mid brew, and many, many more obstacles. Lessons learnt. The low end is difficult.

From The Systems Bible:

> A complex system that works is invariably found to have evolved from a simple system that worked. The parallel proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

Or, in espresso terms, start with an E61 brew group.

u/vogelke · 2 pointsr/sysadmin

> Can you be more specific on the book you mentioned?

Easy peasy. I've got the first version below, I don't know about the others:

u/TOASTEngineer · 1 pointr/liberalgunowners

I dont think those are necessarily incompatible They're relatively competent plotters who don't give a shit about the country and the system is too big and fucked up to change anything for the better.

There's a book called The Systems Bible that tries to explain why organizations and systems full of competent people who want to get the job done still can't actually accomplish any forward progress.

u/oilshell · 1 pointr/ProgrammingLanguages

Well I wasn't suggesting that the compiler infer the right allocation type. I was suggesting that there be tools so that programmers can figure out the allocation types to tell the compiler.

In other words it doesn't seem sufficient to just have a mechanism for the compiler to safely combine different allocation types. I would like some kind of dialogue and feedback with the compiler based on real measurements -- I actually don't want it to be magic.

Most GCs already use a fixed 2- or 3-level policy, e.g. a young generation and an old generation. But once you allow more flexibility than that, you not only have the opportunity for optimization, but also pessimization :)

I mean it depends how big the codebases you're targeting are. If you are thinking of 20K lines of code all written by one programmer, then yes maybe that person can do a great job of choosing the allocation type.

But if you're thinking of 100K or 1M line codebases written by many people, I think the mechanism is only beginning. Consider that C++ allows you tons of knobs to tune performance. Yet in real codebases people are not able to do it.

Here is an example:

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/EUqoIz2iFU4

std::string is responsible for almost half of all allocations in the Chrome browser process; please be careful how you use it! In the course of optimizing SyzyASan performance, the Syzygy team discovered that nearly 25000 (!!) allocations are made for every keystroke in the Omnibox. We've since built some rudimentary memory profiling tools and have found a few issues:

This is in Chrome, one of the most widely used C++ programs out there. It is also highly optimized -- in some components, like v8. The quality of engineers is high; they all know how to write good C++, but when you put them all together the result is really suboptimal.

I have a pessimistic view of software -- one book that exemplifies it is this:

https://www.amazon.com/Systems-Bible-Beginners-Guide-Large/dp/0961825170

e.g. "large systems always operate in degraded mode". I don't think anyone would argue that's not true of the web -- it operates in a perpetual and permanent degraded mode (while being fantastically useful). While I don't understand that much about 3DWeb, the same could be true if it gets large enough.

Anyway this might seem like it's coming out of left field... it's kind of a philosophical critique. The point is that I like the idea of gradual memory management in the abstract -- in fact I have a really inefficient codebase now in OSH that might benefit from it. But I guess from the incomplete picture I have it seemed like a lot the annotations were for single variables? e.g. lex or var? That doesn't seem like it will work well in a large program. Maybe I am misunderstanding.

I also think there is the idea of not devoting too much language real estate to one feature. I mentioned automatic data layout as a related performance optimization that could be just as important, and you might need "room" for that in your new language Cone.

tl;dr:

  • Whenever you look at dynamic measurements of how large programs behave and perform, you get a big surprise. Even if you wrote the program, or even if you paid a lot of money to hire excellent engineers :)
  • Memory management for small programs is sort of a solved problem, either by GC or C++-like programmer choices. But memory management for large programs is very much unsolved. So I guess that is why I am holding GMM up to a high standard.