Booth Tarkington on “The Golden Bachelor”

This weekend, it came to my attention that ABC is making a change in its long-running dating show The Bachelor. A 71 year old man will be the first “golden bachelor” in the upcoming 28th season. I don’t have much of an opinion on the show generally or the new season particularly, but I couldn’t help but think of Booth Tarkington’s Pulitzer Prize-winning The Magnificent Ambersons.

Youth cannot imagine romance apart from youth. That is why the roles of the heroes and heroines of plays are given by the managers to the most youthful actors they can find among the competent. Both middle-aged people and young people enjoy a play about young lovers; but only middle-aged people will tolerate a play about middle-aged lovers; young people will not come to see such a play, because, for them, middle-aged lovers are a joke—not a very funny one. Therefore, to bring both the middle-aged people and the young people into his house, the manager makes his romance as young as he can. Youth will indeed be served, and its profound instinct is to be not only scornfully amused but vaguely angered by middle-age romance.

Booth Tarkington, The Magnificent Ambersons

In an interesting coincidence, both Tarkington and the “Golden Bachelor” are from Indiana. At any rate, I suppose ratings will tell if Tarkington was right or not.

Ended, the clone wars have?

I have done my damnedest to avoid posting publicly about Red Hat’s decision to stop publishing RHEL srpms. For one, the Discourse around it has been largely stupid. I didn’t want any part of the mess. For another, I didn’t have anything particularly novel to add. I’m breaking my silence now because the dust seems to have settled in a very beneficial way that I haven’t seen widely discussed. (To be fair, since I’ve been trying to avoid the discussion, I probably just missed it.)

Full disclosure: as you may know, my role at Red Hat was eliminated earlier this year. This does not make me particularly inclined to give Red Hat as a company the benefit of the doubt, but I try to be fair. Also: during my time at Red Hat, I was the program manager for the creation of CentOS Stream. However, I did not make business decisions about it, nor did I have any say on the termination of CentOS Linux or the recent sprm change.

My take on the situation

I won’t get into the entire history or Red Hat Enterprise Linux, clones, or competitors here. Joe Brockmeier’s ongoing “Clone Wars” series covers the long-term history in detail. I do think it’s worth providing my take on the last few years, though, so you understand my take on the future.

First of all, I don’t think Red Hat (or IBM, if you’d rather) acted with evil intent. That doesn’t mean I think the decision was correct, but I do think it was a legitimate business choice. I disagree with the decision, but as much as they didn’t ask me before, they sure as hell don’t ask me now.

If RHEL development started out with a CentOS Stream model, I’m not sure CentOS Linux (and the other RHEL clones) would have existed in the first place. But we don’t live in that timeline, so RHEL clones exist.

There are plenty of valid reasons for wanting RHEL but not wanting to pay for the subscription. It’s not just that people are being cheap. Until 2018, users of Spot instances on Amazon Web Services couldn’t use RHEL. In a former role, we had RHEL customers who used CentOS Linux in AWS precisely because they wanted to use Spot instances. Others used CentOS Linux in AWS because they didn’t want to deal with subscription management for environments that might come and go. (I understand that subscription-manager is much easier to work with now.)

So while Red Hat may be right to say that RHEL clones don’t add value to Red Hat (and I disagree there, too), RHEL clones clearly add value for their users, which include Red Hat customers. It’s fair to say that, for some people, the perceived value of a RHEL subscription does not match what Red Hat charges for it. How to solve that mismatch is not a problem i’m concerned with.

So what now?

Two community-driven clones popped up in the immediate aftermath of the death of CentOS Linux: Rocky Linux and AlmaLinux. Both of these aimed to fill the role formerly held by CentOS Linux: a bug-for-bug clone of Red Hat Enterprise Linux. I never quite understood what differentiated them in practice.

But now duplicated effort becomes differentiated effort. Rocky Linux will continue to provide a bug-for-bug clone. AlmaLinux, meanwhile, will shift to making an ABI-compatible distribution — one where “software that runs on RHEL will run the same on AlmaLinux.” This differentiated effort allows those communities to serve different use cases. They now have their own niche to succeed or fail in.

Time will tell, but I think Alma’s approach is a better fit for most clone users. I suspect that most people don’t need bug-for-bug compatibility (except in the XKCD #1172 scenario). For many use cases, CentOS Stream is suitable. Of course, people make decisions based on what they think they need, not what they actually need. Third-party software vendors may end up being the deciding factor.

Given the different approaches Rocky and Alma are taking, I think Red Hat’s decision ended up being beneficial to the broader ecosystem. I don’t think it was done with that intent, and I am not arguing that the ends justify the means, but the practical result seems positive on the whole.

Buy autographed copies of my book for Flock to Fedora

Note: this commercial post was approved by the Fedora Council

If you’ll be attending Flock to Fedora — Fedora’s annual contributor conference — in Cork, Ireland this August then I want to sign a copy of Program Management for Open Source Projects for you. Use the online order form before 22 June (and use promo code FLOCK2023 for a $5 discount).

Continue reading

Other writing: May 2023

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

Stuff I wrote

Duck Alignment Academy

Fedora

Book review: If Nietzsche Were a Narwhal

I recently read Justin Gregg’s If Nietzsche Were a Narwhal: What Animal Intelligence Reveals About Human Stupidity. As humans, we tend to assume that our intelligence sets us apart and that our exceptional cognitive abilities are good. There’s no doubt that we’re exceptional, but it’s not clear that we’re good. As Gregg wrote:

Our many intellectual accomplishments are currently on track to produce our own extinction, which is exactly how evolution gets rid of adaptations that suck.

Unique among Earth’s animals, humans have bent our environment to our will. This, of course, has resulted in some undesirable side effects. Despite all of our supposed advancement, we are biologically predisposed to prioritize immediate needs over long-term needs. We get benefit from burning fossil fuels now and assume that we’ll be able to deal with the long-term impacts later. But will we?

Gregg studies animal cognition, so this book is steeped in facts. Indeed, the reader will probably learn more about animals than people. And after reaching the end, the reader may find it’s hard to disagree with Gregg’s assertion that Nietzche — and the rest of the species — would have been happier as a narwhal.

Evolution has many dead ends. It could be that what makes us special actually makes us less happy. Humans have a relatively short time on Earth, so it’s folly to assume that our unique adaptations aren’t maladaptive. It reminds me of the joke where an angel is talking to God about creating humans and says “you’ve ruined a perfectly good monkey. Look, it has anxiety!”

I didn’t come away from this book convinced that human cognition is a bad thing on balance. But as a philosophical starting point, I see a case for Gregg’s argument that “human intelligence may just be the stupidest thing that ever happened.”

Suggestions for Netflix profile improvements

As you may have heard, Netflix is beginning to crack down on password sharing. You may have already received the email inviting you to pay an extra eight dollars per month for additional households on your account. Even though Netflix tacitly (or even actively in some cases) encouraged password sharing for many years, I don’t hold this against them. On the other hand, they could definitely make life a lot easier by making profiles shareable.

Sharing profiles

The prime (heh) example comes from my house. I share my account with my ex wife because we have joint custody of the kids. This allows them to keep track of where they are in a show no matter which house they happen to be watching at. If I could share the profile, then I’d have no reason to share the account.

But I thought of another idea as I tried to describe this to the customer support representative. Profile sharing would make it much easier to travel or visit a friend’s house. If you could temporarily share your profile with another account, then it’s easy to use your profile at someone else’s place. This is less of a hassle, in theory, than logging out the owner, logging yourself in, and hoping you remember to log yourself out when you’re done.

Combining accounts

Another frustration is that you can’t move a profile to an existing account. When Netfix says “People move. Families grow. Relationships end. But throughout these life changes, your Netflix experience should stay the same.” what they mean is “you can always move a profile to a new account, you can never combine accounts.” Did you move in with someone who already had an account and you want to combine them? Too bad! One or both of you need to lose your profile.

I get why they have this ratchet. More accounts means more money. Combining accounts means they get less money. But also it’s kind of shitty. When Netflix was the only(-ish) game in town, it didn’t really matter. But now there are many streaming choices and people are starting to think “hey, maybe I don’t need to subscribe to all of them!” Content choices matter the most, of course, but customer experience matters, too.

The lesson

If you want to please your customers and your product has personalization, you have to consider all of the ways that the personalization might need to be portable. Making it easy to create a new account is important, and can help you get more money. But making it easy to manage profiles in a way that fits how people’s lives actually work is an investment in long-term customer satisfaction.

#inaction bcotton

On 25 June 2018, I published a post called “It’s hattening”. After years of rejected applications, I was finally starting a job at Red Hat. On 24 April 2023, Red Hat announced a 4% reduction in global staff. As a member of that 4%, today is my last day at Red Hat.

What does this mean for Ben?

This is the first time I’ve been laid off from a job. I hope it will be the last, but who can say? I’d be lying if I said I haven’t felt a big range of emotions in the past three weeks: confusion, anger, sadness, amusement.

But I’ve also felt loved. I’ve received so much support from people since the news started spreading. It’s like that end scene of “It’s a Wonderful Life” and I’m George Bailey. I’m proud of the contributions I’ve made to the Fedora community over the last five years, and it feels good to have others recognize that.

While I won’t be contributing as the Fedora Program Manager anymore, I was a Fedora contributor long before I joined Red Hat, and I’m not letting them take that away from me. I’ll still be around Fedora in ways that spark joy, although perhaps not much at first as I let my wounds heal.

I’ve had the great fortune to build an incredible professional and personal network over the years. I’m already pursuing a few opportunities and if those don’t pan out, I’ll be asking for your help finding more. In the meantime, I have (at least) a few weeks to relax for a bit. There’s a ton of work to do around the house, many trails to hike, Program Management for Open Source Projects to promote, and an embarrassingly-large backlog for Duck Alignment Academy articles.

What does this mean for Fedora?

I’ve told folks that if Fedora falls off the rails, then I have failed. I’m working with Matthew, Justin, and others to ensure coverage of the core job duties one way or another. I’ve worked hard over the years to automate tasks that can be automated. The documentation is far more comprehensive than what I inherited.

No doubt there are gaps in what I’ve left for my successors. However, my goal is that in a few months, nobody will notice that I’m gone. That’s my measure of success. The only reason I’ve been successful in my role is because of the work done by my predecessors: John, Robyn, Jaroslav, and Jan.

As to what the broader implication behind the loss of my position might be, I don’t know. There’s no indication that my role was targeted specifically. There are definitely people in Red Hat who continue to view Fedora as strategically important. I wish I had a clearer understanding of how they chose people/roles to cut, but I’ll probably never know the process. What I do know is that I fully intend to still be participating in the Fedora community when my account hits the 20-year mark in May 2029.

Other writing: April 2023

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

Stuff I wrote

Fedora

Duck Alignment Academy

Stuff I curated

Fedora

In defense of Fedora’s release cycle

Earlier this week, Thorsten Leemhuis published a thoughtful post about what he’d change if he magically became the supreme leader of Fedora. In that post and subsequent commentary on Mastodon and Fedora Discussion, he talked about changing Fedora’s release cycle. Since the Fedora Linux release process is my job, I figured I should explain why I disagree.

Integration projects are different

If you haven’t read the post, you should. But here’s the short version: Fedora Linux uses a release model rooted in the 1990s and should move to a “modern” model. Thorsten suggests a one-month cadence for those who want the latest versions and a one-year “steady” release. Such a model has worked well for Firefox, he argues, and so it should work for Fedora.

The key reason I think this is wrong is because Firefox is a development project whereas Fedora is an integration project. Integration projects don’t write a lot of code, they take the work of others and turn it into a coherent whole. This is a fundamentally different kind of work and it takes longer by necessity.

You can’t reliably integrate disparate pieces when they’re in constant motion. That’s why we have freezes leading up to the beta and final releases — they give the QA team time to test against a stationary target. It takes time to run through all of the test cases that make Fedora Linux a reliable operating system. So the choice becomes reducing the pre-release testing or spending a significant portion of the cycle in a freeze, which limits the the usefulness of the one-month cycle.

You can solve some of this with automated testing. And the QA does do a lot of automated testing. But those tests still take time, and there are a lot of interrelated parts in a Linux distribution.

Six months isn’t magic

There’s nothing objectively correct about a six month release cycle. It’s mostly because that’s how you get two releases a year. If the calendar had 10 months, the release cycle would be five. But there is a lower bound where you’ve become a de facto rolling release, even if you still have discrete releases. I don’t know where exactly that boundary is, but I suspect that one month is at or just beyond it.

Similarly, there’s an upper limit where you’re now a slow, plodding project. Again, I can’t say where the line is. Six months may be uncomfortably close to it, but I suspect it’s closer to a year. And, of course, it depends on the nature of the specific project.

So there’s no particular reason Fedora Linux couldn’t move to a shorter release cycle. Five months is totally doable. Four is possible. Three would require a tremendous amount of work before it could be considered. But what’s the benefit of going to a shorter cycle? Does five months instead of six make a meaningful difference? At least with six months, you know there’s a release targeted for April and October. Predictability is nice.

Solving the actual problem

The bigger issue, though, is that I don’t think people actually want this. Yes, you might want your web browser and other applications to update frequently. But that doesn’t mean you want your compiler or Python interpreter or C libraries to update frequently. Most people will avoid this in favor of the “steady” stream. This eliminates the intended benefit to upstream projects.

The people who do want everything to update quickly use a rolling release distribution, something that Thorsten explicitly says his proposal is not.

Fundamentally, the proposal looks at the problem the wrong way. The problem isn’t that a six month cycle is too long. The problem is that application delivery is coupled to operating system delivery. Most people want the latest versions of the applications they care about and for everything else to remain unchanged. The challenge, of course, is that not everyone draws that distinction in the same way.

We unsuccessfully tried to solve this with Modularity. Flatpak, at least for graphical applications, offers another attempt to solve this problem.

Historically, the system and application layers have been distributed together. Figuring out how to decouple these (including how to draw the line between them) is the interesting work. And it provides real value to the end users.

Other writing: March 2023

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

Stuff I wrote

Duck Alignment Academy

  • Be clear about who does what — If you’re not clear about who is supposed to act, people will assume that it’s not them. Be clear so everyone knows what to expect.
  • Words mean things — Choose your words carefully. You want people to discuss the facts, not the wording.
  • Use a decision log to record context — A decision log is a record that you leave for the future. It shares the context to save time when revisiting a past decision.

Fedora

Stuff I curated

Fedora