Luna
@lunnova.dev
Reposted by Luna
The only reason I haven’t moved to another PDS is I want the emergency option to migrate back here
July 11, 2025 at 9:05 PM
The only reason I haven’t moved to another PDS is I want the emergency option to migrate back here
AWS IAM: Extremely inconsistent support for cross-account access.
Whether you must use AssumeRole into another account or can directly grant cross account access with a resource-based policy varies wildly, even within a single service.
Whether you must use AssumeRole into another account or can directly grant cross account access with a resource-based policy varies wildly, even within a single service.
July 11, 2025 at 5:24 PM
AWS IAM: Extremely inconsistent support for cross-account access.
Whether you must use AssumeRole into another account or can directly grant cross account access with a resource-based policy varies wildly, even within a single service.
Whether you must use AssumeRole into another account or can directly grant cross account access with a resource-based policy varies wildly, even within a single service.
> I don’t think this has any real practical implications.
Wondering if any runtimes/libs would treat `VAR` with no = as that var being set, allowing some sort of vuln or misbehavior in mixed-language programs where one part thinks it set, another doesn't.
Probably not, ≈everything calls libc?
Wondering if any runtimes/libs would treat `VAR` with no = as that var being set, allowing some sort of vuln or misbehavior in mixed-language programs where one part thinks it set, another doesn't.
Probably not, ≈everything calls libc?
July 10, 2025 at 9:11 PM
> I don’t think this has any real practical implications.
Wondering if any runtimes/libs would treat `VAR` with no = as that var being set, allowing some sort of vuln or misbehavior in mixed-language programs where one part thinks it set, another doesn't.
Probably not, ≈everything calls libc?
Wondering if any runtimes/libs would treat `VAR` with no = as that var being set, allowing some sort of vuln or misbehavior in mixed-language programs where one part thinks it set, another doesn't.
Probably not, ≈everything calls libc?
that sounds right
opt-in `!` is more aesthetically pleasing if I'm already using nightly only features but no functional changes.
Might be better to drop that and always use enum Never in the next version.
opt-in `!` is more aesthetically pleasing if I'm already using nightly only features but no functional changes.
Might be better to drop that and always use enum Never in the next version.
July 9, 2025 at 1:57 AM
that sounds right
opt-in `!` is more aesthetically pleasing if I'm already using nightly only features but no functional changes.
Might be better to drop that and always use enum Never in the next version.
opt-in `!` is more aesthetically pleasing if I'm already using nightly only features but no functional changes.
Might be better to drop that and always use enum Never in the next version.
should work* on stable unless you turn on the never_type feature which asks it to use `!` instead of a builtin `enum Never {}` def
*not very battle-tested
*not very battle-tested
July 9, 2025 at 1:31 AM
should work* on stable unless you turn on the never_type feature which asks it to use `!` instead of a builtin `enum Never {}` def
*not very battle-tested
*not very battle-tested
@metaflame.dev can I interest you in this, as one of the few denizens of this webbed site to mention pattern types?
July 9, 2025 at 12:33 AM
@metaflame.dev can I interest you in this, as one of the few denizens of this webbed site to mention pattern types?
July 6, 2025 at 7:05 PM