What's everybody working on?

For now, yeah :sweat_smile: that was our first proof of concept to see if the solenoids can even actuate the keys.

Our current version has solenoids hovering over all keys on the octave


Also apologies for any musical jargon I mess up, learning all this as I go along the project

10 Likes

I’m currently working on a block game called Terrafinity. it is similar to Minecraft but with the goal of supporting much larger terrain and render distances. I currently have world saving, LOD rendering, and LOD terrain generation implemented. Most parts of the game are multi threaded and don’t block the render thread. The bottom screenshot is at regular playable settings, the rest are at higher settings although if I improve the rendering engine they might be more playable. I’m currently using OpenGL for rendering, DVUI for the menu, and WIO for window management.


17 Likes

I am hobby-hacking on (and dog-fooding) my own agentic LLM harness for running local models (Qwen 3.6).

Some of the features were vibe-coded with this tool itself, which is an interesting experience by itself. However, everything always goes through my personal review, and I often re-implement things a bit before pushing.

Still, I’ve been seeing notable productivity improvement, and I rarely miss cloud API offerings so far, so I’d say it has been success so far. I still have codex available through the API but in my opinion, local models are/will be the next wave of AI, for all sorts of reasons but mostly because the privacy really changes everything.

Here’s a screenshot of WIP zig16 migration (I am pulling my hair in the other repo, this one is likely going to be easy, so I’m letting qwen to chew threw that)

https://codeberg.org/cztomsik/clown-code

5 Likes

Interesting.. what hardware specs you running locally to make local AI a reality ?

And also - any luck getting local AI to use internet access for data scraping ?

I havnt had much luck with it (not using it for code production, but trying to use it for data acquisition of scattered historical records)

Radeon AI PRO R9700 32G + cheapest AM5 Ryzen 5 + 64G of DDR5 RAM

But before that I was also running unsloth/Qwen3.6-35B-A3B-GGUF on my M3 Max Macbook.

And about scraping, the biggest issue is that everything is blocked now, so it’s not very useful. But scraping is builtin in the tool.

I’m very interesting to follow the progress on this!

recently started a side project. a clean, tui based, music (streaming or otherwise) player. i’m sure one exists in zig already but i figured it would be a soft intro into the language, letting ytdlp mpv do some of the heavy lifting.

4 Likes

Working on a City Building game in my spare time. It’s basically how totally unpredictable stuff you can’t control — think nearby military bases, wars, or a savage global recession — can hijack a city’s vibe and future. I’ll drop something online when the time is right. Just having fun trying to figure out Zig and 3D development. Started with Blender but switched to Blockbench.



21 Likes

made some progress last night
will link the repo once it’s live.

10 Likes

im putting c++ (and a little zig) on a teensy 4.1 for a rocket

3 Likes

Yesterday I decided to finally try add seccomp sandbox to the SDL reference frontend.
The code for the seccomp filter setup itself is pretty simple:

fn installSeccompSandbox(mem: []const u8) !void {
    const seccomp = @import("loader/seccomp.zig");
    const cbpf = @import("loader/cbpf.zig");

    const filter: []const cbpf.Insn = switch (comptime builtin.target.ptrBitWidth()) {
        64 => D: {
            const hi_start: u32 = @truncate(@intFromPtr(mem.ptr) >> 32);
            const lo_start: u32 = @truncate(@intFromPtr(mem.ptr) & 0xFFFFFFFF);
            const hi_end: u32 = @truncate((@intFromPtr(mem.ptr) + mem.len) >> 32);
            const lo_end: u32 = @truncate((@intFromPtr(mem.ptr) + mem.len) & 0xFFFFFFFF);
            break :D &.{
                .ld_abs(seccomp.OFF.IP_HI),
                .jge(hi_start, 1, 0), // if hi(IP) < hi(start) → allow
                .ret(.allow),
                .jgt(hi_end, 0, 1), // if hi(IP) > hi(end) → allow
                .ret(.allow),
                .ld_abs(seccomp.OFF.IP_LO),
                .jge(lo_start, 1, 0), // if lo(IP) < lo(start) → allow
                .ret(.allow),
                .jgt(lo_end -| 1, 0, 1), // if lo(IP) >= lo(end) → allow
                .ret(.allow),
                .ret(.kill_process),
            };
        },
        32 => D: {
            const lo_start: u32 = @intFromPtr(mem.ptr);
            const lo_end: u32 = @intFromPtr(mem.ptr) + mem.len;
            break :D &.{
                .ld_abs(seccomp.OFF.IP_LO),
                .jge(lo_start, 1, 0), // if lo(IP) < lo(start) → allow
                .ret(.allow),
                .jgt(lo_end, 0, 1), // if lo(IP) > lo(end) → allow
                .ret(.allow),
                .ret(.kill_process),
            };
        },
        else => return error.SandboxUnavailable,
    };

    log.info("installing seccomp-bpf sandbox", .{});
    _ = try std.posix.prctl(std.os.linux.PR.SET_NO_NEW_PRIVS, .{ 1, 0, 0, 0 });
    const prog: seccomp.Filter = .init(filter);
    _ = try std.posix.prctl(std.os.linux.PR.SET_SECCOMP, .{ std.os.linux.SECCOMP.MODE.FILTER, @intFromPtr(&prog), 0, 0 });
}

We can test this by creating the following sorvi core:

const std = @import("std");
const sorvi = @import("sorvi");
const log = std.log.scoped(.minimal_example);

pub const std_options: std.Options = .{
    .logFn = sorvi.defaultLog,
    .queryPageSize = sorvi.queryPageSize,
    .page_size_max = sorvi.page_size_max,
    .log_level = .debug,
};

pub const os = sorvi.os;
pub const panic = std.debug.FullPanic(sorvi.defaultPanic);

comptime {
    sorvi.init(@This(), .{
        .id = "org.sorvi.example.minimal",
        .name = "minimal-example",
        .version = "0.0.0",
        .core_extensions = &.{.core_v1},
        .frontend_extensions = &.{.core_v1},
    });
}

pub fn core_v1_init(_: *@This()) !void {
    log.info("Hello world!", .{});
    const msg = "SNEAKY SYSCALL\n";
    _ = std.os.linux.write(1, msg.ptr, msg.len);
}

pub fn core_v1_deinit(self: *@This()) void {
    self.* = undefined;
}

Running it indeed causes SIGSYS:

~/d/p/s/sorvi master• 5.7s | 1 ❱ /home/nix/.cache/zig/o/5eca55ed1681473313a2239ad46c1311/sorvi-frontend /home/nix/.cache/zig/o/f7a9873210e3dab748239ed02239af80/minimal.sorvi
info(libsorvi_loader): /home/nix/.cache/zig/o/f7a9873210e3dab748239ed02239af80/minimal.sorvi: loaded at address u8@22f1f000
info(libsorvi_loader): installing seccomp-bpf sandbox
info(sorvi_sdl): platform: Linux
info(sorvi_sdl): build time version: 3.4.4
info(sorvi_sdl): runtime version: 3.4.4
info(sorvi_sdl): runtime revision: SDL-3.4.4 (https://github.com/castholm/SDL 0.4.2)
info(sorvi_sdl): core id: org.sorvi.example.minimal
info(sorvi_sdl): core name: minimal-example
info(sorvi_sdl): core version: 0.0.0
info(sorvi_sdl): video drivers: wayland (current), x11, kmsdrm, offscreen, dummy, evdev
info(sorvi_sdl): audio drivers: pipewire, pulseaudio, alsa (current), sndio, jack, disk, dummy
info(minimal_example): Hello world!
fish: Job 1, '/home/nix/.cache/zig/o/5eca55ed…' terminated by signal SIGSYS (Bad system call)

Trusting the core instead allows it to go through:

/home/nix/.cache/zig/o/5eca55ed1681473313a2239ad46c1311/sorvi-frontend --trust /home/nix/.cache/zig/o/f7a9873210e3dab748239ed02239af80/minimal.sorvi
info(libsorvi_loader): /home/nix/.cache/zig/o/f7a9873210e3dab748239ed02239af80/minimal.sorvi: loaded at address u8@3f3c5000
info(sorvi_sdl): platform: Linux
info(sorvi_sdl): build time version: 3.4.4
info(sorvi_sdl): runtime version: 3.4.4
info(sorvi_sdl): runtime revision: SDL-3.4.4 (https://github.com/castholm/SDL 0.4.2)
info(sorvi_sdl): core id: org.sorvi.example.minimal
info(sorvi_sdl): core name: minimal-example
info(sorvi_sdl): core version: 0.0.0
info(sorvi_sdl): video drivers: wayland (current), x11, kmsdrm, offscreen, dummy, evdev
info(sorvi_sdl): audio drivers: pipewire, pulseaudio, alsa (current), sndio, jack, disk, dummy
info(minimal_example): Hello world!
SNEAKY SYSCALL
info(sorvi_sdl): core did not initialize any video context, exiting the core

My plan for other operating systems is to launch the frontend inside a debugger and communicate the loaded memory range to the debugger process which can then watch syscalls and abort if they come from the loaded memory range. This has bit of cost, but i think the default mode should be untrusted. On openbsd I don’t have to do anything because openbsd doesn’t allow syscalls from unknown call sites by default (what a great idea). Of course this is only one of the sandboxing layers, I also want the frontend to lock itself down so it only has access to places it needs. I’d imagine you could still do nasty things if you were able to write to the frontend’s memory space and let frontend call the syscall for you.

Goal is to avoid things like this from happening:

8 Likes

These break labels are lovely, I’m stealing them.

And cool project, I love to see sandboxing efforts.

10 Likes

Very cool. What streaming services do you target to support?

just youtube atm. i’ve been using the heck out of it already. zig is a neat language. coming from c; tui state management in zig is so much more succinct.

2 Likes

These days I’m having fun writing a small stack language to make trippy animations. think shadertoy meets forth. It is not much, but it is made with love :slight_smile:

https://codeberg.org/tgirod/smolpix

6 Likes

Looks awesome! From skimming the code it seems very elegant, could you share some of the animations? Also are you aware of live coding?

Thanks for the kind words :slight_smile:

I’d like to export a few animations but right now I don’t have what’s necessary to do that. The earlier version used zignal to export the generated image, but generating animated GIFs was dead slow, so I had to move to raylib to display the animation. Now I can display animations, but I can’t save them to a file.

Right now I’m in the middle of a huge refactoring - this is clearly an “embarassingly parallel” problem, as each pixel of each frame can be computed in parallel. A good occasion to learn more about SIMD and parallel execution!

EDIT: also, yeah, live coding is really cool. messed around in that space a few times, with tools like chuck and supercollider …

2 Likes

Yes, and I don’t think it would take much to SIMDify either; most of the instructions in the machine would need to change very little except maybe for hashing, but shaders run into this problem as well and there are lots of tricks

I‘m mostly working on Aro, fixing Clang compatibility problems.

I also started investigating/trying things out that might eventually lead to a unikernel for aarch64 A CPUs. The guides on the ARM website are really worth a read. There is a tutorial for how to build a memory allocator for example.

3 Likes

I feel the same way about phones and 2FA. Kudos for implementing your own in Zig!
I’ve had some success with the RFCs, but have not worked out all of the bugs with my own implementation (not in Zig).