When the Trump administration announced yesterday that it was banning "advanced robotic devices" from entering the United States, the headlines were all about humanoids. But spying doesn't require legs - and neither does the FCC's robot ban.

The robot ban will sweep up robot vacuum cleaners too, FCC media relations director Katie Gorscak confirms to The Verge.

It's not coming for your existing Roomba, and companies can keep importing and selling already approved ones. But the government claims that future foreign robots pose a national security risk, and even robovac companies are suddenly being asked to commit to US manufacturing.

Whi …

Read the full story at The Verge.

Qualcomm reported that it earned a net income of $2 billion on revenues of $9.9 billion in the quarter ending June 28, 2026.

The post Qualcomm Revenues Decline 4 Percent to $9.9 Billion appeared first on Thurrott.com.

Microsoft reported that it earned a net income of $35.8 billion on revenues of $90 billion in the quarter ending June 30, 2026.

The post Microsoft Earnings Up 18 Percent to $90 Billion appeared first on Thurrott.com.

I’ve been playing around with AT Protocol. The posts on this site are now published to standard.site, and I’ve written a (very basic) WordPress plugin to display posts from my PDS on the Now page of this site.

As a developer, I’ve spent a good chunk of my working life building apps that stored things in databases, and dealing with the pain of migrating things from one database to another. With that background I’m excited about the ways atproto can solve the many pains I’ve encountered, but I also had a bunch of questions as I started to build things. For example, what do I store in my app and what goes into the PDS? What is the relationship between Bluesky and my data? What about big files like images or video?

If you are asking similar questions, I’d recommend listening to the recent episode of Syntax.fm with Dan Abramov, who very clearly articulates the answers to all of these questions, and more. I’d figured a lot of these things out, but after listening to Dan I’d be much more confident in explaining how this works to someone else, without a lot of handwaving!

If you are interested in what else I’m reading while learning about AT Protocol, I’ve just started a collection on Semble (another atproto app) to store interesting atproto links I find.

Starting November 2026 the AWS SDK for .NET will adopt a new annual schedule of adding and removing .NET build targets for the SDK.

In April 2025, we released V4 of the AWS SDK for .NET. A major goal of V4 was to modernize the .NET targets supported by the SDK so we can start taking advantage of modern high-performance .NET APIs. Since the V4 release, we have continued working with the community to take advantage of modern .NET and improve performance. Here are some performance improvement PRs from this year.

Now that V4 has established a modern foundation for the AWS SDK for .NET, we want to ensure it stays current. To do this, we are defining a predictable annual schedule for adding and removing .NET targets from the SDK.

Background

Across AWS there are many .NET NuGet packages published, and not all packages are considered part of the AWS SDK for .NET. The NuGet packages that are referred to as the AWS SDK for .NET are the core library AWSSDK.Core package and the individual AWS service packages that follow the naming pattern AWSSDK.<service-name> such as AWSSDK.S3 or AWSSDK.SQS.

Today, the V4 AWS SDK for .NET builds for the following targets:

• .NET Framework 4.7.2
• .NET Standard 2.0
• .NET Core 3.1
• .NET 8

The .NET Framework 4.7.2 target supports our .NET Framework customers. There is no end-of-life schedule for .NET Framework 4.7.2 from Microsoft, and we will continue to include this target for the foreseeable future. The .NET Standard 2.0 target is currently required for AWS Tools for PowerShell. That means the .NET Standard 2.0 target will also be included for the foreseeable future.

As documented by the Microsoft .NET support cycle modern cross-platform .NET has new major versions released every November, with every other year being an LTS (Long Term Support) release with 3 years of support and the alternating years being STS (Standard Term Support) with 2 years of support.

The case for a defined schedule

Until now, the SDK has only added a new .NET build target when there were new APIs in a .NET release that we wanted to take advantage of. For example, in 2023, we added the .NET 8 target to support Native AOT. This approach works because the SDK only depends on the base .NET runtime, which maintains very strong backward compatibility between releases.

However, this ad hoc approach has led to several issues:

• Customer confusion: Customers see in NuGet the latest target is .NET 8 and conclude that we haven’t updated the SDK for .NET 10, thinking we are behind.
• Unclear target removal: Without a defined schedule, old .NET targets linger with the SDK building technical debt that reduces the amount of effort that can be spent optimizing for the latest .NET version. These old .NET targets also make it harder for community members to build the SDK because it requires them to have versions well past end of support installed in their development environment.
• Delayed feature adoption: Without a schedule, new .NET features require a one-off decision about whether to add a new target, which can result in features being delayed indefinitely with no clear timeline for adoption.

A defined schedule addresses all of these issues by setting clear expectations for both our team and the users of the SDK.

The schedule

Every year, the SDK will be updated to add the build target for the current year’s release. We will attempt to align as closely as possible with the .NET November release cycle but may fall back to December depending on demands for other priorities, particularly for AWS re:Invent. The list of .NET targets will contain at most two LTS versions. If adding the new target would bring the total to three LTS versions, the oldest LTS is removed along with any STS versions that precede the new oldest LTS version.

This schedule gives an additional year of AWS SDK support from AWS after Microsoft has declared end of life for the .NET runtime. That is six months longer than the AWS SDK’s documented Maintenance policy because it provides a better alignment with the .NET yearly release cycle.

Each yearly update of .NET targets will be released as a new minor version of the SDK. In November 2026 we will release V4.1; in November 2027 V4.2; and so on. While the product version receives the minor version bump, the assembly version compiled into the binary will remain 4.0.0. The assembly version is part of the assembly identity. Other assemblies bind to this identity when referenced as a dependency during compilation. This means third-party libraries compiled against V4.0 will continue to work without recompilation because the assembly identity doesn’t change. This follows the same versioning practice we used with V3, ensuring backward compatibility for all third-party libraries.

Yearly target examples

The following examples show how the target list evolves each year. LTS versions are bolded and removed targets are struck out.

November 2026 (V4.1)

Because this is the first year the schedule applies, it will be handled as a special case. We will add the .NET 10 LTS version and remove .NET Core 3.1, which has been end of life since December 2022. By the schedule, we would also add the STS .NET 9 target, but adding a target at the time it is going out of support is unnecessary.

• .NET Framework 4.7.2
• .NET Standard 2.0
• .NET Core 3.1 (LTS) (Removed)
• .NET 8 (LTS)
• .NET 10 (LTS)
• .NET 11 (STS)

November 2027 (V4.2)

The .NET 8 target is removed because it would become a third LTS version.

• .NET Framework 4.7.2
• .NET Standard 2.0
• .NET 8 (LTS) (Removed)
• .NET 10 (LTS)
• .NET 11 (STS)
• .NET 12 (LTS)

November 2028 (V4.3)

Only the new .NET 13 STS is added and nothing is removed. You can continue to use .NET 10 and .NET 11 for another year even though they have reached Microsoft end of life.

• .NET Framework 4.7.2
• .NET Standard 2.0
• .NET 10 (LTS) (Microsoft end of life)
• .NET 11 (STS) (Microsoft end of life)
• .NET 12 (LTS)
• .NET 13 (STS)

November 2029 (V4.4)

The new .NET 14 LTS is added, triggering the removal of .NET 10 (the oldest LTS) and .NET 11 (STS older than the new oldest LTS).

• .NET Framework 4.7.2
• .NET Standard 2.0
• .NET 10 (LTS) (Removed)
• .NET 11 (STS) (Removed)
• .NET 12 (LTS)
• .NET 13 (STS)
• .NET 14 (LTS)

What this means for you

For most of you, this schedule is transparent. NuGet will resolve the best matching target for your application automatically. If you are using a .NET version that is no longer a build target in the latest SDK minor version, you have two options:

1. Stay on the previous SDK minor version. There will be no new releases for the previous minor version, so you will not receive any more SDK updates.
2. Update to the latest SDK version. NuGet will resolve to the .NET Standard 2.0 version of the SDK. For most use cases, .NET Standard 2.0 provides the functionality you need, though it will be missing some target-specific optimizations. For example, if you were using .NET 8 and updated to V4.2 in 2027 when .NET 8 was dropped, you would fall back to .NET Standard 2.0, losing Native AOT support and .NET 8+ performance optimizations.

Conclusion

This schedule brings predictability to how the SDK evolves with the .NET ecosystem. You will always know that the latest .NET version is supported by the end of the year of its release, and you will have a full year of additional AWS SDK support after Microsoft ends support for a .NET version.