标签：#computerscience

Series: Master OOP for Software Engineering Interviews Introduction Ask ten beginner developers: "What is abstraction?" Most answers sound like this: "Abstraction is the process of hiding implementation details and showing only essential information." Technically, that's correct. But if I ask the next question: "Why was abstraction invented?" or "Can you explain abstraction using an Inventory Management System?" or "How is abstraction different from encapsulation?" many candidates struggle. That's because they memorized the definition instead of understanding the idea behind it. In this article, we'll learn abstraction the way experienced software engineers think about it—not by memorizing definitions, but by understanding why it exists, what problem it solves, and how it appears in every modern software system. 🎯 Learning Goals After reading this article, you should be able to: Explain abstraction without memorizing a textbook definition. Understand why abstraction exists. Identify abstraction in everyday life. Recognize abstraction in software systems. Confidently answer beginner interview questions. Build a strong mental model that makes future OOP concepts easier. Before We Learn Abstraction... Let's ask an important question. Why do programming languages even provide OOP? Imagine writing software for an e-commerce company. The system contains: Products Customers Orders Warehouses Payments Delivery Partners Notifications Discounts Reviews Thousands of features. If every developer had to understand every implementation detail before writing code, software development would become impossible. We need a way to reduce complexity. That solution is called abstraction. The Problem Abstraction Solves Imagine buying a new car. You sit inside. You: Press the accelerator. Turn the steering wheel. Shift gears. Press the brake. Simple. But underneath the hood, hundreds of complex operations happen every second. The engine burns fuel. The pistons move. The gearbox changes tor

When I first heard the term backtracking , it sounded like a complicated algorithm reserved for computer scientists. After spending the last couple of weeks learning it and implementing it in a Tetris Optimizer project, I realized something surprising: Backtracking is simply the art of making a decision, checking whether it works, and if it doesn't, undoing it and trying something else. This article explains backtracking using a practical project instead of abstract examples. The Problem Imagine you have several Tetris pieces (tetrominoes), and your goal is to fit all of them into the smallest possible square . It might look something like this: A A A A B B B B C C C C D D D D The challenge is to arrange every piece so that: No pieces overlap. No piece extends outside the board. Every piece is used exactly once. The board is as small as possible. This is much harder than it looks. My First Thought Initially, I thought I could simply place one piece after another. Place A Place B Place C Place D Done! Unfortunately, programming isn't always that kind. Sometimes the first position you choose for piece A makes it impossible to place D later. The mistake wasn't with D . The mistake happened much earlier. Enter Backtracking Backtracking works like this: Place a piece. Try placing the next one. If you get stuck... Remove the last piece. Try a different position. Repeat until every piece fits. It's essentially saying: "If this path doesn't work, let's go back and explore another one." Visualizing the Search Suppose we have four tetrominoes. Start ├── Put A at (0,0) │ ├── Put B │ │ ├── Put C │ │ │ ├── D fits ✅ │ │ │ └── D fails ❌ │ │ └── Try another position │ └── Move A elsewhere └── Try another position for A Every branch represents another possibility. Backtracking explores these branches until it finds one that works. How It Looks in Go The heart of the algorithm is surprisingly small. func solve ( index int ) bool { if index == len ( pieces ) { return true } for every

Introduction “When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.” “The question is,” said Alice, “whether you can make words mean so many different things.” “The question is,” said Humpty Dumpty, “which is to be master—that's all.” — Lewis Carroll, Through the Looking-Glass Humpty Dumpty believes that words can mean whatever we choose them to mean. Alice asks an interesting question. Can they? Programming and Language Programming languages derive much of their power from formally specified semantics. The language implementation, not the programmer, defines what if , while and return mean. I cannot persuade the compiler that false should be treated as true . The rules establish a shared and mechanically enforced understanding of what a program means. Large Language Models however, do not execute according to fixed semantics. They interpret natural language through context. This distinction has profound consequences and suggests that a language model has no intrinsic notion of authority. In a programming language, when two instructions conflict, the language specification and execution environment determine the outcome. In natural language, authority does not arise from the words alone. It depends on context, convention, identity, and external rules. Language models, by nature, inherit this ambiguity. A prompt is therefore not a program in the traditional sense. It is an attempt to establish the context within which subsequent language should be interpreted. "You are a detective." "Do not reveal the identity of the murderer." "Only answer questions using the evidence you have observed." None of these statements is mechanically enforced merely because it appears in the prompt. They describe a role, a constraint, and an assumed world. The model may follow them, but their authority must be created and protected by systems outside the model. Prompt injection exploits precisely this weakness. It

I wanted to understand how malloc actually works under the hood. Most explanations I found online described what an allocator does, but completely skipped over the "why" behind its design decisions. Rather than stopping at theory, I decided to build a cross-platform allocator in C that implements malloc , calloc , realloc , and free from scratch. This article documents the design of that allocator, the architectural tradeoffs I faced, and the core concepts I had to learn along the way. Table Of Contents Design Decisions Architecture Modern Allocator Strategies Core Concepts What's Next Project Overview A custom memory allocator does not create physical memory. Instead, it requests pages of raw virtual memory from the operating system and manages how that memory is partitioned, reused, resized, and released by the application. The goal of this educational project is to implement C's core memory management API using a modular, cross-platform architecture inspired by design principles found in modern allocators, rather than relying on legacy, single-platform tricks. Design Decisions #1: Why I am Skipping sbrk While many classic tutorials use sbrk for educational implementations, I deliberately chose a 100% mmap -based approach for two major reasons: sbrk is a fragile global bottleneck. It works by moving a single pointer (the program break) up and down. This means the allocator assumes it owns a contiguous line of memory. If a third-party library or another thread in the program secretly calls sbrk behind the scenes, the allocator's memory layout can break instantly. mmap , by contrast, provides isolated, independent chunks of memory. Cross-Platform Symmetry. Windows has absolutely no equivalent to sbrk , but it has a direct equivalent to mmap : VirtualAlloc . If we used sbrk , our architectural abstraction ( os_alloc ) would become awkward because Linux would deal with a moving pointer while Windows dealt with independent pages. Using mmap keeps the abstraction perfec

The industry is described as a "dual-track" race. On one side are incumbents (Big Tech) with massive infrastructure and deep pockets. On the other is a wave of nimble startups specializing in specific engineering, error-correction, and simulation challenges. The sector is currently transitioning beyond the Noisy Intermediate-Scale Quantum (NISQ) era toward fault-tolerant systems and commercial quantum advantage—the point where quantum machines reliably outperform classical supercomputers for useful tasks. These companies are building the foundational cloud-accessible platforms and hardware: Amazon Braket (AWS) IBM Google Quantum AI Microsoft NVIDIA These players are driving innovation in specific qubit modalities or niches: Superconducting Qubits: Rigetti Computing, IQM, and Atlantic Quantum. Trapped Ion: IonQ, Quantinuum, and Alpine Quantum Technologies. Neutral Atom: QuEra, PASQAL, and Atom Computing. Photonic: Xanadu, PsiQuantum, and Quandela. Silicon/CMOS: Diraq and Silicon Quantum Computing. Error Correction: Riverlane and Q-CTRL are focused on the "noise" problem, helping make unstable qubits behave predictably. Software & Algorithms: Classiq (design automation) and Multiverse Computing (finance/optimization applications). Quantum-Safe Cybersecurity: PQShield and evolutionQ are developing cryptographic solutions to protect data against future quantum threats.

Notes: Prototype : a line that promises to a compiler that a certain function exists somewhere in the server or harddisk or files so it doesn't throw an error. In C, it is done with copying the declaration line of a function and adding a semicolon at the end of it. When we download / setup a specific programming language we download: the specific version of the language's compiler for your operating system and CPU the version of machine code of standard functions that the creator of the language has written that is fine tuned for our operating system and CPU the header files that has Only the prototype of the standard functions (aka functions like printf that are created by the creator of C) We need these in the compilation process: Pre-processing: compiler changing the header files calling line (#include line) with actual prototypes that are inside the header files and creates a temporary file with .i extension (temporary cause it gets deleted in the next step) that contains the prototype at the very top instead of #include line and your source code below compilation: compiler changes the entire contents of the .I file into assembly code (code written in assembly language). Here is why the specific version of compiler is important because every CPU has specific assembly language commands that are unique to it. Therefore when we setup a language we download specific assembly instructions for our own operating system and it comes handy in this step. Syntax check also happens in this step and the .I file also gets deleted. Now there comes a a.out file that we can actually see listed in our file explorer (but we only see the a.out file after the very end of compilation process but it does exist by this stage) Assembling: compiler changes assembly code (a.out file) to machine code (aka 0's and 1's). linking: compiler links your machine code and the machine code FOR the standard functions (because till now it ONLY has the prototypes of the function written in Binary, not

Most developers use Git every day and understand almost none of it. That's not an insult, it's just the reality of how most people learn tools. You pick up the commands that get you through the day, you memorize the ones that fix the situations you keep breaking, and you build a working mental model that is almost entirely wrong at the mechanical level. The mental model most people carry looks something like this: Git tracks changes to files. When you commit, it saves a snapshot of what changed. Branches are pointers to different lines of work. That's roughly correct at a surface level, but it skips over the actual machinery in a way that leaves you confused every time something unexpected happens. Why does rebasing rewrite history? Why are commits immutable? Why does detached HEAD state exist? Why can you lose work in ways that feel impossible if Git is just tracking changes? The answers are all in the object model, and the object model is surprisingly simple once you sit with it. Git is a content-addressable filesystem Before any of the version control concepts, Git is a key-value store. You put content in, you get a hash back. You use that hash later to retrieve the content. That's the entire foundation, and everything else is built on top of it. The hash Git uses is SHA-1, producing a 40-character hexadecimal string. When you run git hash-object on a file, Git takes the content, prepends a small header describing the object type and size, and runs SHA-1 over the whole thing. The resulting hash is both the key and the identity of that content. Two files with identical content will always produce the same hash. A file whose content changes even slightly will produce a completely different hash. This is the first thing that breaks people's mental models. In most storage systems, identity is location: a file is "that file" because it lives at that path. In Git's object store, identity is content. The path a file lives at is separate metadata, not the file's identity

The Shop on the Corner: How I Learned System Design Without Building Amazon Nephew asks his uncle — 10 years deep into building large-scale systems — to explain "system design," and all the scary jargon that comes with it. Uncle refuses to start with the jargon. Instead: "Forget servers and databases for a minute. Just imagine you're running a small shop." What follows is a thought experiment, built one problem at a time — no cloud bills, no fancy stack, just a counter, a storeroom, and a lot of common sense. Part 1: The Counter — Your First "API" 👦 Nephew: Uncle, everyone at work keeps throwing around terms — load balancer, cache, index, sharding. I nod along, but I don't actually get any of it. 👨‍🦳 Uncle: Then don't start there. Close your eyes for a second and forget servers exist. Suppose — just suppose — you're running a small shop. One counter, one small storeroom at the back. A customer walks up and asks for something. What do you do? 👦 Nephew: I'd walk into the storeroom, find it, walk back, hand it over. 👨‍🦳 Uncle: That's it. That's the entire job of a server handling a request. You don't need to understand Amazon's warehouse to understand Amazon's problems. You need a counter and a storeroom, imagined clearly, and the patience to grow them one honest problem at a time. Here's the shape of what you just described, whether you realized it or not: 🧍 Customer 🧑 You (Counter) 📦 Storeroom (Database) | | | |── "Got Maggi?" ───────>| | | |──── Walk in, search ────────>| | |<─────── Found it ────────────| |<── Hand it over, ──────| | | take payment | | 👨‍🦳 Uncle: One customer, one request, one trip to the storeroom, one response. This is fine. This is correct , even, for a shop with five customers a day. Don't let anyone tell you a single counter isn't "scalable" — a shop that small doesn't need two counters, it needs someone to stop worrying and open the shutter. 👦 Nephew: So this is just... a server handling one request at a time? 👨‍🦳 Uncle: Exactly. Customer sen

leetcode.com Problem Statement Given the root of a binary tree, return its preorder traversal. Preorder Traversal follows: Root ↓ Left ↓ Right Brute Force Intuition In an interview, you can explain it like this: Visit the current node first, then recursively traverse the left subtree followed by the right subtree. Recursion naturally follows the preorder sequence. Complexity Time Complexity: O(N) Space Complexity: O(H) Where: N = Number of Nodes H = Height of Tree Recursive Code class Solution { public List < Integer > preorderTraversal ( TreeNode root ) { List < Integer > ans = new ArrayList <>(); preorder ( root , ans ); return ans ; } private void preorder ( TreeNode root , List < Integer > ans ) { if ( root == null ) return ; ans . add ( root . val ); preorder ( root . left , ans ); preorder ( root . right , ans ); } } Moving Towards the Optimal Iterative Approach Instead of recursion, we can use a stack. Since preorder visits: Root ↓ Left ↓ Right we should process the root immediately. To ensure the left subtree is processed first, push the right child before the left child . Pattern Recognition Whenever you see: Preorder Traversal Simulate Recursion Think: Stack Key Observation Stack follows: LIFO To visit: Left First push: Right First ↓ Left Second so that left is popped first. Optimal Java Solution class Solution { public List < Integer > preorderTraversal ( TreeNode root ) { List < Integer > ans = new ArrayList <>(); if ( root == null ) return ans ; Stack < TreeNode > st = new Stack <>(); st . push ( root ); while (! st . isEmpty ()) { TreeNode node = st . pop (); ans . add ( node . val ); if ( node . right != null ) st . push ( node . right ); if ( node . left != null ) st . push ( node . left ); } return ans ; } } Dry Run 1 / \ 2 3 / \ 4 5 Stack: 1 Visit: 1 Push: 3 2 Visit: 2 Push: 5 4 Traversal: 1 ↓ 2 ↓ 4 ↓ 5 ↓ 3 Answer: [1,2,4,5,3] Why Stack Works? A stack processes the most recently added node first. By pushing: Right Child ↓ Left Child the left child

The second word a professor told me to carry for life. It took me years — and a lot of vectors — to start understanding it. A look back — long before any of the tools we argue about now. The same professor — Sang Lyul Min — handed us these words one at a time in lecture. After trade-off , two more stuck with me. But before the second word itself, here are the two pieces of news he brought to class around then. The internet barely existed; information moved through journals, magazines, and word of mouth. Looking back, it's a little amazing how much still got through. When a chess machine started winning The first breakthrough I remember: computers had finally started playing chess on roughly even terms with the world's best. Deep Blue beat Kasparov around 1996, so the machines he was describing came just before — names like Deep Thought, ChessMachine, Socrates II. He told us, deadpan, that one human competitor's head had "physically burst" from the strain — and we groaned, "Come on, Professor, that's a bit much." We live on the far side of AlphaGo now, so it's easy to forget how much we shrugged at all this back then. I was a decent amateur — a 1-dan at Go, hopeless at janggi (Korean chess) against any program — and I still remember the hollow, slightly bitter feeling the AlphaGo era left even in someone who only ever played for fun. A full-body scan The second: in the US, death-row inmates had consented to the first dense full-body image scans. That was the news that taught me — embarrassingly late — that this kind of computing could reach all the way into medicine. Computers, it turned out, showed up in the strangest places. orthogonal Back to the words. The second one, the professor said, would run through my whole career: orthogonal . The Korean rendering — 직교하는, "at right angles" — was, naturally, a word I'd never heard. The plain-language version was "unrelated, independent." It came back hard years later, when I had to take vectors seriously — first in linear

Eight kids, eight chairs, one rule: explaining FIFA's best-thirds draw to my 8-year-old Rahul Devaskar Rahul Devaskar Rahul Devaskar Follow Jun 27 Eight kids, eight chairs, one rule: explaining FIFA's best-thirds draw to my 8-year-old # webdev # soccer # math # worldcup Add Comment 14 min read

Operating system, a thing that everybody uses but no one talks about. While reading Operating Systems: Three Easy Pieces (OSTEP), my background in C and C++ fueled a growing fascination with memory allocation, virtualization, scheduling, and the intricate mechanics of operating systems. This would be a series of article, the number i am not sure, it will be the amount of content that someone might comfortably read in a 10 min Article. Keeping each piece to a solid 10-minute read is the perfect sweet spot for a developer to read over a cup of coffee. It gives you enough runway to explain a core concept, show the math, and link a practical C/C++ experiment without making their eyes glaze over. Why this Article ? We are often warned against “reinventing the wheel.” However, I firmly believe that building and optimizing modern software is impossible without a fundamental grasp of virtualization, memory allocation, and concurrency. Consider Docker: it functions almost entirely on OS-level virtualization features like Namespaces, cgroups, and isolated filesystems. Similarly, the highly optimized Memory Manager in PostgreSQL only works because it leverages the robust memory management systems already written into the OS kernel. This article aims to bring the core concepts of OSTEP to life through practical experimentation. By accompanying the theory with an open-source repository, my goal is to provide a clear, interactive learning experience that demystifies operating systems. I am not an operating system guru or a Principal Engineer with years of experience, but I hope to become one someday (assuming AI doesn’t replace me first… HeHe ). What I can do is dive in, explore, and try to understand these concepts by actually building things. Because of that, my goal here is to present the findings and experiments I explore rather than giving strong opinions — I’ll leave the comment section for those! Any support, feedback, or contributions from the community will be incredibly

Lately, it feels like my feed is completely flooded with "Become an AI/ML Engineer in 2 Hours!" crash courses and quick certificates promising a golden fast-track into machine learning roles. But let’s be completely real for a second: there are no tutorial shortcuts here. The more I dive into actual system architecture and cloud infrastructure, the more obvious it becomes: machine learning isn't a standalone magic trick. It's built entirely on rock-solid Computer Science, efficient data structures, and heavy-duty software engineering. Software Engineering First, AI Second If you can’t build or scale a reliable backend, manage data pipelines, or understand low-level underlying system logic, you simply cannot scale an AI model in production. Prompt engineering is cool for prototyping, but production-level ML requires real, foundational engineering skills. You have to learn how to be a great software engineer first. Looking Past the Hype (A Solid Structural Roadmap) If you actually want to look past the superficial fluff and understand how real data workloads, model deployments, and ML infrastructure fit into a cloud environment, I found an incredibly solid, structured resource. Instead of hand-waving past the hard parts, Microsoft Learn has an official, step-by-step breakdown on Azure AI and Machine Learning Fundamentals. It actually goes into the core architectural principles and shows you what real cloud-scale infrastructure looks like. Whether you are trying to map out your summer learning roadmap or just want to understand the actual systems backing these models, I highly recommend checking it out. Here is the structured entry point if you want to skip the shortcuts and dive into the real infrastructure: 🔗 Official Azure Machine Learning Technical Hub What are your thoughts? Are you seeing the same "AI shortcut" hype on your feeds, or are people finally starting to focus back on core system fundamentals? Let's discuss in the comments!

Math.random() returns a number between 0 and 1, and roughly nobody reading this could explain what happens between the call and the return. That is fine, fine right up until the output decides who gets money, and then it becomes one of the genuinely hard problems in applied software, the kind that regulated industries build entire testing labs around. Start with the thing most people get wrong: a sequence that passes for random and a fair sequence are different claims, and your users cannot tell them apart by staring at outputs. The users will never catch the difference and that is the whole problem in one sentence. This is why fairness in any real-money system, an online casino being the sharpest example, is a verification problem long before it is a math problem. Pseudorandom generators are deterministic. A PRNG eats a seed, runs it through fixed arithmetic, and spits out numbers that sail through statistical randomness tests while being completely predetermined by that seed. Mersenne Twister is the poster child: excellent distribution, used everywhere by default for years, and from a few hundred observed outputs you can reconstruct its internal state and predict the rest. For a Monte Carlo simulation, who cares! For anything where a human has a financial reason to guess your next number, you just shipped a vulnerability and called it a feature. What you want when stakes exist is a CSPRNG. The guarantee that matters: even with a long history of outputs, an attacker cannot compute the next one or recover the internal state. crypto.randomBytes() in Node. crypto.getRandomValues() in the browser. They sit one autocomplete away from the unsafe option and offer wildly different guarantees, which is exactly why this bug ships so often. The safe call and the dangerous call look like fraternal twins. ** The part players actually rely on ** Say you build it correctly: a proper CSPRNG, real entropy, no timestamp nonsense. You know it is fair but now prove it to a stranger wh

In a world completely powered by technology, have you ever wondered what actually keeps our digital lives from crashing down? Enter the unsung heroes: system and network administration . Think of an operating system like Windows or Linux as a computer's command center, orchestrating everything from the heavy-lifting CPU to the smallest plugged-in device. To keep your data safe and your machine stable, it cleverly splits its brain into two zones: a restricted "user mode" where your everyday apps play, and a highly secure, privileged "kernel mode" reserved strictly for critical system operations. When individual computers connect to form massive global networks, the complexity skyrockets. This comprehensive guide breaks down those complex environments into simple, bite-sized concepts. Here is a quick snapshot of what we will cover: Host & OS Administration : This module covers how an operating system functions as the primary intermediary between a user and a computer's raw physical hardware. It explains how the system kernel manages critical computing processes, memory allocation, local storage file systems, and administrative tasks like security patching and automated scripting. Networking Concepts, Topologies, and Protocols : This module explores how individual computer systems connect and communicate across localized or global distances. It details the structural design of network topologies, addressing rules like IPv4 and IPv6, and the standardized layer frameworks that ensure safe and efficient data transmission. 🏛️ Part 1: Operating Systems & Host Administration 🖥️ Computer Resources and Functions At its core, every computer system is a collection of physical machinery and digital structures working together to solve problems. To understand how an operating system manages these pieces, it helps to look at the foundational puzzle blocks of a computer. This section maps out the primary hardware and data elements the system has to control, alongside a simple breakd

"Intelligence isn't about searching everywhere—it's about knowing where not to search." Artificial Intelligence is often associated with neural networks, large language models, and autonomous systems. But long before modern generative AI, computer scientists were solving a much deeper question: How do intelligent systems make decisions efficiently? Whether you're building search algorithms, recommendation systems, autonomous robots, or distributed systems, the architecture of intelligence teaches timeless lessons about solving problems under uncertainty. Let's explore five powerful ideas that shaped AI—and why they matter far beyond computer science. ✈️ 1. The Pilot's Dilemma: Why Blind Search Fails Imagine you're a pilot. Suddenly, one of your engines fails. In the next few seconds, there are hundreds of switches, buttons, and controls available. If you treated every control equally, you'd spend precious time trying random combinations. That is exactly how uninformed search works. Algorithms like: Breadth-First Search (BFS) Depth-First Search (DFS) have no knowledge of where the solution might be. They simply explore. Start ├── Option A ├── Option B ├── Option C └── ... The larger the search space becomes, the less practical this strategy is. A pilot doesn't blindly flip switches. They use additional knowledge : Engine pressure Fuel flow Hydraulic readings Warning systems Those clues dramatically reduce the number of possibilities. This is exactly what AI calls Informed Search . Instead of exploring everything, intelligent systems use knowledge to eliminate impossible paths before searching them. 🧠 2. Heuristics: The Cheat Code of Intelligence The secret behind informed search is something called a heuristic . A heuristic is simply an educated estimate. Mathematically, h(n) represents the estimated cost from the current state to the goal. One important rule always holds: h(goal) = 0 Once we've reached the goal, there's no remaining cost. Example: Finding Bucharest

I've been going through Jim Kurose's networking lectures lately, and I kept finding myself pausing to re-read the same sections. Not because they were confusing - because things I'd been using for years were finally clicking into place. This post is me writing down what I learned, in the order it started making sense. Before HTTP, there's a webpage A webpage isn't one file. When you open a URL, your browser fetches a base HTML file - and that file references other objects. Images. Scripts. Stylesheets. Each one lives at its own URL. Each one has to be fetched separately. So loading a single "page" might mean firing off 20+ individual requests. This detail matters because the entire evolution of HTTP - from 1.0 to 3 - is basically the story of making those 20 fetches faster. HTTP runs on TCP. That has consequences. HTTP doesn't manage its own connections. It hands that job to TCP. When your browser wants something, it first opens a TCP connection to the server (port 80 for HTTP, 443 for HTTPS), and then asks for the object. Opening a TCP connection isn't free. It takes a round-trip - your machine says "hello," the server says "hello back," and then you can actually talk. That's one RTT(Round Trip Time) just to shake hands, before a single byte of your webpage arrives. So every HTTP request carries at least 2 RTTs of overhead: 1 to open the TCP connection, 1 for the actual request/response. Do that 20 times and you've spent 40 RTTs before the page renders. HTTP/1.0 vs HTTP/1.1: one change that mattered a lot HTTP/1.0 (non-persistent): open a TCP connection, fetch one object, close the connection. Repeat for every object. HTTP/1.1 (persistent): open a TCP connection, fetch as many objects as you need, then close. The server leaves the connection open after each response. That one change cuts subsequent fetches from 2 RTTs to 1 RTT each. For a page with 20 objects, that's real time saved - not microseconds, but hundreds of milliseconds that users actually feel. What an

Network Protocols Network protocols define how computers communicate over a network. Whether you're opening Instagram, sending a WhatsApp message, watching Netflix, or transferring money through a banking app, some protocol is working behind the scenes to make communication possible. Client-Server Model What is it? The Client-Server model is a communication architecture where: Client requests a service or data. Server processes the request and returns a response. Most modern applications follow this architecture. How Does It Work? Client ---------- Request ----------> Server Client <--------- Response ---------- Server The client always initiates communication, and the server listens for incoming requests. Real World Example Instagram When you open Instagram: Mobile app sends a request. Instagram servers process the request. Feed data is fetched from databases. Posts are returned to your phone. Instagram App | V Instagram Server | V Database Advantages Centralized control Easier security management Easy maintenance Easier data consistency Disadvantages Server can become a bottleneck Single point of failure if not replicated Interview One-Liner Client-Server architecture is a centralized model where clients request resources and servers provide them. Peer-to-Peer (P2P) Model What is it? In a Peer-to-Peer network, every machine can act as both: Client Server There is no central server controlling communication. How Does It Work? Peer A <------> Peer B ^ ^ | | V V Peer C <------> Peer D Each peer can directly share resources with others. Real World Example BitTorrent Instead of downloading a file from one server: User | +--> Peer 1 | +--> Peer 2 | +--> Peer 3 Different parts of the file are downloaded from multiple peers simultaneously. Blockchain Bitcoin and Ethereum networks operate using Peer-to-Peer communication. Advantages Highly scalable No central server cost Better fault tolerance Disadvantages Harder to manage Security challenges Data consistency issues Inter

Problem Link - https://leetcode.com/problems/delete-node-in-a-linked-list/ This is one of those interview questions that looks impossible at first. Normally, to delete a node from a Linked List, we need access to the previous node. But in this problem, we're only given the node that needs to be deleted. No head. No previous pointer. So how do we remove it? Let's understand the trick. Problem Statement Write a function to delete a node in a singly linked list. You are not given the head of the list. Instead, you are given only the node that needs to be deleted. Example Input: 4 -> 5 -> 1 -> 9 node = 5 Output: 4 -> 1 -> 9 Initial Thought Normally we delete a node like this: prev.next = node.next But here: We don't have prev We don't have head So the usual deletion approach is impossible. Key Observation Although we cannot delete the current node directly, we can make it look like it never existed. Consider: 4 -> 5 -> 1 -> 9 We need to delete: 5 Instead of removing node 5 , copy the value of the next node into it. 4 -> 1 -> 1 -> 9 Now remove the next node. 4 -> 1 -> 9 The original value 5 has disappeared. Mission accomplished. Intuition Copy the next node's value into the current node. Skip the next node. The current node now behaves as if it was deleted. Since the problem guarantees that the given node is not the tail node, a next node will always exist. Dry Run Input 4 -> 5 -> 1 -> 9 node = 5 Current node: 5 Next node: 1 Step 1 Copy next node value. node.val = node.next.val List becomes: 4 -> 1 -> 1 -> 9 Step 2 Skip next node. node.next = node.next.next List becomes: 4 -> 1 -> 9 Done. Optimal Java Solution class Solution { public void deleteNode ( ListNode node ) { ListNode cur = node . next ; node . val = cur . val ; node . next = cur . next ; } } Even Shorter Version class Solution { public void deleteNode ( ListNode node ) { node . val = node . next . val ; node . next = node . next . next ; } } Complexity Analysis Metric Complexity Time Complexity O(1) Space Comp

Earlier parts examined the performance characteristics of sequential and random access under single-threaded execution, and noted in passing the destructive effect of random access on the TLB. This part devotes full attention to the TLB: what it is, why a TLB miss is more severe than a cache miss, why a page table walk constitutes one of the longest dependency chains a CPU can encounter, how huge pages fundamentally alter TLB reach, and where memory-level parallelism falters in the face of TLB misses. Page Boundaries: Where the Prefetcher Halts Part III, in its discussion of prefetchers, noted a hard constraint: a prefetcher must not cross page boundaries on its own authority. The operating system manages virtual memory in units of pages (typically 4 KB, i.e., 64 cache lines). When a program reaches the end of one page and is about to step into the next, the prefetcher cannot proceed. The reason is that the next page may not reside in physical memory (it may have been swapped out to disk), or it may be an entirely invalid virtual address — if the prefetcher were to speculatively initiate an access to the next page, it would trigger a page fault: the OS would have to suspend the process and swap the page in from disk; in the case of an invalid address, the OS would terminate the process outright. From a security standpoint, the prefetcher neither can nor is permitted to autonomously cross page boundaries without TLB approval. Hence a performance brake appears every 4 KB — even when traversing an array sequentially, after every 64 cache line accesses the prefetch pipeline must pause and await confirmation of an address translation. This is not to say that modern CPU prefetchers are completely unable to cross pages. Intel's Next Page Prefetcher and AMD's equivalent mechanism can consult the TLB when approaching a page boundary — if the address mapping for the next page is already registered in the TLB, the prefetcher receives clearance to continue prefetching across th