Check out our Monthly Survey Page to see what our users are running.
Latest Comments by Redface
Open source graphics drivers get a boost with Mesa 20.2.0 out now
30 September 2020 at 7:26 pm UTC

Mesa 20.2 missed the feature freeze for Ubuntu 20.10 so there is a bug report now to give it an exception https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1896577

And that is not the first time for Mesa, so it is pretty sure it will get into 20.10, and then into 20.04 about 3 months later when 20.04 also gets the 5.8 kernel and xorg from 20.10 and a new installer 20.04.2 with those included.

Edit: Mesa 20.2 is in groovy now https://packages.ubuntu.com/search?suite=groovy&searchon=names&keywords=mesa in time for the release of 20.10

Love Ubuntu but want the latest KDE Plasma? KDE neon now sits atop Ubuntu 20.04
26 August 2020 at 6:32 pm UTC Likes: 2

Quoting: GryxxNow i have to ask difficult question:
I'm looking for distro that:
1. Is fully compatible with Ubuntu in terms of gaming (mainly Robocraft, i do not want to use flatpak)
2. Has fresh packages (KDE, kernel, Mesa, Wine, Lutris being major ones)
3. Does integrate well with KDE
4. I would like something as close as possible to rolling relase

The development version of Ubuntu, specifically the Kubuntu flavour is the closest you can get to that.
Currently its Groovy Gorilla which will come out as 20.10 in October.

Its almost like a rolling release, during most of the half year development phase you get newer versions of the packages. Once it gets close to release more and more parts gets frozen with then only bugfixes, and then it gets released.

A week or so later the next one will start development, and you need to do a small release upgrade, and then its rolls on:-)

Lutris is not yet in the Ubuntu repositories, but the PPA from them does support groovy already. And there has been some progress in getting Lutris into Debian, after which it will get into the Ubuntu development automatically, and then next release. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754129

DirectX 12 exclusive DEATH STRANDING runs on Linux with Proton 5.0-10
24 July 2020 at 9:47 pm UTC

Quoting: Patola[10:48] [1767] [patola@risadinha patola]% apt list --all-versions|grep lib32 | wc -l

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

315
[10:49] [1768] [patola@risadinha patola]% 

Ubuntu also supports multilib. If you grep for lib32 then you get mostly the libraries to crosscompile to 32bit for the various architectures, like for example


lib32stdc++6-10-dbg-sparc64-cross/focal,focal 10-20200411-0ubuntu1cross1 all
lib32stdc++6-10-dbg-x32-cross/focal,focal 10-20200411-0ubuntu1cross1 all


and some amd64 packages containing 32bit, those do not have cross in the name

The packages to support running 32bit are mostly in the i386 arch and do not have lib32 in the package name, so you have to search for i386 to find them. and append :i386 to install them and other operations. For example

apt show libsdl2-2.0-0:i386



to get info about the 32bit sdl2 library in Ubuntu

DirectX 12 exclusive DEATH STRANDING runs on Linux with Proton 5.0-10
23 July 2020 at 5:24 pm UTC

Quoting: Patola
Quoting: Redface
Quoting: Patola20.10? I don't plan to use it. Hopefully I'll have migrated to Arch when it's out. I'm in a point that I can't stand Canonical idiosyncrasies anymore. This stupid bug repeating in 20.04 and 20.10 would not have even happened if not for their impopular idea of forcefully deprecating 32 bits. "Break things on purpose, expecting someone noticing it and reporting a bug"? Imagine the amount of games, applications and other software that will stop working just because someone did not notice, does not know how to open a bug report or does not care.

I cannot see any goodwill coming from Canonical lately. Deeply disappointed with them.

The bug never happened in 20.04, the PPA is not part of the distribution, it is unsupported. And the bug has been fixed in 20.10 already, which first will be released in 3 months.
Yes, for that reason I said explicitly that this PPA is maintained by Canonical people, though. And the process that filters out 32-bits (and needs them to be added to a whitelist) is due to Canonical's decision to stop supporting 32 bits. So, to me, it's still a Canonical bug. One that is not resolved at all, the filter still exists and need to not be applied in a case-by-case basis.

Quoting: RedfaceBugs can happen for any number of reasons, the PPAs and development versions do primarily exist so that bugs can be caught before an update to a released version.
Agreed - my focus was not on the lack of 32 bits on the repository itself but on the process in place to prevent 32 bits builds.

Quoting: RedfaceArch did deprecate 32bit support for installing on 32 bit only CPUs and only building packages needed to run 32 bits programs on a 64bit OS years before Ubuntu did that with 20.04. So if you do not like that they do not build 32 bit packages that no one will install on a 64 bit OS since they always will pick the 64bit version, then you should look else where, like Debian which still support full 32bit only installs, or an older Ubuntu LTS like 18.04
Which is very much a reasonable policy to me. I am against Canonical policy to prevent most 32-bits package, not against Arch policy to not build a full 32-bits distribution. The two are not comparable in my opinion, Arch still does daily builds of thousands of 32-bits packages.

Quoting: RedfaceRemember that Ubuntu 20.04 and and onward still support 32bit versions of all packages needed to run 32bit only programs as long the source package is in the distribution: https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility

This URL has the exact description of the problem I am criticizing: exclude 32-bits package unless someone is engaged enough to the distro to know this address, to engage on that discussion and comment on that post, or go through the other bureaucratic processes (e.g. launchpad) to package something for the distribution, and even then, it's not guaranteed to work. Imagine in, say, 4 years from now, someone will update Ubuntu and finds that an old obscure 32-bits package which is a dependency for these national government software, or game, or niche application does not work in Ubuntu anymore, AND it goes to the extremely improbable case of finding that URL, commenting there about what he needs. Do you actually think someone will even react to his comment? It will be easier for him to change to Debian, or Arch, or anything else that fits his needs. I am changing in advance, for that I have lots of 32-bits games (and a few apps) that I don't want to stop working out of the blue. And for the record, that is not the only reason, of course. I also don't want a distro riddled with unnecessarily containerized software that do not have shared libraries with the rest of the system, I also do not want to waste my time learning and using well crafted software that is suddenly abandoned (upstart, unity, mir), and so on and so forth. So, yes, I am sick of ubuntisms.

BTW: I think that Canonical is quickly losing their mindshare from indirect evidence. A little more than a year ago, we had repositories like the graphics-drivers-dev with NVIDIA beta drivers, or a few other PPAs with them. Nowadays we see each release of the NVIDIA beta drivers passing by and no Ubuntu packages by voluntaries anywhere, while for Arch and others they get it practically day one.

Ubuntu 32bit

No, you wrote "This stupid bug repeating in 20.04 and 20.10" while the bug was in the PPA and 20.10 and fixed both places. We talked about that it takes some time to get into 20.04.

You seem to think that the way Ubuntu implemented to support 32 bit programs on 64 bit systems going forward is a bug, or something else since you have some things misunderstood.

Having a white list is the best possible way forward to do that, and I have not looked how Arch selects 32 libraries to be build but it is probably also some form of whitelist.

Let me explain a bit about the packaging and build system.

Ubuntu and Arch both have the policy to build whats needed to run 32bit programs on 64bit systems.

They do have different package and build systems, so what works to achieve that for one might not work for the other.

Debian and Ubuntu and all their derivatives use multiarch where most other distributions including arch use mulitlib

See https://unix.stackexchange.com/questions/458069/multilib-and-multiarch#458077 for a short discussion about those and the differences.

Maintainers upload source packages to the build system.

All packages will normally be build for all architectures for multiarch. This is not the best way forward when only a subset is needed, so a blacklist would be very inefficient. That is why there is a whitelist.

What happened to the new Nvidia 450 drivers is that they technically are new packages, since multiple versions are needed, mainly for the legacy drivers, so the major version number is part of the package name. And the whitelist is based on package names. Most packages do not have the version number in their name so that would not have to be added again after an update, and for the nvidia drivers they could maybe add some wildcard, or else just have it n a checklist.




Arch does not build all packages for 32bit, they do build a set of

https://www.archlinux.org/packages/?sort=&q=lib32&maintainer=&flagged=

269 packages

and in the AUR https://aur.archlinux.org/packages/?O=0&SeB=nd&K=lib32&outdated=&SB=n&SO=a&PP=50&do_Search=Go

484 packages



20.04 has

apt list --all-versions|grep i386|wc -l

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

5470
packages

You can not compare number of packages directly since the distributions are to different, see https://en.wikipedia.org/wiki/Arch_Linux#Package_management for a short discussion of why. But the arch numbers show that a limited number of packages is needed, and Ubuntu 20.04 has a lot more, due to that the build dependencies also are needed as 32 bit packages.

And users do not have have to check for that list, it was made and added to before release of 20.04 with some additions since then.

If they really need another package in 32 bit where the source is in Ubuntu but not build for 32 then the easiest way is to just build from the source package, or else from upstream.
Just like for any other package any other distribution might not have, or not how the user wants them.

DirectX 12 exclusive DEATH STRANDING runs on Linux with Proton 5.0-10
20 July 2020 at 5:29 pm UTC

Quoting: Patola
Quoting: Redface
Quoting: Patola
Quoting: kaiman
Quoting: PatolaSpeaking of drivers, the 450.57 drivers got to the graphics-drivers PPA for Ubuntu 20.04
So much for Ubuntu LTS releases to get updated NVIDIA drivers without PPAs. :-(
Actually, from my experience, the official Ubuntu repository gets updated a few days after the graphics-drivers PPA. The 440.100 driver came pretty quickly to the official repositories.

440.100 came pretty fast after Nvidia released them, but they also fixed some security bugs: https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-440/440.100-0ubuntu0.20.04.1

There should be 8 weeks of testing after release before a Stable Release Update (SRU) according to https://wiki.ubuntu.com/NVidiaUpdates

430, 435 and then 440 took a few weeks longer than 8 though, lets see how long it will be for 450.

450 is on groovy (the upcoming 20.10) already https://packages.ubuntu.com/groovy/nvidia-driver-450 but still missing i386 like the PPA did, but that will hopefully not take long. https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-450/+bug/1887814

20.10? I don't plan to use it. Hopefully I'll have migrated to Arch when it's out. I'm in a point that I can't stand Canonical idiosyncrasies anymore. This stupid bug repeating in 20.04 and 20.10 would not have even happened if not for their impopular idea of forcefully deprecating 32 bits. "Break things on purpose, expecting someone noticing it and reporting a bug"? Imagine the amount of games, applications and other software that will stop working just because someone did not notice, does not know how to open a bug report or does not care.

I cannot see any goodwill coming from Canonical lately. Deeply disappointed with them.

The bug never happened in 20.04, the PPA is not part of the distribution, it is unsupported. And the bug has been fixed in 20.10 already, which first will be released in 3 months.

Bugs can happen for any number of reasons, the PPAs and development versions do primarily exist so that bugs can be caught before an update to a released version.

Arch did deprecate 32bit support for installing on 32 bit only CPUs and only building packages needed to run 32 bits programs on a 64bit OS years before Ubuntu did that with 20.04. So if you do not like that they do not build 32 bit packages that no one will install on a 64 bit OS since they always will pick the 64bit version, then you should look else where, like Debian which still support full 32bit only installs, or an older Ubuntu LTS like 18.04

Remember that Ubuntu 20.04 and and onward still support 32bit versions of all packages needed to run 32bit only programs as long the source package is in the distribution: https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility

DirectX 12 exclusive DEATH STRANDING runs on Linux with Proton 5.0-10
19 July 2020 at 7:49 pm UTC Likes: 1

Quoting: Patola
Quoting: kaiman
Quoting: PatolaSpeaking of drivers, the 450.57 drivers got to the graphics-drivers PPA for Ubuntu 20.04
So much for Ubuntu LTS releases to get updated NVIDIA drivers without PPAs. :-(
Actually, from my experience, the official Ubuntu repository gets updated a few days after the graphics-drivers PPA. The 440.100 driver came pretty quickly to the official repositories.

440.100 came pretty fast after Nvidia released them, but they also fixed some security bugs: https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-440/440.100-0ubuntu0.20.04.1

There should be 8 weeks of testing after release before a Stable Release Update (SRU) according to https://wiki.ubuntu.com/NVidiaUpdates

430, 435 and then 440 took a few weeks longer than 8 though, lets see how long it will be for 450.

450 is on groovy (the upcoming 20.10) already https://packages.ubuntu.com/groovy/nvidia-driver-450 but still missing i386 like the PPA did, but that will hopefully not take long. https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-450/+bug/1887814

Linux Mint 20 'Ulyana' is out with better NVIDIA Optimus support, fractional scaling
29 June 2020 at 7:49 pm UTC Likes: 1

Quoting: Swiftpaw
Quoting: Redface
Quoting: Schattenspiegel
Quoting: ageres
Quoting: DefaultX-odReason is snapshaming. And it's should be stopped!
If I understand correctly, Chromium has been removed from APT repos too. Or not?
Ubuntu removed it from the APT repos and automatically offered to install the snap instead (they say it is easier to maintain for them that way) - since Linux Mint does share a large part of the Ubuntu repos they would either have to offer the same redirection to snap (which they do not want - read the their blog if you want to know more), package it themselves (which would would be a considerable additional workload for so small a team and not really justified given there are quite a few alternative browsers avaliable and google does not offer it prepackaged themselves) or block the installation with a message stating the reasons behind it and giving you simple directions how to install it anyway, if you insist on using it (which is the way they chose for now).

Ubuntu still has Chromium as a deb package for 16.04 and 18.04. That they have so many supported releases is the reason they switched to snaps for newer releases. Currently the same snap is used for 19.10, 20.04 and 20.10 currently under development.

It takes to many resources for a optional package in universe to package it for so many, and especially the older releases.

The choice was to not have chromium at all or a snap according to a post I saw.

Popos did not want a snap so they build it as a deb for 19.10 and 20.04. I have tried it on Ubuntu, but not tested it much. If someone really wants a deb on 20.04 then getting that package from Popos is an option with pinning (much better than the Debian version build against other library version which some suggest)

But instead of packaging it them self or working with Popos Mint chose to make it harder to install Chromium for their users.
Until Snap is made open source, it shouldn't be used. Your choices are add a PPA for Chromium, install the snap for Chromium anyway even though it's proprietary, or use another browser.
snapd including the snap command is not just open source but free software under the GPL v3: https://github.com/snapcore/snapd https://github.com/snapcore/snapd/blob/master/COPYING
Quoting: SwiftpawThe best solution would be for someone to release a flatpak or appimage of Chromium. That way, everyone could use it across all Linux distros, and no one would be locked into proprietary software while doing so.
Snaps run under most (or all?) Linux distros. See the logarithmic graph at https://snapcraft.io/chromium to see on how many different distributions people installed the Chromium snap. And Chromium is still open source also when packaged as a snap: https://code.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source

What is a problem for some and I also do not like that, is that snaps by default only come from Canonicals servers. You can not add extra snap repositories.
And while you could point snapd to your own servers you will have to implement all the functionality your self and the snaps from Canonicals snapcraft will not be available out of the box.
Or install snaps manually with the --dangerous flag which disbales autoupdates for them
There is a long discussion about that here: https://forum.snapcraft.io/t/external-repositories/1760

Linux Mint 20 'Ulyana' is out with better NVIDIA Optimus support, fractional scaling
29 June 2020 at 4:17 pm UTC Likes: 1

Quoting: Schattenspiegel
Quoting: ageres
Quoting: DefaultX-odReason is snapshaming. And it's should be stopped!
If I understand correctly, Chromium has been removed from APT repos too. Or not?
Ubuntu removed it from the APT repos and automatically offered to install the snap instead (they say it is easier to maintain for them that way) - since Linux Mint does share a large part of the Ubuntu repos they would either have to offer the same redirection to snap (which they do not want - read the their blog if you want to know more), package it themselves (which would would be a considerable additional workload for so small a team and not really justified given there are quite a few alternative browsers avaliable and google does not offer it prepackaged themselves) or block the installation with a message stating the reasons behind it and giving you simple directions how to install it anyway, if you insist on using it (which is the way they chose for now).

Ubuntu still has Chromium as a deb package for 16.04 and 18.04. That they have so many supported releases is the reason they switched to snaps for newer releases. Currently the same snap is used for 19.10, 20.04 and 20.10 currently under development.

It takes to many resources for a optional package in universe to package it for so many, and especially the older releases.

The choice was to not have chromium at all or a snap according to a post I saw.

Popos did not want a snap so they build it as a deb for 19.10 and 20.04. I have tried it on Ubuntu, but not tested it much. If someone really wants a deb on 20.04 then getting that package from Popos is an option with pinning (much better than the Debian version build against other library version which some suggest)

But instead of packaging it them self or working with Popos Mint chose to make it harder to install Chromium for their users.

Distro News - Ubuntu 20.04 'Focal Fossa', Ubuntu MATE and other flavours released
25 April 2020 at 6:51 pm UTC

Quoting: kaimanWith all the positive reactions here, I forced the upgrade from 18.04, as it was a relatively fresh install anyway. I think it's the first time that upgrading from one LTS to the next didn't break the graphics driver, so that's a positive :-).

It didn't, however, go totally smooth. For one it came up with python2 as the default interpreter instead of python3 (the only package actually still depending on python2 being mercurial, which I cannot get rid of, unfortunately). That caused unity-mail to crash, which is still my preferred notification app.

My gnome extensions also weren't updated automatically, and while a notification popped up that updates were available, it took me a while to figure out that what looked like a settings button was actually the button to load the update. But that's on Gnome, not Ubuntu. Also, for some reason, gnome-shell-extension-prefs was not or no longer installed, so extension preferences did not work initially.

But the worst was the new theme. I hate black in particular and dark themes in general. So I switched to the light variant, only to find that all console windows still sported a black window border. Well, turns out console has its own theme settings that for some reason is not following the system default. At least the upgrade preserved my desktop background, but I still have to change grub to show something other than black & white.

And finally, none of the few PPAs I use is yet available for 20.04. Though I guess this will be only a matter of time.

On the whole, I'm content with the updated system, but there's nothing to be ecstatic about.

I had a look at my 20.04 installs regarding python. My desktop has /usr/bin/python which dpkg -S /usr/bin/python says is from the package python-is-python2. The description of that package is:
Quotesymlinks /usr/bin/python to the DEPRECATED python2
In Ubuntu, all python packages use explicit python3 or python2
interpreter and do not use unversioned /usr/bin/python at all. Some
third-party code may still be python2 based, yet may use
/usr/bin/python.
.
This is a convenience package which ships a symlink to point
/usr/bin/python interpreter at the current default python2. It may
improve compatibility with obsolete 3rd-party software, whilst
breaking some modern software.
.
This package will be installed upon upgrades to Ubuntu 20.04, if
DEPRECATED python2 was installed.
.
python2 is DEPRECATED and will not be provided in the future Ubuntu
release. It is recommended to remove python2 and this package after
ensuring that only python3 is in use.
.
No packages may declare dependencies on this package.

My other 20.04 systems do not have /usr/bin/python at all. Trying to run python in a terminal gives:
QuoteCommand 'python' not found, did you mean:

command 'python3' from deb python3
command 'python' from deb python-is-python3
Installing python2 is not even mentioned:-)

So python or python2 are not default, that is python3, you got python pointing to python2 since you have python2 installed, and unity-mail has a bug if it looks at /usr/bin/python and fails if its python2.

Distro News - Ubuntu 20.04 'Focal Fossa', Ubuntu MATE and other flavours released
25 April 2020 at 7:48 am UTC

Quoting: obscurenforeign
Quoting: slaapliedje
Quoting: obscurenforeign
Quoting: eldaking
Quoting: CatKiller
Quoting: eldakingI'll wait a bit anyway and probably will update to 20.04 if it isn't too obnoxious to avoid snaps for most things, or if at least it works well.

sudo apt purge snapd will get rid of snaps entirely. Easy enough.

Sure, but will any default programs be removed by that - like say, the calculator? (I legit don't know what would happen to installed snaps)

And will the Ubuntu repositories contain non-snap alternatives for stuff? If they stop maintaining stuff in the repos because they now use snaps, it becomes impractical to use the distro without it. (While, presumably, other distros could still have those normally... at least for now)

Hey, thank you both for this! I had a look on my system and sure enough, not only was snapd installed but among the few snaps installed on my system was gnome-calculator. I was wondering why the hell the calculator in Ubuntu took a freaking minute to load. Went ahead and installed the calculator from apt and now it loads in less than a second like a good calculator should... oh, and also I'm removing all of snapd and REPLACING ALL THE OTHER SNAPS WITH PACKAGES THAT ACTUALLY WORK RIGHT. ...And seriously contemplating switching to like, Debian or something.
I have been running Debian Sid for pretty much decades at this point. Sure I've played with other distributions along the way, but mostly stick with Debian Sid. You CAN install snapd and flatpak if you'd like in Debian, but it doesn't try to abuse it's users and force it upon anyone.

Thanks for the advice, but my musing about switching to Debian is largely fueled by wanting to avoid snapd. Maybe flatpack's better, but frankly I don't see the use much. ("Am I so out of touch...?")
But no matter what you think of the concept, I hope we can all agree that taking a minute to load a calculator, something that could load in about a second on Windows 95, is unacceptable.

The calculator defaults to the deb package in 20.04 and you can avoid snaps on Ubuntu if you want.

Livestreams & Videos
Community Livestreams
Latest Forum Posts