Awe in Iceland

The Greater Good Institute at Berkeley considers awe one of the keys to well-being:

Awe is the feeling we get in the presence of something vast that challenges our understanding of the world, like looking up at millions of stars in the night sky or marveling at the birth of a child. When people feel awe, they may use other words to describe the experience, such as wonder, amazement, surprise, or transcendence.

That’s the feeling I have at least once a day, every day, here in Iceland.

And it’s difficult to write a blog post about awe. Almost by definition, it’s an emotion that defies easy explanation. It has a mystique that risks being lost in the translation to plain language.

But if I can’t describe the feeling, I can describe why I’m having it.

Unique among my traveling companions, this is my first-ever trip out of my country of origin (🇺🇸) The sliver of gray in this image is the first thing I ever saw of a country not my own:

When we arrived, I got a passport stamp and exchanged currency – both brand new experiences. However mundane, they were novel for me and began waking me up to the new world I’d entered.

Our first few days were chilly, windy, and rainy. I was much happier about this than were my traveling companions. If our weather wasn’t pleasant, it was nonetheless exactly the immersive experience I was hoping for when I signed up for this trip.

In those first few days, I got to see this amazing waterfall:

I got to participate in collecting soil samples at a glacier —

Solo!

— and in howling wind on the side of a moraine:

The right side of the moraine was calm and quiet. The left was much less so.

For good measure, I saw floating blue ice for the first time:

All this was great, and to me they made this trip worth the months of planning and days of travel difficulties it took to get here.

Then we got to Skalanes, where I’m writing this post, and its landscapes exist on a whole other level. Here are ten views here, drawn almost at random from my photos:

This is a country that absolutely runs up the score on natural beauty.

I’ve taken hundreds of pictures here and they’re all amazing – but none does justice to actually being here. That combination is the signature of an awe-inspiring experience.

Awe puts us in touch with something above and beyond our daily worldly experience – call it the divine, the sublime, whatever speaks to you. It’s an experience you can reproduce if you try, but I believe it connects most deeply when it emerges organically from the world you enter. That’s what’s happened to me here.

It is remarkable that this is what we get to do for work, and I am so glad we have some more time to spend here in this awesome country.

Cross-posted at the Earlham Field Science blog.

“A lot of people” – a brief note

Pet peeve: “A lot of people say X” or similarly “A lot of people do Y”.

There’s a lot of people in general: ~330,000,000 in America alone. If you look hard enough, you can find *somebody* who will say/do almost literally anything.

If 1% of Americans believe something, that’s over 3 million believers. That’s both a huge number of people and hardly anybody, depending on your context.

I find this usually isn’t a problem in writing, where with minimally competent phrasing/structure the context is clear. During chit-chat or as used by the likes of Fox News, it can be (often purposely) obtuse.

I like us to try to be specific, is what I’m saying. 🙂

Originally a Twitter thread.

Iceland is on track for summer

Discussions are ongoing about the viability of summer travel given the pandemic. However, as my colleague Charlie has blogged recently, we are “acting as if”. As such, we are trying to maintain our original calendar.

Lo and behold, we have:

Imagine a “You are here” arrow by Spring 1

Here’s the full breakdown of that schedule and our progress:

Our plan for the fall was to find and test alternative UAV’s. This proved prudent, as the federal government banned DJI craft late last year. We are happy with both the Parrot and the Skydio craft, for different reasons which we’ll undoubtedly cover here on this blog in the future.

December and January, which were effectively a long winter break for a subset of us, were dedicated to testing the craft, capturing initial video, and possibly beginning development. This was a success as well. Additionally we have begun spinning up a more sophisticated web presence for the stories we’re telling – changes we will be prepared to publish soon.

We’ve now started the calendar for the spring, term 1 of 2. We are moving into scaling up our operation of the craft and developing software to automate that work. It’s a tough problem but one we can solve in the time we have.

We’re optimistic about our ability to meet the moment. If the world continues to make progress on COVID-19, we should be in shape to have a successful research trip.

2020 in review

You don’t need me to tell you 2020 was a bad year. Others will write about the details that apply nationally and globally, so I’m going to jump right into my own retrospective.

The 2020 wallowing

I was planning on a trip to Iceland followed by a new job with room for advancement in 2020. Instead I stayed at my current job (a good job!), made an attempt at a side hustle that has so far largely fizzled, and was obviously not able to go to Iceland. I didn’t visit family in Montana for Thanksgiving or Christmas. At work, I made a few dumb mistakes (we did rebound in each case, happily). It was, on net, a rough year.

That’s about all I have to say about that. I don’t want to wallow too much, but I also don’t want to go further without acknowledging the struggle.

The better stuff

All that said, the rest of this post summarizes my accomplishments for the year. I write this to remind myself that even though it didn’t generate those external signals, I still did a lot. I advanced my skillset, did my job well, and patched through the year.

Accomplishments:

  • Got out of bed every day and went back to sleep every night
  • Kept Earlham CS running through the pandemic, student dispersal, lockdown, and restricted return
  • Modernized our systems engineering infrastructure with better monitoring, solid backups, improved responsiveness to inquiries, and higher availability – still a long way to go, but we’re so much better than we were a year ago
  • For each error I made, rebounded and learned a lesson
  • Migrated our cluster infrastructure from Torque to Slurm successfully
  • Learned a bunch of low-level details about filesystems, SELinux, and more en route to improving overall quality
  • Took 10,000 steps most days and got outside frequently
  • Provided a lot of internal tech support, engineering, feedback, and project contributions to the projects associated with the Iceland program
  • Made checking LinkedIn a regular part of my routine, though I should use it more socially in the new year
  • Purely as a hobby, learned a ton about video and audio production

Casual observation: I posted a lot in February, and my tech achievements primarily happened over the summer.

I also want to dedicate a section to expanding my horizons. I couldn’t do it with travel, but there were a lot of new things I got the chance to explore this year:

  • On Spotify, listened to 1,408 new artists and 366 new genres (“genre” seems like a nebulous category, but I am taking the win)
  • Watched a lot of new movies, including the complete Hayao Miyazaki filmography
  • Learned to make curry! (this winter squash red Thai curry recipe is great)
  • Baked a pie – apple – for the first time, at Christmas
  • Grew my hair long for the first time in my life (it’s still growing actually – not getting a professional haircut during a pandemic)
  • Visited and walked new hiking trails

That was 2020 for me.

What’s next?

I can’t guarantee 2021 will be better than this year. However, I do have some broad intentions around a theme for the new year. I will do all that is in my control to make the next year better, and I hope you join me.

Extremely preliminary notes about the Parrot Anafi

After three extremely short flights, these are my notes about the Parrot Anafi drone.

We’re experimenting with different UAV’s as part of the Iceland terrestrial surveying program (we’re being optimistic about travel in 2021…). These are some notes with my initial observations.

This is based on the base case: taking the craft out, taking off, flying for at most a few minutes, and touching back down. As such, don’t take a single word of this as gospel – it’s just preliminary opinions for the historical record. 🙂

Short version of the review: holy portability! One thing I don’t like about the DJI Phantoms is that they are so heavy (both the craft and the RC-tablet unit). If it’s a pain here on-campus, where trips are short, I imagine it’s a pain in the field. The Anafi is ludicrously lightweight and doesn’t feel like a chore to carry around.

Video quality on the built-in camera is fantastic (4K etc.).

It’s not a perfectly seamless integration with our existing workflows. Within our group, for example, we usually use tablets, which are handy for their big screens. The Anafi seems built around the assumption of a phone. That’s true all the way down to the RC unit being designed to accommodate a phone but not a tablet. That’s different, but if we can only get this app for phones I am not necessarily sad about it.

There are many X factors I haven’t yet been thorough enough to review. For example: battery life, stability in breezes (heavy winds make most UAV’s hard to use), and the software/developer ecosystem.

These have been my extremely preliminary notes about the Parrot Anafi. It’s not even close to a comprehensive evaluation of everything we care about. Still, those usability factors are important if this is going to scale and be useful for others. So for now, I’m impressed.

CentOS 8 is going away

CentOS 8 is going away at the end of 2021 (emphasis added):

The future of the CentOS Project is CentOS Stream, and over the next year we’ll be shifting focus from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a current RHEL release. CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021. CentOS Stream continues after that date, serving as the upstream (development) branch of Red Hat Enterprise Linux.

We’re just going to walk into the ocean now…

Losing an HPC-friendly, enterprise-grade, stable, free operating system throws a wrench into our activities. We run several small CentOS clusters, though fortunately they all run CentOS 7 (maintenance updates till 2024). We have time to respond, but it will be extra work when it comes time to upgrade.

Here’s an aggregation of observations from the last couple of days:

  • The comments on that blog post speak bluntly.
  • The Beowulf email list is full of discussion already.
  • I see a lot of chatter now about Ubuntu and Debian. Both would be viable distros for the few CentOS 8 hosts we currently run. They may or may not fit cluster upgrade needs a few years from now.
  • Others have chimed in to mention Oracle Enterprise Linux (ehhhhh), a revival of Scientific Linux, NixOS, and GuixOS.
  • This replacement project, Rocky Linux, is in development here or maybe here (hard for me as an outsider to tell). It may go somewhere – or maybe not. I’ve seen others float their own forks as well. Maybe one will get traction, but who can say?
  • CentOS 8 was quite a bit different from CentOS 7. Hard not to feel frustrated at learning a new system just to see its lifespan cut short by eight years.
  • I put a note about this in our issue tracker today. It reads: “The path is straightforward and requires less data copying than some past migrations. We just need to have a good answer on the OS of choice. I imagine the community will converge on either a ‘correct’ answer or a few good answers relatively soon, but I don’t think we’re there yet.”
  • In short, for us: This will be fine, but it will also be annoying.

This does change our strategy for the next few months. We need a new external SSH server, for example, and it can’t reasonably be CentOS 8 anymore. Down the road, we will have cluster systems to upgrade, and I still have no idea what that looks like.

A 2020 success story from Earlham CS

I’m proud of something from this year – a real 2020 success story.

Earlham, winter 2020; 2020 success story

To give some backstory: January-March were maybe the roughest three months of my tech life to date. We had a cascade of server hardware failures that induced a lot of downtime. Total catastrophe. I’m grateful for my institution’s patience.

After a lot of extra hours in windowless rooms working on it, we did resolve those problems. We diagnosed the root causes and took steps to prevent similar issues in the future. I also learned a lot. (Some of the lessons from those days continue to guide us, and they’ve been imprinted on me forever.)

The very next day the March lockdowns started and the College sent everyone away.

We went all-remote for the rest of spring and shifted into hybrid mode for the fall. That increased the dependency on system availability. Naturally, I was uneasy about that after the stress of the spring term. I directed myself and the CS admin students to focus on uptime, iterative improvement, and minimal disruption.

What makes me proud is this: it worked.

Since resolving those issues in the winter and spring, we’ve been stable. Individual services and hosts have had issues, of course. Some of those issues took significant time and energy, and we’re still not perfect (probably never will be!). There is always more to fix, more to improve, more to automate, more to introduce.

But systematically we’ve operated without unplanned interruption since March.

We’ve faced uncertainty after uncertainty in 2020. But my colleagues and students have been able to count on our systems working. We’re not a giant shop here, but we have kept up with the changing times.

There it is: one clear 2020 success story. Engineering this success was a collaborative effort to which I’m just one contributor, but I am proud of it.

Tech improves pandemic life

I can’t imagine going through the COVID-19 pandemic without computers. Tech improves pandemic life, and it makes it easier for us to make good decisions.

For reasons of both personal caution and what I see as a moral duty, I am probably in the 80th percentile for cautious behavior during the pandemic. I live alone, and my job lends itself to remote work for almost everything. What’s more, my workplace is a socially-conscious liberal arts college. As a result, I interact with very few people (those I do see are always masked-up).

That lifestyle is only sustainable because of computer technology. I buy and pick up groceries through an app. Meetings take place over video chats. Songs or podcasts play in the background while I cook. I can stream almost anything I want to see. I’ve continued to learn and to work using some excellent rectangles.

Ron Swanson "This is an excellent rectangle." Tech life.

There are tradeoffs, of course, but I have basically lived this way since March. Doing so I have weathered the pandemic as well as I could hope (so far).

The national dialogue now includes a lot of chatter about how to stay safe for the holidays. I’m cautious and want to model good behavior. That means I’ll be on FaceTime for Thanksgiving, Christmas, and New Year’s Eve. That’s not great, and it’ll be sad not to be physically visiting family.

But for people like me, the alternative to a FaceTime holiday isn’t an in-person holiday, but a canceled holiday, spent in isolation. Thanks to the people in my industry, I don’t have to do that. Technology brings people together. It’s one reason I remain idealistic about the work I do.

Amidst the tragedies and terrors of 2020, pause to appreciate the age we live in and the cool things we’ve invented. Tech improves pandemic life – and improves life in general. There’s lots to worry about if you want (conspiracy theories, AI risk, etc.), but I’m happy to live in a technologically advanced society.

Jupyterhub user issues: a 90% improvement

photo of Jupiter the planet, as a play on words in the context of Jupyterhub user issues
Jupyter errors are not to be confused with Jupiter errors.

At Earlham Computer Science we have to support a couple dozen intro CS students per semester (or, in COVID times, per 7-week term). We teach Python, and we want to make sure everyone has the right tools to succeed. To do that, we use the Jupyterhub notebook environment, and we periodically respond to user issues related to running notebooks there.

A couple of dozen people running Python code on a server can gobble up resources and induce problems. Jupyter has historically been our toughest service to support, but we’ve vastly improved. In fact, as I’ll show, we have reduced the frequency of incidents by about 90 percent over time.

Note: we only recently began automatic tracking of uptime, so that data is almost useless for comparisons over time. This is the best approximation we have. If new information surfaces to discredit any of my methods, I’ll change it, but my colleagues have confirmed to me that this analysis is at least plausible.

Retrieving the raw data

I started my job at Earlham in June 2018. In November 2018, we resolved an archiving issue with our help desk/admin mailing list that gives us our first dataset.

I ran a grep for the “Messages:” string in the thread archives:

grep 'Messages:' */thread.html # super complicated

I did a little text processing to generate the dataset: regular expression find-and-replace in an editor. That reduced the data to a column of YYYY-Month values and a column of message counts.

Then I went and searched for all lines with subject matching “{J,j}upyter” in the subject.html files:

grep -i jupyter {2018,2019,2020}*/subject.html 

I saved it to jupyter-messages-18-20.dat. I did some text processing – again regexes, find and replace – and then decided that followup messages are not what we care about and ran uniq against that file. A few quick wc -l commands later and we find:

  • 21 Jupyter requests in 2018
  • 17 Jupyter requests in 2019
  • 19 Jupyter requests in 2020

One caveat is that in 2020 we moved a lot of communication to Slack. This adds some uncertainty to the data. However, I know from context that Jupyter requests have continued to flow through the mailing list disproportionately. As such, Slack messages are likely to be the sort of redundant information already obscured using uniq in the text processing.

Another qualifier is that a year or so ago we began using GitLab’s Issues as a ticket tracking system. I searched that. It found 11 more Jupyter issues, all from 2020. Fortunately, only 1 of those was a problem that did not overlap with a mailing list entry.

Still, I think those raw numbers are a good baseline. At one level, it looks bad. The 2020 number has barely budged from 2018 and in fact it’s worse than 2019. That’s misleading, though.

Digging deeper into the data

Buried in that tiny dataset is some good news about the trends.

For one thing, those 21 Jupyter requests were in only 4 months out of the year – in other words, we were wildly misconfigured and putting out a lot of unnecessary technical fires. (That’s nobody’s fault – it’s primarily due to the fact that my position did not exist for about a year before I arrived at it, so we atrophied.)

What’s more, the 19 this year are, by inspection, half password or feature requests rather than the 17 problems we saw in 2019, which I think were real.

So in terms of Jupyter problems in the admin list, I find:

  • around 20 in the latter third of 2018
  • 17 in ALL OF 2019
  • only two (granted one was a BIG problem but still only 2) in 2020

That’s a 90% reduction in Jupyterhub user issues over three years, by my account.

“That’s amazing, how’d you do it?”

Number one: thank you, imaginary reader, you’re too kind.

Number two: a lot of ways.

In no particular order:

  1. We migrated off of a VM, which given our hardware constraints was not conducive to a resource-intensive service like Jupyterhub.
  2. Gradually over time, we’ve upgraded our storage hardware, as some of it was old and (turns out) failing.
  3. We added RAM. When it comes to RAM, some is good, more is better, and too much is just enough.
  4. We manage user directories better. We export these over NFS but have done all we can to reduce network dependencies. That significantly reduces the amount of time the CPU spends twiddling its thumbs.

What’s more, we’re not stopping here. We’re currently exploring load-balancing options – for example, running Jupyter notebooks through a batch scheduler like Slurm, or potentially a containerized environment like Kubernetes. There are several solutions, but we haven’t yet determined which is best for our use case.

This is the work of a team of people, not just me, but I wanted to share it as an example of growth and progress over time. It’s incremental but it really does make a difference. Jupyterhub user issues, like so many issues, are usually solvable.