Hunting the Ibis
October 27th, 2019
Charles de Gaulle Airport, Paris

Even Google is in on it.
The recommended route from
Terminal 3 to Terminal 2
involves a train ride
a bus, an Uber
and a 37 minute walk.

I am, as Dave Barry might assure us,
not making this up.

Samuel Johnson not withstanding,
I am tired of Paris.

Not the Champs Elysees
or l’Arc —
I never made it that far.

CDG strives to offset
any good memories of Paris itself.
Life, it says, is not all roses.
Here, have some thorns.

During the war,
they painted over the road signs
to keep the enemy from
finding their way.

I come in peace.
The war is long over.
I seek only a place to sleep.

Hell is not, as JP tells us
other people.
No, it is wandering
Charles de Gaulle at 11:30,
looking for the Ibis,
as though it were not a cheap hotel,
but rather the bird of legend
flying mournfully over the rolling waves
looking for somewhere,
anywhere,
to land for the night.

Today I spent 90 minutes on the phone with Windstream Support for a 2-minute problem.

My dad bought a new DSL modem to replace the one that Windstream provided, so that he could own it and not have to pay a monthly rental fee. Smart move.

Ordinarily, the way these things work is that you unplug the old one and plug in the new one and everything just works. When this did not happen, I called Windstream Support, and there The Saga Begins.

The DSL light kept blinking for several minutes, indicating that it was not getting a connection to the internet service provider.

The first person that I talked to, told me that I needed to contact the hardware manufacturer who would connect in to the modem and change the configuration settings.

This is plainly not true. It is impossible for the hardware manufacturer to connect in if the modem is not connecting to the internet in the first place.

I called back and got a different person, who insisted that the problem was that I had a temporary email address attached to the account. That, also, was not true. And finally after over an hour of pointless back and forth, he finally escalated me to a level 2 network engineer.

The level 2 engineer looked up the model number of the modem that I was using and said that it was an ADSL modem and I needed a VDSL modem, and recommended an option. This took about 2 minutes.

I don’t know the difference between ADSL and VDSL, and, of course, as a customer, I shouldn’t have to.

My beef here is not with incompetent first line support. Of course they’re not competent. I don’t blame them for that. I understand that they are following a script to solve common problems. But intentionally training them to give misleading – and even completely false – answers is not okay.

My objection, rather, is with policies specifically designed to discourage people from owning their own hardware. If they make it as complicated as possible, they can continue to charge a monthly rental fee for equipment, rather than allowing people to control their own network infrastructure.

Someone without a technical background would simply give up at the first hurdle, and not bother trying to buy their own hardware. By making my parents feel stupid and incompetent, they could probably have tricked them into spending more money for something they didn’t actually need. This behavior is predatory and unethical.

Buying a new DSL modem should not be any more complicated than buying a new phone. You plug it in and it just works. Windstream is intentionally creating a situation where people pay more money for things they don’t need. Someone shouldn’t need a technical background or network engineer training in order to connect to the internet.

Isabel recently asked some questions about serving on the Apache Software Foundation board of directors. Here’s my responses:

In your opinion – what are the strengths of the ASF board?

Over the years I have marveled at the poor design decisions in hotels around the world, from the “half wall” shower enclosures to those ones where the entire bathroom area is the shower. Here’s the latest entry in the contest – my bathroom in my hotel in Singapore. This one warrants a video.

I’ve been stewing on this all morning.

https://twitter.com/mairin/status/1094653366624501761?s=19

There’s two issues here.

The obvious one is, of course, that Máirín is a design powerhouse who does the work of 4 mortals, and this blowhard doesn’t know who she is. The disrespect here is stunning.

(For whatever it’s worth, I can’t find any mention of you on any of the Fedora mailing list archives. Are you sure *you* aren’t the no-name rando?)

But there’s – to me – the larger issue. Even if Máirín was a “no name”… even if she wasn’t brilliant and talented, this would STILL be incredibly inappropriate.

This kind of dismissal of new contributors is what leads to dead projects. Every project – every language, every nation, every company – is one generation from extinction. Failure to nurture the next generation is suicide by arrogance.

So the question here is, what do you even mean by “community” when you make statements like this? Do you mean that you want a comfy place for you and your 3 friends, or do you actually want to build something amazing that goes on after you are no longer involved? ‘Cause it sure sounds like you don’t have any clue about what it takes to foster a sustainable culture.

I’d also ask you, Thomas Alps, whoever you are, to cast your mind back to when you, too, were a “no-name rando”. If you had received this kind of hate at that moment, would you still be here?

Today’s no-name randos, as you so charmingly call them, are tomorrow’s core community. Or, more likely, not, if they receive this kind of welcome.

Yesterday I acquired one of these:

It’s an HDMI capture device. You can get one on Amazon.

The idea is that you plug it into any device that has HDMI output, such as your computer, video game console, etc, and you can then record that audio/video stream on your computer using standard video tools.

I got it so that I can produce better videos at the events that I host, such as the one next week in Brussels. The idea is that I can capture what’s getting sent to the main projector, and then merge it with the camera footage of the speaker, producing a video that has both sources of content.

Step one was getting it working on Linux, which was much easier than expected. I am running Fedora 29, but the techniques here should work on any Linux.

First I connected the device to the source as shown in the diagram:

In my case, I was testing with a PS4, but any HDMI source will work. The USB output, I plugged into my laptop.

Next, I installed OBS Studio. On Fedora, this is done via

sudo dnf -y install obs-studio

You can read more about OBS Studio on the project website. It’s clearly a very powerful piece of software, and I’m only using one feature.

In OBS Studio I created a “Scene” at the lower left corner of the app. (It doesn’t matter what you call it.) I then created a Source, selecting “Video Capture Device”, or possibly the actual name of the device, as the source, and “Camera 1” as the Input. You may need to fiddle with this depending on whether you have other cameras (such as a web cam) attached to your computer, which may change the naming/ordering of Inputs in that list.

Note that you can, if you wish configure several Sources at a time, so that you can, for example, record your gaming system, along with a picture-in-picture of your webcam, so that you can give running commentary. That kind of thing is popular on YouTube.

Finally, click “Start Recording”, which will create a .flv file in the location you have configured to save files. (By default, it’s in your home directory. Configure in File -> Settings -> Output.)

When you’re done, click “Stop Recording”, and you’re done. You can then edit that .flv file in your favorite editor. (I use kdenlive.)

Note that the resulting video will have the audio from the HDMI source, and also from whatever onboard mic(s) you have, so if that’s not your intent, set your system audio settings accordingly.

And, because I used my PS4 to experiment with, here’s some footage of me driving my Ferrari in Miami.

The eventual intent here is not just to record driving games (although that’s pretty cool) but, like I said, to produce more useful videos from the CentOS Dojos. So stay tuned to the CentOS YouTube channel, and *hopefully* in the next few weeks we’ll have video produced using this technique, including the slides and the presenter, complete with picture-in-picture format.

Re: this tweet from Cal:

I have been blogging for more than 13 years. Overall, I have averaged 3 blog posts per month in that time. #imOld

— Uncle Cal (@CalEvans) January 22, 2019

I have been blogging for 17 years – at least, on this current blogging platform. In that time, I have posted 2,276 Posts, which gives an average of 11 posts per month.

Looking back to the early days – especially 2002 – it looks like I was blogging multiple times per day, sometimes.

In recent years, it’s been a lot slower. In fact, it looks like in 2018 I posted just 16 times. Which is, to be honest, a lot more than I thought I had.

Each year I determine to Facebook and Tweet less, blog more. By around March I seem to have lost the determination. This year, maybe I’ll do better.

Inspired by Cal’s recent Twitter thread about conference talk rejection, I have been thinking about why conference talks are rejected.

I’ve been participating in running conferences and other events for more than 15 years, in one capacity or another. The part of the process I most dread is when you get the email from the rejected speaker.

“Why was my talk rejected?”

Or, even worse:

“Can you give me some tips that will help me get my talk accepted next time?”

The trouble is, that’s just not how any of this works.

It is almost never the case that talks are rejected. Rather, they are not accepted. This may seem like sophistry, but it’s really true.

For the normal event that I am involved with, we get anywhere from 2 to 5 talk submissions for each available spot in the schedule. A conference is bounded by space, time, and budget limitations that say that you can only have N talks at the event. N is often eroded even further by the need to have keynotes, sponsored sessions,  invited presentations, coffee breaks, and so on.

The upshot is that for every talk you schedule, you’re going to have to reject somewhere between 1 and 4 other talks. As much as you want to, you just can’t schedule everything, even when they’re all awesome.

Now, at the start of the process, there are in fact a few clunkers – talks that you’ll reject because they’re awful, off-topic, spam, or offensive. That’s easy, and I feel no remorse whatsoever about those ones.

The next step is harder. You have to decide what kind of story you want to tell with your content. You want to select a schedule that allows the attendee to take a journey. Perhaps it’s from beginner to expert. Or perhaps it’s a tour of a particular topic, covering all of the high points, and a handful of the deep-dives. The more sessions you have submitted, the more you can craft that story.

This allows you to have an event that crafts a narrative, rather than just having a pile of talks. That, in turn, means that you might schedule a talk that is a 9 out of 10, while dropping a talk that is a 10 out of 10, but which doesn’t fit the narrative, or which is a duplicate of content in another awesome talk.

When you’re done, you have your list of accepted talks, and then you have everything else.

This DOES NOT MEAN that the “everything else” was crap. It means that it didn’t fit the story that you were trying to tell.

And so you send out the reject notifications that say something to this effect:

We regret to inform you that your talk was not accepted for our event. We get a lot of submissions, and have a very limited number of sessions to schedule. Unfortunately, we were not able to include your talk in that selection.

So when you get the followup email asking for the reasons that the talk wasn’t accepted, that’s never, ever, an easy question. Often there isn’t any answer at all, because the selection had nothing whatsoever to do with the talk that was not accepted, which may have been awesome. There’s really nothing they could have done differently.

If there’s one answer I can offer, it’s that you should collaborate with other submitters to craft a story. Get together with your community to decide what story you want to tell, and craft 3, 5, 10, 20 talks that tell that narrative, and present them to the event producers as a track, or a mini-conference, and explain what story you’re trying to tell with the track.

Are you training? Educating? Recruiting? Persuading?

If you attend these talks, in this order, you’ll go from being a Java newbie to being able to write a functional application.

Or

If you attend these talks, in this order, you’ll understand all of the important technologies in HPC, and how they interrelate.

That’s compelling, and I’d schedule that.

But if your talk is an island, unrelated to any other content at the event, even if it’s an awesome talk, chances are I won’t schedule it, because this isn’t about you. It’s about the event’s audience, and what they will take home with them.

And this is why, at ApacheCon North America 2019, I’ve asked ASF projects to sign up to run their own track, summit, mini-conference, or whatever they want to call it, and craft their own story to tell in that track. I want to foster that collaboration, and encourage each community to decide what story they’re trying to tell.

A few weeks ago, a colleague asked me what I believed to be the biggest threat facing open source today. I answered that I think it’s full-time open source developers, and the effect they have on part-time volunteer developers.

Long ago (it actually hasn’t been very long, it just seems that way sometimes) open source was developed primarily by part-time hobbyist developers, working on their evenings and weekends on things that they were passionate about. Sure, there were full-time developers, but they were in the minority. Those of us working a few hours on the weekends envied them greatly. We wished that we, too, could get paid to do the thing that we love.

Now, 20 years on, the overwhelming majority of open source development is done by full-timers, working 9-5 on open source software. (No, I don’t have actual statistics on this. This is purely anecdotally based on my daily observations. I’d love to see actual scientific data on this.) And those who are working nights and weekends are often made to feel that they are less important than those that are putting in the long hours.

Most of the time, this is unintentional. The full-timers are not intentionally marginalizing the part-timers. It just happens as a result of the time that they’re able to put into it.

Imagine, if you will, that you’re a evenings-and-weekends contributor to a project. You have an idea to add a new feature, and you propose it on the mailing list, as per your project culture. And you start working on it, a couple of hours on Friday evening, and then a few more hours on Saturday morning before you have to mow the lawn and take your kids to gymnastics practice. Then there’s the cross country meet, and next thing you know, it’s Monday morning, and you’re back at work.

All week you think about what you’re going to do next weekend.

But, Friday evening comes, and you `git pull`, and, lo and behold, one of the full-timers has taken your starting point, turned it in a new direction, completed the feature, and there’s been a new release of the project. All while you were punching the clock on your unrelated job.

This is great for the product, of course. It moves faster. Users get features faster. Releases come out faster.

But, meanwhile, you have been told pretty clearly that your contribution wasn’t good enough. Or, at the very least, that it wasn’t fast enough.

The Cost of Professionalism

And of course there are lots of other benefits, too. Open source code, as a whole, is probably better than it used to be, because people have more time to focus. The features are more driven by actual use cases, since there’s all sorts of customer feedback that goes into the road map. But the volunteerism that made open source work in the first place is getting slowly squelched.

This is happening daily across the open source world, and MOST of it is unintentional. People are just doing their jobs, after all.

We are also starting to see places where projects are actively shunning the part timers, because they are not pulling their weight. Indeed, in recent weeks I’ve been told this explicitly by a prominent developer on a project that I follow. He feels that the part timers are stealing his glory, because they have their names on the list of contributors, but they aren’t keeping up with the volume of his contributions.

But, whether or not it is intentional, I worry about what this will do to the culture of open source as a whole. I do not in any way begrudge the full-timers their jobs. It’s what I dreamed of for years when I was an evenings-and-weekends open source developer, and it’s what I have now. I am thrilled to be paid to work full time in the open source world. But I worry that most new open source projects are completely corporate driven, and have none of the passion, the scratch-your-own-itch, and the personal drive with which open source began.

While most of the professional open source developers I have worked with in my years at Red Hat have been passionate and personally invested in the projects that they work on, there’s a certain percentage of them for whom this is just a job. If they were reassigned to some other project tomorrow, they’d switch over with no remorse. And I see this more and more as the years go by. Open source projects as passion is giving way to developers that are working on whatever their manager has assigned, and have no personal investment whatsoever.

This doesn’t in any way mean that they are bad people. Work is honorable.

I just worry about what effect this will have, and what open source will look like 20 years from now.

We watched Blues Brothers last night.

Like many movies that have been hyped and built up to me over the years, this one completely failed to live up to the promise.

The premise of the movie is that Dan Aykroyd repeats a particular kinda funny line a dozen times, and lots of famous people are in unexpected situations.

I suspect, that if I had watched Saturday Night Live more as a kid that the movie would have had more appeal. I didn’t, and it didn’t.

So I give this movie a B+ for a pretty decent, if utterly absurd, car chase at the end. But a D in all other respects. The plot was weak and the acting was terrible.

Ironically, as is often the case in situations like this, I think I actually would have enjoyed the movie more had it not been promised as the greatest movie of all time for so many years, by so many people.