Show HN: Helium Browser for Android with extensions support, based on Vanadium https://ift.tt/E7S0dih

Show HN: Helium Browser for Android with extensions support, based on Vanadium Been working on an experimental Chromium-based browser that brings 2 major features to your phone/tablet: 1. desktop-style extensions: natively install any extensions (like uBO) from the chrome web store, just toggle "desktop site" in the menu first. 2. privacy/security hardening: applies the full patch sets from Vanadium (with Helium's currently wip). Means you get both browsers' excellent privacy features, like Vanadium's webrtc IP policy option that protects your real IP by default, and security improvements such as JIT being disabled by default, all while being a reasonably efficient FOSS app that can be installed on any (modern) android. It's still in beta, and as I note in the README, it's not a replacement for the full OS-level security model you'd get from running the GrapheneOS Vanadium combo. However, goal was to combine privacy of Vanadium with the power of desktop extensions and Helium features, and make it accessible to a wider audience. (Passkeys from Bitwarden Mobile should also work straight away once merged in the list of FIDO2 privileged browsers) Build scripts are in the repo if you want to compile it yourself. You can find pre-built releases there too. Would love any feedback/support! https://ift.tt/LqtKxS8 October 27, 2025 at 04:11AM

Show HN: The Legal Embedding Benchmark (MLEB) https://ift.tt/mPBv7YK

Show HN: The Legal Embedding Benchmark (MLEB) Hey HN, I'm excited to share the Massive Legal Embedding Benchmark (MLEB) — the first comprehensive benchmark for legal embedding models. Unlike previous legal retrieval datasets, MLEB was created by someone with actual domain expertise (I have a law degree and previously led the AI team at the Attorney-General's Department of Australia). I came up with MLEB while trying to train my own state-of-the-art legal embedding model. I found that there were no good benchmarks for legal information retrieval to evaluate my model on. That led me down a months-long process working alongside my brother to identify or, in many cases, build our own high-quality legal evaluation sets. The final product was 10 datasets spanning multiple jurisdictions (the US, UK, Australia, Singapore, and Ireland), document types (cases, laws, regulations, contracts, and textbooks), and problem types (retrieval, zero-shot classification, and QA), all of which have been vetted for quality, diversity, and utility. For a model to do well at MLEB, it needs to have both extensive legal domain knowledge and strong legal reasoning skills. That is deliberate — given just how important high-quality embeddings are to legal RAG (particularly for reducing hallucinations), we wanted our benchmark to correlate as strongly as possible with real-world usefulness. The dataset we are most proud of is called Australian Tax Guidance Retrieval. It pairs real-life tax questions posed by Australian taxpayers with relevant Australian Government guidance and policy documents. We constructed the dataset by sourcing questions from the Australian Taxation Office's community forum, where Australian taxpayers ask accountants and ATO officials their tax questions. We found that, in most cases, such questions can be answered by reference to government web pages that, for whatever reason, users were unable to find themselves. Accordingly, we manually went through a stratified sample of 112 challenging forum questions and extracted relevant portions of government guidance materials linked to by tax experts that we verified to be correct. What makes the dataset so valuable is that, unlike the vast majority of legal information retrieval evaluation sets currently available, it consists of genuinely challenging real-world user-created questions, rather than artificially constructed queries that, at times, diverge considerably from the types of tasks embedding models are actually used for. Australian Tax Guidance Retrieval is just one of several other evaluation sets that we painstakingly constructed ourselves simply because there weren't any other options. We've contributed everything, including the code used to evaluate models on MLEB, back to the open-source community. Our hope is that MLEB and the datasets within it will hold value long into the future so that others training legal information retrieval models won't have to detour into building their own "MTEB for law". If you'd like to head straight to the leaderboard instead of reading our full announcement, you can find it here: https://ift.tt/BDobz2n If you're interested in playing around with our model, which happens to be ranked first on MLEB as of 16 October 2025 at least, check out our docs: https://ift.tt/wGLcqdR https://ift.tt/wECSUqR October 27, 2025 at 03:46AM

Show HN: MyraOS – My 32-bit operating system in C and ASM (Hack Club project) https://ift.tt/5UnhoYF

Show HN: MyraOS – My 32-bit operating system in C and ASM (Hack Club project) Hi HN, I’m Dvir, a young developer. Last year, I got rejected after a job interview because I lacked some CPU knowledge. After that, I decided to deepen my understanding in the low level world and learn how things work under the hood. I decided to try and create an OS in C and ASM as a way to broaden my knowledge in this area. This took me on the most interesting ride, where I’ve learned about OS theory and low level programming on a whole new level. I’ve spent hours upon hours, blood and tears, reading different OS theory blogs, learning low level concepts, debugging, testing and working on this project. I started by reading University books and online blogs, while also watching videos. Some sources that helped me out were OSDev Wiki ( https://ift.tt/HJj6x7U ), OSTEP ( https://pages.cs.wisc.edu/~remzi/OSTEP ), open-source repositories like MellOS and LemonOS (more advanced), DoomGeneric, and some friends that have built an OS before. This part was the longest, but also the easiest. I felt like I understood the theory, but still could not connect it into actual code. Sitting down and starting to code was difficult, but I knew that was the next step I needed to take! I began by working on the bootloader, which is optional since you can use a pre-made one (I switched to GRUB later), but implementing it was mainly for learning purposes and to warm up on ASM. These were my steps after that: 1) I started implementing the VGA driver, which gave me the ability to display text. 2) Interrupts - IDT, ISR, IRQ, which signal to the CPU that a certain event occurred and needs handling (such as faults, hardware connected device actions, etc). 3) Keyboard driver, which enables me to display the same text I type on my keyboard. 4) PMM (Physical memory management) 5) Paging and virtual memory management 6) RTC driver - clock addition (which was, in my opinion, optional) 7) PIT driver - Ticks every certain amount of time, and also 8) FS (File System) and physical HDD drivers - for the HDD I chose PATA (HDD communication protocol) for simplicity (SATA is a newer but harder option as well). For the FS I chose EXT2 (The Second Extended FileSystem), which is a foundational linux FS structure introduced in 1993. This FS structure is not the simplest, but is very popular in hobby-OS, it is very supported, easy to set up and upgrade to newer EXT versions, it has a lot of materials online, compared to other options. This was probably the longest and largest feature I had worked on. 9) Syscall support. 10) Libc implementation. 11) Processing and scheduling for multiprocessing. 12) Here I also made a shell to test it all. At this point, I had a working shell, but later decided to go further and add a GUI! I was working on the FS (stage 8), when I heard about Hack Club’s Summer of Making (SoM). This was my first time practicing in HackClub, and I want to express my gratitude and share my enjoyment of participating in it. At first I just wanted to declare the OS as finished after completing the FS, and a bit of other drivers, but because of SoM my perspective was changed completely. Because of the competition, I started to think that I needed to ship a complete OS, with processing, GUI and the bare minimum ability to run Doom. I wanted to show the community in SoM how everything works. Then I worked on it for another 2 months, after finishing the shell, just because of SoM!, totalling my project to almost 7 months of work. At this time I added full GUI support, with dirty rectangles and double buffering, I made a GUI mouse driver, and even made a full Doom port! things I would've never even thought about without participating in SoM. This is my SoM project: https://ift.tt/GvEAcqS . Every project has challenges, especially in such a low level project. I had to do a lot of debugging while working on this, and it is no easy task. I highly recommend using GDB which helped me debug so many of my problems, especially memory ones. The first major challenge I encountered was during the coding of processes - I realized that a lot of my paging code was completely wrong, poorly tested, and had to be reworked. During this time I was already in the competition and it was difficult keeping up with devlogs and new features while fixing old problems in a code I wrote a few months ago. Some more major problems occurred when trying to run Doom, and unlike the last problem, this was a disaster. I had random PFs and memory problems, one run could work while the next one wouldn’t, and the worst part is that it was only on the Doom, and not on processes I created myself. These issues took a lot of time to figure out. I began to question the Doom code itself, and even thought about giving up on the whole project. After a lot of time spent debugging, I fixed the issues. It was a combination of scheduling issues, Libc issues and the Qemu not having enough (wrongfully assuming 128MB for the whole OS was enough). Finally, I worked throughout all the difficulties, and shipped the project! In the end, the experience working on this project was amazing. I learned a lot, grew and improved as a developer, and I thank SoM for helping to increase my motivation and make the project memorable and unique like I never imagined it would be. The repo is at https://ift.tt/zcn3RDu . I’d love to discuss any aspect of this with you all in the comments! https://ift.tt/zcn3RDu October 27, 2025 at 02:13AM

Show HN: I Built DevTools for Blazor (Like React DevTools but for .NET) https://ift.tt/Z9XlmJG

Show HN: I Built DevTools for Blazor (Like React DevTools but for .NET) Hi HN! I've been working on developer tools for Blazor that let you inspect Razor components in the browser, similar to React DevTools or Vue DevTools. The problem: Blazor is Microsoft's frontend framework that lets you write web UIs in C#. It's growing fast but lacks the debugging tools other frameworks have. When your component tree gets complex, you're stuck with Console.WriteLine debugging. What I built: A browser extension + NuGet package that: Shows the Razor component tree in your browser Maps DOM elements back to their source components Highlights components on hover Works with both Blazor Server and WASM How it works: The NuGet package creates shadow copies of your .razor files and injects invisible markers during compilation. These markers survive the Razor→HTML pipeline. The browser extension reads these markers to reconstruct the component tree. Current status: Beta - it works but has rough edges. Found some bugs when testing on larger production apps that I'm working through. All documented on GitHub. Technical challenges solved: Getting markers through the Razor compiler without breaking anything Working around CSS isolation that strips unknown attributes Making it work with both hosting models It's completely open source: https://ift.tt/wP7ItRB Demo site where you can try it: https://ift.tt/ziUwbTm Would love feedback, especially from anyone building production Blazor apps. What debugging pain points do you have that developer tools could solve? https://ift.tt/SKiI8Zv October 26, 2025 at 10:04PM

Show HN: Shadcn/UI theme editor – Design and share Shadcn themes https://ift.tt/q4YZ3uV

Show HN: Shadcn/UI theme editor – Design and share Shadcn themes Hey, I built https://ift.tt/yZxliP5 - a web app for creating and sharing themes for shadcn/ui, made with my some of my favorites, Next.js 15, Tailwind CSS 4, Drizzle ORM, and Supabase. The goal was to make it easy to visually design shadcn color themes, preview them live across various example UIs, and export them straight into your projects (as CSS or via the shadcn CLI registry command). I had a bit of experience going into this because I built the Theme Studio for VS Code in the past, but it was fun using a modern stack and leveraging Cursor to help me along the way this time. GitHub: https://ift.tt/yWzS8jR https://ift.tt/hRN6fLE October 26, 2025 at 01:21AM

Show HN: Gisia – A Lightweight Self-Hosted DevOps Platform https://ift.tt/kQ20pW6

Show HN: Gisia – A Lightweight Self-Hosted DevOps Platform Hi HN, I've been building Gisia – a lightweight, self-hosted DevOps platform for individuals and small teams. It's simpler, more lightweight and you can self-host. Key Features: - Git repository hosting with SSH and HTTP access - CI/CD pipelines with YAML configuration - Issue tracking - Built with modern Rails stack (Rails 8, PostgreSQL, Stimulus/Turbo, Tailwind CSS) Why Gisia? - Lightweight with minimal dependencies - Developer-first design - Fully open-source and auditable - You own your data Current Status: Currently in Alpha with core features complete. Merge requests and notifications are planned. Try It Out: You can take Gisia for a test drive by following the quick start guide in the README. Feedback and contributions welcome! https://ift.tt/Kq4xdmV October 25, 2025 at 08:30PM

Show HN: Random Makers – Show HN and Product Hunt, but Faster and Not Corporate https://ift.tt/eEy3rP7

Show HN: Random Makers – Show HN and Product Hunt, but Faster and Not Corporate https://ift.tt/5aGTP9w October 25, 2025 at 11:32PM