drvdevd

I think this language is fascinating, but immediately reached a similar conclusion: it might trip up an LLM consuming the text directly but once an interpreter/compiler/decompiler has been written for the language it's trivial for an agent to consume these programs and produce them.

Now on the other hand, as a class of techniques - "anti-LLM languages" - it might be a useful method of emitting code that some agents with the correct tools can consume and others cannot, by design. Evolving such techniques with differing specifications might make for an interesting line of investigation.

also I believe it helps you track save games. I have multiple Linux boxes I play GOG games on using Heroic launcher and save game tracking is a big issue (maybe there's a way to do this with Heroic, idk). But I think Galaxy would help here.

If you find macro shots of their faces too they kinda look like dogs with a few extra eyes

> Whether February 22, 2024 comes in like a lion or a lamb, that day will always be September 11131, 1993.

> And one thing is sure: If September is eternal, then Usenet is eternal, too.

Amazing. Love this.

I don’t have a good list of which games I validated in parallels and which I didn’t (since I’ve stopped gaming for the last 6 months or so).

And I do heavily play boomer shooters so it’s likely I was impressed by performance of less demanding games.

Doom Eternal is one AAA game I definitely would want to play in Parallels but can’t because the Vulkan version is not new enough. I’m confident though that Microsoft could bring these APIs up-to-date on an “ARM PC” though, if it has capable 3D hardware.

I haven’t done any objective tests but I frequently run Windows 11 on ARM via Parallels on macOS and - it’s kinda insane (subjectively) how fast it is. Emulated x86 code is pretty fast there as well - I can easily get a solid 60 FPS on some x86 steam games as well.

This appears to be an architectural vulnerability where a speculative execution side channel similar to Spectre can be utilized within Safari or any other browser. The specifics of which environment is exploitable comes down to the specifics of the JavaScript-based gadget they use to trigger/measure this side channel. It may be in the linked paper which I haven’t read yet.

From a cursory review of the FAQs on the page it appears one mitigation might be to only keep one browser tab open at a time? They appear to be using timers and a cache eviction gadget to infer the state of other browser tabs/processes so it’s unclear what they can recover if you are not concurrently having a session to a particular site outside the gadget execution context. ???

Don’t forget these systems are trained or aligned to respond to common niceties because they are meant for public consumption.

I need a self driving Segway, yesterday.

The song is Fu Man Chu, by Desmond Dekker and the ACES.

So from an attackers perspective nowadays it sounds like focusing on encryption weaknesses and/or hardware issues (e.g. glitching) or firmware vulnerabilities is the right place to look?

I was wondering what the newly exposed vector of exploitation was here and I think you nailed it.

This is an interesting thought and I have to agree it’s a legitimate issue. I have also considered something similar - that in the near future, if all software is designed with AI, or “generated” rather than explicitly engineered, we would certainly reap some benefits from that but we would also cease understanding how anything actually works. Obviously no one person fully understands the abstractions we have currently engineered when considering the totality.. but at least currently we have them.