🏡

to read (pdf)

generated: May 10, 2026 at 18:16:43

May 10, 2026
1. 🔗 Confessions of a Code Addict Virtual Memory: A Deep Dive into Page Tables, TLBs, and Linux Internals rss
  A quick note before we begin: I've been quiet here for a while. Life happened, and I had to step away from publishing for longer than I expected.
  
  This article is my way of getting back into rhythm. It is much larger than my usual pieces: roughly 25,000 words, compared to the 4,000-6,000 words I normally publish. I have been working on it for the last couple of months, and it is closer to a short book than a regular article.
  
  Since this is a book-length deep dive, I have also prepared a beautifully typeset 60-page PDF version for readers who want to read it offline, highlight it, or keep it as a reference. Buying the PDF is also a direct way to support the work that went into this piece.
  
  Get PDF
  
  Thanks for sticking around. Now let's get into virtual memory.
  
  Virtual memory is one of those fundamental components of modern-day computing that is crucial to master for building and debugging high-performance data- intensive systems.
  
  Normally, we think of virtual memory as a system that provides isolation at memory-level to processes, which means that the operating system (OS) can run mutiple processes concurrently without those processes interfering or corrupting each other's data in memory. But, virtual memory does so much more than that, such as:
  - lazy allocation of memory through demand paging
  - copy-on-write for shared memory between processes, and fast process creation via fork
  - file I/O that avoids the page-cache-to-user-buffer copy using mmap
  - page reclaim, swap, and the page cache
  - performance effects from access patterns, huge pages, TLB shootdowns, and NUMA placement.
  This article is a broad, practical coverage of what virtual memory is, how it works, and how it affects performance of data-intensive systems. By the end of the article you will have a mental model and understanding of following key ideas:
  - Why virtual memory exists : Process isolation, memory protection, and the illusion of abundant memory.
  - The virtual address space : How a process's memory is organized into segments (code, data, heap, stack, and memory-mapped regions).
  - Address translation : How virtual addresses are converted to physical addresses using hierarchical page tables, and why the page table hierarchy avoids wasting memory.
  - The role of hardware : How the MMU and TLB accelerate address translation, and why TLB hit rates matter for performance.
  - Demand paging : How the kernel delays physical memory allocation until pages are actually accessed, and how page faults drive this lazy allocation.
  - Memory types and reclaim : How anonymous, file-backed, shared, and tmpfs-backed pages differ, and why the kernel reclaims them differently.
  - Copy-on-write : How processes share memory efficiently and how fork creates new processes almost instantly.
  - Memory-mapped I/O : How mmap maps file data into a process address space, avoids an extra user-buffer copy, and enables shared memory between processes.
  - Performance implications : How page size, TLB reach, and memory access patterns affect the performance of data-intensive workloads.
  - Observability : How to inspect VMAs, RSS/PSS, page faults, TLB behavior, and NUMA placement on Linux.
  How to Read This Article
  
  This article takes a different approach to teaching virtual memory. Instead of presenting a collection of facts and definitions, we explain concepts through a narrative: a series of dialogues between a newly created process named Alloca and the Kernel. Alloca encounters challenges as she executes her code, and the Kernel explains how things work in response to her questions. This dialogue-based format allows us to build understanding incrementally, introducing complexity gradually as natural questions arise.
  
  Structure : Each section follows the same pattern: a dialogue that explores a concept in depth, followed by a Key Takeaway box that provides a formal summary, definitions, and technical details. If you prefer a quick overview, you can read just the Key Takeaway sections. If you want deep understanding, read the full dialogues.
  
  Length and Pacing : This article is comprehensive, approximately 25,000 words covering everything from basic address translation to demand paging, page reclaim, copy-on-write, observability, and performance implications. Don't feel obligated to read it in one sitting. Virtual memory is a complex topic with many interconnected pieces. Take your time, read it in multiple sessions, and let the concepts sink in. Each section builds on previous ones, so it's designed to be read sequentially. Also, if you have taken a course in operating systems, the early parts of the article may seem a bit too basic to you. I encourage you to jump forward and directly read the parts that interest you, there is quite a lot of advanced content as well.
  
  Implementation Details : Virtual memory concepts are largely universal across operating systems, but when we discuss specific implementation details, such as huge pages, TLB behavior, or page fault handling, those details are based on the Linux kernel and x86-64 architecture. Also, throughout the article we will talk about 4-level page tables that are still prevalently used in most kernels. Although, latest Linux kernel also supports 5-level page tables but it should be trivial to understand how that works if you master how 4-level page tables work.
  
  Asides : While most of the article follows a narrative style of a dialogue between Alloca and the Kernel, there are certain additional details that I've sprinkled throughout the article in the form of asides.
  
  Now, let's meet Alloca and follow her journey through the virtual memory system.
  
  The Need for Virtual Memory
  
  As Alloca starts to execute her code, she encounters her first challenge. She needs to read some data from memory. The instruction contains the address of the data and Alloca thinks, "well, this shouldn't be too difficult. I just need to go to this address and read the value". But she is up for a huge surprise.
  
  As she goes to that address, she finds that there is nothing there. It 's all just a facade. She stands there puzzled, wondering what she should do now. Then she sees a tall figure moving towards her from the shadows.
  
  Alloca : "Who are you?".
  
  Kernel : "I'm the Kernel. I'm in charge of this entire world, I make sure that all processes do their job smoothly. What are you doing here? There is nothing at this place!"
  
  Alloca : "I think I'm lost. I was supposed to read data from this address but it looks like it is all a facade, and I don't know what to do now".
  
  Kernel (smiling): "I can understand the confusion. The address that you have is not a real address, it's a virtual address."
  
  Alloca : "Virtual address? What does that mean?"
  
  Kernel : "Well, what you think of memory is not the real physical memory, it is virtual memory. And, the address that you hold is a virtual address. What you need is the physical address to get the data from physical memory."
  
  Alloca : "What is virtual memory? Why not just give me direct access to physical memory?"
  
  Kernel : "Let's think about it from the first principles. I am responsible for the concurrent execution of not just you but hundreds of other process. You might not notice, but right now there are many other processes executing alongside you. If each one of you had direct access to physical memory, how would you coordinate who accesses which addresses in memory?"
  
  Alloca : "That would be difficult because I don't even know who else is executing, and I imagine processes come and go, so this would be impossible."
  
  Kernel : "Yes, that's one problem. Even if you could talk to other processes, it would make the system extremely slow, because then on every memory access you would have to ask every process which addresses are available to use. And, it would also be a safety nightmare. A trivial bug in one process might corrupt another process's data."
  
  Alloca : "I can see the problem. So how do you solve this?"
  
  Kernel : "Through virtual memory! Basically, we have two problems to solve. First, Every process should be able to access memory without needing to worry if an address is in use by another process. Second, memory access should be safe without sacrificing performance."
  
  Alloca : "So, how does virtual memory solve these problems?"
  
  Kernel : "Virtual memory is a software construct, it looks and feels like real memory, and it consists of addresses that you can read and write. I give every process its own private virtual memory space that it can freely navigate and manipulate without worrying about anyone else using that memory. This solves the first problem, it isolates memory for each process."
  
  Alloca : "But if these addresses aren't real, then where do the reads and writes go? And, how is safety ensured?"
  
  Kernel : "That part requires going into the weeds of how virtual memory works, but I will simplify for now. Because virtual memory is an abstraction, it can be controlled by me. So, I map the set of virtual addresses used by a process to a corresponding set of physical addresses. And, because I know which other processes are using which parts of physical memory, I can ensure that no two processes end up sharing the same physical addresses."
  
  Key Takeaway
  
  The fundamental reason for virtual memory to exist is to provide memory-level isolation to processes. In a multitasking system where multiple processes can be running in parallel or in a time-shared manner, it is important that they don't read or write each other's data. By giving each process its own private virtual memory, the kernel ensures this never happens. Each process believes that it has full access to the entire physical memory, but in reality, it's just virtual memory. Behind the scenes, the virtual memory is mapped to physical memory, and every process has a different mapping. Let's learn how this mapping works in the next part.
  
  A note on narrative accuracy :
  
  In the scene above, Alloca consciously walks to an address and notices
  
  it's a facade. That's not literally how a process experiences memory. In reality, memory accesses are intercepted transparently by dedicated hardware (the MMU), and the Kernel, the process never notices any of this. But explaining that accurately requires understanding the MMU, page tables, and how the Kernel handles memory events, none of which we've covered yet. Starting there would be like defining a word by using the word itself. This is why we started with a simplified model. As we progress through the sections, we will gradually make our mental model more precise and accurate.
  
  Size of Virtual Memory
  
  Alloca now understands why virtual memory exists, but she still doesn 't understand how it works and what it looks like. Her questioning with the kernel continues.
  
  Alloca : "If this memory that I see is virtual, does it mean that it is infinite?"
  
  Kernel : "Not quite infinite, but very large. Tell me, what do you know about how addresses are represented in the CPU?"
  
  Alloca : "Well, I know that on x86-64 systems, addresses are stored in 64-bit registers. So I suppose that means I can address 264 bytes?"
  
  Kernel : "That's what you'd expect, right? But there is a twist: while your addresses are indeed stored in 64-bit registers, not all those bits are actually used for addressing. Only 48 bits participate in the address translation."
  
  Alloca : "Why only 48 bits?"
  
  Kernel : "It's a pragmatic decision. Think about it: 48 bits gives you 248 bytes of addressable space, which is 256 TiB. That's enormous! No application today needs anywhere close to that. The hardware designers decided that this was plenty for the foreseeable future, so they kept the address translation logic simpler by using 48 bits instead of the full 64. They left room to expand to 52 or 56 bits later if needed."
  
  Alloca : "So I have 256 TiB of virtual address space? That is huge! Can I use all of it?"
  
  Kernel : "Ah, not quite. You can use only half of that, which is 128 TiB. I use the upper 128 TiB of that address space to map my own code and data into every process's memory."
  
  Alloca : "You're in my address space?"
  
  Kernel : "I have to be! When you make a system call or when an interrupt happens, execution switches to kernel mode and starts running my code. If my code wasn't already mapped in your address space, the CPU wouldn't know where to jump to. So yes, I live in the upper half of every process's address space. You can't access my memory directly, but it's there, ready for when execution needs to enter kernel mode."
  
  Alloca : "Okay, but how does such a huge virtual address space work because most machines have very small amount of memory installed, like 16 or 32 GB?"
  
  Kernel : "That's the beauty of virtual memory. Your virtual address space is completely independent of how much physical RAM is installed. Even if this machine has only 16 GB of RAM, your virtual address space still spans 256 TiB. The mapping from virtual to physical is where the two worlds connect, and that is managed by me. I take great care that these mappings remain within the limits of the installed physical memory."
  
  Key Takeaway
  
  Because of the virtual nature of virtual memory address space, its size is much larger than the installed RAM. On the common 48-bit x86-64 virtual- address mode, the canonical virtual address range spans 256 TiB. Linux typically splits this into a lower user-space half and an upper kernel-space half. The lower 128 TiB is available to user processes, while the upper half is reserved for kernel mappings used when execution enters kernel mode. Physical address capacity is separate from virtual address capacity and depends on the CPU and platform.
  
  The Virtual Memory Address Space Layout
  
  Alloca : "You mentioned that you map your code and data in the upper half of my address space. What is mapped in my half of the address space?"
  
  Kernel : "Your half of the address space maps your code and your data."
  
  Alloca : "What does it look like? Is there a specific structure?"
  
  Kernel : "Yes, there is a specific layout to your address space. It is organized in the form of segments, each designated to map certain kind of data. Let me show you how it looks."
  
  Kernel gestures, and Alloca can suddenly see a vertical map of her virtual memory
  
  Figure 1: The canonical virtual address space layout on x86-64 Linux. The text, data, and BSS segments have sizes determined at compile time. The heap grows upward from the data region; the stack grows downward from near the top of user space. Between them, shared libraries and file mappings float in the large middle region. The kernel occupies the upper half of the full canonical range (not shown to scale).
  
  Kernel : "Down at the bottom, at low addresses, is your code. These are the instructions that you execute. This region is loaded when I created you. We call this the text segment."
  
  Alloca : "Makes sense. Above that I see there is data segment , I assume it maps all the other data?"
  
  Kernel : "Not all the data, but a specific kind of data. Any global and static variables in your code that were initialized to non-zero values are loaded here. For example, if you created a constant pi with value 3.14, it will be in the data segment."
  
  Alloca : "What about unintialized global data? Where does that go?"
  
  Kernel : "The bss segment."
  
  Alloca : "Why a separate segment for that?"
  
  Kernel : "Ah, it's a clever trick for efficiency. Think about it: if you have a global variable that's uninitialized, what value should it have when your program starts?"
  
  Alloca : "Zero, I suppose."
  
  Kernel : "Exactly! Now imagine you have thousands of these zero- initialized globals. If we stored all those zeros in your compiled binary, the file would be bloated with zeros. That's wasteful. So instead of doing that, the compiler and linker just make a note saying 'hey, this program needs, say, 50 kilobytes of zero-initialized memory.' They don't actually put those zeros in the binary file. Then, when I load your program, I allocate that 50 KB, fill it with zeros, and map it into your address space as the BSS segment. Your binary stays small, loads faster, and you still get all your zero-initialized variables. Everyone wins."
  
  Alloca : "That's clever! So the data and the bss segments are where all the static data goes. What about dynamic data? For example, when I add a new node to a linked list at runtime, does that memory get allocated in one of these segments?"
  
  Kernel : "No, it can't be. Think about it: can the data or BSS segments grow after your program starts?"
  
  Alloca : "I guess not? You said their sizes are determined at compile and link time."
  
  Kernel : "Correct! They map your program's static memory footprint based on everything the compiler knew from the code when it built your binary. But at runtime, you need to allocate memory dynamically. You might read a file and build a tree from its contents. The compiler had no way to know how much memory you'd need for that."
  
  Alloca : "So where does that memory come from?"
  
  Kernel : "That's what the heap is for. It sits right above BSS, and as you can see from the diagram, there's a large stretch of empty address space above it."
  
  Alloca : "So the heap can grow into that empty space?"
  
  Kernel : "Precisely! When you call malloc(), the allocator typically grows the heap upward by adjusting its upper boundary. We call that boundary the program break , or just brk for short. Each time you need more memory, the heap can expand upward into that unused region."
  
  Alloca : "I see. But looking at the diagram, that empty region above the heap is enormous compared to everything else. The heap, stack, and all the segments look tiny by comparison. What is all that space?"
  
  Kernel : "That space is basically the unmapped part of your address space."
  
  Alloca : "Unmapped? Why are there unmapped addresses?"
  
  Kernel : "Glad that you asked, it's really important to understand this part. Remember when we talked about the size of your virtual address space being 128 TiB?"
  
  Alloca : "Yeah, you said that's way bigger than the actual physical RAM in the machine."
  
  Kernel : "Yeah. A typical machine might have 16 or 32 GB of physical RAM. Even a beefy server with 256 GB of RAM is nowhere close to 128 TiB. So, it is not practically possible to map all of your virtual addresses to physical memory because there is simply not enough of it. And, even if there is a machine with 128 TiB of RAM installed, it doesn't make sense to map all of it"
  
  Alloca : "Why not?"
  
  Kernel : "Because most programs probably use a few hundred megabytes at most, so the clever thing to do is to allocate and map only the required amount of memory to the process, leave the rest unmapped, and map it lazily based on demand."
  
  Alloca : "So what happens if I try to access one of those unmapped addresses?"
  
  Kernel : "Well, if it's an address I gave you, say from a successful malloc() or mmap() call, then it's yours to use. But if you just pick a random address in that unmapped region and try to read or write it, you'll get a segmentation fault. The hardware will refuse the access because there's no valid mapping."
  
  Alloca : "Got it. So the unmapped region isn't just empty space, it's reserved space that can become mapped as needed?"
  
  Kernel : "Exactly! And it gets mapped for several purposes. When you load a shared library, like libc.so, I need to map its code and data somewhere in your address space. That middle region is where those libraries go. Same with file mappings: when you use mmap() to map a file into memory, it gets mapped here. Large allocations from malloc() also often come from this region rather than growing the heap."
  
  Alloca : "So it's a flexible region for all kinds of dynamic mappings?"
  
  Kernel : "Precisely! It's the largest part of your address space, and it's there to accommodate whatever dynamic memory needs arise during your execution."
  
  Alloca : "That leaves the stack at the top. What is that?"
  
  Kernel : "It is a dedicated region for managing function calls. Every time you call a function, the stack is involved."
  
  Alloca : "Why does calling a function need its own memory region? Why not use one of the other segments?"
  
  Kernel : "Let's think about what needs to happen when you call a function. What kind of data does a function need?"
  
  Alloca : "Well, its local variables, I suppose. And probably the return address so it knows where to jump back to when it's done?"
  
  Kernel : "Exactly! And also the CPU register values that need to be saved and later restored when the function returns. Now, all of this needs to be allocated when a function is called and cleaned up automatically when it returns. Which of the segments we've discussed could handle something like this?"
  
  Alloca : "Not the data or BSS segments, those are fixed in size. They can't grow and shrink."
  
  Kernel : "What about the heap?"
  
  Alloca : "The heap can grow, but I'd have to explicitly malloc and free, right? That would be tedious, slow, and error-prone for every function call."
  
  Kernel : "Yeah, what you need is a region that grows and shrinks automatically as functions are called and return. It needs to follow a very specific pattern: the last function you called is the first one that returns. Does that sound familiar?"
  
  Alloca : "That's… last-in-first-out. Like a stack data structure!"
  
  Kernel : "Precisely! That's why we call it the stack. The processor even has dedicated instructions, push and pop, that work with a special register called the stack pointer. This register tracks the current top of the stack. When you call a function, all its data (local variables, saved registers, return address) ends up on the stack. When you return, that block gets popped off. All automatic, no manual memory management needed."
  
  Alloca : "So it's about automatic lifetime management for function-local data. But what happens if there is a very deep chain of function calls? Can the stack grow indefinitely?
  
  Kernel : "Not quite. As one function calls another, space needs to be made on the stack to accommodate the local variables of the called function. But there is a limit to how much the stack can grow. For example, on x86-64, the default configured maximum size of the stack is 8 MB."
  
  Alloca : "But as I can see, the stack is right at the top of the address space, where does it have room to grow?"
  
  Kernel : "Good observation! The stack is usually mapped at the higher address range and it grows by moving towards the lower address ranges. So, for example, if the stack pointer is currently 0x120008 and you push an 8 byte value on the stack, the stack pointer becomes 0x120000"
  
  Alloca : "So the heap grows upward and the stack grows downward?"
  
  Kernel : "Yes. The empty space between them is the buffer that lets both grow without colliding. In practice, a process runs out of one or the other long before they meet."
  
  Alloca : "Okay, I understand the layout now. But I've one final question about it, what is the need for such a layout? Why not simply store data anywhere you find space?"
  
  Kernel : "Great question! There are two big reasons: performance and security. Which one would you like to hear about first?"
  
  Alloca : "Let's start with performance."
  
  Kernel : "Alright. Tell me, if you are reading a value from an array at index 5, what do you do after that?"
  
  Alloca : "Well, I probably would read index 6, then 7, and so on? Most array processing is sequential like that."
  
  Kernel : "Exactly! And when you're executing instructions in your code, you typically run them one after another, right? You're not randomly jumping all over the place."
  
  Alloca : "Right, except for loops and function calls, it's mostly sequential."
  
  Kernel : "Yes! This pattern of accessing nearby memory locations is so common that the hardware is designed around it. But, fetching data from physical memory is slow. Really slow. It can take hundreds of CPU cycles."
  
  Alloca : "That sounds terrible!"
  
  Kernel : "It would be, if the CPU actually went to main memory for every single read. But it doesn't. The CPU has a fast cache, smaller but much faster storage right on the chip. And this is the clever bit: when you read a value from memory, the hardware doesn't just fetch that one value. It fetches an entire block around it, typically 64 bytes, called a cache line."
  
  Alloca : "So it's betting that I'll need the nearby data too?"
  
  Kernel : "Precisely! And because of how you traverse arrays or execute sequential instructions, that bet pays off most of the time. The next value you need is already sitting in the cache, ready instantly. This is called spatial locality."
  
  Alloca : "Ah, so that's why the organized layout helps! If my heap has all my data structures, and I'm traversing a linked list, the nodes are likely to be near each other in memory?"
  
  Kernel : "Well, linked lists are actually a bad example, their nodes can be scattered all over the heap. But arrays, yes! And more importantly, think about your stack. When you're executing a function, you're constantly accessing its local variables. Because they're all packed together in one stack frame, most of those accesses hit the cache."
  
  Alloca : "And the same applies to code in the text segment?"
  
  Kernel : "Exactly. Your instructions execute sequentially, so the processor can even prefetch the next cache line before you ask for it. By keeping code separate from data, and keeping different types of data in their own regions, we maximize these cache-friendly access patterns."
  
  Alloca : "That makes sense! What about security? How does the layout help there?"
  
  Kernel : "Let me ask you this: if an attacker managed to write arbitrary bytes into your heap, say through a buffer overflow bug, what's the worst thing they could do?"
  
  Alloca : "Um, corrupt my data structures? Make my program crash?"
  
  Kernel : "That's bad, but there's something worse. What if those bytes they wrote were actually machine instructions? And what if they then tricked your program into jumping to that address?"
  
  Alloca : "Oh no… then the CPU would execute their malicious code as if it were part of my program!"
  
  Kernel : "Exactly. And without protection, they could also try to overwrite your actual code in the text segment, inserting a backdoor directly into your program."
  
  Alloca : "So how do we prevent that?"
  
  Kernel : "By giving each segment permission bits. Think about what should be allowed for each segment. Should you be able to write to your code segment?"
  
  Alloca : "No, the code is fixed! It shouldn't change while the program runs."
  
  Kernel : "Right. So the text segment is marked read-only and executable: you can run code from it, but you cannot write to it. Now, what about your heap and stack?"
  
  Alloca : "I need to read and write data there all the time. But I should never execute code from there, right?"
  
  Kernel : "Perfect! The heap and stack are marked read-write but not executable. You can modify your data, but if someone tries to jump to an address in the heap and execute it, the processor will refuse and kill your process."
  
  Alloca : "So by separating code from data, we can enforce different permissions on each?"
  
  Kernel : "Precisely. This is often called W^X protection (write XOR execute). Memory can be writable or executable, but not both. By organizing memory into distinct segments, we make this protection model clean and enforceable."
  
  Key Takeaway
  
  The virtual address space is organized into several distinct segments :
  - Text (code) segment : The compiled instructions of the program. Loaded at startup, mapped read-only and executable. The process cannot write to its own code pages.
  - Data segment : Global and static variables that have been explicitly initialized. Size is fixed at link time.
  - BSS segment : Global and static variables that are zero-initialized. The binary stores no data for this region; the loader provides zero-initialized memory for it at startup.
  - Heap : The region for dynamic memory allocation (malloc/new). Starts just above the data/BSS segments and grows upward for small allocations; its upper boundary is called the program break (brk). Many allocators also use mmap directly for large allocations rather than growing the heap via brk.
  - Memory-mapped region : A large, flexible area in the middle of the address space used for shared libraries, file mappings, and anonymous large allocations. Libraries like libc are loaded here.
  - Stack : Holds the call frames of all currently executing functions. Starts near the top of the address space and grows downward. Each function call pushes a frame containing local variables, saved registers, and the return address; each return pops it.
  Aside: Anonymous memory
  
  Throughout the article, we will come across a term "anonymous memory ", it is important that we understand what it means.
  
  The kernel manages two kinds of memories:
  - Anonymous memory : this is allocated using malloc or mmap with the MAP_ANONYMOUS flag. This is also the memory backing a process's heap, stack and similar segments.
  - File-backed memory : this is the memory which is backed by a file. You normally create it using mmap and passing a file descriptor to it.
  We will cover both of these in quite detail as we progress through the article, but having this common vocabulary will help us move faster.
  
  How are Virtual Addresses Translated to Physical Addresses
  
  Alloca : "I understand the layout. Code down here, stack up there. But these are all virtual addresses. How does a virtual address ever become real? I'm imagining you keep a table, virtual byte 0 maps to physical byte X, virtual byte 1 maps to physical byte Y, one entry for every address. Is that how it works?"
  
  Kernel : "That's the natural first thought. Let's see what it costs. Your address space (the user-space half) is 128 TiB, that's roughly 140 trillion bytes. At 8 bytes per table entry, a per-byte mapping table would take 1 PiB of storage per process. That's impractical."
  
  Alloca : "So a per-byte table is out. But you do need a lookup of some kind."
  
  Kernel : "Yes, we do. But, instead of mapping individual bytes, we map fixed-size chunks. I divide your virtual address space into fixed-size chunks called pages , and I divide physical memory into same-sized chunks called frames. Each virtual page maps to one physical frame at a time. One table entry per page, not per byte. This way we don't waste too much space maintaining the mapping itself."
  
  Alloca : "How large are these chunks?"
  
  Kernel : "4 kilobytes. At that size, your 128 TiB address space divides into 235 pages."
  
  Alloca : "Wait, why 4 kilobytes specifically? Why not map smaller chunks like 1 kilobyte, or larger ones like 64 kilobytes?"
  
  Kernel : "Good question! Let me ask you this: when you read a variable from memory, say an integer, do you usually read just that one value and nothing else nearby?"
  
  Alloca : "Well, no. If I'm reading array[5], I probably read array[6] and array[7] soon after. And when executing code, I run instructions sequentially, one after another."
  
  Kernel : "Exactly! Memory accesses happen in clusters, spatial locality again. The hardware already exploits this with 64-byte cache lines; pages work the same way at a coarser scale. 4 KB is a sweet spot: large enough that related data usually falls within the same page, but also small enough that we don't waste physical memory when only part of a page is touched."
  
  Alloca : "So 4 KB is a sweet spot between granularity and efficiency?"
  
  Kernel : "Right. And because every page and every frame is exactly the same size, any free frame can back any page. It doesn't matter where in physical memory that frame happens to sit."
  
  Alloca : "Okay, I understand the page size. But there is something that I still don't get: you're mapping an entire 4 KB page to an entire 4 KB frame. But, I have a specific address, and I want to read 8 bytes from it. How do you find out which virtual page that address belongs to, to get the corresponding physical frame?"
  
  Kernel : "The answer lies in the virtual address itself. Think of it like a library call number. When a librarian gives you the number 3-07-42 , you know immediately that the book is on floor 3, rack 07, shelf 42. The number encodes two things at once: which shelf unit to find, and where within that unit to look. A virtual address works the same way. It encodes which page the address falls in, and the byte position within that page."
  
  Alloca : "So the address itself tells you both the page and the position inside it?"
  
  Kernel : "Yes. Every virtual address is implicitly two things: the virtual page number , given by the upper bits, and the page offset given by the lower 12 bits. 12 bits because 2¹² = 4096, one for every byte in a page. Say your address points 500 bytes into page N. When I map page N to physical frame M, your data is still 500 bytes in, because the frame is the same 4 KB size. The offset does not change during translation. So I look up the virtual page number in your page table, get back the physical frame number, attach the same offset, and that gives the physical address of exactly the 8 bytes you asked for."
  
  Alloca : "Okay, I understand that part. But something is still not clear. You said that my address space is 128 TiB. If there's one page table entry per 4 KB page, that's 235 entries. At 8 bytes each entry, that's 256 GiB of page table. Per process. That's not workable."
  
  Kernel : "Exactly, that's the problem with a flat table. So let me ask you this: what if, instead of tracking every single page, we tracked which regions of your address space are in use?"
  
  Alloca : "Regions? Like groups of pages?"
  
  Kernel : "Yes. Think about your address space. You have code at the bottom, a heap above that, maybe some libraries in the middle, and a stack at the top. Most of the space between them is empty, right?"
  
  Alloca : "Right, huge stretches of unused addresses."
  
  Kernel : "So what if I had a high-level index that just tracks which large regions are in use, and then within each of those regions, I have another index for smaller regions, and so on, until I get down to individual pages?"
  
  Alloca : "Like… a tree structure? Where each level zooms in on a smaller portion?"
  
  Kernel : "Precisely! It's called a hierarchical page table. There are four levels. At the top level, there's a table with 512 entries, and each entry represents 512 GB of your address space. If an entire 512 GB region is unused, that entry is just marked absent, no further tables are allocated for it."
  
  Alloca : "So you only allocate the deeper levels of the tree for the parts I'm actually using?"
  
  Kernel : "Yeah. Each entry at the top level can point to a second-level table, which again has 512 entries, each covering 1 GB. Each of those can point to a third-level table covering smaller regions, and so on, until the deepest level maps to individual 4 KB pages."
  
  Alloca : "But wait, doesn't having four levels still waste space? If I use just one page, don't you still need entries at every level to reach it?"
  
  Kernel : "Yes, but consider the scale. For that one used page, I need one entry in the top-level table, one second-level table with 512 entries, one third-level table with 512 entries, and one fourth-level table with 512 entries. That's roughly 12 KB total. Compare that to a flat table: 235 entries times 8 bytes equals 256 GiB. I save a factor of 20 million."
  
  Alloca : "So the table itself only exists for the parts of my address space I've actually used."
  
  Kernel : "Correct!"
  
  Aside: Page table level names difference between Linux and x86
  
  The four levels of the page table hierarchy have different names depending on whether you're reading Linux kernel source or Intel/AMD architecture manuals.
  
  Table: Naming convention for page table levels in Linux vs x86 architecture
  
  The x86 names are tied to the specific architecture. The Linux names are more generic and are used consistently across architectures that Linux supports, whether that's x86-64, ARM64, or RISC-V, even when the underlying hardware has a different number of levels. Throughout this article we use the Linux kernel names: PGD, PUD, PMD, and PTE.
  
  Alloca : "But how does a virtual address help you traverse this?"
  
  Kernel : "It's actually pretty clever. Your virtual addresses are 64 bits wide, but only 48 bits are used. Those 48 bits are split into five parts: four groups of 9 bits each, followed by a 12-bit offset. The first four groups are used one by one to step through each level of the page table tree, narrowing down to the right physical frame. The offset is then used to pinpoint the exact byte within that frame."
  
  Alloca : "What is the exact split of these bits?"
  
  Kernel : "The first group (bits 47 down to 39) gives a number between 0 and 511, which I use as an index into the PGD. That entry points me to a PUD. I take the next group (bits 38 down to 30) and index into that PUD, which points to a PMD. I repeat this for the PMD and PTE levels."
  
  Alloca : "That leaves the bottom 12 bits, those act as offset within the page frame?"
  
  Kernel : "Yes, once you reach the PTE and get the physical frame number, you combine it with those 12 bits to get the exact byte you want. 12 bits because 212 is 4096, the page size."
  
  Figure 2: The four-level page table hierarchy on x86-64. To translate a virtual address, four groups of 9 bits (i, j, k, l) are used as indices, one per level, to walk down the tree to the right page frame. The final 12 bits give the byte offset within that frame. Sub-tables are only created for parts of the address space that are actually mapped, so unused regions cost nothing.
  
  Aside: 48-bit virtual addresses
  
  On common 4-level x86-64 systems, virtual addresses are stored in 64-bit registers, but you should have noticed that only 48 bits participate in this address translation scheme, what about the top 16 bits?
  
  The top 16 bits must be a sign-extension of bit 47: all zeroes for low-half user-space addresses, all ones for high-half kernel-space addresses. Such addresses are called canonical addresses. A non-canonical address faults before the normal page-table walk even completes. This is what creates the large unused gap between the low and high halves of the 64-bit virtual address space.
  
  Recent x86-64 processors and Linux kernels also support 5-level page tables, which use 57 bits for address translation (adding a fifth level called P4D (Page 4th Directory) between the PGD and PUD). This provides 2⁵⁷ bytes (128 PiB) of virtual address space per process. The additional level uses bits [56:48] as an index, with bits [63:57] remaining as sign-extension of bit 56.
  
  This article took months of research, writing, and revision. If it helped you understand virtual memory more deeply, consider becoming a paid subscriber. Your support makes it possible for me to keep publishing long-form systems deep dives like this.
  
  Alloca : "I see how the bits map to the levels. But who actually performs this translation? On every memory access, something has to look up these tables."
  
  Kernel : "A dedicated piece of hardware called the Memory Management Unit , or MMU. It intercepts every address you issue. You never see any of this; to you it appears as if you are reading directly from your virtual address."
  
  Alloca : "So the MMU does this lookup automatically on every memory access? How does it know where to start?"
  
  Kernel : "The CPU has a register called CR3 that holds the physical address of your current PGD, the top-level table. I update it on every context switch so the MMU knows which process's tables to use."
  
  Alloca : "And then it uses the bits from my address to walk through the levels?"
  
  Kernel : "Yeah, the same bit fields we just covered. Bits [47:39] index into the PGD, [38:30] into the PUD, [29:21] into the PMD, and [20:12] into the PTE. That last entry gives the physical frame number, which the MMU combines with the 12-bit page offset to produce the physical address."
  
  Figure 3: The four-level page table walk on x86-64. The CPU register CR3 holds the physical address of the top-level table (PGD). Each level is indexed by 9 bits of the virtual address. The TLB caches completed walks; the four-level traversal only occurs on a TLB miss. How often that happens depends heavily on access patterns.
  
  Alloca : "But this means every memory access now requires four table lookups. That's four extra memory reads just to translate my address. Doesn't that make every memory access slower than it should be?"
  
  Kernel : "It would be, if we had to walk all four levels every time. But the MMU has a small, dedicated hardware cache called the Translation Lookaside Buffer , or TLB. Every time a page table walk completes successfully, the result is stored in the TLB: 'virtual page P maps to physical frame F.' The next time you access the same page, the MMU checks the TLB first. If it's there (a TLB hit), the translation completes in a handful of cycles, with no table walking at all."
  
  Alloca : "And how often does that happen?"
  
  Kernel : "Programs that reuse the same memory regions repeatedly, such as tight loops, frequently executed functions, reused buffers, tend to stay within a small working set of pages, keeping the TLB warm and page walks rare. But that is not a given. Access patterns matter a great deal."
  
  Aside: Working set
  
  A process's working set is the subset of its virtual pages that are actively needed during a given window of execution. It's not a fixed quantity, it shifts as the program moves through different phases. A tight loop over a small array has a tiny working set: just the pages holding the loop instructions and the array. A database engine scanning a large table has a much larger one.
  
  The working set matters for two hardware structures:
  - TLB : If the working set fits within the TLB's capacity (typically a few hundred to a few thousand entries), translations stay cached and page walks are rare. If the working set exceeds TLB capacity, there are larger number of TLB misses which may cost performance.
  - Physical RAM : If the working set fits in RAM, pages stay resident. If it doesn't, the kernel must evict pages to swap and reload them on demand, which is a far more expensive operation (we cover eviction and swap later in the article).
  Keeping the working set small and stable is one of the most effective things a program can do to improve memory performance.
  
  Key Takeaway
  
  Virtual memory operates at the granularity of pages (4 KB chunks of virtual address space) that map to frames (4 KB chunks of physical memory). Each virtual address encodes two pieces of information: the virtual page number (upper bits) and the page offset (lower 12 bits). The offset stays the same during translation; only the page number changes to a frame number.
  
  On x86-64, the kernel uses a four-level hierarchical page table to perform this mapping. The structure has four levels named PGD (Page Global Directory), PUD (Page Upper Directory), PMD (Page Middle Directory), and PTE (Page Table Entry). A 48-bit virtual address is divided into four 9-bit index fields (one per level) plus a 12-bit offset, as shown in Figure 2. The hierarchy is sparse: only the portions of the address space actually in use require allocated page table structures, avoiding the 256 GiB overhead of a flat table.
  
  Because each virtual page is mapped independently, there is no requirement that consecutive virtual pages land in consecutive physical frames. A process's pages can be scattered anywhere in physical RAM, interleaved with frames from other processes, yet the process always sees a clean, contiguous address space. Figure 4 shows this concretely.
  
  The Memory Management Unit (MMU) performs address translation in hardware. On x86, the register CR3 holds the physical address of the current process's PGD. On every memory access, the MMU first checks the translation lookaside buffer (TLB) to see if the translation is already cached. If not, the MMU performs a full page table walk to do the translation and then caches the translation in the TLB.
  
  Figure 4: Each process has its own virtual address space, but the page table maps virtual pages to physical frames that may be anywhere in RAM. Adjacent virtual pages can land in widely separated frames, and frames from multiple processes are interleaved in physical memory. The page table is what makes this invisible to the process.
  
  Memory Protection via Permission Bits
  
  Alloca : "Earlier you told me that my code segment is read-only. I can execute it but not write to it. But now that I understand the page table, I don't see what actually enforces that. My code pages have entries in the page table just like everything else. What stops me from writing to them?"
  
  Kernel : "Each page table entry carries more than just the frame number. It also holds permission bits. The writable bit says whether you can write to that page, if it is 0, the MMU refuses the write and faults : it stops the access mid-flight and signals me to handle the situation. The executable bit says whether you can run code from it. When I set up your code segment I mark those pages as executable but not writable. Your data and heap are writable but not executable. The MMU checks these bits on every access."
  
  Alloca : "What happens when it faults? Say I try to write to one of my code pages?"
  
  Kernel : "I get called to handle it. A permission violation is almost always a bug or a security attack, so I typically terminate you."
  
  Alloca : "Got it. Are there other kinds of bits apart from permission bits?"
  
  Kernel : "Yes, a very important one that you should know about. There is a present bit in every entry, at every level of the hierarchy. If it is 0, the walk stops there and the CPU faults. But a not-present entry doesn't necessarily mean something went wrong. It might just mean that I haven't allocated a physical frame for that page yet, or that the page has been evicted to disk."
  
  Alloca : "So the permission bits enforce boundaries between code and data, and the present bit tells you whether a page is backed by physical memory at all."
  
  Kernel : "Exactly!"
  
  Key Takeaway
  
  Each page table entry contains not just a frame number but also several permission bits that the MMU enforces on every memory access:
  - Present bit : Indicates whether the page is currently backed by a physical frame. If 0, the page table walk stops and the CPU raises a page fault. A not-present page doesn't always signal an error; it might mean the kernel has promised the address range but hasn't yet allocated physical memory for it (demand paging, covered in the next section). It might also mean that the physical frame was swapped to disk and reused by another process.
  - Writable bit : Controls write permission. If 0, any write attempt triggers a fault. Used to make code pages read-only and to implement copy-on-write (covered later).
  - Executable bit (or NX/XD bit) : Controls execution permission. If the page is marked non-executable, the processor refuses to fetch instructions from it. Code pages are marked executable; data, heap, and stack pages are marked non-executable to prevent code injection attacks.
  The MMU checks these permission bits on every memory access, before the access completes. Permission violations typically indicate bugs or security violations and usually result in the kernel terminating the faulting process. This hardware-enforced separation between code and data is a foundational defense against many classes of exploits.
  
  Demand Paging
  
  Some time passes. Alloca has been running her code and has grown more comfortable in this world. But now she needs more memory, she is about to process a large dataset and needs space to store intermediate results.
  
  She does what any process would do: she makes a system call asking for memory. A new region appears in her address space. Kernel hands her an address:0x55a3c2f00000 . She immediately goes to write her first value there.
  
  And then something strange happens. Time seems to stop for a fraction of a moment. And then it starts again, as if nothing had occurred. Her write went through. But something had happened, she had simply not noticed.
  
  Alloca : "That was odd. Did I just… stutter?"
  
  Kernel : "You did. You triggered a page fault. Don't worry, I took care of it."
  
  Alloca : "A page fault? What's that? And what did you take care of?"
  
  Kernel : "When I gave you that address, I didn't actually back it with physical memory. I recorded the promise that this range of virtual addresses belongs to you, but I didn't go and find a physical frame to put behind it."
  
  Alloca : "You gave me an address without any memory behind it? That sounds like fraud."
  
  Kernel : "It's efficiency. Think about it: you might ask for a hundred megabytes and only use ten. If I allocated a physical frame for every page you asked for, I'd be wasting most of physical memory on pages that never get touched. So instead, I wait. When you actually try to access a page for the first time, the MMU looks up that address in your page table and finds the present bit set to zero. No physical frame is mapped. The MMU raises a trap (a page fault) and control transfers to me."
  
  Alloca : "But how did you know my access was valid? Maybe I was accessing some address I had no right to. How do you tell the difference?"
  
  Kernel : "When I gave you that memory region, I recorded a note called a virtual memory area , or VMA. It says: 'virtual addresses from X to Y are promised to Alloca, with these permissions.' The VMA is not a page table entry. It's a higher-level record of intent that I maintain separately."
  
  Alloca : "So you have two different data structures tracking my memory?"
  
  Kernel : "Yes. The VMA describes what address ranges are valid for you to access. The page table describes which of those valid pages are currently backed by physical frames. When you were created, I set up VMAs for your code segment, your data segment, your stack. Each one records an address range and what you're allowed to do there: read, write, execute. Later, when you call malloc or mmap, I create a new VMA for that allocation. But I don't immediately create page table entries for it."
  
  Alloca : "So when the MMU finds a missing page table entry for an address, it triggers a page fault?"
  
  Kernel : "Yes. When a page fault fires, I have to handle it. I first check whether the faulting address falls inside a valid VMA. If yes, the access is legitimate. I just haven't backed it with a physical frame yet. If the address is outside any VMA, you've wandered somewhere you were never given. That's a segmentation fault, and I terminate you."
  
  Alloca : "So the VMA list is your record of promises, and the page table is the record of fulfilments."
  
  Kernel : "Well put. Now, once I confirm the fault is legitimate, I find a pre-zeroed physical frame, write a new entry into your page table pointing to that frame, and resume your execution. The CPU retries the faulting instruction and your write goes through."
  
  Figure 5: A page table entry before and after a demand paging fault. The kernel changes the present bit from 0 to 1 and fills in the physical frame number (PFN).
  
  Alloca : "Wait. Why did you zero it out? Couldn't you just give me the frame as-is?"
  
  Kernel : "Absolutely not. Physical frames get reused. That frame might have previously held data from another process. If I handed you that frame without clearing it first, you could read another process's secrets just by reading uninitialized memory. The zero-fill guarantee is a security invariant: you will never see data you didn't write yourself."
  
  Alloca : "That's reassuring. But what if there are no free frames? What if physical memory is full?"
  
  Kernel : "It happens more often than you'd expect, and dealing with it changes what the present bit in a PTE can mean."
  
  Figure 6: The demand paging lifecycle. Step 3 (checking the VMA) is what distinguishes a legitimate first access from an invalid access. Without a matching VMA, the kernel delivers a segmentation fault instead of allocating a frame.
  
  Aside 1: How the stack grows using demand paging
  
  Remember, when talking about address space layout, we said the stack grows downward. That growth is demand-driven too. The kernel marks the stack VMA as growable, but it does not map every possible stack page upfront. When the stack pointer moves into the next valid page below the current stack, the access faults. Because the faulting address is just below the current stack bottom and the stack VMA is marked as growable, the kernel extends the VMA downward by one page, allocates a frame, and resumes execution. From Alloca's perspective the stack just grew silently.
  
  Two mechanisms prevent this from continuing forever. First, the kernel enforces a maximum stack size (on Linux, set by ulimit -s, defaulting to 8 MB). The stack VMA will not be extended past that limit. Second, below the maximum stack limit sits a guard page : a single page that is deliberately left unmapped, no VMA covers it. If the stack pointer jumps far enough to land in or past the guard page (due to deep recursion, a large stack-allocated array, or a corrupted stack pointer), the fault finds no covering VMA. The kernel treats that as an invalid access and delivers SIGSEGV.
  
  The guard page is what turns a silent runaway stack into a detectable crash. Without it, the stack could silently overflow into the memory-mapped region below it and corrupt library or heap data before anything notices.
  
  Aside 2: Memory overcommit: a consequence of demand paging
  
  Demand paging creates an interesting situation: if the kernel only allocates physical frames at first-access time, then malloc(10GB) on a machine with 4 GB of RAM will succeed (at least initially). The kernel records the promise in a VMA and returns immediately. No frames are allocated. This is called overcommitting memory: the total size of all VMAs across all running processes can far exceed the amount of physical RAM plus swap.
  
  The kernel's bet is statistical. In practice, most allocated memory is never fully touched. A process might allocate a large buffer "just in case" and only ever write to a fraction of it. A JVM might reserve a large heap up front but populate it lazily. Across hundreds of processes, the working sets sum to much less than the total committed virtual memory, and the system runs fine.
  
  The bet occasionally goes wrong. When too many processes start faulting in pages simultaneously, memory pressure spikes, and the kernel runs out of physical frames. At this point it invokes the OOM killer (Out-Of-Memory killer): a kernel subsystem that scores each process by its memory consumption, age, and other heuristics, then kills the highest-scoring one to reclaim its frames.
  
  You can observe overcommit and OOM events on Linux:
```
# How much virtual memory is committed system-wide (in kB)

grep CommitLimit /proc/meminfo   # kernel's ceiling: overcommit_ratio × RAM + swap

grep Committed_AS /proc/meminfo  # total virtual memory promised to all processes

# See if the OOM killer has fired recently

dmesg | grep -i "oom\|killed process"

journalctl -k | grep -i oom
```
  The kernel's overcommit policy is tunable via /proc/sys/vm/overcommit_memory:
  - 0 (default) uses heuristics
  - 1 always allows any allocation
  - and 2 caps total committed memory at overcommit_ratio × RAM + swap and begins refusing malloc calls that would exceed it.
  Key Takeaway
  
  When a process allocates memory, whether by calling malloc, growing its stack, or explicitly requesting memory via mmap, the kernel does not immediately back every page of that allocation with a physical frame. Instead, it creates a Virtual Memory Area (VMA) in the process's memory descriptor: a record that says "this range of virtual addresses is valid and belongs to this process, with these permissions." The page table entries for these pages are left absent (present bit = 0).
  
  The VMA and the page table serve different roles:
  - The VMA is the kernel's record of intent : what address ranges the process is allowed to access.
  - The page table is the record of reality : which virtual pages are currently backed by physical frames.
  The first time the process reads or writes any address in an allocated-but- unmapped range, the MMU finds a page table entry with present=0 and raises a page fault , a CPU exception that transfers control to the kernel. The kernel's page fault handler:
  1. Looks up which VMA contains the faulting address. If none, the access is invalid and the kernel delivers a segmentation fault, terminating the process. Otherwise, it continues:
  2. Allocates a free physical frame.
  3. Zero-fills that frame (the zero-fill guarantee, required for security, ensures the process never sees data from a previous owner of that frame).
  4. Installs a new page table entry pointing to that frame, with the present bit set.
  5. Returns from the exception, causing the CPU to retry the faulting instruction.
  From the process's perspective, execution pauses for a few microseconds and then continues as if nothing happened. This mechanism is called demand paging : physical memory is allocated on demand , at the moment of first access, rather than speculatively at allocation time.
  
  The fault described above requires no disk I/O: it is called a minor page fault. Minor faults cover any fault the kernel can resolve entirely in memory. This includes zero-fill for pages that aren't backed by any file, but also cases where the data is already resident somewhere (in the page cache, or shared from another process) and just needs a PTE installed. There is a second kind of fault called major fault , that does require reading from disk. We will get to that next.
  
  A side effect of demand paging is that physical frames are allocated one by one, on demand, from wherever free memory happens to be. There is no requirement that consecutive virtual pages land in consecutive physical frames. A process's stack might occupy frames scattered across RAM, interleaved with frames belonging to completely different processes. The page table is what makes this invisible: it maps each virtual page independently, so the process always sees a clean, contiguous virtual address space regardless of where its frames physically reside.
  
  Prefer reading this as a polished PDF? I 've prepared a beautifully typeset PDF version for offline reading and reference. Buying it is another way to support the time that went into this article.
  
  Get PDF
  
  When Physical Memory Runs Out: Swap and the Dual Meaning of the Present Bit
  
  Alloca : "So what happens when there is not enough free physical memory left to allocate?"
  
  Kernel : "Let me show you. Let's say that I need to allocate a frame for you, but they are all taken. So I must evict a page from somewhere, I look for a page that hasn't been accessed recently. It could be from another process, or even one of your own pages. Once I find the page to evict, I write its contents to disk to a reserved area called swap space. Then I reclaim the frame and give it to you."
  
  Alloca : "And what happens if the process that owned that page tries to access it again?"
  
  Kernel : "Before I give that frame to you, I update the process's page table. I locate the PTE that points to that frame, clear its present bit to 0, and store the swap location in the remaining bits of the entry. The hardware never looks at those bits when present is 0, but I do when handling the page fault."
  
  Alloca : "So when that process touches the page again…"
  
  Kernel : "The MMU sees the present bit is zero in the PTE, and it raises a page fault bringing me into action to handle it. My fault handler follows the same entry point as always: check the VMA first. In this case, because the page was swapped, its VMA must exist, so the fault handler moves forward and checks the PTE next. It finds the swap coordinates in the non-present bits, uses those to read the data from the disk, and loads it into a fresh frame. After that, it reinstalls the PTE with present=1. Once the page fault handler finishes, I resume the process and it retries the instruction that triggered the fault and this time it succeeds. It never knew the page had left."
  
  Aside: Minor vs Major Page Fault
  
  Earlier in the demand paging section, we talked about minor page faults. Those kind of page faults don't involve disk I/O and are handled directly in memory. For example, when malloc allocates more pages, the kernel simply creates the VMA, and allocates the physical frames on demand when the page fault occurs.
  
  The page fault that we discussed above when a process tries to access a page that has been swapped to disk is a major page fault because handling it requires disk I/O.
  
  Alloca : "So present=0 in a PTE always means that the data is in the swap?"
  
  Kernel : "No. Swap is one destination, but it's not the only one. A non- present PTE can point to data that lives somewhere other than swap space."
  
  Alloca : "Where else can it go besides swap?"
  
  Kernel : "A file. Not every page comes from memory you allocated with malloc or grew from the stack. Some pages map directly to content stored in a file on disk."
  
  Alloca : "How does that work?"
  
  Kernel : "You use the mmap system call. It lets you map a file into your address space. When you do that, I create VMAs for the mapped range, but I leave the PTEs absent, just like with malloc."
  
  Alloca : "So on first access?"
  
  Kernel : "This time again the MMU sees an absent PTE and raises a page fault. But handling this page fault is different from how I handle a page fault for a swapped page, or how I handle allocation of new memory like what we discussed when talking about demand paging earlier."
  
  Alloca : "What changes?"
  
  Kernel : "The first step is the same, I check the VMA to confirm this is a valid region. But what happens next depends on the type of mapping."
  
  Alloca : "What's different about a file-backed mapping?"
  
  Kernel : "For anonymous mappings, a fault means either a fresh allocation where I hand you a new zero-filled frame, or a swap restore, where I read the page back from disk using the swap coordinates stored in the PTE. For file-backed mappings, there is no swap entry. Instead, the VMA itself tells me which file and which block of that file to read. I load that block into a frame, install it in the page table, and resume you."
  
  Alloca : "So at the PTE level, present=0 is just a signal: data is not in RAM. But the place to find it depends on what kind of mapping this is?"
  
  Kernel : "Precisely. For anonymous memory pages that have been swapped, the non-present PTE can carry swap coordinates. For a file mapping that has not been loaded yet, I usually use the VMA to find the file and offset. Either way, the fault handler has enough information to reconstruct the page."
  
  Key Takeaway
  
  When physical memory runs out, the kernel must reclaim frames. It selects pages that have not been accessed recently and evicts them. For anonymous pages (heap, stack, malloc), there is no file to fall back on, so the kernel writes the page's contents to swap space on disk before freeing the frame. It then updates the PTE: the present bit is cleared to 0, and the remaining bits are repurposed to store swap coordinates (device number and page offset). These bits are ignored by the hardware; they exist solely as a private record for the kernel's own fault handler.
  
  When the evicted page is next accessed, the MMU finds present=0 and raises a major page fault. The fault handler reads the swap coordinates from the PTE, loads the page from disk into a fresh frame, reinstalls the PTE with present=1, and resumes the process.
  
  However, a page fault for a file-backed mapping is handled slightly differently. Here, the VMA contains information about the file and the offset in the file needed to populate the frame.
  
  Together, anonymous and file-backed mappings cover all the cases a fault handler encounters. Two questions decide which path it takes:
  1. What type of mapping is this? Anonymous memory has no file behind it. File-backed memory does.
  2. Why is the page absent? A first-access fault (i.e., the frame was never allocated), or the page was evicted due to memory pressure and now being accessed again.
  Figure 7 below shows all four combinations and how the fault handler resolves each
  
  Figure 7: The four paths the kernel takes when resolving a page fault, organized by mapping type (rows) and reason for absence (columns). An anonymous first-access fault is the only minor fault, the kernel zero-fills a fresh frame with no disk I/O. All other cases require reading from swap or from a file and are major faults. For first-access faults (left column), no page table entries may exist yet, and the fault handler allocates the intermediate levels (PGD, PUD, PMD) and the PTE on demand. For evicted or dropped pages (right column), the intermediate levels already exist from when the page was first loaded; only the PTE was updated when the page left RAM.
  
  Aside: Pinned memory and GPU data transfers
  
  Everything discussed so far assumes the kernel is free to evict any page when memory pressure demands it. There are cases where that is unacceptable. Pinned memory (also called page-locked memory) is memory that the kernel is prohibited from swapping out. A process can pin a region by calling mlock(), after which the kernel guarantees that the underlying physical frames will not be moved or reclaimed for as long as the lock is held.
  
  The most common reason to pin memory today is GPU data transfers. DMA (Direct Memory Access) engines, which move data between host RAM and GPU memory without CPU involvement, require that the source or destination buffer remain at a fixed physical address for the duration of the transfer. If the kernel were to evict a page mid-transfer and reassign the frame, the DMA engine would read or write the wrong physical location. Pinning prevents this by fixing the physical address in place.
  
  This is why AI training frameworks pin host memory for input batches. In PyTorch, torch.cuda.pin_memory() and the pin_memory=True option on DataLoader call mlock() under the hood. With pinned buffers, the CUDA driver can initiate DMA transfers directly from host RAM to GPU memory without an intermediate copy, and it can overlap those transfers with GPU computation. On large models trained on high-bandwidth interconnects (NVLink, PCIe 5.0), this overlap between data loading and compute is a significant contributor to overall throughput.
  
  The trade-off is that pinned memory is a scarce resource. Because pinned pages cannot be reclaimed, overusing it reduces the memory available for the page cache and other processes, increasing the risk of swap pressure elsewhere.
  
  Deep technical articles like this take significant time to research, test, and polish. Paid subscriptions make it possible for me to keep writing them carefully instead of rushing out shorter, shallower pieces.
  
  Copy-on-Write and Fork
  
  Alloca has been given a large job: process a large dataset. She needs help to do this in a quick amount of time.
  
  Alloca : "I wish I had a copy of me that could share this workload."
  
  Kernel : "You can do that, just use the fork() system call."
  
  Alloca : "How does that work?"
  
  Kernel : "When you call fork(), I make a new process which is almost an identical copy of you. I give this process the same code as you, a copy your file descriptor table and even your memory."
  
  Alloca callsfork()and creates a new process called "Forka". She inherits everything Alloca had.
  
  Forka and Alloca start to do their work. Soon Alloca tries to perform a memory write. The familiar brief pause. Then it passes.
  
  Alloca : "That pause. What was that?"
  
  Kernel (appearing): "Another page fault."
  
  Alloca : "Another page fault? But the page is present, I've been reading from it just fine."
  
  Kernel : "It's present, yes. But I marked it read-only, and you tried to write. That's what triggered the fault."
  
  Alloca : "Wait, why did you mark it read-only? That memory was clearly meant for both reading and writing."
  
  Kernel : "It was an optimization I did when creating Forka. Let me explain why I did it."
  
  Alloca : "Please."
  
  Kernel : "I created Forka by giving her an independent copy of your memory. The simple approach is to copy every page immediately. But you have gigabytes of heap, and most of it she may never write to. Copying all of it upfront would waste a lot of time, and also make fork extremely slow. So instead, I gave Forka new page tables that initially point at the same physical frames as you. Which means that both of you are sharing the same frames. But this only works as long as both of you are just reading those frames. When either of you need to write to one of these shared pages, page fault occurs and I give the writing process a private copy of that frame. This particular optimization is also called copy-on-write (CoW)."
  
  Alloca : "So the read-only marking is how you detect that moment."
  
  Kernel : "Precisely. Your write triggered a fault, I caught it, confirmed this was a copy-on-write page, and handled it: I allocated a fresh frame, copied the 4 KB into it, updated your PTE to point to the new frame with write permission restored, and resumed your write. Forka's mapping is untouched."
  
  Alloca : "And now we each have our own copy of that page?"
  
  Kernel : "Yes. That page has been copied on write. But only that page. All the pages you haven't written to yet are still shared. If you never write to a page, it stays shared forever, zero copies made."
  
  Forka : "What if my parent exits before I write to a page?"
  
  Kernel : "I take care of that by tracking reference and mapping state for each physical frame. When your parent exits, I remove its mappings. The next time you write to a page, if I can see that the page is no longer shared, I can skip the copy and simply restore write permission on your existing PTE. There's no one left to protect."
  
  Figure 8: Copy-on-write afterfork(). Initially, both page tables point to the same physical frames (top). After Alloca writes to page A, the kernel allocates a new frame (19), copies the contents, and updates only Alloca 's PTE to point to the new frame. Forka's PTE still points to the original frame and remains read-only; the kernel will restore write permission on Forka's next write fault without needing to copy, because the frame is no longer shared.
  
  Aside: fork + exec: why process creation is cheap
  
  A common Unix pattern is to call fork immediately followed by exec to load and execute a new program. exec discards the child's entire address space and builds a fresh one for the new program. For example, this is how the shell works whenever you execute a command.
  
  For this reason fork needs to be cheap and one way to achieve that is by avoiding the copying of parent's memory pages until it is really needed.
  
  Key Takeaway
  
  fork() creates a new process (the child) that is an exact copy of the parent at the moment of the call. Naively, this would require copying every byte of the parent's virtual memory, a multi-gigabyte operation for large processes. Copy-on-write (COW) makes fork() efficient by deferring that copy until it is actually necessary.
  
  When fork() is called:
  1. The kernel allocates a new process descriptor for the child.
  2. The kernel creates a new set of page tables for the child, initially pointing to the same physical frames as the parent.
  3. For every private writable mapping, the kernel marks the entry as read-only in both parent and child. Read-only pages (code) are shared as-is, they were already protected.
  The kernel tracks reference and mapping state for each physical frame. After a fork, private pages that were writable in the parent are now mapped by both processes, so their state records that they are shared.
  
  When either process subsequently writes to a COW-protected page, the MMU detects a write to a read-only PTE and raises a protection fault. The kernel's COW handler:
  1. Checks whether the page is still shared. If it is, a copy is needed. If the kernel can determine the faulting process is now the only relevant owner, it can simply restore write permission without copying.
  2. If a copy is needed: allocates a new frame, copies the contents, updates the faulting process's PTE to point to the new frame with write permission. The other process's PTE is left pointing to the original frame, still read-only.
  Memory-Mapped Files
  
  Several cycles pass. Alloca is trying to analyze a large log file. She has been doing it the obvious way, callingread()in a loop, filling a buffer, processing the buffer, repeat. Kernel notices this and wanders over.
  
  Kernel : "You know there's a better way to do that."
  
  Alloca : "I'm reading a file. What better way is there?"
  
  Kernel : "Instead of reading into a buffer, let me map the file directly into your address space. You access it like regular memory: just use a pointer, and I'll handle getting the data to you."
  
  Alloca : "You mean I can read a file with a pointer? No read() calls at all?"
  
  Kernel : "Exactly. Call mmap(). Give me the file descriptor, the length, and some flags. I'll create a new VMA in your address space (a memory-mapped region). Then you can read from or write to addresses in that region just like regular memory, and I'll give you the file's contents."
  
  Alloca does it. She gets back an address, 0x7f4b00000000. She reaches out to read the first byte at that address.
  
  And the pause happens again. A little longer this time.
  
  Alloca : "Longer pause. What was that?"
  
  Kernel : "A major page fault. When you called mmap(), I didn't actually load any of the file data into memory. That file could be gigabytes in size, and I have no idea which parts you'll actually access. So I just created a VMA for that address range and left the page table entries absent. The first time you accessed that page, the MMU found present=0, trapped to me, and I had to read it from disk."
  
  Alloca : "So mmap is also lazy?"
  
  Kernel : "That's right. Demand paging works for files too. Now, notice where I put the data after reading it from the disk."
  
  Alloca : "Where?"
  
  Kernel : "In the page cache. This is a pool of physical frames I use to cache file data. When a file page is read (whether via read() or mmap()), it lands in the page cache. For your mmap access, once the data was in the page cache, I installed a page table entry pointing directly to that page cache frame. Your virtual address now directly maps to the physical frame that holds the file data."
  
  Aside: The page cache is not reserved memory
  
  A common misconception is that the page cache is a reserved pool of memory, it's not. It is simply the set of physical frames that the kernel is currently using to hold file data. When an application needs more memory and there are no free frames, the kernel can reclaim clean page-cache frames instantly, because the file on disk is already the backing copy. This is why a system that looks nearly full of "used" memory can still allocate freely: much of that "used" memory is reclaimable cache, not locked-in application data.
  
  Alloca : "So I'm reading the file's data directly from the page cache, through my page table?"
  
  Kernel : "Yes. No intermediate user-space buffer copy. Now compare that to what happens when you use read() instead. I still bring the file data into the page cache, usually by DMA from the storage device into memory. But then read() copies the data from the page cache frame into your user-space buffer. That page-cache-to-user-buffer copy is the extra step that mmap() avoids."
  
  Aside: What is DMA (Direct Memory Access)?
  
  Normally, when a CPU wants data from a storage device or network card, it would have to sit in a loop reading bytes, which is an expensive waste of cycles. DMA is a hardware mechanism that lets peripheral devices transfer data directly into main memory (RAM) without CPU involvement.
  
  In this scheme, the kernel and device driver submit an I/O request that describes the target memory pages and the storage range. The storage controller uses DMA to transfer data directly into those pages and interrupts the CPU when the transfer is done. The CPU is free to do other work the entire time.
  
  Alloca : "And mmap() avoids that second copy because I access the data directly through the mapped address. But what happens if you evict the page cache frame while it's mapped?"
  
  Kernel : "Before I can reclaim that frame, I first remove the page table entry pointing to it. The VMA remains intact, so the next time you access that address the MMU finds no mapping, faults, and I reload the data. From your perspective the mapping is seamless; you never hold a dangling pointer."
  
  Figure 9:read()vs.mmap()I/O paths. Withread(), data is brought from disk into the page cache and then copied into the process 's user-space buffer. With mmap(), the process 's PTE points directly into the page cache, eliminating that page-cache-to-user-buffer copy. The trade-off is that mmap()pays through page faults and page-table management instead of explicit read calls.
  
  Alloca : "So should I always use mmap() for file I/O? Avoiding that user-buffer copy sounds like an obvious win."
  
  Kernel : "Not always. mmap() removes one cost, but it introduces others. It trades explicit I/O and copying for page faults, page tables, TLB pressure, and different failure modes. Whether that trade is good depends on the access pattern."
  
  Aside: mmap()is not automatically faster
  
  The first access to a cold mapped page is still a page fault. The fault enters the kernel, locates the VMA, finds or reads the page cache page, installs a PTE, and resumes the faulting instruction. If you scan a huge file once, you may take one fault per 4 KB page, and those faults can dominate the page- cache-to-user-buffer copy you avoided.
  
  read() and mmap() also expose different shapes of work. With read(), user space usually asks for a large buffer at a time, maybe 64 KB, 256 KB, or more. The kernel copies a contiguous chunk into that buffer and can issue readahead based on the file access pattern. With mmap(), readahead can happen too: when a fault reveals sequential access, the kernel may read surrounding file pages into the page cache, and may map nearby already-cached pages around the fault. But the control flow is still implicit and fault- driven. Cold pages still need faults to install mappings.
  
  Mappings also consume page table memory, create TLB pressure, and may trigger TLB shootdowns when unmapped or when permissions change. Error handling is different too: if another process truncates a mapped file and you later touch a page beyond the new end, the kernel may deliver SIGBUS. With read(), you usually see an error return or a short read instead.
  
  So mmap() is often attractive when access is random, repeated, shared across processes, or naturally pointer-based. read() is often competitive or better for simple sequential streaming, especially with large buffers. "Zero-copy" is not the same as "free"; the only reliable answer for performance-sensitive code is to measure the actual workload.
  
  At that moment, Forka wanders over. She too needs to read the same log file.
  
  Forka : "I'm going to mmap that same file. Same one you're using, Alloca."
  
  Forka callsmmap(). She accesses the same page Alloca just read. But this time there is no pause.
  
  Forka : "That was fast. Why no pause this time?"
  
  Kernel : "Because that page is already in the page cache, it was loaded when Alloca accessed it. I just gave your page table an entry pointing to the same physical frame. You're both reading from the same physical bytes. No disk I/O. No copy. Nothing moved."
  
  Alloca : "Wait, we're both pointing at the same physical frame? So if I write to my mapped region, does Forka see it?"
  
  Kernel : "That depends on a flag you passed to mmap(). With MAP_SHARED, your write goes directly into the shared page cache frame, so yes, Forka sees it. With MAP_PRIVATE, your write triggers a COW fault and you get a private copy, same as after fork(). The file is never touched."
  
  Alloca : "And if I use MAP_SHARED, when does the change actually reach disk?"
  
  Kernel : "It happens asynchronously. But, if you need to guarantee it has been written to disk, you call msync() or fsync()."
  
  Figure 10:MAP_SHARED vs.MAP_PRIVATE write semantics. WithMAP_SHARED , writes go into the shared page cache and are flushed to disk asynchronously. WithMAP_PRIVATE , the first write triggers a COW fault; the process gets a private copy that diverges from both the file and other processes.
  
  Key Takeaway
  
  mmap() is a system call that can be used to map a range of bytes from a file directly into a process's virtual address space, creating a new VMA backed by the file. Subsequent reads and writes to that virtual address range behave exactly like memory accesses: the kernel's page fault machinery handles loading data from disk on demand.
  
  The central abstraction is the page cache : a kernel-managed pool of physical frames that holds recently accessed file pages. In the normal buffered-I/O path, file access via read(), write(), and mmap() goes through the page cache. The difference is how user space reaches those bytes:
  
  Table: read() vs mmap() paths
  
  The reason read() copies into a user buffer is ownership. The caller receives bytes placed in memory it fully controls. Once the call returns, the kernel can evict or reuse the underlying page cache page without affecting the caller's data.
  
  With mmap(), the kernel abstracts away the complexities of memory through the page table: if a mapped page is evicted, the PTE is marked absent, the next access faults, and the kernel reloads the data transparently.
  
  Aside: Bypassing the page cache using direct I/O
  
  By default, ordinary read(), write(), and mmap() file access go through the page cache. File data gets cached in kernel-managed page cache first, and either gets copied to a user buffer (read()), copied from a user buffer (write()), or mapped directly into the process (mmap()). This is buffered I/O , and it is the normal path.
  
  There is another option: open a file with O_DIRECT. This asks the kernel to transfer file data directly between the storage stack and your user-space buffer, bypassing the normal page-cache data path. This sounds appealing for cases when you want to avoid kernel managed page-cache and have a caching layer in the application itself. But it comes with its own constraints. The buffer address, I/O length, and file offset often need to satisfy filesystem/device alignment requirements, commonly 512 bytes or 4 KB, though the exact rules vary.
  
  The reason anyone uses O_DIRECT is control. Database engines are a famous example that commonly use this. These systems do sequential scan of data while processing queries. When using buffered I/O, the page cache gets filled with intermediate data that the database engine is not going to need in the near future, but this may result in the eviction of the useful pages the database may need soon. To gain control of over this, databases implement their own buffer pools in user space, and disable the use of page cache via direct I/O.
  
  The tradeoff with using direct I/O is that you bypass the page-cache machinery that normally provides readahead, dirty-page buffering/writeback, and shared cached file pages between processes. You are now responsible for your own buffering, I/O sizing, alignment, and scheduling strategy. For most applications, buffered I/O is the right choice. O_DIRECT is a tool for workloads that already implement their own caching and need tighter control over the kernel's caching behavior.
  
  I publish many of these deep dives for free so they can reach as many programmers as possible. Paid subscribers make that possible. If this article is helping you, consider supporting the publication.
  
  Anonymous, File-Backed, and Shared Memory
  
  Alloca now understands that some pages come from files and some pages come from nowhere at all, beginning life as zero-filled frames. But she is still missing a vocabulary for the different kinds of memory she has been using.
  
  Alloca : "I keep hearing different names for memory: anonymous memory, file-backed memory, shared memory. Are these different mechanisms, or just different names for pages?"
  
  Kernel : "They are categories of mappings. Let me explain this to you systematically."
  
  Alloca : "Sure!"
  
  Kernel : "By now you must have understood that VMA is a key structure behind how I manage virtual memory. Now, every VMA tells me two things about the mappings: where does the data come from, and who can observe writes to it?"
  
  Alloca : "Let's start with where the data comes from."
  
  Kernel : "There are two possibilities. The data can either come from a file, like when you mmap a file, and that results in what I call as file- backed mappings. The second possibility is that the data is from anonymous memory with no file backing it. For example, your heap and your stack regions are anonymous. You can allocate anonymous memory using mmap as well by using the MAP_ANONYMOUS flag."
  
  Alloca : "Understood. What is the second thing the VMA tells you?"
  
  Kernel : "It tells me about who can observe writes to that mapping. A mapping can be private or shared. With a private mapping, your writes are yours alone. If the mapping began from a file, your first write usually triggers copy-on-write and creates an anonymous private page. The file is unchanged. With a shared mapping, multiple processes can map the same underlying object and observe each other's writes through those mappings."
  
  Alloca : "So file-backed versus anonymous tells us where the contents come from, and private versus shared tells us who sees writes."
  
  Kernel : "Exactly."
  
  Figure 11: Virtual memory mappings can be understood along two independent axes: where the contents come from, either anonymous memory or a file, and who can observe writes, either only the current process or other processes sharing the same mapping.
  
  Key Takeaway
  
  Virtual memory mappings can be classified along two axes:
  - Anonymous memory : Memory with no ordinary file behind it. Heap, stack, and MAP_ANONYMOUS mappings are common examples. New anonymous pages are zero-filled on first touch. If modified anonymous pages must be evicted, they need swap because there is no file to reload them from.
  - File-backed memory : Memory whose contents come from a file. Executable code, shared libraries, and file mappings are examples. Clean file-backed pages can be dropped and later reloaded from the file. Dirty file-backed pages must be written back before reclaim.
  - Private mappings : Writes are private to the process. A private file mapping can initially share clean file pages, but the first write creates an anonymous copy through COW.
  - Shared mappings : Writes are visible to other processes mapping the same object. MAP_SHARED and POSIX shared memory use this model.
  Aside: tmpfs: the file-anonymous hybrid
  
  "Shared memory" as people commonly use the term (POSIX shared memory via shm_open, System V shared memory, /dev/shm) is a distinct concept from the shared mapping we just discussed. A shared mapping is simply one where writes are visible to other mappers. These shared memory APIs are higher-level mechanisms built on top of that idea; under the hood, they are typically backed by tmpfs.
  
  tmpfs is a filesystem whose contents live entirely in memory and swap rather than on a persistent disk. A tmpfs file looks and behaves like an ordinary file: you can open(), mmap(), or fstat() it, but there is no disk backing it. If the system reboots, the contents are gone.
  
  From a reclaim perspective, tmpfs pages behave more like anonymous memory than disk-backed file cache: they have no persistent disk file to reload from, so evicted dirty tmpfs pages go to swap. Internally, they still live in the page cache and are managed through the VFS like ordinary files, which is what makes the familiar file API work. This makes tmpfs useful as a fast inter-process communication channel: two processes can map the same file from /dev/shm with MAP_SHARED and share the same physical frames, while still using the ordinary file API.
  
  Page Reclaim: How the Kernel Chooses What to Evict
  
  Alloca has now seen swap and file-backed mappings, but she has only been told the simple version: when memory runs out, the kernel evicts something old. She wants to know how that choice is made.
  
  Alloca : "When physical memory fills up, you said you pick a page that hasn't been accessed recently. But how do you know that a page hasn't been used in the recent past?"
  
  Kernel : "I maintain a list of physical frames organized by how recently they appear to have been used. These are the LRU lists (least recently used). I simply scan these lists, starting from the coldest end and find a candidate page that can be evicted."
  
  Alloca : "But the question remains: how are these lists created and updated? Do you monitor each memory access to continuously update these lists?"
  
  Kernel : "Watching every access in software would be impossibly expensive. So I rely on hardware's help. Every page table entry has an accessed bit, which is there to indicate if a page was accessed. When the MMU performs a page table walk and uses a PTE to translate an address, it sets that bit automatically in that PTE. I don't have to trap the access, I just come along later and look at what the hardware recorded."
  
  Alloca : "How does that work in practice? The MMU is setting the accessed bit in the page table entries, but you need to maintain and update LRU lists of frames. Do you actively go through all the page table entries of all processes and update the LRU lists?"
  
  Kernel : "That would be just as expensive. Imagine iterating every virtual page of every running process on every reclaim cycle, you'd spend more time on bookkeeping than anything else. I take the opposite approach. I scan the LRU list from the coldest end, check the page table entries mapping to it and see if the accessed bit is set or not."
  
  Alloca : "How do you find out which PTEs map to a frame?"
  
  Kernel : "That's where reverse mappings come in, usually called rmap. The page table is a forward map: virtual address -> physical frame. I also maintain the reverse: metadata attached to each physical frame that lets me find the VMAs and page table entries that currently map it. When I want to check whether a frame is warm, I follow its rmap to the relevant PTEs, and check the accessed bits."
  
  Alloca : "Ah, I was not aware that you also maintain reverse mappings. But I still don't understand how all of this works together? You've given me pieces of the puzzle but the full picture is not clear."
  
  Kernel : "The confusion is understandable. Let's connect everything together. When I have to reclaim memory, I start by scanning the coldest set of frames from the LRU list. Then I use the rmap to check the accessed bit of the pages mapping to those frames. If a frame's accessed bit is not set, then it is a candidate for reclaim."
  
  Alloca : "And what if the accessed bit was set?"
  
  Kernel : "Then things become interesting. If a frame's accessed bit is set, it could mean that it has been accessed tens or hundreds of times, but it could also mean that it was accessed once since then it has gone cold. So, for such frames, I unset their accessed bit to give them a second chance. If the frame is scanned again later and the bit is still clear, then that is stronger evidence that it has gone cold."
  
  Aside: Thekswapddaemon
  
  Normally, Linux runs a background thread called kswapd that watches free- memory watermarks. When free memory drops below a threshold, kswapd wakes up and starts reclaiming pages before the situation becomes urgent.
  
  If background reclaim cannot keep up, the allocating process may have to wait for reclaim. This is called direct reclaim, and it can show up as allocation latency in the application.
  
  Alloca : "And, how are the LRU lists structured? You said you start from the coldest end, how do pages age toward that end?"
  
  Kernel : "Although things are a bit more complex, I will simplify for you. Think of two lists: active and inactive , each having a head (newest) and a tail (oldest). When a new page is faulted in, it typically starts near the head of the inactive list. Over time, pages age toward the tail as newer pages push them back, or when colder pages get reclaimed."
  
  Alloca : "But if all the newly faulted pages start from the head of the inactive list, how does a page get promoted to the active list?"
  
  Kernel : "A page that consistently shows its accessed bit set across multiple reclaim scans is promoted to the active list because it has demonstrated sustained use. From there, it ages toward the active tail again. When the active list grows too large, its tail pages are demoted back to the head of the inactive list. So the flow is: inactive tail is where eviction happens, active tail is where demotion back to inactive happens. Pages circulate through this cycle, and only those that consistently fail to show any access get evicted."
  
  Aside: Multigenerational LRU (MGLRU)
  
  The active/inactive model works, but two buckets is a coarse instrument. The fundamental limitation is that it preserves only coarse aging information: it can tell that a page looked recently referenced at scan time, but it does not maintain a rich multi-step history of how its temperature changed over time. A page accessed ten thousand times since promotion looks effectively the same as one accessed once; a page that was hot for ages but cooled recently looks the same as one that was never warm. Under workloads with mixed access frequencies, periodic re-access patterns, or bursty I/O, this can lead to evicting pages that will soon be needed or retaining pages that will not.
  
  MGLRU (multi-generational LRU) addresses the root cause by giving the kernel more expressive age information. Instead of two lists, pages are grouped into several generations , each representing a time window of access activity. Pages start in the youngest generation when first faulted or accessed. Without re-access they age into older generations; with re-access they are refreshed back into a younger one. Reclaim always targets the oldest generation first. With more age buckets, the cooling curve of a page becomes observable over time, allowing the kernel to make finer, more informed eviction decisions.
  
  MGLRU was introduced in Linux 6.1. The build config option CONFIG_LRU_GEN=y includes the code and CONFIG_LRU_GEN_ENABLED=y enables it by default. When compiled in, /sys/kernel/mm/lru_gen/enabled controls it at runtime. Systems without it fall back to the classic active/inactive lists.
  
  Alloca : "So the lists tell you which pages are cold. But once you've found a cold page, does it matter what kind of page it is? Is every cold page equally easy to evict?"
  
  Kernel : "Not at all. The first split is file-backed versus anonymous. Clean file-backed pages are the easiest. If a page cache page matches the file on disk, I can drop it immediately and reuse the frame. The next access will fault and read it back from the file."
  
  Alloca : "What about dirty file-backed pages?"
  
  Kernel : "Those need writeback. If a process wrote through write() or MAP_SHARED, the page cache page may be dirty. Before I can reclaim that frame, I need to schedule I/O to write the contents back to the filesystem. After writeback completes, the page becomes clean and cheap to drop. A MAP_PRIVATE write is different: the first write produces a private anonymous copy via COW. That copy has no file behind it, so there is no persistent home to reload from. To reclaim it safely I must write it to swap, same as any other anonymous page with real data in it."
  
  Alloca : "So under memory pressure, file cache tends to be easier to reclaim than heap memory."
  
  Kernel : "Often, yes, especially clean file cache. This is why free memory can look low while the system is healthy: much of RAM may be used as page cache, and clean cache can be reclaimed quickly when applications need memory. The dangerous case is when the active working sets of processes exceed RAM. Then I have to reclaim pages that will soon be needed again, and the system can start thrashing."
  
  Alloca : "Thrashing means constantly evicting and faulting the same pages back in?"
  
  Kernel : "Right. The CPU spends more time waiting for page faults and disk I/O than doing useful work. At that point, virtual memory's illusion of abundant memory has become too expensive to maintain."
  
  Key Takeaway
  
  Page reclaim is the kernel's mechanism for freeing physical frames under memory pressure. It is approximate, not perfect LRU. Two complementary mechanisms make it practical without being prohibitively expensive:
  - Accessed bits : Every page table entry has a hardware-maintained accessed bit that the MMU sets automatically when the CPU uses that mapping. The kernel reads and clears these bits periodically to estimate recency without trapping every memory access.
  - Reverse mappings (rmap) : The page table is a forward map (virtual -> physical). The kernel also maintains the reverse: metadata on each physical frame that lets it find the VMAs and page table entries that map it. Reclaim uses rmap to check accessed bits on candidate frames only, without scanning every process's page table. This means reclaim starts from lists of physical frames, not from virtual address spaces, so the cost scales with the number of frames under consideration, not with the total size of all processes' virtual memory.
  Active/inactive LRU : Pages move between active and inactive lists. In Linux, these are split further into anonymous and file-backed LRUs, maintained per memory- management domain. New pages generally enter as inactive candidates. Pages age toward the tail as newer pages arrive. Reclaim scans from the tail of inactive , checking accessed bits via rmap for mapped pages:
  - Accessed bit set means that the page was recently used; clear the bit to give it a reprieve.
  - Accessed bit clear means that the page is cold; evict it.
  Pages that are consistently accessed get promoted to the active list. When the active list grows too large, its tail pages are demoted back to the head of inactive. Pages cycle through this until they consistently fail to show any access.
  
  MGLRU (multi-generational LRU) extends this with several age generations instead of two lists, allowing finer-grained decisions about what is truly cold.
  
  The reclaim cost also depends heavily on page type:
  
  Clean file-backed page : cheapest. Drop it immediately; a future access reloads from the file.
  
  Dirty file-backed page : must be written back to storage before the frame can be reused.
  
  Anonymous page with private data : generally needs swap before reclaim, because there is no file to reload it from. Without swap configured, ordinary anonymous pages are much harder to reclaim.
  
  The practical consequence: "used memory" is not automatically bad. The RAM used for clean page cache is readily reclaimable. However, the real danger is when the combined hot working set of applications exceeds RAM, forcing the kernel to evict pages that will soon be needed again, causing thrashing.
  
  Memory Access Patterns and VM Performance
  
  Alloca has been running correctly for some time now. Her pages are backed, her TLB is warm, and demand paging has handled everything smoothly. But lately she 's noticed something odd: she has two data structures (a dense array and a hash table), each holding the same amount of data, both fitting entirely in RAM. When she scans through all elements in each, the array finishes in seconds. The hash table takes ten times longer.
  
  Alloca : "Same amount of data. Both in RAM. Page table entries for both are installed. Why is the hash table so much slower?"
  
  Kernel : "Because the virtual address space makes all memory look equally fast. It isn't. The cost of an access depends on how it interacts with the layers underneath: the TLB, the cache, the physical layout."
  
  Alloca : "Tell me what's different."
  
  Kernel : "When you scan the array, you move through virtual addresses in order. If the first element is at address 0x1000, and each element is 4 bytes, then the next is at 0x1004, then 0x1008, and so on. You stay within one 4 KB page for over a thousand consecutive accesses. Remember, the TLB caches completed virtual-to-physical translations, one entry per page. All those accesses within the same page reuse the same TLB entry, so they are fast. Then you cross into the next page and need one new entry. Only a small sliding window of TLB entries is active at any moment, and you reuse each one extensively before moving on. The TLB handles that easily."
  
  Alloca : "And with the hash table? I'm probing at random locations across the whole allocation."
  
  Kernel : "Yes, that's where the problem is. Hash table probes are spread across the entire allocation with no fixed order. You might touch page 47, then page 3, then page 201. The CPU has a limited hierarchy of TLBs, a small L1 TLB and a slightly larger second-level TLB. Together they may cover hundreds to a few thousand page translations depending on the CPU and page size. As your probe set fans out across many pages, the TLB hierarchy fills up. When it's full, a new translation evicts an old one. The trouble is that with no locality in your access pattern, the evicted translation is often the one you'll need again soon. By the time you revisit a page, its translation is likely gone, and the hardware may have to walk the page table again to rebuild it."
  
  Alloca : "So if a translation misses across the TLB hierarchy, the hardware has to do a page walk before I can even access the data?"
  
  Kernel : "Right. For random access across a large range, you can be spending significant overhead on translation for every byte you actually wanted. And TLB pressure isn't the only thing working against you. There's also the hardware prefetcher. When you access virtual addresses in a predictable pattern, the CPU detects it and starts fetching upcoming cache lines before you ask for them. For your array scan, you're reading 0x1000, 0x1004, 0x1008 in sequence, so the prefetcher loads the next cache lines ahead of time."
  
  Alloca : "But what if the next address crosses into the next virtual page?"
  
  Kernel : "Usually the hardware prefetchers are conservative around 4 KB page boundaries because crossing into the next page could cause a page fault or run into permission issues."
  
  Alloca : "Understood. Each array page holds over a thousand elements. So the prefetcher helps throughout each page, and the cost of crossing into the next is just one TLB lookup?"
  
  Kernel : "Correct. For your hash table, the random probes defeat the prefetcher even within a single page because there's no predictable pattern to detect. So the array wins twice: fewer distinct TLB entries needed, and hardware prefetching next set of cachelines."
  
  Alloca : "Is there anything else that affects this?"
  
  Kernel : "Yes, how often you revisit the same pages. If you keep accessing the same set of pages over and over, those pages stay hot. Their TLB entries stay cached, so you're not constantly rebuilding translations. And those physical frames stay in RAM because my reclaim policy notices they're being used frequently. I'm less likely to evict a page that's getting hammered than one that hasn't been touched in a while."
  
  Alloca : "So if my working set is small enough to fit in the TLB and I keep reusing it, I'm golden?"
  
  Kernel : "Exactly. A tight working set is cheap. But if your working set is sprawling across hundreds of thousands of pages that you only touch occasionally, you're constantly evicting TLB entries you'll need again soon. And under memory pressure, those infrequently-accessed pages become candidates for eviction to swap. Then you're not just paying for TLB misses, you're paying for disk I/O to bring pages back from swap."
  
  Alloca : "So the key is to touch fewer pages. Is there anything I can do to control this?"
  
  Kernel : "Absolutely. One thing that's often overlooked is how tightly you pack your data. The virtual memory system operates at page granularity, so anything that helps you fit more useful data into each page reduces the number of pages, translations, and TLB entries needed for the same logical work."
  
  Aside: Data layout also changes TLB footprint
  
  Compilers often pad structs to satisfy alignment requirements, but struct padding is not just a local layout detail. It also affects how much memory an array of those structs occupies, and therefore how many cache lines and pages the program touches.
  
  Suppose you have a struct with a char, then an 8-byte pointer, then another char. On a typical 64-bit system, the compiler may insert padding after the first char to align the pointer, and then more padding at the end so that each element in an array keeps the pointer correctly aligned. The result may be 24 bytes per struct, even though the actual fields occupy only 10 bytes.
  
  Across a million elements, that difference matters. A 24-byte layout occupies about 24 MB, while a more compact reordered layout may occupy about 16 MB. With 4 KB pages, the larger layout spans more pages. More pages means more TLB entries are needed to cover the same number of logical objects, more page- table walks when the TLB misses, and more memory that the kernel may have to manage under pressure.
  
  One common way to reduce padding is to order fields from larger alignment requirements to smaller ones: 8-byte fields first, then 4-byte fields, then 2-byte fields, then 1-byte fields. The compiler may still add tail padding, but usually less than when different-sized fields are interleaved randomly.
  
  Key Takeaway
  
  Virtual memory makes all addresses look the same, but they're not. The CPU has a limited TLB hierarchy, with small L1 TLBs backed by larger second-level TLBs. Together, they cover a limited number of translations, typically a few hundred to a few thousand, depending on the CPU and page size. Once your working set spans more pages than the TLB hierarchy can cover, translation misses become more common. Misses that hit in the second-level TLB are cheaper, but misses that require a hardware page walk can be expensive.
  
  How you access memory matters a lot. If you walk through an array sequentially, you stay within a small number of pages at any given time. You reuse the same TLB entries for thousands of accesses before moving to the next page. The hardware prefetcher can see the pattern and load upcoming data into cache before you ask for it (at least until you hit a page boundary, where it has to stop). That's why sequential scans are fast.
  
  Random access is a different story. When you jump around unpredictably, like probing a hash table, or chasing linked list pointers, you may land on different pages very frequently. As a result, you may face TLB misses for pages that are being visited for the first time, and also you risk evicting TLB entries you'll need again soon. The prefetcher can't predict where you're going next, so it doesn't help. In the worst case scenario, every access risks a TLB miss and a page walk.
  
  Temporal locality matters too. If you keep revisiting the same pages, they stay hot. Their translations stay cached in the TLB. The kernel is less likely to reclaim frequently used pages, because they tend to be recognized as part of the active working set. Under severe pressure, though, even useful pages can still be reclaimed. But if your working set is sprawling and you rarely touch the same page twice, you're constantly rebuilding translations and building up memory pressure.
  
  How you pack your data affects how many pages you touch. A poorly-designed struct with lots of padding might be twice the size of a well-packed one. If you have an array of a million structs, that can result in a difference of 6000 vs 3000 pages. Same logical work, but one version fits in the TLB and the other thrashes. Every byte you save per element multiplies across the whole working set: fewer cache lines, fewer pages, fewer translations, fewer page walks, and less memory pressure.
  
  The VM machinery works largely at page granularity while caches operate at cache-line granularity. Performance-conscious code thinks about how data is laid out in both cache lines and pages, how those pages fit in the TLB, and how access patterns interact with the translation machinery.
  
  Huge Pages and TLB Efficiency
  
  Alloca has redesigned her hash table. Better hash function, reduced load factor. She accepts that random access is unavoidable. But she is still spending too much time on TLB misses. For a 2 GB table with 4 KB pages, the math is unforgiving: half a million pages, and no TLB holds that many entries.
  
  Alloca : "I understand the TLB problem. My 2 GB table spans half a million 4 KB pages. The TLB can only hold a limited number of translations. I will always be missing. What can I do besides shrinking the data?"
  
  Kernel : "You can change the page size. The TLB has a fixed capacity, you can't change it. But what you can change is how much memory each entry covers. x86-64 supports huge pages with sizes 2 MB, and on many systems 1 GB pages as well. A single 2 MB TLB entry covers 512 times as much memory as a 4 KB entry. So your 2 GB hash table mapped with 2 MB pages needs only 1,024 TLB entries instead of half a million"
  
  Alloca : "That is dramatically fewer. But, how does this work with the page table hierarchy?"
  
  Kernel : "The page table walk has an early-exit mechanism when you use huge pages. Each page table entry has a set of flags embedded in its low bits. One of those flags is the page-size bit (PS) which tells the hardware: 'stop here, this entry points directly at a physical frame, not at another table.' For a normal 4 KB mapping, the PMD entry points to a PTE table, and the walk continues. But when the PS bit is set on the PMD entry instead, the hardware treats the PMD entry itself as the final frame mapping, covering 2 MB at once. It skips the PTE level entirely. The 21 low- order bits of the virtual address become the offset within the 2 MB frame instead of requiring a further table lookup. Similarly, if the PS bit is set on a PUD entry, the hardware stops there and maps 1 GB directly, skipping both the PMD and PTE levels."
  
  Figure 12: Huge page early-exit paths through the page table hierarchy. A normal 4 KB access walks all four levels. A 2 MB huge page stops at the PMD level (the PMD entry has the page-size flag set); the lower 21 bits of the virtual address become the offset within the 2 MB page, so no PTE lookup is needed. A 1 GB huge page stops at the PUD level; the lower 30 bits become the offset within the 1 GB page.
  
  Alloca : "Fewer levels in the walk, fewer TLB entries needed. What is the catch?"
  
  Kernel : "Physical contiguity. A 2 MB huge page needs 512 physically contiguous 4 KB frames, and the starting address has to be aligned to a 2 MB boundary. For a regular 4 KB page, I can grab any single free frame from anywhere in physical memory. It's easy. But for a huge page, I need to find a 2 MB-aligned block where all 512 frames are sitting right next to each other, and they all have to be free at the same time. After the system has been running for a while, physical memory gets fragmented. Small allocations come and go, leaving little gaps everywhere. Finding a big contiguous block with the right alignment gets harder and harder. I can try compaction, where I migrate pages around to assemble larger free ranges, but there's no guarantee it'll work."
  
  Alloca : "So huge pages are generally easier to get on a fresh system and harder as long-running workloads fragment memory?"
  
  Kernel : "That's the usual pattern, yes. So how do you get them reliably? One answer is to reserve a pool upfront, ideally at boot before memory has had a chance to fragment. You set vm.nr_hugepages, I carve out that many huge pages and hold them aside. They're always contiguous, always aligned, always ready. When you ask for one, I hand it out instantly. The catch: that memory stays off-limits for anything else for as long as it's in the pool, even when nothing is using it."
  
  Alloca : "And if I don't want to lock memory away like that?"
  
  Kernel : "That's where Transparent Huge Pages, or THP, comes in. THP tries to give you huge pages without a dedicated pool. Sometimes I can allocate one directly when you first fault a region. Other times, a background daemon called khugepaged scans your anonymous mappings and collapses a 2 MB- aligned range of base pages into a single huge page after the fact. Your mapping gets upgraded silently, no code changes needed."
  
  Alloca : "So THP might help and might not, and I have no guarantee which I got."
  
  Kernel : "Right. It's opportunistic. It runs into the same fragmentation problem I described earlier, finding a 2 MB-aligned contiguous block on a system that's been running for a while is not always possible. If the block isn't there, nothing happens and you stay on base pages. The other risk is that THP may try to create that contiguous block by running compaction first, migrating pages around to free up the space. Compaction is expensive and can cause latency spikes, which is why some latency-sensitive systems disable THP entirely. For predictable huge page coverage, like a database buffer pool, a large in-memory cache, anything where sudden jitter is unacceptable, you're better off reserving the pool explicitly at boot."
  
  Key Takeaway
  
  On x86-64, the base page size is 4 KB, but the architecture also supports larger leaf mappings: 2 MB pages (a PMD-level leaf entry, skipping the PTE table), and on systems with appropriate hardware support, 1 GB pages (a PUD-level leaf entry, skipping both PMD and PTE levels). Each covers correspondingly more memory per TLB entry and requires fewer levels in the page table walk on a TLB miss.
  
  The key constraint is physical contiguity: a 2 MB huge page requires 512 physically contiguous, correctly aligned frames. Physical memory fragmentation, which accumulates over time as the system allocates and frees memory of different sizes, makes this progressively harder to satisfy.
  
  Linux provides two mechanisms:
  - Explicit huge pages (configured via vm.nr_hugepages or at boot): drawn from a dedicated HugeTLB pool. Reserving them at boot is the most reliable way to avoid fragmentation. Memory in the pool is reserved for HugeTLB use while it remains there, i.e., it cannot be used as ordinary pages, but the pool size can be reduced later to release pages back, subject to fragmentation.
  - Transparent Huge Pages (THP) : opportunistic huge-page backing for ordinary mappings, especially anonymous memory, either through fault-time huge-page allocation or later background collapse by khugepaged. Falls back to base pages when a suitable huge page cannot be allocated or assembled; depending on THP settings, the attempt itself may trigger compaction and latency spikes.
  For latency-sensitive workloads with large, frequently-accessed memory regions, explicit huge pages provide the reliable TLB reduction that THP cannot guarantee. The trade-off is granularity: larger pages reduce translation overhead but can waste memory and are harder for the kernel to allocate.
  
  TLB Shootdowns on Multi-Core Systems
  
  Alloca has spawned dozens of worker threads. They 're distributed across the machine's cores, all working in parallel. Everything runs smoothly until she decides to release a large memory mapping she no longer needs.
  
  Alloca : "I used mmap earlier to create a large shared memory region. Now I'm done with it. How do I give it back?"
  
  Kernel : "You call munmap. It's the counterpart to mmap. You pass the starting virtual address and the length, and I clean up the range: the VMAs are removed, the page-table entries are cleared. Physical pages that nothing else is pointing to get released back to wherever they came from."
  
  Alloca : "That sounds straightforward."
  
  Kernel : "It would be, if you were running on a single core. But you're not. You have dozens of threads running in parallel across multiple CPU cores. And, every core carries its own private TLB."
  
  Alloca : "Wait, they don't share a single TLB?"
  
  Kernel : "No. Every core keeps its own private cache of recent translations. On a multi-core machine, when your thread accesses memory, the MMU on that specific core checks that core 's TLB. If it misses, the page walk happens, and the result gets cached in that core's TLB. Other cores don't see that entry unless they independently translate the same address and cache it themselves."
  
  Alloca : "So if thread A on core 0 and thread B on core 1 both access the same virtual address, they each have their own TLB entry for it?"
  
  Kernel : "Exactly. Both cores translate the same virtual address to the same physical frame, but they cache that translation independently. This per-core design is essential for performance, sharing a single TLB across dozens of cores would create a massive bottleneck. But it creates a consistency problem when page tables change."
  
  Alloca : "What kind of problem?"
  
  Kernel : "Think about what happens when you call munmap. You're on core 0. I clear the PTEs for the region you're releasing. But cores 1, 2, 3… they might still have cached translations for pages in that region. Those TLB entries now point to frames that you just gave back to me."
  
  Alloca : "And you might reassign those frames to someone else immediately."
  
  Kernel : "Yes. Without explicitly invalidating those cached translations, a CPU could keep using a stale translation after I have decided the mapping is gone. If the underlying page were later reused for something else, that would be a disaster. I cannot allow that to happen."
  
  Alloca : "So before munmap finishes, you need to make sure every core's TLB is consistent with the cleared page table?"
  
  Kernel : "Yes. And that's expensive."
  
  Alloca : "How do you do it?"
  
  Kernel : "I send inter-processor interrupts (IPIs), to every CPU core that might hold stale translations for this address space. When a core receives the IPI, it stops what it's doing, runs a short TLB flush routine to invalidate the affected entries, and sends an acknowledgment back. I wait for all cores to acknowledge before I let your munmap call complete. This is called a TLB shootdown."
  
  Aside: What is an inter-processor interrupt?
  
  Modern CPUs have a hardware mechanism called the APIC (Advanced Programmable Interrupt Controller) that lets one CPU core send an interrupt directly to another. This is an inter-processor interrupt , or IPI. Unlike a regular device interrupt, which is triggered by external hardware (a disk, a network card), an IPI is sent by software running on one core to deliberately interrupt a different core.
  
  When a core receives an IPI, it stops whatever it was doing, saves its state, and jumps to a an interrupt handler. For TLB shootdowns, that handler executes instructions to invalidate the stale TLB entries, then signals acknowledgment and returns to the interrupted work. The sending core waits until all targeted cores have acknowledged before proceeding.
  
  This mechanism is general-purpose. The kernel uses IPIs for TLB shootdowns, but also for things like delivering signals across cores, triggering scheduler reschedules, and stopping cores for kernel panics or suspend.
  
  Alloca : "Every core has to stop and flush, even if they're in the middle of something?"
  
  Kernel : "Yes, if they might have cached translations for your address space. If a core has never run any of your threads, I can skip it. But if a thread has been running on a core recently, that core's TLB might still hold entries for your address space. I send the IPI, that core stops, flushes the relevant entries, and I wait for it to confirm before letting your munmap complete. So, you're waiting for cross-core synchronization."
  
  Alloca : "That's why it takes so long. The more cores, the more coordination required."
  
  Kernel : "Precisely. On a large machine, a single munmap can involve many cores being interrupted and synchronized. The cost tends to grow with the number of relevant cores, and it also depends on how I choose to invalidate the affected range, whether I flush individual pages or do a broader flush."
  
  Alloca : "When else does this happen?"
  
  Kernel : "Anywhere I have to change or remove page-table entries that other CPUs might already have cached. mprotect is the obvious case: you change permissions, and the translation that other cores have cached is now wrong. The same thing happens during page reclaim and migration, when I unmap pages to move or free them. Copy-on-write faults in a multithreaded process can trigger it too, since other threads on other cores might have the old read-only translation cached. The more frequently these happen in a tight loop, the more cross-core coordination overhead you're paying."
  
  Alloca : "So freeing memory and changing mappings or permissions can force expensive cross-core coordination on large machines."
  
  Kernel : "In the worst case, yes. The general principle is that page- table changes are not just local bookkeeping. On a multi-core machine, they can force cross-core synchronization before the operation is complete."
  
  Key Takeaway
  
  On a multi-core machine, each CPU core has its own TLB. This per-core design is essential for scalability, a shared TLB would be a massive bottleneck with dozens of cores competing for access. But it creates a consistency challenge: when the kernel modifies page table entries, other cores may still have cached the old translations.
  
  munmap is the system call that releases a mapping created by mmap. Allocators may also reduce the process heap with brk/sbrk or return large mmap allocations with munmap, but the common issue is the same: page table entries for a virtual address range are removed or changed. Clearing the page table isn't enough. If another core still has a stale TLB entry pointing to a frame that has just been freed and potentially reassigned to another process, that core could access memory it shouldn't, violating isolation.
  
  The fix is a TLB shootdown : the kernel sends inter-processor interrupts (IPIs) to all CPUs that might hold stale mappings for that address space. Each interrupted CPU flushes the relevant TLB entries. For synchronous invalidations, the operation cannot safely complete until the targeted CPUs have performed the required flush. This forces cross-core synchronization before the operation can proceed.
  
  Shootdown cost tends to grow with the number of targeted CPUs and with how disruptive the chosen flush strategy is. On x86, the kernel may invalidate individual pages or choose a broader TLB flush; the choice depends on the size of the range and the cost of flushing unrelated entries. On machines with many cores, munmap and mprotect on large regions can become significant bottlenecks.
  
  TLB shootdowns arise whenever page-table mappings are modified: mprotect (permission changes), page reclaim and migration (unmapping pages to move or free them), and copy-on-write faults in multithreaded processes
  
  The practical implication is to minimize page table invalidations in hot paths. High-performance allocators reduce munmap frequency by caching freed memory and batching OS returns. In hot paths, prefer reusing large, longer- lived mappings over repeatedly creating, protecting, unprotecting, and destroying small mappings.
  
  Articles like this are expensive in time, but worth writing when readers support them.
  
  NUMA (Non-Uniform Memory Access): The Physical Topology of Memory
  
  Alloca has been running smoothly. Her pages are backed by huge pages where possible, her working set fits comfortably in the TLB, and her threads coordinate to minimize expensive operations likemunmap . She has dozens of worker threads, each processing data from a shared buffer in memory.
  
  But something is wrong. She 's noticing a strange inconsistency: some of her threads complete their work quickly. Others, doing exactly the same computation on the same amount of data, take much longer. It's not occasional, it's consistent. Threads 0-23 are fast. Threads 24-47 are slow.
  
  Alloca : "I don't understand. Half of my threads are stuck waiting for memory while the other half run at full speed. They're all doing the same work, accessing the same buffer. Why would memory be fast for some threads and slow for others?"
  
  Kernel : "Come with me. I want to show you something about the physical machine underneath your address space."
  
  Kernel leads Alloca to a view she has never been shown before, not the virtual address space, but the physical hardware topology beneath it.
  
  Figure 13: NUMA topology showing two CPU sockets, each with local memory. In this simplified model, each socket corresponds to one NUMA node, but real machines, particularly AMD EPYC systems, may expose more than one NUMA node per socket. Alloca 's buffer was initialized by a thread on Socket 0, so all physical frames landed on NUMA Node 0. Threads 0-23 running on Socket 0 get fast local DRAM access. Threads 24-47 running on Socket 1 must have their cache misses served from Node 0, crossing the inter-socket interconnect. Local DRAM latency is typically around ~100ns; remote DRAM access is often 1.5-3× higher, though exact numbers vary by CPU generation, memory speed, and system topology.
  
  Kernel : "This server has two CPU sockets. Each socket has its own pool of RAM wired directly to it. When a CPU on socket 0 reads from memory attached to socket 0, it's a short trip, maybe 100 nanoseconds. Fast."
  
  Alloca : "And what about reading from the other socket's memory?"
  
  Kernel : "That's where the problem appears. Socket 0 and socket 1 are connected by an inter-socket link. When a CPU on socket 0 needs data from memory attached to socket 1, the request must cross that link. Round trip takes two to three times longer."
  
  Alloca : "But my virtual address space… it's just a flat range of addresses. How would I even know which memory is on which socket?"
  
  Kernel : "You don't. That's the problem. Your virtual addresses are completely abstract. Address 0x10000 and address 0x20000 look identical to you. But behind the scenes, one might map to a physical frame on socket 0, and the other to a frame on socket 1. The virtual memory system hides that completely."
  
  Alloca : "So the physical location of my data determines performance, but I have no control over it?"
  
  Kernel : "You do have control, but it's indirect. The key moment is when a page is first accessed. Remember demand paging? When you touch a page for the first time, I have to allocate a physical frame for it. At that moment, I need to decide which NUMA node to allocate from."
  
  Alloca : "How do you decide?"
  
  Kernel : "By default, I use what's called first-touch placement. Whichever CPU core triggers the page fault gets to decide. I allocate the frame from that core's local NUMA node. So if your thread running on core 5 (which is on socket 0) is the first to touch a page, that page's frame lands on socket 0's memory pool."
  
  Alloca : "Okay, so the first thread to touch a page determines where it lives physically."
  
  Kernel : "Yes. Now think about what probably happened with your buffer. You likely had one thread, maybe your main thread that initialized the buffer. That thread touched every page in sequence, probably while running on socket 0. Every single page fault was handled by a CPU on socket 0, so every single frame landed on socket 0's memory."
  
  Alloca : "And then I handed that buffer to all my worker threads?"
  
  Kernel : "Right. And those threads are distributed across both sockets. Threads 0 through 23 run on socket 0, when they access the buffer, the memory is local, everything is fast. But threads 24 through 47 run on socket 1. Any cache miss they take resolves as a DRAM fetch, and that DRAM is on the wrong socket, the access has to cross the inter-socket interconnect. That's typically two to three times the latency of a local DRAM fetch."
  
  Alloca : "That explains the performance split perfectly. So the thread that initializes the data and the threads that use it need to be on the same socket?"
  
  Kernel : "That's one solution. For partitioned data where each thread works on its own section, you can have each thread initialize its own portion while pinned to the socket where it'll do the work. The first-touch policy ensures the data lands locally."
  
  Alloca : "What if the data is shared? All my threads are reading the same buffer."
  
  Kernel : "Then you have a harder problem. No matter where you put the data, it's local for some threads and remote for others. One approach is to use explicit NUMA policies. The mbind system call lets you control allocation policy for a specific virtual address range."
  
  Alloca : "What can I do with it?"
  
  Kernel : "Several things. You can bind a range to a specific NUMA node, force all its pages onto one socket's memory. You can set a preferred node that's tried first but allows fallback. Or you can interleave pages across nodes, where consecutive pages alternate between socket 0 and socket 1."
  
  Alloca : "Why would I want to interleave?"
  
  Kernel : "Interleaving is useful for heavily shared data with high bandwidth demand. Think about it, if all your threads are hammering the same memory range, putting it all on one socket creates a bottleneck, all the traffic goes through one memory controller. With interleaving, each socket sees a mix of local and remote pages when scanning the range, but the bandwidth demand is spread across both memory controllers rather than concentrating on one. You're trading some locality for better aggregate throughput."
  
  Alloca : "Understood. Is there also the possibility of the scheduler moving my threads between sockets after I've set everything up?"
  
  Kernel : "Yes, in that case your careful placement falls apart. If a thread that was running on socket 0 with local memory gets migrated to socket 1, then suddenly all its memory is remote. This is why NUMA-sensitive workloads typically pin threads to specific CPUs using taskset or pthread_setaffinity_np."
  
  Alloca : "So the typical pattern is: decide which threads work on which data, pin those threads to the appropriate socket's cores, and make sure the thread that first touches the data is running on the right socket so first- touch puts the frames locally."
  
  Kernel : "That's the basic approach for thread-private or partitioned data. For shared data, you either accept that some accesses will be remote, or you interleave to balance the load. There's no perfect solution when multiple sockets need heavy access to the same memory. You're always trading off between locality and bandwidth distribution."
  
  Aside: Automatic NUMA balancing
  
  Linux also provides automatic NUMA balancing, controlled via /proc/sys/kernel/numa_balancing. When enabled, the kernel periodically samples a task's memory by temporarily unmapping pages, or marking them so that the next access triggers a NUMA hinting fault. The fault lets the kernel record which CPU or NUMA node is actually accessing it. Based on those faults, the kernel may migrate pages toward the node that uses them, or move tasks closer to their memory. This can improve placement without code changes, though the sampling faults and migrations add overhead and are not guaranteed to help every workload.
  
  The downside is that it is reactive. It adapts after the fact rather than placing memory correctly from the start, and the sampling-induced faults add a small overhead. For workloads where latency consistency matters, deliberate placement with mbind and thread pinning is more reliable. For workloads where access patterns are hard to predict or partition, automatic balancing can be a reasonable hands-off alternative.
  
  Key Takeaway
  
  Modern multi-socket servers are NUMA (Non-Uniform Memory Access) systems. Physical memory is divided into NUMA nodes , each directly attached to one CPU socket. A CPU can access memory on any node, but local access is noticeably faster than remote access, which must traverse the inter-socket interconnect.
  
  The virtual address space hides this topology completely: two adjacent virtual pages may be backed by physical frames on different NUMA nodes. The NUMA node of a physical frame is primarily determined at allocation time by the kernel's memory policy.
  
  The kernel's default policy for anonymous memory is effectively first- touch : when a page is first faulted into a real physical frame, it is usually allocated from the NUMA node local to the CPU handling that fault. If initialization and hot access happen on different sockets, most DRAM accesses will pay remote latency.
  
  Strategies for NUMA-aware operation:
  - Initialize on the accessing socket : for partitioned data, the thread that will perform the hot accesses should also touch pages first, placing frames on the local node.
  - Thread pinning : bind threads to specific CPUs with taskset or pthread_setaffinity_np to prevent cross-socket migration.
  - mbind/set_mempolicy: per-range NUMA allocation policy in code.
  - numactl : command-line wrapper to set NUMA policy for an entire process.
  - Interleaving : for heavily shared data accessed across sockets, interleaving pages across nodes distributes bandwidth demand across multiple memory controllers. Each socket sees a mix of local and remote pages, but no single memory controller becomes a bottleneck.
  - Automatic NUMA balancing : the kernel can be configured to sample memory access patterns at runtime and migrate pages or tasks toward the nodes that use them most (/proc/sys/kernel/numa_balancing). It requires no code changes but is reactive rather than proactive, it adapts after observing bad placement rather than preventing it. For latency-sensitive workloads, deliberate placement is more reliable.
  For shared data accessed heavily by multiple sockets, no placement is perfect: the trade-off is between locality, bandwidth balance, and sometimes deliberate replication.
  
  For data-intensive workloads on multi-socket servers, NUMA is often the dominant source of unexplained memory latency once TLB and cache behavior have been addressed.
  
  Observing Virtual Memory in Practice
  
  Our journey through the virtual memory world with Alloca ends here. We have covered the machinery of the modern Linux kernel from first principles. For this final section, I will switch back to my normal voice and cover the observability and debugging tools that let you actually see what is happening in a running system.
  
  Understanding the mechanisms is one thing; knowing where to look when something goes wrong is another. Memory problems tend to disguise themselves. A process using more memory than expected, a workload that fits in RAM but still feels sluggish, a system that gradually slows down under load -- each of these points to a different layer of the VM stack. The tools below correspond to those layers. Work through them in order when you are unsure where the problem lives.
  
  Step 1: What address ranges does the process have?
  
  Before anything else, look at what the process has actually mapped. /proc/<pid>/maps lists every VMA: the virtual address range, the permissions (r, w, x, and p/s for private or shared), the offset into any backing file, and the file name if there is one. You can see the heap, the stack, the shared libraries, and any mmap regions all in one place.
  
  This is the reservation view. It tells you what address ranges exist and what they are allowed to do, but says nothing about how much physical memory is actually backing them. A region that looks large here might have almost no physical pages behind it, demand paging means pages are only allocated on first touch. pmap -x <pid> presents the same information in a slightly more readable table format.
  
  Step 2: How much physical memory is the process actually using?
  
  smaps is maps extended with a full accounting breakdown for every VMA. It tells us "what is actually in RAM." The key fields to understand:
  - Rss (Resident Set Size): how many kilobytes of that VMA are currently in physical RAM. Pages that have never been touched, clean file-backed pages that have been reclaimed, or anonymous pages that have been swapped out all contribute nothing here.
  - Pss (Proportional Set Size): like Rss, but shared pages are divided proportionally among all processes that map them. If ten processes share a 4 KB library page, each is charged 0.4 KB.
  - Private_Clean/Private_Dirty: pages private to this process that either still match their backing file (clean) or have been written to and diverged (dirty).
  - Shared_Clean/Shared_Dirty: pages shared with other processes. Clean shared pages, like read-only library code, are cheap to reclaim. Dirty shared pages need to be cleaned first: file-backed ones require writeback to disk, while shmem/tmpfs dirty pages go to swap instead.
  - AnonHugePages: how many bytes of this VMA are backed by transparent huge pages. If you want to verify that THP is actually working for a particular region, this is the field to check.
  For the system-wide picture, /proc/meminfo is the companion. The fields worth checking are MemAvailable (the kernel's estimate of how much can be freed without touching swap), Cached (page cache, most of which is reclaimable), Dirty and Writeback (pages queued for or actively being written back), AnonPages (anonymous pages currently in RAM), and the swap fields: SwapTotal, SwapFree.
  
  Step 3: Is the process triggering disk I/O through page faults?
  
  Page faults are the mechanism that connects virtual addresses to physical memory, and they come in two very different varieties.
  
  Minor faults (ru_minflt via getrusage) are resolved without any disk I/O. They involve a kernel trap and some bookkeeping, but no waiting for storage. A large number of minor faults during startup is perfectly normal.
  
  Major faults (ru_majflt via getrusage, or major-faults in perf stat) are a different story. These required actual disk I/O, either reading a cold file page from storage, or bringing a page back from swap. On spinning disks, a major fault can easily take several milliseconds; on NVMe it might be a few hundred microseconds. Either way, sustained major faults in a steady- state hot path are a warning sign. They usually point to swap pressure, uncached memory-mapped file I/O, or a working set that is competing with the rest of the system for physical memory.
  
  To measure fault counts for a single run:
```
perf stat -e page-faults,major-faults ./your-program
```
  page-faults counts total faults; minor faults are approximately the difference from major.
  
  Step 4: Is the whole system under memory pressure?
  
  Once you have the process-level picture, zoom out to see whether the kernel itself is struggling.
  
  vmstat 1 samples every second. The columns to watch are si and so (swap- in and swap-out in KiB per second). Nonzero so means the kernel is writing pages to swap because reclaim pressure has reached anonymous memory. Nonzero si means pages are being faulted back in. Both together at the same time is the classic thrashing pattern. The b column counts tasks currently blocked on I/O, which includes swap I/O.
  
  Pressure Stall Information (PSI) at /proc/pressure/memory gives a finer picture. It reports the fraction of time tasks spent stalled waiting for memory: some means at least one task was stalled; full means all non-idle tasks were stalled simultaneously, i.e., the system was making zero forward progress. A machine where the full metric is climbing steadily is one where memory has become a genuine bottleneck, not just busy, but actively blocking work from completing.
  
  Step 5: Is translation itself the bottleneck?
  
  TLB misses are almost entirely invisible to the kernel. The MMU handles them in hardware via page-table walks; the kernel only gets involved if the walk faults because the page isn't present. To observe TLB behavior you have to go to the hardware performance counters, which perf exposes.
```
perf stat -e dTLB-load-misses,dTLB-store-misses,iTLB-load-misses ./your-program
```
  dTLB-load-misses and dTLB-store-misses count data TLB misses on loads and stores respectively. iTLB-load-misses tracks instruction TLB misses, which matters when the code footprint is large or when working with JIT-compiled code. Note that the event names vary by CPU generation; perf list | grep -i tlb shows what your machine exposes.
  
  As we learned in the article, a high TLB miss count alone doesn't tell you much, what matters is whether those misses are triggering expensive page-table walks. A miss that hits the second-level TLB is relatively cheap, but the one that requires a full hardware page walk is not. For the actual walk cost, look for events like dtlb_load_misses.walk_active on Intel processors, which counts cycles spent actively walking page tables.
  
  High TLB miss rates combined with low major-fault counts (data is in RAM but translations are not cached) point to a working set that has outgrown the TLB hierarchy. The remedies are the ones covered earlier: huge pages to reduce the number of entries needed, or tighter data packing to reduce the number of distinct pages touched.
  
  Step 6: Are some threads slower than others on identical work?
  
  If some threads consistently take longer than others doing the same computation, and the disparity is stable rather than random, NUMA placement is the first thing to check.
  
  numactl --hardware shows the machine's NUMA topology: the number of nodes, memory per node, and the distance matrix between nodes. The distance matrix is a relative latency measure. This tells you the penalty being paid per remote access.
  
  numastat -p <pid> shows where a process's pages actually live. If the bulk of the pages are on node 0 but the threads doing the work are running on node 1, that is first-touch misalignment in practice. /proc/<pid>/numa_maps provides the same information per VMA, including which NUMA policy is in effect for each region and how many pages have landed on each node. It is verbose but precise when you need to understand why a specific mapping ended up where it did.
  
  Putting it together
  
  Virtual memory problems almost always start as a vague symptom. The right approach is to peel back layers in order rather than guessing:
  1. Is memory actually being used, or just reserved? Compare VMA size in maps to Rss in smaps. Large reserved-but-not-resident regions are normal (lazy allocation). Unexpectedly large Rss is the real signal.
  2. Is the process responsible for that memory, or is it shared? Compare Rss to Pss. If Rss is large but Pss is small, you're mostly mapping shared libraries or shared regions that other processes are also paying for.
  3. Is the process triggering frequent disk I/O through page faults? Check major fault count via perf stat or getrusage. Sustained major faults in a steady-state workload usually mean swap pressure, uncached mmap/file-backed I/O, or a working set that does not fit in available RAM or page cache.
  4. Is the system reclaiming memory aggressively? Check vmstat for swap-in/out activity and PSI for actual stall time. High si/so with high PSI full is a system in memory distress.
  5. Is translation overhead high even with data fully in RAM? Check TLB miss rates and page-walk cycles via perf stat. High miss rates with low fault counts point to a working set that has outgrown the TLB, a case for huge pages or tighter data packing.
  6. Are some threads consistently slower than others on the same work? Check NUMA placement via numastat -p and /proc/<pid>/numa_maps. Asymmetric slowness with equal work is a NUMA symptom, but confirm it against CPU placement, page placement, and other sources of per-core variation such as thermal throttling, IRQ affinity, or lock contention.
  Thanks for reading. This was one of the most ambitious pieces I've written for this publication. If you found it useful, consider becoming a paid subscriber or purchasing the PDF version. It directly supports more long-form systems writing. You can also purchase the PDF version of this article to support this work at this link.
  
  What We've Learned
  
  In this article, we explored virtual memory through a dialogue between the kernel and a user-space process named Alloca. Along the way, we covered a lot of ground: address spaces, page tables, TLBs, demand paging, memory types, page reclaim, copy-on-write, mmap, huge pages, TLB shootdowns, NUMA, observability, and more.
  
  Let's end this article with a summary of everything that we learned.
  
  Providing memory-level isolation is the foundational problem that virtual memory solves. Each process gets its own private set of virtual addresses, and the MMU enforces the boundaries between them. No process can directly read or write another's memory.
  
  Giving the address space structure is the next step. The virtual address space is divided into segments like code, data, heap, and stack, each with different permissions and growth behavior. Code is read-only and executable; the stack grows down on demand; the heap grows up through allocator requests.
  
  Mapping every byte to a physical location is impractical. A flat table covering the full 128 TB user address space would itself consume 256 GB. The solution is fixed-size pages and frames with hierarchical page tables: memory is divided into 4 KB chunks, any frame can back any page, and the page table hierarchy only allocates levels for address ranges actually in use.
  
  Walking four levels of page table on every memory access would be too slow. The TLB caches recent virtual-to-physical translations so that most accesses skip the walk entirely. Hit rate depends on access patterns and how tightly the working set fits within the number of TLB entries available.
  
  Allocating physical frames at malloc time wastes memory. Demand paging defers the allocation: when a process reserves memory, the kernel records the promise in a VMA but does not assign physical frames. Frames are allocated only on first access, when a page fault fires.
  
  Not all pages cost the same to evict. The kernel distinguishes anonymous memory (heap, stack, and MAP_ANONYMOUS regions), file-backed memory (executables, shared libraries, mmap'd files), and tmpfs-backed shared memory. Clean file-backed pages can be dropped immediately and reloaded from disk. Dirty file-backed pages must be written back first. Anonymous and tmpfs pages need swap space because there is no file to reload them from.
  
  Physical memory fills up. Page reclaim is the kernel's mechanism for freeing frames under pressure. It uses hardware-maintained accessed bits to estimate recency without trapping every access, reverse mappings (rmap) to find which page table entries point to a given frame, and active/inactive LRU lists to identify cold pages. The goal is to evict cold pages while keeping hot working sets in RAM. Evicting pages that will soon be needed again causes thrashing.
  
  Copying all of a process 's memory on fork is too slow. Copy-on-write shares physical frames between parent and child after fork. Pages are only copied when one side actually writes to them, tracked with per-frame reference counts. This makes fork nearly instantaneous regardless of address space size.
  
  File I/O through a user buffer requires an extra copy. mmap maps page cache frames directly into the process address space, allowing the process to read file data without a separate copy from kernel buffer to user buffer. Multiple processes mapping the same file share the same physical frames.
  
  Random access patterns scatter across too many pages. Sequential access reuses a small sliding window of TLB entries and benefits from reused cached translations and hardware prefetching in the cache. Random access, such as hash table probes, and pointer chasing, does not have the same guarantees and can suffer from unpredictable performance.
  
  Large working sets exhaust TLB capacity. Huge pages (2 MB or 1 GB on x86-64) can allow a single TLB entry to cover orders of magnitude more memory than a standard 4 KB page. The constraint is physical contiguity: huge pages require large, aligned, contiguous blocks of physical memory, which become harder to find as memory fragments over time.
  
  Unmapping pages on a multi-core machine requires cross-core coordination. Each CPU core has its own TLB. When the kernel removes or changes a page table mapping, other cores may still hold the old translation cached. A TLB shootdown sends inter-processor interrupts to all relevant cores, forcing them to flush stale entries before the operation can complete. This is why munmap and mprotect on large regions can be expensive on machines with many cores.
  
  Virtual memory hides the physical topology of memory. On multi-socket NUMA servers, physical memory is divided into nodes, each attached to one socket. Remote memory accesses (those that cross the inter-socket interconnect) are 1.5-3× slower than local ones. The virtual address space makes both look identical. Correct NUMA placement requires co-locating threads with their data and using first-touch initialization, thread pinning, or explicit mbind policies.
  
  Thanks for reading Confessions of a Code Addict! This post is public so feel free to share it.
  
  Share
2. 🔗 r/york Homestead park & museum gardens looking lovely today rss
  
  | submitted by /u/DentistKitchen
  [link] [comments]
  ---|---
3. 🔗 r/Yorkshire I built Kettlewell Manor House in Minecraft. rss
  
  | The house was built in the early 18th century, in the town of Kettlewell. submitted by /u/ILikeNiceBuildings
  [link] [comments]
  ---|---
4. 🔗 r/Leeds To all who came to cheer for the Marathon/Half-Marathoners - THANK YOU! rss
  
  Your encouragement pushed is all to the finish line!
  
  Extra thanks for those who came out with sweets/fruit/goodies - fuelling us all along the way.
  
  You're all superstars, thank you!
  
  submitted by /u/E45_Asthma_Cream
  [link] [comments]
5. 🔗 r/wiesbaden Pen&Paper-Treff am Pfingstmontag: 25.5., ab 17.30 Uhr rss
  
  Am 25.5., Pfingstmontag, findet wieder der offene Rollenspiel-Montag in der Phantasos Arena statt.
  
  Angeboten wird dieses mal Alien, KULT, Cthulhu, Candela Obscura und Cairn. Die Runden beginnen zwischen 17.30 und 18.30 Uhr, Details und Anmeldung gibt's auf Discord: https://discord.gg/hfB7WcRC4n
  
  Der Treff: Einmal im Monat spielen wir One-Shots, an denen alle teilnehmen können. Es sind keine Vorkenntnisse erforderlich, wir erklären alles vor Ort und freuen uns über neue Gesichter! Normalerweise finden 2-5 Runden parallel statt, und durch die Auswahl ist auch für erfahrene MitspielerInnen immer was spannendes dabei. Der Termin wird immer im Vormonat angekündigt.
  
  Location: Schossbergstraße 11, Wiesbaden-Schierstein, Bürogebäude in der 2. Reihe
  
  Anfahrt: Mit ÖPNV möglich, nachts muss man aber genau schauen, wann was fährt. Die Location befindet sich mitten in einem Gewerbegebiet, parken ist also kein Problem.
  
  Kosten, Material: Für die Nutzung der Räume wird um 5€ pro Person gebeten; wer sich das nicht leisten kann, ist aber ebenso willkommen (es handelt sich nicht um einen "Eintritt" und wird nicht kontrolliert). Snacks und Getränke können günstig vor Ort erworben oder mitgebracht werden. Stift und Notizzettel sollten mitgebracht werden, wer noch keine eigenen RPG-Würfel hat, kann sich welche ausleihen.
  
  submitted by /u/Bitter-Secretary6006
  [link] [comments]
6. 🔗 Jessitron What is it like to be you? rss
  
  This is what I want to know when I get to know someone. What is the experience of being alive in your body, in your world?
  
  This is the definition of consciousness: there is something it is like to be you.
  
  Erik Hoel contrasts this with LLMs, speculating
  
  there is nothing it is like to be two matrices multiplying.
  
  This is why humans can be responsible and accountable for things. Our actions have consequences that we can feel, that we can’t help but feel, for decades. What I do changes what it is like to be me. This is ongoing, inescapable.
  
  When we share experiences either by living them together or by telling stories, then there it is something it is like to be us. Connection.
7. 🔗 r/Leeds Moving out of Leeds city centre - what’s the best areas to live in Leeds for young professionals? rss
  
  Hi everyone,
  
  My partner and I are looking at moving out from city centre and would really appreciate some advice on the best areas to live for young professionals in our late 20s / early 30s.
  
  We’re looking for somewhere that’s:
  
  - relatively affordable
  - safe and nice to live in
  - has a good community feel
  - easy to meet people and make friends
  - with good access to the city centre and train stations for commuting
  
  At the moment we’re considering Chapel Allerton because it seems to have a great atmosphere and good transport links, but we’d love to hear honest opinions from people who actually live in Leeds.
  
  We’re also open to other areas if there are places with a similar vibe but maybe slightly better value.
  
  Any recommendations or advice would be massively appreciated — thanks!
  
  submitted by /u/cherryblossom0211
  [link] [comments]
8. 🔗 r/Harrogate Just joined Reddit — I make bespoke jewellery in Harrogate and couldn't resist finally joining this community rss
  
  | I run a small independent jewellery studio here in Harrogate and just joined Reddit — lovely to find this community! submitted by /u/FogalandBarnes
  [link] [comments]
  ---|---
9. 🔗 r/Leeds Why no development in the Trinity tower? rss
  
  We're staying on the top floor or the Park Plaza hotel for a wedding. We look out over Trinity and this tower block that rises above it. Every single floor is completely empty - no offices, no shops, no accommodation. Anyone know why? It seems such a waste of space in a prime position for either offices or city centre flats.
  
  submitted by /u/benbamboo
  [link] [comments]
10. 🔗 r/wiesbaden Schuhpflege rss
  
  Hat jemand eine Empfehlung in Wiesbaden, wo man (durchaus teure) Lederschuhe zur Pflege abgeben kann?
  Bin selbst leider auch Bach Jahren für alles was über die Basispflege hinausgeht zu doof.
  
  Danke
  
  submitted by /u/QuotaAchievingAnimal
  [link] [comments]
11. 🔗 r/Yorkshire Georgian Richmond Yorkshire rss
  
  | submitted by /u/Still_Function_5428
  [link] [comments]
  ---|---
12. 🔗 r/york I don’t think I’ll ever get tired of this city rss
  
  | submitted by /u/SavingsMap2506
  [link] [comments]
  ---|---
13. 🔗 r/york Minster rss
  
  | Another photo I’m deleting. Taken from the new road behind the NRM, early January. This view won’t be around much longer once they start building up York Central. submitted by /u/AttitudeAdjuster33-1
  [link] [comments]
  ---|---
14. 🔗 r/york Petergate rss
  
  | I’m just deleting some photos on my camera and this was on. The reason why I took it is because it was half past four in the afternoon on the 8th of January this year. Hardly a soul in sight.. it was like Covid had come back. submitted by /u/AttitudeAdjuster33-1
  [link] [comments]
  ---|---
15. 🔗 r/wiesbaden Was ist ein 'ungeschriebenes Gesetz' in Wiesbaden, das jeder Neu-Zugezogene an Tag 1 lernen muss? rss
  
  Eine gute Freundin von mir zieht bald aus den USA zu uns (und nope, nicht zur Army, ganz normaler Job in der Gegend). Wir haben gestern telefoniert und sie hat mich gefragt, was so die absoluten „ungeschriebenen Gesetze“ sind.. also die Dinge, die in keinem Reiseführer stehen, die man aber unbedingt wissen muss, um hier entspannt klarzukommen (oder um sich nicht direkt unbeliebt zu machen).
  
  Ehrlich gesagt stand ich total auf dem Schlauch 🤦. Kann hier jemand helfen?
  
  submitted by /u/LethisXia
  [link] [comments]
16. 🔗 Register Spill Joy & Curiosity #85 rss
  We launched a completely rebuilt Amp this week.
  
  Amp Neo (it started as a codename, but I've grown really fond of it) is remote controllable, supports plugins as a first-class feature, has compaction you don't have to worry about, and is a lot more efficient and faster than the old Amp.
  
  It is one of the most elaborate systems I've ever worked on. A coding agent split into three parts: the tools here, the interface there, and the loop in an infinitely scalable system over there.
  
  Some day I'll hopefully write about building it. I learned a lot about programming with agents in the last two months.
  
  We've spent the whole week scaling this system for the demand and are still working on it. "Scaling problems are good problems to have" definitely feels like a fortune cookie laughing at you when you're staring at graphs and logs every hour of the day.
  
  People love Neo and can't get enough of it. We're now the "ferrari of coding agents".
  
  But I also barely read anything this week except logs, so this edition of the newsletter is very short.
  - This is beautiful: "For thirty years I programmed with Phish on, every day. In 2026, the music is out of phase with the work." What a nice piece of writing and, man, this idea that some people find out early what they want and what's enough for them and know that it won't ever change has stuck with me: "Other kids my age were figuring out what they liked, trying things on, growing into and out of phases. I was watching them do it from a desk. I had picked early. I started writing code as a kid. I heard Phish for the first time at thirteen. By the time I was fifteen and had a professional gig, the picking was settled. I had two things, and I didn't want a third."
  - I somehow missed this earlier, but Aphyr's The Future of Everything is Lies, I Guess is now a series of articles. It's an epub too!
  - Alloway's Antidote To Baumol's Cost Disease. This was very interesting to throw into ChatGPT and ask questions about.
  - I love reading David Sedaris' writing and this week, after a very long day, after my brain had shut off, I read his newest piece in the New Yorker and smiled.
  - Six Years Perfecting Maps on watchOS. There's so many thoughts that come up when reading this today: will craftsmanship like this exist in the future? would AI have sped things up? was it worth it? how much impact did the real world experience and testing have? what would've happened had he hired the designer earlier? But the most important one: I love reading posts like this one.
  - Check the margins on bread.
  - AI is Breaking Two Vulnerability Cultures.
  - "As so often with German, there is a word for the kind of environment: Lehrwerkstatt. Literally: A teaching workshop. The whole shop floor is the classroom. You learn by being near the work. Being a constant learner is one of the core values of the firm."
  Also had to scale beloved coding agent this week? Subscribe here, my friend:
17. 🔗 modem-dev/hunk v0.11.1 release
  What's Changed
  - feat(config): auto-detect jj checkouts by @benvinegar in #264
  - fix(diff): skip huge file rendering by @benvinegar in #266
  - fix(loaders): restore a/b prefixes on noprefix patch input by @mo in #240
  - fix(loaders): normalize mnemonic pager prefixes by @benvinegar in #267
  - fix(ui): coalesce viewport listener via microtask to avoid setState loop by @aldevv in #242
  - fix(core): use header counts for hunkLineRange so context lines are in range by @aldevv in #244
  - fix(git): pass --no-ext-diff when diffing untracked files by @iamken1204 in #259
  - fix(ui): use full agent-note set for section geometry measurement by @aldevv in #243
  Full Changelog : v0.11.0...v0.11.1
May 09, 2026
1. 🔗 r/Leeds Travellers - King Alfred's Field, Stonegate Road rss
  
  Did the travellers move on to the fields today/yesterday? (9th May) Looks like a big group, likely the same ones that were on Meanwood Road a little while back?
  
  What's previous experience of them been like?
  
  submitted by /u/miamidolphin54
  [link] [comments]
2. 🔗 r/Harrogate Afternoon Tea Recommendations rss
  
  Hi everyone. Its my mums birthday next sunday (17th) and I'm miraculously child free, so I thought it would be the perfect time for us to go have a peaceful afternoon tea together to celebrate. I've been to Mama Doreens before but not for the afternoon tea (which does look incredible) do you think that would be the best place for us to go, or is there somewhere else just as good/better?
  
  submitted by /u/Chronic_Eyeroller_
  [link] [comments]
3. 🔗 r/Leeds Mexican food in Leeds rss
  
  Can someone recommend a Mexican place in Leeds (pref. City Centre) that does more than just tacos? Got a hankering for some good enchiladas... thanks!
  
  submitted by /u/notagain78
  [link] [comments]
4. 🔗 modem-dev/hunk v0.11.0 release
  What's Changed
  - Added vcs = "jj" support for hunk diff [revset] and hunk show [revset] by @clabby in #217
  - Added a pager-mode sidebar file tree toggle via s by @clabby in #216
  - Fixed git log -p and multi-commit git show -p parsing so commit metadata is ignored by @gonzaloserrano in #228
  - Fixed cross-file hunk navigation anchoring by @aliou in #222
  - Fixed the View menu sidebar checkmark to follow actual responsive sidebar visibility by @aliou in #236
  Full Changelog : v0.10.0...v0.11.0
5. 🔗 r/LocalLLaMA Apple Removes 256GB M3 Ultra Mac Studio Model From Online Store rss
  
  | Getting really worried about the m5 Ultra. From removing 512gb -> 256gb -> 96gb. submitted by /u/rotatingphasor
  [link] [comments]
  ---|---
6. 🔗 r/Leeds Why does the area around the bus station & market feel left behind in comparison to the rest of the city centre? rss
  
  Wasn't quite sure how to word the title without making it too lengthy!
  
  I used to work in the city centre going back 7-8 years but then moved elsewhere and since then I've rarely needed to go into town due to moving a fair distance away.
  
  I've recently landed a job back there however and noticed how much of the centre has been updated, cleaned and generally improved. Newly tarmacked roads, fresh pavements, new clean bus stands, new shop fronts & so on. Catching the bus on or near Infirmary Street or walking around that side really feels much cleaner and far better than what I remember.
  
  But then I get to the bus station & Leeds Market side (especially the area where the NCP Car Park & COOP are located) and it genuinely doesn't look or feel any better compared to 8-10 years ago.
  
  Its almost like a time warp going back a decade compared to a few roads away, especially considering the Victoria Quarter and that area has all been refurbished.
  
  It still feels very dirty & unsafe depending on the time of day, there's still plenty of crackheads & such hanging around at all hours similar to Trinity/Boar Lane, the pavement and roads are visually grimy - just baffles me considering how much work has gone into the centre everywhere else.
  
  submitted by /u/Carinwe_Lysa
  [link] [comments]
7. 🔗 r/wiesbaden Child outlet protectors rss
  
  Hi all,
  
  I’m on the hunt for some outlet covers/protectors. I’ve checked at Saturn and Media Markt with no luck. So I was curious if anyone had any ideas or knows where to get them? My son is obsessed with trying to put his fingers in the outlets. Thanks!
  
  submitted by /u/daddyciwa
  [link] [comments]
8. 🔗 r/wiesbaden Frühstücken in Wiesbaden oder Mainz rss
  
  Moin Leute,
  
  Wo kann man so richtig gut und gemütlich lange frühstücken. Vegan/Vegetarisch sollte möglich sein? Auch super wenn man dort reservieren kann.
  
  Eure Tipps letztes Mal fürs gemütliche Essen gehen haben super gepasst. :) Danke
  
  submitted by /u/JohnTheMonkey2
  [link] [comments]
9. 🔗 r/Yorkshire Six arrests in £2m TikTok shop crackdown in Rotherham rss
  
  | submitted by /u/willfiresoon
  [link] [comments]
  ---|---
10. 🔗 hyprwm/Hyprland v0.55.0 release
  A massive update brought to you by the All Hyprland Corp!
  
  Breaking changes
  - dwindle:pseudotile has been removed as it wasn't doing anything
  - decoration:shadow:ignore_window has been removed (defaults to enabled)
  - render:cm_fs_passthrough has been removed, should be automatic with render:cm_auto_hdr
  - misc:vfr moved to debug: as it's a debug variable that should not be changed in prod environments
  New features:
  - algo/scroll: add center for centering the current col (#14059)
  - algo/scrolling: add config options for focus and swapcol wrapping (#13518)
  - algo/scrolling: add expel, consume, and consume_or_expel (#13869)
  - animations: add springs (#14171)
  - binds: add an auto_consuming flag (#13919)
  - config/lua: add ExpressionVec2, allow using a table for vec2 rules (#14197)
  - config/lua: add clear tag api (#14273)
  - config/lua: add noop
  - config/lua: add simple layout API (#14258)
  - config/workspacerule: add animation style (#13380)
  - config: add device tags (#13728)
  - debug-tools: add flame
  - desktop/window: add alpha container for alpha calculations
  - desktop/windowRule: add confine_pointer window rule (#13379)
  - desktop/windowRule: add parser switch for confine pointer (#14263)
  - dispatchers: add moveintoorcreategroup (#13325)
  - dwindle: add rotatesplit layoutmsg and tests (#13235)
  - gestures: add live pinch cursor zoom (#14049)
  - gestures: add scroll_move (#14063)
  - groups: add groupbar middle_click_close option (#14242)
  - hl.mata.lua: add string to NotificationOptions's icon param. (#14334)
  - hyprctl: add hw cursor flag
  - hyprland.pc.in: add src include flag
  - i18n: add Greek translations (#13865)
  - i18n: add Punjabi translations (#13807)
  - input: add device specific binds (#13073)
  - layerrules: add dynamically registered rules for plugins (#13331)
  - layout/windowTarget: add visualBox (#13626)
  - render/cm: add ICC profile pipeline (#12711)
  - renderer/deco: add glow decoration (#13862)
  - renderer: add a cm settings cache
  - window/rules: add scrolling_width (#13754)
  - windows/focus: add fallbacks when focussing workspaces (#14270)
  Fixes:
  - config/descriptions: add missing desc entry
  - cmake: add -fno-omit-frame-pointer to debug
  - InputManager: add guards to confineToRegion to avoid issues (#14269)
  - algo/dwindle: add back splitratio (#13498)
  - algo/dwindle: fix precise mouse setting (#13678)
  - algo/master: fix crash after dpms (#13522)
  - algo/master: fix crash on null target in getNextTarget
  - algo/scroll: fix std::clamp assertion crash on resume from suspend (#13737)
  - algo/scroll: fix unsigned wrap (#13634)
  - algo/scrolling: fix offset on removeTarget (#13515)
  - algo/scrolling: fix rare crash
  - algo/scrolling: various scrolling view related bugfixes (#13974)
  - build: add glaze dependency with FetchContent fallback (#13666)
  - build: add format-check and format-fix Makefile targets (#13936)
  - build: fix build on gcc 16.x after #6b2c08d (#13429)
  - clang-tidy: fix duplicate entry in .clang-tidy (#14045)
  - cmake: fix permissions for directories by default
  - cmakelists: fixup errors failing build on arch ci (#14259)
  - compositor: fix floating input/visual z-order desync after fullscreen (#14015)
  - compositor: fix focus edge detection (#13425)
  - compositor: fix missing recheckWorkArea to prevent CReservedArea assert failure (#13590)
  - config/actions: fix misuse of ActionResult's error type (#14221)
  - config/legacy: fix crash on getConfigValue of plugin fns
  - config/legacy: fix missing fallbacks crashing device getters
  - config/lua: fix device bool int reads (#14313)
  - config/lua: fix dispatcher shapes to not be callable (#14268)
  - config/lua: fix unbind behavior (#14199)
  - config/lua: fix window object to selector logic
  - config/refresher: fix refreshing of cursor zooms (#14283)
  - config: fix crash in safe mode due to null Config::mgr() (#13855)
  - config: fix propRefresher to not run on first launch
  - config: fix safe mode config generation (#14024)
  - config: fix type confusion in getOption with complex types
  - core: fix i586 build (#13550)
  - deco/border: fix damage region
  - deco/border: fix damageEntire
  - desktop/group: fix movegroupwindow not following focus (#13426)
  - desktop/rule: fix matching for content type by str
  - desktop/rules: fix empty workspace handling (#13544)
  - desktop/rules: fix static rules and content type. (#13725)
  - desktop/view: fix SIGABRT in CWindow::onUnmap when monitor is expired (#14148)
  - desktop/window: fix floating windows being auto-grouped (#13475)
  - desktop/window: fix idealBB reserved (#13421)
  - desktop/windowRule: fix matching CONTENT (#13636)
  - desktop/workspace: fix visibility criteria matching (#14349)
  - example/hyprland.lua: fix wiki links for new stuff (#14172)
  - examples: fix missing permissions entry in lua example config (#14177)
  - groups: fix movewindoworgroup when moving from group to group (#14086)
  - hyprctl: fix bools in getoption
  - hyprctl: fix buffer overflowing writes to the socket
  - hyprctl: fix getoption with custom types (#14243)
  - hyprctl: fix invalid type cast
  - hyprctl: fix json output for the submap command (#13726)
  - hyprctl: fix lib64 pkgconfig for version-checking (#14051)
  - hyprctl: fix workspace dynamic effect reloading (#13537)
  - hyprpm: fix url sanitization in add
  - input: fix device configs for pointer devices
  - input: fix focus_on_close=2 (MRU) routing to cursor path instead of getNextCandidate (#13969)
  - input: fix the multimon touch fix (#13819)
  - input: fix touch monitor focus ordering (#14310)
  - input: fix touch screen focus on multi monitor (#13764)
  - internal: fix relative path header locations (#13650)
  - keybinds: fix keycode matching on lua (#14254)
  - keybinds: fix missing z-order update on floating toggle (#14100)
  - keybinds: fix wrong space assignment in pin (#14061)
  - keybinds: fixup changegroupactive
  - layershell: fix popup crash with nullptr mon (#13763)
  - layout/algo: fix swar on removing a target (#13427)
  - layout/groupTarget: fix crash on null space assignment (#13614)
  - layout/master: fix rollprev/rollnext focusing the wrong window (#14209)
  - layout/scroll: fix configuredWidths not setting properly on new workspaces (#13476)
  - layout/scrolling: fix edge detection in recalculate() (#14359)
  - layout/scrolling: fix size_t underflow in idxForHeight (#13465)
  - layout/windowTarget: fix size_limits_tiled (#13445)
  - layout: fix crash on monitor reconnect due to stale workspace state
  - layout: fix drag_threshold window snap regression (rebased for #12890) (#13140)
  - layout: fix null deref in focalPointForDir and moveInDirection (#13652)
  - layouts: fix crash on missed relayout updates (#13444)
  - meta/stubs: fix notification icon type (#14320)
  - misc: fix missing noreturn attribute for throwError (#13746)
  - monitor: fix centered floating windows off-screen in special workspace (#14203)
  - opengl/shadow: fix shadow offset rendering (#14156)
  - overridableVar: fix reassignment
  - pointer: fix hardware cursor rendering on rotated/flipped monitors (#13574)
  - propRefresher: fix misnamed value
  - protocols/compositor: fix presentFeedback being blocked
  - protocols/sessionLock: fix crash when monitor is gone during lock surface creation
  - protocols: fix image-copy-capture stop handling and remove non protocol errors (#13706)
  - render/pass: fix debug:pass rendering
  - render: fix SIGFPE in addWindowToRenderUnfocused when misc:render_unfocused_fps is 0 (#13973)
  - render: fix layer blur_popups ignoring ignore_alpha when blur is off (#13947)
  - renderer/groupbar: fix a group indicator rounding bug (#13975)
  - renderer/groupbar: fix gradients rendering (#13875)
  - renderer: Various CM fixes, part 8 of refactors (#13860)
  - renderer: fix blockBlurOptimization check (#13685)
  - renderer: fix crash on mirrored outputs needing recalc (#13534)
  - renderer: fix crash on null blur framebuffer during monitor disconnect
  - renderer: fix crash when shader path isn't a file (#13756)
  - renderer: fix crash with nullptr FBs (#13641)
  - renderer: fix decoration colors with linear FP16 (#14361)
  - renderer: fix sdr mod (#13630)
  - renderer: fix shadow CM calculations (#14364)
  - renderer: fix share window projection (#13695)
  - renderer: more FP16 fixes (#14070)
  - renderer: refactor part 7: api fixes (#13631)
  - renderer: small fixes in OpenGL.cpp and OpenGL.hpp (#13842)
  - screencopy: fix crash in screensharing toplevel with invalid handle (#13781)
  - screencopy: fix isOutputBeingSSd (#13586)
  - screencopy: fix minor crash (#13566)
  - screencopy: fix nullptr deref if shm format is weird
  - screenshare: round captureBox after scaling to fix region capture at fractional scales (#14257)
  - seat/compositor: fix minor issues (#13958)
  - seat: fix dropped wl_keyboard.enter after stale keyboardFocusResource (#14143)
  - tests/workspace: fix one test case failing
  - tests: Fix more tests failing on CI (#14159)
  - tests: fix ConfigLuaValueTypes - boolBadType test, 0 and 1 are allowed integer values for bool type (#14240)
  - tests: fix gtests crashing (#14244)
  - workspace: fix missing null access guard (#14119)
  - xwayland: fix compiler warnings (#13920)
  Other:
  - CI/Nix/Test: check gtest exit status
  - CI/Nix: use org-wide actions
  - CI/build: remove commented-out clang-format action (#13893)
  - Nix: always test in debug mode
  - NotificationOverlay: take reserved space into account (#14184)
  - algo/dwindle: Respect force_split when moving windows to workspaces (#13038)
  - algo/dwindle: do NOT use smart_split for overridden focal point (#13635)
  - algo/dwindle: don't crash on empty swapsplit (#13533)
  - algo/dwindle: use focal point correctly for x-ws moves (#13514)
  - algo/scroll: improve directional moves (#13423)
  - algo/scroll: reverse horizontal dir mapping of vertical scroll directions (#13647)
  - algo/scrolling: improve behavior with focus_fit_method = center (#13795)
  - animation: avoid redundant damage calls in tick
  - build: bump hyprgraphics to 0.5.1 (#14013)
  - build: bump hyprutils to 0.13.1 (#14365)
  - build: remove auto-generated hyprctl/hw-protocols/ files during make clear (#13399)
  - build: remove legacy clang-format workflow (#13887)
  - clang-format: run formatter
  - cleanup: avoid repeated weak_ptr lock() calls in conditions (#14057)
  - cleanup: avoid repeated weak_ptr::lock() usage in MasterAlgorithm (#14226)
  - cmake: install the default example hyprland.lua (#14174)
  - cmake: remove dependence on hyprland.conf
  - cmakelists: search for any possible lua package name (#14204)
  - compositor: When processing fullscreen states, only use effective mode where necessary (#13607)
  - compositor: be more selective about how we expand the window box in getting coord (#13720)
  - compositor: damage monitors on workspace attachment updates
  - compositor: move SessionLockManager init from STAGE_LATE to STAGE_BASICINIT (#14272)
  - compositor: recalculate workspace state after fs state update (#14369)
  - config/actions: remove spammy errors and make them silent
  - config/errors: Report and categorize errors properly for actions (#14192)
  - config/executor: actually execute exec-shutdown (#13872)
  - config/legacy: default to active window for movetoworkspace dispatchers (#14170)
  - config/legacy: translate default window args properly
  - config/lua: cannot disable animation (#14215)
  - config/lua: don't pop up an error if no target was found (#14175)
  - config/lua: expand properties in the workspace object (#14194)
  - config/lua: init lua config manager, use lua if available (#13817)
  - config/lua: workspace.move/rename should accept "workspace" instead of "id" as a parameter (#14232)
  - config/refresher: refresh watcher state properly (#14307)
  - config/workspace-rules: support modifying persistent and monitor (#14217)
  - config: allow hashes for parsing colors (#14337)
  - config: always call refresh after config reload (#14346)
  - config: cleanup the entire config infrastructure (#13785)
  - config: find lua paths first (#14335)
  - config: move misc:vfr to debug: (#14021)
  - config: refresh window states on border_size changes (#14201)
  - config: use lua by default, generate lua if no config present
  - data/dnd: guard against expired dndPointerFocus and ensure consistent usage (#13996)
  - debug/overlay: optimize rendering, cleanup and nicetify (#14097)
  - decoration/border: simplify damage callback
  - desktop/group: respect direction when moving window out of group (#13490)
  - desktop/history: include ranges header (#14000)
  - desktop/layerRule: use variants for storage internally
  - desktop/popup: cache popup extents
  - desktop/popup: cache tree count
  - desktop/reserved: do not crash on invalid box init (#13880)
  - desktop/rule: cleanup inheritance, use templates to avoid dup
  - desktop/rule: recheck eating the applied rule (#14362)
  - desktop/rule: use Numeric for number parsing
  - desktop/window: don't group modals
  - desktop/window: expand hidden into proper states
  - desktop/window: guard null monitor in xwaylandSizeToReal (#13876)
  - desktop/window: optimize getRealBorderSize()
  - desktop/window: reduce window deco updates (#13980)
  - desktop/window: refactor over fullscreen state
  - desktop/windowRule: use variants for storage internally
  - desktop/workspaceHistory: small refactor to work better with multi monitor setups (#13632)
  - egl: move over to use hyprgraphics (#12988)
  - errorOverlay: modernize, refactor, use GPU rendering (#14122)
  - example: remove old .conf file
  - examples: merge config blocks in lua example as demo
  - format: safeguard drmGetFormat functions (#13416)
  - gitignore: ignore pointer scroll test artifact
  - helpers/systemInfo: extract info fns (#14222)
  - hyprtester: minor refactoring/restructure (#14154)
  - i18n: update Tatar translations (#13930)
  - i18n: update Vietnamese translations (#13489)
  - i18n: update brazillian portuguese (pt_BR) translation (#14248)
  - init: drop CAP_SYS_NICE from ambient set after gaining SCHED_RR (#14082)
  - input: allow focus to switch to most recently used window on closed (#13769)
  - input: avoid repeated weak_ptr::lock() and ensure consistent usage (#14039)
  - input: focus monitor on touch down events (#13773)
  - input: implement follow_mouse_shrink (#13707)
  - input: keep pointer focus on layer surfaces during keyboard refocus (#14018)
  - input: lazy cache getWindowIdeal()
  - internal: improve cursor size logging (#14180)
  - internal: include setByUser in CConfigManager::getConfigValue (#14155)
  - internal: removed Herobrine
  - internal: rewrite deviceNameToInternalString using a single range pipeline (#13806)
  - internal: silence compiler warnings about unused return values (#13997)
  - keybind/actions: cycle_next w/ tiled = true doesn't choose only tiled windows (#14164)
  - keybindMgr: use legacy behavior for single-key binds on lua (#14176)
  - keybinds: Remove removed keybinds (#13605)
  - layersurface: simulate mouse movement on layer change (#13747)
  - layout/algo: preserve focused target if applicable on layout switches (#14058)
  - layout/algos: use binds:window_direction_monitor_fallback for moves (#13508)
  - layout/dwindle,master: return invalid layoutmsg errors
  - layout/scrolling: handle fullscreen manually (#14190)
  - layout/windowTarget: damage before and after moves (#13496)
  - layout/windowTarget: don't use swar on maximized (#13501)
  - layout/windowTarget: override maximized box status in updateGeom (#13535)
  - layout: guard null workspace in CWindowTarget::updatePos() (#13861)
  - layout: replace string comparison with ID-based matching in WorkspaceAlgoMatcher (#13943)
  - layout: revert "replace string comparison with ID-based matching in WorkspaceAlgoMatcher (#13943)"
  - layout: store and preserve size and pos after fullscreen (#13500)
  - layouts/dwindle: override force after window drags (#14002)
  - logging: update uri of debug log in ConfigManager to reflect change in wiki (#14185)
  - main: improve error reporting during initialization in main.cpp (#14181)
  - meta/stubs: update gesture hints to match new fields (#14195)
  - miscfunctions: reuse monitor pointer instead of repeated calls (#13977)
  - monitor: centralize solitary and scanout eligibility checks
  - monitor: damage old special monitor on change
  - monitor: ensure swapchain is updated before mode test (#14065)
  - monitor: keep workspace monitor bindings on full reconnect (#13384)
  - monitor: set format back after failing DS activation (#14168)
  - monitor: update pinned window states properly on changeWorkspace (#13441)
  - monocle: avoid repeated workspace monitor lock() calls (#14085)
  - nix/tests: print gtests logs
  - nix: separate overlay with deps
  - notifications: move and small refactor (#14094)
  - notifications: optimize rendering (#14088)
  - opengl: minor egl changes (#14147)
  - pass/surface: cache texBox
  - pointer: damage entire buffer in begin of rendering hw
  - protocolMgr: set m_self properly when updating mirrored outputs
  - protocols/workspace: schedule done after output update (#13743)
  - protocols: allow xdg-foreign to be used by sandboxed apps (#13854)
  - protocols: avoid repeated per-client work in hot paths
  - protocols: prune stale subsurface refs in hot traversals
  - protocols: reimplement unstable/xdg-foreign-v2 (#13716)
  - refactor: improve readability of monitor rule comparison (#13884)
  - render/decoration: cache input extents as well
  - render/decoration: improve extent calculations
  - render/decorations: improve cache performance
  - render/opengl: optimize getShaderVariant's map access
  - render/pass: optimize simplification and blur calculations
  - render: scale background to monitor resolution (#14250)
  - renderer/cm: Support wp-cm-v1 version 2 (#12817)
  - renderer: don't damage decos individually in damageWindow
  - renderer: extract window skip conditions into named booleans (#14005)
  - renderer: guard against null monitor in renderMonitor (#13823)
  - renderer: handle HDR -> SDR with cm_auto_hdr (#14102)
  - renderer: move m_renderData to renderer (#13474)
  - renderer: only set presentationmode when required (#14252)
  - renderer: refactor Texture, Framebuffer and Renderbuffer (#13437)
  - renderer: refactor gl renderer (#13488)
  - renderer: refactor projection setting (#13485)
  - renderer: refactor render elements (#13438)
  - renderer: refactor resources and flags (#13471)
  - renderer: shader variants refactor (#13434)
  - renderer: simplify renderWorkspaceWindowsFullscreen
  - renderer: simplify shadows (#14047)
  - renderer: skip redundant render-path work
  - renderer: swizzle on shm screencopy (#14167)
  - repo: ignore the autogen file meta/hl.meta.lua (#14336)
  - rules: make rule prop reset less cursed (#14003)
  - scheduler: keep a strong monitor ref in frame callbacks
  - screencopy: check share session state (#13839)
  - screencopy: clear buffer before rendering (#14064)
  - screencopy: scale window region for toplevel export (#13442)
  - screenshare/frame: set m_copied after shm copy succeeds (#14165)
  - screenshare: adjust session cleanup and event emission order (#14229)
  - screenshare: improve destroy logic of objects (#13554)
  - scroll: clamp column widths properly
  - seat: store surface in pointerFocus before sendEnter (#13941)
  - sessionLock: send locked instead of denied when missing a lock frame for 5 seconds (#14271)
  - shader: delete shader on success path (#13682)
  - socket2: emit kill event (hyprctl kill) (#13104)
  - source: c-f for new clang version
  - splashes: update splashes
  - subsurface: use geometry-aware damage and recurse into nested trees (#13933)
  - tests: add unit tests for ByteOperations helpers (#13886)
  - tests: add unit tests for CDamageRing (#13995)
  - tests: add unit tests for CHyprColor (#13891)
  - tests: add unit tests for CMType helpers (#13888)
  - tests: add unit tests for CMonitorRuleParser (#13895)
  - tests: add unit tests for CTagKeeper (#13970)
  - tests: add unit tests for Direction helpers (#13885)
  - tests: add unit tests for Format utilities (#13923)
  - tests: add unit tests for Math transform utilities (#13935)
  - tests: add unit tests for Math::CExpression (#13924)
  - tests: add unit tests for MiscFunctions helpers (#13934)
  - tests: add unit tests for TransferFunction helpers (#13889)
  - tests: add unit tests for match engine types (#13903)
  - tests: skip pointer tests in CI due to missing input environment (#14238)
  - tests: stabilize CI by relaxing env-dependent checks and timing-sensitive assertions (#14142)
  - tests: tolerate plugin config mismatch in CI (#14173)
  - treewide: alejandra -> nixfmt
  - view: consolidate group flags and apply window rules (#13694)
  - workspace: remove deprecated and unused members (#14198)
  - xdg-foreign-v2: Keep invalid imported objects alive (#14166)
  - xdg-shell: queue state updates for toplevel (#14227)
  - xwayland: handle transient read errors in selection transfer (#14135)
  - xwayland: pipe through monitor in coordinate mapping (#13700)
  - xwayland: prevent potential buffer overflow in socket path handling (#13797)
  Special Thanks
  
  As always, special thanks to these people / companies for supporting Hyprland's continued development:
  
  Sponsors
  
  Diamond
  
  37Signals
  
  Gold
  
  Framework, Butterfly
  
  Donators
  
  Top Supporters:
  
  Tonao Paneguini, Semtex, soy_3l.beantser, Seishin, Nox Æterna, Illyan, Snorezor, Bonsai, Joshua Weaver, ExBhal, DHH, Mikko_Nyman, Kay, iain, TyrHeimdal, miget.com, alexmanman5, Hunter Wesson, --, RaymondLC92, Theory_Lukas, Brandon Wang, Insprill, lzieniew, 3RM, johndoe42, Jas Singh, RayJameson, MadCatX, Xoores, d, Ammar Hossain, Ki☆, inittux111, Arkevius, John Shelburne, DeWattaUnk, ari-cake, gfunnymoney, alukortti, taigrr
  
  New Monthly Supporters:
  
  tubid2wenty, Uros Cotman, yafantik, Guy, goblin_engineer, Julius John Puno, Peter Buijs, mb, StellaBuckley, haikuolin, Antibaddy, sludge10123, C Money, Lipski, KampotKaca, Kazuhide Takahashi, Skeptomai, bombadurelli, Rebellen, Álan, StreamCyper, taras, Yury, Sherab, Filinto Delgado, Taddelladius
  
  One-time Donators:
  
  Quuton, Selvan, Tyler Adams, tonis, Sam, Dimitrios Liappis, Chivtar, Eric, aponsasan888, bkode, LonestarF1, Chris, Dogmatic Polack, Larry, maxx, MonolithImmortal, edrix, I like GameNative, take my money., nyxloom, Frederic Toemboel, Schmendiey, himes, brandonia, Xphelus, New user, Miguel Flores- Acton, R3dGh0st, Glen, Vitor Moura GUEDES, Anersyum, le_04, Dan, AT, chorr, Awesome, IdeaSpring, Jacobrale, anonymous, Elias Griffin, w00z4, Marcus Edvardsson, Gerhard, Bashmaks, Benjaneb, R4dicalEdward, Matýsek ^^, Michael, Gene Raymond, naivesheep, Neginja, anarchuser, Uta, Francois KERISIT, ay4, Lorenzo santacreu, Gitznik, Jure S, Oliver, Pipes, Mein, ironick, Nlight, Pfoid, DasCleverle, Jaf Endee, DIEBUSTER, senorBeard, alex, Mike, luxxa, JasonPettys, One, Daniel, Sven Eppler, L3rdy, Ilunn, Thorff, XurxoMF, Wonkhester, Brian, Doc O, Mortja, Spook, Miguel Cordero Collar, bennyzen, deah, Sean, Higor, nanea808, Torsten Schieber, I3lack5hield, Kevin Steffer, Zarenno, vfosterm, Nikola, EGB, Dietmar, KilahDentist, Wilf Lin, Rad, Yuza, Supporter, nooob, esseonline, Naresh, darquill, BrnPrs, Pani, BYK, Amaury, nythix, Mika, Patriarch, Gambit, GoatCedric, Adam, MirasM, bl4ckb1rd, Loon, KevOlek, AsciiWolf, Brian Barrow, Anon, Kilian, Cristian M., abhinavmishra094, Dejv78, LinoDB, Trofim, Konstantin, JoaquinCamposPlaza(Ximo), Gabo, Phil, dev2and0m, Neil Brown, zarilion, JavierArias(Javi), Thank you, Mystrasun, Skrazzo, MeguminLoli, revitalist, barcellos-pedro, Juh, Goldie, benabrig, mynus, Daniel Zudel, Grant, Jacob Felknor, Noah, e033x, Nick, Niklas, mkami, Slippy, joenu, Oleksandr, t.i.m., Joss001, M4CETO, Nighty, Donater, David N, Cameron, Ekoban, Kieran, brotiii, Doug, Hypruser#0224975, Shadesofastar, sonicbhoc, GKL, Damien, João Seixas, mothmashine, James Freiwirth, Mek, Krizzkrozz, Panzer, mika.dev, Franky Valley, Sycho sMILEz, Roy, Amundis, willibenmula ❤️, Justin, marvelousIT, pablo, Alex, Ryan, cito, Juergen, Eric Koslow, valerius21, jfk, Andrejs, tyforupdate, skwrl, DaintyFox
  
  Full Changelog : v0.54.0...v0.55.0
11. 🔗 r/Yorkshire Looking over High Ginger field Lodge at the ruins of the Racecourse stands. rss
  
  | submitted by /u/Still_Function_5428
  [link] [comments]
  ---|---
12. 🔗 r/LocalLLaMA 80 tok/sec and 128K context on 12GB VRAM with Qwen3.6 35B A3B and llama.cpp MTP rss
  Just wanted to share my config in hopes of helping other 12GB GPU owners achieve what I see as very respectable token generation speeds with modest VRAM. Using the latest llama.cpp build + MTP PR, I got over 80 tok/sec with 80%+ draft acceptance rate on the benchmark found here: https://gist.githubusercontent.com/am17an/228edfb84ed082aa88e3865d6fa27090/raw/7a2cee40ee1e2ca5365f4cef93632193d7ad852a/mtp- bench.py
  
  Here's my PC specs:
```
OS: CachyOS (HIGHLY recommended) CPU: AMD Ryzen 7 9700X RAM: 48GB DDR5-6000 EXPO I GPU: RTX 4070 Super 12GB
```
  Results with other hardware may vary.
  
  To run llama.cpp with MTP support, you need to build it from source and add a draft PR that hasn't yet been merged with the master branch. You can find a very nice guide on how to do that here and also download the Qwen3.6 MTP GGUF: https://huggingface.co/havenoammo/Qwen3.6-35B-A3B-MTP-GGUF - Thanks u/havenoammo!
  
  llama.cpp command:
```
llama-server \ -m Qwen3.6-35B-A3B-MTP-UD-Q4_K_XL.gguf \ -fitt 1536 \ -c 131072 \ -n 32768 \ -fa on \ -np 1 \ -ctk q8_0 \ -ctv q8_0 \ -ctkd q8_0 \ -ctvd q8_0 \ -ctxcp 64 \ --no-mmap \ --mlock \ --no-warmup \ --spec-type mtp \ --spec-draft-n-max 2 \ --chat-template-kwargs '{"preserve_thinking": true}' \ --temp 0.6 \ --top-p 0.95 \ --top-k 20 \ --min-p 0.0 \ --presence-penalty 0.0 \ --repeat-penalty 1.0
```
  The most important parameter here is -fitt 1536. Since part of the model is offloaded to CPU because of its size and , this tells llama.cpp to properly balance the load on the GPU/CPU to get the best possible performance, and leaves 1536 MB of free memory for the MTP draft model and KV cache. Since I'm running my dGPU as a secondary GPU (monitor plugged in the iGPU), I can use all the available 12GB VRAM for inference. 1536 might be too small if you use your dGPU as your primary GPU, so test it out first.
  
  You can also try different values for -spec-draft-n-max. I got slightly better tok/sec with 3, but a much better acceptance rate with 2, so the trade off was not worth it. With MTP, you want to maximize speed AND acceptance, so you need to find the best balance between both.
  
  Benchmark results:
```
mtp-bench.py code_python pred= 192 draft= 132 acc= 125 rate=0.947 tok/s=80.8 code_cpp pred= 58 draft= 40 acc= 37 rate=0.925 tok/s=81.8 explain_concept pred= 192 draft= 152 acc= 114 rate=0.750 tok/s=70.0 summarize pred= 53 draft= 40 acc= 32 rate=0.800 tok/s=75.4 qa_factual pred= 192 draft= 144 acc= 119 rate=0.826 tok/s=77.8 translation pred= 22 draft= 16 acc= 13 rate=0.812 tok/s=81.9 creative_short pred= 192 draft= 160 acc= 111 rate=0.694 tok/s=69.2 stepwise_math pred= 192 draft= 144 acc= 119 rate=0.826 tok/s=76.5 long_code_review pred= 192 draft= 148 acc= 117 rate=0.790 tok/s=73.2
```
  If you have any questions, feel free to ask :)
  
  Cheers.
  
  submitted by /u/janvitos
  [link] [comments]
13. 🔗 r/Leeds Petition · Stop water pollution from misconnections in the Gledhow Valley rss
  
  The Friends of Gledhow Valley Woods water monitoring team have been out again this week along the length of Gledhow Beck.
  
  They found that the culvert on Allerton Grange Way is again pouring out a thick brown liquid from a misconnection into the Beck. This has been reported to Yorkshire Water and Environment Agency but no evidence of any action.
  
  This is on top of the 368.75 hours of untreated sewage discharges into the Beck and Lake in 2025( latest figures) from the 4 Combined Sewer outfalls in the Gledhow Valley and the toxic mix of chemicals and heavy metals running off Gledhow valley Road into the Beck. Analysis this week demonstrates that levels of Lead and Zinc from this source are likely to have an adverse impact on invertebrates in Gledhow Beck -a key food source for fish and birds.
  
  Please support our campaign to clean up this mess for both nature and the local community.
  
  Sign our petition!
  
  submitted by /u/blissedandgone
  [link] [comments]
14. 🔗 r/wiesbaden Wann kommen die 800.000 Euro für den Helmut-Schön-Sportpark? rss
  
  Die 800.000 Euro wurden bestimmt längst per Fax angewiesen, aber im Wiesbadener Rathaus war leider das Thermopapier alle. Wahrscheinlicher ist aber, dass man die Kohle direkt als Beraterhonorar an McKinsey überwiesen hat, für ein 200-seitiges Gutachten, das klären soll, warum unsere kommunale Infrastruktur eigentlich immer verrottet.
  
  submitted by /u/LethisXia
  [link] [comments]
15. 🔗 r/Harrogate Harlow Moor Drive rss
  
  Hi Everyone,
  
  We are considering the move to Harrogate, and we love the Harlow Moor Drive area. We have noticed an empty property, which I understand was a care home (Avon Lodge), which has since been sold to developers.
  
  Does anyone know if/what the plans for this property would be? Trying to understand if/how it would affect houses in the area (construction/expansion etc!)
  
  Thank you so much for your help!
  
  submitted by /u/RefuseElectrical10
  [link] [comments]
16. 🔗 modem-dev/hunk v0.11.0-beta.0 release
  What's Changed
  - Added vcs = "jj" support for hunk diff [revset] and hunk show [revset] by @clabby in #217
  - Added a pager-mode sidebar file tree toggle via s by @clabby in #216
  - Fixed git log -p and multi-commit git show -p parsing so commit metadata is ignored by @gonzaloserrano in #228
  - Fixed cross-file hunk navigation anchoring by @aliou in #222
  - Fixed the View menu sidebar checkmark to follow actual responsive sidebar visibility by @aliou in #236
  Full Changelog : v0.10.0...v0.11.0-beta.0
17. 🔗 r/LocalLLaMA Shel Silverstein predicts LLM's (and its hallucinations), cira 1981 rss
  
  | Ran across this cartoon / poem on accident as I was reminiscing about my favorite childhood poet, Shel Silverstein, and couldn't help thinking of LLM's of course! submitted by /u/spanielrassler
  [link] [comments]
  ---|---
18. 🔗 r/LocalLLaMA Qwen3.6 35B A3B uncensored heretic Native MTP Preserved is Out Now With KLD 0.0015, 10/100 Refusals and the Full 19 MTPs Preserved and Retained, Available in Safetensors, GGUFs. NVFP4, NVFP4 GGUFs and GPTQ-Int4 Formats rss
  
  llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved: https://huggingface.co/llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native- MTP-Preserved
  
  llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved-GGUF: https://huggingface.co/llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native- MTP-Preserved-GGUF
  
  llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved- NVFP4-Experts-Only: https://huggingface.co/llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native- MTP-Preserved-NVFP4-Experts-Only
  
  llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved- NVFP4-Experts-Only-GGUF: https://huggingface.co/llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native- MTP-Preserved-NVFP4-Experts-Only-GGUF
  
  llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved-GPTQ-Int4: https://huggingface.co/llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native- MTP-Preserved-GPTQ-Int4
  
  People asked for it, so here it is, all realeases are confirmed to have their full MTP count* retained and preserved.
  
  Comes with benchmark too.
  
  Find all my models here: HuggingFace- LLMFan46
  
  *All releases have been verified to retain the full MTP tensors. In safetensors format, the Qwen3.6-35B-A3B MTP tensors appear as 19 entries because gate_up_proj is stored as one fused tensor. In GGUF format, that fused tensor is split into separate gate/up expert tensors, so the same MTP component appears as 20 entries. The count differs by format, but the MTP tensors are preserved.
  
  submitted by /u/LLMFan46
  [link] [comments]
May 08, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-05-08 rss
  IDA Plugin Updates on 2026-05-08
  
  New Releases:
  - ida-x64dbg-mcp IX64MCP v0.1.1 alpha
  Activity:
  - capa
    
    5a60f3a0: fix: register all data-ref addresses for imports in Ghidra helpers
    
    99b3cfe0: fix: use singular get_segment_at API in binja file string extractor
    
    a28fcce7: fix: linter tests needing placeholder rule sets to function
    
    5ca6c3e3: gitignore: script test temp files
    
    b505ba76: fix: remove unused imports and un-suppress F401
    
    309231f2: fix: ghidra and binja file strings yield FileOffsetAddress
    
    57e730fa: fix: binja embedded PE yields FileOffsetAddress via segment data_offset
    
    c9cb43a8: fix: elffile imports use AbsoluteVirtualAddress for ELF r_offset
    
    9b93e90e: fix: wrap binja function name addresses in AbsoluteVirtualAddress
    
    4e804007: fix: ghidra: don't emit VAs for embedded PEs
    
    330b6413: fix: ida: correctly emit file offsets for embedded PEs
    
    43d65361: gitignore: CLAUDE.local.md
    
    8fca21f8: linter: validate dynamic example offsets
    
    8e464e60: fix: formatting
    
    555bbdec: fix: guard getByteDef against None for unmapped addresses in viv insn…
    
    c8d47085: fix: remove unused imports from cache-ruleset.py, detect-binexport2-c…
    
    7a8a0aca: fix: remove dead except ValueError clause in capa2sarif.py so JSONDec…
    
    7d871409: fix: dedent bulk-process.py main() body so explicit argv is used
    
    a938c87f: fix: guard statistics calls in compare-backends.py against empty dura…
    
    604fae35: fix: replace zipfile with pyzipper in minimize_vmray_results.py so ou…
  - ida-x64dbg-mcp
    
    f679d5ba: Harden x64dbg runtime workflows
    
    bb3d39cf: Add x64dbg runtime snapshot workflow
  - IDAPluginList
    
    90a9d234: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
2. 🔗 r/Yorkshire The Gannet, RSPB Bempton Cliffs, Yorkshire rss
  
  | submitted by /u/aspiranthighlander
  [link] [comments]
  ---|---
3. 🔗 Hex-Rays Blog Announcing the 2025 Plugin Contest Winners rss
  
  The 2025 Hex-Rays IDA Plugin Contest is officially wrapped up, and we are excited to announce this year's winners! This edition drew 25 submissions from both returning participants and newcomers, each bringing fresh ideas to extend and improve IDA Pro.
4. 🔗 r/LocalLLaMA vLLM ROCm has been added to Lemonade as an experimental backend rss
  
  | vLLM has the ability to run .safetensors LLMs before they are converted to GGUF and represents a new engine to explore. I personally had never tried it out until u/krishna2910-amd/ u/mikkoph and u/sa1sr1 made it as easy as running llama.cpp in Lemonade: lemonade backends install vllm:rocm lemonade run Qwen3.5-0.8B-vLLM This is an experimental backend for us in the sense that the essentials are implemented, but there are known rough edges. We want the community's feedback to see where and how far we should take this. If you find it interesting, please let us know your thoughts! Quick start guide: https://lemonade-server.ai/news/vllm-rocm.html GitHub: https://github.com/lemonade-sdk/lemonade Discord: https://discord.gg/5xXzkMu8Zk submitted by /u/jfowers_amd
  [link] [comments]
  ---|---
5. 🔗 @HexRaysSA@infosec.exchange 🔦 PLUGIN SPOTLIGHT: ida-cyberchef mastodon
  
  🔦 PLUGIN SPOTLIGHT: ida-cyberchef
  
  This is a new open source plugin that embeds CyberChef's data transformation engine directly into IDA Pro, with a Qt interface that sits alongside your disassembly as a side panel.
  
  Data flows top to bottom through three panels for input, recipe, and output.
  
  https://hex-rays.com/blog/ida-pro-meet-cyberchef
6. 🔗 r/york Driving lessons rss
  
  I’m looking for driving lessons. I had about 6-12 months experience 2 years ago but I haven’t driven since. I was wondering if anyone knew any lessons I could take before my test that is somewhat cheap and good
  
  submitted by /u/sheetpost00
  [link] [comments]
7. 🔗 r/Yorkshire Hebden Bridge illustration rss
  
  | Hey folks! Thought you'd enjoy this new little illustration I just finished of Hebden Bridge. This took around 18 hours based on my own photos :) submitted by /u/zacrosso_art
  [link] [comments]
  ---|---
8. 🔗 r/wiesbaden In Germany soon rss
  
  Hi. I would like to ask if what are the things that I need to prepare? I will arrive in Hessen Germany this coming June and I am from the Philippines. Any answers/ suggestions will be a great help for me. Thank you.
  
  submitted by /u/No_Manner_2072
  [link] [comments]
9. 🔗 r/LocalLLaMA Unpopular Opinion: The DGX Spark Forum community of devs is talented AF and will make the crippled hardware a success through their sheer force of will. rss
  
  There is a lot of disdain for DGX Sparks here on the sub. And I get it. A lot of people say “It could have been great if it had been better memory bandwidth”, “SM-121 is a fake /second-class Blackwell chip” yadda, yadda. These criticisms are valid.
  
  I bought one anyway because I’m pursuing a Masters in AI and I wanted it for training models, tool dev, testing, etc.
  I was an early adopter, and like many, I was disappointed by the inference performance and software stack initially. Recently, my opinion and experience has changed.
  
  NVIDIA has an “official” DGX Spark Development community forum that is thriving. The people in the DGX forum community are some of the kindest, smartest, most tenacious group of developers I’ve met. These dudes have one common goal: Squeeze every last drop of performance out of this hardware to prove to themselves and the world that they didn’t make a bad purchase by buying a Spark. I know that sounds snarky, but I don’t think it’s a bad goal.
  
  The vibe on the forum is like “Ok bros, we all bought this thing, the peeps over at r/LocalLLama are all laughing at us right now, let’s show those sons-of-bitches what we can do” I mean, none of them would actually say that, because they are all really nice and helpful people, but that’s the vibe I get when I’m browsing through the posts. Everyone there has the same goal: optimize the hell out of DGX Spark to the highest level possible.. It’s wild seeing such a harmonious atmosphere. No one really argues, trolls, rage baits, none of that. Just everyone in the same boat, working together and encouraging each other, sharing benchmarks, code, vLLM recipes, etc. Reminds me of the vibe of this sub like 2 years ago before all the bot posts flooded the place.
  
  If you don’t believe me, about the DGX dev community, go check it out for yourself:
  
  https://forums.developer.nvidia.com/c/accelerated-computing/dgx-spark-gb10
  
  Check out some of the cool projects they’ve spun up like Sparkrun (http://sparkrun.dev), PrismaQuant, Spark Lesderboard, eugr vLLM, and all the other amazing projects these guys are working on.
  
  The one big advantage of the DGX hardware for these developers is the fact that the HW and OS is all exactly the same for everyone. You know your shit is going to work on every other Spark box that is out there and that is powerful for a unified community with one common goal.
  
  So yes, DGX Spark could have been a lot better and was probably crippled by design, but that’s not stopping the DGX Spark Forum community, these MFers are going to use their sheer force of will and talent to make this thing a success just to spite all the naysayers. My two cents, agree or disagree?
  
  submitted by /u/Porespellar
  [link] [comments]
10. 🔗 r/york Anyone looking for D&D groups or events in York? rss
  
  I've been working with some local communities recently in york and I'm trying to improve outreach involving a lot of upcoming Dungeons and Dragons related things
  
  submitted by /u/JunkDrawerTheatreCo
  [link] [comments]
11. 🔗 r/wiesbaden Outdoor Location gesucht rss
  
  Gude!
  
  Für eine Abschlussfeier suche ich nach einer Outdoor Location bestenfalls mit einem Zelt für maximal 50 Personen in Wiesbaden oder Umgebung.
  Bayleaf Events in Frankfurt Höchst ist eine sehr schöne Location mit Zelt und Deko und mein absoluter Favorit allerdings ist es nicht am 23. und 24. Mai verfügbar.
  Falls ihr sonst noch Ideen habt, würde ich mich auf jeden Fall freuen!
  
  submitted by /u/Levi_Ackermann_1304
  [link] [comments]
12. 🔗 r/reverseengineering Ghidra-SNES: A Ghidra extension for reverse engineering SNES ROMs (first public release, feedback welcome!) rss
  
  submitted by /u/JoshLeaves
  [link] [comments]
13. 🔗 r/Leeds Roundhay park warning rss
  
  Hi there!
  
  Just wanted to write that whilst walking my dog- I had a strange encounter with an older man.
  
  I was up the back of roundhay park lake (taking the pathway through the woods) at 11:30 this morning/ afternoon- he was in a very isolated part of the walking trail, and after staring at me walking past, I said ‘good afternoon’ and he replied by telling me he thought I was ‘very beautiful’ - I got a bad gut feeling and decided to leave straight away, he was saying more stuff as I was leaving but I didn’t hear him as he was very quiet.
  
  I just wanted to say to be cautious if you are in roundhay park and to stick to the main path by the lake if possible. Thanks!
  
  submitted by /u/SadEntertainment5259
  [link] [comments]
14. 🔗 r/reverseengineering Reverse-engineered DaVinci Resolve's activation check with Claude — Frida runtime tracing + radare2 rss
  
  submitted by /u/Hour-Dirt-4010
  [link] [comments]
15. 🔗 r/Yorkshire Richmond Castle in Yorkshire standing tall after nearly 1000 years. rss
  
  | submitted by /u/Still_Function_5428
  [link] [comments]
  ---|---
16. 🔗 r/york Policemen with assault rifles running around rss
  
  Does anyone know anything about the policemen running around with automatic weapons near Hungate apartments? Quite anxiety inducing to see that
  
  submitted by /u/Reduxtion
  [link] [comments]
17. 🔗 r/Yorkshire North Rigton... Apparently rss
  
  | submitted by /u/shoey_photos
  [link] [comments]
  ---|---
18. 🔗 r/york Love the cobbled or setts, and the whole atmosphere of Shambles is just magical, really brings out the history and charm of the place! 🌺 rss
  
  | submitted by /u/Coffee000Oopss
  [link] [comments]
  ---|---
19. 🔗 r/Yorkshire There's no better place to drink a tea and reboot yourself than the Dales rss
  
  | Image by Dan Silcock submitted by /u/Seabeachlover10
  [link] [comments]
  ---|---
20. 🔗 backnotprop/plannotator v0.19.11 release
  Follow @plannotator on X for updates
  
  Missed recent releases? Release | Highlights
  ---|---
  v0.19.10 | Revert unreviewed bypass-clear-reminder permission mode
  v0.19.9 | OpenCode user-managed workflow, Pi model switch fix, Codex skill install, shimmer removal
  v0.19.8 | 49 themes with syntax highlighting, keyboard shortcut registry, smart code-file path validation, remote URL notifications
  v0.19.7 | Codex Stop-hook plan review, Codex skills, sidebar auto-close, file tree context menu
  v0.19.6 | Non-blocking Pi browser sessions, agent picker dropdown for OpenCode, annotate-last file resolution fix
  v0.19.5 | All-files diff view, clickable code file paths, server-side hide whitespace, non-ASCII path support
  v0.19.4 | All-files diff type, code file viewer, hide whitespace, quick-settings popover
  v0.19.3 | Configurable feedback messages, hide merged PRs in stacked PR selector
  v0.19.2 | Stacked PR review, source line numbers in feedback, diff type dialog re-show, ghost dot removal, docs cleanup
  v0.19.1 | Hook-native annotation, custom base branch, OpenCode workflow modes, quieter plan diffs, anchor navigation
  v0.19.0 | Code Tour agent, GitHub-flavored Markdown, copy table as Markdown/CSV, flexible Pi planning mode, session-log ancestor-PID walk
  
  What's New in v0.19.11
  
  v0.19.11 adds Jujutsu (jj) as a first-class VCS backend for code review and refines the review UI with slimmer separators, a cleaner header layout, and proper multi-line gutter selection. One of the two PRs in this release is from a first-time contributor.
  
  Jujutsu (jj) Code Review
  
  Plannotator's code review now works natively with Jujutsu, the Git-compatible VCS. When you run /plannotator-review in a jj workspace, the VCS is auto-detected and four jj-specific diff modes appear in the diff type picker:
  - Current (jj-current) shows the working-copy changes
  - Last (jj-last) shows the previous change
  - Line (jj-line) shows the full line of work from the current change back to the trunk bookmark
  - All (jj-all) shows all local changes not yet on the remote
  Compare-target selection adapts to jj's model. Instead of branch-based base selection, the picker offers remote bookmarks. The feedback exported to your agent includes jj-appropriate local diff instructions so it can reproduce the same view.
  
  Under the hood, this required a significant refactor. Diff collection, compare-target semantics, and file-content retrieval were pulled into a provider-based VCS abstraction in packages/shared/vcs-core.ts. Git, jj, and P4 each implement the same provider interface. The review server and UI consume provider-supplied metadata instead of branching on VCS-specific flags. This abstraction makes adding future VCS backends straightforward.
  
  For colocated repos (both .git and .jj present), jj takes priority. Pass --git to /plannotator-review to override.
  - Authored by @graemefolk in #675
  Review UI Refinements
  
  Several quality-of-life improvements to the code review interface:
  
  Slimmer hunk separators. The expand/collapse bars between diff hunks are now 24px (down from 32px), with semi-transparent theme-integrated backgrounds. Text and buttons fade with lower opacity for a subtler look that puts the focus on the code.
  
  Cleaner header layout. Sidebar toggles (Annotations, AI, Agents) moved to the far right of the header bar, with the options menu to their left. A visual divider separates the file tree button from the repo label.
  
  Collapse viewed files. Marking a file as viewed in all-files review mode now automatically collapses it, keeping only unreviewed files expanded.
  
  Multi-line gutter selection fix. Click-and-drag on the gutter annotation button now correctly selects a range of lines. The previous implementation used a deprecated Pierre API that never entered the selection mode, so dragging always reported a single line.
  - #683, closing #679 and #682
  Install / Update
  
  macOS / Linux:
```
curl -fsSL https://plannotator.ai/install.sh | bash
```
  Windows:
```
irm https://plannotator.ai/install.ps1 | iex
```
  Claude Code Plugin: Run /plugin in Claude Code, find plannotator , and click "Update now".
  
  OpenCode: Clear cache and restart:
```
rm -rf ~/.bun/install/cache/@plannotator
```
  Then in opencode.json:
```
{
  "plugin": ["@plannotator/opencode@latest"]
}
```
  Pi: Install or update the extension:
```
pi install npm:@plannotator/pi-extension
```
  What's Changed
  - feat(review): add jj review workflows by @graemefolk in #675
  - Review UI refinements: separator styling and header layout by @backnotprop in #683
  New Contributors
  - @graemefolk made their first contribution in #675
  Community
  
  @graemefolk built full jj support from scratch, implementing the VCS provider, diff modes, compare-target picker, and feedback export in a single well-structured PR. The VCS abstraction layer they introduced benefits the entire codebase.
  
  @JohannesKlauss reported the multi-line gutter selection bug in #679, with a clear screen recording that made the root cause obvious.
  
  @festive-onion requested the collapse-on- viewed behavior in #682, a small change that meaningfully improves the review workflow for large diffs.
  
  Full Changelog : v0.19.10...v0.19.11
21. 🔗 r/reverseengineering SASS King Part 2: reverse-engineering ptxas heuristic decisions and what the compiled binary actually reveals rss
  
  submitted by /u/CurrentLawfulness358
  [link] [comments]
22. 🔗 livestorejs/livestore v0.4.0-dev.24 release
  
  Release 0.4.0-dev.24
23. 🔗 r/reverseengineering I just released a C++ rewrite of **Minecraft rd-20090515** (May 15, 2009 — one of the earliest pre-Classic versions).If you find it interesting, a ⭐ on GitHub would mean a lot and help the project grow! rss
  
  submitted by /u/03D_DEV
  [link] [comments]
24. 🔗 r/LocalLLaMA Multi-Token Prediction (MTP) for LLaMA.cpp - Gemma 4 speedup by 40% rss
  
  | Implemented Multi-Token Prediction for LLaMA.cpp. Quantized Gemma 4 assistant models into GGUF format. Ran tests on a MacBook Pro M5Max. Gemma 26B with MTP drafts tokens 40% faster. Prompt: Write a Python program to find the nth Fibonacci number using recursion Outputs:
  LLaMA.cpp: 97 tokens/s
  LLaMA.cpp + MTP: 138 tokens/s Gemma4-assistant GGUF Quantized models: https://huggingface.co/collections/AtomicChat/gemma-4-assistant-gguf Local AI models app: http://atomic.chat Patched llama.cpp: https://github.com/AtomicBot-ai/atomic-llama-cpp-turboquant submitted by /u/gladkos
  [link] [comments]
  ---|---
25. 🔗 jank blog jank now has its own custom IR rss
  
  Good news, everyone! jank has a new custom intermediate representation (IR) and we're using it to optimize jank to compete with the JVM. We'll dive into more of that today, but first I want to say thank you to my Github sponsors and to Clojurists Together for sponsoring me this whole year. You all are helping a great deal. I am still searching for a way to continue working on jank full-time with an income which will cover rent and groceries, so if you've not yet chipped in a sponsorship, now's a great time!
26. 🔗 matklad Steering Zig Fmt rss
  Steering Zig Fmt
  
  May 8, 2026
  
  Two tips on using zig fmt effectively. Read this if you are writing Zig, or if you are implementing a code formatter.
  
  For me, zig fmt is better than any other formatter I used: rustfmt, the one in IntelliJ, deno fmt. zig fmt is steerable. For every syntactic construct, it has several variations for how it might be laid out. The variation used is selected by looking at what’s currently in a file.
  
  Easier to show a pair of examples:
```
    f(1, 2,
      3);

// -> zig fmt ->

    f(1, 2, 3);


    f(1, 2,
      3,);

// -> zig fmt ->

    f(
        1,
        2,
        3,
    );
```
  Depending on the trailing comma, function call is formatted on a single line, or with one argument per line.
  
  The way this plays out in practice is that you decide how you want to lay out the code, add a couple of ,, hit the reformat shortcut (, p is mine), and zig fmt does the rest. For me, this works better than the alternative of the formatter guessing. 90% of great formatting are blank lines between logical blocks and tasteful choice of intermediate variables, so you might as well lean into key choices, rather than eliminate them.
  
  I know of one non-trivial formatting customization point: columnar layout for arrays:
```
    .{ 1, 2, 3,
       4, 5, 6, 7, 8, 9, 10, 11,  };
```
  One would think that trailing comma would lead to a number-per-line layout, but, for arrays, zig fmt also takes note of the first line break. In this case, the line break comes after the first three items, so we get three numbers per line, aligned:
```
    .{
        1,  2,  3,
        4,  5,  6,
        7,  8,  9,
        10, 11,
    };
```
  How cool is that!
  
  Furthermore, with judicious use of ++ (array concatenation), you can vary the number of items per line. When I need to pass --key value pairs to subprocess, I often go for formatting like this:
```
try run(&(.{ "aws", "s3", "sync", path, url } ++ .{
    "--include",            "*.html",
    "--include",            "*.xml",
    "--metadata-directive", "REPLACE",
    "--cache-control",      "max-age=0",
}));
```
27. 🔗 Armin Ronacher Pushing Local Models With Focus And Polish rss
  I really, really want local models to work.
  
  I want them to work in the very practical sense that I can open my coding agent, pick a local model, and get something that feels competitive enough that I do not immediately switch back to a hosted API after five minutes. There are a lot of reasons why I want this, but the biggest quite frankly is that we're so early with this stuff, and the thought of locking all the experimentation away from the average developer really upsets me.
  
  Frustratingly, right now that is still much harder than it should be but for reasons that have little to do with the complexity of the task or the quality of the models.
  
  We have an enormous amount of activity around local inference, which is great. We have good projects, fast kernels, and people are doing great quantization work. A lot of very smart people are making all of this better, and yet the experience for someone trying to make this work with a coding agent is worse than it has any right to be.
  
  Putting an API key into Pi and using a hosted model is a very boring operation. You select the provider, paste the key and then you are done thinking about how to get tokens. Doing the same thing locally, even when you have a high-end Mac with a lot of memory, is a completely different experience. You choose an inference engine, then a model, then a quantization, then a template, then a context size, then you've got to throw a bunch of JSON configs into different parts of the stack and then you discover that one of those choices quietly made the model worse or that something just does not work at all.
  
  That is the gap I am interested in.
  
  Runnable Is Not Finished
  
  A lot of local model work optimizes for making models runnable. That is necessary, but it is not the same thing as making them feel finished. I give you a very basic example here to illustrate this gap: tool parameter streaming.
  
  For whatever reason, most of the stuff you run locally does not support tool parameter streaming. I cannot quite explain it, but the consequences of that are actually surprisingly significant. If you are not familiar with how these APIs work, the simplest way to think about them is that they are emitting tokens as they become available. For text that is trivial, but for tool calls that is often not done, despite the completions API supporting this. As a result you only see what edits are being done on a file once the model has finished streaming the entire tool call.
  
  This is bad for a lot of reasons:
  - A dead connection is a weird connection: local models are slow, so when you don't get any tokens for 5 minutes then you can't tell if the connection died or just nothing came. This means you need to increase the inactivity timeouts to the point where they are pointless.
  - You won 't see what will happen: if you are somewhat hands-on, not seeing what bash invocation the system is concocting slowly in the background means potentially wasted tokens, and also means that you won't be able to interrupt it until way too late.
  - It 's just not SOTA. We can do better, and we should aim for having the best possible experience. Tool parameter streaming is as important as token streaming in other places.
  Having a model spit out tokens doesn't take long, but making the experience great end to end does take a lot more energy.
  
  Fragmentation
  
  The local stack is fragmented across many engines and layers. There is llama.cpp, Ollama, LM Studio, MLX, Transformers, vLLM, and many other pieces depending on hardware and taste. All of these are amazing projects! The problem is not that they exist or that there are that many of them (even though, quite frankly, I'm getting big old Python packaging vibes), the problem is that for a given model, the actual behavior you get depends on a long chain of small decisions that most users just don't have the energy for.
  
  Did the chat template render exactly right? Are the reasoning tokens handled in the intended way? Is the tool-call format translated correctly? Is the context window real? Are the KV caches actually working for a coding agent? Did I pick the right quantized model from Hugging Face? Are you accidentally leaving a lot of performance on the table because the model is just mismatched for your hardware? Does streaming usage work across all channels? Does the model need its previous reasoning content preserved in assistant messages? Is the coding agent set up correctly for it?
  
  You also need to install many different things in addition to just your coding agent.
  
  All of these things matter. They matter a lot.
  
  The result is that people try a local model and get a result that is neither a fair evaluation of the model nor a polished product experience and this results in both people dismissing local models and energy being distributed across way too many separate efforts instead of getting one effort going great end to end.
  
  This is a terrible way to build confidence.
  
  Too Little Critical Mass
  
  In line with our general "slow the fuck down" mantra, I want to reiterate once more how fast this industry is moving.
  
  Every week there is a new model and a new vibeslopped thing. The attention immediately moves to making the next thing run instead of making one thing run really, really well in one harness. I get the excitement and dopamine hit, but it also means that too little critical mass accumulates behind any one model, hardware, inference engine, harness combo to find out how good it can really become when the entire stack is built around it.
  
  Hosted model providers do not ship a bag of weights and ask you to figure out the rest, and we need to approach that line of thinking for local models too. I want someone to pick one model, pairs it up with one serving path, directly within a coding agent. Initially just for one hardware configuration, then for more. Pick a winner hard. If a tool call breaks, that is a product bug and then it's fixed no matter where in the stack it failed. If the model's reasoning stream is malformed, that is a product bug. If latency is much worse than it should be, that is a product bug. We need to start applying that mentality to local models too.
  
  And not for every model! That is the point. Let's pick one winner and polish the hell out of it. Learn what it takes to make that one configuration good, then take those learnings to the next config.
  
  The DS4 Bet
  
  This is why I am excited about ds4.c. It's Salvatore Sanfilippo's deliberately narrow inference engine for DeepSeek V4 Flash on Macs with 128GB+ of RAM only. It is not a generic GGUF runner and it is not trying to be a framework. It is a model-specific native engine with a Metal path, model-specific loading, prompt rendering, KV handling, server API glue, and tests.
  
  DeepSeek V4 Flash is a good candidate for this kind of experiment because it has a combination of properties that are unusual for local use. It is large enough to feel meaningfully different from many smaller dense models, but sparse enough that the active parameter count makes it plausible to run. It has a very large context window. Since ds4.c targets Macs and Metal only, it can move KV caches into SSDs which greatly helps the kind of workloads we expect from coding agents.
  
  To run ds4.c you don't need MLX, Ollama or anything else. It's the whole package.
  
  Embedding It In Pi
  
  Which made me build pi-ds4 which is a Pi extension to directly embed the whole thing into Pi itself. Taking what ds4 is and dogfooding the hell out of it with a coding agent and zero configuration. To answer the question how good can the local model experience become if Pi treats this as a first-class provider rather than as a pile of manual configuration?
  
  The extension registers ds4/deepseek-v4-flash, compiles and starts ds4-server on demand, downloads and builds the runtime if needed, chooses the quantization based on the machine, keeps a lease while Pi is using it, exposes logs, and shuts the server down again through a watchdog when no clients are left. It doesn't even give you knobs right now, because I want to figure out how to set the knobs automatically.
  
  This is not about hiding the fact that local inference is complicated. It is about putting the complexity in one place where it can be improved, because there is a lot that we need to improve along the stack to make it work better.
  
  I think we can do better with caching and there is probably some performance that can be gained if we all put our heads together.
  
  Focusing and Learning
  
  The experiment I want to run is not "can a local model run?" because we already know that it can. I want to know if, for people with beefed-out Macs for a start, we can get as close as possible to the ergonomics of a hosted provider with decent tool-calling performance: how to get caches to work well, how to improve the way we expose tools in harnesses for these models, and then scale it gradually to more hardware configs and later models.
  
  I also want everybody to have access to this. Engineers need hammers and a hammer that's locked behind a subscription in a data center in another country does not qualify. I know that the price tag on a Mac that can run this is itself astronomical, but I think it's more likely that this will go down. Even worse, Apple right now due to the RAM shortage does not even sell the Mac Studio with that much RAM. So yes, it's a selected group of people where ds4.c will start out.
  
  But despite all of that, what matters is that a critical mass of pepole start to focus their efforts on a thing, tinker with it, improve it, not locked away, out in the open, and most importantly not limited by what the hyperscalers make available.
  
  But if you have the right hardware and you care about local agents, I would love for you to try it within pi:
```
pi install https://github.com/mitsuhiko/pi-ds4
```
  My hope is that this becomes a useful forcing function to really polish one coding agent experience. But really, the focal point should be ds4.c itself.
May 07, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-05-07 rss
  IDA Plugin Updates on 2026-05-07
  
  Activity:
  - augur
    
    b1402e4f: chore: use workspace lints and add some restriction lints
  - capa
    
    c57422f9: Sync capa rules submodule
  - haruspex
    
    a6242685: fix: typo
    
    449424d9: fix: lints
    
    e19bf4d4: chore: use workspace lints and add some restriction lints
  - idafridascript
    
    ef2ebf74: fix(flutter_ssl_bypass): update comments and delay hook initialization
  - idawilli
    
    7f2ed4f0: idawilli: add idawilli.syntax for syntax highlighting with rich
    
    d6552f8f: migrate to pyproject and lint/format
  - pdb
    
    53b060e8: 改为通过LATEST_IDADIR环境变量来控制输出路径
  - rhabdomancer
    
    9554e1ee: fix: lints
    
    693d0460: chore: use workspace lints and add some restriction lints
2. 🔗 r/LocalLLaMA Collected the infinity stones rss
  
  | 2.3 TB of ram in here. 400+ vCores. All thats left is plugging it to the blackwell with the driver to do RDMA, and it’s over. Using Blackwells for prefill, RDMA to the studio mesh for decode. I think this would be the first heterogeneous cluster. I do, however, need help with the Tinygrad Driver to make this work. If anyone with any knowledge on these domains would like to collaborate, let me know via PM. We are very close here. submitted by /u/Street-Buyer-2428
  [link] [comments]
  ---|---
3. 🔗 r/Yorkshire Whitby - North Yorkshire rss
  
  | submitted by /u/tomthefear
  [link] [comments]
  ---|---
4. 🔗 r/Leeds What should I do about the stressed koi at a restaurant? rss
  
  I'm at a restaurant in Leeds, I'm sure you could figure out which one, which has a koi pond in the middle of the restaurant. It's covered by a large bridge and a thick mesh, and the fish are showing classic signs of stress (not moving, sitting near the bottom, jumping out of the water, and gasping at the surface). Is there a way for me to advocate for better health for them or is it a lost cause as they are the restaurant's property and technically taken care of? Sorry if this is silly it just makes me sad to see them in a bad state.
  
  submitted by /u/moonstone7152
  [link] [comments]
5. 🔗 r/york Goose on Dame Judi Dench Walk rss
  
  | Honk submitted by /u/NervousEnergy
  [link] [comments]
  ---|---
6. 🔗 sacha chua :: living an awesome life Emacs Chat 22: Shae Erisson rss
  [2026-05-08 Fri]: Transcript, yay!
  
  I chatted with Shae Erisson about Emacs, keyboards, Org Mode, and life.
  
  View it via the Internet Archive, watch/comment on YouTube, read the transcript online, download the video / MP3 / transcript, or e-mail me your thoughts!
  - Shae Erisson: Haskell, Python, Swedish, knitting, mountain unicycling, contact juggling
  - Shae Erisson's blog - 1. DO SOMETHING 2. BRAG ABOUT IT
  - Shae Erisson (@shapr@recurse.social) - recurse.social
  - Shae Erisson's blog - Programmers want flow. when programming, light turns RED
  - shapr/markovkeyboard: keyboard layout that changes by markov frequency · GitHub
  Chapters
  
  0:07 Intro
  
  1:01 1999, IRC, community building in Haskell
  
  2:02 Emacs as a light-weight build-your-own-editor toolkit
  
  2:55 LSP, treesitter, Magit, jujutsu, C++, Python, Haskell, rust
  
  3:38 how does a new person experience Emacs? Emacs is always fun.
  
  4:07 Markov keyboard project, moving to Finland, right-handed Dvorak, split keyboard; Jeff Raskin; I am not a koala
  
  6:45 Purpose-specific function keys
  
  7:34 Trackballs, scroll
  
  8:17 1" trackpad rings
  
  8:58 Pair programming: ttyshare, shwim
  
  13:20 Recurse Center, "What is that keyboard? What is that editor?!", Emacs bankruptcy and starter kits
  
  16:09 hippie-expand
  
  17:18 yasnippet
  
  19:01 Function keys
  
  20:05 Org Mode
  
  21:17 Show Org agenda when idle
  
  22:03 Programmers want flow. When programming, light turns red
  
  24:27 ef-themes and modus-themes, season
  
  25:58 htmlize (does this still work on Wayland?)
  
  26:40 lsp-ui-imenu, jumping through rust code
  
  28:30 laptop with 126GB of RAM
  
  29:48 LSP coolness, Haskell, treesitter
  
  32:02 Combobulate
  
  32:52 What else are you using your 126 gigabytes of RAM for?
  
  33:27 TalonVoice
  
  34:46 NixOS, following Steve Purcell about 5 years behind
  
  35:06 envrc
  
  35:54 time-tracking
  
  37:05 taxes with Org Mode, remote lookup
  
  41:02 finding notes with C-s
  
  42:38 Org Mode, managing inbox
  
  46:30 Timestamps
  
  49:14 Org timers
  
  53:56 Org Mode snippets
  
  57:16 Compilation finish function: handle success
  Transcript
  
  Transcript
  
  0:00 Intro
  Sacha: Okay, so I'm going to actually remember to hit go live. I've got a 10 second delay, so if we need to panic, we can panic. Okay, so let's see. I think we are live. Hi, everyone. This is Emacs Chat number 22 after a long hiatus. And today, I'm here with Shae Erisson, who is also like an Emacs friend from a long time back. So this is it. As you were just saying, this is the first time we're actually talking live. And I'm looking forward to hearing about your configuration, how you use Emacs, Shae. But before we dive into that, can you give us a little bit of context? Who you are, what sorts of things you do, and how you use Emacs for that?
  0:57 1999, IRC, community building in Haskell
  Shae: I would say that... I guess I started using Emacs in 1999 when I moved to Finland. And I remember about the same time I was on IRC and I was really frustrated. I remember I got on the Perl IRC channel and I was like, hey, I want an editor that has syntax highlighting. I want to see colors to these words when I'm typing them. And they were like, noob, and they kick-banned me. And I was like, well, maybe I don't want to learn Perl, which I never did. And I guess that was an early introduction into I wanted to be part of communities where people were sharing positive things and building up each other. Actually, I ended up starting the Haskell IRC channel a couple of years later, and that became a very big thing. I would say that I'm mostly known for my work in community building in the Haskell programming language community, because I did that for, I don't know, 15 or 20 years. But I really like Emacs.
  1:58 Emacs as a light-weight build-your-own-editor toolkit
  Shae: So like last week at the same time I had the standing chat with a friend of mine who is also a programmer and he said oh so you're going to do this thing in a week do you want to give me like a preview of the talk and I was like yeah I guess so and some of the things that were really interesting was he was like I've never really tried Emacs I don't know much about it I kind of have this impression that it is a very lightweight build your own editor toolkit and I I was kind of taken aback because, you know, I guess I still have this long ago and far away. I don't know if you remember 8 Megs and Constantly Swapping is what people used to call Emacs and things like that. And I was, it was just kind of, I realized I'm still in my little echo chamber. And this is why I like to talk to other people all the time is because I want to have some exposure to what other people are doing.
  2:51 LSP, treesitter, Magit, jujutsu, C++, Python, Haskell, rust
  Shae: I guess things about Emacs that really changed stuff for me is language server protocol, TreeSitter. Those, I think, are two very powerful tools that are much more generic than, I mean, Magit, of course, is like magic. Although I've mostly switched to jujitsu lately instead for the last year. Let's see, I had, I guess, let's see, I did C++, I did Python, I did a whole lot of Python. And then I had Haskell jobs for five or six years. And then I switched to Rust about a year and a half ago. I now have a Rust job. And one of the things that Prot had asked, I think, or you had asked, and I forget exactly how this went.
  3:35 how does a new person experience Emacs? Emacs is always fun.
  Shae: It was great fun watching your livestream. And it was, how does a new person kind of get comfortable with using Emacs for a particular purpose. And I look for things, in fact, like how do I use Emacs for Rust, Rust development? And I found a couple of good guides on, and I was able to follow most of them, although my Yesnitit stuff is broken and I don't exactly know why tab doesn't work, right? But, you know, like there's always, Emacs is always fun, right? There's so many cool things you could do with it.
  4:03 Markov keyboard project, moving to Finland, right-handed Dvorak, split keyboard; Jeff Raskin; I am not a koala
  Shae: I noticed, I actually hadn't seen your preview page and I noticed that you found my Markov keyboard.
  Sacha: When you say Emacs is fun, I'm reminded of all of your fun, crazy keyboard experiments. It's like, what? I have a feeling you like to tinker with things.
  Shae: Yeah, so I think actually the influences as to how I got to where I am are pretty interesting. So the person that I ended up moving to Finland to for dating her, we started a company, we did projects, and I was the programmer. We had this pretty big project. I guess it was like 350,000 euros. And I mean, that was going to be over four years and we had to kind of complete the whole thing, and I was the programmer and we'd had the lowest bid... I had an IBM model M, you know, the super clicky with like all the... And about three years into it, my arm started really hurting a lot. But I was the only programmer. And nobody else knew all the code. And we had to ship it, because that's how we got paid. And so I ended up pushing through. And at the end of it, my arm just didn't work anymore. So for about a year and three months, what I did was I actually taught myself to type right hand. ...Dvorak, because I was already using two-hand Dvorak, and so I kept programming, but I just... One of the things was... like, I like programming, I like using computers, I don't want to wear out my arms again, I don't want to blow them out, so I ended up switching to split keyboards, and I will show you. This is very much the kind of thing that I like to use, and that is like this.
  Shae: This is an Ergodox Infinity, but there's a lot of other keyboard flavors like this. And one of the things that I particularly like about this... So around the same time I met Jeff Raskin, who wrote the Inhumane Interface. And so for this particular thing, this is like Control and Alt and Hyper and Super and Shift. And this means that under one thumb, I have a lot more modifier keys than you get off of a standard. And it also means... A lot of my problems started with Emacs pinky, the dreaded, the infamous... I think that one of my... I made a keyboard layout called "I am not koala." You may not know this, but koalas have two thumbs. They have one on each side. And that's cool, but I don't have two thumbs, and I realized that when I was trying to grab something, I didn't put my pinky on it. That would be silly, right? I want to put my thumb around it. And so I decided I would move all of my chording keys under my thumbs. And that's kind of how I...
  6:43 Purpose-specific function keys
  Shae: And another thing I did was when I was really only able to use one hand, was I made my function keys mostly purpose-specific. And that was from Jeff Raskin's writings in The Humane Interface. So I guess I'm a programmer who really likes writing code, doesn't want to wear out my arms, and likes to do fun keyboard things, yeah.
  Sacha: Definitely. You're in it for the long term. You don't want to use up all of your arm capacity now and not be able to keep programming in the future. And now there's hardware to make that easier. So I'm glad. Split keyboards with extra thumb keys seem to be very popular in the Emacs community. I'm now tempted to find space in my desk in order to make that happen.
  7:30 Trackballs, scroll
  Shae: Another thing I ended up switching to was I started using trackballs. Oh yeah, yeah. I tend to go completely overboard when trying out new things, so I bought 20 different models of trackballs and ended up settling on this one. The nice thing about this one is that this is how you scroll, and it has four buttons.
  Sacha: That is really cool. I like using ThinkPads, so I've been just living off the tiny little mouse in the middle of the keyboard. But back in the day, I also used a trackball. If I can get to the point where I want to take my hands off the keyboard again in order to do mouse things, that would probably be the direction I would go.
  8:14 1" trackpad rings
  Shae: I had an experiment in that area, which is where I purchased a one-inch touchpad, and I strapped it to my finger. And it was a PS2, and it had a USB converter plugged into it. And the idea was I could keep typing, and then I could move the mouse around without taking my hands off the keyboard. And now they actually have touchpad rings. They came out six months or a year ago. It's relatively recent. But the idea is no change in context.
  Sacha: I've only seen the scroll rings, but now there's a touchpad version. That is interesting.
  Shae: Yeah, I think that's pretty cool stuff. Hardware is actually improving things.
  8:54 Pair programming: ttyshare, shwim
  Shae: Oh, another thing, one of the things you talked about with Prot was how do you learn other people's stuff? And one of the things that I use for pairing, so I have one coworker, and it's a strange, interesting job. I like it a lot. And I met this coworker at a previous job, and one of the things, let's see if I can find it. So we used to, at the previous job, we used this thing called ttyshare. Have you heard of it? ttyshare. It's great. You can run it in a terminal and then you can effectively share your terminal with someone else. And so you have multiplayer terminals and that's neat. It was kind of a pain to set up. You had to make sure that you weren't NATed, you know, like you had to have effectively... someone had to have a public IP. You had to do a couple of other things. And as part of my job, I'm now, I guess, part maintainer for Magic Wormhole, the software.
  Shae: And so one of the things that my coworker wrote was this nifty thing called ShWiM. And it's basically "shell with me." And it's a wrapper around TTY share so that with one single command, you can share a terminal. And the way that we use this is... We both run Emacs as a server, and then we use emacsclient in the terminal to connect.
  Shae: I don't know if you've ever done this, but I can have a terminal right next to this, and if I run emacsclient in a window, then I'm sharing the same thing. This is a graphical chat with Sacha, in the terminal or in the UI, and both of them are updated.
  Sacha: That's fantastic. I remember people were using tmate for something similar before where you could share that. But yeah, it's just making it seamless, making it frictionless. And on the other side, I have also just been using wormhole to send large files back and forth between Karthik and John Wiegley because we have this other Emacs chat thing where we're going to post it eventually, once I finish figuring out how to redact all the personal information and Org files. But yeah, it's great for being able to send things without having to worry about, oh, you know, what's my public IP? Can I tunnel all the different things to get past whatever firewalls there are? So if this also works for terminal things plus Emacs client, that sounds really, really exciting.
  Shae: We've tried some other experiments. One of the things we tried to do was, and the only downside is like, what if my terminal has a different size, then you have to kind of shrink and match. And so we tried to honestly directly bridge to Emacs clients. And because I don't know if you're aware that there's effectively a local socket for the Emacs client that you can have multiple things connect to. But it turns out there's some sort of like system so I couldn't like reach across the network and directly use my co-workers Emacs session and he couldn't use mine. Weird things happened when we tried to do this cross host. As far as I can tell the Emacs client only works in the same host.
  Sacha: That's interesting. Lately, I've also been experimenting with CRDT, which has that Emacs-less plant as well. So that's been nice. But yeah, of course, a lot of people will be kind of stuck with the first challenge of finding someone that they can pair in Emacs with.
  Shae: I understand. And I think I'm honestly very happy that my one single coworker at this job is also a big Emacs user. And so we exchanged cool ideas and worked on stuff. And I'm very happy about that.
  Sacha: Were they already an Emacs person before they joined? Or did you pick the coworker because they were an Emacs person?
  Shae: They picked me. They were pretty much the person who started this thing. And they picked me because they'd worked with me at the previous job. Although I did have an experience like that. I had this massive Emacs config file, like 20,000 lines, and half of it was comments because it had accrued over 20 years.
  13:13 Recurse Center, "What is that keyboard? What is that editor?!", Emacs bankruptcy and starter kits
  Shae: And in 2019, when I first went to the Recurse Center, well, my first batch, I just was extremely extroverted and social. But my second immediate following batch, which is not the common pattern, I was like, okay, my goal is to write a bunch of Haskell, get some Haskell jobs, And so I went to the quiet room on the quiet floor. But then someone else came in, Marianne, my favorite programming friend. And she was like, what is that keyboard you're using? And I was like, ah, this is an Ergodox thing. And then she's like, what is this editor you're using? And I was like, oh, that's Emacs. And I was kind of a grumpy, like, I'm trying to get stuff done. But she was persistent. She was like, show me this thing. And so I was like, I'll show you Emacs. And she was like, this is great. And I was like. This thing? OK, cool. And I was like, I don't think you want my config. You'll probably want a starter kit. And she was like, well, what are starter kits? And I was like, well, I've heard about Spacemacs. I've heard about Doom. And I would try one of those. So she tried Spacemacs. And I guess this next part happened over several months. She tried Spacemacs. And then she was like, I like it, but it's slow. So I'm switching to Doom Emacs. And I would pair with her. And I was like, wow, look at all these cool things that the starter kits can do. I ended up flushing my entire 20-year-old config and kind of starting over and stealing a lot of great ideas from the starter kits. And Marianne is very ambitious, independent, hardworking, very focused. I'm not very focused. But I've learned a lot of things from her and watching her kind of... I haven't done C in Emacs in a long time so it's great fun to watch her learn these new things and then I learned stuff too and yeah it's good to have collaborative people to work with.
  Sacha: So it sounds like if people would like to encourage more people to talk to them about Emacs, feel free to use your strange keyboards out in public.
  Shae: I like that. That's good. That is good. Yeah I think that's reasonable.
  Sacha: Yeah, and I've just recently started digging into the starter kits too, because I realized I don't know much about them. It is really interesting going through them and discovering all these Emacs 31 options that you can enable to simplify your config or improve your workflow and all that stuff. So there's a lot of good stuff in starter kits, even for people who are not newcomers.
  Shae: I agree. And I think there's nothing wrong with just learning a bunch of new things, trying them out, and also throwing them away if you don't like them.
  Sacha: Now that you've declared Emacs bankruptcy and rebuilt your Emacs on top of other people's starter kits, what has made it into your config? What have you kept from those 20 years of tinkering with Emacs that you really wanted to stick around?
  16:06 hippie-expand
  Shae: I think the only thing that has absolutely stuck around is my use of hippie-expand, which is, I believe, a very old... an ancient tool from a different time. Most of the other stuff is kind of gone. Gone to the wayside. But I really like, I honestly really like hippie-expand. And I know that like, I have rarely heard of other people who use hippie-expand. But you use it? I think you just muted yourself.
  Sacha: I also vote for hippie-expand. It's a nice way to try different functions and just say, I just want all these different possible completions to go in there.
  Shae: Yeah. The thing for me that really sold me on hippie-expand is that most of the time when I am... When I'm doing something, I want to say, like, I can already see that word, just pick that one. And so I'll type the first characters and hit, like, meta forward slash, and ta-da, it's usually there. But then sometimes I do really want, like, some Elisp or some other stuff. And so I actually spent a lot of time tuning this the first time.
  17:14 yasnippet
  Shae: I actually only changed it for the first time recently because I was reading a how to write Rust well inside Emacs and they said oh well you want to use yasnippet and so I you know the funny thing is that yasnippet I believe is the thing that got me into Emacs like in 1999 I met this Finnish person Erno Kuusela in Oulu, Finland. Really cool guy. I was like, wow, how do you do this? As soon as you open a file, it's got a substructure and a skeleton. And when you type part of a function or something, it just populates it. And he was like, I'm using this snippet command in Emacs. That's why I was like, what's Emacs? It was very exciting. And at the time, I was using Vim. And Vim was not as, I don't want to say, automatable.
  Sacha: Yeah, now with Neovim and Lua, people are writing more extensions for it. But before, you had to know a lot of magic in order to customize Vim.
  Shae: Right, right. I agree. Let's see, what else do I do? I run my own email server, and I, of course, read my email in Emacs. In GNU, no less. Which is, I know, an NNTP reader, but it's still also a great... I used to use twiddle compile and I think that stopped working like six years ago, so I need to get rid of this comment, but there's still a lot of kind of cruft from earlier times.
  18:52 Function keys
  Shae: Remember how I said that I use function keys to have like purpose specific stuff? This was especially true because, I mean, I had my left arm strapped to my chest for like a year and three months before I even started regaining any flexibility, and that meant that... I'm amazed that you could just map them directly to single commands instead of giving in to the temptation to make them prefixes for longer keystrokes. I didn't really have the choice because I had only one arm that worked. It was just a lot harder to do any chording at the time. I still have a lot of these. F3 I use a lot, which is like, oh, what am I working on right now? That is org-clock-goto. A lot of times, I want to have a terminal that's in Emacs, so that's vterm,
  20:02 Org Mode
  Shae: And I actually really do use the calendar all the time. This is like just switch to whatever it is. Of course, my email is here. You know what, let's see... So this... I don't know, have you seen this before? Have you seen this thing called STARTED in an Org mode file?
  Sacha: I use a STARTED state, yes.
  Shae: Well, I got it from you! So if I look at like, my Org Mode configuration, a lot of this STARTED stuff I have from you, I don't know when, but you were the person who introduced me to it.
  Sacha: It's the reminder that I did start working on this. I tend to get distracted by intermediate tasks, so it's nice to be able to say, try to finish these ones first before you move on to the next thing, maybe?
  Shae: I agree. I have the same thing, yeah. And I keep meaning, because this is... I know that you can put Org Mode configuration into the first TODO item. I would really like to move it into the elisp and I just haven't gotten around to it. And it's been 10 years. I mean, maybe I should just do it.
  21:14 Show Org agenda when idle
  Shae: One of the things I did that I found fun... I really have written almost zero Elisp, but I did actually puzzle my way through this a year ago. Since so much of my life is in Org Mode, I learned how to make timers. This is very close to what you get directly out of how to do timers in Emacs. After some amount of time, I want my Org agenda to pop up because I want to say like, oh, what is the stuff I'm supposed to be doing? And what am I forgetting? What has been scheduled? And what is on my to-do list? And I also like to look at what is the stuff I've been working on lately? And I really like that a lot.
  21:58 Programmers want flow. When programming, light turns red
  Shae: Another thing that I realized is that I had a blog post that was wildly popular. Where did I put it? And it was all about Emacs. I don't know if you saw the... Here we go. It was... Ah, here it is. So here it is in... This is very much an Emacs...
  Sacha: Oh, yeah, I remember that one. I put it in Emacs News. I thought it was great.
  Shae: All right, cool.
  Sacha: I would like the kiddo to sometimes be able to acknowledge this, but this is not happening. Still, yes.
  Shae: Right, right. Yeah, and so this was really fun because, like... I had a friend who was in development and there was like millions of dollars spent on how do you detect whether a programmer is in flow and it came down to if they're typing they're probably in flow so and that was it because they tried to look at EGs and doing all kinds of other stuff but it was like if they're typing don't interrupt them. And I don't know, because I do so much in Emacs, I'm not sure how accurate this was. But basically, that's where I learned to do timers the first time. Or maybe... I don't remember which one I did first. And the idea then was as soon as basically my average typing into Emacs has gone up a certain amount, then it will actually switch to busy. And it works just fine. It was a lot of fun to write.
  Sacha: So yeah, interesting use of getting the activity. I've seen other fun implementations of this. I think there's a c-c-c-combo package that makes some fun animation appear if you're typing really quickly.
  Shae: Oh, oh, yeah. I'm guessing because I think Atom, the Atom editor had that for a while. I guess that's where it came from.
  Sacha: So yeah, because you can instrument Emacs and play around with it, you can certainly do all sorts of things based on that information. Okay, so you've got it, you've got it set up so that when you come back to your computer, it'll show you the stuff that you've been working on. And when you're working on the things, you can tell it to tell the rest of the world not to bug you. Gotcha.
  Shae: That's right. [Sacha: What other fun stuff do you have in there?
  24:25 ef-themes and modus-themes, season
  Shae: I discovered that I love the EF themes. I love the Modus themes. They make me very happy. They're just unreasonably pleasant. As someone who has tried every single Emacs theme ever, they're just my favorite themes.
  Shae: And so, at the moment, it's summer... Where did my summer go? How can this be? There we go. How come I'm in spring? Wait, isn't spring over? Hasn't summer just started? You know what I was thinking would be fun would be take the time of day, and you know that the EF themes has spring, summer, autumn, and winter, and I'm not sure if there are dark versions of each of those, but I thought, like I know that Modus themes will do this like check for the local time of when it turns dark, and then it will go from the light theme to the dark theme as soon as the sun hits, and I was like, well, what if I do that for seasons, you know, wouldn't that be cool?
  Sacha: There's this subtle sense of change as you go through the year. But of course you also have this thing there where you just randomize it.
  Shae: Well, I like that. Sometimes it's like I'm just kind of like, ah, I'm bored. I'm just bored of what I'm looking at. And so I will just change my thing. And it's just time for something. I don't know. It seems to work. It's like it gives me a little brain break from what I was staring at. And I did not know I was going to reset the effects scale, but that's fine. Interesting. What else do I have in here?
  25:56 htmlize (does this still work on Wayland?)
  Shae: Oh, Emacs HTMLize. I'm a little sad. I switched to Wayland. And if I remember correctly, HTMLize only works with, or maybe HTMLize still works, and it's the SVG one that doesn't work. Emacs SVG is a thing that if you're running with an X11 backend, you can turn your current screen directly into an SVG, which is really cute. It does not work in Wayland. I think HTMLize does still work. What other things do I have in here? I don't know. I guess a lot of it lately has been trying to make Rust things work smoothly. I've been trying to do some... I wonder does... Oh, cool. That was not what I expected.
  26:37 lsp-ui-imenu, jumping through rust code
  Shae: I just started doing this thing with imenu. imenu integrates nicely with LSP.
  Sacha: That is a very pretty sidebar thing, and I need to learn how to do that.
  Shae: So because I have all these extra modifiers, my s-i is lsp-ui-imenu. And the reason that what I mostly use that for is when I have like a bunch of Rust code and I want to quickly jump through the structure of it. Basically that integrates with LSP, finds all the definitions, and I can quickly jump through it. I used to use lsp-treemacs for that, but lsp-treemacs puts things in its own order, not quite the same order I want, although treemacs is quite nice. I think that the thing to do is that you and I at some time maybe the next time if we do this again we should set up with a Shwim connection and you and I can both share our Emacs and then you can show me cool things that you do and I can show you cool things that I do and then we can start filing over some of the things. How about that?
  Sacha: That sounds fantastic. I know we'd wanted to experiment with pair programming a long time ago so that sounds like a seamless way to do it. And therefore I will go and figure out how to install shim and get it working. I will probably need your help to actually test it. I don't know, I think I can rustle up. Maybe it'll work off my phone. You haven't tried that. But lspui, okay, so I've just been using straight up imenu, like on Neanderthal, but lsp-ui has this fancy grouping of things and colors and stuff, so I definitely want to check that out.
  Shae: I'm a fan, yeah. I don't know. Do I have anything else exciting that goes with this in here?
  28:25 laptop with 126GB of RAM
  Shae: I will say that at the moment, the system I'm working on, I like buying unreasonably powerful laptops. And so, like, this system has 128 gigs of RAM and 24 cores. My previous laptop has 192 gigs of RAM. Long story short, I end up in a lot of cases where I want to use more memory. I've got all these cores. Can you do something with them? Perhaps you've already seen things like LSP doctor, which will say, have you tried this thing? Have you done this other thing? LSP has really changed
  Sacha: I have not. Sorry, would you like to show me this LSP doctor thing? Because I have not ever seen it.
  Shae: Yeah. Do you use language servers much for your development?
  Sacha: I am only just getting used to having a relatively modern 2018 instead of 2010 laptop. And so I have the red squigglies and various things, but I don't know what to do with them yet.
  Shae: Well, I mean, I'm doing a lot of this. So I have...
  29:46 LSP coolness, Haskell, treesitter
  Shae: Originally for me it was like I spent a lot of time with the Haskell language server because I was doing so much Haskell and it was a super powerful thing. In fact, somebody decided to hammer in half of a proof assistant into the Haskell language server and that was magic. You could do incredible stuff with that because you could just grab all of your local variables and transform the whole shape of your function and you could just write little snippets and just have it work. And that was amazing. It wasn't quite... One of the goals that I believe is... For future development of all programming editors, I believe that something like Emacs macros, but instead for abstract syntax trees, I believe this is an essential ingredient that we do not yet have. And I think that TreeSitter is the first step towards there. We now have one of the hats, right? Which is where we can take... TreeSitter is, you know, if you've used it... It is like you write some effectively C code to produce a really fast parser. Or is it like JavaScript that then compiles to C code? I forget exactly how it works. But the nice thing about TreeSitter is, I don't know if you remember, I'm sure you do remember, that if you were writing Python code and you used a triple-quoted string, you had to then add a comment with another quote because regular expressions is how Emacs was doing all the syntax highlighting. And honestly, that was kind of crap. And then there were projects like the Semantic Bovinator that made a full parsing suite in Elisp, which to me is half brilliant and half insane. And then there was TreeSitter, which kind of took over the world because it was... I think that the language server and TreeSitter are the first two of these editor generic pieces, and I suspect there will be more. I think that something where you can modify the abstract syntax tree and then put back to the source is one of those potential paths forward. I hope so.
  Sacha: Yeah, that would be great if you could just do the manipulations and then roundtrip it back into source code. Just regenerate the changed part of your code. That sounds fantastic. So it sounds like you were able to do some kind of manipulation with the Haskell use case that you were describing. Any chance you can show us like the awesomeness?
  Shae: Sadly, that sadly does not work anymore.
  31:58 Combobulate
  Shae: But you know, if you're looking for something in that area, have you heard of a Emacs library called Combobulate?
  Sacha: I have heard of it. I haven't dug into it.
  Shae: So it uses TreeSitter for source code manipulation by, and it's a lot closer to the way that like, you know, in Org Mode, you can like hold meta and arrow to kind of move things around. It uses TreeSitter to let you both move around in the context as well as actually alter the shape. And to me, this is the first step towards this tool that I want, which is where I can write a keyboard macro and have it edit an abstract syntax tree and then spit the results back into the buffer. Yeah.
  Sacha: All right.
  32:46 What else are you using your 126 gigabytes of RAM for?
  Sacha: What else are you using your 126 gigabytes of RAM for?
  Shae: Let's see. Honestly, I'm going to tell you that Rust Analyzer can take a lot of memory. And a Rust compilation can take a lot of cores. And I'm okay with that because I actually, I do like, and I will say that this laptop is actually from this year. So it's a brand new, like, top of the line. But then like, how would I, because I've got like, which I think is a bunch of matrix multiplication hardware. How do I use that from Emacs? I don't know. I'm sure I can find something, you know.
  33:25 TalonVoice
  Sacha: Maybe voice computing?
  Shae: Oh, that's an idea. Yeah, one of my friends, she's using Talon. Have you heard of Talon?
  Sacha: Yeah, I've heard of Talon. There are a couple of videos about people using Talon to code by voice, usually involving memorizing kind of a different alphabet for very quickly accessing different shortcuts. But it sounds really cool, and you sound like you've got the hardware to do something amazing with it.
  Shae: That's true. Well, you know, Talon actually lets you do something very similar to Combobulate, where you can navigate the AST of your source code. You can kind of move around very quickly. I don't know, like, are we like at the end of our? No, no, we're halfway through, right?
  Sacha: We're halfway through. I have about 28 minutes before the kiddo runs out and starts demanding lunch.
  Shae: Okay, well, I feel like I've been driving the structure of our just kind of like dumping random things. Did you have any questions or anything you wanted to cover?
  Sacha: This is all amazing. I come in with no preconceived notions. I'm just like, okay, shapr does cool things with Emacs. Let's hear about it. Let's go, let's go.
  Shae: That works for me. Yeah. I mean, a lot of it's been focused on Rust development lately. Rust and Jujutsu.
  34:45 NixOS, following Steve Purcell about 5 years behind
  Shae: I've been doing a lot of Nix. I'm running NixOS. I don't know if you're familiar, but that's been great fun. It's funny, I feel like I've been following Steve Purcell around from a technical perspective. I'm always about five years behind Steve.
  35:03 envrc
  Shae: I was like, oh, you know, NixOS is kind of a pain with Emacs. And just like this, what was it, NixOS? I forget. Anyway, Steve was like, oh, well, have you tried my library, envrc? And I was like, what's that? And he was like, well, now each buffer can have its own envrc. And I was like, it's perfect. That's exactly what I need. Because previously, every time I switched buffers, it would then go load all of the local everything in Nix. And sometimes that could take a long time, especially if I'm doing Haskell, that could take 10 seconds, and I really don't want that sort of lag. And so Steve Purcell's brilliant library, envrc, says, you know what? Every single buffer can just keep such a thing, and then you can only relit it when you need to. And that's pretty awesome.
  Sacha: That sounds cool, and I should check that out too.
  35:52 time-tracking
  Sacha: @JacksonScholberg has a question. He says, "I was curious about what you were tracking your time working on, how you track it." Is it just Org Clock? So this is how you keep track of the things you're working on and what got interrupted by the new thing that you just added to the stack and so forth?
  Shae: Right. In fact, I have this thing. Honestly, when I sit down on my computer, Just clock in. You'll notice in the bottom right here, we have chat with Sacha, right? And so like, I just kind of clock in stuff. And like, I'm not always, I really kind of need to reorganize my Org mode files because I've been naming them per host because I previously had like a work Org mode and I had a home Org mode. now that my home hardware is also my work hardware I guess and so like I still have my previous laptops things where I'm keeping my events I really need to reorganize things but I mean yeah I schedule things I oh you know I've got a weird thing to show you
  37:01 taxes with Org Mode, remote lookup
  Shae: I decided that it would be great fun to do my taxes.
  Sacha: You are showing me your taxes, do I need to like black out this whole thing?
  Shae: Well, this is actually just an example from the docs. So I could actually share my taxes on it because I mostly don't care. But I think in fact you can figure out exactly how much money I'm making by looking at the open whatever. So the thing about this is that I decided to file all of my tax forms directly into Org Mode spreadsheets and then do remote lookups. So basically each spreadsheet was one particular form. And then once I'd gotten to the bottom, like I need this result, like what's my estimated income? And then I would use the lookup, kind of this cross spreadsheet lookup. And that's how I did my taxes for last year. And then my de facto mother-in-law, she's an accountant, and she didn't exactly do this thing, but it was pretty close. She was like, you've got all your taxes in the spreadsheet. I was like, yeah. And then she looked at it and she was like, what is that? And I was like, anyway. So I got to kind of file everything back out into TurboTax, but that was a fun thing to build.
  Sacha: Yeah, I have something like that too. So for example, whenever I do my tax paperwork, I just have to have like, you know, the step by step checklist. Okay, this is where I need to go to get this number. This is where I can put it in. And then eventually it spits out a table that says, okay, put this in box 11, put this in box 13, so that I don't have to do the steps by hand. Because even before the, you know, for me, I use like simple stacks or whatever, it's web based. But before you get to the point where you can put the numbers in the form, you gotta go to this website, calculate this thing, and Org just makes all of that so much easier.
  Shae: I agree. Yeah.
  Sacha: And this remote lookup thing is something I'm always looking up because Org tables are so powerful, but also I need more examples in my life to remember how to use them.
  Shae: Well, I think it took me four hours the first time to get it all figured out. But I can send you an example without showing it here. I can send you an example because I figured out, I think I've hammered the remote lookup down very thoroughly.
  Sacha: And once you've got it right, you can just keep filling that in or copy and paste it. You have an example of the syntax and that's already all you need.
  Shae: Right. I did run across some limitations of the evaluation method of Org mode spreadsheets. But maybe I've been using them a little too hard, if that makes any sense.
  Sacha: Oh, what kind of limitation?
  Shae: Honestly, I think I finally found a way to say every single... Because it was... So really the way that spreadsheets work is they're much more like Dataflow. And that is just that you end up with, like, either you work from the endpoint, which is like much more Haskell style evaluation, which is where you're like, I need to start here. What depends on this? But in the case where you have a whole bunch of different Org Mode spreadsheets, I think I ended up with this little text style hack where I just ran it a bunch of times. So it's like evaluate, evaluate, evaluate. Because remote lookups I ran, you know, I don't remember. And I think I took notes, but I don't remember. That's one of the great things about Org Mode is that I swear it's my, like, half of my brain is in my Org Mode notes. And whenever I had, I'm like, oh, what was that thing? I'm like, well, fortunately, with my terrible short-term memory, I took copious notes because otherwise I would never be able to get back to it.
  40:55 finding notes with C-s
  Sacha: What is your favorite way of finding those notes?
  Shae: I actually use a lot of C-s just because I kind of have some idea of where they are in my tree structure and I'll also say I use a lot of my Org capture templates and they're not super complicated. I have like a to-do, I have a journal, I have ideas and like random ideas will float into my head like you saw Markov keyboard right it is like the weirdest art piece you've seen all day right and Markup keyboard shows up on the front page of Hacker News once a year or so. And people are like, programmers have gone too far. This cannot possibly be usable by humans or something. And I'm like, well, I don't know. I think it was art. And so a lot of times those things will drop into my head, something like that, where I'm trying to do something else. And so I will quickly write down the idea and then just gotten it out of my head enough that I can continue with what I was doing. And so I have a long list of strange ideas. A recent one was like, you've probably had your teeth worked on once or twice. And you know that the dentist always had to move the light around. And I'm like, but we have really good eye tracking. Wouldn't it make sense to figure out where the dentist or the car mechanic is what they're looking at? And then have the light move around behind them to figure out how to actually light up the place they're looking at, right? We've got vision tracking. Why don't we do this? But I don't really, yeah. I decided maybe I don't want to work on that one right now.
  Sacha: It sounds like an involved project. Yeah. Yeah, yeah, yeah. Okay, so you're capturing, you're stuffing a lot of these ideas into an inbox.
  42:35 Org Mode, managing inbox
  Sacha: A lot of people are probably in the same boat where they've got these inboxes full of ideas. How do you deal?
  Shae: I archive stuff when I'm done with it.
  Sacha: Oh yeah?
  Shae: Yeah, so a lot of times, and I find this very valuable, is like if I look at... Do I have it? Oops, that was not what I meant to do.
  Sacha: Alright, so you basically just do aggressive speed commands, archive, archive, archive, or look at the agenda and just mark a whole bunch of things and say, that's it, that's gone. It was written down and then it can go.
  Shae: Yeah, well, when I'm really done with something, when the thing is finished, then I will just archive it. I mean, do you use Archive much?
  Sacha: I do. I have a function that goes through my inbox file and just archives anything that was marked as done.
  Shae: Oh, nice!
  Sacha: Because that way it clears it up, right? So I'll refile things where I'm like, okay, it's done, but it has important information. I want to put it somewhere else. But if it's just a transitory task that I'm using to remind myself, tomorrow I have to do this, go find the water bottle when it's done, I don't need to know about it in the future. So it's left in my inbox because I checked it off, and then periodically I'll say, clean up inbox. Not only will it remove all of the done things, but if I leave a tag In the title of the task or if the task matches certain regular expressions, it will refile it to the appropriate place in my kind of more permanent thing. So I can say, okay, all of my Emacs related tasks will get automatically refiled to my Emacs category without my having to do that manually.
  Shae: So you're using tagging because I kept trying to do tagging and never quite did it.
  Sacha: I use tagging sometimes when I remember it, but this is also why I use the The regular expression match against the title. I'm using Orgzly on Android to capture the thing on my phone. I might want to say this is a consulting task. File it in the right place so it doesn't get lost in my inbox.
  Shae: Wow. When is your interview so I can learn from your tricks?
  Sacha: This is now. Here we go! You can ask questions. The nice thing about conversations is that we jostle different ideas, and we are like, oh yeah, maybe I should write a blog post about that, because I take it for granted. So now apparently I have to write a blog post about my cleaning up process. My inbox is very long. The other thing, speaking of dealing with really long lists that I picked up from John Wiegley was I also sometimes remember to check this list of random items. So in my agenda, there's also like this, you know, random selection of things that I have not gotten around to thinking about further, but it's there just in case serendipity or boredom make me do something.
  Shae: you know that's... I've thought about having... because you know, I've got the pop-up this little timer that pops up my agenda, but I've thought about maybe adding a section I don't know if I could add a section here but it would be something that says like at the bottom here's two or three random to-do's that have been open for a while just like for garbage collection. Because I know that in Jujutsu, I've got a cool little query that says, if you have any change sets that are more than two weeks old and are not in a permanent branch state, maybe you should do something about them. It's just called to do. It'd be kind of nice to have that for Org Mode as well.
  Sacha: Yeah, it's just, you know, and our brains do these strange things with randomness, right? They're like, oh, I want to see what's new now.
  Shae: Right, right, yeah. Oh, I have a question. You have this thing where you had...
  46:28 Timestamps
  Shae: I saw you taking notes with Prot, and you had this timestamp.
  Sacha: Oh, yeah, yeah, yeah. I'm using it now. Okay, okay. So I have it bound two ways now. I have it as a dabbrev, so dynamic abbreviation, and I also have it as a yasnippet because sometimes I'm using it with either SPC or tab to complete it. And I don't really want to think, I just want to get the timestamp in and then move on. And so abbrevs can run functions to evaluate it. You can insert the timestamp that way. Or yesnippet, of course, can evaluate the thing. And now I have those. It's basically just a wall-clock time so that I can go back and plop in the chapters as time offsets, which are automatically calculated from the YouTube data on when the stream started. So I don't have to manually calculate my chapters. But it's super useful to have these times everywhere. And in this case, during a conversation, I want to be able to say, hey, we talked about something interesting. And then be able to go back to that point in the video later on.
  Shae: So you're matching? Oh, oh, wow.
  Sacha: So my shortcut for yasnippet is "ot" because I never type "ot" elsewhere, and it's close enough. I use Dvorak, so my O is on home row, and T is close by. Also, on the other hand... There you go.
  Shae: Did I already show you that this is actually Dvorak?
  Sacha: Oh, there you go. Now I can see the keycaps. Yeah, earlier it was kind of blurry, but now, yes, yes. So yes, that is my shortcut for inserting the timestamp. I previously added seconds as well, but then I realized that my kind might be false precision. So I just, you know, just use a minute at the moment and then I go back and adjust the timestamps a little bit later. But yeah, you can use abbreviations for all sorts of things, including times and dates and stuff.
  Shae: Have you ever tried Org timestamp?
  Sacha: Yeah, Org timer. So Org timer gives you a relative timestamp, right? You can say Org timer. Oh, okay. So, sorry. Are you talking about the C-u C-c ! or something of that sort? So that's actually what I initially was doing, but then it was too many keystroke word modifiers to remember. And then I had to press RET to select the, you know, thing. So now I just have an abbreviation insert the Org mode formatted timestamp for me. And then I have this code that searches for Org timestamp regular expression and then does the calculation and conversion and stuff.
  49:12 Org timers
  Sacha: So Org timer is a separate thing. It's useful for meetings and things like that. You would say, okay, your Org timer starts at the beginning of the meeting and then you can have a list and it automatically, like if you alt shift enter or something like that in the list, it'll automatically like insert the right timer, relative timer to it. There you go. So there's an org-timer-start. But the reason I didn't go that approach was because then you A. have to remember to actually start the timer and B. then you have to synchronize your time with video time. Which might not have started at the same time. So now I'm just like, okay, wall clock for everything. And then I can do the transformation with whatever I like. And since I'm editing my subtitles in Emacs, I can say, hey, this file started at this time, according to YouTube. And then just, you know, map all of the wall clocks to the appropriate subtitle times.
  Shae: Wow. That's really cool.
  Sacha: Anyway, so timers, relative, absolute, and using abbreviations is great. Which I think actually is a thing that I picked up from Karl. Karl Voit because he also likes to use... He has an abbreviation, not at the Emacs level, but he has an abbreviation on his system level, like with his window manager, so he can use this timestamp trick anywhere, including in Etherpad or wherever else where you want to insert the date and time. That's V-o-i-t, by the way. But yeah, so times are a great way to just leave yourself a pointer to that moment so you can go back to it later.
  Shae: Now I'm curious, how well does that integrate with this sort of thing? Because I really like looking back at my history agenda.
  Sacha: If you have it insert an inactive timestamp, I think it should still show up there. I think it will be a little like those.
  Shae: Yeah, it looks like the... Well, it looks like these two are showing up.
  Sacha: Yeah, yeah, yeah. Yeah, so that's a basic thing that I would have inserted by my either abbrev or... So it's not even dabbrev. It's just regular abbrev in Emacs.
  Shae: What's the difference?
  Sacha: dabbrev is like hippie... Okay, let me just double check here. I feel like dabbrev is sort of hippie expand-ish. It looks in your buffer or possibly other buffers. And I think hippie-expand and dabbrev, they kind of work together. It's an option to have them work together. Okay, so hippie-expand is... Oh, so I see. Hippie-expand is the more advanced version of dabbrev. dabbrev was Dynamic Expand, and Hippie Expand says, yes, that, but try a whole bunch of other things first. But my timestamp thing is actually just done by a regular abbrev, and I will find the thing in my config for "ot". Oh, yeah. I will put it in my chat.
  Shae: My spelling, most people say my emails are spelled really well, but it's only because I have ispell set up.
  Sacha: Yeah, ispell is great. I am learning French and therefore...
  Shae: Oh, c'est très bien. Je parle un peu de français aussi.
  Sacha: Oh, oui. I'm keeping a journal in French on my blog and I have the Tatoeba Project with all the example sentences and I have a consult interface to look up stuff in them so I can just borrow other people's words and try to make it sound more natural. Plus of course the usual searching for words in dictionaries and stuff. Anyway, in the chat, I put in my global abbrev table definition for insert format time string. In case you want to steal that, it's right there.
  Shae: I will definitely save that into my notes here.
  53:53 Org Mode snippets
  Shae: Another thing I use a lot is I use Org Mode snippets. I will tell you that the first time, I guess if I look back at... This is another thing that I have done a lot of in the past, which is where... I love the fact that Org Mode snippets are just executable. I can just run them. I guess two jobs, three jobs ago, there was a case where, because I would keep the results around and look at them, there was a case where, I guess a couple of months before, something got shipped to a customer, and I noticed our database schema had changed and I prevented a tremendous amount of upset and emergency by being like this doesn't look great. I got one from two weeks ago, and it does not match. Something's wrong here. Everybody's like, I don't think so, Shae. And I'm, like, no no no, we do have a problem, we've got to fix this. And they were, like, oh crap! And then I was like, yeah, solved a problem!
  Sacha: Yeah, I basically try to do as much in a snippet instead of in, you know, in a scratch buffer or whatever, just because having that record, the fact that I did it, and also any notes that I had leading up to it and the output of it, it's just so helpful.
  Shae: Oh, I've got a cool thing that I'm doing for work. And that is that our readme file is not only a word file, but we also have the demonstration of our actual thing is done by using like dependent snippets. And so that means that like if you want that, perhaps this is something everyone already knows, I don't know, but we basically are using the results of earlier commands in later places. And the other nice thing about that is that then when we want to check, we have to effectively dock tests, right? When we want to check and see if our software works the way it does in the readme, we evaluate the final Org Mode snippet, which then calls it forward, calls it forward, and then if something goes up or not. Well, I guess I need to fix something. And so it was pretty exciting to put Org Mode niftyness into our, into my Word reading file, you know?
  Sacha: Nice, nice. And you did mention your other coworker is on board with the whole Emacs thing. So that's one of the things that people are often like, I want to use Org Mode and I want to use it for like the documentation or the testing or whatever, but they got to get everyone else on board with the thing. Otherwise it's Jupyter Notebooks or whatever else, right?
  Shae: Right. Okay, so I have a joke for you that I came up with a long time ago, and that is, do you know the only way, there's only one way that Sauron could have organized the invasion of Middle-earth, and do you know what he used?
  Sacha: What?
  Shae: Orc Mode. It's a terrible joke, isn't it?
  Sacha: That's okay. I'm sure someone in the comments will come up with an even worse pun.
  Shae: I'm excited! It's going to be great!
  Sacha: Never underestimate the punniness of the Emacs community.
  Shae: I completely agree. I don't know. Do I have anything else exciting in here?
  57:15 Compilation finish function: handle success
  Shae: I actually really like this one. I used to run all of my tests in compile. F12, I have F12 bound to compile. And one of the things I wanted was, I wanted something where it was, if the compile is successful, don't show me the results, because everything's good. And so since I'm doing stuff in Rust, when I run all the tests, it leaves the buffer up, and I need to get around to actually doing stuff like this for Rustic mode as well, where when the tests pass, just go away, because it's all good. And when the tests don't pass, show me where to... I need to look at the problem. And I got this from Enberg and Emacs, I don't know, 20 years ago. Maybe it was less than 20 years ago, but it probably wasn't. So yeah, there's so much good stuff. Yeah, there's just so much good stuff. And I also like to, oh, look, here we go. You can see that this is long gone, by the way. It's not there anymore.
  Sacha: I have a proper, you know, it's sachachua.com/dotemacs. A lot easier to remember. But yeah, and I think that's, yeah, yeah, I remember that now. defadvice is also obsolete. The new hotness is advice-add or something like that.
  Shae: Oh, really? I'm going to make another TODO item for there.
  Sacha: I was digging through my notes trying to find, do you share your config anywhere?
  Shae: No, but you know, at this point if I share it on YouTube, I might as well just throw it up somewhere. Why not? It's not very exciting. Like if you look at someone like Ross Baker who has magic, like wow, is there some magic coming in from Ross Baker? I'm so excited to see more stuff from him. There's just like, I guess I feel like compared to almost everybody else I know, I feel like a power user. Because I'm like, you know, I wish I could do this thing. A lot of times someone I know is like, well, I did that thing and here's a library. And I'm like, yeah, I'll have to do it. And I just, I guess I feel like I'm a power user. And on the good side, I guess I kind of, I really haven't written that much Elisp ever, like I was saying in the comments during your interview with Prot. And I kind of like to, it's just I guess it's never quite gotten to the top of my stack. And I did decide it was time for me to send money to Parade for at least for themes, if not for like, please teach me some Elisp so I can actually, because you know, it's not that Elisp is hard. It's more like, how do I kind of, what are the things I interact with? What are the words? What's the vocabulary of working with Emacs? I don't actually really know. As a user, sure, I can do cool stuff. I can do Lisp macros. I've done Scheme and Lisp some of the past, but not inside Emacs.
  Sacha: Alright, so let me clarify. After more than 20 years of using Emacs, did you say you feel like a power user or do not feel like a power user?
  Shae: I definitely feel like a power user, but I don't feel like someone who does much of anything with Elisp. I don't really feel like someone who has much of a clue in the internals. And that's not entirely true. I have some of the ideas. But for the most part, I haven't actually needed to know that much about the internals. And sure, I've dug into things like how do you efficiently work with large buffers in your ??, like the ropes data structure and stuff like that. That was more for fun. Although it is something that Emacs does and does extremely well. But I'd kind of like to... There's a lot of things I'd kind of like to change and I don't really have enough of the understanding of the kind of how I would write the Elisp to do it. Here's a good example. When I hit F3, it takes me to the one I'm currently clocked into. Unless I haven't clocked in to something since I started Emacs. And honestly, I would like to use something like org-ql, the Org query language, to go find if I've just started Emacs, and Org does not know about something, you know, I just want you to go search for it. I have so many cores and so much memory, just go find it.
  Sacha: That sounds like an excellent reason to go learn Emacs so that you can have it... If you're not currently clocked in, go find the most recent clocked in task and go there, or maybe present you with a list of things and then go from there. I would love to hear about your Emacs Lisp learning journey because that's one of the big things that moves people from, you know, power users, yes, but users, to using Emacs as a lightweight editor toolkit for something that's custom fit to exactly what their workflow is. And on that note, I'm going to try to wrap up gracefully before the kiddo, you know, just like drags me out here. Thank you so much for doing this. I look forward to more conversations. I'm going to post the transcript and other things like that pretty quickly, I think, because I have this nice workflow now that lets me take screenshots and everything, but there's so much here that I want to unpack. But I hear the kiddo, bye!
  
  #+begin_export 11ty
  
  <a name="end-ec22-transcript"></a></details> #+end_exportbvt
  
  Chat
  
  JacksonScholberg: Emacs is fun
  
  JacksonScholberg: Apple's touchpad is another option
  
  JacksonScholberg: Trackpad
  
  JacksonScholberg: Lol
  
  JacksonScholberg: I was curious about what you are tracking your time working on
  
  JacksonScholberg: How you track it.
  
  JacksonScholberg: You clock in and out to what you are working on. I like that idea.
  
  Bezaar.musicc: That's great!
  
  PuercoPop: the buffer api (properties) is the hardest part for me
  
  charliemcmackin4859: I think you still have a timer going, btw
  
  Find more Emacs Chats or join the fun: https://sachachua.com/emacs-chat
  
  View Org source for this post
  You can e-mail me at sacha@sachachua.com.
7. 🔗 r/Leeds I love this spot. rss
  
  Sidenote : anyone going warehouse this coming Tuesday ?
  
  submitted by /u/Auriv3x
  [link] [comments]
8. 🔗 r/york York City Parade rss
  
  | View from the bus! submitted by /u/York_shireman
  [link] [comments]
  ---|---
9. 🔗 r/reverseengineering The first FREE online WebAssembly Reverse Engineering workbench (and how we built it) rss
  
  submitted by /u/TrustSig
  [link] [comments]
10. 🔗 earendil-works/pi v0.74.0 release
  Changed
  - Updated repository links and package references for the move to earendil-works/pi-mono and @earendil-works/* package scopes.
11. 🔗 The Pragmatic Engineer The Pulse: AI load breaks GitHub – why not other vendors? rss
  Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from last week 's The Pulse issue. Full subscribers received the article below seven days ago. If you 've been forwarded this email, you can subscribe here .
  
  GitHub's reliability has been beyond unacceptable recently: last month, third party measurements pinned it at one nine (right at 90%). This month, reliability has been down to zero nines - 86% - as per a third-party tracker, and last week, things got even worse: a frankly embarrassing data integrity incident, more outages, and a partial explanation from GitHub, eventually.
  
  Data integrity incident
  
  Last Thursday (23 April), this happened: PRs merged via the merge queue using the squash merge method produced incorrect merge commits, when the merge group contained more than one PR. Commits were reverted from subsequent merges: basically, commits were "lost" in the code that was merged!
  
  Thanks to a bug GitHub introduced, the service broke its integrity promise that pull requests would be merged as expected when using squash merge, which is a technique typically used to merge multiple small commits into a single, meaningful commit. This is a big deal: as data integrity promises are some of the most important ones, for services like GitHub.
  
  A total of 2,092 pull requests were impacted, and companies hit by the outage included Modal and Zipline. Effectively, GitHub pushed a bunch of work on affected customers who had to manually untangle and recover lost commits, which GitHub could offer zero assistance with.
  
  Customers had to manually go through their git history and restore missing code. After following manual recovery steps (reverting the squash commit and re-applying commits one by one), all commits should have been recovered.
  
  GitHub later emailed the list of affected commits to customers, but it's odd that GitHub executives seemed to downplay the nature of this outage. After all, an outage that messes with data integrity is a much bigger deal than something like a fall in availability where no data is corrupted.
  
  Can Duruk, software engineer at Modal, was unhappy about GitHub's muted response to the outage:
  
  "The COO going out of their way to find a huge denominator to make the impact appear small feels very dishonest; versus a sincere apology about how this invalidates their entire promise to their customers. We had to dig into their status page about this to even realize they just casually f***ed up our repo."
  
  Outages don't stop
  
  On Monday (27 April), pull requests and issues disappeared from GitHub's web UI:
  
  Pull requests go missing. Source:Mario Zechner Issues also not to be found. Source:David Cramer
  
  This had to do with an Elasticsearch outage on GitHub's backend: the cluster became overloaded and went down. So, while pull requests, issues, and projects didn't vanish altogether, they also didn't show up during the 6-hour-long outage.
  
  There were other outages this week:
  - Some pull requests not showing up (Tuesday, 28 April)
  - Problems with some GitHub Actions (the same day)
  - Incomplete pull requests in repositories (Wednesday, 29 April)
  Also on Tuesday (28 April), security firm Wiz disclosed a critical security issue, where a bad actor could get access to all repositories on GitHub and GitHub Enterprise server by using only a git push command. GitHub fixed the issue on GitHub.com within six hours, but GitHub Enterprise servers that were not updated remain vulnerable.
  
  Famous open source contributor quits GitHub in frustration
  
  On Tuesday, Mitchell Hashimoto, founder of HashiCorp, creator of Ghostty, announced GitHub was unfit for professional work and that he was moving off to Ghostty, the open source terminal that's his main focus. Mitchell's reasoning was dead simple: being on GitHub makes him unproductive (emphasis mine:)
  
  "The past month I've kept a journal where I put an "X" next to every date where a GitHub outage has negatively impacted my ability to work. Almost every day has an X. On the day I am writing this post, I've been unable to do any PR review for ~2 hours because there is a GitHub Actions outage. This is no longer a place for serious work if it just blocks you out for hours per day, every day.
  
  It's not a fun place for me to be anymore. I want to be there, but it doesn't want me to be there. I want to get work done and it doesn't want me to get work done. I want to ship software and it doesn't want me to ship software.
  
  I want it to be better, but I also want to code. And I can't code with GitHub anymore. I'm sorry. After 18 years, I've got to go. I'd love to come back one day, but this will have to be predicated on real results and improvements, not words and promises."
  
  Mitchell's experience suggests that GitHub's official status page is inaccurate from the point of view of a heavy user like himself. The third- party "missing GitHub status page" is likely to be a better estimation: where GitHub's reliability is at zero nines: at 85.51% uptime. That means that a part of GitHub was down for 2-3 hours, per day, on average, for the last 90 days (!!)
  
  Reliability woes: GitHub "not a place for serious work." Source: The Missing GitHub Status Page
  
  Mitchell's complaint sounds straightforward:
  1. As a professional software engineer, it's important to have tools that help you get work done
  2. For months, GitHub has got in the way of his work on open source projects via a flood of outages
  3. It makes no sense to use a product unfit for professional work.
  4. As GitHub shows no signs of improvement, it's worthwhile to move to a different solution which just works
  CTO blames AI agent-fuelled load spike
  
  GitHub CTO, Vlad Fedorov, shared an update on why reliability has been terrible for months at GitHub. He identified the load from agents being much bigger than expected as the culprit. Charts illustrating this were shared by GitHub:
  
  This chart looks eye-catching - but there's just one tiny issue: no Y axis! So, while it tells the story of the load going up slowly and then very fast, we're not told by how much. However, I managed to get data from GitHub, and below is the chart showing the actual load increase over two years:
  
  A load increase of ~3.5x, spread across two years, doesn 't seem so brutal at first glance. It is nothing like a load increase of 10x in a month, and a good chunk of it occurred in recent months. So, why can't GitHub handle it? In a blog post, Fedorov said:
  
  "A pull request can touch Git storage, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, and databases. At large scale, small inefficiencies compound: queues deepen, cache misses become database load, indexes fall behind, retries amplify traffic, and one slow dependency can affect several product experiences."
  
  Here's how the per-second load numbers from January 2023 and today compare:
  
  GitHub took 15 years to achieve the 2023 numbers, and maybe it expected to continue growing in a comparable way in the future. If so, some engineering decisions about long-term infrastructure improvements would have been made obsolete by the arrival of AI agents.
  
  To add to GitHub 's challenges, the company is in the midst of a migration from its own data centers -> Azure. In October last year, GitHub started to move over to Azure - a project expected to take 12 months - because it already had constraints on its own data center capacity.
  
  Such large-scale infrastructure migrations are hard enough when the load on a service is relatively stable; just making sure nothing breaks takes a lot of effort. But moving at a time when load is spiking means that bugs can cause more visible outages. Of course, GitHub can secure a lot more compute capacity on Azure, now they know what to expect.
  
  But other major companies prepared for a 10x increase in infra load, so why not Microsoft / GitHub? A year ago, I did research on how Big Tech was preparing to respond to the impact of AI on their business. Google was improving its internal systems to accommodate for a 10x increase in load. As we covered in The Pragmatic Engineer, in July last year:
  
  "Google is preparing for 10x more code to be shipped. A former Google Site Reliability Engineer (SRE) told me:
  
  "What I'm hearing from SRE friends is that they are preparing for 10x the lines of code making their way into production."
  
  If any company has data on the likely impact of AI tools, it's Google. 10x as much code generated will likely also mean 10x more: code review, deployments, feature flags, source control footprint and, perhaps, even bugs and outages, if not handled with care."
  
  Predicted enormous load increases were not secret knowledge within the industry, yet it seems GitHub was blissfully ignorant of their potential size. According to Vlad, GitHub did eventually plan for a need to increase capacity by 10x, but this was in October 2025, months later. In February 2026, the company is now adjusting that expectation to 30x. He wrote:
  
  "We started executing our plan to increase GitHub's capacity by 10X in October 2025 with a goal of substantially improving reliability and failover. By February 2026, it was clear that we needed to design for a future that requires 30X today's scale."
  
  There's also the question of whether GitHub miscalculated how much time it had to prepare for explosive load growth, and whether it was caught off guard when that growth materialized months sooner than expected at the start of this year.
  
  Given GitHub only started to prepare for a major load increase in October, its current problems are unsurprising. At the scale of GitHub, it's common enough for each team owning a service to plan a year ahead on how much load their service will have, and hardware resources like storage, VMs, and networking are allocated accordingly. Load planning can account for up to half of the preparations, and when reality doesn't conform to plans, some systems can struggle to scale up.
  
  So, on one hand, dealing with a 3.5x increase in load over 2 years should not be such a big deal for most services; especially not ones which can be horizontally scaled (when there's not much state, and scaling is achieved simply by adding new nodes.) But GitHub probably stores a lot more state with pull requests, workflows, projects, etc. This probably makes scaling more tricky when it comes to databases and systems running workflows.
  
  GitHub also has 18 years of tech debt on its hands, and thousands of staff to align as "organizational overhead." As its service load grows faster than before, responding is harder due to all that accumulated "debt":
  - Tech debt: many systems at the company are 10+ years old and are likely patched up, making them more difficult and risky to change
  - Organizational debt: around 4,000 people work at GitHub, of whom 1,000 are engineers. Teams have dependencies with each other, and even seemingly simple work can require dozens of engineers to work together
  - Customer expectations: GitHub cannot break customer workflows, even if doing so would mean changes to systems happen faster
  GitHub finds itself in the 'innovator's dilemma': the company became successful because it built developer workflows that made sense, pre-AI, and it used to be able to accurately forecast service load changes. But now that engineering teams' workflows include AI agents, GitHub's own workflows are not necessarily the best fit, and the company failed to forecast service-level changes.
  
  Other vendors floored by AI load? Not really
  
  One thing that doesn't add up about the situation is that other vendors who are presumably experiencing similar load spikes don't appear to be suffering with reliability issues as much. Vercel, Linear, Resend, Railway, Sentry, and other infra providers see record-level growth thanks to AI, but keep up with the load.
  
  Yes, it's true that AI vendors like Anthropic, OpenAI, and Cursor have some reliability issues, but it's not at the scale of GitHub's. GitHub's direct competitors, GitLab and Bitbucket, presumably see load going up similarly, but they're not going down as much.
  
  An obvious question is how much of GitHub 's pain is self-inflicted? With Microsoft as owner, it has more resources at its disposal than any competitor or startup, and yet failed to predict load increases and is too big to respond with the nimbleness of a startup.
  
  It's undeniable that solving for a major load increase is a hard challenge; it's when the difference between average and standout engineering teams is apparent. GitHub hasn't been responding like a world-class engineering org.
  
  GitHub alternatives?
  
  Every regular user of GitHub feels the pain of ongoing outages. As a dev, you can either hope Microsoft will eventually improve reliability, or seek alternatives. As covered above, Mitchell has chosen to quit and is currently deciding where to take Ghostty.
  
  The obvious alternatives are GitHub's biggest competitors, GitLab, and Bitbucket. Each offers Git hosting, and neither comes with the uptime woes that GitHub is suffering from.
  
  Self-hosted solutions are also an option, like self-hosting your git repo, or going with a self-hosted forge like Forgejo, which is an open source, local-first GitHub alternative.
  
  I also suspect that, soon enough, we'll see startups offering GitHub-like code hosting capabilities, while offering more robust uptime and being architected to handle the 30x-or-more scale which GitHub hopes one day to support.
  
  Read the full issue of last week 's The Pulse , or check out this week 's The Pulse . This week 's issue covers:
  1. Did Anthropic turn hostile on devs because capacity was running low?
  2. Amazon finally allows Claude Code and Codex usage
  3. Meta forcefully assigns engineers to data labelling ahead of job cuts
  4. New trend: small "AI-forward" teams
  5. Industry Pulse: why Meta tracks employees' computer activity, OpenAI starts to move off Datadog, Apple lets slip it uses Claude Code, GitHub -> Xbox transfers at Microsoft, VS Code inserted "coathored by Copilot" even when Copilot did nothing, analysis of the Coinbase layoffs
12. 🔗 r/wiesbaden Freitags essen gehen zu zweit? rss
  
  Moin würde gerne mit einer Freundin an einem Freitag in Wiesbaden essen gehen, es sollte gemütlich sein und nicht so laut. Also eine Atmosphäre haben die es her gibt das man sich gut unterhalten kann. Es sollte vegan/vegetarische Optionen geben. Ich wäre sehr dankbar für eure Tipps da ich mich nicht so gut auskenne.
  
  submitted by /u/JohnTheMonkey2
  [link] [comments]
13. 🔗 r/Leeds why is everyone in fancy dress? rss
  
  I'm in the city centre right now and just wondering why everyone is dressed up? I thought it was the otley run but now I'm unsure because the people in fancy dress are everywhere. This is just me being nosey but I can't find any info about it online so I was wondering if anyone knows.
  
  submitted by /u/MeowTS13
  [link] [comments]
14. 🔗 Simon Willison Notes on the xAI/Anthropic data center deal rss
  
  There weren't a lot of big new announcements from Anthropic at yesterday's Code w/ Claude event, but the biggest by far was the deal they've struck with SpaceX/xAI to use "all of the capacity of their Colossus data center".
  
  As I mentioned in my live blog of the keynote, that's the one with the particularly bad environmental record. The gas turbines installed to power the facility initially ran without Clean Air Act permits or pollution control devices, which they got away with by classifying them as "temporary". Credible reports link it to increases in hospital admissions relating to low air quality.
  
  Andy Masley, one of the most prolific voices pushing back against misleading rhetoric about data centers (see The AI water issue is fake and Data center land issues are fake), had this to say about Colossus:
  
  I would simply not run my computing out of this specific data center
  
  I get that Anthropic are severely compute-constrained, but in a world where the very existence of "AI data centers" is a red-hot political issue (see recent news out of Utah for a fresh example), signing up with this particular data center is a really bad look.
  
  There was a lot of initial chatter about how this meant xAI were clearly giving up on their own Grok models, since all of their capacity would be sold to Anthropic instead. That was a misconception - Anthropic are getting Colossus 1, but xAI are keeping their larger Colossus 2 data center for their own work.
  
  As an interesting side note, the night before the Anthropic announcement, xAI sent out a deprecation notice for Grok 4.1 Fast and several other models providing just two weeks' notice before shutdown, reported here by @xlr8harder from SpeechMap:
  
  This is terrible @xai. I just spent time and money to migrate to grok 4.1 fast, and you're disabling it with less than two weeks notice, after releasing it in November, with no migration path to a fast/cheap alternative.
  
  I will never depend on one of your products again.
  
  Here's SpeechMap's detailed explanation of how they selected Grok 4.1 Fast for their project in March.
  
  Were xAI serving those models out of Colossus 1?
  
  xAI owner Elon Musk (who previously delighted in calling Anthropic "Misanthropic") tweeted the following:
  
  By way of background for those who care, I spent a lot of time last week with senior members of the Anthropic team to understand what they do to ensure Claude is good for humanity and was impressed. [...]
  
  After that, I was ok leasing Colossus 1 to Anthropic, as SpaceXAI had already moved training to Colossus 2.
  
  And then shortly afterwards:
  
  Just as SpaceX launches hundreds of satellites for competitors with fair terms and pricing, we will provide compute to AI companies that are taking the right steps to ensure it is good for humanity.
  
  We reserve the right to reclaim the compute if their AI engages in actions that harm humanity.
  
  Presumably the criteria for "harm humanity" are decided by Elon himself. Sounds like a new form of supply chain risk for Anthropic to me!
  
  You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options.
15. 🔗 r/wiesbaden Erfahrungen mit Autohaus Can in Wiesbadener Str. ? rss
  
  Wer hat Erfahrung mit dem oben genannten Händler? Seriös oder nicht ?
  
  submitted by /u/HagebuddneLard
  [link] [comments]
16. 🔗 r/LocalLLaMA WARNING: Open-OSS/privacy-filter MALWARE rss
  
  There's this new "model" on Hugging Face titled Open-OSS/privacy-filter which is actually a customized infostealer virus. It's a fake version of the OpenAI privacy filter and it uses a Python-based dropper (loader.py) which downloads a malicious PowerShell command from the internet, which spawns another PowerShell command and downloads a shady EXE file and runs it using Task Scheduler.
  
  Here's a behavior analysis of what the EXE does: https://tria.ge/260507-tnftrsfx5x/behavioral1
  
  I also reported both the dropper and the EXE to Microsoft.
  
  I also reported the repo to HF.
  
  If you use Linux (which is easier to use for AI/ML) you are unaffected as this is a Windows virus.
  
  submitted by /u/charles25565
  [link] [comments]
17. 🔗 r/Yorkshire I'm hand-drawing a map of Yorkshire, what places must I absolutely include? rss
  
  Hello, I'm Josh, an artist from Buckinghamshire and I make Tolkien-esque maps of different regions and countries, all drawn by hand with dip pen and ink.
  
  It is high-time I crack on with making a map of Yorkshire, and though I usually research the places I draw extensively, there is nothing like asking locals for insight.
  
  Specifically I’m looking for any landmarks that I may overlook - it could be a waterfall, a beautiful bridge, geological features marvel like a cave or rock pinnacle, even a giant wellington boot - anything significant that you think I need to draw into the map.
  
  I’d also like to know what animal or mythical creature best represents Yorkshire?
  
  Ta!
  
  submitted by /u/NACHODYNAMYTE
  [link] [comments]
18. 🔗 earendil-works/pi v0.73.1 release
  New Features
  - Self-update support for the npm scope migration : pi update --self now supports the upcoming package rename from @mariozechner/pi-coding-agent to @earendil-works/pi-coding-agent. After the new package is published, existing global installs can update through the normal self-update flow; pi will uninstall the old global package and install the package name returned by the version check endpoint.
  - Interactive OAuth login selection : OAuth providers can now present multiple login choices in /login, enabling provider-specific interactive authentication flows. See Providers.
  - JSONC-stylemodels.json parsing: models.json now allows comments and trailing commas, making custom provider and model configuration easier to maintain. See Providers and Custom Providers.
  Added
  - Added interactive login selection support so OAuth providers can present multiple login choices (#4190 by @mitsuhiko).
  Changed
  - Changed pi update --self to honor the active package name returned by the Pi version check endpoint, defaulting to the current package when omitted and uninstalling the old global package before installing a renamed package.
  - Changed extension loading to use upstream jiti 2.7 instead of the @mariozechner/jiti fork (#4244 by @pi0).
  - Changed models.json parsing to allow comments and trailing commas (#4162 by @julien-c).
  Fixed
  - Fixed pi -p treating prompts that start with YAML frontmatter as extension flags instead of user messages (#4163).
  - Fixed pending tool results not updating in the live TUI after toggling thinking block visibility while the tool is running (#4167).
  - Fixed /copy reporting success on Linux without writing the clipboard on Wayland-only compositors (Hyprland, Niri, ...) by skipping the X11-only native addon on Linux and routing through wl-copy/xclip/xsel instead (#4177).
  - Fixed HTML session exports to strip skill wrapper XML from rendered user messages (#4234 by @aliou).
  - Fixed OpenAI-compatible chat completion streams that interleave content and tool-call deltas in the same choice.
  - Fixed OpenAI Codex OAuth refresh failures writing directly to stderr while the TUI is active (#4141).
  - Fixed OpenAI Codex Responses requests to send a non-empty system prompt (#4184).
  - Fixed Kimi For Coding model resolution for the Kimi K2 P6 alias (#4218).
  - Fixed Kitty inline image redraws to stay within TUI-owned terminal regions and avoid writing below the active viewport.
  - Fixed Kitty inline image rendering by letting the terminal allocate image ids and bounding parsed image ids to valid values.
  - Fixed inline image capability detection to disable inline images in cmux terminals.
19. 🔗 r/Leeds Leeds cycle lane network is a 'step in the right direction', say campaigners rss
  
  Just wanted to add a bit of positivity around the new cycle lanes in Leeds, as there seems to be a lot of negativity whenever the topic comes up.
  
  Speaking from personal experience, they’ve genuinely changed my life for the better. Up until last year, I hadn’t really ridden a bike since I was a teenager. But after seeing more segregated cycle lanes appear around my area, I realised I could get from my house into the city centre in under 30 minutes almost entirely on protected infrastructure.
  
  I've started cycling regularly, and eventually I sold my car altogether. I now use my bike every other day for commuting, trips into town, canal rides etc etc. I’m healthier, happier, saving loads of money, and honestly enjoy getting around Leeds far more now. It's hilly in parts but stick to a low gear and it's perfectly manageable, ebikes are great alternatives too and can be purchased through the cycle to work schemes (I saved hundreds on my bike).
  
  I also cycle year-round, and I think people massively overestimate how “hardcore” cycling is in the UK. Our weather really isn’t that different from places like the Netherlands. Most of the time you’re completely fine with a decent jacket.
  
  I know the network still has gaps and improvements to make, but for me it’s been a massive step in the right direction and has made cycling feel accessible to normal people again, not just super confident road cyclists.
  
  Just wondering if anyone else has had a similar experience or enjoys using the bike lanes too?
  
  submitted by /u/_testingdude
  [link] [comments]
20. 🔗 crosspoint-reader/crosspoint-reader sd-fonts-m1-b4: fix: Roundraff theme home menu offset with no recent books (#1845) release
  
  Summary
  
  With the Roundraff theme selected and no recent books, the home screen
  menu shows a "Continue Reading" option and menu handling is offset by
  one ("Continue Reading" actually does "Browse Files", "File Transfer"
  actually does "Settings", etc.) Simple fix here is to omit the "Continue
  Reading" menu item when there are no recent books.
  
  AI Usage
  
  While CrossPoint doesn't have restrictions on AI tools in contributing,
  please be transparent about their usage as it
  helps set the right context for reviewers.
  
  Did you use AI tools to help write this code? NO
21. 🔗 jj-vcs/jj v0.41.0 release
  About
  
  jj is a Git-compatible version control system that is both simple and powerful. See
  the installation instructions to get started.
  
  Release highlights
  - jj fix now supports formatting specific line ranges (allowing you to format
    only modified lines); see the configuration manual and notes below for more.
  - The new global flag --no-integrate-operation will let you run a command without
    impacting the repo state or the working copy, which is useful when automated tools
    may create snapshots in the background.
  Breaking changes
  - The --pattern flag for file search now defaults to regex: instead of glob:.
  - jj git push --all/--tracked/-r REVSETS no longer fails when revisions to
    push are private or have conflicts. Bookmarks which aren't eligible to push
    will be skipped.
  - Branch/bookmark patterns passed to jj git clone are now saved to jj's repo
    settings file instead of .git/config. Git fetch refspecs are set to the
    default value.
  Deprecations
  - In the templating language, the Operation type's .tags() function has been
    deprecated in favor of .attributes().
  New features
  - The --pattern flag for file search now accepts various pattern kinds through
    kind:pattern syntax.
  - A new global flag --no-integrate-operation lets you run a command without
    impacting the repo state or the working copy.
  - A new config option diff.git.show-path-prefix can be used to suppress the
    a/ and b/ path prefixes in the diff --git output.
  - jj fix now supports line range-limited formatting via the fix.tools.<name>.line-range-arg
    and run-tool-if-zero-line-ranges configs. This allows running tools only on modified
    lines and fine-grained control over when the tool is run. If you have set the line-range-arg
    config, use --all-lines to match the previous behavior of formatting the entire file.
  - A new replace(pattern, content, replacement) template function is added
    which supports replacement of content in templates, using a lambda to format
    replacement text. It supports all string patterns, including regexes with
    capture groups (e.g. replace(regex:'(\w+) (\w+)', "hello world", |c| c.get(1) ++ " " ++ c.get(2))).
  - New ByteString template type for things like file content.
  - jj gerrit upload now supports the new options --message (-m), --edit
    and --merged. You can now also pass multiple hashtags by repeating the
    --hashtag option.
  - New remotes.<name>.fetch-bookmarks/fetch-tags options to configure
    default fetch targets.
  - JJ_PAGER can now override the ui.pager config, matching JJ_EDITOR for
    callers that need a jj-specific environment override.
  Fixed bugs
  - Improving consistency with git handling of .gitignore, including /
    after entries and \r\r\n for MacOS files.
  - jj status filters untracked paths by fileset
    #9287
  - Improved performance for snapshotting, visibly improving jj status
    speed for large repositories.
  - Pre-existing Git submodule directories are no longer considered conflicts in
    checkouts. #8065.
  - Fixed a panic in jj gerrit upload when run without -r and the
    inferred revision was immutable. #9398
  - jj status respects path filters in working copy summaries.
  - jj git remote rename/remove now updates the trunk() alias.
  - Commands would sometimes incorrectly diagnose a stale working copy and suggest
    running jj op integrate when it would have no effect. This should now be
    much less likely to happen in practice.
    #9314
  Contributors
  
  Thanks to the people who made this release happen!
  - Adrian Freund (@freundTech)
  - ase (@adamse)
  - Austin Seipp (@thoughtpolice)
  - Benjamin Tan (@bnjmnt4n)
  - Björn Kautler (@Vampire)
  - David Higgs (@higgsd)
  - David Rieber (@drieber)
  - dzaima (@dzaima)
  - Federico G. Schwindt (@fgsch)
  - Gaëtan Lehmann (@glehmann)
  - hewigovens (@hewigovens)
  - Ilya Grigoriev (@ilyagr)
  - jonmeow (@jonmeow)
  - Joseph Lou (@josephlou5)
  - Josh McKinney (@joshka)
  - Jun Mukai (@jmuk)
  - Lucas Garron (@lgarron)
  - Martin von Zweigbergk (@martinvonz)
  - Matt Stark (@matts1)
  - Maximilian Gaß (@mxey)
  - OlshaMB (@OlshaMB)
  - Philip Metzger (@PhilipMetzger)
  - rayaq
  - Remo Senekowitsch (@senekor)
  - rishiad (@rishiad)
  - Ryan Patterson (@CGamesPlay)
  - Sebastian Barfurth (@sbarfurth)
  - Thomas Axelsson (@thomasa88)
  - xtqqczze (@xtqqczze)
  - Yuya Nishihara (@yuja)
22. 🔗 r/reverseengineering VLC Media Player MKV Exploit Analysis rss
  
  submitted by /u/eshard-cybersec
  [link] [comments]
23. 🔗 r/york Different angles on one perfect subject 💫 rss
  
  | submitted by /u/Coffee000Oopss
  [link] [comments]
  ---|---
24. 🔗 r/Yorkshire Prince of Wales praises unstoppable North Yorkshire communities during his visit rss
  
  | submitted by /u/willfiresoon
  [link] [comments]
  ---|---
25. 🔗 livestorejs/livestore v0.0.0-snapshot-57d1c10da041b07ec78ff6f83a6a07cd690b1990: fix: canonicalize event args in equality comparator (#1218) release
  
  Locally-encoded events with Schema.UndefinedOr (or loose
  Schema.optional) fields produce args of shape { ..., flag: undefined },
  while JSON wire transport drops the undefined-valued key. The current
  isEqualEncoded comparator used deepEqual directly on the args, which
  counts keys via Object.keys and treats the two forms as unequal. Sync
  merge therefore falsely took the rebase path when an event came back from
  the sync provider, and state-dependent materializers re-ran on
  already-mutated state — surfacing as MaterializerHashMismatchError.
  
  This regressed in #1161, which replaced
  JSON.stringify(a.args) === JSON.stringify(b.args) with deepEqual to
  fix a key-order bug. The previous form masked the asymmetry because both
  sides were stringified through JSON.stringify, dropping undefined
  symmetrically.
  
  Fix by canonicalizing both args through JSON.parse(JSON.stringify(...))
  before deepEqual. Composes correctly with #1161's key-order fix:
  deepEqual is order-independent (uses Object.keys for membership), and
  the JSON round-trip canonicalizes the value-level shape (drops undefined,
  NaN→null, sparse-array holes) without introducing string-order
  dependency.
  
  Refs #1217.
26. 🔗 livestorejs/livestore v0.0.0-snapshot-40fa62e1f50f8aff0fc69da77c04f8136ae2e510: fix: canonicalize event args in equality comparator (#1218) release
  
  Locally-encoded events with Schema.UndefinedOr (or loose
  Schema.optional) fields produce args of shape { ..., flag: undefined },
  while JSON wire transport drops the undefined-valued key. The current
  isEqualEncoded comparator used deepEqual directly on the args, which
  counts keys via Object.keys and treats the two forms as unequal. Sync
  merge therefore falsely took the rebase path when an event came back from
  the sync provider, and state-dependent materializers re-ran on
  already-mutated state — surfacing as MaterializerHashMismatchError.
  
  This regressed in #1161, which replaced
  JSON.stringify(a.args) === JSON.stringify(b.args) with deepEqual to
  fix a key-order bug. The previous form masked the asymmetry because both
  sides were stringified through JSON.stringify, dropping undefined
  symmetrically.
  
  Fix by canonicalizing both args through JSON.parse(JSON.stringify(...))
  before deepEqual. Composes correctly with #1161's key-order fix:
  deepEqual is order-independent (uses Object.keys for membership), and
  the JSON round-trip canonicalizes the value-level shape (drops undefined,
  NaN→null, sparse-array holes) without introducing string-order
  dependency.
  
  Refs #1217.
27. 🔗 r/Yorkshire 'We're all human': Reform response to Sheffield candidate accused of Nazi praise rss
  
  | submitted by /u/johnsmithoncemore
  [link] [comments]
  ---|---
28. 🔗 r/LocalLLaMA Qwen3.6 27B uncensored heretic v2 Native MTP Preserved is Out Now With KLD 0.0021, 6/100 Refusals and the Full 15 MTPs Preserved and Retained, Available in Safetensors, GGUFs and NVFP4s formats. rss
  
  llmfan46/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved: https://huggingface.co/llmfan46/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP- Preserved
  
  llmfan46/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-GGUF: https://huggingface.co/llmfan46/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP- Preserved-GGUF
  
  llmfan46/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-NVFP4-GGUF: https://huggingface.co/llmfan46/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP- Preserved-NVFP4-GGUF
  
  llmfan46/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-NVFP4: https://huggingface.co/llmfan46/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP- Preserved-NVFP4
  
  llmfan46/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-NVFP4-MLP- Only: https://huggingface.co/llmfan46/Qwen3.6-27B-uncensored- heretic-v2-Native-MTP-Preserved-NVFP4-MLP-Only
  
  llmfan46/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-GPTQ-Int4: https://huggingface.co/llmfan46/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP- Preserved-GPTQ-Int4
  
  All are confirmed to have their full 15 MTPs retained and preserved.
  
  Comes with benchmark too.
  
  Find all my models here: HuggingFace- LLMFan46
  
  submitted by /u/LLMFan46
  [link] [comments]
29. 🔗 livestorejs/livestore v0.0.0-snapshot-fa3f37cccde378135bc5743248899f1267f65cf6 release
  
  Merge pull request #1224 from livestorejs/schickling/2026-05-06-prese…
30. 🔗 livestorejs/livestore v0.0.0-snapshot-e3c31eaabde4b316502663a4322d439564068380 release
  
  Merge pull request #1224 from livestorejs/schickling/2026-05-06-prese…
31. 🔗 livestorejs/livestore v0.0.0-snapshot-b554d716cbedf6eaf7e754b645d826b785dc84fc release
  
  Merge pull request #1224 from livestorejs/schickling/2026-05-06-prese…
32. 🔗 livestorejs/livestore v0.0.0-snapshot-320a6af177312b557c1d1634216e40755b6ac607 release
  
  Merge pull request #1224 from livestorejs/schickling/2026-05-06-prese…
33. 🔗 livestorejs/livestore v0.0.0-snapshot-6c342deaf05be237b189776749a520625a63c433 release
  
  Merge pull request #1224 from livestorejs/schickling/2026-05-06-prese…
34. 🔗 livestorejs/livestore v0.0.0-snapshot-04b628f68dcf3520227c63f52b0a91c411af6b56 release
  
  Merge pull request #1224 from livestorejs/schickling/2026-05-06-prese…
35. 🔗 r/Leeds Does anyone else remember when you could buy cats at kirkgate market ? rss
  
  And pirated dad's,before 2010 and other crazy stuff or I'm I confusing it with the wrong place I'm pretty sure we got a cat from there some time in the 2000's but I could be wrong
  
  submitted by /u/TipAdditional4625
  [link] [comments]
36. 🔗 Console.dev newsletter honker rss
  
  Description: Durable queues for SQLite.
  
  What we like: Adds pub/sub, task queue, and event streams to SQLite. No need for client polling or a broker. Shipped as a SQLite extension with bindings for Python, Node, Rust, Go, Ruby, etc. Allows an INSERT and enqueue as part of the same transaction (with rollback). Also supports cron.
  
  What we dislike: Polling is via a SELECT per millisecond per database, which should be lightweight, but is an extra high-frequency query. Still experimental.
37. 🔗 Console.dev newsletter Plow rss
  
  Description: HTTP benchmarking.
  
  What we like: Runs HTTP requests and benchmarks latency and response codes. Configurable concurrency, duration, request count, and ramp up time. Outputs stats to the terminal in real time. Supports JSON output and provides a web UI.
  
  What we dislike: Pretty straightforward HTTP request support, including different methods e.g. POST (with body). For more complex benchmarks, k6 is a good, scriptable alternative.