Your brother mentioned hearing OpenAI isn't turning a profit. Here's what Zvi has written:
From AI #133: America Could Use More Energy (Sep 11, 2025):
"OpenAI is now projecting that it will burn $115 billion (!) on cash between now and 2029, about $80 billion higher than previously expected."
A summary of Zvi Mowshowitz's AI analysis for someone asking about the Tom's Guide "Gemini 3 vs ChatGPT 5.1" comparison article.
Zvi's headline: "Gemini 3 Pro Is a Vast Intelligence With No Spine"
| #!/usr/bin/env bash | |
| : <<'END' | |
| Script Name: madge_concatenator.sh | |
| Purpose: | |
| This script uses 'madge' to find all dependencies for a given TypeScript/JavaScript | |
| entry file, and then concatenates all found files into a single output file. | |
| The output file will contain the absolute file paths and contents of each code file, | |
| separated by a delimiter (```). This is useful for providing a large codebase |
Below is a 2025-focused playbook you can share with newcomers who want to “get their hands into a big code-base, learn fast, and land that first dev role.” In short: open-source is still the best proving ground, but the on-ramp is very different from when you broke in (2014). Cloud dev environments, Discord communities, AI pair-programmers, and funded mentorships mean you can contribute product-grade code in hours—not weeks—and get real humans vouching for you along the way.
| #!/usr/bin/env bash | |
| # Kafka Partition End Offset Checker | |
| # ================================== | |
| # | |
| # This script queries a Kafka cluster to retrieve the end offset information for all partitions | |
| # of a specified topic. It provides the log end offset for each partition, which represents | |
| # the offset where the next message would be appended. | |
| # | |
| # Usage: |
NB: Assumes OS X
FES consumes events from the fes-async-in and the sts-delivery-tracking-events kafka event streams. The latter has never posed a problem, so this document is geared to talk about the former. Regarding fes-async-in, our order management systems send and receive kafka messages through it to communicate with our fulfillment management system. Prior to the solution, we in FMS would occasionally receive a kafka message that we couldn’t consume due to a bug, bad data, etc. When this happened, our kafka consumer tried this message again and again, literally forever. This “just try again” policy is great for transient errors, such as database locking. However, it's a problem if this error isn’t transient, as all other messages behind it are now blocked and will never be processed. This is what we call a "stuck message".
Inspired by this Uber blog post, we wrote [special "punt" code](https://github.com/blueapron/fulfillment-engine/pull
| #!/usr/bin/env bash | |
| : <<'END' | |
| Script Name: code_concatenator.bash | |
| Purpose: | |
| This script is designed to concatenate all code files within specified directories | |
| and their subdirectories, or specified individual files, into a single output file. | |
| The output file will contain the file paths and contents of each code file, | |
| separated by a delimiter (```). This script is particularly useful for preparing |
| #!/usr/bin/env bash | |
| : <<'END' | |
| Script Name: compress_photos.bash | |
| Purpose: | |
| This script is designed to compress a directory of photos to ensure the total | |
| size is under a specified limit (25 MB by default). It's particularly useful | |
| for preparing image files for platforms with strict upload size limits or for | |
| optimizing storage. The script iterates over a set of image files, applying |