Like many institutions, I’m using a video conferencing client whose name rhymes with “Vroom” in order to conduct classes. Things were going great for the first 2 weeks. Last Friday, things took a serious turn.
It all started with a long-standing problem on my home desktop machine. I run Ubuntu Linux 18.04 on a hand-built computer. The board is an Intel motherboard from about 5-10 years ago. I use an NVIDIA-based graphics add-on card, and like all Linux users who employ NVIDIA technology, I have made a Faustian bargain. NVIDIA cards are cheap and faster than their competitors, like AMD, for the same price point. But, their drivers are closed-source. Sure, I can use the “Nouveau” open-source driver… but then I cannot have two monitors connected to the card, and I need two monitors for work reasons (not the least of which is the utility of having two monitors when teaching with Vroom).
So I use the proprietary driver. But this seems to make my desktop graphics unstable. The old symptom was that the KDE window environment’s graphics compositing system would reset, usually at least once an hour (it doesn’t matter if I use XRender, OpenGL2, or OpenGL3… for those of you who care about the details). If I were running a lot of programs that take advantage of graphics capabilities (and I don’t mean anything fancy here, just a web browser and a code editor will do the trick) the compositing system resets happened more often. Sometimes, the graphics shell freezes and needs to be restarted; sometimes, the window manager crashes.
I tried buying and installing an AMD card on my system (they play nice with open-source), but the easiest cards to get are of a generation that doesn’t work with my motherboard (too new). The past generation cards are used and expensive, with worse graphics memory than my NVIDIA card. So that didn’t work for a bunch of reasons, not the least of which was the system would not even boot up!
I’ve tried using different generations of the NVIDIA drivers for Linux (there are BUNCH). I tried older generations, which seemed to help the graphics resets… but didn’t completely stop the problem.
Then, on Friday (on top of all of this!), all hell broke loose with Vroom. Suddenly, the client couldn’t stay up for more than 10 minutes at a time. It would crash and completely interrupt a meeting or class. It happened again tonight during Honors Physics. It was MADDENING.
I realized that although I updated the Vroom client about 10 days ago, a new version is already available. I upgraded that tonight. Who knows if that will solve it?
Bottom line: I have to have my laptop up and running as a backup teaching system in case the desktop goes down in flames. Vroom is another kind of Faustian bargain [1]: easy-to-use video teaching and conferencing capability, at the expense of no clear control over privacy and identity and a closed-source software architecture, which invites flaws by accident and design.
Sigh. When the smoke clears on all of this, I hope to have some time to slow down and think about the long chain of technology issues that are piling up at home. But there is no time to think now…
[1] See Doc Searls’s excellent series of posts about Vroom and all the good and bad it can do: http://blogs.harvard.edu/doc/
P.S. There is no Linux PPA to automatically install the latest Vroom (THANKS, Vroom). I wrote a cron script that others might find useful to check for a new version and install it if one exists)
#!/bin/bash
if [ ! -e "/var/spool/zoom" ]; then
mkdir -p /var/spool/zoom
fi
cd /var/spool/zoom/
if [ -e "zoom_amd64.deb" ]; then
rm -f zoom_amd64.deb
fi
wget 'https://zoom.us/client/latest/zoom_amd64.deb'
old_version=$(dpkg -s zoom | grep '^Version:' | cut -d ' ' -f 2)
new_version=$(dpkg-deb -f zoom_amd64.deb Version)
if [ $old_version == $new_version ]; then
exit
fi
while fuser /var/lib/dpkg/lock; do
echo "Waiting for dpkg lock to be released..."
sleep 30
done
dpkg -i zoom_amd64.deb
