[–] sciurus link

I think in this context by "stability" they mean "not rebooting"

https://www.ubuntu.com/server/livepatch is a commercial service that can apply security patches to a running kernel.

reply

[–] nathan_f77 link

Oh, you're right. Whoops, should have paid more attention!

reply

[–] alexchamberlain link

I think this could have been communicated slightly better; I'm sure if you rebuild your VM regularly, you'll get all the same patches.

reply

[–] IceyEC link

Or even doing a reboot after an `apt update` that comes with a kernel update. The livepatch bit only updates the running kernel anyway

reply

[–] undefined link
[deleted]

reply

[–] nathan_f77 link

> If, for now, you prefer stability over speed, you can get still get going with Livepatch by reverting to the old kernel,

Ha, that's not the most inspirational ending.

I would have hoped that stability doesn't even need to be mentioned, considering that this is now one of the default images on AWS. I don't think anyone would choose this kernel if they thought there might be a higher chance of it crashing and taking down their server.

reply

[–] xemdetia link

I wish they did a better job describing where their gains were. I tried to pull something interesting out of the changelog but it wasn't obvious.

reply

[–] zx2c4 link

    * Disabled CONFIG_NO_HZ_FULL to eliminate deadlocks
      on some instance types
That... sounds like a bad bug?

reply

[–] xmichael99 link

Had a similar conversation about that just yesterday. Our company is using 12.04 and I was nearly floored to see it is soon entering end of life... A quick test of 16.04 says, wow it is not going to be fun for us to upgrade...

reply

[–] softwarelimits link

One of the most valuable aspects of Debian was (and hopefully is and will always be) the fact that a release upgrade was always possible and (at least for me) never caused any problems (rtm of course).

The idea of "LTS" is a stupid reversion of something better we already had - the idea that upgrades are always reliable.

Saying "LTS" for me sounds like "we have lost control over the upgrade process."

Of course I must add that updating from Ubuntu 14.04 to 16.04 went ok on all machines I have seen (servers and also desktop workstations) - this should not be surprising, but the expected default, then we do not need no "LTS" theater.

reply

[–] mattbillenstein link

LTS is a guideline about extended support, extended beta cycles, and less potentially breaking changes vs the non-LTS releases. I don't see it as saying much of anything about the upgrade path, but rather that if you do an apt-get update on an existing LTS box, you can expect to not get major version bumps of tools and libraries and thus less breakage. Of course, you don't get the latest and greatest software, but for most server deployments, that's a desired compromise.

And at least I never do an upgrade anyway -- I always do a fresh install from one LTS to the next one on bare metal -- and simply recycle VMs in the cloud.

reply

[–] merlincorey link

One of the major issues with current transitions is apache 2.2 to 2.4+ and other such large gaps that unfortunately will require manual configuration changes. There are many such instances of these gaps depending on where you are coming from and going to.

reply

[–] sciurus link

LTS is not about how reliable the upgrade from one version of the distribution to another is. It's about how long security and bug fixes will be provided for a version of the distribution.

An Ubuntu LTS gets updates for 60 months. A non-LTS release gets updates for 9 months.

reply

[–] MikeKusold link

You may want to investigate CentOS. They offer 10 year LTS releases.

reply

[–] yo-code-sucks link

Because being lazy solves everything.

reply

[–] mattbillenstein link

I went through all the 2-year releases since 10.04 and if you go through it for every release it's a fairly small incremental change for the most part.

That being said, systemd is a larger change, but I just use a single script to start supervisord, then run all my stuff under that anyway.

reply

[–] aidos link

Oh really — what sort of things have you run into? I'll look at upgrading soon and I'm hoping 14.04 to 16.04 won't be too bad.

reply

[–] sgs1370 link

We're moving from 14.04 to 16.04 and are about done with our migration development - the biggest difference I saw was systemd by default, although for the simple things we do with startup weren't too hard to migrate over. The other only other thing that impacted us was some changes in how the apt and puppet versions that are included by default act, a few things were either more strict or the (previously deprecated) things had actually been removed.

reply

[–] yeukhon link

Python 2 is not there. If you run on AWS, either have a task to download and install Python 2, or in your EC2's user data to install Python 2 (this is necessary for Ansible users).

reply

[–] pekk link

Ironic since Ansible's lack of Python 3 support was due to vociferous insistence by key Ansible developers that it would be wrong even to allow the use of Ansible with Python 3 as long as popular CentOS versions did not have it.

reply

[–] collinmanderson link

I think the bigger reason was Ansible needed to support Python 2.4 and 2.5 for old CentOS versions, making simultaneous Python 3 support very hard. They've now dropped 2.4 and 2.5, thus allowing Python 3 compatibility.

https://github.com/ansible/ansible/pull/22721/files

(Though, it's worth noting that CentOS still does not have Python 3 support out of the box.)

reply

[–] yeukhon link

I have to read it backward. Ansible is now part of RedHat. CentOS doesn't have Python 3, and some key Ansible developers have strong opinion on Ansible not supporting Python 3 in the near future. Am I reading it right?

reply

[–] deckiedan link

Ansible has preliminary py3 support now. It works well enough for me on Ubuntu 16, only py3 installed.

reply

[–] yeukhon link

Which version?

reply

[–] dxhdr link

Upstart is gone and systemd is here instead. It's a huge change.

reply

[–] jamoes link

You can always switch back to upstart if you rely on it. It's a simple process: https://wiki.ubuntu.com/SystemdForUpstartUsers

reply

[–] undefined link
[deleted]

reply

[–] anonbanker link

Thank you for this.

reply

[–] brightball link

I still have a server running Hardy Heron somewhere

reply

[–] aidos link

Cool — now to finally get around to moving to 16.04 :-)

Each time I look at what the last stable Ubuntu release is, I feel like the years are rushing by too fast. I slowly drift further and further behind schedule, though it still doesn't seem a minute since 10.04 came out!

reply

[–] m23khan link

Hi Bashtoni, will this CentOS AMI be your fork (as an individual contributor) or will this be the official CentOS AMI on AWS Marketplace?

reply

[–] bashtoni link

If you prefer RedHat, I've been releasing CentOS images with similar tunning for some time: https://www.bashton.com/blog/2017/centos-7.3-ami/

reply

[–] fred256 link

Not sure. Perhaps it might be a reference to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518457 which caused 100% CPU usage (and thus throttling) on t2 instances in some cases.

reply

[–] mattbillenstein link

Disabling hotadd also fixes I/O errors on nvme disks on the new i3 instances which is mentioned here as well.

reply

[–] yeasayer link

> Resolved CPU throttling with AWS t2.micro instances

What does it mean? I know that all t2.micro instances are CPU throttled (credits system)

reply

[–] adenot link

How does it compare with Amazon Linux? Does it already have the improvements added now to Ubuntu?

reply

[–] phonon link

I assume ENA support relies on this new driver. [1]

Ubuntu 16.04 already supports the ixgbevf driver, I believe. [2]

[1] https://github.com/amzn/amzn-drivers/tree/master/kernel/linu...

[2] https://bugs.launchpad.net/intel/+bug/1536473

reply

[–] KAdot link

The latest Amazon Ubuntu 16.04 AMI comes with ixgbevf version 2.12.1-k, while the Enhanced Networking documentation [1] suggests installing version 2.16.4.

[1] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sriov-net...

reply

[–] TheGuyWhoCodes link

The built in support for ENA is nice but what about the other instances such as C3, C4, D2, I2, R3, and M4 (excluding m4.16xlarge) where you have EN using Intel 82599 Virtual Function interface? Why not support it out of the box?

reply

[–] buzzdenver link

I'm not seeing any speed increase when using an ENA vs non-ENA ami as seen by iperf. ami-80861296 vs ami-2757f631; tested transfer between pairs of m4.large and m4.xl VM-s.

reply

[–] gleenn link

Looks like it's enabled by default on a lot of their images now

reply

[–] jamesblonde link

Nothing about enhanched networking and configuration for 10Gb nets? I had to setup all this (jumbo frames, etc) - felt like a waste of time.

reply

[–] m23khan link

this is great news!! Along with CentOS, I find it a joy working with Ubuntu servers when it comes to administration.

I wish SUSE (SLES) also had a smoother / stable performance on AWS (e.g. recurring issues with their susecloud on aws repo).

reply

[–] ty_a link

Not an automatic update but it is in the standard repo as linux-image-aws. But new AMIs come with the AWS kernel by default.

reply

[–] mercora link

But only in xenial repositories for whatever reasons.

reply

[–] exabrial link

Will this be an automatic update through normal apt-get?

reply