It totally is. I don’t remember where I heard it from but there’s a saying that all poverty is energy poverty. Not enough food for your citizens? That’s because you don’t have enough energy to run the Haber Bosch process for fertilizer production.
Please don’t take this as me saying you were wrong to ever trust Apple, however the best way to organise any data is usually just files on a disk.
That’s becoming a recurring theme for me and even some of my corporate clients now. Confluence, for example, is out the window for secure documentation around sensitive environments and Word Docs in One Drive are back in. It’s surprisingly refreshing and gets the job done way better.
From what I recall, aperture did use files-on-a-disk, maintaining original photos read-only and letting everything else be operations on those originals.
Agree with all of this, apart from possibly OneDrive but that's for another post.
Not Apple-specific really that point for sure anyway. Personally I don't think we should ever ever trust any vendor to control our data or act as a proxy for access to it. If it's not on a physical disk in your hands, in a format which is documented and can be opened by more than one application, then you're one step away from being screwed. There are so many tangible risks we love to sweep under the rug from geopolitics, commercial stability, security, bugs to unexpected side effects. And I've seen some real horror stories on all of those fronts.
At the same time I managed to embed myself thoroughly in it and I'm 3 months in to undoing the mess. It's VERY hard to get back to files on disk. No moving away from that is probably the best option I suspect a lot of us never took.
Hardest stuff to get out of is iCloud/Apple and Adobe.
It's all true, but if you think organizing photo archives is easy, boy have I got news for you.
Metadata, versions, version groupings, projects, albums, there is lots of structure that most people don't realize exists.
Think every picture has an EXIF date and that's the date when it was taken? Think again. Scanning date is not the same as picture date.
Actually, even if you think of a date, you probably imagine the usual ISO8601 2026-01-14T17:37:46Z date — how about when we only know a year? This is something Aperture didn't do either, but when dealing with photo archives what you want is arbitrary precision date intervals. E.g. 1900-1902 for example.
Anyway. Just pointing out that even though "just files on disk" is the right approach, managing those files and their metadata is far from obvious.
You’ll set yourself up for success if you check the dependencies of anything you run, regardless of it being containerised. Use something like Snyk to scan containers and repositories for known exploits and see if anything stands out.
Then you need to run things with as least privilege as possible. Sadly, Docker and containers in general are an anti-pattern here because they’re about convenience first, security second. So the OP should have run the contains as read-only with tight resource limits and ideally IP restrictions on access if it’s not a public service.
Another thing you can do is use Tailscale, or something like it, to keep things being a zero trust, encrypted, access model. Not suitable for public services of course.
I started using my IT and data management skills on film sets to provide data security around the footage. It’s been a breath of fresh air to use advanced concepts in a field that’s very hands on and a big team effort. A lot of communication and working together. It’s been great.
The original, unedited version of the grandparent was bemoaning the lack of vendor support behind FreeBSD so the parent's comment made a lot more sense in-context.
Firstly, FreeBSD already supports x86 Mac Minis. Servers? M-series Minis and Studios are very good servers. Lastly, FreeBSD has an Apple Silicon port which has stalled.
reply