1. It's not a ban on using social media, it's a requirement for age verification to create an account. This only limits usage on the few platforms that force an account to do anything.

2. The technical controls platforms implement are, unsurprisingly, generally quite weak. Kids are crafty enough to circumvent them, and share how freely.

3. Wannabe-influencer parents just create accounts for their kids, making the circumvention trivial.

4. There are no consequences for using a social media account while under 16.

I think the final point is the main one, though. By design there's no mechanism in place for the government to take any action if a kid gets onto social media, only if a platform fails to implement age checks that satisfy the legislation's criteria. So platforms all implemented tokenistic age checks. Platforms don't care, or need to care, if they get bypassed. The government doesn't care.

If I were a more suspicious man I'd say that either the point was never to reduce the use of social media by kids in the first place, or it was well intentioned but railroaded into toothlessness by lobbyists.

If phone support issued an encrypted decrypt code that could only be used with your challenge code to decrypt the decrypt code, replay wouldn't be as trivial.

Every CD is identical, so no matter how iD went about this there's only ever one decryption key (per title, I assume) and those keys must either have been encoded in iD support's response, or already stored on the CD. TestDrive sold iD on the notion that the process was too hard for hacker groups to reverse engineer, and it wasn't.

If Quintauris successfully makes a RISC-V range for automotive use, there'd probably be margin to clone those and sell at a profit, but skirting automotive certification regulations is a high-risk game that (hopefully!) doesn't have many buyers.

If they make an IoT line, again, there might be margin in it, but you'd be trying to fit in between buyers willing and able to engage with Chinese sellers but for some reason unwilling or unable to engage with existing Chinese sellers of existing IoT RISC-V parts. Quintauris is a very, very long way away from being a "household name" along the lines of STM32 or FTDI.

But your more typical use case was to play a single tone for some significant fraction of a second.

I do not believe that emoji like crosses and ticks are particularly common at all, for any language, but LLMs seem to have picked up heavy use of them from somewhere and inserted them into code (and everything else) they generate.

LLM training sets will very likely include the massive corpos of non-English open source code from sites like Gitee, but would be unlikely to generate responses heavily influenced by them unless you've done specific things to make that happen - prompt in Chinese, try to make use of a library only available with Chinese source and/or documentation, perhaps. I've not seen it happen, but I am a light user of LLMs.

Equivalence of terms is an efficient tool for verification; I suspect that isn't really in the set of goals for Fuse, though.

Much as I loved DR-DOS, it did have occasional compatibility hiccups.

As I understand supercompilation, it's an extension of partial evaluation - optimisation is done on a graph of possible execution traces. The downsides should be obvious: execution traces rapidly grow massive, compilation resources grow superlinearly, and there are many cases in which the result is worse than the original.

What value would Fuse get from equivalence of terms, do you think?

It looks like a tidy little functional language - a small, easily grasped syntax surface and generally clear semantics. That you've got it to the point that it can compile and run proper programs is a great achievement for a solo dev project!

The string type in the standard library isn't Unicode-aware, might be worth just noting that. Unicode support can be a big undertaking, but considering whether you'll add it later or not might affect your library design now.

I don't really understand why you have an IO monad. The language isn't pure - `.exec()` means any function can perform IO actions no matter its type signature - so what's IO really for?

Do `impl` additions export? What happens when two libraries add the same function name with different signatures (or just bodies!) to a type's `impl` ?

Is currying automatic? It doesn't seem to be, but, eg, the `sum(x: i32, y: i32)` function theoretically could be called as `sum(5)` to create a closure, but this isn't a documented feature if so.

The website's font is using ligatures, not unicode operator symbols - I'd personally find it much clearer to use a non-ligature font to show what's really there, but that's immaterial to the language.

Perhaps that's the same thing as what you're saying, though: we don't specify these things in detail because it's expensive to spend that much time thinking through it all, when users are largely trained to just accept crashes, glitches, inconsistencies, and the occasional sprinkle of data loss.

Formal verification at the undergraduate level, if you even see it, would be about running software on a spherical cow, though.

The sort of environments in which this is a problem would be extremely uncommon. For a start, you need continuous contention. If you ever get a break in contention you no longer have starvation, and you 'reset' the ticket number monotonicity - to zero, if you actually take a maximum of entering thread ticket numbers instead of a cheap global counter.

If you do actually have an environment in which you expect to have continuous contention over a critical section, some quick napkin math can tell you if it's something to worry about based on the running time of your critical section. If it's over, say, 10ms, you've got a few years of runtime before it's a problem. If it's under 1ms, maybe you want to use 64-bit arithmetic for your ticket number so you can run your system until long after the human species is extinct.

You probably got a 'B' because you didn't give the professor the answer they expected, though, not because of any technical reasons.

Part of what the research shows is that correctness-by-proof has a cost in developer effort.

If there really is a vulnerability-apocalypse due to AI, and it's not just a different flavour of AI hype, the cost of having insecure software will rise to the point that the cost of dealing with insecure or incorrect code at time of creation becomes less than the cost of ignoring it until it blows up.

I doubt it'll rise so much that we'll want to face the cost of behaviour proofs for much code at all, but it's quite possible it'll rise enough that we want to do things like prove that indices are in bounds, at compile time, so vector accesses can skip checks without compromising safety.

CodeWeavers, AIUI, have a plan - and their plan may also be using FEX as a basis.

Wine is wine, yes, but CodeWeavers is not Valve. Mac gaming is niche. The budgets involved are incomparable. Expect it to take weeks to months for hotfixes applied in days to Proton to filter through to CrossOver.

(This is my lived experience: HD2 patch 28th April broke wine compatibility, Proton had a hotfix in a day or two, CrossOver had a preview that partially fixed it May 11th and a release that fully fixed it June 9th; it was unplayable from April 28th to June 9th, longer if you count the stuttering issue that it suffered since March.)

The future of gaming on a Mac is also made less certain by the upcoming obsolescence of Rosetta. AFAICT Apple won't just pull it out completely, but they're clearly uninterested in supporting it long term, so over time the experience of trying to get x86 games to run on ARM Macs will worsen.

(I think I'll aim for a DIY PC build in 2027 in the hopes memory prices decline by then, but it's a faint hope!)