Forem: Tahsin Abrar

Stack Pointer vs Base Pointer: A Friendly Guide to How Function Calls Work

Tahsin Abrar — Mon, 18 May 2026 11:38:49 +0000

Have you ever called a function and wondered what really happens inside the computer?

package main

import "fmt"

func add(x int, y int) int {
    result := x + y
    return result
}

func main() {
    a := 10
    sum := add(a, 4)
    fmt.Println(sum)
}

We know the output will be:

But inside the machine, a lot of quiet work happens.

The CPU needs to remember:

Where did this function start?

Where should it return?

Where are the arguments?

Where are the local variables?

Which function is currently running?

This is where the stack, stack frame, stack pointer, and base pointer come in.

Let’s break them down in a simple way.

First, What Is a Stack?

A stack is a special area of memory used while a program is running.

Think of it like a stack of plates.

You put a plate on top.

You remove the top plate first.

You cannot remove a plate from the middle without disturbing the others.

In programming, the stack works in a similar way.

When a function is called, the program creates a small memory area for that function. This small area is called a stack frame.

When the function finishes, its stack frame is removed.

So if main() calls add(), the stack may look like this:

add() stack frame
main() stack frame

add() is on top because it is currently running.

When add() finishes, its stack frame is removed, and the program returns to main().

What Is a Stack Frame?

A stack frame is the memory space a function gets while it is running.

It usually stores things like:

Function arguments
Return address
Old base pointer
Local variables
Temporary values

For our add() function:

func add(x int, y int) int {
    result := x + y
    return result
}

The stack frame may contain:

x = 10
y = 4
return address
old base pointer
result = 14

The exact layout depends on the CPU, compiler, operating system, and calling convention. But the main idea is the same:

A function needs a private workspace while it runs.

That workspace is its stack frame.

A Quick Note About Memory Addresses

Before we go deeper, let’s clear up one common confusion.

On most modern systems, memory is byte-addressable. That means every byte has its own address.

So memory addresses can look like this:

0, 1, 2, 3, 4, 5, 6, 7, 8 ...

But when we draw memory in larger chunks, like 4-byte chunks on a 32-bit-style example, we often label them like this:

0, 4, 8, 12, 16 ...

This does not mean addresses 1, 2, and 3 do not exist.

It simply means we are drawing memory in 4-byte blocks.

Address 0  -> byte 1 of first block
Address 1  -> byte 2 of first block
Address 2  -> byte 3 of first block
Address 3  -> byte 4 of first block

Address 4  -> byte 1 of second block

For this article, we will use a simple 32-bit mental model where each slot is 4 bytes.

So our stack addresses may move like this:

In many systems, the stack grows downward, which means the address gets smaller as new data is pushed onto the stack.

What Is the Stack Pointer?

The stack pointer, often called SP, points to the current top of the stack.

Imagine you are stacking plates.

The stack pointer is like your finger pointing at the top plate.

When a new value is pushed onto the stack, the stack pointer moves.

When a value is popped from the stack, the stack pointer moves back.

Before push:

Address 76 -> old value
Address 72 -> top of stack  <- SP

Push new value:

Address 76 -> old value
Address 72 -> old top
Address 68 -> new value     <- SP

Because our example stack grows downward, pushing data makes SP move from 72 to 68.

So the stack pointer is dynamic.

It keeps changing as the stack grows and shrinks.

What Is the Base Pointer?

The base pointer, often called BP or frame pointer, points to a stable location inside the current function’s stack frame.

Unlike the stack pointer, the base pointer usually stays fixed while the function is running.

Why do we need that?

Because the stack pointer keeps moving.

If the program only used SP, it would be hard to find local variables and arguments after more values are pushed or popped.

The base pointer solves this problem.

It gives the function a fixed reference point.

From that fixed point, the program can find values using offsets.

BP + 8   -> first argument
BP + 12  -> second argument
BP - 4   -> first local variable
BP - 8   -> second local variable

So the base pointer helps the program answer questions like:

Where is x?

Where is y?

Where is result?

Where should I return after this function ends?

Stack Pointer vs Base Pointer

Here is the simple difference:

Register	Meaning	Behavior
Stack Pointer	Points to the current top of the stack	Changes often
Base Pointer	Points to a fixed place in the current stack frame	Usually stays fixed during the function

A simple way to remember it:

SP tracks movement.

BP gives stability.

The stack pointer is like a moving bookmark.

The base pointer is like an anchor.

What Happens When `main()` Runs?

func main() {
    a := 10
    sum := add(a, 4)
    fmt.Println(sum)
}

When main() starts, the program creates a stack frame for main.

Inside that frame, it stores local variables such as:

a = 10
sum = ?

At first, sum does not have its final value because add(a, 4) has not returned yet.

So the stack may look like this:

main stack frame
----------------
return address
old BP
a = 10

Now main() calls add(a, 4).

That means the program needs a new stack frame for add().

What Happens When `add()` Is Called?

This line is important:

sum := add(a, 4)

The program needs to call add() with two values:

x = 10
y = 4

So it creates a new stack frame for add().

A simplified stack frame may look like this:

add stack frame
---------------
y = 4
x = 10
return address
old BP
result = 0

The order can vary depending on the system, but the idea is the same.

The add() function needs:

Its arguments: x and y

A return address: where to go back after add() finishes

The old base pointer: so the caller’s stack frame can be restored

Its local variable: result

Why Do We Need a Return Address?

When main() calls add(), the CPU jumps to the code for add().

But after add() finishes, the CPU must know where to go back.

It needs to return to this line:

sum := add(a, 4)

More specifically, it needs to return to the next step after the function call, so the returned value can be stored in sum.

That “go back here” location is called the return address.

Without a return address, the program would get lost.

It would finish add() and then have no idea where to continue.

Why Save the Old Base Pointer?

Before add() starts, main() already has its own base pointer.

When add() starts, it gets a new base pointer for its own stack frame.

But when add() finishes, the program must restore the old base pointer so main() can continue correctly.

That is why the old base pointer is saved inside the new stack frame.

Think of it like leaving a breadcrumb.

Before entering a new function, the program says:

“Let me save where I came from, so I can restore it later.”

When the function ends, the old base pointer is loaded back.

Now the caller’s stack frame becomes active again.

How `add()` Finds `x`, `y`, and `result`

Inside add(), we have this line:

result := x + y

The CPU does not understand variable names like humans do.

It does not think:

“Oh, x means 10 and y means 4.”

Instead, the compiler maps variables to memory locations.

Using the base pointer, the program can find values by offsets.

BP + 8   -> x
BP + 12  -> y
BP - 4   -> result

So when the function needs x, it looks at something like:

BP + 8

When it needs y, it looks at:

BP + 12

When it needs to store result, it may use:

BP - 4

So the line:

result := x + y

becomes something like:

read value at BP + 8
read value at BP + 12
add them
store the answer at BP - 4

x = 10
y = 4

result = 14

Returning Back to `main()`

Now add() reaches this line:

return result

The function returns 14.

Then the add() stack frame is no longer needed.

So the program removes it from the stack.

The stack pointer moves back.

The old base pointer is restored.

The return address tells the CPU where to continue.

Now we are back inside main().

The returned value 14 is stored in sum.

sum := 14

Then this line runs:

fmt.Println(sum)

And we see:

A Simple Visual Summary

Here is a simplified version of what happens.

Before calling add():

main stack frame
----------------
a = 10
sum = ?

While add() is running:

add stack frame
---------------
x = 10
y = 4
result = 14

main stack frame
----------------
a = 10
sum = ?

After add() returns:

main stack frame
----------------
a = 10
sum = 14

Then main() prints:

Does This Always Work Exactly Like This?

Not always.

This article uses a simplified model to make the concept easy to understand.

Real systems can be more complex.

Modern compilers may optimize away the base pointer.

Function arguments may be passed through registers instead of the stack.

Go uses goroutine stacks, which can grow and move.

The exact stack layout depends on architecture, compiler version, and calling convention.

But the core idea is still useful:

Functions need stack frames.

The stack pointer tracks the top of the stack.

The base pointer gives a stable reference point inside a function frame.

Return addresses help the program continue from the correct place.

Old base pointers help restore the caller’s frame.

Once you understand this model, debugging, assembly, recursion, memory layout, and low-level programming all become much less mysterious.

A Real-Life Way to Remember It

Imagine you are reading a book and solving exercises.

You are on Chapter 5.

Suddenly, Chapter 5 says:

“Before continuing, go solve Example 2 from Chapter 3.”

So you place a bookmark in Chapter 5.

Then you go to Chapter 3 and solve the example.

After finishing, you return to the bookmark in Chapter 5.

In this story:

The bookmark is like the return address.

Your current page position is like the stack pointer.

The start of your current exercise notes is like the base pointer.

The notes for each exercise are like stack frames.

Every function call is like temporarily jumping into another task, while carefully remembering how to come back.

How to Connect a Namecheap Domain to a DigitalOcean Droplet with Nginx

Tahsin Abrar — Sat, 16 May 2026 15:31:38 +0000

Buying a domain is exciting. Creating a server is exciting too.

But the moment you try to connect both of them, things can feel confusing.

You bought your domain from Namecheap. You created a VPS on DigitalOcean. Now you expect your website to open when someone visits your domain.

But unlike shared hosting or cPanel hosting, DigitalOcean does not automatically connect everything for you.

You need to set up two important things:

DNS : so your domain points to your server
Nginx : so your server knows how to serve your website

In this guide, we will walk through the full setup in a simple and beginner-friendly way.

By the end, your domain will point to your DigitalOcean Droplet, Nginx will serve your website, and HTTPS will be enabled.

The Big Picture

Before touching any settings, let’s understand the flow.

Namecheap Domain
        ↓
DNS points to DigitalOcean IP
        ↓
DigitalOcean Droplet
        ↓
Nginx Web Server
        ↓
Your Website

Your domain is like a human-friendly address.

Your DigitalOcean Droplet is the actual server.

DNS connects the domain to the server.

Nginx receives the request and serves your website files or forwards traffic to your app.

Step 1: Create a DigitalOcean Droplet

First, create a Droplet on DigitalOcean.

For a beginner project or test website, this setup is usually enough:

Ubuntu 22.04 LTS
Basic Droplet
1 GB RAM

After the Droplet is created, DigitalOcean will give you a public IP address.

It will look something like this:

159.89.xxx.xxx

Keep this IP address safe. You will need it in the next step.

This IP is where your domain will point.

Step 2: Point Your Namecheap Domain to DigitalOcean

Now go to your Namecheap account.

Open:

Domain List
→ Manage
→ Advanced DNS

There are two common ways to connect your domain.

Option A: Use A Records

This is the easiest method for beginners.

Add these DNS records:

Type	Host	Value
A Record	@	Your DigitalOcean IP
A Record	www	Your DigitalOcean IP

Example:

Type	Host	Value
A Record	@	159.89.xxx.xxx
A Record	www	159.89.xxx.xxx

You can keep TTL as the default value.

Here is what this does:

example.com       → DigitalOcean server
www.example.com   → DigitalOcean server

So both the root domain and the www version will go to the same Droplet.

For most simple projects, this is the best starting point.

Option B: Use DigitalOcean Nameservers

Another option is to manage DNS from DigitalOcean instead of Namecheap.

In DigitalOcean, go to:

Networking
→ Domains
→ Add Domain

Add your domain there.

DigitalOcean will give you nameservers like:

ns1.digitalocean.com
ns2.digitalocean.com
ns3.digitalocean.com

Then go back to Namecheap:

Domain
→ Manage
→ Nameservers
→ Custom DNS

Add those three DigitalOcean nameservers and save.

This method is useful when you want to manage all DNS records from DigitalOcean, especially if you have multiple subdomains or services.

Which DNS Method Should You Choose?

For beginners, use A Records.

It is simple, clear, and easy to debug.

Use DigitalOcean nameservers when your setup becomes larger, for example:

api.example.com
app.example.com
blog.example.com
admin.example.com

For now, we will continue with the beginner-friendly A Record method.

Step 3: Wait for DNS Propagation

DNS changes are not always instant.

Sometimes they work in a few minutes. Sometimes they take longer.

Usually, it can take:

5 minutes to 1 hour

In some cases, it may take up to:

24 hours

You can use tools like DNS Checker to see whether your domain is pointing to the correct server IP.

A common beginner mistake is changing DNS and immediately thinking something is broken. Sometimes nothing is broken. DNS just needs a little time.

Step 4: Connect to Your Server with SSH

Now connect to your DigitalOcean Droplet.

On Mac or Linux, open your terminal.

On Windows, you can use PowerShell or PuTTY.

Run:

ssh root@YOUR_SERVER_IP

Example:

ssh root@159.89.xxx.xxx

The first time you connect, your terminal may ask for confirmation. Type:

yes

Then enter your password or use your SSH key, depending on how you created the Droplet.

Step 5: Install Nginx

Once you are inside the server, update the package list:

sudo apt update

Then install Nginx:

sudo apt install nginx -y

Check if Nginx is running:

sudo systemctl status nginx

If everything is working, you should see that Nginx is active.

At this point, if you open your server IP in the browser, you may see the default Nginx welcome page.

That means your web server is working.

Step 6: Configure the Firewall

Ubuntu servers often use ufw for firewall management.

Allow Nginx traffic:

sudo ufw allow 'Nginx Full'

Also allow SSH so you do not lock yourself out:

sudo ufw allow OpenSSH

Then enable the firewall:

sudo ufw enable

You can check the firewall status with:

sudo ufw status

You should see that HTTP, HTTPS, and SSH traffic are allowed.

Step 7: Create a Website Folder

Now create a folder for your website.

sudo mkdir -p /var/www/myproject

Create a test HTML file:

sudo nano /var/www/myproject/index.html

Paste this:

<h1>Hello from DigitalOcean</h1>

Save the file:

CTRL + X
Y
Enter

This simple file will help us confirm that the domain and Nginx setup are working.

Step 8: Create an Nginx Server Block

An Nginx server block tells Nginx how to handle traffic for a specific domain.

Create a new config file:

sudo nano /etc/nginx/sites-available/myproject

Paste this configuration:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/myproject;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Replace this:

example.com www.example.com

With your real domain.

For example:

server_name mycoolsite.com www.mycoolsite.com;

This config says:

“When someone visits this domain, serve files from /var/www/myproject.”

Step 9: Enable the Site

Nginx keeps available site configs in:

/etc/nginx/sites-available/

But it only uses configs that are linked in:

/etc/nginx/sites-enabled/

So we need to enable the site:

sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled/

Step 10: Test and Reload Nginx

Before restarting Nginx, always test the config:

sudo nginx -t

If everything is fine, you should see something like:

syntax is ok
test is successful

Now reload Nginx:

sudo systemctl reload nginx

Open your domain in the browser:

http://yourdomain.com

You should see:

Hello from DigitalOcean

Great. Your domain is now connected to your Droplet.

Step 11: Add HTTPS with Certbot

A production website should use HTTPS.

For that, we can use Certbot with Let’s Encrypt.

Install Certbot:

sudo apt install certbot python3-certbot-nginx -y

Then run:

sudo certbot --nginx

Certbot will ask you to choose the domain.

Select your domain and allow redirect to HTTPS.

After that, your site should work with:

https://yourdomain.com

Certbot also sets up automatic renewal, so your SSL certificate can renew before it expires.

Final Architecture

Your setup now looks like this:

Namecheap
   ↓
DNS A Record
   ↓
DigitalOcean Droplet IP
   ↓
Nginx
   ↓
Website Files

This is a common real-world setup used by many developers.

Why This Feels Different from cPanel Hosting

If you are coming from cPanel hosting, DigitalOcean may feel harder at first.

That is normal.

With cPanel hosting, the hosting company usually handles many things for you:

DNS
Apache or Nginx
SSL
PHP
File manager
Email tools

You often just change nameservers and upload your files.

But with a DigitalOcean VPS, you manage the server yourself.

That means you are responsible for:

Nginx
Firewall
SSL
App runtime
Deployment
Security
Logs

The benefit is flexibility.

You can run Node.js, Laravel, Docker, PostgreSQL, Redis, background workers, multiple apps, and more.

The tradeoff is that you need to understand the server setup.

A Real-Life Example

Imagine you built a small portfolio website.

You bought:

myportfolio.com

from Namecheap.

Then you created a DigitalOcean Droplet with this IP:

159.89.100.50

In Namecheap, you add:

Type	Host	Value
A Record	@	159.89.100.50
A Record	www	159.89.100.50

Then on your server, your Nginx config looks like this:

server {
    listen 80;
    server_name myportfolio.com www.myportfolio.com;

    root /var/www/myportfolio;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

After reloading Nginx and setting up SSL, visitors can open:

https://myportfolio.com

And see your website.

That is the full journey from domain to live website.

Hubs, Switches, and Routers Explained Like You're Debugging a Real Network

Tahsin Abrar — Mon, 11 May 2026 06:48:03 +0000

Have you ever connected your laptop to Wi-Fi, opened a browser, typed a URL, and wondered:

"How does my message actually reach the right computer?"

As developers, we often work with APIs, servers, ports, IP addresses, localhost, Docker networks, cloud servers, and routers. But networking can feel confusing because many explanations jump straight into heavy terms.

So let's slow down and make it simple.

In this post, we'll understand three important network devices:

Hub
Switch
Router

We'll also see how data moves from one computer to another inside a local network, and how your computer decides whether to send data directly to another device or through the router.

This article is based on the provided networking class transcript about hubs, switches, routers, MAC tables, and internal communication.

First, Imagine a Small Room Full of Computers

Imagine five computers connected in the same room.

One computer wants to send a message to another computer.

For example:

Computer A wants to send data to Computer D

That sounds simple. But the network has to answer some important questions:

Who sent the data?
Who should receive it?
Are both devices in the same network?
Should the data go to another device first?

This is where hubs, switches, and routers come in.

The Hub: The Loud but Not-So-Smart Device

A hub is one of the simplest network devices.

You can think of it like a loudspeaker.

When one computer sends data to a hub, the hub does not check who the data is for. It simply forwards the data to every other connected port.

So if Computer A sends data through a hub, the hub sends it to:

Computer B
Computer C
Computer D
Computer E

Even if the message was only meant for Computer D.

The other computers receive the data, check it, and then ignore it if it is not meant for them.

Why is a hub considered "not smart"?

Because a hub works at the physical layer, also called Layer 1.

It only understands electrical signals or bits.

It does not understand:

MAC addresses
IP addresses
Ports
Applications
Actual message content

So a hub cannot make smart forwarding decisions.

It just repeats the signal.

Simple way to remember a hub

A hub says:

"I don't know who needs this, so I'll send it to everyone."

That is why hubs are rarely used in modern networks.

The Switch: A Smarter Device That Learns

A switch is much smarter than a hub.

A switch works at the data link layer, also called Layer 2.

That means a switch can understand MAC addresses.

A MAC address is like the hardware address of a network device. Every network interface has one.

For example, imagine five devices connected to a switch:

Port 1 -> Computer A
Port 2 -> Computer B
Port 3 -> Computer C
Port 4 -> Computer D
Port 5 -> Computer E

Each computer has a MAC address:

Computer A -> MAC A
Computer B -> MAC B
Computer C -> MAC C
Computer D -> MAC D
Computer E -> MAC E

Now Computer A wants to send data to Computer D.

The Ethernet frame may look like this in a simplified way:

Source MAC: A
Destination MAC: D
Data: Hello

When the switch receives this frame, it checks the source MAC address.

It says:

MAC A came from Port 1

Then it saves that information in a table.

This table is commonly called:

MAC address table
CAM table
Forwarding database
Bridge table

Different books and vendors may use different names, but the idea is the same.

The switch keeps a record like this:

MAC Address    Port
A              1

What Happens When the Switch Does Not Know the Destination?

Now the switch checks the destination MAC address:

Destination MAC: D

But imagine this is the first time the switch has seen Computer D.

So the switch does not yet know which port leads to MAC D.

What does it do?

It floods the frame.

That means it sends the frame to every port except the port it came from.

So the frame goes to:

Port 2
Port 3
Port 4
Port 5

Computer B receives it and says:

This is not for me.

Computer C says the same.

Computer E says the same.

But Computer D checks the destination MAC and says:

This is mine.

So Computer D accepts the frame.

How the Switch Learns Over Time

Now Computer D replies to Computer A.

The reply frame looks like this:

Source MAC: D
Destination MAC: A
Data: Hello back

The switch receives the frame from Port 4.

It checks the source MAC address and learns:

MAC D came from Port 4

Now the switch table becomes:

MAC Address    Port
A              1
D              4

Next time Computer A sends data to Computer D, the switch does not need to flood the frame.

It already knows:

MAC D is on Port 4

So it sends the frame only to Port 4.

That is why a switch is more efficient than a hub.

Simple way to remember a switch

A switch says:

"I’ll learn where devices are, then send data only where it needs to go."

Hub vs Switch in One Simple Example

Imagine a classroom.

A hub is like a student who receives a note and shouts it to the whole class.

A switch is like a helpful class monitor who learns where everyone sits and quietly gives the note to the right person.

That is the main difference.

Where Does the Router Fit In?

A router works at the network layer, also called Layer 3.

That means a router understands IP addresses.

A switch mainly cares about MAC addresses inside a local network.

A router cares about moving data between different networks.

For example:

Your laptop -> your home network
Your home network -> the internet
The internet -> another server

The router is the device that connects your local network to other networks.

Simple way to remember a router

A router says:

"This data needs to go outside this network. I know where to send it next."

Your Home Router Is Usually More Than Just a Router

This part is important.

The device we casually call a "router" at home is usually not just a router.

It often contains multiple things inside one box:

Router
Switch
Wi-Fi access point
DHCP server
Firewall/NAT features

So when you plug an Ethernet cable into your home router, you are usually plugging it into the switch part of the device.

When your laptop connects through Wi-Fi, it connects through the wireless access point part.

The real routing happens when data needs to leave your local network and go somewhere else, like the internet.

LAN Interface and WAN Interface

A home router usually has two sides:

LAN side

This is your local network.

Your laptop, phone, printer, TV, and other home devices live here.

Example local IP addresses:

192.168.1.10
192.168.1.11
192.168.1.12

Your router may have a local IP like:

192.168.1.1

This is often called the default gateway.

WAN side

This is the side connected to your internet provider.

The router gets a public or provider-side IP address on this side.

So your router sits between:

Your private home network
The outside internet

How Does a Computer Decide Where to Send Data?

Now comes a very important question.

Suppose your computer wants to send data to another IP address.

How does it know whether the destination is inside the same local network or outside?

It uses:

Its own IP address
The destination IP address
The subnet mask
The default gateway

Usually, your computer gets these from DHCP.

A DHCP server may give your device:

IP address:       192.168.1.10
Subnet mask:      255.255.255.0
Default gateway:  192.168.1.1

Now your computer can make a decision.

Example 1: Sending Data Inside the Same Network

Let's say:

Computer A IP: 192.168.1.10
Computer C IP: 192.168.1.11
Subnet mask:   255.255.255.0

Computer A wants to send data to Computer C.

It checks whether both IP addresses belong to the same network.

With this subnet mask, both addresses are part of:

192.168.1.0/24

So Computer A understands:

Computer C is in my local network.

That means Computer A does not need to send the data to the router for routing.

Instead, it sends an Ethernet frame directly toward Computer C's MAC address.

Simplified frame:

Source MAC: A
Destination MAC: C
Source IP: 192.168.1.10
Destination IP: 192.168.1.11

The switch receives the frame and forwards it to Computer C.

The router part does not need to be involved.

Example 2: Sending Data Outside the Network

Now imagine Computer A wants to send data to:

8.8.8.8

That IP is not inside the local network 192.168.1.0/24.

So Computer A understands:

This destination is outside my network.

Now something interesting happens.

The destination IP stays as:

8.8.8.8

But the destination MAC address becomes the MAC address of the router.

Simplified frame:

Source MAC: A
Destination MAC: Router
Source IP: 192.168.1.10
Destination IP: 8.8.8.8

Why?

Because inside the local network, the computer can only deliver frames to local devices by MAC address.

To reach the outside world, it sends the frame to the default gateway first.

The router receives it, looks at the destination IP, and then decides where to send it next.

Important Detail: MAC Address Changes, IP Address Stays

This is one of the most useful networking ideas to understand.

When data moves across networks, the IP packet is trying to reach the final IP address.

But at each local network hop, the MAC address may change.

For example:

Your laptop -> Router
Router -> ISP device
ISP device -> next router
Next router -> destination server

Each step may use a different source and destination MAC address.

But the destination IP is still the final server's IP.

That is why:

Switches care about MAC addresses.
Routers care about IP addresses.

A Developer-Friendly Example

Imagine you are building a backend API.

Your laptop is running a frontend app:

http://localhost:5173

Another computer on the same Wi-Fi is running an API server:

http://192.168.1.25:3000

When your laptop calls that API, it checks:

Am I in the same network as 192.168.1.25?

If yes, your laptop sends the frame toward that device's MAC address.

The switch or Wi-Fi access point handles local delivery.

The router does not need to send the traffic to the internet.

Now imagine your app calls:

https://api.github.com

That server is outside your local network.

So your laptop sends the frame to the router's MAC address.

The router then forwards the packet toward the internet.

This is happening all the time while you code.

Quick Comparison: Hub vs Switch vs Router

Device	Layer	Understands	Main Job
Hub	Layer 1	Bits/signals	Sends data to all ports
Switch	Layer 2	MAC addresses	Sends frames inside a local network
Router	Layer 3	IP addresses	Sends packets between networks

Common Terms You Should Remember

Frame

A frame belongs to the data link layer.

It contains MAC address information.

Source MAC
Destination MAC
Payload

Packet

A packet belongs to the network layer.

It contains IP address information.

Source IP
Destination IP
Payload

Segment

A segment usually belongs to TCP at the transport layer.

It contains port information.

Source port
Destination port
Data

MAC address table

A switch uses this table to remember which MAC address is connected to which port.

MAC Address    Port
A              1
C              3
D              4

Default gateway

The default gateway is usually your router's local IP address.

Your computer sends data to the default gateway when the destination is outside the local network.

A Simple Mental Model

Here is the easiest way to remember everything:

Hub:
"I will send it to everyone."

Switch:
"I will send it to the correct local device if I know where it is."

Router:
"I will send it to another network."

That's it.

Once you understand this, many networking topics become easier:

DHCP
ARP
Subnetting
NAT
Docker networking
Kubernetes networking
Cloud VPCs
Firewalls
Load balancers

DNS Made Simple: What Really Happens Before Your Browser Opens a Website

Tahsin Abrar — Thu, 23 Apr 2026 16:25:15 +0000

We use domain names every day.

We type google.com, facebook.com, or linkedin.com into a browser, press Enter, and the website opens in seconds. It feels simple. Almost boring.

But under the hood, something very important happens before your browser can even start talking to that website.

That thing is DNS.

And here is the part many developers miss early on: if you want to understand TLS/SSL, networking, deployment, or even why a request is slow, you need to understand DNS first.

Because before secure communication begins, your browser has to answer one basic question:

"Where is this website actually hosted?”

Let's break it down in the simplest possible way.

First, let's understand the URL

Take this URL:

https://blog.example.com

It has a few parts:

https → the scheme or protocol
blog → the subdomain
example → the main domain
.com → the top-level domain (TLD)

Another example:

https://engineering.linkedin.com

Here:

https is the protocol
engineering is the subdomain
linkedin is the domain
.com is the TLD

This structure matters because DNS works with these names.

Before we go into DNS, we need to understand one thing clearly:

a domain name is not the real machine address.

It is the human-friendly name for that machine.

Why domain names exist

Humans are good at remembering words.

Machines are good at working with numbers.

That is the heart of the whole idea.

You can easily remember:

facebook.com

But remembering something like this is much harder:

157.240.22.35

That number is an IP address.

An IP address is the real network address of a machine or server.

So when you type a domain name into a browser, your system has to find the IP address behind that name.

That translation is what DNS does.

A simple real-life example

Think about your home address.

If someone knows your address, they can find your house.

Computers work in a similar way.

Every machine connected to a network needs an address. On the internet, that address is the IP address.

Now imagine you built an app locally on your laptop. Maybe it runs on:

localhost:3000

That works on your own machine because your machine knows what localhost means.

But if you deploy that app to a server on AWS, DigitalOcean, or anywhere else, people cannot visit it using localhost.

They need the address of that server.

That real address is the IP address.

But asking users to remember IP addresses is a terrible experience.

So instead of telling people:

Visit 142.250.183.206

we give the server a domain name like:

myapp.com

Now people can remember the name, and machines can still connect using the IP.

That mapping between a human-friendly name and a machine-friendly IP is the whole point of DNS.

So what is DNS?

DNS stands for Domain Name System.

Let's keep it simple:

DNS is the system that converts a domain name into an IP address.

For example:

You type facebook.com
DNS finds the IP address behind facebook.com
Your browser uses that IP to contact the correct server

It is called a system because it is not just one thing.

It involves multiple parts working together:

your browser
your operating system
DNS caches
a DNS resolver
root name servers
TLD name servers
authoritative name servers

That is why it is not called just "domain name lookup.”

It is a system.

Before DNS goes to the internet, it checks cache

This is one of the most useful things to understand.

When you visit a website, your computer does not always start from scratch.

It first checks whether the answer is already stored somewhere.

This stored answer is called cache.

Think of cache like a shortcut memory.

If the system already knows the IP address for a domain, it can skip a lot of work.

That makes everything faster.

Usually, the lookup goes through these layers:

Browser cache
Operating system cache
DNS resolver cache
If not found, then the full DNS lookup starts

That is why websites often open very quickly the second time you visit them.

The full DNS journey, step by step

Now let's walk through what actually happens when you type:

facebook.com

into your browser.

1. The browser checks its own cache

Your browser first asks:

"Do I already know the IP for this domain?”

If yes, great. It uses that IP immediately.

If not, it moves to the next step.

2. The operating system checks its cache

If the browser does not have the answer, your operating system checks whether it has that domain-to-IP mapping stored.

If the OS already knows it, it returns the IP to the browser.

If not, the request continues.

3. The system asks a DNS resolver

Now the request goes to a DNS resolver.

In many cases, this resolver belongs to your ISP, though it could also be a public DNS service.

Its job is to find the answer for you.

And just like the browser and OS, the resolver also checks its own cache first.

If the resolver already knows the IP for facebook.com, it returns it immediately.

If not, now the real DNS lookup begins.

The resolver starts asking other DNS servers

This is where many learners get confused, but the logic is actually very clean.

The resolver does not magically know every IP address in the world.

Instead, it asks the right servers in the right order.

4. It asks a root name server

The resolver asks a root name server something like:

"I need information about .com. Where should I go next?”

Notice something important:

It is not asking for the final IP address yet.

It is asking where the .com information is managed.

The root server replies with the address of the TLD name server for .com.

5. It asks the TLD name server

Now the resolver goes to the .com TLD server and asks:

"Who is responsible for facebook.com?”

Again, this server usually does not return the final website IP directly.

Instead, it returns the address of the authoritative name server for that domain.

That server is the source of truth for the domain's DNS records.

6. It asks the authoritative name server

Now the resolver asks the authoritative name server:

"What is the IP address for facebook.com?”

This server returns the actual DNS record, such as the IP address.

Now the resolver finally has the answer it needs.

7. The answer comes back and gets cached

Once the resolver gets the IP address, it does two useful things:

it returns the answer to your operating system
it stores the answer in cache for future requests

Then the OS may cache it too.

Then the browser may cache it too.

That means the next lookup can be much faster.

8. The browser can finally contact the server

Now your browser has the IP address.

At this point, it can finally open a network connection to the actual server and send the real HTTP or HTTPS request.

That is the moment when the website request truly begins.

So yes, DNS happens before the browser can talk to the web server.

And that is exactly why DNS matters when learning TLS/SSL.

A simple mental model

If all the server names sound too abstract, use this mental model:

Root server → "I do not know the full answer, but I know who handles .com.”
TLD server → "I do not know the full answer, but I know who handles facebook.com.”
Authoritative server → "I am responsible for this domain. Here is the actual answer.”

That is the chain.

Why DNS is called "resolution”

You may hear the phrase:

DNS resolution

This simply means:

the process of resolving a domain name into an IP address

So if someone says:

"The DNS resolution failed”

they mean:

"The system could not turn the domain name into an IP address”

No IP, no connection.
No connection, no website.

Where subdomains fit into this

Let's say you have a domain like:

example.com

You can create subdomains like:

blog.example.com
api.example.com
admin.example.com

This is useful because one domain can support multiple services.

For example:

blog.example.com → blog website
api.example.com → backend API
admin.example.com → internal admin dashboard

Same parent domain.
Different subdomains.
Different purposes.

That is why learning domain structure matters before learning DNS deeply.

Why websites feel fast after the first visit

A lot of developers notice this but do not always connect it to DNS.

The first request may take a bit longer because the system needs to find the IP.

Later requests are faster because the answer may already exist in:

browser cache
OS cache
resolver cache

That means the system can skip most of the lookup chain.

So if a website opens instantly the second time, caching is often part of the reason.

Does DNS use TCP or UDP?

In simple learning material, DNS is often explained with UDP, and that is a good starting point.

Why?

Because UDP is lightweight and fast. It does not need a full connection setup like TCP.

For many standard DNS queries, that makes it a great fit.

A simple way to think about it is:

DNS wants to ask a quick question
get a quick answer
and move on

That said, in real systems, DNS can also use TCP in some cases.

But when you are first learning how DNS feels fast and lightweight, starting with UDP gives you the right intuition.

Why DNS matters before TLS/SSL

This is the part many people skip.

They jump into HTTPS, SSL certificates, and TLS handshakes without asking a more basic question:

How did the browser even find the server in the first place?

Before secure communication starts, the browser needs to know where to connect.

That means:

resolve the domain name into an IP address
connect to the server
then begin TLS/SSL and HTTP communication

So if DNS is unclear, TLS/SSL will always feel a little foggy too.

Understanding DNS first makes the next networking topics much easier.

Why developers should care about this

It is easy to think:

"Do I really need to know all this? I can just build apps.”

You can. For a while.

But sooner or later, deeper understanding starts to matter.

Maybe:

your production request is slow
your domain is not pointing to the right server
your subdomain is broken
your SSL setup is failing
your infrastructure behaves differently across environments
a tool's official docs feel harder than they should

This is where fundamentals help.

When you understand DNS, you stop treating networking like magic.

You start seeing the path.

And once you can see the path, debugging becomes easier.

A small story every developer can relate to

Imagine this.

You deploy your app.
The code is fine.
The server is running.
But the site still does not open.

At first, you think:

is the backend broken?
is the port wrong?
is Nginx failing?
is HTTPS misconfigured?

But the real problem turns out to be simple:

the domain is not resolving correctly.

That one small DNS issue can make the whole app feel "down.”

This is why solid developers do not only learn frameworks.

They learn what happens around the request too.

The big lesson: do not skip the basics

A lot of hard topics become easier when your basics are strong.

Docker makes more sense.
Kubernetes makes more sense.
TLS/SSL makes more sense.
Load balancers, CDNs, proxies, reverse proxies, and hosting all make more sense.

Not because they are easy.

But because you already understand the ground they stand on.

Many developers struggle with official docs not because their English is bad, but because the underlying computer science concepts are still shaky.

That is normal.

And the fix is not shortcuts.

The fix is going back, learning the core ideas properly, and revisiting them again and again until they feel natural.

That is how real confidence is built.

Demystifying TCP: How the Internet Actually Sends Your Data (Without Losing It)

Tahsin Abrar — Mon, 13 Apr 2026 07:58:22 +0000

Let’s be honest for a second. When we write code to fetch data from a server, we usually don't think twice about how it gets there. We write a simple JavaScript fetch() call, hit save, and boom our frontend talks to our backend.

fetch('https://api.example.com/data', {
  method: 'POST',
  body: JSON.stringify({ message: "Hello World" })
});

To us, it feels like magic. We just say "send this," and it arrives. But the Application Layer (where our code lives) is blissfully unaware of the chaotic, noisy, and unpredictable journey that data takes across the internet.

The real unsung hero making sure your "Hello World" doesn't turn into a corrupted mess of random bytes is the Transport Layer specifically, the TCP (Transmission Control Protocol).

Today, we are going to look under the hood. No dry, boring textbook definitions. Just a practical, developer-friendly look at how TCP actually works, how it keeps our data safe, and why understanding it will make you a much better software engineer.

What is TCP, Really?

Imagine you are mailing a 1,000-page manuscript to a publisher, but the post office only allows you to send one page per envelope.

If you just dump 1,000 envelopes into the mailbox, what happens? Some might get lost. Some might arrive out of order. The publisher would be hopelessly confused.

TCP is the ultimate postal manager. It chops your big data into smaller pieces called segments, numbers them, sends them, and waits for a receipt. If a piece goes missing or gets corrupted, TCP demands that it be sent again.

That’s why the "C" in TCP stands for Control. It controls the transmission so you don't have to.

To do this, TCP breaks communication down into three distinct phases:

The Setup (Three-way Handshake)
The Data Transfer
The Teardown (Four-way Finishing)

Let’s walk through them.

Phase 1: The Three-Way Handshake 🤝

Before TCP sends a single byte of your actual data, it needs to make sure the server is awake, willing, and ready to talk. It does this using a process called the Three-Way Handshake.

Imagine calling a friend on the phone:

You: "Hey, are you there? Can you hear me?" (SYN)
Friend: "Yeah, I hear you! Can you hear me?" (SYN-ACK)
You: "Loud and clear. Let's talk." (ACK)

In TCP terms, it looks like this:

SYN (Synchronize): The Client sends a packet with the SYN flag turned on. It says, "I want to connect, and I'm starting my sequence at number 1000."
SYN-ACK (Synchronize-Acknowledge): The Server replies. "I got your request (ACK 1001), and I also want to connect. My sequence starts at 2000" (SYN).
ACK (Acknowledge): The Client sends one final confirmation. "Got it. I'm ready for your data starting at 2001."

Boom. The connection is established. Now, they can safely send data.

What’s Inside a TCP Segment? (The Anatomy of a Header)

When TCP chops up your data, it doesn't just send raw text. It wraps your data in a Header a block of metadata that contains all the instructions for delivery.

A TCP header is usually between 20 and 60 bytes. Let's break down the coolest parts of this header.

1. The Ports (Source & Destination)

You probably know that an HTTP server runs on port 80, HTTPS on 443, and your local React app maybe on 3000. But have you ever wondered what port the client (your browser) uses to make the request?

The TCP header reserves 16 bits each for the Source Port and the Destination Port. 16 bits means $2^{16} - 1$, which gives us a maximum of 65,535 possible ports.

Well-known ports (0 - 1023): Reserved for big stuff. (80 for HTTP, 443 for HTTPS, 22 for SSH).
Registered ports (1024 - 49151): Used by specific apps (like MySQL on 3306).
Ephemeral / Dynamic ports (49152 - 65535): This is the secret sauce!

When your browser makes a request to Facebook (port 443), your Operating System randomly grabs an unused Ephemeral port (let's say 50153) and assigns it to your browser. So the request goes from Your_IP:50153 to Facebook_IP:443. When Facebook replies, it knows exactly to send the data back to port 50153, so it reaches your exact browser tab!

2. Sequence & Acknowledgment Numbers

These are the page numbers of our manuscript analogy.

Sequence Number: "This is byte number 1001 of my data."
ACK Number: "I successfully received up to byte 1005. Please send byte 1006 next."

3. Window Size (Flow Control)

Imagine trying to drink from a firehose. You'd drown. Servers can experience the same thing if a client sends data too fast.

The Window Size is the server politely saying: "Listen, I can only handle 10,000 bytes at a time right now. Don't send me more than that until I acknowledge receipt, or I'll crash." This prevents overwhelming the receiver.

4. The Checksum (Error Detection)

As data travels across the ocean through fiber optic cables, routers, and Wi-Fi signals, electrical interference can flip a bit (turn a 0 into a 1). Your "I love you" might suddenly turn into "I hate you".

To fix this, TCP uses a Checksum. Before sending, the sender takes all the data, adds it up in a specific binary way, flips the bits (One's Complement), and puts that value in the Checksum field.

When the receiver gets it, they do the exact same math. If their result doesn't perfectly match, they know the data got corrupted in transit. They silently drop the corrupted segment, forcing the sender to re-transmit it.

5. Flags

These are tiny 1-bit switches that tell the receiver what kind of segment this is. Is it a setup request (SYN)? Is it an acknowledgment (ACK)? Or is it time to close the connection (FIN)?

Phase 2: Sending the Data

Once the handshake is done, the actual data transfer begins.

Let's say we are sending the string "Hello World". Based on the Maximum Segment Size (MSS) agreed upon during the handshake, TCP might split this into multiple segments.

The client sends "Hell", the server ACKs it. The client sends "o Wo", the server ACKs it.

Because of the Window Size, the client doesn't actually have to wait for an ACK after every single segment. If the window is large enough, it can blast 10 segments at once, and the server can send a single ACK saying, "Yep, got all 10!"

If an ACK never arrives, the sender's internal timer runs out, and it assumes the data was lost in the void. It then resends the data. That's the beauty of it it guarantees delivery.

Phase 3: The Four-Way Teardown 👋

When the client is done sending data, it doesn't just hang up the phone. It's polite. It initiates a Four-Way Teardown.

Client: Sends a FIN (Finish) flag. "I'm done sending data."
Server: Sends an ACK. "Understood, you're done." (At this point, the server might still have a little bit of its own data left to send back to the client. The client will wait and listen).
Server: Sends its own FIN. "Okay, I'm done sending data too."
Client: Sends a final ACK. "Got it. Goodbye forever."

The connection is closed, and the OS frees up the ephemeral port to be used by another application later.

Why Should You Care as a Developer?

You might be thinking, "This is cool, but my framework handles this. Why do I need to know it?"

Because things break.

When your API requests start timing out, understanding the Three-way Handshake helps you debug if a firewall is blocking your SYN packets.
When you wonder why you can't run two node servers on port 3000, you now understand how Ports bind to processes.
When you design high-traffic systems, understanding Window Size helps you realize why servers get overwhelmed and drop connections.

Understanding TCP is like moving from driving an automatic car to a manual transmission. You don't have to think about the gears every day, but when you're stuck in the mud, knowing exactly how the engine connects to the wheels is what gets you out.

Why We Talk OSI but Live in a TCP/IP World (A Developer’s Guide)

Tahsin Abrar — Sun, 12 Apr 2026 10:55:37 +0000

If you’ve ever sat in a tech meeting and nodded along while another engineer threw around terms like "Layer 7 load balancing" or "L4 routing," you aren't alone.

We talk about networking a lot in software development, but there’s a funny quirk in our industry: the model we learn in textbooks isn't exactly the model that runs the internet.

In our last deep dive, we talked about the OSI model a beautiful, theoretical 7-layer philosophy. But out in the wild? The entire world runs on the TCP/IP model.

Today, let's bridge the gap between theory and reality, figure out how data actually moves across the internet, and look at the only layers you actually need to care about as a software engineer.

The Reality Check: 7 Layers vs. 5 Layers

The OSI model breaks networking down into 7 distinct layers. But the TCP/IP model, which is what actually powers the internet today, condenses things down to just 5 layers:

Application Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer

Wait, what happened to the Presentation and Session layers from the OSI model?

In the real world, they didn't disappear; they just got absorbed. When you are building a modern web app say, a Nuxt.js frontend communicating with a Laravel backend your browser and framework handle everything at once.

When you type "Hello" in a chat app, the Application Layer formats that text into JSON (what the Presentation layer used to do), compresses it, converts it to binary, and even checks if the other person is online with that little green dot (what the Session layer used to do). Because the Application Layer handles all of this heavy lifting, the TCP/IP model just groups them together.

A Crucial Developer Rule: Even though the TCP/IP model condensed the top layers, we still use OSI numbering in our everyday developer conversations! We still call the Application Layer L7. We call the Transport layer L4, Network is L3, and Data Link is L2. If you ever call the Application layer "L5," other engineers will look at you funny. Always stick to the L7 terminology!

Layer 4: The Transport Layer (TCP vs. UDP)

Once your application has prepped the data, it hits the Transport Layer. This is where we decide how the data is going to travel, and you have two main choices: TCP or UDP.

TCP (Transmission Control Protocol)

Think of TCP as the highly reliable, slightly slower courier who requires a signature on delivery. It is 100% controlled.

Imagine you are sending a text message that says "I LOVE YOU." If the data gets scrambled and arrives as "O I V E U Y," you're going to have a bad time. For text, JSON payloads, important API requests, or critical database transactions, we use TCP. It ensures every single piece of data arrives in the exact right order. When using TCP, your data is broken down into chunks called Segments.

UDP (User Datagram Protocol)

UDP is the fast, reckless delivery driver throwing newspapers onto your porch without stopping. It doesn't care if a few get lost in the bushes.

We use UDP for things like live video streaming. If a stream contains 10 million frames and a couple of them drop out, your screen might glitch for a fraction of a second, but the video keeps playing. You wouldn't want the whole live stream to pause just to retrieve one missing frame. When using UDP, your data is broken down into chunks called Datagrams.

Moving Down the Stack: L3 to L1

After the Transport Layer, the data keeps moving down the chain:

Network Layer (L3): This is where IP addresses come in. Your data (the Segment or Datagram) gets tagged with the Sender's IP and the Receiver's IP. Once those are attached, the whole package is now called a Packet.
Data Link Layer (L2): Here, we attach MAC addresses to figure out the physical hardware hops the packet needs to take.
Physical Layer (L1): Finally, everything is converted into 1s and 0s raw electrical signals or light pulses shooting through cables.

A quick note for my fellow software engineers: You really only need to master L7, L4, L3, and L2. Unless you have a burning desire to become an electrical engineer, you can safely let the hardware folks worry about the Physical Layer!

A Quick Trip Back to 1969

You might be wondering: if OSI is the standard, why is TCP/IP so different?

It actually comes down to the Cold War. In 1969, the US Defense Department created an organization called ARPANET. They needed a decentralized network where data could survive even if computers or physical locations were destroyed in a war. Over the next decade, they actively developed the TCP/IP model.

It was messy, organic, and random. In fact, TCP was being used to send data long before IP addresses were even a standard! The beautifully organized, perfectly logical OSI model didn't actually come along until 1984 to try and make sense of it all. We teach OSI first because it's fundamentally easier to understand, but TCP/IP is the battle-tested system that won the internet.

Demystifying Linux: How GNU, Shells, and Terminals Actually Work Together

Tahsin Abrar — Tue, 07 Apr 2026 10:09:39 +0000

If you've been working with Linux for a while, you probably know that "Linux" technically just refers to the kernel. But a kernel alone is not enough to give you a working computer. To get a complete Operating System (what we call a Linux Distribution, like Ubuntu or Fedora), you need a lot of other moving parts.

Today, we're going to peel back the layers of a Linux operating system. We'll look at where the tools we use every day actually come from, the difference between a terminal and a shell, and what happens behind the scenes when you type a simple command.

Let's dive in!

The Origin Story: Enter Richard Stallman and GNU

To understand how Linux works today, we have to travel back to 1983. Back then, an operating system called Unix was highly popular among universities and large companies. The problem? Unix was proprietary and expensive.

A programmer named Richard Stallman didn't like this. He believed software, especially operating systems, should be free and accessible to everyone. So, he started the Free Software Foundation (FSF) and launched the GNU Project.

Fun fact: GNU is a recursive acronym that stands for "GNU's Not Unix!"

Stallman's team began building free, open-source replacements for all the essential pieces of Unix. Their plan was to build everything needed for an OS, so that anyone students, devs, or companies could piece together a free operating system.

If you use open-source tools today, you owe a huge "thank you" to Stallman and the FSF.

The Essential GNU Toolkit

So, what exactly did the GNU project build? They created a massive bundle of tools that bridge the gap between human developers and the kernel. Here are the heavy hitters:

1. GCC (GNU Compiler Collection)

If you've ever written a C program, you know you can't just run the raw text. You need to compile it into binary machine code that the computer understands. GCC is the legendary compiler that makes this happen. Without it, the open-source world as we know it wouldn't exist.

2. glibc (GNU C Library)

This one is fascinating. When you write a simple printf("Hello World"); in C, did you know that printf isn't actually a native part of the C language?

Native C handles things like if/else' statements andfor' loops. But interacting with hardware (like printing to a screen, allocating memory, or reading files) requires talking to the kernel. glibc is the massive library that provides functions like printf, scanf, and malloc. It acts as a translator, taking your code and making the complex "system calls" to the kernel on your behalf.

3. GNU Coreutils

This is the toolbox you use every single day. Have you ever typed ls, cd, cat, grep, cp, or rm?
These aren't just random words; they are individual, standalone programs bundled together in what we call the GNU Core Utilities (or Coreutils). They run in the "user space" and allow you to interact with your system.

The Visual Layer: Desktop Environments (DE)

Okay, so we have the kernel (the engine) and the GNU utilities (the steering wheel and pedals). But how do we actually see what we are doing?

That's where Desktop Environments (DE) come in. When you install an OS and see a taskbar, window frames, a file explorer, and icons, you are looking at the DE.

Here are a few popular ones:

GNOME: The default for Ubuntu, Fedora, and Debian. It's modern and beginner-friendly.
KDE Plasma: Popular on Arch and openSUSE. It's incredibly customizable.
Aqua: The proprietary desktop environment used by Apple for macOS (which includes the Finder and the Dock).

The Desktop Environment is also responsible for giving you a Terminal. On Ubuntu (GNOME), it's called GNOME Terminal. On KDE, it's called Konsole. The terminal is just a graphical window an interface that lets you type things. But it doesn't process the commands itself. For that, it needs a Shell.

The Brains of the Operation: The Shell

If the Terminal is just a blank window, the Shell is the smart program running inside it.

The Shell takes the text you type, interprets it, figures out what program you want to run (like an ls command from the Coreutils), and hands that request over to the kernel. When the kernel is done, the Shell takes the output and prints it on your Terminal screen.

A Quick History of Shells:

sh (Bourne Shell): Created by Stephen Bourne at Bell Labs in 1977. The OG.
ksh (KornShell): Created by David Korn in 1983, adding more features.
bash (Bourne Again Shell): The GNU project's free answer to the original Bourne shell. It became the default for almost all Linux distributions for decades.
zsh (Z Shell): A modern, highly customizable shell. If you use a modern Mac, zsh is now the default

Stop Calling Docker a Tool: The Real Story Behind 'docker run hello-world'

Tahsin Abrar — Mon, 06 Apr 2026 10:57:28 +0000

Let’s get one thing straight right out of the gate: Docker is not just a tool. It’s not just a simple application, and it’s certainly not just a piece of standalone software.

If someone tells you Docker is just a software tool, you can confidently tell them they’ve been misled.

So, what is it? Docker is a platform. It is an ecosystem.

To truly master Docker, you have to stop looking at it as a black box that magically runs your code, and start looking at it as a living, breathing ecosystem. Today, we are going to dive deep into how this ecosystem actually works.

The Ecosystem Analogy

Think about a biological ecosystem a food chain. An earthworm is eaten by a duck, the duck is caught by a snake, the snake is hunted by a mongoose, and the mongoose is swooped up by an eagle.

For the ecosystem to function, every single piece of that chain has to exist and interact. Docker works exactly the same way. It is a chain of distinct technologies working together to create what we call the "Docker Platform."

Before we look at the chain in action, let’s meet the main characters:

Docker Client (CLI): The interface where you type your commands.
Docker Engine (dockerd): The background daemon (the brain) that listens for API requests and manages Docker objects.
Docker Desktop: The unsung hero for Mac and Windows users. It quietly creates a Linux Virtual Machine in the background so the Docker Engine has a Linux kernel to work with.
Docker Images: Think of an image as a "screenshot" or a frozen snapshot of a container.
Docker Hub: The massive, cloud-based database where all these images (like Ubuntu, Redis, Postgres, or Node) live.
Docker Compose: (We’ll save this one for a future post, but just know it’s the orchestrator for multi-container setups!)

The Deep Dive: What actually happens when you hit Enter?

Most developers know how to type docker run hello-world. But what happens in the milliseconds after you hit enter? Let’s connect the dots.

Step 1: The Request

You type docker run hello-world into your terminal. The Docker Client catches this command and translates it into a REST API request. It sends this request to the Docker Engine (specifically, the dockerd daemon).

Step 2: Passing the Baton

dockerd is a busy manager. It receives your request and says, "Hey, **containerd* (the high-level container runtime), handle this for me."*

Step 3: The Cache Check

containerd acts like a smart librarian. First, it checks its local cache. It asks: "Do we already have the hello-world image downloaded on this computer?" If this is your first time running it, the answer is no.

Step 4: The Download (Pulling)

Because the image isn't stored locally, containerd reaches out to Docker Hub. It requests the hello-world image, pulls it down, and caches it locally so it won't have to download it again next time.

Step 5: The Build

Now that it has the image, containerd hands it over to runc (the low-level runtime) and says, "Execute this." ### Step 6: The Kernel Magic
Here is where the real magic happens. runc talks directly to the Linux Kernel (which, if you are on Mac/Windows, is provided by Docker Desktop).

It asks the kernel for two very specific things:

Namespaces: To create an isolated "alternate reality" for the container so it can't see what else is running on your machine.
Control Groups (cgroups): To set strict limits on how much RAM, CPU, and Hard Drive space this specific container is allowed to use.

The kernel agrees, builds this isolated little world, and the container is born!

Step 7: The Response

A new process starts inside that container, executes the hello-world script, and sends a success message all the way back up the chain from the daemon, to the CLI, and finally onto your screen.

What happens if you run it a second time?
Try running docker run hello-world again. Notice how much faster it is? It completely skips Docker Hub. containerd finds the image in the local cache, hands it straight to runc, and the container spins up instantly.

The "Just Make it Work" Trap

You might be wondering: Why do I need to know all of this? Here is a hard truth: there are software engineers out there with 5 to 10 years of experience who couldn't explain what you just read. They never dive deep. They treat Docker as a magical black box because their only goal is to "just make it work."

It’s easy to be lazy. It's easy to just copy-paste terminal commands. But taking the easy route puts a hard ceiling on your career.

Think of your brain like a massive library. If you just throw random facts into it without organizing them, you'll never be able to find the information when a server crashes at 2 AM. But if you take the time to connect the dots if you organize your knowledge logically, understanding how dockerd talks to containerd you create a mental index.

When you learn this way, you never forget.

The 3-Second Trap: Why Your HTML to Laravel Blade Conversions Are Loading So Slowly

Tahsin Abrar — Sat, 04 Apr 2026 07:48:18 +0000

You’re working on a shiny new admin dashboard. You found a gorgeous, lightning-fast static HTML template online. You download it, open the index.html file in your browser, and it loads instantly. Perfect.

You copy that HTML into your Laravel project, paste it into a fresh Blade view, fire up your local server, and hit refresh.

...One second.
...Two seconds.
...Three seconds.

Suddenly, the layout snaps into place, and the icons finally pop onto the screen.

What just happened? How did a blazing-fast HTML file turn into a sluggish mess the moment it touched Laravel?

If you’ve ever spent hours debugging this frustrating delay, you are not alone. As a software architect who has spent years building and scaling Laravel applications, I've seen countless developers fall into this exact trap. Today, we’re going to look at why this "delay dilemma" happens and exactly how to fix it.

The Root Cause: The Asset Linking Trap

When converting a static HTML template to a Laravel Blade file, the most common mistake is treating the Blade file exactly like a plain HTML file.

Because Blade fully supports standard HTML syntax, it’s incredibly tempting to just drag and drop your CSS, JS, and image folders into your project and leave the <link> and <script> tags exactly as they were.

It usually looks something like this:

<link rel="stylesheet" href="css/style.css">
<link rel="stylesheet" href="vendors/fontawesome/all.min.css">
<script src="js/main.js"></script>

In a standard HTML environment, the browser looks for those files relative to where the HTML file sits in the folder structure. But in Laravel, your application is routed through the public directory, and your URLs are dynamic.

The Delay Dilemma Explained

When you leave those relative links in your Blade file, the browser gets confused. It tries to load the CSS or the web fonts for your icons asynchronously. But because the file path doesn't align with Laravel's routing structure, the server can't easily find the assets.

Behind the scenes, the browser is hanging. It is desperately searching for prerequisite files especially icon web fonts and core stylesheets. This creates a massive bottleneck. The browser essentially pauses the visual rendering for 2 to 3 seconds while it figures out what to do with the missing or misaligned assets. Finally, it gives up or falls back, and your page abruptly snaps into view.

You might look at your code and think, "My CSS is there, why is it slow?" The truth is, your CSS might be trying to load, but the broken asset links are holding the rest of the page hostage.

The Fix: Do It the Laravel Way

To solve this, we need to stop relying on generic HTML relative paths and start using Laravel's built-in helper functions. Specifically, the asset() helper.

The asset() function generates a full, absolute URL for your application based on your current request scheme (HTTP or HTTPS). It tells the browser exactly where to look inside the public directory, completely eliminating the guesswork and the load delay.

1. Move your assets
First, ensure all your template's css, js, images, and fonts folders are placed directly inside your Laravel project's public directory.

2. Wrap your links
Next, go through your Blade file and update every single static asset link using the {{ asset() }} syntax.

<link rel="stylesheet" href="{{ asset('css/style.css') }}">
<link rel="stylesheet" href="{{ asset('vendors/fontawesome/all.min.css') }}">

3. Don't forget your scripts and images!
This rule applies to everything. If it's a static file, it needs the asset() helper.

<script src="{{ asset('js/main.js') }}"></script>

<img src="{{ asset('images/logo.png') }}" alt="Dashboard Logo">

A Real-Life Game Changer

I remember mentoring a junior developer a few years ago who was completely stuck on this. They were building a massive admin portal and had spent an entire afternoon profiling database queries, thinking their backend code was making the page slow.

I took one look at their app.blade.php layout file and saw dozens of hardcoded <link href="assets/..."> tags. We spent five minutes wrapping them in the asset() helper. When we hit refresh, that painful 3-second delay was completely gone. The icons loaded instantly, and the page felt native and snappy again.

It was a total game-changer for them.

Fixing Git 'Repository Not Found' & Multiple SSH Key Issues

Tahsin Abrar — Sun, 22 Mar 2026 16:16:50 +0000

If you’ve ever worked with multiple GitHub accounts and suddenly hit errors like:

Repository not found
Can’t clone or push to a private repo
Git showing a weird name like "Pagol98" in commits

…you’re not alone. This is one of those problems that looks confusing at first, but once you understand it, it becomes super easy to fix.

In this post, I’ll walk you through the exact issues, why they happen, and a clean, real-world solution you can reuse in any project.

The Real Problem (What’s Going Wrong?)

Let’s break it down into 3 common issues that often get mixed together:

1. Repository Not Found

git clone https://github.com/username/tailadmin-blade-dashboard.git

Error:

remote: Repository not found.
fatal: repository not found

👉 This usually means:

The repo name is wrong (typo)
The repo is private and you don’t have access
You’re using the wrong account

2. Multiple SSH Keys Confusion

You created:

id_ed25519 (personal)
id_work (work)

👉 But Git doesn’t know which key to use for which repo.

So sometimes:

One repo works ✅
Another repo fails ❌

3. 😅 Random Commit Name (like “Pagol98”)

Git uses:

user.name
user.email

If not set correctly → it uses old/default values.

Real-Life Scenario (Why This Happens)

Let’s say:

You have 2 GitHub accounts → Personal + Work
Both have different SSH keys
You clone using HTTPS or default SSH

👉 Git gets confused:

“Which identity should I use?”

And that’s where things break.

Step-by-Step Fix (Clean & Professional Setup)

Step 1: Create SSH Config File

Path:

C:\Users\Asus\.ssh\config

If not exists → create it.

Now add this:

# Personal GitHub
Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519

# Work GitHub
Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_work

👉 This is the magic step.

Step 2: Use SSH Instead of HTTPS

❌ Don’t use:

https://github.com/username/repo.git

✅ Use SSH:

git@github.com:username/repo.git

Now modify it using your config:

👉 Personal repo:

git clone git@github-personal:username/repo.git

👉 Work repo:

git clone git@github-work:username/repo.git

Step 3: Test SSH Connection

ssh -T git@github-personal
ssh -T git@github-work

✅ Expected:

Hi username! You've successfully authenticated

Step 4: Fix Git Commit Name

Check current config:

git config --global user.name
git config --global user.email

Set correct values:

git config --global user.name "Your Name"
git config --global user.email "your-email@gmail.com"

Per-Repository Config (Best Practice)

If you use multiple accounts, don’t rely only on global config.

Inside a specific repo:

git config user.name "Work Name"
git config user.email "work-email@gmail.com"

👉 This avoids mixing identities.

Step 5: Verify Remote URL

git remote -v

Make sure it shows:

git@github-work:username/repo.git

git@github-personal:username/repo.git

This is one of those issues every developer faces at some point—especially when juggling personal and work GitHub accounts.

The key takeaway is simple:

Git doesn’t “understand accounts” — it only understands configuration.

Once you properly configure:

SSH keys
SSH config
Git user info

👉 Everything becomes predictable and smooth.

How to Set Up Passwordless SSH Login with PuTTY.

Tahsin Abrar — Sun, 22 Mar 2026 01:48:29 +0000

If you’ve ever logged into your VPS again and again using a password, you already know how repetitive and risky it can be.

There’s a better way.

In professional server environments, developers almost always use SSH key-based authentication instead of passwords. It’s faster, more secure, and honestly… once you set it up, you won’t want to go back.

In this guide, I’ll walk you through how to set up passwordless SSH login using PuTTY in a simple, practical way.

What Is Passwordless SSH Login?

In simple terms:

Instead of typing a password every time
You use a private key file stored on your computer
The server verifies it using a public key

Think of it like this:

Your server has a lock (public key), and your computer has the only matching key (private key)

No password needed. Just instant access.

Step 1: Generate SSH Key Pair Using PuTTYgen

First, we need to create two keys:

Private Key (.ppk) → stays on your PC
Public Key → goes to your server

Steps:

Open PuTTYgen (comes with PuTTY)
Under Parameters, select:

Ed25519 (modern, faster, more secure than RSA)

Click Generate
Move your mouse randomly (this generates randomness)
Once done:

Click Save private key
Save it somewhere safe (very important ⚠️)

Copy the public key from:

   Public key for pasting into OpenSSH authorized_keys file

Step 2: Add Public Key to Your VPS

Now we tell the server: “This key is allowed to access you.”

Login to your VPS (last time using password)

Then run:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Open authorized_keys file:

nano ~/.ssh/authorized_keys

Paste your public key

Right-click in PuTTY → it will paste automatically
Then save:

Ctrl + O → Enter → Ctrl + X

Secure the file:

chmod 600 ~/.ssh/authorized_keys

Step 3: Configure PuTTY for One-Click Login

Now comes the fun part no more typing anything 😄

Steps:

Open PuTTY
Go to:

   Connection → Data

Set:

 Auto-login username: your_username (e.g., root / ubuntu)

Go to:

   Connection → SSH → Auth → Credentials

Select your .ppk file

Go back to:

   Session

Enter:
- Host Name (IP)
- Saved Session name (e.g., My Production VPS)

Click Save

Result: One Click Login

From now on:

Open PuTTY
Double-click your saved session

You’re instantly logged in. No password. No hassle.

Real-Life Scenario

Let’s say you’re deploying a Laravel project from GitHub to your VPS.

Before:

Login with password every time
Risk of brute-force attacks
Slower CI/CD setup

After:

Instant login using SSH key
Easy automation (GitHub Actions, scripts)
Much more secure

This is exactly how most production servers are managed in real-world teams.

Setting up SSH key-based login might feel a bit technical at first but it’s one of those upgrades that pays off immediately.

You get:

Better security
Faster access
Easier automation

And honestly… once you start using it, typing passwords will feel outdated.

Why Port 8000 Suddenly Stopped Working on My Local Machine (and How I Fixed It)

Tahsin Abrar — Sat, 10 Jan 2026 09:23:29 +0000

A few days ago, I faced one of those annoying local development issues that waste hours and make you question your sanity.

I started my local server like I always do:

http://127.0.0.1:8000

And suddenly…

Failed to listen on 127.0.0.1:8000
An attempt was made to access a socket in a way forbidden by its access permissions

I tried ports 8001, 8002, 8003… all the way to 8010.
Same error. Every. Single. Time.

If this sounds familiar, this post is for you.

The Confusing Part

The first thing any developer does is check if the port is already in use:

netstat -ano | findstr :8000

👉 Nothing. Empty.

So the port is free… right?

Wrong.

This is where Windows tricks you.

The Real Problem (The Part No One Tells You)

On Windows, some ports are reserved by the OS itself.

This usually happens because of:

Hyper-V
WSL2
Docker Desktop
Windows NAT (WinNAT)
VPN software

Even if no app is using the port, Windows blocks it internally.

That’s why:

netstat shows nothing
Your app still fails to start
You lose time debugging the wrong thing

How I Found the Truth

Run this command as Administrator:

netsh int ipv4 show excludedportrange protocol=tcp

On my machine, I saw this:

Start Port    End Port
7943          8042

Boom.

Port 8000 is inside that range.

That means:

Windows owns the port
Your app is not allowed to bind to it
No process will show up in netstat

Why This Error Is So Frustrating

The error message is unclear
Nothing shows in port checks
Reinstalling frameworks won’t help
Killing processes won’t help

I wasted time restarting apps when the problem was the OS itself.

The Fixes (Pick What Fits You)

Option 1: Use a Different Port (Fastest & Safest)

If you just want to move on:

Example (Django):

python manage.py runserver 127.0.0.1:8080

This works without admin access.

Option 2: Disable Hyper-V (Best for Dev Machines)

If you don’t need Hyper-V:

dism.exe /Online /Disable-Feature:Microsoft-Hyper-V

Restart your PC

This permanently frees ports like 8000.

Option 3: Shutdown WSL (Temporary)

wsl --shutdown

Good if you only need a quick fix.

Option 4: Restart WinNAT

net stop winnat
net start winnat

⚠️ Requires Administrator access
⚠️ May be temporary

What NOT to Do

❌ Don’t reinstall Python / Node / Django
❌ Don’t keep killing random processes
❌ Don’t fight the firewall first
❌ Don’t assume netstat tells the full story

This is not your app’s fault.

If this post saved you time, feel free to share it with another developer who’s stuck staring at port 8000 right now 😄
Happy coding! 🚀

Forem: Tahsin Abrar

Stack Pointer vs Base Pointer: A Friendly Guide to How Function Calls Work

First, What Is a Stack?

What Is a Stack Frame?

A Quick Note About Memory Addresses

What Is the Stack Pointer?

What Is the Base Pointer?

Stack Pointer vs Base Pointer

What Happens When main() Runs?

What Happens When add() Is Called?

Why Do We Need a Return Address?

Why Save the Old Base Pointer?

How add() Finds x, y, and result

Returning Back to main()

A Simple Visual Summary

Does This Always Work Exactly Like This?

A Real-Life Way to Remember It

How to Connect a Namecheap Domain to a DigitalOcean Droplet with Nginx

The Big Picture

Step 1: Create a DigitalOcean Droplet

Step 2: Point Your Namecheap Domain to DigitalOcean

Option A: Use A Records

Option B: Use DigitalOcean Nameservers

Which DNS Method Should You Choose?

Step 3: Wait for DNS Propagation

Step 4: Connect to Your Server with SSH

Step 5: Install Nginx

Step 6: Configure the Firewall

Step 7: Create a Website Folder

Step 8: Create an Nginx Server Block

Step 9: Enable the Site

Step 10: Test and Reload Nginx

Step 11: Add HTTPS with Certbot

Final Architecture

Why This Feels Different from cPanel Hosting

A Real-Life Example

Hubs, Switches, and Routers Explained Like You're Debugging a Real Network

First, Imagine a Small Room Full of Computers

The Hub: The Loud but Not-So-Smart Device

Why is a hub considered "not smart"?

Simple way to remember a hub

The Switch: A Smarter Device That Learns

What Happens When the Switch Does Not Know the Destination?

How the Switch Learns Over Time

Simple way to remember a switch

Hub vs Switch in One Simple Example

Where Does the Router Fit In?

Simple way to remember a router

Your Home Router Is Usually More Than Just a Router

LAN Interface and WAN Interface

LAN side

WAN side

How Does a Computer Decide Where to Send Data?

Example 1: Sending Data Inside the Same Network

Example 2: Sending Data Outside the Network

Important Detail: MAC Address Changes, IP Address Stays

A Developer-Friendly Example

Quick Comparison: Hub vs Switch vs Router

Common Terms You Should Remember

Frame

Packet

Segment

MAC address table

Default gateway

A Simple Mental Model

DNS Made Simple: What Really Happens Before Your Browser Opens a Website

First, let's understand the URL

Why domain names exist

A simple real-life example

So what is DNS?

Before DNS goes to the internet, it checks cache

The full DNS journey, step by step

1. The browser checks its own cache

2. The operating system checks its cache

3. The system asks a DNS resolver

The resolver starts asking other DNS servers

4. It asks a root name server

5. It asks the TLD name server

6. It asks the authoritative name server

7. The answer comes back and gets cached

What Happens When `main()` Runs?

What Happens When `add()` Is Called?

How `add()` Finds `x`, `y`, and `result`

Returning Back to `main()`