StatCounter, a web analytics company, claimed that Windows’ market share had fallen from roughly 79% to just 56%, but as expected, it turned out to be a reporting error.

In April 2026, StatCounter documented that Windows held approximately 79% of the desktop market. In June 2026, the same company reported that Windows’ market share had dropped to just 56.55%. This meant Windows’ market share appeared to fall by 22.45 percentage points, or about 28.4%, in just two months.

At the same time, Linux had climbed to 4.39%, while Apple’s OS X and macOS stood at 16.37%. This was immediately picked up by Linux fan sites like Linuxiac and “AI” influencers like Chubby, who posted on X that Windows’ market share was dropping rapidly and shared the screenshot below:

Windows’ reputation may be at an all-time low, but that doesn’t mean the operating system’s market share has dropped below 60%. As expected, StatCounter has admitted that it messed up and rolled out fresh data that shows Windows at 72%. It’ll likely climb back toward 78% in the coming weeks as the numbers continue to adjust.

It’s clear that, even if you take StatCounter’s retracted numbers at face value, Linux’s market share growth does not explain the reported 28% drop in Windows usage.

So where did the missing chunk of Windows users go?

I downloaded the data from StatCounter, and we found that an operating system labeled “Unknown” suddenly accounted for 21.45% of the desktop market. This category could include any device where the browser’s user agent is modified, unavailable, or cannot be correctly identified by StatCounter.

That means a portion of those “Unknown” devices could very well be Windows PCs. The more likely explanation is that StatCounter misclassified a large number of devices rather than Windows suddenly falling below 60% or contributing to Linux’s growth.

It’s not the first time StatCounter has reported wild numbers. In 2025, a number of outlets and influencers reported that Windows 7 was gaining market share to prove a point that Windows 11 is a terrible operating system.

Later, StatCounter rectified the numbers, and Windows 7 went back to less than 1% of the desktop market. Windows 11 may be bad or good, and that’s a different topic, but at no point did it make sense for Windows 7 to jump to over 10% share from less than 1%. If somebody hates Windows 11, they’d switch back to Windows 10 or try macOS or Linux, not go back to Windows 7.

We also observed something similar in 2024 when StatCounter reported that Google’s market share had dropped, and the internet linked it to ChatGPT. In reality, it was a reporting error.

Do not blindly trust StatCounter numbers for Windows or browser market share

I also believed everything StatCounter would throw at me because it’s one of the largest independent web analytics companies. Since it tracks billions of monthly page views, it should give a healthy idea of how well Windows or Linux is doing, right? Well, wrong.

We need to understand how StatCounter works before judging these numbers. StatCounter is an analytics platform, similar to Google Analytics, and it’s used by web properties such as news outlets or e-commerce sites.

StatCounter is installed on more than 1.5 million websites, and it counts billions of page views, not unique devices or users.

How StatCounter tracks web usage, and why it can be briefly incorrect

StatCounter uses anonymous metrics, detects the user agent of each visit, and comes up with a comprehensive market share estimate for browsers and operating systems.

That means even if the base is large, StatCounter numbers are still estimates. They can give you a rough idea, but not an exact picture. So when StatCounter says Windows 7 is under 1% share, that broadly makes sense because how often do you find Windows 7 at commercial places or with consumers today? Only a relatively small number of older PCs still run it.

Unfortunately, StatCounter has a difficult role to play here, and mistakes are bound to happen. For example, bots, AI crawlers, scrapers, modified user agents, and other traffic patterns can manipulate or distort the numbers, causing a brief spike or drop like we’re seeing in the case of Windows’ overall market share now, or Windows 7 last year.

“We remove bot activity and make a small adjustment to our browser stats for prerendering in Google Chrome. Aside from those adjustments, we publish the data as we record it,” StatCounter’s document reads.

StatCounter has already rectified the Windows error for June 2026, which likely would have happened even without the noise from influencers . The inaccurate figures were most likely caused by ambiguous Windows traffic being misclassified as “Unknown.”

In fact, Windows appears to be in a better shape now. More recently, Microsoft confirmed that the OS is installed on 1.6 billion devices, and the number is likely to go up as the company continues to improve the operating system.

But what about you? Have you ever considered switching to Linux? Let me know in the comments below.

The post No, Windows did not fall below 60% market share or lose 20 points to Linux appeared first on Windows Latest

"We need you in the fight," says the American legal expert in privacy, surveillance, AI, and Internet freedom of speech who became the EFF's new executive director in March. As EFF celebrates the anniversary of its founding 1990, "Each headline is different, but they tell one story: Many of the threats that once seemed hypothetical are now reality, and EFF's work to ensure technology supports rights, justice, freedom, and innovation for all people has never been more critical." Governments and large corporations possess surveillance capabilities that were unimaginable just a few years ago. Ever greater concentrations of power are shaping speech, creativity, markets, and democratic institutions. Governments are increasingly seeking to control the internet and people's ability to access information and communicate freely. Our community's work is fundamental to the future of our countries, our livelihoods, and literally our lives... These are perilous times. It is also a moment of extraordinary possibility. The future of AI has not been written and we can work together to get it right. We can make sure our laws reflect the needs of the modern digital age. We can build the technologies that empower rather than marginalize communities. For me, the work starts with recognizing that digital rights are not a siloed policy issue. We must fight and win on the digital terrain to organize, speak freely, access healthcare, find work, receive an education, and participate fully in democracy. We can and must reject a false choice between innovation and civil liberties, and build power across movements to make sure technology truly works for people... EFF's founders understood something remarkably prescient: Technology and civil liberties would become inseparable. Now we all live digital lives, and the important digital rights issues that EFF has worked on since 1990 have become kitchen-table issues all around the world. EFF's founders understood that how technology is built, developed, used, and controlled deeply intersects with rights, justice, freedom, and democracy. EFF's unique combination of world-class lawyers, activists, and public interest technologists pursue change simultaneously in the courts, legislatures, companies, and our communities, and pierce through false choices. This integrated, intersectional approach, grounded in deep legal, policy, and technical expertise, is a linchpin in fighting and winning against some of the most powerful forces in the world — both governments and trillion-dollar companies. We defend people against unlawful government data collection and challenge license plate and face surveillance in our communities. We shape AI law and policy to protect civil liberties and support creativity and innovation. We push companies to strengthen encryption, fight to ensure you have the right to own what you buy, and build public interest technologies like Privacy Badger and Certbot that millions of people rely on every day. This work matters because it all answers the same question: Will technology empower or control us? Major battles the executive director sees on the horizon" "Challenge increasingly sophisticated government and corporate surveillance systems that endanger our rights, democracy, safety and security." "Preserve strong encryption and online anonymity." "Ensure AI is developed and used in ways that respect fundamental rights and works for those who build it, use it, and are affected by it." "Confront the concentrations of power that limit access to new creativity and defend the rights of developers to build and innovate." "To meet these challenges, we must not only utilize the powerful levers of successful litigation, smart policy interventions, and effective public interest technology tools. We must also build a broader movement that recognizes that fights on the digital terrain are integral to all our fights for rights and justice... Together, our EFF community can help broaden the public conversation about technology's role in society and continue building the collective power necessary to shape the future rather than react to it.... "I'm looking forward to meeting more of you at my first EFFecting Change livestream on August 12 with Cory Doctorow, and hope this conversation is just the beginning of finding new ways to work together..." The blog post ends by noting that "We need you and others in the fight. Please renew your membership, become a recurring monthly supporter, and introduce someone new to EFF by snagging them a gift membership. "Everything we accomplish — every lawsuit, every policy victory, every public interest technology tool, every campaign — is possible because people like you are committed to ensuring technology strengthens freedom, privacy, creativity, and opportunity for everyone. "The future we want and need will be built by people and movements working together to ensure technology empowers rather than oppresses. "Let's build that future together."

Read more of this story at Slashdot.

On this week’s show, we’re on the GeekWire deck for our annual founder open house, where we dig into Microsoft’s latest round of layoffs — including a major Xbox shakeup — and the surprising rise of hardware companies on the GeekWire 200.

Then we sit down with four guests to talk about how AI is reshaping how they build: 

• Jana Schuster of StackIQ, whose AI-native platform helps companies find redundancy in their software spending — like Rocket Money, but for business — with a small team.
• Blake Resnick and David Benowitz of Brinc Drones, whose mechanical engineers are now vibe coding their own prototypes;
• Boaz Ashkenazy of Shift AI, who’s setting up always-on agents and rethinking how we interact with AI tools.

Finally, this week’s GeekWire Trivia Challenge: how a longtime T-Mobile executive got his start in the wireless business, and the star-studded history of T-Mobile celebrity endorsers.

Stories mentioned:

• Microsoft cuts 4,800 jobs, about 2% globally, revamps salesforce and launches massive Xbox overhaul
• GeekWire 200 update: New unicorns and a hardware surge remake our list of top Pacific NW startups
• Former GitHub CEO’s startup Entire unveils its answer to the crush of AI coding agents
• Chicago software company plants flag in Seattle area as new leadership team seeks AI talent
• T-Mobile exec Mike Katz exits after 28 years, as carrier reshuffles top ranks and taps ex-AT&T leader

Audio editing by Curt Milton.

The post The Most Dangerous Lie In Project Plans: “We’ll Hire” first appeared on tig.log.

A few days ago I was chatting with Chuck Meyer (devrel for Algolia) and I casually mentioned, "It sure would be cool if Algolia had an easy way to turn my search index into an MCP server." He promptly responded, "Of course, you complete and utter dufus, which is why we already have that feature." (Not an exact quote.) This is exactly the kind of thing I love to hear. I've been using Algolia for my search here for years and honestly have not paid much attention to the new additions on their platform. That was a mistake. Let me show you how dang easy they made this.

First - what's Algolia?

Chuck, forgive me, I'm going to do a horrible job summarizing your entire company into a few sentences. Algolia provides search as a service. You create an index (or multiple) that represent what you want to search, whether it be textual content (like this blog) or ecommerce products (perhaps Dungeon Crawler Carl merch). Via multiple ways, you populate this index and keep it up to date (when you create/edit/delete content locally, you make a corresponding edit to your index).

Once the index is created (and tuned, you can do a lot to tune how your index works), you can then search it. My search is just one simple example, but it's one JavaScript library and a few lines of code.

That's basically it. Well no, there's a lot more, but at least for my implementation here, that's basically it.

Second - what's MCP?

MCP boils down to "if a person is needing to do some kind of action, an MCP server can tell the AI agent, hey, I handle that, just hand it off to me!" At Webflow, for example (sorry, you lay me off you don't get links), the MCP server handled API calls to your Webflow site and integrated with Cursor, Claude, and other agents. If you asked something like, "What Webflow sites do I have", because the Webflow MCP server was added to your agent, and authenticated, it could handle doing the appropriate API calls and returning it such that your agent could document the result.

For a documentation site, an MCP server can help you use free form questions about the docs and get responses in your AI agent.

Third - Ok, now what?

To enable it in Algolia, you log in to your dashboard and select the appropriate application (an application can have one or more indexes), and then click Generate AI in the navigation. In the sub nav, you'll have a section titled "MCP Servers / Public", and then in that UI, just click the "Create Public MCP Server" button.

On that UI, you can select what indexes and tools to enable. I've only got one "real" index, so I picked that and gave my server an incredibly useful and informative name:

On the next page, you can select which tools you want enabled. I picked everything, but I'm not using the Recommendation product so I probably should turn that off.

The end result is the URL to your MCP server. Mine is https://0FJBPN4K5D.algolia.net/mcp/1/vMOWpYc9RK6FuHnWxZcoyg/mcp. At this point, you follow your "usual procedure" on adding MCP to your tools. I tested in a few, including Cursor of course.

Actually using it...

Two big use cases come to mind for this:

• Externally, this creates a very powerful way for users to interact with your documentation. Most documentation for technical products already include this, including Algolia's docs of course. But the target user here is your audience.
• Internally, this could be very powerful. As a content writer, I can already use the existing Algolia search as a quick way to see, "did I blog about X", but with my MCP server, I can ask deeper questions, and even use it to help create new content.

I did some testing related to both of these scenarios, not terribly deep, but enough to be pretty impressed.

In agy, the Antigravity CLI (Google Gemini's models), I asked:

search Ray's mcp server for his opinion on React

And the response was near perfect:

&

""""""""

""

""""""""""

&""

""""""""

"deliberate exclusion" is the name of my Goth band.

In Cursor, I added the MCP server via the app settings and took the approach of the content creator. I asked:

using Ray's MCP server, what do you recommend for a new blog post?

And here's what Cursor and my MCP server came back with:

""

---

""

""""

---

""

""

---

""

• ""

---

---

In case you just skimmed, it literally suggested, as the second suggestion, the blog post I'm right now. Great minds, right?

TLDR

You can add an MCP server to Algolia indexes in 5 minutes. Actually less than that - it took me longer to remember what 2FA app I used with their dashboard.

Oh, and like most of Algolia's products, this falls into their Build tier which is free up to a certain amount of usage, which I've never hit. I've told Chuck before they are too damn generous with their free tier and thankfully they've ignored me.

Let me know what you think - are you using this? Are you using Algolia at all? Leave me a comment below as I'd love to hear from some folks who may already be using this.

A merge is a contract. The moment a change lands on main, every other team in the organization starts building on the assumption that it works. They branch from it, deploy on top of it, and debug their own failures, believing that what came before them was sound.

Most engineering organizations have never written that contract down. They have a pipeline that runs checks, and whatever the checks cover is what the merge promises. Ask what a green checkmark on a PR actually guarantees, and you rarely get a precise answer.

“A merge is a contract. The moment a change lands on main, every other team in the organization starts building on the assumption that it works.”

That vagueness used to be affordable. Code arrived at human speed, written by people who carried its context in their heads and stayed around after merging. Both of those conditions are now gone. 

Coding agents are multiplying PR volume, and an increasing share of changes arrive written by something that holds no lasting context at all. The industry has already noticed the consequence: in GitLab’s recent survey, 85% of respondents said the bottleneck has shifted from writing code to reviewing it. It is time to define the contract explicitly and then look honestly at where today’s pipelines fall short of it.

The four layers of confidence

Strip away tooling, and a change needs four things established about it before the rest of the organization builds on top of it.

First, it is well-formed. It compiles, passes lint and static analysis, and produces a deployable artifact.

Second, it is internally correct. Unit tests confirm the logic does what its author intended, in isolation, with dependencies stubbed out.

Third, it is compatible at its boundaries. It honors the API contracts its consumers depend on and the schemas its producers emit.

Fourth, and this is the layer that matters most in a distributed system, it behaves correctly against the real system. This means both functional and non-functional behavior: functionally, it returns the right results and honors the flows its neighbors expect; non-functionally, it holds up under real traffic in latency, error rates, resource usage, and backward compatibility. This is checked not against mocks or recorded fixtures, but against live versions of the services it calls and the services that call it, with real data shapes and real failure modes.

“The fourth is the expensive one. And the fourth is the only layer that catches the class of bug that actually hurts in microservices: the change that is locally correct and systemically wrong.”

The first three layers are cheap. They need no environment, they parallelize trivially, and they finish in minutes. The fourth is the expensive one, because it needs somewhere real to run. And the fourth is the only layer that catches the class of bug that actually hurts in microservices: the change that is locally correct and systemically wrong.

How the top layer slipped out of the gate

For most of the last decade, the fourth layer did not run before the merge. It could not. Establishing real-system behavior meant having an environment where every service was running, and such environments were scarce, expensive, and slow to create. Teams had one or two shared ones, contested and often broken.

So the industry made a quiet compromise. Merge on the first three layers, then discover system behavior afterward, in a shared environment where everyone’s unvalidated changes accumulate together. We built release management, freeze windows, and on-call rotations for pre-production largely to manage the consequences.

The compromise held, barely, at human pace. When a shared environment underwent ten changes, someone could reconstruct the timeline and find the culprit by asking around. The author was still nearby, context intact, ready to push a fix.

“It was never a principled position that system validation belongs after merge. It was a concession to an infrastructure constraint.”

Notice what the compromise actually was. It was never a principled position that system validation belongs after merge. It was a concession to an infrastructure constraint: pre-merge environments were impractical, so the gate shrank to fit what infrastructure could deliver.

Agents turn a compromise into a liability

Now change the arrival rate. Agents let a team of a hundred engineers produce PR volume that once required several hundred. Every one of those changes easily clears the first three layers, because those are precisely the checks agents are best at meeting. An agent iterates until the build is green, the units pass, and the contracts line up.

What an agent cannot do on its own is discover that its locally perfect change breaks a consumer three services away, because nothing in its feedback loop contains that consumer. It is not a hypothetical risk: analysis of open-source pull requests has found that AI-authored changes carry roughly 1.7 times as many issues as human-written ones, with logic and correctness errors overrepresented. If the merge gate stops at layer three, the gate is now systematically passing changes whose most dangerous failure mode was never examined.

Post-merge discovery breaks down for the same arithmetic reasons. Attribution over a shared branch was tolerable with ten changes in the batch. With fifty, most of them machine-authored and their authors context-free the moment the PR closed, a red suite becomes archaeology. Each additional change in the batch makes every failure more expensive to diagnose, precisely when batches are growing.

Both halves of the old compromise failed together. The gate passes changes it should not, and the after-the-fact safety net can no longer absorb them.

The constraint that justified all of this is Gone

Here is what changed on the infrastructure side. You no longer need a full copy of the stack to give one change a real system to run in.

The model that replaced duplication is straightforward. Your Kubernetes cluster runs a single shared, stable environment that contains the current version of every service, kept up to date by your standard deployment pipeline. When a PR needs validation, only the one or two services changed by that PR get deployed alongside it.

Isolation comes from routed traffic, not from duplicating the entire stack. Requests belonging to that PR carry a small identifying label in their headers. The routing layer reads the label and directs those requests to the changed services where they exist, and to the stable versions everywhere else. Every PR sees a complete, production-like system containing only its own changes, and dozens of PRs can validate simultaneously in the same cluster without affecting each other.

“Isolation comes from routed traffic, not from duplicating the entire stack. Every PR sees a complete, production-like system containing only its own changes.”

Because only the changed services start, such a lightweight ephemeral environment is ready in seconds. The fourth layer of confidence, the one that was too expensive to establish before merge, now costs about as much as a unit test run. This is the capability that platforms like Signadot provide, and it removes the last reason the merge gate stops at layer three.

Rewriting the contract

With the constraint gone, the pipeline reorganizes around a clean division of labor.

CI keeps the first three layers and gets faster by shedding everything else. Build, static analysis, unit tests, contract checks, done in minutes. Its job is to answer one question: is this a well-formed component?

The fourth layer moves into the PR itself. Every pull request, human- or agent-authored, gets its own ephemeral environment and runs its integration and end-to-end validation there, in parallel with every other open PR, before merge. The heavyweight post-merge integration stage, the one that made the whole pipeline slow, shrinks to a thin smoke check or disappears entirely.

The bigger change is in what the stages mean. The post-merge pipeline stops being where problems are discovered and becomes where their absence is confirmed. Discovery belongs before the contract is signed, not after.

The merge contract is then worth writing down, because every clause is enforced: this change builds, its logic is tested, its contracts are compatible, and it has run correctly against the real system. Green means validated, not probably fine.

The gate is a choice now

For years, the honest answer to what a merge should gate was whatever our environments could support. That answer is not accurate anymore. Per-change validation against a production-like system is no longer the expensive part of the pipeline, and code volume is no longer the limiting factor of software delivery. Validation is.

Teams adapting fastest to agent-assisted development are not the ones generating the most code. They are the ones who moved system validation to the left side of the merge, so that velocity arrives as shipped features instead of as a longer queue of unvalidated changes. The infrastructure permits it. The volume demands it. 

What remains is deciding what your green checkmark should mean and building the gate that enforces it. If you want to see that gate running against your own services, Signadot is a practical place to start.

The post 85% say code review is the new bottleneck. Here’s what the AI coding narrative leaves out. appeared first on The New Stack.