paint.net is amazing for basic png editing, I've dreamed of this day. It'a the only thing I miss from Windows. I don't understand the slashback at all.
Also, if you pull the power plug, neither finally blocks nor defers would run. I personally consider it a clear and obvious deficiency in the semantics (and the implementations) of those programming languages but everybody refuses to listen to me.
Back in the days of spinning rust, we had RAID controller cards with batteries, so that if someone pulled the plug, there would be enough power to keep the drives going until any buffered writes were completed.
I certainly wouldn't mind if modern servers had something similar to make sure programs could stop gracefully. But then that doesn't help if you have a hardware failure...
Apparently, Windows does have precisely that, FlushFileBuffers [0][1]. The analogue in the Unix world is fsync(). Of course, some hard drives lie about actually having written their caches down, in which case there is nothing much anyone can do.
I remember looking into the nodejs alternatives some years ago, one way to compare them is to look at the open issues. bun had so many hits for 'segfault' and deno has basically none.
Even now:
bun (zig) [1] 119 open / 885 closed
deno (rust) [2] 0 open / 1 closed
I don't think this has that much to do with Zig's anti-AI stance. More about using the right tool for the job.
I did a really tiny contribution about zig cc supporting -exported_symbols_list, which together with the hack of filtering out -liconv makes for a very viable linux -> macOS Rust cross-compiler. There's a few caveats but those have been manageable so far.
Yeah, do crons even work consistently for GitHub Actions? I tried to set one up the other day and it just randomly skipped runs. There were some docs that suggested they’re entirely unreliable as well.
Hooo boy where do I begin? Dependency deadlocks are the big one - you try to share resource attributes (eg ARN) from one stack to another. You remove the consumer and go to deploy again. The producer sees no more dependency so it prunes the export. But it can't delete the export, cause the consumer still needs it. You can't deploy the consumer, because the producer has to deploy first sequentially. And if you can't delete the consumer (eg your company mandates a CI pipeline deploy for everything) you gotta go bug Ops on slack, wait for someone who has the right perms to delete it, then redeploy.
You can't actually read real values from Parameters/exports (you get a token placeholder) so you can't store JSON then read it back and decode (unless in same stack, which is almost pointless). You can do some hacks with Fn:: though.
Deploying certain resources that have names specified (vs generated) often breaks because it has to create the new resource before destroying the old one, which it can't, because the name conflicts (it's the same name...cause it's the same construct).
It's wildly powerful though, which is great. But we have basically had to create our own internal library to solve what should be non-problems in an IaC system.
Would be hilarious if my coworker stumbled upon this. I know he reads hn and this has been my absolute crusade this quarter.
> The producer sees no more dependency so it prunes the export. But it can't delete the export, cause the consumer still needs it. You can't deploy the consumer, because the producer has to deploy first sequentially. And if you can't delete the consumer (eg your company mandates a CI pipeline deploy for everything) you gotta go bug Ops on slack, wait for someone who has the right perms to delete it, then redeploy.
This is a tricky issue. Here is how we fixed it:
Assume you have a stack with the ConstructID of `foo-bar`, and that uses resources exported to `charlie`.
Update the Stack ConstructID to be a new value, ie `foo-bar-2`. Then at the very end of your CI, add a `cdk destroy foo-bar` to delete the original stack. This forces a new deployment of your stack, which has new references. Then, `charlie` updates with the new stack and the original `foo-bar` stack can be safely destroyed once `charlie` successfully updates.
The real conundrum is with data - you typically want any data stacks (Dynamo, RDS, etc) to be in their own stack at the very beginning of your dependency tree. That way any revised stacks can be cleanly destroyed and recreated without impacting your data.
> Dependency deadlocks are the big one - you try to share resource attributes (eg ARN) from one stack to another. You remove the consumer and go to deploy again. The producer sees no more dependency so it prunes the export.
I’m a little puzzled. How are you getting dependency deadlocks if you’re not creating circular dependencies?
Also, exports in CloudFormation are explicit. I don’t see how this automatic pruning would occur.
> Deploying certain resources that have names specified (vs generated) often breaks
CDK tries to prevent this antipattern from happening by default. You have to explicitly make it name something. The best practice is to use tags to name things, not resource names.
> I’m a little puzzled. How are you getting dependency deadlocks if you’re not creating circular dependencies?
> Also, exports in CloudFormation are explicit. I don’t see how this automatic pruning would occur.
I explained that. It's a quirk of how it tree-shakes, if nothing dereferences the attribute, it deletes the export. And yes it'll automatically create an export if you do something like
> CDK tries to prevent this antipattern from happening by default. You have to explicitly make it name something. The best practice is to use tags to name things, not resource names.
I'm well aware but i'm fighting a ton of institutional inertia at my work.
I'll just echo the other poster with "deadlocks". It's obscene how slow CF is, and the fact that its failure modes often leave you in a state that feels extremely dangerous. I've had to contact AWS Support before due to CF locking up in an irrecoverable way due to cycles.
I've Fairphone 6 with e/OS. Works well. Ok, some caveats:
- mobilepay does not work (I think Danes have an issue with non-mainstream platforms for whatever reason)
- the default browser does not work for some of the authentication flows when it integrates as the in-app browser. But it does give one dark theme on hn so I can just keep it on my homescreen while fireflx is the default for compat reasons.
