Ask HN: What Are You Working On? (December 2025)

I start with SHM memory, will add linux dma-buf once SHM is enough up and running. Currenty monothreaded, ofc. AMD GPU code for SHM is in, now writting wayland protocol code to please the first wayland clients I would like to run (not using the C libraries provided by the wayland project, native wire format).

I want to move away from x11, and once I get something decent with this compositor, I will probably have to fork xwayland in order to make it work with this minimal compositor, that for some level of legacy compatibility (steam client/some games).

In the end, I did design some kind of methodology and coded some SDK tools in order to write a bit more comfortably RISC-V machine code programs in a very simple fire format (only core ISA, not even compressed instructions, no pseudo instructions, using only a simple C preprocessor).

Coding time does not matter on such software in the light of their life cycle once it does "happen".

All that presuming not too much IRL interference... yeah, I know this is excessive to expect that...

The super hard part is not coding, it is motivation: energy, mood, cognitive bias, etc.

htvend is a tool to help you capture any internet dependencies needed in order to perform a task.

It builds a manifest of internet assets needed, which you can check-in with your project.

The idea being that this serves as an upstream package lock file for any asset type, and that you can re-use this to rebuild your application if the upstream assets are removed, or if you are without internet connectivity.

Has an experimental GitHub action to integrate within your GitHub build, archiving assets to S3.

> Show TP: TreatyHopper - Pay less taxes

> Treaty shopping is a tax strategy where companies route profits through intermediary countries with favorable tax treaties to minimize overall tax liability.

Can't make this up x)

I've been working through advent of code using my own little compiler/language. It's in such an early state that some creative problem solving is required, not to mention the compiler bugs! But I'm very pleased to have it running interactively on my blog like this – I want to work towards some bigger notebooks in the style of explorable explanations.

It's unfortunate but native UI (as in, using the native controls with their native look) has mostly died off in my opinion, at least for complex cross-platform applications.

You can try to do it in a cross-platform manner but it never works well. Want to implement a tab bar like VSCode's? Win32 tab bars do not support close buttons (need to be custom rendered) and Cocoa tabs it doesn't even make sense for them to have a close button. In Cocoa you're supposed to use either the windowing system to do tabs (similar to Safari tabs) or custom render everything (like iWork).

So I say screw it, make it look as you wish.

The design of the API is somewhat DOM inspired (everything is built up of divs that can be styled). It's pure retained mode for now, I still need to think how I'll make reactivity work.

On macOS it uses a custom NSView to implement "divs". Drawing is done with CoreAnimation layers. Text editing is handled by a nested a NSTextView control with a transparent background. Could also host a web view in a similar manner. Context menus are native.

On Windows it uses a custom C++ class that stores Windows.UI.Composition surfaces for drawing (could also use DirectComposition + Direct2D). Text editing is handled by a windowless RichEdit control (ITextHost/ITextServices). Context menus are native Win32.

On Linux it uses a custom QWidget with a nested QTextEdit control for text editing. I'm thinking of experimenting with Qt Quick for hardware accelerated rendering like the other two.