I thought it worked just fine on LTSC 2021 (21H2)

I think it could be interesting to explore Universal Blue based distros such as Bazzite for this kind of use cases. The OS comes from a standard OCI container image, which means you can create your own customized one by layering changes on top of an upstream base image.

I feel bad for the unsolicited distro plug though especially since you already have a solution that works well and you are familiar with, but I thought it might still be useful to mention it. I'm not sure if uBlue would even be better vs your current setup. Seems like netboot would still be needed to get the latest version without an extra reboot.

It seems this vuln was already publicized in june, or is that interview from earlier?

> For a lot stuff on my local network I don’t want the hassle and there are loads of use cases in local networks for normal people to just have port 80 no certs on something like 192.x.x.x because there is no easy way to set up public certificates for that and I don’t want everything hostem on cloud - some stuff I want to still host for myself in my local network.

Tbh I don't see what's hard about this. All you need is an A record pointing to your 192.x.x.x, acme capable dns host and a modern reverse proxy. You can even use a free ddns service if you want. Wouldn't bother with this for development, but anything hosted for longer than a few days absolutely yes. Imo not getting browser warnings is alone worth the few minutes it takes nowadays.

“ All you need is an A record pointing to your 192.x.x.x, acme capable dns host and a modern reverse proxy”. That’s a LOT more than socket(), listen(), and accept().

> All you need is an A record pointing to your 192.x.x.x, acme capable dns host and a modern reverse proxy

And to distribute keys that allow those appliances to update the DNS records, to secure those keys, have an a way to install those keys (and update/rotate them), and make sure your DNS host is supported by your acme client.

XD

I can yeah it is easy but I have 20 years of experience.

I don’t want to spend time setting that up.

For less technically capable people you just lost them in first sentence.

> But also, rewriting history only works if you haven't pushed code and are working as a solo developer.

Weird, works fine in our team. Force with lease allows me to push again and the most common type of branch is per-dev and short lived.

I like that Zig allows using relaxed floating point rules with per block granularity to reduce the risk of breaking something else where IEEE compliance does matter. I think OpenMP simd pragmas can be used similarly for C/C++, but that's non-standard.

You can do the same thing with types or the wide crate. But it isn't always obvious when it will become a problem. Usung these types does make auto vectorization fairly reliable.

C++ lambdas can be used to achieve a similar result, not as pretty though https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines... But in general I agree!

The fact that you can't return from there makes for a huge difference, though,

Tangential but funnily enough calling std::expected::error is ub if there is no error :D

This is exactly where Bazzite is convenient since it comes with the latest drivers (including 32-bit) out of the box.

I have used this setup for 6 years or so with KeePassXC and it's fine. Just being mindful of not editing stuff on other devices before the first one has had the chance to sync has been enough to avoid pretty much all sync conflicts. I have only had to resolve those a few times so far, iirc my android client was misconfigured at the time or something.

I still recommend Bitwarden for password management for any "laypeople" since it will just work. Also worth noting that the basic functionality is free.

I do something similar with Syncthing, except I use pass and go-pass on my and my spouse's devices. Those utilities store their data in a git repo already by default, but rather than syncing those repos directly, I have set their upstream remotes to local bare repos which is what Syncthing actually syncs. This avoids contention internal to the git repos which I could see causing some problems through normal git operation and the actual sync between devices should be mostly atomic.

(go-)pass automatically does a push/pull due to several operations which keeps the password store in sync and Syncthing does its thing with the bare repos.

This has reduced my maintenance burden on my spouse's devices down to practically zero. The worst case to fix things is I need to `git pull --rebase` in the bare repo. The pass repo format uses individual encrypted files for each password entry (for better or worse) so I have yet to run into a conflict in the same entry.

Why not just push/pull git branches normally? I had previously been doing that but if you want devices to sync that may not always be online, then you must involve an always online git server (which isn't a great idea due to one of pass's weaknesses).

Even when you do get a sync conflict, Syncthing will rename one of the copies and then you can have KeePassXC merge the two files back into one. So that's still pretty much hassle-free.

Probably due to Obsidian's aggressive autosaving, I did cause a syncthing collision my first day by clicking into a note that I was editing on my other device. Kinda wish desktop Obsidian had a save system more like code editors and less like smartphone apps.

I suppose I can avoid the issue with some discipline.