When you live in the world of ever changing development tools and frameworks, disrupting technologies and freshly generated buzzwords it is tempting to look down at a stable Linux distribution as a static, boring thing, which you install and forget.
Hopefully you don’t forget it completely and at least try to be up to date with the latest updates. But let’s be honest, everyone working in this field has an example of a machine which worked long past the official End Of Life of its operating system.
And that’s OK. Many people can live a happy and exciting life without worrying too much about the depths of the Enterprise Linux-development.
Yet if you are in the business of long-term planning, in the business of development of services which are built to last and in the business of supporting environments too sensitive to change, you have to accept that the stable Linux distribution is a living thing. It has its own development, own lifecycle, its own dependencies and even its own stable branches. It also has some unique challenges people don’t meet while carelessly sliding on the surface.
Also I personally find it interesting and exciting too, but I don’t expect everyone to share the interest.
Anyways, whatever your reasons to come here, welcome on board, buckle up and let’s dive in.
As I am unable to write everything I want to write in one go, I am going to use this page to collect the notes which I (or maybe someone else too, send me links) have written on the topic. You can also send me (
@firstname.lastname@example.org) questions, opinions, corrections. And I will mention you in ~my will~ the credits of the book if I ever write it.
We will see how far it goes.
dist-git and exploded SRPMS – demystified SRPMs, exploded SRPMs and dist-git – what is it all about?
Continuity of Linux distributions I know people who imagine distribution development as the process of piling up the code in the git repository for 6 months and then building it all in one go at the end of those 6 months, so that it can finally be shipped. This is very far from reality. And it is impossible to explain things like CentOS Stream without addressing this confusion.
The Curse Of Bug To Bug Compatibility The chase for “bug-to-bug compatibility” hurts community, hurts RHEL customers and hurts the industry as a whole. The real innovation behind the CentOS Stream is the attempt to change it.
Links to externals sites
- https://dissociatedpress.net/2023/06/24/red-hat-and-the-clone-wars/ “Red Hat and the Clone Wars” – saga in many chapters. Not necessarily required for technical understanding, but provides historical context.
https://email@example.com/in-favor-of-centos-stream-e5a8a43bdcf8 On CentOS Stream vs minor releases of RHEL
https://firstname.lastname@example.org/if-you-dont-understand-its-purpose-you-can-t-improve-the-process-4e48260c3887 On CentOS Stream vs CentOS Linux