bits.

Technology
& cybersecurity

Settings

Article collection

Technical articles

News, engineering writeups, and security research.

Checking service status…
Reading time Based on saved text
Latest discoveries
07
Technicalnetflixtechblog.com

Netflix Stratum Media Processing: Automated Container Right-Sizing

By Violetta Pidvolotska and Naveen Mareddy Stratum is Netflix’s internal serverless media processing platform, shaped by over a decade of experience developing large-scale distributed systems. It powers a wide range of media workloads — including encoding, packaging, inspection, and quality scoring — behind playback, advertising, studio workflows, AI embeddings, and more. Engineers develop Stratum functions by packaging application code and OS dependencies into OCI images. Stratum then schedules these containers as batch jobs on Netflix’s Titus compute platform, with upstream services triggering function executions. Every day, Stratum manages hundreds of thousands of containers across bursty, high-throughput, and latency-sensitive workloads. As Netflix’s core media processing platform, this load needs to scale as new content formats enter the catalog, such as podcasts , live events , sports , ads , or regional ingests like TF1 in France . To request resources for these functions, owners specify their CPU, memory, disk, and network limits as YAML configuration, as shown below: functionName: VideoEncoder.encodeV1 resources: numCpus: 8 memoryInMB: 18000 diskSizeInMB:

Read original ↗
08
Technicalnetflixtechblog.com

The Lifecycle of LLM-as-a-Judge: Building, Aligning, and Monitoring at scale

By Emma Yanyang Kong , JJ Tan , Ishan Gupta , Lars Olds , Claire Campbell , David Fagnan , Ratna Kavuri , Rohan Gosain , Veli Balin , Minsu Jang , Louis Garcia Introduction Any team generating text with an LLM at scale hits the same problem. You cannot evaluate everything manually. You don't know which outputs are great, which are mediocre, and which are harmful, because you simply cannot read them all. The standard solution is LLM-as-a-Judge , a second model that scores the first model’s output as a proxy for human raters. It is fast, cheap, and easy to deploy. However, it introduces a new and critical question: Who evaluates the evaluator? Furthermore, if the judge drifts, quietly degrading and starting to approve bad output, nothing downstream will flag it. This post is about how we solve that problem, by building, aligning, and continuously monitoring LLM judges so they stay trustworthy over time. Our core principle is simple: An LLM judge must never operate alone. It has to be anchored in human judgment. We keep a human-in-the-loop (HITL) at every phase of the lifecycle. Humans define what “good” means, create the labeled benchmark datasets to train and valid

Read original ↗
18
Technicalmartinfowler.com

Fragments: September 8

dealing with AI's counterfeit utility, exasperated readers of LLMs, missing Creating Passionate Users, agents lack Verum Factum, three people making key decisions on AI

Read original ↗
21
Technicaldaniel.haxx.se

A curl audit by Aisle

Over the last year or so, multiple engineers at Aisle have spent a lot of time and energy while pointing their AI powered tooling at the curl source code. This has resulted in no less than thirty-five published curl vulnerabilities and CVE Ids. Today, we make Aisle's audit report available on the curl website. Yet … Continue reading A curl audit by Aisle →

Read original ↗
22
Technicaldaniel.haxx.se

OSI approved the curl license

curl started out GPL licensed, as direct inheritance from its httpget days, but in October 1998 we switched to the Mozilla Public License (MPL). In 2001, we added the MIT license as an additional license to optionally use in addition to MPL. We made curl dual licensed because clearly the MPL license caused problems for … Continue reading OSI approved the curl license →

Read original ↗
23
Technicalantirez.com

The real AI risk is inside the labs - <antirez>

Amodei in his latest blog post wrote a mix of agreeable things and things that I believe misrepresent where the real risk of AI is located. I want to focus my attention on why, among all the risks, open weight models constitute the mildest one. I write these words as a person who strongly believes AI may be very dangerous in the near future: 1. Exactly like what happened during the OpenAI / HF incident (which was a joke, but focus on the modalities, not the outcomes), the first serious AI incident is very likely to happen *inside* the walls of frontier AI labs, while testing a new model, or while the AI lab employees, or the few externals who have access, do something wrong compared to the expected power of the model. 2. Closed models that will never even be opened to the public will be just a few TBs of data. All you need to leak one is a single person with access and the wrong goals, and you are back in the situation of open models. Open models are released *after* testing, and after similarly capable models were already available for some time under an API. The real risk is leaks, not releases, and leaks happen inside frontier companies. 3. As Amodei says, open models,

Read original ↗
24
Technicaleli.thegreenplace.net

Monte-Carlo simulations - Eli Bendersky's website

Monte Carlo simulations (or methods ) is the technique of applying randomness and the Law of large numbers to the solution of various scientific and engineering problems. One of its first documented uses was by Stanislaw Ulam and John von Neumann for nuclear weapon simulations after WWII [1] . In this post …

Read original ↗