The best Hacker News stories from Show from the past day
Latest posts:
Show HN: Certo – An open source platform to deliver Open Badges
Certo is open-source infrastructure for issuing, managing, verifying, and exchanging digital credentials.<p>It implements Open Badges 3.0[1] and W3C Verifiable Credentials[2] which are the open standards that make credentials portable, machine-verifiable, and vendor-independent.<p>It is designed to be:<p>- Self-hosted: run it inside your own infrastructure, air-gapped network, or sovereign cloud
- Standards-compliant: credentials it issues work with any OB3/VC-compatible system
- API-first: everything the UI can do, the API can do
- Exportable: your data is always yours, in open formats
- Extensible: a small, stable core with a plugin interface for everything else<p>A demo is available at <a href="https://certo.schroedinger-hat.org/" rel="nofollow">https://certo.schroedinger-hat.org/</a> which we're using for Schrödinger Hat[3] conferences, workshops, partner communities.<p>I'll be around if you have any questions. Feel free to give a feedback on the project.<p>[1] <a href="https://www.imsglobal.org/spec/ob/v3p0" rel="nofollow">https://www.imsglobal.org/spec/ob/v3p0</a>
[2] <a href="https://www.w3.org/TR/vc-data-model/" rel="nofollow">https://www.w3.org/TR/vc-data-model/</a>
[3] <a href="https://schroedinger-hat.org/" rel="nofollow">https://schroedinger-hat.org/</a>
Show HN: A free DOCX editor with MCP server for editing
Show HN: Rotating torus in terminal (but with kitty graphics protocol)
Hi HN,<p>I'm taking Computer Graphics @ Stanford this summer and wanted to express some very simple concepts I had in mind. That's why I wrote a rotating torus in C. Going from writing a ray-tracer that works in Blender to pure C with no dependencies feels relaxing. Wanted to try Kitty Graphics Protocol on the way, rendering images in terminal felt cool.<p>Open to comments and suggestions.
Show HN: Sign language translation with smart glasses
Hi!<p>I have relatives that speak sign language, and always found it odd that despite unbelievable advances in AI in recent years, the problem still felt somewhat neglected.<p>Especially with the advent of wearable tech; to my knowledge, this is the first project that integrates the meta glasses w/ fingerspelling translation software.<p>As for the technical aspect, I trained a neural net on Google's FSboard dataset modeling a CNN + GRU temporal encoder architecture (trained with CTC), and then decoded the output with CTC beam search and a KenLM language model to solve some of the deficiencies with my model.<p>I've also made it cross-platform (web + iOS, with both web screen sharing and the ability to use non smart-glasses). The project is entirely FOSS.<p>I'm currently working on making the on-device model work cleanly, but unfortunately performance takes a bit of hit on lower-end devices so for now I've opted for hosting the model on Modal.<p>There's so much room for improvement, but I'm happy with this starting point. Let me know what you think, and check out the YouTube demo!
Show HN: A free mini game that makes you a smarter fly fisherperson
Show HN: A free mini game that makes you a smarter fly fisherperson
Show HN: textlog – A quiet, text-only microblogging platform, open-source, no JS
Show HN: textlog – A quiet, text-only microblogging platform, open-source, no JS
Show HN: Wyzer Programming Language
So i've been working on this project since a few days (or months i should say), it's called wyzer (meaning wiser) it's a statically typed, compiled, resource-oriented programming language with integrated distributed safety via choreographic programming and perceus memory model, The reason why i began this project is out of frustration from Rust, you see it does provide safety for your memory by the strict type checking but what it does not gurantee safety against are distributed deadlocks which is basically a few independent nodes or services wait permanently for resources or messages held by each other, forming a circular wait, the rest are cross-service correctness and protocol mismatch as well. If we are specific over here Wyzer works on mainly generalizing the concept of choreographic programming in a high level programming language because its the very few attempts of actually solving these gaps of safety. Instead of borrow checkers and lifetimes wyzer has linear/affine types and a perceus reference counting which is computationally much simpler for an LSP to understand as well<p>after 5 months of research and a few weeks of development i am soon going to release version 0.1.0 of it, if you would like to contribute to it you're most welcome!
Show HN: Wyzer Programming Language
So i've been working on this project since a few days (or months i should say), it's called wyzer (meaning wiser) it's a statically typed, compiled, resource-oriented programming language with integrated distributed safety via choreographic programming and perceus memory model, The reason why i began this project is out of frustration from Rust, you see it does provide safety for your memory by the strict type checking but what it does not gurantee safety against are distributed deadlocks which is basically a few independent nodes or services wait permanently for resources or messages held by each other, forming a circular wait, the rest are cross-service correctness and protocol mismatch as well. If we are specific over here Wyzer works on mainly generalizing the concept of choreographic programming in a high level programming language because its the very few attempts of actually solving these gaps of safety. Instead of borrow checkers and lifetimes wyzer has linear/affine types and a perceus reference counting which is computationally much simpler for an LSP to understand as well<p>after 5 months of research and a few weeks of development i am soon going to release version 0.1.0 of it, if you would like to contribute to it you're most welcome!
Show HN: A terminal glued to the macOS dock
Every single day of my life since I started programming back in 2020 I open my projects through the terminal/ghostty. "cd path" + "code .". Until today I don't even know how to open vscode first then open a project from there.<p>I usually have 3-4 vscode windows open at the same time, and I like them in separate desktops (for mac users). i gotta admit, i use 8 desktops, 3-4 for vscode, 1 for arc, 1 for docker, 1 for postman etc.<p>So my daily routine when I turned on my mac was: (1) open ghostty; (2) cd-path+code.; (3) drag the vscode window to a desired desktop; (4) get back to the ghostty desktop; (5) repeat until all is open.<p>i was unbothered for 6y. Until i realized how inefficient i was being: (1) opening ghostty just to run one-off commands to open another app felt wrong, like why do I need a terminal if it's not a process I need to watch; (2) the need to go back to the ghostty desktop every time i wanted to open a new project and drag it to a new desktop and switch back... it's funny how we simply accept a habit and don't bother to fix it<p>i wanted a terminal that persisted across desktops AND that was always visible so i could access it anytime AND that wasn't big because i would only run one-off commands. so I created starboard.<p>where could I fit a terminal that was always visible and accessible? i looked at the macOS dock, i looked at the empty space to its right, and I said "that's it".<p>starboard is a floating terminal window that's literally glued to the dock, filling the blank space to the right, tracking its height and position live. it's visible from any desktop, a real companion to the dock, and it's a persistent shell.<p>to close the story on my routine, I now can happily jump straight to the desktop i want my project to be in and open it there through Starboard. i rarely open ghostyy, unless i really need it.<p>here's where feedback is massively important. i built this for the way i work with it, the way my dock is, which is in the bottom. my dock's position and height give me a perfect sized Starboard with 3 visible lines that I can happily work with. hearing from you guys how it appears to you would be essential for further improvement.
Show HN: A terminal glued to the macOS dock
Every single day of my life since I started programming back in 2020 I open my projects through the terminal/ghostty. "cd path" + "code .". Until today I don't even know how to open vscode first then open a project from there.<p>I usually have 3-4 vscode windows open at the same time, and I like them in separate desktops (for mac users). i gotta admit, i use 8 desktops, 3-4 for vscode, 1 for arc, 1 for docker, 1 for postman etc.<p>So my daily routine when I turned on my mac was: (1) open ghostty; (2) cd-path+code.; (3) drag the vscode window to a desired desktop; (4) get back to the ghostty desktop; (5) repeat until all is open.<p>i was unbothered for 6y. Until i realized how inefficient i was being: (1) opening ghostty just to run one-off commands to open another app felt wrong, like why do I need a terminal if it's not a process I need to watch; (2) the need to go back to the ghostty desktop every time i wanted to open a new project and drag it to a new desktop and switch back... it's funny how we simply accept a habit and don't bother to fix it<p>i wanted a terminal that persisted across desktops AND that was always visible so i could access it anytime AND that wasn't big because i would only run one-off commands. so I created starboard.<p>where could I fit a terminal that was always visible and accessible? i looked at the macOS dock, i looked at the empty space to its right, and I said "that's it".<p>starboard is a floating terminal window that's literally glued to the dock, filling the blank space to the right, tracking its height and position live. it's visible from any desktop, a real companion to the dock, and it's a persistent shell.<p>to close the story on my routine, I now can happily jump straight to the desktop i want my project to be in and open it there through Starboard. i rarely open ghostyy, unless i really need it.<p>here's where feedback is massively important. i built this for the way i work with it, the way my dock is, which is in the bottom. my dock's position and height give me a perfect sized Starboard with 3 visible lines that I can happily work with. hearing from you guys how it appears to you would be essential for further improvement.
Show HN: A terminal glued to the macOS dock
Every single day of my life since I started programming back in 2020 I open my projects through the terminal/ghostty. "cd path" + "code .". Until today I don't even know how to open vscode first then open a project from there.<p>I usually have 3-4 vscode windows open at the same time, and I like them in separate desktops (for mac users). i gotta admit, i use 8 desktops, 3-4 for vscode, 1 for arc, 1 for docker, 1 for postman etc.<p>So my daily routine when I turned on my mac was: (1) open ghostty; (2) cd-path+code.; (3) drag the vscode window to a desired desktop; (4) get back to the ghostty desktop; (5) repeat until all is open.<p>i was unbothered for 6y. Until i realized how inefficient i was being: (1) opening ghostty just to run one-off commands to open another app felt wrong, like why do I need a terminal if it's not a process I need to watch; (2) the need to go back to the ghostty desktop every time i wanted to open a new project and drag it to a new desktop and switch back... it's funny how we simply accept a habit and don't bother to fix it<p>i wanted a terminal that persisted across desktops AND that was always visible so i could access it anytime AND that wasn't big because i would only run one-off commands. so I created starboard.<p>where could I fit a terminal that was always visible and accessible? i looked at the macOS dock, i looked at the empty space to its right, and I said "that's it".<p>starboard is a floating terminal window that's literally glued to the dock, filling the blank space to the right, tracking its height and position live. it's visible from any desktop, a real companion to the dock, and it's a persistent shell.<p>to close the story on my routine, I now can happily jump straight to the desktop i want my project to be in and open it there through Starboard. i rarely open ghostyy, unless i really need it.<p>here's where feedback is massively important. i built this for the way i work with it, the way my dock is, which is in the bottom. my dock's position and height give me a perfect sized Starboard with 3 visible lines that I can happily work with. hearing from you guys how it appears to you would be essential for further improvement.
Show HN: demake – one source project compiles to any retro game console ROM
This started life as a graphics tool for a specific problem: gen AI can make retro-styled sprites but can't follow exact hardware constraints of pixels and colors.<p>While building this I liked the idea that I can fan-out to any retro videogame console or handheld's specifications.<p>I then devised my own declarative language - Demotic - to express the game you want to build as concisely and naturally as possible without implementation detail. To work on different machines, you use relative units, like vw, vh, vmin, vmax.<p>It has a web UI, CLI and NPM package. Still a work in progress.
Show HN: demake – one source project compiles to any retro game console ROM
This started life as a graphics tool for a specific problem: gen AI can make retro-styled sprites but can't follow exact hardware constraints of pixels and colors.<p>While building this I liked the idea that I can fan-out to any retro videogame console or handheld's specifications.<p>I then devised my own declarative language - Demotic - to express the game you want to build as concisely and naturally as possible without implementation detail. To work on different machines, you use relative units, like vw, vh, vmin, vmax.<p>It has a web UI, CLI and NPM package. Still a work in progress.
Show HN: Wallfacer – A terminal session manager for Claude Code, and more
Show HN: Wallfacer – A terminal session manager for Claude Code, and more
Show HN: Pokémon Emerald Ported to Raspberry Pi Pico 2
Pokémon Emerald ported to the RP2350 microcontroller. No emulator, 60 fps HDMI output. Recompiled from ARMv4T to Cortex-M33 and the Game Boy Advance's video hardware is reimplemented in software on the second core.
Show HN: Pokémon Emerald Ported to Raspberry Pi Pico 2
Pokémon Emerald ported to the RP2350 microcontroller. No emulator, 60 fps HDMI output. Recompiled from ARMv4T to Cortex-M33 and the Game Boy Advance's video hardware is reimplemented in software on the second core.
Show HN: Pokémon Emerald Ported to Raspberry Pi Pico 2
Pokémon Emerald ported to the RP2350 microcontroller. No emulator, 60 fps HDMI output. Recompiled from ARMv4T to Cortex-M33 and the Game Boy Advance's video hardware is reimplemented in software on the second core.