neogoose

I really excited to share my journey of building this movie. It was always my dream to make a cartoon and it was my passion to make a highly efficient rendering pipelines and software.

Movie is directed and produced by me. I watched and changed many times every scene, it’s not a one shot prompt slop.

Thanks for watching

I am tired of executing random scripts to install software and then not being able to uninstall it.

I made a pretty lightweight single-binary cli to manage all of this. It statically analyzes the bash scripts for installing software and then also keeps track of what you have installed for seamless deletion and upgrade experience

It doesn't have to, you can give it a blob of bytes as well. It's just hard to keep it a cli and doesn't use kernel at all

more correct would be - do not use kernel file system

yeah I was just picking up an interesting the title for hn, you should read a README to get the actual understanding of project

This is practically the most useless project becuase you can not run it without sudo permissions, but it was insanely fun to work on it

supports ext4, btrfs, and apfs. Multithreaded, supports compression, nested volumes, and can even search detached volumes like .iso and .dmg without mounting

An interesting bonus point: you can't really vibe code it cause clankers can not run sudo commands

it is absolutely amazing experience on mobile if you guys do not understand how to use a search bar and a couple of segmeneted controls -- there is nothing much I can do about it

you absolutely missed the point

my tool is not using regex, it can use regex but it is not required

you can try it yourself. ripgrep search for "MAX_FILE_SIZE" in the chromium repo takes 6-7 seconds, with fff it is 20milliseconds

so essentially in this specific case it is over 1000x faster, but the repo size is huge (66G, 500k files)

because it is meant to be used by the long running sdk not one shot search (this is where all the optimizations are coming from)

it looks absolutely gorgeous btw but the idea is that you can try the search speed not actually use lmao

it very much depends on the platform and the operating system

for example ripgrep doesn't do any memory mapping on macos which makes it 2-3x faster just becuase of that

if you would search in the chromium repo you would see the correct match https://fff.dmtrkovalenko.dev/?repo=2&q=bazel

I have open sourced the fastest code search implementation. Comprehensive SDK for both file finder and grep file search that is over 100x faster than ripgrep

fff originated as very much loved neovim file finder that is not a ripgrep wrapper and provides better and faster search

Lately I've been researching the way to make it work for AI to improve the search ai harness is perfroming and the results are amazing

works for every harness https://github.com/dmtrKovalenko/fff.nvim

Since glibc (better to say csh) implemented it. https://man7.org/linux/man-pages/man3/glob.3.html search for GLOB_BRACE

I agree though the main problem for me is not the API it's missing functionality of patterns like ./*/*.c. There is a very long running thread in the gnu mailing list where authors do not like this idea.

While I need this because everyone expects it to be available. Another reason is the API for thing like someone else asked here already (match in memory over a list of paths)

That's one of the reasons I built zlob. It literally has an endpoint to do this but if you are talking about glibc there are 2 options

1. fnmatch function which is not ideal because it doesn't take into account all the path specific optimizations and does not support BRACE 2. ALTDIRFUNC flag for globbing let you simulate file system which absolutely sucks

in zlob you can simply call zlob_match_paths(<pattern>, <list>, flags, ptr)

where list would be either c string or rust/zig like slices

100% POSIX and glibc compatible globbing library for C, Zig, and Rust that is faster and supports all the modern globbing formats (more than libc and rust glob crate)

It supports all the formats like * and {a,b} expansion as long as have a very efficient syscall and SIMD optimization for faster processing

I should at some point, I do not need other gear types so I didn't do that, but if this project gets a little attention I'll just do it