At this time you should not upgrade a production desktop from 14.04 to 16.04 | Hacker News Reader

At this time you should not upgrade a production desktop from 14.04 to 16.04

wiki.ubuntu.com

38 pointsiheredia24 comments

Why is this on Hacker news? Ubuntu 16.04 won't be released for another 16 days. Of course you shouldn't upgrade anything production to it!

https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule

I find the language "production desktop" a little interesting, as opposed to "production server". Is a production desktop the same thing as my dev box, which I use to develop and maintain production software?

Yes, and is just as critical as a server. When the server is down, you're losing money. When a dev is down, your company (or you) are losing $X/hr, based on your billable rate or fully loaded costs.

Yes it is.

Production Desktop Down = Company loses $X/hr in Dev salary until it is available again.

$X is generally $50-100/hr, more if you need someone in Ops to help you out.

I guess it is targeted more towards "normal" users, not hackers. Hacker probably can fix it, "normal" users - do not.

I've seen co-workers upgrade their production macbooks to beta/pre-release OSX versions, and then get upset when critical functionality breaks and its an ops "emergency" to get it fixed.

Their warning is appropriate.

People shouldn't upgrade to beta/pre-release software unless they are able and willing to fix it themselves. Too many devs don't know squat about installing operating systems or hardware.

I agree :)

The LTS to LTS upgrade path usually isn't enabled until a point release anyway. For example, the the 12.04 to 14.04 upgrade wasn't enabled in the software update application until 14.04.1 was released a month or two after the initial 14.04 release.

Whole lot of noise in that bug report - they finally managed to narrow it down and fix the issue: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1555237/...

Yay, more systemd-related breakage in a core system component. (udev is developed as part of systemd now and the developers don't particularly care what happens when you run it on anything else. It's also the standard way of creating device nodes on Linux and the only one the kernel developers are willing to support.)

Largely thanks to the people involved developed both udev and the kernel interfaces in lock step.

And who are those people? GregKH and Sievers. I really do wonder why Torvalds still trust GregKH with anything kernel related.

http://www.landley.net/notes-2015.html#05-07-2015

What is a "production desktop" ? I've never heard that term in over 20 years of IT work.

I agree it seems a little silly, but to me any system can qualify as "production" if you are responsible for maintaining it within some expectation of reliability. So for example a "production server" is a server that your customers expect to be reliable and stable. A "production desktop" could exist within an IT environment, for example at a company that provides Ubuntu workstations to its employees. If the sysadmin upgrades machines to 16.04, then they break, employees will be pissed.

Interestingly, there's a still open upgrade bug from Debian 7 (with systemd) to Debian 8 which hangs the upgrade process, that similarly involves udev update.

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774153

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737825

More worrying than this to me is that they're removing the fglrx driver. I'd love to use the open source drivers, but the radeon and amdgpu drivers do not seem to be getting equal amounts of love and amdgpu only applies to really new video cards.

My understanding is that it's not that they want to as such, but that their hand has been forced on the issue, especially given that this is an LTS release, and they've been supporting fglrx a lot longer than many other distros. The fglrx driver is so horribly ancient that there's really no sensible way of supporting it.

Apparently, there'll be a more suitable driver coming out of AMD some time this summer.

The irony is that the machine I need it on is only a couple of years old and has a pitcairn chipset, but something about the way it's set up just does not play nice with the radeon driver and it crashes constantly. fglrx works fine, though.

Do you have a link regarding this other new driver from AMD, btw?

Would it be correct in saying that flgrx is still available, but it's not in the base distribution, and that it's been replaced in the distro by another package?

In other words is it up to the user to install the desired graphics driver that they want? For example, the ones from AMD/ATIs site?

Xorg 1.18, which is what 16.04 is shipping with, doesn't support fglrx, which is why Canonical can't continue to support it.

And that is just too bad since the radeon driver couldn't detect the Ratio of my monitor with a VGA -> DVI adapter (yes the monitor is ancient 720p only)

No. fglrx does not work with the latest version of X.org that 16.04 ships.

I tried the 16.04 cloud image today on kvm. I'm stuck at btrfs loading... Release date is in less than a month I expected the os to boot at least ! Definetely not production ready...

Ran into this myself. Lack of ability to access the tty's greatly reduced my ability to even debug the situation further. I just moved to CentOS.

Reply on news.ycombinator.com