An anonymous reader quotes a report from the New York Times: The World Health Organization declared on Saturday that the spread of the Ebola virus in the Democratic Republic of Congo and Uganda was a global health emergency. The announcement was made a day after Africa's leading public health authority reported that an outbreak in a province in the northeast of the country was linked to dozens of suspected deaths. By Saturday, cases had also been confirmed in Kampala, the capital of Uganda, the W.H.O. said. In Congo's Ituri province, where the outbreak was first identified, 246 suspected cases and 80 deaths attributed to the virus had been reported, although only eight cases had been definitively linked to the virus through laboratory testing. There is no approved vaccine and no therapeutics for the Bundibugyo species of Ebola behind the outbreak, according to the W.H.O. The scale of the outbreak could be far larger than has been detected and reported, the W.H.O. said in declaring a "public health emergency of international concern." It added that there were "significant uncertainties" about the precise number of people infected and the "geographic spread." The W.H.O.'s declaration signals a public health risk requiring a coordinated international response, and is intended to prompt member countries to prepare for the virus to spread and to share vaccines, treatments and other resources needed to contain the outbreak. [...] The risk of the outbreak spreading is exacerbated by a humanitarian crisis, high population mobility and a large network of informal health care facilities in the area, the agency said. Containing an Ebola outbreak depends on the speed and scale of the public health response. The virus is transmitted through direct contact with the bodily fluids of an infected person, putting family members and caregivers at particular risk. Tracing people who may have come into contact with sufferers, isolating and treating victims promptly and safely, and burying the dead properly are all viewed as critical steps.

Read more of this story at Slashdot.

The best GitHub Copilot workflows don’t happen one–thing–at–a time. You might have an agent refactoring a module in VS Code, another debugging tests in the CLI, and a third scaffolding a new feature in the background.

Managing all of that used to only be possible from your desk. The moment you stepped away from your laptop, you lost visibility into every session you had running.

Now, developers can take their GitHub Copilot agent anywhere, with remote control for GitHub Copilot CLI sessions, now generally available on github.com and the GitHub Mobile app. We’re also introducing remote control in VS Code and JetBrains IDE, making GitHub Copilot truly multi-surface and available across any device.

How it works

Start a Copilot session in VS Code or the CLI, take it on the go with /remote on. Your session will be available on github.com and the GitHub Mobile app. Developers will experience one continuous workflow across CLI, VS Code, web, and mobile. Remote control works with any repository as well as directories without repositories, so you can take your work on the go, regardless of set up.

Monitor in real time

Open your session on any device to track progress as it happens. See exactly what Copilot is doing in real time, from the plans it’s researching, files it’s reading, the changes it’s making, to the commands it’s running.

Change course mid-flight

Send additional instructions to a running session from anywhere using natural language. If an agent is heading in the wrong direction, you can send a follow-up to redirect it. Or you can tell your agent to expand scope while a task is in progress. Approve or deny permission requests and manage your sessions on the go.

Complete the full workflow, from anywhere

Remote control enables a complete developer workflow once a session is sent to the web or GitHub Mobile app. For example, using Copilot CLI you could:

1. /planand scaffold with Copilot CLI.
2. /remote onto monitor progress in the GitHub Mobile app or web.
3. Steer the session with follow-up instructions.
4. Review the implementation plan and proposed changes.
5. Create and review a pull request, right from your phone.
6. Merge and move on.

/remote on brings everything together, removing the pain of switching surfaces.

Private by default

Your sessions are only visible to you. Remote control maintains full privacy; no one else can see or access your sessions.

Get started

Remote control is more than a convenience feature. It’s another step toward an end-to-end agentic platform.

Install GitHub Copilot CLI to get started in the CLI.

Or, if you’re already using the latest version of GitHub Copilot CLI or GitHub Copilot in VS Code, there’s nothing new to install. Start a session as you normally would, then use /remote on to send it to the web or mobile.

To learn more and for more detailed instructions, view our remote control documentation for CLI, VS Code, and JetBrains.

The post Take your local GitHub sessions anywhere appeared first on The GitHub Blog.

Open source is the foundation for AI and, as AI workloads scale, developers need that foundation to be more secure, more predictable, and easier to build apps and agents.

At Open Source Summit North America 2026, we’re announcing two updates that strengthen exactly that: the upcoming public preview of Azure Linux 4.0 on Azure Virtual Machines and the general availability of Azure Container Linux, our immutable container-optimized operating system (OS), with the broader rollout at Microsoft Build on June 2. Together, they give developers and organizations a hardened Linux distribution purpose-built for cloud native and AI workloads.

That foundation is also what makes the next chapter possible. The move from cloud native to AI native is the next evolution of open source, and it’s the focus of my keynote this week, From Open Source to Agentic Systems: Building the AI Native Era. Open source is already at the core of AI today, and AI in turn is reshaping how open source itself gets built, from how we collaborate, to how we test, to how the developer experience comes together. We’ve done this before. We know what it takes to build an open ecosystem at scale, and we know that openness is what makes it work.

How open source built the modern cloud: Linux, Kubernetes, and containers

Linux, Kubernetes, and containers have made the modern cloud possible. Every hyperscaler, every AI training cluster, every inference endpoint serving millions of tokens a second is built on open source. Open standards, shared governance, and community innovation have been the way an ecosystem of this scale comes together, allowing the best ideas, from anywhere, to compound.

For Microsoft, this story started in earnest in 2009, when we contributed more than 20,000 lines of Hyper-V driver code to the Linux kernel. A small patch then, but a clear signal of where we were headed.

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.

Azure Linux 4.0 and Azure Container Linux: A secure Linux foundation for cloud native and AI workloads

For developers running modern workloads on Azure, the OS layer should be invisible: secure by default, consistent across hosts and containers, and out of your way. That’s what Azure Linux and Azure Container Linux are designed to do.

Both are hardened, with a reduced package footprint, transparent supply chain, and consistent performance characteristics from the host all the way up to the container. Teams running regulated or security-sensitive workloads get a smaller attack surface and a Linux distribution maintained by the same team that operates the cloud it runs on. And because we develop in the open and contribute upstream first, the work that hardens Azure Linux benefits the broader ecosystem too.

How AI is reshaping open source development

AI isn’t just a new workload sitting on top of open source; it’s changing how open source itself gets built.

• Maintainers are using coding agents to triage issues, generate tests, and review PRs.
• Agentic tooling is starting to handle the toil associated with dependency updates and security patches.
• And the contribution loop is opening to more developers, in more languages, at a faster cadence than we have ever seen.

That’s a good thing for the ecosystem, but it raises the bar on the fundamentals: provenance, review discipline, supply chain integrity, and clear standards. The communities that figure out how to fold AI into their workflows while keeping the trust model intact are the ones who will define the next decade of open source.

Building an open agentic stack: Frameworks, protocols, and governance for AI agents

Delivering agentic systems at global scale takes collaboration across the open source ecosystem. Agents need to work everywhere developers build—across frameworks, clouds, languages, and runtimes. That kind of portability only happens when the foundations are open.

That’s why we are working alongside the open source community on the building blocks of an open agentic stack:

• Microsoft Agent Framework: Our open source SDK and runtime for building, deploying, and managing multi-agent systems. It carries forward the lessons of Semantic Kernel and AutoGen into a single foundation that maps cleanly from local development to cloud deployment, with the observability, evaluation, and lifecycle primitives production systems need.
• Ray and NVIDIA Dynamo: Partnerships and contributions that let agents and AI workloads compose across the most widely adopted open frameworks in the ecosystem.
• A2A (agent-to-agent) protocols: Open interfaces so agents from different vendors, frameworks, and clouds can communicate, delegate, and coordinate.
• Agent Governance Toolkit: The control-plane primitives (identity, policy, audit, access boundaries) that let organizations deploy agents responsibly. Just as Kubernetes needed RBAC and admission controllers to be enterprise-ready, agentic systems need governance primitives and those primitives belong in the open.

Those building blocks need a shared standards body to keep them interoperable. That is where the Agentic AI Foundation comes in.

The Agentic AI Foundation: Open standards for agent interoperability

The Agentic AI Foundation (AAIF) is already the fastest-growing project in Linux Foundation history. Microsoft is a founding member, and we believe deeply in its mission: establishing open standards for agent-to-agent communication, agent runtimes, and agent orchestration.

The AAIF builds on and complements what the Cloud Native Computing Foundation (CNCF) has done for cloud native—the two are designed to work together. The reason this is happening so quickly is straightforward: customers and the broader community are asking for interoperability. They don’t want to bet their agentic future on a single vendor’s stack and open standards are how we make sure they do not have to.

The early momentum across industry and academia tells you how much the ecosystem wants this to be open. As customers scale multi-agent systems composed of custom built and third party agents, interoperability becomes essential to truly deliver on the business transformation goals. The agentic future cannot be proprietary, and the AAIF is how we make sure it isn’t.

Securing the open source supply chain for AI

None of this works if the underlying ecosystem isn’t trustworthy. The same projects that power the cloud and AI also power critical infrastructure, and the people maintaining them are often a handful of volunteers in their spare time. As agents become more autonomous, every dependency they touch becomes part of their trust boundary. Securing open source isn’t just hygiene anymore. It’s a prerequisite for letting AI agents do real work.

That’s why Microsoft has made a sustained, multi-phase investment in OpenSSF and Alpha-Omega:

• A kick-start investment to seed Alpha-Omega’s mission of improving the security posture of critical open source software through expert engagement and automated security testing.
• A second round of funding to Alpha-Omega and OpenSSF to scale sustainable, AI-powered open source security solutions, using the same agentic capabilities we’re building elsewhere to harden the supply chain itself.

We’re also a founding partner in the GitHub Secure Open Source Fund, which pairs direct financial support ($10,000 per project) with a three-week program of security education, mentorship from GitHub Security Lab, tooling, and ongoing check-ins. The model is designed to scale; invest in maintainers as people, not just packages, and the security improvements compound across the dependency graph.

Kubernetes and CNCF: Where Microsoft contributes upstream

For three years running, Microsoft Azure has been the largest public cloud contributor and the second-largest contributor overall to CNCF projects.

That includes core upstream work in Kubernetes, Helm, containerd, Istio, and Envoy—the runtime layer the entire cloud-native ecosystem depends on, alongside community projects we contribute to heavily, like OpenTelemetry, ArgoCD, HolmesGPT, OPA Gatekeeper, and Cilium as well as projects we’ve launched and donated:

• Dapr: Graduated CNCF project for cloud-agnostic distributed applications.
• KAITO: Kubernetes AI Toolchain Operator for deploying and fine-tuning models on AKS and at the edge.
• KubeFleet: Multi-cluster orchestration with smart scheduling and progressive rollouts.
• Radius: Application-centric platform spanning Azure, AWS, and private clouds.
• Drasi: Change-driven workflows over real-time data.
• Copacetic: Supply-chain-focused container patching.
• Dalec: Declarative format for building system packages and containers in a secure way.
• Flatcar: Container-optimized Linux, accepted into CNCF at the incubating level.
• Headlamp: Kubernetes dashboard UI for managing and visualizing clusters for workloads.
• Inspektor Gadget: eBPF-powered observability toolkit for deep Kubernetes and container runtime insights.

Every one of these projects started with a problem we hit running Kubernetes on Azure at scale. When we do work in the open, we get better solutions, and the broader community strengthens and benefits from the work too.

From cloud-native to AI-native: The open source principles that carry over

The takeaway from a decade of cloud native is that the principles still apply:

• Open interfaces, so workloads and agents are portable.
• Shared governance, so no single vendor controls the runway.
• Distributed innovation, so the best ideas can come from anywhere.
• Collective security, so the foundation everyone depends on stays trustworthy.

Kubernetes and Linux fueled the cloud era as the foundational layers. We believe they will be foundational for the agentic era too, alongside the new open standards the community is building right now.

Come find us in Minneapolis

If you’re at the summit this week, please come say hello. The Microsoft team is at the booth with live demos across:

• Azure Linux
• Azure Container Linux
• Azure Kubernetes Service
• KAITO
• Dapr
• Radius
• Our security work

We have engineers, maintainers, and product managers ready to dig into whatever’s on your mind—whether that’s a thorny Kubernetes question, an idea for a new CNCF sandbox project, an AAIF contribution, or how to get your first agent into production.

The cloud era was built by this community. The AI native era will be too. I can’t wait to see what we build together.

See you in Minneapolis.

—Brendan

The post From open source to agentic systems: Microsoft at Open Source Summit North America 2026 appeared first on Microsoft Open Source Blog.

Because someone still has to own the consequences of what gets built and whether it can function at scale.

---