DEV Community: Sunil Varma

Kernel Chronicles – From Unix -> Linux -> Android

Sunil Varma — Sun, 07 Dec 2025 15:42:43 +0000


UNIX (Bell Labs, 1969)
│
├── BSD (Berkeley Software Distribution, 1978)
│     ├── FreeBSD
│     ├── NetBSD
│     └── OpenBSD
│
├── System V (AT&T UNIX, 1983)
│     ├── SVR1/2/3
│     │      ├── Xenix
│     │      └── SCO UNIX
│     └── SVR4 (merged BSD + System V features)
│            ├── Solaris (SunOS → Solaris)
│            ├── HP-UX
│            ├── AIX (IBM)
│            ├── SCO UnixWare
│            └── Others
│
├── Linux Kernel (1991, written from scratch by Linux Torvalds)
│     │
│     ├── Debian
│     │      ├── Ubuntu
│     │      │      ├── Linux Mint
│     │      │      ├── Pop!_OS
│     │      │      ├── Elementary OS
│     │      │      └── Zorin OS
│     │      └── Kali Linux
│     │
│     ├── Red Hat
│     │      ├── Fedora
│     │      ├── RHEL
│     │      ├── CentOS Stream
│     │      ├── Rocky Linux
│     │      └── AlmaLinux
│     │
│     ├── Arch
│     │      ├── Arch Linux
│     │      ├── Manjaro
│     │      └── EndeavourOS
│     │
│     └── Android (Linux kernel + Google framework)
│
└── Mach microkernel (CMU)
       │
       └── NeXTSTEP (1988, Steve Jobs’ NeXT)
             │
             └── Darwin (Apple’s OS core: Mach + BSD)
                   │
                   ├── XNU Kernel (Mach + BSD + I/O Kit)
                   │
                   ├── macOS
                   ├── iOS
                   ├── iPadOS
                   ├── watchOS
                   └── tvOS

A Brief Introduction to Unix

Unix, developed in the 1970s, laid the foundation for modern operating systems. It introduced concepts like multi-user support, hierarchical file systems, and a modular kernel design — ideas that inspired many OSes that followed.

BSD – Unix Reimagined

The Berkeley Software Distribution (BSD) took Unix’s core ideas and created a free, open-source family of operating systems. FreeBSD, OpenBSD, and NetBSD emerged from BSD, each focusing on performance, security, or portability.

Linux – Inspired by Unix

Linux, starting in 1991 with Linus Torvalds’ kernel, is a Unix-like system built from scratch. Unlike BSD, Linux is just a kernel — distributions combine it with software, desktop environments, and package managers to create complete OSes.

macOS – BSD Meets Apple

Apple’s macOS has roots in BSD through NeXTSTEP. It combines a Unix-based kernel with Apple’s proprietary software and graphical interface, giving users a polished, Unix-compliant experience.

Linux Distros and Their Families

Linux distributions (distros) are grouped into families based on their base system:

Debian Family: Debian → Ubuntu → Pop!_OS, Linux Mint

Red Hat Family: Red Hat → Fedora → CentOS / Rocky Linux / AlmaLinux

Arch Family: Arch → Manjaro → EndeavourOS

Independent / Others: Slackware, Gentoo

Linux Distributions – From Kernel to Complete OS

Linux itself is just a kernel — a core that manages hardware, memory, processes, and basic system operations. By itself, it’s not a complete operating system you can directly use.

To turn the kernel into a full OS, developers package it with software, libraries, desktop environments, and utilities. These complete systems are what we call Linux distributions (distros).

Families, Flavors, and Derivatives:

Debian Family

Base: Debian
Package Manager: apt / .deb packages
Derived Distributions:
Debian based distros: Ubuntu, Kali
Ubuntu-based distros: Linux Mint, Pop!_OS, Elementary OS

Red Hat Family

Base: Red Hat Enterprise Linux (RHEL)
Package Manager: dnf / yum / .rpm packages
Derived Distributions:
Fedora
CentOS
Rocky Linux
AlmaLinux

Arch Family

Base: Arch Linux
Package Manager: pacman
Derived Distributions:
Manjaro
EndeavourOS

I have covered only the major 3 Linux families in use today. There are many more and that itself can be made as a very long book. So, just keep in mind that the world of Linux Distributions is very very very huge and is not just limited to above three.

Each distro inherits traits from its parent but adds its own tools, philosophies, and user experience, giving users a wide range of choices depending on their needs and preferences.

All this content was put up according to my understanding of the evolution of unix and distro's of linux. If you think something is incorrect, please feel free to share your view in the comments. Thanks!

Optimizing Constants in JavaScript & TypeScript: Separate vs Grouped Exports

Sunil Varma — Mon, 29 Sep 2025 17:42:04 +0000

When building modern web applications, constants play a huge role — API URLs, timeout values, error messages, routes, and more. But how you export and import constants can affect not only maintainability but also performance and bundle size.

In this post, we’ll explore the different approaches to managing constants in JavaScript/TypeScript projects, compare their pros and cons, and decide which is best for speed and optimization.

Option 1: Separate Exports

// constants.ts
export const API_URL = "https://example.com/api";
export const TIMEOUT = 5000;
export const MAX_RETRIES = 3;

Usage:

import { API_URL, TIMEOUT } from "./constants";

Pros:

Tree-shaking friendly → only what you import gets bundled.
Cleaner auto-imports in IDEs.
No runtime overhead.

Cons:

File can look cluttered with many constants.

Option 2: Grouped in a Single Object

// constants.ts
const CONSTANTS = {
API_URL: "https://example.com/api",
TIMEOUT: 5000,
MAX_RETRIES: 3,
};


export default CONSTANTS;

Usage:

import CONSTANTS from "./constants";
console.log(CONSTANTS.API_URL);

Pros:

Everything under one namespace.
Easy to pass around as a single object.

Cons:

Loses tree-shaking benefits → entire object is included even if you use just one constant.
Slight runtime overhead (property lookups).

Option 3: Group by Domain

// constants.ts
export const API = {
BASE_URL: "https://example.com/api",
TIMEOUT: 5000,
};


export const APP = {
NAME: "MyApp",
VERSION: "1.0.0",
};

Usage:

import { API, APP } from "./constants";


console.log(API.BASE_URL);
console.log(APP.NAME);

Pros:

Logical grouping (API, APP, UI, Errors, etc.).
Still tree-shakeable (you can import only what you need).
Clean and maintainable for larger teams.

Cons:

Slightly more verbose than flat exports.

⚡ Optimization & Performance:

Separate exports (Option 1) → Fastest and most optimised for bundle size, because tree-shaking works perfectly.

Grouped object (Option 2) → Worst for performance in large apps, since bundlers include the whole object.

Grouped by domain (Option 3) → Best of both worlds: keeps code organized and still benefits from tree-shaking.

👉 Rule of Thumb:

- Use Option 1 for small projects.
- Use Option 3 for scalable/large apps.
- Avoid dumping everything into a single CONSTANTS object unless you have a strong reason.

Suggested Folder Structure for Constants in React + TypeScript

src/
  constants/
    api.ts // API endpoints, timeouts
    app.ts // App name, version
    routes.ts // Route paths
    ui.ts // Colors, labels, breakpoints
    index.ts // Barrel file (optional)

This keeps constants modular and easy to maintain while ensuring fast loading times.

What about you? How do you organise constants in your projects? Do you prefer flat exports or grouped objects?

AbortController - The Overlooked Browser API You Should Be Using

Sunil Varma — Fri, 26 Sep 2025 04:54:10 +0000

Ever clicked a button twice and accidentally fired off two API calls? Or maybe you started fetching some big data, only to realise you didn’t actually need it anymore. In real life, you’d just hit a Cancel button, right?

Well, JavaScript has a built-in way to do exactly that: AbortController. Think of it like pulling the plug on a task before it finishes.

Example:

Cancelling a fetch request after 2 seconds

const controller = new AbortController();
const signal = controller.signal;

fetch("https://jsonplaceholder.typicode.com/todos/1", { signal })
  .then(res => res.json())
  .then(data => console.log("Data:", data))
  .catch(err => {
    if (err.name === "AbortError") {
      console.log("❌ Fetch was aborted");
    } else {
      console.error("Something went wrong:", err);
    }
  });

// Cancel the request after 2 seconds
setTimeout(() => {
  controller.abort();
}, 2000);

Run this, and you’ll see the fetch get cut short. Instead of data, you’ll get an AbortError.

⚙️ How Does It Work?

Think of it like this:

Controller → The remote control.
Signal → The wire that connects the remote to the task.
Task (like fetch) → The TV.

When you call abort(), the signal instantly tells the task: “Stop what you’re doing.”

This really comes in handy when you have multiple filters where each click fires a API call with the latest set of filters. But if user selects multiple filters with some delay, only the new API call with latest filter/s should be alive and the old call are no longer required, in this case we can use abortController to cancel out the previous calls. Another common usecase for this would be when dealing with Forms.

And the most important point of this post is AbortController ≠ Server-Side Cancellation

A common misconception: Aborting the API call will cancel the request.

-> Yes, That's correct (partially), because what you are doing is just aborting the request from client side meaning freeing up the resources that is doing the API handling work on client side by closing the HTTP request. But this doesn't free up the resources on the backend if it was not handled the server still processes the request.. So, calling controller.abort() only stops the client from waiting for a response.

const controller = new AbortController();

fetch('/heavy-operation', { signal: controller.signal })
  .catch(err => err.name === 'AbortError' && console.log('Fetch aborted'));

// Later...
controller.abort();

Making Backend Aware: We can achieve this by two approaches

Passive Approach
Active Approach

Passive Approach: To truly cancel the operation on the server, detect when the client disconnects

Node.js Example:

// Node.js / Express example
app.get('/heavy-operation', (req, res) => {
  req.on('close', () => {
    console.log('Client disconnected, aborting server task');
    // Stop any ongoing processing here
  });

  longRunningTask().then(result => res.send(result));
});

Active Approach: Send an explicit cancellation signal

const controller = new AbortController();
const requestId = "12345";

fetch(`/heavy-operation?reqId=${requestId}`, { signal: controller.signal });

// Later, if aborted
controller.abort();
fetch(`/cancel-operation?reqId=${requestId}`); // Tell backend to stop

Server keeps track of requestId tasks and stops processing when /cancel-operation is called.

-> ✅ Stops the browser from receiving the response
-> ❌ Does not stop the server from working

Takeaway:
AbortController makes your UI more responsive by stopping unnecessary client-side waiting, but for truly efficient applications, pair it with server-side cancellation so both frontend and backend resources are freed when a request is no longer needed.

✍️ Co-authored with: @hrithik_pasumarthi

Copy or Clone? A Beginner’s Guide to Object Copying in JavaScript

Sunil Varma — Tue, 23 Sep 2025 04:54:16 +0000

In JavaScript, copying objects and arrays is a common task, but it’s not always straightforward. This is because objects and arrays are reference types, meaning when you assign them to a new variable with = operator, you're often just copying the reference, not the actual data.

🤖 Meet QuirkyRobot

Say you have a robot:

let quirkyrobot = {
  name: 'Chitti',
  humaneProperties: {
    heartRate: null,
    emotions: undefined,
    mood: 'curious'
  },
  technicalProperties: {
    storage: '1 Zettabyte',
    clockSpeed: '1 terahertz',
  },
  introduction: function(){
    let greetings = `Hello! I am ${this.name} the robot. Speed: ${this.technicalProperties.clockSpeed}, Memory: ${this.technicalProperties.storage}`;
    return greetings;
  }
}

Now, If we want to create a copy of this, we would assign it to the new variable using = operator.

let newrobot = quirkyrobot;

You're not creating a new robot; you're just pointing newrobot to the same robot. Any changes to newrobot will affect quirkyrobot and vice versa. It's like having two names for the same person!

Example:

let newrobot = quirkyrobot;
newrobot.name = 'R2-D2';

console.log(quirkyrobot.name); // Outputs: 'R2-D2'

/* Above assignment of name property of newrobot has also modified 
the original objects (quirkyrobot) name property since both objects 
points to same reference */

Sometimes this behaviour is intentional. But when we want to deal with a fresh copy and have the old one untouched, we need to make a true copy from the original object.

1. 🛠️ Shallow Copy (Copying the Top-Level Properties)

A shallow copy means copying the top-level properties of an object. Nested objects or arrays will still reference the same memory location.

1.1. Using spread syntax of ES6 (...)

let shallowCopy = {...quirkyrobot};
shallowCopy.name = 'Wall-e';

console.log(quirkyrobot.name); // Outputs: 'Chitti'
console.log(shallowCopy.name); // Outputs: 'Wall-e'

1.2. Using Object.assign()

let shallowCopy = Object.assign({}, quirkyrobot);
shallowCopy.name = 'Wall-e';

console.log(quirkyrobot.name); // Outputs: 'Chitti'
console.log(shallowCopy.name); // Outputs: 'Wall-e'

Both methods created a new object with the same top-level properties. However, nested objects or arrays of new object still reference the same memory location of those nested structures of original object.

What that means is,

let shallowCopy = Object.assign({}, quirkyrobot);

shallowCopy.humaneProperties.mood = 'calm';

console.log(quirkyrobot.humaneProperties.mood); 
/* Output: 'calm' but not 'curious' since shallowCopy object's nested
structures are still referencing the original object's nested
structures.*/

2. Deep Copy (Cloning Nested Structures)

A deep copy means creating a new object that doesn’t share any references with the original — including nested ones.

Let’s revisit our quirkyrobot and make a true copy this time.

2.1 Using `JSON.parse(JSON.stringify())`:

let deepCopyRobot = JSON.parse(JSON.stringify(quirkyrobot));

deepCopyRobot.humaneProperties.mood = "happy";
console.log(quirkyrobot.humaneProperties.mood); // Outputs: 'curious'
console.log(deepCopyRobot.humaneProperties.mood); // Outputs: 'happy'

This method clones the entire object so changes inside nested properties don’t affect the original.

However, it has a few drawbacks:

It cannot copy functions, undefined, or Symbol values.
Special objects like Date, Map, or Set are converted to plain objects or strings.
It fails on circular references.

In our case, the introduction() method disappears in the copied object:

console.log(typeof deepCopyRobot.introduction); // undefined

So, while JSON.parse(JSON.stringify()) is great for simple objects, it’s not ideal for complex data.

2.2 structuredClone(): (ES6 native solution):

Modern JavaScript offers a built-in function:

let structuredRobot = structuredClone(quirkyrobot);

structuredRobot.humaneProperties.mood = "excited";
console.log(quirkyrobot.humaneProperties.mood); // 'curious'

Handles most of the javascript built-in types but fails with functions and class instances.

2.3 Using Utility Libraries like Lodash:

If you need something battle-tested:

let _ = require("lodash");
let clonedRobot = _.cloneDeep(quirkyrobot);

clonedRobot.humaneProperties.mood = "joyful";
console.log(quirkyrobot.humaneProperties.mood); // 'curious'

Lodash’s cloneDeep() handles almost every case — including nested arrays, objects, maps, and sets — while keeping your original object safe.

If you think your object/array is going to be nested, and you want to copy it to the core, then use Deep Copy/Clone. Else, stick to shallow copy.

Shallow copy is much faster than deep copy, so its advised to use it only when necessary.

References from the OG
MDN Shallow copy
MDN Deep copy
MDN Object.assign()
MDN Structured clone

✍️ Co-authored with: @hrithik_pasumarthi

DEV Community: Sunil Varma

Kernel Chronicles – From Unix -> Linux -> Android

Optimizing Constants in JavaScript & TypeScript: Separate vs Grouped Exports

Option 1: Separate Exports

Pros:

Cons:

Option 2: Grouped in a Single Object

Pros:

Cons:

Option 3: Group by Domain

Pros:

Cons:

⚡ Optimization & Performance:

👉 Rule of Thumb:

Suggested Folder Structure for Constants in React + TypeScript

AbortController - The Overlooked Browser API You Should Be Using

Example:

⚙️ How Does It Work?

Making Backend Aware: We can achieve this by two approaches

Copy or Clone? A Beginner’s Guide to Object Copying in JavaScript

🤖 Meet QuirkyRobot

1. 🛠️ Shallow Copy (Copying the Top-Level Properties)

1.1. Using spread syntax of ES6 (...)

1.2. Using Object.assign()

2. Deep Copy (Cloning Nested Structures)

2.1 Using JSON.parse(JSON.stringify()):

2.2 structuredClone(): (ES6 native solution):

2.3 Using Utility Libraries like Lodash:

2.1 Using `JSON.parse(JSON.stringify())`: