I have the great honor of being on the organizing committee for the LISA conference this year. If you’ve followed me for a while, you know how much I enjoy LISA. It’s a great conference for anyone with a professional interest in sysadmin/DevOps/SRE. This year’s LISA is being held in Nashville, Tennessee, and the committee wants your submission.
As in years past, LISA content is focused on three tracks: architecture, culture, and engineering. There’s great technical content (one year I learned about Linux filesystem tuning from the guy who maintains the ext filesystems), but there’s also great non-technical content. The latter is a feature more conferences need to adopt.
I’d love to see you submit a talk or tutorial about how you solve the everyday (and not-so-everyday) problems in your job. Do you use containers? Databases? Microservices? Cloud? Whatever you do, there’s a space for your proposal.
Submit your talk to https://www.usenix.org/conference/lisa18/call-for-participation by 11:59 PM Pacific on Thursday, May 24. Or talk one of your coworkers into it. Better yet, do both! LISA can only remain a great conference with your participation.
Recently in the #public_speaking channel on Freenode, we were discussing two types of conference talks: the “how” talks and the “why” talks. SomeKittens said:
too many talks are “how” when I really want to hear “why”
I couldn’t agree more. I struggle with “how” talks at conferences because conferences are a fire hose of information and it can be hard to take it all in, never mind retain it. By the time I get back to real life and am ready to implement this new thing I’ve learned, I have forgotten so much. If I’m lucky, I can watch the recorded version a few months later. But then why did I go to the session in the first place?
“How” talks are also often meaningless without the context of “why”. What good is knowing how to frobble the bobulator if I don’t know why a bobulator needs to be frobbled in the first place?
“How” talks are often very specific. A certain person in a certain organization accomplished a certain task in a certain way. How much of that is applicable to another person in another organization? Even if they want to accomplish the exact same task, the conditions aren’t the same.
“Why” talks tend to be more about identifying and presenting principles that can be broadly applied. As genehack pointed out, they tend to be stories. Stories make for much more engaging talks.
If you were to think about a talk mapped to written form, consider a “how” talk like a blog post. It might give a bit of introductory context (and if not, it’s a bad post) but then it gets straight into the matter at hand. There’s a well-defined flow and set of steps. It’s very amenable to copy/paste-ing.
A “why” talk is more like a book or maybe a magazine. You’re not going to copy and paste from it. You may put it down partway through, mull it over, and then pick it back up later. The aim is less about accomplishing a particular task and more about developing a mental framework.
When you’re developing a conference presentation, come up with whatever you want. But at least consider making it a “why” talk.
There are many reasons I enjoy the annual gathering of HTCondor users, administrators, and developers. Some of those reasons involve food and alcohol, but mostly it’s about the networking and the knowledge sharing.
Unlike many other conferences, HTCondor Week is nearly devoid of vendors. I gave a presentation on behalf of my company, and AWS was present this year, but it wasn’t a sales pitch in either case. The focus is on how HTCondor enabled research. I credit the project’s academic roots.
Every year, themes seem to develop. This year, the themes were cloud and caching. Cloud offerings seem to really be ready to take off in this community, even though Miron would say that the cloud is just a different form of grid computing that’s been done for decades. The ability to scale well beyond internal resources quickly and cheaply has obvious appeal. The limiting factor currently seems to be that university funding rules make it slightly more difficult for academic researchers than just pulling out a credit card.
In the course of one session, three different caching mechanisms were discussed. This was interesting because it is not something that’s been discussed much in the past. It makes sense, though, that caching files common across multiple jobs on a node would be a big improvement in performance. I’m most partial to Zach Miller’s fledgling HTCache work, though the squid cache and CacheD presentations had their own appeal.
Todd Tannenbaum’s “Talk of Lies” spent a lot of time talking about performance improvements that have been made in the past year, but they really need to congratulate themselves more. I’ve seen big improvements from 8.0 to 8.2, and it looks like even more will land in 8.4. There’s some excellent work planned for the coming releases, and I hope it pans out.
After days of presentations and conversations, my brain is full of ideas for improving my company’s products. I’m really motivated to make contributions to HTCondor, too. I’m even considering carving out some time to work on that book I’ve been wanting to write for a few years. Now that would truly be a miracle.