By the end of the merge window, 12,632 non-merge changesets had been pulled into the mainline repository for the 5.5 release. This is thus a busy development cycle — just like the cycles that preceded it. Just over half of those changesets were pulled after the writing of our first 5.5 merge-window summary. As is often the case later in the merge window, many of those changes were relatively boring fixes. There were still a number of interesting changes, though; read on for a summary of what happened in the second half of this merge window.

A "split lock" is a low-level memory-bus lock taken by the processor for a memory range that crosses a cache line. Most processors disallow split locks, but x86 implements them. Split locking may be convenient for developers, but it comes at a cost: a single split-locked instruction can occupy the memory bus for around 1,000 clock cycles. It is thus understandable that interest in eliminating split-lock operations is high. What is perhaps less understandable is that a patch set intended to detect split locks has been pending since (at least) May 2018, and it still is not poised to enter the mainline.

Split locks are, in essence, a type of misaligned memory access — something that the x86 architecture has always been relatively willing to forgive. But there is a difference: while a normal unaligned operation will slow down the process performing that operation, split locks will slow down the entire system. The 1,000-cycle delay may be particularly painful on realtime systems, but split locks can be used as an effective denial-of-service attack on any system. There is little disagreement among developers that their use should not be allowed on most systems.

Recent Intel processors can be configured to execute a trap when a split lock is attempted, allowing the operating system to decide whether to allow the operation to continue. Fenghua Yu first posted a patch set enabling this trap in May 2018; LWN covered this work one year later. While many things have changed in this patch set, the basic idea has remained constant: when this feature is enabled, user-space processes that attempt a split lock will receive a SIGBUS signal. What happens when split locks are created in other contexts has varied over time; in the version-10 patch set posted in late November, split locks in the kernel or system firmware will cause a kernel panic.

For many developers, distributed deployment of an application is often achieved using a cloud-native approach with the Kubernetes container orchestration platform. Ray is orthogonal to Kubernetes as it runs on top of Kubernetes as well as laptops, and on public clouds, Stoica said.

In Stoica's view, Kubernetes makes it easy to deploy and manage different applications on the same cluster and is targeted at DevOps. That said, he noted that Kubernetes doesn’t solve the problem of actually making it easy to develop distributed apps. For example, to implement a large-scale reinforcement learning application today, the application needs to handle the logic for scheduling tasks, handling machine failures, efficiently transferring data and so on. Kubernetes simply runs applications once they have been developed, he added.

The Kubernetes scheduler is being overhauled with a series of improvements that will introduce a new framework and enhanced capabilities that could help cluster administrators to optimize performance and utilization. Abdullah Gharaibeh, co-chair of the Kubernetes scheduling special interest group (SIG Scheduling), detailed what has been happening with the scheduler in recent releases and what's on the roadmap in a session at KubeCon + CloudNativeCon North America 2019.

The scheduler component of Kubernetes is a controller that assigns pods to nodes. A Kubernetes pod is a group of containers that is scheduled together, while a node is a worker machine (real or virtual) within the cluster that has all the services needed to run a pod.

Gharaibeh explained that as pods are created they are added into a scheduling queue that is sorted by priority and then processed through two phases. In the first, the pod is run through a filter that makes a determination of what nodes are feasible for that pod to run on. For example, the filter checks to make sure the node has enough resources (CPU and memory) to run the pod. The pods then go through the scoring phase, where the pods are ranked according to additional criteria such as node affinity. If for some reason a pod ends up with no feasible nodes it will be placed back into the queue so it can be scheduled when that becomes possible.

[...]

The Kubernetes Enhancement Proposal (KEP) for the scheduling framework outlines all of the different extension points for plugins. One of the key extension points is called "queue sort", which he said enables an administrator to define a single plugin that defines how the default scheduling queue will be sorted. That's different than the current default scheduling behavior where pods are sorted by priority.

Other extension points include "pre-filter", which checks to make sure that certain pod conditions are met, and "filter", which is used to rule out nodes that can't run a given pod. The "reserve" extension point provides an opportunity to help better schedule pods that are running applications or services that need to maintain state, according to the KEP. "Plugins which maintain runtime state (aka 'stateful plugins') should use this extension point to be notified by the scheduler when resources on a node are being reserved for a given Pod."

The framework also includes what are known as permit plugins, which allow other scheduling plugins to delay binding a pod to a node until a specific condition has been satisfied. Gharaibeh noted that the permit plugins can be useful to enable gang scheduling of a group of pods that need to all be deployed at the same time. "One interesting use case we had was trying to make the scheduler friendlier for batch workloads," he said.

Overall, Gharaibeh emphasized that the scheduling framework will make it easier for Kubernetes developers to extend and add new features into the scheduler. The scheduling framework is currently targeted for the Kubernetes 1.19 milestone, which will be out in mid-2020.

CloudForms is Red Hat’s supported version of upstream ManageIQ, an infrastructure management platform. It lets you see, manage and deploy to various platforms like OpenStack, VMWare, RHEV, OpenShift and public cloud like AWS and Azure, with single pane of glass view across them all. It has its own orchestration engine but also integrates with Ansible for automated deployments.

As best I can tell, their CloudForms updated Statement of Direction article (behind paywall, sorry) shows that Red Hat is killing off support for non-Red Hat platforms like VMware, AWS, Azure, etc. The justification is to focus on open platforms, which I think means CloudForms will ultimately disappear entirely with Red Hat focusing on OpenShift instead.

Do you need to run a script whenever your Raspberry Pi turns on? Here’s Estefannie to explain how to edit crontab to do exactly that.

Compared to the inaugural Rav1e 0.1 release just over one month ago, Rav1e 0.2 was released on Wednesday with 40~70% better performance depending upon the encode settings. 

Since the rav1e 0.1 release in early November there has been various optimizations like more Assembly optimizations and forward-transform SIMD. That has now culminated with the release of rav1e 0.2 as the newest official release and succeeding the recent weekly-ish snapshots. 

Since 2010, the LibrePlanet wiki has provided a space for connection between free software activists, with the following mission statement: "To empower a global network of both local and project-based teams, all working together to advance free software as a social movement for user freedom."

This idea of participation and space for connection between free software activists is what motivates both the wiki and the Free Software Foundation's (FSF) yearly conference by the same name. Our LibrePlanet wiki uses the same software as what powers Wikipedia, which makes it the perfect tool for global collaborative work. We use the wiki as a tool to help organize free software supporters all over the world, so everyone can collaborate around their projects and ideas, as well as communicate with each other using our mailing lists for discussion and development, and our #LibrePlanet IRC channel on Freenode.

LibrePlanet is about spreading the free software ideals, organizing activists and supporters of the free software philosophy, as well as about organizing GNU/Linux, or other technology-specific user groups. The site can be used for a broad range of uses, by expert software developers and budding community activists alike.

We have brought you twelve Core Updates - each packed with lots of new features, improvements and some with just security fixes. A special thank you for Intel again, which kept us especially busy with their hardware bugs, their deceiving marketing campaigns to play down those problems, and of course no support in terms of providing good fixes. We unfortunately had to invest a lot of time in assessing how these vulnerabilities affect IPFire systems and what is best to do about them. All of that held back development and frankly was the most frustrating thing to deal with this year.

But on the plus side, we found some time to invest into an updated web proxy and our reworked Intrusion Prevention System which probably was the single biggest project this year. Routed IPsec VPNs, DFS for Wireless Access Points in higher 5 GHz channels, a new GUI to configure VLANs and finally a rewritten Quality of Service were more of the bigger things that we released this year.

We had a number of Core Updates which only shipped a kernel, either with fixes for Intel's problems or the famous SACK vulnerabilities. Although these might not seem very exciting to you users and the change logs are a short and cryptic read, they are the most important updates that we release. They are what makes IPFire IPFire. A secure and rock-solid firewall OS.

I do not really have to tell you this, because you are all installing your updates swiftly - with only a couple of exceptions. Earlier this year we asked you to migrate from an old 32 bit installation to 64 bits, because we can only provide best security on that platform. And you listened! When we had two thirds of the systems still running on 32 bit, this has now changed to two thirds being on 64 bit.

WordPress 5.3.2 is now available!

This maintenance release features 5 fixes and enhancements.

WordPress 5.3.2 is a short-cycle maintenance release. The next major release will be version 5.4.

You can download WordPress 5.3.2 by clicking the button at the top of this page, or visit your Dashboard → Updates and click Update Now.

If you have sites that support automatic background updates, they’ve already started the update process.

A new mechanism to help thwart return-oriented programming (ROP) and similar attacks has recently been added to the OpenBSD kernel. It will block system calls that are not made via the C library (libc) system-call wrappers. Instead of being able to string together some "gadgets" that make a system call directly, an attacker would need to be able to call the wrapper, which is normally at a randomized location.

Theo de Raadt introduced the feature in a late November posting to the OpenBSD tech mailing list. The idea is to restrict where system calls can come from to the parts of a process's address space where they are expected to come from. OpenBSD already disallows system calls (and any other code) executing from writable pages with its W^X implementation. Since OpenBSD is largely in control of its user-space applications, it can enforce restrictions that would be difficult to enact in a more loosely coupled system like Linux, however. Even so, the restrictions that have been implemented at this point are less strict than what De Raadt would like to see.

The eventual goal would be to disallow system calls from anywhere but the region mapped for libc, but the Go language port for OpenBSD currently makes system calls directly. That means the main program text segment needs to be in the list of memory regions where system calls are allowed to come from. Static binaries will also need to have their text segment included, since libc will inhabit part of that address space.

Ruby is a general purpose, scripting, structured, flexible, fully object-oriented programming language with a focus on simplicity and productivity. Ruby is a very conservative language. It’s equipped with very carefully chosen features that have been fully tested.

Ruby possesses a high portability running a large number of platforms including Linux, Windows, Mac OS X, Cygwin, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, Tru64 UNIX, and HP-UX. At the time of publication, the TIOBE Programming Community index ranks Ruby in 11th place.

Ruby’s popularity was enhanced by the Ruby on Rails framework, a full-stack web framework which has been used to create many popular applications including Basecamp, GitHub, Shopify, Airbnb, Twitch, SoundCloud, Hulu, Zendesk, Square, and Highrise.

The Internet Museum translated to Swedish becomes “internetmuseum“. It is a digital, online-only, museum that collects Internet- and Web related historical information, especially focused on the Swedish angle to all of this. It collects stories from people who did the things. The pioneers, the ground breakers, the leaders, the early visionaries. Most of their documentation is done in the form of video interviews.

I was approached and asked to be part of this – as an Internet Pioneer. Me? Internet Pioneer, really?

Every enterprise has its own set of challenges. You have a large business to run, while also navigating a changing market and evolving customer needs. And while technology can help address some obstacles, it is not a strategy by itself.

So many executives that I talk to get caught up in which technology to choose that they fail to realize the actual technology is, in many ways, the least important decision. During the next five years, the cloud native boom will entirely transform the foundations on which we build and rely every day — from company culture to developer workflow to product development.

If you have a well developed and forward-thinking strategy, it will make a tremendous difference in whether your organization rides this wave of success or becomes just another business wondering what could have been.

If you're unfamiliar with it, DOSBox is an x86 emulator specializing in running PC DOS games (and, presumably, any PC DOS application). For many DOS-based titles, in fact, it may be the only way to run them on modern PCs, let alone Macs. Besides emulating old hardware like video cards and SoundBlasters sufficiently for games to run, one of its key features on supported platforms is dynamically recompiling x86 machine language for enhanced performance. Unfortunately, DOSBox on Power Macs, while it is still supported as of this writing (10.4 and up), runs x86 code strictly in an interpreter and as a result can be quite slow on low-spec systems. For certain games requiring 80486-level performance, only the G5 can realistically emulate those at any reasonable level, and even then uses a lot of CPU doing so or requires skipping some portion of frames to make the game at all playable.

Over on Vogons earlier this year one of the DOSBox contributors wrote up a PowerPC JIT for the dynrec core under Linux which was then ported to OS X. Like the TenFourFox JIT compiles JavaScript to PowerPC machine code, this patch compiles x86 machine code to PowerPC machine code and runs that instead of requiring labourious interpretation. There was briefly a build available on Dropbox with this JIT, which is currently not part of the DOSBox source tree, but that build can no longer be downloaded. So, I went ahead and reconstructed it against the current trunk (at the time I pulled it, r4301) along with a minor tweak and another of this developer's big-endian fixes, and have tidied it up for download.