1. HEADLINE: A way to have different scaling for external monitors hooked up to my HiDPI laptop.

Currently I need can only set a single scaling factor, so I need to ajust my laptop screen resolution to match scaling of the external monitor. If that's not possible, a way to automatically set resolution and scale for both screens once you hook one up would already save me a lot of manual switching and restarting lightDM!

2. HEADLINE: "Native" multitouch gestures like 3-finger swipe to change workspace.

There are some programs that can do this already like xSwipe and Fusuma, but I expect this integrated with a nice and easy menu.

3. HEADLINE: Better battery management.

Battery performance under Ubuntu is often much worse in Ubuntu than Windows. TLP helps, but it's not enough.

Dev: Sure, here you go.

User: But why is it so small on my new shiny tablet high density screen?

Dev: (SHit it worked okay for me) Okay now it detects the density and scale..

User: But when I move the window to my old good lcd screen it becomes way too big!

Dev: Okay let's see if I can dynamically adapt to a new monitor density, it's just one scale factor.

User: But when I put it on my big tv flat screen it is too small!!

Dev: (Oh shit you gotta be kidding me, the pixels are actually a viewing distance relative unit??!)

DPI scaling between monitors work exactly as you'd expect. Windows stay the same size when moving between high-DPI and regular monitors.

These two problems are two of the biggest reasons I don't use Ubuntu (or any Linux) desktop (I use a macbook with a headless Ubuntu Server box and, when necessary, X11 forwarding over ssh).

I have to log out when I plug/unplug or the windows will end up blurry or the wrong size.

I know they have a bad track record of not listening, but I think things might be different now, they seem to be a bit more receptive to feedback, particularly with the beta updates.

Or maybe I'm remembering the prerelease "hai where r the bugz halp" back when Win10 was not yet RTM...

https://discussions.apple.com/thread/7583592?start=0&tstart=...

(Admittedly, "points" are still likely a good measurement for print. Perhaps one can work backwards and fudge point as a measure of angle if you consider 12 point font at a typical viewing distance.)

I assume the real hard piece is figuring out the distance the display is going to be viewed at. Some definite defaults exist (phones are typically about the same distance away, same with desktop monitors) but unique situations certainly can exist. (I'm also assuming that the monitor can report it's physical size and resolution; combined w/ viewing distance, it should be possible to calculate FoV.) If you did this, you should be able to mostly seemlessly split a window between two displays, and have it be equal "size" in the FoV. (of course, some displays have borders, so that fudges it a bit.)

That is a good starting point for calculating the default "optimal UI scaling", but there are going to be adjustments needed for the FoV of the whole screen area (not per pixel) too.

With large screens, for example 24-30" on your desk, just the per-pixel FoV measure will probably be good enough. You have plenty of "space" for windows and content, and want to get the optimal scaling.

But once you get to very small screens like phones, there is a tradeoff between keeping font and UI sizes comfortable, and being able to actually fit enough content on the screen without endless scrolling. I am willing to strain my eyes with smaller font sizes on my phone than on my laptop, just so that I can see more than 5 sentences of text at the same time.

    http://inamidst.com/stuff/notes/csspx

This is at the Operating System level, not like some random one-off application.

For me, the one feature I miss the most is a checkbox option for "Native Scrolling"; Did this really need to be removed?

And the vector-based competition to X (e.g. NeWS, Display Postscript) would have done better.

This would be awesome. Even when both the laptop and the external screen are 1080p, different scaling could be helpful if you want to use a dual monitor setup effectively.

Unfortunately, it's a tough nut to crack given current desktop behavior. For example, you can have a window that straddles both monitors. What should the scaling be? You need to switch at some point as you're moving a window back and forth - when? So it's a challenge, but solving it would be so worth it!

Plugging two 4K monitors into my laptop (which has a native 1080p display) is an awful experience when booted into Ubuntu. You either have to set the DPI to make the laptop display unusable or set it to make the 4K monitors look like $hit.

Plus... you know... games.

Multi-DPI is kind of a hack in general though and is likely to cause issues unless applications have been tested for it very thoroughly, it causes serious issues on major frameworks like Electron and Qt - though both of their support for it is improving slowly. If you want things to work smoothly for now, try to stick to 1 DPI setting.

It's not windows fault the apps don't take advantage of DPI. You can also disable dpi scaling for individual apps.

It's "not Windows fault", sure but it certainly makes it a worse experience than other platforms like OSX where multi-DPI is much more commonly supported.

I mean, I get it, same issue as Vista for Microsoft - people expect 100% backwards compatibility, but it turns out that terrible design decisions made many years ago tend to mean you need to break compatibility. Just like UAC, resolution scaling will be an issue that becomes less painful in Windows over time. Right now it's not great, however.

Just most apps chose to ignore it, the developers took the 'anyone uses 96 dpi anyway' attitude and at the end of 90's most applications started to suck at 120 dpi.

I guess people got lazy, as you say.

No point in spending time on logical pixels if it makes almost no relevant difference...

It's

http://i.imgur.com/o1S8ZUt.png

http://imgur.com/a/5378F

If you're making a decision about whether to make a purchase, don't make it unless you're prepared to do it all at once. Stick to ~100 DPI until you can make a commitment to go all at once.

That has not been my experience here at all. There is a rather active, and sometimes vocal, Windows fan base around here. Misconceptions about the current state of desktop Linux are commonly seen as it seems most people around here only use either Mac or Windows.

I mostly use mac at work, mostly windows at home, and a bit of linux for servers, and my htpc (most of my casual browsing at home)... Each experience is fairly different. And they all have pluses and minuses. That said, more often than not, I prefer the Windows UI desktop/menu, but osx & unity app integration and linux/bash shell environment. I wish that Ubuntu/unity would integrate more of the menu/taskbar features found in windows. (And bring back natural scrolling checkbox)

OS X, years ago when the first retina MBP was released, did everything right. It was seamless from monitor to monitor, scaling done well.

Windows 10, now: OK, ish. Most applications scale badly with blurry text because it's just literally scaling the image afterwards. Newer applications are fine. The actual scaling isn't great - having a window half on one monitor and half on the other leads it to 'picking one' and looking weird on the other.

KDE, now: Pretty good. Correct scaling once you set it up. The autodetection can be dodgy, and the DPI scaling for text isn't linked to the rendering scaling for windows, for some reason. The GUI still only gives you a single scaling option for all monitors, but the autodetection can do different for each monitor, and environment variables can be set to solve it manually. The actual scaling is perfect for the vast majority of things. Things scale correctly and no blurriness. The only application that doesn't handle scaling is Unity3D, so everything is tiny (no fallback to raw image scaling).

In general, it's what you'd expect for interace stuff across the platforms - Linux does it right, but the interfaces around it are bad, Windows does it fine for new stuff, old stuff (which is most stuff) sucks, but the interfaces are OK for doing it, and OS X gets it all right.

Edit: Just to be clear, it's only the Unity3D editor that doesn't do scaling, the actual games work fine, as you'd expect they just get the full space and the game chooses how to render to it. To be fair to Unity about the editor, they support scaling on OS X, and the Linux build is still a beta. It is annoying though.

https://blogs.msdn.microsoft.com/larryosterman/2005/12/15/vo...

    sudo apt install pavucontrol

It lets you configure some neat tricks. For example, you can setup an audio device that forwards to another computer running PulseAudio, an RTP receiver, and a few other similar protocols then set say, Spotify to output to that device. So if you have some network-enabled audio receiver somewhere in your house/office/whatever you can send audio from your Linux workstation to it.

You can of course also pass that audio through various filters/plugins to mess with the sound before it goes out to the remote receiver. For example, equalize it, noise removal, etc. PulseAudio supports LADSPA plugins so if you wanted to you could setup a little Raspberry Pi audio receiver at your front door and yell at solicitors in a robotic voice from your desktop. All with a bit of PulseAudio configuration fiddling =)

I remember trying it on whatever Windows computers were in the lab just to make sure I wasn't crazy and that this wasn't there all along, and sure enough, they kept the same volume no matter whether the headphones were plugged in or not.

One of the first PulseAudio victories I remember, at a time when I vaguely recall that it was a newcomer and people were really pissed at PulseAudio's bugs and recommending just straight ALSA instead.

[0] https://github.com/masmu/pulseaudio-dlna

Actually, this is especially true when both are 1080p, because laptop screens are never as big as desktop monitors, and we also tend to use them closer. I have this exact problem right now but I think I've just adjusted my eyes over time to squinting at 1080p at 14", or perhaps I turned on some display scaling and forgot about it.

> For example, you can have a window that straddles both monitors. What should the scaling be?

Intuitively, I feel like you should use the physical DPI of both screens to make sure that the window has the same physical dimensions on both. But that'd probably lead to weird scaling factors like 1.17 instead of nice round ones, and thus fuzzy scaling, so it probably couldn't quite work. I guess perhaps you'd just snap each display's DPI to the closest predefined value (eg. .25 increments which I think most systems use these days). Then you'd get a similar-sized part on both sides of the boundary.

But yeah, I think overall if you actually use physical DPI for scaling everything should work out close to nicely.

With "Displays have separate spaces" turned off (so windows can be present on more than one monitor at a time), it looks like windows take their DPI setting from whichever monitor the majority of the window is on-- with my current two-monitor setup, the DPI transition happens at the halfway point of a window, regardless of where the mouse is as I'm dragging.

Another approach would be to let the application render at higher DPI and the compositor would downsample the portion on the lower DPI display.

I even had to do this with Chrome [1]. It's crazy how obscure this was when I was setting things up. Other apps, like Gimp, still look like shit because I can't find a way to do the same thing; their GUI just rends at a tiny scale and is difficult to use.

[1] https://superuser.com/a/1120078/103402

Actually Linux/Xorg generally support this out of the box, it is just the higher-level software that would need to make use of it. You can try it youself:

xrandr --output <output-name> --scale 2x2

the result should be the given monitor will appear to have twice the resolution, so if applications believe they are running on a high-DPI display, they will look fine on the external monitor as well.

However due to lack of support and awareness in desktops doing just this might leave you with an unsatisfactory configuration, e.g. part of the desktop erroneously shown on both monitors - you might need to use further xrandr commands to setup the regions that each monitor displays.

I use the same approach to solve this issue on a Windows 7 system I am using, it is just slightly more involved (I need to setup a custom resolution in the Nvidia control panel).

So quality will be there.

For normal/low-DPI screens instead, you'd scale everything down, so you'd lose some memory CPU power, but you'd still get the quality result.

I have a Macbook Pro with retina and stopped using linux simply because I couldn't get a good resolution on my laptop and monitors. And then when traveling (flights etc), ubuntu chewed through battery probably 3 to 4x as fast as OSX so I wasn't good for that either. As a result, I have been on OSX for a couple years now but would love to be back on ubuntu some day.

Autdetection would Be nice, but just being able to set the scaling option in one place and having it apply not only to my desktop but the login manager as well would be very useful.

Also, afaik there is no documentation on changing the scaling factor in the login manager, or at least not in the official docs.

I would not buy a standard resolution monitor at this point, so having simple support for it in Linux is very important to me.

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 <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)

Including the ability to configure what gestures you want in a GUI interface!

- HEADLINE: Please, please, please fix space issues with /boot.

- DESCRIPTION:

I'm constantly running out of space in /boot, due to kernel updates. It drives me so incredibly batty. If I had to guess, this is due to poor defaults in the installer for folks that opt to encrypt their whole disk. Even still, this system was setup back on 14.04 (don't think it started on 12.04), and I have no intention of reinstalling from scratch just to fix it.

Publish something official on how to fix this problem! Make it easy and stress free! Yell at the people who didn't catch this bug before it went out! Sorry, but this is just a really bad problem: it leads to folks like me wasting time, and probably a whole bunch of other folks just not being able to install updates, and no idea why.

- ROLE/AFFILIATION: software developer in the federal government

The simplest fix would probably be to make /boot large enough by default (in the order of 10GB or 20GB or so -- the current size is 512MB IIRC).

A better fix would be to purge old unused kernels automatically but as far as I understand there were some difficult edge cases around that.

Sure, I'll just use 1/6th of SSD to store 60 megabytes.

  $ du -hs /boot/
  56M	/boot/

I don't know what planet you're living on but it's certainly not this one. Between a Ubuntu desktop, a laptop and personal server with multiple Ubuntu VM's on it, all of which are kept up rigorously to date, I fix this problem at least three times a year, every year.

The command line process to fix it[1] is a multi-stage mess of dense bash-foo that comes with a 140 word, two paragraph explanation so that /ubuntu veterans/ can figure out what is going on without resorting to scouring the man page for flags. The friendly GUI process to fix it relies on a third party tool that is no longer maintained[2].

It is not possible to explain to non-technical users what is happening here, which means the only thing they can do when they see this is call their technical friend and cry for help. This is exactly the kind of user experience that makes people think Linux is not ready for widespread desktop use.

This is definitely something the OS should take care of itself. I'm ignorant of the challenges that caused it to be this way in the first place, but in my ignorance I would advocate that:

a) the partition be made larger by default b) the OS auto-purge any kernel package more than three revisions old

[1] https://askubuntu.com/questions/89710/how-do-i-free-up-more-... [2] https://launchpad.net/ubuntu-tweak/

(warning, rant inside)

[0] https://gist.github.com/lloeki/520acee8ba3b44c532c7

IOW, it does automatically remove old kernels, it just keeps the last 2-3.

So, yes, run "apt-get autoremove", that's it.

I love having a terminal with bash and use it constantly, but I don't think it should be needed for the system to just go on working.

Which is not to say you're lying, I'm just sort of flabbergasted that this is an issue for so many people. Do you run autoremove much? Maybe that would solve it for you?

And I believe my boot partition is only 256MB, and I didn't set it to that. That was a system default.

Super common in enterprise deployments. I ran into this a bunch on my $EMPLOYER-issued workstation.

I understand that it may be wise to keep the old kernel around so the system can be booted in case there is a hardware incompatibility or breakage in the new release, but that justifies only one additional kernel. Ubuntu keeps those kernels sitting there until you `apt-get autoremove`, and that means that unless you're running that command routinely, the boot partition is going to fill up at some point, no matter how big you make it.

This is especially a problem for people who use the unattended-upgrades package. I've autoremoved and had it clean up almost a gig of old kernel images before.

The update process generates on the order of 100mb/month.

    > apt-get autoremove
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    The following packages will be REMOVED:
      linux-headers-3.19.0-79 linux-headers-3.19.0-79-generic
      linux-image-3.19.0-78-generic linux-image-3.19.0-79-generic
      linux-image-extra-3.19.0-78-generic linux-image-extra-3.19.0-79-generic
    0 upgraded, 0 newly installed, 24 to remove and 39 not upgraded.
    After this operation, 1,732 MB disk space will be freed.
    Do you want to continue? [Y/n]

Currently, Ubuntu installs a new kernel and update-notifier tells the user a reboot is needed. The autoremove notification only appears when using the terminal which explains why users are running into this issue. Also, update-notifier informs the user another reboot is needed after autoremove is run.

To avoid this mess I’ve commented out the lines of /etc/apt/apt.conf.d/99update-notifier and wrote my own updater using bash and zenity and incorporated needsrestart. It’s not pretty but it works.

For example I'm using LVM with my installation on my Ubuntu laptop and after updating the kernel and running "apt autoremove" it removed the LVM package leaving me scratching my head shortly on reboot as to why it wouldn't find my root filesystem (frankly i have no idea how it became "unneeded").

A more sensible approach is how Red Hat do it with YUM/DNF, that is, to allow a certain number of the same packages to be installed, "installonly_limit" in yum.conf. Doing this means that when a new kernel gets installed the oldest is removed to keep the the system at the limit specified.

On my RHEL/CentOS machines I tend to narrowly provision /boot to around 250-500MB. set "installonly_limit" to 2 and the system will keep the most recent kernel and one back. it works for me.

Of course it doesn't! Why would you assume such a silly thing? /s https://askubuntu.com/questions/563483/why-doesnt-apt-get-au...

Anyway sometimes one wants to keep old kernels. I have an old laptop that runs OK with a 3.something kernel and has wierd video sync problems with any newer ones. Ubuntu 16.04 keeps running with that old kernel so I keep booting from that, maybe once or twice per year.

However the proper solution would be pinning a package and autoremoving the others.

People who know they have broken kernels don't keep upgrading them, they stop and fix them.

People who don't know they have broken kernels also don't know they can boot with an older kernel, so they get nothing from the "backup".

We want to leave some time for people to realize their kernel is broken, so keeping three is probably just fine. Honestly, it would probably be adequate to just bump the oldest one off the queue whenever a newer one is requested. If you've got a tiny boot partition, maybe that means only two revisions. If you've got a huge boot partition it could be 20.

But just keeping them all and making people manually uninstall them gains you nothing, it's user-hostile for no reason.

Once you reboot/kexec into the N+1 kernel, it'll let you remove the N (now N-1) kernel, bringing you down to one. But at that point you've proven the new kernel works—at least well enough to get to a shell you can run apt autoremove from.

This is why autoremove isn't so auto: if it happened automatically after reboot, it might be running on a now-wedged system (e.g. one that can't bring up the display manager), removing the last-known-good kernel and leaving you with only the broken one.

I think the right middle-ground solution would just be for installing kernel updates to touch a file, and for Desktop Environments to notice that file and trigger a dialog prompt of "you've just rebooted into a new kernel. Everything good?"—where answering "yes" runs apt autoremove. On a wedged system, you can't answer the prompt, so the system won't drop the old kernel. (In other words, just copy the "your display settings were changed. Can you read this?" prompt. It's a great design!)

That way, you have kernel N running, first autoremove wipes kernels N-1 and older, then it installs kernel N+1, so that when you reboot into N+1, you'll always have known-good kernel N if it doesn't work.

It's a very similar solution to how a good programmer solves an off-by-one error, doing a shift/rotate shuffle on a for/while loop.

I agree that if the user manually runs an apt [dist-]upgrade—or really any manual apt command—that that's a good time to do apt maintenance work. (Homebrew does maintenance work whenever you invoke it and there haven't been any complaints so far.) But kernels usually get installed automatically, so it can't just run then.

Now, if there was a specific concept of a "last-known good kernel" (imagine, say, the grub package generating+installing a virtual package when you run grub-install, that depends on whatever kernel you specified as your recovery kernel, ensuring it remains around), then your approach could work—you'd always have two kernels, the LKG for a recovery boot, and the newest for a regular boot.

I'm running Ubuntu 16.10 currently. A kernel upgrade hosed my setup yesterday, and having an older kernel available saved my butt. I was able to do another `apt-get update` and things eventually worked with the latest kernel.

What? This is ridiculous and unacceptable. I don't use Ubuntu anymore, can someone tell me what is filling up the boot partition?

I'm currently on ArchLinux and mine is 200MB and it's 14% full! I can't fathom what could occupy so much space.

It can be manually fixed by removing older kernels ("sudo apt purge ...").

Perhaps I'm mistaken but i thought a fix was in place for this, maybe it was something third-party but apt definitely offered to remove unused kernel package for me recently.

http://manpages.ubuntu.com/manpages/xenial/man1/purge-old-ke...

Maybe add some stats to know which kernels have booted successfully, so one knows which old ones can be safely deleted, and keep the last 1 or 2 good ones (not always the latest!).

    The program 'purge-old-kernels' is currently not installed.
    You can install it by typing: apt install byobu

https://packages.debian.org/jessie/byobu "Using Byobu, you can quickly create and move between different windows over a single SSH connection or TTY terminal, split each of those windows into multiple panes, monitor dozens of important statistics about your system, detach and reattach to sessions later while your programs continue to run in the background."

Uhm... what?

It's completely wrong that purge-old-kernels is in Byobu, rather than in the kernel or directly handled by dpkg/apt. Thanks for all the feedback here -- we'll get that cleaned up in 17.10!

For `apt-get install purge-old-kernels` I get

    E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
    E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    E: Unable to locate package purge-old-kernels

EDIT: I straced bash by `strace -o bashlog -f -s 10000 bash` and found the culprit to be /usr/lib/command-not-found. Indeed, if you run `/usr/lib/command-not-found -- purge-old-kernels` directly, you get that same message about byobu.

EDIT2: I assumed this was some kind of bug with the database, but now I actually tried installing byobu and it does make purge-old-kernels available.

    E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
                                                                     ^^^^^^^^^^^^^

Regarding the second, which is instead the core of the problem, see the man page (http://manpages.ubuntu.com/manpages/xenial/man1/purge-old-ke...):

    Provided by: byobu_5.106-0ubuntu1_all bug

    sudo apt-get install byobu

You don't ned to use packages.debian.org to look up what packages do.

> apt show byobu .. Description: text window manager, shell multiplexer, integrated DevOps environment Byobu is Ubuntu's powerful text-based window manager, shell multiplexer, and integrated DevOps environment.

* http://packages.ubuntu.com/yakkety/all/byobu/filelist

(-:

But yes, you're very right. It needs to be moved out.

Only Ubuntu does that, other linux distributions don't have this problem.

I recently installed Ubuntu on some old computers for my relatives and they really like it. If they keep updating and after a couple of months their system fails to work that will be a disaster for any good will they will have developed for Ubuntu.

This needs to be fixed NOW! How can Ubuntu even pretend to be a viable desktop operating systems if normal updating renders the system unusable?!

echo $(dpkg --list | grep linux-image | awk '{ print $2 }' | sort | sed -n '/'`uname -r`'/q;p') $(dpkg --list | grep linux-headers | awk '{ print $2 }' | sort -n | sed -n '/'"$(uname -r | sed "s/\([0-9.-]*\)-\([^0-9]\+\)/\1/")"'/q;p') | xargs sudo apt-get -y purge

    sudo purge-old-kernels --keep 3 -qy

I eventually set up a cron script to regularly delete everything except the last 3 kernels. I think this should really be the default behavior. "Save all the old kernels until you run out of space and everything crashes" doesn't sound like a very sane default.

  $ apt-get dist-upgrade
  $ apt-get autoremove

As for the original issue of not cleaning up the kernels, this is fixed in xenial/16.04 but not in trusty/14.04, see bug report here: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bu...

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

https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1515513

dist-upgrade is NOT (in most cases) meant to upgrade to a newer distribution (eg. Ubuntu 14.04 to 16.04). dist-upgrade is just like upgrade except it also installs additional packages if necessary (eg. linux-kernel-4.1 AND linux-kernel-4.2).

Most people should always run "apt-get dist-upgrade" and never "apt-get upgrade" in order to simply keep their packages up-to-date.

An actual distribution upgrade is triggered by a different command. On Ubuntu: do-release-upgrade

This is a feature (kernel update) that is used by everyone, including newbs. They don't have to understand anything to enjoy the update, and they shouldn't have to understand anything to avoid the space filling issue.

Lots of ways to fix it, I don't claim to know which is best:

* Always leave N% /boot available, and delete or move old kernels to satisfy that.

* Move old kernels to /old_kernels, outside of /boot. Driven either by satisfying N% space, or no more than K number of kernels kept in /boot.

* Opt in, opt out, ask this on installation and for non-server installs, default to "never have to think about this again."

* Easily configurable in the "whatever that box was called when I last used Ubuntu years ago" box.

really, this is what your package manager should do automatically before/after installing new kernels

for your reference: http://askubuntu.com/questions/2793/how-do-i-remove-old-kern...

Just run "apt-get autoremove".

The relevant bug report is here: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bu...

Side note, give up on a separate /boot in future, not needed 99.9% of the time.

You could probably fix this on your system without installing from scratch, but it would take some careful planning (mostly wrt backups!). You'd need to boot from a recovery cd or such, copy /boot into /, edit /etc/fstab accordingly, and then follow the last few steps in the bug report above (from the chrooting onwards). I'd probably test this in a VM first.

I manually removed a bunch of old initrd images the other day.

http://askubuntu.com/questions/616512/purging-old-kernels-fa...

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

They've got a bug reported upstream. We need this fixed in Ubuntu

https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1515513

You can add yourself to the list of people affected to increase the Bug Heat and get this issue fixed.

  $ mountpoint /boot
  /boot is not a mountpoint

In theory, GRUB can load kernels off of a LUKS-encrypted partition, but in practice I've never managed to set that up without having two passphrase prompts, one from GRUB and one for mounting the root filesystem under Linux.

If people are encountering it on this wide a scale, it must be a truly severe problem (that's also probably causing many people who haven't learned about apt-get to give up on software updates entirely!).

https://gist.github.com/vzaliva/bee68ed709ddd2724791a56714ec...

This more than anything. I believe it is this issue (at least for me): https://bugs.launchpad.net/ubuntu/+source/unattended-upgrade...

Yes! Please!!

- HEADLINE: More stable dock/undock and sleep/wake handling.

- DESCRIPTION:

I've noticed that my system often hangs unrecoverably with a blank screen during dock/undock and sleep/wake events. I've learned, though, that I can reduce the likelihood of having problems by trying to minimize the number of state changes that the system has to handle at once. For example, if I'm leaving the house with the laptop, I'll first open the lid, wait 10 seconds to see if the display wants to turn on or not, undock it, wait 10 seconds for it to adjust, and only then put it to sleep. Same thing waking it up: one step at a time, with 10 second pauses in between. Seems to reduce my problems by about 90%. As a developer, this screams "race conditions" to me, but what do I know? If there's a bug filed for this already, I wouldn't know -- no idea what I'd search for.

I take the uptime game pretty seriously: having to reboot means that I lose a ton of context. Right now, I've got nine separate workspaces/desktops going, all with several browser, terminal, etc. windows. A reboot means I'll spend anywhere from 10 to 20 minutes installing updates and recovering all of that state. It's painful. Right now, my system has only been up for 9 days, which is weak sauce.

- ROLE/AFFILIATION: software developer in the federal government

My current xps 13 is the only one I've ever used where it works 100% reliably.

The only hardware related issue I've had has been static background noise from the headphone jack (which I also see on a clean install of windows), but I was able to get past that with the steps here:

https://wiki.archlinux.org/index.php/Dell_XPS_13_(9350)#Hiss...

When I was using he non-open-source drivers, Ctrl-Alt-F# to change virtual terminals would sometimes help. I would switch to a random virtual terminal and back and sometimes it would be working again.

And btw (should have mentioned this): ThinkPad W530 running nVidia drivers.

My ubuntu laptop has now became a stationary computer permanently stuck to the docking station and i never put it to sleep because I'm scared every time i unplug or plug in an external device. Anything from the most simple USB keyboard to ethernet, to VGA monitor, HDMI/DP/DVI monitors, USB3 docking station, close laptop lid, wake from sleep... EVERYTHING has a big chance that the hot plug will fail and you either have to reboot for the device to be detected or in worst case the OS just freezes.

This is a must fix for ubuntu to ever be viable as a desktop OS.

+1 for fixing this issue, just trying to work around it in the meantime.

Even though it doesn't take me much time to recover state its really annoying to know that I have to figure out all these issues anytime I start using a Linux laptop.