DEV Community: Rijul Rajesh

Stopping a Linux Service Isn't Always Enough. systemd Masking Explained

Rijul Rajesh — Fri, 04 Sep 2026 19:51:50 +0000

Hello, I'm Rijul, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product.

In this article, we explore a specific feature of systemd, which is called masking.

If you haven't heard about systemd, it's basically a system and service manager in Linux.

It is responsible for doing things like:

Starting services when you turn on the system
Stopping services
Restarting services, etc.

And systemctl is the command you use to interact with systemd.

Mask in systemd

For more context, we start a service via:

systemctl start service

Now we have this command:

sudo systemctl mask service

Now, if we try to start this particular service, systemd will refuse.

It can give errors like:

Failed to start nginx.service:
Unit nginx.service is masked.

Where mask is useful

Now, on immediately seeing the mask command, it may not be immediately clear what its use is.

Let me explain one situation.

Suppose you have a server where you absolutely don't want Nginx to be running.

In this case, you can try stopping it via:

sudo systemctl stop nginx

But some other script or process somehow starts it again.

This is a problem.

So you want to prevent it from ever being started.

In such cases, mask becomes useful.

All you have to do is:

sudo systemctl mask nginx

What happens when it's masked?

When you mask a service, this is what happens:

sudo systemctl mask nginx

systemd makes a symlink for Nginx. Think of it as a link:

/etc/systemd/system/nginx.service
        ↓
     /dev/null

So systemd looks for:

nginx.service

and finds:

/etc/systemd/system/nginx.service -> /dev/null

systemd interprets that as:

This unit is masked. Don't start it.

Wrapping up

mask is just one of many other commands we use.

Here is an illustration of where mask and unmask fit within the broader range:

So that's about it for this article. See you in the next one.

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production stable while also shipping at high velocity.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

Try LiveReview on your codebase:

How Does AI Know What's Inside an Image? Meet Vision Language Models

Rijul Rajesh — Wed, 02 Sep 2026 19:29:03 +0000

Do you interact with AI models where you put in an image and then it processes it?

Do you wonder what these models are and what is happening behind the scenes?

This is called a VLM, or Vision-Language Model.

A VLM combines vision and language capabilities so that it can process visual information along with text.

A simple way to think about it is:

LLM → Works primarily with text

VLM → Works with images and text

This is a simplified mental model, since VLM architectures can vary. Under the hood, a VLM often combines a vision encoder, a connector or projector, and a language model.

So, how does a VLM actually "see" an image?

How Does a VLM Actually See?

An LLM works with tokens.

But an image is not naturally made up of language tokens.

So we need a way to convert the visual information in an image into something the language model can work with.

A simplified view looks like this:

Image
  ↓
Vision Encoder
  ↓
Visual Representations
  ↓
Vision-Language Connector
  ↓
Language Model
  ↓
Text Response

Let's break this down.

Vision Encoder

The first important component is the Vision Encoder.

Its job is to process the image and turn the visual information into numerical representations that the rest of the model can work with.

Depending on the vision architecture, the image may be divided into smaller regions or patches.

For example:

Each part is processed by the vision encoder, which produces visual representations.

These representations don't simply mean "this patch is a dog" or "this patch is blue."

The vision encoder builds representations that capture visual patterns and context, which can help the model understand things such as shapes, objects, colors, text, spatial relationships, and other visual information.

The exact way this happens depends on the vision encoder architecture. Patch-based processing is common, but it is not universal to every vision system.

The result is essentially a representation of the image that can be passed toward the language model.

Perception and Grounding

Now that we have visual representations, we can talk about two important capabilities: perception and grounding.

Perception

Perception is about understanding the visual content.

It is not just:

"What objects are in this image?"

It can also involve understanding relationships between objects, actions, scenes, and the overall visual context.

For example, given an image of a person riding a bicycle, the model may understand:

Person
  ↓
riding
  ↓
Bicycle

So perception is about building an understanding of what is happening in the image.

Grounding

Grounding is about connecting language to specific parts of the visual input.

For example, if we ask:

"Where is the dog?"

The model could associate the word dog with a particular region of the image.

A simplified representation could be:

{
  "object": "dog",
  "location": "center of the image"
}

In more technical systems, grounding can involve associating language with regions, objects, points, or other parts of an image. Bounding boxes are one common way of representing this, but they are not the only form of grounding.

This becomes especially useful when we want an AI system to not only identify something, but also connect that understanding to where or what it refers to in the image.

VLM vs Multimodal LLM

You may also hear another term:

Multimodal LLM

So what is the difference?

The terminology isn't perfectly standardized, but a useful way to think about it is:

VLM usually emphasizes models that connect vision and language.

Examples include models such as:

Qwen-VL
Qwen2.5-VL
Llama Vision
Pixtral

Multimodal LLM is a broader term often used for language models that can work with multiple types of inputs or outputs, such as:

Text
Images
Audio
Video

So, conceptually, you can think of VLMs as one part of the broader multimodal AI space.

The exact terminology can vary depending on the model and how its creators describe it, so these categories should be treated as a useful mental model rather than strict technical boundaries.

Wrapping Up

So, the basic idea behind a VLM is:

Image
  ↓
Vision Encoder
  ↓
Visual Representations
  ↓
Connector / Projector
  ↓
Language Model
  ↓
Response

The vision side processes the image and produces visual representations.

The connector helps make those representations usable by the language model.

The language model then uses those visual representations together with the text input to generate a response.

VLMs become especially useful when text alone isn't enough to express what we want an AI system to understand.

For example, instead of describing a UI design, diagram, screenshot, chart, or photograph entirely through text, we can simply give the model the image.

In that sense, VLMs give AI systems a way to work with visual information alongside language, making it possible to interact with information that previously had to be described using words.

So that's it about this article, see you on the next one!

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production stable while also shipping at high velocity.

How AI Stores Millions of Vectors Without Using Tons of Memory

Rijul Rajesh — Sat, 29 Aug 2026 19:55:59 +0000

In any sort of AI application, we have the concept of vectors.

Vectors come in different shapes and sizes.

Especially when they are large, we need a good way to manage them.

One way to solve this is by compressing these large vectors.

This is especially relevant to FAISS, which I explained in another article of mine, where it is a library for efficient similarity search over large collections of vectors. Product Quantization is one of the techniques FAISS supports for vector compression and efficient search.

Let's visualize this with a problem.

The Problem

Suppose you have a customer support RAG app

And for that, you have 10 million embeddings containing chunks from product documentation, FAQs, and support articles.

Each of these embeddings has 768 dimensions. Each of those 768 dimensions is used to store a numerical representation of the meaning of that text.

Now, each dimension is a float, so we can think of it as a 32-bit float.

32 bits means 4 bytes.

So:

768 × 4 = 3072 bytes

That's roughly 3 KB per 768-dimensional vector.

Now let's scale this to 10 million embeddings:

10,000,000 × 3 KB = 30 GB

So this 3 KB per vector becomes 30 GB when scaled to 10 million embeddings.

30 GB is roughly the size of a decent-sized game or several high-quality movies.

So imagine searching among this much vector data. It can get expensive.

Let's look at the numbers again.

We have 10 million embeddings. We can't change that.

But we have 3 KB per vector.

What if we could compress that 3 KB further, so that when we scale it to millions of embeddings, we get a much lower storage requirement?

The technique used to do this is called Product Quantization, or PQ.

Let's look at the basic idea behind PQ.

The Basic Idea

Imagine I have this vector:

[0.21, 0.73, -0.15, 0.91, 0.34, -0.52, 0.18, 0.66]

Instead of storing all these floating-point numbers, PQ:

Splits the vector into smaller pieces
Learns representative patterns for each piece
Replaces each piece with the ID of its closest codeword

Let's see an example.

Suppose we split this 8-dimensional vector into 4 pieces:

[0.21, 0.73] [-0.15, 0.91] [0.34, -0.52] [0.18, 0.66]

Now, based on these subvectors, we have a separate codebook for each subvector position.

For the first position, let's assume this is the codebook:

Codebook 1

ID 0 → [0.10, 0.70]
ID 1 → [0.20, 0.75]
ID 2 → [0.80, 0.10]
ID 3 → [-0.20, 0.90]

Now let's match the first subvector to its closest vector in the codebook.

Our first subvector is:

[0.21, 0.73]

This looks pretty close to ID 1, which is:

[0.20, 0.75]

So instead of storing the entire subvector, we store:

Similarly, we do the same thing for the other subvectors.

For:

[-0.15, 0.91]

we have another codebook:

Codebook 2

ID 0 → [-0.30, 0.80]
ID 1 → [0.10, 0.40]
ID 2 → [-0.20, 0.90]
ID 3 → [0.70, 0.20]

The closest one is ID 2.

And we repeat this process for the remaining subvectors.

So the original vector:

[0.21, 0.73] [-0.15, 0.91] [0.34, -0.52] [0.18, 0.66]

can be represented as:

[1, 2, 3, 0]

Each number is an index into a different codebook.

                    Original vector
                          │
          ┌───────────────┼───────────────┐
          ↓               ↓               ↓
      Subvector 1     Subvector 2     Subvector 3 ...
          │               │               │
          ↓               ↓               ↓
     Codebook 1       Codebook 2       Codebook 3
          │               │               │
          ↓               ↓               ↓
        ID 17           ID 42           ID 8

The Compression

So now we have the vector in this form:

[1, 2, 3, 0]

Each ID can be stored using just a few bits.

For this example, let's assume each ID is stored using 1 byte.
(With only 4 possible IDs, 2 bits would technically be enough, but we'll use 1 byte here to keep the example simple.)

We have 4 subvectors:

4 × 1 byte = 4 bytes

Originally, we had 8 floating-point numbers:

8 × 4 bytes = 32 bytes

So the size went down from 32 bytes to 4 bytes.

And remember, this is just an 8-dimensional vector.

Real embeddings are often hundreds or thousands of dimensions.

For example, a 768-dimensional embedding stored as 32-bit floats requires:

768 × 4 = 3072 bytes

With PQ, if we split it into 96 subvectors and store one 8-bit code for each subvector:

96 × 1 byte = 96 bytes

That's 32× less storage for the vector representations.

When you're dealing with millions or billions of vectors, that difference becomes enormous.

And that's the real reason Product Quantization is so useful for large-scale vector search.

Wrapping It Up

At its core, Product Quantization is a clever way of saying:

Instead of storing every number in a vector, split the vector into smaller pieces and represent each piece by the ID of its closest learned codeword.

You lose some precision, but in return, you get dramatically smaller vectors and more efficient approximate distance calculations.

So that's about this article.

See you in the next one!

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production stable while also shipping at high velocity.

Turn Your Obsidian Vault Into an AI-Powered Second Brain

Rijul Rajesh — Thu, 27 Aug 2026 20:26:30 +0000

Hello, I'm Rijul. I'm building git-lrc, a micro AI code reviewer that runs on every commit. It's free and source-available on GitHub. Star git-lrc to help more developers discover the project. Do give it a try and share your feedback

Are you someone who uses Obsidian day-to-day?

Suppose someone asks you about some work you did a few months ago. Or maybe you want to refer back to how you solved a particular problem.

But obviously, you won't remember all the details.

You may need to go through your Obsidian notes just to figure out what you did.

That sounds pretty cumbersome.

When I already had agents doing lower-level work for me, I started thinking, why not get an agent to handle this task as well?

So here I'll show you how I did it.

Introducing the Copilot Plugin for Obsidian

This is a plugin I recently stumbled across.

Just go to Settings → Community Plugins and search for Copilot.

You should find the Copilot plugin.

Just install it.

Once installed, you can connect it to an AI provider. In my case, I connected it to OpenCode.

Now Comes the Fun Part

In the Obsidian sidebar, you'll see a button for Copilot.

Click it, and you now have an AI agent that can work with your Obsidian vault.

So let me demonstrate the problem I had.

I did a Teams integration for an app recently, but I needed to know the specifics of how and when I did it.

Instead of manually searching through my notes and wasting time, I simply asked Copilot:

When did I do stuff related to Teams integration?

You can see the output here:

Now I can see the relevant documents, and I can continue asking questions about them.

For example, I can dig deeper into what I did, when I did it, or how I implemented something.

Wrapping Up

So this is another way you can make your existing workflow a little faster.

It's basically another agent working with your notes, acting more like a second brain that can dig through your old information and bring it back when you need it.

Kind of like a librarian for your brain.

See you in the next article.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

How Does an Email Reach Your Inbox? SMTP Explained with Mailtrap

Rijul Rajesh — Tue, 25 Aug 2026 20:22:35 +0000

Suppose you hit Forgot Password on one of your apps while trying to log in.

A few seconds later, bam, an email appears in your inbox.

Sounds simple, right?

But have you ever thought about what actually happens behind the scenes?

In this article, we'll look at how this works and how you can simulate the whole process for free using Mailtrap.

What Happens When You Send an Email?

The flow we mentioned earlier looks roughly like this:

Your Application
       |
       | SMTP
       ↓
Mail Submission / SMTP Server
       |
       | SMTP
       ↓
Recipient's Mail Server
       |
       ↓
Recipient's Mailbox

But what exactly are a mail server and a recipient's mail server?

Usually, you might think: I clicked Forgot Password, some magic happened, and the email reached my inbox.

That "magic" is handled by several components, including the sending mail server and the recipient's mail server.

What Is a Mail Server?

A mail server is a system responsible for handling email.

It can receive, store, process, and forward emails depending on its role.

For example, when your application needs to send a password reset email, it can hand that email off to a mail server.

The mail server then takes care of sending it toward the recipient.

What Is the Recipient's Mail Server?

The recipient also has a mail server responsible for receiving their email.

For example, if you send an email to someone with a Gmail address, Google's mail infrastructure receives the message and eventually makes it available in the user's inbox.

So the basic idea is:

Your Application
       ↓
Your Mail Server
       ↓
Recipient's Mail Server
       ↓
Recipient's Inbox

Where Does SMTP Come In?

You may also see the term SMTP being thrown around.

SMTP stands for Simple Mail Transfer Protocol.

It is the protocol used for sending and relaying email.

Just like we use a language and set of rules to communicate with each other, applications and mail servers use SMTP to communicate when sending email.

So the application doesn't need to figure out all the details of how the email should be delivered.

It can communicate with an SMTP server and hand the message over to it.

What Is an SMTP Server?

An SMTP server is a server that communicates using SMTP. Depending on its role, it can accept submitted mail, relay mail to another server, or receive mail for its own domain.

An application typically needs configuration like this to connect to one:

SMTP Host: smtp.example.com
SMTP Port: 587
Username: abc123
Password: xyz456

The exact values depend on the SMTP provider you're using.

Test It Yourself: Trying Out Mailtrap

Suppose you want to try this out yourself.

Normally, you might have:

Your App
   ↓
SMTP Server
   ↓
Real User's Inbox

But during development, you probably don't want your test emails going to real users.

This is where Mailtrap can be useful.

With Mailtrap's email sandbox, you can have:

Your App
   ↓
Mailtrap SMTP
   ↓
Mailtrap Inbox

Mailtrap captures the emails inside the sandbox instead of delivering them to the actual recipient.

That's extremely useful when you're developing and testing email workflows.

Setting Up Mailtrap to demo SMTP

To get started, go to Mailtrap and create an account.

Then go to the Sandboxes section:

Mailtrap Sandboxes

Click My Sandbox.

You should see the SMTP credentials required to connect your application.

Keep these credentials handy. We'll use them for the demo.

Sending a Test Email Using SMTP Credentials

You can clone the demo project here:

SMTP Demo GitHub Repository

The project contains a .env.example file with the configuration you need:

SMTP_HOST=
SMTP_PORT=
SMTP_USERNAME=
SMTP_PASSWORD=
FROM_EMAIL=

Here:

SMTP_HOST: The hostname of the SMTP server
SMTP_PORT: The port used by the SMTP server
SMTP_USERNAME: Your SMTP username
SMTP_PASSWORD: Your SMTP password
FROM_EMAIL: The email address the message is sent from

Fill these values using the credentials provided by your Mailtrap sandbox.

Then run the demo application and trigger the email.

python send-email.py

You should see the email appear inside your Mailtrap inbox instead of being delivered to a real recipient.

Wrapping Up

The next time you click Forgot Password and an email appears a few seconds later, there's quite a bit happening behind the scenes.

Your application hands the email to an SMTP server, which can then relay it through the mail system until it reaches the recipient's mail infrastructure.

Whether you're implementing a feature that involves email or simply trying to understand how these seemingly simple things work, SMTP is an important piece of the puzzle.

That's it for this article. See you in the next one.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

How Does an AI Find the Most Similar Information? FAISS Explained

Rijul Rajesh — Mon, 24 Aug 2026 20:08:55 +0000

Imagine you have 100,000 notes and you want to find the one most relevant to a question.

Reading every note one by one works, but it is obviously not efficient.

This is one of the problems FAISS helps solve.

The Problem: Finding Similar Information

Imagine you have a huge pile of notes.

100,000 of them.

Some say:

Python is a programming language.

Others:

Docker packages applications into containers.

And others:

PostgreSQL is a relational database.

Now you ask:

What can I use to run applications in isolated environments?

You want to find the note about Docker.

One simple approach would be:

Question
   ↓
Read note 1
Read note 2
Read note 3
...
Read note 100,000

But this is not efficient.

There is another problem with ordinary keyword search.

Your question says:

"run applications in isolated environments"

But the document says:

"Docker packages applications into containers"

There may not be many exact words in common.

Yet the meaning is related.

This is where semantics come into the picture.

And to work with semantic similarity, we use embeddings.

Turning Notes Into Numbers

An embedding model can turn text into a vector.

For example:

"Docker packages applications into containers"
                    ↓
             Embedding model
                    ↓
       [0.21, -0.73, 0.44, ...]

Another document:

"Kubernetes manages containers"
                    ↓
       [0.19, -0.70, 0.48, ...]

And another:

"Chocolate cake recipe"
                    ↓
       [-0.81, 0.12, -0.34, ...]

The important idea is:

Similar meanings tend to produce similar vectors.

So if we imagine these vectors in a vector space, documents related to Docker and Kubernetes may be closer together, while something about chocolate cake would be much farther away.

So the basic solution is simple:

Find the vectors closest to the query vector.

But then scale becomes a problem.

What happens when we go from:

10,000 documents → 100,000 → 1 million → 10 million?

You could calculate the distance between your question and all 10 million vectors.

That's possible, but it can become expensive.

This is the problem FAISS helps solve.

FAISS: Finding Similar Things Fast

FAISS stands for Facebook AI Similarity Search.

It is a library developed by Meta for efficient similarity search over vectors.

You give FAISS thousands or millions of vectors:

Vector 1
Vector 2
Vector 3
...
Vector 1,000,000

Then you give it a query vector:

Query vector

And ask:

Give me the 5 vectors most similar to this one.

FAISS can return something like:

Closest:

Vector 83721
Vector 192837
Vector 92837
Vector 1827
Vector 72819

The important thing to notice is what FAISS is actually searching.

It is searching vectors, not text.

But How Does That Find the Actual Document?

FAISS doesn't necessarily need to store your documents.

Your application might maintain a mapping like this:

ID 0 → "Python is a programming language"
ID 1 → "Docker packages applications into containers"
ID 2 → "PostgreSQL is a database"
ID 3 → "Kubernetes manages containers"

And FAISS stores the corresponding vectors.

So when you ask:

What runs applications in isolated environments?

The query is converted into a vector and searched against the vectors in FAISS.

It might return:

Closest vector IDs:

1
3

Your application can then map those IDs back to the original documents:

1 → Docker packages applications into containers

3 → Kubernetes manages containers

So FAISS helps you efficiently find which vectors are closest, while your application handles the connection between those vectors and the original data.

What FAISS Actually Does

You can notice the wording in its name:

Similarity Search

FAISS is:

Not a text search engine
Not an AI model
Not an embedding model
Not something that understands English

FAISS doesn't know what Docker is.

It doesn't know what Kubernetes is.

It sees numbers and efficiently searches for vectors that are similar according to the chosen similarity or distance measure.

The embedding model gives the text its numerical representation.

FAISS helps you search those representations efficiently.

FAISS in RAG

If you've read about RAG, you may already know that retrieval is an important part of the process.

A simplified RAG pipeline looks like:

Documents
    ↓
Embeddings
    ↓
Vector index
    ↓
User question
    ↓
Query embedding
    ↓
Similarity search
    ↓
Relevant documents
    ↓
LLM

FAISS can be used in that retrieval step.

Especially when you have a large number of vectors and need to efficiently find the ones most relevant to a query.

Wrapping Up

FAISS is basically a helper for finding similar vectors efficiently.

With a small number of vectors, you may not need anything particularly sophisticated.

But as the number of vectors grows into hundreds of thousands or millions, the way you perform similarity search starts to matter.

That's where technologies like FAISS become useful.

It takes a seemingly simple problem, "find the vectors closest to this one", and provides efficient ways to do it at scale.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

ONNX Explained: The Standard Format for Machine Learning Models

Rijul Rajesh — Sat, 22 Aug 2026 19:23:43 +0000

Did you know there is an open standard for representing machine learning models in a common format?

This is called ONNX.

It provides a standard way to represent machine learning models so they can be used across different runtimes and environments.

Let's see what problem ONNX solves.

The Problem

Suppose you built a machine learning model using PyTorch.

You ran it locally and everything works.

Now you need to deploy it.

The environment where you deploy the model doesn't necessarily have PyTorch installed. You may also need to run the model on different hardware, such as a CPU, GPU, or mobile device.

In the past, this could mean making environment-specific changes or creating custom implementations.

ONNX provides a common representation for the model, making it easier to deploy the model across different runtimes and environments.

What Is ONNX?

ONNX stands for Open Neural Network Exchange.

It defines a standard way of representing machine learning models.

For example, imagine your model performs these operations:

Input
Matrix multiplication
Add bias
ReLU
Output

ONNX can represent this as a computational graph:

Input
  │
  ▼
MatMul
  │
  ▼
 Add
  │
  ▼
 Relu
  │
  ▼
Output

The graph is made up of standardized ONNX operators that describe what the model does.

The resulting model can be serialized as a file such as:

model.onnx

So, at its simplest, ONNX is a standard format for representing machine learning models.

But the ONNX file itself doesn't execute the model.

That's where ONNX Runtime comes in.

ONNX Runtime

ONNX Runtime can load an ONNX model and execute it.

It supports running models across different environments and hardware through its execution providers, including:

CPU
GPU
Mobile
Other supported hardware accelerators

So the basic flow looks like this:

PyTorch Model
     │
     ▼
Export to ONNX
     │
     ▼
 model.onnx
     │
     ▼
ONNX Runtime
     │
     ▼
Run the model

Of course, ONNX doesn't automatically make every model runnable on every piece of hardware. The model's operators and the capabilities of the target runtime still need to be supported.

You can check out this Colab notebook, where we create an ONNX model from PyTorch and then use ONNX Runtime to run it.

Wrapping Up

So that's the basic idea behind ONNX and ONNX Runtime.

ONNX provides a common format for representing machine learning models, while ONNX Runtime provides a way to execute those models.

Together, they make it easier to take a model built in one environment and deploy it across different runtimes and supported hardware.

See you in the next article.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

What Is mDNS? Access Devices on Your Local Network by Name

Rijul Rajesh — Fri, 21 Aug 2026 20:06:22 +0000

Have you ever seen devices on a local network being accessed using a name instead of an IP address?

When I first came across this, I found it pretty interesting.

That technology is called mDNS, or Multicast DNS.

It allows devices on the same local network to discover and communicate with each other using names instead of IP addresses, without requiring a traditional DNS server.

A Simple Example

Suppose your PC has this IP address:

192.168.1.20

And its hostname is:

my-pc.local

Your phone is connected to the same network and has:

192.168.1.30

Normally, if you want to access a web application running on port 3000 on your PC, you might use:

http://192.168.1.20:3000

With mDNS, you can instead use:

http://my-pc.local:3000

You don't need to remember the IP address.

The .local hostname is resolved to the correct device on the local network.

How Does Normal DNS Work?

With traditional DNS, the process looks roughly like this:

You
 ↓
DNS Server
 ↓
"What IP address belongs to example.com?"
 ↓
DNS Server looks up the address
 ↓
IP address returned

The DNS server maintains or retrieves the mapping between a hostname and an IP address.

For example:

example.com → 93.184.216.34

But mDNS works differently.

There isn't a central DNS server that needs to know the address of every device on your local network.

How Does mDNS Work?

Let's say your phone wants to find:

my-pc.local

It can send a multicast query asking:

"Who has my-pc.local?"

The request is sent to the local network.

The PC that owns that hostname responds:

"That's me. I'm 192.168.1.20."

The basic flow looks like this:

Phone
  ↓
"Who has my-pc.local?"
  ↓
Local network
  ↓
PC
  ↓
"That's me. I'm 192.168.1.20"

The phone can then connect to the PC using the returned IP address.

Where Does Multicast Come In?

The M in mDNS stands for Multicast.

For IPv4, mDNS uses the multicast address:

224.0.0.251

You can think of this address as a specific multicast group on the local network.

The devices communicate through this group:

                 Wi-Fi / LAN
                     |
          ┌──────────┼──────────┐
          ↓          ↓          ↓
         PC        Phone      Laptop
          |          |          |
          └──── 224.0.0.251 ───┘

When a device sends an mDNS query to 224.0.0.251, devices listening to that multicast group can receive it.

So if your phone asks:

"Who has my-pc.local?"

the PC can hear the request and respond because it owns that hostname.

Why Is This Useful?

mDNS is particularly useful on local networks where devices need to discover each other without requiring you to manually configure DNS.

For example:

http://my-pc.local:3000
ssh my-pc.local

This is useful for things like:

Accessing development servers
Connecting to computers on your home network
Device discovery
Printers and other network devices
Local development and testing

You don't have to keep track of an IP address that might change.

Wrapping Up

mDNS is essentially DNS for your local network, without requiring a traditional DNS server.

Instead of asking a central DNS server:

"What IP belongs to this hostname?"

a device can ask the local network:

"Who has this hostname?"

The device that owns the name responds with its IP address.

And that's the basic idea behind mDNS.

See you in another article.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

Stop Treating Your Vector Database Like a Black Box: Visualize ChromaDB

Rijul Rajesh — Mon, 17 Aug 2026 20:07:10 +0000

Have you built your first RAG system and set up ChromaDB?

If so, you might have started thinking of ChromaDB as a bit of a black box.

You put documents into it, embeddings come out, searches happen, and relevant chunks are returned.

But what is actually happening inside?

We can make that easier to understand by visualizing the embeddings stored in ChromaDB.

You can get something like this:

Let's see how we can build it.

Before We Start

If you haven't built a RAG system yet, I recommend checking out my RAG article and ChromaDB Article first.

It will give you an idea of how ChromaDB and vector databases work.

Once you're familiar with that, you can come back here and visualize what's happening inside the vector database.

How Does the Visualization Work?

The basic idea is quite simple.

Every chunk in our vector store is represented as a 3072-dimensional vector.

In simple terms, that's a list of 3072 numbers that captures the semantic meaning of that chunk.

The problem is that we can't visualize 3072 dimensions directly.

So we need to reduce those 3072 dimensions down to just 3.

That's where PCA, or Principal Component Analysis, comes in.

What Is PCA?

PCA is a technique used to reduce a high-dimensional vector to a smaller number of dimensions while preserving as much information as possible.

Instead of simply removing random numbers, PCA finds the most important patterns across the dimensions and represents those patterns using fewer dimensions.

In our case:

3072 dimensions
       ↓
      PCA
       ↓
  3 dimensions
       ↓
  3D scatter plot

We can then represent every chunk as a single point in a 3D space.

Chunks with similar embeddings may end up closer together, allowing clusters to appear naturally.

The Five Steps

The visualization script essentially performs five steps.

1. Connect to the Vector Store

The open_store() function opens the local ChromaDB database and gets the rag_demo collection.

I created this RAG demo in my RAG article, so you can check that out if you want to see how the data was created.

2. Pull Out the Records

The collect_entries() function fetches everything we need from the collection:

Embedding vectors
Chunk IDs
Source documents
Chunk text

We will also use the source document information to group the points in the visualization.

3. Compress 3072 Dimensions Into 3

The compress_to_3d() function uses PCA to reduce each 3072-dimensional embedding down to 3 dimensions.

These three values become the X, Y, and Z coordinates of our visualization.

4. Build the Tooltips

The build_hover_labels() function creates the information that appears when you hover over a point.

This lets us see things such as:

Chunk ID
Source document
Part of the chunk text

5. Draw the Scene

Finally, render_scene() creates the interactive 3D visualization using Plotly.

Each point represents a chunk from our vector database.

We also create a separate trace for each source document, which allows us to distinguish where the chunks came from.

The Code

Here is the complete visualization script:

from pathlib import Path

import chromadb
import plotly.graph_objects as go
from sklearn.decomposition import PCA

COLLECTION_NAME = "rag_demo"
DB_PATH = Path(__file__).parent / "chroma_db"
TARGET_AXES = 3


def open_store() -> chromadb.Collection:
    """Return a handle to the local vector collection."""
    client = chromadb.PersistentClient(path=str(DB_PATH))
    return client.get_collection(COLLECTION_NAME)


def collect_entries(store: chromadb.Collection) -> tuple[list, list, list, list]:
    """Pull every stored record out of the collection.

    Returns (vectors, ids, source_tags, chunk_texts) in lock-step order.
    """
    records = store.get(include=["embeddings", "documents", "metadatas"])
    vectors = records["embeddings"]
    ids = records["ids"]
    source_tags = [
        (meta or {}).get("source", "unknown") for meta in records["metadatas"]
    ]
    chunk_texts = records["documents"] or []
    return vectors, ids, source_tags, chunk_texts


def compress_to_3d(vectors: list) -> tuple[object, object]:
    """Fit a PCA model on the vectors and return (model, projected_points)."""
    model = PCA(n_components=TARGET_AXES)
    projected_points = model.fit_transform(vectors)
    return model, projected_points


def build_hover_labels(ids, source_tags, chunk_texts) -> list[str]:
    """Compose the rich tooltip shown when hovering over a point."""
    return [
        f"id: {rid}<br>source: {src}<br>chunk: {text[:120]!r}"
        for rid, src, text in zip(ids, source_tags, chunk_texts)
    ]


def render_scene(
    projected_points,
    source_tags,
    hover_labels,
    variance_explained: float,
) -> None:
    """Build the interactive 3D figure and open it in the browser."""
    figure = go.Figure()
    figure.update_layout(
        title=(
            f"{COLLECTION_NAME} embeddings projected into 3D "
            f"(explained variance {variance_explained:.0%})"
        ),
        scene={
            "xaxis_title": "PCA Axis 1",
            "yaxis_title": "PCA Axis 2",
            "zaxis_title": "PCA Axis 3",
        },
    )

    # One trace per source document so each cluster can be toggled in the legend.
    for source in sorted(set(source_tags)):
        mask = [tag == source for tag in source_tags]
        figure.add_trace(
            go.Scatter3d(
                x=projected_points[mask, 0],
                y=projected_points[mask, 1],
                z=projected_points[mask, 2],
                mode="markers",
                name=source,
                customdata=[
                    hover_labels[i] for i in range(len(mask)) if mask[i]
                ],
                hovertemplate="%{customdata}<extra></extra>",
            )
        )

    figure.show()


def main() -> None:
    store = open_store()

    vectors, ids, source_tags, chunk_texts = collect_entries(store)

    if len(vectors) == 0:
        print("No embeddings found. Run `python ingest.py` first.")
        return

    model, projected_points = compress_to_3d(vectors)
    hover_labels = build_hover_labels(ids, source_tags, chunk_texts)
    variance_explained = model.explained_variance_ratio_.sum()

    render_scene(
        projected_points,
        source_tags,
        hover_labels,
        variance_explained,
    )

    print(
        f"Plotted {len(vectors)} chunks in 3D "
        f"({variance_explained:.0%} of variance preserved)."
    )


if __name__ == "__main__":
    main()

Try It Yourself

Now that you have an idea of how the visualization works, you can try it yourself using my demo repository.

Clone the repository and run:

python ingest.py
python visualize.py

ingest.py loads the data into ChromaDB if it hasn't already been added.

Then visualize.py reads the stored embeddings and launches the 3D visualization.

You should get something like this:

Each dot represents a different chunk in the vector database.

The color represents the source document.

For example, all the red points might represent chunks that came from policies.md.

This gives us a much more intuitive way to look at what's happening inside our vector database.

Instead of just seeing a collection of embeddings, we can actually see how the chunks are distributed in the embedding space.

Wrapping Up

When learning something new, it is easy to stay at the theoretical level.

We can read about embeddings, vector databases, similarity search, and RAG without ever really developing an intuition for what is happening underneath.

Visualization can help bridge that gap.

By reducing our high-dimensional embeddings to three dimensions, we can actually see the data and start developing an intuition for how similar chunks are positioned relative to one another.

It won't show us everything happening inside ChromaDB, but it gives us a useful way to look inside what can otherwise feel like a black box.

See you in another article.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

Keep Up With AI by Building Your First Vector Database with ChromaDB

Rijul Rajesh — Wed, 12 Aug 2026 19:59:39 +0000

ChromaDB is a term you might have heard being mentioned quite often when working with AI applications.

ChromaDB is a vector database.

It is the kind of database you will often see being used in AI applications such as chatbots, RAG systems, and other applications that need to search for information based on semantic meaning.

What Is a Vector Database?

Let's say we have two sentences:

How can I get my money back?

and

What is your refund policy?

The words are different, but the meaning is similar.

To allow a computer to work with this kind of semantic similarity, we can convert text into numbers called embeddings.

An embedding is a numerical representation of the meaning of a piece of text.

A vector database allows us to store these embeddings and later search for information based on their semantic similarity.

ChromaDB is one such vector database.

Installing ChromaDB

Let's start by installing ChromaDB:

pip install chromadb

Once installed, we can import it and create a client:

import chromadb

chroma_client = chromadb.Client()

Now we can create a collection:

collection = chroma_client.create_collection(name="my_collection")

You can think of a collection as a place where we store related pieces of data.

Adding Documents

Now let's add some documents to our collection:

collection.add(
    ids=["id1", "id2"],
    documents=[
        "This is a document about pineapple",
        "This is a document about oranges"
    ]
)

We use collection.add() to add the text to the database.

One useful thing here is that we don't have to manually generate the embeddings ourselves for this basic example.

ChromaDB can generate embeddings for the documents for us.

When you run this for the first time, ChromaDB will download the embedding model it uses to generate these embeddings.

Once the documents and their embeddings are stored, we can search the collection.

Querying the Database

Let's query the database:

results = collection.query(
    query_texts=["This is a query document about hawaii"],
    n_results=2
)

print(results)

Here:

query_texts contains the text we want to search for.
n_results specifies how many results we want to retrieve.

ChromaDB will generate an embedding for the query and compare it with the embeddings stored in the collection.

It then returns the most relevant results.

The output might look something like this:

{
    'ids': [['id1', 'id2']],
    'embeddings': None,
    'documents': [
        [
            'This is a document about pineapple',
            'This is a document about oranges'
        ]
    ],
    'uris': None,
    'included': ['metadatas', 'documents', 'distances'],
    'data': None,
    'metadatas': [[None, None]],
    'distances': [[1.0404, 1.2431]]
}

Notice the distances field.

These values represent how far the results are from the query in the embedding space. The exact interpretation depends on the distance function being used.

In this example, the pineapple document has a smaller distance than the oranges document, meaning ChromaDB considers it more similar to the query.

Getting the Embeddings

By default, the embeddings aren't included in the query result.

If we want to see them, we can explicitly request them:

results = collection.query(
    query_texts=["This is a query document about hawaii"],
    n_results=2,
    include=[
        "distances",
        "metadatas",
        "embeddings",
        "documents"
    ]
)

print(results)

Now the output will include the actual embedding vectors:

{
    'ids': [['id1', 'id2']],
    'embeddings': [
        array([
            [-0.0071,  0.0655, -0.0116, ...,  0.0897,  0.0134],
            [-0.0265,  0.0688, -0.0377, ...,  0.0654,  0.0778]
        ])
    ],
    'documents': [
        [
            'This is a document about pineapple',
            'This is a document about oranges'
        ]
    ],
    'uris': None,
    'included': [
        'distances',
        'metadatas',
        'embeddings',
        'documents'
    ],
    'data': None,
    'metadatas': [[None, None]],
    'distances': [[1.0404, 1.2431]]
}

The actual embedding contains many numbers, so I've shortened the output with ....

The important thing to understand is the flow:

Document
    ↓
Embedding
    ↓
Stored in ChromaDB
    ↓
Query
    ↓
Query embedding
    ↓
Similarity search
    ↓
Relevant documents

And that's the basic idea behind using ChromaDB as a vector database.

Wrapping Up

In this article, we looked at the basics of ChromaDB:

This is only the basic usage.

The more interesting part is seeing how we can use ChromaDB in a real application, such as a RAG system, where we can store documents, search for relevant information, and provide those results to an LLM.

We can explore that in another article.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

You've Heard of RAG. But What Does It Actually Do?

Rijul Rajesh — Mon, 10 Aug 2026 19:56:22 +0000

Have you been scrolling through AI content and constantly seeing the term RAG?

Maybe it sounds like some complicated, high-level AI concept that is difficult to understand.

But RAG is actually fairly simple.

And if you're trying to build AI systems, it is a concept worth understanding.

Let's look at some of the different types of AI systems we see today and understand where RAG fits in.

Types of AI Systems We See Today

There are many different ways of building AI systems today, such as:

Generative AI
RAG systems
Agentic systems
Multi-agent systems

In this article, we'll focus on RAG.

What Is RAG?

RAG stands for Retrieval-Augmented Generation.

The basic idea is simple:

Instead of asking an LLM to answer a question using only what it already knows, we retrieve relevant information and give it to the LLM along with the question.

To understand how this works, we need to look at the main components of a RAG pipeline.

Understanding the RAG Pipeline

A basic RAG pipeline looks like this:

Documents
    ↓
Chunking
    ↓
Embeddings
    ↓
Vector database
    ↓
User question
    ↓
Question embedding
    ↓
Similarity search
    ↓
Relevant chunks
    ↓
Prompt + retrieved chunks
    ↓
LLM
    ↓
Answer

Let's break down each part.

What Is Chunking?

Suppose I have a file called policies.md.

It contains 1,000 lines of information.

I don't want to send the entire document to the LLM every time a user asks a question.

Instead, we break the document into smaller pieces.

This process is called chunking.

Chunking = breaking documents into smaller pieces that can be independently retrieved.

For example:

policies.md
    ↓
Chunk 1
Chunk 2
Chunk 3
...
Chunk 50

Now, instead of searching through or sending the entire document, we can retrieve only the chunks that are relevant to the user's question.

What Are Embeddings?

An embedding represents the semantic meaning of text as numbers.

For example, this sentence:

"What is your refund policy?"

can be converted into an embedding such as:

[0.021, -0.183, 0.442, ...]

The actual embedding contains many more numbers, but the important idea is that text is converted into a numerical representation.

This is useful because we can compare these numerical representations to determine how semantically similar two pieces of text are.

For example, these two questions use different words:

"How can I get my money back?"

and

"What is your refund policy?"

But they have a similar meaning.

Their embeddings should therefore be relatively close to each other.

Understanding the Vector Database

We can store the chunks and their embeddings in a vector database.

We also keep information about where the chunk came from.

Something like:

{
    "text": "Customers can request a refund within 30 days...",
    "embedding": [...],
    "source": "policies.md"
}

So the vector database gives us a way to store our knowledge and later search for information based on semantic similarity.

What Does Retrieval Mean?

Now let's see how retrieval actually works.

Suppose the user asks:

What is the refund policy?

First, we convert the question into an embedding.

Then we search the vector database using that embedding.

The database might return something like:

1. policies.md
   "Customers can request a refund within 30 days..."

2. policies.md
   "Subscriptions can be cancelled at any time..."

3. pricing.md
   "The Pro plan costs $29/month..."

The first result is highly relevant to the question.

Finding these relevant pieces of information is called retrieval.

How RAG Changes the Prompt

Now we have the relevant information.

We can add it to the prompt that we send to the LLM.

Before

User: What is the refund policy?

The model has to answer using only the information it already has.

After

System:
Answer using the provided context.

Context:
Customers can request a refund within 30 days...

Question:
What is the refund policy?

Now the LLM has the relevant information available in its context.

It can generate:

Customers can request a refund within 30 days.

And that's essentially what Retrieval-Augmented Generation means.

Retrieval

Find relevant information.

Augmentation

Put that information into the prompt.

Generation

Ask the LLM to generate an answer using that information.

That's RAG.

Building Your Own RAG: A Simple Example

Now let's take a simple use case and see this in action.

I have a small repository that you can clone and try yourself.

Suppose I have a chatbot that is supposed to answer questions about a company.

The project contains a documents folder with four files:

Company
Policies
Pricing
Products

The chatbot uses Gemini as the underlying LLM.

First, Let's See the Problem Without RAG

First, activate the virtual environment:

source .venv/bin/activate

Then run the chatbot without RAG:

python chat.py --no-rag

Now I'll ask:

What is the company's refund policy?

As you can see, the response is generic.

The chatbot doesn't have access to the company's actual information.

Let's try another question:

Who is the CEO?

Again, we get a generic response.

The problem is that the LLM doesn't have our company's documents in its context.

Now Let's Run the RAG Version

Now let's run the RAG version of the chatbot:

python chat.py

We'll ask the same question:

What is the company's refund policy?

This time, you can see the retrieved chunks.

The system first searches the documents and finds the pieces of information that are relevant to the question.

It then provides those chunks to the LLM so it can generate an answer based on the company's actual information.

Now let's ask something that isn't present in the knowledge base:

Who is the CEO?

This time, the chatbot can recognize that the information isn't available in the knowledge base instead of simply making up an answer.

That's one of the useful properties of RAG.

Wrapping Up

We have built and demonstrated a basic RAG system.

Along the way, we got familiar with concepts such as:

Chunking
Embeddings
Vector databases
Retrieval
Knowledge bases
Retrieval-Augmented Generation

Once we break the process down, these concepts are much simpler than they might initially seem.

Of course, this is only a basic example of RAG.

There are many deeper topics to explore, such as different chunking strategies, embedding models, retrieval methods, reranking, hybrid search, and evaluation.

But for now, you have a basic understanding of what RAG actually does and how the pieces fit together.

See you in the next article.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github

Stop Making Your AI Agent Rediscover Your Codebase

Rijul Rajesh — Sun, 09 Aug 2026 19:49:12 +0000

As I use AI coding agents to work on my repositories, I often find myself opening new sessions for different tasks.

The problem is that every new session starts with the same challenge.

The agent may have to rediscover the codebase.

It may search for files, follow imports, look through related code, and try to understand the project structure all over again.

This gets annoying pretty quickly.

It also means spending additional time, tokens, and context on work that has already been done in previous sessions.

So I started looking for a way to solve this problem, since I imagine many people using coding agents run into the same issue.

That's when I came across codebase-memory-mcp.

What Is codebase-memory-mcp?

You can find the repository here:

https://github.com/DeusData/codebase-memory-mcp

The basic idea is to create a persistent knowledge graph of your codebase that an AI agent can query.

Think about a textbook.

A textbook usually has an index that tells you where to find specific topics instead of requiring you to read the entire book to locate something.

codebase-memory-mcp applies a similar idea to your codebase.

Instead of making the agent repeatedly explore files and related code to figure out where something is, it can query the indexed representation of the codebase and use that information to find the relevant parts.

This gives the agent a better starting point when working on a repository.

Rather than repeatedly asking:

Where is this functionality implemented?

Which files are connected to this component?

Where is this function used?

The agent can use the codebase index to navigate the repository more efficiently.

Installing codebase-memory-mcp

You can follow the installation instructions in the repository's README.

For Linux, you can install it with:

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

Once the installation is complete, you can run:

codebase-memory-mcp install

This configures the MCP server for a number of supported AI coding agents, including OpenCode and Claude Code.

After that, you need to index your project before the agent can query the indexed codebase. The project's README recommends restarting your coding agent and asking it to "Index this project".

Wrapping Up

When we start using AI agents for software development, there are new limitations that we don't encounter in the same way with traditional development.

One of them is the amount of time and context an agent can spend rediscovering a codebase.

Tools like codebase-memory-mcp are interesting because they try to solve that problem by giving agents a persistent representation of the codebase that they can query instead of starting from scratch every time.

As we adapt to agent-based development, understanding these limitations and finding ways to work around them can make the overall development process much smoother.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Give it a ⭐ star on Github