Amazon have filed a non-compete case against one of their sales execs who left and moved to Google. ouch
it’s the empress tree, which can absorb 10x to 100x the quantity of CO2-per-acre vs other tree species
Wow, this is a great answer. As he notes, the Scrum-style process is flawed for big backend projects: “This style of short-term planning, direct customer contact, and continuous iteration is well suited to software with a simple core and lots of customer visible features that are incrementally useful. It is not so well suited to software which has a very simple interface and tons of hidden internal complexity, software which isn’t useful until it’s fairly complete, or leapfrog solutions the customer can’t imagine.” And he goes on to come up with something which works better for Google-style projects:
Our highest priority is to increase customer (and programmer) productivity and access to information. Work on the biggest, most frequently used problems you can find, and create the largest net impact. Don’t give the customer what they ask for; understand them, and revolutionize their world. Developers should create a Google Design Document (a fairly minimal, but structured design doc), explaining the project, what goals it hopes to achieve, and explains why it can’t be done in other ways. This document should be circulated with stakeholders, to get early feedback before the project gets underway. The written record is essential, as it assures there is a clear and agreed understanding of when the project is a success and how it aims to get there. At all phases of the project, critical design elements for larger components should be concisely explained and captured in a design document. Innovate in leapfrogs. It’s more important to finish and deploy a leapfrog than to attempt perfection. There is no perfection. Instead be flexible, and plan to constantly reinvent at every level of the stack. Deliver working software as soon as is reasonably possible, and no sooner. “Dogfood” projects internally before they are shipped externally. Make sure products meet high quality standards before shipping. The quality of the product is more important than the time it takes to achieve it.
CarbonKit provides all the data and models necessary for calculating various greenhouse gas emissions in categories such as car, train and air transport, types of fuel or country-specific grid electricity, electrical appliances, agricultural and industrial processes and building materials.
The goal is to take standard applications and JIT them to their AVX-512 equivalent such that we can fuzz 16 VMs at a time per thread. The net result of this work allows for high performance fuzzing (approx 40 billion to 120 billion instructions per second [the 2 trillion clickbait number is theoretical maximum]) depending on the target, while gathering differential coverage on code, register, and memory state. By gathering more than just code coverage we are able to track state of code deeper than just code coverage itself, allowing us to fuzz through things like memcmp() without any hooks or static analysis of the target at all. Further since we’re running emulated code we are able to run a soft MMU implementation which has byte-level permissions. This gives us stronger-than-ASAN memory protections, making bugs fail faster and cleaner.