Other writing: January 2020

What have I been writing when I haven’t been writing here?

Stuff I wrote

Fedora

Stuff I curated

Fedora

Other writing: December 2019

Stuff I wrote

Red Hat/Fedora

Opensource.com

Stuff I curated

Red Hat/Fedora

SysAdvent

[solved] Can’t log in to KDE on Fedora 31

Earlier today, I ran dnf update on my laptop, as I do regularly. After rebooting, I couldn’t log in. When I typed in my user name and password, it almost immediately returned to the login screen. Running startx from the command line failed, too. I spent an hour or two trying to diagnose the problem. There were a lot of distracting messages in the xorg log.

The problem turned out to be that the startkde command was no longer on my machine. It seems upgrading from version 5.16 to 5.17 of the plasma-workspace package removes startkde in favor of startplasma-x11. Creating a symlink fixed it as a workaround.

This is reported as bug #1785826, and I’m sure Rex and the rest of the Fedora KDE team will have a suitable fix out soon. In the meantime, creating a symlink appears to be the best way to fix it.

Why the symlink works

When an X session starts, it looks in a few different places to see what should be run. One of those places is /etc/X11/xinit/Xclients. This file checks for a preferred desktop environment. If one isn’t specified, it works through a list trying to find one that works. It does this by looking for the specific desktop environment’s executable.

Since startkde no longer exists, it had no way of checking for KDE Plasma. I don’t have any other desktop environments installed on this machine, so there was no other desktop environment to fallback to. I suspect if GNOME were installed, it would have logged me into GNOME instead, at least when running startx.

So another fix would be to replace instances of startkde with startplasma-x11 in the Xclients file (similarly if you have that file in your home directory). However, this leaves anything else that might check for the existence of startkde in the lurch. (I don’t know if anything does).

There’s probably more options for fixing it out there; this is very much not my area of expertise. I’d have to say that this was the most frustrating issue I’ve had to debug in a long time, in part because it took me a while to even know where the problem was. The fact that moving my ~/.kde directory didn’t result in a new one being created told me that it was pretty early in the process.

What distractions did I see?

In trying to diagnose the issue, I got distracted by a variety of error messages:

  • xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
  • /dev/fb0: permission denied
  • gkr-pam: unable to locate daemon control file
  • pam_kwallet5: couldn't open file

Other writing: November 2019

What have I been writing when I haven’t been writing here?

Stuff I wrote

REd Hat/Fedora

Stuff I curated

Red hat/Fedora

Book review: People Powered

Jono Bacon knows something about communities. He wrote the book on it, in fact. And now he has written another book. People Powered is a guide for how companies can create and curate communities.

I often see companies try to start what they call “communities”. In reality, they are ways for the company to get free labor that provide no real benefit to the the participants. But it doesn’t have to be that way. A community that doesn’t benefit the sponsoring company is not likely to continue receiving sponsorship. But if there’s no benefit to the community members, the community will not thrive. Only when everyone involved gets value from the community will the community be vibrant.

A community mission is different than your business vision, but tightly wound around it.

All too often, books like this prescribe the One True Way™. Bacon does not do that. He fills the book with many things the reader should do, but he also makes it clear that there are many right ways to run a community, just as there are many wrong ways.

People Powered is a starting point, not an answer. As I was reading it, I thought “this is a good set of recipes”. Further on, Bacon used the same metaphor. Curse you, Jono! But it’s an apt metaphor. The book presents advice and knowledge based on Bacon’s 20 years of community management. But each community has specific needs, so the reader is encouraged to selectively apply the most relevant parts. And in the tradition of open source, plans should be iterative and evolve to meet the changing needs of communities. Like any good cook, the recipe provides a starting point; the cook makes adjustments to taste.

If I could sum up People Powered in two words, I would pick “be intentional.” Given two more words, I’d add “be selective.” People are often tempted to do all the things, to be all things to all people. And while that may be in the future of a community, getting started requires a more specific focus on what will (and more importantly, what won’t) be done.

People Powered is full of practical advice (including a lot of calls-to-action to find resources on jonobacon.com). But it also contains more philosophical views. Bacon is not a psychologist, but he has made a study of psychology and sociology over the years. This informs the theoretical explanations behind his practical steps. It also guides the conceptual models for communities that he lays out over the course of the book. And to prove that it’s a Jono Bacon book, it includes a few references to behavioral economics and several to Iron Maiden.

I really enjoyed this book. Some of it was obvious to me, given my community leadership experience (admittedly, I’m not the target audience), but I still got a lot of value from it. Chapter 9 (Cyberspace and Meatspace: Better Together) particularly spoke to me in light of some conversations I’ve had at work recently. People Powered is an excellent book for anyone who is currently leading or planning to lead a community as part of a corporate effort.

People Powered (affiliate link) is published by HarperCollins Leadership and was released yesterday.

Disclosures: 1. I received a pre-release digital review copy of People Powered. I received no other consideration for this post (unless you purchased it from the affiliate link above). 2. Jono Bacon is a personal friend, but I would tell him if his book was awful.

Other writing: October 2019

Stuff I wrote

Red Hat/Fedora

Stuff I curated

Red Hat/Fedora

New to Fedora: z

Earlier this month, I attended Chris Waldon’s session “Terminal Velocity: Work faster in your shell” at All Things Open. He covered several interesting tools, one of which is a project called z. z is a smarter version of the cd command. It keeps track of what directories you change to and uses a combination of the frequency and recency (“frecency”) to make an educated guess about where you wanted to go.

I find this really appealing because I often forget where in the file system I put a directory. And z is written as a shell script, so it’s easy to package and use.

z is now packaged and submitted to rawhide, with updates pending for F31 and F30.

Other writing: September 2019

What have I been writing when I haven’t been writing here?

Stuff I wrote

Red Hat/Fedora

Stuff I curated

Red HaT/Fedora

Sporting events should let meteorologists make weather decisions

Sporting events — particularly in the spring and summer when they’re generally done outdoors — present a hazard to participants and spectators alike. Thunderstorms can send a bolt of lightning in an instant, which can prove lethal. Part of the danger is that lightning can strike miles away from the storm, which means people who think they aren’t at risk might be very much at risk.

Many leagues and venues have adopted a largely sensible lighting policy. If lightning strikes within a certain radius, the activity is suspended and everyone is sent to shelter. After some amount of time without a strike (often 30 minutes), the activity resumes. This is, as a general concept, good advice.

Of course, it’s not quite as simple as “if you can see it, flee it. If you can hear it, clear it.” That’s the advice given to the public because it’s simple and easy to remember. But it doesn’t always capture the full story.

To give an example, this summer my local baseball team was playing a game as thunderstorms approached the area. A lightning strike occurred within the 10 mile radius defined by the Prospect League (as an aside, I appreciate the fact that they increased it from the 5 miles it used to be). The umpires suspended play late in the game (it was the 8th inning if I recall).

The trouble with this is that the storm was traveling perpendicular to the stadium. The strike that triggered the delay was well away from the storm and just inside the 10 mile radius. Essentially, it was as close as lightning would come. In this case, continuing play would be a safe decision. And it would have meant pitchers could stay warm and the crowd would have stuck around.

When it comes to weather safety, I’d always prefer overcaution to undercaution. But weather is complex, and the simple rules don’t always fit the situation. Sporting events should always leave weather decisions to meteorologists. High-profile near-misses have raised awareness, but it’s still not universal.

Decentralization is more appealing in theory than in reality

One of the appeals of open standards is that they allow market forces to work. Consumers can choose the tool or service that best meets their specific needs and if someone is a bad actor, the consumer can flee. Centralized proprietary services, in contrast, tie you to a specific provider. Consumers have no choice if they want/need to use the service.

It’s not as great as it sounds

This is true in theory, but reality is more complicated. Centralization allows for lower friction. Counterintuitively, centralization can allow for greater advancement. As Moxie Marlinspike wrote in a Whisper Labs blog post, open standards got the Internet “to the late 90s.” Decentralization is (in part) why email isn’t end-to-end encrypted by default. Centralization is (again, in part) why Slack has largely supplanted IRC and XMPP.

Particularly for services with a directory component (social networks for sure, but also tools like GitHub), centralization makes a lot of sense. It lowers the friction of finding those you care about. It also makes moderation easier.

Of course, those benefits can also be disadvantages. Easier moderation also means easier censorship. But not everyone is capable of or willing to run their own infrastructure. Or to find the “right” service among twenty nearly-identical offerings. The free market requires an informed consumer, and most consumers lack the knowledge necessary to make an informed choice.

Decentralization in open source

Centralized services versus federated (or isolated) services is a common discussion topic in open source. Jason Baker recently wrote a comment on a blog post that read in part:

I use Slack and GitHub and Google * and many other services because they’re simply easier – both for me, and for (most) of the people I’m collaborating with. The cost of being easier for most people I collaborate with is that I’m also probably excluding someone. Is that okay? I’m not sure. I go back and forth on that question a lot. In general, though, I try to be flexible to accommodate the people I’m actually working with, as opposed to solving the hypothetical/academic/moral question.

Centralization to some degree is inevitable. Whether build on open standards or not, most projects would rather work on their project than run their infrastructure. And GitHub (like Sourceforge before it), has enabled many small projects to flourish because they don’t need to spend time on infrastructure. Imagine if every project needed to run it’s own issue tracker, code repository, etc. The barrier to entry would be too high.

Striking a balance

GitHub provides an instructive example. It uses an open, decentralized technology (git) and layers centralized services on top. Users can get the best of both worlds in this sense. Open purists may not find this acceptable, but I think a pragmatic view is more appropriate. If allowing some proprietary services enables a larger and more robust open software ecosystem, isn’t that worthwhile?