David Steele, maintainer of the popular pgBackRest backup and restore project for
PostgreSQL, has archived
the project and announced that it is no longer being maintained.
After a lot of thought, I have decided to stop working on pgBackRest. I did
not come to this decision lightly. pgBackRest has been my passion project for
the last thirteen years, and I was fortunate to have corporate sponsorship for
much of this time, but there were also many late nights and weekends as I worked
to make pgBackRest the project it is today, aided by numerous
contributors. Every open-source developer knows exactly what I mean and how much
of your life gets devoted to a special project.
Since Crunchy Data was sold, I have been maintaining pgBackRest and looking
for a position that would allow me to continue the work, but so far I have not
been successful. Likewise, my efforts to secure sponsorship have also fallen far
short of what I need to make the project viable.
Version 0.16.0 of the Zig programming language was
recently announced, and with
it an expanded version of the new Io interface that we
covered in December.
The new interface is based on an idea called structured concurrency that makes writing
correct concurrent applications easier. Zig’s implementation of
the idea is more explicit and verbose than other languages, however, which could
offer an opportunity to explore the consequences of different designs.
Jon Seager, VP engineering for Canonical, has posted
an update on “what Canonical and Ubuntu will do (or not) to
incorporate AI” that explains what part AI will play in the future
of the company and its distribution.
The bottom line is that Canonical is ramping up its use of AI tools
in a focused and principled manner that favours open weight models
with license terms that feel most compatible with our values, combined
with open source harnesses. AI features will be landing in Ubuntu
throughout the next year as we feel that they’re of sufficient
maturity and quality, with a bias toward local inference by
default.
AI features in Ubuntu features will come in two forms: first as a
means of enhancing existing OS functionality with AI models in the
background, and latterly in the form of “AI native” features and
workflows for those who want them.
This year Canonical has begun a more deliberate push toward
education and developing competence with AI tools. We are not setting
shallow metrics on token usage, or percentages of code written with
AI, but rather incentivising engineers to experiment and understand
where AI tools add value. Rather than force a single early-choice AI
stack, we’re incentivising teams to each pick ‘something different’
and go deep, so we learn more as an org in the next six months.
Version 26.04
of the niri scrollable-tiling Wayland compositor has been released. The most
notable change in this release, as the “most requested niri feature by far“,
is support for the blur effect using the Wayland protocol’s ext-background-effect. This
release also features optional configuration
includes, screencasting support enhancements, and a number of improvements for
input devices.
In short, background blur turned out to be a massive undertaking. Not because of
the blur algorithm itself (by the way, if you want to learn about different blurs,
including the widely used Dual Kawase, I highly recommend this blog post), but because window
background effects in general required a lot of thinking and additions to the code,
especially to make them as efficient as possible. This is one of the most complex
niri features thus far.
Linus has released 7.1-rc1 and closed the
merge window for this release.
Things look fairly normal, although we do have a few different
projects to cull some old hardware support to help minimize
maintenance burden: phasing out i486 support (configs deleted, code
deletions to follow) and independently starting to remove some
really old networking hardware support, and removing some SoC
support that never went anywhere.
But we’re more than making up for any stale code removal with all
the new features and code added, so the diffstat still shows many
more lines added than removed.
Enterprise modernization has reached an inflection point. You can transform one repository easily. Existing tools, including AWS Transform custom, work well for individual repositories, and the process is understood. But what about 50 repositories? 100? 200? When you need to modernize at enterprise scale, transforming code is only part of the challenge. Coordinating people, capturing knowledge, and maintaining quality across your entire portfolio are also important.
In this post, we explore how AWS Transform custom’sbulk automation capabilities address the enterprise coordination problem through intelligent learning and scaled execution. You will see how one customer reduced end-to-end modernization timelines from 7-12 weeks to 2.5 weeks, delivering a 3-5x reduction in delivery time and 10-20x reduction in total effort hours. Most importantly, you will learn how to start your own transformation journey immediately.
The Coordination Problem at Enterprise Scale
Ask any enterprise architect about their last major modernization initiative, and you will hear familiar stories. As an example, an enterprise software company needed to migrate a large legacy codebase to a modern platform. Their projection: 12 weeks of intensive work coordinating across multiple teams.
The code transformation itself took days. The remaining weeks were consumed by the end-to-end activities surrounding it: orchestrating teams across time zones, ensuring consistent patterns across codebases with different histories, and managing dependencies so upstream changes did not break downstream systems. Teams tracked status through meetings and spreadsheets and captured tribal knowledge that existed only in senior developer heads.
This is the enterprise coordination problem. When you scale from one repository to hundreds, coordination overhead explodes. Each additional repository adds not just its own complexity, but new integration points, edge cases, and unanticipated coordination requirements.
The Hidden 70% Gap
In enterprise engagements, we have observed that code transformation represents approximately 30% of the modernization effort. The remaining 70% include things like test generation, validation, comprehensive documentation, business analysis, and organizational coordination across hundreds of moving pieces.
This gap explains why productivity gains from transformation tools rarely materialize. The tools handle code changes, but organizations still struggle with coordination, validation, and knowledge capture. The transformation is completed quickly, but the project takes months.
Here is what we see: traditional approaches fail at enterprise scale because they treat each repository as an independent challenge. Teams repeat work across codebases, make inconsistent decisions, and lose learnings when developers move to different projects. Organizational knowledge remains trapped in individual heads rather than becoming reusable assets.
A New Approach to Enterprise Modernization
AWS Transform custom takes a different approach to enterprise modernization. Rather than repeating the same operation hundreds of times, the service learns from every execution and applies that knowledge to improve future transformations.
The Learn-Scale-Improve Flywheel
The workflow follows a deliberate progression designed to maximize learning while minimizing risk. It begins with a focused learn pilot, scales through bulk automation, and improves through deliberate review, creating a flywheel where each cycle produces better results than the last (Figure 1).
Figure 1: Learn Scale and Improve Flywheel for AWS Transform custom transformation
Learn — You start with two to three representative repositories and execute transformations in interactive mode. You work directly with the AI agent, providing feedback on decisions and validating quality at each step. When the agent encounters ambiguity, it asks questions. You provide guidance, and the system captures that context. At the end of the pilot, you review the feedback and modify the transformation definition. The result is a transformation definition enhanced with your organizational knowledge, ready to scale.
Scale — You shift to non-interactive mode for bulk execution. The system processes dozens or hundreds of repositories overnight without manual intervention, applying patterns learned during the pilot. It validates transformations using your build and test commands and tracks progress across your portfolio in real time. What previously required weeks of team coordination happens overnight. During execution, the system captures observations: new edge cases, unexpected patterns, and optimization opportunities the pilot did not encounter.
Improve — After each round of bulk execution, you review the knowledge items the system captured during processing. These observations surface patterns and edge cases specific to repositories the pilot did not cover. You approve the valuable learnings, and your transformation definition improves for the next iteration. This review step ensures quality control. The system does not self-modify. Transformation owners decide which learnings get incorporated.
The Scale-Improve cycle repeats. Each round of bulk execution generates insights that make the next round more effective. Transformation success rates increase, manual intervention decreases, and edge case handling improves with every iteration.
This flywheel transforms how enterprises capture and share institutional knowledge. Transformation definitions are not automation scripts. They are organizational assets that encode how your company approaches specific modernization scenarios. When an architect defines a transformation strategy, that strategy becomes a reusable definition stored in your registry. When your team identifies best practices, those practices become embedded within the transformation definition and automatically apply across all repositories. Previously, when a senior developer left your team, that knowledge disappears with them. With AWS Transform custom, their expertise is captured in transformation definitions and knowledge items available to the entire organization. Individual expertise becomes an organizational capability.
An Enterprise Customer Modernization Case Study
These productivity gains are production outcomes, not theoretical projections. An enterprise software company needed to migrate a large volume of production-grade Control-M workflows to Apache Airflow, a modernization requiring both technical precision and consistency across a complex, interdependent codebase. Their estimate was 12 weeks of intensive coordination across multiple teams, with risk of inconsistency and integration failures.
Using AWS Transform custom, the company executed an iterative learn-scale-improve workflow. During the pilot phase, they ran interactive transformations on representative repositories, reviewed results, and refined transformation definitions. With each iteration, transformation definitions improved in edge case handling and accuracy. They then shifted to non-interactive bulk execution across their portfolio and completed the full migration in 2.5 weeks.
The validation achieved a 100% success rate across all workflows in scope. Edge case handling improved by 60% compared to the customer’s existing approach, and the transformed code demonstrated a 19% runtime performance improvement while meeting industry expert code quality standards. This proves that organizations can achieve both migration speed and production readiness, with 3-5x faster delivery timelines and 10-20x reduction in total effort hours compared to traditional approaches.
Get Started: Transform Your Repository Portfolio
AWS Transform custom bulk automation capabilities are available as a solution in this Github repo. Follow the learn-scale-improve workflow to begin your transformation journey.
Prerequisites
Before beginning, ensure you have:
An AWS account with AWS Transform custom access enabled
AWS CLI configured with appropriate credentials
Git installed on your local machine or CI/CD environment
IAM permissions for AWS Transform custom operations
AWS Transform custom integrates naturally into your existing development processes. The CLI connects with CI/CD pipelines like Jenkins, GitLab CI, or GitHub Actions. Transformations create code in local Git branches that flow through your standard code review and merge processes. The web interface provides centralized visibility for tracking progress across teams. Validation commands execute automatically during transformation, ensuring code builds successfully and tests pass before changes are considered complete. At the end of the transformation, if validation criteria fail, the transformation is marked as failed.
To accelerate your path to scaled execution, AWS provides an open-source sample repository that gives you a production-ready starting point for running transformations across multiple repositories and transformation definitions simultaneously. The aws-transform-custom-samples scaled execution repository includes scripts that orchestrate bulk execution, manage repository queuing, and handle status tracking across your portfolio. Rather than building orchestration from scratch, you clone the sample, configure it with your repository list and transformation definitions, and begin executing scaled transformations immediately.
Conclusion
Enterprise modernization at scale requires more than code transformation tools. The real challenges are coordination across teams, learning from execution, and capturing knowledge as organizational assets. AWS Transform custom learn-scale-improve workflow addresses these challenges through continual learning that improves quality with every execution, organizational knowledge capture that transforms tribal expertise into reusable assets, and bulk automation that scales consistently across hundreds of repositories. When the next critical security vulnerability requires framework updates across your repositories, or a new runtime version unlocks performance improvements, you respond in days rather than months — using transformation definitions you have already proven.
Real customers have reduced delivery timelines by 3-5x and total effort hours by 10-20x, compressing modernization from months to weeks. These are not aspirational goals. They are production results from organizations using AWS Transform custom today.
Begin Your Transformation Today
Follow the learn-scale-improve workflow on two to three representative repositories, refine your transformation definitions, then scale across your portfolio. To dive deeper into AWS Transform custom bulk automation capabilities, explore these resources:
AWS Transform custom Documentation — Technical documentation covering all capabilities, API references, and integration guides: AWS Transform custom
Scaled Execution Sample Repository — Open-source scripts for running transformations across multiple repositories and transformation definitions: aws-transform-custom-samples
Център-дясното демократично пространство в България е минало през много перипетии. След 2001 г. е в непрекъснат цикъл от роене и последващо коалиране. А и преди това също – СДС става единен субект едва 1997 г., преди това е коалиция. И даже има няколко СДС-та.
В България факторът „новост“ дава електорален бонус, което стимулира възникването на нови субекти в същото пространство. Дори често (макар и невинаги) те да са формирани от бивши членове на някой от предишните субекти. Но това е еднократен бонус, след което нещата се връщат към изходното положение.
И също така, поради естеството на избирателите – с ценностите на свободата и демокрацията – тези субекти винаги са били идеологически вдясно от центъра (дори да са го отричали в началото).
Само че ролята на партиите е те да са устойчив инструмент за политическо представителство. Да осигуряват кадрово допълване, еволюция на позиции, устойчивост на ценности и приемственост на знанията за политическата технология. За да не се открива топлата вода всеки път, за да има трайна кадрова банка от проверени хора, за се намали лутането по политическия спектър.
В единен субект, разбира се, винаги има течения, различни мнения и вътрешна демокрация; спорове сред политически ангажирани симпатизанти защо един не е депутат, а друг е, защо е гласувано по определен начин и т.н. – и това е нормално, когато субектът е формиран на база на общи демократични ценности.
Затова съм убеден в предложението ни от Да, България да начертаем пътна карта към единен политически субект – една партия, която да включва партиите от коалицията и партии извън нея. И това да е дългосрочна инвестиция в инструмент на тази политическа общност, който ще може да се разширява. Защото можеш да се разширяваш само ако изглеждаш устойчив и ако не си зает с „опазване на периметъра“.
Още по-важен е такъв знак на фона на идващите президентски избори, където за първи път от много време имаме шанс за силен резултат.
А моментът е подходящ и по друга причина – предстои ни вероятно дълъг период в опозиция, защото за да падне правителство, излъчено от абсолютно парламентарно мнозинство на един субект, трябва да се случи нещо много кардинално. И в този период има време за формиране и укрепване на единния субект, за да е в пълна готовност за следващи избори. Сега е моментът да се мисли и действа стратегически, с дълъг хоризонт, загърбвайки дребнотемията и тясно-партийното его.
Ще прозвучи нескромно, но това е един от най-подробните текстове за кафе култура в българското интернет пространство, а без нея личният ми кафеен архив някак няма да е пълен.
Ако не сте я чели досега, в статията разказвам за третата вълна (и за предходните две, разбира се) и как стигнахме до нея; какво означава специално кафе и какви са разликите и значението на индустриалното и занятчийското му печене. Опитах се да обясня и защо проследимостта на кафето (от фермата до чашата) е важно за неговото качество. И… още една купчина други полезни и (надявам се) интересни неща.
Даже успях да напъхам между другото и две интервюта с местни пекари.
Приятно четене (с чаша хубаво кафе в ръка)!
.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
