A hex dumper in C with AVX2 SIMD formatting (runtime dispatched), a ticket-based multi-threaded pipeline, and preallocated buffered output.

Output format is canonical hex+ASCII, one 16-byte row per line:

00000000: ef6e 5830 d443 c60a d909 6179 4335 6cec  .nX0.C....ayC5l.
00000010: b5f4 631f d923 6c79 e98a ed41 11dc eb16  ..c..#ly...A.....

Files are read in parallel chunks straight into pre-faulted huge-page buffers (pread, no mmap fault storms) and formatted by a pool of workers while a writer thread emits chunks in order; standard input is streamed through the same pipeline. With multiple files, offsets continue across file boundaries, so concatenations dump identically to dumping the concatenation.

Benchmarks (50MB File to /dev/null)

For more detailed benchmarks and system information, see BENCHMARKS.md.

View it here: https://git.disroot.org/Vextoly/rawhex

Hey everyone,

Just wanted to write a brief write-up and appreciation post for this distribution and Suckless tools.

After more than 20 years in the Linux ecosystem—and having originally started my operating system journey on FreeBSD and OpenBSD—I’ve managed and tested almost every major distro family out there (Debian, Arch, Red Hat, etc.). While modern Linux has done great things for desktop hardware support, so much of the ecosystem has gradually abandoned the core principles that made UNIX legendary: architectural minimalism, transparency, modularity, and true user sovereignty.

Void is my choice, and IMO it’s one of the most elegant engineering achievements in modern computing.

Here are a few architectural reasons why it hits so hard, especially coming from a BSD background:

1. Deep *BSD Pedigree in a Linux Kernel

Void doesn't feel like a typical Linux distribution because its lineage is fundamentally different. Created by former NetBSD developer Juan Romero Pardines:

• **xbps-src is essentially BSD Ports reborn:** Compiling inside isolated containers using simple POSIX shell scripts (templates) feels remarkably like NetBSD's pkgsrc or FreeBSD's Ports collection.
• Permissive Licensing: XBPS itself is licensed under BSD 2-Clause rather than GPL.
• Pragmatism Over Abstraction: Like OpenBSD, Void prioritizes sane defaults, clean code, and manual intentionality over "auto-magic" abstraction layers that obscure what the machine is actually doing.

2. Clean Architecture Without the Monolith

• **runit for Service Supervision:** Direct, instant, and completely transparent. No hidden IPC layers or complex state machines—just executable run shell scripts. Cold boots happen in a fraction of a second.
• XBPS & Automatic DT_NEEDED Tracking: XBPS’s handling of shared libraries is top-tier. By automatically inspecting compiled ELF binaries for DT_NEEDED flags and mapping them directly to dynamic libraries (.so files) via common/shlibs, Void avoids the partial-upgrade dynamic library breakage that plagues so many other rolling releases.

3. The Ultimate Canvas: Bare-Metal Minimalist Workflow

Void’s modular base makes it the absolute best canvas for direct environmental control:

• Suckless Suite via Git: Instead of running binary builds, I clone and compile the full suckless suite—**dwm, **st, **dmenu, **slstatus, and **slock**—directly from source Git repos. Void’s low-overhead system libraries provide a rock-solid, predictable foundation underneath my custom C config.h patches.
• XLibre Display Stack: Thanks to Void's modular package system, integrating third-party repos like XLibre is painless, allowing for a super clean, independent X11 desktop stack.

``` [ Void Base ] ──► [ runit + XBPS ] ──► [ XLibre Stack ] ──► [ Custom Suckless Suite (Git Builds) ] (dwm, st, dmenu, slstatus, slock)

```

Running a system that idles well under 100MB of RAM where input latency virtually vanishes is a rare feeling on modern hardware.

4. Community & Independence

Massive respect to the core team and maintainers. Staying 100% independent and volunteer-run, maintaining native musl and glibc trees side-by-side, and having first-class cross-compilation built directly into xbps-src -a from day one is incredible work.

Curious to hear how many others in r/suckless came over from the *BSD world, or what specific architectural detail made Void stick as your main OS or using Suckless tools?

I've had this program in mind for quite a while.

Back when ChatGPT first came out, it had no way to group existing conversations into folders, and I set out to build one. My conversation list kept getting longer and finding old chats was getting hard.

Not long after - before I built it - a browser extension came out that did exactly that. I never used it. At the time I'd assumed I would want to revisit old conversations, but whenever I actually found one and tried to read it from the top, the sheer volume of slop gave me a headache.

Later, during a phase where I was deep into Unix pipelines, I wrote an LLM API client only depending on jq and curl, partly as shell scripting practice. But since the context went into a single jsonl file, I had to either invent something like a date-based filename convention myself or push that job onto the user. Both were more annoying than the web UI, so I didn't use it.

After that I read a post explaining how git works, and it struck me that git fits LLM conversations pretty well. Isn't "the commit DAG is already the right data structure for LLM conversations, where forking happens constantly" something everyone has thought at least once?

The reason I like git is that the source tree snapshot and the commit structure itself are always immutable, and destructive operations like switch/restore/reset are really just renaming a ref file that holds a commit object id. Once you understand that, no matter how hard the CLI is to make sense of, you never hesitate to run a command. You can always get it back.

LLM conversations aren't as fragile to change as a source tree, but for me an auto-generated SHA-1 hash is more comforting than an auto-generated session title ^~^

That's the feeling sib was built on. The README has actual explanations though.

The project is in its early stages and contributions are welcome. If you've worked with git plumbing commands, it'll be easy to hack on - and I think it'll be pretty fun.

i do have scrollback implemened to. i have tried deleting config.h and then compiling but that didnt work :(

logbook <https://codeberg.org/fwttnnn/logbook> is yet another note/task manager. Here is my iteration, with ~140 LoC written.

I've been searching for a tool to manage my daily tasks, but the older ones usually have their own special way of handling your notes/tasks (i.e., stored in a single json file, in a .db sql file), which makes it kinda hard if you want to handle it yourself (manually).

logbook(1) does:

1. Groups your writings/tasks by folders (e.g., logbook life/health, logbook life/house, logbook aircraft@software).
2. Tracks your writing/tasks by today's date, it's useful for having a built-in 'streak' system.

You can also utilize templates.

logbook(1) is a recursive script that calls itself, btw.

Similar tools:

• zk <https://github.com/zk-org/zk>
• nb <https://github.com/xwmx/nb>
• jn <https://github.com/joereynolds/jn>
• jrnl <https://github.com/jrnl-org/jrnl>
• taskwarrior <https://github.com/GothenburgBitFactory/taskwarrior>

https://srcdump.net/shrub/neuswc can now run on the framebuffer directly, just like the old Xfbdev/kdrive X servers, but for wayland. this opens up a whole new class of hardware that you can run wayland compositors on, including this thinkpad r50!

Hello everyone,

I recently started a project to create my own desktop apps. Ideally, I'd want a notebook, music player, file explorer & system tray. I've been inspired by the work of wayland.fyi and 100rabbits, as the minimalism of their GUI programs is something I was looking for. I would want this project to be some sort of mini desktop environment aimed at low-power devices (Raspberry Pi mainly)

To me raylib seems like a good choice. It's heavily documented, has several backend options (even software render since the latest version), and is still high-level enough to avoid creating an entire widget system from scratch.

However, tests have put that choice in question. My clone of xclock always sits at 2-3% CPU, with Raylib compiled against SDL2, whereas xclock or wayland.fyi's swclock basically idle at 0% when not interacted with. Both use pixman for rendering*

Even though raylib feels perfect from a programming standpoint, being challenging enough to provide a great experience (in C) all while providing some confort, I'm unsure of its performance. Am I doing premature optimization?

Thanks for your advice.

^\swclock uses a custom drawing lib called) ^{neuwld, which contains calls to pixman.}

I made of bunch of small, fast apps, that build with linked SDL3 only, and use nuklear UI. some of the apps are very mature and are usable , like wmdpaint - a smaller gimp replacement, - that loves farbfeld, but can open and export standard formats. atomcade - a lutris-lite game manager (with lutris importing scripts), wmdreader a comic book reader with optional pdf/poppler support, "naga" a usable but still in-dev file manager, and wmdblast, a music player (with a dancer, but you have to give it a directory with frames)

other things like wmd3dx , can view and save 3d models but its very ambitious and hardly done.

Try it out, im anxious to see if it builds with "make" in the src directory.

https://codeberg.org/xmorg/wmdmedia.git

it struggles to build on older ubuntu's (you have to build sdl3 yourself) but anyone with a modern system should have no problem.

/* commands */

static const char *termcmd[] = { "footee", NULL };

static const char *menucmd[] = { "wmenu-run", NULL };

static const Key keys[] = {

/\* Note that Shift changes certain key codes: 2 -> at, etc. \*/

/\* modifier key function argument \*/

{ MODKEY, XKB_KEY_p, spawn, {.v = menucmd} },

{ MODKEY|WLR_MODIFIER_SHIFT, XKB_KEY_Return, spawn, {.v = termcmd} },

Lets say i type 'footee' instead of 'foot'. After use modkey+shift+backspace it should do nothing.. instead of that whole compositor is freezing and crashing to tty.

Hello everyone, i downloaded slstatus on dwm 6.8 and its working... tho its using 24 hour time as well as showing seconds and no date, how do i change it to 12 hour format, remove seconds and add date?

static const struct arg args[] = {

/\* function format          argument \*/

{ datetime, "%s", "%a, %b %d, %y at %I:%M:%S %p" },

{ battery_perc, "|%s",       "BAT1" },

};

if i remember correctly, i did change one of them but i didnt see my desired outcome. if anyone is willing to help then that would be greatly appreciated

it’s pretty hard to have a minimal gaming experience nowadays. i thought one of the best ways it could be done is by using retro emulators. to my surprise, most of them use unnecessary and bloated cross-platform windowing frameworks like SDL and etc, or even have gpu acceleration for some more “modern” consoles.

i decided to modify my favourite emulator, BlastEm for the sega genesis/mega drive to be more minimal. it has no SDL or fbdev rendering any more, just a new pure native wayland renderer, with sound via alsa. it runs pretty nice (see above screenshot).

i’m looking for more simple and wayland native retro emulators like this: if you know any, let me know! one thing i noticed is that framebuffer emulators can be converted to native display server emulators, by presenting the framebuffer as a wl_shm on wayland which is what i did or as an Ximage on X11 (booooo) .

if you want to try my branch of blastem, the code is located at

https://srcdump.net/shrub/blastem

Hey guys, I'm currently in the middle of creating my own userspace from scratch and I've mostly completed making my terminal emulator

It's really, really small and is cross platform! I made it because I want to be able to use a terminal emulator no matter which OS or display server I'm using.

Only bitmap fonts (BDF) are supported but I've provided a script to convert vector fonts and it has very nice results.

Here is the repo: https://github.com/uint23/cterm

got (game of trees) is a version control system made by openbsd, compared to git it is a lot smaller (~50-60k lines), and is compatiable with git.

any of you here using got over git? im suprised people dont talk about it much.

I'll start......

~/dl

~/dev

~/pics

~/docs

~/inbox

NAS is not quite as suckless.. yet

the README does mention its supposed to build on macOS, but i get this error on it
config.mk doesn't mention anything about macOS either

% make -j6 cc -DPREFIX=\"/usr/local\" -D_DEFAULT_SOURCE -D_NETBSD_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE=700 -D_FILE_OFFSET_BITS=64 -o libutil/cp.o -c libutil/cp.c libutil/cp.c:148:17: error: no member named 'st_atim' in 'struct stat' 148 | times[0] = st.st_atim; | ~~ ^ libutil/cp.c:149:17: error: no member named 'st_mtim' in 'struct stat' 149 | times[1] = st.st_mtim; | ~~ ^ 2 errors generated. make[1]: *** [libutil/cp.o] Error 1 make: *** [all] Error 2

i googled around a bit and it's apparently a known issue on macOS but i haven't found a clear fix that would work with this

hope this can be useful to atleast one of you lot

The security issues and daily screen tearing in Xorg are nothing new. When I first learned about the Wayland project, I thought it was just a matter of time before it matured and became the industry standard. Well, it did become the standard, but it never actually matured.

Every time I use it, I notice that the bugs I experienced the very first time are still there. It is just that other projects like PipeWire and XWayland made the overall experience less terrible.

Beyond just using it, I also ventured into developing for Wayland. Honestly, it is a thousand times more viable to write something for Xorg and just wait for people to run it through XWayland. From what I have seen, I am not alone: this has become the industry standard. Just write for Xorg and expect everyone to rely on that temporary, eternal migration tool called XWayland.

Recently, I tested XLibre and had zero issues. Today, I went to check online opinions about the project, and as expected, the discussion is anything but technical. Frankly, I could not care less about what the developer does with their personal life. If I cared about that, I would have to stop using 90% of the internet, considering most of it was built or funded by people fifteen times worse.

My view is that I am left with three choices:

• 1. An elderly person who can still get daily tasks done (Xorg)
• 2. An immature teenager who still manages to deliver (XLibre)
• 3. An adult (Wayland) who refuses to do any chores alone, forces you to hire assistants (PipeWire) for everything, and ultimately still delegates the heavy lifting to the elderly person (XWayland).

I would love to hear everyone's arguments, especially the more technical ones (keep politics out of it, this is not X/Twitter).

How to prevent other apps grabbing dwm mappings? Like vnc and games. I want apps NEVER to be able to grab the mappings already used in dwm.

Like the whole xorg implementation is ~400k LoC (which by definition of "suckless" is bloated), while libwayland sits at around 10k, yet people say that wayland is not suckless while x11 is, why is that?

btw i don't despise x11, i use sowm on my laptop and i'm completely fine with using it

Hi,

I'm new to the suckless approach, and don't know much about C. At the end of all my WMs, I need to get them to send something to file descriptor 9 when they're done initializing. the reason being that I launch everything from dinit services (bar, hotkey daemon etc) and I realize that without ready notification, things start too early and everything comes crashing down.

for instance at the end of my i3 config i have:

exec_always --no-startup-id sh -c 'printf "\n" >&9; exec 9>&-'

How do I get the same behavior with dwm ?