Amit's Tech Hub

Just posted this, would love your take given your background.

www.linkedin.com/posts/activity-747760194182968934…

2 months ago | [YT] | 0

Amit's Tech Hub

Praise in public. Steer in private.

I put that out recently and it came from somewhere real.

There’s a certain type of person online. Privileged. Connected.

They’ve got a platform and they use it to punch down. In their posts. Dressed up as insight, delivered as performance.

And then there’s the other kind. The ones punching up. Hiding behind a screen, going after people they’d never face directly.

I saw a comment last week on a major platform. Directed at someone. Extremely disrespectful. No accountability.

Just cruelty dressed as opinion.

Both directions. Same problem. No integrity.

I used to have a lot of time for some of these people. Direct conversations. Genuine respect. Not anymore.

I’m not naming names. Not to protect anyone. Because if you read this and think it’s about you, reach out. I’ll tell you straight.

What I will say is this: a lot of what passes for honesty online isn’t wisdom. It’s performance. Masks. Gesturing.

I’m done with it. Not from judgment. From love for my own peace.

If you’re here to genuinely help people, I see you. That’s who I’m here for.

The rest? Unfollowed.

4 months ago | [YT] | 0

Amit's Tech Hub

It takes a special type of person to go on the internet and criticise others.

Whether in the comments punching up.

Or from above punching down.

Always be positive and support others.

Praise in public.

If steering or redirection is required it’s always best handled privately.

Most of us are here helping others.

4 months ago | [YT] | 0

Amit's Tech Hub

Currently loving these on Audible, highly recommend all three:

Big Trust by Dr. Shade Zahrai, a powerful exploration of trust as the foundation for everything we build, personally and professionally.

Feel Good Productivity by Ali Abdaal, a fresh perspective on how we approach output and energy. If you want to work smarter without sacrificing what matters, this one is worth your time.

Comfort in Darkness by Rickson Gracie, not just a fighting memoir. It's a masterclass in mental resilience, facing fear with clarity, and finding stillness when you need it most.

Three very different worlds, boardroom, productivity, and martial arts, but the same thread running through all of them:

"Knowing yourself under pressure."

What are you listening to right now?

6 months ago | [YT] | 0

Amit's Tech Hub

I've been using AI daily for a while now, and the biggest thing I've learned is this:

The output is almost never the AI's fault.

It's the prompt.

Here are 8 prompt engineering techniques that changed how I work with AI — from the basics through to some approaches most people never try.

──────────────────────────

01 · What it is — clear communication, not magic
02 · Clarity — specify format, audience, length and tone every time
03 · Roles — "as a [specific expert], [your question]" unlocks a different lens entirely
04 · Chain of thought — "think step by step" dramatically improves reasoning tasks
05 · Format control — there's a reusable template that works on almost any prompt
06 · Few-shot — show 3 examples instead of explaining the rule
07 · Iteration — treat your prompt like code: diagnose what broke, fix that specific thing
08 · Meta-prompting — ask AI to write and improve your own prompts

──────────────────────────

The thing that helped me most was realising your first prompt is a draft.

Not a failure. Not something to delete and start over.

A starting point. 3 rounds of iteration usually gets you somewhere good.

──────────────────────────

I put together a full written guide that goes much deeper on each of these — worked examples, before/after comparisons, templates you can copy and use straight away.

Happy to share it. Just drop a comment or DM me and I'll send it over. No sign-up, no form — just a message.

If this was helpful, a repost would mean a lot — it's a topic worth more people knowing about 🙏

What technique do you find yourself using most? Would love to hear in the comments 👇

#PromptEngineering #AI #ArtificialIntelligence #Productivity #LLM #TechTips

7 months ago | [YT] | 1

Amit's Tech Hub

I can now be found on Substack as well

open.substack.com/pub/amitstechhub/p/automating-li…

7 months ago | [YT] | 0

Amit's Tech Hub

The Best Automation Starts With Frustration

The best automation starts with frustration turning into momentum.

I've been building automation for over two decades. Early in my career, I worked for a startup during the early 2000s where we released our own Linux distribution based on Red Hat Linux, and I learned something that stuck with me: the automation that actually works doesn't come from grand visions or perfect planning. It comes from doing something manually for the third time that week and thinking: "Right, that's it. Never again."

That moment matters. That's when change happens.

Discovery: Research Before You Build

Here's where many engineers go wrong: they see a problem and immediately start coding.

Do your research first. Read the documentation. Look at existing tools and solutions. Check community knowledge. Talk to peers who've solved similar problems. If automation for what you're trying to solve already exists, use it.

When I need to build something new, I keep a physical notepad open while doing the task manually. I jot down each step: what I'm doing, the files involved, the checks I'm performing. This actually matters.

Handwriting activates multiple brain regions simultaneously, engaging the motor cortex, visual processing areas, and memory formation centers in ways typing simply doesn't. Research from the Norwegian University of Science and Technology found that handwriting creates increased connectivity across brain regions involved in learning and memory, particularly in alpha and theta wave frequencies associated with memory encoding. When you write things down by hand, you're forcing deeper cognitive processing of what you're documenting.

Ask yourself as you write: What am I doing here and why? What information do I need at each step? Where does this information come from? What could go wrong? What variations exist?

This isn't wasted time. This is the foundation of everything that comes after.

Manual Tasks: Building Your Understanding

Once you've done something manually a few times and documented it, you've got a repeatable process you understand.

Following your documented manual process, you find the steps you forgot to write down. The assumptions that weren't true. The edge cases that only appear sometimes. The dependencies you didn't realize existed.

You also start seeing patterns: which bits are straightforward, which require decisions, which are always the same, and which vary based on context.

You can't automate what you don't understand.

MVP Automation: Imperfect Action Over Perfect Planning

You've got your manual process and understanding. Now build an MVP that solves your immediate problem.

Start with the simplest tool. Often that's a shell script. You already know the commands; now you're putting them in a file. Add error checking, logging, basic input validation. Done.

I use Python for complex automation. Choose what fits the task. Does it handle every edge case? No. Is it elegant? Not really. Does it solve your problem? Absolutely.

I've worked with engineers who spent weeks planning perfect frameworks. Never finished. Meanwhile, I knocked out a working script in an afternoon that saved hours of manual work weekly.

Imperfect action beats unfinished perfectionism.

Gatekeepers Will Push Back. And They Always Do.

When you start building this way, you'll encounter resistance. There will be gatekeepers who frown upon scrappy approaches. "That's not enterprise-grade. That's not following process. That's just a side project, not real engineering."

But here's what I learned at AWS, and what I've seen again and again. Working scrappy and iterating was the actual culture. Amazon's leadership culture is built on two core principles. First, "Invent and Simplify." Leaders expect innovation from their teams and always find ways to simplify. Second, "Frugality." Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. The culture focused on releasing a product to customers and iterating quickly based on real feedback, not waiting for perfection.

The skeptics are looking at the wrong thing. They're looking at the origin story, not the outcome.

Windows actually started as Microsoft's lower priority while they focused on the OS/2 partnership with IBM. According to insiders at Microsoft, Windows was treated as a lower priority during early development. Yet after Windows 3.0's massive success in 1990, Microsoft fundamentally shifted, eventually rebranding aspects of the failed OS/2 project as Windows NT instead.

Linux started as Linus Torvalds' solo project in 1991, announced as "just a hobby" when he was 21 years old and studying at the University of Helsinki.

Unix began in 1969 when Ken Thompson and Dennis Ritchie at Bell Labs, frustrated with the failed Multics project, decided to reimplement their ideas on a much smaller scale using a discarded PDP-7 minicomputer with just 4K of memory.

AWS emerged from Amazon's internal infrastructure struggles in the early 2000s, when teams were spending 70% of their time on "undifferentiated heavy lifting" instead of innovation, eventually launching publicly in 2006.

Apple started in Steve Jobs' parents' garage in Los Altos, California. After Wozniak pitched his Apple I design to HP five times, they rejected it each time because HP executives couldn't see why an ordinary person would need a computer.

The most transformative infrastructure tools we use today weren't born in perfect conditions with unlimited budgets. They were born from someone saying "I need this to work" and building it anyway.

Building the Toolchain: From Scripts to Systems

Once you've got a working MVP, you start seeing where it needs to grow. This is when you reach for more sophisticated tools.

Ansible is powerful for configuration management across multiple servers; it's idempotent, handles errors properly, and scales well. Terraform is excellent for infrastructure as code, giving you repeatability and version control for cloud resources. Cloud-init is great for initial server setup, turning manual post-install steps into automated bootstrap.

But here's the key: reach for these tools when you need them, not just because they exist. Your MVP script might be perfectly adequate.

Real Problems, Real Solutions

Every piece of automation I've built that people actually use started with a real problem I had myself.

At AWS, I used infrastructure as code tooling to get AWS CodeDeploy Region Builds to GA, scaling regional experiments into production systems across multiple regions. I also automated MicroK8s multi-node cluster creation in my home lab. I was trying to learn Kubernetes in my spare time, but the manual build process consumed hours every time I needed a fresh environment. Time I didn't have. So I automated it. That freed hours I could actually spend learning: understanding cluster behaviour, networking, persistence. Not building infrastructure. Learning. That's automation's real value. It buys you thinking time. I've also written monitoring scripts because observability configuration was tedious, and database backup automation because manual backups fail.

These tools weren't perfectly designed from the start. They were rough, pragmatic solutions. But they worked, saved time, and reduced errors.

The Path Forward

Pick something that annoys you daily. Research what exists. Build something that actually works. Ship it, even if imperfect. Learn from using it. Iterate based on reality.

The good enough that exists beats the perfect that never will.

About Amit: Linux Systems Engineer with 24 years in enterprise infrastructure. I build automation tools for real challenges. Find my tools on Gumroad or follow Amit's Tech Hub on YouTube where I document what I'm building and learning.

Sources

[1] Automation in Software Development: The 2025 Playbook

[2] Before Automating: Understanding the Problem First

[3] 5 Reasons Why Test Automation Frameworks Fail

[4] Brain Research on Handwriting and Memory

[5] How to build a Minimum Viable Platform for Devs

[6] What scripts have you built to stand up a new server?

[7] Learn Powershell Scripting

[8] Terraform

[9] IBM OS/2 | Britannica

[10] Microsoft (relying on DOJ antitrust statement and official Microsoft documentation)

[11] History of Linux

[12] History of Unix

[13] The Strange Birth and Long Life of Unix - IEEE Spectrum

[14] How Amazon grew an awkward side project into AWS - Fortune

[15] Steve Wozniak

[16] Steve Wozniak and the Story of the PC - National Inventors Hall of Fame

[17] Barbarians Led by Bill Gates: Microsoft from the Inside - Jennifer Edstrom and Marlin Eller (Henry Holt and Company, 1998)

[18] Amazon Leadership Principles - Invent and Simplify

[19] Amazon Leadership Principles - Frugality

7 months ago | [YT] | 0

Amit's Tech Hub

Automating Linux Desktop VMs on Mac: From Manual Setup to One-Click Deployment

Here is the demo

https://youtu.be/USXReli8P80?si=naHqD...

Working on Mac is excellent. The hardware is solid, the Unix foundation is there, and the ecosystem works beautifully.

But sometimes you need something additional: a full Linux desktop environment. Not just terminal access. Not just SSH into a headless server. An actual desktop with a GUI.

Maybe you’re:

∙ Testing desktop applications
∙ Learning a new desktop environment
∙ Running GUI tools that need a visual interface
∙ Teaching someone who benefits from visual examples
∙ Demonstrating something that requires clicking around

On Linux, this is straightforward. Spin up a VM, install a desktop environment, done.

On Mac? It requires a bit more setup work.

The Manual Setup Process

Here’s the typical workflow:
1. Install Multipass (a great VM tool for Mac)
2. Launch an Ubuntu instance
3. SSH in
4. Install a desktop environment (XFCE, GNOME, whatever)
5. Install and configure xrdp for RDP access
6. Configure the firewall rules
7. Figure out the networking
8. Configure RDP authentication
9. Connect from Mac to the desktop
10. Test and troubleshoot
11. Document what worked

Time investment: 30-60 minutes if you know what you’re doing. 1-2 hours if you’re learning.

And you need to do this every time you want a fresh desktop VM.

Mac’s Virtualization Technology
Apple has built excellent hypervisor technology into macOS (the Hypervisor framework, and on Apple Silicon, the Virtualization framework).

These provide the foundation that various tools use to create powerful virtualization solutions. Tools like Multipass, UTM, Parallels, and others build on these frameworks to deliver VM capabilities.

The frameworks themselves are low-level APIs designed for developers to build solutions on top of, rather than end-user tools. This design allows for flexibility and specialized implementations.

Why Multipass

Free and open source:
∙ Zero cost
∙ Maintained by Canonical (Ubuntu’s creators)
∙ Active development and regular updates
∙ Open source transparency

Built for developers:
∙ Command-line first design
∙ Scriptable and automatable
∙ Quick VM creation and destruction
∙ Designed for the “I need a Linux instance now” workflow

Uses native Apple frameworks:
∙ Builds on Apple’s Virtualization framework
∙ Native ARM performance on Apple Silicon
∙ Fast startup and shutdown
∙ Minimal overhead
Simple and focused:
∙ Does one thing exceptionally well: Ubuntu VMs
∙ Clean, understandable interface
∙ No unnecessary features
∙ Easy to learn and use

Cloud-init integration:
∙ Uses the same provisioning tool clouds use
∙ Automation-friendly from the start
∙ Can script entire setup processes
∙ Familiar if you’ve worked with cloud infrastructure

Perfect for automation:
∙ Command-line driven
∙ Predictable behavior
∙ Easy to wrap in scripts
∙ Integrates cleanly with other tools

Multipass doesn’t try to be everything. It focuses on making Ubuntu VMs quick and easy.

That’s exactly what I need.

What Working at AWS Taught Me
At AWS, we automated repetitive processes.

Because manual processes:
∙ Consume time
∙ Introduce inconsistencies
∙ Don’t scale efficiently
∙ Create friction that discourages experimentation

If I need a Linux desktop VM and setup takes an hour, I’ll avoid it. I’ll work around it. I’ll find compromises.

Better approach: remove the friction. Make the tool serve the need.

What I Built

A simple script that creates a Multipass Ubuntu instance with:
∙ Lightweight desktop environment (XFCE - fast, clean, functional)
∙ xrdp server configured and running
∙ RDP access properly set up
∙ Networking configured automatically
∙ Ready to connect in minutes

Run the script. Wait 5 minutes. Connect via RDP. Done.

Why XFCE
When running a desktop environment inside a VM, efficiency matters.
XFCE is ideal because:
∙ Lightweight (minimal resource consumption)
∙ Fast (responds quickly in a VM)
∙ Functional (includes everything needed)
∙ Familiar (standard desktop paradigm)
∙ Stable (reliable and consistent)
∙ Works excellently with RDP

GNOME is beautiful but uses 2-3x the memory. KDE has extensive features but can feel slower in a VM.

XFCE is the balanced choice: efficient and functional.

Why RDP Instead of VNC

I use RDP (Remote Desktop Protocol) for specific technical reasons:

RDP advantages:
∙ Better performance over network connections
∙ Smoother remote desktop experience
∙ Superior clipboard sharing
∙ More efficient screen updates
∙ Works perfectly with Microsoft Remote Desktop (free from Mac App Store)

The xrdp configuration:
∙ Provides RDP access to Linux desktops
∙ Compatible with standard RDP clients
∙ Reliable and well-maintained
∙ No additional Mac software needed

The script handles all xrdp configuration automatically: installation, XFCE integration, authentication setup, and automatic startup.

The Automation Philosophy

This script follows a consistent pattern:
Identify repetitive process → Automate it → Share it

The value isn’t just time savings (though it delivers that). The value is removing friction from exploration.

When creating a desktop VM takes 5 minutes(on my Mac Mini M4) instead of an hour, you’ll experiment more. You’ll test ideas. You’ll learn faster.

Setup speed directly impacts exploration frequency.

Real-World Use Cases

Testing desktop applications:
∙ Build Linux GUI applications
∙ Test in actual desktop environments
∙ Keep your main Mac setup clean
Learning desktop environments:
∙ Try different Linux desktops
∙ Experiment without commitment
∙ Quick recreation if something breaks

Teaching and demonstrating:
∙ Show Linux desktop fundamentals
∙ Provide hands-on clickable environments
∙ Easy rebuilds for fresh starts

Running GUI tools:
∙ Access Linux-only GUI applications
∙ Use tools that work better visually
∙ Handle tasks suited to mouse interaction

Development environments:
∙ Build and test desktop applications
∙ Verify across different environments
∙ Debug display-related issues

What I Learned Building This
Building automation deepens system understanding.

To automate desktop VM creation, I learned:

∙ How Multipass networking integrates with Apple’s frameworks
∙ How xrdp configures and authenticates
∙ How desktop environments initialize
∙ Where configuration files live
∙ How to make XFCE and xrdp work together reliably

The script is straightforward. The learning required wasn’t.

Mac-Specific Considerations
Mac architecture, especially Apple Silicon, has specific characteristics:

ARM Architecture:
∙ Apple Silicon uses ARM
∙ Ubuntu ARM images work natively
∙ Performance is excellent on native ARM
∙ No translation overhead
Networking:
∙ Mac’s virtualization framework handles networking differently
∙ Multipass abstracts the complexity
∙ Port forwarding and addressing work cleanly

RDP Client:
∙ Microsoft Remote Desktop is excellent and free
∙ Perfect compatibility with xrdp
∙ Simple configuration
The script handles these details automatically.

The Pattern Continues

This is the third automation tool following the same approach:
1. Micro Kubernetes cluster automation (learning environments)
2. Linux instance creation (rapid provisioning)
3. Desktop VM automation (GUI access on Mac)

The pattern:
∙ Face repetitive manual work
∙ Recognize automation opportunity
∙ Build solution for personal use
∙ Realize others share the need
∙ Share the tool

Every tool addresses a real challenge I experienced.

The Time Investment

Manual setup:
∙ 30-60 minutes if experienced
∙ 1-2 hours if learning
∙ Multiply by each fresh VM needed

Automated setup:
∙ 5 minutes every time
∙ Consistent results
∙ No learning curve after initial use

Over a year, at just once monthly, that’s 6-22 hours saved.

Meaningful time returned to actual work.

What This Enables

When friction drops from “takes an hour” to “done in 5 minutes,” behavior changes:

Previous mindset:
“I probably don’t need a Linux desktop for this. I’ll find a workaround.”

Current mindset:
“Let me spin up a VM and test if this works better with a GUI.”

More experimentation. More exploration. Faster learning.

Infrastructure should enable work, not create barriers.

Amit - Linux Systems Engineer, 24 years in enterprise infrastructure (AWS, Dell, TSB). I build automation tools for real challenges I’ve encountered. Find my tools on Gumroad, or follow my YouTube (Amit’s Tech Hub) where I document what I’m building and learning.​​​​​​​​​​​​​​​​

7 months ago (edited) | [YT] | 1

Amit's Tech Hub

Kubernetes Automation: What I Built Because I Was Tired of Wasting Time

I spent my evenings at AWS doing something that probably sounds insane.

After 10-hour days building CodeDeploy infrastructure, I’d come home and rebuild the same Kubernetes cluster. Again. And again. And again.

Not because I enjoyed it. Because I was trying to learn Kubernetes properly and the manual setup was eating the only time I had left.

So I automated it. That tool became what I’m selling now on Gumroad. And honestly?

The problem it solved is costing you more than you think.

The Actual Problem

Learning Kubernetes means breaking things. A lot.

Which means rebuilding your environment. A lot.

Manual multi-node cluster setup:

∙ 45-60 minutes if you know what you’re doing
∙ 2-3 hours if you’re learning and hit issues
∙ Multiply that by every time you need a clean slate

When I was at AWS, I was doing 50-60 hour weeks on CodeDeploy. I had maybe 8-10 hours per week for learning. I couldn’t afford to spend half that time typing the same kubeadm commands over and over.

The math was brutal: Either spend my limited time actually learning Kubernetes concepts, or spend it on infrastructure setup that should already be automated.

Why MicroK8s

I went with MicroK8s because:

-- Speed - Lighter than full Kubernetes, faster to spin up
-- Real enough - Production-grade features without enterprise bloat
-- Multi-node capable - Could simulate actual cluster behavior on my laptop

But even with MicroK8s, the setup dance was tedious:

1. Provision nodes
2. Install MicroK8s on each
3. Configure networking
4. Join nodes to cluster
5. Enable add-ons
6. Verify everything’s talking
7. Set up kubectl access

Once? Fine. Fifteen times in a month because you’re experimenting? Soul-crushing.

What I Built

My tool automates the entire multi-node MicroK8s cluster build.

What it does:

∙ Spins up your nodes
∙ Handles all installation and config
∙ Joins nodes automatically
∙ Configures networking so it just works
∙ Sets up kubeconfig for immediate kubectl access
∙ Enables common add-ons (DNS, storage, ingress)

What it gives you:

∙ 5-10 minute cluster builds instead of 45-60 minutes
∙ Consistent, reproducible environments
∙ Freedom to experiment without the setup tax
∙ More time learning instead of configuring

The first version was rough - a bash script that barely worked. But it saved me 30-40
minutes every time I needed a fresh cluster.

Over the months I was learning Kubernetes, that added up to dozens of hours.

Hours I used to actually understand pods, services, deployments, StatefulSets, and all the other concepts that make Kubernetes worth learning.

The Real Cost

Let’s do the math:

If you’re learning Kubernetes:

∙ Rebuild cluster 2-3 times per week (conservative)
∙ 45 minutes per rebuild = 1.5-2.25 hours per week
∙ Over 3 months: 18-27 hours spent on setup alone

If you’re teaching teams:

∙ Every person needs their own environment
∙ Every training session needs clean clusters
∙ Every workshop participant hits setup issues
∙ Multiply your time loss by team size

If you’re running experiments:
∙ Testing configurations requires fresh starts
∙ Comparing approaches needs parallel environments
∙ Demonstrating to stakeholders requires working clusters

The tool I built wasn’t about laziness. It was about not letting infrastructure setup become the bottleneck to actual learning.

Why This Matters Beyond My Tool

The principle applies everywhere: Repetitive infrastructure setup is a tax on your actual work.

Whether it’s Kubernetes clusters, dev environments, test infrastructure, or deployment pipelines - every minute you spend manually configuring something that could be automated is a minute you’re not spending on work that actually matters.

At AWS, we automated everything because at scale, manual processes don’t just slow you down - they become impossible.

But the same logic applies when you’re one person trying to learn something new in your evenings after a full workday.

What I Learned

Building automation tools teaches you more about the underlying technology than following tutorials ever will.

To automate MicroK8s cluster creation, I had to deeply understand:

∙ How Kubernetes networking actually works
∙ What each component does and why it’s necessary
∙ Where the failure points are
∙ How to make the process idempotent and recoverable

The tool became both the product and the teacher.

And now it’s something I can offer to others facing the same time crunch I was: people who want to learn Kubernetes but can’t afford to spend half their learning time on infrastructure setup.

The Meta Lesson

This reinforced something I’ve learned over 24 years in infrastructure: The best tools come from solving your own pain.

I wasn’t building this to sell it. I was building it because I needed it.

The fact that others need it too? That’s validation the problem was real.

If you’re spending hours on repetitive setup tasks, you’re probably not alone. And you’re probably sitting on a tool others would pay for.

You just need to build it for yourself first.

Amit - Linux Systems Engineer, 24 years in enterprise infrastructure (AWS, TSB, Dell). I build automation tools for real problems I’ve faced. Find my Kubernetes tools on Gumroad, or follow my YouTube (Amit’s Tech Hub) where I document what I’m building and learning.

7 months ago (edited) | [YT] | 1

Amit's Tech Hub

Recommending Pooja Dutt's channel, who for me makes the best Tech Content

Check this video out - https://youtu.be/xUA8MzHUgFs?si=zu3Za...

1 year ago | [YT] | 1