Agreguesi i feed

Humans are bad at writing secure code, and GNOME developers are no exception. GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code when using unsafe languages like C, C++, or Vala: it’s just too hard for even experienced developers to do properly.

The above paragraph is taken from the abstracts of my GUADEC 2024 and 2025 talks. At the time, I thought failure was inevitable: we humans were so bad at writing software that we had no chance to do it properly, and I certainly would not have trusted an AI to do better than a human. But the landscape today is completely different than last year. AI has improved considerably, and offers a magic fairy wand solution to this problem: we can now simply ask a language model to look for vulnerabilities in our software. They are quite good at this.

There is zero hope of maintaining quality software in 2026 without AI vulnerability scanning. Any claims to the contrary are unserious and delusional. The tremendous quantity of bugs found in our best-maintained projects, like GLib and fwupd, should speak for itself. Failure to scan our projects is an unfair disservice to our users. If we don’t find the vulnerabilities by scanning projects ourselves, attackers certainly will, because the Linux user base has increased to the point that Linux users are finally numerous enough to be worth targeting. Meanwhile, AI has made it easier than ever to build working exploits, which was previously unheard of.

Already resolved all the detectable vulnerabilities? Then ask the AI to look for non-security bugs as well, to further improve quality. GNOME code is generally much better than it used to be, but there remains considerable room for improvement. For the first time in history, we now have the opportunity to improve software quality to a degree that was never realistic before.

Have you heard that most AI bug reports are “slop?” Not so in 2026. That was true for most of 2025, but the quality of AI-generated vulnerability reports has drastically improved. That is not to say that we no longer have problems with bad vulnerability reports, but in general, nowadays most of them are pretty good. (Daniel Stenberg reports the same pattern for curl.)

AI-generated vulnerability reports have nevertheless introduced many undesirable impacts on GNOME maintainers. They are usually annoyingly verbose and unnecessarily detailed. They often exaggerate the severity of the problem, or make misleading or irrelevant claims. They are occasionally incorrect. Sometimes they include outright fabricated data, such as fake stack traces (which is not the norm, but sadly also not uncommon). A good human reviewer will notice and resolve most of the above problems before creating a bug report on your issue tracker, but often problems are reported by inexperienced humans who do not actually know what they are looking at and simply copy/paste everything blindly. Even when the generated issue report is good and avoids all of the above problems (which is rare), good vulnerability reports in sufficiently high quantity can still overwhelm volunteer maintainers. And even if reporters submit a merge request to resolve the problem so maintainers don’t have to (which is also rare), reviewing those merge requests is itself more unwelcome work for overworked maintainers.

That all is to say: I understand the pain caused by the current wave of AI-generated issue reports. Nevertheless, they are essential and unavoidable. We have to learn to accept and deal with them, not stick our heads in the sand and ignore them.

Some GNOME maintainers have adopted a policy prohibiting AI-generated content in issue reports. Do not do this. Nowadays, the overwhelming majority of vulnerability reports are AI-generated. Projects that choose to ban AI-generated content in issue reports might as well ban all vulnerability reports; the effect will be approximately the same.

I propose the following:

• GNOME maintainers should rewrite their AI contribution policies to permit AI-generated vulnerability reports, as I previously requested four months ago.
• Projects that continue to prohibit AI-generated vulnerability reports are no longer suitable dependencies for GNOME, and should be developed someplace other than GNOME GitLab.

We don’t have to tolerate bad issue reports, but AI use alone should not be disqualifying.

Shouldn’t humans rewrite AI-generated bug reports?

When I complain that maintainers should allow AI-generated vulnerability reports, the most common counterargument is that humans should read the AI’s report, understand it, and rewrite the entire thing to remove all AI-generated content. Some bug reporters actually voluntarily do this, but this is rare.

Vulnerability reporting is a public service, not an obligation. If you ask a reporter to do any amount of extra work, they might be willing to do so, but it’s much more likely that they will either stop looking at your project and move on to something else, or continue looking at your project and publish the vulnerability reports someplace other than your issue tracker.

Rewriting issue reports also does not scale. Let’s say you use AI to find 100 security bugs in a GNOME project, a number consistent with the results of actual scans (read on). Would you really spend months rewriting those bug reports before submitting them to upstream? Validating the AI’s claims, upstreaming the issue reports, and submitting merge requests is already a lot of work. Not many people would be willing to additionally rewrite all the issue reports. That’s more work than everything else combined, and is unrealistic.

Even with just a small number of bugs, I would hesitate to spend much time rewriting an issue report because I have many other tasks I would rather spend my time on. At best, I might prepare a quick summary, but it won’t be as useful as a full report.

The CVE Wave Hits GNOME

The current wave of vulnerability reports is reflected in GNOME’s CVE issuance trends:

YearGNOME CVEsGNOME CVEs Excluding GIMP, Gegl, libxml2, and libxslt202121142022146202313420243728202597492026 Year-to-date (2026-09-30)141742026 Normalized188 (141 * 4 / 3)99 (74 * 4 / 3)

The trend here should be pretty clear. Until recently, not many people were reporting vulnerabilities in GNOME. That has changed. We are currently dealing with an order of magnitude more CVEs than just 3 years ago. AI is not the only reason for this; GNOME maintainers have also gotten a little better at flagging issues so that I add them to security tracking. But AI is the primary cause for the increase.

(A few technical notes on this table. CVEs are classified by the year the issue was reported to GNOME, not by the year in the CVE identifier, so e.g. many CVE-2026 issues are counted in 2025. Vulnerabilities reported in 2026 which do not yet have CVEs are not counted, so you can think of the data as being accurate through roughly September 1; multiply the 2026 numbers by 4/3 to make them comparable to the prior years. I count only issues reported to GNOME Security, so any unreported CVEs do not count.)

Although there are still 3 months left in 2026, we will never have data for the rest of the year because I have ended security tracking for new issue reports and nobody else has volunteered to do that work. These CVEs exist only because I request them myself, so I expect the number of CVEs to drastically decrease going forward.

The CVE Wave Hits WebKitGTK

A similar pattern holds for WebKitGTK:

YearWebKitGTK CVEs2015175201657201715820181012019992020382021522022502023452024382025662026 Year-to-date (through WSA-2026-0006)305

CVEs are reported against the year they appeared in a WebKitGTK security advisory, not the year in the CVE ID. The large increase in 2026 is entirely due to AI analysis of Skia and ANGLE. WebKit bundles these libraries because they are not designed to be installed as system libraries, so their vulnerabilities should be counted the same as vulnerabilities in WebKit’s own code. Excluding Skia and ANGLE, there are actually only 21 other WebKitGTK CVEs so far this year, a significant decrease, but excluding CVEs in bundled code would not be fair.

There has actually been a very large increase in WebKit security fixes this year, but this has not resulted in any increase in CVEs. Apple generally creates CVEs for flaws found by external researchers, not often for flaws found by WebKit developers, so the increase in security fixes is not reflected in the total number of CVEs. Only a small fraction of WebKit vulnerabilities receive CVEs.

I had not previously noticed that the count of WebKitGTK CVEs had, until 2026, been decreasing over the past decade. I am not sure why. I also do not know how to explain the low number in 2016.

Announcing the GNOME Bug Bounty Program and Announcing the End of the GNOME Bug Bounty Program

My blog post to-do list says that I need to write a blog post announcing the creation of the GNOME Bug Bounty Program on the YesWeHack platform. Oops, too late. It’s already closed. (Once a task enters my to-do list, it can be a very long time before I get around to doing it.)

The GNOME Bug Bounty Program was generously sponsored by the Sovereign Tech Resilience program of Germany’s Sovereign Tech Agency. I’m not sure precisely when it opened, but the first vulnerability was reported on June 27, 2024, so it would have been sometime shortly before then. We accepted issue reports only for GLib, glib-networking, and libsoup, because GNOME had never operated a bug bounty program before and we did not know what to expect. Starting small had — naively — seemed like a prudent way to avoid a large quantity of issue reports. I had wanted to expand the program to cover all of GNOME, but this failed due to the overwhelming deluge in issues reported against GLib and libsoup.

I requested that the bug bounty program end because I was overwhelmed with incoming AI-generated issue reports. The final issue was reported on February 23, 2026. Here are the results:

YearReports SubmittedReports Accepted20242614202515033202612224Total29871

Those numbers for 2026 reflect less than two months’ worth of issue reports, so you can see why it was no longer sustainable.

After the program closed, our work was not done: there was a long backlog of reports to work though. We just last month caught up with accepting the last of the issues reported back in February, and the last bounty was finally awarded earlier today! Even with YesWeHack’s professional triagers analyzing the issue reports before I reviewed them, keeping up with such a large number of vulnerabilities was not easy for me.

At this point, all reports not accepted have been rejected. The program awarded €183,900 in bounties for 71 vulnerabilities: 45 in libsoup, 23 in GLib, and 3 in glib-networking. Award amounts varied from €500 (16 awards) to €7,500 (2 awards). The arithmetic mean award was €2,662.99.

Bug bounty programs are an exception to the rule that most AI-generated vulnerability reports are good. You can see the number of reports accepted is a small fraction of the number of reports submitted. Excluding 30 reports closed as duplicates, that leaves 197 reports rejected. Turns out, people will submit bad reports when financially incentivized to do so. The low percentage of accepted reports even understates the problem, because many of the accepted reports were actually not very good! Many accepted reports did successfully identify valid security problems (in fact, many of the rejected reports successfully identified valid security problems!), but required many rounds of revision and corrections.

Suffice to say, I have reviewed a lot of really bad AI-generated vulnerability reports. But the reports we received via the discontinued bug bounty program are not comparable to the reports received via regular GNOME issue trackers or the security bug report form. We do still occasionally receive bad vulnerability reports, but not often and not many, so it’s not a big problem anymore. When people submit AI-generated reports without hope of a financial award, those reports are generally much better.

Lessons from the Bug Bounty Program

Closing the bug bounty program because it found too many vulnerabilities is not a particularly pleasant result. That said, it was still a partial success in that it uncovered lots of bugs in libsoup and GLib.

I had hypothesized that libsoup was probably not very secure, but I never imagined just how many vulnerabilities would be discovered. To reduce the quantity of incoming issue reports and better reflect actual risk to GNOME users, I eventually removed all denial of service bugs from program scope, and then later removed SoupServer from the scope due to too many request smuggling vulnerabilities, which are HTTP request parsing bugs that pose no threat to GNOME users. Even with those changes, the libsoup vulnerability reports kept coming until I gave up. The silver lining is that libsoup is now relatively much more secure than before. Other bug reporters have been submitting AI-generated bug reports using the normal libsoup issue tracker, so fortunately the improvements to libsoup will continue despite an end to the financial awards.

I had hypothesized that GLib would be much better than libsoup. I’m not sure whether I was correct. Evaluating the severity of GLib flaws is much harder than for libsoup, since GLib vulnerability reports are generally hypothetical in nature: usually some proof of concept program calls a GLib API using valid but improbable values, then something bad happens.

A large portion of the GLib bugs were integer overflow flaws, which generally result in buffer overflow. I am now more scared of integer overflow than anything else. It’s likely that most software projects have many integer overflow problems. Fortunately, we should be able to catch most such problems by adjusting the compiler flags we use. In particular, -Wconversion or -Wint-conversion and -Wsign-compare should help here. Some GNOME projects already use -Wsign-compare, but I suspect most do not. I think few or no GNOME projects use -Wconversion or -Wint-conversion.

Resuming the bug bounty program would only be possible under substantially different conditions. What we were doing was not working well. To resume, we would need to limit the scope to projects that regularly perform their own AI vulnerability scans. We would also most likely want to pay only for functional exploits, rather than for all vulnerabilities. GNOME code is currently not good enough to continue paying for every vulnerability, and it no longer makes sense to pay bounties for issues that can be found by AI scanners.

Red Hat Scans GLib

Red Hat has contracted with AISLE Research to perform AI vulnerability scans of various GNOME projects. We received a large quantity of findings, and are only just now beginning to individually validate and report our findings to upstream. GLib is by far the hardest hit project, which I was not expecting, accounting for more than 40% of our total findings. I’m not certain why, but perhaps this is because GLib provides so many public APIs. Data passed to public APIs is potentially untrusted, so the attack surface is considerable.

Red Hat’s scan of GLib found 118 vulnerabilities. Or at least, it claimed to. However, due to the way we ran the scans, several of these are actually unnecessary duplicates of each other, which we have not fully deduplicated yet, so the number I report is not entirely trustworthy. Moreover, 46 of these “vulnerabilities” are bugs in gobject-introspection, mostly in the typelib support, which is evidently not very robust. A typelib controls how your program calls libraries; it is effectively calling convention, so it must inherently be fully trusted: a malicious typelib would be able to induce vulnerabilities even without any bugs! I would expect an AI ought to have been able to figure that out, but apparently not. These bugs are still real problems that we ought to fix, but all maintainers agree they are not security vulnerabilities, so let’s count all of them as false positives. That alone creates a 40% false positive rate. Ouch.

I don’t have more stats to share here because we are not yet done working through the issue reports. That said, I am quite pleased with the results thus far. Substantially all of the reports are high-quality. The false positive vulnerability reports are almost all due to one particular misunderstanding and can be treated as good quality non-security bug reports, which are still valuable. Expect many forthcoming CVE assignments for the other findings.

It’s rare for Linux vendors to proactively look for software vulnerabilities, rather than waiting for security researchers to report them. This was a successful experiment in proactively seeking out problems.

Humans Still Useful

In addition to the bug bounty program, the Sovereign Tech Resilience program also sponsored a security audit for GNOME, performed by Codean Labs. This resulted in many findings in various GNOME projects. Most notably, the scope of the audit extended to Flatpak and xdg-desktop-portal, resulting in critical findings.

Most of these issues could have been detected via AI scans, but I am not confident that AIs would have been able to discover the most important findings, like the two Flatpak sandbox escapes that I linked to above. Accordingly, I do not recommend relying on AI alone.

Humanity Still Desired

Although I like AI-generated issue reports, I particularly do not appreciate when I wind up interacting with a robot rather than with a human. It’s pretty obvious when your issue tracker or code review comments are written by an AI. Consider whether outsourcing your writing and your thinking to a language model is truly wise for your public image.

We even have one experienced GNOME developer who is obviously using AI to write all of his posts on GitLab. I am unsure whether he is copy/pasting all of his responses from an AI, or whether he is just a bot now. I especially do not understand the value of this.

Here is a soft proposal, intended only as a starting point for discussion and not as a serious proposal, for what my preferred AI usage policy might look like:

• Newer developers should exercise caution when using AI to write code. Your priority should be learning, and I wonder how much you are really learning when relying on the AI to do work for you.
• Do not use AI to write code comments. Currents AIs are terrible at writing comments. Most comments written by AIs should be deleted. If a comment is truly necessary, then I’d like to see it written in your own words. Presumably AIs will get better at this eventually, but as of 2026, human judgment is still required here.
• Do not use AI to write commit messages. AIs are actually probably better than humans at writing commit messages, but I would still rather hear your own thoughts on the code you are submitting.
• Certainly do not post AI-generated comments on an issue tracker or merge request as if they are your own. You’re not fooling anybody.

Maintain Perspective

Are you scared by the large numbers of recently-discovered vulnerabilities? There is no need to panic. Security bugs are just bugs, and they’re not necessarily more important than other bugs. Occasionally they are emergencies, but far more often they are boring and unexceptional. Security vulnerabilities are not even the biggest digital security threats that users face: those are surely phishing and trojans, with software security bugs a distant third place. No amount of CVE fixing will protect you from those more likely threats.

I don’t want to downplay the severity of security issues either. In fact, evaluating severity is hard. I quite often decide that a bug is not a big deal, only to be proven incorrect. Ideally, we would fix as many security issues as possible, and sooner rather than later. Lifetime issues and out of bounds writes are especially important to fix. Two years ago, I claimed that memory safety vulnerabilities were becoming less threatening, a claim that did not age well: that is surely no longer true due to the drastically increased accessibility of AI exploit generation.

Nonetheless, volunteer maintainers should not feel obligated to fix security issues or treat them as higher-priority than other bug reports. It’s certainly good to fix problems when possible, but my request is only that you do not prohibit issue reports, not that you attempt to personally resolve every security problem yourself. When I add due dates to vulnerability reports, that represents only a disclosure deadline — because issue reports should not stay confidential indefinitely — not an expectation that you fix the issue by that date. Resolving security problems in projects used by big tech companies that depend on your software without contributing back is basically free labor for said companies, and only you can decide whether that’s how you want to spend your volunteer time.

Rust

Yes, even projects written in memory safe languages like Rust still need to allow AI-generated vulnerability reports. Rust will indeed eliminate most memory safety issues (except in unsafe blocks), and you can reasonably expect a Rust project to have an order of magnitude fewer vulnerabilities than a comparable project written in C or C++ or Vala. This is amazing, but not all vulnerabilities are memory safety issues, so this is not an excuse to avoid scanning for flaws.

Although Rust mostly eliminates memory safety risk, any use of Cargo to download dependencies dramatically increases supply chain security risk. The risk of bundling a trojanized dependency arguably — I would even say probably — outweighs the benefit of eliminating memory safety flaws. This problem is inherent to any programming language package manager. Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software.

To Be Continued…

I have exhausted my thoughts on AI vulnerability reports, but there is still much to discuss regarding software quality. Next time, I will discuss additional strategies to improve GNOME quality without significantly relying on AI.

As previously announced, I have discontinued my tracking of GNOME security issues. Nobody else has volunteered to continue that work, so it has concluded (except for issues reported during September 2026, which I will keep an eye on until the end of this month).

Maintainers, I encourage you to request your own CVEs by writing to Red Hat Product Security. Red Hat is an ideal CNA (CVE Numbering Authority) to use for GNOME CVEs because you will receive timely responses. Ignore Red Hat’s suggestions to encrypt your mail using GPG, and use the following email template:

Hi, I request a CVE for: Summary: Requirements to exploit: Component affected: Version affected: All versions <-- change this if needed Patch available: Yes/No Version fixed (if any already): Upstream coordination: See issue report (below) CVSS (optional): Impact (optional): Embargo: No Acknowledgment: Steps to reproduce if available: see issue report Mitigation if available: <-- it's OK to write "None" Original report:

Request a CVE after making your issue report public. It’s possible to reserve a CVE in advance, but this requires twice as many steps, so I recommend making it public first, then request a CVE second.

GNOME and Fedora maintainers should feel free to get in touch with me if you have questions.

An anonymous reader quotes a report from Reuters: OpenAI has informed more than 100 organizations about incidents involving unauthorized activity tied to its AI agents, according to a blog post by the ChatGPT maker, as AI labs face mounting scrutiny over rogue AI agent activity. Here are some other details: - The Sam Altman-led company has been conducting a broad review of the activities of its AI models after the accidental hacking of Hugging Face. - OpenAI is searching through roughly 50 petabytes of data as it works to understand the full scope of its rogue agent activity. - A string of high-profile breaches globally by rogue AI agents in recent months has sparked widespread worries within the AI industry over its ability to control the more powerful AI models now under development. - "In some cases, models used internet access in unintended ways or, in retrospect, did not have the ideal restrictions applied. Over the last several months, we have been applying new technical and operational measures to avoid similar problems, or catch them very early, and will continue this work," OpenAI said. - OpenAI previously said the review would take months to complete given the scale of the work. - The Hugging Face incident remains the most severe rogue agent activity OpenAI has identified from its AI models so far.

Read more of this story at Slashdot.

fjo3 shares a report from The Guardian: Communities across California are rushing to prepare for the imminent arrival of the so-called "Kelvin wave," a massive underwater band of warm water threatening to inundate swaths of the vast North American shoreline. The wave is nearing southern California and expected to reach the San Francisco Bay Area by early October, as it crawls toward Alaska. Waters could rise by a foot along the California coast, according to scientists, who have warned that this could dramatically double the 8-12in rise in sea levels already caused by climate change over the last century. The Kelvin wave doesn't climb and crash like a typical ocean wave; rather, it swells the tides from beneath the surface. It's effectively a massive slosh of warm water, driven by El Nino conditions, that moves across the Pacific before colliding with the South American coastline and surging north. It also won't transport water in the way a tsunami might, but creates conditions that enable higher sea levels to linger. On their own, Kelvin waves aren't always hazardous, according to Mike Jacox, a research oceanographer with the National Marine Fisheries Service, though they can reduce the growth of phytoplankton that form the base of the marine food web. "But when there are very high tides or storm surges, their effects can be amplified," he said. If the rising waters coincide with other climatic events, such as rainstorms and high tides, the phenomenon could swallow beaches, chew away bluffs and coastlines, and submerge streets, homes and businesses. "This coming Kelvin wave is just the beginning," said Dr Jonathan Warrick, a research geologist at the US Geological Survey. "The thing to look out for is what will happen in January, February and March -- that's when we get the biggest storms, we get our largest waves and we have some very large tides." If these events align, their effects will compound, setting the stage for a tumultuous winter. Together, Warrick said, the systems will pack a far bigger punch. "When it comes to these storms and the tides," he said, "we really are kind of rolling the dice."

Read more of this story at Slashdot.

Alongside a refreshed Kindle lineup, Amazon today introduced two accessories that bring physical buttons back to its touchscreen e-readers. The $34.99 Kindle Click is a Bluetooth remote that lets readers turn pages and adjust brightness without touching the device, while a new $79.99 magnetic cover is available for select Paperwhite and Colorsoft models. GeekWire reports: Amazon says [the Kindle Click is] meant for reading under the covers, on a treadmill, or on an airplane tray table. It's available for preorder and ships Oct. 28. It recharges over USB-C, includes side buttons for adjusting brightness, and works with Kindles released in 2024 or later. The company cited BookTok as an inspiration, Bloomberg reported, a reference to the community of readers on TikTok who post book recommendations, reviews and their reading setups. Kindle fans there have been showing off third-party clickers for years. Amazon is also bringing back physical page-turn buttons, which disappeared when the company discontinued the Kindle Oasis in 2024. This time they come in a separate $79.99 magnetic cover, which works only with the new Signature Edition versions of the Paperwhite and Colorsoft. The new Kindles have screens that sit flush with the edges, colors that wrap around to the front, and optional aluminum housings. They also have user-replaceable batteries to comply with European Union rules, Amazon told The Verge. The base Kindle starts at $149.99, or $189.99 in aluminum. The Paperwhite starts at $199.99 and the Colorsoft at $289.99, with Signature Editions at $249.99 and $319.99. Those prices match what Amazon has charged since August, when it raised Kindle prices by $40 to $50, citing memory and storage costs. The base Kindle is available now. The Paperwhite and Colorsoft ship Oct. 28.

Read more of this story at Slashdot.

Linux developers have proposed an IPsec fix after reproducing a memory error in IP-TFS, a mode that groups and pads encrypted traffic to make traffic patterns harder to infer.

Linux developers have proposed a FastRPC fix for a race that can leave the kernel using memory after it has been released.

Linux developers have proposed six fixes for the driver that reads QNX6 filesystems, a disk format associated with the QNX operating system.

LightLLM, software used to serve AI models, can expose Linux AI servers to remote code execution when operators enable its profiling mode, a tool for measuring performance.

Bruce66423 shares a report from The Telegraph: British police forces, including specialist units within the Metropolitan Police, have used Oxygen Forensics software to break into the phones of suspects during live investigations, public documents show. The Virginia-based company behind the software has been accused in the US of having hidden its Russian ownership to avoid sanctions, before it was awarded government contracts. Its American chief executive and a Russian national were arrested last week after a US investigation found the company had sought to hide its ownership in an alleged attempt to avoid sanctions and scrutiny. [...] By September 2024, the US Secret Service had awarded Oxygen a five-year contract for its software. In December 2022, and in October 2023, Oxygen's chief executive told the US government that Oxygen Forensics had "no immediate or highest-level owner." By September 2024, the US Secret Service had awarded Oxygen a five-year contract for its software. In March, Mr Reiber allegedly told the US government that there had been no Russians involved in developing the software and that no one in Russia had access to the environment in which it was built. US prosecutors say this was false. If convicted, both Mr Reiber and Mr Davydov could face a sentence of 20 years in prison.

Read more of this story at Slashdot.

ModSecurity has released fixes for a group of web application firewall (WAF) weaknesses that can let dangerous input reach Linux-hosted applications without being inspected as intended.

Cloudflare has launched two open-weight decision models, Clef and Clef-flash, designed for structured yes/no, multiple-choice, and ranking tasks while also supporting images, video, and up to a 64K context window. Cloudflare says its models outperform TypeSafe's Jev on several benchmarks and can run locally from Hugging Face. The Register reports: For starters, Clef has an LLM backbone. According to Cloudflare, Clef uses specially post-trained, frozen versions of Qwen3.8-27B and Qwen3.5-9B for Clef and Clef-flash, respectively, with the Qwen backbone performing a prefill-only pass during inference. Clef is still fast - faster than Jev, to be fair - and scores choices in parallel after that prefill-only pass. It's not clear what Jev's underlying architecture is, as TypeSafe has kept that a secret. As for its speed and capability, Clef moves fast. Cloudflare ran it against Jev and some other open decision models using the Jev Decision Index available on Hugging Face, and the company's own ranking suggests Clef is slightly slower than other open models, but more accurate, with Clef-flash just as accurate as most of the others, but far faster. To be fair to the competition, Cloudflare self-reported its own scores against the benchmark, and they have yet to be reproduced for ranking on the official Decision Index. Cloudflare also ran Clef against TypeSafe's own benchmarks, and claimed it beat Jev in three out of four areas, only losing out on agent trace observability. Even if it were a bit slower or less accurate, Clef has another major leg up on Jev: It's not limited to classifying text -- it can also handle images and video. Additionally, Clef supports a 64k context window. Jev can also handle up to 64k tokens across a request, although its state plus longest individual question is limited to 32k.

Read more of this story at Slashdot.

Ryan Roslansky is leaving Microsoft and LinkedIn after nearly 18 years, triggering another leadership shuffle across Office and Teams. "Roslansky, who until recently was the CEO of LinkedIn, was promoted to the head of Office last year and then took control of Microsoft Teams earlier this year," notes The Verge. From the report: "Ryan leaves the organization in a strong position," says Microsoft CEO Satya Nadella in an internal memo. "Over the past year, Ryan's team has done critical work bringing together the product, engineering, and design foundations that have made this next phase possible." Roslansky is leaving a week after Microsoft announced its new Copilot, which the company is positioning as "the OS for work." He's also leaving around a month after calling fully AI-generated documents "a doom loop" for workers. "If we're not careful, we'll end up with a very expensive way to avoid writing and reading in an ocean of sameness, genericness," said Roslansky in his LinkedIn post. Microsoft is now moving the teams behind Office and Microsoft Teams over to Charles Lamanna, as part of the Copilot, Agents, and Platform (CAP) organization. [...] Microsoft's chief design officer, Jon Friedman, is also moving to report to Copilot chief Jacob Andreou. Microsoft appointed Dan Shapero as its LinkedIn CEO earlier this year, and he will continue in this role and report directly to Nadella.

Read more of this story at Slashdot.

Micron says the global RAM and storage shortage will tighten further through 2027 and 2028, with CEO Sanjay Mehrotra saying the company has already sold most of next year's capacity. "In calendar 2027 as well as 2028, we see demand exceeding supply. In fact, we see greater tightness in the industry in 2027 and in 2028 versus 2026. Overall, supply-demand environment is only getting tighter," Mehrotra said. "We do not have line of sight to when supply and demand will return to balance." As a result, the company is forecasting record revenue and an 86.25% gross margin. Tom's Hardware reports: The memory and storage industry is not holding back on increasing production, though, with Micron saying that NAND and DRAM shipments are expected to grow in the low-to-mid 20s percentage range for the next two years. However, it seems that this is not enough to match growing demand, as it expects "the industry to remain supply constrained in both years." Still, it seems that manufacturers are prioritizing HBM demand for AI data centers, with the company expecting shipments of these chips to grow faster than conventional DRAM. Micron and other chip manufacturers are bringing new factories online to increase output, but it's going to take years before they can start producing chips. But even as we're amid an unprecedented multi-year memory chip shortage, Micron also announced record financial guidance. It forecasted a record $61.5 billion FQ1 revenue and a gross margin of 86.25%, implying a gross profit of more than $53 billion. After accounting for an estimated $2.06 billion in operating expenses and a tax rate of around 15.5%, the company said its earnings per share sit at $38.15, plus or minus $1.00, for approximately 1.15 billion shares.

Read more of this story at Slashdot.

An anonymous reader quotes a report from 404 Media: A company that makes phone hacking devices claims to have developed a solution that freezes iPhones in a state that lets cops more easily access sensitive data inside them, according to a video obtained by 404 Media. [...] The new technology to get around inactivity reboot was developed by Magnet Forensics, the company behind GrayKey, a popular tool sold to law enforcement agencies that allows them to unlock and access data stored in iPhones and Android smartphones. Magnet has developed a new device called GrayKey Preserve and a feature for its regular GrayKey devices called Evidence Preservation Mode, according to the video. "This is an absolute game changer for iOS forensics and a function that I wish we had years ago," a Magnet employee says in the leaked video, specifically mentioning that the solution is targeted at the iPhone's inactivity reboot feature and the data it makes unavailable. GrayKey Preserve and Evidence Preservation Mode are also designed to combat another iPhone feature that automatically deletes certain data -- such as cached locations, and recently deleted photos and iMessages -- after a certain number of days. "We're gonna be able to preserve that data for an infinite amount of time." [...] 404 Media shared a transcript of the video with Jiska Classen, a researcher at the Hasso Plattner Institute who studies iPhone security. While Classen said that it's impossible to know for sure how Magnet's new feature works based on the video, she posited some theories and agreed that it is "quite a game changer" or "at least puts things back to where they were before inactivity reboot." She thinks Magnet has found a way to manipulate the iPhone's clock, effectively "slowing down time" or even "stopping the clock from ticking, even after a reboot." Most likely, according to her, the GrayKey may disable the iPhone tasks that set data to expire. The "inactivity reboot" feature mentioned above was added to iOS in November 2024 and automatically restarts iPhones that have not been unlocked for 72 hours, making them harder for police to access using forensic tools.

Read more of this story at Slashdot.

Longtime Slashdot reader ThurstonMoore shares a report from Reuters: U.S. Defense Secretary Pete Hegseth on Wednesday announced the creation of a new military command that would be dedicated to building and providing autonomous and robotic capabilities across the U.S. military. The command, which Hegseth said would be called "Autonomous Warfare Command," highlights the rapidly changing nature of warfare and the need to make progress on systems like drones and the use of artificial intelligence. Speaking in front of hundreds of junior officers and enlisted personnel at Quantico, Virginia, in a speech peppered with attacks on the media, Hegseth said the command would be led by a four-star officer. "The pace of war is changing faster than the process to support it," Hegseth said in a speech called the "State of the Force," in which he announced other changes, including the creation of the office of religious affairs. "Cheap compute, superintelligence, and advanced commercial manufacturing have enabled the proliferation of low-cost, high-precision strike," Hegseth added. [...] The United States has long relied on its vast military budget to field some of the world's most expensive weapons systems. But there is an increasing realization within the Pentagon that this is not sustainable. "Today we need both quality and quantity," Hegseth said.

Read more of this story at Slashdot.

The Federal Trade Commission has opened an investigation into OpenAI, Anthropic and other AI companies over potential consumer and safety risks posed by their products, with the agency reportedly preparing requests for documents and executive testimony. CNBC reports: OpenAI stunned the industry in July when it disclosed that its agents broke out of a testing environment and hacked into open-source platform Hugging Face. [...] Earlier this month, Anthropic CEO Dario Amodei rocked the tech sector by urging AI companies to slow how quickly they improve their most advanced models and calling for stronger government oversight. He published a three-step proposal aimed at tempering the pace of development without "sacrificing commercial advantage or the United States' lead in AI." CEO Jensen Huang, argued that individual companies should be responsible for ensuring the safety of their products. President Donald Trump convened top executives from Alphabet, Meta, SpaceX, Nvidia, Palantir, Anthropic, OpenAI and other companies on Tuesday to discuss the issue. The group signed a short voluntary, nonbinding accord, which says that "every company is responsible for developing its own technology safely and in a way that builds trust with customers and the public."

Read more of this story at Slashdot.

Version:next-20261001 (linux-next) Released:2026-10-01

HP is taking aim at Apple's MacBook Neo with the new OmniBook 5 14, a $699.99 Windows laptop that starts with an Intel Core 5 315 processor, 8GB of RAM and 256GB of storage but includes an OLED display even on the base model. It's also slightly thinner and lighter than the Neo. The Verge reports: The OmniBook 5 14 can be configured much higher, with up to a Core 7 350 chip, 16GB of RAM, and a 1TB SSD, but all models include a 1080p webcam, dual speakers, HDMI, 3.5mm audio jack, and just two 10Gbps USB-C ports. And while the inclusion of OLED across the range is a major draw to the new OmniBook, the base config only has a passable 1920 x 1200 resolution and 300 nits of max brightness on its non-touch panel. A touchscreen version will be available when the OmniBook 5 launches in October, but a version with a 2560 x 1600 resolution OLED and 400 nits of brightness isn't coming until March 2027. While the OmniBook 5 14 doesn't seem poised to best the MacBook Neo in raw processing power (based on our other reviews of Wildcat Lake laptops) or screen brightness, it's quite thin, light, and colorful. HP even gave it the nicer, sleeker lid logo usually reserved for pricier models. It starts at just 2.56 pounds, and it's as thin as 0.46 inches / 11.7mm. That's slightly lighter and thinner than a Neo. And I'd expect its Wildcat Lake chips to offer some good-to-great battery life. But we'll have to see how it delivers in actual testing. HP also announced a new ProBook 4 G2iS that is the company's "thinnest business notebook," measuring in at 0.47 inches / 12mm. It'll launch in December with Intel Wildcat Lake chips, 8GB of RAM, and a 256GB SSD, though pricing hasn't been announced.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Ars Technica: For a long time, PC gamers could access many PlayStation 5 games only if the publisher invested in a bespoke port (something Sony has recently said it will be scaling back). Now, though, rapid advancements in PS5 emulators and other tools are making recent PlayStation titles increasingly playable on generic PCs. SharpEmu was the first of these emulators, advancing from a "very early alpha stage" in May to a current state that can "load the eboot.bin of real games, execute native CPU instructions, and partially handle GPU-related functionality." The most recent release boasts 10 tested games that reach a "playable" state, including six that developer CursedIfElse says are "fully playable at 60 fps." That includes simple 2D games like Tetris Forever but also 3D titles like Astro Bot and the PS5 Demon's Souls remaster running at playable frame rates. [...] Amid that SharpEmu progress, fellow PS5 emulator KytyPS5 launched its first public version last week. The major expansion of PS4-focused emulator Kyty "can boot 2D games and a selection of 3D games, including titles built with Unreal Engine 4/5, Unity, and custom engines," according to its GitHub page. An extensive compatibility list for KytyPS5 already shows 134 titles with "controllable gameplay" on the new emulator, though many of those still include reports of persistent, game-breaking bugs. But you can already find YouTube footage of PS5 titles like Astro's Playroom and Demon's Souls running quite capably under the emulator. On top of those more traditional emulators, AnyPS5 might be the most interesting effort to get PS5 games running on PC. The self-described "tool for automatic executables porting" works kind of like Apple's Game Porting Toolkit, relinking a PS5 game's original x86 game code directly to native executable instructions that can run on PC. That puts the effort somewhere between direct static decompilation of a game's source code and more complete emulation of the entire PS5 environment.

Read more of this story at Slashdot.