The terminfo issue was resolved in the v1.2.0 release.
SSH shell integration is disabled by default, but once you enable it in your config you’ll be good to go.
Yeah, complexity is a valid concern. But if your workflow stands to benefit from the performance gains, I’d say it’s a worthy trade-off.
The server/client model that Foot uses is actually pretty clever for RAM-constrained situations, especially if you’re spawning tons of terminal instances. AFAIK, it’s not fundamentally impossible with GPU terminals. Ghostty has single-instance mode on Linux that shares some resources, but the RAM savings aren’t as dramatic because GPU terminals maintain texture buffers and rendering state in VRAM per instance.
The catch with Foot’s approach is all I/O gets multiplexed on a single thread. That’s fine for lightweight usage, but for workflows like mine that involve heavy TUIs and multiple tmux sessions with dozens of windows/panes with big scrollback buffers, it becomes a bottleneck when one or more panes are flooding output from scripts/playbooks/etc.
Like daq mentioned, reduced battery life is one downside if you’re on a laptop. RAM usage is also higher, usually 50-100MB more per instance than traditional terminals (sometimes more depending on the terminal and your config).
In terms of Ghostty specifically, it’s still a fairly young project, so the chance of hitting an edge case issue is higher than if you were using a more mature GPU-accelerated terminal.
Bias warning: I spend most of my workdays in the terminal, and I’m also a contributor to Ghostty.
The most noticeable difference is smoothness when you’re doing intensive terminal work like scrolling through large log files, running TUIs like btop/lazygit/yazi/lnav, or using multiplexers like tmux with multiple panes. Without GPU acceleration, you’ll see stuttering and lag with heavy output or complex interfaces.
It also makes a big difference in editors like Neovim, especially with syntax highlighting in large files or when scrolling quickly through code. The rendering just feels snappier and more responsive overall.
Basically, if you spend significant time in the terminal (like I do), the improved responsiveness is immediately noticeable. If you mostly use it for basic shell commands, the benefit is negligible.
I tried out Pi-hole many years ago, found it a bit too dumbed down and limited for my taste. I’ve been running Technitium for 5-ish years in my homelab, it’s been rock solid and very pleasant work with. I’ve even deployed it at work for a few projects as well. Been waiting for the clustering feature for a while now, super stoked to see this release.
I’d recommend ZFS for most home server/NAS scenarios. Gives you everything you need, and nothing you don’t.
Stuff like Ceph is just as hungry as it is powerful. The performance sweet spot for Ceph barely begins at 5 dedicated nodes (with at least a dozen drives each, ideally). I could never recommend it for home use unless you want to run it in a lab for the sake of learning.
Source: I’ve designed/built/deployed several 1PB+ Ceph clusters over the last ~5yrs.
Yeah they’re fine. TechMikeNY usually has better deals though, at least in my experience. Have bought from them several times both for work and homelab, no complaints.
zsh, ghostty (enable the ssh shell-integration option for auto terminfo installation on the remote), lazyvim
Containers are your friend, especially when you’re going to be doing dev work. Keep the server lean and clean.
Yes:
https://neovim.io/doc/user/remote.html#_remote-editing
https://github.com/barrett-ruth/live-server.nvim
Also, +1 to the Forgejo recommendation.
Pretty sure you could run Pulp in pull-through mode and add your local Forgejo/whatever registry as a remote, which would at least give you a unified “pull” URL. Then just use Forgejo actions to handle the actual build/publish for your local images whenever you push to main (or tag a release, or whatever).
Pulp might actually be able to handle both on its own, I haven’t ever tried though.
I hope people are liking the new SSH integration options :)
I’d recommend setting your sights on the 3-2-1 rule. 3 copies of your data, 2 different mediums, 1 off-site. Hetzner Storage Box is a good cheap offsite option.
Yeah serverpartdeals is legit. Between work and home, I think I’ve tested & deployed 150+ drives from them over the last 3yrs. No duds, no failures, no complaints. Great customer service on the corp side for big orders, too. 10/10 would recommend.
Move over, bud. That’s my hill to die on, too.
Oooh, ouch looks really neat! May actually cause me to retire my extract function. It suddenly feels a little incomplete by comparison, lol.
# Extract any archive
extract() {
if [ -f "$1" ]; then
case $1 in
*.tar.bz2) tar xjf "$1" ;;
*.tar.gz) tar xzf "$1" ;;
*.bz2) bunzip2 "$1" ;;
*.rar) unrar x "$1" ;;
*.gz) gunzip "$1" ;;
*.tar) tar xf "$1" ;;
*.tbz2) tar xjf "$1" ;;
*.tgz) tar xzf "$1" ;;
*.zip) unzip "$1" ;;
*.Z) uncompress "$1" ;;
*.7z) 7z x "$1" ;;
*) echo "'$1' cannot be extracted via extract()" ;;
esac
else
echo "'$1' is not a valid file"
fi
}
I’d recommend using OpenTofu (Terraform) for initial provisioning of VMs and then use Ansible for post-provisioning config & management. That way you’re letting both tools play to their strengths.
https://registry.terraform.io/providers/bpg/proxmox/latest/docs
Did you mean Netbox?
Well, yeah, thats why I’m saying if the action isn’t available directly from Forgejo, just write out the full action URL like the example in my last comment and pull it directly from GitHub. Most/all of the actions you’re pulling from Forgejo are originally forked from GitHub anyway. ¯\_(ツ)_/¯
With both Gitea and Forgejo, sometimes you need to hardcode the action URL, like:
https://github.com/actions/setup-java@v4
Does docker, pypi, apt, ansible galaxy, etc. I use it at work as part of our undercloud for OpenStack. It’s the go-to for StackHPC, too.
I used Mailcow for a while before switching to Stalwart out of curiosity. Stalwart was a bit easier to deploy and feels more polished than Mailcow, but they both get the job done.