Q. How is Amazon Linux 2 different from its predecessors?

There are four major differences Amazon Linux 2 has from its predecessors:

    Amazon Linux 2 will offer long-term support.

    It is available as a VM image for on-premises development and testing.

    It includes systemd service and systems manager as opposed to System V init system and also includes new version of compiler and build tools.

    It provides the ability to install additional software packages through Extras mechanism without impacting the underlying LTS stability of the operating system.  

https://aws.amazon.com/amazon-linux-2/faqs/

Meta: Please don't indent to block quote. It is for code, and due to HN's design makes it unreadable on mobile.

Yeah, unfortunately see it done often too. Here's the text:

---

> Amazon Linux 2 will offer long-term support.

> It is available as a VM image for on-premises development and testing.

> It includes systemd service and systems manager as opposed to System V init system and also includes new version of compiler and build tools.

> It provides the ability to install additional software packages through Extras mechanism without impacting the underlying LTS stability of the operating system.

We are using Amazon Linux in my company, because it is part of the RPM based distributions that are "security approved" (we needed a recent officially built kernel). I always felt it was a weird monster, that works really well for containers, or applications that don't rely on lots of system libraries. You could quickly end up pulling some packages from both EPEL 6 and 7 (if you want clang for example)

I hope we can use the entire EPEL7 with this new version.

systemd support is a quite big news, I guess they're now based on Centos 7.

Someone already pointed out the differences? What kind of optimisations are done to qualify a new spinoff?

> I guess they're now based on Centos 7

If the quoted package versions are anything to go by, that is not the case.

Is Amazon's "Extras" something different than RHEL/CentOS's "Software Collections"? At first glance, they appear to be basically the same thing to me.

as an AWS noob, why would anyone use this over Centos or Ubuntu?

If you're running on AWS it's really nice to have everything preconfigured for things like logging to Cloudwatch, and not having to mess around with kernel optimisations.

Thanks for your answer.

However, they do have images with other distros also well preconfigured though don't they?

Yes they do.

Ubuntu considers AWS/GCP to be certified platforms so the server is fully tested on AWS as a hardware platform and there are specific kernel/toolchain/user-space optimisations done to make it run well [0].

The advantage of one of the existing distributions over Amazon Linux is that they are available and tested across multiple clouds, hardware platforms and range of software.

[0] https://www.ubuntu.com/cloud/public-cloud this page leads to various documentation on images, optimisations etc.

In theory, since the kernel is specifically tuned towards running on EC2 virtual machines (by the people who know EC2 virtual machines better than anyone) as opposed to 'generic' hardware, performance might be slightly better.

Also, and for many more importantly, it's probably easier to get support from Amazon if you're using their official Linux as opposed to a third party distribution.

Your first point is not true compared to Ubuntu at least [0]. AWS is basically are repackaged version of KVM (the last time I checked), so there's no particular advantage. Ubuntu (and I'm sure Centos/RHEL) provide custom images which have the same optimised code.

[0] I'm pretty sure it's true for CentOS / RHEL, I just don't know for a fact.

AWS is mostly Xen (they just introduced a KVM option https://aws.amazon.com/blogs/aws/now-available-compute-inten... ), and there are a few things like "enhanced networking" where you get a performance boost if you're on a kernel with support but it's still functional if you're on any other kernel.

Ubuntu has kernels specifically tuned for different cloud providers in LTS releases. For AWS, it's the linux-aws package.

What about the licensing terms of this OS, and the eventual blobs that can possibly come with it?

"It includes systemd service and systems manager as opposed to System V init system"

I'm off to rewrite/test/fix all ansible and puppet modules so they support FreeBSD. I had hoped AWS was smart enough to stay sober, but no. Too bad, I liked AWS Linux.

I don't know about you, but I like how systemd can restart my processes if they die. sysvinit is ancient; time to move on.

Systemd is a huge improvement for sure. There's some effort involved in understanding new things, and this is one which has ultimately made our lives much easier. I say this as someone who maintains the OS for a large AWS deployment and has made the effort the understand it rather than run away in irrational fear.

I've been managing all my application daemons with supervisord across systems for this reason - it's agnostic as to the underlying init system, can restart crashed daemons, and provides the same kind of "service up/down" functionality as sysv or systemd. Systemd can do quite a lot, but if you have to do any kind of orchestration across nonhomogenous machines, you can't necessarily count on it being in play.

The nice thing about systemd is that it works the same across various Linux distros (unlike even sysvinit!). So I've been solving this problem by pushing everyone to upgrade to a version that supports systemd. :-)

I would really like to see something UI-compatible with systemd that works on non-Linux, though.

Yeah ditto, avoided Amazon Linux for ages since I didn't want to replace my .service files with shell scripts, forever/monit etc, and logging to 'local4'.

Yes, pity. The lack of systemd is a major driver for use of Amazon Linux for us and our efforts to get away from Red Hat. We won't be adopting AL 2 because of this (not if I can help it anyway). I had actually thought that AL not adopting systemd was a sign of clue, but it seems it was just slowness. Let's hope they leave the original AL around long enough to find alternatives we can trust.

Systemd, for all its flaws, is vastly superior to sysvinit. Running from it is only delaying the inevitable.

Red Hat is not systemd. You'll find it in Ubuntu, Debian, SuSE, Arch, and RHEL/CentOS/Scientific.

Is this going to trickle down to Lambda? If so what's the implication there, anything interesting?