Language Selection

English French German Italian Portuguese Spanish

About Tux Machines

Saturday, 20 Jan 18 - Tux Machines is a community-driven public service/news site which has been around for over a decade and primarily focuses on GNU/LinuxSubscribe now Syndicate content

Search This Site

Quick Roundup

Type Titlesort icon Author Replies Last Post
Story 1+ Year Running Arch Linux on a Lenovo Yoga 2 Roy Schestowitz 07/04/2015 - 9:38am
Story Lunar Linux 1.7.0 (i686 & x86_64) ISO’s released Rianne Schestowitz 12/10/2014 - 5:03am
Story Most Popular Desktop Video Player: VLC Roy Schestowitz 22/01/2014 - 5:31pm
Story 'One frickin' user interface for Linux' Roy Schestowitz 29/12/2014 - 5:12pm
Story A Dell 4K laptop with Linux: Tough construction and built for developers. Roy Schestowitz 27/03/2015 - 8:29am
Story Android (Linux) is creating more jobs than iPhone Roy Schestowitz 15/04/2014 - 7:53pm
Story Cinnamon PPA will no longer be maintained for Ubuntu users Roy Schestowitz 27/05/2014 - 7:44am
Story CyanogenMod support arrives for Amazon Kindle Fire HD Roy Schestowitz 23/04/2014 - 10:54am
Story Dell launches Android-based Venue tablets at Computex 2014 Rianne Schestowitz 03/06/2014 - 5:33pm
Story Elementary OS Freya Beta 1 Available For Developers And Testers Rianne Schestowitz 11/09/2014 - 4:33am

Raspberry Pi HAT connects up to three Pmod modules at once

Filed under
Linux
Hardware

Digilent and RS Components have launched a $15, Python supported “Pmod HAT Adapter” for the Raspberry Pi that can connect up to three Digilent Pmod peripheral modules at a time while also extending the 40-pin adapter.

Digilent has joined with distributor RS Components to co-launch a $15 DesignSpark Raspberry Pi Pmod HAT Adapter board that brings Digilent’s Pmod peripheral boards to the Raspberry Pi. The 65 x 56.5mm HAT compliant board offers three 2×6-pin Pmod ports with support for I2C, SPI, UART and GPIO interfaces. The Raspberry Pi’s 40-pin adapter is extended to make full use of the SBC’s interfaces.

Read more

KaOS 2018.01 KDE-focused Linux distro now available with Spectre and Meltdown fixes

Filed under
GNU
KDE
Linux

It can be difficult to find a quality Linux distribution that meets your needs. This is partly because there are just too many operating systems from which to choose. My suggestion is to first find a desktop environment that you prefer, and then narrow down your distro search to one that focuses on that DE. For instance, if you like KDE, both Kubuntu and Netrunner are solid choices.

With all of that said, there is another KDE-focused Linux distro that I highly recommend. Called "KaOS," it is rolling release, meaning you can alway be confident that your computer is running modern packages. Today, KaOS gets its first updated ISO for 2018, and you should definitely use it to upgrade your install media. Why? Because version 2018.01 has fixes for Spectre and Meltdown thanks to Linux kernel 4.14.14 with both AMD and Intel ucode.

Read more

KDE: Linux and Qt in Automotive, KDE Discover, Plasma5 18.01 in Slackware

Filed under
KDE
Slack
  • Linux and Qt in Automotive? Let’s meet up!

    For anyone around the Gothenburg area on Feb 1st, you are most welcome to the Automotive MeetUp held at the Pelagicore and Luxoft offices. There will be talks about Qt/QML, our embedded Linux platform PELUX and some ramblings about open source in automotive by yours truly Wink

  • What about AppImage?

    I see a lot of people asking about state of AppImage support in Discover.

    It’s non-existent, because AppImage does not require centralized software management interfaces like Discover and GNOME Software (or a command-line package manager). AppImage bundles are totally self-contained, and come straight from the developer with zero middlemen, and can be managed on the filesystem using your file manager

    This should sound awfully familiar to former Mac users (like myself), because Mac App bundles are totally self-contained, come straight from the developer with zero middlemen, and are managed using the Finder file manager.

  • What’s new for January? Plasma5 18.01, and more

    When I sat down to write a new post I noticed that I had not written a single post since the previous Plasma 5 announcement. Well, I guess the past month was a busy one. Also I bought a new e-reader (the Kobo Aura H2O 2nd edition) to replace my ageing Sony PRS-T1. That made me spend a lot of time just reading books and enjoying a proper back-lit E-ink screen. What I read? The War of the Flowers by Tad Williams, A Shadow all of Light by Fred Chappell, Persepolis Rising and several of the short stories (Drive, The Butcher of Anderson Station, The Churn and Strange Dogs) by James SA Corey and finally Red Sister by Mark Lawrence. All very much worth your time.

GNU/Linux: Live Patching, Gravity of Kubernetes, Welcome to 2018

Filed under
GNU
Linux
  • How Live Patching Has Improved Xen Virtualization

    The open-source Xen virtualization hypervisor is widely deployed by enterprises and cloud providers alike, which benefit from the continuous innovation that the project delivers.

    In a video interview with ServerWatch, Lars Kurth, Chairman of the Xen Project Advisory Board and Director, Open Source Solutions at Citrix, details some of the recent additions to Xen and how they are helping move the project forward.

  • The Gravity of Kubernetes

    Most new internet businesses started in the foreseeable future will leverage Kubernetes (whether they realize it or not). Many old applications are migrating to Kubernetes too.

    Before Kubernetes, there was no standardization around a specific distributed systems platform. Just like Linux became the standard server-side operating system for a single node, Kubernetes has become the standard way to orchestrate all of the nodes in your application.

    With Kubernetes, distributed systems tools can have network effects. Every time someone builds a new tool for Kubernetes, it makes all the other tools better. And it further cements Kubernetes as the standard.

  • Welcome to 2018

    The image of the technology industry as a whole suffered in 2017, and that process is likely to continue this year as well. That should lead to an increased level of introspection that will certainly affect the free-software community. Many of us got into free software to, among other things, make the world a better place. It is not at all clear that all of our activities are doing that, or what we should do to change that situation. Expect a lively conversation on how our projects should be run and what they should be trying to achieve.

    Some of that introspection will certainly carry into projects related to machine learning and similar topics. There will be more interesting AI-related free software in 2018, but it may not all be beneficial. How well will the world be served, for example, by a highly capable, free facial-recognition system and associated global database? Our community will be no more effective than anybody else at limiting progress of potentially freedom-reducing technologies, but we should try harder to ensure that our technologies promote and support freedom to the greatest extent possible.

    Our 2017 predictions missed the fact that an increasing number of security problems are being found at the hardware level. We'll not make the same mistake in 2018. Much of what we think of as "hardware" has a great deal of software built into it — highly proprietary software that runs at the highest privilege levels and which is not subject to third-party review. Of course that software has bugs and security issues of its own; it couldn't really be any other way. We will see more of those issues in 2018, and many of them are likely to prove difficult to fix.

Linux Kernel Development

Filed under
Development
Linux
  • New Sound Drivers Coming In Linux 4.16 Kernel

    Due to longtime SUSE developer Takashi Iwai going on holiday the next few weeks, he has already sent in the sound driver feature updates targeting the upcoming Linux 4.16 kernel cycle.

    The sound subsystem in Linux 4.16 sees continued changes to the ASoC code, clean-ups to the existing drivers, and a number of new drivers.

  • Varlink: a protocol for IPC

    One of the motivations behind projects like kdbus and bus1, both of which have fallen short of mainline inclusion, is to have an interprocess communication (IPC) mechanism available early in the boot process. The D-Bus IPC mechanism has a daemon that cannot be started until filesystems are mounted and the like, but what if the early boot process wants to perform IPC? A new project, varlink, was recently announced; it aims to provide IPC from early boot onward, though it does not really address the longtime D-Bus performance complaints that also served as motivation for kdbus and bus1.

    The announcement came from Harald Hoyer, but he credited Kay Sievers and Lars Karlitski with much of the work. At its core, varlink is simply a JSON-based protocol that can be used to exchange messages over any connection-oriented transport. No kernel "special sauce" (such as kdbus or bus1) is needed to support it as TCP or Unix-domain sockets will provide the necessary functionality. The messages can be used as a kind of remote procedure call (RPC) using an API defined in an interface file.

  • Statistics for the 4.15 kernel

    The 4.15 kernel is likely to require a relatively long development cycle as a result of the post-rc5 merge of the kernel page-table isolation patches. That said, it should be in something close to its final form, modulo some inevitable bug fixes. The development statistics for this kernel release look fairly normal, but they do reveal an unexpectedly busy cycle overall.

    This development cycle was supposed to be relatively calm after the anticipated rush to get work into the 4.14 long-term-support release. But, while 4.14 ended up with 13,452 non-merge changesets at release, 4.15-rc6 already has 14,226, making it one of the busiest releases in the kernel project's history. Only 4.9 (16,214 changesets) and 4.12 (14,570) brought in more work, and 4.15 may exceed 4.12 by the time it is finished. So far, 1,707 developers have contributed to this kernel; they added 725,000 lines of code while removing 407,000, for a net growth of 318,000 lines of code.

  • A new kernel polling interface

    Polling a set of file descriptors to see which ones can perform I/O without blocking is a useful thing to do — so useful that the kernel provides three different system calls (select(), poll(), and epoll_wait() — plus some variants) to perform it. But sometimes three is not enough; there is now a proposal circulating for a fourth kernel polling interface. As is usually the case, the motivation for this change is performance.
    On January 4, Christoph Hellwig posted a new polling API based on the asynchronous I/O (AIO) mechanism. This may come as a surprise to some, since AIO is not the most loved of kernel interfaces and it tends not to get a lot of attention. AIO allows for the submission of I/O operations without waiting for their completion; that waiting can be done at some other time if need be. The kernel has had AIO support since the 2.5 days, but it has always been somewhat incomplete. Direct file I/O (the original use case) works well, as does network I/O. Many other types of I/O are not supported for asynchronous use, though; attempts to use the AIO interface with them will yield synchronous behavior. In a sense, polling is a natural addition to AIO; the whole point of polling is usually to avoid waiting for operations to complete.

Security: OpenSSL, IoT, and LWN Coverage of 'Intelpocalypse'

Filed under
Security
  • Another Face to Face: Email Changes and Crypto Policy

    The OpenSSL OMC met last month for a two-day face-to-face meeting in London, and like previous F2F meetings, most of the team was present and we addressed a great many issues. This blog posts talks about some of them, and most of the others will get their own blog posts, or notices, later. Red Hat graciously hosted us for the two days, and both Red Hat and Cryptsoft covered the costs of their employees who attended.

    One of the overall threads of the meeting was about increasing the transparency of the project. By default, everything should be done in public. We decided to try some major changes to email and such.

  • Some Basic Rules for Securing Your IoT Stuff

    Throughout 2016 and 2017, attacks from massive botnets made up entirely of hacked [sic] IoT devices had many experts warning of a dire outlook for Internet security. But the future of IoT doesn’t have to be so bleak. Here’s a primer on minimizing the chances that your IoT things become a security liability for you or for the Internet at large.

  • A look at the handling of Meltdown and Spectre

    The Meltdown/Spectre debacle has, deservedly, reached the mainstream press and, likely, most of the public that has even a remote interest in computers and security. It only took a day or so from the accelerated disclosure date of January 3—it was originally scheduled for January 9—before the bugs were making big headlines. But Spectre has been known for at least six months and Meltdown for nearly as long—at least to some in the industry. Others that were affected were completely blindsided by the announcements and have joined the scramble to mitigate these hardware bugs before they bite users. Whatever else can be said about Meltdown and Spectre, the handling (or, in truth, mishandling) of this whole incident has been a horrific failure.

    For those just tuning in, Meltdown and Spectre are two types of hardware bugs that affect most modern CPUs. They allow attackers to cause the CPU to do speculative execution of code, while timing memory accesses to deduce what has or has not been cached, to disclose the contents of memory. These disclosures can span various security boundaries such as between user space and the kernel or between guest operating systems running in virtual machines. For more information, see the LWN article on the flaws and the blog post by Raspberry Pi founder Eben Upton that well describes modern CPU architectures and speculative execution to explain why the Raspberry Pi is not affected.

  • Addressing Meltdown and Spectre in the kernel

    When the Meltdown and Spectre vulnerabilities were disclosed on January 3, attention quickly turned to mitigations. There was already a clear defense against Meltdown in the form of kernel page-table isolation (KPTI), but the defenses against the two Spectre variants had not been developed in public and still do not exist in the mainline kernel. Initial versions of proposed defenses have now been disclosed. The resulting picture shows what has been done to fend off Spectre-based attacks in the near future, but the situation remains chaotic, to put it lightly.

    First, a couple of notes with regard to Meltdown. KPTI has been merged for the 4.15 release, followed by a steady trickle of fixes that is undoubtedly not yet finished. The X86_BUG_CPU_INSECURE processor bit is being renamed to X86_BUG_CPU_MELTDOWN now that the details are public; there will be bug flags for the other two variants added in the near future. 4.9.75 and 4.4.110 have been released with their own KPTI variants. The older kernels do not have mainline KPTI, though; instead, they have a backport of the older KAISER patches that more closely matches what distributors shipped. Those backports have not fully stabilized yet either. KPTI patches for ARM are circulating, but have not yet been merged.

  • Is it time for open processors?

    The disclosure of the Meltdown and Spectre vulnerabilities has brought a new level of attention to the security bugs that can lurk at the hardware level. Massive amounts of work have gone into improving the (still poor) security of our software, but all of that is in vain if the hardware gives away the game. The CPUs that we run in our systems are highly proprietary and have been shown to contain unpleasant surprises (the Intel management engine, for example). It is thus natural to wonder whether it is time to make a move to open-source hardware, much like we have done with our software. Such a move may well be possible, and it would certainly offer some benefits, but it would be no panacea.

    Given the complexity of modern CPUs and the fierceness of the market in which they are sold, it might be surprising to think that they could be developed in an open manner. But there are serious initiatives working in this area; the idea of an open CPU design is not pure fantasy. A quick look around turns up several efforts; the following list is necessarily incomplete.

  • Notes from the Intelpocalypse

    Rumors of an undisclosed CPU security issue have been circulating since before LWN first covered the kernel page-table isolation patch set in November 2017. Now, finally, the information is out — and the problem is even worse than had been expected. Read on for a summary of these issues and what has to be done to respond to them in the kernel.
    All three disclosed vulnerabilities take advantage of the CPU's speculative execution mechanism. In a simple view, a CPU is a deterministic machine executing a set of instructions in sequence in a predictable manner. Real-world CPUs are more complex, and that complexity has opened the door to some unpleasant attacks.

    A CPU is typically working on the execution of multiple instructions at once, for performance reasons. Executing instructions in parallel allows the processor to keep more of its subunits busy at once, which speeds things up. But parallel execution is also driven by the slowness of access to main memory. A cache miss requiring a fetch from RAM can stall the execution of an instruction for hundreds of processor cycles, with a clear impact on performance. To minimize the amount of time it spends waiting for data, the CPU will, to the extent it can, execute instructions after the stalled one, essentially reordering the code in the program. That reordering is often invisible, but it occasionally leads to the sort of fun that caused Documentation/memory-barriers.txt to be written.

US Sanctions Against Chinese Android Phones, LWN Report on Eelo

Filed under
Android
  • A new bill would ban the US government from using Huawei and ZTE phones

    US lawmakers have long worried about the security risks posed the alleged ties between Chinese companies Huawei and ZTE and the country’s government. To that end, Texas Representative Mike Conaway introduced a bill last week called Defending U.S. Government Communications Act, which aims to ban US government agencies from using phones and equipment from the companies.

    Conaway’s bill would prohibit the US government from purchasing and using “telecommunications equipment and/or services,” from Huawei and ZTE. In a statement on his site, he says that technology coming from the country poses a threat to national security, and that use of this equipment “would be inviting Chinese surveillance into all aspects of our lives,” and cites US Intelligence and counterintelligence officials who say that Huawei has shared information with state leaders, and that the its business in the US is growing, representing a further security risk.

  • U.S. lawmakers urge AT&T to cut commercial ties with Huawei - sources

    U.S. lawmakers are urging AT&T Inc, the No. 2 wireless carrier, to cut commercial ties to Chinese phone maker Huawei Technologies Co Ltd and oppose plans by telecom operator China Mobile Ltd to enter the U.S. market because of national security concerns, two congressional aides said.

    The warning comes after the administration of U.S. President Donald Trump took a harder line on policies initiated by his predecessor Barack Obama on issues ranging from Beijing’s role in restraining North Korea to Chinese efforts to acquire U.S. strategic industries.

    Earlier this month, AT&T was forced to scrap a plan to offer its customers Huawei [HWT.UL] handsets after some members of Congress lobbied against the idea with federal regulators, sources told Reuters.

  • Eelo seeks to make a privacy-focused phone

    A focus on privacy is a key feature being touted by a number of different projects these days—from KDE to Tails to Nextcloud. One of the biggest privacy leaks for most people is their phone, so it is no surprise that there are projects looking to address that as well. A new entrant in that category is eelo, which is a non-profit project aimed at producing not only a phone, but also a suite of web services. All of that could potentially replace the Google or Apple mothership, which tend to collect as much personal data as possible.

Mozilla: Resource Hogs, Privacy Month, Firefox Census, These Weeks in Firefox

Filed under
Moz/FF
  • Firefox Quantum Eats RAM Like Chrome

    For a long time, Mozilla’s Firefox has been my web browser of choice. I have always preferred it to using Google’s Chrome, because of its simplicity and reasonable system resource (especially RAM) usage. On many Linux distributions such as Ubuntu, Linux Mint and many others, Firefox even comes installed by default.

    Recently, Mozilla released a new, powerful and faster version of Firefox called Quantum. And according to the developers, it’s new with a “powerful engine that’s built for rapid-fire performance, better, faster page loading that uses less computer memory.”

  • Mozilla Communities Speaker Series #PrivacyMonth

    As a part of the Privacy Month initiative, Mozilla volunteers are hosting a couple of speaker series webinars on Privacy, Security and related topics. The webinars will see renowned speakers talking to us about their work around privacy, how to take control of your digital self, some privacy-security tips and much more.

  • “Ewoks or Porgs?” and Other Important Questions

    You ever go to a party where you decide to ask people REAL questions about themselves, rather than just boring chit chat? Us, too! That’s why we’ve included questions that really hone in on the important stuff in our 2nd Annual Firefox Census.

  • These Weeks in Firefox: Issue 30

Red Hat Corporate News

Filed under
Red Hat

Slack as a Snap

Filed under
Software
Ubuntu
  • In a Snap, Slack Comes to Linux. Here's How To Install It

    While binaries for Slack have been available for Ubuntu and Fedora, other Linux operating systems are not so lucky. To overcome this, Canonical has released Slack as a Snap, which allows Slack to be installed and used on a greater variety of Linux distributions.

    Snapcraft is a command line tool that allows you to install containerised applications called Snaps on many different Linux distribution. As these Snap containers contain all the required dependencies that a program needs to run, it makes it very easy to create and distribute a single container that works on a variety of Linux versions.

  • Linux Users Can Now Download Slack as a ‘Snap’

    Slack is one step closer to becoming the workplace staple for businesses across the globe. The software is now available for use on Linux environments, bundled as a Snap – an application package for opensource systems.

    Tens of millions of users across the world run Linux on their systems, opting for one among its many distribution avatars. In comparison, Slack reported that over 6 million active profiles used the app daily last year, 2 million of them with paid subscriptions. The new release could open Slack up to a whole new set of customers.

  • Slack has arrived on Linux thanks to Canonical Snap

    CANONICAL HAS made the wishes of its users come true again as it brings another major app to Linux users for the first time.

    This time it's popular team platform Slack. The secret sauce is Ubuntu's "Snap" packages, a form of containerisation which puts an app into a little bubble that makes it run in the Linux environment. At Christmas, the technique was used to bring a desktop Spotify to Linux for the first time.

    The important thing here is that Snaps, first launched in 2016, run on any Linux distro, not just Canonical's own Ubuntu. Named specifically were Linux Mint, Manjaro, Debian, ArchLinux, OpenSUSE and Solus. Not only that, they work across desktop, server, cloud and IoT.

Linux Foundation: Upcoming Free Webinars, ONAP, Hyperledger

Filed under
Linux

Linux Gaming For Older/Lower-End Graphics Cards In 2018

Filed under
Graphics/Benchmarks
Gaming

A request came in this week to look at how low-end and older graphics cards are performing with current generation Linux games on OpenGL and Vulkan. With ten older/lower-end NVIDIA GeForce and AMD Radeon graphics cards, here is a look at their performance with a variety of native Linux games atop Ubuntu using the latest Radeon and NVIDIA drivers.

Read more

Also: Wine 3.0 open-source compatibility layer now available

Red Hat Patch Warning

Filed under
Red Hat
Security
  • We Didn't Pull CPU Microcode Update to Pass the Buck
  • Red Hat Will Revert Spectre Patches After Receiving Reports of Boot Issues

    Red Hat is releasing updates that are reverting previous patches for the Spectre vulnerability (Variant 2, aka CVE-2017-5715) after customers complained that some systems were failing to boot.

    "Red Hat is no longer providing microcode to address Spectre, variant 2, due to instabilities introduced that are causing customer systems to not boot," the company said yesterday.

    "The latest microcode_ctl and linux-firmware packages are reverting these unstable microprocessor firmware changes to versions that were known to be stable and well tested, released prior to the Spectre/Meltdown embargo lift date on Jan 3rd," Red Had added.

Security: Updates, SOS Fund, IR, ME, and WPA

Filed under
Security
  • Security updates for Friday
  • Seeking SOS Fund Projects

    I’m spending some time over the next few days looking for the next round of projects which might benefit from an SOS Fund security audit.

  • Strong Incident Response Starts with Careful Preparation

    Through working every day with organizations’ incident response (IR) teams, I am confronted with the entire spectrum of operational maturity. However, even in the companies with robust IR functions, the rapidly evolving threat landscape, constantly changing best practices, and surplus of available tools make it easy to overlook important steps during planning. As a result, by the time an incident occurs, it’s too late to improve their foundational procedures.

  • The Intel Management Engine: an attack on computer users' freedom

    Over time, Intel imposed the Management Engine on all Intel computers, removed the ability for computer users and manufacturers to disable it, and extended its control over the computer to nearly 100%. It even has access to the main computer's memory.

  • What Is WPA3, and When Will I Get It On My Wi-Fi?

    WPA2 is a security standard that governs what happens when you connect to a closed Wi-Fi network using a password. WPA2 defines the protocol a router and Wi-Fi client devices use to perform the “handshake” that allows them to securely connect and how they communicate. Unlike the original WPA standard, WPA2 requires implementation of strong AES encryption that is much more difficult to crack. This encryption ensures that a Wi-Fi access point (like a router) and a Wi-Fi client (like a laptop or phone) can communicate wirelessly without their traffic being snooped on.

First Impressions: Asus Tinkerboard and Docker

Filed under
Linux
Hardware

The board's standard OS is TinkerOS - a Linux variant of Debian 9. I've also read that Android is available but that doesn't interest us here. While Android may use forms of containerisation under the hood it doesn't mix with Docker containers.

Rather than trying TinkerOS I flashed Armbian's release of Ubuntu 16.04.03. The stable build on the download page contains a full desktop, but if you want to run the board headless (like I do) then you can find a smaller image on the "other downloads" link.

I initially used the stable image but had to swap to the nightly build due to a missing kernel module for Kubernetes networking. Having looked this up on Google I found the nightly build contained the fix to turn on the missing module.

Read more

PlayOnLinux For Easier Use Of Wine

Filed under
Linux

PlayOnLinux is a free program that helps to install, run, and manage Windows software on Linux. It can also manage virtual C: drives (known as Wine prefixes), and download and install certain Windows libraries for getting some software to run on Wine properly. Creating different drives using different Wine versions is also possible. It is very handy because what runs well in one version may not run as well (if at all) on a newer version. There is PlayOnMac for macOS and PlayOnBSD for FreeBSD.

Read<br />
more

Syndicate content

More in Tux Machines

KDE: Linux and Qt in Automotive, KDE Discover, Plasma5 18.01 in Slackware

  • Linux and Qt in Automotive? Let’s meet up!
    For anyone around the Gothenburg area on Feb 1st, you are most welcome to the Automotive MeetUp held at the Pelagicore and Luxoft offices. There will be talks about Qt/QML, our embedded Linux platform PELUX and some ramblings about open source in automotive by yours truly ;-)
  • What about AppImage?
    I see a lot of people asking about state of AppImage support in Discover. It’s non-existent, because AppImage does not require centralized software management interfaces like Discover and GNOME Software (or a command-line package manager). AppImage bundles are totally self-contained, and come straight from the developer with zero middlemen, and can be managed on the filesystem using your file manager This should sound awfully familiar to former Mac users (like myself), because Mac App bundles are totally self-contained, come straight from the developer with zero middlemen, and are managed using the Finder file manager.
  • What’s new for January? Plasma5 18.01, and more
    When I sat down to write a new post I noticed that I had not written a single post since the previous Plasma 5 announcement. Well, I guess the past month was a busy one. Also I bought a new e-reader (the Kobo Aura H2O 2nd edition) to replace my ageing Sony PRS-T1. That made me spend a lot of time just reading books and enjoying a proper back-lit E-ink screen. What I read? The War of the Flowers by Tad Williams, A Shadow all of Light by Fred Chappell, Persepolis Rising and several of the short stories (Drive, The Butcher of Anderson Station, The Churn and Strange Dogs) by James SA Corey and finally Red Sister by Mark Lawrence. All very much worth your time.

GNU/Linux: Live Patching, Gravity of Kubernetes, Welcome to 2018

  • How Live Patching Has Improved Xen Virtualization
    The open-source Xen virtualization hypervisor is widely deployed by enterprises and cloud providers alike, which benefit from the continuous innovation that the project delivers. In a video interview with ServerWatch, Lars Kurth, Chairman of the Xen Project Advisory Board and Director, Open Source Solutions at Citrix, details some of the recent additions to Xen and how they are helping move the project forward.
  • The Gravity of Kubernetes
    Most new internet businesses started in the foreseeable future will leverage Kubernetes (whether they realize it or not). Many old applications are migrating to Kubernetes too. Before Kubernetes, there was no standardization around a specific distributed systems platform. Just like Linux became the standard server-side operating system for a single node, Kubernetes has become the standard way to orchestrate all of the nodes in your application. With Kubernetes, distributed systems tools can have network effects. Every time someone builds a new tool for Kubernetes, it makes all the other tools better. And it further cements Kubernetes as the standard.
  • Welcome to 2018
    The image of the technology industry as a whole suffered in 2017, and that process is likely to continue this year as well. That should lead to an increased level of introspection that will certainly affect the free-software community. Many of us got into free software to, among other things, make the world a better place. It is not at all clear that all of our activities are doing that, or what we should do to change that situation. Expect a lively conversation on how our projects should be run and what they should be trying to achieve. Some of that introspection will certainly carry into projects related to machine learning and similar topics. There will be more interesting AI-related free software in 2018, but it may not all be beneficial. How well will the world be served, for example, by a highly capable, free facial-recognition system and associated global database? Our community will be no more effective than anybody else at limiting progress of potentially freedom-reducing technologies, but we should try harder to ensure that our technologies promote and support freedom to the greatest extent possible. Our 2017 predictions missed the fact that an increasing number of security problems are being found at the hardware level. We'll not make the same mistake in 2018. Much of what we think of as "hardware" has a great deal of software built into it — highly proprietary software that runs at the highest privilege levels and which is not subject to third-party review. Of course that software has bugs and security issues of its own; it couldn't really be any other way. We will see more of those issues in 2018, and many of them are likely to prove difficult to fix.

Linux Kernel Development

  • New Sound Drivers Coming In Linux 4.16 Kernel
    Due to longtime SUSE developer Takashi Iwai going on holiday the next few weeks, he has already sent in the sound driver feature updates targeting the upcoming Linux 4.16 kernel cycle. The sound subsystem in Linux 4.16 sees continued changes to the ASoC code, clean-ups to the existing drivers, and a number of new drivers.
  • Varlink: a protocol for IPC
    One of the motivations behind projects like kdbus and bus1, both of which have fallen short of mainline inclusion, is to have an interprocess communication (IPC) mechanism available early in the boot process. The D-Bus IPC mechanism has a daemon that cannot be started until filesystems are mounted and the like, but what if the early boot process wants to perform IPC? A new project, varlink, was recently announced; it aims to provide IPC from early boot onward, though it does not really address the longtime D-Bus performance complaints that also served as motivation for kdbus and bus1. The announcement came from Harald Hoyer, but he credited Kay Sievers and Lars Karlitski with much of the work. At its core, varlink is simply a JSON-based protocol that can be used to exchange messages over any connection-oriented transport. No kernel "special sauce" (such as kdbus or bus1) is needed to support it as TCP or Unix-domain sockets will provide the necessary functionality. The messages can be used as a kind of remote procedure call (RPC) using an API defined in an interface file.
  • Statistics for the 4.15 kernel
    The 4.15 kernel is likely to require a relatively long development cycle as a result of the post-rc5 merge of the kernel page-table isolation patches. That said, it should be in something close to its final form, modulo some inevitable bug fixes. The development statistics for this kernel release look fairly normal, but they do reveal an unexpectedly busy cycle overall. This development cycle was supposed to be relatively calm after the anticipated rush to get work into the 4.14 long-term-support release. But, while 4.14 ended up with 13,452 non-merge changesets at release, 4.15-rc6 already has 14,226, making it one of the busiest releases in the kernel project's history. Only 4.9 (16,214 changesets) and 4.12 (14,570) brought in more work, and 4.15 may exceed 4.12 by the time it is finished. So far, 1,707 developers have contributed to this kernel; they added 725,000 lines of code while removing 407,000, for a net growth of 318,000 lines of code.
  • A new kernel polling interface
    Polling a set of file descriptors to see which ones can perform I/O without blocking is a useful thing to do — so useful that the kernel provides three different system calls (select(), poll(), and epoll_wait() — plus some variants) to perform it. But sometimes three is not enough; there is now a proposal circulating for a fourth kernel polling interface. As is usually the case, the motivation for this change is performance. On January 4, Christoph Hellwig posted a new polling API based on the asynchronous I/O (AIO) mechanism. This may come as a surprise to some, since AIO is not the most loved of kernel interfaces and it tends not to get a lot of attention. AIO allows for the submission of I/O operations without waiting for their completion; that waiting can be done at some other time if need be. The kernel has had AIO support since the 2.5 days, but it has always been somewhat incomplete. Direct file I/O (the original use case) works well, as does network I/O. Many other types of I/O are not supported for asynchronous use, though; attempts to use the AIO interface with them will yield synchronous behavior. In a sense, polling is a natural addition to AIO; the whole point of polling is usually to avoid waiting for operations to complete.

Security: OpenSSL, IoT, and LWN Coverage of 'Intelpocalypse'

  • Another Face to Face: Email Changes and Crypto Policy
    The OpenSSL OMC met last month for a two-day face-to-face meeting in London, and like previous F2F meetings, most of the team was present and we addressed a great many issues. This blog posts talks about some of them, and most of the others will get their own blog posts, or notices, later. Red Hat graciously hosted us for the two days, and both Red Hat and Cryptsoft covered the costs of their employees who attended. One of the overall threads of the meeting was about increasing the transparency of the project. By default, everything should be done in public. We decided to try some major changes to email and such.
  • Some Basic Rules for Securing Your IoT Stuff

    Throughout 2016 and 2017, attacks from massive botnets made up entirely of hacked [sic] IoT devices had many experts warning of a dire outlook for Internet security. But the future of IoT doesn’t have to be so bleak. Here’s a primer on minimizing the chances that your IoT things become a security liability for you or for the Internet at large.

  • A look at the handling of Meltdown and Spectre
    The Meltdown/Spectre debacle has, deservedly, reached the mainstream press and, likely, most of the public that has even a remote interest in computers and security. It only took a day or so from the accelerated disclosure date of January 3—it was originally scheduled for January 9—before the bugs were making big headlines. But Spectre has been known for at least six months and Meltdown for nearly as long—at least to some in the industry. Others that were affected were completely blindsided by the announcements and have joined the scramble to mitigate these hardware bugs before they bite users. Whatever else can be said about Meltdown and Spectre, the handling (or, in truth, mishandling) of this whole incident has been a horrific failure. For those just tuning in, Meltdown and Spectre are two types of hardware bugs that affect most modern CPUs. They allow attackers to cause the CPU to do speculative execution of code, while timing memory accesses to deduce what has or has not been cached, to disclose the contents of memory. These disclosures can span various security boundaries such as between user space and the kernel or between guest operating systems running in virtual machines. For more information, see the LWN article on the flaws and the blog post by Raspberry Pi founder Eben Upton that well describes modern CPU architectures and speculative execution to explain why the Raspberry Pi is not affected.
  • Addressing Meltdown and Spectre in the kernel
    When the Meltdown and Spectre vulnerabilities were disclosed on January 3, attention quickly turned to mitigations. There was already a clear defense against Meltdown in the form of kernel page-table isolation (KPTI), but the defenses against the two Spectre variants had not been developed in public and still do not exist in the mainline kernel. Initial versions of proposed defenses have now been disclosed. The resulting picture shows what has been done to fend off Spectre-based attacks in the near future, but the situation remains chaotic, to put it lightly. First, a couple of notes with regard to Meltdown. KPTI has been merged for the 4.15 release, followed by a steady trickle of fixes that is undoubtedly not yet finished. The X86_BUG_CPU_INSECURE processor bit is being renamed to X86_BUG_CPU_MELTDOWN now that the details are public; there will be bug flags for the other two variants added in the near future. 4.9.75 and 4.4.110 have been released with their own KPTI variants. The older kernels do not have mainline KPTI, though; instead, they have a backport of the older KAISER patches that more closely matches what distributors shipped. Those backports have not fully stabilized yet either. KPTI patches for ARM are circulating, but have not yet been merged.
  • Is it time for open processors?
    The disclosure of the Meltdown and Spectre vulnerabilities has brought a new level of attention to the security bugs that can lurk at the hardware level. Massive amounts of work have gone into improving the (still poor) security of our software, but all of that is in vain if the hardware gives away the game. The CPUs that we run in our systems are highly proprietary and have been shown to contain unpleasant surprises (the Intel management engine, for example). It is thus natural to wonder whether it is time to make a move to open-source hardware, much like we have done with our software. Such a move may well be possible, and it would certainly offer some benefits, but it would be no panacea. Given the complexity of modern CPUs and the fierceness of the market in which they are sold, it might be surprising to think that they could be developed in an open manner. But there are serious initiatives working in this area; the idea of an open CPU design is not pure fantasy. A quick look around turns up several efforts; the following list is necessarily incomplete.
  • Notes from the Intelpocalypse
    Rumors of an undisclosed CPU security issue have been circulating since before LWN first covered the kernel page-table isolation patch set in November 2017. Now, finally, the information is out — and the problem is even worse than had been expected. Read on for a summary of these issues and what has to be done to respond to them in the kernel. All three disclosed vulnerabilities take advantage of the CPU's speculative execution mechanism. In a simple view, a CPU is a deterministic machine executing a set of instructions in sequence in a predictable manner. Real-world CPUs are more complex, and that complexity has opened the door to some unpleasant attacks. A CPU is typically working on the execution of multiple instructions at once, for performance reasons. Executing instructions in parallel allows the processor to keep more of its subunits busy at once, which speeds things up. But parallel execution is also driven by the slowness of access to main memory. A cache miss requiring a fetch from RAM can stall the execution of an instruction for hundreds of processor cycles, with a clear impact on performance. To minimize the amount of time it spends waiting for data, the CPU will, to the extent it can, execute instructions after the stalled one, essentially reordering the code in the program. That reordering is often invisible, but it occasionally leads to the sort of fun that caused Documentation/memory-barriers.txt to be written.