LWN on Kernel and Containers, Folks Form CIQ Leadership Team (UPDATED)
-
The growing image-processor unpleasantness [LWN.net]
There was a time when care had to be taken when buying hardware if the goal was to run Linux on it. The situation has improved considerably in recent decades, and unsupported hardware is more the exception than the rule. That has, for many years, been especially true of Intel hardware; that company has made a point of ensuring that its offerings work with Linux. So it is a bit surprising that the IPU6 image processor shipped with Alder Lake CPUs lacks support in Linux, and is unlikely to get it anytime soon. The problem highlighted here goes beyond just Intel, though.
The IPU6, like most image processors, exists to accept a data stream from a camera sensor and turn it into a useful video stream. These processors can take on a lot of tasks, including rotation, cropping, zooming, color-space conversion, white-balance correction, noise removal, focus management, and more. They are complex devices; the kernel community has responded by creating some equally complex APIs, including Video4Linux2 (V4L2) and media controller, to allow user space to manage them. As long as a device comes with a suitable driver, the kernel can make a camera device available to user space which, with care, can work with it without needing to know the details of the hardware.
As Paul Menzel recently pointed out on the linux-kernel mailing list, there is no such driver for the IPU6, so a mainline Linux kernel cannot drive it. As a result, the kernel lacks support for MIPI cameras on some current laptops, including some versions of the Thinkpad X1 Carbon and Dell XPS 13, which are relatively popular with Linux users (cameras using other interfaces, such as USB UVC, are generally supported). To get around this problem, Dell ships a closed-source, user-space driver in the Ubuntu build it offers on the XPS 13. Lenovo, instead, is not selling the affected systems with Linux preloaded at all at this point.
-
LRU-list manipulation with DAMON [LWN.net]
The DAMON subsystem, which entered the kernel during the 5.15 release cycle, uses various heuristics to determine which pages of memory are in active use. Since the beginning, the intent has been to use this information to influence memory management. The 6.0 kernel contains another step in this direction, giving DAMON the ability to actively reorder pages on the kernel's least-recently-used (LRU) lists.
The kernel's memory-management developers would like nothing better than the ability to know which pages of memory will be needed in the near future; the kernel could then make sure that those pages were resident in RAM. Unfortunately, current hardware is unable to provide that information, so the memory-management code must make guesses instead. Usually, the best guess is that pages that have been used in the recent past are likely to be used again soon, while those that have gone untouched for some time are probably not needed.
-
The container orchestrator landscape [LWN.net]
Docker and other container engines can greatly simplify many aspects of deploying a server-side application, but numerous applications consist of more than one container. Managing a group of containers only gets harder as additional applications and services are deployed; this has led to the development of a class of tools called container orchestrators. The best-known of these by far is Kubernetes; the history of container orchestration can be divided into what came before it and what came after.
The convenience offered by containers comes with some trade-offs; someone who adheres strictly to Docker's idea that each service should have its own container will end up running a large number of them. Even a simple web interface to a database might require running separate containers for the database server and the application; it might also include a separate container for a web server to handle serving static files, a proxy server to terminate SSL/TLS connections, a key-value store to serve as a cache, or even a second application container to handle background jobs and scheduled tasks.
An administrator who is responsible for several such applications will quickly find themselves wishing for a tool to make their job easier; this is where container orchestrators step in. A container orchestrator is a tool that can manage a group of multiple containers as a single unit. Instead of operating on a single server, orchestrators allow combining multiple servers into a cluster, and automatically distribute container workloads among the cluster nodes.
-
Linux and Open Source Veterans Sign On to Form CIQ Leadership Team
Nine cloud and Linux veterans have signed on to form the leadership team for CIQ, the company building the next generation of software infrastructure for enterprises running data-intensive workloads atop the Rocky Linux enterprise Linux distribution. This follows a successful funding round in May and a teaming with Google Cloud in July.
UPDATE
SJVN has more.
-
Linux vets unite behind CIQ, Rocky Linux's parent company | ZDNET
CIQ is a relatively new company. Its leadership, however, has deep roots in open-source software and Linux. Besides Gregory M. Kurtzer, CIQ's co-founder and CEO, who was a creator of CentOS, the popular Red Hat Enterprise Linux (RHEL) clone, its new executive team -- announced Wednesday -- boasts two of the founders of Linuxcare, the first company to make supporting Linux a priority.