I can add a bit on why people end up picking Amazon Linux, and where these reasons conflict with Fedora….
On May 15, 2023, at 10:29 AM, Major Hayden major@mhtx.net wrote:
While mowing the yard last weekend, something came to mind about Fedora on clouds. We spend a lot of time thinking about getting Fedora onto more clouds and making it more interoperable with cloud APIs. Increasing Fedora's usage by making it available in more clouds seems like a worthwhile goal.
One thing we ask ourselves when looking at possible changes to Amazon Linux (including the “base it on Fedora” one) is “How would this benefit our customers?”
It’s a good thing to think about - *why* do we want to increase Fedora usage if not for solving problems for those who end up using Fedora?
However, I wonder why people choose to use Fedora versus an alternative when they deploy in public clouds. These questions came to mind:
- Is there something lacking in the Fedora experience?
We do hear from a lot of Amazon Linux customers that the Long Term Support is important to them. This is, of course, something lacking in the Fedora experience. Perhaps it always should? It can be in direct conflict with the idea of being first, and is certainly a hefty investment.
For the Fedora experience on AWS, there are a few more AWS agents and SDKs packaged in Amazon Linux than Fedora. This is on us (AWS) to fix, and ensure that software we vend is easy to package for linux distributions and can thus easily get into the hands of all EC2 linux users. We over in the Amazon Linux space are quite motivated to make that happen as it means there’s lots of time for the teams working on the upstream software in these packages to ensure they adapt to the changes in the Free Software ecosystem that will make their way into a future AL version. So us, as users of Fedora to make a downstream Linux distribution, get incredible value from Fedora being First.
Other things we hear a lot of is a desire for a choice on language runtimes and major leaf packages. While everyone WISHES they could get rid of older python versions, older php, older MariaDB, PostgreSQL etc, having a choice and a grace period is seen as a feature. For some packages in Fedora, they get this already.
Launch times is another one. When customers in a cloud need to scale up, they want to launch new capacity FAST. There’s a few tricks we have in AL that should make their way upstream :)
There’s also the security footprint - which comes down to the minimal number of packages that are on a base image (AMI or container). Fedora packages do tend to enable a lot of options and functionality, and this makes the base package set fairly large. For AL2023 we were able to tweak (or add) a whole lot of bconds to help bring this down dramatically, and we were looking heavily at “what could we do to alter the default images so that customers would have fewer patching runs required”.
- Is Fedora more difficult to use or does it have limitations that frustrate users?
We have found that ease of use in a cloud isn’t exactly what you’d expect when thinking of ease of use for a more traditional server or desktop OS.
One thing we have ensured we started doing was releasing a new AMI for any security updates. A lot of customers just want to patch with instance replacement, and use the “there’s a new AMI available” as that trigger. It also means that container builds get kicked off, as the base layer changes. Running arbitrary “dnf update” on launch or in container recipes tends to lead to sadness.
Another one is information on what is fixed where, and having accurate and up to date security patching information. This is, of course, a lot of work.
- Are we missing docs and blog posts that help users deploy their favorite applications on Fedora?
One thing I’ve been thinking of as lacking is good guidance for ISVs packaging software. They may need to bundle dependencies and other such things, may even not be open source, but we still want them to be good citizens in the ecosystem and help there not be needless complications.