# content addressed store A storage concept in which data is identified by an address derived from its content, commonly a cryptographic hash. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## What Is a Container Registry and How to Use One DevFeed: [What Is a Container Registry and How to Use One]() Original publisher: [Read original article]() Author: Pramodh Kumar M Published: 2026-08-10T17:48:35Z Content type: tutorial Language: en Sources: [Kubernetes - KodeKloud Blog | DevOps, Cloud, Kubernetes, AI Tutorials & More]() Topics: [container images](), [content addressed store](), [Docker Hub](), [Dockerfile](), [supply-chain-security]() Tags: [base-images](), [cache](), [ci-cd](), [cloud](), [container-images](), [container-registry](), [containers](), [content-addressed-store](), [cryptographic](), [devops](), [docker](), [docker-hub](), [docker-login](), [docker-pull-rate-limits](), [docker-registry](), [harbor](), [image-manifest](), [image-retention-policy](), [image-scanning](), [image-tags-vs-digests](), [kubernetes](), [private-registry](), [pull-through-cache](), [reproducible-builds](), [security](), [supply-chain-security]() ### AI overview This guide explains how container registries store and distribute container images, emphasizing the distinction between mutable tags and immutable content digests. It also covers pushing, pulling, authentication, Docker Hub rate limits, caching, scanning, and retention. ### Source excerpt A tag is a bookmark somebody else can move. A digest is the image itself. Once that distinction lands, reproducible builds, supply chain security, and every it worked yesterday mystery make sense. ## Nix 2.35.0 released DevFeed: [Nix 2.35.0 released]() Original publisher: [Read original article]() Author: lisanna Published: 2026-07-13T20:36:40Z Content type: release Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [releases](), [content addressed store](), [Security](), [hashing](), [integrity]() Tags: [bugfixes](), [content-addressed-store](), [hashing](), [improvements](), [integrity](), [new-features](), [nix-releases](), [releases](), [security]() ### AI overview Nix 2.35.0 is released with new features, bug fixes, performance improvements, and a security fix for recursive-nix. A highlighted change makes source copying to the Nix store more lazy, reducing unnecessary work for typical flake evaluations while preserving the evaluator's existing behavior. ### Source excerpt On behalf of the Nix team, I am pleased to finally announce the release of Nix 2.35.0. This release contains a good number of new features, bugfixes, and performance improvements, and is available at releases.nixos.org. This release also fixes a security issue with recursive-nix: https://github.com/NixOS/nix/security/advisories/GHSA-6h4g-g5j9-fm5f Release Notes Highlights Sources are copied to the store more lazily #3121 #15711 #15920 Historically, flakes source trees have been eagerly fetched to and evaluated from the Nix store to ensure deterministic and hermetic evaluation, even if the resulting store object is not used as a derivation input. This made the implementation simpler, yet made flakes unusable in large repositories and performed unnecessary writes to the store on each change to the source tree. Since Nix 2.32, all I/O (excluding path: and hg+:-style inputs) for reading sources during evaluation has been funneled to their original filesystem location (or to the ~/.cache/nix/tarball-cache-v2 bare git repository for tarball-based inputs). However, the source tree was still fetched to the store - primarily for computing the resulting content-addressed store path. In most cases, (such as importing the nixpkgs package set) this is not necessary. Touching (and hashing the NAR serialisation of) the whole source tree is unavoidable, since: In case of flake inputs, narHash integrity must be checked eagerly. The outPath attribute of a flake must be known in advance, and for backwards compatibility must be a content-addressed store path string with constant string context representing the flake source tree. Even within the constraints imposed by backwards compatibility requirements, there are several improvements that are achievable. To reduce the number of copies performed, Nix now hashes the input without copying first, assuming that the .outPath will not end up in a derivation attribute and thus would never have to be actually fetched to the store. This comes a ## IPIP-0499: Updating IPFS Standards for Consistent, Reproducible CIDs DevFeed: [IPIP-0499: Updating IPFS Standards for Consistent, Reproducible CIDs]() Original publisher: [Read original article]() Author: Michelle Lee Published: 2026-03-09T00:00:00Z Content type: release Language: en Sources: [IPFS]() Topics: [IPFS](), [content addressed store](), [configuration]() Tags: [ipfs](), [kubo](), [object-object](), [standards](), [verification]() ### AI overview IPIP-0499 has been merged into the IPFS specification and defines configuration profiles for DAG construction. Implementations that conform to the same profile produce the same CID for identical input, enabling direct CID comparison for verification and providing a more performant default for large files. ### Source excerpt IPIP-0499 makes IPFS CIDs deterministic and consistent across all implementations. ## Content-Addressing: A Year In Review DevFeed: [Content-Addressing: A Year In Review]() Original publisher: [Read original article]() Author: Robin Berjon Published: 2026-01-15T00:00:00Z Content type: opinion Language: en Sources: [IPFS]() Topics: [content addressed store](), [IPFS](), [P2P]() Tags: [2025](), [content](), [decentralized](), [ipfs](), [object-object](), [peer-to-peer](), [review](), [year-in-review]() ### AI overview A 2025 year-in-review of content addressing describes its role in data verification and independence from centralized authorities. It highlights IPFS community progress toward a more modular technology suite, including standards, specifications, and purpose-built libraries. ### Source excerpt Let's take a look at what happened in content addressing in 2025 -- it's a lot! ## How to Migrate IPFS Websites from Fleek to Modular Infrastructure DevFeed: [How to Migrate IPFS Websites from Fleek to Modular Infrastructure]() Original publisher: [Read original article]() Author: Marcin Rataj Published: 2026-01-06T00:00:00Z Content type: tutorial Language: en Sources: [IPFS]() Topics: [IPFS](), [hosting](), [content addressed store](), [GitHub Pages](), [Self-hosted](), [GitHub Actions]() Tags: [cloudflare](), [github-actions](), [github-pages](), [guide](), [how-to](), [infrastructure](), [ipfs](), [migrate](), [object-object](), [self-hosted]() ### AI overview This practical guide explains how the IPFS Project migrated more than 15 websites from Fleek after its hosting service was discontinued. It describes a modular setup combining GitHub Pages for HTTPS hosting, Kubo for CID and CAR creation, IPFS Cluster for pinning, and DNSLink for URL mapping, providing both HTTP and IPFS access. ### Source excerpt A how-to guide for future-proofing your content-addressed website hosting. ## Migrating the Hub from Git LFS to Xet DevFeed: [Migrating the Hub from Git LFS to Xet]() Original publisher: [Read original article]() Author: Jared Sulzdorf; Joseph Godlewski; Sam Horradarn Published: 2025-07-15T00:00:00Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [xet](), [migration](), [content addressed store](), [content defined chunking](), [Amazon S3](), [Git](), [Open Source]() Tags: [cas](), [content-addressed-store](), [content-defined-chunking](), [git](), [infrastructure](), [integration](), [migration](), [s3](), [storage](), [xet]() ### AI overview The article explains Hugging Face's migration of the Hub from Git LFS to Xet. It describes the Git LFS Bridge, background content migrations, content-defined chunking, the content addressed store, and S3-backed storage that enable gradual, large-scale migration without disrupting users. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## From Chunks to Blocks: Accelerating Uploads and Downloads on the Hub DevFeed: [From Chunks to Blocks: Accelerating Uploads and Downloads on the Hub]() Original publisher: [Read original article]() Author: Jared Sulzdorf; yuchenglow; Zach Nation; saba noorassa Published: 2025-02-12T00:00:00Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [hugging face](), [xet](), [content addressed store](), [AI, ML & Data Engineering](), [Open Source](), [Amazon S3]() Tags: [cas](), [collaboration](), [content-addressed-store](), [content-defined-chunking](), [dedupe](), [hugging-face](), [integration](), [network](), [performance](), [quantization](), [rust](), [s3](), [storage](), [xet]() ### AI overview Hugging Face's Xet team explains how content-defined chunking is being adapted for production to accelerate uploads and downloads on the Hub. The article describes the trade-offs of fine-grained deduplication, including network, infrastructure, metadata, and storage costs, and introduces a Rust-based chunk-oriented integration designed to improve experimentation and collaboration on models and datasets. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## Rearchitecting Hugging Face Uploads and Downloads DevFeed: [Rearchitecting Hugging Face Uploads and Downloads]() Original publisher: [Read original article]() Author: Banerjee; Jared Sulzdorf; Ann Huang Published: 2024-11-26T00:00:00Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [content addressed store](), [hugging face](), [Amazon S3](), [Amazon Web Services](), [huggingface\_hub](), [Compression](), [dataset](), [Latency](), [Network]() Tags: [aws](), [compression](), [content-addressed-store](), [dedupe](), [hugging-face](), [huggingface-hub](), [infrastructure](), [internet](), [latency](), [s3](), [speed](), [storage](), [xet]() ### AI overview Hugging Face is redesigning the Hub's upload and download architecture to handle increasingly large model and dataset files. The proposed design introduces a content-addressed store, custom chunk-aware transfer protocols, byte-level processing, deduplication, and compression while continuing to use S3 for data storage. The read path emphasizes high throughput and low latency, while the write path validates and uploads only necessary chunks to improve speed and security. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## From Files to Chunks: Improving HF Storage Efficiency DevFeed: [From Files to Chunks: Improving HF Storage Efficiency]() Original publisher: [Read original article]() Author: Jared Sulzdorf; Ann Huang Published: 2024-11-20T00:00:00Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [xet](), [content defined chunking](), [content addressed store](), [datasets](), [hugging face](), [Git](), [Open Source]() Tags: [content-addressed-store](), [content-defined-chunking](), [datasets](), [dedupe](), [git](), [open-source](), [performance](), [storage](), [xet]() ### AI overview Hugging Face's Xet team describes a storage system that splits files into variable-sized chunks using content-defined chunking and a rolling hash. Chunks are stored in a content-addressed store with deduplication, so updates upload only new chunks. The article reports a consistent 50% improvement in storage and transfer performance compared with Git LFS across three iterative development use cases, including the CORD-19 dataset. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## Introducing Conditional REST Requests DevFeed: [Introducing Conditional REST Requests]() Original publisher: [Read original article]() Author: Casey Rogers Published: 2017-07-31T00:00:00Z Content type: news Language: en Sources: [Firebase Blog]() Topics: [Firebase](), [Realtime Database](), [REST API](), [content addressed store](), [HTTP](), [Transactions]() Tags: [api](), [cas](), [firebase](), [http](), [launch](), [news](), [realtime-database](), [rest](), [updates]() ### AI overview Firebase introduces conditional REST requests for the Realtime Database. Using ETags and the If-Match header, clients can safely perform compare-and-swap updates and retry when another user changes the data first. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Compare-And-Set in Memcache DevFeed: [Compare-And-Set in Memcache]() Original publisher: [Read original article]() Author: Guido van Rossum (noreply@blogger.com) Published: 2011-08-25T16:59:00Z Content type: tutorial Language: en Sources: [Guido van Rossum]() Topics: [content addressed store](), [Python](), [bug](), [Code]() Tags: [algorithms](), [appengine](), [cas](), [code](), [compare](), [google](), [memcache](), [new-feature](), [python](), [race-condition]() ### AI overview This tutorial explains Compare-And-Set in memcache, including its atomic update use case and how it prevents lost updates caused by race conditions when concurrent requests modify the same key. ### Source excerpt With the most recent release (1.5.3, last week) App Engine's Python API for Memcache has added a new feature, Compare-And-Set. This feature (with a different API) was already available in Java; it has also been available in the non-App-Engine pure-Python memcache client. In fact, I designed the App Engine Python API for this feature to be compatible with the latter, since most of the rest of the App Engine Python API also strives to be at least a superset of that package. But what is it? There seems to be little information on how to use Compare-And-Set with memcache. It is also sometimes (incorrectly) referred to as Compare-And-Swap -- incorrect, because the cas() operation does not actually "swap" anything. The first response when we closed the bug requesting this feature was "Some examples of usage are appreciated." So here goes. The basic use case for Compare-And-Set is when multiple requests that are being handled concurrently need to update the same memcache key in an atomic fashion. Let's assume you are managing a counter in memcache. (Actually, you could use the incr() and decr() operations to update 64-bit integer counters atomically, but just for argument's sake assume you cannot use those -- there are other data types for which the memcache service does not have built-in support.) The naive code to update a counter would be something like this: def init_counter(key): . memcache.set(key, 0) def bump_counter(key): . counter = memcache.get(key) . assert counter is not None, 'Uninitialized counter' . memcache.set(key, counter+1) (Aside: I don't want to have to think about how to get blogger to properly format Python code. I really don't. So just bear with the dots I use for indentation. Okay? Comments pointing me to solutions will be DELETED.) (Aside 2: The assert is kind of naive; in practice you'll have to somehow deal with counter initialization. You also should implement a backup for your counter using the App Engine datastore, so that it can survive evic ## Software Development as a Complex Adaptive System DevFeed: [Software Development as a Complex Adaptive System]() Original publisher: [Read original article]() Published: 2008-11-24T15:41:57Z Content type: opinion Language: en Sources: [Blog by Michael Dubakov]() Topics: [Complex Systems](), [content addressed store](), [Development](), [Software Engineering]() Tags: [complex-systems](), [complexity](), [development-process](), [software-development]() ### AI overview The article explains software development through the lens of Complex Adaptive Systems (CAS). It introduces CAS as adaptive, decentralized networks of interacting agents and relates their properties--such as self-organization, feedback, information exchange, cooperation, and adaptation--to software development. ### Source excerpt Complexity science is very young. Cybernetics, ecology, sociology, meteorology all study complexity. In general, a complex system consists of interacting components. The result of this interaction can't be predicted by observing an individual component. For example, human brain consists of neurons. The brain has 'memory', while each neuron doesn't. Ants' colony behavior can't be predicted from the behavior of an individual ant. And it is impossible to understand software development process looking at how just one developer works. We are especially interested in a particular case of complex systems called Complex Adaptive Systems (CAS). The main difference is that CAS may learn and change (adapt) over time based on previous experience. CAS remember the history, and that is the main difference from chaotic systems. There is no common definition of Complex Adaptive System (CAS). One of the most popular definition was offered by John H. Holland A Complex Adaptive System (CAS) is a dynamic network of many agents (which may represent cells, species, individuals, firms, nations) acting in parallel, constantly acting and reacting to what the other agents are doing. The control of a CAS tends to be highly dispersed and decentralized. If there is to be any coherent behavior in the system, it has to arise from competition and cooperation among the agents themselves. The overall behavior of the system is the result of a huge number of decisions made every moment by many individual agents. CAS has quite many common properties. However, hardly a system should have all of them to be CAS. Moreover, researches define different sets of CAS properties. Let's try to review the most common properties and see how software development process can be described in terms of those properties. CAS Property Software Development interpretation Agent System component People in development team and others involved (product owners, stakeholders). Feedback Each agent in CAS reacts to information fl