Proposal for Ubuntu 20.04LTS

Okay, we finally get to the point.

5 Likes

@popey, maybe @c-lobrano should apply to become an Ubuntu developer and the Ubuntu developers should have a special flair on this forum?

I think it’s also a nice incentive to become an Ubuntu developer.

2 Likes

I think an important point has been lost in all the flame war talk.
I also see the benefit in adding a GUI tool to easily manage kernels in Ubuntu.
I’d propose this to be added in “Software & Updates” app as a tab next to “Livepatch”.

Before, I used Ubuntu Kernel Update Utility (a third party app) for this purpose and that worked beautifully, never had an issue.
The problem is that the dev decided to go proprietary with that app and thus I no longer use it nor do I have a GUI alternative.

It really helped me when I got my Vega64, Threadripper, Magic Keyboard, Magic Mouse. None of this hardware worked with the kernel that my Ubuntu was on at the time so it was either wait for 6 months or use UKUU to upgrade my kernel and that’s what I did. It was painless and it allowed me to finally use my hardware w/o an issue.

I’d like to give my vote for this feature to be developed as I know this would help a lot of people.

1 Like

Gnome Tweaks

In my opinion it would be a bad idea to include it as a default in Ubuntu Desktop since having two different settings apps would be redundant.

However I’d really love some Tweaks features to be exposed in Settings app by default.
Every Ubuntu release I find myself doing the same few tweaks right after release-upgrade and those are:

  • Changing the “Titlebar Buttons” ( X _ □ ) placement back to left as it was on Unity7 which the current Ubuntu layout was designed for might I add.
  • Changing the theme to Adwaita-dark, don’t get me wrong, I love Yaru and I switch back and forth Yaru - Adwaita-dark.
  • Increasing fonts scaling factor to 1,20 b/c fractional UI scaling still isn’t implemented so this is my workaround for the past few years.
  • Installing extensions: GS Connect and Caffeine.

I think at least the “Titlebar Buttons Placement” should be exposed in Ubuntu Settings.

A theme may change, fractional scaling may get implemented, these extensions may be defaulted or abandoned by it’s devs but I’ll be changing the placement of those titlebar buttons for the rest of my life as I’m sure many Ubuntu users do since we liked Unity7 and Unity8 and many are still using those and are yet to transition and those buttons are imo a big deal :slight_smile:

That and maybe have meta packages, like linux-*-mainline for mainline kernels, similar to linux-*-hwe-* for HWE kernels.

This would be useful for Linux users who are using newly-released hardware.

Talking about Tweaks, I like how elementary handles it. Once the Tweak app is installed, it doesn’t show up as standalone, but instead as a new option in the settings app

6 Likes

Don’t forget that -mainline kernels are completely unmaintained kernels without any QA or security reviews, they are built by some script when a new upstream tag is added, inside an unsupported PPA …

To have something like a metapackage you’d have to actually move the debs to the actual archive (a metapackage can not depend on something outside here) which would also mean the kernel team would have to do QA, security reviews etc. Do SRUs so the archive isnt stuck at some snapshot mainline version after release etc etc … this is a hell lot of work (my guess would be probably one or two fulltime devs just to keep this rolling … ).
So my guess would be that a metapackage inside the archive is very unlikely to happen …

Now … you could put a metapackage into the PPA but that would also need quite some manual maintenance to regulary bump the version, monitor when upstreams tags get updated etc … while this is likely a lot less effort than the first option, it is still non-zero and will cost developer time …

Lets take a look what the actual purpose of these mainline builds is at all (from https://wiki.ubuntu.com/Kernel/MainlineBuilds):

By default, Ubuntu systems run with the Ubuntu kernels provided by the Ubuntu
repositories. However it is handy to be able to test with unmodified upstream kernels to
help locate problems in Ubuntu kernel patches, or to confirm that upstream has fixed a
specific issue. To this end we now offer select upstream kernel builds. These kernels are
made from unmodified kernel source but using the Ubuntu kernel configuration files.
These are then packaged as Ubuntu .deb files for simple installation, saving you the time
of compiling kernels, and debugging build issues.

These kernels are not supported and are not appropriate for production use.

In that light i doubt that anyone would put any effort into maintenance work for these kernels… nor would anyone put a tool into a default install that installs kernels that are “not supported and are not appropriate for production use” …

That said, i guess nobody would complain if someone stepped up to put a tool like UKUU into universe (as long as it pops up something like the above warning text when you use it to not have illiterate users shoot temselves in the foot indeed).

2 Likes

I get what you’re saying. Could it then be implemented as a hidden feature until enabled like developers panel in Android? With all the warnings etc ofc.
You have to tap on the kernel version (or something similar) 8 times and then the developers panel shows up in the Android settings app.

Canonical employs GNOME developers too.

4 Likes

OT but this has been the trend last year in my workplace. Almost 90% of developers previously using MacOS (for years), and they were more than half the tech sector of the company, are now in Ubuntu 18.04 and 19.04. And happily so, they say. I have been an Arch user for more than 10 years but these days I’m also mostly in Ubuntu. I’m more of an old school emacs-hacked-from-sources kind of guy, so I really don’t care a lot about snaps, yet, but many of my younger fellows are using vscode snaps (though, some other ones, ppas).

6 Likes

So, I just saw on Twitter how Eoan, right now, doesn’t support latest Navi GPUs. Any plans on making sure that new users won’t have to worry about something like this?

I have no idea, do you know if anyone filed a bug so the relevant development teams are aware of it ?

1 Like

It seems to have been solved: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1848848

1 Like

Flatpak is actually less worse than snaps because they are more efficient and faster.
For example, I was surprised that the flatpak of libreoffice is relatively fast while its snap version is a disaster.

However, even a flatpak package remains less efficient than a debian package, nothing is faster and more efficient than the basic packages of the distribution.

debian package > flatpak package > snap package

1 Like

I kinda like the way Kodi does it. Where you can have standard / advanced / expert settings depending on your choosing. Similarly, you could have a toggle in system settings that enable the more advanced settings (tweaks integrated rather than stand alone).

1 Like

I meant in a general sense. IIRC, when some Vega GPUs (I think it was the Radeon VII) came out, people had to install the mainline kernels just to get their displays to work properly, and I think it took months (19.10, I think) before Ubuntu was able to support it.

I think you’re confusing “snaps start slower than debs” with “snaps are slower than debs”. The former is true, the latter isn’t.

It is true that snap startup time is an annoying issue, but the useful parts far outweigh this problem in my use case anyhow. And I know Ubuntu knows and it’ll eventually get fixed.

5 Likes

Well, the kernel team needs some time to stabilize, make sure backported code doesnt regress and do all the QA of the added ubuntu sauce on top of the kernel tree. typically a kernel package gets frozen 1-2 months before release… if new HW comes out in that time frame it is simply hard to get support in before final release (sometimes it works via SRUs though, if the changes are not too massive like with the above bug report that @emanuc pointed to for example )…

that said … if support for the card landed in 19.10, you should also very soon be able to use the card on 16.04 and 18.04 by using the hwe kernel (which gets backported from 19.10).

1 Like

Yes, when I say “snap is slow”, I mean the first launch of application in the session.
But it’s very annoying because like many, I often start/switch off the PC and therefore the first start of the software must be fast.

However, even if Snap was at the same level as flatpak in terms of launch speed (which I remind you is absolutely not the case), it wouldn’t change the fact that you shouldn’t impose a universal package by default in a distribution. Flatpak, Snap and AppImage must remain an option/alternative.

Otherwise totally unrelated:
The linux kernel of the 20.04LTS will be version 5.5 ?
And Gnome 3.36 ?

1 Like

Anecdotal of course, but I’ve been switching my production workflow to snaps (I’m a 3D modeler, so that’s Blender and Inkscape) and I have yet to find an issue with them.
On large, professional applications where you’re expecting them to use large resources no matter the version, the snap has virtually the same memory usage; and startup times are literally the exact same as the deb packages for both of those applications (I tested them). Plus the added benefit of less complexity to the end user (as a non techie, I always hated having to use the CLI or adding PPAs, seems archaic IMO).

6 Likes