Hi, > > you had the choice of either fighting with RedHat or EMC. > > > Red Hat doesn't "fight." It respects what the customer wants to do. >
If my opinion is worth a grain in this SAN debate: While my work is mostly about red hat products, I don't work for red hat nor any of their partners. Red Hat (and CentOS, Oracle Linux, etc) are very popular so their specifics should be covered. As Debian, Ubuntu and SuSE specifics should. (please forgive me is I left out your favourite distro, but anyway LPIC will have to cut it at some point). I agree that LPIC is about quality open source software, that is (or can) be included by any linux distro, or added by the sysadmin from sources. I agree that is not LPIC job to support any proprietary solution no matter how big and important the vendor. When needed, LPIC shoud cover the concepts any sysadmin would need to understand how to relate the proprietary component to the open source ones, and do not care about tainted kernels Even if my opinion is that they aren't, most of the times, worth the trouble. IMHO and experience you'd have less headache with most bundled open source drivers than proprietary ones, at least when there is a viable open source one. Fell free to disagree, and keep in mind that LPIC should work for both camps. So I think LPIC evaluate if sysadmins are able to install (proprietary) modules, generically, not specific ones from a specific vendor. So I think multipath, dmraid and etc, as in RHEL, are a must on LPIC. But if you'll use EMC proprietary software for Linux, you still has to know a little about multipah, SAS, WWID, etc. Then you see the vendor docs, or even aquire a vendor certification, to complement your LPIC one. PS: If there was a voting scheme, I could simply add +1 to DM-Multipath and not voting on powerpath topics. []s, Fernando Lozano
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
