Language Selection

English French German Italian Portuguese Spanish

Vive La Desktop Difference!

Filed under

The Free Agent e-mail box fills each month with notes from people who are brand new to Linux. It is great to hear from so many people who are trying out Free Software for the first time, but sometimes the mail is predictable.

For instance, this has appeared in my inbox dozens of times: "Should I use KDE or Gnome?" Oh, how I have grown weary of this question. (It's a perennial favorite on newsgroups and forums, too.) Not that it's stupid at all--it's actually a natural question for a user arriving from the land of commercial operating systems, where you don't have this sort of choice. "What? You mean I have two interfaces to choose from?" Yeah, something like that. (I'll not confuse anyone with lesser-known alternatives at the moment.)

So, KDE or Gnome? Not a stupid question--but in my mind, kind of a silly one. Car/computer analogies always hold up well, so let's try one here: If you, dear reader, wrote in asking whether I think you should drive a Mini Cooper or a Hummer, how should I respond? My best bet is to offer no opinion. I know nothing of your preferences or your needs. Either vehicle will get you where you want to go. The difference will be in the experience of getting there. It's the same deal with KDE and Gnome.

Linus Torvalds, the creator of the Linux kernel, recently raised a stir on a public mailing list with some inflammatory comments about the Gnome desktop. He wrote, in part: "This 'users are idiots, and are confused by functionality' mentality of Gnome is a disease. If you think your users are idiots, only idiots will use it. I don't use Gnome, because in striving to be simple, it has long since reached the point where it simply doesn't do what I need it to do. Please, just tell people to use KDE."

This is a classic straw-man argument. I've met more than a few Gnome developers, and I watch their online discussions unfold all the time; I'm here to tell you that they don't believe that "users are idiots, and are confused by functionality." But it sure makes them sound misguided when you frame things that way, doesn't it?

Full Article.

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