GitHub repository with the issue tracker: https://github.com/leahneukirchen/nitro.
Readit Newsnetworked commented on Nitro: A tiny but flexible init system and process supervisor git.vuxu.org/nitro/about/... · Posted by u/todsacerdoti
networked commented on Dokploy is the sweet spot between PaaS and EC2 nikodunk.com/2025-06-10-d... · Posted by u/nikodunk
Last time Coolify came up (https://news.ycombinator.com/item?id=43555996 +183 comments) user crudbug linked a bunch of these:
coolify, dokku, dockploy, swiftwave; and K8s-based: cozystack, kubero, plural
related: https://news.ycombinator.com/item?id=41358020 (+271 comments; 2024) Dokku: My favorite personal serverless platform
I'm glad there's options but once I got one working I feel like I'd be stuck so feedback beforehand from those who've tried multiple is escpecially valuable, especially the monetization aspect for sustainability.
Here is my personal comparison table with 11 items: https://dbohdan.com/self-hosted-paas.
Note: no K8s.
networked commented on Vet is a safety net for the curl | bash pattern github.com/vet-run/vet... · Posted by u/mooreds
Huh
Why not just use the tools separately instead of bringing a third tool for this.
Curl -o script.sh
Cat script.sh
Bash script.sh
What a concept
What it comes down to is that people want a one-liner.
Telling them they shouldn't use a one-liner doesn't work.
Therefore, it is better to provide a safer one-liner.
This assumes that securing `curl | sh` separately from the binaries and packages the script downloads makes sense. I think it does. Theoretically, someone can compromise your site http://example.com with the installation script https://example.com/install.sh but not your binary downloads on GitHub. Reviewing the script lets the user notice that, for example, the download is not coming from the project's GitHub organization.
networked commented on Vet is a safety net for the curl | bash pattern github.com/vet-run/vet... · Posted by u/mooreds
You can also use vipe from moreutils:
curl -sSL https://example.com/install.sh | vipe | sh
vet looks safer. (Edit: It has the diff feature and defaults to not running the script. However, it also doesn't display a new script for review by default.) The advantage of vipe is that you probably have moreutils available in your system's package repositories or already installed.
networked commented on Borg – Deduplicating archiver with compression and encryption borgbackup.org/... · Posted by u/rubyn00bie
I'll die on this hill... If may files that are named like this:
DSC009847.JPG
DSC009847-b3-73ea2364d158.JPG
We'd be living in a better world.
I do that for many of my files. Notably family pictures and family movies, but also .iso files, tar/gzip'ed files, etc.
This makes detecting bitflips trivial.
I've create little shellscripts for verification, backups, etc. that work with files having such a naming scheme.
It's bliss.
My world is a better place now. I moved to such a scheme after I had a series of 20 pictures from vacation with old friends that were corrupted (thankfully I had backups, but the concept of "determining which one is the correct file" programmatically is not that easy).
And, yes, it detected one bitflip since I'm using it.
I don't always verify all the checksums: but I've got a script that does random sampling... It picks x% of the files with such a naming scheme and verifies the checksum of these x% of files picked randomly.
It's not incompatible with ZFS: I still run ZFS on my Proxmox server. It's not incompatible with restic/borg/etc. either.
This solves so many issues, including the "How do you know your data is correct?" (answer is: "Because I've already looked that family movie after the cryptographic hash was added to its name").
Not a panacea but doesn't hurt and it's really not much work.
I prefer
DSC009847.JPG.b3sum
B3SUMS
I do use very similar example.com/foo/bar/b3-abcd0123.html for https://example.com/foo/bar in the archival tool for outgoing links on my website. It avoids the need to have a date prefix like in the Wayback Machine while preventing duplication.
Speaking of .iso files. A recent PR [2] to my favorite Linux USB-disk-image burning tool Caligula has added support for detecting and verifying sidecar files like foo.iso.sha256 (albeit not Blake).
Is <https://github.com/trapd00r/vidir> the same as `vidir` from <https://joeyh.name/code/moreutils/>?
Shout out to moreutils, there are many nice utilities, and there's a `moreutils` package in most distributions.
Update: Looking at the authors listed in the man pages, the `trapd00r` version looks to be a fork of the moreutils version. Not sure how the functionality compares. Both versions seem to have been updated since the fork.
> Both versions seem to have been updated since the fork.
Thanks for pointing this out. It looks like the @trapd00r version has added `--sort` but lacks zero padding for the numbers that improves the UX. I mistakenly thought it was a fork tracking the original. I have edited my comment.
> For file management these days, Dired is my interface of choice. It is simply the more elegant tool for the job. Case in point: renaming a bunch of files in a directory to arbitrary names. With a shell, my standard approach would have been to run some variant of `ls -1 > foo.sh`, edit `foo.sh` to insert `mv` on each line to a renamed target file, `chmod u+x foo.sh` to be executable, run `foo.sh`, delete `foo.sh` and call it a day.
I used to do this before I discovered vidir. [1] vidir is not actually tied to vi; it lets you rename and delete files through your `$EDITOR`. You edit a temporary file that looks like this:
...
0093<tab>./fstab
0094<tab>./fuse.conf
0095<tab>./fwupd
...
I'll give Emacs another try some day, I swear, and Dired is one of the reasons.
Edit: [1] I linked to https://github.com/trapd00r/vidir here at first. That is a fork; vidir comes from https://joeyh.name/code/moreutils/. You probably want the original. It is packaged for Debian, FreeBSD, Homebrew, etc. as part of the package `moreutils`.