Post Syndicated from The Atlantic original https://www.youtube.com/shorts/eEk9DNCKePM
Iran’s Internet is partially restored, Cloudflare Radar data shows
Post Syndicated from Lai Yi Ohlsen original https://blog.cloudflare.com/iran-internet-partially-restored-may-2026/
On Tuesday, May 26, Iran’s vice president announced that Internet access had started to be restored in the country after being cut off almost three months ago, following the launch of U.S. and Israeli attacks on February 28.
Cloudflare Radar data confirms increased activity and indicates a partial restoration of the Internet in Iran. In this blog post, we’ll examine a range of data points that provide a lens into this prolonged shutdown – and the signs that Iran’s citizens are increasingly able to connect once again. As the situation continues to unfold, Radar will have the latest data on Iran’s connectivity.
Iranian citizens have experienced two national Internet shutdowns this year. The first began on January 8 around 16:30 UTC (20:00 local time), and we explored the impact seen over the first few days in a blog post. Traffic from Iran remained near zero until January 21, when a small amount of traffic returned, only to disappear a little over 24 hours later. A similar brief restoration also occurred on January 25, before traffic recovered more fully beginning on January 27.
In late February, as military strikes on Iran escalated, a second nationwide Internet shutdown began. That sweeping shutdown has persisted for nearly three months.
The shutdown began on February 28. On that date, Cloudflare Radar observed a sharp drop in traffic from Iran beginning around 10:30 local time (07:00 UTC). Traffic levels fell to well under 1% of previous levels, with only small amounts of Web and DNS traffic leaving the country.
Our observations indicate that more traffic is now finally able to get through. Starting at around 11:00 UTC on May 26, 87 days after the second shutdown started, Cloudflare Radar observed a marked increase in both traffic and DNS queries.
Data for bytes transferred across Cloudflare’s network shows a brief spike at 11:45 UTC, followed by a steady increase starting at 12:00 UTC. This surge in activity is roughly 15x than the levels observed during the prior week. Following expected diurnal patterns, the traffic starts declining around 21:00 UTC, followed by an increase starting at May 27 3:00 UTC (6:30 local time).
An increase in bytes transferred shows that a higher volume of data is successfully moving across Cloudflare’s network, which is a hopeful signal that a partial restoration is underway.
Cloudflare Radar’s regional breakdowns, shown below, indicate that the vast majority of this new traffic is localized to Tehran, with 91.6% of HTTP requests originating from the capital city. While other regions show minor increases, they are not nearly as significant.
Following an initial burst at 11:45 UTC, Internet providers TCI, IranCell, RighTel and MCCI each saw increases in traffic. Cloudflare Radar measures this traffic by ASN, the unique identifier assigned to an individual network or group of networks.
As shown in the graph below, queries to Cloudflare’s public DNS resolver (1.1.1.1) have also spiked. Because an increase in DNS traffic indicates that more users are requesting websites and services, this upward trend serves as a strong indicator that online access is returning.
These increases in traffic validates that a partial restoration of Iran’s Internet has taken place. However, though these increases in DNS queries and traffic are significant, they remain well below what we observed prior to either disruption. As shown in the graph below, at its peak on May 26, traffic had only returned to 40% of the maximum amount of activity observed so far in 2026.
Network activity over the coming days will reveal whether traffic levels will successfully return to their pre-shutdown baselines. It should also be noted, however, that these changes could be temporary; as demonstrated in January, brief periods of recovery can quickly reverse.
In January, we reported a near-complete loss of announced IPv6 address space that began several hours before the January 8 traffic drop. While a partial restoration of the country’s networks appears to be underway, the volume of announced IPv6 address space — and thus IPv6 traffic from Iran — remains effectively zero.
This is noteworthy because in contrast with IPv6, address space announcements for IPv4 have remained fairly consistent and stable throughout both major 2026 shutdowns in Iran. The fact that IPv4 addresses were not removed from global routing tables, combined with the complete loss of actual traffic, suggests that Iran’s shutdown was achieved through other technical means such as application filtering or whitelisting.
IPV6 address space dropped precipitously in January and has not returned to normal levels.
Amid both 2026 shutdowns, IPv4 address space has stayed relatively consistent.
Having spent the majority of 2026 offline, Iranian citizens face severe disruptions to their daily lives, making these early signs of traffic recovery a critical turning point. We will continue to closely monitor Internet connectivity in Iran and share our findings as the situation evolves.
You can explore more data on Internet connectivity in Iran and the rest of the world at Cloudflare Radar. And you can find our latest observations on X, Mastodon, and Bluesky.
Meet Our Newest AWS Heroes – May 2026
Post Syndicated from Taylor Jacobsen original https://aws.amazon.com/blogs/aws/meet-our-newest-aws-heroes-may-2026/
We’re excited to welcome four outstanding community leaders as our newest AWS Heroes. These individuals embody the spirit of collaboration and knowledge sharing that makes the AWS community thrive. From building AI-powered tools that help fellow builders navigate AWS re:Invent, to leading some of the largest AWS communities in Latin America, to sharing deep cloud architecture expertise across blogs and events. Their dedication to lifting others up through education, mentorship, and community organizing inspires builders around the world.
Damiano Giorgi – Pavia, Italy
Artificial Intelligence Hero Damiano Giorgi is a Cloud Solutions Architect focused on AI and its evolution, who transitioned from on-premises (on-prem) systems engineering to AWS and never looked back. He helps organize AWS User Group Pavia and AWS User Group Milan, and shares content on his personal blog, “Bass and Bytes.” Damiano developed the “Unofficial post:Invent Session Suggester,” powered by Amazon Bedrock and Amazon Nova, to help builders find AWS re:Invent sessions matching their interests. He speaks at conferences across Europe including AWS Summit Milan, AWS Community Day Italy, Adria, Greece, and the Netherlands.
Darryl Ruggles – Ottawa, Canada
Serverless Hero Darryl Ruggles is a Cloud Solutions Architect who spent many years as a software developer before focusing on AWS application and AI/ML architectures. He shares knowledge across serverless, containers, AI/ML, and FinOps through his blog, LinkedIn, and published projects. Darryl is an active member of many online AWS communities including “Believe In Serverless” and loves interacting with the community at events both online and in person.
Ricardo Daniel Ceci – Buenos Aires, Argentina
Artificial Intelligence Hero Ricardo Daniel Ceci leads the AWS User Group Buenos Aires, which is the largest AWS community in Argentina with nearly 2,400 members. He is also the principal organizer of the AWS Community Day Argentina and was recognized as the AWS Community Leader of the Year 2025 for LATAM. Ricardo hosts a podcast featuring conversations with cloud experts, AWS Heroes, and developer advocates across Latin America. He has over fifteen years of experience in cloud and web development, and is passionate about empowering Spanish-speaking builders and lowering the barrier to cloud and AI across LATAM.
Matias Kreder – Buenos Aires, Argentina
Artificial Intelligence Hero Matias Kreder is an AWS Certification Subject Matter Expert (SME) who contributed to multiple AI/ML certifications, including the AWS Certified AI Practitioner exam. His journey began with AWS DeepRacer where he qualified three times as a finalist, which sparked his community work organizing racing events and ML talks across the region. As an AWS User Group Leader for Buenos Aires, he organized the AWS Community Day Argentina 2025 and speaks at community events throughout LATAM.
Learn More
Visit the AWS Heroes webpage if you’d like to learn more about the AWS Heroes program, or to connect with a Hero near you.
— Taylor
Антидемократичен чеклист
Post Syndicated from Светла Енчева original https://www.toest.bg/antidemokratichen-cheklist/
Понякога отмяната на демокрацията идва с преврат или с революция. Друг път – (общо взето) безкръвно, но с рязка и категорична безпардонност – нещо, което наблюдаваме например по време на втория президентски мандат на Доналд Тръмп. Може обаче да се осъществи и на малки стъпки, като бавно и почти неусетно сваряване в антидемократичен бульон.
Засега новата власт не дава ясна заявка, че е тръгнала по този път, но досегашните възгледи и действия на Румен Радев, както и на част от най-тесния кръг политици, с които се е обградил, дават основания за притеснения. Особено на фона на притъпените демократични инстинкти в България, на правосъдната система, която често се използва за политически цели, и на антидемократичните тенденции в тълкуването на Конституцията и в законодателството през последното десетилетие.
Ето защо е полезно още отсега да набележим, макар и без претенция за изчерпателност, някои индикатори, които да играят ролята на „червени лампички“, сигнализиращи, че се върви в антидемократична посока.
Лампички, които вече мигат
От изборите на 19 април измина малко повече от месец, но някои признаци, че новата власт се стреми да отдалечи България от демократичния свят, вече са налице.
Опити за неутрализиране на възможната съпротива
„Прогресивна България“ (ПБ) има пълно мнозинство в 52-рото Народно събрание – комфорт, с какъвто никоя политическа сила не е разполагала от четвърт век. Въпреки това ПБ се опитва да обезсили опозицията още в зародиш – чрез Правилника на парламента. Предложенията за промени в него обезсмислят парламентарния контрол върху правителството и силно стесняват полето на действие на опозиционните депутати, както и достъпа им до информация. Така – чрез един подзаконов акт, какъвто е правилникът – не само се подлива вода на опозицията, а и се подменя формата на управление на България, която по конституция е парламентарна република.
Как се дресира опозиция
52-рият парламент бавно се пренарежда така, че на властта да ѝ е по-удобно: по-малко парламентарен контрол, по-трудно създаване на временни комисии, министри, които могат да отсъстват колкото поискат. А опозицията ще кротува ли? От Емилия Милчева.
Емилия Милчева
Разбира се, това се прави уж в името на ефективността. По-малко реплики, дуплики, парламентарен контрол и изобщо възможности за реакция – по-лесно приемане на закони и упражняване на властта. А най-лесно ще е, ако се върне премахнатият в началото на 1990 г. член първи от тоталитарната конституция – „Ръководна сила в обществото и държавата е Българската комунистическа партия“, но мястото на БКП заеме ПБ. Така ще е ясно кой е начело, и опозицията ще стане излишна.
Евроскептицизъм/антиглобализъм
След антидемократичния обрат в САЩ Европа остава основният стожер на либералната демокрация в света. Евроскептицизмът поставя под въпрос именно ценностите, които стоят в основата на европейското единство. А антиглобалистките тенденции вещаят замяна на усилията да се изгради взаимносвързан и мирен свят с борба за надмощие на по-силния. Вещаят също разпад на изградените връзки, последствията от който вече се усещат на всекидневно равнище.
На новата власт това, изглежда, ѝ харесва. Ето две реплики на премиера само от последните дни. По повод на журналистически въпрос защо евроскептикът Иво Христов ще отговаря за организацията на „Евровизия“ в България, Радев заяви:
Европа има нужда от една солидна доза евроскептицизъм, за да оцелее в съвременния изключително сложен свят.
Интересна формулировка – за да оцелее, Европа трябва да постави под въпрос… себе си. Бившият президент използва 24 май, за да противопостави България на света – той определи българската писменост като „щит“ в „глобалния свят на обезличаващи се култури и чезнещи езици“.
Нарочване на врагове
В България изобретяването на врагове и настройването на хората срещу тях е познат метод на предизборна мобилизация. Понякога се използва и за да се наложат определени промени, както беше например с кампанията срещу Истанбулската конвенция. Този случай впрочем е ярка демонстрация колко са нужни „враговете“, ако се цели антидемократичен обрат.
Вече стана дума, че според Радев България се нуждае от „щит“ срещу „глобалния свят“. Това ще рече, че глобалният свят се възприема като враг. Друг враг, посочен от новата власт, са търговските вериги. Върху тях новото правителство стоварва цялата отговорност за инфлацията, която представя с метафората „галопиращи цени“. Няма значение дали върху инфлацията оказват влияние настоящите войни, несигурността, в която управлението на Тръмп хвърля света, климатичните промени, родната корупция и т.н. Има едни лоши търговски вериги, които, разбира се, са с чужда собственост, и те са виновни за всичко.
Оправдаване на антидемократични режими
Докато Румен Радев и приближените му са критични към ЕС, те нямат такова отношение към Путин, Тръмп, Нетаняху и други диктатори. Под булото на „прагматизма“ и „реализма“ Радев защитава правото на по-силния. Или на този, когото смята за по-силен (това по правило не са европейските лидери). А според представители на ПБ, изказващи се в публичното пространство, Русия е на практика непобедима, затова няма смисъл да ѝ се противопоставяме.
Конкретно към Русия отношението на Радев е последователно, като се започне от репликата му, че Крим „в момента е руски, чий да е“. Той многократно възпроизвежда официалния руски наратив, че подкрепата за агресора (Русия) означава защита на мира, а за нападнатата страна (Украйна) – въвличане във война. А неотдавна аргументира отказа на България да се присъедини към създаването на Специален трибунал за Украйна, като заяви, че от него няма смисъл, защото Русия не е победена и Путин не е пленен.
Няма тема – няма проблем
Подходът определени теми, смятани за неудобни или нежелани, да се смитат под килима, също е широко практикуван от властта в България досега и се вписва във вече съществуващите тенденции към антидемократичност. ПБ продължава по този път – например с предложението досегашната парламентарна комисия по демографската политика, децата и семейството да мине под шапката на тази по социалната политика. Какъв е проблемът? Социалната политика се занимава със социално подпомагане. Извън фокуса ѝ са например теми като домашното насилие и детското правосъдие. Планирането на подобна реорганизация е сигнал, че подобни въпроси ще продължават системно да се игнорират.
Лампички в режим на изчакване
Ето и няколко индикатора за антидемократичен обрат, за които да си отваряме очите, макар и те още да не са на дневен ред.
Изолационизъм
Наченки на изолационизъм всъщност вече се наблюдават, но по-скоро като нюанс на евроскептицизма и антиглобализма на новата власт. Да си спомним цитираното по-горе изказване на Радев как кирилицата ни пази от глобалния свят. Но тенденцията към изолационизъм може да се засили – ако се увеличат призивите за „суверенитет“, ако се възродят призивите за „национална доктрина“, ако се настоява, че България на всяка цена трябва да пази неутралитет. И ако ескалират конфликти с други държави – например с Македония, но не само, ако се насажда враждебно отношение към ЕС и другите международни съюзи, от които България е част. Проблемът със „суверенитета“ и „неутралитета“ е, че чрез подобни мантри България просто бива тласкана към друг господар.
Антидемократично законодателство
С изключение на Правилника на НС, засега новата власт не дава заявка, че ще приема антидемократични закони. До момента успехите в това отношение бяха по-скоро спорадични – забраната на „ЛГБТ пропагандата“ в училище, отричането на еднополовите връзки със закон, публичният регистър на педофилите и още няколко пробива. Приемането на подобни закони обаче може да стане системно и да обхване целия социален живот – забрана на „ЛГБТ пропагандата“ на публични места, забрана на абортите, ограничаване на правото на протест, спънки пред политическия плурализъм и пр.
Кого не пази Законът за защита от домашно насилие?
Една трета от интервюираните в изследване на домашното насилие сред еднополови двойки са преживели насилие от партньор, а две трети – от родител. Въпреки това такова насилие според закона не съществува. Теодора Станимирова търси отговори защо е така.
Теодора Станимирова
Религиозен фундаментализъм
Флиртът на държавата с Българската православна църква не е от вчера. Но той може да се превърне, образно казано, в брак. Най-силната форма на съюз между БПЦ и държавата би била промяна на ролята на Църквата в Конституцията, според която все още религиозните институции са отделени от държавата, а православието е не официална, а просто традиционна религия. Но и вкарването на религията в училище, както и преследването на критици на Църквата може да изиграят сериозна антидемократична роля.
Задушаване на гражданския сектор
Разправата с гражданския сектор е възможна както с антидемократично законодателство – например с приемането на закон, подобен на руския за „чуждестранните агенти“, така и по други начини. Например чрез демонизиране на НПО-тата и „лов на вещици“, чрез кампании като тези против Закона за социалните услуги и Стратегията за детето. И досега е имало подобни опити, но индикатор за преход към антидемократичност би била систематичността на усилията.
Налагане на цензура
И тук в българския контекст става дума по-скоро за засилване на нещо съществуващо. Но ако цензурата приеме законова форма, ако преследването на журналисти и други критични гласове стане правило, а не изключение, ако засягането на определени теми стане забранено или практически невъзможно, ако правото на протест се ограничи, значи си е отишла една от най-важните характеристики на демокрацията – правото на изразяване.
Толерантност към институционалното насилие
Засега властта не дава знак, че може да постъпи по такъв начин, но пък все още няма протести срещу нея. Ако в някакъв момент обаче тя започне да бие наред, а насилието се оправдава, вместо съществуването му да се отрича, или то дори се узакони под някаква форма – това е доста сигурен знак, че държавата не се и опитва да изглежда демократична.
Промяна на формата на управление
Антидемократичният обрат може практически да се официализира чрез изменения на Основния закон, посредством които цялата власт се концентрира в управляващите. Или поне смяната ѝ да стане много трудна. Формата на управление може да се промени и по по-деликатни начини – например чрез Изборния кодекс и различни закони.
Тонът на промяната
Румен Радев идва на власт след дълго управление, макар и с известни паузи, на Бойко Борисов и партията му ГЕРБ – в разнообразни коалиционни варианти. Не може да се каже, че Борисов е радетел за либерална демокрация. Като човек, идващ от силовите структури, той е почитател на твърдата ръка, както и на онези, които управляват по този начин. Борисов обаче се отличава от Радев по искреното си желание да бъде харесван и обичан – от народа, от ЕС, от Тръмп, от папите, изобщо – от всички. Затова понякога отстъпваше пред протести, не правеше резки антиевропейски движения, опитваше се на всеки да угоди, доколкото е възможно.
За Радев популярността обаче като че не е цел, а по-скоро властови ресурс.
Той не създава впечатление на човек, който ще се трогне, ако загуби симпатиите на избирателите си. Поведението на ПБ като цяло внушава: „Ние държим властта, вие ще слушате, ще изпълнявате и няма да ни се пречкате.“ А това е качествена промяна на тона спрямо ерата на ГЕРБ. Освен това, макар и поне засега Радев да избягва пряка конфронтация с ЕС, това не означава, че си поставя за цел в ЕС да го харесват.
Тази разлика с доскорошния модел, колкото и бутафорен и корумпиран да беше той, може да се окаже ключът за кутията на антидемократичната Пандора. Разбира се, антидемократичен обрат може и да не настъпи, а Радев да продължи „прагматично“ и „реалистично“ да се опитва да балансира между силните на деня, които и да са те. Но колкото по-подготвено е едно общество и колкото по-ясно разпознава червените лампички, толкова по-способно е да противостои на отмяната на демокрацията.
Dr. Deepika Chopra | The Power of Real Optimism | Talks at Google
Post Syndicated from Talks at Google original https://www.youtube.com/watch?v=cgPAAt9Nd7o
[$] MOT: a tool to fight openwashing in AI
Post Syndicated from jzb original https://lwn.net/Articles/1073420/
Many large language models (LLMs) are described as open source, but
if one looks a bit deeper it turns out that is not actually so; the
model may be free to download, it may be “open weight“, but it
does not fit the Open Source
Initiative (OSI) Open Source
Definition (OSD). Assessing the actual openness of models is not
easy, as Arnaud Le Hors explained in his talk about the Model Openness Tool (MOT) at Open
Source Summit North America 2026. The tool is designed to help
users of LLMs understand to what degree a model is (or is not) open,
and to combat the openwashing
that is prevalent with LLMs.
Migrating your Java applications to AWS Graviton using AWS Transform custom
Post Syndicated from Hahnara Hyun original https://aws.amazon.com/blogs/compute/migrating-your-java-applications-to-aws-graviton-using-aws-transform-custom/
For Java applications, modern JVMs like Amazon Corretto and OpenJDK are highly optimized for Arm64 and modern applications that are pure Java often require zero changes to run on Graviton. In many cases, applications aren’t fully modernized or purely Java and have a range of dependencies. When you’re responsible for migrating workloads, it’s helpful to use a systematic approach that surfaces issues, proposes solutions, and does the transformation work for you at scale.
That’s why we built the Java x86 to Graviton Migration transformation for AWS Transform custom (ATX). This is an AI-powered agent that analyzes your Java codebase, creates a migration plan, and executes the transformation—complete with version-controlled commits at every step. With ATX you can efficiently assess hundreds of Java applications simultaneously and quickly learn which applications require no changes and which ones need modifications. This streamlines the process of estimating the scope of effort, while also having suggested code updates before you even start.
ATX is available as a Kiro power, a VS Code extension, and an Agent Skill if you’d like to use it directly within other AI assistants to reduce context switching. While we will be using ATX to highlight how you can rapidly accelerate a Graviton migration, we have also published an open source Graviton universal skill based on the Agent Skills open standard so that you have the flexibility to use the skill natively within Kiro, Claude Code, Codex, or the platform of your choice.
AWS Graviton processors, based on the Arm64 architecture, can provide up to 40% better price performance over comparable x86-based instances for a wide variety of workloads. Now customers can use AI tools to quickly migrate workloads to Graviton.
The Java x86 to Graviton migration transformation
At a high level, we recommend customers finish any major version Java updates prior to migrating to Graviton and there’s a separate Java Version Upgrade transformation available for this use case. The Java x86 to Graviton Migration transformation requires a minimum of Java 8 and won’t incorporate Java version updates into the code changes.
The Java x86 to Graviton Migration completes multiple steps with work divided across multiple AI agents within the AWS Transform service, covering things like:
- Native library analysis – Identifies Java Native Interface (JNI) dependencies and finds Arm64-compatible alternatives
- Dependency updates – Updates libraries to versions with Arm64 support
- Build configuration – Modifies Maven/Gradle configs for multi-architecture builds
- Architecture-specific code – Refactors hard-coded x86 assumptions
- Unit Test – Verifies compatibility at runtime given unit tests are in the project
- Documentation – Creates migration notes and runbooks for your team
The agent automatically detects your Java version, manages runtime switching as needed during analysis, and handles much of the environment complexity for you such as multi-module project detection or Maven or Gradle auto-detection. Transformation completion times vary, but for many applications you can expect it to take roughly an hour (ATX works well with repos under 300K lines of code).
In this post, we:
- Walk through the requirements for running the Java x86 to Graviton Migration transformation.
- Help you familiarize yourself with ATX using a single Java application with Interactive Mode
- Outline how to assess Graviton compatibility across the Java applications that you want to migrate to Graviton in a single batch and summarize the results with Campaign Mode.
By the end, you should have a good idea of how Java x86 to Graviton Migration transformation functions and have a summary of the expected code changes and dependency updates needed for each of your Java applications, along with version-controlled code updates.
Graviton transformation requirement
The Java x86 to Graviton migration transformation should run on an Arm64 machine.
The agent doesn’t just read your code, it builds, loads native libraries, and validates your application’s runtime behavior on Arm64. If you run the transformation on an x86 machine, the agent can identify compatibility issues but can’t execute build validation or run tests.
If you try to run on x86, you will see the following error message:
⚠ This transformation requires Arm64 architecture.
Detected: x86_64
Please run ATX on an Arm64 environment. See documentation for options.To get started you need a Graviton instance or Apple Mac laptop running Arm64 with the ATX CLI, build tools, and Java JDKs that your project requires. The project source code should also be loaded locally onto the machine running the ATX CLI. Because Apple silicon is Arm64-based, it’s possible to build, load, and verify Arm64 based dependencies for a quick proof-of-concept. However, we recommend running the transformation in an environment that reflects what you plan to deploy in production to surface any potential OS level incompatibilities.
Requirements
| Requirement | Details |
|---|---|
| AWS Transform custom permissions | AWS Identity and Access Management (IAM) policies for the Transform service (see Authentication docs) |
| Arm64 execution environment | Amazon Elastic Compute Cloud (Amazon EC2) Graviton instance or Apple Silicon Mac. Running on x86 limits validation to static analysis only. Phase 3 (build/test) requires Arm64. |
| Node.js 20+ | Required by the AWS Transform CLI. Use the official installer at nodejs.org/en/download. Package managers (dnf, yum) can install an older version. |
| Git | AWS Transform custom uses local Git for version control during the transformation. |
| AWS Transform CLI | Installed using the setup script (see Client Setup for the curl command). |
| Java build tooling | A JDK (Arm64 build, e.g. Amazon Corretto or OpenJDK), Maven and/or Gradle as required by the target project. These are not optional for Java transformations. The agent needs them for dependency analysis, native library scanning, and build validation. |
Running the Graviton transformation with Interactive Mode
With your code on an Arm64 environment and all the prerequisites for the transformation, we can begin the transformation.
Step 1: Navigate to Your Project and create or clone a git repo
cd /home/developer/workspace # Docker
# or
cd ~/workspace # AMI
git initWe recommend not pointing to the main branch of the repository of your application. You can work in a local git environment or create a separate branch. ATX needs the ability to commit changes as it iteratively transforms your code. The final decision on which commits are pushed is up to the developer.
Step 2: Launch ATX Interactive Mode
Enter the following command to launch ATX interactive mode.
atxATX starts in interactive mode:
To view available transformations, in a separate terminal enter:
atx custom def list > custom_list.txtThe AWS Managed transformations will be listed first, followed by User-created transformations that you’ve developed.
Step 3: Select the Graviton transformation
Enter the following into atx cli:
>AWS/early-access-java-x86-to-gravitonATX will prompt you for next steps and your project details:
> Would you like to:+ c to abort or provide feedback)
1. View the entire transformation definition
2. View specific sections of the transformation definition
3. Apply this transformation to your code
4. Modify this transformation
> 3
> What is the file system path to the code repository where you want to apply this transformation?
> .Note that because this is an AWS Managed Transformation, you can’t view the complete transformation definition or modify it. However, you can provide additional context customized to your use case. Keep in mind that the Transformation won’t make permanent changes to your code through the transformation process.
Step 4: Provide additional context
ATX might ask clarifying questions to tailor the transformation:
Step 5: Review the analysis
ATX analyzes your codebase:
Analyzing your codebase...[████████████████████████████████████████] 100%
✓ Parsed 847 Java files
✓ Analyzed 234 dependencies
✓ Identified 12 native library usages
✓ Scanned build configuration
✓ Evaluated test coverage
Analysis complete. Preparing migration plan...Step 6: Review the migration plan
ATX presents a detailed plan before making changes:
═══════════════════════════════════════════════════════════════
MIGRATION PLAN
═══════════════════════════════════════════════════════════════
I've analyzed your project and here's what I'll do:
PHASE 1: Dependency Updates (12 changes)
────────────────────────────────────────
• Update netty-transport-native-epoll 4.1.85 → 4.1.100
Reason: Arm64 support added in 4.1.94
• Update snappy-java 1.1.8.4 → 1.1.10.5
Reason: Current version lacks Arm64 native binaries
• Update lz4-java 1.7.1 → 1.8.0
Reason: Arm64 optimization improvements
• ... (9 more dependency updates)
PHASE 2: Build Configuration (3 changes)
────────────────────────────────────────
• Add Arm64 classifier to native dependency declarations
• Configure multi-architecture Docker build
• Add Graviton-optimized JVM flags to startup scripts
PHASE 3: Code Modifications (2 changes)
────────────────────────────────────────
• Refactor ProcessorArchitecture.java
Current: Hard-coded x86_64 assumption
Change: Add Arm64 detection logic
• Update NativeLibraryLoader.java
Current: Loads x86-specific .so files
Change: Architecture-aware library loading
PHASE 4: Testing & Validation
────────────────────────────────────────
• Run build and tests on Arm64
• Generate migration report and documentation
═══════════════════════════════════════════════════════════════
? How would you like to proceed?
❯ Execute the full plan
Execute phase by phase (review each)
Modify the plan
Ask questions about the plan
Export plan and exit
Step 7: Ask questions, request changes
This is your chance to understand and adjust:
? Ask questions about the plan:
You: Why are you updating netty to 4.1.100?
ATX: Good concern. Netty 4.1.94 was the first version with Arm64
native transport support, which is required for optimal
performance on Graviton.
However, I can adjust this:
Option 1: Use 4.1.94 (minimum Arm64 support)
Option 2: Use 4.1.97 (includes Arm64 bug fixes)
Option 3: Keep 4.1.100 (latest stable with Arm64)
Which would you prefer?
You: Let's go with 4.1.100.
Step 8: Execute the Transformation
When you’re ready:
? How would you like to proceed?
❯ Execute the full plan
Starting transformation...
Phase 1: Dependency Updates
───────────────────────────
[1/12] Updating netty-transport-native-epoll...
✓ Modified pom.xml
✓ Committed: "chore(deps): update netty to 4.1.97 for Arm64 support"
[2/12] Updating snappy-java...
✓ Modified pom.xml
✓ Committed: "chore(deps): update snappy-java to 1.1.10.5 for Arm64"
... (progress continues)
Phase 2: Build Configuration
───────────────────────────
[1/3] Adding Arm64 classifiers...
✓ Modified pom.xml
✓ Committed: "build: add Arm64 native classifiers"
... (progress continues)
Phase 3: Code Modifications
───────────────────────────
[1/2] Refactoring ProcessorArchitecture.java...
✓ Modified src/main/java/com/example/util/ProcessorArchitecture.java
✓ Committed: "feat: add Arm64 architecture detection"
... (progress continues)
Phase 4: Validation
───────────────────
Running build... ✓
Running tests... ✓ (847 passed, 0 failed)
═══════════════════════════════════════════════════════════════
TRANSFORMATION COMPLETE
═══════════════════════════════════════════════════════════════
Summary:
• 17 files modified
• 3 files created
• 14 commits made
• All tests passing
Generated Artifacts:
• GRAVITON_MIGRATION_REPORT.html - Full migration report
• MIGRATION_RUNBOOK.md - Deployment guide for your team
• commit-log.txt - All commits with descriptions
Your code is now Graviton-ready!
After the transformation is complete, you can now performance test and load test on Graviton instances to configure your scaling policies or target thresholds to maximize price/performance on Graviton. For more guidance on performance testing, see the AWS Graviton Technical Guide.
What you get after transformation
Version-controlled history
Every logical change is a separate commit:
$ git log --oneline -10
a3f2b1c (HEAD) docs: add Graviton migration runbook
b82d4e5 test: add Arm64 architecture verification tests
c9a1f3d feat: add Arm64 architecture detection
d4e7c2a build: configure multi-arch Docker build
e5f8d1b build: add Arm64 native classifiers
f6a9e2c chore(deps): update lz4-java to 1.8.0
g7b0f3d chore(deps): update snappy-java to 1.1.10.5
h8c1a4e chore(deps): update netty to 4.1.97 for Arm64 support
...
Each commit is atomic and revertible. If something doesn’t work, you can git revert specific changes.
Migration report
A comprehensive markdown report covering:
- What was changed and why
- Dependencies that were updated
- Code modifications with before and after diffs
- Performance optimization recommendations
Migration runbook
A deployment guide for your team:
- Pre-deployment checklist
- JVM flags designed for Graviton
- Monitoring and rollback procedures
Additional resources on migrating to Graviton on an infrastructure level can be found in the Transition Guide.
Assessing Graviton compatibility for multiple Java applications with Campaign Mode
When you’re ready to start migrating multiple applications, you might want to opt for an automated process that removes the manual effort of going back and forth with the transformation agent after each transformation step with campaign mode. The following command allows ATX CLI to go through a full transformation that you can check back in with after it’s completed. This limits the additional customization and context that you might want to provide the agent.
As mentioned in the first step of running a Graviton Transformation, the environment that the code is transformed in and decision of which commits are pulled into the main repo is up to the developer. Running in campaign mode across several applications doesn’t require accepting and pushing code changes. Therefore, this automated method is most useful when you want to gauge a high-level overview of effort required to migrate across several or even hundreds of applications.
atx custom def exec \
--code-repository-path /path/to/myapp \
--non-interactive \
--trust-all-tools \
--campaign \
--repo-name myapp \
--add-repoThis command can be added into scripts, allowing further automations to be built into continuous integration and delivery (CI/CD) pipelines or scaling transformation jobs across several repos without manually entering prompts as previously shown through interactive mode.
The status of transformations running with campaign mode will be displayed in the AWS Transform Web UI. Setting up the Web UI is a prerequisite to running a transformation in campaign mode.
In addition to this view, if you run the transformation across multiple applications, you can generate a consolidated dashboard with an agent of your choice. Gather the transformation results into a centralized directory, then use the following prompt for example:
Analyze all Java application Graviton transformation summaries in <directory>/<path>/ and create a comprehensive dashboard that includes:
1. Executive summary with key metrics (total apps, compatibility rate, code changes required)
2. Application summary table with columns: Application name, Type, Java version, Dependencies count, Code changes, Compatibility %, Status
3. Code changes analysis - which apps needed changes and why
4. Dependency transformation analysis - common dependencies and their ARM64 status, any upgrades required
5. Native library analysis - which apps use native libs and their compatibility
6. Performance expectations - JWT/crypto improvements, general performance gains, cost-performance ratios
7. JVM optimization patterns - common flags used across applications
8. Build system patterns - Maven/Gradle usage, Docker multi-arch support
9. Test results summary - pass/fail rates, pre-existing vs ARM64 issues
10. Common libraries requiring changes (or note if none)
11. Deployment readiness assessment
12. Risk assessment with mitigation strategies
13. Migration recommendations with phased approach
14. Documentation summary - total docs created and their coverage
Read graviton-validation/00-summary.md from each application subdirectory. Consolidate findings into a single comprehensive markdown dashboard with tables, metrics, and actionable insights.
Focus on: compatibility rates, code change requirements, dependency issues, performance expectations, and migration readiness.
Keep in mind that agents might output outcomes of the migration that aren’t sourced from the transformation summaries. As a result, we recommend that you use the summary as a high-level estimate of the technical effort required for migrating to Graviton.
Conclusion
The AWS Transform custom Java x86 to Graviton Migration transformation alleviates the guesswork in Graviton migrations by using AI for dependency analysis, compatibility assessment, code refactoring, and runtime validation. Development teams can evaluate hundreds of Java applications simultaneously, with each transformation providing atomic version-controlled commits for straightforward rollback and clear change tracking. The tool offers two modes: 1) interactive mode for hands-on, application-by-application migration with developer review at each step, or 2) campaign mode for automated assessment across multiple applications. ATX converts unknown Graviton migration effort into defined requirements through automated compilation and runtime testing. This provides a more efficient way to evaluate workload compatibility and migrate to Graviton.
The Java x86 to Graviton Migration transformation is one of a range of pre-built AWS Managed Transformations but you can also create custom transformations unique to your own use case that can be scaled to drive migrations across your organization. Learn more on the AWS Transform custom website or documentation.
Resources
- ATX Documentation: https://docs.aws.amazon.com/transform/latest/userguide/custom.html
- AWS-Managed Transformation Definitions: https://github.com/aws-samples/aws-transform-custom-samples/tree/main/aws-managed-definitions
- Graviton Getting Started: github.com/aws/aws-graviton-getting-started
- Agent Skills for Graviton migration: https://github.com/aws/aws-graviton-getting-started/tree/main/tools/skills
Has Trump Corrupted the Military? | The David Frum Show
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=f0i7YG5IZ6Y
Andrew Morton’s 2004 OLS keynote
Post Syndicated from corbet original https://lwn.net/Articles/1070746/
I recently presented a brief tribute to Andrew Morton at the 2026 Linux Storage, Filesystem, Memory
Management, and BPF Summit; it included a suggestion that reading (or
re-reading) his 2004 Ottawa Linux Symposium keynote would be instructive.
This talk, given immediately after the Kernel
Summit session that decided to fundamentally change the kernel’s
development model, tells a lot about how the kernel project got to where it
is today. The text of that speech was hosted on Groklaw, and has since
been replaced by crypto spam, which is rather less useful. In the hopes of
preserving this seminal moment, the transcript has been rescued from the
Wayback Machine and is presented here.
FBI’s 2025 Internet Crime Report
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/05/fbis-2025-internet-crime-report.html
The 2025 Internet Crime Report was published a few weeks ago, but I only just saw it.
Lots of interesting statistics.
[$] Further progress toward removing the page map count
Post Syndicated from corbet original https://lwn.net/Articles/1073418/
The mapcount field was created to track the number of mappings
(page-table entries) that refer to the given page. Among other things, a
mapcount of zero means that the page has no references and can be
reclaimed. Maintaining mapcount has become increasingly
challenging and expensive as the memory-management system has grown in
complexity, so Hildenbrand has been looking for ways to get rid of it.
This session was, he said, maybe one of the last times he will have to
bring up this topic.
Security updates for Wednesday
Post Syndicated from jzb original https://lwn.net/Articles/1074840/
Security updates have been issued by AlmaLinux (bind, buildah, compat-libtiff3, compat-openssl11, containernetworking-plugins, crun, delve, dnsmasq, dovecot, edk2, firefox, freeipmi, gdk-pixbuf2, giflib, git-lfs, glib2, go-fdo-client, go-fdo-server, golang, grafana, grafana-pcp, gstreamer1-plugins-bad-free, gstreamer1-plugins-base, gstreamer1-plugins-good, and gstreamer1-plugins-ugly-free, iputils, jq, kernel, krb5, libcap, LibRaw, libsndfile, libsoup, libsoup3, libssh, libtiff, libvirt, linux-sgx, luksmeta, mingw-glib2, NetworkManager, nginx, nginx:1.24, nginx:1.26, openexr, openssh, openssl, opentelemetry-collector, p11-kit, PackageKit, podman, python-jwcrypto, python-markdown, python-tornado, python3.11, python3.12, python3.14, python3.9, qemu-kvm, rsync, skopeo, sudo, systemd, thunderbird, tomcat, unbound, vim, xorg-x11-server, xorg-x11-server-Xwayland, yggdrasil, and yggdrasil-worker-package-manager), Debian (imagemagick, kdenlive, memcached, node-shell-quote, and samba), Fedora (chromium, curl, editorconfig, haproxy, perl-Crypt-DSA, perl-HTTP-Tiny, poppler, rust-afterburn, rust-coreos-installer, rust-eif_build, rust-rpm-sequoia, rust-sequoia-chameleon-gnupg, rust-sequoia-git, rust-sequoia-keystore-server, rust-sequoia-octopus-librnp, rust-sequoia-openpgp, rust-sequoia-sop, rust-sequoia-sq, rust-sequoia-sqv, and uriparser), Oracle (compat-libtiff3, dnsmasq, firefox, freeipmi, kernel, and uek-kernel), Slackware (mozilla), SUSE (assimp, firefox, glibc, gnutls, go1.25-openssl, go1.26-openssl, kernel, kubevirt, leancrypto, libarchive, libsndfile, mcphost, nginx, openssh, podman, python-GitPython, rsync, and samba), and Ubuntu (ayttm, dnsmasq, libssh2, linux-azure, linux-azure, linux-azure-6.17, linux-iot, linux-lowlatency-hwe-5.15, ngtcp2, onnx, opencc, protobuf, python-git, samba, xdg-dbus-proxy, and xmlrpc-c).
Comic for 2026.05.27 – Join Up
Post Syndicated from Explosm.net original https://explosm.net/comics/join-up
New Cyanide and Happiness Comic
Best of The History Guy: Hold My Beer
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=2Lq6JvZchPs
Celebrating young tech creators at Coolest Projects Ireland 2026
Post Syndicated from Rosie Lucas original https://www.raspberrypi.org/blog/celebrating-young-tech-creators-at-coolest-projects-ireland-2026/
In April, young tech creators gathered at Explorium in Dublin for Coolest Projects Ireland 2026, a lively, creative celebration of young makers and their digital projects. This year’s event was held as part of Kinia’s Creative Technology Week, and welcomed over 100 young people, showcasing more than 80 incredible tech projects. Participants included young people from Code Clubs, CoderDojos, and schools across Ireland, as well as young creators taking part individually.
With creations ranging from coding projects to hardware builds to AI systems, the event provided a wonderful opportunity to celebrate the creativity and passion of young tech creators across Ireland. Here are some project highlights from the day.
Jake | Enter the Kindergarten, Scratch
Jake’s project, Enter the Kindergarten, is a Scratch game where the player has to dodge babies and obstacles in a childcare setting. Jake was inspired to create the game after overcoming his own fear of babies. Here is what he shared with us about his project:
“Well, I used to be afraid of babies. So one Saturday morning, me and my dad came up with the idea to make a kindergarten game where you have to get to the end of the kindergarten.”
Aarabhi | Mystical Waterfall, Hardware
To build her hardware project, Mystical Waterfall, Aarabhi used a Raspberry Pi Pico to create a nature scene, featuring running water and LED lights. Aarabhi spoke to us about why she wanted to enter Coolest Projects:
“I watched a Netflix series, The InBESTigators, where children showcase their science projects. After watching it, it was my dream to do the same!”
Arittra | Cara, AI
Arittra’s project, Cara, was chosen as the judges’ favourite in the AI category this year. Cara, which means ‘friend’ in Irish, is a large language model (LLM) that provides information on the Irish legal, housing, and administrative systems, aimed at supporting people who have emigrated to Ireland. Arittra told us more about the challenges he faced whilst building his project:
“One of the key problems with artificial intelligence is that they hallucinate, but I found a countermeasure to it. I trained it on search variety and gave it backup data, so if one part of the server starts hallucinating, another part automatically steps into its place to find maximum accuracy.”
Get involved
Congratulations and thank you to each and every young creator who joined us for Coolest Projects Ireland 2026. Sharing your projects, celebrating your achievements, and inspiring others is what Coolest Projects is all about.
Missed the fun in Dublin, or want to take your projects to a global stage? Take part in the Coolest Projects 2026 online showcase, which is open for entries from young creators anywhere in the world until 27 May. Look out for more in-person Coolest Projects events taking place around the world over the rest of the year, too!
Find out more at coolestprojects.org.
The post Celebrating young tech creators at Coolest Projects Ireland 2026 appeared first on Raspberry Pi Foundation.
Time Machine Conversation
Post Syndicated from xkcd.com original https://xkcd.com/3251/
Home Assistant 2026.6 Release Party
Post Syndicated from Home Assistant original https://www.youtube.com/watch?v=REUxx6fZ97Y
ZimaCube 2 Pro Review An Unexpected 10GbE NAS with Thunderbolt and PCIe Slots
Post Syndicated from Ryan Smith original https://www.servethehome.com/zimacube-2-pro-review-intel-marvell-asmedia/
We review the ZimaCube 2 Pro NAS and see how this box combines an unexpected processor with 10GbE and many 3.5″ and M.2 SSD drive bays
The post ZimaCube 2 Pro Review An Unexpected 10GbE NAS with Thunderbolt and PCIe Slots appeared first on ServeTheHome.
Automate data discovery and centralized management with AWS Glue Data Catalog
Post Syndicated from Ramakrishna Natarajan original https://aws.amazon.com/blogs/big-data/automate-data-discovery-and-centralized-management-with-aws-glue-data-catalog/
Managing sensitive data across sprawling data environments is hard. In this post, we show you how to tackle data discovery, classification, and governance across your databases, data warehouses, and object storage to regain visibility and control over your data landscape. As you build new features, products, and services, your data naturally spreads across multiple systems to meet immediate application and business needs. Different teams spin up their own data stores, and before long, you’re dealing with a complex web of repositories—often with limited visibility into what exists where. This data sprawl becomes most challenging when you must understand and protect your sensitive data. Security teams often struggle to maintain accurate inventories of data categorization and classification. Stakeholders demand comprehensive insights into data classification and processing activities, usually on tight deadlines, and keeping up-to-date data inventories becomes increasingly daunting as your data grows. Without automation, you’re left with manual processes that stretch over weeks, leave room for human error, and create unnecessary business risk.
The need for automation
In a typical manual scenario, creating a new database triggers a chain of time-consuming events. The governance team reviews the new data source, documents its contents, and scans for sensitive data. The security team assesses its configuration and access controls. Days or weeks pass before you fully understand this new asset’s sensitivity.
With automation, creating a new database triggers immediate action. The system detects the new source, catalogs its structure, identifies sensitive data, and updates a central inventory within minutes, supporting proper governance from the moment you create it. Here’s how it works on AWS: When you create an Amazon Simple Storage Service (Amazon S3) bucket for customer orders, you add tags such as Business Function, Data Owner, and Purpose. After the bucket is in use, the system detects it, creates catalog entries, analyzes data patterns, identifies sensitive information, and updates governance records without additional input from you. This gives your organization real-time visibility. Security teams instantly see which repositories contain sensitive information. Governance teams generate up-to-date inventory reports on demand, and data teams immediately understand sensitivity levels, helping them use data responsibly.
Solution overview
The solution uses key AWS services across three layers that work together for comprehensive data visibility and categorization.
Detection Layer: Continuously monitors your AWS environment for new resource creation. When you provision an Amazon S3 bucket, Amazon Relational Database Service (Amazon RDS) database, or Amazon DynamoDB table, Amazon EventBridge rules capture this activity and initiates the governance workflow, so no data source goes unnoticed.
Figure 1 Automated data source discovery (S3 example) workflow using EventBridge Rules and Lambda functions
Processing Layer: After a new source is detected, AWS Glue crawlers analyze its schema while specialized jobs scan for sensitive data patterns. The system also extracts metadata from resource tags, enriching your understanding of each repository’s purpose and ownership.
Figure 2 PII detection and processing workflow using AWS Glue jobs and DynamoDB staging
Management Layer: Maintains a central source of truth about your data assets. AWS Glue Data Catalog provides a unified view across your organization, tracking schema changes and sensitivity levels. This layer also manages the processing workflow state and generates insights for stakeholders.
Figure 3 Tag-based metadata capture and Data Catalog update workflow
Setting up the solution
This solution uses AWS Cloud Development Kit (AWS CDK) for deployment, organized into four stacks that build upon each other.PrerequisitesBefore deployment, verify that you have:
- Access to an AWS account with permissions to create resources in Amazon S3, AWS Lambda, Amazon DynamoDB, AWS Glue, and Amazon EventBridge
- Node.js (version 18 or later) and npm installed
- Access to a terminal to run AWS CDK CLI commands
- Basic familiarity with AWS Console navigation
Step 1: Infrastructure deployment
Deploy four stacks using AWS CDK. Each establishes components for data discovery, cataloging, and PII detection.
- BaseInfraStack: Deploys core infrastructure—Amazon Virtual Private Cloud (Amazon VPC), DynamoDB tables for state management, EventBridge rules for monitoring, and Lambda functions for orchestration.
- GlueAssetsStack: Sets up S3 buckets for AWS Glue ETL scripts and deploys PySpark code for PII detection.
- GlueJobCreationStack: Creates Data Catalog databases and deploys Lambda functions that automate the creation of AWS Glue crawlers and PII detection jobs for newly discovered data sources.
- ReportingStack: Deploys Lambda functions that process PII detection results and tag metadata, updating the Data Catalog accordingly.
To deploy these stacks, you will use the AWS CDK CLI, running the following commands:
Figure 4 CloudFormation console showing successful stack deployment
Step 2: Verify initial setup
In the AWS Management Console, open DynamoDB and find the glueJobTracker table. This table is a critical component of the framework:
- Purpose: Central state management – tracks processing states and configurations for discovered data sources.
- Current state: The table should be empty because no discovery processes have been triggered yet.
- Structure: Tracks states such as Data Catalog entry creation and PII detection job setup for each data source.
By verifying this table, you confirm that the infrastructure is ready to begin tracking new data sources.
Figure 5 Empty DynamoDB glueJobTracker table before execution
Solution in action
This solution runs automatically in production through EventBridge triggers and scheduled AWS Glue crawlers. The following walkthrough executes each step manually so you can observe the workflow.You follow the journey of a newly created S3 bucket containing sensitive data, seeing how the solution discovers, catalog, and processes it through each stage.
Step 3: Create a new S3 bucket
- Open the Amazon S3 console.
- Choose Create bucket.
- Enter a unique name for your bucket (for example, demo-customer-data-20250819).
- In the Tags section, add the following tags:
- Key: gdpr-scan, Value: true
- Key: Business Function, Value: Sales – US
- Key: Data Classification, Value: Confidential
- Keep other settings as default and choose Create bucket.
Figure 6 S3 console showing new bucket creation with tags
Step 4: Upload sample data
- In the S3 console, open your newly created bucket.
- Choose Upload.
- Create a new file named customer_orders.csv with the below content.
- Upload this file to a folder named orders/ in your bucket.
Figure 7: S3 console showing uploaded CSV file in the orders folder
Step 5: Verify automated detection
- Open the DynamoDB console.
- Navigate to the glueJobTracker table.
- Choose the Items tab.
- You should see a new item with an s3_location matching your bucket name.
Figure 8 DynamoDB console showing detected bucket entry in glueJobTracker table
Step 6: Initiate catalog creation
- Open the AWS Lambda console.
- Find the function with a name containing s3GlueCatalogCreator.
- Choose the function name to open its details.
- Choose the Test tab.
- Create a new test event with an empty JSON object {}.
- Choose Test to invoke the function.
- Check the execution result for a successful response.
Figure 9 Lambda console showing successful function execution
Step 7: Run the AWS Glue crawler
- Navigate to the AWS Glue console.
- In the left sidebar, choose Crawlers.
- Find the crawler with a name related to your S3 bucket.
- Select the crawler and choose Run crawler.
- Wait for the crawler to complete (typically 3–5 minutes).
Figure 10 Glue console showing crawler in “Running” state
Step 8: Verify schema discovery
- In the AWS Glue console, go to Databases in the left sidebar.
- Choose the s3_source_db database.
- You should see a new table corresponding to your uploaded data.
- Choose the table name to view its schema.
Figure 11 Glue console showing detected table schema
Step 9: Execute PII detection
- Return to the Lambda console.
- Find and open the function with a name containing s3GlueCreator.
- Use the Test tab to invoke this function with an empty JSON object {}.
- After successful execution, go to the AWS Glue console.
- Navigate to Jobs in the left sidebar.
- Find the newly created PII detection job (it should contain your bucket name).
- Select the job and choose Run job.
- Monitor the job execution in the Glue console.
Figure 12 Glue console showing PII detection job in “Running” state
Step 10: Review PII detection results
- Open the DynamoDB console.
- Navigate to the piiDetectionOutputTable.
- In the Items tab, you should see new entries related to your data.
- These entries will show detected PII types and confidence scores.
Figure 13 DynamoDB console showing PII detection results in piiDetectionOutputTable
Step 11: Verify Data Catalog updates
- Open the AWS Lambda console.
- Find the function with a name containing ReportingStack-PIIReportS3.
- Choose the function name to open its details.
- Choose the Test tab.
- Create a new test event with an empty JSON object {}.
- Choose Test to invoke the function.
- Check the execution result for a successful response.
- Return to the AWS Glue console.
- Go to Databases > s3_source_db > Your table.
- Review the schema. PII columns should now have comments indicating their classification.
Figure 14 Glue console showing updated table schema with PII classifications
Note: While we focus on S3 data sources in this walkthrough, the framework extends to other data stores, offering a unified approach for PII detection and compliance management, so organizations can automatically discover, catalog, and monitor sensitive data elements across your entire data ecosystem. For more information, see aws-samples/automated-datastore-discovery-with-aws-glue.
Best practices and operational excellence
As you implement this solution, consider these key practices for effective results:
- Design your tagging strategy to capture essential business context about each data source. Implement automated tag enforcement through AWS Organizations for consistency across teams.
- Monitor automated workflows regularly and configure retention policies for processed data to manage costs.
- For enhanced security, configure VPC endpoints for services such as Amazon S3, DynamoDB, and other data sources. This keeps traffic within the AWS network, which is especially important when processing sensitive data. Verify that server-side encryption (SSE) is enabled on your data stores. This solution uses AWS Key Management Service (AWS KMS) keys for DynamoDB tables and SSE-S3 for S3 buckets by default, aligning with data-at-rest encryption best practices.
- For teams with multiple AWS accounts, implement cross-account discovery and cataloging to maintain a comprehensive view of your data landscape.
Figure 15 Centralized Storage of Glue PII Detection Results in AWS Data Catalog
Clean up
To avoid ongoing charges and remove the resources created by this solution, follow these steps:
- Empty and delete the S3 buckets created for sample data and AWS Glue assets.
- Delete the AWS CloudFormation stacks in reverse order of creation:
- ReportingStack
- GlueJobCreationStack
- GlueAssetsStack
- BaseInfraStack
- Manually delete any remaining resources:
- DynamoDB tables (glueJobTracker, piiDetectionOutput, tagCaptureTable)
- AWS Glue databases and crawlers
- Lambda functions
- EventBridge rules
- Review your AWS account to ensure that all related resources have been removed.
Remember, deleting these resources will remove all data and configurations associated with this solution. Make sure that you have saved any important information before proceeding with the clean-up.
Conclusion
In this post, you learned how to build an automated data governance framework using AWS Glue Data Catalog. You set up detection, processing, and management layers that automatically discover, catalog, and classify your data sources.This approach improves how you manage sensitive data assets. Teams spend less time on manual discovery and categorization, freeing them to derive value from data. The system gives you current insights into your data landscape and automatically identifies sensitive data, creating a trusted source of truth that helps teams work efficiently while maintaining controls.You can extend this framework with custom sensitivity patterns for your industry. Its modular design supports continuous improvement and integrates with existing workflows. This turns data governance from a manual burden into an efficient process that scales with your organization.
About the authors
Arias: Human proof for FOSS contributions
Post Syndicated from jzb original https://lwn.net/Articles/1074534/
Rodrigo Arias Mallo, maintainer of the Dillo web browser, has written a
blog post
with a proposal on one way to ensure that a contribution is written by
a human and not AI; he suggests asking new contributors to record
their programming session using asciinema.
In the same way that LLMs generate patches, they can also generate
the asciinema recordings themselves. Then, the contributors can lie to
the reviewers pretending to have made the edits. Perhaps surprisingly,
this is not a easy task for LLMs, at least from my observations. The
corpus of recordings of developers making mistakes and thinking the
whole process of editing a file is not as large as the corpus of FOSS
programs and patches in which to train an LLM. During my very simple
tests I haven’t been able to generate an asciinema session that
remotely resembles what I would expect from a human, and even less so
from a human with a nice editor theme and editing an existing Dillo
source file.
The Dillo project is not yet requiring asciinema recordings, but he
said that he would like to test the theory further. LWN covered asciinema in
January 2026.