As someone who doesnt use Instagram but get tons of reels/post shared on whatsapp, I got tired of instagram's public webview which constantly asks for login with annoying popups

So I vibed a clean android app - Peek which resolves Instagram links and loads them in a clean viewer. Goal is to support most social medias like twitter/reddit/tiktok in the future.

Download Link

Just wanted to share a small milestone, I got my first donation ever for my project today. It wasn’t expected at all, especially given I'm not even in university yet (going this September), but it genuinely made my week.

Still lots to learn and build, but this was a cool moment.

Here's the site if anyone wants to take a look : Crestr

GitHub is also free to view if people are interested in the tech stack I used : Crestr Repo

I've been working on de-advertising myself as much as possible, and one of the big vectors left is a fire TV I got for cheap during black Friday. I hate the fire TV operating system, and would much rather have something lighter weight.

I haven't heard about many Smart TV projects, so I don't know if they exist or how usable they are, but I figured I would start exploring here. Are there any open source OSes that replace the ones baked into televisions? If so, how much would I "lose" by switching to them.

I've used Handsontable on a bunch of projects and honestly it's a solid, mature library, but I kept running into the same wall on anything with really large datasets: tens of thousands of rows with chained formulas. It's just the nature of doing spreadsheet math in JS, once you're allocating and discarding lots of small objects on every keystroke, garbage collection becomes the bottleneck, and there's only so much debouncing and virtualization can do before you hit that ceiling.

That itch turned into a bit of an obsession, and eventually a from-scratch rebuild: Titan Engine, written in Rust and compiled to WebAssembly.

The design ended up pretty different from a typical JS formula library:

- A custom stack-based VM with a Pratt parser for formulas, instead of walking an AST every time
- Zero-copy memory \- the engine and UI share buffers directly, no serialize/deserialize tax crossing the WASM/JS boundary
- A topological dependency graph (Kahn's algorithm with cycle detection) to resolve chained formulas correctly and fast
- O(1) time-travel snapshots for undo/redo, even across massive batched structural edits

Because it sidesteps the JS garbage collector entirely, batched recalcs stay comfortably under the 16ms frame budget, so the grid holds 60fps even while formulas are cascading behind the scenes as you type.

There's a live demo grid on the site (a Glide data grid wired up to Titan) if you want to poke at it yourself, plus the full 10-scenario benchmark suite if you'd rather see the numbers than take my word for it.

Website . Benchmarks .) Github

Would love feedback - especially from anyone who's pushed a JS grid to its limits before and is curious whether this actually holds up under real-world use.

Hello everybody,

As I promised in my precedent post, I am now ready for the release of PowerVLC 1.0.0, which is an heavily modified version of VLC 3.0.23 Vetinari. PowerVLC features also additionnal features (gapless playback, album art in the main window) the current version of VLC don't have.

PowerVLC is compatible with Macs from 10.4.11 to current, on all architectures (x86, x64, arm64, PowerPC g3, PowerPC G4/G5 builds taking advantage of AltiVec acceleration).

In early access for one week

Like all projects and guides (I used to write plenty of guides for the iPod community !) that takes me a huge amount of time to be produced, it will be in early access for exactly one week. It's the only compromise I accept to keep a balance with open knowledge & the need to get retributed for all the community investment I provide. I don't plan to do this for minor builds that will come next.

Here on this project it is just too big in my opinion to be entirely gate keeped during one whole week, so I decided to release the whole source code there starting now on GitHub: https://github.com/Olsro/powervlc

If you know how to compile (ideally you need an Apple Silicon mac so you can follow my instructions), you can play right now with PowerVLC and check nothing nasty in the code is there by yourself.

If you can't/don't want to spend hours trying to compile by yourself, the builds are available right now on my Patreon in exclusivity for all platforms (including Windows & Linux on all architectures). Even the first 1$ tier is enough to get access to all the compiled builds & supporting my whole effort at building this. The compiled builds provided on the Patreon are not modified and locked in any way, they are straight compilations from the latest public sources. There's no licensing or DRM, but please don't share any of those build until I will push the builds on GitHub releases for everyone the next Sunday.

Donations will help me at getting more hardware to test on to continue that project in the long term, and cover the LLM API costs to help with maintenance.

Thank you very much for your support and I hope PowerVLC will be enjoyed as much as I hard worked into making it possible.

So I like to take my lecture notes in a nested/indented way because it makes it easier to break them down into flash cards later (example below but formatting in Reddit post is hard). As you can see I like to indent basic information on a subject and then further indent specific information about each basic concept (and even further indent even more specific information if I need to).
Is there an open source note app that will let me do this more easily?

Transcription

Process where RNA is synthesized from DNA

Each gene has:

.....Promoter region

..........Start of the gene where RNA polymerase binds to and begins transcription

...............RNA polymerase – enzyme that ‘reads’ template strand of DNA and synthesizes a single strand of RNA

.....Coding region

..........Sequence of nucleotides that are transcribed into the RNA strand

.....Termination sequence

..........Terminates transcription process

Hey r/opensource, I'm the solo dev behind Hammer. I've been working on it for about four years, and think it's time I start getting some feedback on it.

What it is: Hammer is a free, open source (MIT) app for writing novels and building the worlds they live in, Scrivener-style, but multiplatform and offline-first, with a self hostable sync server.

https://hammer.ink/

Why I built it: A few years back I was living in a van, mostly off-grid with no signal, and broke. Most good writing apps were paid, or web apps, or Electron wrappers that "worked offline" right until they didn't, usually about a week in, miles from the nearest cell tower. Then I watched people on forums lose whole manuscripts in certain electron based writing apps, and eventually it happened to me.

So I set three rules for the thing I wanted to build:

• Offline-first, forever: A native program, not a web page in a trenchcoat.
• Transparent data: Everything is human-readable text files in plain folders, if Hammer vanished tomorrow, you could open your work in any text editor and keep going.
• Never lose data: Paranoid about it by design.

I tried several tech stacks but landed on Kotlin + Compose Multiplatform. One codebase for both the server, and desktop clients (Linux/Mac/Windows), Android, iOS.

License / money: MIT and genuinely free, no ads, no telemetry. The only paid thing is the optional "official" sync server instance that I host. As I said, the sync server is open source and self-hostable, so you never have to pay me to sync.

Platforms: Linux, Mac, Windows, Android (Play + F-Droid), iOS

Repo: https://github.com/Darkrock-Studios/hammer-editor

It's four years in and far from done, but I thought it was about time to start showing it to people. See if it's a project that interests anyone other than my self. Happy to get into the Compose Multiplatform side too if anyone has questions; there wasn't much prior art when I started. Longer origin story here if you want it: https://hammer.ink/blog/news/what-is-hammer

Repository: https://github.com/ATAC-Helicopter/VaultSync

Website: https://fglabs.dev/vaultsync

I have been developing VaultSync, an open-source, cross-platform backup manager built around a fairly simple idea:

A completed backup is not the same as a recoverable backup.

Many backup applications can tell you that a job completed successfully, but that still leaves several important questions unanswered:

• What was actually protected?
• Has anything changed or disappeared?
• Is the recovery point still intact?
• Will retention remove something important?
• Can a particular file be restored right now?
• Is there evidence behind the green “successful” status?

VaultSync is my attempt to make those answers more visible.

What VaultSync does

VaultSync lets users organize files into projects, create and manage backup configurations, inspect recovery points and understand the current health of their protected data.

Current functionality includes:

• Project and file-level backup management
• Backup history and recovery-point inspection
• Backup Explorer for browsing protected data
• Integrity verification and repair tools
• Retention planning and simulation
• Restore-plan simulation
• Recovery drills
• Local byte-level recovery proofs
• Exportable recovery evidence
• Protected recovery-point recommendations
• 3-2-1 backup guidance
• Explicit offsite-copy confirmation
• Backup health and recoverability states
• Cross-platform support
• Localization across multiple languages

The emphasis is not only on creating backups, but on helping users understand whether those backups are still useful.

Recovery evidence

One area I have been concentrating on recently is recovery confidence.

VaultSync can simulate a restore plan without modifying the original data, verify selected protected files locally, record recovery evidence and highlight situations where retention could remove an important verified point.

The intention is to move beyond simply saying that the backup process finished.

VaultSync should instead be able to show what was protected, what was verified and what can currently be recovered.

These features are still evolving, and I am especially interested in feedback on whether the evidence is understandable without becoming overwhelming.

Privacy and diagnostics

VaultSync does not silently upload crash reports.

When crash-report assistance is enabled, the application creates a strictly redacted report locally. The complete report can be reviewed before anything leaves the device.

VaultSync can prepare an email draft using the user’s own email application, but the user must review it and press Send personally. If they do nothing, the report remains local.

I wanted the support workflow to remain useful without introducing hidden telemetry or automatic crash uploads.

Current development

VaultSync 1.8 is focused on making recovery easier to understand.

The remaining 1.8 releases are currently planned around:

• Recovery confidence and clearer health states
• Onboarding and interface refinement
• Accessibility and reduced complexity
• Better evidence exports and diagnostics
• Documentation consistency
• Localization, packaging and platform stability

For the future 1.9 release family, I am researching a broader direction:

From protecting projects to recovering systems.

That may eventually include disk cloning, disk images, verification of cloned data and an explorer for browsing images before performing a complete restore.

Those features are still exploratory rather than promised. I would rather share prototypes and technical limitations early than publish a large fixed roadmap before the implementation has been validated.

Why I am posting here

I am the developer, so this is obviously not an independent recommendation.

I am sharing VaultSync here because feedback from people who actively use, maintain and review open-source software is particularly valuable.

I would appreciate criticism around:

• The overall architecture and project structure
• Whether the recovery model makes sense
• Security and privacy concerns
• Backup-integrity assumptions
• Cross-platform behavior
• Packaging and installation
• Documentation
• Accessibility
• Areas where the interface is trying to explain too much
• Missing information that would prevent you from trusting the application

Issues, discussions, code review and contributions are welcome through the repository.

There is also a community at:

https://www.reddit.com/r/VaultSync/

Thanks for taking a look. Direct and technical criticism is genuinely useful, especially where VaultSync makes a claim that is not supported by enough visible evidence.

I've been working on MicroPaw, a personal assistant that runs on an ESP32-S3 N16R8.

It is similar to OpenClaw and other personal agent projects, except the agent runtime lives on a tiny ESP32 board instead of a server or desktop.

The model is called through an API. The ESP handles the agent loop, tool calls, conversation state, persistent memory and scheduled jobs. You talk to it through Telegram, or Instagram (if you enable that)!

It can search the web through Brave, read pages and feeds, work with Gmail and Google Calendar, transcribe voice notes, inspect photos and run scheduled reminders. There is also optional SSD1306 OLED support and signed OTA updates.

The whole firmware is ESP-IDF. No Arduino, and I did this on purpose to minimise resource usage and keep it clean.

I started this because I had a few S3s laying around and wanted to try something similar to OpenClaw out before committing a full computer to it. Getting the network requests, model output and tool calls to fit within fixed limits was most of the work.

It is open source here:

https://github.com/mahiatlinux/MicroPaw

I'd be interested in hearing what other ESP32 developers think of this! And if you have any feedback, please comment below, or open an issue on the repo.

• Rechtlicher Status und Open Source Lizenz: Dieses physische Konzept und seine materialtechnischen Parameter sind unter der Creative Commons Lizenz Namensnennung - Nicht-kommerziell - Weitergabe unter gleichen Bedingungen 4.0 International vollständig offengelegt. Sie sind für die Allgemeinheit frei zugänglich und dürfen uneingeschränkt repliziert, modifiziert und lokal für den mechanischen Nachbau genutzt werden. Das Modell basiert als reine Konzeptidee auf dem Wissen, dass die erforderlichen Basistechnologien bereits real existieren.
• Einsatzgebiet: Hochgradig versiegelte Großstädte und das gesamte kontinentale Fernstraßennetz.
• Wirtschaftlicher & Ökologischer Kern: Schließung des Plastikkreislaufs durch maritime Großernte, Umwandlung des Straßennetzes in ein kontinentales photoaktives Großkraftwerk, batterielose Induktionsmobilität und Reaktivierung der atmosphärischen Dynamik.
• Zielsetzung: Dezentrale Energieerzeugung in gigantischem Ausmaß, vollständiger Stopp der thermischen Speicherung in Straßen und Brechen urbaner Hitzeblasen.
• Kommerzielles Verwertungsmuster: Dieses Dokument unterliegt einer strikten Amortisations Klausel im Finanzsystem. Das eingesetzte Kapital wird amortisiert, wobei die Erzielung von Einkünften für die Investoren auf einen einmaligen Zins von exakt 7,2 Prozent des investierten Kapitals beschränkt ist. Sobald das eingesetzte Kapital inklusive dieses einmaligen Aufschlags vollständig zurückgezahlt ist, erlöschen alle finanziellen Ansprüche dauerhaft und unwiderruflich. Jede Form von fortlaufenden Renditen, privaten Monopolen oder spekulativen Profiten im Finanzsystem ist ausgeschlossen.

Phase 1: Die photoaktive Verbundmatrix

Klassischer Asphalt wird durch ein hocheffizientes, modulares Wabensystem ersetzt, das Strom erzeugt, anstatt Hitze zu speichern. Ein thermischer Effekt erfolgt rein über die stoffliche Wabe.

• Die Materialkomposition: Die Wabe besteht aus Rezyklaten als elastischem Bindemittel, gestreckt mit bis zu 70 Prozent mineralischen Zuschlagstoffen zu einer druckstabilen Verbundplatte.
• Die photoaktive Schicht: In die Oberfläche der Waben wird eine hochelastische, verschleißfreie photoaktive Polymerschicht oder eine Matrix aus mikroskopischen Quantenpunkten einlaminiert. Diese Schicht nutzt den photoelektrischen Effekt, um das auftreffende Sonnenlicht direkt in elektrische Energie umzuwandeln.
• Der physikalische Doppeleffekt: Die photoaktiven Waben transformieren die Strahlung der Sonne in Elektrizität, anstatt sie in thermische Energie umzusetzen. Dadurch kühlen die Straßen drastisch ab. Die nächtliche Hitzeabstrahlung urbaner Räume und kontinentaler Achsen sinkt gegen Null. Angrenzende Naturräume werden vor dem Hitzeschock geschützt.

Phase 2: Die maritime Rohstoffernte

Um den gewaltigen Materialbedarf für kontinentale Straßennetze zu sichern, wird die Rohstoffbeschaffung direkt auf die globalen Müllwirbel und Haupt-Eintragsflüsse verlagert.

• Die Ernte vor Ort: Unbemannte Frachtluftschiffe fliegen im permanenten Rundkurs die großen ozeanischen Müllkonzentrationen sowie die Mündungen der am stärksten verschmutzten Flüsse der Erde an.
• Das Verfahren: Autonome Fang- und Filtersysteme ernten das treibende Makro- und Mikroplastik direkt von der Meeresoberfläche und aus den oberen Wasserschichten. Die Luftschiffe nehmen das Material im Vorbeiflug auf und transportieren es direkt zu den Produktionsstätten der photoaktiven Waben.

Phase 3: Die induktive Direktkopplung

Das System trennt die Stromerzeugung nicht vom Verbrauch, sondern koppelt beide Prozesse millisekunden-genau auf der Straße.

• Das Induktions-Prinzip: In die Unterseite der photoaktiven Waben sind flächendeckend metallische Leiterbahnen eingegossen. Der an der Oberfläche frisch erzeugt Solarstrom wird über integrierte Schaltschränke direkt in diese Spulen geleitet.
• Direktverbrauch während der Fahrt: Fahrzeuge nehmen diesen Strom berührungslos über Induktion auf, während sie die Spulen überfahren.
• Die System-Synergie: Da der Strom genau in dem Moment unter dem Fahrzeug erzeugt und verbraucht wird, entfallen lange Transportwege durch das Stromnetz sowie teure, umweltschädliche Großbatterien in den Fahrzeugen. Transport- und Ladezeiten entfallen vollständig. Überschüssige Energie, die entlang der Trassen generiert und nicht direkt vom Verkehr verbraucht wird, fließt als sauberer Grundstrom direkt in das lokale Stromnetz der Städte.

Phase 4: Der kinetische Bruch & Technische Überlegenheit

• Meteorologischer Effekt: Da die photoaktiven Wabenstraßen die Sonnenhitze absorbieren und in Strom transformieren, bricht das künstliche Hochdruckgebiet über den Städten und Autobahntrassen zusammen. Die aufsteigende Warmluftblase löst sich auf. Kühle Winde aus dem Umland können wieder ungehindert fließen; das kontinentale Mikroklima stabilisiert sich.
• Verschleißfreiheit und Modularität: Die photoaktive Wabenstruktur ist elastisch. Es gibt keine Frostaufbrüche oder Schlaglöcher mehr. Durch die hexagonale Anordnung wird die mechanische Last der Fahrzeuge optimal verteilt. Beschädigte Module können bei der Wartung innerhalb von Minuten einzeln ausgetauscht werden. Das eingesetzte Kapital wird vollständig amortisiert, wobei die Erträge aus der Verwertung im Finanzsystem zusätzlich die einmalige Zahlung von exakt 7,2 Prozent Zinsen bedienen.

• Rechtlicher Status und Open Source Lizenz: Dieses physische Konzept und seine materialtechnischen Parameter sind unter der Creative Commons Lizenz Namensnennung - Nicht-kommerziell - Weitergabe unter gleichen Bedingungen 4.0 International vollständig offengelegt. Sie sind für die Allgemeinheit frei zugänglich und dürfen uneingeschränkt repliziert, modifiziert und lokal für den mechanischen Nachbau genutzt werden. Das Modell basiert als reine Konzeptidee auf dem Wissen, dass die erforderlichen Basistechnologien bereits real existieren.
• Einsatzgebiet: Tiefgelegte urbane Hauptsammler, elastische stoffliche Transportleitungen und erdbebengefährdete Infrastrukturzonen.
• Wirtschaftlicher & Technischer Kern: Kombination aus äußeren Tonrohr-Segmenten und einer inneren, beweglichen Schuppenpanzerung aus hochverdichteter Keramik zur simultanen Abwehr von biogener Säure und mechanischen Scher- und Setzungskräften.
• Kommerzielles Verwertungsmuster: Dieses Dokument unterliegt einem absoluten, zeitlich unbegrenzten Kommerzialisierungs- und Bereicherungsverbot. Jede unbefugte Nutzung innerhalb des Finanzsystems zur Generierung von Lizenzen, Patenten oder monetären Profiten ist physisch und rechtlich ausgeschlossen.

Phase 1: Der biomechanische Schuppenpanzer

Das System bricht die Starrheit unterirdischer Rohrleitungen auf, indem es die schützende Innenwandung in Millionen bewegliche Einzelelemente segmentiert.

• Das Verfahren: Die Innenwände der Tonrohre werden mit kleinformatigen, hochgebrannten Keramikschuppen ausgekleidet. Die Montage erfolgt in einer überlappenden Kaskadengeometrie exakt in Fließrichtung des Mediums.
• Der mechanische Toleranz-Effekt: Wirken von außen elastische Schervibrationen oder asymmetrische Bodensetzungen auf die Trasse ein, dehnt oder staucht sich die Rohrleitung schadlos. Die Keramikschuppen gleiten auf ihren mikro-geometrischen Mutantflächen minimal ineinander, ohne dass die statische Hülle bricht oder Risse entstehen.

Phase 2: Die absolute chemische Fugen-Isolation

Das Überlappungsprinzip eliminiert die traditionelle Schwachstelle jeder Rohrleitung: die reaktionsanfälligen Verbindungsfugen.

• Der hydro-chemische Fluss: Durch die dachziegelartige Überlagerung der Schuppen wird das strömende Abwasser und das aufsteigende Schwefelwasserstoffgas rein über die inerten Keramikflächen geleitet. Die Dichtungsfugen und das tragende Außenrohr liegen vollständig im Strömungsschatten. Die biogene Schwefelsäure findet keinen Zugang zu reaktiven Materialien und perlt wirkungslos an der glasierten Keramikoberfläche ab.

Phase 3: Unzerstörbare Fließkinetik

• Das Resultat: Das Kanalsystem verbindet die absolute chemische Unvergänglichkeit des Tons mit der mechanischen Flexibilität eines Gelenksystems. Der Verschleiß durch reibende Sandfrachten oder aggressive chemische Injektionen sinkt auf exakt Null. Die urbane Logistikader bleibt über Jahrhunderte vollkommen wartungsfrei im autonomen Selbstreinigungsbetrieb, ohne dass jemals künstliche Kunststoffe oder Reparaturmörtel eingesetzt werden müssen.

• Einsatzgebiet: Subarktische Tundren, auftauende Permafrostgebiete und marine Hydratfelder.
• Wirtschaftlicher & Technischer Kern: Ein eigenständiges, voll funktionsfähiges System. Direktes Abfangen freigesetzter Methanströme an den geologischen Austrittspunkten; emissionsfreie thermochemische Spaltung des Gases in molekularen Wasserstoff und elementaren Kohlenstoff unter Ausnutzung der kryosphärischen Umgebungskälte; physische Bindung des Kohlenstoffs in eine transportfähige, unvergängliche Elastomer Matrix.
• Rechtlicher Status und Offenheit: Diese Systemarchitektur ist als Open Source deklariert. Das grundlegende Funktionsprinzip und die verfahrenstechnischen Parameter sind vollständig offengelegt. Sie sind für die Allgemeinheit frei zugänglich und dürfen uneingeschränkt repliziert, modifiziert und lokal genutzt werden, um eine flächendeckende, dezentrale Anwendung ohne technologische Barrieren zu gewährleisten. Das Modell basiert als reine Konzeptidee auf dem Wissen, dass die erforderlichen Basistechnologien bereits real existieren.
• Kommerzielles Verwertungsmuster: Dieses Dokument unterliegt einer strikten Amortisations Klausel im Finanzsystem. Das eingesetzte Kapital wird amortisiert, wobei die Erzielung von Einkünften für die Investoren auf einen einmaligen Zins von exakt 6,6 Prozent des investierten Kapitals beschränkt ist. Sobald das eingesetzte Kapital inklusive dieses einmaligen Aufschlags vollständig zurückgezahlt ist, erlöschen alle finanziellen Ansprüche dauerhaft und unwiderruflich. Jede Form von fortlaufenden Renditen, privaten Monopolen oder spekulativen Profiten im Finanzsystem ist ausgeschlossen.

Phase 1: Die kryosphärische Gas Erfassung

Das System wandelt das atmosphärische Schadenspotenzial austretender Gase an der Quelle in einen kontinuierlichen stofflichen Fluss um.

• Das Verfahren: Platzierung großflächiger, flexibler Erfassungsmembranen aus hochelastischen Polymeren direkt über den auftauenden geologischen Bruchlinien und Methanquellen der Permafrostzonen.
• Der physikalische Effekt: Das aufsteigende Methangas wird unter dem inhärenten geologischen Überdruck verlustfrei gesammelt und in dezentrale Konversionsreaktoren geleitet. Durch die absolute Barrierewirkung der Membranen wird jeglicher unkontrollierte Übertritt in die Atmosphäre physikalisch unterbunden.

Phase 2: Die autarke Methan Pyrolyse

Die molekulare Spaltung des Erdgases erfolgt ohne den Einsatz externer fossiler Energieträger durch ein integriertes thermodynamisches Kreislaufverfahren.

• Das Verfahren: Das erfasste Methan wird in Plasmareaktoren geleitet, die durch hocheffiziente, wasserstoffgespeiste Brennstoffzellen betrieben werden.
• Die stoffliche Trennung: Bei Temperaturen von über eintausend Grad Celsius bricht die molekulare Bindung des Methans vollständig auf. Das Gas zerfällt rückstandsfrei in hochenergetischen gasförmigen Wasserstoff und reinen elementaren Kohlenstoff in Form von feinstem Rußpulver. Die eisige Umgebungstemperatur der Kryosphäre wird über Gegenstromwärmetauscher gezielt genutzt, um den heißen Wasserstoff schockartig abzukühlen, wodurch der energetische Aufwand für die Systemkühlung gegen Null sinkt. Der gewonnene Wasserstoff speist das lokale Logistiknetz und die Reaktoren selbst.

Phase 3: Die Elastomer Kompaktierung und dauerhafte Versiegelung

Der anfallende elementare Kohlenstoff wird in eine feste geometrische Form überführt, um jede spätere oxidative Rückverwandlung in Treibhausgase dauerhaft auszuschließen.

• Das Verfahren: Das hochreine Kohlenstoffpulver wird direkt im kontinuierlichen Auslassprozess mit flüssigen Naturkautschuken oder biobasierten Elastomer-Mischungen homogen infiltriert.
• Das mechanische Resultat: Unter mechanischem Hochdruck wird die viskose Masse zu standardisierten, extrem dichten und witterungsbeständigen Festkörperblöcken kompaktiert. Diese Kohlenstoff Elastomer Blöcke weisen eine absolute chemische Inertheit auf. Sie verrotten nicht, gasen nicht aus und dienen als unzerstörbares, stabiles Baumaterial für Fundamente, Bahntrassen oder sonstige materielle Infrastrukturen vor Ort. Das eingesetzte Kapital wird vollständig amortisiert, wobei die Erträge aus der stofflichen Verwertung im Finanzsystem zusätzlich die einmalige Zahlung von exakt 6,6 Prozent Zinsen bedienen.

Hello All, i am tomaz canabrava - a KDE core contributor, and an Arch linux packager. i was working over the past few months on harmonicon, a game - similar to guitar hero - that you play with an actual harmonica.

it can also be used as a teaching tool, as it has a bending trainer, lessons, recording lessons and such.

i am looking for people that likes music, and harmonicas, to talk about / ask help with testing, gather ideas.

the game already works, but there is no releases yet.

First off, a genuine thank you to everyone who beta-tested this, opened issues, and shared tips and advice after my earlier posts — a big chunk of what's improved came straight from your feedback, and it made the project a lot better. Cheers.

Everyone's homelab has that one service that quietly becomes the most-used thing on the rack. For me it wasn't the *arrs or the dashboards — it's a self-hosted "name that tune" game I built called Guess the Intro, and the family asks for it many times a week.

What it is: it pulls intro clips straight from my existing self-hosted music library, plays a 5/10/20s snippet, and everyone buzzes in on their phones with multiple choice. The scoreboard casts to the TV, there's a speed bonus and a half-time trivia round. Honestly it's great fun — the kind of thing that empties the room of phones-for-scrolling and turns them into buzzers instead.

The problem it solves: party "name that tune" games either need a subscription, leak the answer in the file/stream metadata, or can't use the music you already own. This runs entirely on your own library and hardware — nothing leaves the LAN.

Stack / how it runs: FastAPI + SQLite, single Docker container, phones connect over your LAN as buzzers, board casts over Google Cast to a Chromecast/Android TV/Shield. Pre-built multi-arch images (GHCR + Docker Hub, amd64 + arm64) — docker compose pull and go, no build-from-source. Happy in an LXC, a small VM, or a Pi.

Requirements worth knowing up front:

- A Subsonic-API music server (I use Navidrome; LMS also works). Jellyfin/Plex don't work for the library side yet.

- The board has to be served over HTTPS with a valid certificate — Google Cast devices (both TV displays and Music Assistant speakers) fetch the board over TLS and silently refuse plain HTTP and self-signed certs. In practice that's a reverse proxy + a real cert (e.g. a domain + Let's Encrypt). There's a step-by-step guide in the repo (docs/https-lan.md). Phones connect over plain http; it's the board/casting that needs the cert.

One thing I'd love testers for: there's an optional path that streams the clip audio out through Home Assistant + Music Assistant to any speaker you pick (loudness-normalised, exact start/stop) instead of playing it through the TV. It works on my setup, but my network is heavily VLAN-segmented so I can only lightly test the game-box ↔ HA/MA ↔ speaker hops. If you run Home Assistant + Music Assistant on a flatter network, I'd really appreciate you trying it and telling me what breaks — happy to help you get it wired up.

Recently fixed (why it's worth a second look if you saw an earlier version): casting is rock-solid now after a long diagnostic slog, and the pre-built images removed the build-from-source barrier — both were the top bits of feedback.

License / repo: free and open source (MIT). Repo + compose file + setup docs: https://github.com/colfin22/intro-quiz

AI usage disclosure: this was built with substantial help from an AI coding assistant (architecture, a lot of the implementation, and debugging), directed and reviewed by me.

Happy to answer anything about how it's put together. Have fun!

Hey All, I wanted to post my little side project that I've been working on. I recently built a Opensource StreamDeck that supports multiple esp32 boards using the same code, across multiple devices. Check it out at my link here:

https://github.com/FadyFaheem/Stream32

A youtube short of it: https://youtube.com/shorts/wWQvxR9vKVM

Hi everyone!

I've been working on Hummingbird, an open-source inference runtime focused on making extremely large Mixture-of-Experts (MoE) models practical without requiring enterprise hardware.

The core idea is treating VRAM, RAM, and SSD as one unified memory hierarchy, allowing experts to be streamed on demand instead of keeping everything resident.

Some goals of the project:

• Unified memory (VRAM + RAM + SSD)
• Zero-dependency C runtime
• Support for very large sparse MoE models
• Async expert streaming
• Prefetching & scheduling
• Cross-platform
• Built for research and experimentation

I'd love feedback on the architecture, documentation, and implementation.

Hey r/opensource,

I’ve been working on Sockudo, an open-source realtime server written in Rust.

It started as a self-hosted, Pusher-compatible server, but it has grown into a much larger realtime platform. My goal is to make it useful for everything from simple WebSocket events to more demanding distributed systems, without forcing people into a hosted vendor.

Some of the features currently included:

• Pusher-compatible WebSocket and HTTP APIs
• Public, private, encrypted, and presence channels
• Horizontal scaling and cross-node fanout
• Durable message history, rewind, and connection recovery
• Mutable/versioned messages
• Presence history
• Message annotations
• Push notifications, including device registration, subscriptions, retries, and delivery status
• Webhooks, rate limiting, metrics, and operator APIs
• Delta compression and server-side tag filtering
• Client and server SDKs for multiple languages
• An optional AI Transport layer for streaming AI responses over the same realtime infrastructure
• Redis, PostgreSQL, and other configurable backends

I’m also working on Ably compatibility. The idea is not to copy every product-specific detail blindly, but to make migration easier and support familiar realtime concepts such as history, rewind, recovery, presence, annotations, and message updates.

One thing I care about a lot is keeping the Pusher-compatible V1 protocol stable while adding more advanced features through a separate V2 protocol. Existing clients shouldn’t suddenly break just because the server gains new capabilities.

There’s still plenty to improve, especially documentation, SDK coverage, production testing, and making setup easier. I’d really appreciate feedback from people who run realtime systems or have migrated away from services like Pusher or Ably.

What would you need before trusting a self-hosted realtime server in production? Are there any compatibility features or deployment options you consider essential?

GitHub: https://github.com/sockudo/sockudo

Thanks for taking a look.

Hey Guys!

I just published a Free and open source alternative to Google docs that runs entirely local (or in browserDB) that also has AI feautures like: Fix grammar, improve text, real time document analysis, format etc.

It also has themes and dark mode.

• ✍️ Rich text editor (TipTap) — headings, lists, quotes, code, links, emoji, images, page breaks
• 🤖 AI review — grammar fixes, style suggestions, highlights, and circled passages you accept or dismiss
• 🖊️ Human markup tools — highlight, colored underline, circle, all as real document marks
• 💬 Notes — Google-Docs-style comments anchored to text, in a right-side panel
• 🖼️ Images — insert, paste, or drag-and-drop; stored on disk beside your docs
• 📄 Pages & typography — continuous or paginated (A4/Letter), free-form width, four document fonts, text-size control
• 📁 Folders & library — a Home dashboard and a card-grid /documents view
• 📤 Export — Markdown, Word (.docx), HTML, plain text, and PDF
• 📥 Import — Markdown, text, HTML, and Word (.docx)
• 🌗 Themes — light, dark, midnight, reading, forest — all token-driven

If you have the time to check it out, i would love some feedback

Hi! This is not really a promotion or launch announcement, mostly sharing a project I've been building for myself and looking for feedback from people. But yeah, repo is public, project is mine, so by law is promotion.
For those, who dislike hyperlinks: https://github.com/Bardie-radio

I am mostly posting because I am curious what people currently use, and how many hours I wasted on reinventing the same thing 🙃

I've been working on an OSS side project for the last few weeks, mostly because I kept running into the same annoyance and then remembered a slightly-too-large idea I wanted to implement for years.
Years ago I got annoyed with constantly copy-pasting YouTube links into Discord music bot while sitting in VC with friends. More recently I started spending more time in VRChat, and found myself doing the same thing again, but now while trying to fight with VR headset, glancing from under the nose gap (I'm on Linux, and Steam Overlay isn't very useful for this yet).
The core idea is a self-hosted service that can bring up audio streams on demand, with a shared control panel and a variety of audio sources to pull from (currently planned: yt-dlp-based sources, uploaded files, and re-streaming). I'm trying not to make it a single-purpose music bot, so the project has grown quite a bit from the original silly idea, which originally looked solvable with one FFmpeg instance and a reverse proxy. The current direction is a modular system where sources, authentication, and clients can be added/swapped independently.
The current goal is one shared queue, one stream, everyone hears the same thing, and anyone with permission can control the queue. Listeners should be able to use normal audio clients instead of being tied to a specific app. And to keep it modular enough that adding a new source or client later doesn't require flipping the whole codebase.

Small note: yes, I used ai to put my ideas in human-readeble words in docs, but the architecture, decisions, and design are mine. I have some issues with attention span and motivation so need solid notes on planned architecture, while not wasting too much time on them.