GetAwayWithThis

"I am drinking my own piss and don't undersrand why others woudn't"

The massgrave site has a faq entry for this. According to them it's only a cosmetic bug and microsoft will probably patch it.

I'm sorry, how many recipes do you need for air frying food? It controls temps and time. What other variable is there to warrant app connectivity?

Phone or walk up to helpdesk, they open one for you.

I have a domain registered that I use, just didn't feel the need to mention it exactly. Hence why I anonymized my results. I did not change anything that would alter the troubleshooting steps, only the domain name and ip addresses are generic but otherwise consistent.

The domain and records are set up correctly on the provider end because I receive valid let's encrypt certs for my subdomains through caddy. The issue is only with Fedora. I checked a live of ubuntu and fedora iso on a second computer. Fedora consistently cannot resolve the domains on the default configuration while ubuntu and anything else I tried can.

I just tried adding the local IP:Port and the app.domain.example to the /etc/hosts file as the examples show. Restarted systemd-resolved but no dice. Ideally, I'd like to make this family friendly and avoid having to make client specific configurations anyway. So far only I run fedora at home, so my device has this issue only. I am partial to the OS otherwise, so I was hoping I could solve this.

EDIT Sorry about that it dawned on my what you asked for really. From the resolvedctl results DNS Domain: domain.local would be mydomainname.local. Yes I kept .local in the search domain fields for most of my things. Is this something that matters, or could this be a workaround if I changed it to my actual mydomainname.tld? As far as I undertand this would work if mDNS was on. Not sure if LLMNR makes use of it the same way.

It's due for a head gasket change, not much else. Not worth upgrading to a newer car for my price range and use case. I don't need a computer I don't own.

They skirted around it on the official doc. They didn't explicitly say not all 6a devices are affected. They instead say if yours is affected, based on where you got it from and what are the laws in your area, you might be eligible for compensation or free repair.

It is entierly possible that hardware lottery is in play and some batts are feom a different supplyer. From what I gathered.

I think google is banking on the fact that despite all this, people will stay with them and give a very slim discount. But only once they complained loud enough. The do trade-ins all the time.

The thing is, bi-yearly phone replacements are not needed for most people anymore. Recent mid range phones can last double that.

Performance is good enough with modern SOCs. And new sets don't have new essential features, so keeping them alive for cheap is a no brainer for most. Especially if support is promised.

If this is a safety issue, google should issue a recall and pay for the mistake by replacing your battery for free. It's their design flaw. Also don't promise 7 years of support if you brick the device 2 years in.

Thanks for the feedback! I am doing the opposite right now funnily enough. Trying to move away from having everything on Truenas as an app because of the host-app communication limitations. I have a bridge network set up but it still has its issues.

I'll need to get some hardware to make this happen. At least to have a PCIe SATA controller I can pass through to a TrueNas VM so I can have everything on one physical host.

Nextcloud is on the list to try. For now syncthing was fixed up for filesync from my shoddy implementation of it yeras ago.

How's your Nextcloud holding up now? I am undecided between a separate host vs the Truenas app. I heard that the TN app likes to break on update but I didn't have the time nor infrastructure to test it thoroughly yet.