The paper documents "congestion collapse" in the early internet. Too many TCP packets were sent at once, some were dropped, resent, dropped again, resent again, and so on, causing bandwidth to drop. The paper then goes on to present ways to scale the number of packets sent according to the number of packets acknowledged or lost.
What distinguishes senior practitioners from juniors, in software development and in other crafts, is the number of errors they've already made and the lessons they learned from those errors.
Those mistakes and learnings together inform their judgement when approaching tasks and allow them to ask questions like:
* Is this code robust enough? (They ask because of the many times they pushed code and suddenly everything broke.)
* Should we even be building this? (They ask because of that one time they didn't ask, and wasted weeks of effort on something that was never used.)
* Is approach A the best way to achieve our goal? (They ask because of that one time they tried A, thought it would take one week, but spent two months on it instead.)
* What happens when we're asked to add X feature? (They ask because of that one time they were surprised by a feature request and had to rewrite a bunch of their code.)
On Android, you can distribute, download, and install .apk files outside of the Play Store [1]. There's also an app called f-droid [2] which acts as a 'store' for some open source apps.
You may want to hold off on both. SICP uses Scheme, a dialect of Lisp. Neither it nor Haskell closely resembles Python, and the differences may confuse rather than illuminate.
That said, once you're done with your class, by all means give them a look.
That appears to be the Intro to Operating Systems course from the Georgia Tech OMSCS program.
Udacity also hosts the GT Advanced Operating Systems course: https://www.udacity.com/course/advanced-operating-systems--u.... AOS is not a "how to" course, but rather a tour of the challenges operating systems may face (distribution, fault tolerance, scale) and of academic papers attempting to solve them (mostly from the 90s and 00s). As such, the material might not be a good fit for the original post, but this commenter found it fascinating.
> I guess I would like to have a solution that not only synchronises across all platforms (Linux, macOS, Windows, iOS), but most importantly is secure as my notes can contain sensitive information. If there is an open-source solution for this problem, I have no problem with self-hosting such system.
If access across machines and operating systems is a priority for you, you may want to set up a private wiki and ticket tracker, either on your own machine or with a cloud provider.
Org-mode files are tree-structured, so anything you can structure as a tree should work well with org-mode. The navigation controls work nicely: expanding/collapsing, reordering, searching within subtrees.
Can a monorepo support module- or subdirectory-level ownership controls? Or do teams using a monorepo just do without them?
Partially answering my own question: SVN, recommended in a prior comment [0], supports path-based authorization [1]. But what about teams using another version control system?
From an article [0] published in last month's CACM, describing attempts by three 2016 conferences to anonymize papers:
We find that anonymization is imperfect but fairly effective: 70%–86% of the reviews were submitted with no author guesses, and 74%–90% of reviews were submitted with no correct guesses.
Here's one I enjoyed: "Congestion avoidance and control," by Jacobson, 1988. https://dl.acm.org/doi/pdf/10.1145/52325.52356
The paper documents "congestion collapse" in the early internet. Too many TCP packets were sent at once, some were dropped, resent, dropped again, resent again, and so on, causing bandwidth to drop. The paper then goes on to present ways to scale the number of packets sent according to the number of packets acknowledged or lost.