Language Selection

English French German Italian Portuguese Spanish

Linux Foundation and Kernel Development

Filed under
Linux
  • Containers Microconference Accepted into 2018 Linux Plumbers Conference

    The Containers Micro-conference at Linux Plumbers is the yearly gathering of container runtime developers, kernel developers and container users. It is the one opportunity to have everyone in the same room to both look back at the past year in the container space and discuss the year ahead.

    In the past, topics such as use of cgroups by containers, system call filtering and interception (Seccomp), improvements/additions of kernel namespaces, interaction with the Linux Security Modules (AppArmor, SELinux, SMACK), TPM based validation (IMA), mount propagation and mount API changes, uevent isolation, unprivileged filesystem mounts and more have been discussed in this micro-conference.

  • LF Deep Learning Foundation Advances Open Source Artificial Intelligence With Major Membership Growth

    The LF Deep Learning Foundation, an umbrella organization of The Linux Foundation that supports and sustains open source innovation in artificial intelligence, machine learning, and deep learning, today announced five new members: Ciena, DiDi, Intel, Orange and Red Hat. The support of these new members will provide additional resources to the community to develop and expand open source AI, ML and DL projects, such as the Acumos AI Project, the foundation's comprehensive platform for AI model discovery, development and sharing.

  • A quick history of early-boot memory allocators

    One might think that memory allocation during system startup should not be difficult: almost all of memory is free, there is no concurrency, and there are no background tasks that will compete for memory. Even so, boot-time memory management is a tricky task. Physical memory is not necessarily contiguous, its extents change from system to system, and the detection of those extents may be not trivial. With NUMA things are even more complex because, in order to satisfy allocation locality, the exact memory topology must be determined. To cope with this, sophisticated mechanisms for memory management are required even during the earliest stages of the boot process.

    One could ask: "so why not use the same allocator that Linux uses normally from the very beginning?" The problem is that the primary Linux page allocator is a complex beast and it, too, needs to allocate memory to initialize itself. Moreover, the page-allocator data structures should be allocated in a NUMA-aware way. So another solution is required to get to the point where the memory-management subsystem can become fully operational.

    In the early days, Linux didn't have an early memory allocator; in the 1.0 kernel, memory initialization was not as robust and versatile as it is today. Every subsystem initialization call, or simply any function called from start_kernel(), had access to the starting address of the single block of free memory via the global memory_start variable. If a function needed to allocate memory it just increased memory_start by the desired amount. By the time v2.0 was released, Linux was already ported to five more architectures, but boot-time memory management remained as simple as in v1.0, with the only difference being that the extents of the physical memory were detected by the architecture-specific code. It should be noted, though, that hardware in those days was much simpler and memory configurations could be detected more easily.

  • Teaching the OOM killer about control groups

    The kernel's out-of-memory (OOM) killer is summoned when the system runs short of free memory and is unable to proceed without killing one or more processes. As might be expected, the policy decisions around which processes should be targeted have engendered controversy for as long as the OOM killer has existed. The 4.19 development cycle is likely to include a new OOM-killer implementation that targets control groups rather than individual processes, but it turns out that there is significant disagreement over how the OOM killer and control groups should interact.

    To simplify a bit: when the OOM killer is invoked, it tries to pick the process whose demise will free the most memory while causing the least misery for users of the system. The heuristics used to make this selection have varied considerably over time — it was once remarked that each developer who changes the heuristics makes them work for their use case while ruining things for everybody else. In current kernels, the heuristics implemented in oom_badness() are relatively simple: sum up the amount of memory used by a process, then scale it by the process's oom_score_adj value. That value, found in the process's /proc directory, can be tweaked by system administrators to make specific processes more or less attractive as an OOM-killer target.

    No OOM-killer implementation is perfect, and this one is no exception. One problem is that it does not pay attention to how much memory a particular user has allocated; it only looks at specific processes. If user A has a single large process while user B has 100 smaller ones, the OOM killer will invariably target A's process, even if B is using far more memory overall. That behavior is tolerable on a single-user system, but it is less than optimal on a large system running containers on behalf of multiple users.

More in Tux Machines

Canonical/Ubuntu: Quirky Xerus 8.6, Snapcraft and More

  • Quirky Xerus 8.6 features latest DEBs from Ubuntu 16.04.x
    The independent Linux-based operating system, Quirky 8.6, a side project of Puppy Linux made with Woof, has just hit the market. According to an announcement by its creator, Barry Kauler, who retired from the Puppy Linux project to work on the Quirky Distro, the woofQ operating system is live for users to download and enjoy. The latest release mainly features bug fixes and minor improvements from previous Quirky OS 8.x versions. The release notes of Quirky’s Xerus version 8.6 explain that the update comes with a package upgrade to version 2.49.4 SeaMonkey and Kernel 4.14.63 with aufs patch. The new release is built with the latest DEBs from the Ubuntu 16.04.x range and features improvements for its EasyShare with specific improvements for Android connections. A Gxlat language translator has been introduced in this update and there are 10 architectural improvements and fixes as well. Several minor security bugs have also been patched since its predecessor.
  • Snapcraft at Europython 2018
    In July, several members of our advocacy and design teams went to Europython 2018 in Edinburgh. It was a really well-organised event, mixing great speakers from a vibrant community at a great location. The main reason for us to get closer to the Python developer community was to promote Snapcraft as the best way to publish on Linux, for app developers in general, and for Python developers in particular. As well as increasing awareness of Snapcraft, we gained a deeper understanding of the needs of Python developers and made contact with interesting products and engineers.
  • Cloud Native, Docker, K8s Summit
  • Ubuntu 18.04.1 Bionic Beaver Has Been Released (Download Links)

Graphics: Wayland/Weston, Mesa and AMD

  • Wayland 1.16 / Weston 5.0 RC2 Released To Fix Vulnerabilities
    Two release candidates of Wayland 1.16 / Weston 5.0 were not originally scheduled, but it's been necessitated due to some pressing issues both with Wayland and its reference compositor. Samsung's Derek Foreman issued these "RC2" releases on Friday rather than going straight to the official Wayland 1.16 and Weston 5.0 releases. On the Wayland front, Michael Srb found and fixed issues that could cause pointer overflows within Wayland's connection code. These overflow fixes are the only changes in this Wayland 1.15.94 (RC2) version.
  • RAGE & Doom Get Radeon Workarounds In Mesa 18.3-dev
    If you are looking to enjoy id Software's RAGE or Doom VFR games this weekend on Linux via Wine, they should be playing nicer with the latest open-source Mesa graphics driver code. Timothy Arceri at Valve has added a workaround to get RAGE working under Wine with RadeonSI. The workaround is a DRIRC configuration addition for allowing GLSL built-in variable redeclarations. This is enough to get RAGE working with RadeonSI on Mesa Git. Though only RadeonSI is working out currently since the game relies upon the OpenGL compatibility profile mode that is only supported currently by RadeonSI when it comes to the Mesa drivers. Thanks to Valve's developers and others, the OpenGL compatibility profile mode for RadeonSI has matured into great shape these past few months.
  • Adreno 600 Series Support Lands In Mesa 18.3 Gallium3D
    With the Adreno 600 series support going into Linux 4.19 for the kernel bits, the user-space OpenGL driver support for the latest-generation Qualcomm graphics has now been merged into Mesa. Kristian Høgsberg Kristensen of Google's Chrome OS graphics team (yes, Kristian of Wayland and DRI2 fame) has been working on the Gallium3D support for the Adreno 600 series hardware along with Freedreno founder Rob Clark. This A6xx support is being tacked onto the existing Freedreno Gallium3D driver and amounts to just over six thousand lines of new code. Keep in mind this A6xx Freedreno back-end must also be used with the supported MSM DRM driver in the Linux 4.19+ kernel.
  • AMDGPU-PRO 18.30 Radeon Linux Driver Released with Support for Ubuntu 18.04 LTS
    Featuring official support for the AMD Radeon PRO WX 8200 graphics cards and initial Wattman-like functionality, the Radeon Software for Linux 18.30 finally adds support for some of the most recent Ubuntu, Red Hat Enterprise Linux, and CentOS Linux distributions. These include Ubuntu 18.04.1 LTS (Bionic Beaver), Ubuntu 16.04.5 LTS (Xenial Xerus), Red Hat Enterprise Linux 7.5, Red Hat Enterprise Linux 6.10, CentOS 7.5, and CentOS 6.10. SUSE Linux Enterprise Desktop and Server (SLED/SLES) 12 Service Pack (SP) 3 is supported as well, but not the latest SUSE Linux Enterprise 15.
  • AMDVLK Vulkan Driver Update Fixes Witcher 3 Issue, Bug Fixes
    In addition to AMD releasing AMDGPU-PRO 18.30 on Friday, they also did their usual weekly source push of their newest "AMDVLK" open-source Radeon Vulkan driver code.

Kernel: Linux 4.19 Staging and Greg Kroah-Hartman's Very Many Stable Releases

  • Linux 4.19 Staging Brings EROFS File-System & Gasket Driver Framework
    Following the USB subsystem updates, Greg Kroah-Hartman sent in the kernel's staging area work for the Linux 4.19 merge window. This experimental/testing area of the Linux kernel is adding a new file-system with 4.19: EROFS. EROFS is developed by Huawei for possible Android device use-cases. EROFS stands for the Extendable Read-Only File-System and is developed to address shortcomings in other Linux read-only file-systems. EROFS features compression support and other features, but the on-disk layout format isn't 100% firm yet -- hence going into the staging area.
  • USB Patches Posted For Linux 4.19 Kernel, Including The New USB-C DisplayPort Driver
    Having wrapped up his latest stable kernel wrangling and the fallout from L1TF/Foreshadow, Greg Kroah-Hartman got around today to sending out the feature pull requests for the kernel subsystems he oversees. His first new batch of changes for Linux 4.19 today is the USB subsystem work.
  • One Week Past Linux 4.18.0, The Linux 4.18.3 Kernel Is Already Out
    Greg Kroah-Hartman had a fun Friday night issuing new point releases to the Linux 3.18 / 4.4 / 4.9 / 4.14 / 4.17 / 4.18 kernels only to have to issue new point releases minutes later. It was just on Thursday that Linux 4.18.1 was released along with updates to older stable branches for bringing L1TF / Foreshadow mitigation. Friday night then brought Linux 4.18.2, Linux 4.17.16, Linux 4.14.64, Linux 4.9.121, Linux 4.4.149, and Linux 3.18.119 with more patches. Those kernels brought various fixes, including in the x86 PTI code for clearing the global bit more aggressively, crypto fixes, and other maintenance work.

Trinity Desktop Environment R14.0.5

  • 2018.08.18: Trinity Desktop Environment R14.0.5 Released!
    The Trinity Desktop Environment (TDE) development team is pleased to announce the immediate availability of the new TDE R14.0.5 release. TDE is a complete software desktop environment designed for Unix-like operating systems, intended for computer users preferring a traditional desktop model, and is free/libre software. R14.0.5 is the fifth maintenance release of the R14.0 series, and is built on and improves the previous R14.0.4 version. Maintenance releases are intended to promptly bring bug fixes to users, while preserving overall stability through the avoidance of both major new features and major codebase re-factoring.
  • Trinity Desktop R14.0.5 Lets You Keep Enjoying The KDE 3 Experience In 2018
    For those that have fond memories of the K Desktop Environment 3, you can still enjoy a KDE3-derived experience in 2018 with the just-released Trinity Desktop R14.0.5. Trinity Desktop continues to see occasional updates as the fork of the KDE 3.5 packages. Trinity Desktop R14.0.5 is the new release this weekend and their first since R14.0.4 was released last November.