These discussions always focus around enforcement and never on alignment. The moat for this stuff historically has never been strict enforcement; it has been that the people who have the know-how on how to do it have nothing to gain by doing it, since they are well-educated and benefit from the current socioeconomic order (they have no motive to change it; rather, they want to climb it).
This is shifting. First, economic stratification is getting worse, and as economic mobility declines people start looking for alternatives. (See all of Gen Z cheering for Luigi Mangione). Second, AI will enable people who are less educated to build these kinds of weapons.
For example, you can use a Kalman filter to greatly improve the data you get from an IMU and GPS via sensor fusion. Before, this required a specialist skillset; now you can get a "good enough" implementation by prompting Claude.
I really wish the debate around this stuff wasn't framed in terms of preventative enforcement because it naturally leads towards more enforcement (when your only tool is a hammer...). The root of the issue is that the government does not trust its citizenry to follow the law without Big Brother watching. That in and of itself is a symptom of a larger grave political crisis in America: the decay of the state's political legitimacy.
> The root of the issue is that the government does not trust its citizenry to follow the law without Big Brother watching.
People did fly two planes into the World Trade Center. That was a thing that happened. Along with all the regular mass shootings, all the way up to Vegas.
> That in and of itself is a symptom of a larger grave political crisis in America: the decay of the state's political legitimacy.
Well, only because people are actively chiselling away at it because they think they will be able to loot the ruins.
your argument here rests on whether someone with the know how to do these types of things will not be able to find a job in the near future. I’d call this unlikely
There are no few smart, knowledgeable people in the world (perhaps self-educated, perhaps not) who for a huge variety of reasons may be either unwilling or unable to hold a typical job.
I’ll bet most of us here know at least a few people along these lines.
I used to feel the same but you can just prompt it to reply with only one word when its done. Most people prefer it to summarize because its easier to track so ig thats the natural default
Endpoint security software on the Mac, if it's worth the hit to system resources that is, inspect every call to exec and fork that occur in the kernel and also inspect those for known attack vectors, malicious scripts, etc. The one I have installed on my work Mac will kill reverse shell attempts before they are run. Will stop keychain attacks. Infostealing (as they can also get every file system op as they are happening in the kernel).
Gatekeeper and Xprotect are good, but there's only so much they can do.
Antivirus programs will run on PowerShell scripts, VBScript files, JScript files, and all other kinds of automation on Windows.
The screenshots from the article clearly show a permission prompt for a program. Whether that's a binary or a shell script or something else doesn't matter, the infection stage should've been caught by anti malware rather than permission prompts.
Windows Defender does this already. If Apple's AV can't catch this, I think they may be relying on their DRM-as-a-security-measure (signatures, notarisation, etc.) a bit too much.
You can simply ask the model to point out if there are any problems and then fix them yourself. You don't have to copy and paste its output into your book. You can also pay for an actual copyeditor to edit your book.
You can also edit it yourself and then ask a friend, relative, or colleague to read the parts you are struggling with improving. "Does this sentence flow? Is there a better way to say this? Is this confusing?"
If you're going to sink time into writing a book, it's worth spending some time editing it so your message gets through clearly. But that's just my opinion, your mileage may vary.
I can second this, after finishing my intro Japanese classes I was able to parse the grammar of most sentences. Memorizing vocab was the hard part, so I used OCR on manga pages and then Yomitan to hover over and see word definitions (in English).
Most existing mainstream languages aren’t expressive enough to encode these invariants. For languages outside of the mainstream, Lean 4 is a language supporting verification, and it’s also a full programming language, so you can write your proofs/theorems in the same language that you program in.
In most languages you can express any invariant, sure, but you can't prove that the invariant is upheld unless you run the program.
For example a NonNegativeInteger type in most languages would just have a constructor that raises an exception if provided with a negative number. But in languages with proofs, the compiler can prevent you from constructing values of this type at all unless you have a corresponding proof that the value can't be negative (for example, the value is a result of squaring a real number).
Most roll their own for three reasons: performance, context, and error handling. Bison/Menhir et al. are easy to write a grammar and get started with, but in exchange you get less flexibility overall. It becomes difficult to handle context-sensitive parts, do error recovery, and give the user meaningful errors that describe exactly what’s wrong. Usually if there’s a small syntax error we want to try to tell the user how to fix it instead of just producing “Syntax error”, and that requires being able to fix the input and keep parsing.
Menhir has a new mode where the parser is driven externally; this allows your code to drive the entire thing, which requires a lot more machinery than fire-and-forget but also affords you more flexibility.
If you're parsing a new language that you're trying to define, I do recommend using a parser generator to check your grammar, even if your "real" parser is handwritten for good reasons. A parser generator will insist on your grammar being unambiguous, or at least tell you where it is ambiguous. Without this sanity check, your unconstrained handwritten parser is almost guaranteed to not actually parse the language you think it parses.
