Bradley D. Thornton wrote: > Okay, certainly not a thousand; several hundred; and at least 30, > maybe 40; and in that order. > I know in practice people build kernels everyday and tote them around > with them. >
Which is why we need a Survey/JTA to see how much. I have a feeling it's at least 0.3%, maybe closer to 5%. > Perhaps you're only considering the more general purpose distros with > support contracts? You mean Sustained (Enterprise) Linux distributions? The ones sustained for 5-7 or even 10-13 years for a fixed Application Binary Interface (ABI). Other than prepping the kernel for adding modules, it's kinda inversely proportional to the reason you'd want to run one. If one is building kernels, and even core software, it kinda defeats the purpose of having a fixed ABI Enterprise distribution. And for embedded or IoT devices that are consistently updated without any need for a sustained ABI, most people aren't running a Sustained Linux distribution. The kind that led me to completely eradicate RHCE > from our enterprise at Medata when they told us that a kernel compile > that we needed for our software would void our support contract? > Well, Red Hat (RHEL), SuSE (SLED/SLES) and even Canonical (Ubuntu LTS) have various guarantees on ABI compatibility. So other than prepping the kernel tree for building additional modules/subsystems to load, changing the core/stock modules will result in such. Perhaps you're not considering Arch, Gentoo, Slackware, and many other > distros used on both the desktop and in the enterprise. > That's why I don't like the term 'Enterprise' but more 'Long-Term Sustained.' It costs Red Hat and SuSE and inordinate amount of sustaining engineering to backport and keep the long-term ABI, as even Canonical is founding out as its Advantage program moves from 5 to 7-8 years. But if one's enterprise is rebasing within a year, or even continually, it's really at odds with the model. The classic Ian Murdock discussion on lifecycle applies, which explains Debian as well. The BSDs have used a 'ports' approach over the years too, although it's ABI/API doesn't change as much as GNU/Linux. A mention? No, I think this is a core competency and it would take two > hands just to count the people I know who do kernel compiles each week > - - obviously, my circle of geeks seems different than yours, but the > suggestion that, "hardly anyone builds a custom kernel" is hardly, > even remotely accurate. > Which is what a Survey/JTA should identify, at least if it surveys a good portion of the hosting and custom software development market. It's getting interesting nowdays because Red Hat has more of a 'core' ABI for hardware/base software, but then an 'Application Streams' (aka Fedora 'Modular') approach to non-core libraries and software. The idea here is that the ABI is for hardware and base software that has to be fixed, but everything above it should 'Modular' (Fedora term) or 'Streams' (Red Hat term). Containers then take this to a new level, and Red Hat actually had OpenShift before Kubernetes, Docker and even LXC existed. It came out of the need for JBoss to run different, multiple libraries and language support, especially between Dev, Test, QA and Prod releases, and "Software Collections" (SCL) wasn't 'cutting it.' But the kernel and core ABI is still fixed, even with RHEL 8 'CoreOS' now at the heart of OpenShift Container Platform (OCP) v4. If someone comes to me interviewing for an admin job and they only > have a *concept* of a kernel compile or toolchain, I can assure you > that they only have a concept of a job. > Depends on what the client/customer needs. Configuring and compiling a kernel has never not been a core > competency, and is also one of the things that has always set LPI > apart from silos that offer their own certs to suit their narrative of > what an engineer should have in their magic bag of Trix. > All the more reason to ensure it's in LPI, especially if we can justify it via a Survey/JTA. Regardless, I'd argue 'prepping' the kernel is still needed just to build modules and, even more so, entire, modular subsystems that may not be included in the 'stock' distribution. Thanks for asking, I'm really glad you did too :) > That's what this list is for. Now if we can quantify it with a Survey/JTA, even better. The good news is that it's already in the objectives ... So it's more about justifying its removal than its continued inclusion ... at least that's what I think (don't quote me). - bjs
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
