Young engineers who are entering the workforce now or have entered in the last 2-3 years, if you try to look behind all the token maxxing high, are facing a grim reality right now.
I use the word “high” very much intentionally because this is how the AI subscription systems have been designed. If you are at the beginning of your career and funding your own subscriptions, then to even stay competitive, you have to keep paying every month. And it requires active flow of income just to keep your subscriptions alive as the free tiers are mostly not great.
How Open Source Can Shape Your Career and Growth as an Engineer
If you are beginning your engineering journey right about now, using AI tools that work as your second brain sounds great, and will get you through your hobby projects, maybe interviews, first few months at your job. But I would like to talk about something that will help you go through the long career you have in front of you. Technologies will come and go, but you have to move ahead regardless the technologies and tools you have in your hand. Because after a few years you will learn that writing code is effectively a tiny part of being an engineer.
Hardcoding secrets like passwords, API keys, and database credentials inside Docker images is a big security risk. If these images are shared or stored in a public registry, sensitive data can be exposed. A much better approach is to store secrets securely and inject them into applications only when needed.
In a recent project, I worked on securing secrets in a Kubernetes-based environment using HashiCorp Vault and ArgoCD Vault Plugin. This method ensures that sensitive data is never stored inside the application code or Docker images.
I flew back to Kolkata today. Ayanti and I came to Kolkata earlier this month because MIL suddenly fell ill. She had to be hospitalised. And we flew here in hours notice. Then last week i have to travel back to Bangalore for some work. And now I’m back to Kolkata again.
Too many thoughts are rushing through my mind and I am having trouble processing everything at the same time. So thought I’ll try writing things down.
I got an opportunity to join a group trip to Bandipur forest stay organized by Deepa Mohan and took it on a whim. I bought a new 200-500 mm lens just around that time. It was a good opportunity to test it.
The pickup time was around 6AM and luck wasn’t with me to book a cab. So I walked to the nearest Yulu spot and took a Yulu for pickup. Ananth gave me a tide to and from Bandipur all the way. The morning felt crisp and full of anticipation.
After weeks of the usual hustle and bustle of daily life in Bangalore, we felt the need to escape the routine and recharge. The monotony of work, responsibilities, and the constant city noise had started to weigh us down. A break was long overdue—a chance to reconnect with nature, explore new places, and spend quality time as a family. As luck would have it, our friend Navya invited a bunch of us to her home in Shimoga for the independence day weekend. Little did we know, this journey would provide not just a change of scenery, but a series of memorable experiences that left us refreshed and reenergized.
Recently came across a scenario, where curl was able to connect to localhost but not 127.0.0.1. When I tried curl 127.0.0.1:80, it just hung there. While curl localhost:80 returns the expected output.
My first instinct was to check apache config to see if it was only serving to localhost and not the IP address. But that seemed unlikely because /etc/hosts had the correct entry.
My next big clue was when I tried curl -v localhost:80, this was the output -
Scenario: You SSH into an Ubuntu server. How do you know if you just logged in inside a docker container, or just a regular VM?
Turns out there are no straight answers.
Docker provides virtualization based on Linux Containers (LXC). LXC is a technology to provide operating system virtualization for processes on Linux. This means, that processes can be executed in isolation without starting a real and heavy virtual machine. All processes will be executed on the same Linux kernel, but will still have their own namespaces, users and file system.
In the previous post we figured out how to find the process which is writing an open file. And we also saw that we can kill the process and it’ll stop it from writing to that file. But what if we are not supposed to kill the process? But we still need to close the file.
First we need to figure out the file descriptor for that file for that process.
Scenario: Imagine you login to a server and you find that the disk is filling up rapidly. Either by using df -h or du -h -d1 /<dir> or getting errors like no more disk space left etc. How do you figure out who is filling up the file?
Solution: Let’s say the file in question is /var/log/badd.log and it’s rapidly filling up.
First step is to use lsof to figure out which process has that file open. To write to a file, any process has to first open that file. So the process will show up in lsof, which is a program to “list open files”. With any luck your output will show up like this -
