

lol I started to reply, suggesting a recommendation feature to help find non-algorithmic tech feeds but then realized that’s exactly how all this started.


lol I started to reply, suggesting a recommendation feature to help find non-algorithmic tech feeds but then realized that’s exactly how all this started.


While I support the idea of using RSS readers to break free from algorithmic and/or AI curated feeds, I’ve mostly stopped bothering, since all the content that gets into the feeds has become algorithmic, AI slop.
There’s just no escaping it these days.


missing a way to find out what they do without installing them
At the very top of the project page it says:
Termix is a web-based server management platform with SSH terminal, tunneling, and file editing capabilities.
Now you know what it does without installing it


You’re confusing a lack of handholding with gatekeeping.
beginner friendly solution, something with a UI, fewer manual configs…
First, you’re not entirely right. you can get a ton of self hosting done with things like Synology or Home assistant, and never see the complexity. You might get owned by a botnet, but it “works.”
Self hosting securely has a steep learning curve, there’s no way around that. What you’re asking for is for someone to write programs that’ll let you skip the learning curve.
GitHub is littered with abandoned attempts at doing this. You bury your lede by mentioning “your project” at the end. It’s your project going to be another well intentioned attempt that’s eventually abandoned or causes more problems than it solves?


in Powershell, yes. the cmdlet naming convention is Verb-CamelCase.
Only specific verbs are allowed as well. It works if the convention is broken, but it’ll complain when you import them as a module.


At some point you had to learn all about debugging the overly-complicated and annoying OS that runs your full installs, didn’t you?


per the searxng container instructions:
Understanding container architecture basics is essential for properly maintaining your SearXNG instance. This guide assumes familiarity with container concepts and provides deployment steps at a high level.
The fact that you’re logging into your container to manually edit your config hints that you need to read more about managing containers.
Make sure you’re editing the file that you’re mounting on the host, and edit it from the host.
Have you checked the actual log with podman logs? It’ll tell you what it’s doing about its config.
Why do tape drives seen to be best? What’s your use case? They’re still used in enterprise environments because they’re insanely dense compared to hard disks, and it’s real easy to load a truck with a few petabytes to ship elsewhere. Is that what you need? Density? Seems like not for just a few gigs.
If you want backups you need to ship your media, tapes or otherwise, off-site.
Pop your files into a cloud service and call it done. If you’re looking for long term archives and don’t want to use other people’s computers, burn some DVDs and store them at someone else’s house.


no. Arp bridges layer 1 and 2. It’s switch local. With a VLAN, it becomes VLAN local, in the sense that 802.1q creates a “virtual” switch.


Broadcast traffic (such as DHCP) doesn’t cross subnets without a router configured to forward it. It’s one of the reasons subnets exist.


What in the world is “a proprietary OS I cannot trust”. What’s your actual threat model? Have you actually run any risk analyses or code audits against these OSes vs. (i assume) Linux to know for sure that you can trust any give FOSS OS? You do realize there’s still an OS on your dumb switch, right?
This is a silly reason to not learn to manage your networking hardware.


A VLAN is (theoretically) equivalent to a physically separated layer 2 domain. The only way for machines to communicate between vlans is via a gateway interface.
If you don’t trust the operating system, then you don’t trust that it won’t change it’s IP/subnet to just hop onto the other network. Or even send packets with the other network’s header and spoof packets onto the other subnets.
It’s trivially easy to malform broadcast traffic and hop subnets, or to use various arp table attacks to trick the switching device. If you need to segregate traffic, you need a VLAN.
Edit: Should probably note that simply VLAN tagging from the endpoints on a trunk port isn’t any better than subnetting, since an untrusted machine can just tag packets however it wants. You need to use an 802.1q aware switch and gateway to use VLANs effectively.


What you are asking will work. That’s the whole point of subnets. No you don’t need a VLAN to segregate traffic. It can be helpful for things like broadcast control.
However, you used the word “trust” which means that this is a security concern. If you are subnetting because of trust, then yes you absolutely do need to use VLANs.


deleted by creator


deleted by creator


deleted by creator


deleted by creator
deleted by creator


The answer to your overarching question is not “common maintenance procedures”, but “change management processes”
When things change, things can break. Immutable OSes and declarative configuration notwithstanding.
OS and Configuration drift only actually matter if you’ve got a documented baseline. That’s what your declaratives can solve. However they don’t help when you’re tinkering in a home server and drifting your declaratives.
I’m pretty certain every service I want to run has a docker image already, so does it matter?
This right here is the attitude that’s going to undermine everything you’re asking. There’s nothing about containers that is inherently “safer” than running native OS packages or even building your own. Containerization is about scalability and repeatability, not availability or reliability. It’s still up to you to monitor changelogs and determine exactly what is going to break when you pull the latest docker image. That’s no different than a native package.
Self signed for this use case is fine. you know and trust both ends of your connection, and no one else needs to know or trust either end of the connection.