https://en.wikipedia.org/wiki/United_States_Office_of_War_In... https://cartoonresearch.com/index.php/walt-disney-classified...
3,942 karma · joined April 20, 2010
[ my public key: https://keybase.io/gauntletwizard; my proof: https://keybase.io/gauntletwizard/sigs/WLBbW433_lqvZr3EFcUj8sCaut00PcbdQ5dKfxC0TV4 ]
https://en.wikipedia.org/wiki/United_States_Office_of_War_In... https://cartoonresearch.com/index.php/walt-disney-classified...
I am a Site Reliability Engineer (SRE), Google Style, with experience at both large and small organizations. I can help you build a Platform Engineering practice from the very beginning. I'm looking to help small dev teams increase their velocity by implementing best-practices of Devops: CI/CD, Kubernetes Deployments, and effective Monitoring frameworks.
Check out my recent talk at SRECon: https://youtu.be/dswPHnfGwlY
My resume: https://resume.gauntletwizard.net/ThomasHahnResume.pdf
My LinkedIn: https://www.linkedin.com/in/thomas-hahn-3344ba3/
My Github: https://github.com/GauntletWizard
Request logging should be done in a structured form. You don't need an indexing solution for this kind of request logging - It's vaguely timestamp ordered, and that's about it. If you need to search it, it gets loaded into a structured data query engine - Spark, or Bigquery/Athena.
Audit logging belongs in a durable database and it requires being written and committed before the request is finished serving - Logging frameworks that dump to disk or stdout obviously fail his requirement.
https://www.iana.org/assignments/protocol-numbers/protocol-n...
The problem is one of degrees - Anyone you notice on a big site is likely posting very often - "Terminally online" is the word. The more niche you go, they are alternatively deeper into their own fantasy worlds. I haven't figured out how to arrange coincidence; Repeated coincidental meetings have long been studied to be the basis of friendship, and intentionally going to "meetups" where the attendance is common but not fixed is the best way to foster that.
Online matchmaking has been the biggest problem here - You are guaranteed a game, but you'll never run into the same people twice. Once upon a time you had localish communities form around servers that were low-ping to them, which really worked well - You were likely to run into the same people, and they were likely to be nearby but not so close that you'd have run into them anyway.
I am a Site Reliability Engineer (SRE), Google Style, with experience at both large and small organizations. I can help you build a Platform Engineering practice from the very beginning. I'm looking to help small dev teams increase their velocity by implementing best-practices of Devops: CI/CD, Kubernetes Deployments, and effective Monitoring frameworks.
Check out my recent talk at SRECon: https://youtu.be/dswPHnfGwlY
My resume: https://resume.gauntletwizard.net/ThomasHahnResume.pdf
My LinkedIn: https://www.linkedin.com/in/thomas-hahn-3344ba3/
My Github: https://github.com/GauntletWizard
We do something obviously silly for this exercise - we assume that all caches are cold, because the point of a recursive DNS server is mostly to act as a cache. So we'll be going through a bunch of queries that usually are simply answered from cache instead.
At the top are 13 "root dns servers". These return responses for top level domains, such as ".com". When you want to request www.google.com, first you have to ask who controls ".com". Your recursive server (just "you" from now on) sends a request to the root servers - "Who are the nameservers (ns) for .com?" Also written as "QUERY .com NS". The root servers will answer - "A(answer) .com NS 1.2.3.4 AA (Authoritative answer)". The root dns servers believe they are the authority for the "." Zone, because they are.
The recursive resolver, you, then use this knowledge. You ask a similar query of the ".com" nameservers - "Q google.com NS" they respond, giving you an authoritative answer for google.com "A google.com NS nameservers.google.com AA". But you don't know who the nameservers for google.com, how do you resolve this loop? DNS has a mechanism for that. It includes a few extra records, called glue records, to close the gap. "X(tra) nameservers.google.com 8.8.9.9"
Finally, you know who the nameservers for google.com are - You then send them a request. "Q www.google.com A(Internet Protocol)" you might instead send an AAAA request, for an ipv6 address, instead.
There's a ton more - Support for text records of arbitrary type, support for addressing schemes that no longer see use, etc. but thems the basics. You can run your own whole Internet, if you want to - Just build your own recursive server pointing at your own roots, and then host whatever you want on whatever up you want - Just don't expect to be able to connect to the real Internet at the same time. Also basically everything phones home and breaks. :shrug:
It's not that I trust randos on reddit, it's that even when they're wrong, I can link someone to the same bad advice and it doesn't change on me, for the most part.
git = !cd -- ${GIT_PREFIX:-.} && gitThis was a base act of legal buffoonery. It is transparently bullshit.
Software tends to rot, though, and software at Google double so.
What we're bad at is asymmetric warfare of the 100:1 and 1000:1, as Iraq and Afghanistan have shown.
It's also based on observations of performance - for many moons, the performance hit of swapping was bad enough that it was never worth it to run two jobs concurrently that didn't both fit into ram together. The exceptions weren't even exceptions. Disk thrashing was a serious impediment and way to slow your whole fleet down.
Now with fast flash being so common, swap is probably actually a good thing for many workloads again, but only "many", and SREs would prefer you make that explicit by using memory mapped files for data that's of random utility, so that the OS can manage that pressure for you, understanding that those files don't need to be fully resident.
[1] This is an oversimplification that I don't remember the real truth of off the top of my head