Preview Bucket Access Logs for Greater Visibility and Control

Post Syndicated from Bala Krishna Gangisetty original https://www.backblaze.com/blog/preview-bucket-access-logs-for-greater-visibility-and-control/

A decorative image showing the Backblaze logo on a cloud over a pattern representing a network.

You’ve always had insight into the buckets in your B2 Cloud Storage account, and now you can go deeper. With Bucket Access Logs, it’s possible to see a detailed record of operations performed against objects inside of a bucket. Whether you’re managing a growing archive, running audits, or troubleshooting automated workflows, these logs can provide the transparency needed to stay in control.

Starting today, Bucket Access Logs are available in limited preview. If you are interested, reach out to Support for more information.

What you can track with Bucket Access Logs

Once enabled, Bucket Access Logs record a range of operations performed on the objects in a bucket. That includes:

Every log entry includes details like the timestamp, operation type, and the object involved. If you’ve ever wished you had a record of what happened—and when—it’s now within reach.

Easy to configure: User interface (UI) and APIs

Bucket Access Logs are fully S3 compatible. You can configure logging through the Backblaze B2 web UI or programmatically via the S3 API using standard tools or SDKs. This makes it easy to integrate logging into your existing workflows and infrastructure without needing to learn anything new.

Because B2’s Bucket Access Logs are S3 compatible, your existing S3 log management tools will work seamlessly with B2 Logs. This allows you to use the same tools and processes you already have in place for monitoring, analyzing, and storing logs.

Important: Don’t enable access logging on the same bucket that you use as the log destination. This can result in an endless loop of logs generating more logs.

Once configured, you’ll begin to see new log objects arrive in the destination bucket as activity occurs in the source bucket. From there, you can analyze, archive, or pipe the data into other systems for further processing.

Preview: Configuring Bucket Access Logs in the UI

Here’s a preview of how you will be able to configure Bucket Access Logs via the user interface:

A screenshot of how to navigate to the Backblaze Bucket Access Logs feature.
A screenshot of how to configure Backblaze Bucket Access Logs.

This simple, intuitive interface lets you easily configure your logging settings, choose a destination bucket, and start tracking operations on your objects. Once enabled, you’ll have access to the logs directly in the destination bucket, with the details you need to monitor and analyze your data access patterns.

Use cases for Bucket Access Logs

Bucket Access Logs unlock a broad set of security, privacy, and operational workflows. Here are just a few examples of how you can use them:

1. Security and privacy monitoring

Organizations storing sensitive data—like security footage, personal files, or customer assets—often need detailed audit trails for compliance and accountability.

  • Log object access activity through pre-signed URLs and correlate access with specific users.
  • Track access times, IP addresses, and user actions to meet reporting requirements or identify suspicious behavior.
  • Detect potentially compromised application keys by analyzing activity patterns without disrupting all keys in use.
  • Enforce privacy policies by monitoring the source IP addresses of requests and verifying they match allowed sources.
  • Analyze latency and bandwidth metrics across object access requests to optimize data delivery.

2. Infrastructure and traffic control

When storage access is tightly integrated with content delivery networks (CDNs) or other network layers, it’s important to confirm that traffic flows through the correct paths.

  • Validate that object uploads originate only from approved CDNs or endpoints, not directly from unauthorized sources.
  • Detect misconfigurations early by comparing traffic origins to expected network patterns.

3. Usage tracking and audit trails

Understanding how data moves through your system can help with cost management, client reporting, and internal transparency.

  • Monitor object uploads and deletions that impact billing to better forecast and control storage costs.
  • Maintain a historical record of object activity for clients or partners who require verifiable data access trails.
  • Troubleshoot issues in automated workflows by reviewing the sequence of operations on specific objects.

Across these use cases, a common thread emerges: the need to know when, what, and where for activity happening inside your buckets.

Get started with Bucket Access Logs

Bucket Access Logs are available today in preview. To try it out, contact Support for more information.

For more detailed instructions and guidance on configuring and using Bucket Access Logs, check out the official Bucket Access Logs documentation.

Whether you’re building for compliance, monitoring security, or just want better observability into your workflows, Bucket Access Logs give you the visibility you need—right where your data lives.

The post Preview Bucket Access Logs for Greater Visibility and Control appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

[$] Some __nonstring__ turbulence

Post Syndicated from corbet original https://lwn.net/Articles/1018486/

New compiler releases often bring with them new warnings; those warnings
are usually welcome, since they help developers find problems before they
turn into nasty bugs. Adapting to new warnings can also create disruption
in the development process, though, especially when an important developer
upgrades to a new compiler at an unfortunate time. This is just the
scenario that played out with the 6.15-rc3
kernel release
and the implementation of
-Wunterminated-string-initialization in GCC 15.

[$] Freezing filesystems for suspend

Post Syndicated from jake original https://lwn.net/Articles/1018341/

Sometimes worms have a tendency to multiply once their can is opened.
James Bottomley recently encountered that situation; he led a session in
the filesystem track at the 2025 Linux Storage, Filesystem, Memory
Management, and BPF Summit (LSFMM+BPF) to discuss filesystem behavior with
respect to suspending and resuming the system. As he noted in his topic
proposal
, he came at the problem because he needed a way to
resynchronize the contents of efivarfs
after a system resume and thought there should be an API available to use.
But, as the resulting thread shows, the filesystem freeze and thaw code had
never been used by the system-wide suspend and resume code. Due to a
scheduling mixup, though, several of us missed Bottomley’s session,
including Luis Chamberlain who has been working on hooking those two pieces
up; what follows is largely from a second session that Chamberlain led,
with some background information from the topic-proposal discussion and an
email exchange with Bottomley.

Security updates for Thursday

Post Syndicated from jake original https://lwn.net/Articles/1018717/

Security updates have been issued by Debian (haproxy and openrazer), Fedora (c-ares and mingw-poppler), Red Hat (thunderbird), SUSE (epiphany, ffmpeg-6, gopass, and libsoup-3_0-0), and Ubuntu (erlang, haproxy, libapache2-mod-auth-openidc, libarchive, linux, linux-aws, linux-azure, linux-azure-5.15, linux-azure-fde, linux-azure-fde-5.15, linux-gcp, linux-gke, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-intel-iotg, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-nvidia-tegra, linux-nvidia-tegra-igx, linux-oracle, linux-raspi, linux, linux-aws, linux-azure, linux-azure-6.8, linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, linux-oem-6.8, linux-oracle, linux-oracle-6.8, linux-aws-6.8, linux-aws-fips, linux-fips, linux-gcp-fips, linux-azure-fips, linux-gcp, linux-gke, linux-gkeop, linux-gcp-6.8, linux-ibm-5.15, linux-intel-iot-realtime, linux-realtime, linux-intel-iotg-5.15, linux-realtime, perl, and yelp, yelp-xsl).

THE NEW Rapid7 MDR for Enterprise: Tailored Detection and Response for Complex Environments

Post Syndicated from C.J. Spallitta original https://blog.rapid7.com/2025/04/24/the-new-rapid7-mdr-for-enterprise-tailored-detection-and-response-for-complex-environments/

THE NEW Rapid7 MDR for Enterprise: Tailored Detection and Response for Complex Environments

Complex ecosystems. Custom applications. Specialized log sources. Distributed operations. Enterprise security leaders aren’t just defending against threats—they’re navigating a fragmented environment where visibility, coverage, and coordination are constant challenges.

Our MDR service provides powerful protection for thousands of organizations worldwide today. But as enterprise environments grow more distributed and unique, many security teams find themselves needing something more flexible—something that can be tightly aligned to their internal workflows, toolsets, and detection strategies.

That’s why we’re excited to introduce Rapid7 MDR for Enterprise—a fully managed, customized detection and response service designed to meet the complexity of the modern enterprise head-on.

Tailored Coverage to Extend Your Existing Security Program

MDR for Enterprise builds on the proven foundation of Rapid7’s MDR, layering on advanced customization and collaboration to meet highly specific enterprise needs:

  • Custom Event Source Integration: Extend visibility to proprietary, vertical-specific, or legacy technologies that standard integrations don’t cover.
  • Bring Your Own Logs: Monitor your own log sources, working with our o Detection Engineering team to optimize signal fidelity and context.
  • Tailored Detection Engineering: Rapid7 Detection Engineers design and tune detection rules that reflect your actual environment—not a theoretical model​.

Designed to Meet You Where You Are

Enterprise environments rarely look the same. Some rely on legacy infrastructure alongside modern cloud stacks. Others have industry-specific applications or internally developed tools that aren’t covered by typical MDR integrations. And many are already investing in their own detections or bringing in telemetry from a wide range of tools.

MDR for Enterprise is built to adapt to this complexity. It allows customers to bring their own log sources and extend monitoring into non-standard systems. Whether it’s a homegrown application or a niche vertical-specific tool, we’ll build the integration and align detection logic to your context—not the other way around.

More Than a Vendor. A True Operational Partner.

One of the biggest differences with MDR for Enterprise is how we collaborate. This isn’t a black-box service or a reactive alert-forwarding engine. We work alongside your internal team to co-develop incident response protocols and continuous tuning cycles.

We’re not just another SOC you plug into—we’re a strategic extension of your security program. Through tightly integrated processes and regular reviews, your team and ours operate as one. That operational interlock ensures context is never lost, alerts are always actionable, and response is always aligned to your priorities.

Elevating the Tools You Already Trust

Enterprise security teams have made serious investments—in technology, in detection engineering, in internal processes. We’re not here to disrupt that. MDR for Enterprise is designed to enhance your existing ecosystem, not replace it.

We will partner with you to develop a custom monitoring solution for your business critical applications to meet your specific security uses cases  —from triage, to investigation, and response through our global SOC. This approach improves your ROI and creates a seamless bridge between your team’s internal expertise and our operational scale.

Enterprise-Ready, Without the Tradeoffs

With MDR for Enterprise, you don’t have to choose between visibility and control, speed and customization, or scale and support. You get a partner that understands enterprise complexity—and builds a service around it.

Ready to explore what tailored MDR could look like for your team? Reach out to the team to learn more.

Научни новини: Вълнести мишки, свирепи вълци и нови цветове

Post Syndicated from Михаил Ангелов original https://www.toest.bg/nauchni-novini-vulnesti-mishki-svirepi-vultsi-i-novi-tsvetove/

Завръщане на изчезнали видове или маркетингова кампания?

Научни новини: Вълнести мишки, свирепи вълци и нови цветове

Вълнестият мамут е един от най-добре проучените изчезнали видове поради множеството открити негови останки. Популациите на впечатляващото животно започват да намаляват преди около 10 000 години с масовото измиране на мегафауната в края на плеистоцена. Смята се, че последната малка популация е живяла на полярния остров Врангел преди около 4000 години – тогава пирамидите в Гиза вече са били построени. Според някои хипотези за изчезването му принос има и засиленият лов от човека.

За разлика от по-древните животни, които познаваме само от фосилизираните им останки, за анатомията на вълнестия мамут се знае много – някои образци са толкова добре запазени в пермафроста, че дори в един от тях е открита течна кръв. Наличието на дълбоко замразени тъкани не само улеснява сглобяването на генома им, но дори дава възможност за разглеждане на триизмерната му структура.

Още първите разработки, свързани с генома на мамута, пораждат интерес у генетика Джордж Чърч и той започва да работи върху възстановяването на вида. Така през 2015 г. екипът му успява да направи промени в 15 гена на най-близкия жив родственик на изчезналия вид – азиатския слон. В следващите няколко години броят им се увеличава и според новини от 2017 г. в редактираните клетки има 45 гена, които са със секвенцията на вълнестия мамут. За съжаление, тези експерименти не са публикувани в научен журнал и точната методология и получените резултати не са достъпни.

Стъпвайки на тези разработки, през 2021 г. Чърч основа компанията Colossal Biosciences с основен фокус завръщането на изчезнали видове. Един от тях е тасманийският вълк, който е унищожен от хората, а последният екземпляр загива в зоологическа градина през 1936 г. Миналата година от Colossal съобщиха, че геномът му вече е секвениран почти напълно и започва активна работа по възстановяването на животното.

Но тази година в рамките на два месеца компанията попадна два пъти в новинарските емисии, предизвиквайки доста вълнение с живи образци на редактирани животни. 

Миналия месец бяха публикувани снимки на вълнеста мишка (наречена така от компанията), обявена като първа стъпка към връщането на вълнестия мамут. Малките гризачи имат впечатляващ външен вид със своята дълга златиста козина. Уви, под нея се крият генетични редакции, които само са вдъхновени от изчезналия гигант.

За да променят козината на мишките, учените използват дълбоките познания за генома им и правят редакции в гени, които са отговорни за белези, свързани с окосмяването. Например Fgf5 контролира дължината на космите, Fam83g и Tgfa отговарят за къдравия им вид, а Mc1r регулира синтеза на пигменти. Постижението определено заслужава внимание от технологична гледна точка, защото показва силата на CRISPR за извършване на няколко редакции едновременно – в симпатичните мишки са манипулирани седем гена. Но редакциите са от „по-лесните“ – т.нар. knock-out, които причиняват мутации, нарушаващи функцията на даден ген. Така ефективно мишките са променени, за да изглеждат като вълнестия мамут, но в тях няма ДНК от него.

За създаване на хибрида между мамут и слон пред учените стои много по-трудна задача. Те трябва да променят множество гени, като редакциите няма да са свързани с изключването им, а с промени на техните секвенции, които в някои случаи може да са осезаеми и екстензивни. Част от тази работа вече е свършена, но не е ясно колко допълнителни намеси в генома ще са нужни. Въпреки че наличните инструменти за модификация на генома се развиват бързо, възможността за извършване на няколко намеси наведнъж все още е ограничена. Освен това тяхната ефективност не е толкова висока – налага се времеемко преглеждане на редактираните клетки, за да се установи кои носят желаните редакции.

Към момента плановете са първите мамутчета да бъдат родени през 2028 г., което е доста амбициозна цел – само износването им от майките ще отнеме 22 месеца, което означава, че учените разполагат с около една година да направят нужните редакции и да подготвят ембриони за имплантиране.

Докато вълненията около мишките все още не бяха утихнали, в мащабна пиар кампания фирмата съобщи за „завръщането на свирепия вълк“ – вид, също изчезнал в края на плеистоцена. Най-близкият му родственик е сивият вълк, но от скелетите им става ясно, че той е бил по-голям и е имал значително по-силна захапка – очаквано за хищник, ловуващ по-дребни представители на мегафауната.

Достъпната информация за генома им е оскъдна – през 2021 г. международен екип публикува статия за секвенирането на пет проби, но за съжаление, с много ниско покритие. Colossal изтъкват това в специална секция на сайта си, където сравняват тези резултати със своите – шестима учени успяват да секвенират почти пълен геном от две проби. Според компанията, базирайки се на тези два генома, за „превръщане“ на сивия вълк в свиреп са нужни редакции само на 20 локуса (участъка) в 14 гена. Това повдига известни съмнения, понеже според публикуваното на сайта им отделянето на двата вида е настъпило преди около 3 млн. години – време, за което в геномите се натрупват много разлики. Уви, анализът на компанията не е публичен и затова към момента твърдението не може да се провери.

Но голямата гордост на Colossal не са тези анализи, а три вълчета – мъжките Ромул и Рем и женската Калиси, която е с три месеца по-малка от тях. Компанията не споделя какви редакции са направени в тях, и дава оскъдна информация на сайта си, както и на журналисти, но видимите разлики с обикновените вълци са основно по-големият им размер и бялата козина.

Подобно на мишките, тези два белега са намеси в генома на сивия вълк, а не привнесени от ДНК на изчезналия вид. Генът за размер, който са манипулирали учените, се нарича LCORL. Интересното е, че неговата активност намалява размера и при други видове (хора, прасета, кучета и др.). Намаляването на действието му чрез нарушаване на един от функционалните участъци на протеина води до по-голям размер на редактираните вълци. Много е вероятно промяната в цвета на козината също да се дължи на нарушаване на синтеза на меланини. Както и при вълнестите мишки, в генома на трите животни няма древна ДНК – намесите са направени по начин, който ги доближава до нея.

Всичко това не значи, че редактираните животни не са впечатляващо постижение. Учените от компанията имат много добри резултати в редица проекти и в разнообразни процедури. Дори само секвенирането на генома на свирепия вълк може да бъде ценен принос за науката, ако бъде споделен. Разработените протоколи за множествени редакции също изглеждат изключително оптимизирани.

Но от наличната информация скептицизмът към работата на компанията донякъде е оправдан – немалка част от разработките им не се публикуват и не са достъпни за рецензия. Наред с това използваният от тях език е прекалено оптимистичен и звучи по-скоро като продукт на маркетинг – получените животни няма как да се определят като „истински“ вълнести мамути или свирепи вълци. В най-добрия случай те ще могат да бъдат разглеждани като хибриди, а за по-критичния научен поглед ще са по-скоро слонове или вълци, в които са направени генетични редакции или са вмъкнати участъци от ДНК на друг вид – трансгенни животни. Нещо, което се прави и в момента за фундаментални изследвания.

Освен това се създава и погрешното впечатление, че тези изчезнали видове могат да бъдат възстановени напълно, което е опасно от консервационна гледна точка. Не на последно място, има и етични съображения. Слоновете са изключително интелигентни животни с много силна стадна динамика, поради което най-вероятно единични екземпляри няма да се чувстват добре сами. Като се вземат предвид дългата бременност при слоновете и неясната успеваемост на процедурата, създаването на достатъчно големи стада ще отнеме значително време и ресурси.

От друга страна, компанията очевидно грабва въображението на хората с новините за рунтави гризачи и свирепи вълци, помагайки за приемането на генните манипулации като нещо, което не е страшно и може да бъде полезно дори и от екологична гледна точка. Също така част от разработките все пак се публикуват, което може да донесе ползи в областта на генетичните редакции. Някои от техниките имат потенциал за приложение в медицината за генни терапии или за по-сложни редакции с цел фундаментални изследвания.

Времето ще покаже дали Colossal ще успеят да постигнат целта си и как точно ще бъдат приети новите животни от научните среди, които засега са по-скоро скептични, и на фона на вълнението на широката публика. 

Невиждан цвят

Възприемането на различни цветове е донякъде субективно. Но в основата си то се базира на система, която е добре проучена на физиологично ниво. В очите ни има два вида клетки, отговарящи за създаване на картината, която виждаме – пръчици, които не различават цвета, а само силата на светлината, и конуси, които правят разлика между отделните цветове.

Пръчиците са много по-чувствителни и многобройни (около десет пъти повече) и отговарят за зрението ни при оскъдна светлина. Конусите се делят на три разновидности, в зависимост от дължината на вълната, която улавят най-добре – S, M, L (short, medium, long), съответно за синя, зелена и червена светлина (трицветно зрение). Всеки от пигментите в тях има определен пик, при който се активират най-интензивно, но те могат да улавят с по-нисък интензитет и светлина с близка дължина на вълната. Сигналите от активацията на тези клетки се предават към мозъка, той ги интерпретира и създава картината, която виждаме. Това ни позволява да различаваме около милион нюанса на цветовете.

Но поради това припокриване между сигналите, особено на клетките за зелено и червено (M и L), на практика е невъзможно да видим зелено, без към него мозъкът ни да „добави“ и известно количество жълто. Поради това на практика е невъзможно да видим „истинско зелено“, тъй като няма естествен начин да се стимулират само един тип клетки. Това се променя с нова методология, наречена от изобретателите си Oz, с помощта на която петима доброволци са видели невиждан до момента нюанс на зеленото.

Процедурата е изключително сложна и високотехнологична. Първата стъпка е пълно картиране на ретиновата мозайка на доброволците. По този начин изследователите получават информация за разположението на различните клетки в ретините им. След това участниците поставят главите си в специална установка, където има място, което захапват – така могат да държат главата и съответно очите си почти неподвижни в пространството. И тук става магията – софтуер, наречен Wizard, следи микроскопичните и неволни движения на очите, като същевременно насочва прецизно специален лазер, така че светлината му да попада само в предварително избрани клетки, в случая M конуси.

Новият цвят, наречен от учените olo (от компютърното представяне на активация само на M конусите – 0, 1, 0), е описан от участниците в изследването като синьо-зелено, морскосиньо, зелено, но с много по-силен интензитет от обичайните им нюанси.

Като всяка изключително сложна система и Oz, въпреки своя магьосник, има своите недостатъци. Тъй като броят на M конусите е изключително голям, е много трудно лазерът да се насочи към всеки от тях. Поради това размерът на цветното петно, което виждат доброволците, е сравнително малко – колкото монета от 1 лев, гледана от една ръка разстояние, около два пъти по-голямо от Луната в нощното небе. По-сериозният проблем е, че въпреки следенето на движението на очите и прецизното насочване на лазера, около 60% от излъчената светлина попада в други клетки. Все пак според изчисленията на учените, потвърдени емпирично от наблюденията на участниците в изследването, цветът е извън границите на обичайното ни възприятие. Това прави бъдещото подобрение на технологията още по-интригуващо, защото, ако разсейването на светлината се намали и наистина се активират само един тип клетки, то цветът ще е още по-наситен.

Макар и на пръв поглед да изглежда така, разработената система не е просто високотехнологична играчка. Екипът, създал Oz и Wizard, смята, че интересното тепърва предстои. Системата може да се използва за различни експерименти, свързани с работата на зрението ни и с възприятието на цветовете. По-амбициозната цел е с помощта на подобрена установка, която може да покрие цялото зрително поле, да се помогне на хора с цветна слепота. Това е стъпка към трайно възстановяване на коректното трицветно виждане при тях. 

Вече има експерименти с примати, при които във възрастни екземпляри с червено-зелена слепота с помощта на генна терапия е добавен трети пигмент. От проведените тестове процедурата изглежда успешна – маймуните успешно различават предмети, които преди това са приемали за еднакви. Този експеримент показва, че подобна терапия може да се приложи и при хора. Но все още има много неясноти – маймуните все пак не могат да споделят възприятията си с учените, поради което не се знае как точно се справя мозъкът при внезапната поява на нов сигнал в зрителната система.

Именно тук от полза би била подобрена версия на Oz – конусите могат да бъдат разделени, така че да получават различна цветова информация, давайки възможност да се изследва пластичността на мозъка без драстични намеси. Ако се окаже, че той се адаптира лесно към подобна промяна, на практика ще е възможно разделянето на конусите ни на допълнителни подвидове, което да позволи тетра- или повече цветно зрение. Това би отворило вратите към напълно нов свят на цветно възприятие.

The countdown begins! Astro Pi participants to have their programs run in space

Post Syndicated from Fergus Kirkpatrick original https://www.raspberrypi.org/blog/the-countdown-begins-astro-pi-participants-to-have-their-programs-run-in-space/

This week, young people participating in the European Astro Pi Challenge 2024/25 will have their programs run in space! Astronauts from the European Space Agency (ESA) have been setting up the Astro Pi computers on board the International Space Station (ISS) ready to receive the programs. 

The European Astro Pi Challenge is an ESA Education project run in collaboration with the Raspberry Pi Foundation. It has two strands: Mission Zero, where young people write programs that display pixel art on LED screens on board the ISS, and Mission Space Lab, where more advanced learners attempt to calculate the speed of the ISS by writing programs that gather data from onboard equipment.

This year has already been a great year for the challenge!

A photograph of a young learner coding on a computer for Mission Zero
A young learner coding on a computer for Mission Zero

Mission Zero reaches more young people than ever

Mission Zero received 17,285 team submissions this year, representing 25,405 young people from ESA member and associate member states. This marks the highest-ever level of participation in Mission Zero since its inception back in 2017. Here at Mission Control, we’re delighted to announce that nearly all the participating teams (17,109 out of 17,285) have achieved ‘flight status’ — meaning that their programs will run in space. 

It’s been great to see so many young people taking part from areas of educational disadvantage too. Through partnerships with youth organisations and community events such as Beyond the Bias and Norwich Science Festival, we’ve seen Mission Zero reach even more young creators from traditionally underrepresented groups.

The 2024/25 Mission Zero project guide featured new coded pixel art examples for teams to remix and reinterpret. Many teams also created their own artworks and animations, with amazing creativity and coding skills on display. We’ll be selecting six submissions from this year to feature as the new code examples in the 2025/26 Mission Zero project guide. Look out for more news on this in the summer.

A selection of pixel art inspired by nature created by young people for Mission Zero
GIFs submitted by Mission Zero participants

New highs for Mission Space Lab

Mission Space Lab teams were tasked again this year with writing programs to collect data from cameras and sensors on board the ISS to calculate its speed. We’ve been really pleased to see 562 teams register and 325 submit their programs. This has resulted in an amazing 309 teams being awarded flight status — their programs will each run on the ISS for ten minutes, giving participants the unparalleled opportunity to record sensor data in space and take photos many miles above the Earth. 

More teams have submitted programs and achieved flight status this year than in 2023/24. We believe this uptick is due, in part, to a couple of new additions that have made submissions easier: 

  • Firstly, Mission Space Lab teams can now test their programs online using the Astro Pi Replay Tool. This gives them a chance to see if their program will work on the real Astro Pis on board the ISS by replaying historical data sets captured from previous missions. 

Secondly, teams have been able to use the Picamzero Python library, which makes it easier to use PiCamera2 functionality.

A photograph taken from space of the Peloponnese Peninsula
The Peloponnese Peninsula in Greece, taken in 2024 by the Astro Pi computers on the ISS

Deployment

Today’s the day when Mission Zero and Mission Space Lab teams with flight status will have their programs sent up to the ISS. Astronauts have been busy setting up the Astro Pi computers ready to receive the programs and putting them into position. Over the next two weeks, the programs will run and the collected data will be sent down from the ISS to Earth. 

An illustration of the International Space Station sending program files to a satellite dish on Earth
Files being sent down from the ISS

In June, Mission Zero and Mission Space Lab teams will receive certificates of participation with the exact times their programs ran on the ISS, along with the coordinates of where the ISS was above the Earth. Mission Space Lab teams will also receive a zip file with the data their programs collected. 

None of this would have been possible without the hard work of all the mentors, teachers, and Code Club leaders that organise the teams of young people doing the Astro Pi missions. 

Let’s stay curious, with our eyes upwards on that final frontier!

Looking for ways to keep your creators coding?

While you wait for the next cycle of the European Astro Pi Challenge, there are many other exciting coding opportunities for you and your teams to explore, including:

  • Coolest Projects: Coolest Projects is a free, worldwide showcase where young digital creators share the amazing things they’ve made with technology. There’s an international online showcase as well as in-person events in several countries. Every participant gets certificates and rewards, and projects of any kind and at any level are encouraged.
  • Code Club projects: Our extensive collection of Code Club projects explore Python, Scratch, the BBC micro:bit, and much more — there’s something available for all young people, no matter their level of experience.

The post The countdown begins! Astro Pi participants to have their programs run in space appeared first on Raspberry Pi Foundation.

Незаконната постройка на българската законност

Post Syndicated from Светла Енчева original https://www.toest.bg/nezakonnata-postroyka-na-bulgarskata-zakonnost/

Незаконната постройка на българската законност

15 април, вторият ден от Страстната седмица. Докато мейнстрийм медиите се надпреварват коя ще произведе повече материали за мъките Христови, кметът на столичния район „Илинден“ Емил Бранчевски разпорежда да се съборят единствените жилища на около 200 души в кв. „Захарна фабрика“. За потушаване на евентуалната съпротива на обитателите им на място са изпратени жандармеристи. Има дори водно оръдие.

Унищожаването на съществувалото от десетилетия ромско гето се извършва, въпреки че три дни по-рано Европейският съд по правата на човека (ЕСПЧ) в Страсбург изрично забранява разрушаването на махалата в „Захарна фабрика“. Бранчевски защитава отказа си да се съобрази със съдебното решение с аргументи, които може да се обобщят така: ЕСПЧ нещо се е объркал.

За хората, оставени без дом, няма осигурени алтернативни жилища. Единственото предложение е жилищен блок в кв. „Ботунец“ без ток, вода, прозорци и врати. Междувременно кметове на различни столични райони заявяват, че няма да приемат на територията си бедстващите роми.

Липса на официални позиции и наличие на неофициални

В тази ситуация Васил Терзиев се държи, сякаш нарушаването на международното право в града, чийто кмет е той, изобщо не го засяга. В деня на събарянето на гетото постовете му във Facebook са за езерата в Южния парк и откриването на детска градина. Два дни по-късно пише за празничното настроение, което създава великденската украса в София.

Няма позиции и на „Спаси София“ (СС), чиято номинация за районен кмет е Бранчевски, както и на останалите партии и коалиции в Столичния общински съвет. Включително на „Продължаваме промяната“ и „Демократична България“, които бяха в коалиция със СС до 22 април 2025 г., когато „Спаси София“ обяви, че сваля доверието си от Терзиев.

Чий е Емил Бранчевски?

От СС и коалицията, от която бяха част, всъщност имат известно основание да не поемат отговорност за действията на Бранчевски. В края на 2024 г. той се обърна срещу партията на Борис Бонев и обвини членовете ѝ в „некадърност“. Това стана в деня, след като Върховният административен съд го възстанови на поста му.

Делото във ВАС беше по обвинение, че кметът на „Илинден“ притежава фирма във Великобритания, за която той твърдеше, че не знае нищо и че е фиктивна – създадена само за да бъде компрометиран.

Подобни дела имаше и срещу други районни кметове от ПП–ДБ–СС. Кметовете на „Оборище“ Георги Кузмов и на „Слатина“ Георги Илиев решиха да участват в нови избори за постовете си. Кузмов спечели на първи тур, а частичните избори в „Слатина“ предстоят през юни.

Откакто Бранчевски се отрече от СС, той вече не е на прицела на българската правосъдна система.

Единствената позиция на представител на екипа на кмета е на Надежда Бачева от „Да, България“,

зам.-кметица по социални дейности и интеграция на хора с увреждания. Във Facebook тя заяви, че на всички, останали без дом, е осигурена алтернатива, но едва три семейства са приели помощта, а другите „отказват подадената ръка“. И дори ги обвини, че не искали временен подслон, а „хотел“, както и да прередят чакащите за общинско жилище над 7000 души.

Незаконната постройка на българската законност
Ул. „Суходолска“ 3, кв. „Захарна фабрика“. Снимка: Вера Гоцева

Информацията, която Бачева представя за броя на засегнатите, е подвеждаща. Тя твърди, че едва 27 души са останали без покрив, защото те са регистрирани на адреса на гетото – ул. „Суходолска“ 3. Много от обитателите на махалата обаче се водят на други адреси, на които не живеят. Причината за това е, че на един и същи адрес не е разрешено да живеят произволен брой хора, а махалата в „Захарна фабрика“ разполага само с този адрес – ул. „Суходолска“ 3. Така на някои от нейните жители им се налага да се регистрират на други места, защото без адресна регистрация не могат да имат дори лични документи. 

На зам.-кметицата се противопостави съпартиецът ѝ Манол Пейков. Той определи поста ѝ като „неуместен“ и „проява на лош вкус“, подчерта, че е имало решение на ЕСПЧ, и заключи:

Когато се намираш от страната на оня, дето е сгафил […], не се втурваш да обясняваш какво и как, ами навеждаш глава, понасяш ударите и действаш, за да оправиш нещата.

Позицията на общинския съветник Христо Копаранов

Освен член на групата на СС в СОС, Христо Копаранов е адвокат и правозащитник. Той защитава про боно Бранчевски по делото за фирмата във Великобритания. „Тоест“ го помоли за коментар за събарянето на ромските къщи в район „Илинден“.

Според него „нещата са доста по-сложни, отколкото се представят“, защото от едната страна са хората, които остават без къщи, от другата – жителите на района, които „с право се оплакват, че дишат отровен въздух“, и това не ги прави „расисти“ – и дишането е основно човешко право.

В същото време заиграването с техните страхове посредством потъпкване на международното право е безобразно

подчерта той и определи действията на районната администрация като „поведение тип „слон в стъкларски магазин“.

Общинският съветник сподели, че самият той живее в „Западен парк“ (квартал в близост до „Захарна фабрика“ и „Факултета“), но обмисля да се премести заради мръсния въздух, причина за който е горенето на отпадъци в гетата. „Не може да се разрушат жилища просто така, но не може община и държава да абдикират и от въпроса какво дишаме.“

Същевременно Копаранов смята, че изискванията на международното право са от първостепенно значение, още повече че България вече е била осъждана по подобни казуси от ЕСПЧ, например по делото „Йорданова и други срещу България“. В присъдите се казва, че когато премахва незаконни строежи, които са нечии единствени жилища, държавата трябва да постъпи съразмерно, т.е. да осигури алтернативно настаняване. А щом в конкретния случая със „Захарна фабрика“ ЕСПЧ е наложил привременни мерки,

кметът на района не може сам да преценява подведен ли е съдът, или не. Той е длъжен да се съобрази с разпореждането.

По-сериозният проблем според Христо Копаранов обаче е, че „общината и държавата не могат да създават бездомници“, и той многократно е коментирал темата с жители на района. В това той вижда и най-голямата грешка на Бранчевски. Защото оставянето на хора без подслон е лошо не само за тях, то създава проблеми за сигурността на всички – „същите хора ще трябва да живеят някъде в града“.

Границата, която събарянето на къщите в „Захарна фабрика“ прекрачва

В България не е прецедент да се унищожават единствените жилища на ромски семейства с аргумента, че те са „незаконни постройки“, без да се предоставят алтернативи на обитателите им. Това се е правило много пъти.

Не е прецедент и да не се изпълняват решения на ЕСПЧ. Ето няколко примера.

По общо три дела ЕСПЧ е постановил, че България не може да отнема правото на глас на затворници и на хора, поставени под запрещение, без да се отчитат тежестта на извършеното престъпление и размерът на присъдата на лишените от свобода или съответно индивидуалните възможности на запретените лица. До ден днешен обаче хората под запрещение нямат право да гласуват, както и лишените от свобода с влязла в сила присъда, независимо каква е тя.

През септември 2023 г. ЕС отсъди, че България трябва да създаде правна рамка, дори тя да не е брак, която признава и гарантира защита на съюзите на лица от един и същи пол. Не само че това не е направено, а дори интимните връзки на еднополовите двойки не се признават за съществуващи от закона.

Случаят със „Захарна фабрика“ обаче е различен, защото става въпрос за дело по конкретен казус, заведено от БХК от името на 14 жители на махалата с цел предотвратяване на определено действие. В други аналогични ситуации българските институции са се съобразявали с разпореждането на ЕСПЧ да не се събарят къщи, преди да се осигури алтернатива. Но не и в тази.

Незаконната постройка на българската законност
Ул. „Суходолска“ 3, кв. „Захарна фабрика“. Снимка: Вера Гоцева

Пирамидалната структура на правосъдието

Аргументът на Емил Бранчевски за незаконността на постройките и взетото още през 2016 г. решение за премахването им показва, че той или не разбира какво е правосъдие, или не иска да се съобразява с него.

Решенията, които една или друга институция взема, се основават на нормативни актове. Има подзаконови актове, например правилници и наредби. Над тях са законите и кодексите. Те пък се подчиняват на Конституцията. Основният закон, от своя страна, не трябва да противоречи на международното законодателство, което България е ратифицирала. Част от това международно законодателство е Европейската конвенция за правата на човека (ЕКПЧ).

Както Конституционният съд решава какво противоречи на Конституцията и какво – не, така Съдът в Страсбург съблюдава спазването на ЕКПЧ. И решенията му са задължителни за страните, ратифицирали Конвенцията.

Правосъдие в стил „за кокошка няма прошка, за милиони няма закони“

Позволявайки си да не се съобрази с решение на ЕСПЧ, Бранчевски демонстрира, че за него незаконността на едни къщи е по-сериозно закононарушение от несъобразяването с международното законодателство.

Може би кметът на „Илинден“ е вдъхновен от американския президент Доналд Тръмп, който, когато някое съдебно решение не му изнася, обвинява съда и конкретните съдии, които са го взели. Но когато един държавен глава отказва да се подчинява на правото, това прилича на опит за въвеждане на диктатура (диктатурата ще е въведена, ако се премахнат всички закони, които пречат на държавния глава).

Когато обаче един районен кмет не иска да се съобрази с правото, това отваря вратата към повсеместен произвол. Защото правото затова е право, за да регулира обществените отношения, независимо че тази регулация няма как да се харесва на всички.

А какво да правим с незаконно паркиралите ламарини на колела?

Замисляли ли сте се върху израза „незаконни постройки“, когато става въпрос за събарянето на единствени жилища на роми? Това словосъчетание изпълнява дехуманизираща функция – то концентрира вниманието върху факта, че нещо е незаконно, и го отвлича от по-важното – човешката ценност. Унищожават се нечии домове. А една незаконна постройка може да е какво ли не – склад, барака за дърва, подпорна стена…

Пардон, „подпорната стена“ на Алепу, която уж не беше хотел, ама всъщност е, вече е законна. Може би защото в нея не живеят роми.

Хайде да си направим един мисловен експеримент.

Да си представим, че някой от районните кметове в София е твърдо решен да се справи с незаконното паркиране по тротоари и градинки. И въведе радикална мярка – всеки автомобил, паркиран в нарушение, се предава за скрап. Но вместо да казва „коли“ или „автомобили“, кметът употребява израза „незаконно паркирали ламарини на колела“.

Притежателите на превозните средства се противопоставят на мярката с аргументите, че тя е непропорционална, че е посегателство върху правото им на собственост, че за колите си са плащали данъци и осигуровки, че няма достатъчно места, където да паркират. Кметът обаче настоява, че незаконно паркиралите ламарини на колела трябва да ги няма. И точка.

Може би си мислите, че примерът е неподходящ, защото собствениците на колите ги притежават легално, плащат за тях данъци и осигуровки, само ги паркират в нарушение. А хората в ромската махала живеят в къщи, които са незаконни, дори да плащат ток и вода.

Но и ситуацията с автомобилите в столицата, както и тази с незаконните къщи в ромските гета са резултат от дългогодишния отказ от въвеждане на политики, които предлагат системни решения на системни проблеми.

Всъщност прави сте – не е същото. Отнемането на автомобила неизбежно причинява известен дискомфорт, особено за хора, които не са свикнали да използват обществения транспорт и/или нямат удобни транспортни връзки. Липсата на дом обаче е много по-сериозен проблем. Обитателите на „Захарна фабрика“, останали без покрив над главата, не само нямат къде да спят, да се изкъпят или просто да си починат. Те трудно могат да продължат да ходят на работа, децата им прекъсват училище, изобщо – изпадат от обществото.

Неслучайно неприкосновеността на жилището е спомената като част от правото на зачитане на личния и семейния живот в ЕСПЧ. Тя впрочем присъства и в Конституцията. Но докато степенуваме хората по ценност, колите на едни ще са по-важни от живота на други.

How to import existing AWS Organizations SCPs and RCPs to CloudFormation

Post Syndicated from Swara Gandhi original https://aws.amazon.com/blogs/security/how-to-import-existing-aws-organizations-scps-and-rcps-to-cloudformation/

Many AWS Organizations customers begin by creating and manually applying service control policies (SCPs) and resource control policies (RCPs) through the AWS Management Console or AWS Command Line Interface (AWS CLI) when they first set up their environments. However, as the organization grows and the number of policies increases, this manual approach can become cumbersome. It can result in limited visibility into all implemented SCPs and RCPs, the targets they’re attached to (such as accounts, organizational units (OUs), or nested OUs), and the ability to manage updates effectively. Without clear visibility and proper access controls, it becomes challenging to track who’s making changes and how they are being made.

Importing existing SCPs and RCPs into AWS CloudFormation can help streamline the management of your policies by enabling history tracking, policy validation through CloudFormation Hooks, and rollback capabilities. You can also sync stacks with source code stored in a Git repository with Git sync. With Git sync, you can use pull requests and version tracking to configure, deploy, and update your CloudFormation stacks from a centralized location. When you commit changes to the template or the deployment file, CloudFormation automatically updates the stack.

In this post, I provide a solution to import existing SCPs and RCPs into AWS CloudFormation templates using the CloudFormation infrastructure as code generator (IaC generator). By using the IaC generator, you can automate the management of your SCPs and RCPs at scale.

Important: Only existing policies are brought into CloudFormation; policies are not recreated.

Solution overview

The solution in this post includes a command line tool for discovering SCPs and RCPs in your organization and automating policy import into CloudFormation templates. The following figure shows the end-to-end flow:

Figure 1: Solution overview

Figure 1: Solution overview

The end-to-end flow shown in the preceding figure includes:

  1. Run the tool: The tool automates the following steps and can be run in the management account or delegated administrator account.
    1. Identify SCPs and RCPs in the organization: The tool begins by making API calls to the Organizations service to retrieve the policies in your environment. It then provides a count of the total number of SCPs and RCPs present.
    2. Identify AWS Control Tower SCPs and RCPs and policies without targets:
      1. AWS Control Tower SCPs and RCPs: The tool checks for SCPs and RCPs created by AWS Control Tower and lists them in the output for your review.
        • SCPs are identified by the aws-guardrails- prefix in their policy names.
        • RCPs are identified by the AWSControlTower-Controls- prefix in their policy names.
      2. Policies with no targets: The tool also identifies SCPs and RCPs that aren’t attached to an organizational unit (OU), account, or root and lists them. These policies might be redundant or need reassignment.
    3. CloudFormation IaC generator scan: At this stage, you will be prompted to confirm whether you want to import the policies to the CloudFormation templates using CloudFormation resource scan. If you select yes, the tool will initiate a CloudFormation resource scan using IaC generator to get details about the policies including policy name, targets, policy tags, and so on.
    4. Create template from scanned policy resources: The tool generates CloudFormation template with the policy resources. The template will include the policies without targets (if any).
  2. Review process: After the template is generated, it’s recommended that you preview the template using IaC generator from the CloudFormation console. We recommend viewing the template resource section to verify and adjust the generated templates as needed (step 11 of the solution deployment).
  3. Create CloudFormation stacks with the generated templates: After reviewing the templates, import them into CloudFormation stacks for deployment. It’s important to note that only existing policies are brought into CloudFormation—policies aren’t recreated. The templates reflect the current policies and policy attributes.

Consideration before implementing the solution

There are some considerations that you need to keep in mind before implementing the solution.

  • If you have enabled the AWS Organizations policy management delegation, you should run this solution from the delegated administrator account. Otherwise, you can run the solution using the management account.

    Note: Delegating management of organizations policies to a delegated administrator member account is recommended best practice.

  • AWS Control Tower SCPs and RCPs (with or without targets) won’t be imported to the CloudFormation templates because they should be managed using AWS Control Tower. Changes made to AWS Control Tower resources outside of AWS Control Tower can cause drift and affect AWS Control Tower functionality in unpredictable ways.
  • FullAWSAccess SCP and RCPFullAWSAccess RCP are AWS managed policies that won’t be imported to CloudFormation because CloudFormation stacks do not allow importing AWS managed resources.
  • You might see multiple CloudFormation templates created if you exceed the CloudFormation template size quotas. To help ensure smooth creation, the tool is designed to automatically split the content into multiple templates if necessary, allowing you to stay within the quotas while still accommodating the imported content.
  • Note that the generated templates have the following attributes set by default.
    • Deletion policy: Set to Retain. This enables persisting the policies even when their related stack is deleted.
    • Update Replace policy: Set to Delete. This enables deletion of the physical ID associated with the policy when the policy is updated.

Solution deployment

Now that you understand the solution and know the considerations to keep in mind, you’re ready to deploy the solution.

  1. Clone the solution repository.
    git clone https://github.com/aws-samples/sample-tool-for-importing-existing-AWS-SCPs-and-RCPs
    

  2. Navigate to the directory of the cloned repository.
    cd sample-tool-for-importing-existing-AWS-SCPs-and-RCPs/
    

  3. Install the solution (Python 3.10+ is supported)
    pip install .
    

  4. If you want to use a particular AWS Identity and Access Management (IAM) principal to run this tool, create a profile in ~./aws/config using an IAM principal from your AWS Organizations management account. If you have delegated policy management to a member account, make sure that you use the IAM principal from the delegated administrator account. 

    Note: The IAM principal will need to have the following permissions to be able to successfully run the tool.

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "VisualEditor0",
                "Effect": "Allow",
                "Action": [
                    "organizations:Describe*",
                    "organizations:List*",
                    "cloudformation:Describe*",
                    "cloudformation:Detect*",
                    "cloudformation:Estimate*",
                    "cloudformation:Get*",
                    "cloudformation:List*",
                    "cloudformation:CreateGeneratedTemplate",
                    "cloudformation:StartResourceScan",
                    "cloudformation:UpdateGeneratedTemplate",
                    "cloudformation:CreateStack",
                    "cloudformation:DeleteStack",
                    "cloudformation:UpdateStack",
                    "cloudformation:DeleteGeneratedTemplate"
                ],
                "Resource": "*"
            }
        ]
    }
    

  5. You can run the tool specifying a profile name as a command line argument. Use the following command, replacing <profile_name> with the name of the profile you created in step 4. If you do not specify a profile, the default profile from the file ~./aws/config will be used.
    policy-importer --profile <profile_name>
    

  6. After the preceding command is executed, you will see an output displaying the total number of SCPs and RCPs found in the organization. The output will also list AWS Control Tower managed policies as INFO, in addition to policies without targets as a WARNING. At this point, you can enter Yes to proceed with scanning to import the policies, or enter No if you want to exit.

    Note: If policies without targets are detected, we recommend stopping at this point. Either delete the policies without targets or assign appropriate targets to them. You can then rerun the tool from step 5. If you proceed without addressing the policies without targets, be aware that these policies will also be included in the CloudFormation template.

    Figure 2: Terminal view with policies identified in the organization

    Figure 2: Terminal view with policies identified in the organization

  7. If you enter Yes, the CloudFormation IaC resource scan will begin immediately. You will see the resource scan ID Amazon Resource Name (ARN) displayed.

    Note: A scan can take up to 10 minutes for every 1,000 resources.

    Figure 3: Terminal view with AWS CloudFormation resource scan details

    Figure 3: Terminal view with AWS CloudFormation resource scan details

  8. You can also review the scan progress from the IaC generator page of the CloudFormation console as shown in the following figure. To get to the IaC generator page, go to the CloudFormation console and choose IaC generator from the navigation pane.
    Figure 4: View the scan summary in the CloudFormation console to track progress

    Figure 4: View the scan summary in the CloudFormation console to track progress

  9. Upon completion of the scan, the template generation process will be initiated.
    Figure 5: Terminal view showing CloudFormation template being created

    Figure 5: Terminal view showing CloudFormation template being created

  10. After the template creation is finished, sign in to the AWS CloudFormation IaC console. Choose the Templates tab to review the generated templates and verify that they align with your requirements.
    Figure 6: View CloudFormation templates in the console

    Figure 6: View CloudFormation templates in the console

  11. You can review the policies added to a template by selecting a template name.
    Figure 7: Review policies included in the template

    Figure 7: Review policies included in the template

  12. When satisfied, you can proceed to import the templates into CloudFormation stacks for deployment by selecting Import to stack.
    Figure 8: Import a template into the CloudFormation stack

    Figure 8: Import a template into the CloudFormation stack

  13. Follow the prompts to create a stack.
    Figure 9: AWS CloudFormation stack example

    Figure 9: AWS CloudFormation stack example

  14. The tool automatically creates a folder named Policies in your current directory and downloads the generated templates.

    Note: If you encounter errors, check the recommended solutions for common issues.

As shown in the following figure, there are two recommended next steps.

Figure 10: Solution overview including recommended next steps

Figure 10: Solution overview including recommended next steps

After the existing policies are imported into a CloudFormation stack, we recommend storing your CloudFormation templates in a private Git repository. You can use the Policies folder that was automatically created by the tool in the current local directory with the generated templates downloaded and set up a continuous integration and delivery (CI/CD) pipeline to efficiently manage the imported policies.

By using a Git repository, you can use version control features like pull requests, branch management, and history tracking. This approach allows your team to efficiently review, update, and deploy policies with better collaboration and control. You can also create a CI/CD pipeline to automate the deployment of changes to your CloudFormation stacks, helping to ensure that updates are consistent and reliable.

We also recommend incorporating CloudFormation Hooks in your environment. CloudFormation Hooks can help validate policies (and other resources) against best practices, to help ensure that they adhere to the correct syntax, follow security best practices, and minimize potential vulnerabilities.

Related resources:

Conclusion

Importing existing AWS Organizations service control policies (SCPs) and resource control policies (RCPs) into CloudFormation provides an efficient and scalable approach to managing and automating your AWS governance. After they’ve been imported, you can manage and update policies directly in CloudFormation, to help ensure consistency and version control across your organization. The tool also creates a Policies folder in your current directory, storing downloaded templates for use as a central repository and integration with a CI/CD pipeline.

By using CloudFormation Hooks, you can further improve your policy management by validating SCPs and RCPs against best practices and policy grammar. This approach centralizes your policy updates, making governance more automated and efficient while reducing the risk of misconfiguration.

Swara Gandhi

Swara Gandhi

Swara is a Senior Solutions Architect on the AWS Identity Solutions team. She works on building secure and scalable end-to-end identity solutions. She is passionate about everything identity, security, and cloud.

Amazon introduces SWE-PolyBench, a multilingual benchmark for AI Coding Agents

Post Syndicated from Christian Bock original https://aws.amazon.com/blogs/devops/amazon-introduces-swe-polybench-a-multi-lingual-benchmark-for-ai-coding-agents/

Coding agents powered by large language models have shown impressive capabilities in software engineering tasks, but evaluating their performance across diverse programming languages and real-world scenarios remains challenging. This led to a recent explosion in benchmark creation to assess the coding effectiveness of said systems in controlled environments. In particular, SWE-Bench which measures the performance of systems in the context of GitHub issues has spurred the development of capable coding agents resulting in over 50 leaderboard submissions, thereby becoming the de-facto standard for coding agent benchmarking. Despite its significant impact as a pioneering benchmark, SWE-Bench, and in particular its “verified” subset, also shows some limitations. It contains only Python repositories, the majority of tasks are bug fixes, and at over 45% of all tasks, the Django repository is significantly over-represented.

Today, Amazon introduces SWE-PolyBench, the first industry benchmark to evaluate AI coding agents’ ability to navigate and understand complex codebases, introducing rich metrics to advance AI performance in real-world scenarios. SWE-PolyBench contains over 2,000 curated issues in four languages. In addition, it contains a stratified subset of 500 issues (SWE-PolyBench500) for the purpose of rapid experimentation. SWE-PolyBench evaluates the performance of AI coding agents through a comprehensive set of metrics: pass rates across different programming languages and task complexity levels, along with precision and recall measurements for code/file context identification. These evaluation metrics can help the community address challenges in understanding how well AI coding agents can navigate through and comprehend complex codebases

The leaderboard is accessible here. The SWE-PolyBench dataset is available on Hugging Face and the paper at arxiv. Evaluations can be run using the SWE-PolyBench codebase.

Below, we describe the key features, characteristics, and the creation process of our dataset alongside the new evaluation metrics, and performance of open source agents from our experiments.

Key features of SWE-PolyBench at a glance

  1. Multi-Language Support: Java (165 tasks), JavaScript (1017 tasks), TypeScript (729 tasks), and Python (199 tasks).
  2. Extensive Dataset: 2110 instances from 21 repositories ranging from web frameworks to code editors and ML tools, on the same scale as SWE-Bench full with more repository.
  3. Task Variety: Includes bug fixes, feature requests, and code refactoring.
  4. Faster Experimentation: SWE-PolyBench500 is a stratified subset for efficient experimentation.
  5. Leaderboard: A leaderboard with a rich set of metrics for transparent benchmarking.

Building a comprehensive dataset

The creation of SWE-PolyBench involved a data collection and filtering process designed to ensure the quality and relevance of the benchmark tasks. SWE-Bench, a benchmark for Python code generation, evaluates agents on real-world programming tasks by utilizing GitHub issues and their corresponding code and test modifications. We extended the SWE-Bench data acquisition pipeline to support 3 additional languages besides Python and used it to gather and process coding challenges from real-world repositories as shown in Figure 1.

A flowchart diagram showing a software development process. It starts with an issue (#3039) and pull request (#3147) on the left, goes through a metadata filter in the middle, then splits into a runtime setup and testing phase on the right. The testing phase feeds into a test-based filter at the end. The diagram includes icons for programming languages like JavaScript, TypeScript, Python, and Java.

Figure 1: Overview of the SWE-PolyBench data generation pipeline, illustrating the process of collecting, filtering, and validating coding tasks.

The data acquisition pipeline collects pull requests (PRs) that close issues from popular repositories across Java, JavaScript, TypeScript, and Python. These PRs undergo filtering and are set up in containerized environments for consistent test execution. The process categorizes tests as fail-to-pass (F2P) or pass-to-pass (P2P) based on their outcomes before and after patch application. Only PRs with at least one F2P test are included in the final dataset, ensuring that each task represents a meaningful coding challenge. This streamlined approach results in a dataset that closely mimics real-world coding scenarios, providing a robust foundation for evaluating AI coding assistants.

Dataset characteristics

When constructing SWE-PolyBench, we aimed to collect GitHub issues that represent diverse programming scenarios: issues involving modifications across multiple code files and spanning different task categories (such as bug fixes, feature requests, and refactoring). Tables 1 and 2 provide descriptive statistics on the composition and complexity of SWE-PolyBench full (PB) and SWE-PolyBench500 (PB500). To offer a point of reference, we compare these statistics with those of SWE-Bench (SWE) and SWE-Bench verified (SWEv). Tasks in SWE-PolyBench require on average more files to be modified and more nodes to be changed, which indicates that they have higher complexity and are closer to tasks in real-world projects. The distribution of tasks is also more diverse, in particular for SWE-PolyBench500.

A comparison table showing statistics for different software benchmarks (SWE-PolyBench, SWE-PolyBench500, SWE-Bench, and SWE-Bench verified). The table has two main sections: Modified Files showing average changes across programming languages (Python, Java, JavaScript, TypeScript), and Task Category distribution showing percentages for Bug Fix, Feature Request, Refactoring, and Miscellaneous tasks

A detailed table comparing dataset complexity across different programming languages and benchmarks (SWE, SWEv, PB, and PB500). The table shows statistics for syntax tree node changes, divided into two main sections: Node Change Category percentages (None, Function only, Class only, Mixed) and Node Change Count averages (Function, Class, Number of Nodes). The highest values in each column are shown in bold, with notable variations across Python, Java, JavaScript, and TypeScript implementations.

New evaluation metrics

To comprehensively evaluate AI coding assistants, SWE-Polybench introduces multiple new metrics in addition to the pass rate. The pass rate is the proportion of tasks successfully solved as measured by the generated patch passing all relevant tests. It is the primary metric for assessing coding agent performance, but it doesn’t provide a complete picture of an agent’s capabilities. In particular, it doesn’t give much information on an agent’s ability to navigate and understand complex code repositories. SWE-PolyBench introduces a new set of metrics based on Concrete Syntax Tree (CST) node analysis and the established file-level localization metric:

  1. File-level Localization: assesses the agent’s ability to identify the correct files that need to be modified within a repository. Let us assume that we would need to modify file.py to solve our problem. If our coding agent implements a change in any other file, it would receive a file retrieval score of 0.
  2. CST Node-level Retrieval: evaluates the agent’s ability to identify specific code structures that require changes. It uses the Concrete Syntax Tree (CST) representation of the code to measure how accurately the agent can locate the exact functions or classes that need modification.
A side-by-side comparison showing two Git version control diffs. Each diff shows a line being removed (in red, prefixed with '-') where my_var equals 3, and a line being added (in green, prefixed with '+') where my_var equals 2. Above the diffs are connected dots in different colors (green, pink, blue, and yellow) representing Git commit history visualization.

Figure 2: Illustration of CST node changes.

In Figure 2, we see a change in class node A materialized by a change in its initialization function on the left path starting from the file node. In contrast to the first change, the change in class B is considered a function node change as it doesn’t impact class construction.

Let us assume the change that would solve our problem is the change in the __init__ function. If our coding agent implements the change in my_func, it receives both a class and function node retrieval score of 0.

By combining pass rate assessment with both file-level and CST node-level retrieval metrics, SWE-PolyBench offers a detailed evaluation of AI coding assistants’ capabilities in real-world scenarios. This approach provides deeper insights into how well agents navigate and comprehend complex codebases, going beyond simple task completion to assess their understanding of code structure and organization.

Performance of open-source coding agents

Key Findings

  1. Language Proficiency: Python is the strongest language for all agents, likely due to its prevalence in training data and existing benchmarks.
  2. Complexity Challenges: Performance degrades as task complexity increases, particularly when modifications to 3 or more files are required.
  3. Task Specialization: Different agents show strengths in various task categories (bug fixes, feature requests, refactoring).
  4. Context Importance: The informativeness of problem statements impacts success rates across all agents (refer to Figure 5 of the appendix paper for details about this analysis).

Many existing open-source agents are designed primarily for Python. Adapting them to work for all four languages of SWE-PolyBench required adjusting test execution commands, modifying parsing mechanisms, and adapting containerization strategies for each language. We adapted and evaluated three open-source agents on SWE-PolyBench. The aforementioned adjustments are reflected by the added “-PB” suffix to the original agent names.

Two radar charts comparing three AI models: Aider-PB Sonnet 3.5, Agentless-PB Sonnet 3.5, and SWE-agent-PB Sonnet 3.5. The left chart shows performance across programming languages (Java, JavaScript, TypeScript, Python). The right chart displays performance in different coding styles (Functional only, Single Function, All, Mixed, No nodes, Single Class, Class only). Each model is represented by a different colored line, with Aider-PB generally showing the highest performance across categories.

Figure 3: Performance of coding agents across programming languages and task complexities, highlighting strengths and areas for improvement.

Figure 3 provides a visual representation of agent performance across different dimensions:

  • Language Proficiency: The left side of the chart shows that all three agents perform best in Python, with significantly lower pass rates in other languages. This highlights the current bias towards Python in many coding agents and their underlying large language models.
  • Task Complexity: The right side of the chart illustrates how performance degrades as task complexity increases. Agents show higher pass rates for tasks involving single class or function changes, but struggle with tasks requiring modifications to multiple classes or functions and in instances where both class and function changes are required.

This comprehensive view of agent performance underscores the value of SWE-PolyBench in identifying specific strengths and weaknesses of different coding assistants, paving the way for targeted improvements in future iterations.

In addition to these insights, the evaluation revealed interesting patterns across different task categories as shown in Table 2. The performance data across bug fixes, feature requests, and refactoring tasks reveals varying strengths among AI coding assistants. The performance on bug fixing tasks is relatively consistent. There is more variability between different agents and between multiple runs of a given agent for feature request tasks and refactoring tasks.

Table 3 showing average pass rates with standard error by task category for three agents: Agentless-PB, SWE-Agent-PB, and Aider-PB. The task categories are Bug Fix, Feature Request, and Refactoring. Aider-PB has the highest pass rates for Bug Fix (13.8) and Feature Request (15.1), while SWE-Agent-PB leads in Refactoring (16.1). Standard errors are provided for each value.

Join the SWE-PolyBench community

SWE-PolyBench and its evaluation framework are publicly available. This open approach invites the global developer community to build upon this work and advance the field of AI-assisted software engineering. As coding agents continue to evolve, benchmarks like SWE-PolyBench play a crucial role in ensuring they can meet the diverse needs of real-world software development across multiple programming languages and task types.

Explore SWE-PolyBench today and contribute to the future of AI-powered software engineering!

Resources

Authors

Christian Bock

Christian Bock is an Applied Scientist at Amazon Web Services working on AI for code.

Laurent Callot

Laurent Callot is a Principal Applied Scientist at Amazon Web Services leading teams creating AI agents for software development.

Luca Franceschi

Luca Franceschi is an Applied Scientist at Amazon Web Services working on ML models to improve the efficiency of AI agents for code generation.

Woo Jung Kim

Woo Jung Kim is an applied scientist at Amazon Web Services. He is developing an AI agentic tool designed to improve developer’s productivity.

Shihab Rashid

Shihab Rashid is an Applied Scientist at Amazon Web Services working on agentic AI for code generation with a focus on multi agent systems.

Prabhu Teja

Prabhu Teja is an Applied Scientist at Amazon Web Services. Prabhu works on LLM assisted code generation with a focus on natural language interaction.

Simon Valentin

Simon Valentin is an Applied Scientist at Amazon Web Services working on AI for code.

Martin Wistuba

Martin Wistuba is a senior applied scientist at Amazon Web Services. As part of Amazon Q Developer, he is helping developers to write more code in less time.

Giovanni Zappella

Giovanni Zappella is a Principal Applied Scientist working on the creations of intelligent agents for code generation. While at Amazon he also contributed to the creation of new algorithms for Continual Learning, AutoML and recommendations systems.

Yuan Zhuang

Yuan Zhuang is an Applied Scientist at Amazon Web Services working on AI agents for code generation.

[$] Addressing UID/GID drift in rpm-ostree and bootc

Post Syndicated from jzb original https://lwn.net/Articles/1018082/

The Fedora Project is looking for solutions to an interesting
problem with its image-based editions and spins, such as the Atomic Desktops
or CoreOS, that are
created with rpm-ostree or bootc. If a package that
is part of a image-based version has a user or group created
dynamically on installation, and it owns files installed on the
system, the system may be subject to user ID (UID) and group ID (GID) “drift”
on updates. This “UID/GID drift” may come about when a new image with
updates is generated, and therefore files may have the wrong
ownership. This can have side-effects ranging from mildly inconvenient to
serious. No solutions have been adopted just yet, but there are a few
ideas on how to deal with the problem.

Analyzing Performance at Exabyte Scale

Post Syndicated from Tim Johnson original https://www.backblaze.com/blog/analyzing-performance-at-exabyte-scale/

A decorative image showing a cloud in the foreground and various mocked up graphs in the background.

When you’re operating a data storage platform at exabyte scale, even small inefficiencies become big problems. With billions of files flowing through our systems, performance isn’t something we think about after the fact—it’s something we constantly chase, measure, and optimize.

But before you can improve cloud performance, you have to know where to look. When we were working on improving small file uploads, I was tasked with taking a closer look at our file upload pipeline to see if we could make it faster. 

The path from that general idea to hitting a clear performance goal taught me a lot—not just about our systems, but about how to approach performance work in a principled, strategic way. Here’s how it unfolded, and what you can apply to your own environment.

Step one: Define the problem

The initial ask from our Product team was pretty familiar: “Can we make uploads faster?” It’s a fair question, but not a very actionable one. So we worked with our Product team to define our success criteria. Here are some of the questions we asked to get to specific, actionable goals:

“What do we mean by faster? Do we want to improve latency or throughput?”

“Do we want to improve all uploads? Just big files? Just small files?
“What qualifies as a small upload?”

After some back and forth, we landed on a clear, measurable target: Process file uploads of 1MB or less via our B2 API in under 40 milliseconds. That specificity made a huge difference:

  • With a goal of 40 milliseconds, we had a stopping point. We would know when we’d done enough.
  • We had a bar to measure against and a way to identify what was worth optimizing. If something took two milliseconds, we could leave it alone. If it took 30, it became the focus.
  • We could scope effort. There’s a big difference between getting something under 40 milliseconds versus 200. 

Step two: Use the right tools for the job if you possibly can

Analyzing performance without proper tooling means doing a lot of heavy lifting by hand. We had to drop custom instrumentation throughout the stack, create metric-collecting objects, and pass them all the way down the call stack so we could get timing data from different parts of the upload path.

The upload flow touches more than 20 storage pods and services, so we also built a lightweight sampling system to keep from flooding our metrics pipeline. The data went into an open-source search and analytics suite, and from there we built dashboards to try to make sense of it all.

It was time-consuming. Painfully so. But it worked. 

I could now compare fast and slow uploads, identify patterns, and—most importantly—see where time was actually being spent. That’s how we discovered that fsync was dominating our performance profile, captured in the screenshot below. We measured each sub-operation that comprises our drive write operations, and grouped them by the total time they took to complete. You can see the process fsync sub-operation dominates in every group. Removing or optimizing around it offered a 10x speedup. But it took weeks of manual effort to get to that insight.

Drive write operations grouped by the time they took to complete.

Enter: Tracing at scale

Eventually, we brought in more powerful tooling, including an open source distributed tracing system. It was a game changer.

What used to take dozens of lines of code and a lot of custom wiring now took a single annotation. More importantly, it gave us something we couldn’t get otherwise: a way to see activity across services, systems, and pods—all in one view.

It allowed us to correlate events happening across different physical machines, trace performance end-to-end, and understand the impact of specific changes in real time.

At one point, we were debating whether a particular optimization would get us across the finish line. This optimization allows the slowest shard to store asynchronously if and only if all others had been successfully and durably stored. This prevents a single slow shard from slowing down the entire upload. Thanks to the new tooling, we didn’t have to guess—we could see that once we flipped the switch, we’d hit our 40ms goal (and it would help all other uploads as well, not just small uploads). That let us focus on getting that one feature ready for production, confident that it would move the needle.

Visualization demonstrating one of our upload optimizations, this time for a slower upload. The first 19 shards to complete were stored successfully and durably, so we stop waiting for the last shard, return a 200 status code to the customer (indicated by the dotted line), and allow the 20th shard to finish asynchronously.

Step three: Optimize with intent

One of the biggest lessons I learned through this process is that you can spend weeks optimizing the wrong thing if you’re not careful. That’s why measurement has to come first.

Don’t guess. Instrument. Don’t tweak randomly. Set a baseline and track deltas. Performance work is iterative. You’ll fix one bottleneck, only to reveal the next one lurking beneath it. That’s the job.

In hindsight, one of the smartest things we did was setting a clear performance goal at the start of the project. It didn’t just help us focus—it told us when we were done. You can optimize forever. Knowing when to stop is just as important as knowing where to begin.

Step four: Tool up for the future

The tracing tool has made life a lot easier, but it’s not the only tool we use. Our analytics suite still plays a big role when we want to analyze aggregate data, or need the flexibility to slice and dice data. The two complement each other nicely.

There’s no one-size-fits-all solution—it’s more like a toolbox. And like any good toolbox, it keeps growing with our needs.

Advice from the trenches

If you’re running distributed systems or chasing performance in your own stack, here’s what I’d suggest:

  • Start with a clear goal. Know exactly what “faster” means, and write it down.
  • Measure before you optimize. Otherwise, you’re flying blind.
  • Pick the right tool for the job. Tracing, metrics, logs—they all have their place.
  • Don’t wait to build your tools. Invest in observability early.
  • Know when to stop. The ROI of performance work diminishes fast if you’re not careful.

And maybe give your helper methods better names than DoSomeWork. Or don’t. It makes the code reviews a little more entertaining.

The post Analyzing Performance at Exabyte Scale appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

The collective thoughts of the interwebz