252 karma · joined January 27, 2016
The author makes some wise predictions on Apple's response to the lawsuit. Particularly on whether Apple will appeal the injunction because it was based on the UCL, but the injunction applies nationwide. Though no matter what happens, I hope consumers and developers get a fair shake.
Side note: if you end up dual booting your gaming PC, please learn from my mistakes and disable Fast Startup before you do. Otherwise you're going to have a bad time.
[0] https://newzoo.com/insights/articles/newzoo-games-market-num...
Plus, while there is an abundance of sales materials out there, none of them will prepare you as well as actually doing the thing. I'm not scared of talking to customers, no matter what impressive titles they may bring to the table -- I've already spoken with dozens of other CTOs, CISOs, COOs, etc. from the deals I worked on. I'm acutely aware of the art of a pitch, and have a mental model for which techniques are crucial and which are to be avoided. After practicing the pitch/demo enough, I was able to start analyzing my choice of words, flow, etc. during the actual call (as opposed to after the fact). I also learned the art to managing deal cycles, and an immediate "no" is vastly preferable to a "no" after being strung along for a year. Perhaps most importantly, I learned how to be the trusted technical advisor to the customer -- the sales rep may want every deal to close, whether or not it's a good fit, but that's not the way to happy customers and good integrity in the sales process.
I only did the sales engineering role for a little under a year, but it provided me with incredible value.
[0] https://github.com/p4lang/p4c/blob/main/backends/ebpf/README... [1] https://github.com/vmware/p4c-xdp [2] https://opennetworking.org/news-and-events/blog/p4c-ubpf-a-n...
[0] https://www.lightreading.com/5g/intels-reorg-puts-nick-mckeo...
Operating Systems: Three Easy Pieces: In 2013, I found this book because I was frustrated with the textbook assigned for my operating systems class (Silberchatz). OSTEP has incredibly clear and concise descriptions without skimping on necessary details. It's wonderfully written. I was so jazzed up about this book that I ended up sending a lot of edits / improvements, and the authors gave me a very kind shoutout in the acknowledgements section.
Computer Networking: A Top-Down Approach: In 2013, this was the assigned textbook for my computer networking class. I already owned Tanenbaum & Wetherall which is good, but preferred this book. It is a more approachable treatment of networking (without sacrificing any crucial topics), so better for a first course.
I've heard glowing reviews of The Algorithm Design Manual, Designing Data-Intensive Applications, and Structure and Interpretation of Computer Programs over the years, but I haven't personally gone through them. For the TeachYourselfCS categories that I know the textbook landscape, I find their selections spot-on and pretty refreshing.
At a more detailed level, I find Folly much more substantial than Abseil. For example, both provide high performance hash tables. Abseil also provides a BTree-based map, which Folly does not. But Folly provides concurrent skip lists, LRU evicted hash maps, a high performance MPMC queue, etc. And that's just talking about data structures. Folly also has asynchronous I/O tools, futures, reference-counted buffers for IO, and many other things outside the scope of Abseil.
Personally, I am loving the asynchronous I/O mechanisms in Folly. It feels more expressive and results in cleaner code than boost ASIO. Just a first impression though, I am relatively new to the library.
In case you need an explanation: in the context of a forum, the parent comment is the one you are replying to, and the grandparent comment is the one your parent comment replied to.
A subset of the perceived issues with the reporting:
- How do the exploited servers phone home to China, when they were not connected to the open Internet? Not impossible, but it's asking for a lot of trust without more information. [0]
- One of the only named sources, Ryan Fitzpatrick, saying the details in their big hack article are identical to an example he constructed for the journalists to show that type of attack is plausible. The entire podcast is a great listen, but here is a direct quote: "In September when he asked me like, 'Okay, hey, we think it looks like a signal amplifier or a coupler. What’s a coupler? What does it look like?' […] I sent him a link to Mouser, a catalog where you can buy a 0.006 x 0.003 inch coupler. Turns out that’s the exact coupler in all the images in the story." [1]
- An accusation that the journalists who authored the Big Hack have had a previous story that made a big claim, they had many anonymous sources that back up their claims, but in the end there were extreme doubts of the veracity from people in the know. [2]
- Bloomberg sent another reporter, completely separate from the Big Hack article, in their tracks to discreetly talk to sources / involved parties to figure out the truth. [3]
Sources:
[0] https://daringfireball.net/2018/10/bloomberg_the_big_hack
[1] https://risky.biz/RB517_feature/
[2] https://threadreaderapp.com/thread/1049617855396933632.html
[3] https://www.washingtonpost.com/blogs/erik-wemple/wp/2018/11/...
Pertinent quotes from the article [0]: "The goal of this effort, Elgin told the potential source, was to get to 'ground truth'; if Elgin heard from 10 or so sources that 'The Big Hack' was itself a piece of hackery, he would send that message up his chain of command. The potential source told Elgin that the denials of 'The Big Hack' were '100 percent right.'"
"According to the potential source, Elgin also asked about the possibility that Peter Ziatek, senior director of information security at Apple, had written a report regarding a hardware hack affecting Apple. In an interview with the Erik Wemple Blog, Ziatek says that he’d never written that report, nor is he aware of such a document. Following the publication of Bloomberg’s story, Apple conducted what it calls a 'secondary' investigation surrounding its awareness of events along the lines of what was alleged in 'The Big Hack.' That investigation included a full pat-down of Ziatek’s own electronic communications. It found nothing to corroborate the claims in the Bloomberg story, according to Ziatek."
[0] https://www.washingtonpost.com/blogs/erik-wemple/wp/2018/11/...
XDP = eXpress Data Path. It is a new packet processing mechanism in the Linux kernel, which is in some ways an answer to DPDK and other userspace networking frameworks that skip the kernel in pursuit of high performance. It was originally proposed by Cloudflare, when they achieved poor scalability (in terms of packets per second) for something as simple as a packet drop rule in the kernel. The principle behind XDP is to leverage packet processing rules as early as possible in the packet processing pipeline (no wasted work). However, only certain types of rules are simple enough to be done in a high performance way -- complex rules would still be left to netfilter / ebtables.
The rules which XDP leverages, called extended Berkeley Packet Filters (eBPF) are a new take on an old technology. eBPF is a mechanism that allows userspace BPF rules to be inserted on-the-fly into the kernel. Essentially, matching rules which meet certain simplicity requirements (e.g. loop free) can be compiled into a bytecode that is executed by the kernel in a very efficient way. This is an extremely flexible technology, and one domain which it is well suited for is packet processing. BCC is just the set of compiler tools for creating your own eBPF bytecode.