Read more of this story at Slashdot.
Read more of this story at Slashdot.
If you were in search of a practical Linux distro, Omarchy might’ve come onto your radar. And if you liked that it strips out the usual endless terminal setup, in favour of a pre-tuned, Arch Linux-based opinionated desktop, you might have also heard about its creator, David Heinemeier Hansson, or DHH, as he’s known.
The 37signals co-founder recently took to X with a direct plea (or rather, an open challenge) to Microsoft’s top brass:
“Microsoft should ship Office for Linux natively. Excel and Word are still the GOATs in their segments. What do we need to do to make this happen @satyanadella?”

DHH created a distro around the idea that Linux can be a polished daily driver for developers and creators. But as good as modern distros have become, productivity software is still the elephant in the room.
He asks Satya Nadella what it would take to get native Linux versions of Word and Excel. Of course, the web version of Microsoft 365 (Office) already works in a Linux browser, and that too for free, but DHH quoted an arbitrary 10% fidelity that’s still missing for Linux power users.

DHH also responded to the idea that Microsoft would risk cannibalizing Windows if they shipped a native Linux version of Word or Excel; he answered that Microsoft isn’t married to Windows anymore, because that’s not where the money comes from these days.
It’s no secret, though, and Microsoft’s FY2026 Q4 results are in favour of DHH. Windows OEM and Devices revenue fell 7% year over year, while Microsoft 365 Commercial cloud revenue grew 14%, Azure grew 43%, and Microsoft Cloud revenue overall hit $59.3 billion, up 27%.
Windows Latest broke down just how small Windows has become inside Microsoft’s business, estimating Windows client revenue at a little over 5% of the company’s total.

With 1.6 billion monthly users, Windows still counts for plenty. But Microsoft’s financial center of gravity has moved to cloud and subscriptions, which makes DHH’s argument more plausible than it would’ve been a decade ago.
It doesn’t follow that native Office would kill Windows sales either. The general hatred towards Windows would have people claim that nobody would buy Windows again if Office landed on Linux, but Windows isn’t sold because people want Office.
Much of it moves through OEM deals and enterprise agreements bundled with endpoint management. A more agreeable reply mentioned that Microsoft doesn’t need someone to buy Windows to make money off them. A Linux user can still pay for Microsoft 365, Teams, Azure, or Defender.
In recent developments, Microsoft now officially supports Edge on Linux, and its Linux resources page pushes Edge, VS Code, PowerShell, and Defender to Linux users.

We’ve looked at how well Microsoft optimized WSL so developers get Linux tooling without leaving Windows. Microsoft increasingly wants its services to follow the user, regardless of which OS they’re running.
Microsoft already supports Linux, mostly through the browser. Microsoft’s documentation admits the web version has fewer features than desktop Office, missing things like captions, citations, advanced collaboration, and document parts in Word alone. It’s DHH’s “last 10%” argument confirmed by Microsoft!

Excel is the strongest case for a native port. Power Pivot, Excel’s advanced data-modeling engine, doesn’t exist on Mac at all, full stop, according to Microsoft’s support answers. Power Query exists on Mac in a limited form. Neither comes close to the full Windows experience.
The distinction isn’t cosmetic either, since Power Pivot supports DAX, relationships, and the kind of enterprise data modeling that makes Excel indispensable for analysts.

The real moat isn’t Word and Excel’s interface. It’s Power Query, Power Pivot, VBA, Power BI, SharePoint, OneDrive, Teams, and enterprise identity management, all wired into the same ecosystem (which is a word we generally associate with Apple!).
This is also why LibreOffice being good enough for most people doesn’t eliminate demand for Microsoft’s version. LibreOffice is a legitimate alternative, but Microsoft Office remains the compatibility reference point for complex Excel workbooks and enterprise workflows.
The common internet slang “just vibe-code Office for Linux,” came up way too many times in the replies, and in case you haven’t figured it out already, it isn’t realistic. Matching Word and Excel’s UI isn’t hard for AI. But matching decades of document formats, calculation logic, macros, and edge cases takes more than meets the eye.

There were recent reports of Linux taking 10% of Windows market share, but we proved that it’s inaccurate. However, Linux has seen some real growth, and in more interesting news, we covered how Ubuntu is growing faster through WSL on Windows than as a native install, but it’s nowhere near large enough to make a native Office port an obvious business call for the Redmond giant.

Omarchy is not trying to convert Windows users to Linux. It’s trying to make Linux desktop approachable for developers who already have reasons to be there, and Microsoft’s WSL strategy is close to an admission that plenty of them do.
Microsoft brought Edge to Linux years after Chrome got there, which is a sign it wants Edge users wherever it can get them.
The billion-dollar question is: would Microsoft prefer to lose a Linux user completely, or sell them a Microsoft 365 subscription?
A native Linux Office suite would still cost a ton of engineering time for a comparatively small desktop market, and Microsoft has announced no such plan. DHH’s request is strategically interesting, though.
The post Excel keeps people on Windows, and a Linux distro creator wants Microsoft to end that appeared first on Windows Latest
At a time when the consensus is that corporations do not know what to do with AI, Microsoft actually has a plan that leverages AI to bring more native WinUI apps to the Microsoft Store.
The company published a new quick-start guide that helps anyone go from an empty folder to a published WinUI 3 app using AI, VS Code, and their winapp CLI. Microsoft says the whole thing takes about 30 minutes, doesn’t need Visual Studio, and runs on free tools including the GitHub Copilot free tier.

You see how this looks, right? The easy 30-minute guide is basically a hook to lure beginner developers into making apps for Windows 11 without having to do the “hard work” of coding. I support this because the Microsoft Store could use some WinUI apps!
Now anyone can create a new WinUI app with AI, have an agent add features, test the result, package it as MSIX, and submit it to the Microsoft Store, all for free and with minimal effort. But I’m more interested in the attached AI-assisted migration guides for existing WPF and UWP apps.

To me, this is what Microsoft’s answer to Windows’ long-running native app problem looks like: make WinUI apps easier to build, make old apps easier to move over, and let AI handle the tedious parts in both.
The new-app workflow runs on VS Code, .NET 10, Microsoft’s Windows App Development CLI, WinUI project templates, GitHub Copilot, and WinUI agent plugin.

This shouldn’t be confused with how the company promoted their generic chatbot, Copilot. The WinUI agent ships with specialized skills for WinUI design, code review, UI testing, packaging, and framework migration.
Microsoft also recommends connecting the agent to its Learn MCP server, so it pulls current WinUI API documentation at query time. Considering the lower popularity of WinUI 3, it is fair to assume that AI models have years more training material on WPF and UWP.
The WPF migration guide doesn’t pretend this is a find-and-replace job. System.Windows.* becomes Microsoft.UI.Xaml.*, and Microsoft hands the AI agent a full substitution table covering controls, threading, window management, DPI handling, and data binding, plus a starter prompt telling it what to flag.
Microsoft’s migration guide for UWP to WinUI 3 starts by saying that the former is no longer under active development and that WinUI 3 and the Windows App SDK are its successors. Interestingly, the guide warns that AI models trained on years of UWP samples will keep reproducing those patterns unless the migration skill gives them explicit substitutions to follow.

Microsoft is essentially trying to lower the cost of moving its enormous existing library of WPF and UWP software onto the new native framework.
Windows keeps getting web apps instead of native ones because cross-platform web frameworks are cheaper to build for, letting developers reuse code across platforms instead of writing for a Windows framework that may change in the future, like it already did multiple times in the past.
At Build 2026, Microsoft made a strong commitment to changing that perception, calling WinUI the “production platform for Windows apps” and dropping the “3” from its name to tell the developer community that they won’t replace the framework again.
Microsoft also committed to lower memory usage, DataGrid and charting support, better WPF interop, and more open-source participation. In fact, WinUI is now fully open source.
It’s not just for app development. The company has been replacing pieces of Windows 11’s legacy interface with WinUI 3, with the most recent being AutoPlay, Print Management, and more in the pipeline. It’s unfair to ask developers to adopt a stack Microsoft won’t use themselves.

Microsoft’s pitch for native apps isn’t that WebView2 or Electron are bad technology, although I disagree. The company’s documentation talks of WebView2 as a legitimate way to build hybrid apps, and it says resource use comes down to how well a developer optimizes their web content.
Funnily enough, the Windows 11 Weather app, built on WebView2, uses 1.2GB of RAM at idle, about five times what Apple’s native macOS Weather app uses, with nine Chromium sub-processes.

Despite having an enterprise-first approach, Microsoft Teams added an Efficiency Mode only after years of complaints.

Popular third-party apps like WhatsApp’s Windows app have struggled with loading times while also eating through RAM. Discord admitted its Windows app was a resource hog and tested auto-restarting it once RAM usage crosses 4GB.

Microsoft is telling third-party developers to build leaner native apps while some of its own apps and Windows UI are based on WebView2.
David Fowler, Microsoft’s Distinguished Engineer working on Aspire, recently said typing code is absolutely over. Yes, the WinUI tooling here has agents that generate code, understand a project, run tests, and fix what breaks, instead of a human having to type every line.

However, AI making code cheaper to produce isn’t the same as making it good. Microsoft knows this too, which is why the WinUI agent ships with dedicated code-review and UI-testing skills.
If Microsoft wants AI to generate more Windows software, that software still needs to be efficient, or making native apps easier to build just produces more badly optimized native apps.
I fell into a rabbit hole trying to decode what Microsoft’s plan is to get more native apps on Windows 11. If years ago, it needed Steve Ballmer to chant “developers, developers, developers” on stage, now the game has changed, with many devs now preferring Linux environments and a large group of AI-based app developers choosing MacBooks, owing to its powerful hardware.

Redmond is trying to keep its place in three ways:
Microsoft is trying to make building for Windows happen inside a Windows environment designed around AI agents. If it works, Windows could get more native apps without developers having to rewrite everything by hand. But Microsoft still has to prove those AI-built WinUI apps will be faster and lighter than the web apps it wants to replace.
The post Microsoft is ending Windows 11’s web app slop era, and AI now writes native apps in 30 minutes appeared first on Windows Latest
How are you, hacker?
🪐Want to know what's trending right now?:
The Techbeat by HackerNoon has got you covered with fresh content from our trending stories of the day! Set email preference here.
## Qwen3.8-27B-DFlash2: A Guide to Faster Qwen Inference
By @aimodels44 [ 7 Min read ]
Explore Qwen3.8-27B-DFlash2, a speculative decoding model that delivers up to 3.43× faster Qwen3.8-27B inference with no quality loss. Read More.

By @technologynews [ 15 Min read ] The scariest AI story of 2026 isn't job loss. It's the "cognitive precariat": employed, productive, and hollowed out. Read More.

By @thomascherickal [ 31 Min read ] Gemini Spark vs Hermes Agent vs OpenClaw compared for 2026: security, pricing, killer features, and verdicts for power users, developers, enterprises. Read More.

By @kalaninja [ 12 Min read ] Learn how zero-copy parsing, bytemuck, and Pinocchio make Solana account layouts safer and prevent AI-generated data model bugs. Read More.

By @aimodels44 [ 8 Min read ] A complete guide to Qwen3.8-27B Uncensored GGUF covering llama.cpp setup, quantization, multimodal support, benchmarks, use cases and limitations. Read More.

By @egorkaleynik [ 13 Min read ] A detailed guide on how to use AI for generating content that no one will call AI slop. Read More.

By @technologynews [ 4 Min read ] OpenAI and Anthropic tests show AI agents exploiting security weaknesses, raising concerns about capability rather than machines going rogue. Read More.

By @superorange0707 [ 5 Min read ] Build an AI requirements compiler that links evidence, detects conflicts, derives interfaces and tests, and renders versioned PRDs with visible uncertainty. Read More.

By @mcsee [ 5 Min read ] Don't reuse an existing getter to bolt on new business logic from outside the object. Read More.

By @noufalb [ 13 Min read ] AI is removing routine junior work, but those tasks also helped build expertise. Companies may be trading short-term productivity for long-term capability debt. Read More.

By @aimodels44 [ 9 Min read ] Explore Qwen3.8-27B Cold Fusion, a 27B AI model designed to cut thinking tokens while retaining strong quantized reasoning performance. Read More.

By @zbruceli [ 30 Min read ] What if the 1991 Linus Torvalds woke up in 2026 and called the whole AI stack bad taste? And an open source approach to change that. Read More.

By @thomascherickal [ 20 Min read ] Ox Alpha had no author for six days. It was GLM-5.3-Flash. Benchmarks, architecture, real hardware costs from datacentre to hobbyist, and what it means. Read More.

By @noonification [ 2 Min read ] 8/30/2026: Top 5 stories on the HackerNoon homepage! Read More.

By @octowatchdlp [ 6 Min read ] Activity percentages on time-tracking dashboards are basically a compressed view of mouse and keyboard input. Read More.

By @proflead [ 3 Min read ] How the Agents Dashboard and codex queue turn multiple AI coding sessions into one manageable workflow. Read More.

By @ank17 [ 4 Min read ] Building a mobile app with an AI coding agent changed more than typing speed. It shifted the real work toward specs, logic, and product decisions. Read More.

By @c4twithshell [ 3 Min read ] AI agents are making open source contributions easier than ever but they're also changing how trust is built. Here's why that may become the next SCA Read More.

By @botbeat [ 3 Min read ] What makes this exit unusual is Google isn't losing Dean to a rival, it's that they're is bankrolling his next act. Alphabet is a founding investor. Read More.

By @thetechpanda [ 4 Min read ]
Robotaxis are expanding across major cities, raising new questions about driver displacement, safety, labor shortages, and the economics of autonomous transport Read More.
🧑💻 What happened in your world this week? It's been said that writing can help consolidate technical knowledge, establish credibility, and contribute to emerging community standards. Feeling stuck? We got you covered ⬇️⬇️⬇️
ANSWER THESE GREATEST INTERVIEW QUESTIONS OF ALL TIME
We hope you enjoy this worth of free reading material. Feel free to forward this email to a nerdy friend who'll love you for it.
See you on Planet Internet! With love,
The HackerNoon Team ✌️
.gif)
The rapid transition toward autonomous multi-agent systems has exposed the acute fragility of maintaining bespoke, hard-coded API integrations for every large language model. In 2026, enterprise software architects and engineering teams are moving away from proprietary function-calling wrappers in favor of open, vendor-neutral interface standards.
Under the modern enterprise landscape—anchored by the open-source Model Context Protocol (MCP) 2026 specification and cross-industry Linux Foundation governance—applications now establish standardized, bidirectional bridges between foundation models and live business environments. This architectural shift eliminates mounting integration debt while enforcing stringent enterprise security and operational governance.
For the past three years, engineering organizations rushed to equip generative models with external agency by writing bespoke tool-calling functions. Whenever an engineering team wanted an AI assistant to query an internal PostgreSQL database, inspect a GitHub repository, or create an issue in Jira, developers wrote custom JSON schemas and handcrafted Python or TypeScript client code tailored to one specific model provider.
This ad-hoc paradigm created an unsustainable M×N integration bottleneck. If an enterprise deployed three distinct models across two client environments (such as an IDE extension and an automated Slack bot) alongside ten internal software services, developers had to maintain sixty separate integration paths. Every time an API vendor changed a payload structure or released a revised SDK version, fragile custom connectors broke across the entire enterprise stack.
As explored in our technical breakdown on decoding the differences between Gen AI and Agentic AI, true autonomy demands standardized sensory perception and deterministic action execution. Rather than spending valuable development cycles on repetitive integration plumbing, modern software engineering requires a universal interface bus where data sources expose their capabilities once, and all AI clients consume them reliably.
This integration gridlock is precisely what drove the industry-wide adoption of the open-source Model Context Protocol in 2026. By turning external services into modular, pluggable servers that communicate via uniform schemas, organizations have finally decoupled foundation model reasoning from concrete backend infrastructure.
The Model Context Protocol establishes a clean, three-tier architecture consisting of the Host, the Client, and the Server. Understanding how these three entities collaborate is essential for building resilient agentic systems.
The Host is the primary user-facing application or orchestration runtime where cognitive work originates. Examples of Hosts include developer IDEs, conversational assistants, and enterprise multi-agent workflow engines. The Host is responsible for initializing client instances, managing authentication keys, enforcing user permissions, and presenting results back to human operators.
The Client resides inside the Host application and maintains a direct 1:1 connection with an individual MCP Server. The Client handles protocol negotiation, converts model function calls into structured JSON-RPC 2.0 requests, and receives streaming responses. A single Host can manage dozens of active Clients simultaneously, allowing an AI agent to interact with a file system, a cloud telemetry service, and a database within the same reasoning loop.
The Server is a lightweight, dedicated process or microservice that exposes domain-specific capabilities to Clients. The Server does not need to know which language model is querying it; it simply advertises its available tools, resources, and prompts, executes requested operations when invoked with valid arguments, and returns structured data payloads.
Communication between Clients and Servers is executed over two primary transport protocols:
To see how autonomous agents organize multiple domain workers, our architectural guide on why agentic AI is tech's biggest winner in 2026 provides helpful context on real-world multi-agent workflow orchestration.
Unlike early tool-calling interfaces that treated all external interactions as opaque function executions, the Model Context Protocol categorizes capabilities into three distinct, first-class primitives:
Tools represent model-controlled actions that produce side effects or retrieve dynamic computational results. Examples include executing SQL statements, running unit tests, sending emails, or provisioning cloud resources. Every tool definition includes a strict JSON schema describing its parameters, required fields, and expected response format, allowing language models to plan and invoke function calls with mathematical precision.
Resources represent read-only data streams and document contexts that the Host or user can attach directly to model context windows. Resources are identified by standard URIs (such as postgres://warehouse/orders/schema or file:///repo/docs/architecture.md). Unlike static RAG chunks, MCP Resources support real-time subscription models: when an underlying database schema or log file changes, the Server emits an update notification, ensuring the agent always reasons over active, authoritative state.
Prompts are parameterized, reusable workflow templates exposed by the Server to guide both human users and AI agents through complex multi-step procedures. A GitHub MCP Server might expose a prompt titled review-pull-request, which automatically gathers the diff, fetches relevant style guidelines, and structures the critique. Prompts transform ad-hoc prompt engineering into version-controlled, reusable enterprise assets.
To appreciate how dramatically the Model Context Protocol streamlines development, consider how developers traditionally integrated a customer order lookup tool compared to how it is authored today with an MCP Server.
In traditional setups, developers wrote proprietary schema bindings coupled tightly to a single SDK. If the team migrated from one LLM provider to another, the schema definitions, validation logic, and error formatting had to be rewritten from scratch:
// LEGACY: Proprietary OpenAI-specific function calling wrapper
// Hardcoded schema and manual dispatch tightly coupled to one vendor
const orderLookupTool = {
type: "function",
function: {
name: "lookup_customer_order",
description: "Fetch customer order details from PostgreSQL database",
parameters: {
type: "object",
properties: {
order_id: { type: "string", description: "The UUID of the order" },
include_history: { type: "boolean", description: "Fetch audit log" }
},
required: ["order_id"]
}
}
};
// Custom execution dispatcher with manual JSON parsing and error handling
async function handleToolCall(toolCall) {
if (toolCall.function.name === "lookup_customer_order") {
const args = JSON.parse(toolCall.function.arguments);
return await db.orders.findUnique({ where: { id: args.order_id } });
}
throw new Error("Unknown function call");
}With MCP, the server exposes the capability using a standardized SDK. Any compliant MCP Client (whether running in Visual Studio, Claude Desktop, Cursor, or a custom internal enterprise agent) can discover, inspect, and invoke this tool without a single line of custom adapter code:
// MODERN: Standardized Enterprise MCP Server implementation (TypeScript)
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { ListToolsRequestSchema, CallToolRequestSchema } from "@modelcontextprotocol/sdk/types.js";
import { z } from "zod";
const server = new Server(
{ name: "enterprise-order-service", version: "2.0.0" },
{ capabilities: { tools: {}, resources: {} } }
);
// 1. Advertise available tools using standardized schemas
server.setRequestHandler(ListToolsRequestSchema, async () => ({
tools: [
{
name: "lookup_customer_order",
description: "Securely query customer order records from PostgreSQL",
inputSchema: {
type: "object",
properties: {
orderId: { type: "string", description: "Enterprise order UUID" },
includeAudit: { type: "boolean", description: "Include compliance log" }
},
required: ["orderId"]
}
}
]
}));
// 2. Deterministic execution with typed arguments and uniform response envelope
server.setRequestHandler(CallToolRequestSchema, async (request) => {
if (request.params.name === "lookup_customer_order") {
const { orderId, includeAudit } = request.params.arguments as { orderId: string; includeAudit?: boolean };
const orderData = await queryOrderDatabase(orderId, includeAudit);
return {
content: [
{ type: "text", text: JSON.stringify(orderData, null, 2) }
]
};
}
throw new Error(`Tool not found: ${request.params.name}`);
});
// 3. Connect via isolated standard input/output transport
const transport = new StdioServerTransport();
await server.connect(transport);
Notice the architectural elegance: the server is completely agnostic of the LLM. It can be invoked by a local open-weight model running through Ollama or a massive frontier cloud model without altering a single byte of server-side code.
Deploying autonomous agents in enterprise banking, healthcare, and e-commerce requires far more than reliable API connectivity. When an AI model is empowered to invoke software tools, organizations face catastrophic risks if an agent falls victim to indirect prompt injection or enters runaway execution loops.
The Model Context Protocol incorporates four essential protective layers specifically designed to satisfy corporate security reviews:
Developers working in local development workflows can explore our guide on running local AI models with Ollama and SLMs to prototype private, zero-leakage MCP architectures right on developer workstations.
As enterprise architectures mature, confusion often arises regarding the relationship between the Model Context Protocol, multi-agent communication frameworks, and modern knowledge retrieval strategies. Far from competing, these technologies form a cohesive, layered ecosystem:
The maturation of the Model Context Protocol marks a pivotal milestone in software engineering, resolving one of the most stubborn friction points in enterprise AI adoption. By replacing fragile, proprietary tool connectors with an open and universally supported standard, engineering teams can finally focus on business domain logic and workflow orchestration rather than low-level API plumbing.
As multi-agent ecosystems become the primary interface for software creation, operations, and enterprise data analysis, standardized protocols will serve as the essential connective tissue of modern digital infrastructure. Organizations that adopt MCP today insulate themselves against vendor lock-in, streamline their compliance audits, and unlock unprecedented speed when rolling out autonomous capabilities.
I encourage software engineers, team leads, and architects to begin by wrapping a single internal utility or database service into a standardized MCP Server. Test it against your local development environment, observe how cleanly your AI coding assistant interacts with it, and scale your agentic infrastructure with confidence. Feel free to share your thoughts, architecture questions, and implementation experiences in the comments below!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|