Hi all, I think the biggest challenge around on-line content is making sure it is not a once-off event where content goes out of date. Maybe organizing recurrent "hack-a-thons" for bok content would be a good idea especially if we can develop a community or buzz around such events. Something like having local or national hack-a-thons and build up to an annual in-person international "hack-a-thon" get-together, for a final push etc, to provide some community spirit and incentive to participate.
I am all for on-line, continuously improving content. We should make it an objective that whenever the objectives are updated the content will be available at the same time. We need consistency though. BTW I am keen to participate in a week-end online hack-a-thon as put forward by Matthew. kind regards On 08/03/2017 20:55, G. Matthew Rice wrote: > On Mon, Feb 27, 2017 at 10:03 PM, Jeremy Hajek <ha...@hawk.iit.edu> wrote: >> Thanks for all the hard work here - I admire this serious stepping up in the >> LPIC standards. Recently I found that the textbooks that matched the LPIC > Hey, guys, > > What do you think of the idea of a 'write a book in a weekend' idea? > I've seen it work (almost) with other books. I think they just forgot > to put more effort into planning the book upfront. > > We could also make it easier by focusing on creating the Body of > Knowledge and forget the prose. Kind of like the start of the LPIC-2 > BoK at: > > https://wiki.lpi.org/wiki/LPIC-2_BoK > https://wiki.lpi.org/wiki/LPIC-2_BoK_Content_206.1_Make_and_install_programs_from_source > > FYI: https://en.wikipedia.org/wiki/Body_of_knowledge > > What do you guys think? A couple of us can work out the outline > beforehand and then meet up online for a weekend (LPI will find a nice > way to say thanks to the participants). > > As well, I have at least one publisher that would be interested in > publishing the results, too. No promises, they haven't seen what > they're agreeing to yet ;) > > The nice thing part of the BoK is that it provides more reference-able > material for all authors; books, training material, etc. > > Regards, > --matt > >> standards were too old to be of use so I started to write my own (it turned >> into a mix a LPIC 1 and 2) I finished 12 of 15 chapters (along with review >> questions, labs, podcast questions...) I ran out of gas (and had a third >> child =) https://github.com/jhajek/linux-text-book-part-1 (built in >> Pandoc/Markdown) >> >> Your comment Fabian, >> >> ""Good point. So far, we we have "Design software to be run in containers" >> in >> 701.1 which strives this a little. >> >> Do you think adding "Understand major differences between containers and >> virtual machines" to either 702.1 or 702.3 helps? 702.1 would be pretty >> Docker-specific, 702.3 we could allow us to cover this in a more generic >> way. We also have the security implications of containers as well as >> awareness of other container solutions (rkt) here. >> >> Bryan Canrtill the CTO of Joyent (creator of Dtrace at Sun) made an >> excellent presentation at Hashi Conf entitled, "The Container Revolution: >> reflections on the first decade." This presentation is key to >> understanding the difference of Containers and Virtual Machines, the best >> quote is: The virtual machine is vestigial abstraction. We can not get to >> #serverless without getting rid of of the VM. >> >> Containers indicate a titanic leap in technology (almost 1984-ian with the >> IBM PC and Apple Mac coming into existence, or say Windows 95 and its decade >> of dominance) >> >> Docker has been called the 21st century ELF format >> (http://slides.com/nikhilvaze/dockercon2015recap#/8). The ELF format >> allowed a single Linux Binary type -- the hope is that containers through >> Docker will be that same concept for delivering immutable applications. >> "Docker is doing to apt what apt did to tar" >> Perhaps this should be LPIC level 4 as opposed to a single subsection? >> >> I teach at the college level and am responsible for brining this tech into >> intro and intermediate Linux and sys admin courses. I am working through >> http://artofmonitoring.com with my students. James Turnbull's book on >> Riemann event routing platform (written by Kyle Kingsburry) using Packer to >> build our infrastructure and Vagrant to launch the virtual machines. It was >> a struggle at the beginning but I think they are coming along. Would a >> course like this be an LPIC 2 or 3? Or even parts of LPIC 1? >> >> What are your thoughts? >> >> >> >> On Mon, Feb 27, 2017 at 11:00 AM, <lpi-examdev-requ...@lpi.org> wrote: >>> Send lpi-examdev mailing list submissions to >>> lpi-examdev@lpi.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >>> or, via email, send a message with subject or body 'help' to >>> lpi-examdev-requ...@lpi.org >>> >>> You can reach the person managing the list at >>> lpi-examdev-ow...@lpi.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of lpi-examdev digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: lpi-examdev Digest, Vol 104, Issue 4 (Fabian Thorns) >>> 2. Re: lpi-examdev Digest, Vol 104, Issue 4 (Fabian Thorns) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Mon, 27 Feb 2017 11:16:23 +0100 >>> From: Fabian Thorns <ftho...@lpi.org> >>> Subject: Re: [lpi-examdev] lpi-examdev Digest, Vol 104, Issue 4 >>> To: "This is the lpi-examdev mailing list." <lpi-examdev@lpi.org> >>> Message-ID: >>> >>> <CABEAHcJSM4XcJAf9Abxo7+kfcd=vqfjxmjzl5rsxhp0nknc...@mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hi Jeremy, >>> >>> thanks for your encouraging feedback! >>> >>> On Sun, Feb 26, 2017 at 5:05 AM, Jeremy Hajek <ha...@hawk.iit.edu> wrote: >>> >>> I had one piece of advice. The Docker material needs to be reviewed >>>> because the concepts there are vastly different than Virtualization. >>>> Perhaps the Docker material could be its own track/specialization? >>>> >>> This depends a lot of the depth of Docker. You're right, the current >>> objectives are mostly about using Docker, not about configuring its latest >>> detail and understand the actual containerization on a Kernel level. If we >>> would like to test that, we would need to require more background in Linux >>> / operating system than we currently ask the candidates of the new exam to >>> have. Such an exam would probably be better off in the LPIC-3 track since >>> we can expect a high level of Linux proficiency. For the LPIC-OT DevOps >>> Tools Engineer, we intentionally want to keep these requirements low to >>> make the effort to study the objectives reasonable for software developers >>> too. How far do you get into these technical background in your lectures? >>> >>> >>> >>>> What I mean is traditional Virtualization which we have been using for a >>>> while now (VMware, Virtual Box, others) is essentially the same >>>> concepts >>>> as a regular PC-- its hardware virtualization (virt of a BIOS, Drivers, >>>> and >>>> so on) >>>> >>>> Docker (and containers in general) move to a different concept of >>>> immutable infrastructure--which flies in the face of all the LPIC base >>>> standards. Those needs are lessened when you are enabling containers >>>> that >>>> have no SSH even. Containers that are being spun up via AWS Lambda for >>>> instance are done so fast and then destroyed--because it is cheaper to >>>> spin >>>> a container up calculate something and then spin it down (much in the >>>> way >>>> you would use a function()in a programming language) . TL DR Containers >>>> (Docker) are more than just lightweight virtualization. >>>> >>> Good point. So far, we we have "Design software to be run in containers" >>> in >>> 701.1 which strives this a little. >>> >>> Do you think adding "Understand major differences between containers and >>> virtual machines" to either 702.1 or 702.3 helps? 702.1 would be pretty >>> Docker-specific, 702.3 we could allow us to cover this in a more generic >>> way. We also have the security implications of containers as well as >>> awareness of other container solutions (rkt) here. >>> >>> Let me know what you think -- and thank you for pointing this out. >>> >>> Fabian >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> http://list.lpi.org/cgi-bin/mailman/private/lpi-examdev/attachments/20170227/13b8e826/attachment.html >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Mon, 27 Feb 2017 11:17:42 +0100 >>> From: Fabian Thorns <ftho...@lpi.org> >>> Subject: Re: [lpi-examdev] lpi-examdev Digest, Vol 104, Issue 4 >>> To: "This is the lpi-examdev mailing list." <lpi-examdev@lpi.org> >>> Message-ID: >>> >>> <cabeahckodk-2jhxwdndwnccneqyc_2j5o5zvzubkbauuqpy...@mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hi Bryan, >>> >>> On Sun, Feb 26, 2017 at 5:13 AM, Bryan Smith <b.j.sm...@ieee.org> wrote: >>> >>>> DevOps in the '10s are the move to Stateless Servers, just like >>>> Client-Server in the '90s was the move to Stateless Clients. >>>> >>>> No more persistent stores in Servers, just like we eliminated on >>>> Clients. >>>> That's how to focus on this, and how Containers and DevOps are different >>>> than Traditional Virtualization and it's continuing support for >>>> persistent >>>> data on Servers. >>>> >>> All true, but this not only specific to containers but also to >>> microservices and similar architecture patterns. In 701.1 we already >>> mention "how services handle data persistence". Do you think we should be >>> more specific here? >>> >>> Regards, >>> >>> Fabian >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> http://list.lpi.org/cgi-bin/mailman/private/lpi-examdev/attachments/20170227/81645b26/attachment-0001.htm >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> lpi-examdev mailing list >>> lpi-examdev@lpi.org >>> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >>> >>> End of lpi-examdev Digest, Vol 104, Issue 6 >>> ******************************************* >> >> >> >> -- >> Jeremy Hajek >> Systems Architect - School of Applied Technology >> Industry Associate Professor of Information Technology and Management >> ext: 630-682-6075 (2-6075) >> lab: 630-682-6060 (2-6060) >> Main: 312-567-5291 (7-5291) >> cell: 630-666-1961 >> skype: jeremy.hajek >> >> _______________________________________________ >> lpi-examdev mailing list >> lpi-examdev@lpi.org >> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >> >> -- Mark Clarke 📱 +2711-781 8014 � www.JumpingBean.co.za
_______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
