The December 14, 2025 release of DietPi v9.20 introduces a new remote desktop server option, continued improvements for popular Arm-based single-board computers, and a broad set of fixes across DietPi tools and software packages. The update focuses on usability, stability, and hardware compatibility, particularly around USB, storage, and backup handling. DietPi: DietPi is a […]

> Day 10: Factory In this challenge we need to turn some machines on and get them to use the correct joltage. > The manual describes one machine per line. Each line contains a single indicator light diagram in [square brackets], one or more button wiring schematics in (parentheses), and joltage requirements in {curly braces}. [.##.] (3) (1,3) (2) (2,3) (0,2) (0,1) {3,5,4,7} [...#.] (0,2,3,4) (2,3) (0,4) (0,1,2) (1,2,3,4) {7,5,12,7,2} [.###.#] (0,1,2,3,4) (0,3,4) (0,1,2,4,5) (1,2) {10,11,11,5,10,5} ## Part 1 In this part we are asked, “What is the fewest button presses required to correctly configure the indicator lights on all of the machines?” I do not like admitting that the first part of this one tripped me up. Parsing the text was easy enough but frankly I was not sure how to hnadle that information once it was read in and split apart. I tried a few things but my solutions ended up overcounting and I could not track down why. For this reason I sought someone elses solution that I could learn from. On the subreddit there was a vanilla Python solution that used sets and bitwise operators. First the lights are converted to be a decimal representation of the binary value where “.” is a 0 and “#” is a 1. This is done from left to right so the second light in the example of […#.] is read as 01000 = 8. Next each of the button presses are translated to a decimal representation of the binary value communicated. For the buttons [‘(3)’, ‘(1,3)’, ‘(2)’, ‘(2,3)’, ‘(0,2)’, ‘(0,1)’] where the number is the index for the lights. As an example (3) = 1000 = 8 and (1,3) = 1010 = 10. I’ve spent a bunch of time staring at this bit of code but I think I’ve got it now. current_lights = set(lights ^ btn for lights in current_lights for btn in buttons) This is contained in a for loop that iterates the number of button presses and followed up by an if statement that checks if the target (desired light combination) appears in the resulting set. A set is used to make sure each of the values added are unique. If there are multiple ways to get to the same number we don’t care since we’re counting presses and not button press combinations. This creates a set of (lights XOR buttons) for all lights in the current set. Each successive loop of this operation applies all button presses to each possible light state. This works since the lights work like binary operators. If a light is off “.” and the button press would interact with it then it turns on “#”. If the light is on “#” and the button press would interact with it then it turns off “.”. This exactly how XOR works and since integers compared with “^” are compared as binary this setup generates light possibilities in the form of the decimal representation of binary interactions. ## Part 2 This part asks, “What is the fewest button presses required to correctly configure the joltage level counters on all of the machines?” The light state is ignored and instead the button presses changes the joltage as communicated in the curly braces. This is the first time I had to install another library to get this to work. I did not come up with this solution but am instead writing to make sure I have some understanding of what’s happening here. The solution I found used SciPy and specifically LinearConstraint, milp, and Bounds. Once the variables for this function are set milp (Mixed-integer linear programming) function can return the desired value. result = milp(c, constraints=constraints, bounds=bounds, integrality=integrality) This is run for each line and the sum is calculated. I need to dig into exactly how this one works as I’m not sure what is happening under the hood.

Cinebench 2026 out and ready to hammer CPUs and graphics cards six times as hard

A turn based tactics style Roguelike mecha RPG set in a world recovering from the apocalypse. Take control of an 18m, 50 ton death machine and build a team of unique lancemates. Features include a det...

What are you doing this week? Feel free to share! Keep in mind it’s OK to do nothing at all, too.

uv installs packages faster than pip by an order of magnitude. The usual explanation is “it’s written in Rust.” That’s true, but it doesn’t explain much. Plenty of tools are written in Rust without being notably fast. The interesting question is what design decisions made the difference. Charlie Marsh’s Jane Street talk and a Xebia engineering deep-dive do an excellent job at covering the technical details. Let’s dig into the design decisions that led to it: standards that enable fast paths, things uv drops that pip supports, and optimizations that don’t require Rust at all. ## The standards that made uv possible pip’s slowness isn’t a failure of implementation. For years, Python packaging required executing code to find out what a package needed. The problem was setup.py. You couldn’t know a package’s dependencies without running its setup script. But you couldn’t run its setup script without installing its build dependencies. PEP 518 in 2016 called this out explicitly: “You can’t execute a setup.py file without knowing its dependencies, but currently there is no standard way to know what those dependencies are in an automated fashion without executing the setup.py file.” This chicken-and-egg problem forced pip to download packages, execute untrusted code, fail, install missing build tools, and try again. Every install was potentially a cascade of subprocess spawns and arbitrary code execution. Installing a source distribution was essentially `curl | bash` with extra steps. The fix came in stages: * PEP 518 (2016) created pyproject.toml, giving packages a place to declare build dependencies without code execution. The TOML format was borrowed from Rust’s Cargo, which makes a Rust tool returning to fix Python packaging feel less like coincidence. * PEP 517 (2017) separated build frontends from backends, so pip didn’t need to understand setuptools internals. * PEP 621 (2020) standardized the `[project]` table, so dependencies could be read by parsing TOML rather than running Python. * PEP 658 (2022) put package metadata directly in the Simple Repository API, so resolvers could fetch dependency information without downloading wheels at all. PEP 658 went live on PyPI in May 2023. uv launched in February 2024. The timing isn’t coincidental. uv could be fast because the ecosystem finally had the infrastructure to support it. A tool like uv couldn’t have shipped in 2020. The standards weren’t there yet. Other ecosystems figured this out earlier. Cargo has had static metadata from the start. npm’s package.json is declarative. Python’s packaging standards finally bring it to parity. ## What uv drops Speed comes from elimination. Every code path you don’t have is a code path you don’t wait for. uv’s compatibility documentation is a list of things it doesn’t do: **No .egg support.** Eggs were the pre-wheel binary format. pip still handles them; uv doesn’t even try. The format has been obsolete for over a decade. **No pip.conf.** uv ignores pip’s configuration files entirely. No parsing, no environment variable lookups, no inheritance from system-wide and per-user locations. **No bytecode compilation by default.** pip compiles .py files to .pyc during installation. uv skips this step, shaving time off every install. You can opt in if you want it. **Virtual environments required.** pip lets you install into system Python by default. uv inverts this, refusing to touch system Python without explicit flags. This removes a whole category of permission checks and safety code. **Stricter spec enforcement.** pip accepts malformed packages that technically violate packaging specs. uv rejects them. Less tolerance means less fallback logic. **Ignoring requires-python upper bounds.** When a package says it requires `python<4.0`, uv ignores the upper bound and only checks the lower. This reduces resolver backtracking dramatically since upper bounds are almost always wrong. Packages declare `python<4.0` because they haven’t tested on Python 4, not because they’ll actually break. The constraint is defensive, not predictive. **First-index wins by default.** When multiple package indexes are configured, pip checks all of them. uv picks from the first index that has the package, stopping there. This prevents dependency confusion attacks and avoids extra network requests. Each of these is a code path pip has to execute and uv doesn’t. ## Optimizations that don’t need Rust Some of uv’s speed comes from Rust. But not as much as you’d think. Several key optimizations could be implemented in pip today: **HTTP range requests for metadata.** Wheel files are zip archives, and zip archives put their file listing at the end. uv tries PEP 658 metadata first, falls back to HTTP range requests for the zip central directory, then full wheel download, then building from source. Each step is slower and riskier. The design makes the fast path cover 99% of cases. This is HTTP protocol work, not Rust. **Parallel downloads.** pip downloads packages one at a time. uv downloads many at once. This is concurrency, not language magic. **Global cache with hardlinks.** pip copies packages into each virtual environment. uv keeps one copy globally and uses hardlinks (or copy-on-write on filesystems that support it). Installing the same package into ten venvs takes the same disk space as one. This is filesystem ops, not language-dependent. **Python-free resolution.** pip needs Python running to do anything, and invokes build backends as subprocesses to get metadata from legacy packages. uv parses TOML and wheel metadata natively, only spawning Python when it hits a setup.py-only package that has no other option. **PubGrub resolver.** uv uses the PubGrub algorithm, originally from Dart’s pub package manager. pip uses a backtracking resolver. PubGrub is faster at finding solutions and better at explaining failures. It’s an algorithm choice, not a language choice. ## Where Rust actually matters Some optimizations do require Rust: **Zero-copy deserialization.** uv uses rkyv to deserialize cached data without copying it. The data format is the in-memory format. This is a Rust-specific technique. **Lock-free concurrent data structures.** Rust’s ownership model makes concurrent access safe without locks. Python’s GIL makes this difficult. **No interpreter startup.** Every time pip spawns a subprocess, it pays Python’s startup cost. uv is a single static binary with no runtime to initialize. **Compact version representation.** uv packs versions into u64 integers where possible, making comparison and hashing fast. Over 90% of versions fit in one u64. This is micro-optimization that compounds across millions of comparisons. These are real advantages. But they’re smaller than the architectural wins from dropping legacy support and exploiting modern standards. ## The actual lesson uv is fast because of what it doesn’t do, not because of what language it’s written in. The standards work of PEP 518, 517, 621, and 658 made fast package management possible. Dropping eggs, pip.conf, and permissive parsing made it achievable. Rust makes it a bit faster still. pip could implement parallel downloads, global caching, and metadata-only resolution tomorrow. It doesn’t, largely because backwards compatibility with fifteen years of edge cases takes precedence. But it means pip will always be slower than a tool that starts fresh with modern assumptions. The takeaway for other package managers: the things that make uv fast are static metadata, no code execution to discover dependencies, and the ability to resolve everything upfront before downloading. Cargo and npm have operated this way for years. If your ecosystem requires running arbitrary code to find out what a package needs, you’ve already lost.

Ruby 4.0 full and annotated changelog