I think it’s because of the frame reaching half a mm or so above the screen and the battery cover opening up when I drop it.
I don’t know where and I don’t remember when but I’ve seen some investigation that phones with detachable covers and batteries survive falls better because those moving parts disperse the energy of the fall better, instead of all the shock going into the next stress point - the screen or the glass on the back
I don’t intend to overly nit-pick, but since OP said themselves they are new to this: Wine doesn’t translate the exe. It translates system calls from Windows ones to Linux ones. So to have an example: opening a file would be some system call in both systems. But, of course, different because the OSes are different. An exe would be calling Windows one. What WINE/Proton do is get that call and translate it into Linux system call, so that .exe can still open a file, as if it was running in Windows
As for OPs question: AFAIK when using dx11 you will still in the end be using Vulkan, just through DXVK (as this comment said, translates dx calls into Vulkan calls). Theoretically setting to use Vulkan in the game itself might have less overhead (no DXVK in the middle) but it’s a mixed bag in my experience. I think that Windows Vulkan support is just not yet there, so the in-game code for Vulkan is so-so.
I second this: you have to check on which setting each game works better
Might be! It’s just that having a container like that feels easier than looking after bare-metal secondary db
Maybe I’ll just pg_dump during Nextcloud maintenance window and get into BorgBackup putting the dumps on NAS? If I have to revive the db from the dead, I’ll probably just use the dump anyway, so that’s one hoop less
2nd DB would be on the NAS but its not being used by the app, so as long as it’s asynchronous writes, you should be okay
But then I have to maintain it too. And it will be using RAM that was supposed to only be for servicing RAID. On a platform where RAM can’t grow
For sure my setup will be growing and changing with time. But ATM this “prod” db lives only on laptop’s SSD
replication in the database it self
AFAIK db replication would require running another db on NAS. Which I tried to avoid
I have another cronjob that takes a backup into the first database docker init folder. Older backups end with -date so they won’t get picked up by the init script. You can do similar with just docker.
Yeah, that’s why I’m thinking to do. Have a container that watches changes to db data and rsyncs those into the NAS for safekeeping. My main goal in all of this is so db data won’t die with laptop’s SSD
For steam you need to run a second opentrack inside the container. There’s a writeup somewhere in opentrack issues for that
Edit: https://github.com/opentrack/opentrack/issues/1260#issuecomment-881908297
Oh, that’s interesting! Sounds a bit crazy but I’m interested in what you find out :D
I wonder if in this case VMs don’t make it work better. There is another layer between the process and NFS than pure docker+volume
db running on the Pi with storage on the Pi could be faster than the db running on the laptop with storage on the Pi
I think so too, but I’m mindful of the 1GB RAM per TB rule. I’m afraid to choke the NAS and on Pi I can’t put in more RAM
keep the DB on the most powerful CPU and quickest disk
Thing is, I expect that NAS to be faster than the SSD on the laptop that runs a bunch of stuff. Even NC log file will take up some IO
But I get the point you are all making here, I’m changing course :)
it’s generally not a good plan to put anything that needs realtime access remote to the device processing it
So in your opinion putting whole nextcloud_data as NFS mount is also a bad idea? Keep NFS as external storage and/or only user data?
AIO docker
It was too blackbox to me. I had some issue and found it hard to debug. fpm+nginx is more my speed
This BorgBackup app is available only in AIO?
You can easily just try it out though
Yeah, but if that setup leads to problem in a few months, I won’t catch that. That’s why I decided to ask and judging by the other answer, I dodged a bullet here
Now I’m thinking of setting up something like this. Maybe even in another container? One volume with data bound, one with NFS and a bunch of scripts in entrypoint to rsync(?) between the two on inotifywait. There is lsyncd but it’s been unmaintained for two years now
Well, they only say they won’t work on it. But can we keep it alive as community without forking?
I hope Logseq OG will be accepting PRs. I’d hate to go back to Obsidian
I know that it’s solved by now but I’d like to propose another approach to solving such issues
"$@" in the shellEDIT: apparently there’s also this
I swear, this guy is all over the place. I’m very curious as what he will end up
Oof, my lab is lightweight compared to yours but I’ve been thinking of putting up a grafana for mine too. Would you mind sharing how much resources it takes to run and roughly how much storage does, let’s say, a month of data take? I know that it all depends on what one puts inside but just as a reference point