Removed by mod
Removed by mod
While this is technically true, there is no provider on the planet that can freeze state of RAM in a way that would be useful for this.
It’s technically feasible to recover data on a laptop’s RAM, but not from a virtualized multi-tenant instance tied to a specific user.
Handbrake or VLC. I’d honestly just learn the CLI to make this work better for your benefit though. Much simpler to do remotely if you want changes.
Same deal. They’re now switching to SteamOS, so will have kernel drivers soon.
That’s really a driver issue from the manufacturer. If ASUS wanted, they could have pushed a proper kernel driver a long time ago. They bet on Windows for some reason though 🤷
https://docs.datalust.co/docs/collecting-docker-container-logs
You have a formatting issue. Solve for that instead of just switching to something else hoping it will get better.
I’m not sure what you mean. You either need to post a lot more details and information about your setup, or you need to read and understand the Tailscale docs.
For all traffic. Tailscale ACLs deny by default. If you’ve never changed them, you need to do that.
You need to adjust your ACLs to allow traffic over Tailscale.
And multiple failed consoles since they took it over.
If the application supports an API of some sort, you could run OCR, then send them over API as converted input.
If the apps don’t support them, then no.
If the apps don’t support them, then no.
If you don’t want to expose port 80 or 443, then just change the ports they are running on. Right now you’re mapping 80/443 in docker, so just change those numbers to something else if you don’t want to use them. The number on the right is the internal service port, and the left of the colon is the port you’re opening to proxy to the port on the left. Adding Caddy does exactly the same thing and serves no purpose except another layer of obfuscation you don’t need.
You’re missing the point of Caddy, and your ports are all wrong. You don’t need it if you’re already exposing ports via Docker to 80/443. Remove Caddy.
Run a livecd of whatever Linux distro you like, and get a USB drive. Store persistent files on the USB stick.
Hence the downvotes.
A solar cluster and whole house battery bank would do this for the majority of the day. You need to hook it into your AC circuit with microinverters, and then have a circuit switch to handoff power back and forth. You’d at least be sure to run off solar during the day.
You could probably use yours for the same, but you need that AC transfer circuit into your breakers. Never do anything like this without an electrician.
This is a beginner. I wouldn’t try to overcomplicate it.
I’m not talking about snapshots. I’m talking about viewing the RAM of a running instance and having that be useful for anyone who managed to get it. And let me give you two simple reasons why it’s not going to be useful:
Unless you were to go and be on that instance at the exact moment something was happening (or shortly thereafter), that memory is going to be useless.
Now, if someone were absolutely stupid, disabled CPU security extensions at the Hypervisor, AND did something like make a RAM disk and stored something on that-which is really just going out your way to leave a trail-then yeah, maybe you’d get something.
The default of every hosting provider I’m familiar with is encryption by default on absolutely everything from the Hypervisor up except the disk, so I’m seriously doubting the claim of OP unless there is otherwise non-TMB information.
Disk snapshots are another story if unencrypted.