Agreguesi i feed

This week OpenAI launched a version of ChatGPT exclusively designed for teenagers between the ages of 13 and 17, reports CTV, "saying this version came with stronger protections around content related to mentions of suicide, self-harm and romantic or sexual chats." [Tech analyst Carmi Levy says] "What it's doing is it's using cues, it's sort of watching how you're using the tool, and it's trying to guess your age." Levy said if ChatGPT thinks a person has lied about their age when they first signed up, it will automatically put them into the Teens mode for protection. "It includes those sort of two things: prevent you from having experiences that are age inappropriate, and also add features that are aligned with academics, so that makes it easier to study, makes it less likely for you to cheat on an assignment, provide resources that that that allow you to learn more effectively," he said. Levy reminded users that this is still an application and a web service, which means it's constantly collecting personal information about the users' activities on the device and using the data to estimate their age... In the event a user is talking about self-harm, this new version will block the conversation and suggest additional help or call emergency or mental health services, Levy explained. It would do the same with violent content, eating disorders, engaging in dangerous activities, as well as explicit, sexual or graphic content. "It's using AI again to sort of parse out that conversation: 'are we headed in a in a significant direction? If so, throw up that guardrail, stop it from happening, redirect.'" However, the tech analyst said a number of people who have attempted to bypass the guiderails for research have succeeded in doing so "with a little bit of prompting.... I wouldn't call it 100% safe. That's kind of the catch-22 of the entire AI industry." This will lead parents to think that their children are safer and reduce the oversight on their online activities, which Levy described as a "perverse impact" that is "problematic." "Parents should not assume that OpenAI has their kids' best interests at heart. They should also not assume that these technologies are perfect. They will miss certain things, and they will also engage in what we call false positives," he said. "An adult who's legitimately is in the platform might be tagged as a child because the AI simply got it wrong." OpenAI's blog post says the new mode was designed for "preserving the ability to learn, create, and explore." But CNN notes the move "comes as OpenAI faces a string of lawsuits alleging that inappropriate conversations with ChatGPT contributed to the harm or deaths of young people." [New tools] include nudges for teen users to take a break if they've been active for 90 minutes within a three-hour window. OpenAI is also adding options for teens or parents to set "Quiet Hours" when ChatGPT is unavailable or "Study Hours" where ChatGPT's study mode for learning will be on by default. The company also said it has improved protections to prevent ChatGPT from expressing personal feelings toward a user. And it's adding reminders that caution teens to think twice if they try to upload a private or sensitive image to the chatbot... Nearly a third of American teens use AI chatbots daily, a Pew Research Center study published in December found. ChatGPT was by far the most popular AI chatbot in the survey, with more than half of those teens reporting having used it. Engadget shared this observation from Josh Golin, the executive director of Fairplay, a non-profit advocating for policies to make the internet safer for children. "Most parents, overwhelmingly, do not avail themselves of [parental oversight] tools, in part because they are deliberately made hard to find and use." Golin's group wanted to see testing of the tools first to see whether they led to better outcomes for teenagers. "The way this was just announced feels more like a response aimed at public relations than actual deep thinking about what kind of support [teens] need." And Mashable got a similar quote from Robbie Torney, head of AI/digital assessments for Common Sense Media's Youth AI Safety Institute. OpenAI's teen experience makes important safety commitments, but "What we really need now is evidence that they work, and we need this evidence, including our testing and the testing of others, before anyone, including parents, puts real trust in ChatGPT for Teens." Importantly, Torney said parents shouldn't assume their child is using ChatGPT for Teens. While OpenAI uses age estimation to place users in the age-appropriate version of ChatGPT, it can still mistake a user as older. Parents can be sure their child is using the teen version by linking their ChatGPT account to their child's and implementing OpenAI's parental control features. If a teen has previously lied about their age — and plenty do — they may continue to access the adult version of ChatGPT... Torney said caregivers must enact parental controls to receive notifications from OpenAI should their teen discuss suicide, self-harm, or acts of violence in immediate or dangerous ways... An OpenAI spokesperson said every notification is reviewed by a trained human before it's sent. The company strives to review notifications in under one hour.

Read more of this story at Slashdot.

In recent weeks, I’ve been working on adding key rotation support to flatpak, so that repositories which sign their commits and summary files with a key with an expiry date have a way to push updates to that key to all the clients which use them. Currently that’s not possible without each client manually having its config updated to use the new key data (even if the change in key data is just to bump the expiry date).

In the process I’ve learned a few more things about GPG keys, subkeys, signatures, UIDs, etc., which I thought I might dump here in case it’s useful for someone else (or me, in the future). I don’t claim to be an expert, so I may still be misunderstanding some bits. GPG is complex. One thing which has helped ground things is finding the documentation in RFC 4880 (and related) which defines the GPG packet format.

One thing which keeps flatpak’s use of GPG simple is that it doesn’t use any of the web-of-trust features or trust-on-first-use (TOFU). Its use of GPG is limited to the keyring format (essentially pubring.gpg), for storing and publishing public and private keys, subkeys, signatures, revocations, UIDs; and using them to sign and verify OSTree commits and various repository files (summary, summary.idx, etc.).

Quick primer on the parts of GPG

GPG has keyrings: collections of primary keys. A primary key has public and private/secret parts. The way flatpak uses it, the secret part of a key always stays on the server, and is used to generate signatures. The public part is published by the server and configured in every client using that repository, used to verify the commit signatures. Each client has one keyring per remote it has configured. Typically this contains one primary key, but it could contain several, any of which can be used to verify signatures from that remote.

A key is identified using a fingerprint, a 40-character hex string. It can also be identified using a key ID, which is a substring of the fingerprint. There’s also keygrips, but let’s ignore those.

You can see fingerprints for keys using gpg --list-keys --fingerprint.

A primary key has one or more subkeys (at least in flatpak’s usage). All of these keys have public and private/secret parts as above. Each key has a usage which indicates what GPG will let you use it for, such as certifying, signing, authenticating, encrypting. The primary key is typically used to certify its subkeys by creating cross-certification signatures which bind them to the primary key, forming a short chain of trust — anyone who trusts the primary key should trust a subkey which it cross-certifies.

You can see subkeys as the sub lines using gpg --list-keys --with-subkey-fingerprint. The [SCE], [S], [E] (etc.) fields show the usage flags for a key.

The other usage we care about is signing (flatpak doesn’t use authentication or encryption usages). GPG separates keys by usage to prevent attacks where a key is used for a purpose it’s not intended for, and because keys used for different purposes often need to be treated with different levels of care.

In particular, separating by usage means the private/secret part of the primary key can be kept completely offline, and only brought out in a special key signing ceremony when a new subkey needs to be generated and cross-certified. This reduces the risk of the very valuable primary key, which is the root of every client’s trust in the repository, being leaked.

So, we use a signing subkey for day-to-day signing of OSTree commits. For a big flatpak repository, the private/secret part of this subkey might be kept in a hardware security module, so it can’t be exfiltrated from the server if the server were compromised. But there’s still the risk of a compromised server being used to sign things it shouldn’t (such as malicious apps).

That’s a matter for server security, but we can somewhat mitigate against the possibility of the signing subkey being leaked by setting an expiration date on it. Clients might choose not to trust signatures made by it after that date; and gpg certainly wouldn’t allow it to be used to create new signatures.

The expiry date of a key is shown as an expires field in the gpg --list-keys --with-subkey-fingerprint output.

What happens when the subkey expires? By that point, the administrators should have generated another subkey, cross-certified by the primary key in a key signing ceremony (I assume the ceremony involves cake). The private/secret part of the new subkey needs to stay secret, as before; but the public part needs to be distributed to every client’s keyring, along with the new cross-certification signature from the primary key, so the clients know they can trust signatures made by that subkey.

That’s the bit which flatpak is currently lacking.

So in summary: GPG has keyrings. Keyrings have primary keys. Primary keys have one or more subkeys and cross-certification signatures from the primary key on those subkeys. Each subkey has a usage, but flatpak only uses certify (for the primary key) and sign (for the subkeys). Keys can have expiration dates.

And if you want to see the full contents of a keyring, run gpg --list-keys --with-colons. It’ll output everything (no filtering) in a machine readable format described here (best reference I’ve been able to find), which is sometimes easier to use than remembering which --with-blah option to pass to GPG to get it to show the information you want.

What else does GPG have?

Quite a few things. We’ll ignore the big things which are not relevant to flatpak.

Each primary key also has one or more UIDs. These are like subkeys in that they are cross-certified by the primary key. Each UID is a user identity — typically a name and email address. If you were using GPG in a web of trust, the binding between the primary key and a UID is what you sign that you trust when you sign someone’s key in a key signing party.

The UIDs are listed below each primary key in gpg --list-keys.

Flatpak doesn’t need UIDs, but they are an unavoidable part of GPG — each primary key must have at least one. A flatpak repository will typically put a server contact email address in the UID and then everyone will ignore it.

UIDs can be revoked; for example if someone loses control of the email address in it and wants their friends to no longer trust emails from it. Flatpak currently doesn’t use this.

What else can be revoked? The cross-certification signatures! You may have heard of a GPG revocation certificate. This is a way of revoking an entire primary key. But there’s also a way of revoking a particular cross-certification signature, meaning that the primary key is still valid/trusted, but the owner of the primary key has lost control of one of the subkeys, and that subkey should no longer be trusted. This is different from key expiration, as it’s a statement that something has explicitly gone wrong.

Because of how GPG is built up as a series of packets of different types, a signature revocation is actually a revocation packet appended to the primary key. This means you can re-cross-certify a subkey after revoking it, by appending another cross-certification packet. And even revoke it again after that. Not sure if there’s a use case for this or if it’s just a consequence of the packet format, but this behaviour does play havoc with working out whether to trust a subkey.

Cross-certification signatures can also have an expiration date built into them, separate from the expiration date of the subkey. I’m not sure of the use case for this either, but there must be one.

Some notes on running GPG on the command line

GPG is historically famously hard to use. I feel this has got better in recent years, particularly for scripting it. In particular it’s added a whole load of --quick-blah commands to generate keys, set expiries, etc. from scripts.

One thing which repeatedly tripped me up before I stopped trying to fight it was its concept of a ’homedir’. GPG needs to look for its keyring (and trust database, and various other files) somewhere, and will not run without them, so you always need to pass it a ‘homedir’ to look for them in. By default, this will be ~/.gnupg, so it’s very easy to accidentally end up operating on your personal GPG keyring when you’re trying to do something in a project.

If using GPG as a tool or in a script, I think you should always create a temporary homedir, pass it as gpg --homedir=/path/to/temp and explicitly import whatever keys or context you need into this homedir before doing whatever operation you need.

This is necessary even if ‘all’ you want to do is view a downloaded .gpg keyring, because what GPG displays may be affected by the trust database in its homedir. So to view a downloaded keyring you should still do something like mkdir temp; gpg --homedir=./temp ./path/to/download.gpg.

If you are trying to sign something, you will typically pass the fingerprint or key ID of a primary key to GPG; for example as gpg --local-user 0xfingerprint --sign ./path/to/file. GPG will helpfully use the usage flags of the subkey of that primary key to choose which subkey to sign with. If you want to sign with a specific subkey, you need to suffix the fingerprint with an exclamation mark (!) otherwise GPG will still choose what it thinks is the most appropriate subkey, which might not align with the subkey you carefully chose. This ! suffix format is common throughout the GPG command line interface for when you want to specify a specific subkey.

Sorry

That was more of a braindump than I imagined when I set out to write this. I hope some of it is useful; feedback welcome if I’ve got anything wrong. If any GPG experts fancy reviewing key rotation support in flatpak, the draft implementation is here.

"Iran shut down a British power plant for four days in an unprecedented cyber attack," reports the Telegraph. More details from the BBC: The government said that at no point was there a risk to the UK's energy system, but the Department for Energy Security and Net Zero (DESNZ) has contacted power companies to advise them about the risk of cyber attacks... DESNZ said the incident had affected a small-scale generator and at no point had there been a risk to the wider energy system. The UK's power network has a number of smaller gas generators which provide short-term power when needed. Thanks to Alain Williams (Slashdot reader #2,972) for sharing the news.

Read more of this story at Slashdot.

Slovakia acquired speed cameras to modernize its traffic control-- but there was a surprise. Tom's Hardware cites this story from the Risky Bulletin Newsletter: Unfortunately, the country's national security service, the NBU, has discovered that the cameras have multiple security issues. Firstly, they have SMS-activated Russian backdoors. Secondly, live camera feeds can be accessed by anyone with the device IP, no password necessary... [The cameras] are thought to be rebranded Russian CORDON PRO.M traffic cameras, produced by a St. Petersburg-based firm called Semicon... reportedly bought via a Cyprus-based shell company with fake certifications. Reports also suggest that pressure from the opposition political party in Slovakia led to the NBU investigations... Probably most seriously, in terms of national security, these cameras contain a hardcoded list of Russian phone numbers, which can be used to open a backdoor. An SMS from one of these numbers can open shell and network access... [T]he SecureBoot feature is ineffective, and the web management portal can be accessed, exposing live streams, by anyone with the camera IP. Cameras that have been installed and set up have since been deactivated by the Slovak Ministry of the Interior. Meanwhile, for due diligence, an independent auditor will be called in to confirm the NBU's findings. It is thought that Croatia, and some other countries in Eastern Europe, may have undiscovered issues with traffic control cameras of similar origin.

Read more of this story at Slashdot.

"There is still no sign of economy-wide job destruction," says economist Erik Brynjolfsson. Working with researchers at the Stanford Digital Economy Lab, Brynjolfsson has determined an AI "job apocalypse" is unlikely, reports the Washington Post, "even though it will likely impact entry-level jobs." And Brynjolfsson "predicts that demand for experienced workers such as senior coders will still be high even if AI takes on more routine knowledge and coding work in the future." Earlier this month, Brynjolfsson and his colleagues at the Stanford Digital Economy Lab updated their widely publicized report, "Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence," to reflect that they do not see widespread, economy-wide job displacement associated with AI... Brynjolfsson: What has moved on the upside is productivity. Nonfarm business productivity growth is running over 2 percent, the best sustained stretch since the late-1990s boom... The gains show up years after the investment, and they're starting to show up... By 2030, we will have enormously more capable AI, meaningfully faster productivity growth and an unemployment rate that looks unremarkable — somewhere in its historical range. That surprises people, but it's what the mechanism implies... [T]he technology is becoming much more powerful, and it's going to be even more powerful. Secondly, there are huge implications for business and the economy, including some increases in living standards, but also, potentially, job disruption. And then, thirdly, we must act now to address this gap. We can't just sit back and wait for the tsunami to hit us. And one of the things we can do is put in place institutions, policies and research to make the technology more complementary — using AI to complement people so it creates more jobs. A common misconception among business managers is AI, in order to be effective, has to reduce jobs. That's just not true. You can use AI to increase employment and productivity at the same time. It's kind of a win-win... Right now, tax policy is very skewed toward favoring capital versus labor — and, as a consequence, a lot of entrepreneurs and managers, they're basically being guided by the federal government to replace workers with machines. And I don't think that's necessarily what we'd like to have happen. From an economist's perspective, what you want to be doing is not mimicking and replacing things. You want to be extending and complementing — have humans do new things they never could have done before. He acknowledges "real, persistent and widening" effects on entry-level jobs, with a labor market "closing the on-ramp for people starting their careers... If companies don't hire people at the base of the pyramid, then they're not going to have those people later when they need them." One he points out that one company is instead using AI to speed up its training of young employees.

Read more of this story at Slashdot.

"It began life just a year after SimCity 4's 2003 launch," writes the blog PCGamesN. "Now, over 20 years later, it's still going strong with the arrival of Network Addon Mod update 50." The SimCity 4 Network Addon Mod, or simply 'NAM' among the community, has long been a de facto recommendation to anyone looking to pick up the classic city builder. It's a comprehensive overhaul to the game's transportation and infrastructure networks that combines key fixes with a vast set of additional build pieces such as overpasses, intersections, on-ramps, roundabouts, and so on.... [Y]ou'll be able to place down elements adjacent to one another that might previously have needed a one-tile gap between them. Streets can be dragged diagonally, slope tolerances have been improved, and you can build tunnels with the street network. The new version also includes a fix for the 'Eternal Commuter Loop' bug, which might sound fairly innocuous if you're not deep in the weeds. In actuality, it's a 23-year-long frustration that has plagued modders ever since launch. Essentially, it's a problem with the regional pathfinding across city boundaries in certain layouts, causing your Sims to bounce from location to location in search of work without actually taking up a job in any of them. Your zone demand is ruined, traffic builds to unsustainable levels, and the economy falls to pieces before your very eyes. Until now, the only real solution was to simply avoid building layouts that gave your commuters the chance to loop between locations. Now, by blocking specific neighbor-to-neighbor routes while allowing the rest to run as normal, the problem has been resolved... Equally impressively, the mandatory implementation of the DLL has reduced the size of the NAM codebase "by almost 90% and by more than ten million lines, making it easier to maintain and reducing the chance of bugs." Thanks to long-time Slashdot reader Striek for sharing the news.

Read more of this story at Slashdot.

An anonymous reader shared this report from the blog It's FOSS: Canonical has committed funding to a three-year PhD project focused on building a system that can automatically translate large C codebases into Rust. And they are not alone; UK Research and Innovation is matching their funding for the project, which is set to run through the University of Bristol's Programming Languages Research Group. The PhD is aiming to build an all-encompassing platform that can take a C repository running into hundreds of thousands of lines and translate it into Rust that's "safe, behaviourally correct and maintainable Rust." The work will be carried out by a student, Alex Wood, who will be supported by Professor Meng Wang leading the work, with Dr. Cristina David and Canonical's Jon Seager serving as co-supervisors.

Read more of this story at Slashdot.

Version:7.1.10 (stable) Released:2026-08-23 Source:linux-7.1.10.tar.xz PGP Signature:linux-7.1.10.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-7.1.10

Version:6.18.46 (longterm) Released:2026-08-23 Source:linux-6.18.46.tar.xz PGP Signature:linux-6.18.46.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.18.46

Version:6.12.105 (longterm) Released:2026-08-23 Source:linux-6.12.105.tar.xz PGP Signature:linux-6.12.105.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.12.105

Version:6.6.153 (longterm) Released:2026-08-23 Source:linux-6.6.153.tar.xz PGP Signature:linux-6.6.153.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.6.153

Version:6.1.184 (longterm) Released:2026-08-23 Source:linux-6.1.184.tar.xz PGP Signature:linux-6.1.184.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.1.184

Version:5.15.217 (longterm) Released:2026-08-23 Source:linux-5.15.217.tar.xz PGP Signature:linux-5.15.217.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-5.15.217

Version:5.10.266 (longterm) Released:2026-08-23 Source:linux-5.10.266.tar.xz PGP Signature:linux-5.10.266.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-5.10.266

Falling prices have made grid-scale storage batteries more attractive, reports Bloomberg. But after decades of stagnant investment, America's grids "are racing to make the upgrades needed to plug them in," with supplies straining for the necessary equipment. Demand for batteries has skyrocketed as electricity use across the U.S. swells, driven by data centers' booming energy needs and increasing electrification. It's also getting harder to get them connected to power grids... As those upgrades get delayed, storage projects are piling up in interconnection queues from coast to coast. For example, Consolidated Edison Inc., a major utility in New York state, says over the last two years the volume of battery storage projects waiting to be connected has grown by 300%... "The whole process of interconnecting these new power plants got really log-jammed and bottlenecked," said Joseph Rand, an energy policy researcher at the Lawrence Berkeley National Laboratory... Nationwide, some 750 gigawatts of energy storage projects — roughly equivalent to the generating capacity of more than 700 nuclear reactors — are in line to get grid connections, according to the lab's research. Not all of these projects will get built. Many developers already abandoned the queue because of delays. Still, the waiting time is increasing; the median was five years in 2025, up from a year and a half in 2015. The flood of battery projects is expected to continue. Wood Mackenzie, an energy consultancy, projects the U.S. energy storage market will quadruple in the next six years... [Shortages in key equipment] have driven up construction costs and time lines for grid upgrades, leaving utilities struggling to build fast enough. A drought of skilled workers is further slowing them down... In California, PG&E Corp., the state's largest utility, told regulators in January that a key driver of delays was long lead times for specialized equipment. Procuring certain breakers could take nearly four years, according to the utility, which reported a 300% increase in its interconnection workload compared to prior years. In Northern California, for example, holdups to circuit breaker upgrades to a substation in Solano County led to projected delays for two battery projects worth a combined 450 megawatts. Transmission line work in the Bay Area has put another 800 megawatts of energy storage at risk of delay, according to PG&E. Last year New York's Con Ed started requiring developers to help pay for upgrades if their projects will push power demand and strain infrastructure. But that also drew criticism: According to a survey conducted by the trade group New York Battery and Energy Storage Technology Consortium (NY-BEST), the new methodology raised costs by an average of $21 million per project, a 14-fold increase. At least 25 projects have been canceled as a result, according to the group. Battery advocates have appealed to state regulators to get Con Ed to abandon the new policy. Thanks to Slashdot reader Bruce66423 for sharing the news.

Read more of this story at Slashdot.

Debian developers are voting on whether to ban AI-assisted contributions, reports the blog Linuxiac, with a ballot listing eight proposals and a "None of the above" option. The first one is still the original proposal to ban LLM-assisted contributions by changing the Debian Social Contract. This would stop generative AI from being used for direct Debian work like packaging, software, documentation, translations, websites, and project communication. However, upstream projects made with AI help would not be affected. The proposal gives several reasons for the ban, such as unclear copyright and licensing, doubts about the reliability of AI-generated work, extra review work for maintainers, aggressive scraping of Free Software resources, and the high resource use of large AI systems... The second option would clearly allow contributions that are partly or fully made by an LLM, as long as contributors check their technical quality, security, licensing, and usefulness, fully understand the changes, and disclose major AI help. It would also ban sending private or sensitive Debian information to untrusted external AI services. A similar fourth option recognizes worries about generative AI but says banning it would be hard to enforce and not helpful. This proposal would accept AI-assisted Debian work if it follows the Debian Free Software Guidelines, is properly reviewed and understood by the contributor, and is marked as AI-assisted when needed. The fifth proposal is even more open. It says Debian should not support or ban generative AI tools, but should apply the same standards for quality, correctness, maintainability, and legality to all contributions, no matter how they were made... One unique proposal is called "Debian is created by humans." Instead of banning AI tools for contributors, it focuses on what actually gets included in Debian. With this approach, contributors could use generative AI for research, analysis, exploration, or critique, but could not submit AI-generated output directly as Debian packaging, patches, documentation, bug reports, project communications, or other Debian work. As the proposal says: humans create Debian. Another, much stricter proposal asks Debian contributors to avoid LLM use as much as possible. It would require all Debian communication, like bug reports, mailing-list messages, Salsa discussions, and Planet Debian posts, to be written only by humans. Any AI use in Debian work would have to be disclosed, and violations could be handled under the project's Code of Conduct. The CEO/founder of AI-native compliance management platform company Strike Graph believes a Debian AI ban is "the wrong fix for the actual problem" at hand, reports The New Stack: "Debian's ban isn't really about banning AI," [CEO Justin] Beals says. "It's an admission that nobody has built a reliable way to verify what an AI agent actually produced before it lands in a codebase this many systems depend on, including infrastructure running in orbit. That's a legitimate thing to be worried about...." He thinks that any policy statement that says AI isn't allowed simply won't hold up, as the tooling keeps getting harder to detect... Looking across the complete set of tabled propositions, proposal A (no LLM contributions to Debian via social contract) needs a 3:1 majority to pass; the other seven proposals (B to H) need a simple majority.

Read more of this story at Slashdot.

Retraction Watch reports: A trial date has been set in a $1 billion defamation case against Elsevier that alleges the company published what plaintiffs say was a manipulated study about an air purifying technology over objections from peer reviewers. The case has already cost Elsevier a $10,000 sanction from a judge. Global Plasma Solutions (GPS), which makes air quality products, sued Elsevier in 2022 after the publisher declined to retract a 2021 paper in Building and Environment about GPS' needlepoint bipolar ionization technology, which it heavily marketed during the COVID-19 pandemic as an air purifier. The complaint claims Elsevier is responsible for the authors' alleged omission of data and misleading conclusions in the paper that fueled "massive" financial losses for the company, its lawyers claim. Elsevier knew the paper "failed peer review" under its "own standards," but moved forward with the article despite this knowledge, according to GPS, which now goes by GPS Air. The complaint has survived a bid by Elsevier to dismiss the case, and a trial has been set for Dec. 7. In allowing the case to proceed, U.S. Magistrate Judge David Keesler said in a May 2024 opinion that GPS has "plausibly alleged actual malice" by Elsevier defined as "knowledge of falsity or reckless disregard for the truth." Chief Judge Martin Reidinger of the U.S. District Court for the Western District of North Carolina upheld Keesler's recommendation in July 2025... Citing internal and discovery documents, GPS alleges an assessment of 19 journals revealed Elsevier has published more than 1,200 articles either without any peer review, or against the recommendations of the reviewers. Thanks to long-time Slashdot reader sandbagger for sharing the article.

Read more of this story at Slashdot.

Hello,

Here’s some thoughts on software for August.

Bear with me on these broad categories but I think you can group most software projects into one of these groups: art, infrastructure, and activism.

Art is primarily to communicate experiences and feelings to others. Making video games is art. Making digital musical and instruments and visual effects is art. The drawing you did as a child that’s stuck on somebody’s fridge is art. The 3rd year computing student’s university coursework, uploaded to Github without comment and abandoned forever… that’s art, or at least, it’s a sketchbook. The thorny entry to the IOCCC, the optimized inner loop deep in some graphics toolkit, that only a handful of people will ever look at, but all of them will agree: that’s art.

People make art for fun, learning and practice.

Infrastructure is stuff that is needed and expected for the world to function. The definition of infrastructure changes over time, as societies adopt and depend on new technologies. Roads, milk delivery, electricity, bakeries, aqueducts, supermarkets, the internet, trams, the lift in your apartment building, and so on. Many societies depend on software projects now. Web browsers, phone cells, operating systems, social networks, software developer tools, power grid management, Google Maps, and so on.

People make infrastructure for money, or perhaps out of a sense of duty.

Activism is a desire to bring about a particular social or political goal or change. I don’t know when the first activist software project started, but it was no later than the 1980s when the GNU project began its stated mission to make proprietary software unviable via copyleft, and many free software projects followed along. The design of the GNU C compiler was shaped by the mission. Tor began in the 2000s with the goal of ensuring private, uncensored internet access. Bitcoin began with the stated aim of destroying the financial system, the wake of the 2008 bank crisis. Although in many countries it’s now regulated financial infrastructure, which shows you that projects can move between these categories over time.

People spend our energy on activism based on our beliefs, usually a sense of wanting to make the world a better place for everyone, or at least for ourselves, and our friends and family.

Not everything fits into these categories (the biggest gap I can see is experiments and research) but let’s keep this short, I want to use them to look at the conversations I keep seeing in the open source world this year.

When one person sees a project as activism and another sees it as infrastructure, you see some genuinely confused conversations happening.

Codeberg banned projects with largely AI generated code from the site, and Sourcehut is considering doing the same. If you see these projects as Git hosting infrastructure similar to Gitlab and Github, then that decision makes very little sense. Why would they want to host fewer projects? However if you see the project as a group of activists trying to reduce the power and influence of US tech firms, and limit the harms of rapid of adoption of AI, then it makes a lot of sense.

Linux decided to allow some LLM use and not put too many limits, as long as its making the project better. If you see Linux as a bunch of engineers building infrastructure then it’s a very logical decision. But if you thought your contributions were part of some activist movement then that might be a disappointing decision.

Every so often I hear someone say things like “please keep politics out of software”. You can infer that they’re probably talking about infrastructure software — and it’s as misguided as if they said it about any other infrastructure. Is an aqueduct political? If one country is seen as stealing another country’s water then… yes. Can a shipping lane be political? Yes, see numerous examples, including the ongoing US-Iran conflict. Can a road be political? Yes, if it crosses a border, especially if it’s in dispute. Ask someone old from Berlin or the north of Ireland about whether roads can be political.

Maintaining software takes a lot of effort. If someone is putting in that effort without being paid, they have some other motivation for doing it. Humans rarely do difficult, laborious work for no reason. Our motivation might be to learn, to show off, to have fun, to meet people, to collaborate with friends, or it might be to work towards some kind of political or societal change. I’ve probably contributed to open source for all of these reasons at different times.

We are increasingly referring to open source software as “digital infrastructure” and funding some of the maintenance work via corporate money and public money. This is great, but it requires the project to frame itself as infrastructure rather than activism. You are unlikely to get funding from Microsoft if you openly state that your goal is to destroy Microsoft. You are unlikely to get funding from a government if your stated goal is to destroy the modern financial system or prevent all forms of censorship.

Activists using open source licenses have something of a problem to deal with. If your goal is to bring about world peace, you hardly want people building drones and missiles using the software you develop. Yet the open source movement have made it clear that if you try to limit who can use your software, it’s no longer open source. And, many software engineers have made it clear they don’t give a shit about software licensing anyway and they’ll use your code however they want without even reading the license.

You can control access to software infrastructure, of course, just like you can put soldiers and passport controls on a bridge or a road. But you can’t call it open source any more.

The GNOME desktop project is art, infrastructure and activism. The discussion on Reddit is mostly people who design and post desktops and themes for fun. Several corporations build products with GNOME, and treat it as infrastructure. And then there are contributors who want to bring about change, perhaps weakening the power of Big Tech by spreading an ethical alternative to Android and iOS.

GNOME hasn’t made a statement on AI use, and I don’t think we’ve tried very hard to discuss it so far. I wonder if we’re putting it off because we’d have to also discuss whether our goal is to maintain some infrastructure, or build something cool-looking, or bring about meaningful societal change?

Over the summer of 2026, I worked towards bringing the option of playing Vocab-Style puzzles to GNOME Crosswords as part of Google Summer of Code. This entailed adding support to the puzzle library, and writing the backend of the algorithm responsible for grid generation. Jonathan Blandford provides a thorough rundown on the ins and outs of Crosswords with these slides.

The first few weeks of the start of GSoC were spent by adding a drop-down calendar widget to Crosswords Editor, and storing GDate data as ISO8601. We decided to integrate this into my design despite it not being directly related to the proposed project because it still contributed to the Crosswords app.

For the new puzzle type, I started with adding support to the puzzle library, libipuz, which is responsible for formatting and representing puzzles styled as ‘paper-and-pencil’ crosswords. My primary mentor and I bounced ideas back and forth for some time before we started designing and writing the algorithm. We landed on an idea and I created an initial design document for the plan of action to follow for the summer. We decided that aiming for both the backend and frontend in one summer may be more work than we initially thought, so we concluded on focusing exclusively on getting a working algorithm to build from.

The bulk of this summer consisted of writing and reconfiguring the depth-first search backtracking algorithm.

 

GitLab Links to Code:

An overview of my GitLab profile can be found here.

• Implementation of New Vocab Puzzles
  • This is the bulk of the algorithm and unit tests. The user inputs a word, the word gets analyzed in a recursive function to check for crossings and constraints, we save the state of the board, backtrack if needed, and present a grid.
• Vocab Ipuz
  • Adding new class for IpuzVocab to support vocab puzzles in the puzzle library (libipuz).
• Check for Island Words
  • There may be a word in a list that may not share any intersection points with any others no matter how many backtracks are done. Consequently, this affects grid creation in a timely manner and may prevent grid generation at all by stating it false. We can compare the bitmask of words in the list before we even activate the algorithm to detect a word that would potentially conflict with the others.

• Date Validation
  • Previously, the Crosswords Editor had a free-for-all AdwEntryRow. However its purpose is to present a legible date to the user, and store the date in ISO8601 format. I used GDateTime, GDate, and a Gtk Calendar widget to add a drop-down calendar in the date box. The chosen date presented in Gregorian style to the user, and stored as ISO8601 to the backend.
• Added Dispose to Shapebg
  • Releases references to GObjects that Shapebg owns and frees Shapebg’s remaining memory.

 

Design Docs:

• Updated Design Doc
•  Vocab Design Doc

 

Blog Post Links (Most Recent -> Oldest):

• GSoC 2026 Final Report – Laureen Caliman
• Vocab-style Crosswords Update | Final Stretch
• Intern Experience at GUADEC
• Update on Crosswords Backtracking Algorithm
• Pick a Word, Any Word
• Extending Libipuz
• GSoC Project Start
• Introduction Post

 

I also gave a lightning talk at the 2026 GNOME Users and Developers European Conference here. Thank you to the GNOME Travel Committee for making that opportunity possible.

I still have some work to do for both Libipuz and Crosswords: finish the island-checking function detailed above, open a new MR to choose the most compact/square grid out of 500 options and present that to the user directly rather than them cherry-pick through a large selection,  create a new MR to add photos of the puzzle in libipuz using gi-docgen, convert the 500-generated grid code to a PuzzleTask, and incorporate the frontend to make this a fully-functioning part of the game.

I would like to thank my primary mentor, Jonathan Blandford, and my other mentor, Federico Mena Quintero, for their guidance, feedback, patience, and teaching. This program was exactly what I needed to become better at development and serves as my rock to open-source contributions. I learned a lot of valuable skills such as document reading, how much to push in a commit, how to slow down trying to get a lot done at once, but simultaneously how to speed up my progression on the parts that actually matter, code with brevity, and a whole lot of dealing with nasty version control!

I intend to continue contributing to GNOME Crosswords as well as the overall GNOME Foundation. I look forward to collaborating with more people involved in the Foundation!

 

A rapidly developing El Nino is already reaching record-setting levels for this time of year and is expected to intensify further over the coming months. "The El Nino has blossomed. It is off the charts. Usual measures of El Nino have blown past prior record levels in the period with good data, even though maximum effects are still several months in the future," writes renowned climate scientist James Hansen at Columbia University in New York in a newsletter sent today. Climate scientists disagree over whether it has already surpassed previous "super El Nino" events on every metric, but several say the signal is unprecedented in forecasts and could ultimately become the strongest modern event on record. New Scientist reports: There are different ways of measuring El Ninos, which occur when warm surface waters spread eastwards along the equator across the surface of the tropical Pacific Ocean. Hansen thinks the best measure is how much warmer than usual the upper 300 meters of the eastern tropical Pacific becomes. "Our preferred metric, the heat anomaly in the upper 300 meters of the Equatorial Pacific Ocean... already exceeds the 1997-98 super El Nino," he writes. [...] What's clear is that this developing super El Nino will soon exceed previous events on all measures. "I have never seen an El Nino signal this intense in our forecasts," [Adam Scaife at the Met Office, the UK's national weather service] said in a statement released today. "If the forecast is accurate... then 2026 will far exceed our recent experience of El Nino and its worldwide climate influences." While Hansen is comparing the developing super El Nino to other modern events for which we have direct temperature records, Hayley Fowler at Newcastle University in the UK thinks it could also exceed historical events suspected to be even larger. "The super El Nino evolving in the Pacific will likely be the biggest ever recorded, reaching or exceeding the levels of the 1877-1878 El Nino which caused widespread impacts, including famines and around 50 million deaths (3-4 percent of the global population at the time), mostly across Asia and South America," Fowler said in a statement.

Read more of this story at Slashdot.