“offloading”

Volume does not implement both maxFileSizeInBits and maxFileSize, while one of them must be implemented. Implementing this didn't seem to change the result. But I definitely do need to fix the sample FSKit project I've been copying as a base for all of these bug reports, then! Have you looked at what the actual block size of that device is and what FSBlockDeviceResource.blockSize is? Both physicalBlockSize and FSBlockDeviceResource.blockSize are 512 on the disk image. However, there are other issues. Your testing with a disk image, but the disk image block size is 0x200/512, NOT 0x1000/4096. If you’re looking at those values from the volume side, you may get 4096, but that's because the volume changed what stat returned, not because it's actually true. ... In your particular case, this also means that the stat value you're returning is 4x larger than the underlying FSResource size. That isn't necessarily wrong, but that's because the VFS layer will basically believe anything you tell it, not because that's wh

Thanks so much, @tbartelmess1—this is super helpful, and really appreciated a bit more context from our app: App context (what we store) The blobs we persist will be user-generated cruise photos, we would downsize those to more manageable size as iphone format photos can be quite big, but they would still be in the 1-3 mb after downsizing Realistic volume per active user: a few hundred images/year; heavy users could reach low thousands over time. Decision: use Core Data Binary Data + “Allows External Storage” We’ll keep originals as Binary Data (Allows External Storage) so Core Data handles externalization transparently, my philosophy has always been to offload as much work to the system services as possible. We’ll keep thumbnails as well inline in coredata (let coredata decide but likely will be inline (blob)). CloudKit mirroring We’ll rely on NSPersistentCloudKitContainer mirroring; we understand CloudKit decides when an attribute becomes a CKAsset independently of Core Data’s externalization thres

Oh, there are so many pitfalls here )-: The System keychain is a filed-based keychain. To modify it you must have file system permissions to change the file. That means running as root. Using sudo for this is tricky because of execution context issues. There are two relavent bits of execution context here: BSD and security. The sudo command changes the first but not the second. That can result in a lot of ‘fun’ edge cases. In this specific situation I think the only relevant edge case is the default keychain, which is easy to work around. However, keep an eye out for this in other situations where you use the security-related APIs from sudo. Note TN2083 Daemons and Agents talks about execution contexts in some detail. File-based keychains use an access control system based on ACLs. If program A adds a keychain item and program B tries to access it, one of two things happens by default: If B is in a GUI context, the user gets a dialog asking whether to allow this. If not, the access fails. Your -T argument is

This answer is for home routers. Much of the bufferbloat on the internet is on the home router and ISP head ends. There is only so much you can do end-to-end - and the advice in the video is primarily targeted at LTE <-> server interactions. Definitely take a hard look at your server behaviors as I wrote above! I've written a lot and given many presentations on the bufferbloat problems in the typical home or office network, one of the more amusing is here: https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/ To improve the ISP link... encourage your customers to get better home routers with Smart Queue Management (SQM), and fq-codel for the wifi. It's universally available from third party router firmwares like openwrt, dd-wrt, merlin, and tomato. It's also available for most gamer routers (netduma calls it anti-bufferbloat), it's the premier feature of the evenroute (eero also), ubnt's edgerouter products and the udm pro also have sqm. IP fire, tangledOS also, it's a really