Post Syndicated from corbet original https://lwn.net/Articles/1074907/
The Linux Foundation will be hosting a
live interview with LWN co-founder Jonathan Corbet. The event will
take place on Tuesday, June 2 at 8:00AM Pacific daylight time (UTC-7).
Registration is open for those who would like to attend.
Post Syndicated from James Hill original https://aws.amazon.com/blogs/big-data/how-buildkite-operates-test-analytics-at-massive-scale-with-amazon-msk-and-amazon-managed-service-for-apache-flink/
When engineering teams at Slack, Reddit, Canva, Airbnb, Shopify, and Uber need to ship code with confidence, they rely on Buildkite. As a CI/CD platform, Buildkite orchestrates complex build, test, and deployment pipelines for some of the most demanding engineering organizations in the world. It handles everything from routine code commits to artificial intelligence (AI) model-training workloads, processing over 50 billion requests per month.
At the heart of Buildkite’s test orchestration portfolio is Test Engine, a specialized analytics product designed to help engineering teams understand and optimize their test suites at scale. Test Engine aggregates results across thousands of builds, flags flaky tests, runs parallel test execution across machine fleets, and delivers interactive analytics on test execution data. It supports arbitrary metadata tagging for dimensions like instance type, architecture, language version, cloud provider, and feature flags.
The challenge? Delivering all of this in real time, across multiple enterprise tenants, at a volume that would stress even the most robust data infrastructure. In this post, we explore how Buildkite uses Amazon Managed Streaming for Apache Kafka (Amazon MSK) and Amazon Managed Service for Apache Flink to power Test Engine’s streaming-first analytics architecture at scale.
Buildkite’s Test Engine must ingest and serve analytics on test telemetry from thousands of distributed pipelines simultaneously, for multiple enterprise customers. The scale is unforgiving: 50 billion test executions per month, 500K events per second at peak ingestion, and webhook payloads reaching 21 MB.
The original Rails and PostgreSQL stack couldn’t sustain this growth. In 2024, the team re-architected around a distributed streaming layer, a stateful stream processor for pre-aggregations, and multiple specialized stores: a key-value store for fast lookups, a relational database for pre-computed aggregates, and an open table format (Iceberg) with a distributed query engine (Trino) for flexible querying.
Yet the core tension remained unsolved. Enterprise customers demanded interactive, arbitrary slicing of billions of records across high-cardinality dimensions, not canned reports. The stream processor couldn’t handle ad hoc aggregations at query time. The key-value store was blind to analytical queries. The distributed query engine offered flexibility but was too slow for interactive use.
The result was a system that was expensive and operationally complex. It included nine relational database clusters, sprawling ETL pipelines, and 24/7 pre-aggregation jobs running regardless of demand. It still couldn’t deliver the one thing customers needed most: fast, flexible, interactive analytics at scale.
The solution Buildkite arrived at centers on Amazon Managed Streaming for Apache Kafka (Amazon MSK) and Amazon Managed Service for Apache Flink as the real-time data streaming and processing layers, decoupling high-throughput ingestion from downstream analytics.
The following diagram shows the end-to-end data flow from CI/CD agents through Amazon MSK and Amazon Managed Service for Apache Flink to the analytics layer.
Amazon MSK sits at the critical junction between data producers (the distributed CI/CD agents and test collectors running across customer infrastructure) and the downstream processing and analytics layers. Amazon Managed Service for Apache Flink then transforms those raw event streams into enriched, queryable data before it reaches the analytics store.
Amazon MSK’s role begins at ingestion. Test collectors embedded in CI/CD pipelines publish test execution events directly to Kafka topics. The existing Amazon MSK cluster handles between 5 MB/sec and 100 MB/sec of inbound data under normal operating conditions. The architecture is designed to absorb the significant variance inherent in CI/CD workloads, where pipeline activity is bursty and correlated with engineering team working hours across global time zones.
When the Buildkite project was initiated, MSK Express Brokers were not yet available, leading the team to adopt MSK Tiered Storage as the primary mechanism for scaling and recovery. With MSK Express Brokers now generally available, the team is evaluating a migration of its most critical log ingestion workload, which sustains up to 1 GB/s at peak ingestion. MSK Express Brokers bring automatic storage scaling with zero storage management overhead, up to 20x faster scaling and 90% faster broker recovery, 3x higher per-broker throughput, 5x more partitions per broker, and built-in Intelligent Rebalancing.
Sitting between Amazon MSK and the analytics layer, Amazon Managed Service for Apache Flink acts as the stateful stream processing engine that transforms raw event streams before they reach downstream systems. Buildkite selected Flink for its exactly-once processing, mature stateful computation model, and deep Kafka integration. Handling sustained peaks of over 25,000 events per second, Amazon Managed Service for Apache Flink eliminates the operational overhead of cluster provisioning, version upgrades, checkpointing, and job recovery. This frees engineering teams to focus on application logic.
Amazon Managed Service for Apache Flink powers key stateful processing tasks, including flaky test detection through time-windowed pattern matching, enriching execution events with pipeline and customer metadata, and routing processed data to downstream systems such as ClickHouse for analytics, PostgreSQL for operational workloads, and Amazon Simple Storage Service (Amazon S3) for long-term archival.
Amazon MSK’s three-replica configuration ensures that no single broker failure can cause data loss or ingestion interruption. Combined with flexible data retention, the architecture provides a meaningful replay window. If a downstream consumer (Amazon Managed Service for Apache Flink, ClickHouse, or another service) experiences an outage, it can resume processing from its last committed offset without data loss.
During the migration to the current architecture, Buildkite employed a dual-write strategy: simultaneously writing to both the existing PostgreSQL pipeline and the new Amazon MSK/ClickHouse path. This approach allowed the team to validate data consistency and gradually shift traffic without risking customer-facing disruption. This pattern speaks to the operational maturity Amazon MSK provides.
The shift to a streaming-first architecture, combined with the downstream simplification of the analytics engine, produced significant operational improvements:
| Metric | Value |
| Monthly test executions (for test engine platform) | 50 billion (4x growth from 3B) |
| Sustained peak ingestion | 500K events/second |
| Total records in analytics store | 200 billion |
| Log ingestion requests | 70,000+ per second |
| Peak webhook throughput | 1.7 GB/second |
| MSK inbound throughput range | 5 MB/sec – 100 MB/sec |
The technical architecture ultimately exists to serve one purpose: helping developers ship better software faster. The streaming-first architecture built on Amazon MSK and Amazon Managed Service for Apache Flink delivers on that promise across four dimensions.
On-demand analytics replaced pre-computed reports. Customers can now interactively slice and dice 70 billion records across arbitrary metadata dimensions. They get answers to queries like “Show me P50 test durations by instance type and architecture for the last 30 days” in seconds, not hours. Real-time log streaming through the “live tail” feature means developers no longer wait for a build to complete before diagnosing failures. At 25,000 events per second, this experience scales across thousands of concurrent enterprise pipelines without degradation.
Smarter test intelligence comes from Amazon Managed Service for Apache Flink’s stateful flaky test detection: when a test begins exhibiting intermittent failure patterns, Amazon Managed Service for Apache Flink identifies it as it happens, not after the fact. This is what separates a proactive analytics platform from a reactive one. It requires publishing data to Kafka, processing with Flink, and letting ClickHouse handle the complex read requests.
Buildkite’s journey from a Rails/Postgres monolith to a streaming-first analytics platform reflects a pattern increasingly common among enterprise SaaS companies: a reliable, high-throughput streaming and processing layer is not an optimization. It is a prerequisite for operating at scale.
Amazon MSK and Amazon Managed Service for Apache Flink form the backbone that helps Buildkite ingest 50 billion test executions per month, serve real-time interactive analytics to enterprise customers, and do so at lower cost than the more complex architecture it replaced. Amazon MSK handles durable, elastic event buffering. Amazon Managed Service for Apache Flink transforms raw streams into enriched, queryable data. Together they absorb the operational complexity that would otherwise consume engineering capacity.
For platform engineers evaluating streaming infrastructure for multi-tenant SaaS workloads, the signal is clear: invest in the streaming backbone early, and let managed services handle the operational complexity.
To learn more about Amazon MSK and Amazon Managed Service for Apache Flink, visit aws.amazon.com/msk and aws.amazon.com/managed-service-apache-flink.
Post Syndicated from Johan Eklund, Matthew Wongkee, Noelia Tardón original https://aws.amazon.com/blogs/big-data/how-zynga-scaled-multi-warehouse-data-governance-with-amazon-redshift-federated-permissions/
Zynga, a global leader in interactive entertainment operates a portfolio of mobile game studios including Socialpoint, the creators of Dragon City and Monster Legends. Zynga’s analytics platform processes telemetry and revenue data across studios using Amazon Redshift as its central data warehouse.
As Zynga expanded its analytics architecture to include individual studios with their own compute environments, the team faced a challenge: how to maintain centralized data governance while granting studios independent query capacity. Their existing approach to permission management introduced lag and required custom infrastructure if scaled to multiple warehouses.
In this post, we walk through how Zynga adopted Amazon Redshift federated permissions and AWS IAM Identity Center to enforce consistent, tiered data access across provisioned and serverless Amazon Redshift environments without building custom synchronization pipelines.
Zynga needed to onboard Socialpoint’s current Amazon Redshift workloads and make Zynga’s central data available to them. Zynga’s existing production cluster would house the Socialpoint raw data, but the compute would come from another warehouse set up as a consumer. At the same time, Zynga’s data access control policies would need to be enforced across all warehouses. Zynga uses a tiered access control policy which would need to be synced across all consumers with no permission lag or manual grant synchronization.
During the migration, Socialpoint’s specific extract, transform, and load (ETL) processes would be included in Zynga’s central ETLs and their data ingestion pipeline would be replaced by Zynga’s latest generation of data ingestion infrastructure. Because the migration process happens in stages, Amazon Redshift sizing would also gradually need to increase.
The team evaluated two alternatives before arriving at a solution:
Zynga implemented a solution using three AWS services working together:
The architecture uses a dual-grant approach where every permission is granted to both an IAM Identity Center group (for users) and a federated IAM role (for service accounts). This gives both authentication paths the same access.
Zynga’s existing Okta directory syncs to IAM Identity Center, which is connected to the Amazon Redshift Serverless workgroup. When a user authenticates, Amazon Redshift automatically creates a user mapped to their email address and assigns them to roles based on their Okta group membership.
For example, an analyst in the Gamma Tier group signs in and is automatically assigned the AWSIDC:role.sso.gamma role in Amazon Redshift. No manual role assignment or synchronization job is required.
Service accounts, used for programmatic access, authenticate differently. Either using their IAM role and calling the get-credentials API, or by using the new federated permissions feature. Each service account assumes a federated IAM role, which creates a corresponding federated user in Amazon Redshift (for example, IAMR:role_iam_gamma).
Figure 1 – Identity layer
To ensure that both users and service accounts can access the same data, every read permission is granted to both the IAM Identity Center group and the federated IAM role in a single statement:
Post Syndicated from The Atlantic original https://www.youtube.com/shorts/eEk9DNCKePM
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.
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.
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.
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.
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.
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.
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-рото Народно събрание – комфорт, с какъвто никоя политическа сила не е разполагала от четвърт век. Въпреки това ПБ се опитва да обезсили опозицията още в зародиш – чрез Правилника на парламента. Предложенията за промени в него обезсмислят парламентарния контрол върху правителството и силно стесняват полето на действие на опозиционните депутати, както и достъпа им до информация. Така – чрез един подзаконов акт, какъвто е правилникът – не само се подлива вода на опозицията, а и се подменя формата на управление на България, която по конституция е парламентарна република.
Емилия Милчева
Разбира се, това се прави уж в името на ефективността. По-малко реплики, дуплики, парламентарен контрол и изобщо възможности за реакция – по-лесно приемане на закони и упражняване на властта. А най-лесно ще е, ако се върне премахнатият в началото на 1990 г. член първи от тоталитарната конституция – „Ръководна сила в обществото и държавата е Българската комунистическа партия“, но мястото на БКП заеме ПБ. Така ще е ясно кой е начело, и опозицията ще стане излишна.
След антидемократичния обрат в САЩ Европа остава основният стожер на либералната демокрация в света. Евроскептицизмът поставя под въпрос именно ценностите, които стоят в основата на европейското единство. А антиглобалистките тенденции вещаят замяна на усилията да се изгради взаимносвързан и мирен свят с борба за надмощие на по-силния. Вещаят също разпад на изградените връзки, последствията от който вече се усещат на всекидневно равнище.
На новата власт това, изглежда, ѝ харесва. Ето две реплики на премиера само от последните дни. По повод на журналистически въпрос защо евроскептикът Иво Христов ще отговаря за организацията на „Евровизия“ в България, Радев заяви:
Европа има нужда от една солидна доза евроскептицизъм, за да оцелее в съвременния изключително сложен свят.
Интересна формулировка – за да оцелее, Европа трябва да постави под въпрос… себе си. Бившият президент използва 24 май, за да противопостави България на света – той определи българската писменост като „щит“ в „глобалния свят на обезличаващи се култури и чезнещи езици“.
В България изобретяването на врагове и настройването на хората срещу тях е познат метод на предизборна мобилизация. Понякога се използва и за да се наложат определени промени, както беше например с кампанията срещу Истанбулската конвенция. Този случай впрочем е ярка демонстрация колко са нужни „враговете“, ако се цели антидемократичен обрат.
Вече стана дума, че според Радев България се нуждае от „щит“ срещу „глобалния свят“. Това ще рече, че глобалният свят се възприема като враг. Друг враг, посочен от новата власт, са търговските вериги. Върху тях новото правителство стоварва цялата отговорност за инфлацията, която представя с метафората „галопиращи цени“. Няма значение дали върху инфлацията оказват влияние настоящите войни, несигурността, в която управлението на Тръмп хвърля света, климатичните промени, родната корупция и т.н. Има едни лоши търговски вериги, които, разбира се, са с чужда собственост, и те са виновни за всичко.
Докато Румен Радев и приближените му са критични към ЕС, те нямат такова отношение към Путин, Тръмп, Нетаняху и други диктатори. Под булото на „прагматизма“ и „реализма“ Радев защитава правото на по-силния. Или на този, когото смята за по-силен (това по правило не са европейските лидери). А според представители на ПБ, изказващи се в публичното пространство, Русия е на практика непобедима, затова няма смисъл да ѝ се противопоставяме.
Конкретно към Русия отношението на Радев е последователно, като се започне от репликата му, че Крим „в момента е руски, чий да е“. Той многократно възпроизвежда официалния руски наратив, че подкрепата за агресора (Русия) означава защита на мира, а за нападнатата страна (Украйна) – въвличане във война. А неотдавна аргументира отказа на България да се присъедини към създаването на Специален трибунал за Украйна, като заяви, че от него няма смисъл, защото Русия не е победена и Путин не е пленен.
Подходът определени теми, смятани за неудобни или нежелани, да се смитат под килима, също е широко практикуван от властта в България досега и се вписва във вече съществуващите тенденции към антидемократичност. ПБ продължава по този път – например с предложението досегашната парламентарна комисия по демографската политика, децата и семейството да мине под шапката на тази по социалната политика. Какъв е проблемът? Социалната политика се занимава със социално подпомагане. Извън фокуса ѝ са например теми като домашното насилие и детското правосъдие. Планирането на подобна реорганизация е сигнал, че подобни въпроси ще продължават системно да се игнорират.
Ето и няколко индикатора за антидемократичен обрат, за които да си отваряме очите, макар и те още да не са на дневен ред.
Наченки на изолационизъм всъщност вече се наблюдават, но по-скоро като нюанс на евроскептицизма и антиглобализма на новата власт. Да си спомним цитираното по-горе изказване на Радев как кирилицата ни пази от глобалния свят. Но тенденцията към изолационизъм може да се засили – ако се увеличат призивите за „суверенитет“, ако се възродят призивите за „национална доктрина“, ако се настоява, че България на всяка цена трябва да пази неутралитет. И ако ескалират конфликти с други държави – например с Македония, но не само, ако се насажда враждебно отношение към ЕС и другите международни съюзи, от които България е част. Проблемът със „суверенитета“ и „неутралитета“ е, че чрез подобни мантри България просто бива тласкана към друг господар.
С изключение на Правилника на НС, засега новата власт не дава заявка, че ще приема антидемократични закони. До момента успехите в това отношение бяха по-скоро спорадични – забраната на „ЛГБТ пропагандата“ в училище, отричането на еднополовите връзки със закон, публичният регистър на педофилите и още няколко пробива. Приемането на подобни закони обаче може да стане системно и да обхване целия социален живот – забрана на „ЛГБТ пропагандата“ на публични места, забрана на абортите, ограничаване на правото на протест, спънки пред политическия плурализъм и пр.
Теодора Станимирова
Флиртът на държавата с Българската православна църква не е от вчера. Но той може да се превърне, образно казано, в брак. Най-силната форма на съюз между БПЦ и държавата би била промяна на ролята на Църквата в Конституцията, според която все още религиозните институции са отделени от държавата, а православието е не официална, а просто традиционна религия. Но и вкарването на религията в училище, както и преследването на критици на Църквата може да изиграят сериозна антидемократична роля.
Разправата с гражданския сектор е възможна както с антидемократично законодателство – например с приемането на закон, подобен на руския за „чуждестранните агенти“, така и по други начини. Например чрез демонизиране на НПО-тата и „лов на вещици“, чрез кампании като тези против Закона за социалните услуги и Стратегията за детето. И досега е имало подобни опити, но индикатор за преход към антидемократичност би била систематичността на усилията.
И тук в българския контекст става дума по-скоро за засилване на нещо съществуващо. Но ако цензурата приеме законова форма, ако преследването на журналисти и други критични гласове стане правило, а не изключение, ако засягането на определени теми стане забранено или практически невъзможно, ако правото на протест се ограничи, значи си е отишла една от най-важните характеристики на демокрацията – правото на изразяване.
Засега властта не дава знак, че може да постъпи по такъв начин, но пък все още няма протести срещу нея. Ако в някакъв момент обаче тя започне да бие наред, а насилието се оправдава, вместо съществуването му да се отрича, или то дори се узакони под някаква форма – това е доста сигурен знак, че държавата не се и опитва да изглежда демократична.
Антидемократичният обрат може практически да се официализира чрез изменения на Основния закон, посредством които цялата власт се концентрира в управляващите. Или поне смяната ѝ да стане много трудна. Формата на управление може да се промени и по по-деликатни начини – например чрез Изборния кодекс и различни закони.
Румен Радев идва на власт след дълго управление, макар и с известни паузи, на Бойко Борисов и партията му ГЕРБ – в разнообразни коалиционни варианти. Не може да се каже, че Борисов е радетел за либерална демокрация. Като човек, идващ от силовите структури, той е почитател на твърдата ръка, както и на онези, които управляват по този начин. Борисов обаче се отличава от Радев по искреното си желание да бъде харесван и обичан – от народа, от ЕС, от Тръмп, от папите, изобщо – от всички. Затова понякога отстъпваше пред протести, не правеше резки антиевропейски движения, опитваше се на всеки да угоди, доколкото е възможно.
Той не създава впечатление на човек, който ще се трогне, ако загуби симпатиите на избирателите си. Поведението на ПБ като цяло внушава: „Ние държим властта, вие ще слушате, ще изпълнявате и няма да ни се пречкате.“ А това е качествена промяна на тона спрямо ерата на ГЕРБ. Освен това, макар и поне засега Радев да избягва пряка конфронтация с ЕС, това не означава, че си поставя за цел в ЕС да го харесват.
Тази разлика с доскорошния модел, колкото и бутафорен и корумпиран да беше той, може да се окаже ключът за кутията на антидемократичната Пандора. Разбира се, антидемократичен обрат може и да не настъпи, а Радев да продължи „прагматично“ и „реалистично“ да се опитва да балансира между силните на деня, които и да са те. Но колкото по-подготвено е едно общество и колкото по-ясно разпознава червените лампички, толкова по-способно е да противостои на отмяната на демокрацията.
Post Syndicated from Talks at Google original https://www.youtube.com/watch?v=cgPAAt9Nd7o
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.
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.
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:
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:
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.
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. |
With your code on an Arm64 environment and all the prerequisites for the transformation, we can begin the transformation.
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.
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.
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.
ATX might ask clarifying questions to tailor the transformation:
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...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
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.
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.
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.
A comprehensive markdown report covering:
A deployment guide for your team:
Additional resources on migrating to Graviton on an infrastructure level can be found in the Transition Guide.
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.
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.
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=f0i7YG5IZ6Y
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.
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.
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.
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).
Post Syndicated from Explosm.net original https://explosm.net/comics/join-up
New Cyanide and Happiness Comic
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=2Lq6JvZchPs
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’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.”
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’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.”
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.
Post Syndicated from xkcd.com original https://xkcd.com/3251/
Post Syndicated from Home Assistant original https://www.youtube.com/watch?v=REUxx6fZ97Y