Two of six screenshots show the app. So the rejection fits the rules and is easy to understand. I often agree with complaints that Apple's rejections are unclear or problematic, but this isn't one of those cases.
And I'm kind of confused by these screenshots as well, since there are lines between them, as if they're one screenshot. And the labels over the screenshots are nonsensical and graphically glitched.
I think introducing unpredictable new prohibitions is a much bigger problem than the specific bans on cryptocurrency or AI written code. Especially when it leads to existing code becoming unavailable and doesn't just ban new contributions violating the rules.
> Anyone who cares about security will be using App Attest or the Google store equivalent.
Why? I rarely have security objectives where remote attention would help, and it has a huge impact on user freedom. For B2C attestation is just an evil captcha.
I definitely got more out of paying full attention to lectures in university compared to wasting effort on hand writing notes. And properly typeset lecture notes written by somebody else are much better for studying than the illegible handwritten notes I produce.
Abusing IP ranges which were assigned to an organization but aren't actually used on the public Internet as private addresses is pretty common. Sure, it's bad practice, but not a big deal.
When designing a character on a computer, you play around with many options, until you settle on one of them. Since you did exactly the same thing for all those variants, it's difficult to remember which one you ultimately picked. Writing down the final result by hand helps distinguish it from the alternatives in your mind.
That's very different from academic lectures, where you are directly told the facts, and not a multitude of equally valid alternatives.
I consider an inline-pointer a form of inline-metadata. When I mentioned that inline metadata isn't necessary I was referring to the kind of external lookup you describe.
Yes, large allocations need to be aligned to `alignof(max_align_t)`. But small allocations could have a smaller alignment. For example a single byte allocation can actually be a single byte with no alignment, since types can't have an alignment larger than their size.
There is no reason an allocation needs to contain any inline metadata. And even if it does, the allocator could choose to make it unalined, and pay the cost of an unalined access on de-allocation.
I'm a big fan of persisting almost everything in the primary database. With one exception: I'd immediately use object storage (S3) for files which are large in number or size. Files which are few and small (e.g. templates) are fine in the db.
There was some recent uncertainty about pgBackRest getting discontinued due to lack of funding. But the maintainer secured funding, and pgBackRest development will continue.
An atomic volume snapshot should work for any database that's durable on power failure. Ideally preceded by a checkpoint, to minimize recovery time. Atomicity of the snapshot mechanism is essential to prevent data corruption using this approach.
We used EBS snapshots on AWS for multi-TB MongoDB to get incremental backups that are fast to create and fast to restore (with some performance degradation after restore).
It doesn't support point-in-time recovery, but since it's fast you can create frequent snapshots (e.g. hourly). I'd consider adding this as a secondary backup strategy, even if you use a higher-level postgres-specific backup tool.
I'd avoid using overly opinionated code hosters that capriciously change their ToS to ban content that was allowed before without a very good reason. I'd like my code to survive long after I stop maintaining it, and such changes reduce my trust that a hoster will achieve that.
(This specific change wouldn't affect me, since all the code I published was written without AI)
How do they define "vibe coded"? I believe "vibe coded" was originally defined as letting AI write code without human review. But I often see it used for all AI assisted code.
edit: Looks like they don't talk about "vibe coding" at all, but ban code mostly written by AI:
> You must not share projects that mostly consist of code written by "generative AI"-tools
And I'm kind of confused by these screenshots as well, since there are lines between them, as if they're one screenshot. And the labels over the screenshots are nonsensical and graphically glitched.