In German you use en-dashes with spaces, whereas in English it’s em-dashes without spaces. Some people dislike em-dashes in English though and use en-dashes with spaces as well.
In English, typically em-dashes are set without spaces or with thin spaces when used to separate appositives/parentheticals (though that style isn't universal even in professional print, there are places that aet them open, and en-dashes set open can also be used in this role); when representating an interruption, they generally have no space before but frequently have space following. And other uses have other patterns.
In British English en-dashes with spaces is more common than em-dashes without spaces, I think, but I don't have any data for that, just a general impression.
git absorb works surprisingly well. I was quite skeptical in the beginning, but it really turned into something I used daily (until I switched to jj, where I haven't found a replacement yet). If you use stepwise commits I can really recommend it.
small edit: It seems that jj supports `jj absorb` now as well. Wonderful!
Indeed, though I don't think it can create fixup commits if that's what you're looking for. However, it might work great for that if you pair it with jj-spr: https://github.com/LucioFranco/jj-spr
Yes, depending on your highlighting scheme. Not every highlighting scheme shows this by default, unfortunately.
To me, this seems initially like some very minor thing, but I find this very helpful working with non-trivial code. For larger methods you can directly discern whether a not-as-immutable-declared variable behaves immutable nonetheless.
Other than that they shouldn't have a big advantage for a more professional user with unique, long, and random passwords. For the common user it should be a great upgrade, giving all these advantages with better UX.
I'd say that the basic sailing knots should fit your bill pretty well. I can't recommend an online source, but you should find plenty resources on Youtube. It shouldn't take longer than an evening or two to learn them.
Wireguard does not re-resolve dns when your dyndns ip changes. This ip change is common in parts of Europe where it usually changes daily. To circumvent this you need a jumphost or similar. This again brings additional issues when you don’t want to go through the jumphost when at home (I use nftables-magic on the router, but it’s not very nice).
ISPs do give enough where I am the issue is usually when you are behind 2 firewalls past that or have VMs that you want to DHCP, things like that.
A real world example my ISP provides /56 at the router level but if you put a firewall behind it, that gets a /64 (cannot be changed). Now the firewall cannot further delegate prefixes since it's already used. Some firewalls allow RA pass-through but in my case this wasn't an option so I had to set up NAT66 (non-standard :/) just to get outbound ipv6 connectivity.
Modern CPUs are mostly limited by their energy budget/heat and smaller cores are more efficient. Also, if you have a workload scaling to, say, 8 cores chances are good that it also scales to 20+, allowing the usage of many small cores. Hence, having a few fast and then several smaller, more efficient cores should be also useful for workstations and servers.
For a networked Time Machine restore you can reinstall MacOS without restoring first and then use the migration utility to restore from a remote Time Machine. That seems to use a different smb binary which works. Still, I find it infuriating that restoring, one of the most important things you do on a machine, is broken and was not caught by QA.
