Content
- WHY!
- HOW!
- WHAT NOW!
Imagine two guys just talking about some tech/framework (very easy to imagine I'm sure) which is fascinating to them and just like anybody else gets too excited to a point where one of them describes an idea for a mini-project on the spot. The descriptions go along the lines of something he himself would want to use and haven't found anything just like that. He proposes that there should be a reader application that should have profiles or some preset settings (like notifications, color tone, brightness. etc.) which are enabled whenever he is in the app, the other guy follows... As they use more words they now have a concept which is what this project is about and the framework in the discussion is a noob-friendly, cross-platform mobile framework we have all heard of, flutter. Flutter has become very popular and we wanted to try it out. The idea of writing code once and running it on multiple platforms is still very exciting to us and we wanted to give it a try. The guys forget about it the very next day but that's not the point for now. This was why this project was built. So let's quickly move on to how I built it using flutter and all of what I learned from this very first try at building a mobile application.
Finally, the lockdown begins and I decide to come through with this project and write lines of dart code. To be honest I was more excited about making this project with vim because I had only become more familiar with this editor. I had to vim flex, I am not sorry about it.
I ran into numerous problems when Linux kernel v5.6 was released. Flutter hot-reload won't work or even flutter run won't work for some while. It was fixed soon but didn't reach the stable channel for long enough time therefore, had to make a switch to the dev channel in flutter.
The best thing about flutter is the availability of packages. The first package I had to use was a pdf viewer which I didn't want to write from scratch, then had to use a package for scrollbar and ended up using more packages than I would like. There's a package for even the tiniest of things with flutter.
The package's names are self-explanatory and it's a very simple app so nothing complex is happening in that department.
I would have loved a way to modularize/structure the code better and that's how I started in the beginning, turned out it became complex quickly, and then I ended up doing most of the things in a single file (since itβs a tiny app, very tiny) and minimum modules. The problem was some package classes were easier to instantiate and use without having a separate file for each. It makes the most sense because the packages in themselves are modules and need not be broken down any further.
One big note, flutter comes with dart so please keep it in mind before installing dart yourself separately, it will only waste disk space.
I spent a little longer on the syntax and testing little things which cost more time in the beginning and weren't necessary. Also didn't plan on how to keep persistent data in the beginning and moved ahead to just make things work and hack around to find the best practices.
I should have spent more time thinking about how I am going to implement persistent data storage on the device. I used basic file i/o operations to achieve that since I had to write a list. List isnβt that complex of a data structure but I would have liked it if I could have done it in a more efficient way. I tried finding a better way but failed. I have this feeling that there is a better way to do what I wanted to do and I ain't giving up looking for one anytime soon.
I have read how people say dart is such a failed attempt at a coding language but I found it very easy to get started with. The syntax is very familiar to java or c++ and the standard library is rich which makes the development process much faster as well as more efficient. Flutter builds on top of dart and benefits from all of that. Even the memory management is top class with dart.
Async calls on dart worked for me without any hiccups and basically everything during the project had a positive impact on what I feel about mobile app development with flutter. There are a plethora of inbuilt classes for mostly all the purposes I needed.
How everything is so well integrated makes me appreciate the project even more. I learned that when I was trying to understand how to get storage permissions for my app. The declarative nature made a lot of sense to me.
Everything a typical pdf viewer should do and more.
The things which would have made it a real good app were things like changing the phone sound profile or adjusting the brightness and display tone for the better reading experience, etc. Things like these are the bells and whistles of this project but it's still a good enough utility for someone looking for a very minimal and good looking pdf viewer.
The app cannot share the pdfs with other apps and that's something I want to add very soon as well as better ways to sort all the files in the list. For now, it is sorted based on the last access by the user.
I also am going to refactor the code and add comments for better understanding in the future (I suck at comments as of now; Update: I actually refactored the code and added comments, canβt believe myself, haha!).
With this project, I also tried Github actions for the first time and it wasn't as smooth of an experience. All of my work was being committed to the development branch of this project and I wanted to have the apk built and released using Github actions. So that's what I did and that's what has been happening for a while. I triggered it on the push to master which happens when dev is merged or something is pushed on the master branch. During this time I was all set to have the app on GitHub releases but found a simpler way to have the releases on Sourceforge. That's how I used Github actions for the first time with this project.
This tiny little project was my first attempt with flutter and a few more things. There are missing features I would have loved to incorporate and I might do that in future.
I have some more ideas to try with flutter and that's exciting to me. I want to build something that could stream real time audio from a host to multiple clients using socket connections or something similar, I will start to build that very soon, I am still very confused about trying to make it using flutter or try native app development this time. Some more ideas in the pipeline are a DRINK WATER alert app along with a browser extension, a multiplayer math game using flutter, and some more.
If you have made it this far I would like to thank you for reading my very informal project entry and in case you want to collaborate with me on anything please feel free reach out, I would love to do that.
Live long and keep building stuff. Peace out!
]]>Suckless's dwm is a dynamic window manager for Linux. It's one of the most popular window managers, but because of the suckless mentality, the default dwm is very minimal. It's reasonable and functional but lacks extra features. Luckily, the way patches work with dwm means you can transform it to look like other window managers. There are patches for the core and the bar. I've been using dwm for almost six months and have updated my fork with patches and customized the config. This post describes my dwm setup.
Here are the patches I've applied, in the order I applied them. (You can find a "how-to apply a patch" section at the end of this post.)
~/.dwm/autostart.sh that dwm runs every time it starts.dwm.c file for this feature. This lets you switch between two windows next to each other with Alt+Tab (or whatever keybinding you set). This makes it more comfortable to transition from Windows to Linux and back. I'll try to create a patch from this to submit to suckless.These are the patches I've applied. Some other useful patches are colorbar and most of the patches related to the status bar. I highly suggest looking at the patches yourself to get the most out of dwm. Linux encourages customization, and dwm is highly customizable, so you can make it whatever you want.
Here are some of my scripts for the statusbar and the autostart script:
#! /bin/bash
dunst &
copyq &
xss-lock -v -l xsecurelock &
picom &
nm-applet &
feh --bg-scale /home/law/Downloads/wallpaper.jpg
/home/law/apps/scripts/statusbar.sh & #!/bin/sh
while :
do
/home/law/apps/scripts/statusbarnoloop.sh
sleep 60
done #!/bin/sh
time=$(date "+ο¬ %a, %d ο %H:%M")
mute=$(pactl list sinks | awk '/Mute:/{ print $2 }' | head -n 1)
bat=$(acpi -b | awk '{ print $4}' | sed 's/%,//')
batStat=$(acpi -b | awk '{ print $3}' | sed 's/,//')
if [ $bat -lt 15 ] && [ $batStat = 'Discharging' ]
then
notify-send 'Battery Low!' "Plug in the charger."
elif ( [ $bat = 30 ] || [ $bat = 25 ] ) && [ $batStat = 'Discharging' ]
then
notify-send 'Battery Low!' "Plug in the charger."
elif ( [ $bat = 90 ] || [ $bat = 85 ] ) && [ $batStat = 'Charging' ]
then
notify-send 'Charged!' "Remove the charger."
elif [ $bat -gt 95 ] && [ $batStat = 'Charging' ]
then
notify-send 'Charged!' "Remove the charger."
fi
if [ $batStat = 'Charging' ]
then
bat=$bat" ο"
else
bat=$bat" ο"
fi
volume=$(amixer -c 1 -M -D pulse get Master | grep -o -E [[:digit:]]+% | awk "FNR <= 1")
if [[ $1 = "--ref" ]]
then
temp=$(curl "api.openweathermap.org/data/2.5/weather?q=Jaisalmer&appid={YOU_USE_YOURS}&units=metric" | jq .main.temp)
if [[ $temp = "" ]]
then
temp=" ξ΄"
else
temp=$(printf %0.f $temp)"Β°C"
fi
echo "$temp" > /home/law/apps/scripts/temp
fi
temp=$(cat /home/law/apps/scripts/temp)
if [[ $mute = "yes" ]]
then
xsetroot -name " ο§ $bat ο $temp ε©’ mute $time ξ‘"
else
xsetroot -name " ο§ $bat ο $temp ε’³ $volume $time ξ‘"
fiTo apply a patch, use the following command in the project directory (in this case, dwm):
patch < NAME_OF_THE_DIFF_FILEPatching rarely succeeds on its own. A .diff file contains the location of the code that needs to change and what to replace it with. If you've modified those lines of code before, the patch will fail. You'll then have to manually look at the diff file and change the code yourself.
That's my dwm fork, available on my GitHub. I've tried all the major window managers, but dwm feels the simplest and most extensible. I'm not a fan of the suckless mentality, but you should definitely give dwm a try; it's a great window manager.
Thanks for reading! Have a great day.
]]>SyncP (sync player) is a couple of Python scripts that use an mpv backend to play local media files in sync between hosts and clients. A host and a client are needed because it's a serverless app. A host must port-forward so clients can connect and sync media playback. The mpv backend is the core of the project; I was lucky to get a lot of help from jaseg/python-mpv.
In an age of streaming and screen-sharing applications, this project seems un-innovative, and it doesn't do much more than sync playback and listen for events like toggles (play/pause). But living in a third-world country, I don't have access to high-bandwidth, low-latency, unlimited data. Because of this, I had to think of something that wasn't streaming. Screen sharing and streaming both consume a lot of data, and syncP solves that problem entirely by using encoded text messages for communication between hosts and clients.
Initially, this project was limited to one client per host, but now it can have any number of clients. The project is available on pypi and can be installed with pip install syncP. After installation, syncp --help should be enough to get started. Before installing, you must set up mpv for the player to run; a guide is available in the repo at lawRathod/syncP.
Since it can play any kind of media extension (lovely mpv), you can enjoy watching movies or TV shows or even listening to music with your friends.
The three major components of the project are the following scripts:
The host script must be started first by a host and will perform the following actions in order:
player class (inside player.py). The class constructor lets the user choose the media file to be played at the very beginning. The function returns a player object, which is later used to control the player.player.py and all the threads. Every new connection is then appended to the list.These things are done consistently and allow the host to receive connections anytime while the process is running. The data sent between the host and clients are encoded text messages like "toggle" on playback toggle and "sync: time", which is a way to sync the time between all the clients and the host. I figured I'd only allow hosts to sync time between connections. When a toggle message is received from a client, the host receives it, sends it to all other connections, and acts as a broadcaster.
The host starts the socket with the keep_alive flag to help the connections sustain the life of the media playback and not drop randomly after some time. I found this out the hard way, but the fix was easy and quick to implement.
The client side of the project does very little compared to the host because I felt it should be kept as light as possible, with the host handling most of the complexities. The following happens on the client side:
That's all that happens. Once the connection is set, the app sends a keep-alive message to keep the connection alive, and now the host and client are in sync.
This is the common module between the client and host that enables playback and sync operations. It primarily uses work from jaseg/python-mpv. The player class keeps event listeners, and media file selection tidy and in a module. The constructor brings all the necessary objects to the class for future use. Some event listeners for toggles and keys are also part of this script.
This was my first shot at working with a couple of things. Mainly, web sockets and threads took a little time to get used to. I learned how to create a systematic design that could come to life and get things done in the desired way. This was a cute little project for me to hack together in a little time to help me watch stuff with my friends. It's always a little challenging to bake an interface and make design choices when you aren't the only one using the app. This app is CLI-based, and I didn't have to design something as complex as a platform, which saved me a lot of time. I took some things for granted, like the abstractions Python has to offer, and I hope to understand them more deeply.
Here's a list of things where I think the app could have shined and provided a better experience. I'm not sure if I'm ever going to implement these because an application is never really "finished."
I can think of many more, but it feels like a rabbit hole where you begin to imagine a completely different thing than what the app is right now.
Thank you for making it this far. Have a great day! π
]]>Machine learning models are increasingly being trained on sensitive data, social networks, medical records, financial transactions. But here's an uncomfortable question: can an attacker figure out whether your data was used to train a model just by querying it?
This is the core question behind Membership Inference Attacks (MIA), and in this project, I implemented a framework to test how vulnerable Graph Neural Networks are to this privacy threat.
Graph Neural Networks have become the go-to architecture for learning on relational data, social networks, citation graphs, biological networks. But their very strength, leveraging neighborhood information, might also be their weakness.
When a GNN is trained on a graph, it learns patterns from the training nodes. The hypothesis is that the model behaves differently on data it has seen during training versus data it hasn't. An attacker can exploit this difference to infer membership.
I implemented the TSTS methodology from this research paper. The attack works as follows:
The key insight is that the shadow model helps the attacker learn what "training data behavior" looks like, even without access to the actual training data.
The framework supports four popular GNN architectures:
One contribution of this implementation is enhanced feature engineering for the attack model. Beyond basic node features, I compute:
These features help the attack model capture subtle differences in how the target model treats training vs. non-training nodes.
The baseline attack model achieved ~70-75% accuracy. I developed an improved version with:
This pushed attack accuracy to 80-85% in some configurations.
The framework works with both standard benchmarks and custom social network data:
Standard Datasets: Cora, CiteSeer, PubMed, Flickr, Reddit
Custom Datasets:
Each custom dataset contains ~256 subgraphs with ~120 nodes each, split into training, non-training, and synthetic subsets.
| Model | Dataset | Attack Accuracy | AUROC |
|---|---|---|---|
| GAT | Twitch | 48-52% | ~0.50 |
| GAT | Event | 48-52% | ~0.50 |
| GCN | Twitch | 50-55% | ~0.52 |
| SAGE | Event | 48-50% | ~0.49 |
Interestingly, the attack performance varies significantly across configurations. Some subgraphs are highly vulnerable (attack correctly identifies 96% of training samples) while others are resistant.
This framework provides a foundation for:
The full code is available on GitHub.
The code is organized into three main components:
bridge.py β Data format conversion (pickle β PyG)
rebmi_adapter.py β Feature engineering & data organization
TSTS.py β Main attack pipeline
Configure your experiment in TSTS.py:
model_type = "GAT" # GCN/GAT/SAGE/SGC
data_type = "Custom_Event" # Dataset selection
CUSTOM_ADVANCED_FEATURES = True # Enhanced features
USE_IMPROVED_ATTACK = True # Improved attack modelThis project was completed as part of my university coursework, implementing and extending the methodology from "Membership Inference Attack on Graph Neural Networks" (arXiv:2101.06570).
]]>That's where CRDTs (Conflict-free Replicated Data Types) come in, and why I built Minidote - an Elixir implementation of a distributed CRDT system with causal broadcast guarantees.
Traditional distributed systems rely on consensus protocols like Raft or Paxos to maintain consistency. While these provide strong guarantees, they come at a cost: during network partitions, nodes must either stop accepting writes or risk inconsistency.
For many applications - collaborative editors, shopping carts, social media feeds - availability matters more than linearizability. Users expect their actions to work, even if their connection is flaky.
CRDTs are data structures with a mathematical property: they can be modified independently on different nodes and always merge deterministically to the same state. No coordination required. No conflicts to resolve manually.
Minidote implements six CRDT types:
Minidote is built as a layered system:
βββββββββββββββββββ
β Minidote API β β Simple read/update interface
βββββββββββββββββββ€
β Minidote.Server β β CRDT state + vector clocks
βββββββββββββββββββ€
β BroadcastLayer β β Causal ordering guarantees
βββββββββββββββββββ€
β LinkLayer β β Network abstraction + retries
βββββββββββββββββββ€
β Persistence β β Disk logs + state snapshots
βββββββββββββββββββ
Vector clocks track causal relationships between operations. If Alice's edit depends on Bob's, Minidote ensures Bob's change is applied first on all nodes - even if network delays cause them to arrive out of order.
Causal broadcast propagates updates to all nodes while respecting these dependencies. Operations are logged to disk before broadcasting, enabling crash recovery through log replay.
The test suite includes scenarios modeling actual distributed applications:
Minidote is a learning project that demonstrates CRDT principles, not a production-ready database. Current limitations include:
These are deliberate simplifications to keep the codebase understandable.
This project was developed with AI assistance using Claude Code and Windsurf. The experience demonstrated how AI tools can accelerate systems programming work while maintaining code quality.
Minidote is open source and available on GitHub:
The repository includes comprehensive documentation on the design, broadcast model, and testing infrastructure. Clone it, run mix test, and explore how CRDTs enable distributed systems that are both available and eventually consistent.
Project: MiniDote β Distributed Key-Value Store
Repository: https://github.com/lawRathod/minidote
Project: IPFS Lab & Kubo Modification
Repository: https://github.com/lawRathod/ipfs-lab
Repository: https://github.com/lawRathod/uni-project-dec
Asynchronous Vertical Federated Learning (AVFL)
Project: Generative AI Portfolio
Repository: https://github.com/lawRathod/gen-ai-portfolio
It's a small PWA that runs Hugging Face's background-removal models entirely client-side using ONNX Runtime and WebAssembly. You drop an image in, it generates a mask, and you download it. No uploads, no API keys, no server costs. Just your browser doing the work.
I didn't set out to build the most sophisticated background removal tool. I wanted to see what's actually possible right now in the browser, with real models, on real hardware.
The app uses @huggingface/transformers to load ONNX models and run inference through WebAssembly. When you open the page, the model downloads and caches locally. After that, everything runs offline.
There are multiple models available β ISNet-ONNX, RMBG-1.4, and MODNet β each with different tradeoffs between size, speed, and quality. You pick one, load an image, and hit generate. The model processes it in the browser and returns a mask PNG.
I also added a benchmark mode that runs all models sequentially against the same image and shows you a comparison table with load times, inference times, and sizes. It's useful if you're trying to figure out which model works best for your use case.
The obvious question is why not just send the image to a server and get the result back. There are a few reasons.
Privacy is the main one. You're not uploading your images anywhere. They stay on your machine the entire time. For a lot of use cases, that matters more than people think.
Then there's the cost thing. Running inference on a server means GPUs, infrastructure, scaling, all of that. Running it in the browser means the user's machine does the work, and it's free. The tradeoff is speed β it's not going to be as fast as a GPU server β but for a lot of cases, it's fast enough.
And honestly, I just wanted to see if it could be done well. The answer is yes, with some caveats.
Working with ONNX in the browser is not something I had done before. The Hugging Face transformers library makes it surprisingly straightforward, but there are still details you need to figure out. WASM paths, model loading states, keeping the UI responsive during inference β all of that takes some thought.
One thing that surprised me is how well it works as a PWA. Once the model is cached, the whole thing runs offline. You can close the tab, come back later, and it just works. The service worker handles caching the app shell and the model files, so there's no need to re-download anything.
I also spent time on the UI side of things. There's a network status LED that shows whether you're online, fetching, or offline-ready. Side-by-side preview for the original and the mask. Zoom overlay for inspecting details. Small things, but they make the experience feel more polished.
Each model has its own characteristics. ISNet-ONNX is a good balance of quality and speed. RMBG-1.4 tends to produce cleaner edges but takes a bit longer. MODNet is lighter and faster but sometimes misses finer details.
The benchmark mode lets you see these differences directly. Load an image, run all models, compare the results. It's not a scientific benchmark β it's just one image on your machine β but it gives you a sense of what to expect.
Right now it does one thing: remove backgrounds and export masks. I'm not sure there's much more to add honestly. Maybe more models over time as better ones become available. Maybe some quality-of-life improvements.
But I think the interesting part isn't the feature set. It's the approach. Running AI models in the browser changes the whole equation. No server, no data collection, no costs. Just code running on your machine.
That feels like the right direction for a lot of tools.
The app is live at experiments.prats.page/bgrem and the code is on GitHub if you want to look at how it's put together.
Thank you for making it this far. Have a great day! π
]]>This was my first KubeCon. I went with Juan and Ainhoa from Zondax, and it was their first time too. We didn't go in with a super structured plan, just a simple goal: absorb as much as possible about CNCF projects and the whole cloud native ecosystem.
I don't think I was prepared for how overwhelming it would be.
The moment you walk into the venue, it just hits you. It's huge, loud, dense and every company, every project trying to show why they matter. "Sales pitch" is the easiest way to describe it, but it didn't feel fake. It felt like everyone genuinely believes they're building something important, and this is their shot to show it.
I found myself constantly switching modes, sometimes just listening, sometimes questioning everything, sometimes trying to break down what's actually useful vs what's just well presented. Being a student in distributed systems, I think I naturally leaned into that. I didn't just want to be impressed, I wanted to understand what's actually real.
The keynotes were honestly great. Very much on the edge of what's happening right now in Kubernetes and everything around it. One talk that really stuck with me was Kubernetes at the edge, running on a glider. They literally had a glider on stage, with the pilot there.
That was such a cool moment.
It wasn't just "look at this tech," it was tech in a real, slightly crazy environment. That mix of engineering and adventure is exactly how I imagine enjoying tech in the future.
AI was everywhere, which was expected, but the vibe around it was interesting. It wasn't doom or hype, it was more like, "okay this is here" and let's figure out how to actually use it properly. Most talks kept it pretty positive, and I liked that. There's already too much negativity around AI outside, mostly because people don't know what the next few years look like.
At KubeCon it felt more grounded.
At some point during the event, I had this weird mix of feelings. On one hand, I felt kind of useless. Like I didn't really have anything to offer there. I was just consuming everything. On the other hand, I felt completely enriched. The ecosystem is way bigger than I had imagined, and just being around people building things at that scale was inspiring.
I think it also made me think a lot about the future, maybe even entrepreneurship. Just seeing how many ideas are out there, how people position them, how they talk about their "moats", overall it was interesting to observe beyond just the tech.
I spent a lot of time at sponsor booths, talking to engineers and teams. Most people were friendly. Engineers especially, probably because it's easier to relate. With others, you can kind of feel it when you say you're a student. Not in a bad way, just⦠less interest. It's fine, part of the game I guess.
Some of the best moments were just random conversations. I had lunch with people from German IT companies, a consultant from Iceland, and a really curious guy from Greece. We ended up talking about everything from tech to how close you can get to an active volcano in Iceland. Those were surprisingly warm interactions, the kind you don't plan but remember.
I wouldn't say I'm very extroverted, but I realized I actually enjoy talking to people a lot. I just don't always initiate it. This event kind of pushed me to do that more, and I think I want to carry that forward. Especially talking to engineers.
Also yes, I took a fair amount of swag. And the after parties were fun. KubeTrain was easily the best one.
And then there was Amsterdam.
Outside the event, I spent time exploring the city with Ainhoa. She knew some really nice spots, not just the obvious tourist places, and that made the experience much better. Slowing down a bit in between all the chaos helped.
We went to the Van Gogh Museum, and that was honestly one of the most impactful parts of the trip. Seeing Vincent van Gogh's work in person hits differently. It's beautiful, but also kind of heartbreaking when you think about how his life went.
I don't know, it just makes you reflect a bit. About passion, about timing, about how things unfold. Also what gives a bit of hope is that he started late, so maybe trying new things later in life isn't that crazy.
And yeah, maybe I'll try painting someday. Slightly wishful thinking, but still.
I also got to spend more time with Juan, which I was really looking forward to. We had worked together but not very closely before. He's someone I respect a lot who is very sharp, very curious, and just fun to talk to. Walking around with him, listening to how he thinks about things, you end up learning a lot without it feeling like learning.
I'm glad I got that time.
Overall, KubeCon was a mix of everything quite overwhelming, exciting, slightly intimidating, but very energizing. I learned a lot from the talks, enjoyed the conversations, explored a new city, and came back with a lot to think about.
I went there mostly as a consumer.
I came back feeling like I want to find where I can actually contribute.
]]>Here's why. Distributed systems fail in really weird ways. Not the obvious stuff β servers going down, networks cutting out. I mean the subtle ones. Retry storms. Timeout cascades. Queue amplification. The kind where things get gradually worse, then suddenly much worse, and by the time you notice, you're already in trouble.
These failures are a nightmare to reproduce. They depend on precise timing, on exactly when a packet arrives, on which goroutine gets scheduled first. You run the same test five times, it fails once, you have no idea why. Change a log line and the bug disappears.
That's what got me looking into DES.
DES stands for discrete-event simulation. The idea is simple: instead of simulating time continuously, you jump from one event to the next. A packet arrives, a timer fires, a task completes. Nothing changes between events, so there's nothing to simulate.
It's a natural fit for distributed systems. Almost everything in a distributed system is event-driven β messages, timeouts, scheduling decisions. You don't need dense time steps like you would in a physics simulation. You just need a queue of events and a clock that advances when it's time for the next one.
The scheduler is the core piece. It's really just a priority queue. You pop the earliest event, advance the clock, execute the callback. The callback can schedule more events. That's the loop.
What makes this useful is determinism. A DES scheduler controls three things that are normally unpredictable:
Same seed, same execution. Every time.
This changes the debugging story completely. Normally you're adding log lines, running in staging, praying you can reproduce whatever went wrong. With DES, you record the exact sequence of events that led to the failure and replay it. Like a DVR for your system. You can pause, look at state, step through event by event.
I think that's pretty powerful.
The tricky bit is making this work with real systems. Most distributed services are written in languages with threading, async runtimes, runtime schedulers β all things that fight against determinism. You need to intercept the right layer and route everything through the simulator without changing the application logic.
This is the direction I'm exploring for my thesis. The core question is: how do you make a Go program believe it's been running for five seconds when only fifty microseconds of wall-clock time have passed? I don't know if it'll work yet, but that's kind of the point.
You can't make everything deterministic. A Go program uses the OS scheduler, reads environment variables, touches the filesystem. What you can do is define a clear boundary and guarantee replayability within it. I've been calling this the determinism envelope.
The envelope covers simulated time, seeded randomness, and intercepted network I/O. If your code stays within these, replay is guaranteed. Step outside β read the wall clock, open a real socket β and all bets are off. It's not a limitation, it's a contract.
This framing is still early. I'm testing it against real systems to see where it breaks. That might end up being the more interesting part β finding the edge cases where the envelope doesn't hold and understanding why.
There are other approaches. You can build formal models with TLA+ or Alloy and prove properties. Chaos engineering lets you run experiments in production and see what breaks. Unit tests with mocked timeouts cover smaller pieces.
DES sits somewhere between these. You're running actual code, so it's more concrete than a formal model. You can reproduce failures deterministically, which gives you more control than chaos experiments. And it goes further than unit tests because you can simulate complex network conditions across whole systems.
I don't think any of these replace each other. They're different tools for different questions.
I got into distributed systems because they feel like the most interesting engineering challenge right now. Everything is distributed, everything fails, and most of the time we're flying blind. DES gives us a way to actually see what's happening.
There's something satisfying about watching a complex system unfold deterministically. Every event, every scheduling decision, every random number is exactly what you asked for. It's the opposite of the usual distributed debugging experience, where you're chasing ghosts.
The current plan for my thesis is to build a framework that takes real Go service logic and runs it under a deterministic simulation. The goal is to find metastable failure states before they hit production. But it's early, and honestly, that direction might shift as I learn more. I'm exploring what's possible, what works, and what doesn't. The framework might not come together the way I'm imagining, and that's fine.
Anyway. That's where I'm at right now. A lot of open questions, but that's the exciting part.
]]>