Language Selection

English French German Italian Portuguese Spanish

Portland Project betas common tools for GNOME, KDE

Filed under
Software

The Portland Project, the collaborative venture of Linux vendors and developers to simplify the process of porting and integrating applications for Linux desktops, has announced the beta release of its first application tools for the Linux desktop's GNOME and KDE environments.

The Portland Project's beta includes a suite of command line tools that are designed to help ISVs (independent software vendors) install their applications in the major Linux desktop environments. Portland's programming interfaces build upon established freedesktop.org specifications to provide developers with easy-to-use tools that automate implementation.

The beta is designed to automate the most commonly used desktop integration tasks, such as activating a web browser and starting an email composer.

Full Story.

More in Tux Machines

Hangover Alpha 2 Lets Windows x86/x64 Programs Run On ARM64, POWER 64-bit

The Wine program for running Windows games/applications on Linux and other platforms can run on a number of different architectures, but Wine doesn't handle the emulation of running Windows x86/x64 binaries on other architectures like 64-bit ARM or PowerPC. But that's what the Wine-based Hangover is about with currently allowing those conventional Windows binaries to run on AArch64 (ARM64) and 64-bit POWER too. Hangover started out with a focus on Windows x64 binaries on ARM64 in looking at the possible use-case of running Windows software on ARM mobile devices and more. This year with the help of Raptor Computing Systems there has been Hangover support added for IBM POWER 64-bit. Read more Also: Come And Find Out About Her Story

Jonathan Dieter: Switching to OSTree

Given our shift towards containers, the most obvious solution would have been to switch to Fedora CoreOS, but a number of our call servers have Sangoma telephony cards with kernel drivers that are, unfortunately, out-of-tree. While there are some elegant ways to load custom kernel modules into Fedora CoreOS, we needed a more stable kernel, due to the (lack of) speed in which these modules are updated to build with new kernels. So we decided to go with a custom OSTree distribution (surprisingly named SpearlineOS), built using rpm-ostree and CentOS 8. SpearlineOS has two streams, staging and production. At the moment, we’re manually building each new release, pushing it to staging, running it through some smoke tests, and, then, finally, pushing it to production. We are in the process of setting up a full staging environment with automatic builds and automatic promotion to production once a build has been functioning correctly for set period of time. We’ve also setup greenboot in SpearlineOS so that our servers are able to fail back to an older release if the current one fails for any reason. Read more

Python Programming

KDE Bug-squashing

  • This week in KDE: Continuous bug massacre

    This week the bug squashing continues at full speed! We’ve made short work of tons of bugs throughout our software stack, including the infamous login sound bug, some very important and longstanding issues with extended attributes, and a ton of quality-of-life improvements for the Plasma Wayland session. But we also managed to add a few nice new features that I think you’ll like.

  • KDE Saw A "Bug Massacre" This Week With Better NVIDIA Wayland Experience, Many Fixes

    The bug fixing in KDE land continues and ends the month with a "bug massacre", for how KDE developer Nate Graham describes it in his weekly recaps.  Graham also commented of this week's KDE efforts as "bug squashing continues at full speed!" Some of the work that got addressed this week for KDE includes:  - The KDE Plasma Wayland session no longer requires manually setting an environment variable to make NVIDIA GPUs with the proprietary driver properly function. This change is with KDE Plasma 5.20.2 for offering a better KDE Wayland out-of-the-box experience on NVIDIA's proprietary driver. This is addressed by automatically detecting the NVIDIA proprietary driver and EGLStreams rather than making the user set KWIN_DRM_USE_EGL_STREAMS.