# zenOSmosis blog > Quietly ambitious software, in public. Author: [jzombie](https://github.com/jzombie) Site: https://blog.zenosmosis.com/ ## Posts - [The Magnet Vector: A Shared Latent Space for Autonomous Discovery](https://blog.zenosmosis.com/posts/8-magnet-vector/): Shared latent space for humans and machines, designed for autonomous discovery and maximum impact. - [Rust's "Other" Official Book (The Reference Guide)](https://blog.zenosmosis.com/posts/7-rust-other-book/): While The Rust Book is excellent, it doesn’t dive deep into the core language specification. But fear not, fellow Rustaceans, as another guide lives on the same domain as the Book itself. - [NATO Phonetic Alphabet Words](https://blog.zenosmosis.com/posts/6-nato-alphabet-words/): A simple guide to remembering and using the NATO phonetic alphabet clearly over the phone. - [Git read-tree: Carbon-Copy without Merge Hell](https://blog.zenosmosis.com/posts/5-git-read-tree/): `git read-tree` is a photocopier. It copies the state of another branch directly into your staging area. It doesn't care about history, ancestors, or shared code. It just puts the files where you want them. - ["Fastest Database?" TPC-H is the Benchmark that calls their bluff](https://blog.zenosmosis.com/posts/4-what-does-fastest-db-mean/): What is "fast" anyway?... - [Why does anyone invent anything?](https://blog.zenosmosis.com/posts/3-why-does-anyone-invent-anything/): Why are there multiple brands of [anything] with extremely similar features... - [A new set of tradeoffs](https://blog.zenosmosis.com/posts/2-a-new-set-of-tradeoffs/): This project did not start with some grand plan to build a database engine... - [From zero to something](https://blog.zenosmosis.com/posts/1-from-zero-to-something/): Going from zero to something at all is an infinite improvement... --- ## The Magnet Vector: A Shared Latent Space for Autonomous Discovery Source: https://blog.zenosmosis.com/posts/8-magnet-vector/ Published: 2026-11-10 > _As of Nov 2026, this is a proposal. Parts described were directional at writing time._ The traditional push model of digital distribution, blindly submitting resumes into portals, publishing keyword stuffed SEO articles, and begging algorithms for attention, is functionally dead. Artificial intelligence and semantic search have rendered these outbound tactics obsolete. To survive this shift, this document proposes the **Magnet Vector** framework: a strategy that abandons outbound marketing in favor of constructing a shared latent space for humans and machines alike. The core hypothesis is that instead of forcing a static document into a crowded digital void, a [repository](https://github.com/jzombie) can be engineered as a dense coordinate in a latent space. By mathematically aligning high value metadata, code, and documentation to the exact parameters automated algorithms seek, the system proposes to create a localized magnetic pull. The goal is to leverage algorithmic arbitrage, allowing discovery algorithms to perform the marketing labor autonomously. ### 1. The Physics of Semantic Gravity The term _Magnet Vector_ captures the mechanics of this distribution model: * **It is a Vector:** In modern AI search, concepts are high dimensional arrays. An AI model searching for content likely will not judge your project on visual flair, it is a coordinate on a large map. Focus on deep semantic meaning over superficial keywords and your footprint sits at a specific, calculated location. * **It is a Magnet:** When a project reaches semantic density, it exerts inbound pull, a kind of semantic gravity. Because the meaning is structured, it draws anyone who lands on it, whether an AI agent parsing code or a human looking for a solution, deeper into the broader architecture. You are not manually marketing in the traditional sense, you are building a beacon. Map your technical capabilities to the semantic intent of your audience and you create pull. ### 2. Auto-Marketing via Algorithmic Arbitrage The core is algorithmic arbitrage, treating a recommendation engine or retrieval pipeline as an inefficient market, and attention as the mispriced asset. You do not manually convince humans if you can mathematically convince their assistants. This engine operates across a few high level vectors: * **[Generative Engine Optimization (GEO)](https://arxiv.org/abs/2311.09735):** Per the paper, adding citations, quotations, and statistics can lift visibility in generated answers up to about 40 percent, with fluency helping and effects varying by domain. Keyword stuffing, the classic SEO move, does not transfer. Better odds of being cited, not a guarantee of being the definitive answer. * **Autonomous Agent Discovery:** Expose tools as [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) servers on unified gateways. When a human prompts an AI to solve a problem, the AI searches the registry, calculates similarity between need and tool, and integrates your work without human intervention. * **Workflow Gravity:** Syndicate automated technical telemetry through [RSS](https://www.rssboard.org/rss-specification) feeds. This captures power users, quants, and senior engineers who live on aggregators, bypassing social noise. GEO controls how generative engines cite text. Magnet Vector is the wider pipeline for discovery, execution, and inward routing. It does not rely on a single channel. **A brief comparison of methodologies:** | | Traditional SEO | GEO | Magnet Vector (this proposal) | |---|---|---|---| | **Consumer** | Human scanning results | Agent assembling an answer | Agent executing code or solving a task | | **Goal** | Earn the click | Earn the citation | Earn execution, adoption, and inward routing | | **Surface** | Results page | Generated response | Generated response, agent loop, registry | | **Main signals** | Backlinks, keywords, meta tags, page experience | Citations, statistics, quotations, fluency, clean structure | Structured summaries, `llms.txt` routing, MCP tools, registry presence, clean prose | | **Success metric** | Rankings, CTR, traffic | Citation visibility and accuracy | Task success, tool use, traversal depth | | **Scope** | Single URL | Single passage | Multi-node ecosystem where each entry routes deeper | | **Honest limits** | Mature, measured, gamed constantly | Younger evidence base, domain dependent | A file or listing alone guarantees nothing; quality of the underlying work still decides | ### 3. Are We in Alignment? This is the primary use of this document. When building a new feature in another repo, or creating new content for maximum impact, ask: _are we in alignment?_ * Does this asset have one clear coordinate, one sentence that says what it is and who it is for? * Can both a human and a machine extract that in seconds, each in their preferred surface? * Does it route deeper, one link leading to the next layer, not a dead end? * Does it add density, or does it dilute the space with fluff? * If an agent had only the summary, would it cite us correctly? If yes, ship it. If no, the feature or post is not ready for the latent space, regardless of how polished it looks. ### 4. Structural Foundation in Brief Implementation is secondary to the above, and will be detailed separately. High level only: The routing layer for machine discovery is proposed to be the [**`llms.txt` protocol (currently v2 specification)**](https://llmstxt.org/). Human context stays completely out of `llms.txt`. The human layer lives in `README.md` or Web UI with visuals and narrative. The machine layer stays terse, H1 plus blockquote plus H2 grouped links with single sentence context, limited to the crown jewels, under 5,000 tokens. Where `llms.txt` is the routing map, `llms-full.txt` is the full carrier: a single file with complete content for agents that require bulk ingestion in one pass without following links. Both files are generated from the same source values to prevent drift. Aggarwal et al.'s [GEO: Generative Engine Optimization](https://arxiv.org/abs/2311.09735) demonstrates that generative engines reward structural density over domain prominence: in its benchmarks, lower-ranked baseline sources saw relative visibility gains exceeding 100% when optimized with authoritative citations and structured facts. Astro evaluated machine manifests against human consumption patterns, removing the files because “we have seen little uptake in usage, these files get very little traffic” ([withastro/docs#13538](https://github.com/withastro/docs/pull/13538)). This proposal rejects pageviews as a valid evaluation metric for machine endpoints. Agent pull context is pre-fetched, cached, and bursty; a single fetch can seed an entire IDE session without registering repeated server hits. We explicitly reject that removal logic and keep both files active. For repos that produce visual assets, prefer dense tables in text for topology and external SVGs linked via image tags for humans. Inline text to diagram tools (such as [Mermaid.js](https://mermaid.js.org/)) have a place where they fit, but they are not the core of this framework and should not dominate the article or the repo. --- ## Rust's "Other" Official Book (The Reference Guide) Source: https://blog.zenosmosis.com/posts/7-rust-other-book/ Published: 2025-12-31 I’ve used `macro_rules!` plenty of times, but recently I wanted to explore the full range of available **fragment specifiers**. I wasn't trying to learn *how* to write a macro; I just wanted to know every single option available to me beyond the usual `$x:expr` or `$y:ident`. I started where lots of others officially do: *The Rust Programming Language* (affectionately known as "The Rust Book"). But while The Rust Book is excellent, it doesn’t dive deep into the core language specification. That is when I realized that Rust actually hosts two different "books" on the exact same domain. They are just a directory change away from one another: ## 1. The Rust Book (The Tutorial) https://doc.rust-lang.org/book/ * **Goal:** Teaches you Rust from first principles. It focuses on building an intuitive understanding of "how Rust wants you to think." * **Use it for:** Learning ownership, borrowing, traits, and getting productive with Cargo. ## 2. The Rust Reference (The Specification) https://doc.rust-lang.org/reference/ * **Goal:** Defines what Rust *is*. It describes the grammar, strict syntax rules, and edge cases. It is dry, precise, and exhaustive. * **Use it for:** Looking up exact rules (like macro matchers), operator precedence, and memory models. ---- *By the way, if you are looking for the exact definitions of macro metavariables (like I was), they are defined in the Reference here: [https://doc.rust-lang.org/reference/macros-by-example.html\#metavariables](https://doc.rust-lang.org/reference/macros-by-example.html#metavariables)* --- ## NATO Phonetic Alphabet Words Source: https://blog.zenosmosis.com/posts/6-nato-alphabet-words/ Published: 2025-12-24 We have all been there. You are on the phone with customer support, the connection is slightly crackly, and you are desperately trying to spell out your email address. *"No, that's 'B' as in... Boy. No, 'D' as in... Dog? wait, 'P' as in..."* It’s frustrating, and it wastes time. The solution is the **NATO Phonetic Alphabet**. It’s the standard used by pilots, the military, and emergency responders to ensure zero ambiguity. Once you learn it, you never go back to saying *"S as in... Sea?"* again. Here is the full list, followed by the easiest way to actually lock these into your brain. --- ## The List (A-Z) * **A:** Alpha * **B:** Bravo * **C:** Charlie * **D:** Delta * **E:** Echo * **F:** Foxtrot * **G:** Golf * **H:** Hotel * **I:** India * **J:** Juliett * **K:** Kilo * **L:** Lima * **M:** Mike * **N:** November * **O:** Oscar * **P:** Papa * **Q:** Quebec * **R:** Romeo * **S:** Sierra * **T:** Tango * **U:** Uniform * **V:** Victor * **W:** Whiskey * **X:** X-ray * **Y:** Yankee * **Z:** Zulu --- ## How to actually remember this (without it feeling like homework) Rote memorization is boring. Here is a faster, practical way to get these fluent so you don't freeze up when you need them. ### 1. The "Chunking" Method Don't try to eat the whole elephant at once. Break the alphabet down into groups of five or six. Master the first group before moving to the next. * **Group 1:** Alpha, Bravo, Charlie, Delta, Echo * **Group 2:** Foxtrot, Golf, Hotel, India, Juliett * **Group 3:** Kilo, Lima, Mike, November, Oscar * **Group 4:** Papa, Quebec, Romeo, Sierra, Tango * **Group 5:** Uniform, Victor, Whiskey, X-ray, Yankee, Zulu ### 2. The License Plate Game This is the best way to practice during your commute. When you are stuck in traffic, look at the license plate of the car ahead of you. If you see **"JPK 424"**, say out loud: *"Juliett, Papa, Kilo."* Do this once a day for a week, and you’ll be surprised how fast it becomes second nature. ### 3. Watch out for the weird ones Most of these are intuitive, but a few trip people up. * **J is for Juliett:** It's standard, but easy to forget because we want to say "Jack" or "John." * **Q is for Quebec:** Avoid saying "Queen" because it sounds too much like "Green" or "Bean" over a bad connection. * **M vs. N:** "Mike" and "November" are distinct sounds. Avoid "M as in Mary" because it sounds similar to "N as in Nancy" over a noisy line. ### 4. Use it or lose it You don't need intense flashcards. Just look for opportunities to use it. The next time you call to make a reservation or confirm an appointment, force yourself to use the phonetic alphabet. It feels cool, it saves time, and the person on the other end of the line will thank you. ## Additional reading https://en.wikipedia.org/wiki/NATO_phonetic_alphabet --- ## Git read-tree: Carbon-Copy without Merge Hell Source: https://blog.zenosmosis.com/posts/5-git-read-tree/ Published: 2025-12-02 Have you ever tried to merge a branch, knowing it would end in *merge hell*, when all you actually wanted was the code itself? Maybe you’re working on a feature and realized you went down a rabbit hole. You want to reset your project state to match a clean branch, but you don't want to lose your current commit history or switch branches. Or perhaps you want to bring in a massive set of changes from a colleague, but you want them staged as a single file update rather than a messy merge history. Most developers wrestle with `git merge` or `git cherry-pick` for this. But there is a simpler, sharper tool for the job: `git read-tree`. **git read-tree is a photocopier. It copies the state of another branch directly into your staging area. It doesn't care about history, ancestors, or shared code. It just puts the files where you want them.** *(And best of all, it's already included with git, so there's nothing else to download or install.)* It’s often considered a "plumbing" command (meant for scripts), but if you understand how it handles the staging area, it becomes one of the fastest ways to force-sync your code. *Note: This does not come without caveats to the original code authors\! Any code you borrow from another branch that’s not already in the branch you plan on merging to will wind up being attributed to you, as if you’re the original writer.* ## How to Use It Before you begin, and this is very important, you will want to ensure your branch is not currently dirty\! That means that you have either committed or stashed away your current copies, and there is nothing in the staging area\! Here is the scenario: You are currently on feature-branch, and you need code from another branch, and there’s not a clean way to merge it without fixing a lot of merge conflicts, but you want to stay on feature-branch, and you want to ensure you have non-breaking changes\! **The Simplified `git read-tree` Workflow:** ```bash # Update your branch with the remote branch git read-tree ``` You will see a list of files that are both Staged (Green) and Unstaged (Red). Here is how to read that status output: 1. **The Staged Changes (Green):** These are the changes that did take effect in the Index. Git is comparing your current HEAD to the new Index (which now looks like main). It is saying: "If you commit right now, we will add all these files from Main." 2. **The Unstaged Changes (Red):** These are the "changes" that would effectively wipe out what you just staged. Git is comparing the new Index (main) to your old Working Directory (feature-branch). It sees your old files on disk and thinks: "Hey, the file on your disk doesn't match this new Index. If you add this file now, you'll revert back to the old version." This is the "limbo" state. You have the new code ready to go in the staging area, but your old code is still visible in your uncommitted changes. To complete the merge, just discard the uncommitted changes! (This is why it is very important to start off without staged or uncommitted changes.) ## Why use `git read-tree` instead of `git merge`? In the vast majority of scenarios, you should probably **not** use `git read-tree`. The `git merge` command is the standard, safe, and most comprehensive tool for integrating changes from one branch into another, and it explicitly retains the full, traceable history of both branches. However, `git read-tree` serves a very niche, specific purpose. It is essentially a low-level plumbing command that allows you to quickly grab the *file contents* from another branch and place them directly into your current index—your staging area—without recording the transfer as a standard merge commit. ## The Primary Use Case: Code, Not History The core reason to reach for `git read-tree` is when all you need is the *code* from another branch, and you have no need (or desire) to track the lineage or history of that transfer. This is a "surgical" operation, focusing purely on the filesystem state defined by the other branch's tree object, ## The Key Advantage: Conflict Avoidance The most compelling practical reason for using `git read-tree` is to sidestep the automatic merge conflict detection process that `git merge` initiates. * **How `git merge` works:** `git merge` attempts a three-way merge, comparing the common ancestor, your branch, and the target branch. If the same lines of code have been changed in both branches since the common ancestor, it flags a conflict and stops, requiring manual resolution. * **How `git read-tree` works:** When you run `git read-tree `, Git simply reads the files from that branch and inserts them into your index. It essentially overwrites what was in your index with the state of the other branch's files. Because it is not performing a merge analysis, it does not detect or report merge conflicts. This can be useful if you know that the changes in the target branch are **meant to completely supersede** the files in your current branch, or if you are deliberately performing a non-standard integration where the merge logic would unnecessarily complicate things. ## Caveats and Additional Info Because `git read-tree` bypasses standard merge logic and history tracking, it is a destructive and potentially confusing operation if not used with precision. 1. **History is Lost:** The operation itself is not recorded as a merge. If you commit after using `read-tree`, the commit will simply look like a normal snapshot with no indication of where the code originated. This makes debugging and rollbacks significantly harder. 2. **No Safety Net:** If you use `read-tree` on top of existing work, the files from the source branch will overwrite files in your index, potentially discarding your unstaged changes without warning. *So long as you start with a clean state, without any staged or uncommited changes, you can easily roll back before committing the new code.* 3. **Intermediate Utility:** `read-tree` is often used by advanced Git users or script writers as a building block for more complex operations, rather than as a primary command for daily workflow. --- ## "Fastest Database?" TPC-H is the Benchmark that calls their bluff Source: https://blog.zenosmosis.com/posts/4-what-does-fastest-db-mean/ Published: 2025-11-16 You’ve seen the claims. Seemingly every database vendor, from legacy giants to brand-new startups, has a chart or some blog posts claiming that they are the “fastest.” But what does “fast” even mean? Is it “fast” for one person running one query on a perfectly quiet system? Or is it “fast” for a whole team of analysts running end-of-quarter reports while new sales data is pouring in? This is the exact problem the TPC-H benchmark was built to solve. It’s not just a performance test; it’s a simulation of a real, chaotic, ad-hoc business environment. It’s one of the best tools we have for cutting through the marketing hype and seeing how a data warehouse really performs. Let’s break down what it is and why its “secret ingredient” is so important. ## What is TPC-H and why is it Important? TPC-H (from the **[Transaction Processing Performance Council](https://www.tpc.org/)**) is a standardized benchmark for measuring how well a database (and the hardware it runs on) handles analytical / decision-support workloads. The *“-H”* suffix historically stands for “ad-hoc”, reflecting that the benchmark is built around business-oriented ad-hoc queries rather than fixed canned reports. The official description from https://www.tpc.org/tpch/ says that: > *“TPC-H is a decision support benchmark… consists of a suite of business oriented ad-hoc queries and concurrent data modifications… examine large volumes of data, execute queries with a high degree of complexity, and give answers to critical business questions.”* The current specification can be found at: https://www.tpc.org/tpc_documents_current_versions/current_specifications5.asp The TPC also maintains an official results database. To claim an official TPC-H result, vendors must follow the full specification, publish a full disclosure report (FDR), and pass an independent audit. Those results are the only ones that are directly comparable across platforms. By contrast, many blog posts and marketing pages run “TPC-H like” queries or data and then report numbers without going through the TPC disclosure and audit process. Those can be useful for engineering discussion or internal testing, but they should be treated as informal benchmarks, not official TPC-H results, and taken with a grain of salt when used for vendor-to-vendor comparison. ## What it measures TPC-H, an OLAP (Online Analytical Processing) benchmark, is aimed squarely at data warehousing / decision support systems, not transactional OLTP (Online Transaction Processing) apps. Although there are elements of transaction-based concurrent processing, the main focus is on its decision support performance. - **Complex joins and aggregations** Most queries join 4-8 tables, do group-bys, HAVING, subqueries, correlated subqueries, etc. - **Scan-heavy workloads** Many queries touch large portions of the fact tables (especially lineitem and orders) at increasing scale factors. - **Ad-hoc, business-style logic**. The 22 queries correspond to “business questions” like: - Pricing summaries (Q1) - Minimum-cost supplier (Q2) - Market share by nation (Q8) - Promotion effect (Q14) - Dormant high-balance customers (Q22) - **Single-stream and multi-stream performance** The composite metric `QphH@Size` (TPC-H **Queries per Hour** at a specific **Scale Factor**) is a geometric mean of two separate tests: - **Power** *(@Size)*: A single-stream test where all 22 queries (Q1-Q22) are run sequentially. This measures the raw query optimization and execution speed. - **Throughput** *(@Size)*: A multi-stream test where multiple concurrent query streams (each running Q1-Q22) are executed at the same time as the two data modification (Refresh) streams. This measures the system’s scalability and concurrency handling under load. - *@Size*: This refers to the Scale Factor (SF), which defines the database size. SF1 = 1 GB, SF100 = 100 GB, SF30000 = 30 TB, etc. An official result is always tied to a specific scale factor. - **Concurrent data modifications (refresh functions)** TPC-H isn’t just a read-only benchmark. The test requires two “Refresh Functions” (RF1: New Orders/Line items, RF2 [The “Old Sales” refresh function]: Deleted orders) to be run concurrently with the query “throughput” streams. This tests the system’s ability to handle a mixed workload–running complex analytical queries on data that is simultaneously being changed (inserts and deletes). This measures the effectiveness of the system’s concurrency control (e.g. locking, snapshot isolation) and its ability to maintain high query performance without blocking or failing during data manipulation. So, when a vendor posts an official TPC-H result, it is an end-to-end measure of: - Query optimization quality - Execution engine (joins, grouping, sort, aggregation, parallelism) - IO subsystem and storage layout - Hardware (CPU, memory, disks) - …and concurrency handling for analytical workloads Unofficial numbers that do not appear in the TPC results database and do not include a full disclosure report may still be interesting, but they are not directly comparable to audited TPC-H results and should be interpreted accordingly. ## The TPC-H schema The benchmark’s data model simulates a wholesale supplier’s business. It consists of 8 tables. The complexity of the queries comes from joining these tables in various ways. - **Fact Tables (Large & Growing):** - `lineitem`: The largest table, with ~6 million rows per Scale Factor (SF). - `orders`: The second-largest table, with ~1.5 million rows per SF. - **Dimension Tables (Smaller):** - `part`, `partsupp`, `supplier`, `customer` - **Static Tables (Tiny):** - `nation`, `region` Understanding this, you can see how queries joining `lineitem`, `orders`, `customer`, `supplier`, and `nation` (like the queries `Q5`, `Q7`, `Q8` mentioned below) become complex tests of the join engine. ## The TPC-H queries TPC-H is divided into 22 SQL queries. Here is a high-level overview of what they summarize. ### Pricing, Profit, & Revenue (The "Big Money" Group) #### Q1: Pricing Summary Report *Business question:* Summarize quantities, prices, discounts, and charges for all line items shipped by a given cutoff date, grouped by return status and line status. #### Q6: Forecasting Revenue Change *Business question:* For a given year, how much additional revenue would have been earned if discounts in a specific range had been removed for qualifying low-quantity line items? #### Q9: Product Type Profit Measure *Business question:* For a given product line (parts whose name contains a specified substring), what profit is generated each year in each supplier nation, where profit is revenue minus supply cost? #### Q14: Promotion Effect *Business question:* What percentage of shipped revenue in a given month came from “promo” parts? #### Q17: Small-Quantity-Order Revenue *Business question:* If we stopped taking orders for a given brand and container where the quantity is less than 20% of that part’s historical average order quantity, how much gross (undiscounted) revenue would we lose per year on average over the 7-year period? #### Q19: Discounted Revenue *Business question:* What gross discounted revenue is generated by orders for three specific branded part profiles, defined by size, container, and quantity ranges, that are shipped by air and delivered in person? ### Supply Chain & Suppliers #### Q2: Minimum Cost Supplier *Business question:* In a given region, for each part of a specified type and size, which supplier offers it at the lowest supply cost, preferring suppliers with the highest account balances when there are ties? #### Q11: Important Stock Identification *Business question:* In a given nation, which parts represent a significant share of the total inventory value? #### Q15: Top Supplier *Business question:* Which supplier(s) generated the most revenue from shipped parts in a given quarter? #### Q16: Parts/Supplier Relationship *Business question:* For selected part sizes, how many suppliers can provide parts that meet a customer’s requirements, excluding a given brand, a given type prefix, and suppliers with registered complaints, grouped by brand, type, and size? #### Q20: Potential Part Promotion *Business question:* Which suppliers in a given nation have excess stock of parts whose names match a given pattern (e.g., color-prefixed), where “excess” means more than 50% of the quantity they shipped of that part in a given year, making them candidates for promotion? #### Q21: Suppliers Who Kept Orders Waiting *Business question:* In a given nation, which suppliers were the sole cause of late delivery in completed multi-supplier orders, and how many such orders did they delay? ### Orders & Shipping Logistics #### Q3: Shipping Priority *Business question:* For a given market segment and cutoff date, which unshipped orders have the highest potential revenue and should be prioritized for shipping? #### Q4: Order Priority Shipping *Business question:* For a given quarter, how many orders in each priority level had at least one line item delivered late relative to its committed date? #### Q12: Shipping Modes and Order Priority *Business question:* For two selected shipping modes, how many late deliveries do they produce in a given year, and are high-priority orders (URGENT/HIGH) being delivered late more often than lower-priority ones? #### Q18: Large Volume Customer *Business question:* For large-quantity orders (total quantity above a threshold), which 100 orders have the highest total price, and which customers placed them? ### Market & Customer Analysis #### Q5: Local Supplier Volume *Business question:* For a given year and region, how much revenue comes from orders where the customer and supplier are in the same nation, aggregated per nation in that region? #### Q7: Volume Shipping *Business question:* For two specific nations, what gross discounted revenue was generated by goods shipped between them in 1995 and 1996, broken down by supplier nation, customer nation, and year, to support shipping contract negotiations? #### Q8: National Market Share *Business question:* For a given part type and region, how does a given nation’s revenue-based market share change between 1995 and 1996? #### Q10: Returned Item Reporting *Business question:* For a given quarter, which 20 customers caused the most lost revenue by returning items, and how much revenue was lost for each of them? #### Q13: Customer Distribution *Business question:* How are customers distributed by number of orders, including customers with zero orders, excluding certain special orders? #### Q22: Global Sales Opportunity *Business question:* For a chosen set of country codes, how many customers with no orders and above-average positive account balances are there, and what is the total of those balances? --- ## Why does anyone invent anything? Source: https://blog.zenosmosis.com/posts/3-why-does-anyone-invent-anything/ Published: 2025-11-14 Why are there multiple brands of cars with extremely similar features? Most of them have four wheels, a steering wheel, pedals in roughly the same layout, a windshield, and a trunk. From far enough away, a Honda and a BMW are the same object: a metal box that moves you from A to B. Why are there multiple operating systems with graphical interfaces that look almost interchangeable at a glance? Windows, macOS, KDE, GNOME, iOS, Android: they all reuse the same handful of ideas. Desktop, taskbar or dock, file menu, copy and paste, windows that overlap, icons that you can drag around. Even the “new” ones are really variations on a pattern that solidified decades ago. Why do Unix-like systems spawn endless desktop environments and window managers that all sit on top of the same kernel? XFCE, GNOME, KDE, i3, sway, Awesome, and on and on. They share the same underlying system calls and process model, but people keep rearranging the pixels. Why are there dozens of Linux distributions that all share the same kernel? Different wallpapers, package managers, default configs, and community norms wrapped around essentially the same core. If “Linux is Linux,” why does anyone bother shipping yet another distro? Why are there multiple CPU architectures for consumer hardware at all? X86, x86_64, ARM, RISC-V and others, each with their own instruction sets and tradeoffs, all ultimately executing code to add numbers, move bytes, and jump around in memory. “Reinventing the wheel” is only pointless if: 1. You really are copying an existing design without understanding it, and 2. You are not changing any constraints, goals, or tradeoffs. But as soon as any of those shift, you are not reinventing the wheel; you are designing a wheel that fits a different road, a different load, and a different vehicle. --- ## A new set of tradeoffs Source: https://blog.zenosmosis.com/posts/2-a-new-set-of-tradeoffs/ Published: 2025-11-14 This project did not start with some grand plan to build a database engine. It started with a small tool called [Muxio](https://github.com/jzombie/rust-muxio), a library I hacked together in Rust to give me WebSocket connectivity between Rust, Python, and WASM clients. Somehow, at least for a few hours, it ended up on the front page of Hacker News. I still like the project a lot, but I am not entirely sure how or why it wound up there. For most people, that is a spike of traffic, a few GitHub stars, and then life goes back to normal. For me, one side effect was a message from a company I was already interested in about a potential role. On paper, it looked almost ideal: market data, infrastructure, performance, and a career track in Rust. Exactly the kind of work I actually enjoy doing. Before any of this, I had already thought about reaching out to them directly with something like, "hey, I built this library that fits what you do, you should look at it, and maybe look at me too." I had briefly been a client of theirs, had decent insight into their market data offerings, designed a schema to capture what I wanted, and started building a never-ending series of machine learning models that I was convinced would make me very rich, or at least noticeable. So when this role basically came to me, I was sure I was their guy. The first interview, with one of the co-founders, went well. A few interviews in, I bombed one. That was the end of that. But one of the things they asked about in that failed round was something I did not know yet and had been thinking about building for myself anyway. So after the interview died, I started building it. That is how this project started: not with a clean vision, but with a door closing, a question I could not shake, and the decision to just build the thing on my own, to learn how it could truly work in conjunction with my own set of trade-offs that I would subsequently impose on such a system. --- ## From zero to something Source: https://blog.zenosmosis.com/posts/1-from-zero-to-something/ Published: 2025-11-13 When first starting to build a project of any kind, the first few things that go right are huge wins. Going from zero to something at all is an infinite improvement, and then things immediately start to slow down from there. Some projects we take on are for pleasure, others for greed, others to just see if we can do it. The project that I’m currently working on, [a database](https://github.com/jzombie/rust-llkv), I’ve lost track of exactly why I’m still working on it, but I’m committed to it, just to see if I can build it, even though I’ve got these _AI_ tools working alongside me many steps of the way. Can _they_ build it? So before I really dive into the details of this database, let me tell you a little bit about what to expect from this blog. You see, it’s a learning journey for me, and as such, there’s going to be a lot of incorrect assumptions along the way, and I may be slightly embarrassed once I realize that I was wrong about a few things, but I will do my best to just keep going anyway. Our lives are always some type of journey anyway. We never know what the future holds, and we’re always learning anyway. So if we’re always learning, it’s safe to say that we are making some mistakes along the way.