Disparallel

Getting more thinking time tends to give surprisingly small improvements to playing strength. For a classical alpha-beta search based engine, for a given ply (turn) you might have ~20 moves to consider each depth of the search tree. If you're trying to brute force search deeper, a 10x increase in compute time or power doesn't even let you search an extra ply.

Elo gains for engines tend to come from better evaluation, better pruning, and better search heuristics. That's not to say that longer search time or a stronger CPU doesn't help, it just doesn't magically make a weak engine into a strong engine.

The help section article lists

# Data that isn’t protected by the VPN

Not all network data from your device is protected by the VPN. Examples of data that aren’t protected by the VPN include:

- Tethering traffic

  - This includes USB and Wi-Fi hotspot.

- Push notifications

- Wi-Fi calling and other IMS services

- Work profile app traffic

  - This applies if a work profile is configured on your device.

- Data traffic from an app that routes traffic directly over the Wi-Fi or a cellular connection

All of which make sense to me except push notifications. My guess is they might mean syncing notifications to e.g. a watch.

KeepassXC has built in db file merge support! It's hidden somewhere in the menus. I've never personally had to do something more complicated than "I added a new entry on two different devices before syncing" but it's worked well for me so far.

I think the interpretation intended there is that if you hand a representation of a file to a tool, it needs to be immutable.

The representation likely is full of string refs and pointers to the actual data in memory to prevent egregious copying, and the caller of the api should not be able to modify the data structure they receive and accidentally modify the actual file unless they do so through an api intended for it.

Nothing to do with copyright, more that swift-format or your lsp integration should never accidentally modify a file without user initiation.

It depends on what you're doing. Swift Foundation is cross platform for Windows/Linux/macOS and exposes apis for things like file systems, paths, process creation with the caveat that what a "Thread" is or what it means if a file is executable is a little different between platforms. If you're writing a cli tool you should be able stay mostly within the Swift stdlib and Foundation and that'll work on all platforms. As more libraries are ported to Windows (e.g. hopefully swift-nio), that should become more and more the case.

Where this isn't the case would be if performance mattered, some of Foundation system api implementations (at least, the Windows ones) can be a little inefficient since the Foundation api model and the Windows way of doing things doesn't always match and the Windows implementation has to do extra work to match the semantics.

Another would be UI wise, I haven't heard of plans for Apple to open source SwiftUI. Though since Swift can call into the native platform apis, it's quite possible to write a (perhaps not as slick) alternative.