On Fri, Jun 21, 2013 at 7:48 AM, Alexandru Juncu <[email protected]> wrote:
> Well, the ls command isn't rocket science either, but it is presented in > LPIC-1. > Nor is the virsh command, which leverages the libvirt layer of abstraction, so a candidate doesn't need to know what Hypervisor or what container approach is used underneath. Also, I think there are two sides: you could know basic things, like > what is the difference between operating system level virtualization > ,paravirtualization and full virtualization and how to create machines > and use them (basic command). Or just focus on the virsh command, and knock out all the universal commonality in one shot. This would be something for LPIC-2 (some > could go as far as to say it's for LPIC-1, buy LPIC-1 perhaps should > be the really generic things you need to know about Linux > distributions); Or, again, just focus on the virsh command, and knock out all distros in one shot. ;) The 3 level pyramid is very good. But maybe LPI needs to take a lesson from other certification vendors and initial tracks from the second > level. Just a thought... > And what examples would those be? If you want to look at Red Hat EX318, that's a basic administration exam on, essentially, oVirt. This is too dangerous to answer. Each topic is there for a reason and > some people would be offended if I would say we should remove their > favorite topic. > Again ... what's wrong with just covering libvirt and virsh? I'm going to keep saying ... until someone recognizes it's there ... and it has drivers for all Hypervisor and container technologies. It exists for a reason. So are we not about open source and open standards that are technology, and even vendor, agnostic? Or do we wish to continue the "brand name" and "marketing" non-sense most of us left the commercial software world for? Or do I need the bumper sticker, "my Hypervisor beat up your honor student" to join in? -- bjs P.S. If I see any "bias" in my career, and in my fellow co-workers, it's how much my customers -- let alone the sheer number of Upstream maintainers my employer employs -- who work _broadly_ on, _beyond_ what my employer sells support with. But that's just who we are, as a whole. I.e., kinda drives our frustration when people say we only do KVM, which is the most inaccurate statement on the planet about any entity remotely related to open source (much less one that does open source 100%). Just saying, this entire thread makes my point better than I ever could. ;)
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
