Separating the libadwaita toolkit from the Adwaita theme so I can use one without the other
Fully keyboard-navigable file picker dialog. Or make it more straightforward to plug in a new implementation without also having to tear out the drywall.
X11 support
- Posts
- 9
- Comments
- 221
- Joined
- 2 mo. ago
- Posts
- 9
- Comments
- 221
- Joined
- 2 mo. ago
Note the date. This blog post is a few months old. I was expecting new drama on the latest episode of Who Hosted Whom (and does that make them fascist (and does that matter)) until new events but i guess it's just reruns this week.
I'm guilty of a few of these and sorry not sorry but this is not changing.
Often these are written with local dev and testing in mind, and in any case the expectation is that self-hosters will look through them and probably customize them - and in any case be responsble for their own firewalls and proxies - before deploying them to a public-facing server. Larger deployments sometimes have internal load balancers on separate machines so even when reflecting a production deployment, exposing on 0.0.0.0 or running eith network=host might be normal.
Never just run third-party compose files for user services on a machine directly exposed to untrusted networks like the internet.
One related story: I did have the arguable pleasure to operate a stateful Websockets/HTTP2-heavy horizontally scaled "microservice" API with Rails and even more Ruby, as well as gRPC written in other stuff. Pinning of instances based on auth headers and sessions, weighting based on subpaths, stuff like that. It was originally deployed with Traefik. When it went from "beta" stage to having to handle heavier traffic consistently and reliably on the public internet, Traefik did not cut it anymore and after a few rounds of evaluation we settled on HAProxy, which was never regretted IIRC. My friends company had it in front of one of the countries busiest online services at the time, a pipeline largely built in PHP. Fronted with haproxy. I have seen similar patterns patterns play out at other times in other places.
Outside of $work I've had them all running side by side or layered (should consolidate some but ain't nobody got time for that) over 5+ years so I think I have a decent feel for their differences.
I'm not saying HAProxy is perfect, always the best pick, has the most features, or without tradeoffs. It does take a lot more upfront learning and tweaking to get what you need from it. But I can't square your claims with lived experience, especially when you specifically contrast it with Traefik, which I would say is easy to get started with, has popular first-class support for containers, and loved by small teams - but breaks at scale and when you hit more advanced use-cases.
Not that any of the things either of us have mentioned so far is releveant whatsoever for a budding homelabber asking how to do domain-based http routing.
I think you are just baiting now.
More concretely..? What cursed endpoints is this too simple for?
https://docs.haproxy.org/3.2/configuration.html#http-request
https://docs.haproxy.org/3.2/configuration.html#7
https://docs.haproxy.org/3.2/configuration.html#11
What is an example of a "Better feature" relevant here?
HAProxy if you’re just doing containers
What makes you say that? From my experience、HAProxy a very competent, flexible, performant and scalable general proxy. It was already established when Docker came on the scene. The more container-oriented would be Traefik (or Envoy).
Please don't recommend UFW.
One main problem with UFW, besides being based on legacy iptables (instead of the modern nftables which is easier to learn and manage), is the config format. Keeping track of your changes over track is hard, and even with tools like ansible it easily becomes a mess where things can fall out of sync with what you expect.
Unless you need iptables for some legacy system or have a weird fetish for it, nobody needs to learn iptables today. On modern Linux systems, iptables isn't a kernel module anymore but a CLI shim that actually interacts with the nft backend.
It is also full of footguns. Misconfigured UFW resulting in getting pwned is very common. For example, with default settings, Docker will bypass UFW completely for incoming traffic.
I strongly recommend
firewalld, or rawdoggingnftables, instead of ufw.There used to be limitations with firewalld but policies maturing and replacing the deprecated "direct" rules together with other general improvements has made it a good default choice by now.
sudo apt-get install firewalld systemctl enable --now firewalld # ssh on port 22 opened but otherwise most things blocked by default firewall-cmd --get-active-zones firewall-cmd --info-zone=public firewall-cmd --zone=public --add-port=1234/tcp firewall-cmd --runtime-to-permanentThere are some decent guides online. Also take a look in
/etc/firewalld/firewalld.confand see if you want to change anything. Pay attention to the part about Docker.You need to know about zones, ports, and interfaces for the basics. Services are optional. Policies are more advanced.
I suggest it for your laptop, too.
The right nginx config will do this. Since you already have Nginx Proxy Manager, you shouldn't need to introduce another proxy in the middle just for this.
Most beginners find Caddy a lot easier to learn and configure compared to Nginx, BTW.
Another thing that I rarely see mentioned is that since SNI (domain name) is unencrypted for https (unless ECH, which is still not common), you can proxy and route https requests based on domain without terminating TLS or involving http at all.
sniproxyis a proxy for just that and available in debian repos. If all you really need is passing through request to downstream proxies or a service terminating TLS itself, it works nicely.The built-in rollback functionality doesn’t hurt either.
More than that I think it's a prerequisite for doing this.
You could self-host a shared "source of truth" git repo that you access over ssh or filesystem. That can be anything from a USB thumb drive, a small clean server or a container on your existing desktop with ssh access, to an entire Forgejo deployment. Then you only need the "secret zero" of an ssh key to get everything set up and syncable.
If fresh setup is more common, you probably have other parts like package installation and network configuration that you also want to automate. Enter configuration management like ansible or salt, image builders like packer or archiso, "immutable" solutions like Nix or rpm-ostree. Once you get there you typically manage that in git anyway and you could put your dotfiles repo as a submodule and copy them over as part of OS setup.
If it's just for once in a blue moon, manual ad-hoc copying gets you pretty far.
No matter how you slice it I think you have to either frequently spend time syncing changes or just accept the drift and divergence between machines and the sources.
Wishful thinking and stretching the definition beyond meaningfulness with regards to your conclusion. Lies, damned lies, and statistics. Don't delude each other.
Still, I've believed for a long time that the tipping point with an increasing trajectory is around 5% so pretty optimistic about recent trends.
If you have the option to "run a terminal here" then you can run
pwdfrom there to get the current directory path.OK, I'm not that familiar with KDE Connect itself so it's possible that it may have some built-in configuration for this (mounting a subpath directly instead of the root).
What you can hopefully do to make this easier without knowing more about KDE Connect is using symlinks.
Assuming the mount paths (which include IP address and port) are static, you can symlink them to more conventient locations. For example:
# find sftp mount path, assuming kio-fuse enabled find /run/user/$(id -u)/kio-fuse-* -type d -name emulated mkdir -p ~/Connected/ ln -s /run/user/..../emulated/0 ~/Connected/MyTabletThen you can bookmark those locations in the file manager.
This will only work with the static IP (or make KDEC mount on a path not including ip:port) and how to do that depends on over what protocol you connect.
Just for telling the filesystems apart I guess you could also put an empty file or folder like
emulated/0/00_MyTabletwhich will at least make it obvious where you are when you list the root.Peertube? TBH I'd rather take the few paragraphs and a couple of screenshots than having to spend 10 minutes fighting Google blocks for the privilege of watching anyonymously...
Able to make it watchable outside of YT?
It's been continuously improving. There are devices that are a hassle but you're a lot more likely to have things Just Working compared to a few years ago.
My understanding is that Ampere and others should run perfectly like any old x86 with a normal dist like vanilla Debian mostly due to a lot of hard work from individuals in the wider community.
Much of the time, dtb (device tree) and device drivers are what it comes down to.
For more estoric or finicky hardware, I think the dists with the best ARM support are Armbian, OpenWrt, and PostmarketOS.
Jeff Geerling has been reporting a lot about his experiments. https://www.jeffgeerling.com/
I wrote about getting Debian running on a device based on a popular Rockchip SoC last year. I assume the kernel situation has improved since trixie. https://blog.kumio.org/posts/2025/01/bananapim7-hvm.html
Try running it on something like an older Celeron, a RaspberryPi 3, a PinePhone, or a constrained VM. For me alt+tab can take seconds on GNOME but still be almost instant in Xfce on the same hardware.
I assume it's from Wayland not performing as well on these platforms combined with fancy animated transitions being enabled by default on G.
It can be about not having to change hardware as much as about habits.
Don't you have like half of those already..?