Sergio Belkin wrote: > Hi community, > I was looking at Topic 201 ... > https://wiki.lpi.org/wiki/LPIC-2_Objectives_V4.5#Objectives:_Exam_201. > ... does it make sense persisting on kernel 2.6? > Granted, CentOS 6 includes kernel 2.6.x.... but will lose support by end > of November '20 ... >
I'm also not aware of any long-term enterprise or embedded release that will be in use by the time the next revision is released. E.g., both Red Hat and SuSE AG (who rebases, as Oracle does) will have ended all pre-3.x support by then. Sergio Belkin wrote: > Please honestly, how many times in the last 5 years did you build a new > kernel? In the last 3 years ago? In the last 1 year? > Please, don't get me wrong, I think that is important conceptually **be > aware of** kernel building. But I think that in practice hardly anyone > builds a custom kernel. > Also, kernels on mainstream distros such as CentOS and Debian differ a lot > with upstream versions. > Devil's Advocate ... (consideration) But even in the case of DPKG buildpackage (Debian-based) and SRPMS SPEC (Fedora-based) kernels, still knowing the phases of building a kernel can be important in prepping the source tree if one is going to build kernel modules around them -- whether raw tarball, DPKG buildpackage or RPM SPEC. Now it's much better than it used to be, but I've still had to break out -- e.g., Fedora-based -- the .src.rpm and its SPEC with Tar+Patches to prep a significant, added subsystem and/or other build of a module, and knowing the steps of the kernel's own build phases is ideal (in addition to Fedora's, like for Debian's too). Now that said, flipping the other way ... (consideration) A survey, JTA, etc... might have some merit to re-evaluate the 'weight' of the objective. But ... (to clarify a common, misconception) Even more: if you build a custom kernel on [RHEL] you lose the support. > Not if you're prepping the kernel tree for an added module, but still the _exact_, _supported_ Red Hat 'extraversion' release, build and errata for 100%, full support. ;) Red Hat just doesn't support that module, while it still supports the kernel. At most, Red Hat Global Support Services (GSS) will require a reproducer without the added module. But they still have select 'levels of effort' even if it cannot be reproduced. Again, I regularly prep-build the kernel tree for RHEL (even Fedora, although no longer Debian -- been years since I was a Debian kernel maintainer, of virtually _no_ note) to build additional kernel modules with the 'as-is,' _support_ to the _exact_ kernel 'extraversion.' Especially when the originator of the module doesn't provide a nice, modular dynamic or static mechanism for DKMS, akmod, kmod2, etc... Now regarding the _original_ statement (CentOS) ... Even more: if you build a custom kernel on Centos, you lose the support. > Side Argument: I wasn't aware CentOS had 'support' (?) I'll have to re-sync with Johnny Hughes et al., but I've been using this since he said it in 2011 or so ... (loved it when it came across) >>>* When you want something that is provided for free, and when you want to **treat me like you are paying me a million dollars a year to give it to **you, guess what ...* >>>* You can also get service level agreements from Red Hat or from Oracle or** Novell.* Johnny doesn't like to pick any vendor, but if someone brings up the fact that they need CentOS compatible, he'll quickly point out how CentOS (and Oracle Linux) don't exist any more if no one is paying Red Hat. He still says this, even after becoming a Red Hat employee as of 2014, along with the rest of the CentOS team. Yes, they are Red Hat employees since, so he has a paycheck coming in to keep the updates more regular. Of course, CentOS is now such a small, tiny build of RHEL's overall set of products, and adding Fedora EPEL doesn't match RHEL. I'm sure 'SLA' means many things to many people, but this usually means the ability to affect the entire stream of the product, at least in the spheres I work in. Even Oracle puts asterisks on that, and totally if you're using the Oracle Unbreakable Enterprise Kernel (UEK) where they even admit, "Oh, we don't support that, not that, not that either ... you must use the Red Hat Compatible kernel." As always, 100% PEER viewpoint, as an individual. - bjs
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
