just_another_person@lemmy.worldtoLinux@lemmy.ml•Daemon that kills processes using too much CPU
2·
5 hours agoIt’s not the CPU. All that will do is consume CPU and raise your energy bill.
It’s not the CPU. All that will do is consume CPU and raise your energy bill.
In general, it’s not an out of control CPU that’s going to halt your machine, it’s memory loss. If you have an out of control process taking too much memory, it should get OOMkilled by the kernel, but if you don’t have proper swap configured, and not enough memory, it may not have time to successfully prevent the machine from running out of memory and halting.
I’ve made a few, but they were quite specific in their purpose. The esp32 ecosystem is pretty great for this purpose, but generally I find people won’t take the time to fuss around with making their own anything when off the shelf varieties are cheap.
You’re describing a CDN. You can’t afford it.
I’d look more into boosting whatever your uplink is versus trying to distribute to localized users.
Well, firstly, it’s not what Tailscale is meant for. I’m getting downvoted by the people using the wrong tool for the wrong job.
You don’t install a VPN on all your local machines just to talk to each other. That’s insane. You especially don’t install one that, while misconfigured, is sending all of its traffic OUTSIDE of your local network, then back in. This is what Tailscale on a number of local machines will do by default.
The way Tailscale works is by installing a Wireguard client on a machine. It then checks in with their DERP servers to figure out it’s network situation (behind NAT, peers in the network, routing tables…etc). So when you have more than one client on the Tailscale network, it automagically assumes some things, the first being that these two machines dont have a more direct route to talk to each other.
So then it will attempt to bridge a path between the DERP server each client is checked into, and pass traffic that way. Which means you then have two machines on the same local network sending traffic OUTSIDE of that network, then back in to complete a VPN network.
This is stupid.
You setup multiple different networks and use exit nodes to bridge two networks together with Tailscale. That’s the entire point. This means setting up routes to let the orchestration layer know that a set of certain machines exist in the same network, and shouldn’t use Tailscale to communicate with each other. Then it will only be using routes for REMOTE networks, where other clients exist, to pass traffic over the Tailscale network.
May I ask what you were planning on doing with Tailscale? I can point you in the right direction.
https://gist.github.com/camullen/0c41d989ac2ad7a89e75eb3be0f8fb16
Just cut Windows out as much as possible and run everything in WSL. Setup everything to boot straight to all your WSL layers, and aside from the absolute shit Base OS, it should be the same.
Yeah, it’s just a simple scheduler. It’s not doing anything fancier than that unless you setup other automations for it to do so. It’s pretty much the same thing you can get from the thermostat itself, so no real reason to run it from HA unless you’re making it pay attention to other sensors or rules.
The thermostat and Ha operate independently, so if you happen to accidentally have some schedule or rule defined on the thermostat itself, it will still execute. Check that first.
Next, you need to check your event and trigger logs for your defined schedule or rules and be certain about the if/when they are/aren’t firing. It should be pretty clear what’s going on there, and if there is a potential time zone issue with this package you’ve installed.
Move your Nginx pets to something else. Pretty simple.
Okay, but give a little look into where your disk is using space.
du -hsc /
And work from there.
It depends on where that storage was used. Some details would be useful.
At its core, you shouldn’t need to keep any previous layers than the one you’re using for the OS.
You also technically don’t need snapshots for anything but your personal file space.
I’m not sure what you’d like here. You didn’t give much info.
Did you want someone to literally work out a full config for you in here? We don’t know what you’re even running.
This is just basic network routing and subnetting.
Not sure what the Frame means with any of this. It’s going to be running the same stack as Deck, which is KDE. It’s also not going to be any sort of headset for your PC, at least at the outset.
As for your other Dr questions, it’s all just personal preference. The Desktop is just window dressing on a compositor and window manager anymore. If you’re comfortable without all the system helpers and convenience of using either Gnome or KDE, you can just run a WM like Hyprland or Sway instead.
If you’re not comfortable using SSH, each Linux DE comes with its own RDP setup, so refer to the docs of whichever you’re running to set that up if you want things to be super simple.
Past that, there’s tons of stuff, but I would generally avoid VNC these days because it’s pretty much a dead protocol that is insecure and inefficient.
Some people prefer to use RDP compatible tools, some people just use Moonlight. You can use whatever is comfortable for you, really. I would avoid all the suggestions that are telling you to install the giant constructs like Mesh Central though. That’s overkill for just two machines here.
I hate having to continuously point this out, but DO NOT DO THIS unless you have a deeper understanding of networking.
“Just installing Tailscale” without proper configuration of the default routes is going to cause all kinds of routing inefficiencies and loopbacks in your internal network that is absolutely unnecessary, especially for what OP asking for.
This is just bad advice.
If you’re solely talking about Caddy using self-signed, just use the caddy directory created for this. Should be simple.
The global /etc/SSL dir is locked down for a reason, and you shouldn’t relax permissions there just so Caddy can get to subdirs.
Frigate isn’t a resource hog unless you enable the inference and classification stuff. If you don’t need that, and are only running 2 cameras, it should be fine.
Shinobi is another option without all the advanced junk you may not need though.
Need more details here:
OBS and Owncast should allow you to do this for the most part, but it’s heavily dependent on all of the above.
HA is definitely the largest adopted. OpenHab is probably more geared for developers, but has a more concise and powerful automation system.
As for hardware to run it on: get a cheap n100 Minipc and be done with it. Uses 6-12W, and it’s going to miles.kore efficient for this use than a regular PC.