Language Selection

English French German Italian Portuguese Spanish

Arch-based Linux distro KaOS 2014.08 is here with KDE 4.14.0

Filed under
GNU
Linux

The Linux desktop community has reached a sad state. Ubuntu 14.04 was a disappointing release and Fedora is taking way too long between releases. Hell, OpenSUSE is an overall disaster. It is hard to recommend any Linux-based operating system beyond Mint. Even the popular KDE plasma environment and its associated programs are in a transition phase, moving from 4.x to 5.x. As exciting as KDE 5 may be, it is still not ready for prime-time; it is recommended to stay with 4 for now.

Read more

More in Tux Machines

IBM/Red Hat Leftovers

  • Red Hat and Samsung Collaborate to Drive 5G Adoption with Kubernetes-Based Networking for Service Providers

    Red Hat, Inc., the world's leading provider of open source solutions, today announced collaboration with Samsung to deliver 5G network solutions built on Red Hat OpenShift, the industry’s most comprehensive enterprise Kubernetes platform, and will help service providers make 5G a reality across use cases, including 5G core, edge computing, IoT, machine learning and more.

  • Red Hat wins the Bronze Stevie Award for Quarkus

    Red Hat’s Quarkus framework modernizes Java software by making it cloud-native Revolutionary open-source project helps applications consume 1/10th the memory and startup 300x faster when compared to traditional Java Quarkus helps Java maintain its platform leader status through modern innovation designed to meet the fast-paced, ever-changing demands of today’s businesses

  • Season 6: Meet the Inventors

    Inventors don’t always get the credit they deserve, even for world-changing breakthroughs. Season 6 of Command Line Heroes tells the stories of ingenious inventors who haven’t been given their full due. These heroes did nothing less than create new industries, dazzle our imaginations, and reshaped the world as we know it. The first episode drops October 13, 2020. Subscribe today and sign up for the newsletter to get the latest updates.

  • Removing run-time disabling for SELinux in Fedora

    Disabling SELinux is, perhaps sadly in some ways, a time-honored tradition for users of Fedora, RHEL, and other distributions that feature the security mechanism. Over the years, SELinux has gotten easier to tolerate due to the hard work of its developers and the distributions, but there are still third-party packages that recommend or require disabling SELinux in order to function. Up until fairly recently, the kernel has supported disabling SELinux at run time, but that mechanism has been deprecated—in part due to another kernel security feature. Now Fedora is planning to eliminate the ability to disable SELinux at run time in Fedora 34, which sparked some discussion in its devel mailing list. SELinux is a Linux Security Module (LSM) for enforcing mandatory access control (MAC) rules. But the "module" part of the LSM name has been a misnomer since a 2007 change to make the interface static and remove the option to load LSMs at run time. So kernels are built with a list of supported LSMs, and they can be enabled or disabled at boot time using kernel command-line options. Certain architectures had bootloaders that made it difficult for users to add parameters to the command line, though, so the SELinux developers added a way to disable it at run time. The need for that functionality has faded, and removing it will allow another kernel hardening feature to be used. The post-init read-only memory feature provides a way to mark certain kernel data structures as read-only after the kernel has initialized them. The idea is that various data structures are prime targets for kernel exploits; function-pointer structures, like those used by the LSM hooks, are of particular interest. So the LSM hooks were protected that way. However, that hardening is only enabled if the ability to disable SELinux at run time is not present in the kernel. The presence of the SELinux feature is governed by the CONFIG_SECURITY_SELINUX_DISABLE kernel build option. In order to get that hardening feature, Ben Cotton posted a proposal for Fedora 34 to remove the support for disabling SELinux at run time. The proposal is owned by Petr Lautrbach and Ondrej Mosnacek; it would migrate users to the selinux=0 command-line option if they are currently disabling SELinux via the SELINUX=disabled setting in /etc/selinux/config. The proposal, which has been updated on the Fedora wiki based on feedback, would not change the ability to switch SELinux between enforcing and permissive modes at run time using setenforce The 5.6 kernel deprecated the run-time-disable feature for SELinux. The kernel currently prints a message to that effect, but there are plans to make using it even more painful by sleeping for five seconds when it is used. It may get even more obnoxious over time; eventually the plan is to remove it altogether. Red Hat distributions (Fedora, CentOS, RHEL) are the only known users of the feature at this point, so once they have all moved away, the feature can be removed from the kernel. RHEL and CentOS systems will stick around for a lot longer than Fedora systems, since it is only supported for a bit over year. But Red Hat will just continue to maintain the feature in the RHEL/CentOS kernels; removing the run-time disable from Fedora presumably means that the next RHEL/CentOS major release will no longer support it either.

  • Beyond autonomous vehicles: how automakers are partnering to shape the future

    Autonomous driving is movie-level science fiction poised to become our everyday reality. To remain competitive and relevant, manufacturers are employing the latest autonomous capabilities and partnering to develop self-driving vehicles. There is no shortage of investor or consumer enthusiasm. Self-driving vehicles bask in the media spotlight, so it’s easy to overlook how hard automotive IT teams are working to transform the underlying infrastructure and processes needed to create that reality. The goal is to both support autonomous driving capabilities and, perhaps more importantly, improve their organizational agility, security, data focus, and ultimately, innovation.

Ubuntu 20.10 (Groovy Gorilla) Beta Is Now Available for Download

Development on Ubuntu 20.10 kicked off earlier this year, shortly after the launch of Ubuntu 20.04 LTS (Focal Fossa), but since it’s not a long-term supported (LTS) series, there aren’t any major new features and enhancements to be expected in the upcoming release. The biggest things you already know about them. Ubuntu 20.10 will be shipping with the latest and greatest Linux 5.8 kernel series, which, of course, brings better hardware support, as well as the latest and greatest GNOME 3.38 desktop environment, which I took for a first look this week. Read more

Debian: Sparky Linux, Mailman vs DKIM and Some Reports

  • Sparky news 2020/09

    The 9th monthly Sparky project and donate report of 2020: • Linux kernel updated up to version 5.8.12 & 5.9-rc5 • added to repos: Browsh, Ciano, Brackets, Cherrytree • Sparky 2020.09 of the rolling line released

  •  
  • Ian Jackson: Mailman vs DKIM - a novel solution

    Do not configure Mailman to replace the mail domains in From: headers. Instead, try out my small new program which can make your Mailman transparent, so that DKIM signatures survive. [...] DKIM is a new anti-spoofing mechanism for Internet email, intended to help fight spam. DKIM, paired with the DMARC policy system, has been remarkably successful at stemming the flood of joe-job spams. As usually deployed, DKIM works like this: When a message is originally sent, the author's MUA sends it to the MTA for their From: domain for outward delivery. The From: domain mailserver calculates a cryptographic signature of the message, and puts the signature in the headers of the message. Obviously not the whole message can be signed, since at the very least additional headers need to be added in transit, and sometimes headers need to be modified too. The signing MTA gets to decide what parts of the message are covered by the signature: they nominate the header fields that are covered by the signature, and specify how to handle the body. A recipient MTA looks up the public key for the From: domain in the DNS, and checks the signature. If the signature doesn't match, depending on policy (originator's policy, in the DNS, and recipient's policy of course), typically the message will be treated as spam.

  •  
  • Sylvain Beucler: Debian LTS and ELTS - September 2020

    Here is my transparent report for my work on the Debian Long Term Support (LTS) and Debian Extended Long Term Support (ELTS), which extend the security support for past Debian releases, as a paid contributor. In September, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 19.75h for LTS (out of my 30 max; all done) and 20h for ELTS (out of my 20 max; all done).

  •  
  • Molly de Blanc: Free Software Activities – September 2020

    I’m attempting to step down from the Outreach team, which is more work than I thought it would be. I had a very complicated relationship with the Outreach team. When no one else was there to take on making sure we did GSoC and Outreachy, I stepped up. It wasn’t really what I wanted to be doing, but it’s important. I’m glad to have more time to focus on other things that feel more aligned with what I’m trying to work on right now.

Audiocasts/Shows: GamingOnLinux, The Linux Experiment and Coc Explorer