Canonical's official Ubuntu blog, with announcements on releases, security updates, snaps, minimal images and licensing positions.
HN links it for security updates and official statements, like the ZFS licensing post; commenters also question its claims, such as image sizes, and Ubuntu's long-term commitments.
When Simon Peter (the author) actually filed an issue for a GNOME change that he found unhelpful, and gave use-cases and invited people to give use-cases as to why the change needed reverting, the change was reverted: https://gitlab.gnome.org/GNOME/nautilus/issues/437
GNOME prefers that people hop onto their IRC (which is not logged so, unfortunately, people can't easily reference previous progress made) but filing GitLab issues also works. There's the gnome-design IRC for trying to create change to the Human Interface Guidelines. In the Nautilus IRC I suggested trying a GNOME Forum to try and collect design feedback better but they say they've tried this before and there weren't enough people willing to maintain it so the forum died. The problem is that GNOME devs get so much outright abuse for their design decisions that it's too unpleasant for them to engage with the community and, because their devs are nearly all volunteers (bar, like, two Red Hatters (one being the Files lead)), there's no-one paid to engage with the community like there is in, say, snapcraft (who have engaged with criticism very well in my opinion, even if they haven't outright capitulated to demand (which I think is a bad idea anyway since you then end up flip flopping constantly because the outrage is always against the status quo (KDE has this problem (https://mail.kde.org/pipermail/plasma-devel/2018-June/086117.html) also see Ubuntu - outrage against Unity 7 was cited in Shuttleworth's comments…
> Ubuntu which is only around 40mb […]
I just downloaded Ubuntu 18.04 and 19.04 and they are not 40MB:
$ docker image ls | grep ubuntu
ubuntu 19.04 f723e3b6f1bd 76.4MB
ubuntu 18.04 d131e0fa2585 102.0MB
ubuntu 16.04 a51debf7e1eb 116.0MB
How do you get a 40MB Ubuntu Docker image?
---
I followed @sofaofthedamned — https://blog.ubuntu.com/2018/07/09/minimal-ubuntu-released
But I’m still confused, where are they getting 29MB from? Even the compressed files are big:
Ubuntu Bionic [1]
- ubuntu-18.04-minimal-cloudimg-amd64-root.tar.xz | 77M
- ubuntu-18.04-minimal-cloudimg-amd64.img | 163M
- ubuntu-18.04-minimal-cloudimg-amd64.squashfs | 96M
Ubuntu Cosmic [2]
- ubuntu-18.10-minimal-cloudimg-amd64-root.tar.xz | 210M
- ubuntu-18.10-minimal-cloudimg-amd64.img | 295M
- ubuntu-18.10-minimal-cloudimg-amd64.squashfs | 229M
Ubuntu Disco [3]
- ubuntu-19.04-minimal-cloudimg-amd64-root.tar.xz | 69M
- ubuntu-19.04-minimal-cloudimg-amd64.img | 155M
- ubuntu-19.04-minimal-cloudimg-amd64.squashfs | 89M
[1] http://cloud-images.ubuntu.com/minimal/releases/bionic/release-20190425.1/
[2] http://cloud-images.ubuntu.com/minimal/releases/cosmic/release-20190419/
[3] http://cloud-images.ubuntu.com/minimal/releases/disco/release-20190417/
Ubuntu is my daily driver, but don't expect Ubuntu promoting something to mean they're sticking with it for the long haul. See Wayland[1], Unity[2], and NetworkManager (EDIT apparently still supported with Netplan). I once backported a bug in Ubuntu's version of a Torrent Client (Deluge), and got to inform the software's lead developer that Ubuntu had actually stopped using his software by default in the next release in favor of Transmission.
I've been using Ubuntu since 8.04, ran a LoCo team and even did some package maintenance, and I've watched Ubuntu embrace tech whole heartedly, and then drop it like a rock 2 releases later, over and over again. Ubuntu moves fast and breaks things, and them promoting something should not indicate to you that they'll promote it for the long term. Long Term Support does not mean long term new development, and LTS support does not mean helping to implement support in new major Kernel versions.
1. https://blog.ubuntu.com/2018/01/26/bionic-beaver-18-04-lts-to-use-xorg-by-default
2. https://arstechnica.com/information-technology/2018/05/ubuntu-18-04-the-return-of-a-familiar-interface-marks-the-best-ubuntu-in-years/
> Linux users should apply kernel and CPU microcode updates as soon as they are available from their distribution vendor, and follow any guidance to adjust system settings.
Canonical says that they have those for 14/16/18.04 [1]. But possibly more interesting is the fact that this disclosure has been so well synchronized. How do the relevant players decide what the threshold is for informing other tech companies? How does everyone know what policies that the constituent companies use to prevent early disclosure or unintended disclosure to 'somewhat-less-trusted-employees'? Is this all coordinated by US CERT?
[1] https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigate-new-microarchitectural-data-sampling-mds-vulnerabilities
Unfortunately by doing this they made another mess.
When they updated OpenJDK to 11 [1] they didn't realize that some things have been dropped from the core project, and others have moved; as a result (among other things) JavaFX is now broken in Ubuntu Bionic. [2]
I think this is something inexcusable for an LTS.
[1] https://blog.ubuntu.com/2019/04/19/announcing-openjdk-11-packages-in-ubuntu-18-04-lts
[2] https://bugs.launchpad.net/ubuntu/+source/openjfx/+bug/1825054
Commentary by Intel: https://software.intel.com/security-software-guidance/software-guidance/microarchitectural-data-sampling
Commentary by RedHat: https://www.redhat.com/en/blog/understanding-mds-vulnerability-what-it-why-it-works-and-how-mitigate-it (https://news.ycombinator.com/item?id=19912108)
Commentary by Ubuntu: https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigate-new-microarchitectural-data-sampling-mds-vulnerabilities