DEV Community: Syed Masood Shah

Why I export meeting notes to markdown in 2026

Syed Masood Shah — Tue, 15 Sep 2026 20:46:21 +0000

Half of a meeting note is the note itself. The other half is where it ends up the morning after, when you actually need it.

I used to keep minutes inside whatever app wrote them at the end of the call. Then I went looking for a decision we made in April, and the app wanted me to sign in. The decision was buried behind a search box that only matched the whole phrase. It was my own notes and I couldn't get at them. That's the part of AI meeting notes nobody shows you in the demo.

So now everything I write down lands as markdown files on the same drive as the rest of my life. Teams call, Zoom hookup, three people around a table in the office — the recording gets transcribed on my own PC, a local model writes it up, and I export the result to markdown, plain text, or PDF. Then it's a file. Files don't expire, don't need a subscription to be opened, and don't ask me for a password in two years when the vendor rebrands and deletes my account.

I keep them in a folder by date, and I point whatever I want cross-linked at Obsidian. A markdown file opens in anything: Obsidian, VS Code, Notepad. A PDF I can mail to a stakeholder who doesn't live in my tooling. Plain text when I just want to paste the decisions into a ticket.

What meeting minutes actually need

Part of why these files work is what's inside them. A raw transcript is not minutes — and a file is only useful in six months if it answers four questions:

What did we decide?
Who owns each action, and by when?
What stayed open?
Why did any of it matter?

The app I use builds exactly that structure without me asking: a one-paragraph summary, the key decisions in plain words, action items with owners and dates where anyone actually said them, and a list of open questions. If the audio is decent, it keeps the owners and due dates people said out loud. That's the difference between a file I reopen and a file I delete.

None of that touches the internet, which matters more than it sounds. The audio, the transcript, and the finished minutes stay on my machine. No bot joins the call, no audio goes to a vendor's server, no account, no subscription. A confidential Monday sync doesn't turn into somebody's training data.

How to export meeting notes to markdown

The setup is boring in a good way. Windows 10 or 11, Python 3.10+, and LM Studio running any small model so the minutes-writing step stays local too. It runs on CPU; a GPU just makes faster-whisper transcribe quicker. Record, stop, read your notes, export. Markdown, text, and PDF are each one button.

If you're tired of handing your meetings to a cloud notetaker but don't want another subscription to babysit, the meeting-notes app I use is a one-time $9 at https://symshah.gumroad.com/l/xgoypx. Your notes, on your disk, in a format that'll outlive the app.

FAQ

What format should I export meeting minutes to?
Markdown for anything you'll link, search, or keep long-term; PDF when you need to share it with people who don't care about formats; plain text when you just want the decisions in a ticket.

Can AI meeting notes export to markdown automatically?
Most cloud notetakers treat markdown as an afterthought and keep your real archive on their servers. A local app exports the same file that already exists, so there's nothing to sync and nothing you don't own.

Is exporting meeting notes to PDF possible offline?
Yes. The PDF is generated on your own machine, so you can produce it with no internet connection and no cloud involved.

What real-time video translation needs under the hood (2026)

Syed Masood Shah — Tue, 15 Sep 2026 13:58:58 +0000

Somewhere between a loaded mail server and a Zoom invite, I wound up building a tool that dubs foreign films in my browser. Not because I set out to. Because I got tired of a movie I wanted to watch being in a language I only half understand, and the cloud dubbing options wanted my video and my credit card.

Real-time video translation sounds like a flex when you say it fast. In practice it's a pipe with three stages, and most people assume it's one big black box. It isn't.

What real-time video translation actually is

Here's the honest definition I use when people ask. It's hearing a line of dialogue in one language and hearing that same line spoken back to you in yours, a couple seconds later, while the video keeps playing. Not reading subtitles — hearing speech you understand. No saved files, no waiting for a render to finish. It just happens while you watch.

The pipeline, stage by stage

Stage one is grabbing the sound. My browser extension captures the tab's audio the moment you press play. No upload, nothing routed through my own network — the audio never leaves the machine.

Stage two is Whisper turning that audio into text as it streams. I feed it chunks, not the whole file, so the transcript lags the picture by only a few seconds.

Stage three is the translation, which runs on a local LLM through LM Studio. Free, and this is the bit people don't believe: it doesn't need a training-grade rig. Python 3.10+, LM Studio, one small model around 2GB. A GPU helps but isn't required.

Then Kokoro speaks the translated line out loud, and it does one thing that quietly makes the whole thing usable: it watches the pitch of whoever's talking and swaps between male and female voices to match. A two-person scene doesn't turn into a wall of one synthetic narrator. The original dialogue ducks under the dub so you still hear the film, just quieter underneath.

The bottleneck nobody mentions

It can't translate until the speaker finishes the sentence. That's physics, not a flaw. Whisper has to hear a line before the LLM can translate it, and the LLM has to produce an answer before Kokoro can speak. Every tool in this space works this way, cloud or local, and any one that pretends otherwise is dubbing from a script someone already gave it. The honest latency is a sentence or two. Fine by me — it beats subtitles for following a conversation on screen.

The part I actually care about is that nothing about this touches a server I don't control. The movie I'm watching, the words on screen, my listening habits — all local, offline once it's set up. I built it as a small Windows app plus a browser extension, and I priced it at a flat $19 one-time instead of a subscription, because running your own translation shouldn't bill you monthly. If that's the trade you're after, it's at https://symshah.gumroad.com/l/livedub.

FAQ

Does it need a powerful computer?
No. A normal laptop runs it; a GPU speeds it up but isn't required.

Does it upload my video anywhere?
No. Capturing, transcribing, translating and speaking all happen on your machine.

Why does the dub lag behind the video?
The translator can't start until the speaker finishes a sentence. That delay is a sentence or two and applies to every dubbing tool, local or cloud.

Your backup isn't a backup until you've tested the restore (2026)

Syed Masood Shah — Tue, 15 Sep 2026 13:52:20 +0000

I used to believe a backup was a backup. Then I needed one.

This is the part nobody tells you in the homelab forums. You'll read a hundred threads about deduplication ratios and retention schedules, and almost none about the moment you actually try to get your data back and it doesn't work. My first real restore test failed on a Tuesday, and it wasn't the storage that let me down. It was me. I'd never checked that the thing could come back.

So if you run any self-hosted setup — especially the kind that backs up Docker volumes and configs with restic — here's the routine I use now before I trust a single snapshot.

A backup is only a promise. A restore is the proof.

Why I test restores instead of just taking snapshots

Backup tools are really good at backing up. restic snapshots are fast, deduplicated, encrypted, and they look great in a list. The trap is that a full snapshot list tells you nothing about whether the data is readable, whether the repository password still works, or whether you could pull a specific file out under pressure.

That's why my rule is: once a month, I restore something real from a snapshot. Not to a test directory I'll delete — to a path I actually compare against the source. And I run restic check first to confirm the repo is internally consistent, because a repo that's silently corrupt will still list snapshots happily.

A restore drill catches the things that bite you later: a forgotten repo password, a backend that stopped being reachable months ago, an encryption key you rotated but didn't re-test. Those don't show up in a status dashboard.

The restore test I actually run

Keep it boring. A single command that pulls a recent snapshot into a scratch directory and diffs it against the live tree:

restic -r /mnt/backups/repo restore latest --target /tmp/restore-test

Then a diff, a scripted check that the file count and sizes match, and you're done. The whole thing takes five minutes. The point isn't drama — it's that the skill and the credentials both still work.

Backup verification is a habit, not a project

The teams that survive incidents aren't the ones with the most elaborate backup dashboards. They're the ones who've actually restored under pressure before. Once a month I do the drill, and because the routine is scheduled and logged, I can prove it happened. When the audit rolls around and someone asks "are these backups good?", I show them the restore logs, not a promise.

If you're building this out for a small business or a homelab and don't want to reinvent the backup-and-verify layer yourself, I bundled the exact approach I use — restic plus a small audit dashboard that tracks when backups ran and whether restores were tested — into the SMB Security Pack, a $15 one-time set of three self-hosted Docker stacks. It's the backup piece I wish I'd had before that failed Tuesday.

FAQ

How often should I test a restic restore?

Once a month for anything you care about. Weekly if it's business-critical. The cost is a few minutes and it turns "we back up" into "we can restore."

What's the difference between restic check and a restore?

restic check verifies the repository is internally consistent and all data is readable. A restore proves you can actually pull files back out and use them. Run both; they catch different failures.

Can I test a restore without touching production data?

Yes. Restore to a scratch directory like /tmp/restore-test, diff against the source, then delete it. No production impact, full confidence.

Try the SMB Security Pack — three self-hosted Docker stacks (Wazuh, CrowdSec + Grafana, restic backup with an audit dashboard) for $15 one-time.

Q4_K_M vs Q8_0 for your local LLM: what I actually notice (2026)

Syed Masood Shah — Tue, 15 Sep 2026 13:45:33 +0000

I spent a solid three months refusing to quantize anything out of sheer stubbornness. Full precision or nothing. It was dumb. A 7B model at full float needed about 14GB of VRAM, my GPU has 8GB, so I was watching the thing spill into CPU RAM and crawl. Then I actually read what Q4_K_M meant and stopped being smug about it.

If you're new to this, a quick setup of the terms, because the model download pages assume you already know. Quantization is squashing the model's weights from 16-bit floats down to 4-bit or 8-bit integers so the file is smaller and fits in video memory. The names look like model gibberish, but the two you'll see on every GGUF repo are Q4 and Q8_0, and honestly the K_M suffix just means the weights get split into blocks where the sensitive ones stay a bit more precise. That's it. That's most of the mystery. GGUF is the container format LM Studio and Ollama read, so if you've ever stared at a hugging face page going what do I press, this is the short version: grab the Q4_K_M file and get on with your day.

Here's what I actually measured on my local setup when it comes to local LLM quality loss. Going from Q8_0 down to Q4_K_M cost me maybe three percent on the generic chatbots, and I could not feel it in normal conversation. Where I noticed it was structured reasoning, harder token pressure.

So when does Q8_0 win? When the task is decision-critical. Code, extraction, anything where one wrong token breaks the output, an eight-bit model earns its two-times-the-file-size. When is Q4_K_M fine? Most days. I run a private chat assistant, and honestly, I forget it's sharpened down. The frustrating part of measuring this properly is the cheap metric lies to you. Perplexity moved by nothing. My actual task pass rates told the real story.

My rule now is boring but practical: whatever still fits in VRAM first, pick the biggest quant that does. A 13B at Q8_0 that spills to CPU loses to a 12GB-class model in Q4_K_M every single time, because the whole model living in fast memory beats a wiser one limping. Slow tokens are the silent killer. On an 8GB card, Q4_K_M for a 7B fits. On 16, you have Q8_0 room for 13B and it's worth it.

I put the whole thing together as a bundle because I got tired of re-docing it every laptop. LM Studio for running models, Open WebUI for the chat interface, Docker to hold the stack, and pre-tested quantized models so I don't gamble on a repo at midnight. Everything stays on my own hardware, no cloud hop, no monthly bill, no one getting a copy of my queries. It's pay-what-you-want at nine dollars and change, which is cheaper than the latte I used to buy to run the same model. If you're already running the stack, add the quantized draw, it's the cheapest RAM you'll buy. https://symshah.gumroad.com/l/selfhosted-ai-homelab

If you want the shortcut instead of the benchmark gauntlet: pick Q4_K_M first, swap to Q8_0 only when a task genuinely fails, and never trust a perplexity number alone. Trust the task that keeps failing.

FAQ

Is Q8_0 really worth double the size cost? Roughly, yes, a 7B model that's about 4.9GB at Q4_K_M is closer to 8.5GB at Q8_0. Worth it only when precision-sensitive output matters.

Does Q4_K_M actually lose quality versus full precision? Around one to three percent on standard benchmarks and a touch more on hard reasoning. Usually invisible in chat, real in code.

Which quantization should I start with in LM Studio? Q4_K_M. It's the default pick in the community for a reason, and you can re-download a higher quant later without touching the rest of your setup.

Private meeting notes in 2026 stay on your own PC

Syed Masood Shah — Sun, 13 Sep 2026 20:43:23 +0000

Somewhere in a privacy policy you clicked past, most meeting-notetaker apps reserve the right to train on your own calls. I read that clause about Otter's suite after the 2026 Illinois lawsuit landed, and I got quiet for a second. A third of my calendar is vendor calls, HR syncs, and salary talk. The idea that any of it was fair game for someone's model is what finally pushed me to run meeting notes entirely local.

What private meeting notes actually mean

Private meeting notes don't mean the tool has a pretty lock icon. It means the audio never leaves your machine. Not a transcription service on some vendor's cluster, not a summarization API, not a training corpus. When I say nothing leaves the PC, I mean literally nothing leaves the PC. If you unplug the router mid-meeting, the whole pipeline still finishes.

Where cloud notes quietly leak

The leaks are rarely a breach. Usually it's boring and contractual. A bot joins as a participant and everything said goes to someone else's server. The vendor's own LLM summarizes it. The raw recording gets retained for "quality" and staff can see it. Maybe that's fine for a general standup. On a call about a client's unpaid invoice or a peer's performance review, it's not.

That's the gap I was trying to close. I didn't want a cheaper Otter. I wanted the same structured output with the recording and the minutes never existing anywhere but my desk.

The setup that keeps meeting minutes local

I'm on Windows, so the app I settled on records mic and system audio — Teams, Zoom, Meet, or a room full of people — then transcribes on-device with Whisper, then feeds it to a small local model in LM Studio that writes the minutes. Summary, key decisions, action items with owners and dates where they were stated, open questions. It exports to Markdown, text, or PDF.

Requirements are modest: Windows 10/11, Python 3.10+, and the free LM Studio with any small model loaded. It runs on plain CPU. A GPU just makes the transcription step faster — mine's a work laptop with no gaming card and the bottleneck is still my attention, not the box.

# no cloud call here - faster-whisper and LM Studio both run locally
pip install faster-whisper

I keep the raw transcript too, because a transcript is a record and minutes are a promise. When someone swears a decision went differently, I have the exact words from my own disk, not a link to a shared doc I don't control.

Why I stopped caring about the "best" notetaker

Every cloud notetaker compares on accuracy percentage and UX polish. I stopped comparing once the constraint was privacy. If the audio can't leave the building, most of the market is off the table by definition, and the choice shrinks to how well a local tool handles my meeting structure. Structured action items beat a pretty transcript every week.

I've been running this for a few months now. The minutes land as files, I keep what matters, and searchable history stays under my own folder. It costs $9 once, no subscription, no account, no upload queue. If you want the same without handing your calls to a vendor, it's at https://symshah.gumroad.com/l/xgoypx

FAQ

Will a local setup keep up with a long call?

Yes. Transcription runs as the meeting happens (or right after), and a small LLM writes the minutes. On CPU a marathon three-hour session waits longer for the transcript pass, but it always finishes — and it finishes on your machine.

Do I need an Nvidia GPU for this?

No. CPU works fine with faster-whisper's small models and any half-decent LM Studio model. A GPU speeds up the transcription, that's the whole difference.

What happens to the recordings afterwards?

What you choose. They stay in a local folder, get moved to your backup routine, or get deleted. There is no vendor retention policy because there is no vendor.

What cloud dubbing actually costs vs running it locally (2026)

Syed Masood Shah — Sun, 13 Sep 2026 01:55:45 +0000

I used to send film clips to cloud dubbing services and watch the meter run. Five minutes of a French documentary was about a dollar. A full episode runs longer, and the numbers get stupid fast. That's the whole reason I stopped looking at the meter and started dubbing locally instead.

The short version: cloud dubbing charges by the minute, by the character, or by the month. Local dubbing costs a one-time model download and your electricity. My outage bill for a year of local video translation was roughly what that cloud service dinged me for two afternoons.

What cloud dubbing actually charges

Most cloud dubbing and translation tools bake their pricing into usage. You get a free tier that's measured in seconds, then it's per-minute for audio, per-character for generated speech. Ten hours of dubbed video a week adds up to a very specific number. Some roll it into a flat monthly sub, so if you don't use it every single day you're paying to keep it warm.

Then there's the stuff nobody prices into the comparison. Your audio goes to their servers, so the clip you're translating is now someone else's dataset. It's usually against their ToS to dub proprietary or sensitive media at all. And you need a connection for every single sentence.

Why I moved translation fully local

My whole pipeline runs on one Windows box. The browser extension grabs the tab audio, Whisper transcribes it, LM Studio runs a small local LLM to translate, and Kokoro TTS speaks the result. It's a ~2GB model, Python 3.10, no GPU required (it helps). Once set up, it works offline.

The male/female voice switching is the part that surprised people. I had a tool that always picked one voice for every speaker. Pitch analysis decides the voice per line, so a two-person scene has two actual voices, and the original audio ducks under the dub so you still hear the music and the delivery.

It's not instant. It waits a sentence or two because it can't translate until someone finishes talking. Every dubbing tool does this. The difference is the wait happens on my desk and nothing leaves the building.

The honest cost breakdown

I did the math instead of guessing, and the delta was lopsided. My monthly spend on the local rig was the model storage and fan noise. The cloud quotes I got were either a per-minute meter or a subscription that assumed heavy daily use. That subscription only made sense if I was dubbing constantly.

Privacy is the part I'd defend to a client. Proprietary training video, client interviews, unreleased content — none of it touches a third party. Disconnect the machine and it still works. You can't do that with a service that holds your audio on its servers.

FAQ

Can I dub videos in real time with a computer that has no GPU?
Yes. The bottleneck is Whisper and the TTS, and Kokoro runs fine on CPU. A slow laptop just means a slightly longer sentence gap. No GPU required.

Is everything stored locally?
Yes. After the initial model download the whole pipeline is offline. Audio, transcripts, and the translated dub never leave your machine.

What languages does it handle?
Whatever Whisper transcribes and the local LLM translates. Same coverage as the underlying models, which is a lot. I mostly dub into and out of English, Spanish, French, and Hindi.

If you want to skip the week of wiring it together, my working build is a one-time $19 at https://symshah.gumroad.com/l/livedub. Offline after setup, no meter.

Self-hosted SIEM vs cloud SIEM: what I learned in 2026

Syed Masood Shah — Sun, 13 Sep 2026 01:50:53 +0000

Every SIEM renewal, someone forwards me the same spreadsheet. Splunk, Sentinel, QRadar, all the per-GB ingestion rates, and the sales line about how the cloud one "handles everything for you." It always looks reasonable at ten gigs a day. It never looks reasonable by the second renewal, when your log volume has tripled and the invoice has quadrupled.

So here's my honest take on the self-hosted SIEM vs cloud SIEM question in 2026: the features are closer than the marketing wants you to believe, and the real fight is over who owns your log volume and what happens when that volume spikes.

A cloud SIEM bills you on ingestion. Ransomware hits, a box goes sideways, forensic logs flood in — exactly when you're busy, your bill multiplies. I've watched a budget take that hit during a real incident. It's the worst possible moment to discover your meter.

A self-hosted one doesn't care how much you pour into it. I run Wazuh in Docker on my own hardware. Logs land on my disk, not someone's shared pool, and the only limit is the disk I gave it. Same idea runs through the whole stack I use:

wazuh      # SIEM core — detection and file integrity
crowdsec   # threat wall — blocks the bad IPs before they matter
restic     # backup audit — proves the data is actually there

Three Docker stacks instead of three SaaS renewals. Wazuh's the engine, CrowdSec sits in front of anything exposed, and restic quietly backs the rest up. No per-GB meter on any of them.

The honest trade-offs: you maintain it. Wazuh doesn't tune itself, so you'll spend an afternoon taming alert noise. My rule stack started loud and got quieter as I filtered out what didn't matter. There's no phone number to call at 3am — I'm the support desk for my own lab.

But the payoff is real control. My security data stays mine. No retention policy I'm told about after the fact, no export window, no vendor roadmap deciding whether a feature survives. If I want a year of logs, I keep a year of logs.

And I know roughly what it costs. Not zero — I pay for the machine and the power. But versus a cloud SIEM billed on ingestion it's a rounding error, and the cost barely moves whether I log ten events or ten thousand. The spike is the whole game, and self-hosting wins it.

None of this is revolutionary. It's what "own your logs" actually looks like in practice. If you're weighing whether to self-host or keep feeding the meter, stop comparing the sales sheets and start comparing what happens when your volume doubles mid-incident.

I bundled this all into one stack you can spin up yourself — a SIEM core, a threat wall, and a backup layer, each a plain docker-compose file. If that sounds useful, it's over at SMB Security Pack.

FAQ

Do I need a big server for a self-hosted SIEM?
No — Wazuh in Docker runs fine on a mid-range homelab box. Give it a few GB of RAM and disk for retention and you're set.

Does self-hosting mean I lose threat-intel updates?
No. Wazuh ships regular rule updates and CrowdSec pulls live blocklists. You keep the intelligence without the SaaS bill.

Is self-hosting still cheaper if cloud prices keep dropping?
Generally, yes, because cloud SIEM cost scales with your log volume while fixed hardware doesn't move. It only catches up when you outgrow the box.

Run Your Own Private ChatGPT With Open WebUI (2026)

Syed Masood Shah — Sun, 13 Sep 2026 01:42:46 +0000

I got tired of pasting work questions into a browser tab and wondering who else had a copy. So last year I stood up my own private ChatGPT at home. It took one evening, and I haven't logged back into the browser one since. Here's the honest version of how it works, and where you'll actually hit friction.

Quick before I forget: by 'private ChatGPT' I mean a chat interface that runs on hardware I control, talking to a model that also runs on hardware I control. No API calls out, no prompt logging on someone else's server, no account tied to my email.

What a self-hosted ChatGPT actually is

It's two pieces. The engine is the model, and the face is a web UI. For the face I use Open WebUI, because it looks and behaves like the thing everyone grew up clicking. Threads, markdown, regenerating answers, a model picker in the corner. Nobody in my house needed a tutorial.

Underneath sits a local model. The bundle I run uses LM Studio to manage and serve quantized models, which sounds fancy until you realize a quantized model is just the same model with the weights rounded off so it fits in your VRAM. Q4 is the usual sweet spot. You lose a little edge case reasoning and keep most of the useful answers.

The one-command start

Open WebUI and a local model engine run fine as a Docker pair. If you already have anything running on port 11434, that's likely Ollama or LM Studio's server — let the container talk to the host instead of fighting over the port:

docker run -d -p 3000:8080 \n  --add-host=host.docker.internal:host-gateway \n  -v open-webui:/app/backend/data \n  --name open-webui --restart always \n  ghcr.io/open-webui/open-webui:main

Open http://localhost:3000, claim the first account (it becomes admin), point it at your local model, done. That's the whole setup. Most of the evening is spent pulling models and deciding which quant to bother with.

Where it's actually better

The privacy is the point. My team's questions, my half-finished notes, the slightly embarrassing drafting — none of it leaves the desk. When the internet dropped during a storm last month, my chat kept working. A local model can't be rate-limited, and it won't change its behavior because thousands of other people hammered the same endpoint.

Where it's honestly worse

A 7B or 8B model is not a frontier flagship. It'll write competent drafts, summarize, explain code, and do the 90% of work I actually ask it for. It will occasionally be confidently wrong in ways a bigger cloud model wouldn't. I keep the cloud account around for the rare genuinely hard question.

I put all the defaults I learned into one place so you don't relive the wrong-quant-and-restart hour: my Self-Hosted AI Home Lab bundle covers the Docker stack, Open WebUI, and the quantized model picks that actually fit a home GPU: https://symshah.gumroad.com/l/selfhosted-ai-homelab

It's pay-what-you-want from nine bucks. If you'd rather just tinker with the two commands above, honestly, that works too.

FAQ

Is a private ChatGPT as smart as ChatGPT?

No. A home GPU runs a small quantized model that's good at drafting, summarizing and coding help, not a frontier model. For my daily work it's close enough that I stopped going back.

Do I need an expensive graphics card?

An 8GB card runs a solid 7B quantized model. 12GB opens up the 13B class. The better VRAM headroom buys larger models, not necessarily faster ones.

Does Open WebUI cost anything?

No. It's open source, and it talks to any local model engine — LM Studio, Ollama, or anything OpenAI-compatible. Your hardware and electricity are the only thing you pay for.

Meeting notes without a bot joining your call (2026)

Syed Masood Shah — Fri, 11 Sep 2026 20:40:05 +0000

The first time I fired up a meeting bot, a client asked, mid-call, who that was sitting at the bottom of the participant list. It wasn't a person. It was Otter, quietly streaming our conversation to someone else's server, and I had to explain that to a human who hadn't agreed to it. That was the day I started doing meeting notes without a bot joining the call.

The pitch for these tools is appealing, sure. A bot drops into your Zoom or Teams invite, listens, and emails you a tidy summary. But it also shows up as a visible guest, needs the host to admit it, gets blocked in locked rooms, and — the part that mattered to my client — uploads the audio to run transcription on vendor infrastructure. Nobody on the call consented to that. It's a lousy look for a company that handles other people's data.

There's a quieter way to get the same result, and it's all local.

What "meeting notes without a bot" actually means

Bot-free AI meeting notes are just software running on your own machine. It captures your microphone and your system audio at the OS layer — on Windows that's a WASAPI loopback device — so a call sounds the same as any participant joining normally. Nothing new appears on the meeting's participant list, because nothing joined. The meeting software just sees you on your own laptop.

The whole pipeline stays on your computer: capture, transcribe, summarize, export. On Windows 10 or 11 with Python 3.10+, transcription runs locally through faster-whisper, and a local LLM loaded in LM Studio turns the transcript into structured minutes. Since it's all on-device, there's no account, no subscription, and nothing ever uploaded — which means no recording banner on someone else's screen, and no bot to apologize for.

The actual workflow, once it's running

Recording is one click at the start of the call. Hit stop when it's over, and a few minutes later you have the transcript back. The local model then summarizes it into four sections:

Summary — what the meeting was about in a few plain sentences
Key decisions — what actually got agreed
Action items — with owners and dates, where anyone said them
Open questions — the loose ends worth carrying forward

Then you export to Markdown, text, or PDF. I export to plain text and drop the files in a shared folder that everyone can read, so the minutes are just files on disk instead of a chat bubble nobody scrolls back to.

A GPU makes transcription faster, but it's not required — it runs fine on CPU. If you've got an old work laptop with no dedicated graphics, that's exactly the machine I use it on.

Why local wins here

A bot you can't see and didn't ask for is bad enough. But the privacy case is the real one. For client calls, vendor conversations, or anything with personal data, the difference between "audio stays on my disk" and "audio goes to a vendor server for 30 to 90 days" is not a detail. One of those tools even keeps your recording by default. The on-device path doesn't have to ask the question.

There's one trade-off worth naming: you can only record meetings you're actually in. A bot could join a call you weren't invited to. I consider that a feature, not a bug — I shouldn't be capturing conversations I didn't attend.

FAQ

Do these tools work with locked or password-protected meetings? Yes. Since nothing tries to join the call, there's no bot to admit and no room blocker to fight. You're already in the meeting, so the recorder just works.

Does it need a GPU or a cloud account? Neither. It runs on CPU with Python 3.10+ and a free local model in LM Studio. A GPU only speeds up transcription. No account and no subscription — it's a one-time $9 purchase, not a per-seat monthly plan.

Is the audio ever uploaded anywhere? No. Everything happens on your own PC — capture, transcription, and the LLM summary. Nothing leaves the machine, which is the entire point.

If you want the same thing without explaining a stranger to your client, I wrote exactly this as a Windows app called Local Meeting Notes — record any call, get private minutes, and never let a bot through the door.

How to Capture Browser Tab Audio for a Local AI Dubber (2026)

Syed Masood Shah — Thu, 10 Sep 2026 13:53:01 +0000

The first weekend I tried to build LiveDub, I couldn't get the audio out of the browser. Not the hard part, not the model, not the TTS. Just getting the damn sound that was already playing in a tab and handing it to a script. Everything else was downstream of that, and nothing moved until I solved it.

Here's the thing about capturing browser tab audio that nobody warns you about: the browser doesn't hand you a stream you can just read. What you mostly have access to from an extension is the microphone, via getUserMedia. That gives you what the machine hears, which is not the same as what the tab is playing. You want the tab's own audio, clean, no speaker bleed, no room echo. A microphone grab of a movie playing on speakers is a disaster for transcription.

How to capture browser tab audio the way a dubber needs

There are two honest routes.

First is an off-screen capture element. You render the tab to a hidden canvas and pull the audio along with it. It works, it's clean, but it's heavier than it sounds and it fights with how some players render.

Second — the one I ended up on — is a loopback. The extension grabs the system audio output and subtracts everything that isn't that tab. Or you go lower and use a loopback channel at the OS level. On Windows that's where the loopback sits.

The short version: an extension can subscribe to the audio stream of its own tab. It doesn't need the mic, and it doesn't need to hear your speakers. That stream is what you pipe into Whisper.

The part that looks easy and isn't

Autoplay. Chrome used to let any tab blast audio the moment a page loaded, and tab capture was trivial. Then autoplay restrictions arrived, and suddenly a background tab isn't producing audio for you to capture until the user actually starts the video. So you can't just have a dubber sitting in a tab waiting. You have to ride the user's play state, or play in a way the browser lets audio flow.

I also burn CPU asking whether there's even audio before I kick off transcription. I watch the volume envelope and wait for a real pause — about 450ms of quiet — before I treat a chunk as a finished sentence. A fixed timer clips sentences in half and Whisper hallucinates on the pieces. A pause detector keeps the transcript whole.

Why this stays local

The whole pipeline — tab audio, Whisper, the LM Studio LLM that translates, Kokoro speaking — runs on my machine. Nothing is uploaded, and once the models are pulled it works offline. I watch a film in a language I don't speak and hear it in English while it plays, with the original dialogue ducking under the dub. No account, no credits, no API key.

It's Windows-only, Python 3.10+, and needs LM Studio (free) plus one small model around 2GB. No GPU required, though one makes Whisper noticeably snappier. And yes, it lags a sentence or two behind — it can't translate a line until the speaker finishes. Every dubbing tool has that delay; the honest ones admit it.

FAQ

Can a browser extension capture audio without the microphone?
Yes. An extension can subscribe to its own tab's audio stream directly, which is exactly how a local dubber avoids mic bleed and room noise.

Does capturing tab audio work offline?
Yes, once models are installed. The capture, transcription, translation, and speech all run on your machine with no network connection.

Is browser tab audio capture heavy on CPU?
The capture itself is light. The cost is in transcription, which is why it helps to watch for natural pauses instead of transcribing on a fixed clock.

If you want the finished thing rather than the archaeology, I sell LiveDub on Gumroad (https://symshah.gumroad.com/l/livedub) for $19 once. Setup is a download, LM Studio, one small model, and you're dubbing whatever you watch.

Open source SIEM in 2026 is cheaper than you think

Syed Masood Shah — Thu, 10 Sep 2026 13:47:48 +0000

I keep hearing the same excuse from small businesses: a SIEM is for enterprises. You need a dedicated security team, sixteen gigs of RAM minimum, and a budget line that makes the CFO wince. I believed that too, right up until I ran one myself. In 2026 a genuinely useful open source SIEM runs on the same kind of box you'd give a file server, and the software costs you nothing if you self-host it.

What an open source SIEM actually is

Strip the marketing and a SIEM just collects logs from your machines, runs them against detection rules, and flags the stuff that looks like an attack. Wazuh does that and a bit more — file integrity monitoring, vulnerability detection, compliance checks — all under GPLv2. No agent caps, no log-volume caps, no premium tier hiding behind a feature flag. That's the part vendors never lead with.

The part that scares people is the footprint, and honestly it's deserved. The heavy piece is the indexer, which is OpenSearch under the hood, and it needs one kernel setting or it refuses to start:

sudo sysctl -w vm.max_map_count=262144

Get that right, change the default admin password on first login, and you've done the two things that break most fresh installs.

Why self-hosting kills the "too expensive" excuse

Here's the thing nobody tells you: you don't have to run the enterprise-sized version. A single-node Wazuh stack is three containers — a manager, an indexer, and a dashboard — and docker compose up -d brings the whole thing up. You get the same detection engine and dashboards the big shops use, just without the scaling-to-ten-thousand-agents part that you'll never need.

What you actually pay is mostly time and a spare machine. 4GB of RAM will technically get you up; 8GB is comfortable. If there's an old Dell or a retired dev box sitting under someone's desk, that's your SIEM. The only real monthly cost is electricity, and the only real ongoing job is not ignoring the alerts once you have them.

The catch: out-of-the-box Wazuh rules are noisy. Real-world usage means a couple of weeks of quieting alerts that don't matter so the ones that do stand out. If anything, that's the part that justifies a pre-built stack — someone's already done the tuning for you. Concretely, that's why the setup I run paired Wazuh as the SIEM core with CrowdSec and Grafana for the network layer and restic for verifiable backups, because a SIEM that sees an attack you can't roll back from is only half a story.

FAQ

Do I need a dedicated security team to run an open source SIEM?

No. One person with Docker experience can stand up a single-node Wazuh deployment in an afternoon. The ongoing work is alert triage, not plumbing.

How much RAM does a self-hosted SIEM need?

You can get a single-node stack running on 4GB, but 8GB is the number I'd actually recommend for an indexer that doesn't feel sluggish.

Is Wazuh really free for a business?

Yes. The core platform is GPLv2 open source — no license fee at any scale. The company sells optional cloud hosting and support, but running it yourself in production costs nothing beyond your hardware.

If you'd rather skip the tuning weeks, I packaged the whole thing as three docker-compose stacks — SIEM core, threat wall, and backup audit — for a one-time $15 at https://symshah.gumroad.com/l/smb-security-pack with free updates. The software inside is all open source; you're paying for the setup that's already worked out.

Local RAG: querying my documents without the cloud (2026)

Syed Masood Shah — Thu, 10 Sep 2026 13:40:18 +0000

Two things finally clicked for me at the same time. One, I had years of documents scattered everywhere: runbooks, config notes, old ticket write-ups, meeting files. Two, the newest versions of chat tools got genuinely good at retrieving answers out of a pile of files you hand them. Problem was, handing them meant uploading that pile to someone else's server.

So last month I stopped doing that. I built a local RAG pipeline in my home lab and now I query my own searchable knowledge base across my LAN, and the files never leave my house. Feel free to keep uploading everything to a cloud tool if that's your call. I decided this week that my runbooks and client notes aren't something I want sitting in someone else's training data.

What a self-hosted RAG setup actually is

RAG, in plain terms, is the trick of retrieving the right chunks of your own documents and stuffing them into the prompt so the model answers from what's actually there instead of guessing from memory. You skip the "does the model know my network topology" lottery entirely. Locally, that's a vector store plus an embedding step plus whatever small LLM you already run. No magic — just retrieval before generation.

The stack I landed on is boring on purpose: a local model runtime, a web UI, and Docker holding all of it together. Upload a PDF, it gets split and embedded into vectors, and from then on I ask questions in the chat window like it's any AI tool. The difference is the answer is grounded in my files, and nothing crossed the firewall.

Why local beat the cloud for the same job

The honest cost of cloud RAG isn't the API bill. It's the pipeline you build twice. You index everything into their system, you fight their upload limits, you hope their retention keeps your data inside whatever jurisdiction you care about.

Local flips all of that. I index once, my data stays encrypted and sitting on my own disk, I don't pay per query, and I control the model so it's not quietly swapping out for a newer remote one I never approved. For a working infrastructure notebook, that control is the whole point.

It's also not the giant lift people assume. If you already run quantized models through a web UI and Docker is second nature, the extra step is just pointing the UI at a folder of documents and letting it build the index. That's realistically an evening project, not a week.

# the pattern is just: docs in -> embeddings -> vector store -> query
# everything lives in one docker-compose file on my home server

FAQ

Do I need a powerful GPU for local RAG?
No. Embedding small chunks is light, and a mid-range card or even a decent CPU handles it. My everyday queries run on the same modest GPU I already used for the LLM.

What file types can a self-hosted RAG index?
PDFs, Markdown, plain text, most office documents. I mostly feed it runbooks and notes and it handles them fine.

Is local RAG as accurate as a cloud one?
For my own documents, it's better, because the retrieval is grounded in exactly what I wrote rather than whatever the cloud model happens to guess. The wording quality of the answer isn't as flashy as a frontier model, but the grounding is what I actually need.

I'd already built the whole base — the model runtime, the web chat UI, Docker, the quantized models — into one self-contained lab so none of it touches the cloud. Adding local RAG on top meant wiring one more layer into that. If you want that base without assembling every piece by hand, the whole setup I run is rolled up in one bundle at https://symshah.gumroad.com/l/selfhosted-ai-homelab. It's how I stopped renting my own notes.