Kinda what prompted me to think about this. I started seeing some too good phishing emails recently.

Good point. It’ll have to have no access to the internet or anything local outside of its container. Just text in, text out.

Thanks for the heads up. This would have been a nasty surprise followed by unknown duration of hair pulling.

Another vote for Immich. Running it with docker compose is trivial. Been using it for 2 years now and it’s been glorious. Running it without docker would take more setup, not sure how complex.

Really feels like it. Look at the paragraphs and the list here.

Omacom Foundation launches with $18.5 million

It’s time to dream big. Omarchy Quattro has given people a chance to experience what the malleable computer of the future looks like, and they like it (a lot!). It now feels like a moral obligation to make this future more broadly available and fundamentally change how people relate to their computers for the first time in what seems like forever.

To do just that, I’m incorporating the Omacom Foundation to ensure that this mission is fully funded, durable, and ready to accelerate.

This nonprofit foundation will hold the trademarks, fund the infrastructure, promote the work, and support the open-source projects and developers Omarchy depends on.

These twelve Founding Patrons are each contributing $1 million to this mission:

• Tobi Lütke, CEO of Shopify
• Patrick Collison, CEO of Stripe
• Michael Dell, Chairman and CEO of Dell Technologies
• Jack Dorsey, Block Head and Chairman of Block
• Matthew Prince, CEO of Cloudflare
• Brendan Iribe, Cofounder of Sesame and Oculus
• Jason Fried, CEO of 37signals
• Drew Houston, cofounder and co-CEO of Dropbox
• Peter Steinberger, creator of OpenClaw
• Brian Armstrong, CEO of Coinbase
• Yunjie Dai, cofounder of TapTap
• Yours truly

These Founding Corporate Patrons are each contributing $1 million a year for three years or $1.5 million in tokens, with renewal by mutual agreement:

• DigitalOcean
• Meta Superintelligence Labs

That’ll be expensive so I don’t think it’ll be happening. They’ll be OK with collecting data from the 95% of their customers who don’t know how to block the TV from having internet access.

Good to know. I will make sure not to update as mine isn’t doing it yet.

This is true but it’s nice to have the whole app, data and database in one place, going together, snapshotted together, “backupable” together. It’s slower for sure. That said it can be reasonably fast with a large pool (more disks). With the magic of SSD cache, database reads fly and reads are the majority of the loads in my heads. In the future I would put root on ZFS as well and either do SSD cache or have root on ZFS SSD pool that gets send/recved regularly onto the spinning pool so it’s easy to restore when needed.

Thanks for the pointer. Checked, tried a couple others - they don’t know about it. They have some other non-random DNS records. AFAIK they can absolutely find it if they scan for all domains, but it’ll take forever if the name is randomly-generated and sufficiently long. Someone has to be determined to spend the resources. This doesn’t guard against that but against bots trying to fuck with the service at the port. I could move it to a wildcard though. There’s an overlap with another subdomain (they’re actually sub-subdomains and the first sub is common) but I could move that.

Hm. As far as I know that can only be done if AXFR is enabled (it’s not), if the domain has entered some search engine that has remembered it, through SSL cert that’s not wildcard, or through brute force lookup. Am I missing something?

It’s just an A record pointing to my IP. IP’s updated from my router via the DNS provider API.

Thanks for looking into it. As far as I read they moved to an ORM with 10.11 as a prereq to supporting other db engines. I’m guessing the db connection code would be undergoing major changes when they do that so I wouldn’t rewrite the current implementation. I’d either follow that work and help them get it right or rework the implementation after they’re done. We’ll just suffer through the mean time. 😄

64K is generally small recordsize. For media they recommend 1M. My db was sitting on the default 128K recordsize and perforned fine on 10.10. It doesn’t matter much for reads because ZFS keeps it in RAM and if it gets evicted it goes into SSD cache (l2arc). But for writes the cache wouldn’t help unless I disable sync which risks data loss. I don’t think 10.10 did much writes during lib scan so write perf only mattered when something changed.

Not sure if this is the problem I was hitting with my Home Videos library type. It’s got directories with YouTube videos. I tried re-adding it in 12-rc3, which was released a month after the nightly mentioned in the issue thread. Still couldn’t complete. I ended up re-adding the media as Shows library. Works okay with the directory structure I have.

That would be reasonable. I did repeated rescans and only counted subsequent rescans. For me the initial scan after upgrade took a bit more but not hours. Subsequent scans took less. E.g. 20min -> 13min for write-optimized filesystem. So that’s reasonable, although 10.10 was way faster. Library scans are expected to get faster in 13 according to some Github threads I read.

When I had the broken Home Videos library I waited 3 days for the initial scan to complete and it did not. Repeated rescans did not seem to complete although I didn’t wait 3 days for them. I’m not taking into account those scan times. Something was wrong with this library type on 10.11 and/or my media. Worked fine on 10.10.

Do you mean the SSL cert? Yes, that’s wildcard on *.mydomain.com. Then the subdomain is kvtn4ftxfreurdcw7qtr21mcywxaqqm.mydomain.com.

I came up with a funny strategy I use to lock it down a bit. What’s exposed to the internet for me is Apache2 reverse proxy. The proxy is locked down to reject all connections EXCEPT for the ones coming from a special subdomain which is something like a 64-character long random string. This prevents pretty any unwanted connections. Obviously the special subdomain must remain as secret as a shared password among the Jellyfin users. It works for trusted users.

What I want ideally is an “authenticated firewall.” OpenWrt rejecting all connections on the open port except for an allowlist of IPs. Then there must be a system where users can authenticate and their IP is added to the allowlist. I haven’t found an off-the-shelf solution like this but I’ll make it some day. Too bad I figured this random string subdomain trick cause it seems good enough for now. :D

600MB. Would that require changes to Jellyfin? They’re on the path to introducing Postgres support.

Complications, yes!