Ask HN: What do you want to see in Ubuntu 17.10?

I'm mostly replying at the point 1., as it's closed to what I do...

I know we should offer an UI for that, but waiting for that you can just workaround this.

Well, as said unity supports scaling, although it's not possible to scale toolkits per monitor.

However... There's actually a good workaround for this, that works fine for multiple monitors.

The idea is that you scale everything up to 2x / or your maximum scaling (including window contents), then you scale the non-HiDPI monitors down using xrandr --scale

For example, if you want to use normal resolution there, you just have to do something like:

xrandr --output --scale 2x2

In this way it will be scaled down, and everything will be readable and almost 1x1.

You can test this in normal resolution monitor as well, and you'll see things should be pretty good.

I should find some time to implement this directly inside UCC / USD, so that users will get this for free...

Notice that there's also a bug in X causing some mouse trapping, so you'd probably also need X to be patched as explained in this bug: https://pad.lv/1580123 (we'd like to include this upstream, but we're waiting for X upstream approval for that)

- HEADLINE: Better handling of apt and dpkg locks during apt-get upgrade/update

- ROLE/AFFILIATION: Cloud hosting provider

- DESCRIPTION: Thanks for taking our feedback! I work in cloud services and deal with many Ubuntu 16.xx users of various skill levels. One of the most common issues that I see are folks reporting that the "apt-get update && apt-get upgrade" commands fail on newly deployed cloud servers. I wouldn't really classify this as a bug, but some internal changes to the apt/apt-get commands could make things a lot smoother. Here's what happens.

1. Cloud service providers periodically make a disk image of Ubuntu 16 with the latest packages an updates. 2. These images are used for several weeks (or sometimes even longer). 3. When customers deploy a new Ubuntu cloud server, the disk image is copied to a new machine. 4. The machine boots. Ubuntu realizes that it hasn't been booted for a while and performs some internal tasks. IIRC this is related to the "apt daily updates" service. This is the thread I always seem to reference ( http://unix.stackexchange.com/questions/315502/how-to-disabl... ). The apt tasks run, which can take serveral minutes. 5. Asynchronously, the cloud service reports that the server is ready. 6. The customer (or their scripts) will login and do some provisioning. A common first provisioning step is to do a package update: "apt-get update && apt-get upgrade". These may fail if the "apt daily updates" task is still running. I've seen a variety of errors, but usually look like this:

> E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable) > E: Unable to lock directory /var/lib/apt/lists/

When running "apt-get update" during this state, it sleeps for a few moments, then reports an apt/dpkg lock error. Since most of the time this whole process happens autonomously, it seems like making "apt-get update" and "apt-get upgrade" block until a lock is available would be quite beneficial. Documentation on the web for upgrading ubuntu usually references these two commands, so I don't think adding new parameters would be that beneficial; changing the default behavior would be better.

In the meantime, perhaps you'll find the list of hardware certified to work with Ubuntu useful: https://certification.ubuntu.com/

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!