Forem: Saumya Agrawal

The "Everything is a File" Tour of Linux

Saumya Agrawal — Wed, 22 Apr 2026 13:48:08 +0000

I wanted to overcome my command line phobia and join the 4% club of human bots who don't panic when they see the terminal, typing away in their plain terminal. I wanted to feel like a hacker. Not the movie kind with three keyboards and cascading green text, but the kind who actually understands what their computer is doing. So I googled "How to learn Linux" and landed on the most mundane, beige documentation website I have ever seen in my life. I dropped into forums next, expecting a more human approach. The first post I found had someone saying "just build your own kernel." I just wanted to learn things, not go on a spiritual journey.

People told me Linux had a learning curve. Except this curve was a cliff.

If you want a 12-minute brush through Linux basics before diving into the weird stuff, Fireship made a video for exactly that.

Before we go into a rabbit hole, I will suggest to try all of this on a VPS, a VM, or a Docker container. Not your main machine. The reason is simple: some of what I will show you involves deliberately breaking things. Try to understand the command before copying, because imagine copying rm -rf /. But if you are HIM, nobody is stopping you. On a throwaway container? You type exit, spin up a fresh one, and try again. Freedom to destroy without consequences is genuinely how you learn Linux fastest.

Two tools that will save you more than any tutorial

Before anything else: man and tldr. These are your cheat codes.

man is the built-in Linux manual. Every command, every system file, every config format has one. When you wonder what a flag does or what a file is for, man has the answer written by the people who built the thing.

man ls
man chmod
man 5 passwd      # the 5 means file format manual, not the command
man resolv.conf   # the config file itself has a man page

The problem with man is density. It was written by engineers for engineers. Enter tldr, a community-written alternative that gives you just the practical common cases.

apt install tldr
tldr ls
tldr chmod

tldr gives you five useful examples instead of fifty pages of specification. Use tldr when you want to quickly understand what something does. Use man when you need the full picture. If man is the textbook, tldr is the cheat sheet your classmate scribbled the night before the exam.

One more habit worth building early: when something fails, read the actual error message before googling. "Permission denied" means permissions. "No such file or directory" means the path is wrong or the file doesn't exist. "Command not found" means it is not installed or not in your PATH. Linux error messages are not trying to confuse you. They are telling you what happened.

What even is `/etc`

/etc is where Linux keeps its brain. Configuration for almost everything the system does lives here in plain text files you can open with any editor. I spent the first hour just running ls /etc and opening random files, and breaking things up. That felt like finding an unlocked door in a building I thought was sealed.

DNS redirection or how I broke Google with one line

The one thing I tried in /etc was /etc/hosts. I wanted to reach my local dev server by a name instead of 127.0.0.1:3000. Opening the file:

nano /etc/hosts

127.0.0.1   localhost
::1         localhost ip6-localhost

I added one line at the bottom and saved:

127.0.0.1   myapp.local

It worked immediately. No restart, no daemon reload. The file is read fresh on every single lookup because this check happens before Linux even thinks about asking a DNS server anything.

Then I had an idea. What if I pointed instagram.com at localhost?

nano /etc/hosts
# add: 127.0.0.1   instagram.com

ping instagram.com

PING instagram.com (127.0.0.1) 56 bytes of data.

This is poor man's parental control. All of Meta's infrastructure, the entire DNS system, bypassed by one line in a text file on your machine. The whole internet is the fallback. This file runs first.

Imagine making your friend slowly lose their mind on a shared Linux machine, redirect their most visited sites to 127.0.0.1 in /etc/hosts. They will restart their wifi three times, blame their ISP, factory reset their router, and spend an hour in a chat with customer support before anyone thinks to check a text file.

`/etc/resolv.conf`: the file that keeps rewriting itself

Once I understood /etc/hosts, I wanted to know what happened when a hostname was not found there. That fallback is /etc/resolv.conf, which holds the actual DNS server address the system asks.

cat /etc/resolv.conf

# This file is managed by man:systemd-resolved(8). Do not edit.
nameserver 127.0.0.53

I had edited this on my machine and my changes kept vanishing. Now I understood why. systemd-resolved is a local DNS middleman running at 127.0.0.53. It manages this file and rewrites it whenever it restarts.

Let's break the internet:

echo "nameserver 0.0.0.0" > /etc/resolv.conf
ping google.com

ping: google.com: Temporary failure in name resolution

The machine is still connected to the network. It just cannot resolve any names because it is asking a DNS server that does not exist. apt update fails, curl fails, package installs fail. The network is fine, only name resolution is dead. This is what a misconfigured DNS server looks like from the inside.

# Fix it immediately
echo "nameserver 8.8.8.8" > /etc/resolv.conf

The permanent fix without the file fighting back is editing systemd-resolved's own config:

nano /etc/systemd/resolved.conf
# under [Resolve]:
# DNS=1.1.1.1
# FallbackDNS=8.8.8.8
systemctl restart systemd-resolved

`/etc/passwd` and `/etc/shadow`: the user accounts are just a text file

I heard that everything in Linux is treated as a file, from hardware device to system configurations, just a file. This in itself was surprising to me, till I started exploring it through /etc/passwd

cat /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
saumya:x:1001:1001::/home/saumya:/bin/bash

# the above is in the form of name:password:UID:GID:GECOS:directory:shell (root:x:0:0:root:/root:/bin/bash)

Seven colon-separated fields per line: username, password placeholder, user ID, group ID, comment, home directory, login shell. The x in the second field means the actual password hash is stored in /etc/shadow, which only root can read.

sudo cat /etc/shadow | grep saumya

saumya:$6$rounds=4096$saltstring$hashedpassword:19820:0:99999:7:::

# 9 fields separated by ':'

The 9 fields are username, encrypted password, last change, minimum age, maximum age, warning, activity, expiration and reserved.

$6$ means SHA-512. The rounds=4096 deliberately makes hashing slow. Slow hashing means brute-force attacks take longer. Your password is protected partly by intentional computational expense.

Now the interesting part. Every account with /usr/sbin/nologin as its login shell cannot open an interactive session. Try to SSH in as www-data and the connection closes immediately. No password prompt, no shell, nothing. These accounts exist only so the processes running as them have a numeric user identity for permissions. They are not meant for humans to log into.

Now, i wanted to try breaking it and hence, changed my login shell to /bin/false in /etc/passwd.

nano /etc/passwd

# find your line, change /bin/bash to /bin/false

When i tried to connect in a new terminal, the session closes the instant the shell starts because /bin/false exits immediately with a failure code. My account exists, password is correct, the SSH connection succeeds, but I am immediately disconnected. I have locked yourself out without deleting the account or changing the password.

I fixed the current session by changing /bin/false back to /bin/bash.

`/etc/ssh/sshd_config`: watching bots try your front door

On any internet-facing VPS, run this after it has been up for a day:

grep "Failed password" /var/log/auth.log | wc -l

On a fresh VPS after few hours, that number is usually in the thousands. Automated bots scan every IP address on the internet looking for open port 22 and trying common username and password combinations. root, admin, ubuntu, 123456. Constantly, from everywhere.

All SSH behavior is controlled by /etc/ssh/sshd_config:

nano /etc/ssh/sshd_config

You would see a file with multiple lines with Port info, permits and authentications. Two lines that matter immediately:

PasswordAuthentication no
PermitRootLogin no

Setting PasswordAuthentication no means SSH only accepts key-based authentication. The bots still knock but there is nothing to brute-force. No password means no attack surface. PermitRootLogin no means even with valid root credentials, nobody SSHs directly into root.

Want to watch the bots in real time:

tail -f /var/log/auth.log

Run that for five minutes on a fresh VPS. The attempts come in constantly from IP addresses across dozens of countries. It is mildly unsettling and also clarifying. This is just what the internet is like all the time.

After disabling passwords:

systemctl restart sshd
grep "Failed password" /var/log/auth.log | tail -5
# bots still try, still fail, but now they fail faster

Whenever the bots try a password, the server tells them 'NO', not even letting them trying the password to authenticate.

`/etc/fstab`: the file that can stop your machine from booting

/etc/fstab is read at boot. Linux mounts everything listed here. USB drives, additional partitions, network shares. Get an entry wrong and the machine may not boot.

cat /etc/fstab

# in the order
# file system, mount point, type, options, dump and pass


UUID=abc123   /        ext4    defaults    0 1
UUID=def456   /boot    ext4    defaults    0 2
tmpfs         /tmp     tmpfs   defaults    0 0

UUID is used instead of the device name because the name might change but the UUID won't. This acts as the Aadhar Number of the device.

The experiment:

nano /etc/fstab
# add at the bottom:
broken-entry-here

'broken-entry-here' is a string of text without the columns. When the mount command encounters it, it has no idea what the device is, and where it should be mounted.

Now test without rebooting:

mount -a

This command is essentially the dry run of the boot process.

mount: /: can't find broken-entry-here.

Error. Exactly what you would get on boot if you saved this and restarted. Fix it by removing or commenting out the broken line, then run mount -a again to confirm it passes.

The rule: always test with mount -a before rebooting when you touch /etc/fstab. Always. A bad fstab entry drops you into recovery mode or an emergency shell with no obvious explanation. Keep a mental note that this file exists and kills boots if you get it wrong.

`/proc`: the folder that is not actually on disk

/proc is a virtual filesystem. There are no files here stored on disk anywhere. When you read something from /proc, the kernel generates the content on the spot from its own live internal data. It is a window into running system state, not stored data.

cat /proc/meminfo

Run it twice, ten seconds apart. The numbers change. Because it is live.

cat /proc/cpuinfo | grep "flags" | head -1

The flags like vmx, aes and sse which details the CPU capability the processor supports. vmx means hardware virtualization is available. If you try to run KVM and it refuses, check for this flag. aes means the CPU has built-in AES hardware acceleration. Disk encryption and TLS are genuinely faster because of this single flag. sse/avx means CPU has Streaming SIMD Extensions which can boost performance for heavy computations, and video encoding.

The per-process data is where things get interesting. Every running process gets its own directory:

# Find something running
ps aux | grep nginx
# Say it's PID 1234

ls /proc/1234/

cmdline  cwd  environ  exe  fd  maps  mem  net  status

fd/ lists every file descriptor the process has open right now. Log files, sockets, pipes, all of it as symlinks. environ has the exact environment variables the process launched with. cmdline shows the full command that started it. status has memory use, current state, which user it runs as.

cat /proc/1234/cmdline | tr '\0' ' '
ls -la /proc/1234/fd/

The kernel stores command arguments separated by null bytes (\0) to avoid confusion with spaces inside arguments. tr swaps those null spaces to make it readable.

When you delete a file while a process holds it open, the data stays on disk. The file is gone from ls but the space is allocated until the process releases its file descriptor. In Linux, file is a link to a block of data, you are only removing the name. If the process has file descriptor open, data block will be kept alive. By redirecting to the FD in /proc, you're telling the kernel to wipe the actual data blocks while leaving the 'ghost' handle intact.

Find these with lsof | grep deleted. Fix without restarting the process:

> /proc/1234/fd/4

That truncates the held-open file to zero bytes through the process's own descriptor. Disk space reclaimed, process uninterrupted.

Routing: where packets actually go

The routing table is what your machine consults before sending any packet. It decides which network interface and which gateway to use.

ip route show

default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.100 metric 100
# local lane
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100

The default line handles everything. It says "for any destination I don't have a specific rule for, send it to 192.168.1.1." That is your router. Every internet-bound packet passes through that rule.

Delete it and watch what happens:

ip route del default
ping google.com

connect: Network is unreachable

The machine is still on the network. It just cannot reach anything outside the local subnet because there is no default route. This is one of the first things to check when a server cannot reach the internet. The default route may simply not exist, perhaps because a VPN misconfigured it, or because someone ran ip route flush without knowing what it did.

ip route add default via 192.168.1.1   
# put it back

# Most useful debugging command for routing
ip route get 8.8.8.8

8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.100

One line is the complete answer about which interface and gateway any packet would use to reach any destination.

`/dev`: the devices that are not devices

/dev/null, /dev/zero, /dev/random all live in the same directory as actual hardware. They have the same character device type marker. None of them are physical hardware.

/dev/null is a black hole. Write anything to it, and it is gone silently. Read from it, you get immediate end-of-file. This is what command > /dev/null 2>&1 does: stdout goes to the black hole, 2>&1 sends stderr to wherever stdout is going (also the black hole).

The numbers represent 'streams.' 1 is standard output (normal text), and 2 is standard error. 2>&1 means, take all the errors and send them into the same pipe where the normal text is going. Since that pipe leads to /dev/null, the command becomes perfectly silent.

# Silence all output but still check if it worked
some_noisy_command > /dev/null 2>&1
echo $?     # 0 means success, anything else means it failed

/dev/zero produces infinite zero bytes. Good for filling disks or creating blank test files:

fallocate -l 500M bigfile   # faster for large files
# or the /dev/zero version:
dd if=/dev/zero of=bigfile bs=1M count=500

df -h    # watch disk fill up
rm bigfile

fallocate is instant because it just tells the filesystem to reserve the space without actually writing anything to the disk. dd if=/dev/zero forces the CPU to actually churn out millions of zeros and write them one by one.

/dev/urandom produces cryptographically random bytes collected from hardware entropy:

cat /dev/urandom | tr -dc 'a-zA-Z0-9' | head -c 24
echo
# or the cleaner version:
openssl rand -base64 18

The thing that made this concrete for me: the same read() system call your code uses to open a text file reads random bytes from /dev/urandom. Same interface but completely different behavior underneath. That is the "everything is a file" idea became real.

`/boot`: where the kernel lives

ls /boot

vmlinuz-5.15.0-91-generic
initrd.img-5.15.0-91-generic
grub/
config-5.15.0-91-generic

vmlinuz is the compressed Linux kernel (vm = virtual machine, z- compressed like .zip). The actual operating system, stored as a file. initrd.img is a temporary RAM filesystem that acts as a bridge, which loads before the real filesystem mounts at boot. grub/ has the bootloader that lets you choose between operating systems.

cat /boot/config-$(uname -r) | grep CONFIG_EXT4

CONFIG_EXT4_FS=y

That file is the kernel build configuration. Every driver, every feature, listed. Most of it is cryptic without context but searching it teaches you what the kernel actually supports.

The only advice here: do not delete anything from /boot. Deleting vmlinuz means the computer cannot boot at all. Recovery requires a live USB. This is the one folder in the filesystem where curiosity should not turn into experiments.

Consider /etc is the brain and /proc is the nervous system, /boot is the heart of Linux.

`/var/log`: the system's diary

/var/log is where the machine writes what happened. Everything.

ls /var/log

auth.log    syslog    kern.log    dpkg.log
nginx/      apt/      journal/

auth.log records every login, failed or successful. syslog is the general system log. kern.log has kernel messages. dpkg.log records every package installed or removed and when.

Some logs are plain text files you can cat like syslog, while others live in the journal/ directory stores logs in a binary format to make them searchable and faster to filter. The journalctl command is used to read these binary logs.

tail -f /var/log/syslog           # live system events
journalctl -u nginx -f            # live logs for a specific service
journalctl -xe                    # recent journal with explanations
journalctl --since "1 hour ago"   # last hour of everything

When something breaks, look for the log file for the specific thing that broke. It almost always contains the exact error. If logs kept growing forever, they’d fill your entire disk. Linux uses a tool called logrotate that periodically takes the old log, compresses it in the .gz files, and eventually deletes it

`/etc/systemd/system/` writing a service that survives crashes

Systemd starts everything on boot and manages services. Unit files in /etc/systemd/system/ tell it what to run.

I wanted a script running on boot that restarted if it crashed. Cron can run on boot with @reboot but has no crash recovery. A service file does:

nano /etc/systemd/system/myapp.service

[Unit]
Description=My app
After=network.target

[Service]
Type=simple
User=saumya
WorkingDirectory=/home/saumya/app
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

After=network.target line is a safety check that tells Linux to not start this app until the network is actually up.

By default, system services want to run as root and can be a security risk. If the app gets hacked, User= makes sure the attacker is trapped in the user account and doesn't get access to keys. WorkingDirectory ensures that if the code looks for a file in ./config, it's looking in the right folder.

systemctl daemon-reload
systemctl enable myapp
systemctl start myapp
systemctl status myapp

Restart=on-failure is the important line. The process crashes, it comes back in 5 seconds because of RestartSec=5 which can be adjusted. You stop it with systemctl stop. The distinction between a crash and an intentional stop is handled automatically.

Logs for this service:

journalctl -u myapp -f

`PATH` why commands vanish when you break one variable

PATH tells the shell where to look for executables. When you type ls, the shell searches every directory in PATH until it finds a file named ls. If PATH is wrong, every command fails.

export PATH=""
ls

bash: ls: command not found

Everything is gone. The binaries still exist on disk but the shell just lost its map. It can be fixed with:

export PATH=/usr/bin:/bin:/usr/sbin:/sbin
ls    # back

Why this matters beyond the experiment: cron jobs run with a stripped PATH by default. If your script calls something in /usr/local/bin and cron's PATH does not include that directory, the cron job silently fails with "command not found" while the exact same script works fine in your terminal. Set PATH explicitly in your crontab:

PATH=/usr/local/bin:/usr/bin:/bin
* * * * * /home/saumya/myscript.sh

If you’re ever unsure where a command is actually coming from, use which. Running which ls shows the exact path the shell found. It also helps to verify if the map is working.

Permissions

Permissions in theory is chmod, rwx, octal numbers. In practice I kept getting them wrong until I broke something on purpose.

echo '#!/bin/bash
echo "this ran"' > myscript.sh
./myscript.sh

bash: ./myscript.sh: Permission denied

The file exists and the content is correct, but newly created files have no execute permission. Check with:

ls -la myscript.sh
# -rw-r--r-- 1 saumya saumya 30 myscript.sh

No x anywhere. Add it:

chmod +x myscript.sh
./myscript.sh
# this ran

Now the more interesting break. Remove execute from ls itself:

chmod -x /bin/ls
ls

bash: /bin/ls: Permission denied

ls still exists on disk. It just cannot be executed. From the shell's perspective it might as well not be there. Fix:

chmod +x /bin/ls

The three positions: owner, group, others mean the same permissions behave differently depending on who runs the command. When your web server returns 403 errors and logs say "permission denied," this is why. The files exist, the server is running, but www-data does not have the permission to read them.

chown -R www-data:www-data /var/www/html
chmod -R 755 /var/www/html

For a file: +x means you can run it; But for a directory: +x means you can view it using cd.

Linux works on Principle of Least Privilege(PoLP), hence avoid the temptation to run chmod 777.

Environment variables

A friend set a variable in ~/.bashrc. It worked in his terminal. His systemd service couldn't see it which is followed by hours of debugging.

Every process inherits environment variables from its parent. The terminal is started by the login process, which sources ~/.bashrc, which sets your variables. Systemd (PID 1) starts services. Systemd never read your ~/.bashrc. The variables your terminal has, the service has never heard of.

Your terminal reads ~/.bashrc and /etc/profile and has everything you configured. A cron job reads almost nothing. PATH is /usr/bin:/bin. Your tools in /usr/local/bin are invisible. A systemd service reads only what you explicitly declare in its unit file under [Service].

For services, declare variables in the unit file:

[Service]
Environment=NODE_ENV=production
EnvironmentFile=/etc/myapp/.env

For cron, set PATH at the top of the crontab or use absolute paths everywhere. For your own sessions, ~/.bashrc works. The confusion only happens when you expect one environment to be visible in another. In Linux, explicit is better than implicit. If a service needs a variable, tell the service directly.

Terminal shortcuts worth memorizing now

Ctrl+R searches command history interactively. Start typing any part of a command you ran before. This is faster than retyping long paths.

cd - goes to the last directory you were in. Jump between two locations without retyping either path.

!! repeats the last command. The classic use is sudo !! when you forgot sudo.

Ctrl+A and Ctrl+E jump to the start and end of the current line. Ctrl+W deletes the last word backwards. These three reduce terminal frustration noticeably.

When a config file edit breaks something and you want to know exactly what changed: diff /etc/nginx/nginx.conf.backup /etc/nginx/nginx.conf. Keep backups before editing important files. cp nginx.conf nginx.conf.bak takes two seconds.

I found two resources that can be helpful in the learning curve of Linux:

Linux Journey : This has organized learning path that breaks down the complexities of the Linux operating system into digestible stages.
Bandit : It is wargame designed to teach the fundamentals of the Linux command line. Visually looks boring, but is really interesting to follow through.

References

Fireship: Linux in 100 Seconds : start here if you haven't
Linux man pages : every file and command has one
tldr pages : install with apt install tldr, use it for every new command
Arch Wiki : the best Linux documentation on the internet, works for all distros regardless of what you're running
explainshell.com : paste any command and it breaks down every flag visually
The filesystem docs : official kernel documentation

Beyond window: Understanding global and globalThis in JavaScript

Saumya Agrawal — Fri, 13 Mar 2026 08:50:15 +0000

When you wrote your first code in Node.js, you used console and setTimeout without the need for import or declaration. They are present in your IDE, ready to be used. Have you ever wondered where they came from?

It is all the work of global, an object that Node.js creates way before the code even starts to run. An object that holds everything the runtime gives you for free.

JavaScript then introduced globalThis, which is a story in itself about the growth of Node.js.

What Is Node.js?

Before we dive into global, let's understand what Node.js is.

JavaScript was initially intended for browsers to run inside Chrome, Firefox, and Safari. The browsers provided a runtime, an engine to execute the code, along with a set of built-in tools like document, window, and fetch.

Node.js wanted to take the JavaScript engine, V8, out of the browser and make it run anywhere.

The same language running on a different environment, but they have their own version of an object that holds everything a code needs without the need to import.

In the browser: the object is window.

In Node.js: the object is called global.

`global`: The Node.js Global Object

When Node.js starts, it creates a global object and provides it with every tool the code needs.

// When the code is written:
console.log("I am global");
setTimeout(() => {}, 1000);

// Javascript does this in the background:
global.console.log("I am global");
global.setTimeout(() => {}, 1000);

But Node.js allows us to skip adding global every time, and looks things up on global automatically.

console.log(global.console === console);       // true
console.log(global.setTimeout === setTimeout); // true

They are the same objects, global is where they are stored.

What lives on `global`

`this` in Node.js

// At the top of a Node.js file:
console.log(this);          
console.log(this === global);

By looking at the code above, you might expect this to be global. Surprisingly, it is not. The output of console.log(this) is {} which is not global.

Node.js wraps every single file in a function before running it:

//  Node.js silently wraps your file in this
(function(exports, require, module,                     
            __filename, __dirname) {                      

    // everything you write goes in here                  

  });

The code is not at the true top level, but it is inside a function. And this inside that function points to module.exports (which starts as {}), not to global.

console.log(this); // {}
console.log(this === global); // false
console.log(this === module.exports); // true

In Node.js, this returns global when a function is called.

function test() {
  console.log(this);    // Object [global].... (in not-strict mode)
}

test();

// in browser
console.log(this); // window
console.log(this === window); // true

this reference note:

Where code runs	What `this` becomes
Browser top-level	`window`
Node top level	`module.exports`
Function call (non-strict)	`global` object
Strict mode function	`undefined`
Method call	the object
Every environment global	`globalThis`

The Problem That Needed Solving

For years, Node.js developers just used global and browser developers used window. The problem here was the need to access global object in both environments. If you build a utility library that formats dates, handles errors, or adds a bit of logging, and publish it on npm so both browser apps and Node.js apps can use it, it would be difficult because of the different global object.

// This crashes in Node.js as window does not exist here
console.log(window.Math);
// ReferenceError: window is not defined

// This crashes in a browser as global does not exist here
console.log(global.Math);
// ReferenceError: global is not defined

Neither name works in both places. So developers started writing workarounds:

// The only solution was:
const globalObject =
  typeof window !== "undefined" ? window :
  typeof global !== "undefined" ? global :
  typeof self   !== "undefined" ? self   :
  null;

This solved the problem of global. Hence, there came a need to introduce a fix.

`globalThis`

ES2020 introduced globalThis as the standard, universal way to access the global object in any JavaScript environment.

// Works in Node.js:
console.log(globalThis === global); // true

// Works in a browser:
console.log(globalThis === window); // true

// Works in a Web Worker:
console.log(globalThis === self);   // true

Hence, the solution the devs used was replaced by a single line of code

const globalObject = globalThis;

globalThis did not replace global in Node.js. global is still there and valid Node.js code. But globalThis is now the recommended way, especially in the code that might run outside of Node.js.

`global` vs `globalThis`

// These do exactly the same thing in Node.js
console.log(global.Math.PI);      // 3.141592653589793
console.log(globalThis.Math.PI);  // 3.141592653589793

// These are the same object
console.log(global === globalThis); // true

// Both let you access anything on the global scope
console.log(global.setTimeout === setTimeout);      // true
console.log(globalThis.setTimeout === setTimeout);  // true

The difference is:

	`global` works	`globalThis` works
Node.js	Yes	Yes
Browser	No	Yes
Workers	No	Yes
Deno	No	Yes

globalThis is used when a package, utility, or library is created that is meant to be shared.

Do Not Add Things to `global` Yourself

Node.js will not stop you from putting your own values on global. However, it is not recommended to use them, and the following example illustrates why.

If you had a small application that required a username and were about to use that username in multiple files throughout the application, you might think that it would be beneficial to place the username into a global variable so that you can reference it throughout the entire application.

// app.js — your main file
global.username = "User";

console.log("App started");


// greet.js — a separate file
function greet() {
  console.log("Hello, " + username); // no import, just works
}

greet(); // "Hello, User"

As your application grows and you eventually have ten files, then there is a potential that after months of work on your application, you will have a situation wherein you will have printed a username incorrectly and upon opening the file where the erroneous user name was printed (greet.js), you would notice there was no import statement for this username, thus you would be required to search through all of the files to locate the source of the incorrect username.

This is what makes variables defined as global variables invisible, and therefore, there is no trail leading to their origin.

When done correctly:

// user.js: one place where username lives
const username = "User";

module.exports = username;

// greet.js: it's clear exactly where username comes from
const username = require("./user");

function greet() {
  console.log("Hello, " + username);
}

greet(); // "Hello, User"

Hence, if instead of globally defining your username, you had created an import statement for the username and used the import in greet.js to define the username, then anyone who looks at greet.js immediately sees where the username is declared, and there is no need to search. This type of coding is much easier to work with, especially when the size of your application increases, or someone new to the project is introduced.

JavaScript was originally designed to run on the browser. However, Node.js took it outside the browser environment and runs JavaScript without the need for a browser.

The way to access that global object was through the variable global. Likewise, browsers have a built-in global variable called window and Web Workers have a built-in global variable called self, which performs the same function as the global variable.

As JavaScript expanded into other environments, developers wanted to write code that worked across all of those environments, like Node.js, Windows, etc., with fewer modifications. However, because there was no consistent name for the global object, this was difficult for developers.

Fortunately, ES2020 introduced the globalThis variable as the global reference for JavaScript in all environments, it will point to the same object no matter what environment your JavaScript code runs in.

In the case of Node.js, global and globalThis both point to the same place. You would use global if you wanted to write code that was specific to Node.js and you want to explicitly reference global. You would use globalThis if you needed to write code that may eventually run in a different environment.

References

Understanding JavaScript Variables and Data Types Through Game Design

Saumya Agrawal — Sun, 08 Mar 2026 04:19:29 +0000

Whenever you start learning a programming language, be it Python, Java, C++, or JavaScript, one concept is common to all of them: variables and data types. Variables and Data Types are the building blocks of a programming language. Variables solve a simple yet important problem: the memory. When a user types their name into a login form, your code needs to hold onto that name long enough to display it, validate it, or send it to a server. When a game tracks your score, it stores that number somewhere so it can update it every time you earn points. Without variables, every piece of data would vanish the moment it appeared. Your program would have no memory, no state, and no way to make decisions based on what happened before.

But storing data is only half the story. A program also needs to understand what kind of data it is working with. This is where data types come in. Imagine storing the value 50. Is it a number representing age? A score in a game? Or is it the string "50" typed by a user in a form? The program needs to know this difference because it determines what operations can be performed on that value. Numbers can be added, divided, or compared mathematically, while strings are treated as text that can be concatenated, sliced, or formatted. Data types give meaning and structure to the values stored in variables.

Let's explore the two with the concept of games.

Variables: The Save File

Imagine playing an RPG with no save files. Whenever you launch the game, your character is gone, the item in your bag disappears, your world resets. The world has no idea who you are in every single run.

That would be unbearable, exactly what code would be like without variables.

A variable is JavaScript's save file. It's a named space in memory where your program stores a piece of information and can look it up later by that name.

💡 A variable is a named save slot in memory that can store values, so it can be used later.

Hence, every RPG has a save file, where the game save your progress, the character name, the inventory, current HP, upgrades, map, level, character progression. Later when you load your save file, you start from where you left off.

Variable Mapping of Save File

fileName	Store	JS Syntax	Data Type
playerName	Caraxes	let playerName = 'Caraxes'	String
health	70	let health = 70	Number
BOSS_LEVEL	14	const BOSS_LEVEL = 14	Number
swordAcquired	false	let swordAcquired = false	Boolean

In JavaScript code

// Creating save file for a game character
let playerName = "Caraxes";        // slot: name
let health = 100;                 // slot: current HP
let bossLevel = 0;               // slot: starts at 0
let swordAcquired = false;
const BOSS_LEVEL  = 99;         // locked: Number of Boss remains same

// Reading from save slots
console.log(playerName);        // "Caraxes"
console.log(health);           // 100

// The game progresses update the slots
health = 70;                 // player took damage
bossLevel  = 3;              // progression on map
swordAcquired = true;         // sword found

console.log(health);          // 70
console.log(bossLevel);       // 3
console.log(swordAcquired)     // true

Declaring Variables: var, let and const

In games, not all save slots work the same way. Some hold your main campaign state, updated regularly. Some are locked achievement records you can only read, never modify.

JavaScript offers three keywords through which variables can be declared:

var: The original way to declare variables which is now deprecated. It can be redeclared and has no scope. It introduces a lot of bugs to the code by not following the modern rules and concepts introduced to JavaScript.

var playerName = "Caraxes";
console.log(playerName);            //Caraxes

//Redeclared
var playerName = "Neoz";
console.log(playerName);            //Neoz

💡
The problem with var is that it can be redeclared without any warning, which makes it easy to accidentally overwrite a value and create bugs which are difficult to spot.

let: This keyword is used when the variables are expected to see change overtime.

let health = 60;
let healthPotion = 20;
console.log(health);        // 60

// update value
health = health + healthPotion;
console.log(health);       // 80

let health = 100;         // SyntaxError:'health' has already been declared

💡
You can update it freely but you cannot redeclare the same variable in the same scope

const: This keyword is used when the variables are not supposed to change.

const maxHealth = 100;

maxHealth = 200;         //TypeError: Assignment to constant variable

💡
Default to const. Only switch to let if you know the value will change. Never use var in your code.

var vs let vs const

Feature	`var`	`let`	`const`
Redeclared	Yes	No	No
Reassigned	Yes	Yes	No
Scope	Function	Block	Block
Hoisted	Yes, as `undefined`	Yes but not initialized	Yes, but not initialized
Use	Avoid	Yes	Yes, preferred

Primitive Data Types: What Goes In The Slot?

A save file aka variable stores value, and every value has a type. Some slots hold text (a character name), some hold numbers (HP), some hold a simple yes/no flag (does the character have a sword?). In JavaScript, the type of the value determines what it is, how it would behave and what operations can be performed.

There are five primitive data types:

String

Any text placed between quotes, which can be single, double or backticks are treated as string type.

let firstName = "Caraxes";
let greeting = 'Hello';
let message = `Welcome to Neverland, ${firstName}!`; // Template literal

console.log(firstName); // Caraxes
console.log(greeting);  // Hello
console.log(message);   // Welcome to Neverland, Caraxes!

💡
Backtick strings or template literals lets you embed variables using ${}. Prefer them over string concatenation.

Number

Integers and decimals are number in JavaScript.

let health = 100;                 
let healthPotion = 1;              
let level = 0; 

console.log(health-10);    // 90
console.log(level + 1);    // 1

💡
Watch out for floating-point quirks: console.log(0.1 + 0.2); results in 0.30000000000000004 as JS uses IEEE 754 standard. use toFixed() to solve this problem or make use of library in case of sensitive data.

Boolean

They have two states: either yes/true or no/false. They are used in logic and consitions.

let isAlive = true;
let hasArmour = false;

console.log(isAlive);  // true
console.log(hasArmour);  // false

if (!hasArmour) {
  console.log("You are vulnerable in Boss fight"); // You are vulnerable in Boss fight
}

💡
Boolean variables often start with is, has, or can — like isLoggedIn, hasPermission, canUpdate. This makes the intent immediately clear.

Null

It is used to make an intentional empty slot.

let weaponEquipped = null;
console.log(weaponEquipped); // null

Undefined

When a variable or slot exist but a value is not stored in that slot. JavaScript does it automatically when you declare a variable without assigning a value.

let conquest;
console.log(conquest); // undefined

Highlights:

let playerName  = "Caraxes";   // String. Text in quotes
let health      = 100;        // Number. No quotes
let hasShield   = true;      // Boolean. true or false
let equippedGun = null;      // Null. Empty on purpose
let questReward;             // Undefined. Slot exists, nothing saved yet

// typeof reveals the type stored in each slot
console.log(typeof playerName);   // "string"
console.log(typeof health);        // "number"
console.log(typeof hasShield);     // "boolean"
console.log(typeof equippedGun);   // "object"  JS bug
console.log(typeof questReward);   // "undefined"

💡
typeof null returns "object" — this is a bug in JavaScript that was never fixed for backward compatibility reasons.

let weapon = null;
console.log(typeof weapon);      // "object" which is confusing
console.log(weapon === null);   // true. use this instead

Scope: Who can access which slot?

Some game data is global. Your player name shows in every menu, every screen. Other data only exists during a specific fight, a boss's HP bar lives only for that encounter. When you leave the arena, it's gone.

That's scope. It determines where in your code a variable is accessible. let and const are block-scoped, they live only inside the { } where they were created. var ignores blocks and leaks out, which is exactly the problem.

Global Scope

A variable declared outside any function or block is global. It can be accessed anywhere in your code.

Block Scope

Variables declared with let or const inside curly braces { } only exist within those braces.

const GAME_TITLE = "Dark Soul";    // Global scope but cant be changed
let playerName = "Caraxes";        // Global scope but can be changed

if (true) {                        // entering the boss arena
  let bossHealth = 7100;         // block-scoped: stays here
  const bossName   = "Nameless King"; // block-scoped: stays here
  var narrator     = "You can't trap me"; // leaks out!
} 

console.log(playerName);  // "Caraxes" 
console.log(narrator);    // "You can't trap me" | var leaked out
console.log(bossHealth);  // ReferenceError: bossHealth is not defined
console.log(bossName);    // ReferenceError: bossName is not defined

💡
var was designed before block scope existed. It ignores if, for, and while blocks. This means a var declared inside an if statement is accessible outside it. It is a real source of bugs. let and const were created specifically to fix this.

JavaScript Glitches

Every game ships with a few unintended bugs. JavaScript is no different, it had certain behaviour in its early days. As the language evolved, new features were introduced to help in fixing those issues, but the older issues cannot be patched because as too much of the web depends on them.

"5" + 3 equals "53", not 8 The + operator does two different things: math addition and string joining. If either side is a string, JS concatenates instead of adding. This surprises almost every beginner, especially when user input (from forms, URLs, etc.) arrives as a string that looks like a number.

// Bonus points come in from a form, they're a STRING
let bonus = "100";    // looks like a number, has quotes = string
let score  = 50;

console.log(score + bonus);           // "50100" | string concat
console.log(score + Number(bonus));   // 150 | explicit conversion
console.log(score + +bonus);         // 150 | unary + shorthand

const doesn't lock object contents const prevents reassigning the slot, but if the slot holds an object, the object's properties can still change. Think of it as locking the locker door, not what's stored inside it.

const player = { name: "Neoz", health: 100 };

player.health = 80;     // changing a property is allowed
console.log(player);    // { name: "Neoz", health: 80 }

player = {};             // TypeError | can't swap the whole object

Save File

A variable stores a named value in memory.
Use const by default. Switch to let only if the value needs to change. Avoid var.
The 5 primitive types are: string, number, boolean, null, and undefined.
Scope controls where a variable is accessible. let and const are block-scoped; var is not.
Use typeof to inspect what type a variable holds.

Forem: Saumya Agrawal

The "Everything is a File" Tour of Linux

Two tools that will save you more than any tutorial

What even is /etc

DNS redirection or how I broke Google with one line

/etc/resolv.conf: the file that keeps rewriting itself

/etc/passwd and /etc/shadow: the user accounts are just a text file

/etc/ssh/sshd_config: watching bots try your front door

/etc/fstab: the file that can stop your machine from booting

/proc: the folder that is not actually on disk

Routing: where packets actually go

/dev: the devices that are not devices

/boot: where the kernel lives

/var/log: the system's diary

/etc/systemd/system/ writing a service that survives crashes

PATH why commands vanish when you break one variable

Permissions

Environment variables

Terminal shortcuts worth memorizing now

References

Beyond window: Understanding global and globalThis in JavaScript

What Is Node.js?

global: The Node.js Global Object

What lives on global

this in Node.js

The Problem That Needed Solving

globalThis

global vs globalThis

Do Not Add Things to global Yourself

References

Understanding JavaScript Variables and Data Types Through Game Design

Variables: The Save File

Declaring Variables: var, let and const

Primitive Data Types: What Goes In The Slot?

String

Number

Boolean

Null

Undefined

Scope: Who can access which slot?

Global Scope

Block Scope

JavaScript Glitches

Save File

Continue Your Quest

What even is `/etc`

`/etc/resolv.conf`: the file that keeps rewriting itself

`/etc/passwd` and `/etc/shadow`: the user accounts are just a text file

`/etc/ssh/sshd_config`: watching bots try your front door

`/etc/fstab`: the file that can stop your machine from booting

`/proc`: the folder that is not actually on disk

`/dev`: the devices that are not devices

`/boot`: where the kernel lives

`/var/log`: the system's diary

`/etc/systemd/system/` writing a service that survives crashes

`PATH` why commands vanish when you break one variable

`global`: The Node.js Global Object

What lives on `global`

`this` in Node.js

`globalThis`

`global` vs `globalThis`

Do Not Add Things to `global` Yourself