The next Linux kernel is shaping up to be a interesting release with it's support for existing as well as future AMD Navi GPUs in addition to support for the mysterious CometLake-H and CometLake-LP platforms on the Intel side.
See our coverage of the first 5.3 release candidate for the highlights added during the merge window (the rest of the rc's are typically mostly bug-fixes and small patches).
make oldconfig loves to ask many intimidating questions when you move to a new major version of the Linux kernel.
"So we probably didn't strictly need an rc8 this release, but with LPC and the KS conference travel this upcoming week it just makes everything easier.
And partly because of the extra week, we then had a few fixes that
maybe otherwise would have been delayed and marked for stable. The
most notable one (but hopefully not very noticeable) is fixing race
conditions in configfs. That won't affect very many people, with
configfs not all that widely used, but Christoph and Al both felt it
needed to be fixed.
Other than that, it really is a very small rc (and hopefully the final
week will be smaller still). In fact, the configfs fix along with a
vhost revert is about half of the patch. The rest is various small
things: a few sound fixes, some drm fixes, and a few other random
fixes. Even in the drm case, the selftest addition is bigger than the
core code patches.
The appended shortlog is short enough that it's easy enough to scroll
through if you are interested in the details."
As Linux said, Linux Kernel 5.3 is essentially ready to be released and rc8 could easily have been the final version. Everything indicates that the final 5.3 kernel version will be released on Saturday the 16th of September - unless something horrible comes to light this week. There is no mention of any problems on the kernel mailing list as of now.
The latest release candidate as well as the latest versions of the stable kernels are available from kernel.org.
published 2019-09-09 - last edited 2019-09-09
latest kernel news:
There's not much new in the latest version of the free software Android appstore. There is no mention of version 1.7.1 in the changelog and there is no news on the f-droid website. A close-up inspection of the gitlab repository indicates that only a donation related file has been changed since 1.7 was released early last month.
A lot of the the applications available in the appstore have been updated since last month. We feel compelled to mention that OSMand is a great map and navigation program which allows you to download maps and navigate without any network connection. There is also the very sensible and easy to use Vanilla Music Player. These and other great free software programs can easily be installed using the F-Droid appstore for Android which is available from f-droid.org.
published 2019-09-06 - last edited 2019-09-06
The latest version of the cross-platform IDE for developing software with the Qt toolkit has a new "pin" files feature which allows you to make files stay on top and never go away even if you bulk close all files in a project. There's also support for installing all files that are installed by your build system's install step on remote targets.
Qt creator editing the Kaidan XMPP instant messaging program.
The new pin feature allows you to have files always open and always readily available on top of the "Open Documents" pane. Pinned files remain open even if you choose to Close All Files in Project. This may be quite useful if you want a few files with notes or code-snippets to be there regardless of which project you are working on.
Developers targeting Android will be happy to learn that CMake and Qbs projects now support Android targets and perhaps not that happy to learn that MIPS64 support is gone and it will not be coming back.
Qt creator is available under a (L)GPL v3 license and, if you want to make evil proprietary software, a "Commercial" license. The morally acceptable GPL v3 version is typically available in GNU/Linux distributions repositories under the name qt-creator and a trial version of the commercial edition can be acquired from Qt's download page.
published 2019-09-06 - last edited 2019-09-06
The second Mesa 19.2 release candidate is now available for hardcore and bleeding edge GNU/Linux users who want the latest in graphics technology. Mesa 19.2 will be the first Mesa version to support the AMD Navi GPUs released this summer as well as a mysterious "unreleased" AMD chip referred to as "Navi14". There is also improvements in the Intel Iris graphics driver for Intel iGPUs.
AMD GPU. Not a Navi.
Mesa 19.2 will be the first Mesa version with support for the AMD Navi GPUs which were released this summer. The upcoming soon to be released Linux kernel 5.3 is also required.
Mesa 19.2 rc2 was brought to you by (ordered by (edits)): Marek Ol?ák (18), Kenneth Graunke (15), Samuel Pitoiset (7), Tapani Pälli (3), Bas Nieuwenhuizen (3), Lionel Landwerlin (2), Dave Airlie (2), Thong Thai (1), Rafael Antognolli (1), Pierre-Eric Pelloux-Prayer (1), Paulo Zanoni (1), Jose Maria Casanova Crespo (1), Ilia Mirkin (1), Dylan Baker (1), Danylo Piliaiev (1), Andres Rodriguez (1), Alyssa Rosenzweig (1), Alex Smith (1).
We asked AMD employed Mesa developer Marek Ol?ák about the highlights in the upcoming Mesa 19.2 release:
"Navi10 and Navi14 are the biggest highlights, other than that, 19.2.0.html contains the list of new extensions"
Marek Ol?ák on September 5th, 2019
The mention of a Navi14 in addition to the already-released Navi10 chip peaked our curiosity. Marek Ol?ák clammed up when we tried to follow up on this:
"sorry, it's an unreleased chip, so I'm not allowed to say what it is"
Marek Ol?ák on September 5th, 2019
Both Navi14 and Navi10 are referred to as gfx10 in the code.
There's also improvements on the Intel side where the Intel Iris driver is slowly striding towards feature-parity with the existing i915 driver for Intel GPUs. The Intel Iris driver is not yet the default driver for Intel graphics, i915 is and it will remain the default for some time. The new Iris driver will eventually replace it- Early adopters eager to test it can try it by starting OpenGL applications with environment variable MESA_LOADER_DRIVER_OVERRIDE=iris set. The Iris drivers performance seems to be pretty much on-par with i915 at this point but your mileage may vary.
The complete shortlog story for Mesa 19.2 rc 2 is:
radv: Change memory type order for GPUs without dedicated VRAM
pan/midgard: Fix writeout combining
radv: additional query fixes
radv: Use correct vgpr_comp_cnt for VS if both prim_id and instance_id are needed.
radv: Emit VGT_GS_ONCHIP_CNTL for tess on GFX10.
radv: Disable NGG for geometry shaders.
nir/loop_unroll: Prepare loop for unrolling in wrapper_unroll
virgl: fix format conversion for recent gallium changes.
gallivm: fix atomic compare-and-swap
nir/algrbraic: Don't optimize open-coded bitfield reverse when lowering is enabled
intel/compiler: Request bitfield_reverse lowering on pre-Gen7 hardware
nir/algebraic: Mark some value range analysis-based optimizations imprecise
nir/range-analysis: Adjust result range of exp2 to account for flush-to-zero
nir/range-analysis: Adjust result range of multiplication to account for flush-to-zero
nir/range-analysis: Fix incorrect fadd range result for (ne_zero, ne_zero)
nir/range-analysis: Handle constants in nir_op_mov just like nir_op_bcsel
gallium/vl: use compute preference for all multimedia, not just blit
mesa: recover target_check before get_current_tex_objects
gallium/ddebug: Wrap resource_get_param if available
gallium/trace: Wrap resource_get_param if available
gallium/rbug: Wrap resource_get_param if available
It has been 3 years since the last release of the free open source strategy game Warzone 2100 from 1999. Warzone 2100 has been free software since 2004 and it's small hardcore community has been making small incremental improvements ever since. Version 3.2 could not get into scaling which made it unusable on modern monitors. The latest version has a brand new "Display Scale" option which works well on modern 4K displays. There's also better and smoother graphics and the lagging which would sometimes be noticeable when a lot of things were going on is gone. The new version is available for GNU/Linux, Windows and MacOS. There is no Android version.
Warzone 2100 3.3, gameplay close-up
Warzone 2100 3.3 gameplay
A detailed list of all the changes the voluntary developers have worked so hard to bring to this new release can be found deep in the Warzone 2100 forums in a post titled "Release 3.3.0".
The new display scaling feature and the many fixes related to scaling and window resizing is probably the most important change in this release - specially if you are using a monitor made the last few years. The 3.2 version lacked scaling support which makes it as good as unusable on modern monitors. The new version works perfectly on a 4k display when scaling is set to 200%; the game is designed for those outdated 1080p relics and works best on those when no scaling is applied.
Warzone 2100 3.3 has graphics improvements as well as graphics driver fixes for several platforms.
Warzone 2100 has many kinds of units. Aircraft are called "VTOLs" and this is what they look like. The hotkey ctrl-v gives you control over the vtol units.
There's also some tactical AI changes under the hood. Some of the AI computer-controlled units are now considering secondary and long-range orders.
Warzone 2100 has a "Campaign" mode where you follow a story of how humans were wiped out by a evil computer network by playing various campaigns which consist of many levels. There has been a lot of fixes to this game-mode since the last release.
There does not seem to be much related to multi-player gameplay in the new release in the official change-log. It wasn't broken and has always worked great as long as you have a UPnP supported firewall or manually open port 2100 to allow people to connect (if you are hosting the game, those who participate do not need to open the port). However, there are improvements in this area too - even though they are not indicated by the changelog. An anonymous Warzone 2100 community source told us that:
"There *are* actually a lot of fixes related to multiplayer. From improvements with UPnP, to fixes with downloaded maps, to reduced lag in multiplayer (part of broader performance improvements), etc."
Warzone 2100 is worth a try if you never played it. It's quite fun for a 20 years old game. All GNU/Linux distributions have the old version in their repositories and they will all have the new version immediately or eventually depending on distribution.
published 2019-09-01 - last edited 2019-09-01
Big websites like Microsoft github and GitLab Inc is where the vast majority of people encounter git for the first time. It is actually free open source software and you can and should install it on your own server instead of surrendering control over vital code to large multi-national corporations. The latest version of git has many fixes both server and client-side. It is also "futureproof".
There has been a total of 505 commits by 77 people since version 2.22.0. 26 of those people had never contributed to git (the software, not git repositories in general) prior to this release.
Linus Torvalds wrote git because he needed something to manage the Linux Kernel code-base and he was unhappy with all the existing alternatives for source management.
Updates since v2.22
Backward compatibility note
The "--base" option of "format-patch" computed the patch-ids for prerequisite patches in an unstable way, which has been updated to compute in a way that is compatible with "git patch-id --stable".
The "git log" command by default behaves as if the --mailmap option was given.
UI, Workflows & Features
The "git fast-export/import" pair has been taught to handle commits with log messages in encoding other than UTF-8 better.
In recent versions of Git, per-worktree refs are exposed in refs/worktrees/<wtname>/ hierarchy, which means that worktree names must be a valid refname component. The code now sanitizes the names given to worktrees, to make sure these refs are well-formed.
"git merge" learned "--quit" option that cleans up the in-progress merge while leaving the working tree and the index still in a mess.
"git format-patch" learns a configuration to set the default for its --notes=<ref> option.
The code to show args with potential typo that cannot be interpreted as a commit-ish has been improved.
"git clone --recurse-submodules" learned to set up the submodules to ignore commit object names recorded in the superproject gitlink and instead use the commits that happen to be at the tip of the remote-tracking branches from the get-go, by passing the new "--remote-submodules" option.
The pattern "git diff/grep" use to extract funcname and words boundary for Matlab has been extend to cover Octave, which is more or less equivalent.
"git help git" was hard to discover (well, at least for some people).
The pattern "git diff/grep" use to extract funcname and words boundary for Rust has been added.
"git status" can be told a non-standard default value for the "--[no-]ahead-behind" option with a new configuration variable status.aheadBehind.
"git fetch" and "git pull" reports when a fetch results in non-fast-forward updates to let the user notice unusual situation. The commands learned "--no-show-forced-updates" option to disable this safety feature.
Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command.
"git branch --list" learned to always output the detached HEAD as the first item (when the HEAD is detached, of course), regardless of the locale.
The conditional inclusion mechanism learned to base the choice on the branch the HEAD currently is on.
"git rev-list --objects" learned the "--no-object-names" option to squelch the path to the object that is used as a grouping hint for pack-objects.
A new tag.gpgSign configuration variable turns "git tag -a" into "git tag -s".
"git multi-pack-index" learned expire and repack subcommands.
"git blame" learned to "ignore" commits in the history, whose effects (as well as their presence) get ignored.
"git cherry-pick/revert" learned a new "--skip" action.
The tips of refs from the alternate object store can be used as starting point for reachability computation now.
Extra blank lines in "git status" output have been reduced.
The commits in a repository can be described by multiple commit-graph files now, which allows the commit-graph files to be updated incrementally.
"git range-diff" output has been tweaked for easier identification of which part of what file the patch shown is about.
Performance, Internal Implementation, Development Support etc.
Update supporting parts of "git rebase" to remove code that should no longer be used.
Developer support to emulate unsatisfied prerequisites in tests to ensure that the remainder of the tests still succeeds when tests with prerequisites are skipped.
"git update-server-info" learned not to rewrite the file with the same contents.
The way of specifying the path to find dynamic libraries at runtime has been simplified. The old default to pass -R/path/to/dir has been replaced with the new default to pass -Wl,-rpath,/path/to/dir, which is the more recent GCC uses. Those who need to build with an old GCC can still use "CC_LD_DYNPATH=-R"
Prepare use of reachability index in topological walker that works on a range (A..B).
A new tutorial targeting specifically aspiring git-core developers has been added.
Auto-detect how to tell HP-UX aCC where to use dynamically linked libraries from at runtime.
"git mergetool" and its tests now spawn fewer subprocesses.
Dev support update to help tracing out tests.
Support to build with MSVC has been updated.
"git fetch" that grabs from a group of remotes learned to run the auto-gc only once at the very end.
A handful of Windows build patches have been upstreamed.
The code to read state files used by the sequencer machinery for "git status" has been made more robust against a corrupt or stale state files.
"git for-each-ref" with multiple patterns have been optimized.
The tree-walk API learned to pass an in-core repository instance throughout more codepaths.
When one step in multi step cherry-pick or revert is reset or committed, the command line prompt script failed to notice the current status, which has been improved.
Many GIT_TEST_* environment variables control various aspects of how our tests are run, but a few followed "non-empty is true, empty or unset is false" while others followed the usual "there are a few ways to spell true, like yes, on, etc., and also ways to spell false, like no, off, etc." convention.
Adjust the dir-iterator API and apply it to the local clone optimization codepath.
We have been trying out a few language features outside c89; the coding guidelines document did not talk about them and instead had a blanket ban against them.
A test helper has been introduced to optimize preparation of test repositories with many simple commits, and a handful of test scripts have been updated to use it.
Fixes since v2.22
A relative pathname given to "git init --template=<path> <repo>" ought to be relative to the directory "git init" gets invoked in, but it instead was made relative to the repository, which has been corrected.
"git worktree add" used to fail when another worktree connected to the same repository was corrupt, which has been corrected.
The ownership rule for the file descriptor to fast-import remote backend was mixed up, leading to an unrelated file descriptor getting closed, which has been fixed.
A "merge -c" instruction during "git rebase --rebase-merges" should give the user a chance to edit the log message, even when there is otherwise no need to create a new merge and replace the existing one (i.e. fast-forward instead), but did not. Which has been corrected.
Code cleanup and futureproof.
More parameter validation.
"git update-server-info" used to leave stale packfiles in its output, which has been corrected.
The server side support for "git fetch" used to show incorrect value for the HEAD symbolic ref when the namespace feature is in use, which has been corrected.
"git am -i --resolved" segfaulted after trying to see a commit as if it were a tree, which has been corrected.
"git bundle verify" needs to see if prerequisite objects exist in the receiving repository, but the command did not check if we are in a repository upfront, which has been corrected.
"git merge --squash" is designed to update the working tree and the index without creating the commit, and this cannot be countermanded by adding the "--commit" option; the command now refuses to work when both options are given.
The data collected by fsmonitor was not properly written back to the on-disk index file, breaking t7519 tests occasionally, which has been corrected.
Update to Unicode 12.1 width table.
The command line to invoke a "git cat-file" command from inside "git p4" was not properly quoted to protect a caret and running a broken command on Windows, which has been corrected.
"git request-pull" learned to warn when the ref we ask them to pull from in the local repository and in the published repository are different.
When creating a partial clone, the object filtering criteria is recorded for the origin of the clone, but this incorrectly used a hardcoded name "origin" to name that remote; it has been corrected to honor the "--origin <name>" option.
"git fetch" into a lazy clone forgot to fetch base objects that are necessary to complete delta in a thin packfile, which has been corrected.
The filter_data used in the list-objects-filter (which manages a lazily sparse clone repository) did not use the dynamic array API correctly---'nr' is supposed to point at one past the last element of the array in use. This has been corrected.
The description about slashes in gitignore patterns (used to indicate things like "anchored to this level only" and "only matches directories") has been revamped.
The URL decoding code has been updated to avoid going past the end of the string while parsing %-<hex>-<hex> sequence.
The list of for-each like macros used by clang-format has been updated.
"git branch --list" learned to show branches that are checked out in other worktrees connected to the same repository prefixed with '+', similar to the way the currently checked out branch is shown with '*' in front. (merge 6e9381469e nb/branch-show-other-worktrees-head later to maint).
Code restructuring during 2.20 period broke fetching tags via "import" based transports.
The commit-graph file is now part of the "files that the runtime may keep open file descriptors on, all of which would need to be closed when done with the object store", and the file descriptor to an existing commit-graph file now is closed before "gc" finalizes a new instance to replace it.
"git checkout -p" needs to selectively apply a patch in reverse, which did not work well.
Code clean-up to avoid signed integer wraparounds during binary search.
"git interpret-trailers" always treated '#' as the comment character, regardless of core.commentChar setting, which has been corrected.
"git stash show 23" used to work, but no more after getting rewritten in C; this regression has been corrected.
"git rebase --abort" used to leave refs/rewritten/ when concluding "git rebase -r", which has been corrected.
An incorrect list of options was cached after command line completion failed (e.g. trying to complete a command that requires a repository outside one), which has been corrected.
The code to parse scaled numbers out of configuration files has been made more robust and also easier to follow.
The codepath to compute delta islands used to spew progress output without giving the callers any way to squelch it, which has been fixed.
Protocol capabilities that go over wire should never be translated, but it was incorrectly marked for translation, which has been corrected. The output of protocol capabilities for debugging has been tweaked a bit.
Use "Erase in Line" CSI sequence that is already used in the editor support to clear cruft in the progress output.
"git submodule foreach" did not protect command line options passed to the command to be run in each submodule correctly, when the "--recursive" option was in use.
The configuration variable rebase.rescheduleFailedExec should be effective only while running an interactive rebase and should not affect anything when running a non-interactive one, which was not the case. This has been corrected.
The "git clone" documentation refers to command line options in its description in the short form; they have been replaced with long forms to make them more recognisable.
Generation of pack bitmaps are now disabled when .keep files exist, as these are mutually exclusive features. (merge 7328482253 ew/repack-with-bitmaps-by-default later to maint).
"git rm" to resolve a conflicted path leaked an internal message "needs merge" before actually removing the path, which was confusing. This has been corrected.
"git stash --keep-index" did not work correctly on paths that have been removed, which has been fixed. (merge b932f6a5e8 tg/stash-keep-index-with-removed-paths later to maint).
Window 7 update ;-)
A codepath that reads from GPG for signed object verification read past the end of allocated buffer, which has been fixed.
"git clean" silently skipped a path when it cannot lstat() it; now it gives a warning.
"git push --atomic" that goes over the transport-helper (namely, the smart http transport) failed to prevent refs to be pushed when it can locally tell that one of the ref update will fail without having to consult the other end, which has been corrected.
The internal diff machinery can be made to read out of bounds while looking for --function-context line in a corner case, which has been corrected. (merge b777f3fd61 jk/xdiff-clamp-funcname-context-index later to maint).
Other code cleanup, docfix, build fix, etc. (merge fbec05c210 cc/test-oidmap later to maint). (merge 7a06fb038c jk/no-system-includes-in-dot-c later to maint). (merge 81ed2b405c cb/xdiff-no-system-includes-in-dot-c later to maint). (merge d61e6ce1dd sg/fsck-config-in-doc later to maint).
Source tarballs for git 2.23.0 can be found at kernel.org and the master branch can be cloned from one of these three mirrors:
You can manage source-code with git without setting up your own git server(s) - but you should be aware of the risks if you choose to use someone else's service. Big git service vendors like Microsoft github have censored many free software projects and they have been specially aggressive against free software related to emulating old and outdated hardware. Microsoft's rules and terms of service can and do change with the wind and your software project, public or private, could be removed at Microsoft's discretion at any time for any or no reason. Running your own server may be preferable - but do be aware that there are other risks related to going that route. Backups are desired and somewhat required. Software on just one git server in a basement somewhere may disappear if there is a flood, fire or nuclear exposition.
published 2019-08-17 - last edited 2019-08-17
The next version of IBMs beta-test distribution for Red Hat Enterprise Linux has been branched off from Fedora's bleeding edge "rawhide" tree. The first beta verison of Fedodra 31 will be released September 29th and the final version will be released in the end of October. The high-lights in Fedora 31 are CgroupsV2 resource control, Python 3 as the default python interpreter and updated versions of the KDE, GNOME, XFCE and DeepinDE desktop environments. There will be no i386 or i686 versions of Fedora 31.
Fedora 31 will use version 2.30 of the GNU C Library. The GCC version is currently 9.1.1, the final release will either have that or a newer version. It will also have Gawk 5.0.1. Node.js 12.x will be the default Node.js interpreter. A 10.x Node.js interpreter will remain available for those who need the older version. RPM is updated to 4.15. Golang is updated to 1.13, Perl is updated to 5.30 and Erland is updated to 22. Haskell packages will use GHC 8.6. Those struggling with making R packages work will be happy to learn that Fedora 31's package manager will handle dependencies for packages made in the R programming automatically. The Mono stack is bumped to version 5.20.
Fedora 31 is currently using unreleased 5.3git version of the Linux Kernel.
Updated Desktop Environments
GNOME 3.33.3 on Fedora 31.
On the desktop side there's an option to use the newly released Xfce 4.14. DeepinDE 15.11 will also be available.
GNOME 3.33.3 (or newer) on Wayland will be the default desktop environment.Mozilla Firefox will run natively on Wayland under GNOME but it will still use XWayland/X11 under other Wayland compositors like KDE Plasma and Sway. Qt applications also run natively under GNOME Wayland from now on. They already do under other desktop environments when they are running under Wayland and now they do under GNOME too.
Fedora 31 has KDE Plasma 5.16 with version 19.05 of the KDE Applications available.
KDE 5.16.4 on Fedora 31.
These are the versions included in the branched Fedora 31 as of now, the final release could have newer versions of these desktop environments.
It's over: i386 and i686 are no longer supported
There will NOT be a i686 version of Fedora 31. 32-bit libraries will still be present and it will still be possible to run Steam and WINE and other software which require 32-bit libraries. Fedora is not trying to pull a Ubuntu but Fedora is dropping i686 kernels which means that there will not be any bootable i686 installation images and you will not be able to install Fedora 31 on ancient Intel and AMD computers.
More advanced resource-control
Activation and use of CgroupsV2 is one of the more interesting improvements in Fedora 31. This technology allows processes to be assigned groups with advanced resource limits on CPU time, memory use, disk use and so on. The kernel has had support for cgroups for ages and the newer and fancier cgroupsv2 has also been in the mainline kernel for some time. No distribution has as of yet taken advantage of CgroupsV2 and user-space tools have been lacking. Most distributions doesn't even support CgroupsV1. Fedora 31 will be the first distributions to implement CgroupsV2. CgroupsV1, which is supported by Fedora 30, is useful but it does have some major design-flaws. CgroupsV2 is a partial rewrite of CgroupsV1 and there is also quite a lot of new features. CgroupsV2 is specially useful for those working with containers and virtualized environments where per-user or per-process resource limits are essential.
New identifying markers to accurately Count You
Privacy-aware users may be shocked to learn that Fedora 31 will have VARIANT and VARIANT_ID fields in /usr/lib/os-release in addition to all the other version-specific incriminating information which is already in that file. This new VARIANT_ID will be submitted to Fedoras central servers when you update so they can accurately count you.
No more password-less default SSH logins
On the security side there's no more logging in using a password when connecting with SSH. This has been the default in the stock OpenSSH package since 2015. Most distributions have allowed password logins by default since it does make a lot of sense to allow it until you've had a chance to actually setup a login key. It is a configuration change in the default /etc/ssh/sshd_config where PasswordAuthentication no is a new default; changing that to yes is still possible.
It's over for Python 2
Python 2 and packages requiring it are being eradicated from Fedora 31. Python 2 is very near it's end-of-life January 1st 2020 and Python 3 has been the version to use for years. There are still many packages requiring Python 2 in Fedora. Some are built without Python 2 support in Fedora 31 and some packages are simply removed. The python command, which on Fedora 30 defaults to python 2.7.16, defaults to Python 3 in Fedora 31.
Faster package installation
Fedora 31 will use zstd instead of xz to compress the RPM packages. This is supposedly due to xz decompression being slower than zstd. The default xz binary Fedora and other distributions use is single-threaded and that binary is slower than zstd. However, the parallel xz implementation pixz exists and it a whole lot faster since it uses multiple CPU cores. zstd has multi-core support but it is disabled by default. zstd compression level 19 is used. Single-threaded zstd is faster than single-threaded xz when it comes to decompression so it is an improvement. Why IBM didn't go with pixz or plzip instead is anyone's guess.
The Yum package manager is not present in Fedora 31. Fedora has used dnf for package management for some time and the yum command has been a redirect to dnf for several versions. It has remained optionally available but now it's gone.
Regular "Cloud" support
IBM/RedHat and SUSE are fiercely competing for the lucrative cloud market. Fedora 30 has cloud images available. Those have not been updated since the initial release. Fedora 31 will have monthly cloud images for all supported cloud providers released throughout it's life-cycle.
Upgrading to Fedora 31
Fedora 31 was just branched off the bleeding edge Rawhide tree. It isn't even beta yet, the beta version is not scheduled to be released until September 24th and the final version of Fedora 31 will be released October 29th. Upgrading to Fedora 31 now is not advisable unless you are a wizard who knows what you are doing. You probably are so you might as well run these fine commands as root:
This will take some time since Fedora will download all the packages that are required to update. Run dnf system-upgrade reboot when it is done and the machine will reboot and upgrade to Fedora 31.
There is currently no rpmfusion branch for Fedora 31 which means you will not be able to use the free world versions of mpv, ffmpeg and other software which have crippled versions in Fedora's standard repositories due to American software patents.
Installation images for 31 are not yet available and they won't be until it reaches beta-status. You have to grab a torrent for Fedora 30 and install that and upgrade if you do not already have Fedora installed.
published 2019-08-17 - last edited 2019-08-17
Microsoft has announced that their Windows OS has yet another critical security hole which allows anyone to take control over machines running that operating system if remote desktop services are enabled. The result is that you may be seeing attempts to connect to port 3389 in your firewall. These can be safely be ignored since they are only targeting Windows-infected computers.
No user interaction is required to take over a unpatched Windows machine running its built-in remote desktop services. This means that worms and malware can exploit this gaping security hole with ease. Microsoft issued patches for the vulnerabilities known as CVE-2019-1181 and CVE-2019-1182 on Tuesday the 13th of August. These affect Windows 7 SP1, Windows Server 2008 R2 SP1, Windows Server 2012, Windows 8.1, Windows Server 2012 R2 and all versions of Windows 10 (including server versions). Remote Desktop Services are disabled by default so this only affects Windows machines where RDS has been manually enabled.
ncat (manual) from the nmap package (it is in a separate package called nmap-ncat on some distributions) can be used to listen for a view attempts to exploit Windows machines:
ncat -v -l 3389
Windows users should update their machines and disable RDS if that service is not required or stop using a toy OS and upgrade to a real one like Debian or Manjaro. GNU/Linux need to do nothing since the only affect on GNU/Linux is a minor increase in traffic on port 3389 to routers and firewalls and machines directly connected to the Internet - unless someone on your LAN is infected. The LAN case is the easiest to fix; all you need to do is to plug in a USB stick with Debian or Manjaro or another GNU/Linux distribution and remove the Windows infestation.
published 2019-08-16 - last edited 2019-08-21
The community distribution Debian is 26 years old today. The Debian Project was founded by Ian Murdock on August 16th, 1993. The first version, Debian 0.01, wasn't released until one month later on September 15th, 1993.
The Debian Project is a non-profit organization which makes the Debian GNU/Linux distribution very different from commercial distributions like RHEL and Fedora from IBM and SUSE Enterprise and OpenSUSE from EQT Partners. Debian is actually a community project, it is not just a corporately controlled product with a in practice meaningless "community distribution" stamp on it.
Debian also differs from commercial distributions in another important way: It supports a lot more system architectures than commercial products. The latest version of the Debian distribution, Debian Buster, is available for ARM, MIPS, PowerPC and IBM System Z in addition to regular i386 and x86-64 computers.
Debian is also known for using older "stable" versions of software instead of newer potentially unstable versions. As an example, the latest bleeding edge Debian distribution Buster uses Xfce 4.12 instead of the newly released Xfce 4.14.
26 years is quite a long time. Some of Debian's contributors and users have not been alive that long.
It is with great pleasure we say Happy Birthday Debian.
Debian users and contributors will be celebrating all over the world today. The Swedes, who now own the competing SUSE distribution, will be celebrating in Stockholm at four o'clock local time. Sweden is a creepy place and you shouldn't go there but if you are already there you might as well celebrate. There will likely be Debian celebrations in other parts of the world too.
published 2019-08-16 - last edited 2019-08-16
It only took 5 years for AMD to submit a kernel patch which doesn't even fix RDRAND being broken on older AMD APUs after suspend. Their kernel patch "fixes" the problem by completely disabling the RDRAND instruction on all family 15 and 16 APUs and CPUs from AMD - even those not affected by this particular issue.
This has nothing to do with RDRAND being broken on 3000 series AMD CPUs.That issue is fixed by a BIOS update. Motherboard BIOS updates with the AMD AGESA firmware versioned 1003ABB or higher fixes the Ryzen 3000 CPUs failure to generate random data when RDRAND is called. Biostar made beta BIOSes with AGESA 1003ABB available on July 30th and ASUS made BIOS updates for their products available on August 12th.
AMD is now addressing older APUs like the E1-1200 and the E1-2500 which stops returning random values after the system has been suspended. This makes systemd versions from 240 to 242 freak out and make affected machines unusable after they have been suspended. There is a systemd patch for these versions and distributions like Fedora and Debian Buster have patched systemd versions in their repositories. This solved the immediately visible problems caused by the AMD RDRAND bug on these APUs but it never fixed the underlying problem.
AMD asset Tom Lendacky submitted a patch which makes the kernel as well as user-space programs believe that AMD family 15h and 16h APUs and CPUs don't support RDRAND at all on August 14th.
"There have been reports of RDRAND issues after resuming from suspend on
some AMD family 15h and family 16h systems. This issue stems from BIOS
not performing the proper steps during resume to ensure RDRAND continues
to function properly.
RDRAND support is indicated by CPUID Fn00000001_ECX. This bit can be
reset by clearing MSR C001_1004. Any software that checks for RDRAND
support using CPUID, including the kernel, will believe that RDRAND is
Update the CPU initialization to clear the RDRAND CPUID bit for any family
15h and 16h processor that supports RDRAND. If it is known that the family
15h or family 16h system does not have an RDRAND resume issue or that the
system will not be placed in suspend, the "rdrand_force" kernel parameter
can be used to stop the clearing of the RDRAND CPUID bit."
AMD asset Tom Lendacky explaining AMDs proposed patch on the LKML on August 14th, 2019
The obvious question is:
"You are the CPU vendor. Surely you can tell us how to init RDRAND in
kernel if BIOS failed to do that... can you?"
Kernel developer Pavel Machek in response to AMDs proposed patch
It appears that AMD can't or won't share that information. It could be that nobody at AMD has it after all the years that have passed since the affected chips were designed. Actually fixing the bug would of course be preferable. AMD has instead opted to hide it with
+static void init_hide_rdrand(struct cpuinfo_x86 *c)
+ * The nordrand option can clear X86_FEATURE_RDRAND, so check for
+ * RDRAND support using the CPUID function directly.
+ if (!(cpuid_ecx(1) & BIT(30)) || rdrand_force)
+ msr_clear_bit(MSR_AMD64_CPUID_FN_00000001, 62);
+ clear_cpu_cap(c, X86_FEATURE_RDRAND);
+ pr_info_once("hiding RDRAND via CPUID\n");
if vendor = X86_VENDOR_AMD and family = 0x15 or family = 0x16.
AMDs proposed solution does work - but it is a solution which removes a feature which is partially broken instead of actually fixing the problem with it. It good that AMD is finally doing something half a decade after the affected products were released.
AMDs patch has of course not yet made it into the mainline kernel; it was proposed on the kernel mailing list yesterday and the standard review process does take some time. It will probably make it into the kernel eventually since this bug plaguing older AMD APUs does need a solution.
published 2019-08-15 - last edited 2019-08-15
The Onion Router's many nodes are banned by quite a few tyrannical regimes around the world. Tor has a feature called "bridges" which helps by-pass local censorship. Bridges are computers who act as middle-men between end-users and the Tor network. They are not listed in the Tor directory and they are meant to be hard to learn. It is, of course, possible to pretend you are a lots and lots of end-users in order to learn all the bridges. Tor's new "Snowflake" browser-plugin aims so make Tor even more censorship-resistant by allowing anyone with that browser plugin to act as a proxy for Tor's bridges.
We can only speculate if the explosion of supposed Tor users and the subsequent rapid decline in Iran had anything to do with learning all the Tor networks bridges or not (the graph appears to have leveled off at a higher base-line than it used to have). It is fair to say that making a lot of connections would be one way to learn all the Tor network's bridges in order to block them and prevent access to the Tor network.
The Tor Project has now launched a new initiative called "Snowflake" which aims to make censoring the Tor network even harder. It works like this: People running a web browser in parts of the world where there is no Internet censorship can install a plug-in called "Snowflake". People in parts of the world where there is Internet censorship can connect to users running the "Snowflake" plugin and access the Tor network via that user and a bridge.
The "Snowflake" plug-in does not make your browser a regular proxy. Users who connect to the Internet via that plugin connect to Someone's Web browser with the Snowflake plug-in -> Tor bridge -> The Tor Network -> A Tor Exit Node. It will not be your IP listed in the logs of whatever web services those using your Snowflake proxy access, it will be the IP of the Tor exit node they happen to route through.
There are web browser plugins for Chrome and Firefox available at snowflake.torproject.org if you would like to help users in parts of the world with heavily censored Internet connections by-pass that censorship.
As for the security and anonymity aspects of using the Tor Network.. There are some hard questions one want to ask about the current state of this network. We'll leave you with the following snap-shot of the Tor network for your consideration:
The Tor Network has thousands of nodes. That simple fact may make it sound like you're activities on the Tor network is untraceable but in reality the vast majority of Tor nodes are located in just four cities in Europe. Is it logical to conclude that it's pure chance that there's more "regular people" in four cities in Europe running Tor nodes than the rest of the world put together? Or could it be that there's something else going? Just asking.
published 2019-08-14 - last edited 2019-08-14
A now former Google employee who went on camera talking about Google election meddling and other illegalities in June has made a 300 MB compressed archive filled with internal Google documents available through Project Veritas. The documents include censorship blacklists and plans which outline a clear political agenda.
20 minute interview with former Google employee Zachary Vorhies. by Project Veritas
Project Veritas has, in a move which brings back memories of flash-only websites, made the internal Google documents available through a third party service which requires a proprietary plug-in which is not available on GNU/Linux. There appears to be support for ancient Firefox versions "up to 51" on a few select GNU/Linux distributions - but this requires installing a evil closed source binary plugin. Doing that on a very old an outdated browser is a bad idea.
Luckily, one of our sources in Korea was able to download the full "erverything" archive file and forward it using a Windows-infected computer. We are pleased to make the full document archive available using the standard open and free software way: BitTorrent. Open the following file in any BitTorrent client such as qBittorrent, Transmission or rTorrent to get all the documents:
This file is in .zip format not .tar.bz2 as you would expect. We chose to use the original zip file provided by Project Veritas instead of creating our own for accuracy and to keep the md5sum (79e5e34aecc3c718b79216f48a4f51eb) identical.
published 2019-08-14 - last edited 2019-08-14
The forth release-candidate of the upcoming Linux Kernel 5.3 is the largest release candidate "in years". A lot of the changes since rc3 are network-related and quote a few of those are related to WIFI drivers like the iwlwifi driver for Intel wireless network cards. There's also a notable amount of changes related to Logitech input devices. There's also new Spectre v1 swapgs mitigations in this kernel; fixes for Intel CPU security flaws keep piling onto the already huge pile of fixes for Intel's highly insecure Swiss-cheese products.
"I mentioned last week that rc3 was unusually small.
Well, we fixed that. The small size of rc3 was clearly just because of
pull request timing patterns, and rc4 is back up to normal size and
Part of it is networking - rc3 didn't have any net updates, and rc4
does. But it's not just that, I think we just happened to have several
things that shifted to this past week instead of having made it into
It is worth nothing that while this rc is the largest rc4 (at least in
number of commits) that we've had in a couple of years, it's not
really outrageously so - it really is just larger than usual by about
the same amount that rc3 was smaller than usual.
So I'm not worried, I'm just pointing out a random and somewhat unusual pattern.
Outside of the networking changes that came in this week, there's a
little bit of everything - drivers being most of it as usual (sound,
gpu, hid, pinctrl, usb, misc - in addition to the networking drivers,
of course). But we also have the usual arch updates (x86, arm64,
s390), various tooling updates (selftests and perf), documentation,
and filesystems fixes (gfs2, nfs). And fall-through comment updates
(although the current discussion is about hopefully fairly soon
turning the comments into actual statement attributes, which is the
modern non-lint way of doing it).
The rc isn't so big that you can't just scroll through the shortlog
below to get a feel for the kind of details we have. Nothing looks
particularly scary, although the swapgs speculation thing made the
news, I guess."
The leading GNU/Linux desktop environment Xfce has released a new stable version after almost 5 years of development. The latest version is based on GTK3 instead of GTK2 and it uses GDBus instead of GLib under the hood. There's entirely new components like Xfce's new screensaver and many small and large improvements to the existing applications in Xfce 4.12 such as the file-manager Thunar, the video player Parole, the Xfce4-terminal terminal emulator.
catfish has one path exclusion fix and translation fixes.
Xfce's video player Parole now inhibits power management during video playback.
Xfce's screensaver can optionally inhibit itself if full-screen programs are running and the "blank" screensaver has gotten support for DPMS.
The datetime panel plugin was not ported to GTK3 until this release. Version 0.8.0 has spacing improvements in the preferences dialog and fixed font styling in addition to all the under-the-hood changes made porting it to GTK3.
The weather panel plugin's GTK3 port is also new to the final release. It will now use https for all connections and it's icon now respects the panels configured size.
xfce4-places-plugin has a lot of translation updates since the latest release and some code cleanups.
The latest exo library adds icons to the Help and Close buttons
xfce4-session sets XAUTHLOCALHOSTNAME correctly in systemd user sessions
libxfce4ui won't try to set a button image if an empty string is used
xfce4-settings has quite a lot of changes. Xfce's display manager is included in this package. It has fixed settings retention, it uses proper icon names and it will not longer warn you if you remove the last available profile. GtkStock buttons have been replaced in many of the configuration dialog boxes. And there's a lot of translation updates.
the xfdesktop component has gotten a special Xfce 4.14 wallpaper which is set as default. Most distributions will override this and will leave Xfce's default available as an option.
The panel now keeps both the tasklist and the pager visible during drag and drop. The launcher now pops up where the pointer is. And there's a lot of translation updates.
The file manager Thunar has removed "auto-expand folders" from the tree-view since that caused a bad user-experience when using the keyboard. It's preferences dialog has gotten button icons for help and close. And it now updates the "Open with" menu items when new software is installed. There's also translation updates.
xfce4-power-manager now hides the brightness label if there is no screen brightness setting.
The changes between 4.14pre3 and 4.14 are very small. However, the changes to both the desktop experience and the Xfce programs is huge between 4.12 and 4.14.
Major changes since Xfce 4.12
What is the single biggest improvement between 4.12 and 4.14 if you have to pick just one?
"Migrating to gtk3 is definitely the biggest one. might not be the most important for end users, but huge in terms of maintainability, bug fixings, etc."
Xfce developer Igor Zakharov
Xfce 4.14's desktop looks very similar to how it's always looked: It's a very traditional desktop environment with panels and desktop icons. It may not appear like much has changed at first blush. But there are many improvements to the Xfce desktop experience.
Xfce 4.14 running on Fedora 30 with the Parole media player and the mousepad text editor.
Good-bye screen tearing
The huge under-the-hood changes to Xfce's window manager xfce4 is by itself a good reason to upgrade from 4.12 to 4.14.Xfce has long been famous for it's horrible screen tearing. This was a huge problem with Xfce 4.12 which could most be fixed by changing X's configuration file. Why X and distributions shipping it default to TearFree set to false is a mystery; it's not like the majority of people prefer horrible screen tearing. Xfce's window manager xfwm4 has gotten a lot of changes since 4.12. It's now got Vsync support, support for high-resolution displays and a lot of compositor-related improvements. There is still some hints of screen tearing on less common setups like triple-head desktops but it's a thing of the past for the vast majority of configurations. There is no tearing at all on any setup if the X tearfree option is set to true. xfwm4 has also gotten some Nvidia specific improvements since 4.12 and it now works a whole lot better with the proprietary Nvidia drivers.
Multi-monitor aware desktop
The desktop now supports X's RandR to make it aware of which monitor is the "primary" on multi-screen setups. xfdesktop also syncs the user's wallpaper to the AccountsService - which may not be a good thing: Now choosing someone's username from the login-manager will reveal the wallpaper. Much remains the same, the menu you get when you right-click the desktop is almost identical in 4.12 and 4.14. The only minor difference is that there is a "Open terminal here" item in 4.14. The panels do have quite a few differences. The panels have also become multi-monitor aware and you can now choose to have a panel fixed at whatever display is set as Primary. Panels can also span monitors. Panel configurations can be backed up and restored using a re-worked interface.
Better session management
Xfce has an option under Settings called Session and startup. It was previously possible to Add and disable and enable services started on login under Application Autostart. Xfce 4.14 allows services configured here to be triggered on login, logout, shutdown, restart, suspend, hibernate and hybrid sleep. Hybrid sleep is a new option in the logout dialog too. However, there is still no support for hybrid sleep in Xfce's power manager so you can't have it do that when a laptop's lid is closed or power goes below a critical level.
Xfce 4.14 has DBus management under the hood which is something DBus-aware applications, and most are, can take advantage of.
New High DPI display scaling option
Xfce4 has a new option in it's Appearance settings under the tab Settings called "Window Scaling" which will make GTK windows scale to a multiplier set there. This is a silly option which is required because the GTK developers decided to remove the ability to set toolbar icon sizes - the GNOME developers who made that decision probably thought it was a too friendly option to give people with weak eye-sight. There is still the better option of choosing correct "Custom DPI setting" under the Fonts tab. You will have to pick one of the two; if you set the DPI to 160 - which is correct for a 4k display at 27" and you choose 2x scaling you get fonts that are twice as large as they should be. You are likely better off not using that new option.
Screensaver and Power manager
Xfce used to rely on the general xscreensaver program for screen saving capabilities. Xfce 4.14 now comes with it's own screensaver. This program is a fork of .. mate-screensaver which was forked from gnome-screensaver which was forked from .. xscreensaver. This new screensaver is closely integrated with Xfce's power manager - which has seen a lot of improvements since 4.12.
Xfce's screensaver can use existing xscreensaver-compatible screensavers. That does not work on Manjaro Linux for some reason and you only get the few screensavers built into Xfce's own screensaver. Fedora users will get a long list of xscreensaver screensavers if the xscreeensaver and/or xscreensaver-extras are installed.
This is the first version of Ristretto which is based on GTK3+. It is essentially the same as the GTK2 version. It has some bug-fixes and translation updates but nothing new in terms of features, the port to GTK3 is the big high-light in this release.
Ristretto was one of the last Xfce applications on the 4.14 roadmap which was not ported from GTK2 to GTK3. Xfce developer Igor Zakharov has worked tirelessly to bring Ristretto into the new GTK3 paradime.
Some features like the ability to set Xfce's desktop wallpaper has been made backwards compatible so Ristretto 0.10.0 is able to work with both Xfce 4.12 and the very soon to be released 4.14.
The more important highlights from the changelog for this release are:
Port to GTK3
Add icons to "Close", "Cancel", "Apply", "OK" buttons
Resolve or suppress deprecation warnings
Resolve "GtkDialog mapped without a transient parent" for set wallpaper dialog
Fix the ristretto icon loading size (128, not 256)
Fix sensitivity of flip menu
Add more separators to the menus
Make Preferences dialog prettier
Make the privacy dialog prettier
Support for setting background image for both gtk2 and gtk3 versions of xfdesktop (bug #14571)
configure: print build configuration
Translation updates: Belarusian (be), Danish (da), German (de), Spanish (es), Basque (eu), Finnish (fi), Hungarian (hu), Armenian (Armenia) (hy_AM), Italian (it), Kazakh (kk), Lithuanian (lt), Norwegian Bokmål (nb), Polish (pl), Portuguese (pt), Portuguese (Brazil) (pt_BR), Russian (ru), Turkish (tr), Chinese (China) (zh_CN), Chinese (Taiwan) (zh_TW)
Ristretto still lacks an easy way to quickly switch between folders. Adding this essential functionality would be a big change and a lot of work. Ristretto developer Igor Zakharov had this to say about it:
"The first gtk3 release will mostly be a port of existing functionality plus some bug fixes. the folder switching feature is a big one; perhaps, it will be implemented later."
Xfce 4.14 final is scheduled to be released on Sunday the 11th of August. Xfce's Release Manager Simon Steinbeiss will be unable to work on Xfce this weekend due to important personal priorities. Several leading Xfce developers have been given git commit access and the release will likely proceed as scheduled.
published 2019-08-09 - last edited 2019-08-09
The move was not entirely surprising given that IBM is one of the RISC-V foundations founding members. There is no announcement of Red Hat distributions like Fedora and Red Hat Enterprise Linux becoming available for RISC-V any time soon. However, this does signal that they have plans in that direction.
The American chip-maker Qualcomm still dominates the mobile and embedded markets with their ARM based System-On-A-Chip (SOC) solutions. Qualcomm is, like IBM, a founding member of the RISC-V foundation - yet there's no RISC-V chips available from Qualcomm. An American GNU/Linux distribution for RISC-V from Red Hat could help change that.
The Chinese have a working 16-core RISC-V chip and another Chinese RISC-V chip named Loongson Godson 3A4000/3B4000 in October. It will be produced in Europe by STMicroelectronics on a 28nm process. The Chinese have written a in-depth analysis of the Loongson Godson 3A4000. That chip does have one flaw: it consumes up to 80W at 2.0 GHz. That rules out tablets and mobile phones but does leave the door open for servers. There is no big Chinese Linux vendor or any Chinese Linux distribution for RISC-V.
It is interesting to note that the Swedish-owned German Linux vendor SUSE is not a member of the RISC-V foundation. Canonical, who makes the Ubuntu distribution, is also not a member.
The new minor version of the Bitcoin Core wallet software for storing and managing the crypto-currency BTC has some minor bug fixes, performance improvements and updated translations. Tor users will be happy to learn that this Bitcoin Core version does not hang for ages when it's shut down while it's connected to the Tor network. Bitcoin Core 0.18.1 is available for GNU/Linux, Windows and macOS.
Bitcoin Core is a wallet program for storing BTC crypto-currency. It is currently trading at $11765.
There's basically nothing new since 0.18.1 rc1 two weeks ago but there is a lot of changes since 0.18.0. The network-related code has these changes:
#15990 Add tests and documentation for blocksonly (MarcoFalke)
#16021 Avoid logging transaction decode errors to stderr (MarcoFalke)
#16405 fix: tor: Call `event_base_loopbreak` from the event's callback (promag)
#16412 Make poll in InterruptibleRecv only filter for POLLIN events (tecnovert)
The Wallet code has seen one change since 0.18.0 which was not present in 0.18.1rc1:
#15913 Add -ignorepartialspends to list of ignored wallet options (luke-jr)
There's some changes related to APIs and remote procedure calls (RPC):
#15991 Bugfix: fix pruneblockchain returned prune height (jonasschnelli)
#15899 Document iswitness flag and fix bug in converttopsbt (MarcoFalke)
#16026 Ensure that uncompressed public keys in a multisig always returns a legacy address (achow101)
#14039 Disallow extended encoding for non-witness transactions (sipa)
#16210 add 2nd arg to signrawtransactionwithkey examples (dooglus)
#16250 signrawtransactionwithkey: report error when missing redeemScript/witnessScript (ajtowns)
The still not at all user-friendly graphical interface has seen some changes too:
#16044 fix the bug of OPEN CONFIGURATION FILE on Mac (shannon1916)
#15957 Show "No wallets available" in open menu instead of nothing (meshcollider)
#16118 Enable open wallet menu on setWalletController (promag)
#16135 Set progressDialog to nullptr (promag)
#16231 Fix open wallet menu initialization order (promag)
#16254 Set `AA_EnableHighDpiScaling` attribute early (hebasto)
#16122 Enable console line edit on setClientModel (promag)
#16348 Assert QMetaObject::invokeMethod result (promag)
There's also some changes to the build system and the internal tests.
There is one known problem in this release: Users who use multiple different wallets and have enabled the coin control features (allows you to select what inputs are used as outputs in a transaction) can end up with a "wrong-wallet state" when switching between wallets using the drop-down menu. The Bitcoin Core developers recommend not using the coin control features when multiple wallets are loaded.
Xfce's team describes the Whiskermenu as "An alternate menu". That may be true in theory but in practice it's the default standard menu on most distributions. The new version has translation updates for Bulgarian, Czech, Danish, Galician, Icelandic and Nepali. It also removes a partial crash-fix for crashes caused by garcon.
The optional Xfce Whiskermenu is fancier than the stock Xfce menu. Many distributions opt to use it as the default menu.
The release notes for 2.3.3 are:
Removed workaround for garcon that did not always fix crash.
Why was this crash fix removed, you may wonder. An anonymous source in the Xfce developer community explained that:
"There was a bug in garcon that crashed whatever used it while .desktop files were being updated. The whiskermenu author implemented a workaround that worked partially and now removed it because garcon was fixed."
The Linux Journal was the first magazine to write about the Linux kernel and operating systems based on it back when it launched in 1994. It was published as monthly printed magazines until September 2011 when it switched to publishing digital monthly editions. It was almost over in 2017 when the Linux Journal announced that it was closing it's doors. However, Private Internet Access stepped in with funding and the Journal kept going. Now, 25 years since it published it's first edition, it's over and the staff is let go.
A Linux Journal cover from October, 2002.
"On August 7, 2019, Linux Journal shut its doors for good. All staff were laid off and the company is left with no operating funds to continue in any capacity. The website will continue to stay up for the next few weeks, hopefully longer for archival purposes if we can make it happen."
Linux Journal, LLC
The Linux Journal has had many interesting and noteworthy articles during it's 25 years of existence. It really is quite sad that it's come to this.
The Linux Journal Good-Bye letter titled "Linux Journal Ceases Publication: An Awkward Goodbye" by Kyle Rankin thanks both the readers who supported it and the staff who kept on writing interesting and sometimes very in-depth articles. Kyle goes on to write that "We truly did everything we could to make this a success, and I'm so sorry it didn't work out.". They probably did do all they could to keep it afloat; running a publication like this one is not a very lucrative proposition. This site's been around since 2004 yet it's not anywhere near profitable enough to be a full-time job. It would be great if more people would read it and share links to it but that's not happening so I work at a farm and this site remains a hobby-project. The Linux Journal had a large staff and an office and other expenses which probably made it hard to keep it profitable. It is very sad that they are gone and they will be missed.
published 2019-08-08 - last edited 2019-08-08
The latest version of the graphics library which underpins all GNU/Linux graphics when free drivers are used has a lot of other fixes for Radeon graphics cards. There's also fixes for nv50 and nvc0 based NVidia cards in the free nouveau driver and some fixes for Intel integrated graphics.
Games like SuperTuxKart render their graphics using the Mesa 3d graphics library.
There's also fixes for the spirv, nir and egl backends. This is a minor bug-fix release, the bigger features like AMD Navi support will come when Mesa 19.2 is released. The first release candidate for 19.2 should have been out yesterday according to their total plan for Mesa 19.2. It has been delayed. Mesa developer Emil Velikov has announced that "With multiple teams finalising the final features for their drivers, I've decided to push the branch point by one week." Mesa 19.2 rc2 is scheduled for August 13th which indicates that rc1 will be available on that date.
The Mesa team high-lights these fixes in Mesa 19.1.4:
A fix for hair artifacts in Max Payne 3 on AMD/RADV.
Vulkan 24/48 bit formats are now not supported on Ivybridge.
R8G8B8_UNORM_SRGB is not supported on Haswell.
Vulkan transform feedback extension is disabled on Intel gen7.
AMD video encoding/decoding: (uvd and vcn are AMD-specific video decoding technology)
radeon/uvd: fix poc for hevc encode
radeon/vcn: fix poc for hevc encode
radeon/uvd: enable rate control for hevc encoding
radeon/vcn: enable rate control for hevc encoding
AMD Vulkan: (radv)
radv: fix queries with WAIT_BIT returning VK_NOT_READY
radv: fix crash in vkCmdClearAttachments with unused attachment
radv: Set correct metadata size for GFX9+.
radv: Take variable descriptor counts into account for buffer entries.