|
|
Log in / Subscribe / Register

LWN's 2021 retrospective

By Jonathan Corbet
December 22, 2021
It may have seemed questionable at times, but we have indeed survived yet another year — LWN's 22nd year of publication. That can only mean one thing: it is time to take a look back at our ill-advised attempt to make predictions in January and see how it all worked out. Shockingly, some of those predictions were at least partially on the mark. Others were ... not quite so good.

The predictions

The first prediction made in January was that the world would emerge from the depths of the pandemic, and that in-person events would return. Needless to say, things didn't quite work out that way. The pandemic is still very much with us (and possibly about to take another turn for the worse) and, while a few in-person gatherings did take place toward the end of the year, most Linux events are still being held online. The free-software community does still appear to be holding up well, though; it may be true that staying home and interacting with our screens is all we ever wanted to do in the first place.

The prediction that support for CentOS 8 would end was, obviously, obvious; that is still scheduled to happen at the end of this year. Tied to that prediction was a suggestion that, in fact, CentOS 8 Stream might turn out to be good enough for many users, and perhaps even better for some. The lack of "CentOS 8 Stream broke my production system" stories suggests that may have come true, at least to an extent, though it is hard to know for sure.

We also included the prediction that there would be attempts to recreate old-style CentOS 8; given that those attempts were already underway at the time, we cannot claim credit for a lot of foresight. We highlighted Rocky Linux as the highest-profile effort, but lamented its lack of public discussions. Rocky Linux is still out there, and some public mailing lists have been added, but anybody looking for insights in the rocky-devel archives will be disappointed. Meanwhile, AlmaLinux appears to have stolen the spotlight and seems to be doing well, though its communication channels are not particularly friendly to casual browsers. In any case, the prediction that "most or all" of the CentOS 8 recreation efforts were likely to fail does not appear to have been borne out, so far at least.

It is hard to say what became of the prediction that openSUSE would need to better define its relationship with the SUSE mothership; things have been rather silent on that front. The effort to create an independent foundation as the home for openSUSE appears to have stalled, though it would not be surprising to learn that private discussions are ongoing. From what can be seen publicly, nothing has really changed.

Did it become possible to submit kernel patches without touching an email client? In truth, that was possible even before with tools like git send-email. Since then, some further progress has been made; a tool to turn a GitHub pull request into an email series is one relatively prominent example. Coming in the near future will be enhancements to the b4 tool and a new web service that will further remove the necessity for email to submit patches.

So that prediction can be counted as being at least partially successful, but it missed the other half of the equation, which could be expressed as "it will become possible to receive and apply kernel patches without using email". This, of course, refers to the lore+lei work that was recently made public, along with the ongoing work on b4. The kernel community isn't moving away from email anytime soon, but it will become increasingly easy to avoid many of the more annoying aspects of email in kernel development.

Did the commercial side of BPF become more prominent, as predicted? The increasing number of developers working on BPF and the commercial support behind projects like Cilium suggest that the answer is "yes".

The new GNOME 40 interface did make an appearance as predicted, but the expected complaints, for the most part, did not. The changes were not all that disruptive in the end, and it seems certain that most desktop users have, at this point, either made their peace with GNOME or found another solution that is more to their liking.

Included in our predictions was the statement that Python developers would have to think about the future of the language and when it might actually be "done". If long email threads are any evidence, there is clearly some thinking going on, but it still seems to be focused on the shape the new language features should take rather than how many more new features are appropriate at all. At least the prediction that there would be no Python 4 seems to be holding for now.

We predicted that software supply-chain attacks would be a serious threat. That threat is always with us and, on occasion, malicious packages (UAParser, Great Suspender, PHP) were indeed discovered to have been injected into popular repositories. But, as the series of Log4j vulnerabilities makes it clear, our worst enemy in this regard is probably still ourselves. We are quite accomplished at injecting our own vulnerabilities and have no need to outsource that work to outside attackers.

There has been an increase in antitrust enforcement activities, both in the US and Europe, as predicted. As also predicted, things are moving slowly, and there has been little practical effect so far. Also as predicted, the influence of OpenStreetMap continues to grow; the predicted clashes with the hobbyist base appear to have calmed down somewhat instead, though.

What was missed

All told, our 2021 predictions did not go all that badly; arguably that is the result of having not gone too far out on a limb back in January. But there is the associated question of what was missed: what did we fail to predict that we should have perhaps foreseen?

Sometimes the most obvious things can be the hardest to anticipate; consider, for example, the case of minor revision numbers for stable kernel releases. A single byte was set aside for those numbers, since nobody ever thought there would be more than 255 releases of a single stable series. But we live in a different world, with fast-arriving stable updates and kernels that are supported for several years. It should have been possible for us, and for the developers involved, to not only predict that those numbers would overflow, but to make a good guess as to exactly when that would happen. We were all caught by surprise anyway.

The addition of structural pattern matching into Python was a long time in coming with a good chance of happening in 2021. We even mentioned it while talking about Python, but didn't think to predict its acceptance.

It didn't occur to us that Richard Stallman might return to the Free Software Foundation's board of directors, but perhaps it should have. The FSF has always struggled to have an identity separate from its association with Stallman — if, indeed, it wants that at all. So letting him back in may have seemed like the best path forward despite the loud public backlash that resulted.

Perhaps it was not easily predictable that the whole UMN episode, where university researchers intentionally tried to insert buggy patches into the kernel, would happen in 2021. But certainly something like that was going to happen sooner or later; some developers had been warning about the prospect for years. Happily, the kernel's processes worked and, aside from a lot of wasted time, no real harm was done.

Another thing we perhaps should have foreseen but didn't was the intersection of machine-learning technologies and software development. That, too, was only a matter of time; it came to light this year in the form of the GitHub Copilot offering. The controversy over whether Copilot is a violation of free-software licenses has faded over the months, but it seems likely to return as these technologies mature and proliferate.

We have often predicted that the realtime preemption code would be merged into the mainline kernel — and just as often had to make excuses for that prediction when things didn't work out that way. So it is entirely fitting that, in the year when the realtime code really was merged, we didn't even think about predicting it.

Other notes

We lost a number of members of our community this year, including Kent Fredric, Karsten Loesing, Fredrik Lundh, and Jörg Schilling. They will be missed.

This year we produced yet another 50 LWN Weekly Editions; those contained 260 feature articles, of which 227 were written in house. Over 7,200 security alerts went into the weekly editions, along with about 4,300 kernel patches. Our conference coverage reflects the pandemic era, of course, but we still had coverage of eight events in 2021, and assisted with the organization of three of those. It has been yet another busy year — as usual.

At the end of the year we say goodbye to Rebecca Sobol, who is headed off into a well-earned retirement. While she was not present at the very beginning of LWN, she joined us shortly thereafter as the first person who was actually paid to work on LWN, and has been here ever since, even through the times when things looked grim and there was no money for payroll. Over the years she has written articles, attended conferences, herded authors, and interfaced with our group subscription managers; see her goodbye note for details. LWN would not be what it is without her participation, and she, too, will be missed.

There will be some changes at LWN next year as we seek to replace her, but it's not yet clear what form those changes will take; stay tuned. Meanwhile, we wish the best of the year-end holidays for all of our readers; it remains a privilege and an honor to write for, and be supported by, all of you. We will see you all back here next year.


to post comments

LWN's 2021 retrospective

Posted Dec 22, 2021 19:50 UTC (Wed) by smoogen (subscriber, #97) [Link]

I think the lack of chatter on the Rocky and Alma mailing lists may be a matter of change of communication habits. Most of the 'chatter' happens either in one of the IRC/Mattermost/Matrix cross-channels with what looks like equal number of questions from all of them. The 'forums' are also much more communicative. Very little is happening on the mailing list side (and in general has been falling off on the centos mailing lists even before the EOL of 8.).

I was going to call this generational change, but I am seeing many of the people I know who were on mailing lists in the past.. just not subscribing to new ones and doing their communication as one-offs in a forum. There are the die-hards like myself (and probably half a dozen people who will reply to this forum post.. ), but I think for the time being reporting via mailbox review is going to be harder.

LWN's 2021 retrospective

Posted Dec 22, 2021 20:13 UTC (Wed) by pebolle (guest, #35204) [Link] (5 responses)

My try at this game was published in https://lwn.net/Articles/841919/ :
> - The Documentation Foundation will collapse;
> - Mozilla will decline even further. By the end of 2021 it's basically limping along;
> - another episode or two of Debian's refusal-to-end-the-systemd-soap will be aired;
> - RedHat will finally stop funding half-a-dozen-of-the-same-thing and force Fedora to only work on a single desktop offering (ie, Gnome);
> - related to the four predictions above: the Free Software world will still struggle to cope with a world where computing is basically done on (locked down) smart appliances, (locked down) phones/tables, and (corporate controlled) clouds.

As far as I can tell none of the first four predictions were correct. (Which I think is a good thing for the first three predictions and a bad thing for the fourth prediction. I still hope RedHat will force Fedora to focus more.)

The last prediction is a bit of a true-ism. Rather hard to judge whether this can be considered a correct prediction or not. So I'll rate myself 0.5 out of 5.

Yay me!

LWN's 2021 retrospective

Posted Dec 22, 2021 21:27 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (2 responses)

I still hope RedHat will force Fedora to focus more.

It's not clear how much RedHat can force Fedora to do that. RedHat can, should, and AFAIK does tell its employees who work on Fedora what they should work on. But they don't have the same kind of sway over volunteers; they just don't have any leverage. To the extent they do have leverage, they need to be very careful about scaring away volunteers. A major benefit to RedHat of having a distribution like Fedora is that it gets volunteers working to develop future directions of their distribution. They don't want to be uninviting to some volunteers for fear of alienating more volunteers than they intended.

And it's not at all clear that the lack of focus in Fedora is necessarily bad for RedHat. There's a real danger that something like RHEL will be so focused on serving the needs of its existing users that it misses potential users who need something different. Fedora exists as a separate project at least in part to avoid that commercial focus and to let users experiment with new things. That experimentation may never pan out, but it would be a mistake for RedHat to squash it in the name of focus.

LWN's 2021 retrospective

Posted Dec 22, 2021 21:52 UTC (Wed) by james (guest, #1325) [Link] (1 responses)

There's a real danger that something like RHEL will be so focused on serving the needs of its existing users that it misses potential users who need something different.
Replace "RHEL" with "commercial UNIX" and you have the situation in the early 1980s when UNIX missed the personal computer market due to being wildly too expensive. The situation repeated itself once Linux won acceptance as a commercial UNIX-like OS: the "universal OS" nature of Linux meant it had plenty of extras to encourage customers to move.

I doubt if IBM's corporate memory stretches back that far, but I'd be surprised if Red Hat never worked that one out.

LWN's 2021 retrospective

Posted Dec 22, 2021 23:51 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

I doubt if IBM's corporate memory stretches back that far, but I'd be surprised if Red Hat never worked that one out.

Exactly. People think of Fedora as being primarily about development, but it's also low cost, very detailed market research. If Red Hat tries to keep too tight of reins on things, it will wind up choking that off.

LWN's 2021 retrospective

Posted Dec 22, 2021 21:33 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

> As far as I can tell none of the first four predictions were correct. (Which I think is a good thing for the first three predictions and a bad thing for the fourth prediction. I still hope RedHat will force Fedora to focus more.)

Okay, I don't use Fedora, but that change would make certain I never even LOOK at it ...

And I suspect the majority of non-Gnome desktops are independent spins (aren't they?), so RedHat *CAN'T* force it - if they're not paying for it they don't have any influence.

As the article said, most Gnome-haters have either come to terms with it or made alternative arrangements - I just completely ignore it - and if you like it, don't try and force it on me!

Cheers,
Wol

LWN's 2021 retrospective

Posted Dec 23, 2021 21:41 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

The Fedora desktop spins are mostly official spins published at https://spins.fedoraproject.org. Red Hat doesn't have very much to do with them. I can't imagine trying to get rid of them. What would be the point? It's not like their contributors would magically start working on Fedora Workstation instead: they would just move on to other distros.

LWN's 2021 retrospective

Posted Dec 23, 2021 8:20 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link]

A sizable part of the time wasted by the several buggy patches from some UMN researchers was due to both the over-reaction of reverting many unrelated patches (closer to two orders of magnitude than to one order of magnitude more than needed) which were valid, as well as the successful attempt to create a huge amount of bad press for UMN.
I get it, the point was to try and prevent others from repeating the experiment in an overt way... it just indicates others that future attempts to contribute intentionally buggy patches need to be stealthy :)

The stream of fixes for vulnerabilities in the likes of unprivileged user namespaces, eBPF and io_uring shows that there are already enough unintentionally contributed bugs, for intentionally contributing bugs not to be a very interesting way to introduce security issues (which wasn't even the goal of the several patches from UMN researchers, AFAICS).

LWN's 2021 retrospective

Posted Dec 28, 2021 18:18 UTC (Tue) by babywipes (subscriber, #104169) [Link]

This is a great recap. I wanted to post a comment thanking you all. LWN is the only real news platform I read. Keep up the great work!


Copyright © 2021, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds