Hacker News Reader

The entire point of LTS is that things don't change. Security features are back ported, but you're on Node 0.10 because when 14.04 was released it included Node 0.10. You have an old version of youtube-dl because that's what was available at the time.

You use an LTS release when you want to do 'apt-get upgrade' and not change anything. No new features, no deprecated features, no changes other than back ported bug and security patches. No moving to a newer version of Apache which uses different modules by default, or a newer version of PHP which changes a critical default variable. It's always the same software, just fixed when it's broken.

If you're looking to keep your system up-to-date with the latest and greatest, then there are a few suggested solutions:

1. Install stuff yourself 2. Use a backports PPA or vendor packages 3. Use a more specific package manager (e.g. pip for python, cpan for perl, npm for node, etc) 4. Update your servers more than once every four years

If you want the latest version of software, you need to not use the LTS version, and you need to update to the newer releases as they're released, because the entire point of LTS is not to do the thing you're asking to do.

Also as follow on, you'll find that the packages that draw community support also tend to have PPAs (personal package archive), these are very easy to add to Ubuntu these days and typically backport more recent versions of software to older LTS (and sometimes non LTS) Ubuntu releases.

For example I use the nginx PPA on some of my older servers and it supports nginx 1.11 on Ubuntu 14.04 even thought 14.04.4 LTS only supports 1.4.6.

apt-add-repository is what you're looking for.

Every time someone suggests this it makes me a bit nervous because you're advocating I install binaries compiled by some random person and deploy them on all my production servers. If there were official backports of some sort from the python people for example, then yeah, but otherwise, nope nope nope.

The parent example was saying about official ppa only, official as in the original software company providing that ppa. In this case, nginx ppa is provided by nginx developers. Other example is postgres.

But I get it, there are not many ppa like that.

Just in case, there's Linuxbrew (http://linuxbrew.sh/), Homebrew for Linux.

While you're correct, it should be noted that "security backports" are much less complete than they'd have you think.

Do NOT take the promises of enterprise distributors for granted, both because there are a lot of security problems that never get fixed, and because the expertise to sufficiently backport is often lacking (cf. the Debian SSL entropy crisis of some years back).

You are usually better off using a newer upstream with the security fix integrated than relying on a distro-pushed backport. For a demonstration, try installing redis from the official Ubuntu repos.

For one thing: Non-LTS versions of Ubuntu have the same problem, just replace "24 months" with "6 months".

For another thing: LTS Ubuntu is the recommended version of Ubuntu: https://www.ubuntu.com/download/desktop

New users going into Ubuntu have no clue that going to ubuntu.com and clicking "Download" will give them an incredibly out-of-date OS.

> The entire point of LTS is that things _don't_ change.

That's not the root problem.

The root problem is that people want non-broken software, and updates sometimes break things.

LTS is one workaround, by committing to make as few updates as possible (mostly only high-impact security patches), you limit the likelihood that updates will break things.

But the problem is, not having updates also breaks things. `youtube-dl` is my usual example. Others include that having an old version of Node will break software that expects newer versions of Node.

The solution I'm proposing is to let the user choose whether or not they want up-to-date software on a case-by-case basis. I did not expect this to be so controversial.

> 1. Install stuff yourself

This is not a suggested solution, this is the problem we are trying to find solutions for.

> 2. Use a backports PPA or vendor packages

> 3. Use a more specific package manager (e.g. pip for python, cpan for perl, npm for node, etc)

These are workarounds that are MUCH less usable than just using the distro's built-in package manager. It is true that I can do this (mostly, I just build from source), but what I am asking is a way to make this easier, because it is a common problem that everyone has, and because it's the entire problem that a package manager is supposed to solve in the first place.

> 4. Update your servers more than once every four years

> If you want the latest version of software, you need to not use the LTS version, and you need to update to the newer releases as they're released, because the entire point of LTS is not to do the thing you're asking to do.

Sometimes, you want some of your software to change and other software not to change. The job of a computer is to do what the user wants it to do, is it not?

Like, if I'm using LTS, it's presumably because of something like "wifi works on this exact combination of system software and I don't want to risk it breaking with a random update". So the default would be to install software from a known working system. But I should be able to explicitly opt into installing other up-to-date software; keep my browser up-to-date and all that.

That's why I'm proposing a new command, so you can type in something like `apt-get install-latest youtube-dl` and get the latest version. `apt-get install` would still work the same as before.

Right, but the "new command" is "snap install ..." ;-)

Things are supposed to be stable if you're running an LTS, you savage! If you want everything bleeding edge, then use Arch Linux, not an Ubuntu LTS. Good god man.

Also I love the incredible specificity of your "ROLE/AFFILIATION". Top 2000, eh? Heh.

There needs to be a rational middle ground.

Arch is bleeding edge and has no qualms pushing updates that break things and telling you to fix it. That's fine for workstations (and I've used Arch as my workstation OS for over 10 years), but it doesn't work well for servers.

IMO, LTS should be transformed to a yearly release cycle with 2 years of support, not bi-annual with 5 years. This would fix a lot of problems, especially considering that distros can get frozen with versions of packages that are already pretty old when they go gold. Keeping support around for 5 years (which is basically a myth anyway) is just a big waste for everyone.

There is a rational middle ground -- Ubuntu's regular semi-annual releases.

If Ubuntu doesn't meet your needs, maybe try Centos + EPEL. You get a lot of stability with the option to install more recent versions of some packages.

Then again, you seem to be taking all this pretty personally, so my comments are probably wasted on you.

> and has no qualms pushing updates that break things and telling you to fix it.

I've been using Arch for 4 or 5 years and can only recall a couple instances where I needed to force-install a package to accomodate a backwards-incompatible change.

>There is a rational middle ground -- Ubuntu's regular semi-annual releases.

I'm aware of Ubuntu's normal releases. These aren't labeled enterprise-ready, so enterprises won't use them.

They also frequently contain experimental/unstable stuff, not because they need to, but because the LTS release cycle causes the release team to treat non-LTS releases like a beta.

>Then again, you seem to be taking all this pretty personally, so my comments are probably wasted on you.

I'm really not sure how you came away with the impression that I'm taking Ubuntu's release cycle as a personal affront. I'm not the top-2000 guy you initially replied to.

Rest assured, I do not believe that Canonical has selected its release process specifically to offend me. :)

>I've been using Arch for 4 or 5 years and can only recall a couple instances where I needed to force-install a package to accomodate a backwards-incompatible change.

Yeah, it's very rare to need to force install (has become more rare in recent years, but was still quite rare). When I say "break things", I don't mean you have to pass the force flag to the package manager.

I mean that configuration formats change, binary formats may change, a lot of system expectations may break that could take you offline for a while, even if you know how to fix them (for example, significant PostgreSQL updates require the data to be reimported to the new version).

Their transition to Python 3 as the default /usr/bin/python about 2 years before anyone else broke all kinds of stuff, for example. That's fine, you sign up for it when you use Arch. But that's not the kind of experience most people expect for a server distro.

Use Debian stretch

2 years support :-) That would be really nice for us (Canonical). But we just announced ESM (Extended Security Maintenance) for Ubuntu 12.04, which is just about to EOL after 5 years of support. There are still over 10 million Ubuntu 12.04 machines that install security updates every day!

I feel like it's very common to want some things to be stable and other things to be bleeding edge. Like, why are my only two choices "everything out of date" or "everything bleeding edge"? Why not make software for actual humans to use? I remember that being Ubuntu's motto.

Like, I presume it's pretty common for an actual human not to want their wifi to be bricked by an update. I presume it's also pretty common for an actual human to want a version of `youtube-dl` that works. It seems user-hostile to force a user to choose one or the other.

And before you say "but PPAs", PPAs are a workaround that have various flaws (you need to use google and copy/paste code, instead of just using your package manager as a package manager) (and they're only available for certain repositories) (and many of them are unofficial). Ubuntu/Debian already maintain up-to-date repositories, why not just allow users to selectively install software from them?

(I wasn't sure what to put for ROLE/AFFILIATION, honestly; I saw other people being vaguely specific and I tried to copy them)

In what way is Ubuntu not for humans to use?

I don't know what youtube-dl even is, why should your personal interest be the top priority of Ubuntu and when it doesn't work evidence that Ubuntu isn't fit for humans?

This is the exact problem snaps are supposed to solve. Check out Snapcraft.io

This.

My laptop is on Ubuntu 16.04. Via apt, I get libreoffice 5.1.6 from last october. Snap gives me 5.3.1, which is the newest one.

Snap is not there yet. Finding stuff is hard, because uApp Explorer [0] is not good enough yet. It suffers from trying to appeal to servers, desktop, mobile, and IoT (which probably just means Raspberry Pi). It is confusing and messy.

Edit: Since GP mentioned youtube-dl, specifically. A `snap find youtube` gives me three different variants:

youtube-dl-casept 2017.03.26 casept

youtube-dl-snap daily fireeye

youtube-dl-bdmurray 2016.10.16 bdmurray

The first one looks recent. Maybe the second one is even better? As I said, it is confusing so far. We have to figure out how to do curation well.

[0] https://uappexplorer.com/apps?type=snappy

Would be interesting if there's a way to list more information on the snap, such as submission date / last updated etc.

I guess if you want a bleeding edge experimental server, you might want to try Arch Linux. But you will have to tinker... a lot. It all comes as a trade off. You get the benefit of rolling release and AUR, you loose the stability.

Here's a balanced comment from the Arch wiki regarding Arch not being meant for the server:

https://wiki.archlinux.org/index.php/Server#Arch_Linux_as_a_...

"You may have seen the comments or claims: Arch Linux was never intended as a server operating system! This is correct: there is no server installation disc available, per se, such as those you may find for other distributions. This is because Arch Linux comes as a minimal (but solid) base system, with very few desktop or server features pre-installed. This does not mean Arch Linux is a bad server system; quite the contrary. Arch's core installation is a secure and capable foundation. Since only a small number of features come pre-installed, this core installation can easily be used as a basis for a Linux server. All the popular server software (Apache, MySQL/MariaDB, PHP, Samba, and plenty more) are available in the official repository, and even more are available on the AUR. The wiki also contains much detailed documentation regarding how to get set up with this software."

Also, because you mention youtube-dl. Here's the latest package version in the Arch repos (only a few days old =)

https://www.archlinux.org/packages/?sort=&q=youtube-dl&maint...

Ah this is a good idea, and one we're very specifically trying to solve. The way you're going to do this in Ubuntu will be with the "snap" packaging manager!

You can already use "snap install ..." to install hundreds of latest/greatest software packages, which evolve independently of the underlying OS. We're investing even more heavily here, so please do stay tuned, and try out snaps!

Use a rolling release distribution (like Arch or the more conservative OpenSuSE Tumbleweed) if you want the latest and greatest packages. The point of LTS releases in minimal breakage during uptates coupled with some two or more years of updates.

> (which installed Ubuntu 14.04 LTS), and `apt-get install nodejs` installed Node 0.10 (from 2013! in 2017!).

Not in 2017. In 2014. You're using Ubuntu 14, which means you get 2014 versions.

Even the latest versions of Ubuntu install Node 0.10. This is a known thing in the Node community which is why we use tj/n or NVM.

The "Node community" disagrees with the actual version numbers on the Ubuntu packages. The version numbers on the packages say that whilst Ubuntu 14.04 has nodejs version 0.10, both Ubuntu 16.04 and Ubuntu 16.10 have nodejs version 4.2.6.

* http://packages.ubuntu.com/trusty/nodejs

* http://packages.ubuntu.com/xenial/nodejs

* http://packages.ubuntu.com/yakkety/nodejs

* http://packages.ubuntu.com/zesty/nodejs

I very much agree. Apart from driver issues this is the area that creates the most friction for me. It feels weird having to fight the OS on something where the right thing to do seems so obvious.