A Proposal To Update Ubuntu's Kernel/Mesa/GNOME Components On A Monthly Basis

[theghost]

In the end, there should only be two releases considering how fast things move these days like Mesa. Remove the naming (like artful) and version numbers and just have:

- Ubuntu (monthly releases until the end of time)
- Ubuntu LTS (snapshots that are updated every 2 years)

The LTS version is updated more frequently and not only every 2 years, for a good reason...

https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack

And not only the Kernel is updated.
You cannot simply create a snapshot for LTS and don't update it for 2 years.

Given that it's the question whether monthly releases are useful or whether they produce more overhead than a 6-month release.

I think the real problem for most users isn't the rolling update factor for Ubuntu but more the non-update factor.
I am not sure if the latter is caused by relying on Debian.
The greatest problem is that Ubuntu creates a snapshot of kernel and userspace at a certain date and takes this as base for the next release.
But even though minor bugfix updates are released within the window of snapshot date and release date of the snapshot, they are not contained within the release.
Same goes for updates after release date.
Here are some examples for Ubuntu's latest release (17.10):

- Kernel version today is 4.13.0-16 (whatever this strange version system is, I guess and hope it's 4.13.16) --> Upstream: EOL (not maintained anymore by upstream) --> so bad choice of kernel version for a release

- Mesa 17.2.2 is in 17.10 --> Upstream: 17.2.8 (!) so Ubuntu missed 6 (!) releases of bugfixes for graphics.

You can complete the list on your own.

We even have a great use-case why this policy is bad. Ubuntu uses an outdated Kernel, forgot to backport important patches for intel-spi and activated a kernel module despite the warning, with the result that a lot of notebooks were bricked.

[theghost]

Yet another possible solution : try experimenting with openSuSE Tumbleweed.
- It's also a rolling distro (hence the name) just like Debian Testing, Arch, Gentoo, etc.
- In my experience, it's better curated than Gentoo and Arch, a lot less breakage when new versions arrive (but that means that the arrival of new kernels will lag a tiny bit behind the upstream vanilla. Still a couple of weeks later, you should get it into your installation.)
- It has a good ecosystem of third party repositories ("open build system", similar to Ubuntu's PPA, Fedora's COPR), very well integrated into an automatic build system ("open build system", much better than Fedora's Koji).



For the record, that's not as difficult as it sounds.
(Hint: start by importing your current settings from " /proc/config,gz ", so you more or less have the same configuration in your new kernel as in the older).




That's why I've settled for a rolling distro that is a tad bit less aggressive than Gentoo / Arch.

OpenSUSE's model seems the best one, in the long run.
Instead of releying solely on user testing, they set on OpenQA.
This might take some time to set up test cases but they worth it with every release of new components.

[xcom]

Windows style update doesn't work on Linux. I can install the latest Catalyst driver on an old, unpatched Windows 7, but on Linux driver comes with the fresh kernel.
I don't think it's an issue on your desktop machine. If you wish a very stable server maybe Ubuntu, or CentOS is your friend , but at home I think the latest stable kernel is okay.
I use Arch Linux with always the latest packages, and I find it very stable and good for gaming, web browsing, compiling.
I used Ubuntu since v 07.04, but after a while you will want more control over your system, and Arch is the next step I think.

[PackRat]

OpenSUSE's model seems the best one, in the long run.
Instead of releying solely on user testing, they set on OpenQA.
This might take some time to set up test cases but they worth it with every release of new components.

My favorite feature of Opensuse is the snapper rollbacks with btrfs. It works similar to windows system restore. If a user breaks something rollback. If an update breaks something rollback. Tumbleweed is the only rolling release that has this safety net out of the box. Microsoft could learn from opensuse too. If a person downloads windows 10 it will be out of date
and the user will have a ton of updates to do. Tumbleweed snapshot are up to date, nothing to do. Even with OpenQA stuff that's broken happens,but rollbacks save the day.

[kaprikawn]

You've spent your whole life up to this point without hdmi audio. What does it hurt to wait a few more months?

No I haven't, I previously had a 7970 which did audio through HDMI on the OSS driver just fine. The 480 is a relatively recent purchase.

[kaprikawn]

Use Debian testing Xfce with Oibaf ppa mesa and a custom kernel. Debian testing has rolled since December 2000. How to use, see the second message: https://www.phoronix.com/forums/foru...in-living-room

Debian and XFCE which combined are probably going to be stuck on Xorg for the next 10 years. No thanks. You like your distro and DE which is fine for you, but I want Wayland and I actually like Gnome.

Besides, some more knowledgeable folks have given me some excellent advice already in this thread which solves my problem in a way suitable for my setup.

[kaprikawn]

Yet another possible solution : try experimenting with openSuSE Tumbleweed.

I installed SuSe a long time ago for about five minutes, didn't like it and installed something else. I think it's about time I gave it another shot. I might stick it on my test box and give it a whirl. Thanks for the input.

[starshipeleven]

If you would know how to google, then you would know about the following settings and stop whining:

https://filedb.experts-exchange.com/...settings-2.png

If you knew how to read, then you would know that I was NOT talking about blocking windows updates (as easy as setting the internet connection as "metered" https://www.howtogeek.com/226722/HOW...ON-WINDOWS-10/ and worked 100% from day 1, while your method was added much later) and would stop posting bullshit.

I personally use http://www.thewindowsclub.com/make-w...indows-updates because I like to have the old settings back, and I have Windows 10 Pro anyway (does not work on Home versions)

I'd also like to point out that blocking updates works perfectly fine also on Linux.

But blocking updates is not a good idea in general.

[pq1930562]

I was NOT talking about blocking windows updates

Yes you did. Feature updates (i.e. upgrade from Windows 10 1607 to 1703 to 1709 and so on...) are being delivered via Windows Update.

And the screenshot that I presented to you shows you how to defer these feature updates, which gives you time to wait until device manufacturers have come up with new drivers.

Deferring feature upgrades does not defer security updates. So you could still be on Windows 10 1607 today and receive security updates (even though 1709 is the current version).

If you knew how to read [...] and would stop posting bullshit.

So cute .

[tjaalton]

The greatest problem is that Ubuntu creates a snapshot of kernel and userspace at a certain date and takes this as base for the next release.
But even though minor bugfix updates are released within the window of snapshot date and release date of the snapshot, they are not contained within the release.
Same goes for updates after release date.
Here are some examples for Ubuntu's latest release (17.10):

- Kernel version today is 4.13.0-16 (whatever this strange version system is, I guess and hope it's 4.13.16) --> Upstream: EOL (not maintained anymore by upstream) --> so bad choice of kernel version for a release

- Mesa 17.2.2 is in 17.10 --> Upstream: 17.2.8 (!) so Ubuntu missed 6 (!) releases of bugfixes for graphics.

You can complete the list on your own.

We even have a great use-case why this policy is bad. Ubuntu uses an outdated Kernel, forgot to backport important patches for intel-spi and activated a kernel module despite the warning, with the result that a lot of notebooks were bricked.

Artful-proposed (and xenial-proposed!) has had mesa-17.2.4 since November 22nd, but getting real people to actually verify the bugs it should fix is hard and time consuming. Since the paperwork takes ages, I don't even try to chase after every point release, so the unwritten "policy" regarding Mesa is that the last point release will be SRU'd. In this case I couldn't wait that long, and because 17.3.0 was delayed it means that 17.2.x is still not closed yet (AIUI). Besides, point releases can still regress something.

Regarding that intel-spi thing; the upstream patch(es?) that eventually got backported was/were not marked for stable, so how on earth would that've been caught at the time?