The record-breaking September security update fixes two exploited privilege-escalation zero-days and 20 potentially wormable vulnerabilities. The post Microsoft Patches Record 974 Vulnerabilities, Including Two Exploited Zero-Days appeared first on SecurityWeek .
Chipmaking changes could boost productivity of new ASML machines by 40 percent.
Your personal AI agent that gets things done Discussion | Link
Hundreds of thousands of AI agent sandboxes can already run concurrently on a single DeepSeek cluster. Now the company is The post DeepSeek is hiring 150 engineers, and none of them will touch a model appeared first on The New Stack .
Meta's new personal AI agent Muse wants access to users' email, calendars, payments, health services, and more — making the company's biggest consumer AI bet yet a major test of whether people still trust Meta with their data.
Article URL: https://openai.com/index/introducing-chatgpt-images-2-5/ Comments URL: https://news.ycombinator.com/item?id=49614720 Points: 275 # Comments: 371
Tracked as CVE-2026-75650, the exploited defect allows unauthenticated attackers to execute arbitrary code. The post Adobe Patches Over 170 Vulnerabilities, Including Commerce Zero-Day appeared first on SecurityWeek .
One shared space where your team and AI agents work Discussion | Link
AI/ML and complex batch workloads continue to push the boundaries of Kubernetes scheduling. Following the foundational workload-centric enhancements introduced in previous releases, Kubernetes v1.37 delivers the next major milestone in the Workload-Aware Scheduling (WAS) journey. In this release, the core Workload and PodGroup APIs—enabling gang scheduling—along with Workload-Aware Preemption (WAP) and shared DRA ResourceClaims for PodGroups, all graduate to Beta, solidifying their role in the Kubernetes ecosystem. To address the hierarchical scheduling requirements of modern high-performance distributed workloads, v1.37 introduces the new CompositePodGroup API. This new API allows expressing multi-level topology constraints, gang scheduling, and preemption policies for complex, heterogeneous groups of Pods. Crucially, this architectural expansion unlocks native scheduling support for advanced workload structures commonly managed by higher-order extension APIs such as JobSet and LeaderWorkerSet (LWS). Alongside these API additions, v1.37 focuses on streamlining adoption by introducing a new set of controller integration APIs and the workloadbuilder Go library. These provide standardized building blocks that significantly simplify how out-of-tree controllers can integrate with WAS capabilities. Utilizing these new tools, the native Job controller integration has been upgraded to fully consume the expanded WAS APIs—enabling advanced scheduling policies, flexible disruption modes, and topology-aware scheduling for standard batch workloads. Gang scheduling and Workload / PodGroup APIs Kubernetes v1.37 delivers a major milestone: Workload / PodGroup APIs and gang scheduling are officially graduating to Beta. This graduation signals that native, "all-or-nothing" scheduling for workloads is solidifying for wider adoption. Key updates to the API and gang scheduling algorithm in this release include: Beta graduation and API versioning changes The core Workload and PodGroup APIs have been promoted to v1beta1, meaning they are now one step away from General Availability (GA). For early adopters who have been testing these features, take note of the alpha versioning transition: v1alpha2 has been entirely replaced by v1alpha3. This transition introduces breaking changes designed to clean up the API structure around disruptionMode . Native PodGroup queueing A significant under-the-hood improvement in v1.37 makes the PodGroup a first-class citizen in the scheduling queue. Previously, even if belonging to a PodGroup, all member Pods were queued individually. Now, only the top-level PodGroup object is queued. This ensures all Pods share the same queueing behavior and lays the groundwork for more advanced PodGroup queueing strategies in the future. Dynamic elasticity with minCount mutability In earlier iterations, the minCount field, which dictates the minimum number of Pods required to successfully schedule a PodGroup, was strictly immutable. In v1.37, minCount is now mutable. This API change unlocks flexibility for elastic workloads. Controllers can now dynamically adjust the minimum required size of a gang on the fly, allowing workloads to gracefully degrade or expand without interrupting already-scheduled Pods. Workload-aware preemption In Kubernetes v1.37 the separate WorkloadAwarePreemption feature gate for workload-aware preemption was merged into the GenericWorkload feature gate, becoming a core part of the gang scheduling effort. While the core concepts of workload-aware preemption stay the same, there are some differences between the v1.36 and v1.37 releases: Performance and optimality To check whether a preemptor can fit in the cluster thanks to preemption, the scheduler simulates the removal of all potential victims and re-runs the scheduling algorithm. After that it tries to reprieve as many victims as possible. In the v1.36 release, the scheduling algorithm was run for each victim reprieval, verifying whether with the victim reprieved, the algorithm can still find a valid placement for the preemptor. In v1.37, the scheduling algorithm is run only once and the preemptor Pods are assumed based on its output. Later, the reprieval checks whether a victim can still run in its place with the preemptor assumed. PodGroup as a victim One of the limitations of v1.36 was the fact that the default preemption for single Pods was not aware of PodGroups and was not respecting their disruptionMode fields, allowing for disruption of single Pods even when the PodGroup had disruptionMode: {all: {}} set. Kubernetes v1.37 removes this limitation; the default preemption now respects the PodGroup disruptionMode field. Rename of the disruptionMode fields During the promotion of the API to Beta, the disruptionMode field was changed to decouple its naming from the PodGroup object, allowing consistent naming across PodGroups and CompositePodGroups. The modes changed as follows: PodGroup became all , and Pod became single . Support for preemptionPolicy In v1.36, the PodGroup does not have a preemptionPolicy field. The PodGroup can perform preemption as long as none of the Pods forming it has preemptionPolicy: Never set. In v1.37, when the PodGroupPreemptionPolicy feature gate is enabled, a PodGroup also has a preemptionPolicy field. It serves as an authoritative field for whether a PodGroup can perform preemption. CompositePodGroup API In Kubernetes v1.36, workload-aware scheduling established a clean separation between static workload templates (Workload) and runtime group state (PodGroup), but the supported scheduling policies were limited to a single, flat group. The CompositePodGroup API, introduced in Kubernetes v1.37, extends this model to support hierarchical scheduling requirements. This API allows its consumers to express multi-level scheduling requirements by organizing a workload in a tree-shaped hierarchy consisting of CompositePodGroup and PodGroup objects. Each CompositePodGroup carries policies and constraints that apply to other groups (CompositePodGroups and/or PodGroups), similar to how PodGroups govern scheduling behavior for a flat group of Pods. The scheduler treats such a hierarchy as a single scheduling unit and aims to satisfy the requirements specified by every group within that hierarchy. Defining a workload hierarchy To express multi-level scheduling requirements, you define a hierarchy of templates in a Workload object. Controllers then create the corresponding CompositePodGroup and PodGroup objects from that hierarchy. To support this, the Workload API is extended with the spec.compositePodGroupTemplates field. Each CompositePodGroupTemplate defines a template for a parent CompositePodGroup and directly nests the templates ( podGroupTemplates and/or compositePodGroupTemplates ) from which its child groups derive. Below is a sample Workload object that defines a two-level template hierarchy: apiVersion : scheduling.k8s.io/v1beta1 kind : Workload metadata : name : example-workload annotations : kubernetes.io/description : "Two-level workload hierarchy requiring 4 worker Pods and 1 driver Pod to schedule together." spec : compositePodGroupTemplates : - name : workload-root schedulingPolicy : gang : minGroupCount : 2 podGroupTemplates : - name : workers schedulingPolicy : gang : minCount : 4 - name : driver schedulingPolicy : gang : minCount : 1 After creating example-workload , a controller can stamp out the corresponding runtime group objects from these templates: A root CompositePodGroup that references the workload-root template in example-workload and carries its group-level scheduling policy (gang scheduling with minGroupCount: 2 ): apiVersion : scheduling.k8s.io/v1alpha3 kind : CompositePodGroup metadata : name : example-root-group annotations : kubernetes.io/description : "Root group coordinating gang scheduling across child worker and driver PodGroups." spec : workloadRef : workloadName : example-workload templateName : workload-root schedulingPolicy : gang : minGroupCount : 2 Two child PodGroup objects ( example-workload-workers and example-workload-driver ) that reference their respective leaf templates in example-workload and link to the root group via parentCompositePodGroupName : apiVersion : scheduling.k8s.io/v1beta1 kind : PodGroup metadata : name : example-workload-workers annotations : kubernetes.io/description : "Worker group requiring at least 4 Pods to be scheduled together." spec : parentCompositePodGroupName : example-root-group workloadRef : workloadName : example-workload templateName : workers schedulingPolicy : gang : minCount : 4 --- apiVersion : scheduling.k8s.io/v1beta1 kind : PodGroup metadata : name : example-workload-driver annotations : kubernetes.io/description : "Driver group requiring 1 Pod to schedule alongside the workers." spec : parentCompositePodGroupName : example-root-group workloadRef : workloadName : example-workload templateName : driver schedulingPolicy : gang : minCount : 1 How multi-level gang scheduling works To schedule a hierarchical workload, kube-scheduler evaluates the entire group tree as a unified scheduling unit: Recursive evaluation : The scheduler traverses the hierarchy from the root CompositePodGroup down to the leaf PodGroup objects. At each level, a parent CompositePodGroup is considered schedulable only when its child groups satisfy its scheduling policy (for example, placing at least minGroupCount of child groups when using the gang policy), while each leaf PodGroup must satisfy its own Pod-level policy (for example, placing at least minCount of member Pods when using the gang policy). All-or-nothing scheduling : Once a valid combination of child groups is found that satisfies the requirements of the root CompositePodGroup, the Pods across the entire hierarchy are scheduled and bound atomically. If the root group cannot satisfy its policy constraints, the entire hierarchy remains unschedulable and no Pods are bound, preventing partial deployments and deadlocks. Workload-aware preemption for the CompositePodGroup API Kubernetes v1.37 extends workload-aware preemption to support CompositePodGroup hierarchies as well. Specifically, if a CompositePodGroup cannot be scheduled due to insufficient capacity in the cluster, the scheduler can invoke preemption to evict lower-priority workloads in order to fit the Pods belonging to that CompositePodGroup. A CompositePodGroup can be selected for preemption as well. To specify the desired behavior during preemption, workload owners can specify an appropriate disruptionMode in the CompositePodGroup spec: single : Allows individual child groups within the CompositePodGroup to be preempted and disrupted independently. This is the behavior when disruptionMode is not set. all : Enforces "all-or-nothing" disruption semantics across the entire CompositePodGroup hierarchy. If any Pod within the descendant subtree must be preempted, the scheduler evicts all Pods across the entire hierarchy together. Topology-aware scheduling In Kubernetes v1.37, topology-aware scheduling expands to support complex, multi-level workload hierarchies and delivers performance improvements for existing single-level deployments. Multi-level topology-aware scheduling In Kubernetes v1.36, we introduced foundational topology-aware scheduling, allowing you to define co-location constraints directly on a PodGroup. While effective for single-level groupings, complex distributed workloads—such as large-scale AI/ML training, JobSet deployments, or disaggregated inference via LeaderWorkerSet (LWS)—often require co-location across multiple levels of cluster infrastructure simultaneously. For example, an entire workload may need to run within a single availability zone, while different parts of that workload (such as specific worker groups or driver processes) require strict co-location within specific server racks. In Kubernetes v1.37, alongside the new CompositePodGroup API ( scheduling.k8s.io/v1alpha3 ), topology-aware scheduling expands to support multi-level topology-aware scheduling . You can now express complex co-location requirements by specifying topology constraints at different levels of a group hierarchy. Top-down topology constraint resolution During hierarchical scheduling, the kube-scheduler resolves multi-level topology constraints in a top-down manner. Specifically, topology domains that are considered during the scheduling of a child group are confined within a topology domain that corresponds to the placement assumed by the parent group. Configuration and runtime execution Using the updated Workload API ( scheduling.k8s.io/v1beta1 ), you can configure multi-level topology constraints directly within compositePodGroupTemplates . In the example below, the parent template constrains the overall workload to a single availability zone ( topology.kubernetes.io/zone ), while child templates for workers and driver constrain their respective Pods to server racks ( topology.example.com/rack ) within that selected zone: apiVersion : scheduling.k8s.io/v1beta1 kind : Workload metadata : name : multi-level-tas-workload namespace : job-ns annotations : kubernetes.io/description : "Workload defining zone-level co-location for the root group and rack-level co-location for child groups." spec : compositePodGroupTemplates : - name : root schedulingPolicy : gang : minGroupCount : 2 schedulingConstraints : topology : - key : topology.kubernetes.io/zone podGroupTemplates : - name : workers schedulingPolicy : gang : minCount : 8 schedulingConstraints : topology : - key : topology.example.com/rack - name : driver schedulingPolicy : gang : minCount : 1 schedulingConstraints : topology : - key : topology.example.com/rack When a controller creates an instance of this workload at runtime, it spawns the corresponding runtime objects from these templates: The root CompositePodGroup referencing the root template, carrying the availability zone topology constraint and the hierarchical gang scheduling policy. The two child PodGroup objects ( tas-workload-workers and tas-workload-driver ), each referencing the root CompositePodGroup as their parent group via the parentCompositePodGroupName spec field: apiVersion : scheduling.k8s.io/v1alpha3 kind : CompositePodGroup metadata : name : tas-workload-root namespace : job-ns annotations : kubernetes.io/description : "Root group constraining the entire workload to a single availability zone." spec : workloadRef : workloadName : multi-level-tas-workload templateName : root schedulingPolicy : gang : minGroupCount : 2 schedulingConstraints : topology : - key : topology.kubernetes.io/zone --- apiVersion : scheduling.k8s.io/v1beta1 kind : PodGroup metadata : name : tas-workload-workers namespace : job-ns annotations : kubernetes.io/description : "Worker group requiring 8 Pods co-located within a single rack in the selected zone." spec : parentCompositePodGroupName : tas-workload-root workloadRef : workloadName : multi-level-tas-workload templateName : workers schedulingPolicy : gang : minCount : 8 schedulingConstraints : topology : - key : topology.example.com/rack --- apiVersion : scheduling.k8s.io/v1beta1 kind : PodGroup metadata : name : tas-workload-driver namespace : job-ns annotations : kubernetes.io/description : "Driver group requiring 1 Pod placed in a rack within the selected zone." spec : parentCompositePodGroupName : tas-workload-root workloadRef : workloadName : multi-level-tas-workload templateName : driver schedulingPolicy : gang : minCount : 1 schedulingConstraints : topology : - key : topology.example.com/rack During scheduling, the scheduler evaluates multiple candidate availability zones across the cluster for tas-workload-root . For each candidate zone, it subdivides the nodes by rack topology to explore feasible rack placements for tas-workload-workers and tas-workload-driver strictly within that zone, systematically evaluating multiple combinations across available zones and racks before making a scheduling decision. By allowing topology constraints to be modeled hierarchically, Kubernetes v1.37 provides a structured way to express multi-level co-location requirements across complex cluster infrastructures. Performance improvements for single-level TAS Alongside the Alpha introduction of multi-level hierarchies, Kubernetes v1.37 reduces the cost of placement evaluation for existing single-level topology-aware scheduling. We are continuously working to optimize the efficiency of placement evaluation algorithms in kube-scheduler and plan to deliver further performance improvements in future releases. Controller Integration APIs Kubernetes v1.37 introduces new standard building blocks so that every controller can expose the same scheduling primitives in their own APIs, and share the same logic for translating them into scheduling objects. These primitives express specific scheduling behaviors — such as policies or disruption logic — while leaving the field naming flexible for each controller. A prime example of this is the native Job controller, which we detail in the next section. Types prefixed with WorkloadPodGroup describe a leaf group of Pods; types prefixed with WorkloadCompositePodGroup describe a group of groups. A controller embeds them verbatim into its own API, under whatever field name fits its domain: WorkloadPodGroupSchedulingPolicy — either basic , meaning standard Pod-by-Pod scheduling, or gang with a minCount . The composite variant takes a minGroupCount instead. WorkloadPodGroupSchedulingConstraints — the topology constraints ( topology[].key ) the group's Pods must be co-located within. WorkloadPodGroupDisruptionMode — single or all , with the preemption semantics described earlier in this post. WorkloadPodGroupResourceClaim — the ResourceClaims shared across the group. Only the shapes are shared, so controllers retain full autonomy over how they name and nest these fields in their own APIs. The workloadbuilder library turns that intent into the scheduling objects. A controller describes its workload as a tree of WorkloadItem nodes — a node with children compiles to a CompositePodGroupTemplate , a node without children to a PodGroupTemplate — and attaches its own defaults plus the user-supplied building blocks to each node. From there, Validate() reports problems back at the exact field path within the controller's own API, BuildWorkload() compiles the tree into a Workload, and NewPodGroup() and NewCompositePodGroup() stamp out the runtime group objects. Validation is deny-by-default: a controller declares the policies and disruption modes it actually supports through AllowedPolicies and AllowedDisruptionModes , and anything outside those lists is rejected. Building blocks added in future releases therefore stay unavailable until a controller explicitly opts into them. For hierarchical workloads where a parent controller owns the Workload and delegates group creation to its children, NewBuilderFromExistingWorkload lets a child materialize only its own PodGroup from the parent's Workload. Neither the building blocks nor the library have a feature gate of their own; they become user-visible through whichever controller adopts them. The native Job controller is the first to do so, and we detail it in the next section. Integration with the Job controller Building upon the new controller integration APIs, the Job API now features an explicit .spec.scheduling field, so you can declare how a Job should be scheduled instead of relying on the Job controller to infer it from the Job's shape. This expands support well beyond static, indexed, and fully-parallel Jobs. .spec.scheduling is composed of the building blocks described above: schedulingPolicy — basic for standard Pod-by-Pod scheduling, or gang for all-or-nothing scheduling. schedulingConstraints — the topology domain the Job's Pods must be co-located within. disruptionMode — whether the Job's Pods can be preempted individually ( single ) or only as a whole ( all ). resourceClaims — the ResourceClaims shared by all of the Job's Pods. For example: apiVersion : batch/v1 kind : Job metadata : name : distributed-training-job annotations : kubernetes.io/description : "Distributed Job using explicit WAS scheduling with gang policy and zone topology constraints." spec : parallelism : 8 completions : 8 scheduling : schedulingPolicy : gang : {} # minCount omitted → defaults to parallelism (8) schedulingConstraints : topology : - key : topology.kubernetes.io/zone disruptionMode : all : {} template : spec : containers : ... Omitting .spec.scheduling , or omitting schedulingPolicy within it, selects the basic policy, which behaves exactly like standard Job scheduling today. For every Job it manages, the controller compiles this configuration into a Workload and a PodGroup owned by the Job, and sets .spec.schedulingGroup.podGroupName on each Pod it creates so the scheduler treats them as one group. Once created, .spec.scheduling is immutable, with one exception: schedulingPolicy.gang.minCount can be updated, which lets you resize a running gang. DRA ResourceClaim support for workloads As the core WAS APIs mature, so do their integrations with Dynamic Resource Allocation (DRA). Kubernetes v1.36 introduced the DRAWorkloadResourceClaims feature gate. The associated feature allows ResourceClaims to be replicated and reserved for entire PodGroups and shared by all their member Pods: apiVersion : scheduling.k8s.io/v1beta1 kind : PodGroup metadata : name : training-job-workers-pg spec : ... resourceClaims : - name : pg-claim resourceClaimTemplateName : my-claim-template --- apiVersion : v1 kind : Pod metadata : name : topology-aware-workers-pg-pod spec : ... schedulingGroup : podGroupName : training-job-workers-pg resourceClaims : - name : pg-claim resourceClaimTemplateName : my-claim-template In Kubernetes v1.37, the DRAWorkloadResourceClaims feature gate graduated to Beta. While the API and core functionality of the feature remain unchanged, one change eliminates some potentially surprising behavior when disabling the feature. Previously when one of a Pod's spec.resourceClaims referenced a ResourceClaimTemplate and matched one of its PodGroup's spec.resourceClaims and the DRAWorkloadResourceClaims feature gate was disabled , a ResourceClaim was created for the Pod instead of the PodGroup. In that scenario in v1.37, no ResourceClaim is created at all. This change prevents Kubernetes from creating a flood of ResourceClaims from a ResourceClaimTemplate and potentially exhausting DRA resources when a claim intended to be shared by a whole PodGroup is replicated for each and every Pod in the group. For more information, see the feature documentation . What's next? The Workload-Aware Scheduling Working Group (WG WAS) is currently finalizing its plans for the Kubernetes v1.38 release cycle. While the roadmap is still taking shape (stay tuned!), the following key initiatives are already planned: Graduation of Workload and PodGroup APIs to GA: Solidifying the core foundation of workload-aware scheduling as a stable Kubernetes API. Graduation of Topology-Aware Scheduling (TAS) and CompositePodGroup (CPG) to Beta: Bringing these advanced placement and hierarchical scheduling features to Beta stability. Graduation of controller integration building blocks to Beta: Further refining the integration APIs to ensure a robust developer experience. Increased adoption and integration: Expanding the ecosystem by integrating workload-aware scheduling with other controllers, with a particular focus on hierarchical orchestrators such as JobSet . Kueue Integration: Fostering closer alignment between WAS and Kueue . In the near term, we aim to ensure Kueue is fully aware of WAS features for seamless interoperability. In the long term, we envision Kueue leveraging WAS as its underlying engine for capabilities like gang-scheduling and topology-aware placement. Getting started Many of the workload-aware scheduling improvements are now available as Beta features in v1.37, while new advanced capabilities are introduced in Alpha. Both Beta and Alpha features here are disabled by default and require manual enablement. Beta features: Workload API, gang scheduling, and preemption: The GenericWorkload feature gate (which now integrates gang scheduling and workload-aware preemption) is Beta and disabled by default on the kube-apiserver , kube-controller-manager and kube-scheduler . Ensure your manifests are updated to use the scheduling.k8s.io/v1beta1 API group . DRA ResourceClaim support for workloads: Enable the DRAWorkloadResourceClaims feature gate on the kube-apiserver , kube-controller-manager , kube-scheduler and kubelet . Alpha features: Topology-aware scheduling: Enable the TopologyAwareWorkloadScheduling feature gate on the kube-apiserver and kube-scheduler . CompositePodGroup API: Enable the CompositePodGroup feature gate on the kube-apiserver , kube-controller-manager and kube-scheduler , and ensure the scheduling.k8s.io/v1alpha3 API version is enabled. Note that enabling CompositePodGroup on the kube-controller-manager also requires the TopologyAwareWorkloadScheduling feature gate to be enabled. Workload API integration with the Job controller: Enable the WorkloadWithJob feature gate on the kube-apiserver and kube-controller-manager . PodGroup preemptionPolicy : Enable the PodGroupPreemptionPolicy feature gate on the kube-apiserver and kube-scheduler . Controller integration APIs: The new workloadbuilder library is available to developers building both out-of-tree and in-tree controllers who want to integrate with WAS. It does not require a feature gate. You can explore the library and find usage examples directly in the kubernetes/component-helpers repository. We encourage you to try out workload-aware scheduling in your test clusters and share your experiences to help shape the future of Kubernetes scheduling. You can send your feedback by: Reaching out via Slack (#wg-workload-aware-scheduling) . Joining the WG Workload-Aware Scheduling or SIG Scheduling meetings. Filing a new issue in the Kubernetes repository. Learn more To dive deeper into the architecture and design of these features, read the KEPs: KEP-4671: Gang Scheduling Support in Kubernetes KEP-5710: Workload-aware preemption KEP-5732: Topology-aware workload scheduling KEP-6012: CompositePodGroup API KEP-6089: WAS: Controller Integration APIs KEP-5547: WAS: Integrate Workload APIs with Job controller KEP-5729: DRA: ResourceClaim Support for Workloads
A 78-year-old British woman is facing deportation for failing to fill out a Brexit residence application on time.
The support portal has been redesigned and moved to a new home at help.github.com. It brings support, docs, learning, community, and account resources together in one place with Copilot-powered search… The post New customer portal help.github.com appeared first on The GitHub Blog .
Mathematician Tristan Buckmaster says an OpenAI researcher pressured him after information about his AI-assisted progress on the Navier-Stokes equations allegedly reached the company. The researcher tried to remove his co-author because he works at Anthropic and threatened Buckmaster when he refused, according to Buckmaster's account. OpenAI then claimed its own breakthrough using the same unusual solution path. Buckmaster had uploaded all his drafts to Codex. OpenAI told him the model didn't look up user data, but when he asked about training, he says he got no answer. OpenAI denies the allegations. The article OpenAI researcher allegedly pressured mathematician to drop Anthropic co-author from math breakthrough paper appeared first on The Decoder .
Private, on-device meeting notes for Mac Discussion | Link
There is a $1 million bounty for the first person providing a solution to the Navier-Stokes existence and smoothness problem.
At least 30 men, women and children drowned when their dinghy capsized on 24 November 2021.
Article URL: https://openai.com/index/navier-stokes-solution/ Comments URL: https://news.ycombinator.com/item?id=49613262 Points: 1016 # Comments: 845
Minor Changes #14372 dbf6aad Thanks @ichernetsky-cf ! - Add containers[].observability support to wrangler deploy Wrangler now accepts container-specific observability settings via containers[].observability , including application-level targeting fields for Containers. Root observability continues to work as a fallback when a container does not define its own observability settings. wrangler deploy now preserves legacy configuration.observability for existing container apps that still use rollout-based observability, while using top-level application observability for new or already-migrated apps. Existing application diffs are now normalized even when stored resource limits cannot be mapped to a named instance type. API-only metadata and equivalent managed-registry image names no longer appear as edits or affect whether deployment changes require a rollout. #15004 e20df20 Thanks @MattieTK ! - Delegate agent Pages project creation with a production branch to Workers When run by an AI agent, wrangler pages project create --production-branch <name> is now eligible for delegation to a Workers static-assets deploy. The production branch names the target that a Workers deploy would publish to, so it does not need to disqualify a brand-new project from delegation. wrangler pages deploy --branch <name> remains on Pages because an interactive new-project flow separately prompts for its production branch. The deployment branch may therefore represent a preview and cannot safely be converted into a production Workers deployment. #15004 e20df20 Thanks @MattieTK ! - Widen agent Pages-to-Workers delegation to new projects on accounts that already use Pages When run by an AI agent, wrangler pages deploy and wrangler pages project create now delegate a brand-new static Pages project to a Workers static-assets deploy even when the account already has other Pages projects. The gate is now per-project rather than per-account: a command targeting a project that already exists stays on Pages, but a new project is delegated regardless of the account's other Pages projects. A project name restored from the Pages configuration cache is only used when the cache belongs to the currently authenticated account. An account-matching cached name remains on Pages even when the project is missing remotely, preserving the user's recorded Pages intent. After switching accounts, an otherwise unnamed deploy stays on Pages rather than treating a stale cached project name as a new project on the selected account. Patch Changes #15560 edb3631 Thanks @dependabot ! - Update dependencies of "miniflare", "wrangler" The following dependency versions have been updated: Dependency From To @cloudflare/workers-types ^5.20260907.1 ^5.20260908.1 workerd 1.20260907.1 1.20260908.1 #15557 63c7ff1 Thanks @tomekancu ! - Fix wrangler d1 execute --local being extremely slow with large SQL files or commands The local SQL splitter consumed quoted strings and comments character-by-character, re-checking the full accumulated string each time. This made splitting a large quoted value or comment quadratic, so seed files could take tens of seconds to run. The splitter now only inspects a bounded trailing window on each step, making splitting effectively linear. The remote path is unaffected as it imports the file server-side. #15542 a4e41df Thanks @NAVEENKUMARKR777 ! - Fix wrangler dev running the custom build command twice on startup and on every config change Wrangler already runs the custom build.command once before starting wrangler dev , to resolve the Worker's entry point. When dev.watch wasn't explicitly disabled, BundlerController then unconditionally ran the same build command again the moment it started watching for changes, and repeated this on every subsequent config reload too. For fast build commands this just meant duplicate log output (e.g. a vite build visibly running twice at startup). For slower or stateful build commands, running two builds concurrently against the same output files could corrupt the result or fail outright (for example, non-deterministic wasm-opt failures have been reported for Rust builds). The initial watcher setup now only bundles the output the build command already produced, instead of re-running the command. Real file changes detected by the watcher still re-run the build command as before. Updated dependencies [ edb3631 , bcebf08 ]: miniflare@5.20260908.0-alpha
Train your MicroDuck and win the Golden Beak Belt Discussion | Link
Ruslan Kravchenko resigns over allegations some of his officials were engaged in large-scale money laundering Ukraine’s prosecutor general has resigned after investigators used ladders to raid his office in connection with a major corruption scandal that threatens to embarrass Volodymyr Zelenskyy. Ruslan Kravchenko quit his post on Monday after allegations that some of his officials were involved in large-scale money laundering. They received cash to protect call centres involved in illegal phone scams, it was claimed. Continue reading...
Malicious prompts concealed in documents, metadata, emails, images and code can manipulate autonomous agents into taking dangerous actions. The post The Hidden Instructions That Can Hijack AI Agents appeared first on SecurityWeek .
See how an MIT researcher uses GPT-5.6 Sol with Codex to autonomously run quantum computing experiments, analyze results, and calibrate qubits.
Alleged ‘white-hat’ hackers drained $320 million from Liquid’s federation wallet, demanding a bug fix. The post Hackers Return $263 Million Stolen From Liquid Network appeared first on SecurityWeek .
Google Cloud expands its enterprise AI push with Accenture, betting on forward-deployed engineers to drive adoption and overcome deployment bottlenecks.
A previously undocumented financially motivated threat actor has been linked to attacks targeting Brazilian financial institutions since at least March 2026. Cybersecurity company CrowdStrike is tracking the Brazil-based activity cluster under the name Slim Spider. "The adversary demonstrates deep operational knowledge of Brazilian financial infrastructure, including the instant payment