Language Selection

English French German Italian Portuguese Spanish

KDE4 and Plasma 5 for Slackware

Filed under
  • KDE4 and Qt4 deprecation in FreeBSD

    This is a reminder — for those who don’t read all of the FreeBSD mailing lists — that KDE4 is marked deprecated in the official ports tree for FreeBSD, and will be removed at the end of this year (in about 20 days). Then Qt4 will be removed from the official ports tree in mid-march.

    Since both pieces of software are end-of-life and unmaintained upstream already for several years, the kde@ team at FreeBSD no longer can maintain them. Recent time-sinks were dealing with OpenSSL 1.1.1, libressl, C++17, .. the code is old, and there’s newer, nicer, better-maintained code available generally by replacing 4 with 5.

  • KDE Plasma 5 for Slackware – end of the year edition

    I just uploaded a whole new batch of packages containing KDE Plasma5 for Slackware. The previous batch, KDE 5_18.10 is already two months old and has some library compatibility issues. The new KDE 5_18.12 for Slackware consists of KDE Frameworks 5.53.0, Plasma 5.14.4 and Applications 18.08.3. All this on top of Qt 5.11.3.
    Compiled on the latest Slackware -current, it’s running smoothly here on my laptop.
    I decided against upgrading to QT 5.12.0. This is a new LTS release, but I will wait for the other distros to find bugs in this new software. Next week, KDE will release KDE Applications 18.12.0 and that too is something I want to check a bit before releasing Slackware packages. Therefore it’s likely that a new batch of packages containing Qt 5.12 and KDE Applications 18.12 will see the light shortly after the New Year.

More in Tux Machines

Kernel: Virtualisation, BPF, and Btrfs

  • QEMU 5.1 Bringing Many CPU Improvements From Loongson To RISC-V To s390

    QEMU 5.1-rc0 is available as the first step towards this next feature release of this important component to the Linux virtualization stack. The QEMU 5.1-rc0 release marks the hard feature freeze for this next release. Weekly release candidates will continue until QEMU 5.1 is ready to ship around the middle of August.

  • Sleepable BPF programs

    When support for classic BPF was added to the kernel many years ago, there was no question of whether BPF programs could block in their execution. Their functionality was limited to examining a packet's contents and deciding whether the packet should be forwarded or not; there was nothing such a program could do to block. Since then, BPF has changed a lot, but the assumption that BPF programs cannot sleep has been built deeply into the BPF machinery. More recently, classic BPF has been pushed aside by the extended BPF dialect; the wider applicability of extended BPF is now forcing a rethink of some basic assumptions. BPF programs can now do many things that were not possible for classic BPF programs, including calling helper functions in the kernel, accessing data structures ("maps") shared with the kernel or user space, and synchronizing with spinlocks. The core assumption that BPF programs are atomic has not changed, though. Once the kernel jumps into a BPF program, that program must complete without doing anything that might put the thread it is running in to sleep. BPF programs themselves have no way of invoking any sort of blocking action, and the helper functions exported to BPF programs by the kernel are required to be atomic. As BPF gains functionality and grows toward some sort of sentient singularity moment, though, the inability to block is increasingly getting in the way. There has, thus, been interest in making BPF programs sleepable for some time now, and that interest has recently expressed itself as code in the form of this patch set from Alexei Starovoitov. The patch adds a new flag, BPF_F_SLEEPABLE, that can be used when loading BPF programs into the kernel; it marks programs that may sleep during their execution. That, in turn, informs the BPF verifier about the nature of the program, and brings a number of new restrictions into effect. Most of these restrictions are the result of the simple fact that the BPF subsystem was never designed with sleepable programs in mind. Parts of that subsystem have been updated to handle sleeping programs correctly, but many other parts have not. That is likely to change over time but, until then, the functionality implemented by any part of the BPF subsystem that still expects atomicity is off-limits to sleepable programs. For example, of the many types of BPF programs supported by the kernel, only two are allowed to block: those run from the Linux security module subsystem and tracing programs (BPF_PROG_TYPE_LSM and BPF_PROG_TYPE_TRACING). Even then, tracing programs can only sleep if they are attached to security hooks or are attached to functions that have been set up for error injection. Other types of programs are likely to be added in the future, but the coverage will never be universal. Many types of BPF programs are invoked from within contexts that, themselves, do not allow sleeping — deep within the network packet-processing code or attached to atomic functions, for example — so making those programs sleepable is just not going to happen.

  • Btrfs at Facebook

    The Btrfs filesystem has had a long and sometimes turbulent history; LWN first wrote about it in 2007. It offers features not found in any other mainline Linux filesystem, but reliability and performance problems have prevented its widespread adoption. There is at least one company that is using Btrfs on a massive scale, though: Facebook. At the 2020 Open Source Summit North America virtual event, Btrfs developer Josef Bacik described why and how Facebook has invested deeply in Btrfs and where the remaining challenges are. Every Facebook service, Bacik began, runs within a container; among other things, that makes it easy to migrate services between machines (or even between data centers). Facebook has a huge number of machines, so it is impossible to manage them in any sort of unique way; the company wants all of these machines to be as consistent as possible. It should be possible to move any service to any machine at any time. The company will, on occasion, bring down entire data centers to test how well its disaster-recovery mechanisms work.

today's howtos

Home Assistant improves performance in 0.112 release

The Home Assistant project has released version 0.112 of the open-source home automation hub we have previously covered, which is the eighth release of the project this year. While previous releases have largely focused on new integrations and enhancements to the front-end interface, in this release the focus has shifted more toward improving the performance of the database. It is important to be aware that there are significant database changes and multiple potential backward compatibility breaks to understand before attempting an upgrade to take advantage of the improvements. According to the release notes written by contributor Franck Nijhof, better performance has been a major goal of this release with a focus on both the logbook and history components. This builds on the work of the previous release (v0.111) from a performance perspective, which focused on reducing the time it takes to initialize the hub at startup. Read more

Android Leftovers