❌

Reading view

AI predicts prolonged air leak after lung surgery in elderly patients

When surgeons remove a portion of a cancerous lung, one of the most frustrating complications they can face is air. A persistent leak from the lung’s cut surface or staple lines — known as prolonged air leak — keeps chest tubes in place far longer than anyone would like, extends hospital stays, inflates costs, and elevates the risk of infection and other downstream problems. Now, a research team in China has developed a machine learning tool that predicts, with striking accuracy, which older lung cancer patients are most likely to develop this complication before it ever occurs. The study, published in BMC Cancer, combines cardiopulmonary exercise testing data with an interpretable artificial intelligence model and could reshape how thoracic surgical teams prepare for and manage one of the most common postoperative challenges in lung surgery.

The research was led by Zixiao Wang, Jiabao Ding, Huagang Liang and colleagues at the First Hospital of Qinhuangdao, in collaboration with Kai Wang of Tianjin Chest Hospital. It addressed a well-recognized gap in thoracic surgical practice. While prolonged air leak — typically defined as air leaking from the chest drainage system for more than five days after surgery — is among the most frequent complications following video-assisted thoracoscopic anatomical lung resection, the prediction models available to clinicians have historically lacked rigorous external validation and, critically, interpretability. Surgeons have been asked to trust risk scores without understanding where those risks come from, a barrier that has limited clinical uptake of computational tools in the operating room planning process.

To build their model, the investigators enrolled patients aged 60 and older with lung cancer who underwent thoracoscopic anatomical lung resection — either lobectomy, the removal of an entire lung lobe, or segmentectomy, the removal of a smaller anatomical segment. The study was designed as a dual-centre cohort investigation with both retrospective and prospective components. A total of 471 patients treated at Qinhuangdao First Hospital between January 2024 and June 2025 formed the model development cohort. A separate group of 140 patients from Tianjin Chest Hospital, enrolled prospectively between June and August 2025, provided the external validation set — a crucial test of whether the model generalized beyond the institution where it was built.

The methodology followed the emerging best-practice playbook for clinical machine learning. After preliminary data processing, the development cohort was randomly split into a training set containing 70 percent of patients and an internal validation set holding the remaining 30 percent. Because prolonged air leak affects only a minority of surgical patients, the training data were inherently imbalanced, with far more non-leak cases than leak cases — a condition that can fool machine learning algorithms into simply predicting that no one is at risk. The researchers countered this with SMOTE, the Synthetic Minority Over-sampling Technique, which generates synthetic examples of the underrepresented class to rebalance the dataset and force the algorithms to learn the genuine signature of risk.

Feature selection was performed using LASSO regression — least absolute shrinkage and selection operator — a statistical technique that penalizes model complexity and drives the coefficients of irrelevant variables to zero, effectively filtering a large panel of candidate variables down to the most predictive few. From this process, four predictors of prolonged air leak emerged: a history of emphysema, the smoking index, a previous history of thoracic surgery or chest trauma, and the ventilatory equivalent for carbon dioxide, abbreviated VE/VCO₂. This last variable is drawn directly from cardiopulmonary exercise testing, a stress test performed on a bicycle or treadmill that measures how the heart, lungs, and circulatory system respond together to increasing exertion. VE/VCO₂ reflects the efficiency of ventilation during exercise — how much air a patient must move to eliminate a given amount of carbon dioxide — and elevated values signal impaired pulmonary gas exchange and often underlying parenchymal lung disease.

With the four features in hand, the team constructed six competing machine learning models: logistic regression, support vector machine, decision tree, extreme gradient boosting, and artificial neural networks, among others. Each was evaluated using a battery of metrics including the area under the receiver operating characteristic curve, or AUC, the F1 score, and the Brier score, which measures the accuracy of probabilistic predictions. The winner was XGBoost, an ensemble method that builds a sequence of decision trees, with each new tree trained to correct the residual errors of its predecessors. In internal validation, XGBoost achieved an AUC of 0.903 (95 percent confidence interval, 0.834 to 0.960) — well within the range conventionally considered excellent discrimination — along with the highest F1 score of 0.717 and the lowest Brier score of 0.092 among all six candidates.

The external validation was arguably the study’s most important test. A model can memorize the quirks of its home institution’s patient population, equipment, and surgical practices, only to falter elsewhere. Yet when applied to the 140 previously unseen patients from Tianjin Chest Hospital, the XGBoost model maintained an AUC of 0.800 (95 percent confidence interval, 0.656 to 0.913), with a sensitivity of 0.700, a specificity of 0.833, and a Brier score of 0.133. In practical terms, the model correctly flagged seven out of ten patients who went on to develop prolonged air leak while correctly reassuring more than eight out of ten of those who did not — performance that, if replicated in routine practice, would give surgeons a meaningful window to intervene preemptively.

Interpretability was treated not as an afterthought but as a core design requirement. The researchers applied SHAP — Shapley Additive Explanations — a technique borrowed from cooperative game theory that assigns each feature a contribution value for every individual prediction. Rather than presenting clinicians with an opaque probability, SHAP reveals how much each of the four variables pushed a given patient’s risk up or down, and in which direction. Through this analysis, VE/VCO₂ emerged as the single most influential feature, followed by the other three predictors ranked by correlation. The finding is physiologically plausible: patients whose lungs ventilate inefficiently under the stress of exercise are precisely those whose lung tissue is most fragile and least likely to seal spontaneously after surgical manipulation. A history of emphysema, a heavy smoking history, and prior chest surgery or trauma each independently compound this tissue vulnerability.

The clinical utility of the work extends beyond prediction to prevention. Armed with a preoperative risk estimate, surgical teams can tailor their approach for high-risk patients. Options include more meticulous staple-line reinforcement, the use of sealants or pledgeted sutures on fragile lung tissue, choosing segmentectomy over lobectomy where oncologically appropriate, planning for ambulatory drainage systems on discharge, or scheduling earlier follow-up to catch and manage leaks before they become complicated. To lower the barrier to bedside use, the team built a web-based risk calculator that allows clinicians to enter a patient’s four variables and receive an individualized probability of prolonged air leak — no programming expertise required.

The significance of incorporating cardiopulmonary exercise testing into a surgical prediction model deserves particular emphasis. Traditional preoperative pulmonary assessment in lung cancer surgery has relied on static spirometric measures such as forced expiratory volume in one second, or FEV1, and the diffusing capacity for carbon monoxide, DLCO. These tests measure lung function at rest and provide only a partial picture of cardiopulmonary reserve. CPET, by contrast, captures the integrated response of multiple organ systems under physiological stress, and the VE/VCO₂ slope in particular has gained recognition as a sensitive marker of ventilatory inefficiency in chronic obstructive pulmonary disease and heart failure. The present study suggests that this dynamic measure carries prognostic information for surgical outcomes that static tests do not fully capture — a finding with implications well beyond air leak prediction.

Several caveats frame the work appropriately. The study population was limited to Chinese patients aged 60 and above undergoing video-assisted thoracoscopic resection, and generalization to younger patients, other surgical techniques such as robotic-assisted resection, or different health care systems remains to be demonstrated. The external validation cohort, while methodologically essential, comprised 140 patients, and wider multicenter prospective trials would strengthen confidence in the model’s performance. The published article is an accepted, peer-reviewed author manuscript shared early ahead of the final version of record. The study was funded by the Beijing Kechuang Medical Development Foundation, with the funder playing no role in study design, analysis, or manuscript preparation, and the authors declare no competing interests.

Even so, the study stands as a compelling example of where predictive medicine is heading. By pairing a rigorous dual-centre validation strategy with explainable artificial intelligence and a physiologically grounded predictor, the researchers have moved machine learning in thoracic surgery closer to genuine clinical utility rather than proof-of-concept novelty. For the growing population of older patients facing lung cancer surgery, a simple preoperative test and a few clicks in a web calculator may soon determine who needs extra surgical vigilance — and spare many of them the days of tethered chest drainage that have long been an accepted, if unwelcome, part of recovery.

Subject of Research: Machine learning-based prediction of prolonged air leak after video-assisted thoracoscopic anatomical lung resection in older lung cancer patients using cardiopulmonary exercise testing

Article Title: Machine learning-based prediction of prolonged air leak after video-assisted thoracoscopic anatomical lung resection in older patients using cardiopulmonary exercise testing: a dual-centre development and validation study

Article References: Wang, Z., Wang, K., Zhu, N., liu, H., Li, J., Liang, H., & Ding, J. (2026). Machine learning-based prediction of prolonged air leak after video-assisted thoracoscopic anatomical lung resection in older patients using cardiopulmonary exercise testing: a dual-centre development and validation study. BMC Cancer. https://doi.org/10.1186/s12885-026-16933-z

Image Credits: AI Generated

DOI: 10.1186/s12885-026-16933-z

Keywords: Machine learning, Prolonged air leak, Cardiopulmonary exercise testing, XGBoost, Lung cancer surgery, Video-assisted thoracoscopic surgery, Prediction models, VE/VCO₂, SHAP interpretability, Thoracic surgery, Predictive medicine, COPD

  •  

John Ternus Begins His Apple CEO Era With a Discreet Public Profile

John Ternus has entered one of the most visible positions in global business without trying to turn his first days into a personal media event. The new CEO arrived with a remarkably discreet public profile, a newly opened social presence and decades of work completed mostly behind Apple’s products.

His X account, @johnternus, appeared publicly on September 1, the day he officially succeeded Tim Cook. Its biography contained only the company logo and his new title. The first post was even shorter: “hello.”

The simplicity felt consistent with an executive who has spent most of his career explaining materials, engineering decisions and manufacturing improvements rather than building a public personality. It also created a sharp contrast with the scale of the position he now occupies.

Ternus can remain personally reserved, but the CEO role will repeatedly place him before customers, employees, investors, governments and developers. His first social post may have been quiet. The responsibilities arriving behind it are anything but.

John Ternus Arrives Without a Personal Media Machine

Ternus did not maintain a prominent public social account during his years leading hardware engineering. Most customers encountered him through carefully produced product presentations, occasional interviews or appearances focused on a particular device.

Even within those settings, his style remained technical and controlled. He usually spoke about engineering choices, durability, materials, performance and the work required to turn a design into a product that could be manufactured at enormous scale.

His new X account does not immediately change that character. Opening a channel is different from revealing a private life or becoming a daily commentator. The minimal introduction suggests a place for official communication rather than an invitation into every passing thought.

That would follow an established pattern for senior leadership. Tim Cook used his public account to acknowledge product launches, employees, social causes, environmental initiatives, community visits and major events. His posts rarely became extended personal debates.

Ternus may adopt a similar rhythm, although the account is too new to define its purpose. One word and a short biography cannot tell us how frequently he will post, which subjects he will address or whether he will write directly during moments of controversy.

The restrained opening still served one practical purpose. It established an authenticated public identity before unofficial profiles, impersonators and parody accounts could occupy the space around a newly appointed CEO.

A man with short dark hair and light stubble, rumored to be Apple Next CEO, smiles at the camera. He is wearing a black crew-neck shirt and is posed in front of a plain, light background.
John Ternus | Image Credit: Apple Inc.

A Career Built Behind the Hardware

The limited public profile should not be mistaken for limited influence inside the company.

Ternus joined the product design team in 2001 and became a vice president of hardware engineering in 2013. He entered the executive team as senior vice president in 2021, eventually overseeing engineering work across iPhone, iPad, Mac, AirPods and Apple Watch.

His official biography credits him with an instrumental role in the introduction of iPad and AirPods, along with work across multiple generations of the company’s largest product lines. It also connects his leadership to improvements in reliability, durability, materials, repairability and environmental performance.

This background gives Ternus a different starting point from a CEO recruited principally through finance, sales, software or public policy. He arrives from the part of the organization responsible for making difficult designs function consistently outside a laboratory.

Hardware engineering at this scale reaches far beyond choosing a processor or shaping an enclosure. It requires coordinating displays, batteries, cameras, radios, thermal systems, structural materials, manufacturing equipment, repair procedures and supplier capacity. A small change can affect production across millions of units.

That experience may explain part of his measured communication style. Engineering organizations reward details that survive testing. Public attention often rewards immediate confidence. Ternus has spent his career in an environment where confidence eventually meets a drop test, production line or repair bench.

His public appearances have often carried the same discipline. He tends to explain what a product team accomplished without placing himself at the center of the accomplishment.

The CEO Role Changes the Audience

Leading hardware engineering allowed Ternus to speak after a product decision had passed through years of development. As CEO, he will also need to speak while difficult questions remain unresolved.

Investors will expect him to explain spending, growth and long-term priorities. Governments will want answers about manufacturing, competition, privacy and platform control. Employees will look for direction as artificial intelligence, robotics, home technology, augmented reality and satellite communications create new opportunities across the company.

Customers will judge him through products, but they will also hear his response when a launch disappoints, a service fails or a policy creates frustration.

This is where a discreet profile can become either an advantage or a limitation.

A CEO who does not comment constantly preserves the weight of the moments when he chooses to speak. Fewer posts also reduce the chance that a hurried reaction becomes the story instead of the company’s work.

Silence becomes harder to maintain when people expect reassurance. Product defects, security incidents, employee concerns and political disputes can create situations in which a carefully prepared statement feels too distant. Ternus will have to decide when restraint protects the company and when it begins to look like avoidance.

Cook will remain involved as executive chairman and is expected to assist with areas including engagement with policymakers. That arrangement gives Ternus continuity during the transition without removing the need to develop his own public authority.

The distinction between their roles will become more visible with time. Cook can offer experience and institutional relationships, but employees and customers need to recognize which priorities belong to the new CEO.

A More Technical Public Voice Could Work

Ternus does not need to imitate Steve Jobs’ stage presence or Cook’s diplomatic style. A convincing public identity can grow from the expertise that brought him to the position.

The most natural version would be an engineering-minded CEO who explains trade-offs without turning every decision into a slogan. Product design is full of compromises involving battery life, weight, cost, durability, repairability and production capacity. Carefully explaining some of those decisions could make corporate communication more informative.

His 2024 commencement appearance at Penn Engineering offered a rare view outside a product presentation. Ternus returned to the university where he earned his mechanical engineering degree and addressed students as an experienced engineer rather than a celebrity executive.

That type of setting allows more personality to appear without requiring constant social posting. Longer interviews, engineering discussions, employee conversations and educational appearances may suit him better than trying to manufacture spontaneity several times a day.

A restrained profile could also reinforce collaboration. The products reaching customers are built by large teams, and Ternus has generally presented himself as a representative of that work. Maintaining that tone as CEO would keep attention on the organization rather than turning every announcement into a personal performance.

The difficulty will be preserving technical depth while discussing areas beyond hardware. Services, entertainment, artificial intelligence, software platforms and international policy cannot always be explained through materials and manufacturing. The CEO must connect them into one recognizable direction.

His First Major Appearances Will Define the Account

The opening “hello” gives Ternus room to decide how visible he wants to become.

Upcoming product events will offer an early test. A social account can distribute announcements and photographs, but the stage will reveal more: which subjects he chooses to introduce, how much technical detail he includes and whether he remains present throughout the presentation or delegates most of it to other executives.

Earnings calls will create a different test. Product videos are rehearsed around finished work; financial discussions require direct answers about demand, margins, investment and risks. His language in those conversations will begin shaping how investors understand the new administration.

Internal communication may prove equally influential even when the public sees only fragments. Employees will listen for signals about decision-making speed, tolerance for experimentation and the relationship between engineering ambition and commercial discipline.

The X account can support that work, but it cannot substitute for it. A polished stream of product announcements would tell customers what has shipped. Occasional direct messages during difficult moments would reveal more about how Ternus intends to lead.

For now, the empty space around his first post is part of the story. The next useful signal may not be how often John Ternus speaks, but which moment persuades this notably private engineer that the CEO should speak in his own voice.

Two men walk side by side on a gravel path surrounded by greenery, smiling and engaged in conversation. Both are casually dressed in long-sleeve shirts, jeans, and sneakers.
Image Credit: Apple Inc.

 

The post John Ternus Begins His Apple CEO Era With a Discreet Public Profile appeared first on AppleMagazine.

  •  

How to keep your mission-critical cloud workloads running

Entrusting mission-critical workloads in the cloud puts a lot of pressure on IT operations to build resilience into data infrastructure they don’t even own — to make sure that when an incident happens elsewhere, the lights stay on at home. Fortunately, savvy CIOs are learning they can architect their systems for resilience and high availability to keep mission-critical cloud workloads running when disaster strikes.

When designing for resilient, highly available cloud workloads it is critical to understand the details of your cloud provider’s service level agreement (SLA) and recognize that providers operate on a shared responsibility model. That means there are many things the provider is responsible for, but the workloads you’ve got running on their infrastructure are not among them. With that in mind, we’ll need to focus on three core goals essential to building and maintaining highly available, resilient cloud workloads:

  1. Identify and eliminate single points of failure
  2. Close or mitigate conditions leading to recovery gaps, and
  3. Overcome operational complexity.

Remember, everything fails

Designing for application-level resilience and high availability is predicated on recognizing that everything fails. That’s not pessimism, but realism, and embracing this fact gives you a leg up in architecting resilient IT. Hardware breaks down, disasters occur, mistakes are made, software incompatibilities are common, and limits are exceeded that result in loss of service. There are four categories of failure that need to be taken into consideration when designing for resilience and high availability:

  1. Single point of failure: As the term suggests, this describes a non-redundant device, route, or point of connectivity that results in zero fault tolerance in the event of an incident involving that choke point.
  2. Excessive load: Exceeding the throughput or memory limits of a device or service can result in latency, service degradation, or failure affecting service level agreements (SLA) and service level objectives (SLO).
  3. Misconfigurations and bugs: Perhaps the most common source of failure, these breakdowns often occur during installation, maintenance, and patching leading to the incorrect execution of code.
  4. Shared fate: This type of failure is like non-redundant connectivity. When you rely on third-party services and there is an incident beyond your control affecting a partner, it can result in downtime or service degradation.

Having identified the primary challenges to maintaining service uptime and continuity, let’s explore an approach to achieving resilience through high availability, disaster recovery, and the process of continuous improvement.

Working toward continuous improvement

High availability is often thought of as measured by “X Nines,” representing the percentage of time a service is operational over the course of a specified time frame, usually a year. Six nines of availability, for example, means that a service can be expected to run 99.9999% of the time, or 8759.99 hours out of 8760 in a year. That sounds good until a disaster happens. Then we shift to disaster recovery, or the ability to restore a service and its associated data quickly and correctly when things go wrong. Disaster recovery is often measured and evaluated by a recovery point objective (RPO), which is the maximum acceptable amount of data loss, and a recovery time objective (RTO), which is the maximum acceptable amount of time a service can be down.

By learning from our mistakes, incidents, and the ongoing process of testing, observing, and evaluating IT operations, we apply new information in the goal of continuous improvement to get peak performance out of our investments in IT. But because we’re addressing resilience and high availability in the context of workloads operating in the cloud, we should understand the shared responsibility model that most cloud service providers use. Details may differ from provider to provider, but the shared responsibility model of cloud services is your vendor’s statement of responsibility for maintaining its infrastructure and ability to deliver storage and compute capacity in a region and availability zone where you have a need. In return, you accept responsibility for the configuration, maintenance, availability and operation of the workloads you choose to run on your vendor’s cloud.

Infoworld - Shared Responsibility

SIOS Technology

A cloud service provider will typically operate and maintain physical infrastructure in different areas around the world, with multiple availability zones in each area. Each availability zone will have one or more data centers with its own power, cooling, and other operational support. Data centers are typically located far enough from each other to minimize the chance that a natural or regional disaster will affect multiple data centers, but close enough that they can operate as a single, logical data center — thereby maximizing bandwidth and throughput, while minimizing latency. This is redundancy at scale that eliminates a single point of data center failure.

Designing for application high availability and disaster recovery

To build out or retrofit your infrastructure for application-level resilience and high availability, there are four things you must have: clustering, data replication, failover, and disaster recovery. Let’s look at each and how to architect for them.

Clustering

Clustering is the practice of connecting like and complementary systems to improve availability and reliability. Think of it as putting into practice the maxim “the whole is greater than the sum of its parts.” Traditionally, clustering was achieved using hardware, specifically storage area networks (SAN), to connect and support systems in a physical data center. However, in the cloud age, hardware-based clustering has proven to be expensive and inflexible. Software-based SANless clustering with products such as SIOS LifeKeeper delivers all the benefits of the traditional approach while also working better in cloud and hybrid environments.

Infoworld - SAN vs. SANless

SIOS Technology

SANless clusters enable the configuration of nodes based on the organization’s operational priorities and work easily for enterprises running geographically distributed data centers or cloud availability zones. Because SIOS LifeKeeper supports single-site, multi-site, cloud, or mixed environments, and affords real-time access to operational data during incidents requiring failover, it is ideal when mission-critical workloads are distributed across multiple providers. LifeKeeper clusters create redundancy and eliminate single points of failure, both of which are necessary for achieving high availability. For enterprises operating hybrid or multi-cloud infrastructure, this enables you to shift to secondary resources should your primary service experience an outage.

Data replication

IT operations and your mission-critical applications rely on data, so it’s vital to keep data in sync between nodes in real time, whether synchronously or asynchronously, depending on the application. When working to achieve high availability, it’s important to monitor the health of infrastructure elements and the applications you’re running. This ensures that downtime affecting the application and any downstream dependencies is detected so that failover and recovery to a standby node can occur automatically. When everything is in sync and data replication is happening, this ensures complete readiness; there’s no need to rebuild a database or for any manual operations. And with SANless clusters using SIOS DataKeeper, this will happen across availability zones, regions, and to or from on-premises, cloud, or multi-cloud resources in hybrid environments.

Infoworld - Data Replication

SIOS Technology

What’s important here is that the software you use for SANless clustering be application aware. That’s SIOS LifeKeeper. Because high availability and resilience mean not just failing over to standby infrastructure resources, but for properly failing over mission-critical workloads (think SQL Server, SAP, Postgres, or industry-specific applications like Meditech), the software needs to understand how those applications work so that they can recover and restart cleanly. Otherwise, when failover occurs, there’s a good chance that workload is not going to be available, or it could be out of sync. When your software is application-aware, failover and recovery is fast and predictable with no API dependencies or last-minute provisioning.

Failover

With SIOS SANless application-aware clustering and replication in place, you can automate real-time failover and achieve the goal of high availability and resilience. Because we’ve chosen a software-based approach, failover occurs in the data plane, so there’s no need to spin up a new instance following an incident. Everything is already running, in sync, and ready. Furthermore, failover is immediate and it’s predictable. That is what you need when dealing with mission-critical workloads. Consider that many of the mission-critical applications you use were not designed to operate in the cloud, so even if your infrastructure is resilient, the application itself represents a single point of failure. Without replication, application monitoring, and real-time failover automation, you risk loss of revenue, security degradation, or worse.

Infoworld - HA Clustering

SIOS Technology

Depending on the size of your enterprise and the industry in which it operates, an hour of downtime can cost $1 million or more, and 90% of organizations report costs of at least $300,000 per hour. Beyond that simple loss of revenue are soft costs associated with reputation damage, lost productivity, missed transactions, and more. Revenue protection is only part of the equation; it is about protecting the business.

Disaster recovery

Any design for high availability and resilience must also take into consideration the risk of a non-IT disaster that disrupts operations. Natural disasters like fires, earthquakes, and floods, or disasters caused by humans like the accidental severing of a trunkline or an act of sabotage conspire to bring operations to a sudden halt. Clustering, replication, and failover all play into disaster recovery, but there are additional considerations that must be addressed. For disaster recovery (DR), you’re going to want geographic distance between your primary site and your DR site to minimize the risk that a regional event doesn’t affect both. That means you’re going to want asynchronous (or near real-time) data replication.

Infoworld - Disaster Recovery

SIOS Technology

Asynchronous replication is typically only a second or less behind synchronous replication, so it is de facto real-time, but that delay allows you to replicate across higher-latency networks and across longer distances. And because replication is happening continuously, even if you have a local failover between node one and node two, replication to the DR node doesn’t stop. Instead, when node two comes online it becomes the source of the mirror replicating to the DR site and back to node one once it is restored.

Patching and planned maintenance

Beyond the simplicity and cost advantages that come from taking a software-based approach to designing your cloud and hybrid infrastructure for high availability there is another big benefit. You are also better prepared to respond to the increased pressure on rapid implementation of software updates and security patches. No one wants to be the person responsible for taking too long to patch for a vulnerability, but every time you touch a system, you’re introducing the risk of error. That risk is greater when dealing with the cloud where you have less control over the underlying infrastructure, more abstraction, and a lot more moving parts.

In short, patches can break things as well as fix them. They have thus become a significant contributing factor as a cause of downtime. With SANless clusters you’re able to minimize that risk by enabling rolling updates, meaning you can patch a secondary server, verify that the patch didn’t break anything, and then patch the original server where the primary application is still running. If something does break on the secondary server, the primary is unaffected and you can quickly recover to the previous state while you figure out what went wrong. This simplifies the process of executing ad hoc patches and performing planned maintenance, mitigating the associated risks.

An investment in cloud and hybrid infrastructure and services doesn’t have to put IT operations at the mercy of a third party. With the right approach, you can design for high availability and resilience and keep your mission-critical workloads running in the cloud even when things outside of your control go wrong.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

  •  

Swift 6.4: Warning for Weak Captures Within Nested Closures

John Sundell:

New in Swift 6.4 […] is a warning which is emitted when a nested closure performs a weak capture while the parent closure implicitly captures that object as a strong reference.

At first glance, that new diagnostic could be a bit puzzling, since it might seem unnecessary to have to specify such a weak capture twice (or, alternatively, move it to the parent closure’s capture list), but it turns out that it’s an incredibly useful new warning that can help us avoid a quite common kind of memory management bug.

[…]

Finally, in situations where capturing self strongly doesn’t actually lead to a retain cycle, we can silence the new warning for nested weak captures by explicitly adding self to the outer closure’s capture list, such as when creating a Task within the following example[…]

Previously:

  •  
❌