It might be an interesting topic, but wouldn't it be better if reformatted into a single page of text (there's what, 300 words there?) rather than 49 slides?
Quite possibly - the original was a lightning talk delivered at YAPC::EU in Pisa this year - so while a single page of text would probably be a better idea for you as a reader, the original format worked very well live.
Imagine the presenter going through these one at a time with descriptions and appropriate pauses so people go "oh my god he's not going to ... he is!" and an audience of a couple hundred perl hackers laughing their collected asses off at each slide to approximate the original effect.
If anybody does collect it into a single page version, please do tell cog - I'm hoping that the video will eventually go up onto http://presentingperl.org/ along with all the others, and I'll make sure it gets linked with a thank you :)
People seem to be more and more fixated on the "one thing per rapidly changing slide" style of presentation nowadays. I can certainly see the advantages of having only one thing in your audience's mind at a time as you blab--they're more focused, and the rapidly changing slides fits better with modern attention spans. But it definitely kills the utility of the slides on their own.
For an even more difficult to follow slide deck see the git tricks presentation currently on the frontpage. 328 slides!
If you're producing the slides for a live audience, this style is superior. People can read faster than you can talk, so if what you're saying is all packed onto the slides it creates a bad audience dynamic.
If, OTOH, the slide you're producing are intended to be read, denser, more informational slides are appropriate.
As with most things in life, what to do depends on who your audience is.
People may be fixated on the "one thing per rapidly changing slide" style of presentation nowadays, but I don't know anybody who is fixated on the "one thing per rapidly changing slide" style of reading.
One of my most important realizations when I first started preparing lectures was that there are two things that people use "slides" for. The first is as a visual aid, for use during the presentation itself. The second is as a set of notes containing the important information that the presentation was meant to convey. The things that make for useful notes are very different from the things that make for good visual aids, and when people try and do both at the same time... you get the craptacular PowerPoint disasters described ad nauseum by Tufte, etc.
If I were giving a talk about various sneaky ways to recover from a borked chmod situation, I'd personally find the slides linked to in the parent to be just about right- each slide talks about one solution, and my audience would be able to focus on each solution as I was talking about it without a lot of extraneous visual noise. However, you're 100% correct that, for use as lecture notes, this format is suboptimal. As after-the-fact readers, it would be far more useful just to have a list of each solution, perhaps with a little bit of commentary for each one.
As everybody knows, Tufte hates the "title with lots of bullet points" school of slide design with the burning fire of a thousand suns. However, IIRC, he dislikes the "one thing per rapidly-changing slide" approach as well, finding it indicative of a patronizing and controlling attitude towards one's audience. I'm not sure I agree with him 100% on this point- I've had pretty good luck using this style for lectures, although I've learned that students who are expecting more "traditional" slides (and are planning on using them as lecture notes) are disappointed when they see that my slides won't work quite as well as other people's for that purpose. Tufte's suggestion of providing a printed outline or handout containing more detailed or supplementary information is a good one, and I've started sometimes putting together separate outlines or "cheat sheets" with stuff that I think my audience might want/need to refer to later.
One lovely piece of middle ground between the "minimalist" and "traditional" schools of slide design is Michael Alley's "Assertion-Evidence" slide structure ( http://www.writing.engr.psu.edu/slides.html ). It's not always the right solution for every situation- in slide design, there's no one-size-fits-all "right" way to design a slide- but I've found that it works really well for presenting technical subjects, and the resulting slides make excellent ready-made lecture notes. On the other hand, preparing a presentation using his approach takes way longer, because you actually have to really think out exactly what it is you want to communicate and how you wish to do so- using either the "traditional" or "minimalist" approaches, it's possible to end up quickly filling a lot of space with empty and useless text, and that's absolutely not possible with Alley's approach. Of course, I personally see that as a feature of the Alley method rather than a bug, but there have definitely been times when I've been in a time crunch and found myself reverting to a less well-structured slide design just in the interests of getting the slides finished in time for a last-minute talk.
I think the style that Lessig popularized is a bit more extreme, along the lines of one slide per second or two, often with sentences split up across slides, and transitions synchronized with gestures or intonation. That makes the slides sort of a performance-art prop.
I would blame/credit audrey tang, pugs and the lambdacamels for popularizing the takahashi method[0]
(notable difference from lessig's style is the lack of non-text content).
My feeling about this is mostly anecdotical, but during the days of crazy pugs development a massive number of hackers from different communities was exposed to what was happening, tools designed for building such presentations bloomed, and, well, after that time I've seen a lot more of those :)
I agree that this is easiest, and I'm surprised that the article calls it "hardcore" (slides 38-39). But it does bring to mind a more devious challenge: Someone ran "chmod -x ld.so"...
It does affect files, but umask only subtracts permission bits. So if the program creating the file doesn't try to set it executable, then umask will never change that.
This is neat but it sort of seems kind of trivial to solve. I guess it's interesting to see the different possibilities but if you are allowed to write some kind of program then it's just totally trivial.
I'm stupid, I guess. I saw the last slide ("there is no problem as the system is still running" (and chmod can therefore still be executed)) and thought that was the solution.
Once again I've learned that for every problem there is a solution that is clear, simple and wrong (and that I myself am quite likely to hit upon this solution).
If you try it, you'll find that it doesn't, in fact, work. Apparently the shell performs a lookup of the access rights of the program you're trying to execute, meaning once you've done "chmod -x chmod", you really have created yourself a problem.
I think the last slide just points out that there is no problem. The presenter never said you had to fix the chmod situation, just that the machine can't be rebooted. Maybe I misinterpreted...