| Butterflyplace | https://bsky.app/profile/cynicalsecurity.bsky.social |
| Homepage | http://arrigotriulzi.ch/ |
| First 0day | 1986 |
With Windows 9x Subsystem for Linux you can run all your favourite Windows and Linux apps side-by-side with a modern Linux kernel running cooperatively with the Windows kernel in ring 0. And unlike modern WSL, no hardware virtualisation is used so even your 486 can run it!
Please enjoy, I think this might be one of my greatest hacks of all time
vibe-coding report:
Early afternoon:
Started looking at a set of scripts doing data handling in ksh on OpenBSD with Ollama + opencode
Mid-afternoon:
Ollama + opencode messed up the scripts enough that nothing worked, reverted to my version which might not have been so sexy and elegant re: error processing but at least didn't cobble the data.
Late afternoon:
OK, let's try Claude code. The first iterations removed good code (mine), created random regex which were clearly wrong, tried using gawk features on OpenBSD awk despite being told it was OpenBSD.
Evening:
Finally coaxed Claude code to "do the right thing". Scripts run and do what they were supposed to do.
Still had to edit the scripts by hand to add in a missing comparison to avoid printing log files when nothing has changed every couple of minutes.
I really enjoyed working on this audit for @freedomofpress with @robbje. Quite an important piece of software!
https://x41-dsec.de/security/research/job/news/2026/04/21/securedrop-review-2026/
As a crude first approximation, the problem-solving component of mathematical research (which, one should stress, is not the *only* aspect of such research) can be decomposed into three subcomponents:
1. Proof generation (finding a solution to a given problem);
2. Proof verification (checking that a proposed solution actually works); and
3. Proof digestion (understanding the essence of a solution, placing it in context with previous literature, summarizing and explaining it effectively, and gaining insights on other related problems and topics).
Until recently, all three of these subtasks were rather difficult and time-intensive to perform; but a human mathematician (or a collaboration between several mathematicians) who had invested the effort to both generate a proof and verify it usually gained enough understanding into the structure of that proof that they could also digest it effectively. Because of this, our community has been generally content to emphasize the proof generation and verification aspect of problem solving, as the proof digestion tended to be created naturally as an organic byproduct of these first two aspects. This was also convenient for assessing proof efforts, as the generation and verification tasks had well-defined objectives, whilst proof digestion was a more subjective and open-ended process. [Though "the ability to present the result at a research conference and take questions" is a rough first approximation of a metric for whether a proof has been digested,] (1/3)
However, recent advances in both AI and proof formalization have begun to vastly accelerate and automate the first two components of this process. This is leading to a new type of "impedance mismatch": problems for which solutions can be rapidly generated and verified in a mostly automated process, but for which no human author has understood the arguments well enough to initiate the (much slower) digestion process.
In fact, with the current cultural incentives that reward the first authors to "solve" the problem, rather than the later authors who "digest" the solution, one may end up with the perverse situation in which an AI-generated (and formally verified) solution to an problem that is presented to the community without any significant digestion may actually *inhibit* the progress of the field that the problem lies in, by discouraging any further attempts to work on the problem, simplify and explain the proof, and extract broader insights. (2/3)
We may be in the market to hire a part-time FreeBSD and Bastille sysadmin (~20hrs week) specifically in the EMEA or APAC timezones (eventually both).
The roles require experience with FreeBSD, Bastille, nginx, and at least one useful coding language.
Timeline is mid-to-late 2026 to start.
Any of our EU / APAC friends want to come work part-time with the Bastille creator on a cybersecurity startup?
Hailey
Michael Dexter
Thomas Pornin
mumblegrepper
Brian Bilston
Terence Tao
BastilleBSD 
ChaCha20Poly1305