This new alpha build has a quality of life improvement for the Move tools, support for CICP metadata, and good quality HDR->SDR tone mapping when opening HDR images with supported file types (including plugins).

You can read more about the CICP and HDR tone mapping support at https://x.com/rickbrewPDN/status/2072357433390047252 or https://bsky.app/profile/rickbrew.bsky.social/post/3mplx7ujotk2a

You can read more about 5.2 and what it includes by reading the release notes for the first alpha.

Change Log

Changes since 5.2 Alpha (build 9650):

• Changed: The Move Selection and Move Selected Pixels tools will now behave more intuitively when using constrained resizing (when holding shift). The aspect ratio that was used for a constrained resize used to be “locked in” when the selection was first drawn. The aspect ratio is now picked up when you start a constrained resize, and remembered until a non-constrained resize is performed.
• Added CICP metadata and color management support to the imaging framework 
  • See the CicpColorSpace struct in the PaintDotNet.Imaging namespace.
  • It has a CanColorTransformFrom property, indicating that it can be used as the source color space for the IImagingFactory.CreateColorTransformedBitmap or IBitmapSource.CreateColorTransformer extension methods.
  • It also has a CanCreateColorContext property that indicates when it is possible to create an IColorContext directly (ICC profiles can’t be generated for all CICP combinations) with the IImagingFactory.CreateColorContext(CicpColorSpace) extension method.
  • These can then be used by a FileType to provide a compatible image (“document”). Paint.NET’s color management is based on ICC color profiles, and some CICP color spaces (those involving PQ or HLG) cannot be expressed as an ICC color profile. Those images can, however, be transformed to an ICC-compatible color space with the aforementioned extension methods.
• Added HDR support to the new FileType plugin system
  • An image is tagged as HDR at load time via the IFileTypeDocument.Metadata.Hdr metadata section. Set IsHdrDocument to true, and optionally specify luminance data. The pixel format must be floating point (PixelFormats.Rgba64Half or PixelFormats.Rgba128Float), and the color context must be linearized.
  • Paint.NET does not yet support HDR editing, so it will convert the image to SDR with appropriate, high quality tone mapping.
• Added CICP support for AVIF, JPEG XL, and PNG.
• Added HDR tone mapping support for AVIF, HEIC, JPEG XL, JPEG XR, and PNG. If the image file being opened is HDR then it will be converted to SDR in an appropriate manner. Eventually Paint.NET will support HDR editing, this conversion process will go away, and the FileType plugins won’t even need to be updated.
• Added Rgb64, Rgb64Half, and Rgb128Float pixel formats for the imaging framework.
• Added a /disableCompositionSwapChain command-line parameter. This disables the use of Windows.UI.Composition, and should enable easier progress on the WINE effort.
• Fixed: When right-clicking on an image tab at the top, and then clicking on Open Containing Folder, two Explorer windows were being opened.
• Added a note in the installer about the new website address (https://www.paint.net). You can read more about it here: https://x.com/rickbrewPDN/status/2060397901650825238 or https://bsky.app/profile/rickbrew.bsky.social/post/3mmz73u6lzs2t

Download and Install

This build is available via the built-in updater as long as you have opted-in to pre-release updates. From within Settings -> Updates, enable “Also check for pre-release (beta) versions of paint.net” and then click on the Check Now button. You can also use the links below to download an offline installer or portable ZIP.

You can also download the installer here (for any supported CPU and OS), which is also where you can find downloads for offline installers, portable ZIPs, and deployable MSIs.

Hello Folks!

Welcome Back to AZ Update

A few years ago, Antony Bartolo and I launched a simple idea called AZ Update.

The goal was to provide a place where IT professionals could quickly understand what was changing in Azure, why it mattered, and what they should pay attention to next. The show became a weekly conversation focused on Azure news, infrastructure, operations, security, and the real-world impact of Microsoft's latest cloud updates.

Today, Azure is moving faster than ever.

Every week brings new services, platform capabilities, operational improvements, AI innovations, and architectural guidance. Keeping up is a full-time job. Most of us don't have time to read every blog post, release note, announcement, and documentation update.

That's why I'm bringing AZ Update back.

This time, as a weekly LinkedIn newsletter and this blog.  To be completely transparent I am using an AI Agent to parse the update list for any in the last 7 days, filter for Infra/Ops content and research product docs and help with the draft. I do review content and write the post myself.

Each edition will cut through the noise and focus on what matters most for cloud architects, platform engineers, infrastructure teams, SREs, security professionals, and IT operators. I'll share the Azure announcements worth your attention, explain why they're important, highlight practical implications, and point you to the resources that can help you go deeper.

Just a concise weekly briefing from one ITPro to another.

If your day-to-day involves building, operating, securing, or modernizing infrastructure in Azure, Azure Arc, AKS, hybrid environments, or the growing world of AI-powered operations, this newsletter is for you.

Welcome to the next chapter of AZ Update.

 

Here is week 1!

This week’s Azure infrastructure updates bring practical operational gains for security, platform reliability, disaster recovery, and identity-driven access control. Here is a detailed ITPro breakdown with implementation guidance you can use in production planning.

• Update #1 - Generally Available: Network Security Perimeter support for Azure Event Hubs
• Update #2 - Generally Available: Confidential Computing support for Azure Event Hubs Dedicated
• Update #3 - Generally Available: Support 5x churn in Azure Site Recovery
• Update #4 - Generally Available: Microsoft Entra ID-based access for Azure Blob Storage SFTP

Update #1 - Generally Available: Network Security Perimeter support for Azure Event Hubs

Why ITPros should care

Network Security Perimeter for Event Hubs changes how ITPros enforce connectivity boundaries around mission-critical event pipelines. Instead of depending only on isolated firewall rules per namespace, you can apply perimeter-aware controls that are easier to govern consistently across multiple services.

From an operations perspective, this is a service-level hardening improvement. It helps reduce accidental exposure and supports better audit conversations when security teams ask for clear evidence of allowed and denied paths.

Operational value

The operational value is stronger day-two control. You can standardise network access policy patterns for producer and consumer applications, reduce policy drift, and simplify incident investigations when unexpected traffic appears.

For production rollout, validate all dependencies first: private endpoints, DNS resolution, trusted service exceptions, managed identities, and cross-subscription network paths.

Real-world example with step-by-step guidance

1. Inventory current producer and consumer traffic flows, including private endpoints, DNS zones, and any trusted service allowances.
2. Deploy a pilot Event Hubs namespace with perimeter controls in non-production and mirror realistic ingestion and consumption traffic.
3. Apply least-privilege inbound and outbound perimeter rules, then execute end-to-end send/receive tests with representative message volume.
4. Review diagnostic logs for denies, refine exceptions only where business-justified, and capture evidence for change management.
5. Promote to production in stages with a rollback plan that restores previous network policy if message flow health degrades.

Technical details including code examples

Use the following sequence when validating that perimeter onboarding did not break data plane operations. The first command confirms your active Azure context, the second verifies endpoint reachability, and the third validates Event Hub metadata retrieval.

Run this safely in a test window before production enforcement. If connectivity and control-plane checks pass in test, repeat with production namespace read-only checks before enabling stricter policies.

az account show --output table Test-NetConnection <namespace>.servicebus.windows.net -Port 5671 az eventhubs eventhub show --resource-group <rg> --namespace-name <namespace> --name <eventhub> --output table

Expected outcome: TCP probe to port 5671 succeeds, and Event Hub metadata query returns without auth or network timeout errors. If probe fails, check DNS, NSGs, route tables, private endpoint linkage, and perimeter rule assignment scope.

Comprehensive Resources

• Azure update: Network Security Perimeter support for Azure Event Hubs
• Network Security Perimeter concepts
• Azure Event Hubs documentation
• Event Hubs networking and security

•  

Update #2 - Generally Available: Confidential Computing support for Azure Event Hubs Dedicated

Why ITPros should care

Confidential Computing support for Event Hubs Dedicated matters when ITPros operate regulated or high-sensitivity event streams. It extends protection expectations beyond encryption at rest and in transit, into stronger assurances during processing.

Compared with older architectures, this reduces the need for some compensating controls and helps security and operations teams align on platform-native protections for streaming workloads.

Operational value

Operationally, this strengthens trust boundaries for event ingestion platforms that feed analytics, SIEM, and business-critical automation. It also improves evidence posture for compliance reviews where data handling controls must be demonstrated end to end.

Before rollout, validate throughput impact, partition behaviour, client compatibility, and observability baselines so confidentiality controls do not create unexpected SLO regressions.

Real-world example with step-by-step guidance

1. Classify Event Hubs namespaces by sensitivity and select the first dedicated environment where enhanced confidentiality requirements apply.
2. Enable and validate in non-production with representative producer and consumer load, including peak and burst patterns.
3. Measure latency, throughput, and throttling trends before and after enablement to confirm workload behaviour remains acceptable.
4. Capture attestation and configuration evidence required by internal security governance or external auditors.
5. Roll out in waves by workload criticality, with rollback criteria tied to message latency, error rates, and throttling thresholds.

Technical details including code examples

This validation example confirms namespace details and metrics health so you can compare baseline vs post-change behaviour. The metrics query focuses on ingestion, egress, and throttling signals that commonly surface operational risk first.

Run with a least-privileged operations identity that can read namespace configuration and metrics. Avoid making unrelated changes while collecting baseline evidence.

az eventhubs namespace show --resource-group <rg> --name <namespace> --output jsonc az monitor metrics list --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.EventHub/namespaces/<namespace> --metric IncomingMessages OutgoingMessages ThrottledRequests --interval PT5M az account show --query user.name -o tsv

Expected outcome: namespace query succeeds, metrics return consistently, and no abnormal throttling spike appears after control changes. If results diverge, review dedicated capacity planning, partition strategy, RBAC scope, and workload profile fidelity.

Comprehensive Resources

• Azure update: Confidential Computing support for Azure Event Hubs Dedicated
• Event Hubs Dedicated overview
• Azure Confidential Computing overview
• Monitor Azure Event Hubs

•  

Update #3 - Generally Available: Support 5x churn in Azure Site Recovery

Why ITPros should care

Higher churn support in Azure Site Recovery is directly relevant for ITPros protecting write-intensive systems. It expands what can be replicated reliably, reducing DR exceptions for fast-changing workloads.

Compared with the previous operational envelope, this gives more room for modern transactional applications while still requiring disciplined capacity and replication health management.

Operational value

Operational value is improved DR coverage and better alignment between production write behaviour and recovery plans. Teams can protect more workloads without bespoke workaround architecture.

For production rollout, validate process server sizing, bandwidth headroom, cache storage performance, and sustained replication lag during peak change windows.

Real-world example with step-by-step guidance

1. Baseline current churn and replication lag for candidate workloads to identify which systems benefit most from the increased support.
2. Enable replication in a pilot for one high-churn workload and observe initial seeding and steady-state health.
3. Run test failover and reprotect to verify recovery objectives and operational runbook completeness.
4. Tune bandwidth and cache settings if lag increases during peak write intervals or backup overlap windows.
5. Onboard additional workloads incrementally and use replication health gates before each expansion wave.

Technical details including code examples

These commands are relevant for validating actual recovery readiness instead of configuration-only status. They expose protected item health and support controlled failover rehearsal.

Use a non-production network for test failover and document outputs so operations and business continuity stakeholders share the same readiness evidence.

az site-recovery fabric list --resource-group <rg> --vault-name <vault> -o table az site-recovery protected-item list --resource-group <rg> --vault-name <vault> --fabric-name <fabric> --protection-container <container> -o table az site-recovery recovery-plan test-failover --resource-group <rg> --vault-name <vault> --name <recoveryPlan> --network-id <testNetworkId>

Expected outcome: protected items remain healthy, lag remains within target, and test failover completes without consistency errors. If failures occur, inspect connectivity, process server capacity, cache throughput, and policy mappings.

Comprehensive Resources

• Azure update: Support 5x churn in Azure Site Recovery
• Azure Site Recovery documentation
• Monitor and troubleshoot Site Recovery
• Site Recovery capacity planning

•  

Update #4 - Generally Available: Microsoft Entra ID-based access for Azure Blob Storage SFTP

Why ITPros should care

This launch modernises SFTP access for Azure Blob Storage by bringing identity control closer to Microsoft Entra. ITPros gain stronger governance options than local-account-only models for many enterprise scenarios.

Operationally, the key change is identity lifecycle alignment: provisioning, review, and revocation can be managed with central identity processes instead of fragmented local credentials.

Operational value

The value is reduced credential sprawl, better auditability, and clearer access accountability across teams and external partners exchanging files over SFTP.

Before production, validate client compatibility, RBAC scope, network restrictions, access review cadence, and emergency break-glass procedures.

Real-world example with step-by-step guidance

1. Confirm SFTP is enabled on the storage account and validate networking model (public endpoint restrictions or private access path) matches policy.
2. Assign Entra-based permissions with least privilege and validate scope at storage account and container boundaries.
3. Test SFTP authentication and file operations using approved clients while collecting diagnostic logs for audit evidence.
4. Validate joiner-mover-leaver scenarios by changing membership and role assignments, then confirming access updates propagate correctly.
5. Roll out in stages by partner or workload segment with clear support ownership and incident response runbooks.

Technical details including code examples

This sequence verifies account capability and role assignment posture before user acceptance testing. It is useful for catching scope mistakes that often cause authentication-success/data-access-failure patterns.

Run safely by using a dedicated test identity and non-production storage account first; then repeat read-only validation in production before broad enablement.

az storage account show --name <storageAccount> --resource-group <rg> --query "{name:name,isSftpEnabled:isSftpEnabled,allowBlobPublicAccess:allowBlobPublicAccess}" -o jsonc az role assignment list --assignee <principalObjectId> --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<storageAccount> -o table az account show --query user.name -o tsv

Expected outcome: SFTP capability is enabled, expected role assignments are present, and test identity can perform allowed operations only. If sign-in works but file actions fail, inspect RBAC propagation delay, ACL/permission scope, and storage network restrictions.

Comprehensive Resources

• Azure update: Microsoft Entra ID-based access for Azure Blob Storage SFTP
• SFTP support for Azure Blob Storage
• Authorize blob data with Microsoft Entra ID
• Azure Storage security baseline

If you are planning adoption, start with one workload per update area, collect operational evidence, and standardise the validated pattern in your runbooks and IaC modules. That approach keeps change safe while accelerating delivery.

Cheers!

Pierre

Summary

In this episode, Andy sits down with Attia Qureshi, a coach and negotiation expert who is co-author, with John Richardson, of Never Settle. There's no shortage of great negotiation advice out there, yet in real conversations with real stakes and real emotions, that advice often fails to turn into action. This book tackles that gap between insight and habit.

Attia shares why emotions are not a distraction from negotiation but central to it, why getting clear about what you actually want is harder than it sounds, and how we leave value on the table without realizing it. You'll hear practical stories, from resetting a difficult relationship with a glass of lemonade to expanding the pie in a salary negotiation, plus small daily exercises for building resilience to rejection and learning to say no in a way that strengthens relationships rather than damaging them.

If you're looking for practical, doable ways to become a more confident negotiator and influencer, this episode is for you!

Sound Bites

• "You can get more by caring about what the other person needs and building a strong relational foundation."
• "People are not born amazing negotiators. They develop that skill over time, just like people are not born confident."
• "You have to practice that small step out in the real world where the stakes are low and build that skill day after day, month after month."
• "You and I have probably already negotiated half a dozen times today."
• "When someone gives us something, we want to return the favor."
• "New studies now show that 90 to 95% of decision-making comes from unconscious emotional processing."
• "So many of us quit before we even start."
• "But if we do have a goal and we do prepare for the conversation, our likelihood of success is double."
• "A good negotiation doesn't always mean getting 'yes' at the end of it."
• "I always tell my students, people can almost always help you. It depends on if they want to or not."

Chapters

• 00:00 Introduction
• 02:06 Start of Interview
• 02:17 Growing Up: Early Lessons in Conflict
• 07:10 Negotiation and Confidence Are Skills, Not Personality
• 08:04 Life Is Full of Everyday Negotiations
• 10:30 Why Negotiation Training Often Fails
• 12:30 Resetting a Difficult Relationship
• 17:20 Influence vs. Manipulation
• 22:33 Emotions, Fear, and Building Resilience
• 28:00 Using the Emotion Wheel
• 29:36 Getting Clear on What You Really Want
• 33:39 Expanding the Pie: Creating Value
• 40:50 The Power of Saying No
• 47:27 Teaching Kids to Negotiate
• 51:23 End of Interview
• 51:55 Andy Comments After the Interview
• 55:22 Outtakes

Learn More

You can learn more about Attia and her work at AttiaQureshi.com.

For more learning on this topic, check out:

• Episode 157 with Dr. Robert Cialdini. Known as the godfather of influence, his name came up several times during today's discussion, making this a great follow-up.
• Episode 412 with Scott Walker. A former Scotland Yard hostage negotiator who shares a lot of practical lessons about influence.
• Episode 385 with Vanessa Patrick. She wrote one of the best books on how to say no, a fitting companion to today's conversation.

Chat with PMeLa

You can chat directly with PMeLa—the podcast's AI persona—to get episode recommendations and answers to your project management and leadership questions. Visit PeopleAndProjectsPodcast.com/PMeLa to chat with her.

Join Us for LEAD52

I know you want to be a more confident leader–that's why you listen to this podcast. LEAD52 is a global community of people like you who are committed to transforming their ability to lead and deliver. It's 52 weeks of leadership learning, delivered right to your inbox, taking less than 5 minutes a week. And it's all for free. Learn more and sign up at GetLEAD52.com. Thanks!

Thank you for joining me for this episode of The People and Projects Podcast!

Talent Triangle: Power Skills

Topics: Negotiation, Influence, Leadership, Project Management, Reciprocity, Emotional Intelligence, Resilience, Saying No, Stakeholder Management, Relationship Building, Value Creation, Confidence

The following music was used for this episode:

Music: Quantum Sparks (Full Version) by MusicLFiles
License (CC BY 4.0): https://filmmusic.io/standard-license

Music: Tropical Vibe by WinnieTheMoog
License (CC BY 4.0): https://filmmusic.io/standard-license

Download audio: https://traffic.libsyn.com/secure/peopleandprojectspodcast/514-AttiaQureshi.mp3?dest-id=107017

I killed a SaaS product a few years ago. Not because the idea was wrong, and not because the market wasn’t there. Because the platform underneath it changed ownership, repriced its API overnight, and what had been a viable foundation rapidly became an unworkable cost centre.

I’ve been watching the AI space closely ever since.   I’m seeing the same structural pattern forming -just with larger numbers, more VC money, and bigger stakes.

This post isn’t about what I lost. It’s about what I think is coming for a lot of people building on LLM APIs right now, and what you can do about it before it happens to you.

Some Background, How I Know What a Rug Pull Feels Like

In 2013 I started building a product called Social Opinion. The idea was to use NLP and sentiment analysis to mine social data for real-time signals of commercial intent, then enable marketers to act on those signals with targeted advertising.

Right message, right person, at the right time.

It worked well enough that the platform I’d built on top of invited me to their HQ’s in San Francisco and New York.

They gave me access to internal alpha APIs. They told me in writing that they were “invested in this partnership” and intended to “move forward at full speed.”

A few years later, under new ownership, they killed free API access with almost no notice. The product I’d built entirely on top of that access was no longer viable. I shut it down.

I’m not telling that story for sympathy. I’m telling it because the dynamics that played out are almost identical to what’s happening in AI tooling right now, and most people building in this space haven’t lived through the other side of it yet.

~

What’s Happening in AI Right Now

Many products are being built on top of Open AI, Anthropic, Google, and other LLM providers. The access is cheap. In some cases it’s nearly free, backed by organisations willing to absorb losses while pursuing long-term strategic goals.

That’s a deliberate strategy. Get builders dependent on your infrastructure. Get end users habituated to the experience. Then, once the ecosystem is locked in, figure out the economics.

None of that is secret. The providers aren’t hiding it. But there’s a gap between knowing something abstractly and actually pricing it into your product decisions, and right now, a lot of teams are building as if today’s API costs are a permanent feature of the landscape rather than a temporary one.

~

The Specific Risks Worth Naming

Some risks to consider and worth noting:

• Pricing isn’t static. Today’s API costs reflect a market that’s still expanding rapidly, with providers prioritising growth, adoption, and market share alongside profitability. As those priorities evolve, pricing will too. If your product’s unit economics only work at today’s rates, you’re relying on an assumption you don’t control. Know where your break-even point is before someone else decides it for you.
• Ownership and strategy changes. I know what it looks like when a platform changes hands and the new owners have different priorities. Models get acquired. Labs get bought. Priorities shift. The relationship you have with a platform today is only as stable as that platform’s ownership and incentive structure  -neither of which you control.
• Model deprecation. The specific model your product is tuned around may not exist in two years. Providers are moving fast, retiring older versions, and the prompt engineering, fine-tuning, or integration work you’ve done against a specific version doesn’t automatically transfer. This isn’t hypothetical -it’s already happening.

 

What you’re allowed to build on top of a given API can change. Use cases that are permitted today may be restricted tomorrow. Output you’re allowed to store, repurpose, or sell downstream is subject to terms that can be updated with relatively little notice.

~

This Isn’t an Argument Against Building

It would be easy to read this as “don’t build on LLM APIs.” That’s not what I’m saying. The capabilities available right now are remarkable, and the right time to build with them is while the access is good and the cost is manageable.   I am building with these tools too.

The argument is about how you build. Specifically, about whether you’re designing for the risk that already exists, or pretending it doesn’t.

~

What I’d Do Differently

Having been burned before, here are some things to approach differently:

• Abstract the model layer from day one. Your application logic should not be tightly coupled to a specific provider or model. If switching from OpenAI to Anthropic to an open-source alternative requires a significant rewrite, you’ve already lost flexibility you’ll eventually need.
• Model your unit economics at 10x current API cost. If the product stops working at ten times today’s inference price, that’s a risk you’re carrying. Know where the break-even is. Have a plan for what you do when — not if — costs move.
• Watch where the VC money actually is. The providers keeping prices low are doing so with someone else’s capital. Track the funding cycles, the runway signals, the revenue disclosures. When the subsidised period ends, it tends to end fast.
• Don’t mistake a good relationship for a contractual one. A dedicated support contact, early access to new models, enthusiastic partnership emails — these are signs of goodwill, not protection. Goodwill is not transferable when ownership changes.
• Keep an eye on open-source alternatives. The gap between frontier closed models and capable open-source alternatives is narrowing. Building with an awareness of what you could run yourself — if you had to — changes the risk calculation significantly.

 

Make sure something survives the product. This might be skills, architecture patterns, domain knowledge, or customer relationships.  The things that compound regardless of what happens to any specific product or API.

~

Transparency

I didn’t fully apply these rules when I was building Social Opinion. I knew platform risk was a concept. I didn’t treat it as an active design constraint. The relationship with the platform felt strong enough that I underweighted what would happen if it changed.

What did I get out of it?

The NLP work, the real-time architecture, the understanding of intent detection at scale, the experience of presenting a product at a global competition -none of that went away when the product did. That part I did right, even if accidentally.

But I’d have built the product differently if I’d genuinely designed for the risk from the start. If I were starting something today on top of LLM credits that exist because a hyperscaler is buying market share, I’d be asking harder questions about what the product looks like when those credits cost ten times as much.

Whether it happens in two years or ten is impossible to know. The point is that platform incentives eventually change.

But platforms eventually optimise for their own economics, not yours.

If you’re building on someone else’s infrastructure, design as though that day will come.

~

Python 3.14 is the most consequential CPython release in years for teams that care about parallelism, safer string handling, and cleaner typing workflows. Whether you're on Fedora, Red Hat Enterprise Linux (RHEL), CentOS Stream, a Red Hat Universal Base Image (UBI) container, a Red Hat Hardened Image, or Red Hat OpenShift, this post tells you what changed in the language, where you can run it today, and what you need to change in your projects.

This post discusses the headline features in Python 3.14, then maps them to how Red Hat ships and supports the interpreter across the platforms you already use—including RHEL 10.2 and RHEL 9.8, both of which introduced the Python 3.14 stack in the same release wave (early 2026).

Where Python 3.14 fits in the Red Hat ecosystem

Python 3.14 is available across the full Red Hat stack. The delivery mechanism differs by platform:

• Fedora: The upstream community project, FedoraFedora Linuxnbsp;Linux is the fast-moving distribution where Red Hat and contributors integrate new upstream software before it lands in RHEL. Read What is Fedora? for how it relates to CentOS Stream and RHEL.
• CentOS Stream: CentOS Stream is the continuously delivered Linux distribution that sits between Fedora and RHEL it's the development platform where RHEL minor releases are built. Read What is CentOS Stream for more information, or read the project documentation.
• Red Hat Enterprise Linux (RHEL): The production foundation or deployments requiring a hardened security posture, long-term stability, and enterprise support. RHEL documentation describes the repositories.
• Red Hat Universal Base Image (UBI): Red Hat Universal Base Images (UBI) are OCI-compliant, freely redistributable container base images built from RHEL content, with their own license terms so you can build and ship containers outside Red Hat platforms. The Red Hat Ecosystem Catalog — UBI lists ubi9, ubi10, minimal, micro, and init variants. Read Types of container images to learn how UBI relates to other image types.
• Red Hat Hardened Images: Red Hat Hardened Images are a no-cost catalog of minimal, distroless-style container images built from Red Hat's pipeline—only what the application needs at runtime, with separate builder images for compile and dnf steps. For a product overview, read Hardened, ready, and no cost. For hands-on guidance, read Build and deploy secure minimal containers with Red Hat Hardened Images and Plan your image strategy. The image catalog is located at images.redhat.com.
• Red Hat OpenShift: The cloud-native application platform used to scale and orchestrate your containerized Python workloads.

Red Hat does not change the default system Python during a RHEL minor release cycle. On RHEL 10, the default remains Python 3.12 (python3 in BaseOS) for the full RHEL 10 lifecycle. Python 3.14 arrives as an additional AppStream channel package you install alongside the default—first in RHEL 10.2, alongside the same stack on RHEL 9.8. On RHEL 9, python3.14 is a dedicated application stream parallel to existing Python 3.9 and Python 3.12 choices. The CodeReady Linux Builder (CRB) channel also contains some Python content as noted below.

This AppStream model is intentional: platform stability for OS tooling, versioned choice for your applications.

Platform	How Python 3.14 is delivered	Typical install / use
FedoraFedora Linuxnbsp;Linux	python3.14 RPM (Fedora 43+); optional free-threading; Fedora container images on Quay	sudo dnf install python3.14Python 3.14 is the system python3 on Fedora 43 and later, installed by default on standard Fedora images.
CentOS Stream 9 / 10	python3.14 in AppStream (and CRB on Stream 9); mirrors upcoming RHEL minors	sudo dnf install python3.14 on Stream 9 or 10
RHEL 10.2	python3.14 AppStream; python3.14-freethreading (CRB repo); RHSA-backed updates	sudo dnf install python3.14
RHEL 9.8	python3.14 application stream (non-modular RPM naming)	sudo dnf install python3.14
Red Hat UBI	Install python3.14 into UBI using AppStream repos, or use RHEL/Python runtime images built for containers	FROM registry.access.redhat.com/ubi9/ubi and dnf install python3.14, or pull rhel9/python-314
Red Hat Hardened Images	Install minimal python images with 3.14 builder and runtime tags from images.redhat.com	Multi-stage build: hi/python:3.14-builder → hi/python:3.14
Red Hat OpenShift	S2I and cluster workloads using the images above	registry.redhat.io/rhel9/python-314, UBI-based builds, or Hardened Images

Availability for FedoraFedora Linuxnbsp;Linux

• On the host: python3.14 RPMs in Fedora 43 and later (maintained in Fedora Packages — python3.14), including free-threading subpackages as they are packaged for each release.
• In containers: quay.io/fedora/python-314 and quay.io/fedora/python-314-minimal (listed in the s2i-python-container image matrix).

Fedora is the earliest place to prototype Python 3.14 features on a full desktop or server OS. Treat it as a preview of what will flow toward CentOS Stream and RHEL, not as a production support target unless your organization standardizes on Fedora directly.

Availability for CentOS Stream

• CentOS Stream 9: python3.14 packages in AppStream and related build tooling in CRB (see Stream 9 package sets).
• CentOS Stream 10: python3.14 in AppStream (for example, python3.14-3.14.x el10 builds), aligned with RHEL 10-oriented content.
• Container images on Quay: quay.io/sclorg/python-314-c9s, quay.io/sclorg/python-314-c10s, and matching -minimal variants as presented in the s2i-python-container table. This is useful for CI that must match Stream before RHEL minor releases ship.

Use CentOS Stream to validate workloads against upcoming RHEL behavior. Migrate production to RHEL 9.8 or RHEL 10.2 when you need subscription-backed errata and support.

RHEL 10.2 and RHEL 9.8: What is the same, what differs

Both minor releases ship python3.14 for application development, but the surrounding platform context differs:

	RHEL 10.2	RHEL 9.8
System default Python	3.12 (python3)	3.9 (platform python3, with other versions from application streams)
How you invoke 3.14	python3.14 (AppStream, non-modular RPM naming)	python3.14 (application stream)
Free-threading	python3.14-freethreading available (CRB)	python3.14-freethreading available (CRB)
In-place upgrade path	RHEL 9.8 to 10.2 is a supported Leapp upgrade path (with arch requirements)	Stay on 9.x or plan jump to 10.2
Container images	Release notes list rhel9/python-314 images with other updated runtimes	Same image names documented for 9.8

If you standardize on Python 3.14 in 2026, decide whether the deployment target is RHEL 9.8 (long-running 9.x estates) or RHEL 10.2 (new 10.x adopters and 9.8→10.2 upgrades). Test on the same major RHEL you run in production.

 

Availability for Red Hat Universal Base Image (UBI)

UBI does not replace versioned Python runtime images. You have two common patterns:

1. Add Python 3.14 to a UBI base: Start from registry.access.redhat.com/ubi9/ubi or ubi10/ubi, enable UBI AppStream repositories, and dnf install python3.14 (the same RPM names as on RHEL when repositories are configured in the build).
2. Use RHEL Python runtime images: These are subscription-oriented application images, not generic UBI bases, documented in RHEL release notes and the catalog. For example:
   • registry.redhat.io/rhel9/python-314 (full)
   • registry.redhat.io/rhel9/python-314-minimal
   • registry.redhat.io/rhel10/python-314-minimal

Authenticate to registry.redhat.io as in Red Hat Container Registry authentication before pulling subscription-only images.

UBI fits custom Dockerfiles/Containerfiles you redistribute broadly, whilerhel9/python-314 fits entitled RHEL/OpenShift pipelines that need a maintained Python stack.

Availability for Red Hat Hardened Images

• Runtime: registry.access.redhat.com/hi/python:3.14 (minimal production image)
• Build stage: registry.access.redhat.com/hi/python:3.14-builder (includes package manager and tools for pip install, compiling extensions, and so on)
• FIPS environments: hi/python:3.14-fips and 3.14-fips-builder where required

Hardened Images target production security posture (small attack surface, rapid CVE remediation). Pair them with Python 3.14 when you want 3.14 language features without shipping a full UBI layer in the final image.

Practices that work everywhere

• Call python3.14 (not just an unversioned python3) in shebangs, Makefiles, and CI so you don't invoke Python 3.12 on RHEL 10 or 3.9 on RHEL 9.
• Keep project dependencies in a venv (python3.14 -m venv .venv) or container image, not mixed with system site-packages.
• On RHEL, subscribe and use official builds so you receive security errata targeting python3.14 RPMs for both -el9 and -el10_2 rather than various upstream compiles.

For Red Hat OpenShift, choose an image strategy explicitly:

• RHEL runtime images (rhel9/python-314): Documented in RHEL 9.8 and RHEL 10.2 release notes. Use with entitled registries.
• UBI-based builds: UBI plus python3.14 RPMs when you control the Containerfile and need redistribution-friendly bases.
• Hardened Images: Red Hat Hardened Images hi/python:3.14 when minimal production images matter most.

Avoid generic upstream-only Python images on cluster if your policy requires Red Hat-maintained errata paths.

Release highlights: Language and runtime

The official What's new in Python 3.14 documentation is the authoritative reference. Below is a developer-oriented tour focused on changes you are likely to feel in day-to-day Linux work.

Deferred evaluation of annotations (PEP 649, PEP 749)

Type annotations are no longer evaluated eagerly at function and class definition time. They are stored and evaluated when needed, which:

• Improves import and startup time for annotation-heavy codebases.
• Makes forward references work without from __future__ import annotations` in most cases.
• Introduces annotationlib for introspecting annotations as values, forward refs, or strings.

If you relied on annotations executing side effects at import time (uncommon but possible), audit those modules. Most Django, FastAPI, and dataclass-heavy apps benefit with no code changes.

Template string literals: t-strings (PEP 750)

t-strings use a t"..." prefix (like f-strings) but produce a Template object with separate static and interpolated parts instead of a single str. That enables safe, explicit processing—SQL builders, HTML escaping, structured logging—without regex-parsing f-string output.

from string.templatelib import Template, Interpolation# t-strings produce a Template object, not a string.# Pass it to a renderer that escapes each Interpolation value.user_input = "<script>alert('xss')</script>"tpl = t"<p>Hello, {user_input}</p>"# html = my_html_renderer(tpl) # renderer escapes user_input before inserting

For web and data services on RHEL or Red Hat OpenShift, t-strings are a pattern to adopt gradually: They shine when you own the rendering pipeline and want f-string ergonomics without f-string pitfalls.

Multiple interpreters in the standard library (PEP 734)

CPython has supported subinterpreters for years through the C API. Python 3.14 exposes concurrent.interpreters to Python code. Isolated interpreters can run in one process with less overhead than multiprocessing for some CPU-bound designs, and concurrent.futures.InterpreterPoolExecutor (in concurrent.futures) offers a familiar pool API.

Caveat for production on Linux: Many PyPI wheels with C extensions are still catching up to multi-interpreter and free-threaded builds. Test your dependency tree before betting a service on interpreter pools.

Free-threaded Python is supported upstream (PEP 779)

Python 3.13 introduced an experimental free-threaded build (GIL optional). Python 3.14 promotes the free-threading to officially supported status by the upstream community —a major step toward true multi-core parallelism in pure Python and in extensions that declare compatibility. While Python 3.14 is the first version where free-threaded Python is officially supported upstream, it is still considered optional and non-default.

Important: Free-threaded PythonPthon has not yet had sufficient testing against enterprise environments, so Red Hat has added it to the CRB repository for developers to work with until such time as full enterprise support can be guaranteed.

On Fedora and RHEL, free-threading is packaged separately. On RHEL 10.2, install python3.14-freethreading (standard and free-threading builds are split, similar to Fedora's packaging model). RHEL 9.8 also ships the python3.14 stack—confirm free-threading package names for your architecture in the 9.8 package manifest. That lets you opt in per application without changing the OS default (python3 remains Python 3.12 on RHEL 10, or Python 3.9 on RHEL 9).

When it helps: CPU-bound parallel workloads where threads previously serialized on the GIL.

When to wait: Libraries in your stack that are not yet tested on free-threaded builds (NumPy, pandas, and others are improving, but you should verify for your versions).

compression.zstd in the standard library (PEP 784)

Zstandard compression is available as compression.zstd, reducing the need for external zstandard bindings for many log archival, artifact cache, and data pipeline tasks—common in CI runners on CentOS Stream and Fedora.

Syntax and ergonomics

• PEP 758: except ValueError, TypeError: Allows catching multiple exception types without parentheses around the tuple.
• PEP 765: return, break, and continue that exit a finally block now emit a SyntaxWarning, so audit any finally blocks using these before upgrading.
• Improved error messages and syntax-highlighted REPL (including color in some standard-library CLIs) are small changes that add up during interactive debugging on remote RHEL hosts.

Asyncio introspection

Asyncio gains better introspection and debugging support, useful for microservices on OpenShift where you need to understand task stalls without attaching a heavy profiler.

Platform and packaging notes

• PEP 776: Emscripten is tier-3 supported (relevant if you target WASM toolchains from Fedora build roots).
• JIT (experimental) is included in all Windows and macOS official CPython 3.14 binaries (opt-in with PYTHON_JIT=1, disabled by default). Linux builds from Red Hat/Fedora follow distro packaging policy, so do not assume JIT is enabled in python3.14 RPMs until your release notes say so.
• PEP 761: PGP signatures discontinued for upstream CPython releases. Verify artifacts through your distro or Red Hat errata channels instead.

Feature deep dive: What Linux developers should try first

Here are some of the particulars you ought to address first.

Typing and application frameworks

If you maintain libraries or large apps on RHEL 9.8 or RHEL 10.2:

1. Remove redundant from __future__ import annotations where you only added it for forward refs.
2. Run your mypy/pyright CI job unchanged first, then explore annotationlib if you generate schemas from types.
3. Re-measure cold start for container entrypoints on OpenShift. Annotation deferral can save milliseconds to seconds on huge codebases.
4. On RHEL 10.2, remember dnf install python3-* targets Python 3.12 unless you version the package name (python3.14-* add-ons).

Concurrency on real hardware

Plan a benchmark branch: Standard python3.14 compared to python3.14-freethreading on RHEL 10.2 (or your 9.8 arch if free-threading RPMs are listed).Use the same workload, and the same dependency pins. Memory usage is often higher on free-threaded builds, but measure before changing production Deployment resource limits on Red Hat OpenShift.

Containers on Red Hat OpenShift

If you're running containers on Red Hat OpenShift, keep these points in mind:

• RHEL runtime image: registry.redhat.io/rhel9/python-314 or rhel9/python-314-minimal (see catalog — Python 3.14 Minimal).
• UBI + RPM: Build from ubi9/ubi or ubi10/ubi and install python3.14 when you need a custom image you can redistribute.
• Hardened Images: registry.access.redhat.com/hi/python:3.14-builder → hi/python:3.14 for minimal runtime (see build custom application images).
• S2I: s2i-python-container documents 3.14 images for RHEL 9 and 10, CentOS Stream 9 and 10, and Fedora.
• Security: Pin digests, and rebuild for Red Hat Security Advisory (RHSA) and Hardened Image catalog updates.

Data and platform engineering on RHEL 9.8 and RHEL 10.2

• Use compression.zstd for log shipping agents and artifact caches on hosts and in CentOS Stream 10 CI that gates RHEL 10.2 deploys.
• For UUID workloads, Python 3.14 adds uuid.uuid6(), uuid.uuid7(), and uuid.uuid8() (see RFC 9562), enabling time-sortable UUIDs, which are handy for database primary keys in distributed services without extra dependencies.
• Apply dnf update python3.14 on both releases to pick up CVE fixes using RHSA-backed advisories.

Porting from Python 3.12 or 3.13

Read Porting to Python 3.14 and the Python 3.14 changelog deprecations section. Priority checks for Red Hat platform teams:

Area	Action
Annotations	Search for metaclass or typing hacks that assumed eager evaluation
Deprecated modules	Run tests with PYTHONWARNINGS=default in CI (Fedora/CentOS Stream pipelines)
C extensions	Rebuild wheels for Python 3.14 ABI, verify manylinux vs internal wheelhouse
Multiprocessing vs interpreters	Prototype with InterpreterPoolExecutor only after extension audit
Free-threading	Treat as opt-in, and run regression suite on python3.14-freethreading if you enable it

On RHEL 9.8 and RHEL 10.2, stay on python3.14 RPM updates (3.14.1 → 3.14.4, and so on) through dnf update so you pick up CVE fixes without rebasing your own compile.

Support lifecycle and planning

Upstream CPython 3.14 follows the annual release cadence (PEP 602). Plan platform alignment roughly as:

• Fedora: Earliest consumption and widest package set (including free-threading splits).
• CentOS Stream 10: Validate stacks before locking RHEL 10.2 production baselines.
• RHEL 9.8: First 9.x minor with the python3.14 application stream—good for estates staying on RHEL 9 on Python 3.14 through 2029 when support for Python 3.14 application stream ends (RHEL 9 itself is supported through 2032). The python3.14-freethreading package is available in the CRB repository. Application Streams do not receive EUS or ELS coverage, so after May 2029, migrate to a newer Python AppStream.
• RHEL 10.2: First 10.x minor with python3.14 AppStream for new RHEL 10 deployments and 9.8 to 10.2 upgrades. System remains on Python 3.12, and python3.14-freethreading is available in the CRB repository.
• Red Hat OpenShift: Coordinate cluster version, builder image, and rhel9/python-314 image tags with your platform team; image updates track RHEL errata.

Conclusion

Python 3.14 brings deferred annotations, t-strings, standard-library subinterpreters, official free-threading, and compression.zstd—features that matter for modern services. Within the Red Hat ecosystem, you can adopt these features through python3.14 RPMs on the upstream Fedora project and CentOS Stream. For production, Red Hat Enterprise Linux 9.8 and 10.2 deliver Python 3.14 through AppStream (with free-threading available on RHEL 9.8 and 10.2 in CRB). This delivery allows you to install python3.14 for your workloads without replacing or impacting the system python3 that the base OS tools rely on (Python 3.12 on RHEL 10 and Python 3.9 on RHEL 9). This consistent footprint extends to containerized environments using Red Hat Universal Base Image (UBI), Red Hat Hardened Images (hi/python:3.14), and Red Hat OpenShift.

Start with a versioned virtual environment or a pinned container, run your test suite, and only then experiment with free-threading or interpreter pools. That sequence keeps your development predictable while still letting you use the most capable CPython release yet. By standardizing on official Red Hat Python builds across this pathway, you reduce operational overhead, maintain a supported, patched security baseline, and deploy with confidence on the platform you already trust.

The post New features in Python 3.14 appeared first on Red Hat Developer.

Whenever I write about vertical slice architecture, the same question shows up in my inbox: "OK, but how do I test it?"

It's a fair question, because the testing habits most of us learned grew up alongside layered architecture. Mock the repository, test the service, assert the service called the repository. In VSA there is no service layer to test and often no repository to mock. The slice is a request, a handler, and the database work, living together in one place.

People read that and conclude vertical slices are hard to test. It's the opposite. You just have to stop testing layers and start testing what the slice actually is: a feature.

The Slice Is the Unit

A vertical slice has a natural contract: a request goes in at the top, and an observable outcome comes out the bottom (a response, plus rows in a database, plus maybe a message on a bus).

So test exactly that contract:

One slice = one focused set of tests that exercise it from the endpoint to the database.

Not a handler test with a mocked DbContext. Not an endpoint test with a mocked handler. The whole slice, through its public entrance, against a real database.

If you're coming from layered architecture, this feels like "just integration tests". It is, and that's the point: the test pyramid is a lie for this kind of code. A slice test catches broken SQL, broken mapping, broken validation, and broken routing in one go, none of which a mocked-out unit test can see.

The Setup That Makes It Practical

Two pieces make slice tests fast enough to run constantly: WebApplicationFactory to host the app in-memory, and Testcontainers for real infrastructure in Docker. My examples use Postgres, but the same approach covers Redis, a message broker, or anything else the slice touches.

The shared fixture boots both once for the whole test class:

public class ApiFixture : WebApplicationFactory<Program>, IAsyncLifetime
{
    private readonly PostgreSqlContainer _db = new PostgreSqlBuilder()
        .WithImage("postgres:17-alpine")
        .Build();

    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        builder.UseSetting("ConnectionStrings:Database", _db.GetConnectionString());

        // Fake only what you don't own (payment gateways, email providers)
        builder.ConfigureTestServices(services =>
            services.AddSingleton<IEmailSender, FakeEmailSender>());
    }

    public async Task InitializeAsync()
    {
        await _db.StartAsync();

        // Create the schema once the container is up. If your app already
        // migrates on startup, drop this and let the host do it.
        using var scope = Services.CreateScope();
        await scope.ServiceProvider
            .GetRequiredService<AppDbContext>()
            .Database.MigrateAsync();
    }

    public new Task DisposeAsync() => _db.DisposeAsync().AsTask();
}

And a slice test reads like a description of the feature:

public class CreateShipmentTests(ApiFixture api) : IClassFixture<ApiFixture>
{
    [Fact]
    public async Task Creates_shipment_and_persists_it()
    {
        var client = api.CreateClient();
        var orderId = Guid.NewGuid();

        var response = await client.PostAsJsonAsync("/shipments", new
        {
            OrderId = orderId,
            Address = "123 Main Street"
        });

        response.StatusCode.Should().Be(HttpStatusCode.Created);

        // A fresh scope, so we read what actually persisted.
        using var scope = api.Services.CreateScope();
        var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        var shipment = await db.Shipments.SingleAsync(s => s.OrderId == orderId);
        shipment.Status.Should().Be(ShipmentStatus.Pending);
    }

    [Fact]
    public async Task Rejects_a_shipment_without_an_address()
    {
        var client = api.CreateClient();
        var orderId = Guid.NewGuid();

        var response = await client.PostAsJsonAsync("/shipments",
            new { OrderId = orderId, Address = "" });

        response.StatusCode.Should().Be(HttpStatusCode.BadRequest);

        // The 400 is only half the contract; make sure nothing slipped through.
        using var scope = api.Services.CreateScope();
        var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        (await db.Shipments.AnyAsync(s => s.OrderId == orderId)).Should().BeFalse();
    }
}

Two small choices in the assertion carry weight. It reads through a fresh scope, so you see what actually persisted, not what EF Core's change tracker still holds in memory. And it filters by the OrderId you sent instead of grabbing "the one row", which keeps the test truthful even when it isn't the only thing writing to the database.

Notice what the test doesn't know: whether the slice uses MediatR or plain endpoints, EF Core or Dapper, one file or three. That ignorance is the payoff. You can refactor everything inside the slice without touching a single test. Tests coupled to layers punish refactoring; tests coupled to behavior enable it.

A note on speed, because it's the usual objection: the container and the host start once per test class, not per test. On my machine a suite like this runs in seconds, and my Testcontainers best practices cover the reuse tricks that keep it that way as the suite grows.

That database is shared, though, and it's worth saying out loud: every test in the class writes to the same Postgres, and the state carries over. Filtering by OrderId (like above) keeps individual assertions honest, but anything that counts rows or checks ordering wants a clean slate. A small helper on the fixture wipes the tables between runs, no extra libraries required:

public async Task ResetAsync()
{
    using var scope = Services.CreateScope();
    var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();

    // Add each table the slice touches.
    await db.Shipments.ExecuteDeleteAsync();
}

Then call it at the top of each test. xUnit runs the tests in a class sequentially, so a reset at the start hands each one a clean slate:

[Fact]
public async Task Creates_shipment_and_persists_it()
{
    await api.ResetAsync();

    // ... arrange, act, assert
}

Now each test starts from a known state.

Where Unit Tests Still Earn Their Keep

Most slices are thin: validate, load, mutate, save. Slice tests cover those completely, and unit testing a thin handler through mocks just restates the implementation.

But some slices contain real logic: pricing rules, state machines, date math around business calendars. When that happens, don't test the logic through HTTP. Extract it into the domain (a method on the entity, a domain service, a plain class) and unit test it there, exhaustively, with no infrastructure in sight.

The split is clean:

• Slice tests prove the feature works end to end: routing, validation, persistence, the happy path, and the important sad paths.
• Unit tests hammer the interesting domain logic with every edge case, at nanosecond speed.

If a slice has no interesting logic, it gets no unit tests.

Keep the Slices From Growing Into Each Other

One more failure mode: tests pass, features work, and six months later every slice quietly references three others. Slice independence is the property that makes VSA worth having, so put it under test too, with architecture tests:

[Fact]
public void Slices_should_not_reference_other_slices()
{
    var result = Types.InAssembly(typeof(Program).Assembly)
        .That().ResideInNamespace("Features.Shipments")
        .ShouldNot().HaveDependencyOn("Features.Invoicing")
        .GetResult();

    result.IsSuccessful.Should().BeTrue();
}

Cheap to write, and it turns "please don't couple slices" from a code-review plea into a failing build.

Summary

Testing vertical slice architecture stops being confusing the moment you pick the right unit:

1. Test the slice as a feature: real HTTP in, real database out, via WebApplicationFactory + Testcontainers.
2. Fake only what you don't own. Your database is yours; a real one goes in the test.
3. Unit test extracted domain logic, not thin handlers.
4. Architecture tests keep slices independent while the codebase grows.

The result is a suite that describes features instead of layers, survives refactoring, and catches the bugs that actually reach production.

Thanks for reading.

And stay awesome!

---