Stories
Slash Boxes
Comments

SoylentNews is people

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:433

posted by janrinok on Saturday May 23, @10:08PM   Printer-friendly

Coding After AI - Are Humans Still Good Enough for Software Development?:

The last weeks were pretty crazy when it comes to security issues that affect basically everyone. Applications, virtualization stacks like QEMU, CI/CD platforms, operating systems, kernels and even components that were considered stable and trusted for years suddenly became part of critical discussions again.

What makes this wave of vulnerabilities different is not only the technical impact itself. It is the way many of these issues were discovered. Bugs that survived years of reviews, audits, production usage and thousands of developers looking at the same code are now being uncovered within days. In many cases the common factor is artificial intelligence assisted research.

It was honestly not easy to find a proper title for this post because all of them somehow describe the current situation perfectly.

  • The Age of AI Vulnerability Discovery Has Begun
  • Decades of Trust, Minutes to Break: AI and Modern CVE Discovery
  • The End of Human Scale Security Engineering
  • Fragnesia, DirtyFrag and Friends: The AI Bug Hunting Explosion

But in the end I ended up with a question instead:

  • Programming After AI: Are Humans Still Good Enough?

All of these headlines point to the same uncomfortable reality. Modern software has reached a level of complexity where humans alone may no longer be able to fully understand every corner case, race condition and unexpected interaction hidden deep inside millions of lines of code.

The scary part is that most of these vulnerabilities were not introduced yesterday. Some of them existed silently for years. They lived through releases, rewrites, migrations and security reviews without being noticed. Then suddenly AI assisted analysis enters the picture and starts finding them one after another.

This raises a serious question for the future of software engineering and security research. Are we slowly reaching the point where humans can still build systems, but no longer fully secure them without machine assistance? And if AI becomes better at finding vulnerabilities than humans are at preventing them, what does that mean for the future of secure software development?

For decades software development was primarily driven by humans alone. People learned programming languages, understood algorithms, studied operating systems and network communication, and eventually started building their own applications, libraries and platforms. Every piece of software reflected the knowledge, experience and mindset of the person who created it.

Becoming a skilled developer was never something that happened within weeks or months. It often took years to truly understand how software works internally and how different systems interact with each other. Programming was never only about writing code itself. Developers also had to understand operating systems, APIs, protocols, databases, virtualization, authentication, networking, hardware behavior and many other surrounding components. A good engineer did not only know how to write functions, but also understood the complete environment in which those functions were running.

The quality of code always depended heavily on the capabilities of its author. An experienced developer could write elegant, performant and maintainable code that survived for years with only minimal adjustments. Others produced software that worked, but consumed unnecessary resources, scaled poorly or became difficult to maintain over time. Performance optimizations, memory management and architecture decisions were often directly tied to the knowledge level of the developer.

At the same time humans also introduced mistakes into their own code. Sometimes these mistakes were small and harmless, resulting in minor bugs or unexpected behavior. In other cases they created severe security vulnerabilities that remained hidden for years. A missing boundary check, incorrect assumptions about concurrency, unsafe memory handling or misunderstood access controls could eventually become the foundation for critical security issues.

Software engineering therefore evolved around the principle that reviews would minimize those problems. Developers reviewed each others code, tested changes, discussed implementations and tried to identify weaknesses before software reached production. This process became one of the most important foundations of modern software development. Pull requests, peer reviews, testing pipelines and quality gates were all designed around the assumption that humans are capable of validating the work of other humans.

However, this approach always had natural limitations. A developer who wrote a specific function or subsystem usually understood it very well. The original author remembered why certain decisions were made, which workarounds existed and where edge cases had already been considered. The longer someone worked on the same project, the more the code became an extension of their own thinking.

For external contributors or newcomers the situation was often completely different. Even understanding relatively small functions could already become difficult. Variable names reflected internal assumptions, undocumented dependencies existed between modules and logic paths evolved over years of changes. Code that looked simple at first glance could hide complex interactions that were only understood by the original maintainers.

As projects grew larger this problem scaled dramatically. Modern systems are rarely isolated applications anymore. Today software interacts with APIs, databases, virtualization layers, authentication systems, container runtimes, orchestration platforms, message brokers and external services all at the same time. A single logical mistake in one component can create unexpected side effects across entirely different systems.

This increasing complexity also changed the nature of security issues. Early software bugs were often relatively direct and easy to identify. Modern vulnerabilities frequently emerge from combinations of conditions, timing issues, race conditions or interactions between components that were never expected to communicate in a dangerous way. The famous phrase that software is eating the world also means that software complexity is becoming impossible for single individuals to fully understand.

Another important factor was human exhaustion. Reviewing thousands of lines of code every day is mentally demanding. Developers become tired, deadlines create pressure and companies prioritize feature delivery over perfect engineering. Even highly skilled reviewers can miss critical issues simply because modern code bases exceed human attention spans. Many vulnerabilities that are discovered today are not necessarily hidden because developers were careless, but because the amount of logic and possible execution paths became too large for humans to reason about consistently. So, at this point it doesn't wonder anyone that out of sudden many security issues just came up by AI like Dirtyfrag, Fragnesia, pTrace or QEMU issues and many other ones. The bad thing? Even some of those fixes like Fragnesia were inconsitently fixed where just a bit later some new PoCs (e.g., Fragnesia 2 by v12sec ) raised up.

There was also a strong culture of trust in software engineering. Stable code that survived years in production was often considered safe by default (which is nowadays definately a wrong assumption). Projects with many contributors and large communities created the impression that somebody would eventually notice severe issues. But recent discoveries show that this assumption was overly optimistic. Vulnerabilities can survive years of development, thousands of commits and countless reviews without being detected. All for fair reasons!

At the same time humans also brought creativity and intuition into software development. Developers understood business requirements, made architectural tradeoffs and adapted systems to real world needs. Human engineers were not only writing instructions for computers, they were building abstractions and ecosystems around constantly changing requirements. This creative aspect became one of the greatest strengths of human driven software engineering.

The problem is that creativity alone does not guarantee correctness. As systems became larger and more interconnected, the gap between what humans can build and what humans can completely understand started growing rapidly. For years the industry accepted this as a normal reality. Bugs were expected, patches became part of daily operations and security updates evolved into a permanent lifecycle rather than exceptional events.

Looking back, the past era of software engineering was defined by an important balance. Humans created the systems, humans reviewed the systems and humans tried to secure the systems. The entire process depended on collective experience, collaboration and trust in human reasoning. The question today is whether this model can still scale in a world where software complexity grows faster than human comprehension itself.

Can Humans Still Scale in Software Development vs AI?

The question today is whether the traditional model of software engineering can still scale in a world where software complexity grows faster than human comprehension itself. Personally, I believe we are currently witnessing one of the biggest shifts the software industry has ever experienced. And just a few years ago, many of us completely underestimated it.

When the first public AI coding tools appeared, the overall reaction from developers was often somewhere between curiosity and amusement. The generated code was full of mistakes, inefficient logic, security issues and sometimes complete nonsense. AI generated applications looked impressive at first glance, but once developers actually reviewed the code, the weaknesses became obvious almost immediately.

Many engineers and developers, including myself, looked at those early results and thought the same thing: there is no way this replaces experienced developers. The gap between human engineers and machine generated code simply looked too large. AI lacked architectural understanding, context awareness, long term reasoning and deep technical intuition. At least that was our assumption at the time.

The reality is that our imagination was simply too limited.

What many people failed to realize was the speed at which these systems improve. Humans often think in relatively linear progressions. AI development over the last years was anything but linear. Models improved simultaneously across nearly every domain imaginable. Text generation improved. Image generation improved. Voice synthesis improved. Video generation improved. Reasoning improved. Context understanding improved.

One of the most famous examples can probably be seen in the evolution of AI generated videos around the well known "Will Smith eating spaghetti" example. Early generations looked surreal and broken. Hands melted into objects, faces deformed and movements made no physical sense. People laughed at it because it looked absurd and obviously artificial.

But every new generation improved dramatically. What looked impossible one year suddenly became convincing the next year. By 2025 the generated videos already became surprisingly realistic. By 2026 they started looking almost indistinguishable from reality itself. The progress between iterations was honestly difficult to fully comprehend in real time because humans naturally compare against the present rather than against where things started.

The exact same development happened in software engineering.

Early AI generated code was often unusable in production environments. Today models are capable of generating complete applications, APIs, infrastructure definitions, database schemas, Kubernetes manifests, CI and CD pipelines and even complex integrations between distributed systems. Modern models are no longer only generating isolated functions. They are increasingly capable of understanding relationships between entire systems.

AI does not get tired while reviewing code. It does not lose focus after reviewing the five hundredth pull request of the week. It does not forget edge cases because of stress, deadlines or lack of sleep. It can continuously analyze enormous code bases, compare implementation patterns, evaluate dependencies and search for dangerous combinations of conditions without interruption.

This becomes especially visible in security research. The recent wave of vulnerabilities discovered in operating systems, kernels, virtualization stacks and infrastructure software demonstrates something important. Many of those vulnerabilities existed for years, even for systems that were known for their higher security approaches like FreeBSD and OpenBSD (so it isn't limited to Linux as many ones will try to tell you). Some survived countless reviews by highly experienced engineers and security researchers. They were hidden inside massive code bases that simply exceeded human capacity for complete reasoning, just as mentioned before.

AI changes this dynamic completely.

A machine can traverse execution paths endlessly. It can compare thousands of possible states, analyze race conditions and evaluate interactions between components at a scale that humans realistically cannot maintain consistently anymore. This does not necessarily mean AI "understands" software the same way humans do. But understanding is not always required to identify dangerous behavior patterns.

Another important difference is operational scale. Humans work in limited timeframes. Engineers need breaks, sleep and context switching. AI systems can operate continuously twenty four hours a day and seven days a week. They can scan repositories, generate patches, write tests, validate assumptions and perform repeated analysis without exhaustion.

Of course this also creates dangerous scenarios. Leaving autonomous systems completely unrestricted can absolutely end badly. AI can generate insecure code just as quickly as secure code. It can automate exploitation, accelerate malware development and massively reduce the entry barrier for offensive security activities. The same technology that helps defenders can also empower attackers.

This is why boundaries and controlled environments become increasingly important. AI works best when humans define goals, limitations and architectural direction. Rail guards matter. Context matters. Oversight matters. At least for now.

But even within those boundaries the productivity difference is becoming impossible to ignore. A single engineer assisted by advanced AI systems can now achieve output levels that previously required entire teams. Tasks that once consumed days can now be completed within hours. Documentation, refactoring, test generation, code reviews and vulnerability analysis are increasingly becoming partially automated workflows.

Good Developers Will Become Better With AI, Bad Ones...

One thing has become very clear over the last years. AI will not affect every developer equally. Good engineers who already understand systems deeply will become dramatically more effective with AI assistance. Bad developers on the other hand will most likely struggle harder and harder to justify their role in the future.

This may sound harsh at first, but software engineering was never only about writing syntax into an editor. The real value of experienced engineers always came from understanding architecture, dependencies, scalability, security, performance and operational behavior of systems in production environments. Those skills do not disappear with AI. In fact, they become even more important.

A strong engineer can already take an idea, split it into logical components, define boundaries, identify risks and understand how systems should communicate with each other. When AI enters this workflow, the same engineer suddenly gains the ability to execute those ideas at an entirely different scale and speed.

Tasks that previously consumed entire weeks can now be delegated almost instantly. Documentation can be generated automatically. Refactoring can happen across large repositories within minutes. APIs can be scaffolded quickly. Infrastructure definitions can be created, adjusted and validated continuously. Tests can be generated in parallel while another AI agent analyzes security issues and another one reviews dependencies or optimizes performance bottlenecks.

The most important shift is that good engineers no longer operate alone. They effectively start managing a team of AI agents that can work continuously and simultaneously across multiple scopes, technologies and programming languages.

A single experienced developer can now orchestrate workflows that previously required multiple junior developers, senior engineers, QA teams and documentation writers. The engineer no longer spends the majority of time manually implementing every single detail. Instead, the role becomes more strategic and supervisory.

This transformation also does not only affect traditional software development itself. It affects nearly every technical role across the entire IT industry. DevOps engineering, infrastructure automation, CI and CD development, system administration, cloud operations, platform engineering, SDN based networking and even offensive and defensive security research are all being reshaped by AI accelerated workflows.

A modern engineer can now generate infrastructure deployments, validate Kubernetes configurations, optimize network policies, analyze firewall rules, simulate distributed environments and audit security relevant code paths simultaneously with AI assistance. Even highly specialized areas that previously required years of focused experience are increasingly becoming partially automated through intelligent tooling.

This is also one of the major reasons why the security industry currently experiences an almost overwhelming amount of new discoveries every single day. AI systems continuously scan enormous code bases, compare logic paths, analyze race conditions and identify unexpected interactions between components. Vulnerabilities that remained hidden for years are suddenly discovered one after another because machines are capable of reviewing software at a scale humans simply cannot maintain consistently anymore.

The huge increase in newly discovered vulnerabilities does not necessarily mean software suddenly became worse overnight. In many cases those issues already existed for years. What changed is the speed and depth at which AI assisted research can now analyze systems.

This is where the huge role shift begins.

In the future, fundamental knowledge about system architecture will likely become one of the most valuable skills in the industry. Understanding how components interact, how distributed systems behave under load, how APIs should be designed, how security boundaries are enforced and how data flows through complex environments becomes far more important than simply remembering syntax details for a specific language.

Prompting itself also becomes a skill. Not because prompts magically replace engineering knowledge, but because clear instructions require clear thinking. A developer who cannot structure problems properly will also struggle to guide AI systems effectively. Good prompting is often nothing more than good engineering communication translated into machine readable instructions.

Talking about "translated into machine readable instructions", this is also a part that becomes more and more interesting as AI is not just a single scope and adapts to many other things. For this at least, there were also ideas to improve the results by different approaches. One of them is JSON prompting, where prompts are no longer written purely as natural language but instead structured into clearly defined machine-readable fields and instructions. Instead of vaguely describing an outcome, JSON prompting allows developers and researchers to define context, tasks, constraints, examples, output formats, priorities, and even behavioral expectations in a deterministic structure that AI systems can process far more consistently. The result is often significantly more predictable, reusable, and precise outputs — something that becomes increasingly important as AI moves deeper into software engineering, infrastructure automation, security research, CI/CD orchestration, video generation, and large-scale operational workflows.

At the same time boundaries become critical. AI systems can accidentally leak sensitive information, expose credentials, generate insecure implementations or interact with systems in unintended ways if they are not controlled correctly. The engineer therefore becomes responsible for defining strict operational guard rails, permissions and limitations around those systems.

This means future engineers will increasingly act like architects, supervisors and coordinators of autonomous workflows rather than pure code producers. The actual implementation work gets delegated to AI agents while humans focus on validation, priorities, architecture decisions and business requirements.

Ironically, this also changes the traditional mentoring structure inside engineering teams. Historically large parts of senior engineering time were consumed by onboarding juniors, reviewing pull requests, explaining system behavior and correcting implementation mistakes. AI systems now increasingly absorb many of those repetitive tasks.

Instead of mentoring several junior developers individually, a senior engineer might supervise multiple AI agents that already operate at relatively high implementation quality. Reviews still exist, but they move toward higher abstraction levels. The engineer checks whether the overall direction is correct rather than manually validating every single line of code.

This does not necessarily mean junior engineers disappear completely, but the expectations for entry level positions will likely change dramatically. Companies may need fewer people for repetitive implementation work because AI can already automate large parts of it. The remaining human roles become more focused on reasoning, architecture and oversight.

And this creates a dangerous situation for weaker developers.

People who mainly relied on copying code snippets without deeply understanding systems may suddenly find themselves competing directly against machines that can do exactly that, but faster and at significantly larger scale. Developers who never evolved beyond basic implementation tasks could face increasing pressure because AI systems continuously improve in those areas.

A highly skilled developer with strong architectural understanding and operational experience can suddenly execute ideas at a speed that was previously impossible for individuals. One person can coordinate backend services, infrastructure automation, security analysis, frontend development, testing and deployment workflows simultaneously with AI assistance.

This creates an enormous productivity gap between engineers who adapt and engineers who do not.

The future therefore may not necessarily belong to developers who write the most code manually. It will probably belong to developers who best understand systems, define correct boundaries, communicate intent clearly and successfully orchestrate intelligent machines toward reliable outcomes.

In many ways software engineering is shifting from manual implementation toward intelligent delegation.

And the engineers who learn how to control that delegation effectively will likely become more powerful than entire development teams from only a few years ago.

Is the Future AI Coding?

Personally, I increasingly believe that the future of software development is moving toward AI driven engineering. Not because humans suddenly became unintelligent, but because the surrounding complexity of modern systems has reached a level that humans alone can no longer fully process consistently.

Modern infrastructure is no longer a single application running on a single server. Today software interacts with distributed APIs, virtualization layers, Kubernetes clusters, CI/CD pipelines, cloud environments, authentication systems, network overlays, message queues, storage backends and external third party services simultaneously. Every additional layer introduces new states, new dependencies and entirely new possibilities for unexpected interactions.

Humans are simply limited in how many execution paths, dependencies and edge cases they can reason about at the same time. Even highly experienced engineers eventually overlook conditions, assumptions or side effects because the amount of surrounding logic becomes too large. This is exactly why so many vulnerabilities survived for years inside trusted software stacks before AI assisted analysis started exposing them one after another.

And this is where AI changes the entire landscape.

The real power does not only come from a single AI model generating code. The real shift happens once multiple AI agents start working together. One agent can generate implementations, another reviews the code, another validates architecture decisions, another creates tests, while another continuously searches for security issues, race conditions or unexpected behavior patterns. Suddenly workflows become possible that humans alone could never realistically maintain at that scale.

The interesting part is that this no longer feels theoretical. It is already happening. AI systems can continuously create, review, validate and test thousands of different possibilities without exhaustion. Machines do not lose focus after reviewing the five hundredth pull request. They do not forget dependencies because of stress, deadlines or lack of sleep. They can continuously compare patterns across enormous repositories and identify combinations that would never realistically become visible to individual engineers.

What becomes increasingly obvious is that software development slowly shifts away from manual implementation toward orchestration. The engineer of the future may no longer write every single line of code directly, but instead coordinate intelligent systems that perform the majority of implementation and validation automatically.

But maybe this transformation is only one part of a much larger change that is currently beginning.

Languages and Human Communication

One of the most important areas in this entire development is natural language processing itself. In many ways it already affects daily life far outside traditional software engineering.

Human communication has never been perfectly deterministic. You can see this in normal conversations with friends, family members, partners or co-workers every single day. Something that sounds completely obvious and clear to one person might be interpreted entirely differently by somebody else. Humans constantly misunderstand context, intent, priorities and hidden assumptions.

The same principle also applies to large language models.

Prompts often appear clear to the person writing them while the model interprets them differently internally. This is exactly why prompt engineering became such a major topic. Developers try to improve outputs through better structured prompts, clearer constraints, examples, negative instruction lists and increasingly deterministic formatting approaches such as JSON prompting.

But in reality this is still relatively inefficient.

Natural language itself was built for humans, not for machines. Human language evolved around abstraction, emotions, ambiguity and incomplete context. Machines however work best with precision, structure and deterministic interpretation. This creates a strange middle layer where humans continuously try to translate thoughts into machine understandable instructions.

And this raises another interesting question for the future.

What if programming languages themselves eventually change completely?

Current programming languages were heavily designed around human readability and human maintainability. Languages evolved to make software easier for humans to write, review and debug. Abstractions, syntax simplifications and high level frameworks all primarily exist because humans need understandable systems.

But what happens once humans are no longer the primary implementers?

If software generation becomes largely autonomous, readability for humans may slowly lose importance. Machines do not require elegant syntax, beautiful abstractions or easy to understand naming conventions. AI systems could eventually operate on highly optimized intermediate representations or entirely new language structures that are designed purely for machine efficiency, optimization and performance rather than human comprehension.

Ironically, this would almost feel like a return to earlier eras of computing. Many engineers still remember assembly language development where humans worked much closer to machine instructions directly. Over time higher level languages abstracted away complexity because humans needed better maintainability and scalability. But if AI becomes the primary actor behind software generation, the industry could eventually move back toward representations that humans barely understand anymore.

This creates a difficult contradiction.

On one side fully machine optimized languages could massively improve performance, optimization and automated reasoning. On the other side humans would increasingly lose direct understanding of the software they still depend on. Validation itself becomes difficult once humans can no longer realistically review the generated logic manually.

And this may become one of the most important challenges of the next generation of software engineering: how do humans maintain trust in systems they can no longer fully understand themselves?

The Transition Phase Already Started

Personally, I am pretty sure that we are already inside the transition phase today.

Many engineers are no longer operating in a purely manual development workflow. Large parts of the industry already work in an AI assisted mode, whether openly acknowledged or not. Developers use AI for implementation, refactoring, documentation, infrastructure generation, debugging, testing and security analysis every single day. The productivity improvements are already too large to ignore.

At the same time, fully autonomous AI driven software development still feels slightly too early right now. Even though many so called "vibe coded" projects sometimes make that statement look questionable, they also reveal the current limitations very clearly. A lot of those projects look impressive initially, but long term maintainability, architectural consistency and operational reliability often still become problematic over time.

However, I do not think this limitation will remain for very long.

The next major iteration will most likely focus heavily on maintainability, autonomous validation and long term reasoning. Once AI systems become better at continuously managing larger code bases across extended periods of time, the remaining gap between AI assisted and fully AI driven development could shrink extremely quickly.

And after that, the next iteration may become even more disruptive: a complete language shift itself.

Programming languages may eventually evolve away from human readability toward machine optimized representations. Performance could improve dramatically, automated reasoning could become more efficient and systems could operate at scales that humans would no longer realistically maintain manually anymore.

The tradeoff however may be severe. We could gain incredible efficiency while simultaneously losing direct human readability and understanding. And maybe that is ultimately the real future of software engineering: humans defining intent, boundaries and goals while autonomous systems increasingly handle the actual implementation, communication and optimization layers entirely on their own.

Whether we fully like that future or not, it already feels much closer than most people currently realize... And it might become very scary at all!


Original Submission

posted by janrinok on Saturday May 23, @05:20PM   Printer-friendly

CISA Leaves Open Door for Hackers

https://arstechnica.com/information-technology/2026/05/in-stunning-display-of-stupid-secret-cisa-credentials-found-in-public-github-repo/

Security researcher Brian Krebs brings us the news that America’s Cybersecurity & Infrastructure Agency (CISA) has had a large store of plaintext passwords, SSH private keys, tokens, and “other sensitive CISA assets” exposed in a public GitHub repo since at least November 2025.

The now-offline public repo—named, somewhat aspirationally, “Private-CISA”—was brought to Krebs’ attention by GitGuardian’s Guillaume Valadon, who was alerted to the repo’s presence by GitGuardian’s public code scans. Krebs says that Valadon approached him after receiving no responses from the Private-CISA repo’s owner.

In an email to Krebs, Valadon claimed that the repo’s commit logs show that GitHub’s default protections against committing secrets—protections designed to protect unwitting or unskilled developers against exactly this kind of stupidness—had been disabled by the repo’s administrator.

Testing by Seralys founder Philippe Caturegli showed that this was not a joke or hoax and that he was able to use the credentials in the Private-CISA repo to gain access to multiple Amazon Web Services GovCloud accounts “at a high privilege level.”

Krebs notes that the repo appeared to be managed by Virginia-based Nightwing, a CISA contractor. Nightwing has so far not commented publicly, instead referring questions back to CISA.

This isn’t the first time CISA has screwed up—in fact, it’s not even the first time this year. In January, polygraph-failing acting CISA Director Madhu Gottumukkala uploaded sensitive government documents to ChatGPT after demanding and receiving an exemption to the agency policy that prohibited ChatGPT’s use by CISA personnel. Gottumukkala was removed from his role in February.

America's Top Cyber-Defense Agency Left A GitHub Repo Open With With Passwords, Keys, Tokens – And Incredibly Obvious Filenames

https://www.theregister.com/security/2026/05/19/americas-top-cyber-defense-agency-left-a-github-repo-open-with-with-passwords-keys-tokens-and-incredibly-obvious-filenames/5242915

The US Cybersecurity and Infrastructure Security Agency (CISA) left open a GitHub repository named "Private-CISA" containing plain-text passwords, private keys, tokens, and secrets – with obvious file names like "external-secret-repo-creds.yaml" and "AWS-Workspace-Firefox-Passwords.csv" – for six months.

GitGuardian researcher Guillaume Valadon, fresh off a recent talk on Kubernetes secret leaks, found the public repository on May 14, and told The Register that he "quickly understood that the leak was bad and that time was running out. A national agency having 844 MB of production infrastructure material in a public GitHub repository for six months is as serious as a secrets leak gets." 

Valadon, who previously spent nine years at France's CISA equivalent, ANSSI, told us the leak included tokens for CISA's internal JFrog Artifactory, Azure registry keys, AWS credentials, Kubernetes manifests, ArgoCD application files, Terraform infrastructure code, GitHub personal access tokens, and Entra ID SAML certificates.

GitGuardian reported the leaky repository to CISA on May 14, and the agency took it down a day later. 

A CISA spokesperson told The Register that it was aware of the report and is investigating. "Currently, there is no indication that any sensitive data was compromised as a result of this incident."

It's not a good look for the nation's infosec agency, which hasn't had a permanent boss since Trump took office,  is facing hundreds of millions of dollars in budgets cuts on top of deep cuts to staff and funding last year, and has suffered its share of embarrassing security snafus in the interim.

In a Tuesday blog, Valadon said he initially thought the repo "was a hoax, given how suspicious the directory names (Backup-April-2026/, All Backups/, LZ-Artifactory/, Kubernetes-Important-Yaml-Files/, ENTRA ID - SAML Certificates/ ...), file names (external-secret-repo-creds.yaml, CAWS GitHub Token.txt, Important AWS Tokens.txt, AWS-Workspace-Firefox-Passwords.csv, Kube-Config.txt ...), and their contents (private keys, personal and professional GitHub tokens, AWS secrets, ...) seemed too good to be true," Valadon wrote.

It wasn't a hoax  – "The Cybersecurity and Infrastructure Security Agency is aware of the reported exposure and is continuing to investigate the situation,"  but it was a "catalogue of unsafe practices," he added, containing passwords stored in plain text, backups committed to Git, and an "explicit" how-to guide for disabling GitHub's secret scanning.

After initially reporting the leak through the CERT/CC portal, and only receiving an auto-acknowledgement as of the morning of May 15  – a Friday  – Valadon alerted security journalist Brian Krebs about the publicly exposed secrets, which seemed to speed up CISA's processes. By 6 pm EST that night, the feds took down the repository. 

Valadon told The Reg he gives CISA credit for quickly deleting the repository. "Most of our responsible disclosures take much longer, and many are never fixed," he said. "Managing to take the repository offline in a day is impressive work."

He doesn't know if any other parties with less altruistic intentions found the secrets first, although the fact that the repository was never forked (based on public GitHub events) would seem to indicate that it wasn't widely circulated on the dark web. 

"The only ones that can answer definitively is GitHub," Valadon said. GitHub did not immediately respond to The Register's inquiry.

GitGuardian isn't aware of any of the exposed credentials being abused by unauthorized individuals

"Each category of secret in the repository unlocks a specific attack path," Valadon said. "Stacked together, they cover the full range: from destructive attacks and ransomware extortion to quiet, long-term persistence inside CISA's build and deployment pipeline. That last scenario worried me the most, and it's why I escalated through every channel we had until the repository was taken offline."

Plus, the committer used both a CISA-issued contractor email and a personal Yahoo email across the same commits, and created the repository using a personal GitHub account. "That mixed-identity pattern is one of the hardest surfaces for security teams to cover, and it's where the worst leaks happen," Valadon said.®


Original Submission #1Original Submission #2

posted by hubie on Saturday May 23, @12:35PM   Printer-friendly

At 25, Kurt Gödel proved there can never be a mathematical "theory of everything." Columnist Natalie Wolchover explores the implications:

In 1931, by turning logic on itself, Kurt Gödel proved a pair of theorems that transformed the landscape of knowledge and truth. These "incompleteness theorems" established that no formal system of mathematics — no finite set of rules, or axioms, from which everything is supposed to follow — can ever be complete. There will always be true mathematical statements that don't logically follow from those axioms.

I spent the early weeks of the Covid pandemic learning how the 25-year-old Austrian logician and mathematician did such a thing, and then writing a rundown of his proof in fewer than 2,000 words. (My wife, when I reminded her of this period: "Oh yeah, that time you almost went crazy?" A slight exaggeration.)

But even after grasping the steps of Gödel's proof, I was unsure what to make of his theorems, which are commonly understood as ruling out the possibility of a mathematical "theory of everything." It's not just me. In Gödel's Proof (a classic 1958 book that I heavily relied upon for my account), philosopher Ernest Nagel and mathematician James R. Newman wrote that the meaning of Gödel's theorems "has not been fully fathomed."

Maybe not, but six decades have passed since then. Where are we with these ideas today? Recently, I asked logicians, mathematicians, philosophers, and one physicist to discuss the meaning of incompleteness. They had plenty to say about the implications of Gödel's strange intellectual achievement and how it changed the course of humanity's unending search for truth.

[...]

It is easy to lose one's sense of wonder at the fact that such a blindingly obvious set of axioms — the Peano axioms for arithmetic (the set of rules about the natural numbers 0, 1, 2, 3 ... closely related to the system that Gödel used in his proof, such as the rule, "Every number has a successor") — is essentially incomplete and undecidable, meaning that all axiomatizable consistent extensions are incomplete and undecidable. Hold on to that wonder! The incompleteness theorems teach us that when it comes to our attempt to master the conceptual order, whether it be in mathematics or, for that matter, in any other domain, we will always fail — and indeed, in this case more than any other, we should be glad to have failed, for failure was clearly the more interesting, the more profound, outcome.


Original Submission

posted by hubie on Saturday May 23, @07:46AM   Printer-friendly

Got an older Kindle? Don't throw it away or rush to upgrade:

Amazon is ending support for older Kindle models on May 20, 2026, but you don't have to grieve your favorite Kindle just yet. With a few simple workarounds (and a couple more advanced ones if you're feeling ambitious), you can keep your Kindle going for years. And if you are ready to move on, there are some solid alternatives worth considering.

Note that you will still be able to read books on discontinued Kindle and Kindle Fire models. But beginning May 20, you won't be able to download new content from the Kindle Store.

[...] Technically, you don't own the books you buy from the Kindle store. What this means is that you're not allowed to transfer or modify those titles. In essence, you're purchasing a license to access the content, which can be revoked at any time. Not only does sideloading make it possible to get content on what Amazon deems an "obsolete" device, but it also lets you own the books you put on your device.

[...] Don't worry, you don't have to steal content from your favorite authors to keep using your Kindle. There are plenty of e-stores where you can buy DRM-free novels legally, such as ebook.com and Smashwords. If you want to try this process for free, public-domain repositories such as the one at Standard Ebooks are a great place to start.

[...] It's possible to untether your Kindle from its Amazon overlord by jailbreaking it, but keep in mind that doing so comes with risks. It's more technical than sideloading and can result in a bricked or otherwise broken Kindle if you run into an issue. Not that it matters for Kindles made before 2013, but it'll probably void your warranty as well. Jailbreaking is a bit of a process and doesn't work for every single Kindle, so make sure to double-check your system version and Kindle model for compatibility before you dive down this rabbit hole.

That said, a jailbroken Kindle can run open-source ebook viewers like KOreader. You'll still have to sideload books, but you'll get much greater control over your Kindle. The platform offers better PDF compatibility, wireless syncing with your Calibre library, and support for more ebook file types without the need to convert them as you do on a non-jailbroken Kindle.


Original Submission

posted by hubie on Saturday May 23, @03:04AM   Printer-friendly
from the corporate-welfare dept.

Data centers are skewing the power supply market, resulting in higher prices for everyone:

Monitoring Analytics, the federally mandated independent watchdog that keeps an eye on the critical PJM Interconnection that distributes power around the U.S., said in a new report [PDF] that a massive 75.5% increase in power costs in the largest region of the U.S. has been directly caused by data centers, and it also blamed the regional market operator for failing to keep up with the rising demand. The price increases have been steep; wholesale electricity prices went up from $77.78 per MWh in the first quarter of 2025 to $136.53 per MWh in the same period of this year.

“The price impacts on customers have been very large and are not reversible,” the watchdog said in the report. “The price impacts will be even larger in the near term unless the issues associated with data center load are addressed in a timely manner, prior to the next BRA (base residual auction), scheduled for June 2026.” Monitoring Analytics says that PJM Interconnection is trying to rewrite the rules for the capacity market and bake in data center demands into its forecasts. The watchdog is critical of this proposal as it will raise the prices for all electricity consumers, putting an unnecessary burden on households and small businesses.

There is a possible solution to this problem: make data centers and other major consumers negotiate directly with power producers instead of mixing that demand with the BRA. This auction is where capacity is sold some three years ahead of when it's needed, and including data center demand in the BRA will push prices up for everyone. In fact, the report says that without the AI infrastructure built out, the PJM Capacity Market would not have seen the high prices we're experiencing now. So, by making data centers negotiate directly with power producers, this will ensure that the expanded capacity is solely shouldered by these large consumers and help keep utility bills stable for everyone else.

However, this is not within the interests of PJM Interconnection. After all, by keeping massive data center loads baked into the general capacity forecast, the power auction would result in higher prices as demand moves up, but supply stays at relatively the same level. This higher cost, in turn, would then be passed on to transmission operators and local utilities, eventually making its way into the bill of the individual consumer.

The increasing backlash against data center development, particularly its impact on electricity prices, has caught the attention of the federal government. In March of this year, President Donald Trump gathered some of the country’s biggest AI hyperscalers in the White House and made them promise that they would “pay their own way” when it comes to AI infrastructure costs. This is, in principle, what Monitoring Analytics is pushing for: have tech companies pay for their own power — both the electricity they consume, and the infrastructure needed for it.

Unfortunately, the “ratepayer protection pledge” is nothing but a promise, and it cannot force institutions like PJM Interconnection to not pass on the burden of cost to the average American unless Congress passes a federal law that forces the Federal Energy Regulatory Commission (FERC) to prevent cost-shifting.


Original Submission

posted by hubie on Friday May 22, @10:15PM   Printer-friendly

New X-rays and CT scans showed small case with locking mechanism containing metal instruments:

Archaeologists used a combination of advanced CT scans and 3D digital reconstruction to identify one of the Pompeii victims who died in 79 CE during the eruption of Mount Vesuvius as most likely having been a Roman doctor, according to an announcement by the Pompeii Archaeological Park.

As previously reported, the eruption of Mount Vesuvius released thermal energy roughly equivalent to 100,000 times the atomic bombs dropped on Hiroshima and Nagasaki at the end of World War II, spewing molten rock, pumice, and hot ash over the cities of Pompeii and Herculaneum in particular. The vast majority of people in Pompeii and Herculaneum—the cities hardest hit—perished from asphyxiation, choking on the thick clouds of noxious gas and ash. But at least some of the Vesuvian victims probably died instantaneously from the intense heat of fast-moving pyroclastic flows, with temperatures high enough to boil brains and explode skulls.

In the 19th century, an archaeologist named Giuseppe Fiorelli figured out how to make casts of those frozen bodies by pouring liquid plaster into the voids where the soft tissue had been. Some 1,000 bodies have been discovered in the ruins, and 104 plaster casts have been preserved. Restoration efforts on 86 of those casts began about 10 years ago, during which researchers took CT scans and X-rays to determine whether complete skeletons were present.

The CT scans and X-ray images revealed that there had been a great deal of manipulation of the casts, depending on the aesthetics of the era in which they were made, including altering some features of the bodies' shapes or adding metal rods to stabilize the cast, as well as frequently removing bones before casting. Ancient DNA analysis in 2024 of four victims found in what is known as the "House of the golden bracelet" revealed that all four bodies were male and none were genetically related—challenging the pre-existing preferred narratives and suggesting those may reflect certain cultural biases.

This latest discovery involves one of the plaster cast remains of 14 victims found in what is now known as the Garden of the Fugitives, who died when they were overtaken by the pyroclastic flow while trying to flee via the Nocera Gate. Pompeii superintendent Medeo Maiuri excavated the victims in 1961, originally found in three smaller groups, although today the plaster casts are displayed in a line.

Maiuri published a fanciful, largely fictional account of who he believed those bodies to be in National Geographic that same year: a merchant with severe osteoarthritis; a mother and her two young children; a young couple with an infant daughter; and a servant with what appeared to be a shoulder bag, although the "bag" later turned out to just be a malformation in the plaster.

For decades, archaeologists had overlooked a small object trapped within another of the plaster casts that had been kept in storage for decades at the archaeological park. The new analysis with X-ray imaging and CT scans revealed that it was a small case with parts made out of metal—specifically, a toothed wheel operating a locking system. The case contained a coin-filled fabric pouch and several metal instruments similar to what a Roman physician (medicus) might have used, leading the team to conclude the man had likely been a doctor, fleeing Pompeii with his instruments close at hand.


Original Submission

posted by hubie on Friday May 22, @05:27PM   Printer-friendly

Varda hails success of autonomous touchdown tech and celebrates heat data haul:

American outfit Varda Space Industries thinks it's a little closer to operating factories in space after successfully landing its latest test craft.

Varda won the USA's first-ever license to first license fly uncrewed spacecraft that reenter the Earth's atmosphere. The company wants to do this so it can build small craft that include manufacturing facilities that create products it's only possible to make in microgravity - mostly pharmaceuticals - and figures that the relatively cheap launch services offered by private launch companies will make orbital factories economically viable.

Spacecraft are not cheap to build, and the cost rises if they include equipment to slow from orbital speeds before reaching Earth's atmosphere. Crewed craft can be more expensive still. And humanity just doesn't have a lot of capacity to schlep stuff home from space.

In March, Varda therefore launched a capsule called the W-6 that it hoped would survive re-entry at hypersonic speeds, and do so using an autonomous navigation system "that uses onboard imagery to identify resident space objects, including stars and low Earth orbit satellites, to determine precise vehicle position."

The company reckons that represents "a critical step toward fully autonomous navigation for hypersonic and reentry vehicles."

The craft also carried one nose tile that included samples of advanced thermal protection materials, another two tiles equipped with sensors to record data NASA will use to learn about hypersonic re-entry and the materials that make it possible.

Thermal performance matters because if you go to all the trouble of launching an orbiting factory if the product made in space gets cooked during re-entry.

It all seems to have worked because the capsule touched down as planned on Monday.

Varda hasn't said much about the state of the W-6's capsule and its interior when it landed but has celebrated the flight as "another demonstration that frequent, low-cost, reliable return is easily accessible."

The W-6 landed at the Koonibba Test Range in South Australia, whose operator Southern Launch celebrated the fact this is the fourth capsule to land in the patch of remote bushland it tends in the last twelve months.

See also: FAA to Require Reentry Vehicles Licensed Before Launch


Original Submission

posted by hubie on Friday May 22, @12:43PM   Printer-friendly
from the I-have-altered-the-deal dept.

Older Intel 7-based processors are locked up for servers and industrial use, leaving OEMs with little choice:

Intel 7 still underpins a large portion of Intel’s product line, from consumer notebook and desktop CPUs like Raptor Lake to Xeon 6 “Granite Rapids” server processors. As AI-driven demand for data center CPUs surged through 2025, Intel deliberately shifted Intel 7 wafer starts toward its Data Center and AI group, where Xeon parts can bring higher ASPs and better margins.

CFO David Zinsner confirmed as much during Intel’s Q3 earnings call last October, when he said capacity constraints on Intel 7 and 10 had limited the company’s ability to meet demand across both data center and client products. Intel currently has no plans to expand Intel 7 capacity.

Another exec described placing an order for 100 Intel 7 processors and receiving just 30, with 10 of those being unrequested 18A-based chips. “We were told if we don't take the 18A CPUs, they would be given to other PC makers.” Intel, in a statement to Nikkei Asia, described its Core Series 3 processors as “integral” to its client strategy but didn’t confirm whether it is actively steering clients toward 18A adoption.

Many PC makers had originally built only a handful of 18A-based models to support Intel's launch rather than in response to consumer demand, the report claims. "Frankly speaking, PC makers designed a few models based on 18A last year mainly as a favor to Intel, as the chip is expensive and the market demand is relatively small because it is too premium," another source reportedly said.

According to this report, that’s now changed, however, as OEMs that want CPU allocation are effectively being forced to redesign more of their lineups around the newer, pricier silicon. These designs, per one executive, will take “at least three months” to complete and verify, and the shift to premium CPUs also forces upgrades to displays, sensors, and other components to justify the price tag. Wildcat Lake launched barely a month ago, meaning Intel is asking OEMs to commit volume to a product family with almost no commercial track record.

[...] Counterpoint Research analyst Brady Wang said that demand continues to outpace supply, and that some of that pressure may be offset by weakening PC demand overall. Some in the industry expect a year-on-year decline of more than 15% as component costs rise.


Original Submission

posted by hubie on Friday May 22, @08:01AM   Printer-friendly

https://www.npr.org/2026/05/18/nx-s1-5822366/musk-altman-openai-jury-verdict-claims-dismissed

A jury in California took less than two hours to decide that Elon Musk waited too long to file a lawsuit against his one-time business partner Sam Altman over the direction he's steered the artificial intelligence company OpenAI since the two had a falling out nearly a decade ago.

In a unanimous decision, the nine-member advisory jury said Musk was beyond the statute of limitations when he launched his case in 2024. Judge Yvonne Gonzalez Rogers, of the U.S. District Court for the Northern District of California, agreed, tossing the case out."

[...] In determining that the suit was filed too late, the jury sidestepped questions at the heart of Musk's case accusing Altman and co-founder Greg Brockman of committing a "breach of charitable trust" by allegedly jettisoning OpenAI's founding mission, and then profiting from the decision — claims they disputed in court.


Original Submission

posted by janrinok on Friday May 22, @03:19AM   Printer-friendly

https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

Microsoft has released Linux-based programs before. The first was the Azure Sphere edge computing device. This was followed by CBL-Mariner, a Linux-based container software platform, which was later renamed Azure Linux. Never, however, had Microsoft released a general-purpose Linux distro, until now.

That was it. That was all he said. Zemlin called him back onstage and asked if he'd really just announced a Microsoft Linux distro. Burns replied that yes, he had. Zemlin continued, "When Microsoft joined the Linux Foundation, there was this big conspiracy theory that somehow the Linux Foundation was undermining open source in partnership with Microsoft, and now you announce that you're shipping a Linux distribution. That's amazing."

He's right. It is. We've come a long way from the days when former Microsoft CEO Steve Ballmer called Linux a cancer. Now, Burns said, "It's been a really great journey, and it's been awesome to see everybody within the company rally around it."

So why did the news catch us all by surprise? It was because the news was originally meant to be announced at Microsoft Techcon in two weeks. But, at the last minute, Microsoft decided to let the news out now.

Burns left the conference before I could get further details, but the Linux Foundation's crack PR team arranged for me to meet Lachlan Everson, Microsoft's principal program manager on Azure's open-source team. He told me Microsoft is turning Azure Linux into a full-fledged general-purpose cloud distribution with Azure Linux 4.0 while simultaneously productizing Flatcar Container Linux as a hardened, immutable container host called Azure Container Linux (ACL).

The former is a general-purpose virtual machine (VM) image for all Azure customers, not just Azure Kubernetes Service (AKS) users. Until now, Everson noted, "we had Azure Linux only available to third-party customers through AKS specifically, and that was Azure Linux 3.0." Going forward, this will be ACL.

Everson emphasized that Azure Linux 4.0 is the culmination of years of internal usage and the evolution of the earlier Mariner distribution. "So we've been running Azure Linux for many years internally, and we got through to 3.0, and we only allowed it on as a container host on AKS. What we've done is make it a general-purpose, so this is all the learnings that we've had in the heritage of Mariner."

Under the hood, Azure Linux 4.0 is based on Fedora Linux and is delivered as an open distribution on GitHub. This code is available now. Yes, Red Hat knows that Microsoft has done this. Everson continued, "So, we made a decision to use Fedora as an upstream, so it's using RPMs in the Fedora ecosystem. Microsoft curates the packages and the supply chain to fit Azure's cloud platform." Microsoft also created "it to be purpose-built for Azure, which integrates vertically into all of our infrastructure to give you the best Azure Linux experience on Azure."

While Azure Linux will ship as a VM image, Microsoft is already preparing a developer-friendly path onto Windows desktops: "And as of today, we have it as a VM image for your VM host on Azure. We're going to announce WSL images as well."

While developers will be able to run Azure Linux locally through WSL, Microsoft is not positioning it as a traditional desktop Linux. Asked whether he could run it on his laptop, Everson said: "I will be able to run it on my laptop, or what have you. Yes, on Windows 11." However, when pressed about a desktop experience, Everson was clear that there are "no plans" for a graphical environment.

"It's optimized for server-side in the cloud," he said, adding that even on a developer machine, users should expect a lean environment. "Minimal packages, yeah. The idea is that we offer you a consistent experience to do your development on your machine, and that you can take your workloads as you develop them on your machine and run them with VS Code. You can run your applications on that, and know that the platform is the same that you're running on the cloud, so that you have that kind of consistency between environments."

Flatcar itself remains the upstream project, but Microsoft is packaging it for Azure customers. Everson described Flatcar as "purpose-built, immutable, secure by default, production-ready operating system, and Azure Container Linux is the productization of that, but we're still investing in the upstream Flatcar ecosystem and pulling that downstream into a productized exterior experience just for container workloads, so it's a container hosting in AKS."

To underscore the immutable model, he added, "Everything's baked in, so there is no package manager. We bake the bits into the immutable, and they're in the immutable version. So Azure Container Linux is the immutable version. So you shouldn't be changing any system packages or any application packages. Anything that you need to change is customer workloads run in containers."

For existing Azure Linux 3.x users, Microsoft is promising a straightforward path forward rather than a disruptive migration. In response to a question about moving from "Azure Linux free," Everson said simply, "Yes," when asked if users could "just upgrade" without a migration. He then outlined a defined support window: "We have two years of support."

Within that window, Microsoft aims to keep kernel choices stable while providing upgrades. "So what we try to do is pick specific kernel versions that we're using for over the lifetime of the two years of support for that specific version, and then we offer an upgrade pathway for customers as well, so it's fully supported and then upgradable in the two years." This is paired with a predictable monthly security update rhythm.

That said, security is central to the Azure Linux story, especially amid a surge of kernel issues in the AI era. Everson framed Microsoft's value proposition around owning the entire supply chain: "So, part of the value proposition is that because we are taking care of the supply chain of all the pieces to build the distribution, we have minimal surface area of the packages, curated kernel, and customizations for running on Azure to support all the hardware, and we also have best-in-class security."

Microsoft is committing to monthly patches for Azure Linux -- just don't call it Patch Tuesday. However, if a serious Common Vulnerabilities and Exposures (CVE) appears, Microsoft promises to offer a patched image "as soon as those patches come out."

The new Azure Linux is also designed to let customers offload much of the update management if they choose. When asked whether users would need to intervene to stay current, Everson pointed to built-in automation: "Whether they're VMs or AKS, we have the ability to opt in to automatic upgrades based on security." In larger, scaled-out deployments, those updates are handled gradually to avoid disruption.

For customers with fragile or highly customized applications, opting out remains an option. "So if you opt into that, you will always be up to date and secure with the latest versions," Everson said, before acknowledging the other camp: "You can definitely opt out of it."

He tied this approach back to a philosophy of staying ahead of public disclosure: "As Jim said, we've got to make sure that our customers can keep up to date with the rate of change and the rate of disclosures and patches, so we've really baked that into the core of the operating system, that we can take those updates really quickly, so that you're not waiting,"

Everson cast Azure Linux as a response to the "AI-native explosion" and the dominance of Linux as the substrate for modern AI applications. "All AI applications are running on the Linux stack," he said. Microsoft, he argued, has "learned to build very hard on Linux images, and we want to give that to our customers, so that they can be successful in the AI native era."

At the same time, he stressed that Azure Linux is meant to complement, not replace, other distributions in Azure's catalog. Asked whether Red Hat knew about the new offering, the answer was unequivocal: "Actually, yes." Everson added, "We still have a great ecosystem of partners, right? This changes nothing with those relationships. If you want to run Red Hat, if you want to run Ubuntu, that's absolutely okay. What we saw was an opportunity to give you a batteries-included experience on Azure. We have eight endorsed distros on our platform, and we will continue to work with those."

As Microsoft announced in a blog post, "Today, more than two-thirds of customer cores in Azure run Linux, and the platforms running Microsoft 365, GitHub, and OpenAI's ChatGPT all sit on Linux foundations. When ChatGPT scales across more than 10 million compute cores worldwide and serves a billion queries a day, Linux and Kubernetes are what make that possible."

So here we are. Microsoft is running its most important services on Linux. Thus, it only makes sense that Microsoft is finally shipping a complete, albeit server-centric, Linux distro while continuing to support multiple other Linux distros. Today, Microsoft has finally admitted that it is, outside the desktop, primarily a Linux company.


Original Submission

posted by janrinok on Thursday May 21, @10:34PM   Printer-friendly

Iran's claim over subsea chokepoint pushes US tech companies to overland fiber:

Iran claims it will charge US tech companies fees for using undersea Internet cables that run beneath the contested Strait of Hormuz shipping lanes. The war has already halted multiple projects and led to the suspension of cable repairs in the region—and the latest Iranian threats may accelerate efforts by Big Tech and Gulf countries to find alternative routes for bypassing the Strait of Hormuz's digital chokepoint.

The latest assertions of Iranian authority over the Strait of Hormuz were announced in a brief statement by Ebrahim Zolfaghari, a spokesperson for Iran's military and the Islamic Revolutionary Guard Corps. "We will impose fees on internet cables" Zolfaghari wrote in a May 9 post. It was not immediately clear how Iran might implement such fees or impose its rules on cable projects, given that the majority of routes pass through Oman-controlled waters.

But Tasnim and Fars, both Iranian state-linked media channels, laid out more detailed proposals on how Iran could charge license fees to US tech giants for the use and maintenance of undersea cables carrying regional Internet traffic, according to The Guardian. For example, the Tasnim plan described charging tech companies—specifically naming Meta, Google, Amazon, and Microsoft—license fees for cable usage while also claiming that Iran alone has the right to repair and maintain the subsea cables.

More than 99 percent of international Internet traffic runs through the global network of undersea cables that crisscross various oceans, connecting continents and islands. The major active cables running through the Strait of Hormuz primarily serve the Gulf countries in the region. They include the Asia Africa Europe-1, FALCON, and the Gulf Bridge International Cable System, according to TeleGeography, a telecommunications research organization.

The FALCON and Gulf Bridge cables run through Iranian territorial waters at certain points, Alan Mauldin, a research director for TeleGeography, said in a CNN interview. CNN also reported that Iranian state media outlets have "issued veiled threats warning of damage to cables."

By comparison, there is "not much risk to Europe-Asia data traffic from hostilities in the Strait of Hormuz" because such Internet traffic primarily travels through cables in the Red Sea, TeleGeography wrote in a blog post. But undersea cables in the Red Sea have already seen a spate of damage in recent years, exacerbated by lengthy repair times and attacks by Houthi rebels allied with Iran.

Iran's capability to threaten undersea cables as a way of imposing its will is uncertain at this point. Since the US and Israel started the war by attacking Iran on February 28, the US military claims to have destroyed 161 vessels of the Iranian navy, according to Admiral Brad Cooper, commander of US Central Command, in testimony given to the Senate Armed Services Committee on May 14. The US military has also sunk some of the small fast boats operated by Iran's paramilitary Islamic Revolutionary Guard Corps when the latter threatened civilian shipping in and around the Strait of Hormuz.

The vast majority of damage to undersea cables comes from commercial ships accidentally dragging their anchors or fishing trawlers dragging weighted nets along the seafloor. So it's not out of the realm of possibility for a more innocuous-looking Iranian ship to sneakily perform some subsea cable sabotage if it's willing to run the gauntlet of US military surveillance and patrols in the strait.

Even a damaged commercial ship abandoned in the strait could end up dragging its anchor across some cables, as was the case with a drifting ship that damaged three cables following an attack by Houthi rebels in the Red Sea in 2024.

However, the greatest threat to subsea cable infrastructure in the Strait of Hormuz may simply come from delays in any necessary cable repairs in the region. Such jobs require specialized ships to find the damaged area and lower grappling hooks to lift up the cable for inspection and repair, according to BBC News. That repair process can require days or sometimes weeks, which would leave the ship vulnerable to Iranian missiles, drones, or fast boats that have continued to attack commercial shipping in and around the strait.

"Operators face a choice: pay protection fees and accept Iranian licensing over Middle East Gulf seabed activity, or accept that future faults may go unrepaired indefinitely," said Windward, a maritime intelligence company, in a blog post. "A single transoceanic cable system costs between $300 million and $1 billion to deploy. The expected value of an Iranian protection fee, from Tehran's perspective, is structured to sit well below that."

The Strait of Hormuz has already been a no-go region for repair ships since the conflict began early this year—and new cable projects have also been halted. In March, the French state-owned company Alcatel Submarine Networks notified customers that it could not fulfill ongoing contracts due to one of its main cable-laying ships being stranded near Saudi Arabia, according to Bloomberg. That led to the suspension of a Meta-backed undersea cable project aimed at expanding Internet service across Africa.

All this has spurred efforts by US tech companies and Gulf countries to develop overland routes for Internet cables that bypass the Strait of Hormuz, according to Rest of World. But the independent projects originated by Saudi Arabia, Qatar, and the United Arab Emirates represent competing efforts rather than regional coordination—and overland cable projects can face their own geopolitical complications with planned routes through countries such as Syria, Iraq, Sudan, and Ethiopia.

Most major US tech companies involved in the AI data center buildout have bought into a scheme to channel data through fiber-optic cables that run along protected oil and gas pipeline routes, from the southern end of Iraq to the Turkish border and beyond to Europe, the Rest of World reported. Once completed, the overland project by IQ Networks, an Iraqi telecom company, would provide a direct overland fiber link between the Gulf and Europe.

The need to seek alternative Internet fiber routes comes on top of Big Tech's other headaches from the war and Strait of Hormuz crisis. As the US and Israel launched airstrikes on Iran in the early weeks of the war, Iran retaliated by attacking shipping near the strait along with targeting a wide range of infrastructure across the Gulf region. Iranian drone attacks on data centers disrupted Amazon Web Services in the region and stuck Amazon with months of repairs while forcing another data center developer to pause Middle East projects.


Original Submission

posted by janrinok on Thursday May 21, @05:51PM   Printer-friendly

Mysteries by their very nature don't invite consensus. Without a clear answer, people's opinions tend to diverge over what the most likely solution is. Physics mysteries are no different, as evidenced by the results of a survey APS conducted last summer.

Building on an earlier survey, the American Physical Society's "Physics" Magazine ran a ten-question survey that covered some of the biggest controversies in cosmology, particle physics, and general relativity. More than 1600 people took the time to share their opinions with us, making this, to our knowledge, the largest survey to date focused on physicists' views of open questions in physics

https://physics.aps.org/articles/v19/34

[...] The survey respondents came from a diverse background. A little over 20% of the participants called themselves "science enthusiasts," with the rest identifying as researchers in one of four categories: gravity (10%), astrophysics (12%), particle physics (18%), or another field of science (30%).

Only one topic revealed close alignment: how to think about the "big bang." A large majority (70%) chose to describe it as a hot, dense state without committing to whether it corresponds to an absolute beginning of time or not. We found this alignment significant, as it suggests that the big bang is no longer widely considered the beginning of the Universe. The only other question that had a majority answer was that on early-Universe cosmology: Just over half of respondents selected "cosmic inflation" as the best explanation of early-Universe conundrums.

The survey revealed considerable skepticism over the standard model of cosmology, called ΛCDM, which stipulates the type of dark energy and dark matter that dominate the Universe's energy budget. Dark matter is typically assumed to be a new class of particle outside of the standard model of particle physics. However, a weakly interacting massive particle (WIMP), once a clear front-runner, was picked by only 10% of respondents. Larger fractions favored what were once considered less-mainstream possibilities: 17% chose a light particle such as an axion; 22% pointed to possible modification to Einstein's theory of gravity (either modified Newtonian dynamics [MOND] or quantum gravity); and around 21% made the safe bet, saying that dark matter might be a hybrid combination of all the above.

Dark energy was equally contentious. The traditional standard bearer—the cosmological constant Λ—received only about 25% of the votes, finishing neck and neck with the leading dark energy contender—a time-varying scalar field. A third option—involving some type of gravity modification—garnered much of the remaining votes.

Taken together, the dark matter and dark energy results point to a shift away from traditional views. The standard model of cosmology has far less support than one might imagine from its name!

Some tidbits:
* Almost 40 % of physicists support the Copenhagen interpretation of quantum mechanics
* [...] about 5% of respondents chose quantum gravity—a theory often associated with extremely high energy—as the solution to several outstanding mysteries (including early-Universe cosmology, dark matter, dark energy, and the Hubble tension), which are all related to lower energy scales.


Original Submission

posted by janrinok on Thursday May 21, @01:03PM   Printer-friendly

The retail bookseller plans to open 60 more stores in the US this year:

James Daunt, the CEO of Barnes & Noble, has declared that he has "no problem" with AI-written books being sold in the retailer's stores.

In a recent segment for NBC News' "Business in America" series, Today host Jenna Bush Hager asked Daunt how AI has affected the book publishing industry. The question came amid fierce concerns in creative industries about AI-generated content replacing authentic human art, and artists seeing paid work disappear as their literature is being used to train AI models.

"You have said that if the rise of AI books becomes a thing, you would be willing to sell them within your stores," Bush Hager said.

"Yes, I have actually no problem selling any book, as long as it doesn't masquerade or pretend to be something that it isn't," the British businessman responded. "And that it has an essential quality to it, and that the customer, the reader, wants it."

"So as long as an AI-written book says it's an AI-written book and doesn't pretend to be something else and isn't ripping off somebody else, as long as that's clearly stated and the customer wants to buy it, then we will stock them."

"We have 300,000 titles across all of our stores," Daunt, who became the CEO of Barnes & Noble in 2019, added. "Do we think that some of those may be AI? The chances are that they are, but we're not really conscious of them."

He also argued that in this moment, it doesn't seem like those AI-generated books "are going to get much commercial traction."

"So I think it's something that one should treat with common sense and acceptance, but not allow anything to masquerade [as]," he explained. He said that the "clarity around who the author is and whether they're a real person" is what's crucial.

His comments come after many authors' careers have been impacted by AI. In a 2025 study for Cambridge University, 59 percent of UK novelists reported their work had been used to train large language models (LLMs) without permission or any payment. In addition, more than a third of the authors stated their income had suffered due to generative AI, often through the loss of other work that supports their novel writing.

Daunt — who's also the Managing Director of Waterstones, the largest independent bookshop chain in the U.K. — has previously shared his acceptance of AI-generated books.

During a December appearance on BBC's Big Boss Interview podcast, he said: "If people want to read that book, AI-generated or not, we will be selling it - as long as it doesn't pretend to [be] something that it isn't. We as booksellers would certainly naturally and instinctively disdain it."

In 2019, Barnes & Noble was acquired by the hedge fund Elliott Advisors for $683 million, after it had been a publicly traded company on the New York Stock Exchange for 26 years.

Although hundreds of Barnes & Noble stores closed in the 2010s in the U.S., the chain is in the midst of a comeback. In December, the retailer announced its plans to open 60 stores across the country this year, with locations in Ohio, Texas, Florida, Illinois, Colorado, Washington state, California, Virginia, Georgia and Washington, DC.

"Barnes & Noble is enjoying a period of tremendous growth as the strategy to hand control of each bookstore to its local booksellers has proven so successful," the company said in a statement to USA Today at the time. "In 2024, Barnes & Noble opened more new bookstores in a single year than it had in the whole decade from 2009 to 2019."


Original Submission

posted by janrinok on Thursday May 21, @08:17AM   Printer-friendly

https://www.bbc.co.uk/news/articles/c1e24z2q7xqo

PlayStation Plus subscribers will be hit with price rises in some regions, the gaming company has said, citing "market conditions".

A basic monthly subscription to the gaming service will rise by £1, $1 (75p), and €1 (87p) to £7.99, $10.99, and €9.99 respectively. Meanwhile, a basic three-month subscription will go up by £3, $3, and €3 to £21.99, $27.99, and €27.99 respectively.

PlayStation did not specify where the rises would apply, but said they do not apply to current subscribers, except in Turkey or India, unless the existing subscription changes or lapses.

The rises will take effect on Wednesday 20 May and come just a few months after the company increased the price of a PlayStation 5.

PlayStation Plus gives users access to online multiplayer, monthly downloadable games, and exclusive PlayStation Store discounts.

There are three tiers of subscription: Essential, Extra, and Premium. All have different pricing for monthly, three-month, and yearly options.

PlayStation did not say whether there would be any price increases for the other subscription tiers or what might happen to the 12-month subscription.

Some on social media reacted angrily to the announcement, with one person writing: "Online games should be free to play... doesn't even make sense we have to pay to play online."

Another said: "Are the 'market conditions' in the room with us?"

The video game industry has been hit with supply problems due to the US-Israel war with Iran and the price of memory chips has skyrocketed because of the artificial intelligence (AI) boom.

In March, PlayStation, which is owned by Sony, the PlayStation 5's price would rise by £90 in the UK and by $100 in the US due to "continued pressures in the global economic landscape".

PlayStation's rival Nintendo also announced this month that it will hike the price of its Switch 2 console $449.99 to $499.99 in the US, and €469.99 to €499.99 in most European countries.


Original Submission

posted by hubie on Thursday May 21, @03:36AM   Printer-friendly
from the vc-bonfire dept.

https://arstechnica.com/science/2026/05/casimir-force-co-opted-to-generate-free-energy-midichlorians-not-included/

This week, a company called Casimir Inc. emerged from "stealth mode" to announce that it had raised significant funding from venture capitalists willing to roll the dice on free energy. That's right: a startup has gotten serious backing to develop sources of perpetual free energy. The people behind this fantastic new energy generator also brought us the wildly successful WTF thruster EM-drive that could supposedly directly convert electricity into a propulsive force.

(Its one practical application was in the show Salvation, where it was treated with the same detailed attention to physical laws as Galaxy Quest's Omega-13.)

With that success, who are we to be skeptical?
[...]
The Casimir force is a real thing, arising from the fact that a vacuum is not actually nothing. Instead, it is filled with a froth of virtual particles becoming real in pairs, waving to us, annihilating each other, and sinking back into the soup of virtual particles. The Casimir force emerges when we create an imbalance in the spatial distribution of these virtual particles
[...]
Put simply, a mode describes how a photon can spread out and occupy a space.
[...]
The Universe is big, so it has an enormous number of modes. But if you create a confined space within the Universe, such as the gap between two closely spaced metal plates, there are only a few modes available, and they are less likely to be occupied by a particle. Between the plates, we have no particles; outside the plates, we have particles. This excess of particles, as they bounce off the plates, drives them together.

This is the Casimir force.
[...]
To get a continuous flow of energy, according to Casimir Inc., the setup needs to be slightly different. The plates are fixed so they can't move together, and a row of pillars is placed between the plates. The plates and pillars are then connected via the device that will be powered (a load). From here, things get hazy because the details are missing—or at least highly obfuscated.

[...]
there are a couple of ways to make tunneling asymmetric (and hence might work). The one proposed in the paper by Casimir Inc. is that the structure it has designed somehow has modes between the plates that follow the same rules as a hydrogen atom, and the tunneling involves an electron going from a high-energy state to a low-energy state (at least in hydrogen, these would represent different energetic states).

If this is the case, one would expect a net flow of electrons from high energy to low energy via tunneling. Unfortunately, although the math in the paper looks fine (I've not checked it in detail), the underlying assumption—that the modes are identical to those in a hydrogen atom—seems quite shaky.
[...]
Nevertheless, the company claims to have made a device and measured a drop in voltage between the plates and pillars. The company also claims this voltage is predicted in a paper that doesn't appear to have any predictions, which is necessary for success.

I would be shocked if Casimir, Inc. had not measured a potential difference. For a decade, surfaces of materials were the bane of my existence.
[...]
But let's give the company the benefit of the doubt and assume it will observe (or already has observed) an electron flow from the plates to the pillars due to the Casimir force—it's not impossible. These electrons still need to be coaxed through a load where they can give up their energy.
[...]
Eventually, the whole charge pump will grind to a halt, leaving no current flow. In other words, I expect that no useful energy will be extracted. But I do value the company's service in burning through a bunch of VC money.


Original Submission

Today's News | May 24 | May 22  >