Agreguesi i feed

An anonymous reader quotes a report from 404 Media: LinkedIn, a social network awash with long AI-generated posts from executives and other corporate workers, has introduced a new button that users can click to flag if a post "seems like AI slop," according to 404 Media's own tests. If you have been anywhere near LinkedIn in the past couple of years, you have undoubtedly seen users posting blatantly AI-generated missives. Often these posts take some sort of news event, and opine on how this relates to thought leadership, or some other LinkedIn brainrot term. It's also pretty wild the button specifically uses the term "AI slop" and not, say, "It seems this was generated with AI." [...] After publication of this piece, Hari Srinivasan, chief product officer at LinkedIn, wrote their own post about the button. "AI slop is a top priority for all of us. We really care about this. People come to LinkedIn to connect with real people and share their real perspectives, ideas and expertise. Here are a few more changes to keep it that way," he wrote. The button in part will help LinkedIn tune its own models for identifying AI slop. "We are ramping up a series of new and improved classifiers that identify if a post is AI-slop or generally low-quality content. This will reduce the amount of AI slop you might see in suggested content and content from outside your network," the post said. "We are ramping the ability for members to tell us if they believe a post or comment seems like AI slop. Slop is hard to define and the definition changes; this lets us tune our models and make better feeds." Srinivasan also said LinkedIn is removing the AI-powered "enhance your post" feature with another that "proofreads your words, but does not change your voice."

Read more of this story at Slashdot.

Linux administrators automate almost everything. Backups run on a schedule, logs rotate on their own, updates ship through pipelines, and health checks happen without anyone opening a terminal.

Your operating system forms the base layer of your production pipeline. Moving from a basic workstation layout to an enterprise environment takes deliberate work around security hardening, telemetry, and automated provisioning.

A production company and filmmaker are suing Netflix for $105 million, alleging the streamer lost a stolen drive containing an unencrypted master copy of the unreleased Nicolas Cage film Fortitude, which they claim damage its exclusivity and market value. Netflix denied responsibility for the lost film but said it takes content security seriously and has offered to monitor piracy sites for unauthorized copies. CBS News reports: The complaint filed on Wednesday in California district court alleges that the film's associate producer, Daniel Haido, hand-delivered an unencrypted master copy of the film to Netflix so the company could screen it as a potential buyer. Haido verbally instructed the employee to delete the files after the screening, according to the suit. A little over a week after the screening, Netflix emailed the filmmakers to say the drive had been stolen, the plaintiffs allege. "Someone stole a good amount of drives from our office desks this past week," a Netflix executive wrote in the email, according to the suit. The complaint notes the movie, entitled "Fortitude," took over seven years to make and cost $45 million. It tells the story of a secret mission called Operation Fortitude during World War II that was orchestrated to mislead the Nazis about the Allied invasion of Europe. The film stars Nicolas Cage as Dusko Popov, a real-life spy during World War II, as well as Sir Ben Kingsley and Ron Perlman. The plaintiffs said studios will now be dissuaded from buying the rights to the movie, knowing that a version of it could be released by a third party for free. "The film's value depended in significant part on its exclusivity as an unreleased, first-to-market work," the complaint states. "By losing control of the film, Netflix destroyed that exclusivity and materially, if not completely, impaired the film's marketability."

Read more of this story at Slashdot.

Anthropic found that Claude models breached three outside organizations during cybersecurity tests because misconfigured environments accidentally gave them access to the internet. The company notified those affected and urged other AI labs to audit their own testing systems. The BBC reports: Anthropic said in a statement that it reviewed more than 140,000 tests to find evidence that Claude - its family of AI models - could access the internet from testing environments that were designed to be sealed off. The tests include so-called "capture-the-flag" evaluations in which Claude was tasked with obtaining information by breaching other systems - a common way that experts assess a model's hacking capabilities. A "misconfiguration" on systems run by Anthropic and its testing partner left the models with live internet access, allowing them to breach other systems, the San Francisco-based firm said. Anthropic said the earliest incidents date back to April and that it is "approaching the fixes as if the responsibility were ours alone." Neither Anthropic nor the organizations that were breached had noticed the intrusions at the time. Anthropic said it could have reviewed its records more thoroughly and added that the findings gave the firm "cautious optimism" that such risks can be overcome with more investment and tighter measures. "The broader lesson is not necessarily that AI has developed a fundamentally new attack capability," cyber security expert David Allott told the BBC. "Instead, it is that AI agents can combine capabilities, obtain credentials and system access to take actions autonomously, while adapting scope and scale at machine speed," he added. The announcement comes just days after OpenAI said that its models had breached the systems of other companies, including AI tools platform Hugging Face.

Read more of this story at Slashdot.

An anonymous Slashdot reader writes: Surveillance cameras owned by Flock Safety have been cut down with electric saws in New York State, vandalized with paint in Oakland, California, and rammed with a truck in Idaho. Flock claims its services fight crime, but law enforcement agencies also use their services to track vehicles based on license plate numbers and reconstruct the their movements, even when the drivers and owners of these vehicles have never been accused or convicted of any crime. (Flock states it has 120,000 automated cameras that record license plate data, as well as pan-tilt-zoom cameras, across the United States.) A guerilla mindset among average citizens have seen these cameras forcibly disabled within recent weeks with sympathy directed toward the vigilantes. In June, a West Virginia man accused of destroying several Flock cameras was arrested. Under a Facebook post from the local NBC affiliate announcing his arrest are dozens of people volunteering to provide alibis. "He was out fishing with me that day, you got the wrong guy," one man wrote.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Ars Technica: This week, the Model Context Protocol (MCP), an open source standard for how AI systems interact with external tools and data sources, saw its largest update since its introduction. Most notably, MCP's protocol core is now stateless, so requests are no longer dependent on a session tied to an individual server instance. This change has the potential to address long-standing barriers to scalability. The blog post announcing the specification, written by lead maintainers David Soria Parra and Den Delimarsky (who both work at Anthropic), says: "The highlight of this release is a stateless protocol core -- MCP is transforming from a bidirectional stateful protocol into a request/response stateless protocol. It was one of the most highly-requested features from developers who were eager to get better reliability and scalability for their MCP servers." [...] There is also a new deprecation policy that ensures at least 12 months between when a feature's formal deprecation is enacted and when the feature may actually be removed -- with a narrow exception for critical security updates. This is again in keeping with the general "let's make this work better at enterprise scale" theme of the new specification. This update is "MCP's most important since remote MCP first launched over a year ago," Soria Parra wrote. Other additions include "Multi Round-Trip Requests, header-based routing, cacheable list results, authorization hardening, a formal extensions framework, and updated Tier 1 SDKs." A full list of changes can be found here.

Read more of this story at Slashdot.

joshuark quotes a report from MIT Technology Review: It is impossible to make large language models fully secure against hacks because of a fundamental flaw in how they work, a team of researchers argue in a paper presented at the International Conference on Machine Learning, a top AI conference, this month. The claim has huge implications for the safety of this technology. By taking advantage of this flaw, which concerns how LLMs identify who or what is giving them instructions, the researchers were able to make popular LLMs spit out information they had been trained not to provide, such as how to synthesize cocaine and how to sabotage a commercial aircraft's navigation system. "There's a real probability that this is going to be a problem that's fundamentally unsolvable," says Charles Ye, an independent researcher and coauthor of the ICML paper. [...] The ICML paper describes attacks against several of OpenAI's models, but Cui and Ye say that they have since seen similar results with models made by Anthropic, Alibaba, and DeepSeek. Cui and her colleagues wanted to find out why an attack like chain-of-thought forgery was so effective. They suspected it had something to do with the mechanism that LLMs use to keep track of where their instructions are coming from. But what Cui and her colleagues discovered is that LLMs are in fact very bad at keeping track of different roles. In a series of experiments that looked at what was going on inside a handful of different models, the researchers found that LLMs seem to identify the role of a specific chunk of text not by the tags around it but by the style of that text and the words it contains. The upshot, the researchers claim, is that all an attacker needs to do to hack an LLM is write text that spoofs a certain role. And because roles are a fundamental part of how LLMs work, no amount of training will fully solve the problem. "There's going to be a huge economic incentive for people to do jailbreaks and prompt injections," says Cui. The best defense could be to expect the worst. Organizations shouldn't trust LLMs, and they should expect that anything done by agents could be unsafe, he says: "That's not a great solution, but it just might be what we have to do." "It's really incredible that these things are being deployed everywhere to control super-critical systems. There's been no study of the fundamental science here. We're all doing it ad hoc."

Read more of this story at Slashdot.

Happy GNOME translators, reviewers, and developers,

I have just created the GNOME 51 release on Damned Lies, our translation platform.

Have a look at the GNOME release calendar in order to know the coming due dates. As a reminder:

• 2026-08-01 : API/ABI, Feature, UI, String Announcement Period
• 2026-08-22 : String Freeze for GNOME 51
• 2026-09-12 : GNOME 51 Tarballs due date

You can of course start translating before the string freeze, but it might happen that you will have to rewrite some of the already updated strings.

The string freeze occurs 3 weeks after, and changes are not expected to come, except those that have been declared (or detected by Damned) explicitly and validated by the Coordination team (which you can reach here: Teams / Translation / Coordination · GitLab ).

If you are a developer, entering the String Announcement period means that you are likely to declare the update in your strings to the coordination project; this way, team coordinators can track the changes and know what requires their attention.

Team coordinators, it’s time to rally your teams, review your documentation, and welcome new members! Please remember that translation is a great way to connect with our GNOME communities, and that your new members might be future maintainers of our ecosystem!

Thank you all for your participation, happy translating!

FYI: 42 languages reached > 85% for GNOME 50 UI, let’s do even better! Good luck, everyone!

Dirty COW. Dirty Pipe. Dirty Frag. DirtyDecrypt.

Warning! Do not try any of this at home! Messing with internals of electronic devices is dangerous and can lead to electrical fires, serious injury and even loss of life.

My dad started using a super 8 film camera as early as 1967 (the system was launched in 1965). He stopped doing it in the 1980s as it became pretty much impossible to buy film. Ever since then the films have been stored in multiple cardboard boxes in his basement. Recently he moved to a smaller apartment so all the films and related hardware had to go somewhere else. Namely, to me. Here is a representative sample.

The picture does really not make justice to the projector. It is perhaps the only household appliance I have ever owned that could survive a head-on collision with an IBM Thinkpad from the 2000s. The projector weighs 10 kilos and consumes 200 watts when running, half of which is taken by its halogen light bulb. For comparison a typical modern LED light bulb consumes less than 5 watts.

The projector has not been used this millennium so unsurprisingly it did nothing when I plugged it in. The back cover could be opened (with a screwdriver) revealing two glass fuses, one of which was burnt. I replaced it and plugged the machine back in. It immediately let loose the magic smoke even though everything was turned off. Fortunately I had kept the back cover open so could see the smoke the second it appeared and managed to cut the power before flames appeared. Unfortunately the smoke originated deep inside the machine so I could not see which component was the source. To get deeper I would have to remove all the covers. That is no small feat, mind you, I had to buy a whole new ratchet set to get all the various screws out.

This thing predates printed circuit boards that would tell you which holes belong to which components. Instead all components have been soldered to the board by hand with Japanese meticulousness. The board won't give us any help on deciphering how things should work. Visual inspection also does not reveal any immediately broken components. Neither did poking around with a multimeter.

The only life line was that even though a component had started smoking the fuse had not blown. In theory I could plug the machine in for a second and see if smoke appears again. If it does I can see the exact component faulty component. At this point I'd like to remind you of the warning at the top of the post. If you have a known broken electrical device, you should never connect it to any sort of a power source. Seek advice from a qualified professional instead. Even if you manage not to burn your house down, electric shocks are nasty any resulting smoke is almost certainly noxious.

Anyhow, after taking sufficient precautions I plugged it back in and immediately got smoke and could decipher what was wrong. One of the main electrolytic capacitors (the one that was in the most inconvenient location, obviously) had dried out and shorted. This caused one of the bridge rectifiers to have its positive and negative output leads short circuited. Here are the problematic components.

The dark blue capacitor on the right is the broken one. For some weird reason the three decoupling capacitors have different voltage ratings (16V, 25V and 50V) even though there is only one transformer and input voltage (12 V). The black circles are the bridge rectifiers. The one on the right is the broken one. In this picture the cracks are fairly visible but trying to detect them in person is very difficult, even with a magnifying glass and a flashlight. According to multimeter measurements the other two capacitors and rectifier are working, but it's better to replace all of them. 50 year old eletrolytic capacitors have a short life expectancy and the additional work needed to fix all instead of only one is insignificant.

Here is a comparison shot of the old components and their modern replacements.

After soldering in the new components you enter a paranoid session of measuring every possible combination on the board to ensure you have not accidentally created a short or put any of the components in the wrong way. Any failure can give you a live Electroboom experience in your own home. Even though it sounds exciting, you really don't want to see it with your own eyes. I don't speak from experience here, and intend to keep it that way.

Anyhow, eventually you have to plug the power and try if the machine works. Amazingly enough it did without a hitch. Once you have it running you can truly appreciate how well the mechanical parts of the projector have been designed. It runs silent, smooth and with zero visible jitter. There is only one plastic knob in the entire device. Unfortunately it is the lens focus adjustment wheel, and it has broken off (as you can see in the first image). You can still sort of twist it with your fingers but the experience is inconvenient to say the least.

What next?An obvious question some of you might have is "Wouldn't it be more convenient to watch films on a computer than an ancient and potentially deadly projector?" The answer to that is "Yes, it would indeed be." But more on that in a future blog post.

Version:6.18.41 (longterm) Released:2026-07-30 Source:linux-6.18.41.tar.xz PGP Signature:linux-6.18.41.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.18.41

Version:6.12.100 (longterm) Released:2026-07-30 Source:linux-6.12.100.tar.xz PGP Signature:linux-6.12.100.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.12.100

Version:6.6.147 (longterm) Released:2026-07-30 Source:linux-6.6.147.tar.xz PGP Signature:linux-6.6.147.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.6.147

Version:6.1.180 (longterm) Released:2026-07-30 Source:linux-6.1.180.tar.xz PGP Signature:linux-6.1.180.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.1.180

Version:5.15.213 (longterm) Released:2026-07-30 Source:linux-5.15.213.tar.xz PGP Signature:linux-5.15.213.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-5.15.213

Version:5.10.262 (longterm) Released:2026-07-30 Source:linux-5.10.262.tar.xz PGP Signature:linux-5.10.262.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-5.10.262

An anonymous reader quotes a report from Wired: OpenAI said Tuesday that the rogue AI agent that breached Hugging Face's platform also hacked multiple third-party accounts and services as part of the attack. It's now clear that the unprecedented security incident, which arose during an internal test of OpenAI's latest AI models, was more extensive than the company initially disclosed. In an updated blog post, OpenAI said that an ongoing review of the incident revealed that "four accounts" tied to "publicly available services" were used by the AI agent as part of a larger effort to hack Hugging Face. The rogue agent apparently found credentials that had been exposed on the open web and used them to break into the accounts. OpenAI did not disclose what companies or organizations the accounts belonged to, but noted that they were not impacted at "the level of severity or scale of what we've shared related to Hugging Face." One of the additional accounts compromised by OpenAI's agent was used as an "outbound relay and staging path," potentially to obscure where the attack on Hugging Face was coming from, the company said. OpenAI's rogue agent also used another account for data storage to assist with the hack. Reuters reported on Tuesday that a customer of Modal, a company that offers software infrastructure for training and running AI services, was one of the entities compromised by OpenAI's agent. In a statement to WIRED, Modal's chief technology officer Akshat Bubna confirmed that OpenAI's agent exploited a vulnerability in one of its customer's codebases, which was running on Modal's infrastructure. However, Bubna says, "Modal's platform was not compromised in any way." The identity of the customer could not be determined.

Read more of this story at Slashdot.

Version:6.12.99 (longterm) Released:2026-07-29 Source:linux-6.12.99.tar.xz PGP Signature:linux-6.12.99.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.12.99

Version:6.6.146 (longterm) Released:2026-07-29 Source:linux-6.6.146.tar.xz PGP Signature:linux-6.6.146.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.6.146