And that's a general developer v.. sustainment engineer argument, which still affects containers, despite arguments to the contrary.
It kills me when developers they use Ubuntu, and then argue that Ubuntu LTS is the same. It's not. They need to devekop on LTS. I'll even argument that's like saying Fedora is the same as RHEL (or CentOS), and they argue they are not. At firstvI agree, but not fir the reasons they think - - because Fedora is actually supported much longer than Ubuntu (non-LTS). They are confused by trademarks, and ignorant of technical reality. As far as building newer kernels on RHEL, that's called Oracle UEK, and it breaks so much (as even Oracle admits - - they only support specific Oracle application with UEK). Even SLES and Ubuntu LTS rebase kernels and some support is removed. Red Hat does offer some rebase kernels as part of add-ons, but there are limits to what Red Hat supports on those, so the standard are unrebased kernels for 100% ABI/API support for 10-13+ years. In the end, lifecycle realities don't change with containers. If you update containers with 12-15 months, Debian and Fedora works, 6-9 months, Ubuntu, Gentoo. But if you need 2+ years, that's Ubuntu LTS, SLES or RHEL (CentOS), and of one cannot rebase the kernel, then really only RHEL for 10-13+ (CentOS for 10, as Red Hat doesn't release the SRPMs/patchsets for ELS after year 10). Architects and stakeholders cannot be ignorant of Linux lifecycle, that doesn't change with containers. - bjs On Sun, Feb 24, 2019, 15:29 Sergio Belkin <[email protected] wrote: > I think that this post is interesting in connection with we talked about : > https://opensource.com/article/19/2/linux-distributions-still-matter-containers > > El jue., 31 ene. 2019 a las 9:40, Bryan Smith (<[email protected]>) > escribió: > >> Kenneth Peiruza <[email protected]> wrote: >> > Longer trainings are harder to sell. >> >> And develop too. Red Hat found that to be the case as well, and >> started creating more and more 200-level courses, sometimes with >> exams, that were only 2 days long, especially for new technologies. >> That way they could reach the market quicker. Of course some >> eventually became 300 and even 400 level, and a full week with a >> longer exam, but the 200 allowed them to get out-the-door. >> >> > So we have established a common minimal knowledge (i.e. docker and got >> essentials) then divided most other topics (jenkins & packer for >> developers, k8s and ansible for ops). >> > I'd suggest dividing LPI DevOps in 1 essential course with this common >> ground the. A LPIc DevOps for developers and DevOps for sysadmins. >> >> Have you talked to Fabian and Matt about this? If the market is >> suggesting that model, it would be interesting to visit when the >> DevOps program is revised in a couple of years. >> >> - bjs >> -- >> >> -- >> Bryan J Smith - http://www.linkedin.com/in/bjsmith >> E-mail: b.j.smith at ieee.org or me at bjsmith.me >> _______________________________________________ >> lpi-examdev mailing list >> [email protected] >> https://list.lpi.org/mailman/listinfo/lpi-examdev > > > > -- > -- > Sergio Belkin > LPIC-2 Certified - http://www.lpi.org > _______________________________________________ > lpi-examdev mailing list > [email protected] > https://list.lpi.org/mailman/listinfo/lpi-examdev
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
