Some time ago I visited a used book fair and came across this awesome piece of 80s scifi-asthetic.
This book is a collection of short stories by the Polish author Stanisław Lem originally published in 1964. Its English title is The Cyberiad. One story, about Trurl's electronic troubadour, turned out to be surprisingly topical.
Spoilers for the whole story followThe inventor Trurl (revealed in other stories to be a robot) wants to create a machine that can generate poetry. He begins by obtaining several hundred tonnes of books to use as training data.
Trurl gets to work constructing the electric poetry machine. In the process they have to create massive data storage containers that stretch further out than one can see using binoculars. This is considered a necessary evil to get this great invention going.
The machine will not work as expected. As a last resort Trurl rips out all logic circuits and replaces them with "narsistors". Then things start working.
Trurl invites his friend Klapaucius over to test the new machine. They give it all sorts of weird and wacky instructions like "create a pastoral love poem that also contains mathematics and cybernetics". Basically they do a whole bunch of prompt engineering. They talk and behave exactly like people of 2021-2023 did when LLMs first appeared.
Eventually the machine causes uproar among poets and there are protests demanding it to shut down. These go nowhere in part because the media secretly love the machine. They are using it to create their own content for pennies and thus don't want to see it come to harm. As all of this is going on various people develop symptoms quite similar to modern day AI psychosis.
Things eventually crash when Trurl gets the machine's electrical bill, which turns out to be astronomical. He needs to get rid of the machine and manage to dump it on a visiting dignitary who takes it to his home planet where causes a supernova explosion. Trurl deems that to be sufficiently far away to not be his problem any more.
The difference between fact and fictionIn the story all the problems are caused by the fact that the machine's output is vastly higher quality than anything humans can create. Even the great Stanisław Lem could not predict that in reality the output would turn out to be mediocre garbage and still lead to all the same problems.
Even though the story specifies that the machine is given some "basic instructions" first, nobody tries to do a prompt injection attack on it. That would only appear almost 30 years later in 1993's Paranoia novel Title Deleted for Security Reasons. An earlier example may well exist somewhere, it almost always does.
Together with Modal, I’m happy to announce that the Sovereign Tech Agency is investing nearly €510k into Flatpak development. The focus is on closing gaps in Flatpak’s sandboxing story: new portals for audio, networking, VPNs, and spell checking, plus infrastructure work on entitlements and intents.
I’ll be leading the technical side alongside Adrian, with organizational support from Kateryna and Cade. We’ve brought on a great team and the project will ramp up over the coming months through the end of 2027.
Read the full announcement on the Modal blog.
In Some Changes to GNOME Security Tracking, I reported:
I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.
This is because I was planning to leave my job at Red Hat on December 31 due to some internal Red Hat policy changes. But this timeline has now unexpectedly moved forward two months, to October 30. Accordingly, I will now discontinue tracking newly-reported security issues on October 1, 2026. During October, I will focus only on tracking issues reported prior to October 1. By November 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.
If your agentic workload involves the agent being able to run arbitrary code (like bash or equivalent), then you should not use a “LLM as part of your app” framework like LangChain, BeeAI, OGX etc. Instead, run OpenCode, goose, or another general coding agent inside a sandbox such as OpenShell.
Sandboxing limits what the agent can access directly. For privileged effects, it is best augmented with a pattern like safe outputs: the agent emits a structured, unprivileged request that separately trusted code validates and applies.
A compact decision tree Can it run bash or arbitrary code? ├─ Yes → Run a generic agent in a sandbox └─ No → Are you *really* sure *all* of your tool calls (MCP or builtin) don't accidentally expose "execute arbitrary code"? ├─ Yes → OK, maybe LangChain or equivalent makes sense └─ No → Goto startI also think the builtin sandboxing in most agent tools (like Claude Code and Gemini CLI) is a bad idea, and it’s better to just ensure the entire thing is sandboxed.
Related to all of this, a key thing anyone making an “agent” needs to ask is “how is this different from just writing an agent skill”. From my previous post you’ll know that I think GitHub Agentic Workflows is a good reference baseline for applying agentic AI (background/task oriented) safely and effectively. And there an “agent” is almost exactly just an agent skill, but with a bit of YAML defining its integration with the outer system.
Why should it be harder than that? I just don’t see it making sense for custom agents written in frameworks like LangChain to proliferate in most use cases. Sure you can use LLMs to generate it, but it’s even more secure and understandable to not have that code at all.
Even for the use case of an interactive chat bot, do you really need a custom app versus just MCP tools for an already generic frontend? I doubt it.
I don’t think it makes sense for most organizations to have proliferation of custom bespoke agents like these LangChain-style frameworks encourage. Skills and sandboxed generic agents are just easier to understand and work with.
Hello! I'm Angelo Verlain, a Software Engineering student, and I've been working for the last 3 months easing the debugging process of GJS apps by adding Debug Adapter Protocol (DAP) support to GJS as part of Google Summer of Code (GSoC 2026).
A debugger is software for executing a computer program in an environment that allows for programming-level inspection and control. A debugger is often used to debug, but can be used for other goals including testing. Common features of a debugger include stepping through code line-by-line, breaking into the program's flow of control, managing breakpoints, and reporting and modifying memory. <sup>1</sup>
What is GJS?GJS or GNOME JavaScript is a JavaScript interpreter that allows developers to write code that can leverage GLib/GObject and various other libraries that work with GObject Introspection like GTK, Libsoup, etc...
In practice, GJS allows you to write GNOME/GTK Applications and GNOME Components in JavaScript. The GNOME Shell & Extensions, GNOME Weather, GNOME Audio Player, GNOME Maps, Workbench are all examples of projects powered by GJS.
What is DAP?The Debug Adapter Protocol is a a specification that describes how messages are passed between a debugger client (for example, your IDE) and server (such as the Node.js or any other language runtime). It specifies and communicates pausing & continuing execution, setting breakpoints, stepping through the code, viewing stack traces, and more. It works by defining a standard way for your development tool (e.g. GNOME Builder, VS Code, Zed, etc...) to connect to a debugger.
Today, you can already debug applications and libraries written for/with Android, Node.js, Deno, C, C++, Rust, Python and more. This project aims to make GJS applications debuggable in your favourite editor or debugger by implementing a DAP adapter for GJS.
Adding DAP to GJSGJS already supports debugging programs by use of the --debugger flag, which spins up a GDB-style CLI interface where you invoke it by running gjs --debugger [file-name].js and writing commands like breakpoint [line], step, frame to set breakpoints, step through the code and print the stack frame respectively.
It works well, but it's different from the GUI debugging that’s more popular these days.
Here's an example of GJS debugging the following code saved as test2.js
function print(i) { console.log(i); } for (let i = 0; i < 10; i++) { print(i); }If GJS had support for DAP, you wouldn’t be limited to just using the text mode debugger, but could debug applications using your favourite editor (Zed, VS Code, etc…)
The workflow would be easier too: Press F5 to debug (standard hotkey), specify the path to your entrypoint, and then run the program. To set a breakpoint, simply type the debugger keyword or click in the gutter/margin of your editor (even after your program has started execution!).
When the program reaches that breakpoint, you will have a nice stack trace showing where the program stopped, and give you options to inspect the current variables in the different scopes, continue execution, or step next, in our out of frames.
Here's an example of debugging the same script using VS Code's Node.js adapter (the experience we want):
Note that you can more clearly see the variables, call stack and breakpoints in the debugger.
ScopeMy work is focused on launching & debugging GJS apps.
The scope is also limited to launching & debugging GJS applications or running scripts in the GJS interpreter and debugging them. Attaching to already running applications is not in scope.
Concretely this also means that debugging components like the GNOME Shell is not in scope.
Furthermore, I have only written an extension for Zed since it’s the editor I use, but other editor extensions like VS Code, Builder, and Emacs could be implemented as a follow-up task and will be relatively easy since GJS itself implements the DAP specification and we just need to bridge the two. If you want support for a specific editor or debugger, please let me know :).
ProgressI've made significant progress on the project.
The project period is coming to a close and I’ve made significant progress. Currently, the following is implement:
My next steps will focus on the following:
Figure: Debugging a program with a visual debugger (Zed), showing breakpoints (red circle in the gutter), current line highlighted and variables
I’m looking forward to sharing my progress when we get to the end of the program! Expect another blog post in the next couple of weeks.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.