lsr: ls with io_uring

Lovely, I might try doing this for some other "classic" utility!

A bit off-topic too, but I'm new to Zig and curious. This here: ``` const allocator = sfb.get();

    var cmd: Command = .{ .arena = allocator };

``` means that all allocations need to be written with an allocator in mind? I.e. one has to pick an allocator per each memory allocation? Or is there a default one?

Allocator is an interface so you write library code only once, and then the caller decides which concrete implementation to use.

There's cases where you do want to change your code based on the expectation that you will be provided a special kind of allocator (e.g. arenas), but that's a more niche thing and in any case it all comes together pretty well in practice.

Caveat emptor, I don't write Zig but followed its development closely for awhile. A core design element of zig is that you shouldn't be stuck with one particular memory model. Zig encourages passing an allocator context around, where those allocators conform to a standardized interface. That means you could pass in different allocators with different performance characteristics at runtime.

But yes, there is a default allocator, std.heap.page_allocator

std.heap.smp_allocator

You should basically only use the page allocator if you're writing another allocator.

> you shouldn't be stuck with one particular memory model

Nit: an allocator is not a "memory model", and I very much want the memory model to not change under my feet.

> Zig encourages passing an allocator context around, where those allocators conform to a standardized interface.

in libraries. if youre just writing a final product it's totally fine to pick one and use it everywhere.

> std.heap.page_allocator

strongly disrecommend using this allocator as "default", it will take a trip to kernelland on each allocation.