Post Syndicated from The Atlantic original https://www.youtube.com/shorts/g5_l4wEONTs
Your alt text passes automated checks. That doesn’t mean it’s any good.
Post Syndicated from Taarik Ashenafi original https://github.blog/engineering/user-experience/your-alt-text-passes-automated-checks-that-doesnt-mean-its-any-good/
More than one in four images on the web’s most popular home pages have alt text that’s missing, vague, or copied from adjacent images.
That’s from WebAIM’s 2026 WebAIM Million report, which found that alt text,an HTML attribute containing text describing the content of an image, was missing on 16.2% of images across the top million home pages. Among the images that did have alt text, another 10.8% provided an undescriptive attribute, such as alt="image", a raw filename, or a description duplicated from a neighbor.
While automated tooling reliably flags missing alt text, it isn’t as good at fixing poorly written alt text. Most alt text checkers test whether an accessible name for an image exists, not whether the provided alt text says anything useful about the associated image, and that’s a deliberate design choice: a quality-oriented rule with false positives is a rule teams switch off. So alt="IMG_2847.png" passes. So does the same alt="3/5 stars" on five different star-shaped icons.
We built an alt text plugin for the GitHub Accessibility Scanner to help improve your alt text. This post covers where we drew the line between what a checker can prove and what it can only suspect, why our worst bug turned out to be a layout problem rather than a parsing one, and what changed once we let a model into the loop.
If you’re building automated checks of your own, for accessibility or otherwise, the tradeoffs should transfer.
Proving a string is wrong without seeing the picture
Presence of alt text is an objective fact; the attribute is there or it isn’t. Quality is often a judgment call. A machine can’t prove whether a sentence adequately describes a picture in context from markup.
However, not all quality is subjective. There’s several checks you can perform based on the alt text alone, with no need to consult the image content:
- The attribute is absent (not empty) or whitespace-only.
- The alt is a filename, such as
hero.png,IMG_2847.jpg. - The alt is a placeholder somebody meant to replace, such as
TODO,tbd. - The alt is one generic word naming the medium instead of the content, such as
image,logo,chart. - The same alt repeats across adjacent images.
Every one of those is a claim about a string, and that became our dividing line. Five deterministic rules run by default which need no credentials for running AI models or network calls. One opt-in rule calls a model with provided image content and surrounding context, for judgments an alt text string can’t support on its own.
First, we had to determine which images to judge on a scanned webpage. We use Playwright’s role-based locator rather than querySelectorAll('img'), so anything not included in the browser’s accessibility tree drops out, including anything carrying alt="". That last exclusion matters most. An empty alt is the author explicitly saying the image is decorative, and flagging it would punish exactly the behavior you want to encourage.
So, how strict should it be? A quality checker lives or dies on false positives, so we chose closed sets over clever heuristics. The vague-alt rule normalizes a string, then checks it against a curated list of words that carry no information on their own. It fires only on an exact match:
alt="image"gets flagged.alt="image of the login screen with the SSO button highlighted"doesn’t.
Rules this literal miss plenty of bad alt text. We took the miss over the false positive, because a reliable checker that developers enable beats one that gets switched off.
Repetition is a layout problem, not a DOM problem
Repeated alt text presented an interesting problem. Picture a row of five star-shaped icons that each say "3/5 stars". A screen reader user hears the same thing five times and learns nothing new from four of them.
Our first version walked the images in document order and flagged any run sharing the same normalized alt. It caught things it shouldn’t have. For example, a footer “GitHub” logo and a header “GitHub” logo might sit next to each other in the extracted list but nowhere near each other on screen, so nobody experiences them as a group.
What matters is where images land on screen, not where they sit in the markup. So the rule now checks page layout, and only extends a run when the gap between two bounding boxes is small compared to the boxes themselves:
const gap = Math.max(horizontalGap, verticalGap)
const largerDim = Math.max(a.boundingBox.width, a.boundingBox.height,
b.boundingBox.width, b.boundingBox.height)
return gap > GAP_MULTIPLIER * largerDimTwo details worth noting:
- The multiplier is a judgment call, not a number we derived from anything. It’s the kind of value you tune against real pages instead of trusting from a spec.
- When either image has no measurable box, the check fails open and the run continues. A missing finding is invisible; a wrong one isn’t.
Getting a model to act like a reviewer, not a critic
Deterministic rules only need the alt string. Anything smarter needs to know what the page is about, and none of that is tracked by the image element. Whether alt="a smiling person" is fine depends entirely on what surrounds it: on a generic mood shot, it’s probably works. But under a heading where a specific person is named, it doesn’t provide enough detail.
In our optional alt-text-qualitycheck, we extract page context alongside each image: the nearest heading, the page title, any <figcaption>, whether the image sits inside a link or button, and up to 600 characters of nearby prose.
The link signal matters most, because when an image is a link’s only content, its alt becomes the link’s accessible name. The right alt then names the destination instead of describing the picture.
One caution: The plugin only records that an image sits inside a link. We don’t check whether it’s the link’s only content, which is the part that actually turns alt into a link name. So right now both cases look identical to the model.
That context, the alt, and the image go to a vision model through GitHub Models. Our failure modes were rarely the model misreading a picture. They were the model having opinions. Given perfectly good alt text, our first version of the checker would suggest different alt text, because “could this be better?” is a question a language model always answers yes to. Every image becomes a finding, so the signal disappears.
Three changes fixed it:
- A decision procedure instead of an instruction. The prompt walks four ordered steps, stops at the first that matches, and emits that step’s verdict: decorative, redundant with a caption, functional, or informative.
- Explicit anti-nitpick rules. Trust the author’s framing. Separate redundant prefixes (“Image of…”) from semantic ones (“Photograph of…”). Treat a short alt as correct when the surrounding prose already analyzes the image.
- Structured output with a forced field order, so
reasoningis generated beforeverdictand the model has to build an argument before it picks a label.
None of that makes the model unfailingly correct. It makes it consistent enough to iterate against. The repository carries an offline grading harness built from published teaching material: WebAIM, the W3C images tutorial, and POET. The rule and the harness share one prompt, so what you tune offline is what runs in CI. That harness only tests the model’s judgment, though, not the whole pipeline. A case can score perfectly there and never reach the model in a real scan.
Sending images to a model is a privacy and cost decision
The moment a check calls an external model with webpage data, it stops being just a lint rule and requires careful data flow design. A few things follow from that:
- The rule is off by default. It won’t run unless you deliberately enable it in your plugin configuration, and it needs a token with access to GitHub Models.
- URLs get redacted. Image URLs and link
hrefs often carry signed CDN tokens or session identifiers, so query and fragment are stripped from anything entering the model context or the rule’s error logs. For the same reason,srcandsrcsetare replaced with(omitted)in the markup we send. - Everything in that context window is untrusted input. Titles, headings, and prose all come from the page being scanned, and a page can contain text written to steer a model. Structured output constrains the shape of a response, not the reasoning behind it.
One caution, because that list is easy to over-read: findings still carry the real page URL and original HTML into the scanner’s normal reporting pipeline. That’s on purpose, since you can’t fix an image you can’t locate. Redaction narrows what reaches the model and the logs, not what lands in your own issues. And if you set up Azure AI Vision credentials, an optional OCR pre-pass sends image bytes to a second place. Nothing requires Azure, but a data-flow review needs to cover both paths.
Cost follows the same shape. In the common case this is one model call per image per scan, which on an image-heavy site dominates the cost of the whole run. That’s reason enough to put it on a schedule rather than on every commit.
What this still can’t do
- The deterministic rules are literal. They catch alt text that’s obviously unwritten, not alt text that’s fluent and wrong. They also read the
altattribute rather than the computed accessible name, so anaria-labelthat fixes the problem won’t stop the finding. - The model-backed rule produces false positives. Every finding is a prompt for human attention, not a verdict.
- Silence isn’t coverage. That rule re-fetches images outside the browser session, so anything behind authentication can fail to load. Fetch and model errors are logged and skipped, which means a page can come back clean because nothing got checked.
- Suggested alt text is a draft. A model that sees the image and a few nearby words can’t account for your audience, your house style, or the job that image is doing on the whole page.
- Some findings double up with the scanner’s built-in checks, since our
missing-altrule covers the same ground. - We only check HTML
<img>tags. SVG,role="img"containers, CSS backgrounds, and canvas aren’t covered yet. - This is new code with limited real-world feedback. Rules like these improve when they meet the variety of markup and content found across real sites. This plugin hasn’t had that yet, so treat early findings accordingly.
- Passing isn’t conformance. Automated checks are a floor. Testing with people who use assistive tech is the goal.
What we’d tell you if you’re building something similar
Separate what you can prove from what you can only suspect, and give them different defaults. Checks that prove something should be cheap, predictable, and on by default. Checks that only suspect something should be opt-in, and should read as a suggestion rather than a verdict. Then, ask what the user experiences rather than what the DOM says. Every gap still open in this plugin has that second shape. We record that an image is inside a link, not that it is the link. We read an attribute, not a computed name.
That distance is the real boundary, and a better model doesn’t close it. Deciding what the functionality of an image is for a user who can’t see it still requires human judgment. What automation buys you is making sure that human is giving the right images a second examination.
Try the alt-text plugin in your accessibility scanning workflow. If it tells you the wrong thing, please report it. Open an issue with the finding and, if public, a link to the affected page.
The post Your alt text passes automated checks. That doesn’t mean it’s any good. appeared first on The GitHub Blog.
Intel Diamond Rapids the 2027 Intel Xeon at Hot Chips 2026
Post Syndicated from Patrick Kennedy original https://www.servethehome.com/intel-diamond-rapids-the-2027-intel-xeon-at-hot-chips-2026/
At Hot Chips 2026, Intel showed off its next-gen 2027 Diamond Rapids server CPU with up to 256 cores per socket
The post Intel Diamond Rapids the 2027 Intel Xeon at Hot Chips 2026 appeared first on ServeTheHome.
Introducing AWS Glue 6.0 for faster and more cost-effective data integration
Post Syndicated from Aarthi Srinivasan original https://aws.amazon.com/blogs/big-data/introducing-aws-glue-6-0-for-apache-spark/
Organizations running large data processing pipelines want lower costs, faster job runtimes, and dependable support for open table formats, without adding operational overhead. AWS Glue, a serverless, scalable data integration service that you can use to discover, prepare, move, and integrate data from multiple sources, has now launched AWS Glue 6.0, the new version of AWS Glue that addresses these needs. This version upgrade lowers AWS Glue pricing by 30% and improves performance with AWS optimized Apache Spark 4.1. It also augments developer experience with new features and adds support for Apache Iceberg V3 specifications that are suitable for enterprise adoption. The newly available AWS Glue 6.0 makes data processing workloads more manageable, faster to run, and easier to operate.
In this post, we cover the key capabilities of AWS Glue 6.0 and their performance benefits. We share code examples to help you take full advantage of the release, and we show you how to get started.
AWS Glue 6.0 highlights
AWS Glue 6.0 brings together four major improvements designed to transform how you build and run data integration workloads.
First, it upgrades the underlying runtime to Apache Spark 4.1.1, Python 3.13, Scala 2.13, and AWS SDK for Java 2.x, delivering performance improvements that can help with faster job completion times and lower costs.
Second, this release reduces current AWS Glue usage rate by 30%, and when combined with the performance improvements, you may realize an even lower effective cost.
Third, AWS Glue 6.0 introduces support for more capabilities of Apache Iceberg V3. This includes the VARIANT data type with automatic shredding, deletion vectors, row lineage tracking, nanosecond timestamps, and geo types. With these capabilities, you can build modern lakehouse architectures on the latest open table format standards.
Finally, new features like Spark Declarative Pipelines, Real-Time Mode for streaming and Python virtual environments with S3 caching are designed to further improve performance and developer experience. The following sections dive deeper into each of these areas.
Runtime upgrades
AWS Glue 6.0 upgrades the core runtime stack across the board, bringing newer versions of Apache Spark, Python, Scala, and the AWS SDK to your serverless data integration workloads.
- Apache Spark 4.1.1 – AWS Glue 6.0 runs an AWS optimized build of Apache Spark 4.1.1, a major generational leap from Spark 3.5 on AWS Glue 5.1. This release introduces improvements focused on intent-driven data engineering, real-time streaming with sub-second latencies down to single-digit milliseconds for stateless tasks, faster PySpark performance, and expanded SQL features.
- Python 3.13 – Supports Python 3.13, a stable release that brings interpreter changes, Python data model enhancements, standard library updates, and security updates.
- Scala 2.13 – Upgrades to Scala 2.13 which includes a collections library overhaul, language and syntax feature changes, standard library additions, and compiler performance updates.
Reduced Pricing
AWS Glue 6.0 cuts current AWS Glue pricing by 30%. This means every job you run on AWS Glue 6.0 costs 30% less per DPU-hour compared to AWS Glue 5.1, with no changes required to your workload configuration. When you combine this pricing reduction with the performance improvements delivered by runtime upgrades, your effective cost savings can compound because jobs can complete faster and consume fewer DPU-hours on a lower price point. If you run large-scale Extract, Transform, and Load (ETL) pipelines or recurring batch workloads, this compounding effect can help reduce your monthly spend.
To quantify the comparison, we ran the industry-standard TPC-DS benchmark at 3 TB scale on Parquet data stored in Amazon Simple Storage Service (Amazon S3), using 30 G.2X workers on AWS Glue. The following table compares the results we obtained in our tests for AWS Glue 6.0 and AWS Glue 5.1. Thus, based on TPC-DS benchmark at 3 TB scale, AWS Glue 6.0 delivers up to 36% better price performance than AWS Glue 5.1.
| . | AWS Glue 6.0 | AWS Glue 5.1 |
| Estimated Cost ($) | USD 5.61 | USD 8.87 |
Table 1: 3TB TPC-DS benchmark comparison between AWS Glue 6.0 and AWS Glue 5.1
Updated Open Table Format (OTF) support
AWS Glue 6.0 ships with updated versions of all three major open table formats – Iceberg 1.11.0, Hudi 1.1.1, and Delta Lake 4.2.0 – providing better performance, improved merge-on-read capabilities, streamlined concurrency control, and expanded SQL compatibility.
Besides supporting the latest open table format versions, AWS Glue 6.0 delivers Apache Iceberg V3 specification that is suitable for enterprise use. The highlight is Variant shredding, which AWS Glue uses to automatically decompose semi-structured data into physically optimized, columnar sub-fields, which should result in faster query read performance. Combined with deletion vectors for efficient row-level updates, UNKNOWN column types, default column values, and richer data type support, AWS Glue 6.0 is designed to make your open data lakes faster, more flexible, and more cost-efficient. AWS Glue 6.0 also adds support for geospatial data types (Geometry and Geography) and nanosecond-precision timestamps from the Apache Iceberg V3 specification, neither of which are currently supported in open-source Apache Spark 4.1. Additional features like row lineage tracking round out the Apache Iceberg V3 capabilities available on AWS Glue 6.0.
In the following sections, we illustrate select capabilities from Apache Iceberg V3 specification on AWS Glue 6.0.
- VARIANT column type
Apache Iceberg V3 introduces the Variant type to store semi-structured data (think JSON, XML, logs, and deeply nested event data) in a compact binary format. Variant shredding is designed to automatically decompose VARIANT columns into physically optimized, columnar sub-fields, facilitating predicate pushdowns and reducing scan overhead. It aims to provide simpler management of semi-structured data, without the need for complex flattening logic. With Variant type, you get the flexibility of embedding a JSON data type in your table columns while shredding is designed to help accelerate read queries and reduce costs.
- UNKNOWN column type
The UNKNOWN type in Apache Iceberg V3 acts as a flexible placeholder for columns where the data type is not yet determined at the time of table creation or data ingestion. Tables can accept all-null data initially, and the column type can be upgraded later without breaking ingestion pipelines or consuming applications. This can simplify schema evolution for rapidly changing data sources. Apache Iceberg V3’s UNKNOWN column type maps to Spark 4.1’s VOID type.
- DEFAULT column values
Apache Iceberg V3’s DEFAULT column values allow specifying a default value for a column in the table metadata. When you add a new column, the query engine is designed to automatically apply this default to older rows, without rewriting data or running manual backfill operations.
The following code demonstrates creating an Apache Iceberg V3 table that uses VARIANT and UNKNOWN types, and DEFAULT values for a column.
Prerequisites
To get started with this code example, make sure you have the following prerequisites.
- An AWS account.
- An AWS Identity and Access Management (IAM) role with permissions for AWS Glue, the AWS Glue Data Catalog, and Amazon S3. For more information, see Setting up IAM permissions for AWS Glue. This will be the AWS Glue job execution role.
- An S3 bucket to store the Iceberg table data.
Steps
To create an AWS Glue 6.0 job, use the following steps.
- Log in to your AWS account and open the AWS Glue console.
- Create a new ETL job, with Script editor option.
- Choose engine as Spark in the drop-down menu.
- Start fresh, Create script and copy-paste the following code.
- Replace the demo S3 bucket name with your bucket name in the code.
- Provide the following details in the Job details tab.
- A Name for the job.
- The IAM role you have from Prerequisites (2) for the IAM role of the job.
- Choose Glue 6.0 for the Glue version.
- Leave the rest as defaults.The following screenshot shows the Job details tab with illustrated values in the AWS Glue console.
Figure 1: Job details tab with the Glue version set to Glue 6.0
- Scroll down. Under Advanced properties, for Job parameters, add the following additional Job parameter key-value pair:
--datalake-formats=icebergThe following screenshot shows the Job parameters with the illustrated key-value pair in the AWS Glue console.
Figure 2: Job parameters with the datalake-formats key set to iceberg
- Save the job and choose Run.
- After the job is completed successfully, from the Runs tab – Run details, you can inspect the Output logs that take you to the logs in the Amazon CloudWatch console. The following shows the sample output for the
SELECTquery in the script.
Notice that we inserted two rows with values only in the record_id and the variant column. Variant column inserts were done using parse_json(). The reserved_field is of VOID type, hence returns NULL values. The status column is declared with a default active value and returns active, since the column was omitted during the insert operation.
- Deletion Vectors
Apache Iceberg V3 replaces the traditional positional delete files used in Apache Iceberg V2 to deletion vectors. This change can help improve Merge-on-Read (MoR) performance. This shift replaces heavy, multi-file Parquet reads with highly compressed, direct binary bitmaps that can provide lower storage overhead and faster reads on delete-heavy tables. In scenarios with heavy table updates, such as streaming change data capture (CDC) from operational databases, Apache Iceberg V3 can offer read performance advantage over Apache Iceberg V2.To validate the performance of deletion vectors, we created two identical AWS Glue streaming jobs and ingested the events into two different Iceberg tables, one in Apache Iceberg V2 and another in Apache Iceberg V3 format. The streaming CDC events were approximately 150,000 events per second, merge-on-read, update-heavy. Every micro-batch writes row-level deletes. We froze both tables at the same delete-heavy state and disabled compaction, leaving the tables with roughly 1.7 million rows in valid state out of the 26.4 million physical rows. The following table summarizes the read performance latency of the two Iceberg tables. We observed in this testing that reading from the delete-heavy Apache Iceberg V3 is at least 1.5 times faster than the reading from a similar Apache Iceberg V2 table. For larger enterprise scale Apache Iceberg V3 tables, the read performance could improve further.
Table 2 – Read latency comparison between Apache Iceberg V2 delete files and Apache Iceberg V3 deletion vectors
New ETL features
AWS Glue 6.0 introduces several additional capabilities designed to simplify how you build and manage data pipelines, some of which are discussed in the following list.
- Spark Declarative Pipelines (SDP) where you define the outcomes you want for your entire data pipelines in a declarative fashion with SQL statements or Python decorators while AWS Glue handles execution flow, dependency resolution, parallelism, checkpointing, CDC, and recovery automatically. This helps you focus on business logic rather than orchestration plumbing.
- Real-Time Mode (RTM) for streaming delivers continuous execution for Structured Streaming with sub-second latencies, down to single-digit milliseconds for stateless tasks. This can help support real-time use cases like fraud detection, live dashboards, and event-driven architectures without managing dedicated streaming infrastructure.
- Arrow-Native UDFs/UDTFs execute Python functions directly on PyArrow batches without Pandas conversion overhead, which can result in faster performance for custom transformation logic at scale.
- Recursive Common Table Expressions (CTE) adds WITH RECURSIVE queries natively, allowing graph traversals and hierarchical queries without workarounds or external libraries.
- Python data source filter pushdown evaluates filters at the data source designed to minimize data movement, reduce the volume of data scanned, and improve job performance.
- With Python virtual environments and S3 caching, you can provide pre-built Python dependencies, which should result in reduced startup latency for AWS Glue jobs by eliminating runtime dependency resolution. For existing jobs that use
--additional-python-modules, no action is required. AWS Glue automatically handles the conversion to virtual environments when your job runs on AWS Glue 6.0.
Dependent library upgrades
The following table summarizes the key runtime and library version upgrades on AWS Glue 6.0.
| Feature | Glue 6.0 | Glue 5.1 |
| Spark | 4.1.1-amzn-0 | 3.5.6-amzn-1 |
| Python | 3.13.14 | 3.11.15 |
| Scala | 2.13.17 | 2.12.18 |
| AWS SDK for Java | 2.44.6 (Version 1.x removed) |
2.35.5 |
| Boto3 | 1.42.84 | 1.40.61 |
| Java | 17.0.20 | 17.0.19 |
| Iceberg | 1.11.0 | 1.10.0 |
| Hudi | 1.1.1 | .0.2 |
| Delta Lake | 4.2.0 | 3.3.2 |
| AWS Glue Data Catalog client | 4.11.0 | 4.9.0 |
| EMR DynamoDB connector | 6.1.0 | 5.7.0 |
| Arrow | 18.3.0 | 2.0.1 |
| Hive | 2.3.10-amzn-1 | 2.3.9-amzn-4 |
Table 3: Runtime and library version comparison across AWS Glue 6.0 and AWS Glue 5.1
Getting started
To get started with AWS Glue 6.0, you can use one of the following methods.
- Open the AWS Glue console and create a new ETL job, selecting Glue 6.0 for the Job version. You can also use AWS SDK, AWS Command Line Interface (CLI) and Amazon SageMaker Unified Studio for creating Glue jobs with version 6.0.
- To get started with AWS Glue 6.0 interactively, use Glue Interactive Sessions within Glue Studio Notebooks (via the %glue_version magic) or connect with Spark Connect from your local IDE.
- Migrate your existing AWS Glue jobs to AWS Glue 6.0 using the Spark Upgrade Agent.
Clean up
To avoid incurring costs, clean up the resources you created for this post.
- Delete the Data Catalog database and the Iceberg table.
- Delete the data and metadata folders of the Iceberg table from your S3 bucket.
- Delete the AWS Glue job and the AWS Glue job execution IAM role.
Conclusion
AWS Glue 6.0 is designed to be faster, more cost-effective, and easier to use for building your open data lakehouse architectures and orchestrating your data pipelines. In this post, we discussed the key highlights of AWS Glue 6.0 and illustrated usage of Apache Iceberg V3 features with code samples. You can create new AWS Glue jobs on AWS Glue 6.0 or migrate your existing AWS Glue jobs to benefit from these improvements.
With Apache Spark 4.1.1, Apache Iceberg V3, Python 3.13, upgraded open table format libraries, and new streaming capabilities, AWS Glue 6.0 aims to help you build new data applications or to operate your existing data pipelines more efficiently and with less maintenance overhead.
We encourage you to test AWS Glue 6.0 in your development environment today. Check out this blog that talks about upgrading your AWS Glue jobs to AWS Glue 6.0. Also, in the coming days and weeks, look out for blogs on individual topics illustrating various features of Spark 4.1.1 and Apache Iceberg V3 on AWS Glue 6.0.
Acknowledgements: We thank the numerous engineers and leaders who helped build AWS Glue 6.0 to support customers with a highly performant Spark runtime and other value-added capabilities.
About the authors
Upgrade AWS Glue jobs to Glue 6.0 with AI-powered Spark upgrades
Post Syndicated from Prasad Nadig original https://aws.amazon.com/blogs/big-data/upgrade-aws-glue-jobs-to-glue-6-0-with-ai-powered-spark-upgrades/
Upgrading PySpark jobs to a new Apache Spark major version can introduce breaking changes. Removed configuration keys, stricter type casting, and Python library incompatibilities can cause runtime failures or silent behavior differences. With AWS Glue 6.0 now running Apache Spark 4.1 and Python 3.13, you need a reliable way to migrate your existing jobs while validating correctness.
In this post, we walk through upgrading a PySpark ETL job from AWS Glue 5.1 to AWS Glue 6.0. We use the generative AI upgrades for Apache Spark in the AWS Glue console. The upgrade analysis automatically identifies incompatibilities, iteratively resolves them, validates the result with data quality checks, and presents recommended changes for your review. AWS Glue 6.0 also delivers up to 36% better price performance* along with Iceberg v3, Spark Declarative Pipelines, Real-Time Mode, and Arrow-native Python UDFs.
What changes with AWS Glue 6.0
AWS Glue 6.0 runs Apache Spark 4.1, which introduces several behavioral changes from the Spark 3.5 runtime used in AWS Glue 5.1:
| Behavior | Spark 3.5 (AWS Glue 5.1) | Spark 4.1 (AWS Glue 6.0) |
| ANSI SQL mode | Disabled by default | Enabled by default |
| Legacy Parquet datetime configs | Supported | Removed (renamed) |
| Python runtime | 3.11 | 3.13 |
Beyond version compatibility, AWS Glue 6.0 also introduces:
- Apache Iceberg v3 with VARIANT Shredding for efficient semi-structured data handling.
- Spark Declarative Pipelines — agent-authorable ETL.
- Real-Time Mode — single-digit millisecond streaming latency.
- Arrow-native Python UDFs (PyArrow) for improved performance.
- Built-in observability with structured metrics and enhanced Spark UI.
- Up to 36% better price performance compared to AWS Glue 5.1*.
These runtime changes mean your existing AWS Glue jobs might encounter removed configuration keys, stricter type casting behavior, or Python package version incompatibilities when running on AWS Glue 6.0. Fixing these manually is time-consuming and error-prone. The following sections show how the generative upgrade analysis handles this automatically.
The sample job
Our example is a daily ecommerce order analytics pipeline running on AWS Glue 5.1:
What the job does:
- Ingests 10,000 orders from Parquet files with INT96 timestamps (including pre-1900 historical dates from a legacy system migration).
- Computes revenue metrics by casting string prices to numeric values and calculating line totals with discounts and tax.
- Segments customers using recency, frequency, and monetary (RFM) scoring through
mapInPandaswith pandas and scikit-learn. - Writes enriched results back to Amazon Simple Storage Service (Amazon S3).
Job configuration (AWS Glue 5.1):
This job runs successfully on AWS Glue 5.1. The following sections walk through how the upgrade analysis identifies and resolves incompatibilities when upgrading this job to AWS Glue 6.0. Before starting, confirm you have the prerequisites in place.
Prerequisites
- An AWS account with access to the AWS Glue console.
- An existing AWS Glue job on version 5.1 or earlier with at least one successful run.
- An Amazon S3 path for storing the upgrade analysis results.
Running the upgrade analysis from the console
The following steps walk through the upgrade analysis workflow using the AWS Glue console.
Step 1: Select your job
Navigate to your job in the AWS Glue Studio console. Confirm the job has a successful run history on AWS Glue 5.1 before starting the upgrade analysis.
Figure 1: Job run status for the job on AWS Glue 5.1
Step 2: Start the upgrade analysis
From the job’s Actions menu, select Upgrade with generative AI. Configure the following:
- Target AWS Glue version: 6.0.
- Results S3 path: An S3 location where the analysis stores its artifacts and recommendations.
Figure 2: The Upgrade with generative AI option in the Actions menu
Configure the target AWS Glue version and the S3 results path, then choose Run.
Figure 3: The Upgrade with generative AI window for setting the target AWS Glue version and results path
Choose Run. The analysis begins by running your job on AWS Glue 5.1 to establish a baseline. It then iteratively tests the job on AWS Glue 6.0, identifies failures, applies recommended fixes, and validates the job. If the upgrade analysis cannot resolve an incompatibility within its attempt budget, the analysis stops and reports the unresolved issue for manual review. Your original job remains unchanged.
Note: The upgrade analysis executes your job multiple times (one baseline run plus one or more validation attempts), and each run consumes Data Processing Units (DPUs). For large or long-running jobs, consider using the run configuration option to specify fewer workers or a smaller dataset to optimize analysis cost.
Step 3: Monitor progress
The console displays the analysis progressing through multiple validation attempts. Each attempt either succeeds or fails with a specific error, and the upgrade analysis uses that error signal to determine and apply the appropriate fix for the next attempt.
Figure 4: Upgrade analysis progress across multiple validation attempts
What the upgrade analysis found and fixed
The analysis completed in four validation attempts, identifying and resolving three distinct incompatibilities. The upgrade uses deterministic migration rules for known config changes, and automated diagnosis for runtime or code errors.
Iteration 1: Removed Parquet legacy configuration
The analysis first sanitizes any Spark configurations that were removed in Spark 4.1. Our job used spark.sql.legacy.parquet.datetimeRebaseModeInWrite and spark.sql.legacy.parquet.int96RebaseModeInWrite, which no longer exist.
Migration rule applied: The SQL configs with the spark.sql.legacy prefix were removed in Spark 4.1. They have been renamed to their non-legacy equivalents, preserving the original values.
Recommended change:
The read-side configs (datetimeRebaseModeInRead, int96RebaseModeInRead) already used the correct non-legacy names and required no changes.
However, with this fix applied, the validation run still failed because the Python module installation encountered an error on the AWS Glue 6.0 image.
Iteration 2: Python module version incompatibility
The pinned module versions (pandas==2.2.2, scikit-learn==1.5.0, numpy==1.26.4) could not be installed in the AWS Glue 6.0 Python 3.13 environment.
Error:
Recommended change: The upgrade analysis updated the version specifications from exact pins to minimum version constraints, allowing pip to resolve compatible versions for Python 3.13:
With modules installing successfully, the job launched on AWS Glue 6.0 but encountered a runtime error.
Iteration 3: ANSI mode strict type casting
Spark 4.1 enables ANSI SQL mode by default (spark.sql.ansi.enabled=true). Our revenue calculation casts string prices to double, but approximately 1.8% of records contain non-numeric placeholder values such as “N/A”, “pending”, or “null” from the upstream system. From a business perspective, this meant 1.8% of revenue orders were silently excluded from revenue metrics. This data quality issue was invisible to the original pipeline.
On AWS Glue 5.1 (ANSI mode off), cast("N/A" as double) silently returns null. On AWS Glue 6.0 (ANSI mode on), this throws an exception:
Error:
Migration rule applied: As of Spark 4.1, spark.sql.ansi.enabled is on by default. Casting a malformed value now raises CAST_INVALID_INPUT instead of returning NULL. The upgrade analysis resolved this by updating the script to use try_cast(), which safely returns NULL for malformed input while preserving ANSI mode protections for the rest of the job.
Recommended change:
Before (AWS Glue 5.1):
After (AWS Glue 6.0, fixed by the upgrade analysis):
This is a targeted fix that handles the known dirty data without disabling ANSI mode globally, keeping overflow detection and type safety active throughout the job.
Final validation and data quality check
After applying all three fixes, the analysis ran the job on AWS Glue 6.0 one final time and performed a data quality comparison between the AWS Glue 5.1 baseline output and the AWS Glue 6.0 output.
Result: The job completed successfully and all data validations passed with no mismatches detected between the source and target outputs.
Figure 5: Final analysis status with links to the results output path in Amazon S3
Reviewing the upgrade summary
The analysis produces a detailed summary stored in your S3 results path. This summary documents each validation attempt, the errors encountered, the migration rules applied, and the recommended configuration changes:
The following is a snippet from the upgrade summary (summary.md) showing the recommended changes and validation attempt details:
The summary documents each validation attempt, the changes applied, and the data quality results.
Figure 6: Upgrade summary snippet showing validation attempt details, data quality, and analysis results
After reviewing the recommendations, accept the changes to upgrade your job to AWS Glue 6.0. This updates your job definition with the recommended configuration, including the renamed Spark configs, updated module versions, and any script modifications. Because the analysis has already validated the job on AWS Glue 6.0 and confirmed data quality parity with the original, your job is ready for production.
After reviewing the recommendations, you can apply the upgraded script to your job.
Figure 7: The option to apply the upgraded script to the job
Choose Apply to confirm the upgrade.
Figure 8: The Apply button that confirms upgrading the job to AWS Glue 6.0
After applying, the job definition reflects the new AWS Glue version.
Figure 9: The AWS Glue version for the job after applying the upgrade
Python virtual environments in AWS Glue 6.0
AWS Glue 6.0 introduces --python-virtual-env-storage-prefix, a service-managed virtual environment with S3 caching that simplifies Python dependency management.
For existing jobs that use --additional-python-modules, no action is required. AWS Glue automatically handles the conversion to virtual environments when your job runs on AWS Glue 6.0. Your jobs continue to work without any changes.
For new jobs on AWS Glue 6.0, we recommend using the virtual environment approach:
How it works:
- On the first run, AWS Glue installs your modules into a virtual environment, packages it, and caches the result to your specified S3 path (approximately 15–30 seconds of additional startup time).
- On subsequent runs, AWS Glue downloads and extracts the cached virtual environment instead of running
pip install. - The cache is automatically invalidated when your module list, versions, or AWS Glue version changes.
This approach provides faster cold starts after the first run, requires no Docker image management (unlike --python-virtual-env), and is entirely service-managed with no maintenance burden.
Conclusion
The generative upgrade analysis identified and resolved three distinct compatibility issues in our AWS Glue 5.1 job, so the job now runs successfully on AWS Glue 6.0 with Apache Spark 4.1:
- The upgrade analysis renamed legacy Parquet datetime configuration keys (removed in Spark 4.1) to their current equivalents.
- The upgrade analysis updated Python module version specifications that were incompatible with Python 3.13 to use flexible minimum version constraints.
- The upgrade analysis addressed the new ANSI SQL mode default (which causes runtime failures on malformed data) with a targeted fix using
try_cast()to safely handle non-numeric values while preserving ANSI mode protections.
The analysis validated that the upgraded job produces output consistent with the original, and presented all changes as recommendations for review before applying them to your job.
Next steps
- Review the AWS Glue 6.0 documentation for the complete list of new features and changes. For a detailed walkthrough of what is new, see Introducing AWS Glue 6.0 for Apache Spark.
- Read the Apache Spark 4.1 migration for additional behavioral changes.
- Try the upgrade analysis on your AWS Glue jobs through the console.
- See the Python virtual environment documentation for detailed setup guidance.
- To reproduce this walkthrough, start with any existing AWS Glue job running on version 5.1 or earlier with a successful run history. No additional sample code or CloudFormation template is required.
After you have reviewed and accepted the upgrade changes, you can delete the analysis results stored in your S3 results path.
*Based on 3TB TPC-DS benchmark comparing AWS Glue 6.0 to AWS Glue 5.1.
About the authors
Arm’s AGI Data Center CPU at Hot Chips 2026
Post Syndicated from Ryan Smith original https://www.servethehome.com/arms-agi-data-center-cpu-at-hot-chips-2026/
At Hot Chips 2026, Arm is showcasing their AGI data center CPU, the company’s first complete commercial CPU design. Based around Arm’s Neoverse V3 CPU cores, AGI is designed to power the next generation of agentic AI servers
The post Arm’s AGI Data Center CPU at Hot Chips 2026 appeared first on ServeTheHome.
The Cloudflare Blog – Brought to you by EmDash
Post Syndicated from Kody Jackson original https://blog.cloudflare.com/cloudflare-blog-uses-emdash/
You likely noticed the recent redesign of the Cloudflare Blog. We added dark mode, modernized the look and feel, and made a lot of other small improvements along the way.
What you might not have noticed – well, except for those who are more terminally online – is that the redesign was part of a much bigger migration project. On Wednesday, August 12, we moved the blog to EmDash, a content management system (CMS) built especially to work on Astro and with Cloudflare.
We’ll take you into the migration story – what we learned and how EmDash got better – as well as into the benefits we’re already seeing from a new platform.
We are Customer Zero
At Cloudflare, Cloudflare itself is Customer Zero. This means that we use our products. And – in use – we make them better for ourselves and our customers.
This is a very real cultural value at Cloudflare. The burden of proof is on you if you want to use an external vendor. Why can’t that team support you, what gaps are there, why can’t those gaps be filled, and are those “gaps” true requirements?
This preference is even enshrined in our internal engineering standards, known as our Codex.
We don’t just build products for others; we build them to run Cloudflare itself. We are our own first, most demanding customer.
We validate scale, security, and usability on our own massive infrastructure before a paying customer ever touches the product. If a product breaks, it breaks us first. This forces us to fix issues immediately, ensuring that by the time a feature reaches the enterprise, it has already survived the harshest production environment on earth.
With the launch of EmDash and some limitations with our current CMS vendor, we knew that we’d likely be the Customer Zero for EmDash internally at Cloudflare.
Customer Zero in Action
When we began our initial migration conversations, we started with two main questions:
- Does EmDash work for us?
- Can EmDash scale?
Does the platform work?
Our first question was the most broad, does EmDash work for us? This is something you’d want to know broadly about any new platform, but especially one that’s pre-1.0.
To answer this question, we ran through a bunch of common user flows, such as:
- Publishing and unpublishing a post
- Authoring a new post
- Scheduling a post
- Adding media items
By and large, EmDash held up pretty well to these usability tests. The gaps we found were generally related to:
- The sheer scale of the Cloudflare Blog (media, content entity search, and bylines)
- Nuances around localization, SEO, and Content Security Policies (CSPs)
- Usability features for the admin editor – especially ones that might delay the publishing of a post – such as easier findability for custom HTML blocks, bugs in the in-entity content editor, and keeping the formatting toolbar in view for longer posts.
The biggest oversight we found was around scheduled posts, which didn’t work until EmDash version 0.19.0. This gap was understandable given the early version of EmDash, but it was also definitely something we didn’t want to be finding out after the scheduled time for a post.
Can EmDash scale?
Our biggest concerns were whether our proposed EmDash setup could handle the traffic we saw on the Cloudflare Blog.
The traffic pattern to our blog is incredibly varied. Normal load sits in the neighborhood of 75 requests per second (RPS), but also spikes up to over 5,000 RPS. Some of these spikes line up with the publishing times of new posts, meaning those posts went viral and attracted a lot of attention. Others happen during all points of the day and night, which likely means folks are sending some extra traffic our way, just to see what happens.
Performance also matters for our systems (and our readers). Cloudflare is a web performance company, after all, so the speed at which a page loads becomes incredibly important.
With those two concerns in mind, we built out some scenarios using k6, an open-source performance testing tool:
- Ramp: Where we gradually increase requests up to triple the prod baseline and then cool down.
- Breakpoint: Where we ramp from 0 to 100 RPS over 10 minutes, stopping when something breaks.
- Burst: Where we throw an immediate traffic load of 7,000 RPS and see what happens.
For each of those scenarios, we evaluated:
- Availability: Failure when more than 0.01% of HTTP requests lead to 5xx errors, meaning the application couldn’t handle the traffic.
- Latency:
- P95 latency: Failure when more than 5% of responses exceed 500ms.
- P99 latency: Failure when more than 1% of responses exceed 1000ms.
Armed with these tests – and a lot of internal discussion and data points – we came to our production architecture:
- EmDash, running on a Cloudflare Worker
- Running behind the new Workers Cache (we believe as the first major site to do so)
- Using the new EmDash object cache built on Workers KV, which the EmDash team built specifically for our use case.
- Using Cloudflare’s new, first-party Hyperdrive integration with PlanetScale.
The multiple layers of caching we put in place play a key role in making the blog both fast and resilient. In the diagram below, they are ordered from top to bottom by proximity to the user:
With this setup, we’re typically serving 99.5% of static files from a cache and 70% of requests from a cache, improving frontend performance and decreasing load on the database.
Once we had that architecture in place, we could start thinking about the frontend redesign as well.
Frontend redesign
Beyond updating the backend architecture, the migration offered us the perfect opportunity to bring the blog's interface into alignment with Cloudflare’s updated visual language. We rebuilt the frontend experience using patterns established by the Kumo design system, creating visual and structural consistency between the Cloudflare homepage, dashboard, and marketing sites. The result is a cohesive reading experience that feels like a natural extension of the broader Cloudflare ecosystem.
A major priority for this redesign, and a long-overdue request from our readers, was native support for light and dark modes. We implemented theme switching tied directly to system preferences, alongside an explicit toggle, and ensured that accessibility guidelines were strictly met across both themes. Regardless of preference, the updated palette and code syntax highlighting adapt seamlessly without sacrificing legibility.
We also took the opportunity to solve a few long-standing user experience quirks, starting with our email subscription form. Previously, the subscription box lived in the top right corner of the page. Because of its placement, readers frequently mistook it for a search bar and typed their search queries directly into the input field.
To fix this, we moved the email sign-up into a dedicated call-to-action block at the bottom of posts.
Now, once a reader finishes an article and wants to stay updated, the prompt to subscribe appears naturally at the end of a post.
Finally, we introduced two dedicated sidebar features on interior post pages to improve navigation and community engagement. On the right, an "On this page" table of contents tracks your progress and lets you jump directly to specific sections of longer technical posts. On the left, a new "Discuss Online" section makes it effortless to share articles and engage in conversations across social platforms and developer communities.
Rollout strategy
As we got nearer to our migration, we started focusing on the broader question of “how do we make this change safely?” Ensuring zero downtime for our readers was a non-negotiable requirement, alongside guaranteeing a seamless fallback mechanism if something went wrong at the last minute.
To achieve this, we deployed a proxy Worker to intelligently route traffic between the legacy blog and the new EmDash-powered site. This Worker set a version cookie on requests, which then let us route incoming traffic to the new or legacy experience accordingly. Additionally, this strategy allowed us to fall back to the legacy blog if the new site experienced any 500 errors. Thanks to the flexibility of Cloudflare Workers, this proxy was relatively simple to create and scaled without any issues. The ability to configure a direct worker-to-worker connection through the NEW_BLOG service binding was particularly useful here, as it reduced latency for any end user going through the proxy. This service binding let the proxy Worker dispatch incoming requests directly to the new blog Worker instead of sending them through a public hostname, DNS, TLS, and an outbound HTTP connection.
On launch day, we initiated a gradual rollout, starting at just 1% of total traffic, then incrementally stepping up to 5%, 15%, and beyond as we validated system health. This phased approach allowed us to observe how the platform handled real-world production load while catching a few last-minute edge cases without impacting the vast majority of our audience. By the end of the day, we had comfortably shifted 100% of traffic over to the new platform.
Results
Measurable performance gains
One of our primary objectives for this migration was to deliver a faster, more reliable site to our readers, and the early data shows we accomplished exactly that.
Comparing p95 response latencies between the old architecture (green line) and the new EmDash setup (yellow line) revealed a stark difference. Where the previous platform experienced periodic latency spikes under load, the new system maintains a remarkably flat, consistent response profile. By running EmDash on Cloudflare Workers alongside our new caching layers, we’ve delivered a significantly faster and more performant reading experience across the board.
We’ve seen all these performance gains – and minimal errors – while serving up to 850 RPS.
MCP servers
With this change, the blog also got more accessible for agents, in two distinct ways.
The first is that we released a new Model Context Protocol (MCP) server for the Cloudflare Blog.
An MCP server bundles up a bunch of specific tools that your agent can then use to interact with an external resource, almost like an API for agents.
Using that MCP, you can now use the following tools with your agents:
search_postslist_postsget_postlist_tags
With the new, intuitive EmDash APIs and AI search endpoints exposed by our Worker, creating this new MCP took just a few hours of work.
The second is that – for our blog authors – EmDash has an MCP server for EmDash itself, meaning that they can browse, create, and edit content, publish and schedule posts, remove files, and more.
Though this sort of agentic tooling is becoming more standardized in the CMS industry, what’s not standard is that it’s available without any additional cost. The MCP is just another part of the platform, reflecting a growing trend of designing for agents, as well as humans.
The first test: Agents Week
At Cloudflare, we run multiple innovation “weeks” a year, where we set ambitious goals for internal teams around specific themes. These weeks push our products forward, as well as help customers digest the changes that are constantly happening at Cloudflare.
The latest of these, Agents Week, was quite a test for the new blog. We launched 18 new posts over 9 days. And those posts got a lot of traffic, close to 3 million pageviews.
On the frontend, our new blog Worker did very well, serving up to 450 RPS without any noticeable issues. Thanks to Cloudflare’s built-in DDoS protection, we also absorbed a 28,000 RPS DDoS attack on August 10th, also without any noticeable issues.
On the editing side, we continued to find some issues. Most of these involved small quirks of the editing experience, though we also found some bugs specifically around scheduled posts. We’ve since raised these to the EmDash team and are confident that they’ll be fixed before Birthday Week.
Give EmDash a try
We want to give a heartfelt thank you to the EmDash team, who made this migration about as smooth as possible and were incredibly receptive to our feedback. This is how Customer Zero is supposed to work, and it’s incredibly gratifying to share an inside look into that process with all of our readers as well.
If you’re in the market for a new CMS, try out EmDash today. It’s pretty amazing and – with the upcoming launch to v1 – it’ll be getting even better soon.
Fujitsu’s Arm-based Monaka Data Center CPU at Hot Chips 2026
Post Syndicated from Ryan Smith original https://www.servethehome.com/fujitsus-arm-based-monaka-data-center-cpu-at-hot-chips-2026/
At Hot Chips 2026, Fujitsu outlined its upcoming Monaka CPU, a highly efficient Arm-based CPU for data centers and AI workloads
The post Fujitsu’s Arm-based Monaka Data Center CPU at Hot Chips 2026 appeared first on ServeTheHome.
NVIDIA Vera CPU at Hot Chips 2026
Post Syndicated from Ryan Smith original https://www.servethehome.com/nvidia-vera-cpu-at-hot-chips-2026/
At Hot Chips 2026, NVIDIA went into detail on its upcoming Vera server CPU, and the Olympus CPU architecture. With 88 cores per chip, NVIDIA has ambitious aims for its in-house designed CPU architecture
The post NVIDIA Vera CPU at Hot Chips 2026 appeared first on ServeTheHome.
Временната отсечка на Зеления ринг и какво да очакваме
Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/greenring-aug26/
В събота реших да мина през отсечката на Зеления ринг в Изгрев и Слатина, за която от общината през страницата си за проекта за Зеления ринг писаха, че ще се ремонтира и доведе до временно състояние, за да могат феновете да стигат по-лесно до европейското по волейбол в Арената след две седмици. Това всъщност е много добра идея, тъй като всеки път като има събитие там тротоарите и пешеходните пътеки около кръговото на 4-ти км. се препълват създавайки опасност както за пешеходците, така и блокирайки движението.
Отсечката е от началото на хотела на Тиков до края Арената. Вижда се, че са сложили бордюри и вече е насипан част от чакъла. Хотел East Plasa партнирали като ще предоставят достъп за 10 метра през имота си и ще изградят стълби до нивото на зеления ринг. Това, всъщност, е най-малкото, което следва да направят предвид, че изсякоха дърветата там, унищожиха почвения слой и са оставили строителни отпадъци в края на разчистената площ докато строяха хотела си.
Попитах и ми отговориха, че няма да се слага асфалт и бордюрите са само, за да държат чакъла. Лампите са също временно докато не се реши как да изглежда цялата отсечка от гара Пионер. Събитията за обсъждане на плановете щели започнат през септември. Питах и какви са плановете за минаване с колело или детска количка и отговориха, че се обмисля и това.
Ако искате да стигнете до същото място. Единственият начин в момента е да влезете откъм ул. Любен Русев – където е Топлофикация и където районният кмет на Изгрев иска да му строи частник ново кметство по схема кон за кокошка. Там има едно мостче (единственото водещо до бъдещото кметство), по което ще стигнете до още неразчистената част от зеления ринг. Завивате надясно и ще ви пречат само строителните отпадъци от строежа на East Plasa. Ако се разчистят бетонните блокове, ще може да се минава с колело и от там.
Има една пътека вляво, която обаче стига до частен имот (дясното кръгче на последната снимка). Би трябвало да може да се влезе и от пътека още на изток, но общински имот-улица стигаща до зеления ринг е застроена с вход на гараж (лявото кръгче). Не е ясно дали и как е позволено това, но ще трябва да се разруши.
Всъщност, докато бях в Зеления ринг видях поне три случая на незаконно строителство или нарушения в готови сгради. Разпознават се с просто око. Когато районният ни кмет, на когото са разпределени от call.sofia тези сигнали, неизбежно слезе да се снима за фейса след две седмици на вече свършената работа, надявам се да ги забележи и най-вече да ги санкционира. Ха дано, ама надали.
Още статии свързани с темата за Зеления ринг може да прочетете тук:
Intel Core Series 3 (Wildcat Lake) CPU at Hot Chips 2026
Post Syndicated from Ryan Smith original https://www.servethehome.com/intel-core-series-3-wildcat-lake-cpu-at-hot-chips-2026/
At Hot Chips 2026, Intel went deeper into its newest budget SoC design, Wildcat Lake, which is being used in consumer and edge devices
The post Intel Core Series 3 (Wildcat Lake) CPU at Hot Chips 2026 appeared first on ServeTheHome.
IBM Z and LinuxONE Dual-ISA Processor and AI Acceleration at Hot Chips 2026
Post Syndicated from Patrick Kennedy original https://www.servethehome.com/ibm-z-and-linuxone-dual-isa-processor-and-ai-acceleration-at-hot-chips-2026/
At Hot Chips 2026, IBM showed a crazy new IBM Z CPU that will support IBM Z and Arm instruction sets natively.
The post IBM Z and LinuxONE Dual-ISA Processor and AI Acceleration at Hot Chips 2026 appeared first on ServeTheHome.
AWS Weekly Roundup: Student Rewards on AWS Builder Center, Local Zone in Las Vegas, and more (August 24, 2026)
Post Syndicated from Esra Kayabali original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-student-rewards-on-aws-builder-center-local-zone-in-las-vegas-and-more-august-24-2026/
During my time at AWS, I have always looked for opportunities to work with students. I have delivered over 50 talks at universities across the region, and watching the potential in the room is always a strong motivator. It reminds me of why I do this work, and that the students I meet today may well become our customers and collaborators tomorrow. That is why I am happy to open this week with Student Rewards on AWS Builder Center.
Rick Suttles published Introducing Student Rewards on AWS Builder Center, a new benefit for verified higher education students. When you verify your enrollment through SheerID and complete your Builder Center profile, you unlock 12 months of premium AWS Skill Builder access (900+ courses, hands-on labs, certification exam prep, and game-based learning). From there, you earn badges through actions on Builder Center: publishing articles, commenting, and maintaining engagement. At 7 badges, you unlock $10 in AWS Credits. At 14 badges, another $20 in credits. At 21 badges, you earn an AWS Foundational Certification exam voucher ($100 value).
This represents a commitment of over $500 million in resources during this back-to-school season, providing students with the training, tools, and certification needed to start building their careers in cloud and AI. Student Rewards is available to students 18 years or older and enrolled at accredited higher education institutions worldwide, subject to verification and applicable terms.
Verify your student status and start learning, earning badges, and unlocking rewards!
Last week’s launches
Here’s what else happened this week.
- A new AWS Local Zone in Las Vegas, Nevada – This new Local Zone supports Amazon EC2 C7i, M7i, R7i, and C8gn instances, Amazon EBS, Amazon ECS, Amazon EKS, Application Load Balancer, and AWS Direct Connect. AWS Local Zones are now available in more than 30 metropolitan areas worldwide. In addition, AWS added a fourth Availability Zone to the Europe (London) Region, delivering next-generation AI and ML capacity with Trn3 and P6 accelerated instances alongside general-purpose compute.
- Amazon EC2 Auto Scaling now supports batch instance termination – You can now pass up to 100 instance IDs to the
TerminateInstanceInAutoScalingGroupAPI to terminate them as a batch, reducing the number of API calls needed to scale down your Auto Scaling groups. Batch termination is designed for workloads that need to rapidly scale down, such as AI/ML training jobs, container orchestrators, or event-driven architectures that spin up large fleets temporarily. - AWS CloudShell now includes a built-in visual file editor – CloudShell now includes a visual file editor that you can launch directly from your shell session using a single edit command. The editor supports syntax highlighting, find-and-replace, multi-line selection, copy-paste, and undo-redo in a single browser session. Whether you are updating a deployment script, modifying an agent steering file, editing a CloudFormation template, or fixing a Lambda function, the editor provides a seamless edit-and-run experience without leaving CloudShell.
- Amazon Bedrock now supports SpaceXAI Grok 4.6 with cross-Region inference – Grok 4.6, a frontier model built for coding, agentic tasks, and knowledge work, is now available on Amazon Bedrock. The model runs on the bedrock-runtime endpoint with support for the Responses, Chat Completions, and Converse APIs, and works with existing account-level controls including model invocation logging, Amazon CloudWatch metrics, and cost itemization in AWS Cost Explorer.
- Amazon Bedrock expands API support and introduces cross-Region inference for OpenAI models – Amazon Bedrock now supports OpenAI GPT-5.6 models (Sol, Terra, and Luna) with the Responses, Converse, and Chat Completions APIs, and adds cross-Region inference. Geo cross-Region inference routes requests within a predefined geography (including new US Geo support with this launch), while Global cross-Region inference serves requests from any commercial AWS Region at a lower per-token cost.
- AgentCore payments is now generally available in Amazon Bedrock AgentCore – At general availability, AgentCore payments includes Quick Create for Coinbase credential provisioning directly within the AgentCore console, a curated Coinbase Bazar MCP server of pay-per-use x402 endpoints via AgentCore gateway, support for the Machine Payment Protocol (MPP), and the “upto” scheme in the x402 protocol for pay-per-inference and dynamic pricing use cases. To learn more, visit the AI Blog post.
- AWS Glue 6.0 delivers 30% price reduction and Iceberg v3 support – AWS Glue 6.0 is built on a fully modernized runtime, Apache Spark 4.1, Python 3.13, and Scala 2.13, delivering 30% lower pricing than previous AWS Glue versions. With Iceberg v3, Glue 6.0 adds the VARIANT data type with automatic shredding for faster reads on semi-structured data, deletion vectors for high-performance row-level updates, geometry and geography data types for spatial processing, and flexible schema evolution.
For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.
Other AWS news
Here are some additional posts you may find useful:
- Updates to your AWS Sign-In experience – AWS is gradually introducing updates to the sign-in and sign-up experience. The redesigned sign-in page introduces a unified email entry point for root users and customers using the new email-based sign-in method, while IAM users continue signing in with their account ID, username, and password. The page also includes sign-in options for customers whose AWS account was created using a supported identity provider (Google, GitHub, Apple, or Amazon.com). A redesigned session selection page simplifies viewing and managing multiple active account and role sessions. If your organization relies on browser automation or scripted workflows that interact with the sign-in page, review the post to understand how these changes might affect your configuration.
- In the works: AWS Builder Lofts in Berlin, Hyderabad, and São Paulo – My colleague Channy announced plans to open new Builder Lofts in three cities. Since the first Builder Loft opened in San Francisco in July 2025, it has welcomed more than 22,500 developers through its doors. Each new location will be a permanent community space offering free workshops, networking events, pitch nights, content creation spaces, and co-working areas. Berlin will focus on digital sovereignty and security-readiness, Hyderabad on AI and cloud-native architecture, and São Paulo on supporting Latin America’s developer ecosystem.
- AWS and Amazon WorkSpaces recognized as a Leader in the 2026 Gartner Magic Quadrant for Desktop as a Service – AWS has been named a Leader in the 2026 Gartner Magic Quadrant for Desktop as a Service (DaaS) for the third consecutive year, evaluated on Completeness of Vision and Ability to Execute. Gartner noted strengths in operations, geographic strategy, and overall viability. This is also the first year the evaluation includes Amazon WorkSpaces for AI agents, a capability that runs AI agents within the same desktop environment, security perimeter, and audit trail as human users.
For a full list of AWS blog posts, be sure to keep an eye on the AWS Blogs page.
Upcoming AWS events
Check your calendar and sign up for upcoming AWS events:
- AWS Summits – Free in-person events for builders and innovators to learn, connect, and explore the latest in cloud. Coming up: Zurich (September 2), São Paulo (September 3), Tel Aviv (September 10), and Dubai (September 30). You can also watch keynotes and sessions on the AWS Summits Global Livestream + On-Demand Hub. To access live and on-demand content for a particular Summit, you need to be registered for that event.
- AWS Community Days – Community-led conferences planned and delivered by community leaders. Upcoming events include Bolivia, Santa Cruz (August 29), Toronto, Canada (August 29), JAWS SONIC, Tokyo (September 5), Warsaw, Poland (September 8).
Visit the AWS Builder Center to meet other builders, contribute solutions, and find resources that help you keep building.
Summer is slowly coming to an end, and I am already planning a few days off in the coming months to keep me motivated through the rainy autumn ahead. I hope you are doing the same. Come back next week for more!
Rapid7 Analysis: Microsoft SharePoint Remote Code Execution (CVE-2026-63520)
Post Syndicated from Stephen Fewer original https://www.rapid7.com/blog/post/ra-microsoft-sharepoint-remote-code-execution-cve-2026-63520
S10 E14: Bob Menendez & McKinsey: Last Week Tonight with John Oliver
Post Syndicated from LastWeekTonight original https://www.youtube.com/watch?v=-BRWR6iK2iY
How a global payment processor preserved AWS RAM shares and Lake Formation permissions during an AWS Organizations migration
Post Syndicated from Sam Mukherjee original https://aws.amazon.com/blogs/architecture/how-a-global-payment-processor-preserved-aws-ram-shares-and-lake-formation-permissions-during-an-aws-organizations-migration/
Accounts move between organizations in AWS Organizations whenever a business changes shape. A merger folds one estate into another. A divestiture carves one out, and some companies run more than one organization by design.
The moves take more care when AWS Resource Access Manager (AWS RAM) resource shares are involved. An organization-bound share trusts an account through its organization membership, so when the account leaves, AWS RAM removes that association. Anything in production that depends on a shared resource needs a continuity plan before the first account moves.
A leading worldwide provider of payment technology and software solutions, based out of the United States, used temporary AWS RAM resource shares to preserve AWS Lake Formation permissions during an AWS Organizations migration of 382 AWS accounts. The payment processor serves merchants and financial institutions around the world. The program separated them from their former parent company, a US-headquartered financial technology provider serving banking and capital markets clients globally, before a Transitional Service Agreement (TSA) expired in April 2026.
The migration unfolded alongside wider corporate change. In January 2026, the payment processor was acquired by a leading payments technology company headquartered in the United States. The transaction transforms the acquirer into a pure-play commerce solutions provider, serving the full spectrum of clients from small businesses to global enterprises worldwide. The migrating estate also included the payment processor’s embedded payments platform, a US-based provider of embedded payment and automated onboarding tools for software-as-a-service (SaaS) platforms.
Most workloads kept running when the original organization-bound shares broke, but the control plane lost access. They needed a migration pattern that preserved service continuity without leaving temporary permissions behind.
AWS partnered with them to design and validate that pattern in two weeks. It uses retained bridge shares for the move, then restores the original shares as the durable permission objects.
In this post, we explain why the bridge works, why the original share must return, and how the company applied the pattern at enterprise scale. For command-level implementation, see Transfer AWS accounts between AWS Organizations while preserving AWS Lake Formation permissions and aws-samples/sample-aws-ram-org-migration.
Solution overview
An AWS account can consume a resource to share automatically while it belongs to the same organization as the producer. When the account leaves, AWS RAM removes that organization-bound principal association. Creating a retained bridge share as an external association before the move preserves access through the organization’s change.
After the move, the company restores the migrated account to the original share, verifies access, and removes the bridge. The original share remains the AWS Lake Formation-managed source of truth. New grants and resource changes continue to attach to it, not to the point-in-time bridge copy. Keeping both would create duplicate permission state and drift.
The following diagram shows the migration wave structure.
The company’s cloud engineering team ran 14 non-production waves, a production pilot, 12 weekly production waves, and three contingency waves. The TSA expired inside the contingency window, leaving about one week of usable slack.
Challenge
The risk surfaced in a production wave in February 2026. A terraform apply against a shared AWS Transit Gateway failed with a permission error, although traffic kept flowing and no alarm fired.
This was a control plane failure. Existing attachments, DNS paths, and certificates continued to work, but engineers could not change shared resources. The dedicated AWS Transit Gateway, Amazon Route 53 Resolver, and the embedded payments platform’s AWS Glue Data Catalog waves were still ahead.
Why the issue stayed hidden
Most services retain their data plane when an AWS RAM association breaks. For example, an Amazon Elastic Compute Cloud (Amazon EC2) instance in a shared Amazon Virtual Private Cloud (Amazon VPC) keeps running, but the account cannot launch a new instance. Infrastructure-as-code exposed the problem because it needed control-plane access.
The following table summarizes the affected resource types confirmed by the customer.
| Resource | AWS service | Effect of losing the share |
| AWS Transit Gateway | ec2:TransitGateway |
Loses control plane access, keeps the data plane |
| Amazon Route 53 Resolver rules | route53resolver:ResolverRule |
Risk of DNS resolution disruption |
| AWS Private Certificate Authority (AWS Private CA) | acm-pca:CertificateAuthority |
Loses the share, issued certificates keep working |
| Amazon EC2 prefix lists | ec2:PrefixList |
Keeps the data plane, blocks new resource creation |
| AWS Glue Data Catalog databases and tables | AWS Glue and AWS Lake Formation | Requires bridge-share validation before migration |
Some services require additional handling. Depending on its resource-cleanup configuration, an AWS Firewall Manager policy can remove AWS Network Firewall rules, which you must then redeploy, and organization-integrated AWS CloudFormation StackSets can delete stacks unless you set them to retain.
The embedded payments platform initially entered the estate through an acquisition by the former parent company. Its embedded payment and automated onboarding capabilities were subsequently integrated into the payment processor’s ecosystem to support a broader platform-focused offering for SaaS providers. The platform shared databases and tables across 10 accounts with account IDs as principals, and the workstream was paused rather than testing the migration against production.
Why the original shares broke
The company had enabled sharing with AWS Organizations in the producer account. AWS RAM therefore trusted each in-organization principal through organization membership, even when a share named an account ID. When an account left the source organization, AWS RAM removed that organization-bound association.
A share created for a principal outside the organization behaves differently. AWS RAM sends an invitation, and the accepted association is external. Because it does not depend on organization membership, it survives the account move. The bridge-share pattern uses this behavior.
Why non-production testing missed it
The company’s non-production accounts were already in a separate organization. They never crossed the boundary that caused production associations to break.
Fourteen clean waves validated the migration process but not the production-only condition. Each validation environment must cross the same trust boundary as production.
Applying the bridge-share pattern
This failure was raised with the AWS account team, which brought AWS RAM, AWS Glue, AWS Lake Formation, and AWS Organizations service teams into the response. The company first used a manual recovery path for 21 accounts while the teams automated a scalable approach.
On February 27, 2026, AWS released RetainSharingOnAccountLeaveOrganization for new AWS RAM resource shares. The setting marks principals as external after they accept the invitation. The customer confirmed that the setting does not retrofit existing shares, so those shares needed a temporary parallel share.
Retaining access during the move
AWS RAM allows a resource to belong to more than one resource share, so a parallel share can exist alongside the original. A second retained share was created alongside each original, targeting the same consumer account.
The consumer accepted the invitation before migration, creating an external association. During the move, AWS RAM removed the original organization-bound association while the bridge continued to grant access. AWS Organizations also support transferring an account directly between organizations, so the move itself does not require an intermediate standalone period.
Why restore the original share?
The bridge is a migration-only continuity copy. The original AWS Lake Formation-created share remains the durable, service-managed permission object. If a team adds a grant or changes a shared resource during the migration window, that change applies to the original share, not automatically to the bridge.
The company therefore restored migrated principals to the original share before deleting the bridge. Leaving both in place would create two permission paths that can diverge, complicate audits, and conceal which share is authoritative.
Automation deletes a bridge only after it finds a non-bridge original whose resources, principals, and permissions cover the bridge and whose associations are all ASSOCIATED. This check confirms the original share’s associations are active before removing the temporary path. Access and connectivity were validated separately, as described in the Outcome section.
Validated workflow
AWS validated the pattern across three test accounts and two organizations before it was used in production. Testing confirmed that allowExternalPrincipals alone was not enough. The bridge also required retainSharingOnAccountLeaveOrganization.
The following diagram shows the bridge before and after the account move.
Each production wave used five steps:
- Inventory. Map each original share, resource, principal, permission, and Region. AWS RAM is Regional, so repeat the inventory in every in-scope Region.
- Create and accept bridges. Create a retained share for the same resource and principals, then accept its invitation from each consumer account before migration.
- Migrate. Move the account. AWS RAM removes the organization-bound association, while the accepted bridge keeps access active.
- Restore originals. Add the migrated account IDs back to the original shares as external principals. This reactivates the durable shares and includes grants created during the migration window.
- Validate and remove bridges. Confirm resources, principals, permissions, and association status, then delete only bridge shares fully covered by active originals.
This workflow ran for every remaining production wave and kept the weekly cadence.
Validating AWS Glue and Lake Formation permissions
The embedded payments platform shared AWS Glue Data Catalog databases and tables across 10 accounts, with account IDs as principals. The configuration was reproduced in disposable accounts, and the resource policy was recorded through a cross-organization move.
The validated automation records principal-to-share mappings, supports dry-run and execute modes, restores principals to the original shares, and deletes bridges only after validation. The embedded payments platform completed its production migration on July 21, 2026.
Outcome
- The global payment processor migrated 378 of the 382 accounts into its landing zone. The final four awaited approvals from external stakeholders.
The TSA with the former parent company ended on schedule in April 2026. No customer-facing workload lost availability, and the company recorded no network drops across the production waves. The company and AWS moved from discovery to a validated bridge-share pattern in two weeks.
After each migration, the cloud engineering team restored the original shares, verified access and connectivity, and removed the bridges. Deleting the temporary copies confirmed that the original service-managed permission path was active and authoritative.
Production, non-production, and the embedded payments platform now run in one landing zone. They control their own guardrails, security posture, provisioning, and change process.
AWS has published the validated pattern and automation, so other organizations can start with a tested procedure.
Lessons learned
This program produced three lessons for organizations planning similar migrations.
Match validation boundaries to production
A test organization cannot expose this failure unless it crosses the same organization boundary as production. Map each production risk to an environment that can reproduce it before the first wave.
Monitor control plane changes
AWS RAM emits resource share state-change events directly to Amazon EventBridge, and AWS CloudTrail records DisassociateResourceShare API calls for audit. A weekly post-migration sweep provided a periodic reconciliation check to catch stale shares.
Inventory dependencies and destination guardrails
The Account Assessment for AWS Organizations tool inventories AWS RAM dependencies before teams set the wave plan. The company’s cloud engineering team reviewed destination guardrails at the same time. A service control policy that blocked ram:AcceptResourceShareInvitation during migration windows was temporarily adjusted.
Conclusion
The migration of this leading payment technology and software company shows how a retained bridge share can protect access while an account moves between AWS Organizations. The bridge is temporary: restoring the original share keeps AWS Lake Formation permissions aligned with future grants and avoids two sources of permission state. Inventory, dry-run-first automation, and post-move validation helped the company meet its deadline without customer disruption.
Next steps
To apply this pattern, read Transfer AWS accounts between AWS Organizations while preserving AWS Lake Formation permissions and review aws-samples/sample-aws-ram-org-migration. Run the scripts in dry-run mode, validate each Region and account, and engage your AWS account team early when AWS Glue Data Catalog or AWS Lake Formation resources are in scope.
About the authors
[$] How to be safe from quantum computing
Post Syndicated from daroc original https://lwn.net/Articles/1088305/
Practical quantum computers have been ten years away for the last several
decades. Now, however, it’s beginning to look as though they will be
possible in just a few years. Recent
research with obfuscated results demonstrated much lower memory requirements to factor
ECDSA keys on a quantum computer, with
work by other researchers in the open more than halving memory use compared
to the state of the art in 2023.
At the same time, computer
manufacturers are
boasting quantum processors that retain viable superpositions over longer periods.
Given how slowly software updates filter out to stable systems, it’s worth
looking at what configuration changes and protocol updates are needed to be safe
from quantum computers now.
Emacs 31.1 released
Post Syndicated from jzb original https://lwn.net/Articles/1090308/
Version 31.1 of the Emacs editor has been released. There is a long list of
changes including the removal of the Emacs dumper, a new user Lisp
directory feature, a “Send to…” menu item in context-menu-mode, and
many other changes; see the NEWS file for
more information. Mickey Petersen, author of Mastering Emacs, also has
a rundown
of some of the quality-of-life features appearing in this release.
Security updates for Monday
Post Syndicated from jzb original https://lwn.net/Articles/1090304/
Security updates have been issued by AlmaLinux (ansible-core, cups-filters, curl, java-1.8.0-openjdk, java-17-openjdk, java-21-openjdk, java-25-openjdk, kbd, kernel, perl-Date-Manip, php:8.2, and php:8.3), Debian (designate, firefox-esr, gst-plugins-bad1.0, libnet-dns-perl, nvidia-graphics-drivers, openjdk-21, openjdk-25, spip, and thunderbird), Fedora (AusweisApp2, bluez, calibre, ceph, chromium, GitPython, kernel, pack, perl-URI, rsync, and tcpreplay), Gentoo (GNU Emacs and needrestart), Oracle (ansible-core, java-1.8.0-openjdk, java-17-openjdk, java-21-openjdk, java-25-openjdk, kbd, kernel, mysql:8.4, perl-Date-Manip, perl:5.32, and sssd), Red Hat (curl, dnsmasq, kbd, kernel, libcap, libreswan, openssh, rsync, samba, unbound, and vim), SUSE (389-ds, apptainer, avahi, bugwarden, chromium, ffmpeg-9-libavcodec-devel, firefox, firefox-esr, gimp, go1.27, helm, ignition, libarchive, libjxl-devel, libssh, multipath-tools, openssl-3, pcp, perl-Net-CIDR-Set, perl-Net-OAuth, postgresql14, postgresql15, python-msgpack, python-pyasn1, python-urllib3, python313, python313-pytest-html, redis, runc, sccache, sssd, util-linux, vim, weechat, and wget), and Ubuntu (linux-fips, linux-gcp-5.15, linux-hwe-7.0, linux-ibm, linux-kvm, linux-lowlatency, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, and linux-nvidia-6.17).
Sean Duffy’s Road Trip #lastweektonight
Post Syndicated from LastWeekTonight original https://www.youtube.com/shorts/UuesMLxBZL4