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

TL;DR: I'm not a programmer. I'm a sysadmin with a dream: a distributed forum database with no owner, no single point of failure, client-side filtering (like VLANs for content), and optional Nostr/ZeroNet/Atlas transport.

What exists: database replicated across nodes, each node chooses what to store and what filters to apply. Moderation = subscribing to trusted filters. No crypto required.

What I need: reality check, technical feasibility analysis, database schema advice, prototype devs (PHP/Go/Rust), testers.

What I offer: small budget ($100-200/mo for specific tasks), domain/hosting funding, endless gratitude.

Full article (detailed, 8000+ words, includes philosophy and use cases): https://write.as/zyhlc76pi2op3.md

Please be brutal. I can take it.

cross-posted from: https://lemmy.world/post/45047387

Title...

I'm kinda disgusted with Microsoft and Github has been declining into an AI-Centric hellhole, to the point my recommendations are almost exclusively AI related... And let's not forget, the new Copilot Training enabled by default (which honestly, how do you get rid of this thing, VSCode also feels intrusive with AI-First bullshittery)

I've been wondering about moving to Gitlab but.... "Finally, AI for the entire software lifecycle." is literally plastered in the landing page. So.. that feels like a no-go.

Codeberg is very decent, it's based on Forgejo so ActivityPub is also a thing (but is cross-instance contributions possible?) but it's exclusive for Source-Available and Free Projects, which, by all means, totally fine! Half of my "active" projects are for free, and are open source (does that make them FOSS even though I'm basically the only dev?)

And last but not least, Forgejo and Gitlab themselves are self-hostable, but...how expensive (price and storage) would it be to self host a Git Forge??

And maybe I'm being narrow-sighted... For FOSS projects in Github, sadly I'll have no choice but to contribute there, if that's the only place where the project resides, same for Gitlab, and Codeberg* (unless cross-instance contrib is a thing)

For now, I'm thinking of moving FOSS/OSS projects to Codeberg, but for personal projects? What are some good options?