1 karma · joined September 1, 2023
The docker use-case is tricky, as images are immutable so you have to basically create a new image with the cert in place.
MITMProxy is a tool I reach for when I need to know what requests and responses something is making.
I was introduced to it when tracing bugs between a docker client and non-api conforming docker registry. But since then I find myself reaching for it whenever I want to see the https requests something I am running is making. It's a bit of a pain to the CA, so I thought I would document the steps, including how to man in the middle requests of a docker container you are running.
I know some people reach for Wireshark to look at network requests, but I've never really mastered Wireshark. mitmproxy has a very intuitive UI and is excellant if you just interested in http and https requests.
My understanding is they are looking at page management activity and whether it increases above what they would expect if they didn't notify.
Some of the details are covered in the paper [1]
>The Markov Decision Process (MDP) is based on a sequence of notification candidates for a particular person. The actions here are sending and dropping the notification, and the state describes a set of features about the person and the notification candidate. There are rewards for interactions and activity on Facebook, with a penalty for sending the notification to control the volume of notifications sent. The policy optimizes for the long term value and is able to capture incremental effects of sending the notification by comparing the Q-values of the send and drop action
> The training data spans multiple weeks to enable the RL model to capture page admins’ responses and interactions to the notifications with their managed pages over a long term horizon. The accumulated discounted rewards collected in the training allow the model to identify page admins with longterm intent to stay active with the help of being notified.
I think that is the hardest question, what to optimize for. Jason mentions that facebook employs social scientists who help set what the value is they are optimizing for.
> I don’t work on the social science part of it. We try to optimize and we do it on good faith that the goals we’re optimizing for are good faith goals. But I’ve been in enough of the meetings to see the intent is really a good intent. It’s just a thing that’s very difficult to quantify.
> But I do think that the intent is to provide that value. And I do think that they would trade some of the margin for the value in a heartbeat.
Replying here to sibling: Thank you for the feedback. I think it is fair to say this interview does not explore in depth the issues that these techniques can cause and it certainly only presents one side. I think the recommendation to get more than one perspective is a good one.
Let me know if there is anyone specific you recommend I talk to.
I think you are correct to have concerns around optimizing for pure engagement though. These algos are giant optimizing machines. What should we be asking them to optimize? That seems like an important question that was only vaguely touched on in this discussion.
Jason Gauci joined facebook to try to solve some problems with the newsfeed using reinforcement learning. He originally got into ML via training bots to play capture the flag. What he ended up creating is open source [1].
[1]: https://reagent.ai/
https://idris2.readthedocs.io/en/latest/typedd/typedd.html#t...
Many of these, I suspect are not book length but more essay or novella length (< 30,000 words ).
That is fine, I don't need people to pad out a book, but I'd like to understand the length a bit before hand.
Even if you know about branch prediction, then asking the guest to explain it, maybe even pretending not to know about it, is a great way to have concepts introduced and make things more approachable.
Lex wouldn't be as popular as he was if he didn't have a good sense for the level of knowledge his ideal listener has about the subject.
I also think there are many straight interview podcasts and I'm trying to do something different.
I spend way too much time lurking on hacker news so having this show up here is both exciting and frightening for me ... be careful what you wish for.
The UNIX room - The unix room at bell labs was a shared room where they would hang out and have coffee. Some people worked exclusively in the UNIX room, like Ken Thompson, but most worked in their private offices and came to the UNIX room to share what they worked on and have a coffee and catch up. This room was the culture center of the computing group at Bell Labs.
Because they were all sharing a file system on a single machine, it was easy for various people to iterate on programs. They only had one rule which was if you changed the program last, you were the owner. In some ways, it mirrors how open source works today.
Brian is super modest and claims to be a horrible programmer but he is comparing himself to Ken Thompson, who he thinks is just incredible. Ken once wrote a disassembler, assembler and B interpreter for a mini-computer that ran a printer they were struggling with, in a couple of days, so that they could get it printing again. This blew Brian's mind.
At the time, Brian didn't think that the work they were doing was 'important' in a big sense. The culture was more like working with computers is hard, let's try to make it better and lets try to solve practical problems.
The book "Unix: A History and a Memoir" has many other great details.
Is that where the innovation is here, Darcs style patch sets?
Zettelkasten Method can make a lot of sense in contexts like that. If you are writing a weekly blog, keep building notes up and polishing parts of them for the blog. Then your note taking process is in fact your blog writing process, but a bit more procedurally free form.