Amazon Linux 2023 virtual machine images still MIA

When Amazon Linux 2023 was released on March 15, it was supposed to be offered as a virtual machine image that organizations could run on their own servers. "When Amazon Linux 2023 becomes generally available, it will be provided as a virtual machine image for on-premises use, enabling you to easily develop, test, and certify …

[Inventor of the Marmite Laser]

For the five hundredth time today, there's no demand.

[FIA]

There's a couple of github tickets asking for it, and it not being released seems to be newsworthy. That sounds like at least some demand??

In leu of any more sensible comments I'm going to tinfoil that they've accidentally realised some secret sauce would be GPLd if they did.

(In reality someone maybe enabling 'hybrid cloud' approaches wasn't in their best business interests).

[Mike Pellatt]

If they had any long-term strategic thinking, they'd realise that enabling hybrid-cloud was exactly what was in their best business interests.

[abend0c4]

That sounds like at least some demand

You perhaps need to reflect further on the internal contradiction in the OP's comment.

[Mike Pellatt]

Ah yes, the amusement we had back in the day when all our local had was Courage keg beers, like "Best"

"Pint of Directors please"

"We don't stock that, there's no demand"

rinse & repeat every time we went there.

One of the reasons we only went there on a Sunday evening.

[F. Frederick Skitty]

Why not just use Debian? I don't understand what Amazon's proprietary version of a Linux distro adds that makes it so appealing. And yes, I do run systems in EC2, so this isn't a comment made out of ignorance of AWS.

[sten2012]

I've seen critical vulns that have taken Debian multiple weeks to patch into widely used daemons in Stable that Red Hat turned around immediately. So I see why enterprises are reluctant, at least it's why I would be.

No idea how Amazon Linux did in terms of time but if you're asking why enterprise users are reluctant then that might be one such reason.

If you're asking why Amazon engineers are making a proprietary Linux rather than contributing to Debian then sorry. I'm not sure

[F. Frederick Skitty]

The academic studies I've seen, based on time to release a fix after the announcement of a CVE, show RedHat as far slower to patch Enterprise Linux than Debian patching Stable (approximately 10% slower in terms of number of days). Patches to Fedora are generally slower than Debian Testing, although much closer (approximately 3% slower in terms of number of days).

I guess management like having someone they can theoretically blame if they get compromised, but 1) they need to check the terms of their contract with RedHat/IBM, and 2) are they really going to take on RedHat/IBM for legal recourse?

[sten2012]

Thanks for this. My example was purely and only anecdotal but the only experience I have. If there's been studies I'd be keen to get any names or papers. I'm glad my experience was an outlier.

Edit: also I wouldn't notice when it's faster. My only time pay attention is the occasion when I'm falling behind - so when Debian patches first it's not something I'd notice or worry about. When I start getting flagged for vulns and have no route to patch - then I'm paying attention.

[emfiliane]

Originally the idea was that Amazon Linux was going to be the most tightly integrated with AWS features across the board, needing less configuration and being easier to deploy for various tasks.

It ended up being just a very badly maintained fork of RHEL that was always way out of date, and constant broken promises about what would be added or when updates would be released. Despite that it probably sucked even more life out of RHEL, since Amazon has usurped Microsoft's crown of embrace, extend, extinguish.

I regret ever trying to make use of it, as the main thing it led to was hours of googling how to work around its idiosyncratic limitations that other distros didn't have.

[sten2012]

> "The fact that it doesn't (for instance) work with upstream RHEL/CentOS repositories like EPEL is really what dooms it, because who the hell wants to sit around building RPMs in the year of our lord 2023?"

A while back I'd have called that a disadvantage too but not any more. Anything that creates or even appearing to be a dependency on RHEL upstreams for functionality is now a reason to avoid. Binary compatible with an upstream I can't rely on unless I'm a RHEL customer - and then I might as well just use RHEL.

OK EPEL isn't quite the same thing but may succumb to the same fate as CentOS and at this point in my view all benefits of ABI compatibility are already gone.

[simpfeld]

This is the most ignored thing with the RHEL debacle, EPEL (and other 3rd party repos e.g. rpmfusion) are largely virtually essential for making RHEL useful in a general sense. RH kicking this wasps of this ecosystem (which mostly built these repos) will make RHEL much less useful.

[Henry Wertz 1]

odd

odd, given that presumably they already have an image to deploy on ec2 itself, and people expecting it to run on site are probably using software that provides an ec2 style deployment environment.