Agreguesi i feed

Hello, I am pleased to announce a new Cambalache release.

Cambalache is a WYSIWYG (What You See Is What You Get) tool that allows you to create and edit user interfaces for Gtk 4 and 3 applications.

This new version depends on GNOME SDK 51 and includes all new properties and types from Gtk and Adwaita! It also removes the file hash from the project file which should prevent unnecessary git conflicts.

In case you missed it, you can read more about Cambalache in version 1.0 release blog.

Cambalache’s First Major Milestone!

Help us continue developing

If you find this application useful you can support it’s development by contributing on Liberapay or Patreon

Where to get it?

From Flathub

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo flatpak install flathub ar.xjuan.Cambalache

or directly from gitlab

git clone https://gitlab.gnome.org/jpu/cambalache.git Matrix channel

Have any question? come chat with us at #cambalache:gnome.org

Mastodon

Follow me in Mastodon @xjuan to get news related to Cambalache development.

As usual happy coding!

(This is an updated version of an older post - the introduction remains the same, the technical details are different)

Linux draws a distinction between code running in kernel (kernel space) and applications running in userland (user space). This is enforced at the hardware level - in x86-speak1, kernel space code runs in ring 0 and user space code runs in ring 32. If you’re running in ring 3 and you attempt to touch memory that’s only accessible in ring 0, the hardware will raise a fault. No matter how privileged your ring 3 code, you don’t get to touch ring 0.

Kind of. In theory. Traditionally this wasn’t well enforced. At the most basic level, since root can load kernel modules, you could just build a kernel module that performed any kernel modifications you wanted and then have root load it. Technically user space code wasn’t modifying kernel space code, but the difference was pretty semantic rather than useful. But it got worse - root could also map memory ranges belonging to PCI devices3, and if the device could perform DMA you could just ask the device to overwrite bits of the kernel4. Or root could modify special CPU registers (“Model Specific Registers”, or MSRs) that alter CPU behaviour via the /dev/msr interface, and compromise the kernel boundary that way.

It turns out that there were a number of ways root was effectively equivalent to ring 0, and the boundary was more about reliability (ie, a process running as root that ends up misbehaving should still only be able to crash itself rather than taking down the kernel with it) than security. After all, if you were root you could just replace the on-disk kernel with a backdoored one and reboot. Going deeper, you could replace the bootloader with one that automatically injected backdoors into a legitimate kernel image. We didn’t have any way to prevent this sort of thing, so attempting to harden the root/kernel boundary wasn’t especially interesting.

In 2012 Microsoft started requiring vendors ship systems with UEFI Secure Boot, a firmware feature that allowed5 systems to refuse to boot anything without an appropriate signature. This not only enabled the creation of a system that drew a strong boundary between root and kernel, it arguably required one - what’s the point of restricting what the firmware will stick in ring 0 if root can just throw more code in there afterwards? What ended up as the Lockdown Linux Security Module provides the tooling for this, blocking userspace interfaces that can be used to modify the kernel and enforcing that any modules have a trusted signature.

But that comes at something of a cost. Most of the features that Lockdown blocks are fairly niche, so the direct impact of having it enabled is small. Except that it also blocks hibernation6, and it turns out some people were using that. The obvious question is “what does hibernation have to do with keeping root out of kernel space”, and the answer is a little convoluted and is tied into how Linux implements hibernation. Basically, Linux saves system state into the swap partition and modifies the header to indicate that there’s a hibernation image there instead of swap. On the next boot, the kernel sees the header indicating that it’s a hibernation image, copies the contents of the swap partition back into RAM, and then jumps back into the old kernel code. What ensures that the hibernation image was actually written out by the kernel? Absolutely nothing, which means a motivated attacker with root access could turn off swap, write a hibernation image to the swap partition themselves, and then reboot. The kernel would happily resume into the attacker’s image, giving the attacker control over what gets copied back into kernel space.

This is annoying, because normally when we think about attacks on swap we mitigate it by requiring an encrypted swap partition. But in this case, our attacker is root, and so already has access to the plaintext version of the swap partition. Disk encryption doesn’t save us here. We need some way to verify that the hibernation image was written out by the kernel, not by root. And thankfully we have some tools for that.

Trusted Platform Modules (TPMs) are cryptographic coprocessors7 capable of doing things like generating encryption keys and then encrypting things with them. You can ask a TPM to encrypt something with a key that’s tied to that specific TPM - the OS has no access to the decryption key, and nor does any other TPM. So we can have the kernel generate an encryption key, encrypt part of the hibernation image with it, and then have the TPM encrypt it. We store the encrypted copy of the key in the hibernation image as well. On resume, the kernel reads the encrypted copy of the key, passes it to the TPM, gets the decrypted copy back and is able to verify the hibernation image.

That’s great! Except root can do exactly the same thing. This tells us the hibernation image was generated on this machine, but doesn’t tell us that it was done by the kernel. We need some way to be able to differentiate between keys that were generated in kernel and ones that were generated in userland. TPMs have the concept of “localities” (effectively privilege levels) that would be perfect for this. Userland is only able to access locality 0, so the kernel could simply use locality 1 to encrypt the key. Unfortunately, localities are typically only available on systems that implement a Dynamic Root of Trust Measurement like Intel’s TXT, and most consumer systems have no support for this. So, we need another approach.

TPMs have a set of Platform Configuration Registers (PCRs), intended for keeping a record of system state. The OS isn’t able to modify the PCRs directly. Instead, the OS provides a cryptographic hash of some material to the TPM. The TPM takes the existing PCR value, appends the new hash to that, and then stores the hash of the combination in the PCR - a process called “extension”. This means that the new value of the TPM depends not only on the value of the new data, it depends on the previous value of the PCR - and, in turn, that previous value depended on its previous value, and so on. The only way to get to a specific PCR value is to either (a) break the hash algorithm, or (b) perform exactly the same sequence of writes. On system reset the PCRs go back to a known value, and the entire process starts again.

Some PCRs are different. PCR 23, for example, can be reset back to its original value without resetting the system. We can make use of that. The first thing we need to do is to prevent userland from being able to reset or extend PCR 23 itself. All TPM accesses go through the kernel, so this is a simple matter of parsing the write before it’s sent to the TPM and returning an error if it’s a sensitive command that would touch PCR 23. We now know that any change in PCR 23’s state will be restricted to the kernel.

When we encrypt material with the TPM, we can ask it to record the PCR state. This is given back to us as metadata accompanying the encrypted secret. Along with the metadata is an additional signature created by the TPM, which can be used to prove that the metadata is both legitimate and associated with this specific encrypted data. In our case, that means we know what the value of PCR 23 was when we encrypted the key. That means that if we simply extend PCR 23 with a known value in-kernel before encrypting our key, we can look at the value of PCR 23 in the metadata. If it matches, the key was encrypted by the kernel - userland can create its own key, but it has no way to extend PCR 23 to the appropriate value first. We now know that the key was generated by the kernel.

Unfortunately it turns out that some people actually make use of PCR 23, and restricting it to the kernel makes them sad. There are other resettable PCRs, but only in non-0 localities, so (a) we can’t reset them on most systems and (b) we’ll just find someone who uses them anyway and run into the same problem. We need a different approach.

Thankfully TPMs have a small chunk of non-volatile RAM that can be used for storing things, and by “storing” I mean they can be used in a range of different ways. One of these is effectively as additional PCRs. These values can be configured such that they work the same way as PCRs, with the only way to modify them being to append a new hash to their existing value and update the new value to the hash of that merged value. We can allocate one of these for in-kernel use and reject any access from userspace, and also there are officially allocated ranges (so people shouldn’t be using random values) and the namespace is large enough anyway that w eshouldn’t collide with anyone, so we can carve one of those out and use it for this purpose.

Unfortunately, though, these NV indexes aren’t included in the creation data we get when we create a key, so we need another approach. TPMs have the concept of sessions, a series of commands executed in sequence. A flag allows these sessions to be “audited”, with the TPM keeping a running track of the hash of the commands executed and the results returned. At the end of the session you can ask for a signed copy of this hash, and if you’ve kept a log of all the commands then you can verify that they match that signed hash and know that this log represents a real communication with the TPM. If we read the NV index and generate the key inside the same session, we can verify that the key we’re looking at was created while the NV index had a specific value, and if only the kernel can set that value then we know that the key was generated by the kernel.

Or, well, can we? Only new kernels would impose the restriction on modifying that NV index. An attacker could boot an old kernel, generate a key there in userland, sign a hibernation image with it, and then reboot into a new kernel. The new kernel would see a valid signature with a valid NV index associated with it and have no way to know it was generated from userland rather than the kernel. We need to be able to tell the difference between kernels that implement this feature and ones that don’t, and we need to do that without being able to go back in time to change old kernel behaviour. We can extend a PCR to indicate we implement the new functionality, but so can an attacker running an old kernel.

The normal approach to determining whether an event occurred in a specific phase of the boot process is to “cap” the PCRs - extend them with a known value that indicates a transition between stages of the boot process. Any events that occur before the cap event must have occurred in the previous stage of boot, and since the final PCR value depends on the order of measurements and not just the contents of those measurements, if a PCR is capped before userland runs, userland can’t fake the same PCR value afterwards. If Linux capped the PCRs before userland started running, we’d be able to place a measurement there before the cap occurred and then prove that that extension occurred before userland had the opportunity to interfere. We could simply place a statement that the kernel supported the NV index restrictions there, and we’d be fine.

Unfortunately Linux doesn’t currently do this, and adding support for doing so doesn’t fix the problem - if an attacker boots a kernel that doesn’t cap a PCR, they can just cap it themselves from userland. So, we’re faced with the same problem: booting an older kernel allows the system to be placed in an identical state to the current kernel, and a fake hibernation image can be written out. Solving this requires a PCR that was being modified after kernel code was running, but before userland was started, even with existing kernels.

Thankfully, there is one! PCR 5 is defined as containing measurements related to boot management configuration and data. One of the measurements it contains is the result of the UEFI ExitBootServices() call. ExitBootServices() is called at the transition from the UEFI boot environment to the running OS, and the kernel contains code that executes before it. So, if we measure an assertion regarding whether or not we support restricted access to NV indexes into PCR 5 before we call ExitBootServices(), this will prevent userspace from spoofing us (because userspace will only be able to extend PCR 5 after the firmware extended PCR 5 in response to ExitBootServices() being called). Obviously this depends on the firmware actually performing the PCR 5 extension when ExitBootServices() is called, but if firmware’s out of spec then I don’t think there’s any real expectation of it being secure enough for any of this to buy you anything anyway.

That’s what this patchset does. Review feedback so far seems positive, although James Bottomley suggested a design improvement. My approach of using an NV index as a PCR and generating a signing key made sense as a consequence of my original approach involving PCR 23, which had been to use the key creation data and not use audit sessions at all. But the goal isn’t to use a key - it’s to prove that hibernation occurred in-kernel, and while signing is one way of doing that, there are others. His suggestion is to simply record the hash of the hibernation image into the NV index and then read that back as part of the audit session. On resume we verify the audit session log is legitimate, read the hibernation image, and compare the hash of the hibernation image against the hash in the log. If it matches, and if the PCR 5 value matches, we know the audit session happened in kernel and that the hibernation image hasn’t been modified.

It still seems like we’re missing something, though. If we’re not storing a key anywhere, how do we verify the audit session? To explain this we’re going to need to go into some details about how TPM keys work in the first place. TPMs can produce a special kind of key called an Attestation Key, or AK. Attestation keys are used to sign attestation statements from the TPM, such as PCR quotes or audit logs. We need a separate key type for this in order to prove that the signature was generated as part of an attestation - normal TPM signing keys are fundamentally designed to sign arbitrary material, and so can be used by userland to sign something that looks identical to an attestation record. By being able to distinguish the types of key the TPM uses, we can prove that a signature was generated using an AK, and so know that it’s a real TPM attestation (because nothing other than the TPM can sign stuff with an AK).

But even beyond this distinction, TPMs have different key types. Ordinary keys are generated using an RNG and will be unique. Primary keys are generated using a seed that is used as an input into a key derivation function. For a given TPM, using the same seed to generate the same type of primary key will always generate the same primary key8. We can have the kernel deterministically generate an AK during suspend in order to sign the audit log, and then generate the same key again on resume to validate it. This means we don’t need any other form of trusted storage for the AK - the TPM already provides that functionality.

This is all rather complicated but I’ve been thinking about this for some time now and I haven’t come up with a cleaner solution. The only real open issue is the degree to which machines actually perform the PCR 5 extension. If it turns out there’s a bunch that don’t we’ll need to come up with some alternative approach to identifying whether the kernel supports this functionality, but the design is such that that should be invisible to userspace so adding alternatives later shouldn’t be an issue. Filtering accesses to the NV index is also not super clean, and depends on there not being alternative mechanisms to get at the TPM by sending raw commands. Again, this is intended to be opaque to userland and can be improved if we come up with something better later on (such as a secure way to pass a secret to the kernel on boot that can be used as an auth value for acess to the NV index).

Anyway. Time to go and fix the next thing.

1. Other architectures use different terminology here, such as “supervisor” and “user” mode, but it’s broadly equivalent ↩︎

2. In theory rings 1 and 2 would allow you to run drivers with privileges somewhere between full kernel access and userland applications, but in reality we just don’t talk about them in polite company ↩︎

3. This is how graphics worked in Linux before kernel modesetting turned up. XFree86 would just map your GPU’s registers into userland and poke them directly. This was not a huge win for stability ↩︎

4. IOMMUs can help you here, by restricting the memory PCI devices can DMA to or from. The kernel then gets to allocate ranges for device buffers and configure the IOMMU such that the device can’t DMA to anything else. Except that region of memory may still contain sensitive material such as function pointers, and attacks like this can still cause you problems as a result. ↩︎

5. This describes why I’m using “allowed” rather than “required” here ↩︎

6. Saving the system state to disk and powering down the platform entirely - significantly slower than suspending the system while keeping state in RAM, but also resilient against the system losing power. ↩︎

7. With some handwaving around “coprocessor”. TPMs can’t be part of the OS or the system firmware, but they don’t technically need to be an independent component. Intel have a TPM implementation that runs on the Management Engine, a separate processor built into the motherboard chipset. AMD have one that runs on the Platform Security Processor, a small ARM core built into their CPU. Various ARM implementations run a TPM in Trustzone, a special CPU mode that (in theory) is able to access resources that are entirely blocked off from anything running in the OS, kernel or otherwise. ↩︎

8. Unless the TPM is cleared, in which case it’ll generate a new internal seed and now the keys will be different to before the clear ↩︎

Canadian cybersecurity figures say they were shocked after ransomware negotiator Edward Dubrovsky was reportedly arrested in Pennsylvania in connection with the FBI's ShinyHunters hacking investigation. "We will continue to work closely with our partners to disrupt what's left of the ShinyHunters group and their associates, no matter where they operate," wrote FBI Director Kash Patel on social media. CBC News reports: Reuters reported Sunday that sources familiar with the matter identified the arrested suspect as Ed Dubrovsky, a Canadian cybersecurity executive whose career has focused on helping clients negotiate with ransomware attackers. Court documents from the U.S. District Court for the Eastern District of Pennsylvania show Dubrovsky is facing two criminal charges: conspiracy to threaten to impair the confidentiality of information with the intent to extort money, and interference with commerce by threats. The allegations have not been proven in court. "For the cybersecurity community in general, I think that there's a sense of shock," Toronto-based tech and cybersecurity analyst Ritesh Kotak told CBC News on Monday. Kotak says Dubrovsky is "very popular" and has spoken at numerous conferences, but stressed that the charges "are clearly just allegations" and that it is not yet known "what exactly has happened." "This is an individual that was for the most part respected when it came to ransomware negotiations," he said. "A lot of people are familiar with his work as well." ShinyHunters is one of the world's most prolific data theft and extortion groups that's been tied to major campaigns, including a recent breach involving FBI employee data, a cyberattack on Canvas, as well as various cyberattacks affecting companies including Telus, Microsoft, and Ticketmaster.

Read more of this story at Slashdot.

Apple has unveiled the $299 HomeView, a 7-inch smart display that combines Siri AI, FaceTime, customizable widgets, and Apple Home controls in a countertop or wall-mounted design. It also acts as a Matter controller and Thread Border Router, supports up to six facial-recognition profiles, and can use personal context from messages, calendars, and email when paired with a nearby Apple Intelligence-capable iPhone. The Verge reports: The device's square shape makes it feel less imposing than larger smart displays like Google's Nest Hub Max or Amazon's Echo Show 11, and I can see it fitting nicely on my kitchen counter -- though it might be a hair too big for my bedside table. The HomeView is the centerpiece of Apple's new push into the home. It costs $299 and launches alongside a new collection of cameras, thermostats, and a door lock designed for Apple Home. As a smart home hub, Matter controller, and Thread Border Router, the HomeView can orchestrate these and other Apple Home and Matter smart home devices. It's available in eight countries at launch: the US, UK, Canada, Australia, New Zealand, Singapore, South Africa, and India. Pre-orders are open now, with devices shipping November 13th.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Yahoo Finance: Microsoft has debuted its latest AI chip, the Azure Maia 300, as it looks to reduce its reliance on third-party processors from the likes of Nvidia and AMD. Unveiled at the OCP Global Summit 2026 in San Jose on Monday, the Maia 300 will join Microsoft's Maia 200 and Maia 100 chips as part of what the company said will be multigigawatt deployments beginning next year. The Windows maker said that will make its Maia chips the "primary AI inference system for Microsoft products and services." The company said Maia 300 provides 40% more tokens per megawatt than "leading GPU-based systems," a clear swipe at Nvidia, and that a 96-chip rack offers seven times the rack-scale token throughput of Microsoft's Maia 200. [...] The Maia 200 chip currently powers its Microsoft production workloads, including Microsoft 365 Copilot, as well as OpenAI models, Microsoft's MAI models, and open-source models. That provides 1.7 times more tokens per watt for AI capabilities in Microsoft's Teams, Copilot, and Cowork software versus other GPU-based systems, the company said.

Read more of this story at Slashdot.

LinuxDays 2026, the largest open-source event in Czechia, took place on the first weekend of October, and we had a Fedora & CentOS booth there again. This time, we got a smaller table and our booth equipment was more modest because no one traveled from Brno by car—we only had what we could carry on the train. However, we had quite a few nice stickers and one Framework laptop, which generated a lot of attention again.

I was happy that I didn’t have to staff the booth alone; I was accompanied by Vojtěch Trefny, a long-time Fedora contributor.

Even though CentOS Stream has existed for seven years now, we still received questions like: “Oh, CentOS is still alive? I thought Red Hat killed it a long time ago.” This was typically the starting point for a conversation about the differences between the original CentOS and CentOS Stream, as well as their relation to Red Hat Enterprise Linux.

Most questions about Fedora were related to Framework, which didn’t come as a surprise given that we were showcasing Fedora Linux 45 on a Framework Laptop 16. People asked whether there is any cooperation between Fedora and Framework, whether Fedora Linux is a good OS for Framework hardware, and whether Framework is a good laptop option for Fedora Linux. To all of that, we had very positive answers.

It was an exhausting weekend because we had dozens of conversations, but it was also refreshing to meet Fedora and CentOS users and hear feedback directly from them. I’d like to thank Fedora for sponsoring my trip and Vojtěch for helping me with the booth.

No Man's Sky is coming to iPhone and iPad on October 28, more than a decade after its rocky launch and long-running redemption arc. The title will cost $19.99, but a free trial will let users try it out before purchasing. Ars Technica reports: It will run on devices as far back as the iPhone 11 and the third-generation iPad Air. No Man's Sky might not have the most cutting-edge AAA graphics (though they're still strong, and they've come a long way since launch via updates), but the game's uncommon method of generating galaxies of incomprehensible scale on device consistently for all players from a single-seed happening on a phone is remarkable for those of us who remember phones performing far behind consoles or desktop PCs. This version of the game includes all of the content and systems updates to the game that have been added over the years -- the expansions that famously took the game from a rocky launch reception to a widely beloved redemption story. There are a couple of compromises, though, and it's similar to what we saw with No Man's Sky on the Nintendo Switch. Hello Games says the ability to build and explore player-made planetary settlements is limited to the iPhone 15 Pro and later, and multiplayer is not supported on any iOS device. "We are excited to see player feedback on iOS, and will support it appropriately based on how many folks are playing," the company says, leaving the door open to perhaps not supporting all future content updates if the player base isn't there to justify it.

Read more of this story at Slashdot.

No single person can know everything happening in Fedora at any given time. I say this often in our community, half as a warning and half for comfort. For a while, I did not really believe it applied to me. I wanted to know everything. I joined new teams, participated in tickets, and either participated or led meetings across the project. Surprisingly, as a young university student, I held a vast amount of it in my head.

But Fedora does not stand still long enough for that to last. Eventually, I was spread thin across more teams than I could realistically track. As my academic load increased or I began an internship, promises I made quietly fell off my radar. It was not because I did not care. It was because the systems I used to track them could not keep up with the sprawl, when my available time to contribute changed.

However, as I reentered the Fedora community as a Red Hat employee, the same systems I used as a student were challenged. As I get going with my new role, I am rethinking how I can rebalance my bandwidth sustainably. So, this post is about how I started managing multiple Git repos with AI agents to claw back some of that bandwidth. It is not really a story about a remarkable tool. It is an argument that in a project this sprawling, protecting your attention is the real win. I will cover two moments when things fell through the cracks, the workflow I built to catch them, a real example of it working, and an honest take on trusting AI when it sometimes gets things wrong.

Why managing multiple Git repos gets hard at Fedora’s scale

Fedora is sprawling. Fedora’s distribution Git (dist-git), the home for package sources, holds something like 20,000 packages. Add the team and SIG repositories that coordinate the people behind those packages on Fedora Forge, and the number of places where decisions get made is enormous. Yet, most contributors only touch a handful of them. However, even a handful is often scattered across different platforms, with no single view of all of it.

Where things fell through the cracks

Before this workflow, it felt like pure chaos, and I have the scars to prove it. Fedora runs on mailing lists, Fedora Discussion topics, Matrix chat rooms, and Fedora Forge issues/tickets. Furthermore, all of these are spread across dozens of teams, Working Groups (WGs), and Special Interest Groups (SIGs). In short, there are a lot of different places to follow a lot of different things.

For a long stretch, the Fedora Marketing Team had a backlog of tickets. In a few cases, contributors asked for talks and presentations to be uploaded to the Fedora YouTube channel. I had the access to do it and other YouTube maintainers were no longer active, so therefore, it was quietly mine to own. I saw the tickets at least once, but I was overworked and busy with higher-priority work. The YouTube videos slid off my list. A new volunteer eventually picked them up months or even a year later.

Additionally, Fedora also runs meetings well… on paper. Fedora holds virtual text meetings in Matrix chat rooms with a bot that logs everything. Each meeting has a clear start, a clear end, and annotated topics. But a faithful log is not the same as follow-through. For example, in AI/ML SIG meetings, we discuss a decision or someone takes an action item, and it gets logged. But it does not always make it back into the relevant ticket or discussion post. The record exists, but it does not connect itself to the places that need updating.

Patterns like this repeat themselves. The examples above are merely specific examples of where things fall through the cracks. However, there are things like this that happen everyday in different corners of the community too.

The AI multi-repo workflow

So, here is the workflow I use now. It does not get rid of all the chaos, but it helps me manage it much better. First, I point an LLM-gen-AI agent at a directory holding several cloned Git repositories. For example, the AI/ML SIG docs repository, AI/ML SIG tickets repository, and Agent Skills library. Then I ask it to analyze across all of them.

I also feed it meeting logs or summaries. I ask it to cross-check them against open tickets and Fedora Discussion topics:

• Did we document the decisions?

• Did we track the action items?

• Is anyone still waiting on a reply?

Critically, I do not want it reading only files from my local git clones. I want it to query the remotes too: the Fedora Forge API, issues, discussions, and more. The underlying Forgejo API is enormous. It lets the agent track the actual cadence a team works at, not just a snapshot.

A word on trust and hallucination

I have to be honest here: the agent sometimes gets things wrong. It will occasionally misread a thread or hallucinate a detail. However, I do not think that disqualifies it. Humans get things wrong too. I would rather have slightly imperfect visibility into tens, hundreds, or even thousands of repositories than none at all. Ultimately, the question is not whether the agent is ever wrong. The question is what level of risk you are willing to accept for the visibility you gain.

A real example: Reviewer guidelines across three repos

Our Fedora Agent Skills Library needed reviewer guidelines. Laura Barcziová (@lbarczio), on our reviewer team, wrote a solid REVIEWING.md in the ai-ml/skills-library repo. But our separate ai-ml/docs repository only had a page on creating a skill, and nothing on reviewing one.

I used an agent in OpenCode to pull discussion context from Fedora Forge issues about our reviewer process. It helped me reconcile that context with Laura’s draft. Then I orchestrated multiple Pull Requests across the repositories at once. This brought the AI/ML SIG docs site in line with what the team had actually decided.

The real payoff is not the tool

In conclusion, the payoff is that it hands me back the capacity to zoom out. In a project where nobody can hold it all in their head, something should watch dozens of repositories. It surfaces what changed and what needs to catch up. That means I can engage with people’s feedback instead of just surviving the volume of it. When someone takes the time to review my Pull Request, I want the bandwidth to genuinely consider what they said. I do not want to just clear my queue.

I hope this overview of my flow and process is insightful. As of yet, I do not have a commenting feature on my blog, although I am looking into this. Tag me in a LinkedIn post and we can continue the conversation there.

Researchers have created a strengthened "BioPykrete" by combining ice with cellulose nanocrystals and a custom protein that binds the plant-based crystals to the ice structure. In small-scale tests, the material was about 10 times stronger than regular ice and absorbed 70 times more energy before breaking. ScienceAlert reports: Instead of wood pulp's larger, disordered fibers, the researchers used cellulose nanocrystals here. Cellulose is the main structural material in plants, and in nanocrystal form, it can act as a microscopic strengthening agent for other materials, including ice -- essentially stopping cracks from spreading easily. The protein used here was called CBM3a-AFPIII, a combination of an antifreeze protein (AFP) and a carbohydrate-binding module (CBM). Its job was to act like glue, keeping the cellulose nanocrystals and ice bonded together. It's a clever approach, and the researchers think that by tweaking their ingredients and methods, they might be able to improve their 'super ice' even further. "Optimizing solidification kinetics and freezing protocols, alongside developing diverse AFP-CBM variants, could yield even higher-strength composites," write the researchers. Besides further tests of the durability of the material, the researchers are also keen to take a closer look at how cracks propagate through BioPykrete, to confirm that the underlying strengthening mechanisms are what they think they are. Further down the line, this approach could open up a whole new landscape for materials used in packaging, construction, and more: Using a custom protein to bring two unlikely compounds (ice and cellulose) together. "By bridging the gap between recombinant protein design and structural engineering, we have developed a high-performance material specifically engineered for the rigors of the world's most extreme environments," write the researchers. The findings have been published in the journal Colloids and Surfaces B: Biointerfaces.

Read more of this story at Slashdot.

An anonymous reader quotes a report from ZDNet: Many open-source developers still dislike AI. The latest example is System76 banning AI-generated content from its COSMIC desktop. At Open Source Summit Europe, Linux creator Linus Torvalds offered a different take: "I actually really like using AI," Torvald told Dirk Hohndel, his good friend and head of Ericsson Software Technology, in their latest discussion. [...] Torvalds said, "I think that you need to be very careful using AI when you're doing something real and important." Torvalds explained he hadn't always felt that way about AI programming. "I used to think it was just not very good -- but now I'm at the point where I actually really like using AI." "To be fair," he continued, "I don't do a lot of kernel programming. I'm a maintainer. The Linux kernel is a project where other people do the real work, and I act as the collection point. But I still enjoy programming immensely. I think AI is a wonderful tool if you use it correctly and treat it as a tool, and I find it makes programming much more enjoyable." Torvalds recalled, "I started programming in 1981 or so, and back then computers were much simpler, and you could understand what they were doing, and also the programs you compared your own programs to were much simpler." "It's a different story today," Torvalds said. "The bar in software engineering has grown so high that it's hard to see your own small efforts as worth anything, because you're used to all these polished, professional programs. [...] A lot of people make fun of vibe coding, but I think it's a wonderful way to find joy in programming. It makes you feel like you're doing something relevant. It allows you, as a new programmer, to do things that you would otherwise have a really hard time with." He continued: "I love the concept of AI as a gateway drug because I was working on my own toy project, the guitar pedal, and I knew what I was doing. I had a user interface that I had written myself in C that was running on a microcontroller that was running on this small screen, and I was like, "This is just stupid. It looks like something from the '80s; I wanted it to look like something from this century. But I don't do Java. I do kernels." "So, I use AI to do the things that I'm bad at," Torvalds went on, "I'd seen all the same YouTube videos you have. Give AI a prompt, and it will do it. So I gave it a prompt, and it did it, and it was horrendous. Then I said, 'Hey, look! I already did this in C. I did it the right way. It's just ugly." Torvalds acknowledged that AI tools are helping identify security vulnerabilities and improve the Linux kernel, but at the cost of overwhelming maintainers with questionable bug reports and superficial fixes. He called some submissions "mindless band-aid kind of patches." That said, despite AI's growing influence, Torvalds believes Linux's success comes from steady, incremental development rather than sweeping changes. "I'm a big believer in the whole incremental small changes that, over time, turn into big features," he said. The development goal remains "incremental improvement and steady progress all the time."

Read more of this story at Slashdot.

I remember back in 2020, people were complaining that we didn’t have enough documentation for creating GNOME Shell extensions. They said it was almost impossible to figure out where to start. They were right, learning all of it without proper documentation was a huge challenge for me too.

So, I decided to learn the GNOME Shell source code and shared what I learned in a YouTube tutorial series. I spent countless hours learning and making those videos, and the community was very happy to finally have guides and documentation.

On the GNOME side, Sriram Ramkrishna started the GNOME Extensions Rebooted project. When he noticed my tutorials, he invited me to join the team to help write documentation. I spent many hours learning GTK4 and the GNOME Shell 40 source code to write the famous GNOME Shell 40 Port Guide. I’d argue that many extension authors would have given up without it. Migrating from GTK3 to GTK4 and adapting to the changes between 3.38 and 40 was overwhelming. I wrote the guide with many examples, so developers could easily understand how to port their code.

Today we have all the documentation needed to start and maintain extensions, but nowadays, people are just simply vibe coding GNOME Shell extensions without reading any of it before submitting it to EGO. To be honest, in the age of LLMs, it feels like our documentation is feeding LLMs more than actual human developers.

For years, I tried my best to help the community, answering questions daily and reviewing extensions submitted to EGO, often spending 4 to 10 hours a day managing the whole extensions eco system. GNOME was incredibly generous this year and awarded me the GNOME Pants Award 2026 for my contributions to GNOME and the extensions ecosystem. That was a major personal milestone, and honestly, a testament to the growth of our community as a whole.

I’m writing this post because since early 2025, the volume of submissions has exploded. The vast majority are AI generated, and the huge workload is pushing me close to burnout. To be clear, all of my work is unpaid. While managing this volume easily matches a full-time job, my monthly donations remain close to zero. Given how many people use GNOME extensions daily, I truly believe our community can help make this workload doable. If you find value in what I do or if my work has helped you out over the years, please consider supporting me through donations. Without financial support, I simply won’t be able to keep going at this pace.

AI generated extensions, especially when prompted by non developers are frequently bloated and poorly designed. Because extensions run directly inside the GNOME Shell process, quality control is critical. Low-quality, AI generated code directly threatens the stability of the entire shell, and vibe coders need to realize that. As someone who reviews code across all of EGO, I can tell you that LLMs produce needlessly complex, hard to read code that takes significantly longer to review. To make matters worse, some submitters rely on AI to generate replies during the review process. I even received a response that accidentally pasted the LLM’s instructions intended for the user:

Then, respond to the specific points it points to and maintain a real public repository, with testing instructions and development history. This gives the base reviewer to evaluate maintenance and quality, without trying to hide anything.

On a positive note, a while back I published An Open Letter to AI for Generating GNOME Shell Extensions to fix specific code patterns their models were generating incorrectly and I noticed most of those issues disappear just a few weeks after that post, which is great news, but also proof of just how heavily our documentation is feeding these LLMs.

Anyway, we need viable solutions to keep the EGO ecosystem stable, trustworthy, and sustainable:

• I’m asking developers who understand GTK and GNOME Shell source code to join the review team. I am happy to mentor and teach you the review process. Please note that while this is a volunteer role, we need people who can be consistently available during the week.
• As many of you know, we introduced the Shexli linter a few months ago to make the review process easier. We need someone to help us improve it. The workflow is straightforward: reviewers identify false negatives and false positives during reviews, and you fix them in Shexli.

If you are interested in joining the review team or helping with Shexli, please reach out to us on GNOME Extensions Matrix channel. Thanks for being part of the GNOME community!

Firefox 158 is now available with JPEG XL image support enabled by default, making .jxl images a standard part of the browser rather than an experimental feature. The release also adds JPEG XL to Firefox's default image Accept header, improves Smart Window form filling, and brings new CSS typed-arithmetic support for developers. Phoronix reports: At long last, Firefox 158 is ready to go with JPEG-XL image support as an alternative to the likes of WebP, JPEG, PNG, and GIF. The default HTTP Accept header for image requests also now supports "image/jxl" for the JPEG-XL image format. Prior releases of Firefox had JPEG-XL gated by an experimental option. Firefox 158 also now supports filling forms faster in Smart Window when clicking into a form field or selecting Fill from sources. On the developer side, CSS typed arithmetic are now supported to use functions like calc() to divide two values of the same data type even if of different units. Developer changes and release binaries can be found at their respective links.

Read more of this story at Slashdot.

An attacker could log in as another user without passing the password or signature checks meant to stop them.

You do not have to run an untrusted program for it to become dangerous.

A local user with no write permission changed a root-owned file's contents in a published XFS demonstration.

An unauthenticated visitor could make an affected WordPress site permanently delete content already in its trash by submitting a public form.

An anonymous reader quotes a report from Bloomberg: Epic Games delayed the release of an upcoming video-game collaboration with Walt Disney and told its developers to use more artificial intelligence tools to finish the game, according to people familiar with the project. The title had been slated for release in March, but is now delayed with no new date communicated, said the people familiar, who asked to not be identified because they weren't authorized to speak publicly. Developers on the game, a shooter featuring characters from the Marvel and Star Wars franchises, were instructed to implement an "AI first" production model using tools such as Anthropic's Claude. Humans will then manage and guide that work. "No more hand-written code," one of the game's directors told staff in an internal message reviewed by Bloomberg. The director added that all art for the game would be "generated with full AI workflows." Even before this announcement, the maker of the popular Fortnite game had been pushing hard for the use of AI across all of its divisions. But this is the first time a major video-game company has attempted to build a title primarily with AI. "We're embracing AI-accelerated development, led by Epic developers who are the visionaries and creative drivers for everything we do," said Jake Jones, communications director at Epic Games, in a statement to Bloomberg News.

Read more of this story at Slashdot.

Meta CEO Mark Zuckerberg says the company has reached the AI "frontier" with its new Muse Wonder model and will be offered as a closed, paid product for businesses. Zuckerberg also rejected calls for an industry-wide slowdown, arguing that AI can be managed with conventional guardrails as Meta continues spending heavily on models, infrastructure, and talent. The Financial Times reports: Speaking with the FT as Meta releases its Muse Wonder AI model on Monday, the billionaire chief executive claimed the new system was "going to allow much more sophisticated behaviours that are at the frontier of what is being done in the AI field." [...] "Getting to this point both required a large amount of compute and investment, and a lot of very rigorous scientific work by the group working on it over an extended period of time," said Zuckerberg. [...] Meta said Muse Wonder outperforms Anthropic's Claude Opus 5.5 and Fable 5.1 and OpenAI's GPT-6 Astra on some technical benchmarks. It said the new model can be used to carry out complex tasks from "understanding a lease to making sense of financial or health information." However, Muse Wonder will also be "closed," with its best versions sold directly to businesses. That pits it against Anthropic and OpenAI for corporate AI contracts in a serious test of its ambitions. Zuckerberg signaled further spending as Meta was "already working on the next step up," adding that its model development would "probably feel like it'll go quite a bit faster from here." However, he also shrugged off mounting fears that the technology was advancing at a rate that will soon surpass human control. [...] The Meta chief declined to be drawn on his figure for "P(doom)" -- a much-discussed Silicon Valley term to describe the probability that AI will lead to mass destruction. Instead, he argued that responsibility should fall on the individual lab to ensure model safety. "I'm much closer to the belief that AI is a technology that can be engineered with normal guardrails and built responsibly than the anthropomorphic vision of AI, which is that it is just going to go do its own thing," he said. Zuckerberg has previously rejected calls by the heads of AI labs such as Anthropic's Dario Amodei and OpenAI's Sam Altman for an industry-wide "slowdown" in AI development. He also played a key role in crafting US President Donald Trump's White House "Accord on Super Intelligence," setting out principles for self-regulation of the industry, which critics say falls far short of a formal global AI governance regime.

Read more of this story at Slashdot.

Google has introduced the $179 Fitbit Edge, a new fitness tracker with a 1.34-inch OLED display, built-in GPS, ECG support, week-long battery life, and Fitbit's first user-replaceable battery. "And unlike the Pixel Watch, it's compatible with Android and iPhones via the Google Health app," reports Wired. From the report: The Edge has a user-replaceable battery, a Fitbit first, aligning with Google's efforts to make its Pixel Watch more repairable. (Likely also due to new battery regulations set to take effect next year in the European Union.) Repair options will vary by region and availability. If you find the Pixel Watch's round face too bulky, the Edge's capsule-shaped alternative might suit smaller wrists better. If the Charge 6's 1.04-inch display was too small, the Edge upgrades it to a larger 1.34-inch screen. The difference is noticeable, and that extra real estate could make a real impact when glancing at your metrics mid-workout. The Edge borrows a few more attributes from the Pixel Watch, including an altimeter that uses atmospheric pressure to measure elevation changes. That means it can record elevation gain and loss during outdoor activities, track floors climbed, and add more context to your outdoor stats. It also has a far-field skin temperature sensor, replacing the standard device temperature sensor found in other Fitbits. By bringing some of the Pixel Watch's more advanced hardware to a fitness-first wearable, Google is giving the Edge a compelling middle-ground position in its lineup at a Fitbit-friendly price. The Edge inherits the Fitbit Air's improvements while restoring several Charge 6 features the screenless tracker lacks, including built-in GPS and electrical sensors that work with the electrocardiogram (ECG) app. You can also control music playback on a connected Bluetooth device, as you could with the Charge 6, and Google Maps turn-by-turn directions will arrive later this year. [...] With a Google Health Premium subscription, the Edge can track blood pressure trends without manual calibration and insulin resistance trends without requiring a blood draw. Google first announced these capabilities alongside the Pixel Watch 5's debut, but they only became available at the end of September. They're also available on the Air, keeping Google's screenless tracker up to date as its lineup expands.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Ars Technica: When Russia began attacking Ukrainian data centers and telecommunication infrastructure, it apparently failed to prepare for possible retaliation. Now Russia's digital services are facing widespread outages after Ukrainian drone strikes knocked out three of the largest data centers owned by Russian tech giant Yandex within several days. Pro-Kremlin bloggers are warning that Russia's centralized digital economy could collapse because the country is not prepared for the "data center war" it started, according to posts translated by the pseudonymous independent researcher ChrisO_wiki. The Russian commentators also suggested that Ukraine's decentralized digital services could prove more resilient than Russia's system if the countries continue trading such blows. Russia initially launched a drone strike campaign targeting Ukrainian data centers and mobile phone networks in late September. The attacks temporarily disrupted Internet and cell phone service for up to 100,000 households in the Ukrainian capital of Kyiv and came as part of a broader long-range strike campaign that has involved Russian missiles and jet-powered drones hitting Ukraine's power grid infrastructure, transportation hubs, and even residential apartment building blocks. But Ukraine soon began striking back at data centers owned by the Russian company Yandex, also known as "Russia's Google," in what Ukrainian President Volodymyr Zelenskyy has described as a "symmetrical response." [...] More importantly for Russian society, the damage to Yandex's data centers has reportedly caused interruptions or outages to popular Russian payment apps and digital banking services, email, e-commerce platforms, video streaming services, ride-hailing and food delivery apps, and navigation and map services. Yandex's search engine also accounts for about 70 percent of the market share in Russia. The disruptions are even more widespread, because the data center damage also impacts Yandex's cloud computing service, which counts some of Russia's largest companies as customers, according to The Moscow Times, an independent newspaper. These include large grocery and fast-food chains as well as a household appliance retailer.

Read more of this story at Slashdot.