Forem: Rohak

Your OS: Designed for Many, Used by One

Rohak — Tue, 05 May 2026 13:13:15 +0000

I reinstalled Windows few months ago. Three days later, I was still not done with the Settings, Control Panel, Admin account setup and Software installations.

Uninstalling unnecessary or unused stuff is the next nightmare. APPDATA (Local, LocalLow, Roaming), Program Files (Normal and x86), ProgramData, registry, random folders buried in Documents. Don't get me started on the million cache and temp/tmp directories.

Each one is a breadcrumb left behind by an app that assumed it could scatter its files wherever it pleased and you should be fine with it. I wasn't fine with it.

Revo Uninstaller and equivalent tools exists entirely because Windows can't clean up after itself. These third-party tools' entire purpose is to fix a problem that shouldn't exist. And it's still clunky: values (set/unset) mismatch between the app and the system, updating values in the app doesn't change the system settings, etc.

Linux is better, but not solved. Dotfiles and directories in ~/.config, ~/.local, ~/.cache, package conflicts between system-wide and user-wide installs. There's an ongoing argument, that's been going on for decades, about where things should live. It hasn't produced a consensus.

Same problem. Different aesthetics.

Brief History on OS Design Choices

This isn't accidental. Blame historical tech-debt.

Modern OS architecture descends from multi-user mainframe and Unix traditions where many users shared one machine. Separating user data, system data and application data made sense when the alternative was users reading each other's files.

But that's not how most personal computers are used today. My laptop has one user. Most company devices have one owner. The multi-user security model is still there, largely intact, protecting me from... myself and making sure I don't hand over the keys to the system to a bad actor due to a misclick or not reading installation permissions.

The architecture hasn't caught up with the use case.

My 3-Pointer Design Principles

This isn't an implementation proposal and I'm not writing a kernel. These are design suggestions: a set of principles I'd want an OS to follow, IF I had a say in development. These are OS-agnostic principles, applicable to Windows or Linux equally.

1. One User, One Pseudo-Sudo

A personal OS should have exactly two privilege levels:

The user: you, for everything you do day to day.
A pseudo-sudo account: for installs, system changes and anything that touches the OS itself.

The critical distinction: the pseudo-sudo account has a separate password from your sign-in password, and it has no home directory, no user data, no persistent session. It exists only to authorise privileged actions. It is not a person, it is ONLY a key.

No root with a home directory. No administrator account you accidentally leave logged in. No sudo that remembers your password for five minutes and quietly lets the next command through.

Two clear levels with a hard boundary between them.

2. App-Local Everything

Every installed application should own its own config, cache and data, stored within its own directory. Not in %APPDATA%. Not in ~/.config/appname. In the app directory itself.

The benefits are obvious once you say them out loud:

Uninstalling an app means deleting its folder. Nothing left behind.
Moving an app means moving its folder. Config comes with it.
Auditing what an app stores means looking in one place.

The default should be: your files live with you, the app's files live with the app.

3. One Global Config SEAN File

System settings: display, network, audio, locale, power, etc., should live in a single, human-readable global config file. One file, I dub as global-conf.sean.

SEAN (pronounced as "Shaun", a nod to JSON file type and Heavy Rain, the game) stands for: System Entity Attribute Notation file. Format or nomenclature is less important than the principle though.

Template global-conf.sean: -

# global-conf.sean
# System Entity Attribute Notation
# Version: 1.0.0

[system]
system-name     = my-machine
architecture    = x86_64

-> [display]
# Display nested inside system and can be called as display.resolution alternatively
resolution      = 2560x1440
refresh_rate    = 144
scaling         = 125%

-> [audio]
# alternate nesting method
output.device   = default
output.volume   = 25
input.device    = default
input.volume    = 100

--> [headphones]
# Headphones settings nestes inside audio, which in turn is, inside system

[power]
sleep.on_battery     = 15min
sleep.on_ac          = 30min
fast_boot            = false

[network]
hostname        = my-machine
dns.primary     = 1.1.1.1
dns.secondary   = 8.8.8.8
ipv6            = true
firewall.mode   = strict

[security]
screen_lock          = true
screen_lock.timeout  = 5min
encrypt_storage      = true
pseudo_sudo.timeout  = 0

This is better than settings scattered across a registry with 200,000 keys, or being split between /etc, /usr/share, and a dozen other locations, or requiring a GUI to change a setting that is, fundamentally, just a key-value pair.

One file. Version-controllable. Readable without a special tool. Transferable to a new machine without hassle.

The Benefits

If these three principles were the default, a few things become possible that currently aren't.

Reproducible setups: If your system config lives in one file and apps are self-contained, your entire OS setup becomes version-controllable. Fresh install means cloning a repo and running a script. Your global-conf.sean is your IaC.
Automated CI/CD: System changes go through a pipeline, not a manual click-through. Roll back a bad config change the same way you'd roll back a bad deploy. This exists for servers. It should exist for personal machines too.
Pre-hardened images: One can easily build and distribute a baseline image as an add-on. For e.g., a hardened Windows or a Windows-like Linux distro becomes easier to build, maintain and distribute when the architecture supports it.
True portability: New machine, same environment. No dotfile managers, backup tools or manual reinstallation. Just the file and the app folders.

Already Available Alternatives

I'm not claiming these ideas are new. I'm claiming they're not the default and they should be, at least for power users, developers or even in a singly owned system.

NixOS comes closest to my principle 3. Its declarative configuration.nix is similar to the kind of global config I'm describing. The trade-off is complexity. NixOS has a steep learning curve that makes it inaccessible to most users.
Flatpak and Snap move toward my principle 2. Containerised apps with sandboxed storage. But they layer on top of existing systems rather than replacing the underlying model, and config portability is still limited. macOS app bundles gets it right for most apps. But ~/Library still exists, still accumulates and still requires manual archaeology to clean.
ChromeOS implements principle 1 in spirit. It's a single-user OS with a simple privilege model. The trade-off is that it's also a locked-down, cloud-dependent system that trades local control for simplicity.

None of them implement all three. None of them make these principles the default, out of the box, for a general-purpose OS.

The Current Blockers

I've been arguing one side. Here's the other.

Shared state is a real problem. If every app owns its config locally, what happens when two apps need to communicate? A global config for system settings is clean, but apps interact with each other as much as the system. Some shared state is necessary or maybe a non-conventional way of thinking and implementation.
The pseudo-sudo model has edge cases. What happens with background services that always need admin access? Daemons, update managers, antivirus. These don't fit neatly into "user action requiring a one-time key". The model works for interactive installs. It gets complicated for persistent system processes. App/process level elevation can be a thing, but that opens another can of security worms.
Backwards compatibility. Any OS that wanted to implement this would be breaking decades of software assumptions. Apps expect %APPDATA% to exist. They expect to write to /etc. Path migrations are hard.

These aren't reasons not to try. They're reasons the design is harder than it looks.

Final Notes

I want to reinstall my OS and be productive in the matter of hours, not days.
I want to uninstall an app and have it actually be gone.
I want to understand what my system is doing by reading a file, not running a registry editor with seemingly random numbers treated as flag/conditional values/parameters.
Personal computers are personal. The OS should be designed like it knows that.

PS: This is a design opinion piece, not an implementation proposal. If you disagree with the trade-offs or think I've missed something, let's chat. I'd genuinely like to hear more on this.

Technical Write-up: Comparing CMS Architectures

Rohak — Fri, 01 May 2026 11:56:08 +0000

I had a question I couldn't answer from documentation alone: how different does it actually feel to build similar systems in Django vs Express.js?

Similar features and scope, but two different stacks: built in parallel so the comparison would be honest. This post is the pseudo-technical summary of what I observed.

The Project

A Blog/CMS with standard requirements: user authentication, post creation and management, media uploads, role-based access (User and Admin) and a templated frontend (nothing exotic). The kind of system where framework and architecture matter more than LAF (Look and Feel).

Component	Express.js	Django
Runtime	Node.js (JavaScript)	Python 3.13
Database	MongoDB via Mongoose	SQLite via Django ORM
Authentication	Manual JWT + cookie-parser	Django Built-in Auth
Media Handling	multer (server-side storage)	FileField / ImageField
Templating	EJS + Bootstrap 5	Django Templates + Bootstrap 5

Both implementations are in separate repositories. The goal was functional parity, not just similar features, but equivalent behaviour so the comparison would be meaningful and as fair and impartial as possible.

Both repositories are linked in the README file if you want to look at the full implementations.

Authentication: Visible Contrast

This is where the difference between the two frameworks is most visible. Not in logic flow but its implementation.

Express.js: You Own Everything

In Express, authentication doesn't exist until you build it. Here's the user model handling password hashing and login validation:

// Pre-save: salt generation and hashing
userSchema.pre("save", function (next) {
  const user = this;
  if (!user.isModified("password")) return next();

  const salt = randomBytes(64).toString();
  const passwordHash = createHmac("sha256", salt)
    .update(user.password)
    .digest("hex");

  this.salt = salt;
  this.password = passwordHash;
  next();
});

// Login: validate credentials and return token
userSchema.static("userValidatorandTokenise", async function (email, password) {
  const user = await this.findOne({ email });
  if (!user) throw new Error("User Not Found");

  const hashChk = createHmac("sha256", user.salt)
    .update(password)
    .digest("hex");

  if (hashChk !== user.password) throw new Error("Incorrect Password");

  return createUserToken(user);
});

This is before touching JWT issuance, cookie management or route protection middleware, all of which live in separate files that you have to write as well.

The upside: you understand exactly what's happening at every step.
The downside: every step is a surface area for mistakes.

Django: The Framework Handles It

The Django equivalent for user profiles is this:

class Profile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    image = models.ImageField(default="default.jpg", upload_to="profile_pics")

    def __str__(self):
        return f"{self.user.username}'s Profile"

    def save(self, *args, **kwargs):
        super().save(*args, **kwargs)
        img = Image.open(self.image.path)
        if img.height > 480 or img.width > 480:
            op_size = (480, 480)
            img.thumbnail(op_size)
            img.save(self.image.path)

The Profile model handles the custom parts: profile photo with auto-resizing.

Password hashing, session management, login/logout views, CSRF protection, the admin interface, all of that comes from django.contrib.auth, which you import in one line.

The upside: The entire custom auth logic is roughly zero lines in Django.
The downside: Sometimes it may feel rigid to the 'tinkerers'.

Data Modelling: Flexibility vs. Integrity

MongoDB with Mongoose gave you schema flexibility and document structure could evolve without migrations. For a project where post metadata might change frequently, that's an advantage.

Django's ORM enforced relational integrity from the start. Every schema change goes through a migration. That may seem like a time-loss during development, but it is this friction that prevents bugs where your data structure and application logic drift apart.

Neither is universally better.

The answer: if your data structure is uncertain, MongoDB's flexibility is worth having.
If your data structure is known upfront, Django's migrations give you a paper trail and consistency guarantees that are hard to replicate manually.

Developer Velocity: Whatcha Ya Building

Django won on features that map directly to what the framework provides out-of-the-box. The admin interface appears in about 10 lines of configuration. User management, permissions, CRUD scaffolding, placeholder/fake data, all faster.
Express.js won on understanding. Building the middleware pipeline manually meant you could debug it precisely, extend it without fighting the framework and understand exactly what each request was doing at every point in its lifecycle.

The pattern I noticed: Django is faster when the framework has already solved your problem. Express is faster when it hasn't, because you're not working around someone else's abstractions.

Security Posture

This is where I'd push back against the framing that custom implementations are inherently more flexible or powerful.

Django's session management, CSRF protection and password hashing are production-hardened defaults. They're not configurable because the correct configuration is already in place.
Express implementation requires you to make explicit decisions about salt length, hash algorithm, cookie configuration and token expiry. I feel like I made reasonable choices, but they were my choices, made at implementation time and they're only as good as my knowledge at that moment.

For security-sensitive logic specifically, "batteries included" maybe is better if you're not deep in security engineering. If you know what you're doing and aren't bothered by time constraints, you can try custom auth.

Takeaway: Stop thinking about food

Building both taught me something the documentation doesn't say directly: the choice between Express.js vs Django isn't just about JavaScript vs Python. It's about how much of the stack you want to own. Apart from that, if you're a working professional, you also have to take into consideration, the leadership and the existing tech that might give you nightmares during integration testing if you chose incompatible stack.

Express is like an empty house with just walls where you can design your interior while Django is like moving into a fully furnished house.

On the reference projects, both implementations were built with reference to these two tutorial series:

The implementations follow both references closely with minor tweaks. Comments functionality was intentionally excluded from both to keep the scope focused on the architectural comparison rather than feature completeness.

What's worth noting: the tutorials reflect their frameworks' philosophies as much as the frameworks themselves do. Corey's series is methodical and production-minded, it teaches you Django the way Django wants to be used. Piyush's series is fast and mechanical, it prioritises understanding what's actually happening under the hood over getting to a finished product quickly. The code difference and the teaching difference point in the same direction.