asg2018

A more generic approach to ensure you have what you'd expect to have A side effect of the many new ways to package filesystems (here's looking at you, containers!), is that filesystems are being copied around without many of the features that traditional packaging provided (i.e. `rpm -qV ...`). Much progress has been made for reproducible digests of containers. In this talk Vincent Batts will review options for distributing filesystems with reproducibility, and verifying the at-rest outcomes. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/185

libcapsule is a project that allows segregated dynamic linking: Access to the symbols of a library without being exposed to any of the dependencies of that library without requiring recompilation of the binary that pulls it in. libcapsule's goal is to improve portability of programs that are distributed with runtimes (cf flatpak) that still need access to [some] libraries from the host (eg libGL) while insulating said program from any system libraries outside the runtime other than those it directly requires. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/173

Please submit your talks to mpitt [at] redhat [dot] com or to organizers at the venue about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/233

TL;DR: Stop making "Desktop Linux" a moving target by agreeing on a minimal baseline that third-party application can take for granted to exist on each Desktop Linux system. To make "Desktop Linux" a viable platform (as in: Windows, macOS) to develop against, we need to insist on backward compatibility and either need to find the "least common denominator" by experimentation (as we have done for over a decade now), or get the main Linux distributions (Ubuntu, Fedora, openSUSE, Debian, etc.) to agree on a certain set of infrastructure that can be expected to be "there", in a consistant way, without unnecessary differences. A guaranteed minimal set of infrastructure (available in the default installation of all distributions) with guaranteed backward compatibility is required for "Desktop Linux" to become viable as a platform. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/174

Sick of insecure PXE booting over TFTP? Come learn about our efforts to write modern boot loaders in Linux's user space. LinuxBoot is a project to put Linux kernels into firmware. LinuxBoot means we have the full toolset of modern languages like Go at our fingertips: let's use them! We can now easily develop boot loaders with trivial support for HTTPS-, gRPC- or TPM-based network booting. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/215

System containers, the oldest type of containers, focus on running an entire Linux distribution, including all its services in very much the same way it would on a physical system or virtual machine. System containers come with some unique challenges, users of those containers expect to be able to do pretty much everything that they can on a normal system. This means it’s not possible to restrict those containers quite as much as application containers can be. It also means that there are extra expectations to be met:

• Being able to add/remove devices to/from a running container
• Loading security profiles inside a container
• Using file capabilities in the container
• Mounting file systems
• Proper reporting of uptime, resource consumption and limits
• Live-migration

In this presentation, we’ll explore some of the existing technologies in use by LXC and LXD to address some of those expectations as well as upcoming kernel and userspace features that will allow system containers to do even more than they do today. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/224

Early boot provisioning systems aim to enable automated, declarative, immutable patterns for Linux systems. In this talk, I'll discuss the CoreOS Ignition system and illustrate how it works and addresses real-world use cases on bare-metal, cloud providers, and hypervisors. I'll share experiences using and integrating early provisioning and highlight new challenges for contributors to explore. With Ignition shipping in several Linux distributions soon, early boot provisioning shows promise and potential for the future. Early boot provisioning systems prepare a Linux host by partitioning disks, creating filesystems, and writing systemd units and configs. They aim to enable automated, declarative, immutable infrastructure patterns and shape the way large-scale Linux systems operate. In this talk, I'll discuss the original CoreOS declarative config and Ignition system, share how it works, and how it arose. I'll walk through real-world use cases on bare-metal, cloud providers, and hypervisors to show early boot provisioning concepts and where they shine. I'll review experiences using Ignition and cloud-init and integrating them into Matchbox and the Typhoon Kubernetes distribution. For those designing or integrating early boot provisioners, I'll discuss advanced features, exciting areas for exploration, and my hopes for these systems over time. Now that Container Linux and Flatcar Linux support Ignition and Red Hat has announced Fedora CoreOS and Red Hat CoreOS will as well, early boot provisioning can evolve to benefit more distributions and users. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/190

The Linux Audit daemon is responsible for writing audit records to the disk, which you can then access with ausearch and aureport. However, it turned out that parsing and centralizing these records is not as easy as you would hope. Elastic's new Auditbeat fixes this by keeping the original configuration, but ships them to a centralized location where you can easily visualize all events. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. This talk shows you what can you do to discover changes, events, and potential security breaches as soon as possible on interactive dashboards. Additionally, we are combining Auditd events with logs, which are security relevant. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/216

Recently, work that we have been doing on Endless OS to allow peer to peer OS and flatpak updates has been reaching maturity and nearing wider deployment. This talk will give an overview of how we support LAN and USB updates of OSTrees, how it fits in upstream in OSTree and flatpak, and what you’d need to do to enable peer to peer updates for your OSTree system. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/220

I’d like to show you how to find bugs in Linux systems using machine learning, when paired with the totally seemingly useless and annoying false positives that come out of your integration tests. I’d like to show you how to find bugs in Linux systems using machine learning, when paired with the totally seemingly useless and annoying false positives that come out of your integration tests. We’ve all been frustrated unreproducible bugs in Linux … And also by stupid test-flakes that show up as failures in integration tests even though nothing related has changed. Both unproducible bugs and test flakes are the result of permutations in timing, load, ordering. I want to prove that unreproducible bugs are the same thing as test flakes. And we have a massive source of data here, millions of records of test flakes. Lets take a look at how the Cockpit project trains bots to correlate these flakes into unsupervised clusters. and automatically make use of the data, identifying real bugs, or simply retriggering tests. We’ll dive into details about Normalized Compression Distance, Unsupervised Clustering, TF-IDF and many other simple techniques used to zero in on the bugs. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/207

Kdump is a vital tool for debugging severe kernel crashes, especially if the failure can't be reproduced easily or an direct access to the system is not possible. Kdump is a vital tool for debugging severe kernel crashes, especially if the failure can't be reproduced easily or an direct access to the system is not possible. When an sever error happens in the kernel, a new crash kernel get loaded which saves the memory of the crashed system. These dump can be used to analyze the state of the machine and hopefully give insights on what has happened. This talks will dive into the internals of kexec and kdump. How the crash kernel get set-up, how it's execution get triggered. We will also look into kexec-tool, the user-space part needed to set up a system to use kdump. Where necessary, the architectural specific details will be explained by looking at the arm64 implementation. This talk is thought for people who want to have an insight into how kdump is working. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/169

We'll be covering happenings, learnings and new challenges running and supporting systemd in production on the Facebook fleet throughout the past year. This talk is a followup to systemd @ Facebook — a year later that was presented last year. We'll cover the latest developments, how we're leveraging new systemd features, how we continue rolling systemd on the fleet, and finally discuss a number of interesting case studies. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/192

This talk will describe all of the reasons for podman, all of its features demonstrate its functionality, I will cover the background of podman, how we built it, why we built it, I will demonstrate using it in multiple different ways, Running containers building container images Communicating with it via var link, cockpit integration. Communicating with it from a remote machine. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/177

There is so much more than you can so, than just starting and stooping your service, when you start to interact with systemd from within your application. Lets find out!!! We'll explore how can you interact with systemd from your aplication, by describing how pystemd, a python binding for systemd, was created at facebook, and what type things your programs can take advantage if you just interact with systemd more. From executing section of your code securely to create development environment on the fly, There is so much more than you can so, than just starting and stooping your service, when you start to interact with systemd from within your application. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/194

Flatpak is a desktop-focused application distribution and deployment system for linux. This talk will walk through the technical details of the core functionallity and explain how it work and why it works that way.

Flatpak has now had a major stable release and the rate of change is slowing down. This is a good time to take a look at how the things work behind the scenes.

This talk will go through the technical details behind flatpak, explaining things like ostree, bubblewrap and how flatpak uses this to implement the sandbox and basic flatpak commands. It will also explain in high-level terms how the portals and other desktop integration features work.

about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/181

Whether you are interested in multimedia programming in specific or curious about how Rust programming language can enable you to write almost-bug-free code without having to compromise on efficiency, this talk is for you. GStreamer is a popular framework of choice for multimedia programming in the Linux world, especially for embedded. Since efficiency is a typical core requirement for embedded solutions, traditionally C/C++ have been the languages of choice for writing GStreamer applications and plugins. Unfortunately, this efficiency comes at the price of safety. Even the most skilled C/C++ developers make mistakes with memory management and the results could potentially be catastrophic. Thread safety is another aspect that is central to multimedia solutions but is extremely difficult to achieve with C/C++. Rust language is designed to be both efficient and safe at the same time. In this talk, Zeeshan will present how GStreamer's Rust bindings not only make multimedia programming a lot safer, easier and fun but also allow developers to write even more efficient code than C/C++ in certain cases. While the talk will be focused on multimedia and GStreamer in specific, most of the concepts presented shall be very generic. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/172

CRI-O is a brand new container runtime dedicated and optimized to support kubernetes workload. Its goal is to be a stable container runtime tied to kubernetes releases, replacing the docker daemon. Historically every update of Docker has broken Kubernetes. This has led to major rewriting and fixes of Kubernetes, which is understandable since Docker is not primarily for Kubernetes. Kubernetes needs a container runtime dedicated to its specifications. CRI-O, the name comes from the Container Runtime Interface for Open container runtimes, takes advantages of emerging standards like OCI Runtime and Image Specification, as well as open source projects to handle container images (github.com:containers/image, github.com:containers/storage) . This means as these projects advance CRI-O will be able to take advantage of the improvements and features, but all the while guaranteeing that it will not break any functionality required by the Kubernetes CRI. CRI-O works with runc and Clear Containers runtimes. CRI-O was designed from the ground up to satisfy Kubernetes Container Runtime Interface, and currently passes all node and E2E tests. The github repository has been setup to not accept any pull requests that causes these tests to break. We will be tying the versions of CRI-O to the Kubernetes versions, to maintain complete compatibility. This talk will describe the CRI-O architecture as well as demonstrate different kubernetes features running on top of CRI-O exercising the CRI API. The attendees will learn how to configure CRI-O with kubernetes and use it for their workloads. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/211

Efficient monitoring of large-scale networks poses a delicate balance between capture granularity on the one hand and the imposed overheads and performance penalties on the other. Skydive is an open source real-time network topology and protocol analyzer, featuring smart network collection which is both granular and efficient. Skydive allows for efficient network monitoring at scale through Linux networking features such as BPF and eBPF. In the talk we will present Skydive and will give an update of the features that introduced since one year. We will show how Skydive leverages eBPF to produce useful insights on top of network topology information. We will share some performance results showing the efficiency of Skydive BPF/eBPF capturing in the context of a Kubernetes deployment. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/202

It is now possible to run Android ontop of an entirely Open Source Linux Graphics stack, this talk will dig into how you can do it too! Finally, it is possible to run Android on top of mainline Graphics! The recent addition of DRM Atomic Modesetting and Explicit Synchronization to the kernel paved the way, albeit some changes to the Android userspace were necessary. The Android graphics stack is built on a abstraction layer, thus drm_hwcomposer - a component to connect this abstraction layer to the mainline DRM API - was created. Moreover, changes to MESA and the abstraction layer itself were also needed for a full conversion to mainline. This talk will cover recent developments in the area which enabled Qualcomm, i.MX and Intel based platforms to run Android using the mainline graphics stack. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/164

This talk presents TAPS (Transport Services), a proposed abstraction for a new Networking API, and calls for the Linux community to get involved. Even decades after its introduction, the Socket API is still the de-facto standard Networking API on many systems. Its simplifying abstraction of a network connection as a file helped making networking easier to integrate into applications in the early days, but by now, networking has become way more complex. We have to deal with asynchronous communication, with the choice between IPv4 and IPv6 addresses, with multiple local network interfaces being available, and more. With the development of new transport protocols, such as QUIC, an application may even be able to choose a different transport protocol than TCP, which fundamentally offers the same service. It would be beneficial to develop a future networking API with a better abstraction, so applications can make use of the different options without having to implement a complex decision logic themselves. The Transport Services (TAPS) Working Group in the IETF is currently developing such an abstraction, which will be proposed as a new standard networking API. It will be fundamentally event-based and object-oriented, presenting a simple Connection and Message abstraction to applications. An application only has to specify abstract requirements for a new Connection, such as reliable and in-order Delivery of messages, and the Transport System below the API will choose a transport protocol and network configuration. This talk presents the current TAPS architecture and API elements, and calls for the Linux community to get involved, for example by developing a new implementation of this API or reviewing and commenting on the documents. about this event: https://cfp.all-systems-go.io/en/ASG2018/public/events/188