Hey there,

A few months ago we open sourced Voiden, an offline API client we originally built to replace Postman for us internally. Main inspiration was curl and Obsidian (and other plain text editors).

It now has around 11k installs so quite happy with this.

Core principles we built it on:

• file-based, all plain executable markdown
• API requests composable through blocks (endpoint, auth, params, body) that can be used, reused, replaced and version in Git, just like code.
• free, local-first, Git based

Since open sourcing, almost everything that we shipped came from actual users, feedback and contributions.

A few examples was building API workflows (multiple requests in the same file, for example for CRUD flows) and scripting (JS/Python/Shell) before and after requests. Also added a “skills” layer so tools like Claude/Codex can operate directly on .void files and request blocks.

Repo: https://github.com/VoidenHQ/voiden Download: https://voiden.md/download

What I am looking/hoping for:

• Feedback on the tool itself, especially if you design and test APIs in your work.
• Ideas and tips from experienced folks on how to improve the visibility of the repo, especially for potential contributors that are looking for projects to contribute on: Adding good first issues, or other labels? (currently not doing that extensively so I am planning to put some structure).

thanks a million, (this is my first post about this in this sub-lemmy, if you are in other ones you might have seen this already)

cheers,

The Khronos OpenCL Working Group has released OpenCL 3.1, bringing widely deployed, field-proven capabilities into the core specification to expand functionality, including SPIR-V ingestion, that developers will be able to rely on across conformant implementations.

Features now mandated by OpenCL 3.1 have been deployed as extensions or optional capabilities. This is by design. The OpenCL working group evolves the specification by proving features in the field as extensions first, watching how they get used across multiple implementations, refining them based on developer feedback, and only then graduating them into the core specification.

Every conformant OpenCL 3.1 implementation will be required to consume SPIR-V kernels — a feature that has been one of the most requested by developers. OpenCL 3.1 additionally requires support for the SPIR-V query extension, which enables applications to enumerate the SPIR-V capabilities, extensions, and versions that a device supports, simplifying the adoption of new SPIR-V features as they become available.

Several features essential to HPC and AI kernels are also now mandatory in the core OpenCL 3.1 specification:

• Subgroups, including shuffles, rotations, and an expanded set of supported data types. A fundamental building block for tuned reductions, scans, and matrix kernels.
• Integer dot products, including saturating and accumulating variants, together with extended bit operations: Both map directly to dedicated hardware instructions on a wide range of modern silicon, and both are common building blocks for matrix multiplications and the low-precision arithmetic central to inference workloads.
• A new query for the suggested local work-group size. This gives applications and profilers a runtime hint for the optimal work-group size for a given kernel and device, eliminating the need for manual tuning or repeated size calculations across multiple enqueues and improving performance predictability on diverse hardware.
• A standard device UUID query, matching Vulkan’s VkPhysicalDeviceIDProperties::deviceUUID. This allows applications to correlate the same physical device across APIs, which is essential for multi-device systems and for external memory-sharing scenarios that span OpenCL and Vulkan.

I’ve been experimenting with building very small personal tools to help myself stay focused. Recently I wrote a minimal terminal‑based Pomodoro timer because I was struggling to start my side projects and wanted something simple that just works.

While building it, I realized I also need to learn how to distribute small projects properly. Right now I’m trying a simple approach: closed‑source, pay‑what‑you‑want, no DRM, and users just get the right to use the tool.

Since I’m still learning how licensing, expectations and “fairness” work for tiny solo projects, I’m curious how other developers see this model. Is this a reasonable way to distribute small tools? What would you expect as a user or developer?

For context, here’s the project I’m experimenting with.

GitHub: https://github.com/Mietkiewski/MPomidoro