filed
Job queue using FUSE
git clone git://mccd.space/filed
| Log | Files | Refs | README | LICENSE |
commit 8b2b7c98bbed7b7acdf825b5167daed0a7537a36 parent a86f4a3c55e164499c39a42c39ff0f8bdfa67a39 Author: Marc <marc@coquand.email> Date: Mon, 29 Jun 2026 15:56:25 +0200 README formatting Diffstat:
| M | README.md | | | 31 | ++++++++++++++++++++++++------- |
1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md @@ -125,12 +125,16 @@ packing a lot of features. - [x] Customizable backoff and timeout before retries - [x] Last modified and created at are correctly rendered for jobs - [x] "Landlock"-mode for sandboxing - - [x] Add filed-launch - a script that can be used to restrict command access - - [x] Add command arguments to filed to lock it down, but still allow it access to state files, and remove that access in filed-launch + - [x] Add filed-launch - a script that can be used to restrict + command access + - [x] Add command arguments to filed to lock it down, but still + allow it access to state files, and remove that access in + filed-launch - [ ] Support landlock cli to only take -ro or -rw, use stat to determine if it's a file. - [ ] Support network restrictions - [ ] A reusable systemd unit file -- [ ] Notification on failure. Unfortunately [inotify does not work with fuse], which would have been elegant otherwise. +- [ ] Notification on failure. Unfortunately [inotify does not work + with fuse], which would have been elegant otherwise. - [ ] Notify forget and other updates. - [ ] Package for Alpine Linux (with reusable openrc script) - [ ] Add support for removing/moving active jobs @@ -148,10 +152,23 @@ quite a few warts and inefficiencies. ## Alternatives -- [nq] - `nq` is simpler and not a persistent process, but does not feature retries. They serve different purposes: `nq` for ad-hoc queuing of command lines. `filed` serves well as a job manager for your server, where you want admins to see jobs and be able to rerun them. -- [task-spooler] - `ts` has better control over how you want the task executed (GPU or CPU), and a lot of other features. It does (AFAIK) not support retries, which are supported in `filed`. -- [bull] - `bull` is only for node and javascript. It features a graphical UI, and a few other features not found in `filed`. `filed` eschews a GUI in favor of simple files, allowing it to better interoperate with other systems, and allows it to use regular unix permissions for access management. -- sqs - requires you to setup most infrastructure around retries yourself. sqs is far more complex, more focused on message passing, harder to inspect, but far more flexible. Sqs scales better and fits more workloads. +- [nq] - `nq` is simpler and not a persistent process, but does not + feature retries. They serve different purposes: `nq` for ad-hoc + queuing of command lines. `filed` serves well as a job manager for + your server, where you want admins to see jobs and be able to rerun + them. +- [task-spooler] - `ts` has better control over how you want the task + executed (GPU or CPU), and a lot of other features. It does (AFAIK) + not support retries, which are supported in `filed`. +- [bull] - `bull` is only for node and javascript. It features a + graphical UI, and a few other features not found in `filed`. `filed` + eschews a GUI in favor of simple files, allowing it to better + interoperate with other systems, and allows it to use regular unix + permissions for access management. +- sqs - requires you to setup most infrastructure around retries + yourself. sqs is far more complex, more focused on message passing, + harder to inspect, but far more flexible. Sqs scales better and fits + more workloads. [nq]: https://github.com/leahneukirchen/nq [task-spooler]: https://github.com/justanhduc/task-spooler