Products > Computers
Ubuntu 20.04 LTS
RoGeorge:
"SMT vulnerable" means it's vulnerable! It's not some name of a fix.
After disabling the Multithreading from BIOS, it now shows:
--- Quote ---~$ tail -n+1 /sys/devices/system/cpu/vulnerabilities/*
==> /sys/devices/system/cpu/vulnerabilities/l1tf <==
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled :phew:
==> /sys/devices/system/cpu/vulnerabilities/meltdown <==
Mitigation: PTI
==> /sys/devices/system/cpu/vulnerabilities/spec_store_bypass <==
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
==> /sys/devices/system/cpu/vulnerabilities/spectre_v1 <==
Mitigation: __user pointer sanitization
==> /sys/devices/system/cpu/vulnerabilities/spectre_v2 <==
Mitigation: Full generic retpoline, IBPB, IBRS_FW
--- End quote ---
RoGeorge:
I am testing right now Gentoo and Kubuntu 20.04 LTS (Focal Fossa) prerelease.
Gentoo is great, but for a desktop use, at home, is unpractical (at least for my typical usage). Gentoo needs way too much attention, it takes way too long to update or emerge (compiling from sources). Gentoo makes sense if one has a farm full of identical servers, or something, but not for a single desktop at home, and a typical daily usage.
OTOH, Kubuntu 20.04 LTS (prerelease, right now an early beta, maybe) is just right as a home desktop.
Kubuntu means Ubuntu, but with KDE/Plasma instead of Gnome (normal Ubuntu comes with Gnome GUI instead of KDE/Plasma), and LTS stands for Long Time Support (5 years for free, or 10 years payed support).
The release date is somewhere around 20 of April 2020, but daily builds (prerelease) can be downloaded and installed:
http://cdimage.ubuntu.com/kubuntu/daily-live/current/
or, fot classical Ubuntu, the Focal Fossa 20.04 LTS daily builds are at:
http://cdimage.ubuntu.com/daily-live/current/
I am writing from a Kubuntu 20.04 prerelease install, and so far it was rock solid. The only bug so far (or maybe not bug, but difficulty, IDK) was that I can not connect with Samba to a WinXP shared folder (worked OK with Ubuntu 18.10, but not working with Kubuntu 20.04 LTS, also the interface is different) not sure why it doesn't work.
Other than SMB, all seems to be working fine. Also, there are lots of updates and fixes at each couple of hours, since we are less than a month before the official 20.04 LTS release. :D
To me, Kubuntu 20.04 LTS was so far very stable (testing it for more than a weekend now), and there is still a month of potential bugs fixes before the official release. :-+
brucehoult:
--- Quote from: RoGeorge on March 22, 2020, 06:14:19 am ---I am testing right now Gentoo and Kubuntu 20.04 LTS (Focal Fossa) prerelease.
Gentoo is great, but for a desktop use, at home, is unpractical (at least for my typical usage). Gentoo needs way too much attention, it takes way too long to update or emerge (compiling from sources). Gentoo makes sense if one has a farm full of identical servers, or something, but not for a single desktop at home, and a typical daily usage.
OTOH, Kubuntu 20.04 LTS (prerelease, right now an early beta, maybe) is just right as a home desktop.
--- End quote ---
I completely agree that Ubuntu LTS is the right thing to use for people who just want to use Linux for real work, not dick about with it all the time.
In principle Kubuntu is as good as Ubuntu for this, and in some ways the UI is better. I used Kubuntu back in the mid 2000's, mostly because my gf Jes at the time was part of the documentation team. Back then in the days before Core [2] [Duo] the UI was noticeably a bit less resource intensive.
I ended up switching to regular Ubuntu because it was less trouble, and a lot of binary-distributed software was linked against the Gnome libraries anyway.
Pretty much every company I've come across using Linux internally and developing software on it uses Ubuntu LTS -- many of them still on 16.04 at this point. That's the supported platform. Often individual developers within the company are allowed -- even maybe encouraged -- to run something different if they prefer it, but if they encounter a situation where something works on Ubuntu LTS and doesn't work on their own workstation then that's their problem to find a fix for.
The exception is EDA companies, which seem to have settled on RedHat-ish systems, generally Centos.
I'm running 18.04 LTS on my own machines. I'll be updating to 20.04 LTS when the software updater suggests that I do -- probably around June or July I guess.
RoGeorge:
I've had an issue yesterday with Kubuntu 20.04 LTS. The file "~/.xsession-errors" filled up all the partition, more than 60GB, mostly with the same error message about VDPAU not being able to create chroma filter. Found 3 log spammers:
Log spammer 1
This was something related with VLC. Played a movie with the VLC hardware decoder set to VDPAU (for nVidia), while the movie was playing on a monitor connected to the onboard i7 GPU (Intel® HD Graphics 4600), then the PC went to standby, and the next day run out of space.
To empty the ~/.xsession-errors file, redirect /dev/null to it
--- Code: ---> .xsession-errors
--- End code ---
Set the VLC hardware decoding to Automatic in VLC. From menu Tools -> Preferences -> Input/Codecs -> Hardware-accelerated decoding, and from the corresponding drop down box select Automatic, then press Save.
Log spammer 2
Looking in the ~/.xsession-errors again, there was still some smaller spam with the repeated message "qml: temp unit: 0". This was from a widget/plasmoid installed from the official "Plasma Addon - Discover" repository. The addon is called Thermal Monitor, and also has had a minor bug that all the temperatures were shown except for the CPU, where it showed OFF instead of a number. At a right click and Reload Temperature Sources, the CPU temperature start working.
To fix the error log spamming with "qml: temp unit: 0", open the file "~/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/code/temperature-utils.js" and in the line #16, change print into dbgprint, then save, so line 16 will look like that:
--- Code: ---dbgprint('temp unit: ' + temperatureUnit)
--- End code ---
To fix the OFF displayed instead of hte CPU temperature, open the file "~/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml" and change the line 58 from "property var systemmonitorAvailableSources" into
--- Code: ---property var systemmonitorAvailableSources: []
--- End code ---
then save and restart.
The Thermal Monitor plasmoid should now display correctly, without any help, and also should not spam error messages any more. The fixes above were found by reading the github issues and comments, e.g. https://github.com/kotelnik/plasma-applet-thermal-monitor/issues/53
Log spammer 3
A third spammer I found was the KTorrent. When started from the GUI, it was continually sending thousands and thousands of lines into ~/.xsession-errors log, with all the TCP connection, failures, even a canceled attempt of renaming a torrent was logged with all the details, including the old and the new file name, that were the same, since the rename attempt was canceled, way too verbose. :o
However, when I started ktorrent from a terminal, I noticed the same crazy verbosity, but only in the terminal where ktorrent was running, and nothing into the ~/.xsession-errors. Even more, after redirecting the stdout to /dev/null, no error messages were displaying, so all those were not errors from stderr, were just normal stdout messages, thought, not sure why they had to be many.
To fix that, in the file "/usr/share/applications/org.kde.ktorrent.desktop", find the "Exec=" key and redirect stdout to /dev/null by replacing the line "Exec=ktorrent %U" with
--- Code: ---Exec=sh -c "ktorrent %U" > /dev/null
--- End code ---
Save and start the KTorrent from GUI. The extra shell wrapper is required, or else when a new torrent URL is added, the shell will concatenate the %U list of URLs with > /dev/null, which will generate errors.
The .xsession-errors should now stay clean of ktorrent spam, only the ktorrent errors, if any, will go into the error log. If curious about what .desktop file does, what is Exec= key, or what is %U, they are described in the doc pages:
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
Question
About the last one, when a programm is started from a GUI instead of a terminal, it seems OK to redirect the stderr to an error log, but why redirecting the stdout to the ~/.xsession-errors, too? Is this expected behaviour, or a bug?
rdl:
I've never understood why recording log files is on by default. In well over twenty years of using PCs, running multiple operating systems, I don't recall ever having a problem that was solved because of something in a log file. On the other hand, no telling how many drives died an early death because of them.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version