Hacker News Reader

Comment by userbinator | Hacker News Reader

I'm not by any means a regular user of macOS but whenever I've had to use it, it's had the impression of a sleek and elegant face with much worse below the surface, and this is no different.

It makes sense to make a copy when you set an image as a wallpaper, but what doesn't make sense is to keep that copy (with an automatically generated unique name!?!?) even after another wallpaper is set.

But, looking at the "wrong way" and guessing at the implementation, I have an idea how this happened: "Share" makes a copy with a unique name, presumably to avoid conflicting with anything else, and then tells the OS to set that as the wallpaper.

I wouldn't even call this a "cache", but a "leak".

View on HN

Everything is a mess under the surface. It's more or less impossible to write something as complex as a modern desktop OS and keep all your code and behavior neat and tidy.

Maybe more things should have TTL capability in computing.

Like why did we have it for cookies and not localstorage or Indexdb?

Is there any filesystem with ttl support?

compost!

you could emulate that with $ find, but expiring stuff will require quite a mind-shift, I guess.

I do similar for mp3 recordings at https://codeberg.org/mro/internet-radio-recorder/src/commit/...

It's not really TTL that's needed here, it's a notion of file/directory tree priority integrated with the filing system APIs. Think about it: there's no reason not to use every single byte of your disk. The only reason we have to leave so much empty space as padding today and manage it so manually is because the OS itself won't automatically delete unimportant files when needed. If it did then apps could just generate caches with abandon safe in the knowledge that they'd be overwritten when necessary. Also, the user would always see the "true" amount of free space, i.e. actual space - caches - tmp files.

This is perfectly elegant. The desktop picture and the photos for it are segmented from the rest of the system in a container (similar to Virtual Locations on Windows) that the app can access instead of letting every random app access all your files at once without you having any control about it.

Regarding caching: generally, it's up to each individual developer (and sometimes even different teams within a company) to do this right. The only place where developers are 'forced' to do it right is '/tmp/' because that is supposed to get nuked every reboot.

that the app can access instead of letting every random app access all your files at once without you having any control about it.

That has nothing at all to do with this idiocy of using a different name every time, and not even thinking that it could be a problem to automatically create effectively "orphaned" files that no one would know about until it's too late.

It has everything to do with using a different name every time. Say you have incompatible caches, do you really want to deny your user the option to run two versions in parallel?

Reply on news.ycombinator.com