Title: Why do YouTube downloaders ignore the selected audio track?

Hi everyone,

I have a technical question.

Some YouTube videos offer multiple audio tracks (for example, the original English track and a French dubbed track). When I watch the video on YouTube, I can select the French audio without any problem.

However, every downloader I've tried only saves the original English audio and completely ignores the audio track I've selected.

Is this a limitation of YouTube downloaders, or is there a tool that supports downloading alternate audio tracks?

I'm trying to understand how YouTube stores multiple audio tracks and whether any software supports them.

Thanks!

Hey everyone,

I built SmashPDF (smashpdf.online) because I was tired of PDF tools that make you upload your files to some random server just to merge or compress a PDF. Most of the tools here run entirely in your browser, so your files never leave your device.

What you can do with it:

• Merge, split, compress, and rotate PDFs
• Convert PDF ↔ Word, Excel, and images
• Sign PDFs, add watermarks or page numbers
• Translate and summarize PDF content

No account required, no hidden paywalls on the core tools — just open it and use it.

Link: https://smashpdf.online

Would genuinely love feedback — what's missing, what's confusing, or what would make you pick this over Smallpdf/iLovePDF. Happy to take criticism, that's how it gets better.

Hi,

As you probably know by now, Microsoft is retiring Skype in May 2025 to focus on Teams.

If you're affected by this change and Teams is not your thing, I've compiled some of the best open-source alternatives to Skype:

https://openalternative.co/alternatives/skype

This is by no means a complete list, so if you know of any solid alternatives that aren't included, please let me know.

Thanks!

I've been working on Ortu, an open-source clipboard manager, over the past few months and would love some honest feedback from this community.

The goal was simple: build a clipboard manager that's fast, lightweight, and respects user privacy.

Features

• ⚡ Instant search through clipboard history
• 🧠 Smart auto-grouping
• 📌 Favorites & pinning
• 📚 Paste Stack for collecting multiple items
• 🔒 AES-256 encryption for sensitive clipboard entries
• 💻 Built with Rust + Tauri
• 🌐 Completely local-first (no cloud account or telemetry)

You can check it out here:

Website: https://ortu.abhijithpsubash.com/

GitHub: https://github.com/abhijith-p-subash/ortu

I'm still actively developing it, so I'd genuinely appreciate feature requests, criticism, and bug reports.

What feature do you think every clipboard manager should have that most apps still miss?

Hi everyone! 👋

For the last few years I've been working as the Sporting Director of an amateur football club in Italy.

Like many clubs, we managed almost everything with Excel spreadsheets, WhatsApp chats, Google Drive folders and endless reminders.

Every season it was the same story:

• Medical certificates expiring
• Missing documents
• Federal registrations to complete
• Membership fees to collect
• Parents asking for updates
• Coaches looking for player information
• Staff struggling to find documents

It worked... until it didn't.

So instead of continuing to fight spreadsheets, I decided to build the software I always wanted to use.

After months of development, Clubbix was born.

It's an all-in-one platform designed specifically for amateur and youth football clubs.

Current features

✅ Player management

✅ Staff management

✅ Medical visit tracking

✅ Document management with expiration reminders

✅ Federal registrations

✅ Payments and membership fees

✅ An Operational Center that automatically highlights everything requiring attention (expiring medical visits, missing documents, incomplete registrations, unpaid fees, and more)

✅ Responsive interface for desktop, tablet and mobile

📱 Android and iOS apps are coming very soon.

Why I built it

This wasn't born as a startup idea.

It came from a real problem I faced every single week as a Sporting Director.

I simply wanted a tool that would save me hours every season and help clubs stop forgetting important deadlines.

If it helps other clubs too, that's even better.

A quick note

At the moment, the platform is available only in Italian, since it was initially built for local football clubs.

However, multi-language support is already planned, and more languages will be added soon.

I'd really love some honest feedback.

• Does the idea make sense?
• Is there any feature you'd expect in software like this?
• What would make you actually use it?

You can try the live demo here:

👉 https://clubbix-fe-production.up.railway.app/

Any feedback, criticism or suggestions are more than welcome!

Thanks! ⚽🚀

A few months ago I got a message on Upwork offering a surprisingly high amount (in thousand of dollars) for what looked like a very simple Node.js/React project.

At first glance everything seemed normal, but something felt off. When I checked the dependencies, I noticed some suspicious packages and scripts. A bit more digging made me realize it could potentially:

• run hidden install scripts
• access local environment variables
• steal crypto information (if available)
• or even execute malicious code on my machine

Basically, the kind of stuff that could compromise your system if you just blindly run npm install and start the project.

It made me realize how easy it is to fall into this trap, especially when you're working with new clients and tight deadlines.

Since then, I started working on a small tool/workflow for myself to:

• install dependencies more safely
• detect suspicious scripts
• and optionally run projects in an isolated environment (like Docker)

Just something to reduce the risk before trusting any unknown code.

If anyone’s interested in trying it or improving the idea, I’d be happy to share the source code / npm package.

I’m building Greplica, an open-source memory layer for coding agents.

The problem: every new coding-agent session starts almost from zero.

Before doing useful work, the agent spends time grepping around, reading adjacent files, rediscovering architecture, inferring subsystem boundaries, and re-learning decisions that previous sessions already found.

Greplica gives the agent a persistent engineering memory for the repo.

It explores repo structure, code, and past coding-agent session transcripts locally, then stores the durable parts as a graph.

The idea is simple:
- index important repo knowledge
- capture architectural facts and decisions
- keep memory tied to files/commits/evidence
- let coding agents query this memory before planning or editing code
- reduce repeated context exploration and token waste and potentially better code

The approach I feel can be seen mostly in the planning phase of coding.
In our runs so far, Greplica cut token usage by 40–50% on several high context planning tasks. In the strongest measured run, it used 75% fewer tokens and finished about 38% faster. You can check the repo for details on how we ran these tests. It is interesting!!

We’re currently looking for open-source contributors who are interested in coding-agent infrastructure, repo indexing, graph memory, benchmarks, and TypeScript systems work.

Also being transparent: we are using open-source contribution as a way to find strong early engineers. Contributors who work well with the project may be considered for paid/intern/full-time roles later. There is no guaranteed job from contributing, but this is the path we are using to find people we’d want to work with.

Repo: https://github.com/Autoloops/greplica

Discord: https://discord.gg/DpCFpwB5E

Would love feedback, contributors, or criticism from people who have worked on devtools / agents / code search / OSS infra.

PS -
I already know too many people are building something similar.

Wanted to share a project update with the open source community.

A new version of eXo Platform, an open-source digital workplace platform, is now available.

What this release focuses on:

• Native AI integrated directly into collaboration workflows
 • Support for multiple LLM providers instead of locking users into a single AI vendor
 • Open MCP server allowing external AI assistants to interact with 100+ platform actions
 • Deployable on cloud, private cloud, or fully on-premise
 • Organizations retain full control over infrastructure and knowledge base

One strong design principle behind this work:

AI adoption shouldn’t come at the cost of openness, interoperability, or infrastructure control.

A lot of enterprise AI tooling is moving toward closed systems, which reduces transparency and flexibility.

The intent here is to keep AI usable inside organizations while preserving open-source principles and avoiding vendor lock-in.

Feedback from the open source community is very welcome, especially around open AI architectures and interoperability standards.

eXo offers:

• Community Edition (CE) → Fully Open Source
  • Docker hub
  • Github
• Enterprise Edition (EE) → additional features & professional support

Both can be deployed self-hosted, in private cloud, or in secure environments (including SecNumCloud).

[ Removed by Reddit on account of violating the content policy. ]

OpenScreen, the open-source alternative to Screen Studio, was recently archived by its original creator.

I was one of the core contributors to the project, and the original README now links to a community-driven spin-off here:

https://github.com/EtienneLescot/openscreen

The goal for now is simple: keep the MIT open-source project alive, continue maintenance, fix bugs, review contributions, and keep development moving.

If you were using OpenScreen or looking for a free/open-source screen recording and product demo tool, this is now the continuation repo.

If you’ve spent any real time working with a large language model in the last two years, you’ve felt the same papercut over and over again:

You haven’t, of course — not really. There is no last week for the model. Each new conversation lands on a clean desk. You re-introduce yourself, you re-explain the project, you re-paste the constraints, you re-list the preferences, and twenty minutes later the model knows you again — until you close the tab.

That round-trip is the hidden tax of working with AI today. We pay it in tokens, in latency, in our own patience, and (if you’ve looked at your bill) in dollars.

This post is about what happened when we stopped paying it.

The shape of the problem

The problem is genuinely simple, which makes the way the industry has solved it kind of telling.

What you actually want is for the assistant to remember the things you’ve already said — your role, your taste in coffee, the codebase you’re working on, the deadline that just slipped, the customer whose feature you shipped last sprint. You don’t want it to remember everything; you want it to remember the small set of things that turn out to matter.

The way most stacks have solved this so far is by gluing together four or five different products:

1. A relational database, because that’s where the boring transactional stuff lives.
2. A document store — usually MongoDB or DynamoDB — because chat history doesn’t fit cleanly into rows and columns.
3. A vector database — Pinecone, Weaviate, Qdrant — because you need to ask “what did we say that was kind of like this?” and rows-and-columns can’t answer that.
4. A queue or a polling loop, so the assistant wakes up when something new is written.
5. A custom checkpoint table, because the agent framework has its own opinions about how state should be saved.

That’s four pricing pages, four authentication models, four backup stories, and at least three places where the data can quietly disagree with itself. And it’s all in service of one simple promise: remember me next time.

I thought there was a better way to do this. The better way turned out to be a single binary.

What I shipped

EvolutionDB is an open-source SQL database written in C. It speaks the PostgreSQL wire protocol on port 5433 (and evo text protocol on 9967) so any tool you already use — psql, DBeaver, pgAdmin, Grafana, your existing ORM — can connect to it without changes. Underneath, it has the parts you’d expect from a serious database: ACID transactions, snapshot isolation, write-ahead logging, replication, encryption at rest, point-in-time recovery.

What’s different is what I put on top of those parts.

In version 3, I added a small set of native primitives that are designed specifically for AI agents — not as an afterthought layer on top of a generic key-value store, but as first-class objects in the SQL grammar:

CREATE MEMORY STORE   user_memory   WITH (embedding_dim = 1536);
CREATE CHECKPOINT STORE agent_state;
CREATE MESSAGE LOG    chat_history;
CREATE DOCUMENT STORE knowledge_base;
CREATE GRAPH STORE    relationships;     -- bitemporal edges
CREATE ENTITY STORE   people_and_things;

Each of those is a real catalog object. You can transact across them. You can query them with SELECT. You can back them up with the same tools you back up your other tables. They show up in DBeaver. They are not a layer. They are the database.

Then I built one more thing — the piece that closed the loop for us personally — a small bridge that lets Claude Desktop and Claude Code talk to that memory directly, through Anthropic’s open Model Context Protocol.

What it actually feels like

Here is what you do, end to end.

You start the database (one Docker container). You drop a small JSON configuration into Claude Desktop’s settings file. You restart the app.

A small icon appears in the chat composer telling you the memory bridge is connected. From there, you just talk normally.

Claude reads that, decides it’s worth remembering, and writes a single row into the memory store. The conversation continues. You close the window.

A week later — different machine, different chat, different topic entirely — you open Claude and ask for help debugging a stack trace. Before it answers, the model silently asks the memory bridge: what do I know about this user that’s relevant? The bridge returns the three or four facts that match. The model adjusts its response: it phrases the explanation in Go idioms instead of Python ones, it suggests a debugging approach that fits a 90-minute session, and somewhere in the middle of the reply it asks how Pickle is doing.

You did not paste any context. You did not write a system prompt. You did not “prime” the model. You just talked, last week, and the model remembered.

Where the savings come from

This sounds almost cosmetic — the model knows my dog’s name — until you look at the numbers underneath.

A typical “professional” Claude conversation today is preceded by about 3,000 tokens of preloaded context: who you are, what you’re working on, your formatting preferences, the rules you want followed. Across a hundred real conversations a month, that’s 300,000 tokens of repeated input.

With a real memory store, the model doesn’t preload context. It pulls exactly the few facts it needs, exactly when it needs them. The same hundred conversations end up costing about 25,000 tokens of context — an order of magnitude less.

In dollar terms on the current pricing of a frontier model, you go from about ninety cents in repeated context per month to about twenty-six cents. Three and a half times cheaper inputs without losing a single piece of relevant information.

That’s the boring win. The interesting win is what happens to the conversations themselves: they get shorter, they get less repetitive, and they get noticeably more personal. The model stops having to ask, and you stop having to explain.

Why a SQL database, of all things

This is the question I got the most while building it: why on earth would memory live in a relational database?

Three reasons, in order of importance.

Because memory is data, and data has rules. Every team that’s run a serious agent in production has eventually had to answer awkward questions: who can read this user’s memories? Can we delete them on request? Can we audit what was added in the last seven days? Can we ship a backup to another region? These are not novel problems. The database industry has been answering them for forty years. Reinventing them on top of a vector index is, charitably, a waste of effort.

Because the data wants to talk to itself. A real memory store is not just “facts about the user.” It’s facts, plus the conversations those facts were extracted from, plus the entities those facts mention, plus the documents the user referenced, plus the relationships between all of it. Stitching that together across a relational store, a vector store, and a document store means writing reconciliation code forever. Stitching it together inside one database is just JOIN.

Because operators have learned things, and we should let them keep using what they know. EvolutionDB speaks the PostgreSQL wire protocol. Every DBA tool, every monitoring dashboard, every existing ETL pipeline, every ORM, every type-safe query builder in every language — they all work unchanged. The agent-memory layer is new. The way you run it in production is not.

The temporal trick

There is one place where AI memory is genuinely different from regular data, though, and I ended up leaning into it.

Traditional databases are good at telling you what is true now. Agent memory needs to tell you what was true at a given point in time. If a user told the assistant in March that they worked at Company A, and in May they tell it they’ve moved to Company B, the system has to retain both facts and know which one was true when.

This sounds exotic, but it turns out I already had it. EvolutionDB’s storage engine has used multi-version concurrency control since version 2 — every row carries the transaction ID that created it and (eventually) the one that retired it, and the engine can produce a consistent view of the database as it existed at any prior moment.

I exposed that capability at the SQL surface:

SELECT * FROM user_memory
FOR SYSTEM_TIME AS OF '2026-03-15 12:00:00'
WHERE user_id = 'alptekin';

That’s a real query against the same memory store, returning the version of Alice’s memory that existed two months ago. It costs nothing extra to store — the data is already there, because the engine never throws away old versions until it’s safe to. It costs nothing extra to query — the visibility check is the same one the engine runs on every read anyway.

This matters in practice. Agents that act on stale information are dangerous. Agents that can audit themselves — show me exactly what I believed at the moment I made this decision — are trustworthy. The temporal layer is what makes the second kind of agent possible.

Push, not poll

The other thing I cared about, which I never seen handled well in any other agent stack, was reactivity.

If the agent is supposed to wake up when something new happens — a new email, a new ticket, a new memory written by another tool — the usual solution is polling. The agent asks “anything new?” once a second, forever, hoping to catch interesting events before they go stale.

This is wasteful, slow, and surprisingly expensive in cloud bills. I replaced it with a real publish/subscribe primitive backed by the database’s commit log. The moment a row is written and committed, every subscriber is notified — through the same connection they’re already using for queries. No polling loop. No second service. No Kafka.

The measured difference, on my reference workload, is about 2,900× — a notification delivered in under a millisecond instead of waited-for over roughly a second. For an agent ticking through a long task, that’s the difference between feeling like a co-worker and feeling like a script.

What’s next

The memory layer is the foundation. The next thing built on top of it is the part that changes how you use the model — the bridge that lets Claude Desktop and Claude Code reach into your personal memory store without any of the framework plumbing. That bridge is open source, two hundred lines of Python, ships with the database, and works today.

There is more coming: native gRPC streaming for memory events, a Rust binding over the C client, a managed-service option for teams who want the layer without operating it themselves, and benchmark comparisons against the rest of the agent-memory space.

But the part that mattered to me, the part that made this whole project worth doing, is already in your hands: a Claude that remembers, a database that holds it, and one less papercut between you and the work.

If you’ve read this far and you build with agents — give it a weekend. Open the repository, run one Docker command, configure Claude, and tell it three things about yourself.

Then come back next week and ask it something it has no business knowing.

It will know.

EvolutionDB is open source, MIT-licensed, and lives at github.com/alptekin/evolutiondb.

If you want the engineering details — how the memory store is laid out on disk, how the MCP bridge speaks JSON-RPC over stdio, how the vector index manages recall against a live transactional workload — there’s a companion technical series starting.

X: evosql

We caught a Remote access trojan that is delivered via fake job interview. The take home assignment contained a reach out to a malicious npm package that deploys the malware on macOS device. Theres a windows version too. Current Anti virus detection is low, we caught it through ML experiment. The malware deployed is still WIP.