Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.

Log In

Log In

Create Account  |  Retrieve Password


Site News

Join our Folding@Home team:
Main F@H site
Our team page


Funding Goal
For 6-month period:
2022-07-01 to 2022-12-31
(All amounts are estimated)
Base Goal:
$3500.00

Currently:
$438.92

12.5%

Covers transactions:
2022-07-02 10:17:28 ..
2022-10-05 12:33:58 UTC
(SPIDs: [1838..1866])
Last Update:
2022-10-05 14:04:11 UTC --fnord666

Support us: Subscribe Here
and buy SoylentNews Swag


We always have a place for talented people, visit the Get Involved section on the wiki to see how you can make SoylentNews better.

Roughly how much cash is in your pocket/wallet/purse right now?

  • None: why do I need cash anymore, grandpa?
  • Just enough for random small transactions
  • Enough for regular errands (grocery, fuel, etc.)
  • An unreasonably large amount
  • Normally none, but whatever amount my non-app-using acquantice paid me back for dinner
  • I'm all-in on crypto, you insensitive fiat-currency-loving clod!

[ Results | Polls ]
Comments:111 | Votes:494

posted by janrinok on Thursday June 04, @07:58AM   Printer-friendly

https://www.theregister.com/ai-and-ml/2026/06/02/github-copilot-users-threaten-exit-as-metered-billing-kicks-in/5249826

Developers seem to hate Microsoft's new usage-based billing policy for GitHub Copilot as they report burning through a month's worth of credits in hours. 

"This is a staggering shift from a 'predictable subscription' to a 'stressful meter-based' service that hinders my productivity rather than helping it," wrote one developer on GitHub's user forum who said they were paying for Microsoft's $39-per-month Copilot Pro+ plan but burned through about 8 percent of their monthly AI Credits allocation in two hours under the new billing system. "At this rate, my 7,000-unit quota will be depleted in less than two days." 

Their outrage is a consistent and growing theme among the business users of AI who suddenly see eye-popping bills after years of experimenting with a nearly free service. One GitHub Copilot developer requested a single change to their project and burned more than $6, they wrote. 

"Not after a day of usage. Not after dozens of prompts. After ONE request," the developer stated on GitHub's user forum. "I understand that large projects require context, but this level of consumption feels completely unreasonable and impossible to predict. How are individual developers supposed to budget for this when a single feature request can consume such a large portion of the monthly allowance?" 

The changes went into effect across the site on Monday. In GitHub's April post announcing the new billing scheme, Microsoft said the change was made from monthly billing to usage-based because GitHub Copilot is "not the same product it was a year ago." 

"It now powers far more complex, agentic workflows that consume far more compute. This change is designed to deliver a more sustainable and reliable product experience by aligning pricing to actual usage and costs," the post to its user community reads. "We believe GitHub Copilot remains the best value and experience for agentic coding. Usage-based billing aligns cost more closely to actual usage and value, while continuing to offer developers the freedom to choose the models and agents that work best for them." 

GitHub Copilot lets developers access a range of AI models from within their development tools. That had allowed some users to make large numbers of requests across multiple models while paying as little as $10 per month for Copilot Pro, or $39 per month for Copilot Pro+.

Now, each request from users is dynamically priced depending on the model used, the request, and the amount of material submitted by the user, as well as the complexity of the answer returned.

"Woke up to the new billing UI this morning. Figured I'd test it out on some actual work — just needed Claude 4.8 to help fix a couple things on a site I'm editing," one Reddit user posted. "It gave some pretty mediocre suggestions. Didn't really solve the problem, I still had to do most of the work myself ... Then I checked the actual usage page. 1,180 credits used. 16% of my monthly Pro+ allowance. Gone. For basically nothing." 

The comments online have been overwhelmingly negative, with users on GitHub's forum and Reddit vowing to abandon the product and move their work directly to Anthropic, OpenAI, and some creating their own workarounds through a series of free or cheaper AI vendors, like RooCode, LM Studio, or OpenRouter. 

"I've opted to stick to Pro+, burn through my allocated credit in a week, and then pivot to using OpenRouter for the remainder of the month," one user posted. "OpenRouter offers a similar set of advantages that Copilot has over other providers. It can be used within the same VS Code interface. Plus it has more models and credit rolls-over for up to a year." 

The Register asked Microsoft about the user complaints and a GitHub spokesperson responded with a statement saying it had introduced a new billing policy, and provided a link to a FAQ.

"Usage-based billing is now in effect. Pricing for GitHub Copilot now reflects actual usage with spending limits, usage dashboards, and model selection available to help manage costs. We're also introducing Copilot Max for users who need more capacity," the statement reads.


Original Submission

posted by janrinok on Thursday June 04, @03:14AM   Printer-friendly

Welcome to this year's 22nd issue of DistroWatch Weekly! This week we are thrilled to present you with a special milestone edition of DistroWatch Weekly. As I write this, DistroWatch is celebrating its 25th anniversary! Not many websites get to survive for a quarter of a century and we're thrilled our readers continue to come along for the experience. Later in this Weekly we share some thoughts on our publication turning 25 years old and provide some statistics about our little corner of the Internet.

DistroWatch is a website that provides news, distribution pages hit rankings, and other general information about various Linux distributions as well as other free software/open source Unix-like operating systems. It now contains information on several hundred distributions and a few hundred distributions labeled as active.

How many of our community use Distrowatch? Do you view it regularly, daily, occassionally, or ask "Is Distrowatch still going...?".


Original Submission

posted by janrinok on Wednesday June 03, @10:26PM   Printer-friendly

https://arstechnica.com/ai/2026/06/openais-math-breakthrough-played-to-ais-strengths/

In mid-May, OpenAI announced that an internal AI model had disproved the Erdős unit distance conjecture, a famous problem in discrete geometry that had stumped human mathematicians for the last 80 years.

OpenAI gave several mathematicians early access to the result and published their reactions. Tim Gowers—who won the Fields Medal, the most prestigious prize in mathematics—wrote that "there is no doubt that the solution to the unit-distance problem is a milestone in AI mathematics."

University of Toronto professor Daniel Litt wrote that "this is the first example of a result produced autonomously by an AI that I find exciting in itself, as opposed to as a leading indicator."

It's arguably the first time that an AI system has found a proof resolving a major open conjecture. That's impressive, but I don't view it as a radical break from the previous trajectory of AI progress in mathematics.

Three years ago, LLMs struggled to solve arithmetic problems. It was only last year that LLMs started acing high school mathematics competitions.

When I attended the Joint Mathematics Meetings—the largest annual mathematics conference in the world—in January, I learned that AI systems were starting to contribute to mathematical research, but only in constrained settings. It took significant human interpretation to turn an AI output into a publishable theorem.

OpenAI's new result is the next step in this progression. The AI model cleverly applied existing ideas drawn from several subfields of mathematics to create a full proof. But it didn't pioneer any genuinely new techniques. The result has since been cleaned up and extended by human mathematicians.

This points to a medium-term future where human mathematicians and AI models complement each other: AIs have a broader knowledge of past work than any human alive and much more willingness to grind through tedious proof strategies that aren't likely to work. But humans can still think more deeply about any one problem and ask more interesting questions.

That might not last. AI systems have been improving at math so rapidly that it's unclear what role, if any, human mathematicians will play a decade from now.

Paul Erdős was one of the most prolific mathematicians in history. He wrote over 1,500 papers in his lifetime, the most ever. One of his greatest talents was coming up with problems that are simple to state but have deep roots.

In 1946, he introduced the unit distance problem. Imagine you have some points in a 2D plane and you measure the distance between each pair of points:

In this diagram, there are five points and ten pairs of points. Three pairs happen to be exactly 1 unit apart: AD, BE, and CE.

Can we rearrange the points so that more pairs of points are exactly 1 unit apart?

Yes. For instance, we could move points A and D to be closer to the B, C, and E cluster. With a bit more work, we could further rearrange the points so that there are seven pairs exactly one unit apart. But that's the most we can do.

We could do the same analysis with 6 points, 7 points, and so on. But as the number of points grows, the problem very quickly becomes too complicated to find the exact answer.

So instead of asking exactly how many unit distances are possible for a given number of points, Erdős tried to calculate upper and lower bounds on the number of length-one lines for npoints, assuming that n is a large number.

To help calculate a lower bound, Erdős assumed that the points would be laid out in a grid. This is probably not the optimal layout, but if he could demonstrate that points in a grid have a certain number of pairs with unit distance, then the optimal arrangement must have at least that number.

The simplest option is to space the grid so that every point is distance 1 from its neighbors directly above, below, left, and right. However, Erdős saw that you could do even better if you took diagonals into account. If you make the grid spacing smaller, you can make each point be distance 1 from a greater number of neighbors. In the diagram above, if the grid spacing is 1, then each individual point is one unit away from four neighbors (the left panel). Instead, if the grid spacing is ⅕ (as shown on the right), then each individual point is one unit away from 12 neighbors:

OpenAI's write-up of its new result included a confusing diagram showing points in a grid with a bunch of lines connecting them. The diagram becomes easier to understand if we superimpose a circle like this:

This works because of the Pythagorean theorem, which states that if we have a point that is a units to the right and b units above another point, the distance c between those two points satisfies a² + b² = c². The trick is to choose some number c² so that there are a whole bunch of pairs of whole numbers a and b such that a² + b² = c². Then, if we scale the grid down so that each point is 1/c from its neighbors, there will be a bunch of unit distances.

For example, if we choose c² = 25, then the Pythagorean equation can be satisfied by either 0² + 5² = 25 or 3² + 4² = 25. This corresponds to the 12-grid-point circle I showed earlier, with points at (0,5), (3,4), (4,3), (5,0), (-4,3), (-3,4), and so forth. (Technically, these lengths should all be divided by 5 — (⅗, ⅘) for example—but I'm leaving the denominators out for clarity.)

OpenAI's diagram is based on choosing c² = 65, which can be satisfied by either 1² + 8² = 65 or 4² + 7² = 65. This means that if the grid spacing is 1/√65, each point will be one unit away from 16 other points: (1,8), (4,7), (7,4), (8,1), (-1,8), (-4,7), and so forth. Larger values for c²—if they're chosen carefully—enable more whole-number diagonals and hence more unit-distance pairs.

However, if c² is too large compared to the number of points in the grid, then many of the potential one-unit-away neighbors will be outside the grid.

In short, we want to choose a c² that's large enough but not too large. Using insights from number theory, including Jacobi's two-square theorem, Erdős was able to show that an optimally sized circle will enable the number of unit-distance pairs to grow faster than the number of points, but only barely.

The question became "can you do better?" To find an upper bound, Erdős used an argument from a quite different area of mathematics called graph theory to show that you could only have so many unit distances. But his upper bound grows much, much faster than the best lower bound he was able to construct.

Erdős's conjecture was that the actual optimum was much closer to the lower bound than the upper one. He predicted, but couldn't prove, that the maximum number of unit-distance pairs grows just barely faster than the number of points.

To be more precise, Erdős conjectured that the number of unit distances would be n^(1+o(1)). In other words, for a sufficiently large n, the maximum number of unit distances would be less than n^(1+𝜖) for any 𝜖 > 0. That could end up growing a little faster than his lower-bound construction—which was n^(1 + C/(log log n)) for some constant C—but within the same general ballpark.

Proving his guess became known as the unit distance problem. For the next 80 years, it looked like Erdős was right.

Then an OpenAI model proved him wrong.

Erdős's conjecture assumed that, at least for a large number of points, a square grid could yield about as many unit-distance pairs as organizing the points in other ways. OpenAI's AI proved this wrong by demonstrating that there was another, more complex way to organize n points that allowed more pairs to be exactly one unit apart.

Precisely because the new pattern of points is more complicated, it's tricky to explain it concisely. But you can think of it as a clever modification of Erdős's grid.

The AI constructed a grid in a high-dimensional space and then projected this more complex structure into two dimensions. And instead of using a whole-number grid with points like (1,3) or (-3,6), the AI construction used something called algebraic integers to build this more complicated grid. It turns out that this kind of higher-dimensional grid has richer structure, which allows the AI to pack more unit distances into the same number of points.

It's hard to illustrate this alternative arrangement of points because it only becomes advantageous with a very large number of points. But here's a simpler arrangement of points that was constructed in a similar way. You can click here if you want to play with the illustration yourself.

It has 1,345 points and only produces 5,916 unit distances, fewer than the 7,632 unit distances that a square 1,296-point grid produces using the Erdős technique. But I think it gives a sense of how a pattern that isn't a grid could produce more unit distances than a square grid.

The more complicated patterns pay off. While the OpenAI model's proof does not explicitly state how many unit-distance pairs are possible for n points, human mathematician Will Sawin was able to show that it grows at least at the rate of n1.014. This might seem small, but as n gets really big, this number will become much larger than the counts produced by the Erdős approach.

That being said, the AI's result doesn't completely resolve the problem. Our best upper bound for the number of unit distances is around n1.333. More work is needed to close this gap.

If you'd asked me two weeks ago—before OpenAI's announcement—about the most novel contributions of LLMs to mathematics, I probably would have pointed to the AlphaEvolve system from Google DeepMind.

AlphaEvolve harnesses LLMs to be the engine of an optimization process. If you can turn a math problem into a piece of code to optimize, which you often can, the LLM might find better solutions than humans have for certain types of problems. In November, four mathematicians (including Terence Tao) released a paper that analyzed AlphaEvolve's performance on 67 optimization problems across the mathematical literature. They found that AlphaEvolve was able to improve on the established literature in some cases.

This was a step up in autonomy from previous LLM contributions, such as literature review, but it still required humans to frame it as an optimization problem and turn the AI's output into usable mathematics. And only certain types of problems are amenable to this approach. More conceptual questions that don't include a number to optimize can't easily be studied with AlphaEvolve.

So AI companies have been working to develop LLM systems that can directly output a correct solution to any math problem. OpenAI's result is a substantial step in that direction. But it also fits the pattern of previous AI-assisted mathematics.

For one thing, other companies have also worked to solve Erdős problems. Because Erdős posed hundreds of problems over his career—and because mathematician Thomas Bloom has organized an effort to compile all of them at www.erdosproblems.com—AI companies have used them as a testing ground to evaluate AI systems. In January, Cambridge undergraduate Kevin Barreto worked with a friend to ask GPT-5.2 and Harmonic's Aristotle to produce the first autonomous solution of an Erdős problem. On May 22, two days after OpenAI's announcement, Google announced that its AI system had solved nine open Erdős problems, including two that had been open for over 50 years.

To be clear, the problem that OpenAI solved is more impressive than any of the other work I just mentioned. But OpenAI's solution is more in line with past AI efforts than the headline result might suggest.

One reason the unit distance problem was unsolved for 80 years, despite being so well known, is that most people thought Erdős's conjecture was true. But the mathematical tools we have are nowhere close to being able to prove Erdős's bound. So mathematicians expected that any proof of the conjecture would involve major new ideas or approaches.

Instead, as we've seen, the AI disproved the conjecture by making an extension of Erdős's initial construction. It was a clever and nonobvious solution, but it also bore some similarity to the kind of optimization work done by a system like AlphaEvolve.

This dynamic is reflected in some of the mathematicians' responses. Mathematician Tim Gowers wrote that when he first heard about the AI's result, he thought it had proved the theorem. "I spent the evening adjusting my world view: If the AI could come up with a proof like that, then maybe it would be all over for mathematicians very soon."

But the next morning, Gowers and other external reviewers received an email about the result, and he realized that the LLM "had disproved the conjecture rather than proving it, which came as a big relief."

OpenAI's solution also had two properties that played to the strengths of AI models relative to humans.

First, the eventual solution relied on applying sophisticated techniques from a quite different area of mathematics: algebraic number theory. AI systems have been trained on huge swaths of mathematics—and there's a lot of math out there—so they have a broader knowledge of previous mathematical work than any human in the world. For a human to solve this, they would have needed to have the relevant algebraic number theory knowledge while also being interested in the unit distance problem, a rare combination.

Second, the reasoning process was such a grind, and seemingly unlikely to succeed, that most humans would not have thought it worth the trouble. Jacob Tsimerman, a University of Toronto professor, remarked in the OpenAI document that he had briefly considered taking a similar approach to disprove the conjecture. But that type of technique "consumes much time and frequently doesn't work out," so he abandoned the project.

An AI, on the other hand, can work through many proof strategies that don't work out before discovering one that does. OpenAI could have run the problem many times before a model found a solution. Indeed, an OpenAI chart revealed that even with the maximum token budget, the internal model solves the problem only half of the time.

To be clear, what the AI system did is still impressive. "It's always tempting to look at a completed proof and declare it obvious after the fact," Tsimerman said later in his remark. But as I noted previously, it also played to the strengths of AI systems.

In the short to medium term, this points to a world where AI models complement humans but do not replace them. AI systems will tackle lists of problems curated by human mathematicians or aid humans in finding relevant approaches from seemingly unrelated mathematical fields. But they won't immediately displace the human role in choosing which questions to ask or developing wholly new techniques.

Even this result was very much a human-AI collaboration. While the AI system found the proof on its own, human mathematicians verified the result. Other humans came up with better-written proofs that extended the AI's initial ideas, like Will Sawin finding an explicit lower bound as I mentioned above.

It's unclear how long this complementarity will last, however. Gowers spent the rest of his comment exploring whether the relief he felt on hearing that AI had disproved the conjecture was justified. He more or less concluded that it was, but in a footnote, he wrote that he would guess "that AI will soon reach a high level at other activities such as building theories, formulating definitions and asking interesting questions."

In the past year, we've gone from AI systems that hadn't yet beaten high school mathematics competitions to ones that can advance mathematics in interesting ways. It seems likely that AI systems will continue to become more autonomous when working on mathematical problems.

At the same time, we haven't fully explored what current models can achieve in math. Soon after OpenAI's announcement, University of Michigan postdoc Xiao Ma found that GPT-5.5 was also able to prove Erdős wrong if given a small hint. If a generally available model could disprove this famous conjecture and no one noticed, what other discoveries could happen today that no one has thought to try?

Kai Williams is a reporter for Understanding AI, a Substack newsletter founded by Ars Technica alum Timothy B. Lee. His work is supported by a Tarbell Fellowship. Subscribe to Understanding AI to get more from Tim and Kai.


Original Submission

posted by janrinok on Wednesday June 03, @05:34PM   Printer-friendly

https://www.slashgear.com/2184557/uss-supercarrier-gerald-r-ford-nuclear-power-plant/

The USS Gerald R. Ford, first deployed in late 2022, is a truly remarkable ship. It already earned the distinction of being the world's largest aircraft carrier and, as of May 2026, is on track to earn another impressive distinction. The over 1,100-foot-long supercarrier is being fitted to serve as a floating nuclear power plant for an on-land naval installation. The test is slated to take place at Naval Station Norfolk, located in Norfolk, Virginia, sometime in summer 2026.

The carrier and its twin A1B nuclear reactors — which were developed specifically for the Gerald R. Ford — will power the entire base. While the United States military has kept many specifics of the A1B under wraps, estimates suggest that a single A1B produces about 700 MWt; two of them, then, would generate 1,400 MWt. This is approximately 25% more power than the A4W reactors that powered Nimitz-class vessels. Of course, it's not just a matter of plugging it into the grid, and the U.S. Navy will conduct extensive research and testing to safely and effectively move power from the ship to land.

While this is a fascinating feat on paper, what exactly is the point of running a naval base off of a supercarrier's nuclear reactors? According to those involved with the effort, this project is all about preparedness.

Naturally, there is a point behind a test of this magnitude. The idea behind running a naval base off the USS Gerald R. Ford's nuclear reactors is to enhance the U.S. military's disaster response capabilities. Should a natural disaster or an enemy attack take out a region's power grid, these carriers could act as floating generators until the affected areas get back on their feet. As more Ford-class carriers — like the USS John F. Kennedy, set for arrival in 2027 – come online, the Navy could have a fleet of floating power stations ready to respond to multiple worst-case scenarios across the country.

The Navy is confident that this capability can help in military and civilian capacities alike. During a May 2026 House Armed Services Committee hearing, Acting Secretary of the Navy Hung Cao suggested that these vessels could also help provide electricity to repair military bases and supply fresh water to drought-stricken areas (via Nuclear Newswire). Of course, whether the USS Gerald R. Ford can actually do any of this depends on the results of this test.

The USS Gerald R. Ford might not be the most decorated U.S. Navy aircraft carrier in history, but there's no denying its place in the history books. In addition to being notably enormous, it could very well be the saving grace for disaster-stricken areas in need of electricity.


Original Submission

posted by jelizondo on Wednesday June 03, @12:57PM   Printer-friendly

https://www.cnet.com/tech/services-and-software/perplexity-ai-cnn-copyright-suit/

The AI search company Perplexity is being sued by CNN and other media companies for copyright infringement.

AI products regularly scrape news publications and websites to answer user questions with real-time data, accelerating the collapse in traffic and revenue to original sources.

In response to the lawsuit, Jesse Dwyer, Perplexity's chief communications officer, told Stetler and other media outlets in a statement: "You can't copyright facts." The US government's Copyright Office states: "Copyright does not protect facts, ideas, systems, or methods of operation, although it may protect the way these things are expressed."

CNN said in its own statement that a company valued at tens of billions of dollars shouldn't "steal from entities that create the original content Perplexity exploits" and that "commercial operators can and must pay to make use of it." 

A Perplexity representative didn't immediately respond to a request for comment.

Perplexity is one of several companies, including OpenAI and Anthropic, that have been battling news publishers and media giants over copyright claims. 

(Disclosure: Ziff Davis, CNET's parent company, in 2025 filed a lawsuit against OpenAI, alleging it infringed Ziff Davis copyrights in training and operating its AI systems.)  

More than 100 such lawsuits have been filed. But different conclusions have been reached as to whether training AI models on copyrighted data counts as fair use, said Michael Goodyear, an associate professor at New York Law School. Considerations include how the training occurs, what AI outputs contain and whether there's any competitive harm to copyright holders. 

"No appellate courts have yet weighed in on the viability of these copyright infringement claims against AI companies," Goodyear said. 

In the CNN case, he said that Perplexity is correct that facts aren't protected by copyright, but the way CNN presents facts could be.

"Even short news articles would typically qualify for copyright protection under the low bar of required originality," Goodyear said. "The question becomes whether the thousands of cases of infringement CNN describes are copying whole paragraphs verbatim, or whether they are paraphrasing or merely copying unprotectable facts."

As plunging website traffic has drained billions in publisher revenue and triggered widespread media layoffs, AI firms are aggravating the crisis. According to a new report from the think tank Open Markets Institute, over the past six months, the rate of AI crawlers bypassing paywalls and blocks has nearly quadrupled, spiking from 3.3% to 12.9%. 

That's partly why a number of publishers signed AI content licensing deals with tech companies to monetize content used to train AI systems. One way out for Perplexity may be to renegotiate a licensing deal with CNN. Even if Perplexity has valid legal arguments, a licensing agreement could shift from unauthorized scraping toward a formalized content partnership. 

However, the Open Markets Institute report says that when it comes to AI content licensing, news and content creators are trapped in a double bind. The same tech giants whose AI tools are starving websites of human traffic are now the ones gatekeeping the licensing deals meant to replace that lost ad revenue. 


Original Submission

posted by jelizondo on Wednesday June 03, @08:03AM   Printer-friendly

https://arstechnica.com/tech-policy/2026/05/musk-says-us-military-suicide-drones-used-starlink-in-violation-of-spacex-rules/

SpaceX and the Pentagon have been bickering about the price of using Starshield satellite service during the Iran war, according to a Reuters report published today. It appears that SpaceX asked the military for more money after it started using satellite terminals on "kamikaze" attack drones in Iran.

SpaceX CEO Elon Musk claimed the Reuters report is wrong. But Musk also said the military drones initially used the commercial Starlink service instead of the government-specific network, in violation of Starlink's terms of service. Musk blamed the violation on the contractor that built the drones for the government.

The Reuters report, based on Pentagon documents and interviews with sources familiar with the pricing talks, said that SpaceX recently asked the military to pay $25,000 for Starshield access on each kamikaze drone. The Pentagon, which previously paid $5,000 for each connection, objected to the price hike but ultimately agreed to pay it, according to Reuters.

While the $25,000 charge is a monthly fee for the satellite connection provided to a satellite terminal, the terminals are being used with drones that only make one-way trips before hitting targets and detonating on impact.

Starshield is a network for government entities and is based on Starlink technology. Musk wrote in an X post today that the "Reuters article is false." But in the very same post, he seemed to confirm a dispute over how the military used SpaceX satellite technology.

"They made improper use of the Starlink civilian system for military purposes. Direct violation of terms of service," Musk wrote today, seeming to indicate that the military used the commercial Starlink system when it should have been using Starshield.

Musk said later that the drones were configured incorrectly by a military contractor. "There is a US government arm of SpaceX called Starshield, which has a different set of satellites than Starlink, which is for civilian use. The company that makes the suicide drones incorrectly used the civilian system, instead of the Starshield," Musk wrote.

The Pentagon "denied any violation of its agreement with SpaceX," according to Reuters. Starshield terminals sold by SpaceX to the military can connect both to the commercial Starlink satellite constellation and Starshield, the Reuters article said.

The drones in question are part of the Low-cost Uncrewed Combat Attack System (LUCAS), which was made by defense contractor Spektreworks. We contacted Spektreworks today and will update this article if it responds.

Musk previously addressed the military use of SpaceX satellite terminals on drones on March 1, one day after the Iran war began, in response to an X post in which a user posted a picture of one of the drones that appeared to have an integrated satellite terminal.

"It is a violation of commercial Starlink terms of service to use the terminal for weapon systems. This applies to all users and is shut down when discovered," Musk wrote at the time. "There is a separate network called Starshield, which is operated by the US government. This is not under SpaceX control."

Within weeks of the US launching strikes in Iran, "SpaceX executives met Pentagon officials and argued the military was underpaying for the service," the Reuters article said.

"SpaceX argued the LUCAS drones were operating under conditions that aligned more closely with its aviation tier subscription rather than a lower priced land or mobility service. Pentagon officials argued that the $25,000 price tag—a monthly fee—was designed for aircraft, not kamikaze drones that used [a] Starlink connection for a matter of minutes or hours, according to one of the sources," Reuters reported.

The Pentagon "ultimately agreed to pay SpaceX's proposed price increase" from $5,000 to $25,000, according to Reuters. LUCAS drones give the military a cheaper alternative to traditional missiles and grew out of an effort to reverse-engineer Iranian-built drones. Each drone reportedly costs about $35,000.

Despite agreeing to the price increase, "senior officials including Deputy Secretary of Defense Steve Feinberg remained uneasy about the arrangement," and Pentagon officials in April "met to revisit the pricing with Terrence O'Shaughnessy, a retired four-star Air Force general who now leads SpaceX's defense business," according to Reuters.

"Still, the Pentagon is currently considering an additional purchase of more than 3,500 Starshield terminal subscriptions, including 100 with the higher-priced aviation tier, according to Pentagon documents reviewed by Reuters," the article said. "The deal could generate hundreds of millions of dollars in annual revenue for SpaceX, though Reuters could not determine whether an agreement has been finalized, or what price is being discussed."

There has also reportedly been a dispute over the price of providing Starlink mobile service to Iranian citizens who have suffered under a government-imposed Internet blackout. In January, the US reportedly smuggled 6,000 Starlink broadband terminals into Iran to help residents bypass blocks to Internet access.

Reuters reported that Pentagon officials asked SpaceX about providing Iranians with direct-to-cell service, which can keep people connected on standard cell phones without needing a terminal.

"SpaceX, which generated $11.4 billion in revenue from Starlink in 2025, proposed charging as much as $500 million to launch the capability, along with a $100 million monthly fee to operate it, according to one of the people and Pentagon documents—prompting alarm from defense officials over the price. Reuters could not determine whether an agreement has been reached," the Reuters article said.

The US and SpaceX previously had a dispute over payment for satellite terminals sent to Ukraine beginning in 2022. SpaceX initially donated terminals before asking the Pentagon to pay for ongoing service and more terminals. The Defense Department later confirmed that it was paying for Starlink service in Ukraine.

SpaceX's IPO filing last week said that revenue for its government connectivity business dropped in the most recent quarter. SpaceX's overall connectivity revenue in Q3 2026 was $3.3 billion, a year-over-year increase of $782 million. The increase was driven by boosts in revenue from consumers, large businesses, mobile partnerships with wireless carriers, and Starlink's aviation and maritime offerings. The overall revenue increase would have been higher if not for "a decrease of $175 million in our government connectivity business," SpaceX said.

While SpaceX isn't the only operator of low-Earth orbit satellites, Reuters notes that "no other company provides a comparable alternative to Starlink, which has become an increasingly critical tool in modern warfare since Russia's invasion of Ukraine in 2022."

The Department of Defense declined to comment on its negotiations with SpaceX today, but told Ars that it "is operating in accordance with the terms and conditions of its contracts." The department also provided Ars with a statement indicating that the military is looking for alternatives to SpaceX.

"The Department of War is committed to fostering a competitive environment for commercial satellite communications and is conducting comprehensive market research to continuously monitor commercial offerings that align with government requirements," the Pentagon statement said. "We are actively engaging with industry to identify innovative solutions and new entrants, ensuring acquisitions are inclusive of a diverse range of capable vendors."

The statement added that the Space Force's "Commercial Satellite Communications Office is working on additional options with other proliferated low earth orbit partners as part of its strategy to leverage the unprecedented capabilities provided by the commercial SATCOM industry."

We contacted SpaceX and will update this article if it responds.

Pentagon spokesperson Sean Parnell responded to the Reuters article in an X post today. "The Fake News media has the story wrong, again. SpaceX remains a strong and valued partner to the Department of War. The claims in this article are simply not based in reality and do not reflect the close, effective collaboration between our teams."

Musk shared Parnell's post, calling it a "correction issued by [the] Department of War."


Original Submission

posted by jelizondo on Wednesday June 03, @03:21AM   Printer-friendly
from the If-it's-so-obvious-why-didn't-you-do-it? dept.

https://viterbischool.usc.edu/news/2026/05/a-robot-hand-that-taught-itself-to-play-piano-could-change-the-future-of-machines/

USC researchers built the "Musician Hand," a four-fingered tendon-driven robot that learns to play piano by ear after just two minutes of random "motor babbling" on the keys. Hearing a ~30-note melody once, it converts the audio to a spectrogram, maps sounds to the motor commands needed to reproduce them, and plays the tune back in one attempt — well enough that blind judges sometimes couldn't tell it from trained human pianists.

The work, led by Hesam Azadjou under Francisco Valero-Cuevas at USC Viterbi (published in Royal Society Interface), challenges the traditional robotics assumption that good performance requires massive data, heavy computation, and tightly controlled environments. Instead, it mimics how animals learn: perceive, guess, adapt — using minimal energy and experience.

The researchers see the same "perceptual robotics" approach enabling cheaper, faster-deployed machines that work in unpredictable real-world settings — e.g., exoskeletons that learn an individual's gait early in Parkinson's and later help restore it, or home physical-therapy robots that adapt to each patient in real time.


Original Submission

posted by hubie on Tuesday June 02, @10:37PM   Printer-friendly

The technique correctly identified visited websites with roughly 89% accuracy and running applications with roughly 96% accuracy on a test Mac:

Security researchers at Graz University of Technology in Austria have published a paper describing a side-channel attack that lets a malicious website identify what other sites and apps a visitor has open by measuring SSD access latency through JavaScript inside a standard browser sandbox. The technique, called FROST (Fingerprinting Remotely using OPFS-based SSD Timing), correctly identified visited websites with roughly 89% accuracy and running applications with roughly 96% accuracy on a test Mac, requires nothing from the victim beyond visiting the attacker's page, and works across different browsers.

FROST exploits the Origin Private File System (OPFS), a browser API that lets websites create and store files on a user's local disk without prompting for permission. Previous SSD side-channel attacks that we’ve seen require native code running through privileged kernel interfaces, but FROST eliminates that requirement.

The team disclosed their findings to Google, Apple, and Mozilla: Google said it doesn't consider fingerprinting a security vulnerability, Apple called the attack "currently out of scope," and Mozilla acknowledged the findings without implementing fixes.

The attack creates a large OPFS file on the victim's SSD, with both Chrome and Safari allowing a website to claim up to 60% of total disk space through OPFS, which on a 256GB drive is over 150GB. The file must exceed the system's available RAM so that every random 4 KB read hits the SSD rather than the OS’s page cache. When other activity generates its own disk I/O, it creates measurable latency spikes in the attacker's reads, and those timing patterns are fed into a convolutional neural network trained to recognize specific websites and applications by their I/O signatures.

Because the contention occurs at the storage level, the attack works across browsers; running the attacker page in Chrome while the victim browsed in Safari showed only a 3.38% throughput difference versus a same-browser attack.

The full fingerprinting attack was only tested on an M2 Mac Mini with 8GB of RAM and a 256GB SSD. On Linux, the researchers confirmed they could measure SSD latency from the browser, but didn’t run the full fingerprinting classification, and Windows wasn’t tested at all. The OPFS file must also reside on the same physical SSD as the monitored activity, which isn’t guaranteed on multi-drive workstations.

By far the biggest barrier to this attack is the large file size; most people will notice tens or hundreds of gigabytes suddenly disappearing, but the researchers propose mitigations, including capping OPFS file sizes to fit within system memory or requiring explicit permission for OPFS file creation. Given that Google doesn’t classify fingerprinting as a security issue, browser-level fixes are unlikely in the near term.


Original Submission

posted by hubie on Tuesday June 02, @05:52PM   Printer-friendly

Now that doesn't mean Linux stable kernel maintainer Greg Kroah-Hartman thinks Rust is magic:

At the Rust Week conference, the world's biggest Rust language conference, in Utrecht, Netherlands, Linux stable kernel maintainer Greg Kroah-Hartman opened by saying: "I'm here to talk about untrusted data and Linux, and how Rust is going to save us." After "a long month or two on the kernel security list," he pushed that point even further: "I'm going to make even a bolder statement and say, 'You are going to save Linux.' Sorry, it's all on you."

What he was talking about was the sudden flood of serious Linux security holes being discovered, such as Dirty Frag, Copy Fail, and Fragnesia, that have come to light thanks to the latest AI bug-detection programs.

As a result, Kroah-Hartman, who has "seen every single kernel security bug ever" since 2005, said the kernel team is now issuing "13 CVEs [Common Vulnerabilities and Exposures] a day, or something, something crazy." He thinks Rust is one of the few realistic ways to slash the class of bugs that come from C's traditional error-handling and resource-management pitfalls.

Kroah-Hartman illustrated those pitfalls with real C bugs in the kernel, including a 15-year-old Bluetooth bug that dereferenced a pointer without checking it and a Xen bug where "we forgot to unlock" in an error path. "The majority of the bugs in the kernel are this tiny, minor stuff," he explained. "Error conditions aren't checked, locks aren't forgotten, unreleased memories leak, and vulnerabilities add up over time. They crash the kernel. This is what we live with in C. This is why we don't like it."

Kroah-Hartman argued that the "best beauty of Rust" is catching those mistakes at build time rather than in review. For example, when it comes to locking, he highlighted Rust's locking abstractions in the kernel: "The only way you can get access to inner pointers of structures is by grabbing that lock, and releasing the lock automatically. The compiler does it, it's guarded, the lock happens, everything's happy. You just can't write code to access these values...without grabbing the lock. The compiler will not let you."

Those properties, he argued, directly remove a huge fraction of the bugs he sees: "This is going to save us those two things. First, 60% of the bugs in the kernel right there, they're gone. Thank you." The payoff is earlier, more automated enforcement: "If this happens at build time, not review time, don't make me a maintainer who has to read your code [and] say, 'Oh, then you properly check that error value. Oh, did you properly grab the locks in the right spot?' Rust gives us that for free. This is the best thing ever."

Even if Rust vanished tomorrow, Kroah-Hartman argued, it has already forced the kernel to clean up C code and interfaces. He credited Rust's influence outright: "We stole this from Rust. Thank you. It's a good idea, so if Rust disappeared tomorrow, we have cleaned up the C code in the kernel so much and taken in the ideas. We thank you, you've made Linux better with it just by existing."

[...] Now, that doesn't mean he thinks Rust is magic. It's not. He cited one of the first Rust components merged into the kernel: QR code display logic used when the kernel crashes. "That logic was written in Rust. Famously, it had a memory bug. It was given a buffer and its size, and the rest of the st code never checked the buffer size... Could scribble all over memory, because Rust can crash just as bad as C." So, Rust "is not a silver bullet."

He's also not encouraging anyone to rewrite the Linux kernel in Rust. One attendee asked, "Do you actually encourage rewriting stuff that's already there in the kernel with [Rust]?" Greg replied: "No, we don't want rewrites, so unless you're the maintainer and owner of that file, just do it for new stuff. Leave existing C code alone, and let's evolve forward after that." He gave Binder, Android's core interprocess communication (IPC), as an example where both C and Rust implementations coexist temporarily to reach parity, after which "they're going to delete the C code, because I trust them, and they are the owners and maintainers of both those."

[...] What ultimately sold a number of core maintainers, including him, on Rust was how it "makes reviewing code easier." With CI [Continuous Integration] bots enforcing builds and Rust's type system enforcing key invariants, maintainers can "focus on the logic" rather than resource bookkeeping: "I can care about that one function. I don't have to worry about the rest of this stuff, because I assume that it works properly, because it was built properly."

Internally, he said, the top maintainers have already made their call on Rust's status: "The Linux kernel maintainers, we get together every year and talk about what the processes are doing. Last year, we said the Rust experiment is over. It's not an experiment. This is for real." The rationale: "The people behind it are real. We trust them. We know what they're doing. They've shown and put in the work to make Rust a viable language in the kernel, and we're going to make this stick. Let's go full speed ahead. And, as always," he said wryly, "world domination proceeds."


Original Submission

posted by hubie on Tuesday June 02, @01:07PM   Printer-friendly

The feds are raising the alarm about a new category of threat:

In the wake of attacks on CEOs, a nationwide protest movement targeting data centers, and increasing concerns about AI job replacement, federal intelligence agencies and domestic law enforcement are circulating reports with a new domestic target in mind: anti-technology extremists.

More than 1,000 pages of unpublished reports from the Department of Homeland Security, FBI, and fusion centers obtained by WIRED show a national shift taking place to surveil this new and worryingly broad category of people and activities deemed an emerging threat.

This new effort follows President Donald Trump's National Security Presidential Memo 7, which instructs the Department of Justice to target anyone holding "anti-American," "anti-Christian," and "anti-capitalism" beliefs. Earlier this month, Trump's counterterrorism czar, Sebastian Gorka, released a public counterterrorism strategy claiming that left-wing extremists are one of the three top counterterrorism priorities facing the United States.

Taken together, these Trump administration directives have commandeered the domestic surveillance apparatus to surveil and criminalize speech and assembly that challenges the ideology of the White House. A new focus on anti-technology extremism adds an unreported category to already public designations under a presidency that has heavily invested political and material capital in AI and data center proliferation.

Among the documents in the tranche obtained by WIRED is a New York Intelligence and Counterterrorism Bureau report that warns of widespread upheaval in response to AI adoption. Of particular note is a novel term for what the bureau purports to be an emerging extremism threat.

"The chaotic atmosphere that may result from emergent AI technology in the next five years may fuel large-scale protests that devolve into civil unrest and anti-tech violent extremist activity, especially in large urban areas such as New York City," the report reads. The term "anti-tech violent extremism" does not appear in any publicly available DHS or FBI domestic extremism reports or guides and represents a novel grouping of a wide range of ideologies under a single extremist category.

[...] Created in the wake of 9/11, 80 fusion centers now pockmark the country and serve as go-betweens for federal intelligence agencies and state and local law enforcement. In addition to concerns about portions of the American populace disturbed by the rapid proliferation of AI, these centers are also gathering and circulating "intelligence" about alleged threats to data centers.

A Western Pennsylvania fusion center, for example, claimed that "adversarial actors, including state-sponsored entities, criminal groups, and extremists, such as homegrown violent extremists or environmental extremists, may target US data centers" and that "these actors could also exploit the strategic importance of data centers to the US economy, using them for activities like cryptocurrency mining or leveraging third-party entities, such as front companies, to gain access to US data and infrastructure."


Original Submission

posted by hubie on Tuesday June 02, @08:24AM   Printer-friendly
from the spray-on-stealth-in-a-can dept.

Stealth on a budget:

A Turkish researcher just shared details of a sprayable radar absorbent material (RAM) designed to be applied to drones and other small uncrewed aerial vehicles (UAVs). According to the Defense Blog, Yunus İnce and their small defense research firm have been working on the material, called Kürşat 3.0, for more than seven years. İnce shared test footage of the product with the publication, showing the claimed 43dB signal attenuation. This is a greater reduction compared to broadband coatings tested by academic researchers in standardized test conditions. However, the company's claims must still be validated by a third-party expert to prove that it actually works and makes it harder to detect UAVs.

Drone warfare has exploded in recent years, with the ongoing Russian invasion of Ukraine, which started in 2022, showing how these cheap and tiny gadgets could effectively stop the advance of a multi-million-dollar tank column. Both sides of the conflict have wholeheartedly adopted UAVs as part of their military tactics, and militaries around the globe are devising cost-effective ways of taking down this new threat, like using lasers, microwaves, or good ol’ kinetic energy. Drone operators and manufacturers are not taking these threats lightly, with companies working to make them harder to detect via radar.

[...] A UAV’s advantage is its small size and low cost, making it cost-inefficient to produce specialized radar-deflecting designs. However, the Kürşat 3.0 could be a game-changer if other scientists can confirm that it really works. Many UAVs are so small that it’s difficult to detect them at longer distances — covering them with this “spray-on” RAM would only make it harder for defenders to detect and lock on to them using traditional radar sets.

This coating is not the be-all and end-all of drone stealth, though. That’s because most drones are built for efficiency and speed, not stealth, so they lack the required geometry to deflect radar signals. This is especially true for quadcopters, where the four exposed blades would easily reflect signals back to the radar transceiver. But because they’re often already tiny, covering them in Kürşat 3.0 spray would increase their survivability and make it harder for defenders to target them on their radar scopes.


Original Submission

posted by janrinok on Tuesday June 02, @06:29AM   Printer-friendly

kolie has been hard at work producing a logical line for line copy of rehash (written in perl) in Python - including warts where they affect the functioning of the software. This will ensure that the software remains maintainable into the future, and gives kolie a chance to fix some previously unknown bugs.

PyHash is currently running on dev.soylentnews.org. Please take a look and report any problems / observations / comments in kolie's journal. This software is still under development as kolie explains. If you cannot log in with your usual username/password you might have to create a new account on dev.

posted by hubie on Tuesday June 02, @03:39AM   Printer-friendly

The flaw affects the boundary between the Linux CIFS client and cifs-utils, allowing local root access on some systems.

A newly disclosed Linux local privilege escalation vulnerability, CIFSwitch, allows an unprivileged local user to gain root access on certain systems via the Linux kernel's CIFS client and the cifs-utils userspace helper. CIFS, also known as SMB, is a network file-sharing protocol commonly used to access Windows file shares from Linux and other platforms.

Security researcher Asim Manizada disclosed the issue, describing it as a non-universal Linux local root vulnerability since exploitability depends on specific distribution configurations. A public proof-of-concept exploit is available, increasing the urgency for patching and mitigation on affected systems.

CIFSwitch exists at the interface between the kernel CIFS client and cifs.upcall, the cifs-utils helper for Kerberos-authenticated CIFS/SMB mounts. While CIFS is commonly associated with Windows file shares, Linux systems can also mount SMB shares using the kernel CIFS client.

The vulnerability arises from how CIFS uses Linux keyrings. Normally, the kernel requests a cifs.spnego key, and the system's request-key configuration launches cifs.upcall as root to handle Kerberos/SPNEGO authentication.

According to the disclosure, the vulnerability allows an unprivileged userspace process to request a forged cifs.spnego key description. The kernel failed to properly reject descriptions not originating from kernel CIFS, and the default request-key rule could still launch cifs.upcall as root.

The userspace helper then parsed attacker-controlled fields, including pid, uid, creduid, and upcall_target, as if they were generated by the kernel. By setting upcall_target=app, the helper could switch into a namespace controlled by the attacker.

The attack is particularly dangerous because account lookup through NSS can occur before the final privilege drop. In this state, a namespace-local NSS configuration and module can be loaded by the root helper, enabling attacker-controlled code to run with root privileges.

[...] The good news is that CIFSwitch does not affect every Linux system by default. The researcher lists several required conditions: a vulnerable kernel, an affected cifs-utils version, the default cifs.spnego request-key rule, enabled unprivileged user and mount namespaces, and SELinux or AppArmor policies that do not block the attack chain.

The tested stock-exploitable systems listed in the disclosure include Linux Mint 21.3 and 22.3, CentOS Stream 9, Rocky Linux 9, Kali Linux 2021.4 through 2026.1 headless, AlmaLinux 9.7 and Azure cloud image, SLES 15 SP7, SLES SAP 15 SP7, and SLES SAP 16 with SELinux permissive.

Other systems are listed as exploitable under the default policy only if cifs-utils is installed manually. That group includes Ubuntu 18.04 LTS, 20.04 LTS, and 22.04 LTS, Debian 11 "Bullseye", 12 "Bookworm", and 13 "Trixie", Pop!_OS 22.04 and 24.04, openSUSE Leap 15.6, Rocky Linux 8 GenericCloud, Oracle Linux 8 and 9 KVM images, and Amazon Linux 2023 with SELinux permissive.


Original Submission

posted by jelizondo on Monday June 01, @10:54PM   Printer-friendly

https://www.tomshardware.com/tech-industry/jensen-huang-urges-super-micro-to-tighten-compliance

Huang told reporters at Songshan Airport that Nvidia insists its partners follow U.S. trade rules. "We insist our partners are compliant. We hope that they will enhance and improve their regulation compliance and prevent that from happening in the future," Huang said in an address to the media.

The Taiwan case is separate from, but closely related to, the much larger U.S. federal prosecution unsealed in March. That indictment charged Supermicro co-founder Yih-Shyan "Wally" Liaw and two others with conspiring to smuggle approximately $2.5 billion worth of Nvidia-equipped servers to China through shell companies in Southeast Asia. Liaw has pleaded not guilty, and Supermicro has said it’s not named as a defendant and is cooperating with the investigation.

In the same press scrum at Songshan Airport, Huang confirmed that China is included in the $200 billion addressable market he projected for Nvidia's upcoming Vera CPU during the company's earnings call on May 20th. "H200 has been licensed to ship to China. It would be terrific to be able to serve that market. The Chinese market is very important. It's very large, of course," Huang told reporters, according to Reuters.

Despite the licensing approval, not a single H200 has been delivered to a Chinese customer. While roughly 10 Chinese firms have been cleared to purchase the chip, shipments haven’t started, and President Trump's talks with Chinese President Xi Jinping in Beijing earlier this month produced no breakthrough on Nvidia chip sales.

Huang is in Taipei ahead of Nvidia's GTC Taipei event and his Computex keynote on June 1st, where he’s expected to explore the Vera Rubin platform's software stack. He described the platform as "the largest product launch, probably in the history of Taiwan," noting that each Vera Rubin NVL72 system contains nearly 2 million parts and involves around 150 Taiwanese ecosystem partners.


Original Submission

posted by jelizondo on Monday June 01, @05:12PM   Printer-friendly

https://www.theregister.com/science/2026/05/26/bezos-rocket-fell-short-after-cryogenic-leak-cut-engine-thrust/5246481

The US Federal Aviation Administration (FAA) and Blue Origin have revealed what went wrong on the third flight of New Glenn and it looks like a cryogenic leak is our culprit. 

According to Blue Origin: "Prior to our second GS2 burn, we experienced an off-nominal thermal condition, and, as a result, one of the BE-3U engines didn't achieve full thrust to reach our target orbit."

The FAA's explanation was a little more detailed: "The final mishap report identified the direct cause of the mishap as a cryogenic leak that froze a hydraulic line and led to a thrust anomaly during the second stage engine burn."

The April 19 launch of the NG-3 mission started well. The first stage firing went well, and the booster made a successful landing on Blue Origin's floating landing platform, Jacklyn. However, during the second burn of the second stage (dubbed GS2), things went awry. One of the two BE-3U engines failed to achieve full thrust, leaving the payload, AST SpaceMobile's BlueBird 7 satellite, in a lower-than-planned orbit. AST SpaceMobile later said the spacecraft would be deorbited.

All told, nine corrective actions were identified to prevent a repeat of the problem, and Blue Origin says all have been implemented ahead of the next New Glenn launch. The FAA said it will verify those changes before the rocket flies again.

It is, however, not immediately clear what payload the company will be launching. Blue Origin CEO Dave Limp showed off a video of the next vehicle being lifted onto the Transporter Erector, but gave no further details.

Like SpaceX, which will be launching the next batch of AST SpaceMobile BlueBird satellites, Blue Origin has several targets to hit. It is expected to launch an uncrewed lunar lander this year and deliver NASA's off-again-on-again VIPER mission to the lunar surface in late 2027.

NASA boss Jared Isaacman said in recent weeks that SpaceX and Blue Origin had told the agency both would have vehicles "to meet our needs" for a late 2027 rendezvous, docking, and capability test tied to Artemis III.

Approval from the FAA removes one distraction for the company. However, time is running out for Blue Origin to accomplish its goals before the end of next year.


Original Submission