LWN's unreliable predictions for 2022

By Jonathan Corbet
January 3, 2022

It is 2022 already, and that can only mean one thing: it's time for your editor to make a (bigger) fool of himself by posting a set of predictions for what may come in the new year. One should never pass up an opportunity for a humbling experience, after all. There can be no doubt that interesting things will happen this year; let's see how many random darts thrown in that direction can hit close to the mark.

Starting with something that is, hopefully, fairly obvious: 2022 will see a wider awareness that maintainers need support for free-software projects to be healthy. It has been a while since companies working with free software realized that they needed to support the developers of that software; that is the path toward stronger projects and better influence over how those projects evolve. But even the projects with the most economic support struggle to support their maintainers, and the effects can be felt across the entire community. The ongoing Log4j debacle is just the latest symptom of this problem.

Supporting maintainers can be a hard sell for a corporate manager. Developers can focus most of their time directly on their employers' needs, but maintainers have to make the project work for all participants, including their employers' competitors. The value of their contribution is harder to quantify. But the cost of neglected maintenance is high and growing, and the smarter companies will start to figure this out.

This support will also take the form of a greater willingness to pay for supported free-software products in areas where that has not generally happened. The recent announcement that support for GnuPG is selling well is a case in point. This critical project has languished for years, depending on donations from individuals; maintainer Werner Koch is now telling donors that their support is no longer needed.

The browsers wars will return with a vengeance as the Chrome browser builds on its dominance and increasingly serves its owner's agenda. The Firefox browser saved us from an oppressive browser monopoly once; it now seems that only Firefox is in a position to do that again. A single-browser world is not a good result, even if that browser isn't owned by a large advertising company. Awareness of this problem, and efforts to fight it, will grow in 2022; whether Mozilla can overcome its own problems and rise to the challenge again remains to be seen, though.

Use of centralized, proprietary services will be a bone of contention in 2022, much like it was in 2021. Whether they are Git forges, fallback DNS servers, or content-delivery networks, free-software projects will find it hard to work efficiently without these services, but they will also be uncomfortable depending on them. In the absence of freer alternatives, though, the trend toward proprietary services is likely to continue. Keeping a project going is hard enough as it is; requiring projects to maintain unrelated services will not make it easier.

The 6.0 kernel will be released in 2022, with December 4 being the most likely release date (though it could happen in early October if Linus Torvalds decides to stop 5.x at 5.19 rather than 5.20). As always, there will be nothing special about 6.0; it will be just yet another kernel release, but the dot-zero release number will look like a milestone anyway.

Support for kernel modules written in Rust will be merged in 2022, but not before we have to endure at least one more long discussion on whether adding a new language makes sense. Some developers will resist the burden of learning a new language, while others will repeat strange theories about how adding Rust is a sign of some sort of corporate takeover of the project. But the kernel project needs to be looking at safer technologies, and Rust seems well positioned to address that need.

Python will lose its infamous global interpreter lock (GIL) in 2022. This change will certainly not be in the 3.11 release, due in October, but it will be on a clear track for merging into a later release. Just like the big kernel lock, Python's global lock seems entrenched and impossible to remove, but dedicated developers are getting there.

GNU projects will continue to push toward independence from the Free Software Foundation. This could be seen in 2021 when the GCC and GNU C Library projects chose to drop the FSF's longstanding copyright-assignment requirement. Maintainers in the Emacs project, arguably the one that remains most firmly under Richard Stallman's control, are getting grumpier about that requirement as well, and the project as a whole is under pressure to change its processes, some of which were established in the 1980s. It is a stretch, but 2022 may be the year that Emacs, too, starts making more of its own decisions.

Machine learning will play a bigger role in free-software development. Much of the commercial use of machine learning is built on free software, of course, but our community makes relatively little use of that technology. There are opportunities in many areas, including patch review and code generation, that should be pursued. Investments in our tools tend to pay off in a big way, and there is reason to believe that can happen with machine learning as well.

More importantly (but more of a stretch): machine learning will become more widely available outside of large proprietary services. Not that long ago, building and maintaining a comprehensive, global map database looked like something only large companies could do; now many of those companies depend on OpenStreetMap instead. Machine-learning applications can require massive amounts of CPU power and can raise interesting intellectual-property questions, but they should not be limited to corporate data centers. Free software is going to require free models to work with; the alternative is likely to be that whole problem domains will lack free solutions.

Linux may lose some embedded market share this year to competitors like Fuchsia. Alternative systems will continue to find it hard to compete with Linux's massive development community, but they offer advantages like relative simplicity, permissive licensing, and greater amenability to corporate control. These systems will not displace Linux in a big way in 2022, but they may well make some inroads around the edges.

Some other notes

It seems strange to have a set of predictions for the year that don't mention COVID, but it has become increasingly clear that nobody has a clue of what will happen in that regard. The free-software community has been lucky in that COVID has not hit us that hard, so far. Let us hope that continues as we, with luck, start to put this pandemic behind us.

Finally, LWN will begin its 25th year of publication in late January. A quarter of a century ago, we were convinced that Linux had a bright future, but we could have never imagined where Linux would end up in 2022 — or that LWN would still be a part of it. It has been a great thing to participate in, and the outstanding community of readers that has come together here is a big part of that.

Expect some changes at LWN over the coming year as we work out how to respond to Rebecca Sobol's retirement and, more generally, how to position LWN for the next 25 years. The free-software community has a lot of work to do still, and we don't plan to miss it. Meanwhile, please accept our best wishes for a 2022 that, with any luck at all, will be far better than its immediate predecessors.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 1:34 UTC (Tue) by KJ7RRV (subscriber, #153595) [Link] (9 responses)

I'm probably going to migrate all my GitHub repos to a self hosted Gitea instance this year. Hopefully a federated forge will be developed so people can contribute to self hosted projects more easily without using SSO or creating lots of accounts.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 11:54 UTC (Tue) by larkey (guest, #104463) [Link] (3 responses)

There's some work regarding using matrix as some kind of SSO provider. That way you could host your own Gitea and have anyone log in using their matrix account (possibly self-hosted as well). This would be basically federated SSO. Combined with WebAuthn using SoloKeys/YubiKeys this looks like a bright future indeed.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 12:23 UTC (Tue) by bluca (subscriber, #118303) [Link]

A bright future of getting pwned most likely :-) opsec is expensive, time consuming and _hard_ work

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 17:19 UTC (Tue) by KJ7RRV (subscriber, #153595) [Link]

That definitely sounds interesting! It would be nice to have a universal account that wasn't tied to $BIG_TECH_COMPANY.

LWN's unreliable predictions for 2022

Posted Jan 8, 2022 1:04 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

> That way you could host your own Gitea and have anyone log in using their matrix account (possibly self-hosted as well).

An intriguing idea. How do they propose to solve the spam problem? (There will inevitably be a spam problem when you do something like this. See also: email)

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 14:50 UTC (Tue) by fredrik (subscriber, #232) [Link] (1 responses)

One advantage of the massive migration of projects to Github is that has made it easy for a casual visitor to find a project's issue tracker.

As an example, when KJ7RRV mentioned Gitea above, I attempted to find the Gitea project's issue tracker. It is AFAICT not on their own self-hosted instance of Gitea. Instead it is found on Github. Took a bit of digging around to find it.

So, I would like to take this opportunity to encourage to all projects to prominently advertise where their issue tracker can be found. Regardless of where the source code repository is hosted, but perhaps especially so when the project is not hosted on github.com.

LWN's unreliable predictions for 2022

Posted Jan 6, 2022 13:48 UTC (Thu) by geuder (guest, #62854) [Link]

> I would like to take this opportunity to encourage to all projects to prominently advertise where their issue tracker can be found

That's not only the issue tracker. I needed to document other aspects like security / vulnerability disclosure policies, release policies, and, review policies of the open source components we use in our product. It was a lot of work and far too often I needed to write "seems undocumented". For big projects its not necessarily easier, they can have bits and pieces of (partially outdated) information spread out over various Web sites.

LWN's unreliable predictions for 2022

Posted Jan 6, 2022 22:55 UTC (Thu) by Creideiki (subscriber, #38747) [Link] (2 responses)

Gitea just received funding from NLnet to further the development of federation features, so maybe we'll see something despite the demise of the original ForgeFed project.

LWN's unreliable predictions for 2022

Posted Jan 11, 2022 1:05 UTC (Tue) by flussence (guest, #85566) [Link] (1 responses)

I'd be happy if they would just make the existing federated login in Gitea usable, so people could roam between self-hosted repository services without making a gazillion accounts. WTF is a "OAuth2 client key" and why do I have to configure one per remote host, and for that matter why do I have to manually configure each remote host allowed to log in? Do I just make something up in that field? Do I have to go around bothering other sysadmins for this info? (that'd be a deal killer)

This stuff was so much easier to understand back in the OpenID days, but nobody implements providers for that any more because it got squeezed out by this enterprise headache. Of course the protocol's over-engineered on purpose to kill off small-scale participation on the web, but even the software I'm *using* that speaks both ends of it can't talk to each other.

LWN's unreliable predictions for 2022

Posted Jan 11, 2022 1:23 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Ah, OAuth2. Basically, service providers got unhappy that users were using Any Client instead of the Blessed Client™ (which has ads, tracking, and other "fun" enterprise-y things embedded). So OAuth2 has the idea of authenticating a *client* to the service. Users then allow that client to access the service on their behalf. I agree that this does indeed have security benefits including:

- scraping account auth isn't useful as the other client also needs the client secret (though this is a DRM-ish thing in that "fat" clients have the secret embedded somewhere anyways)
- limiting access to the account through specific services (instead of "app passwords" which generally are full account access)
- generally better permission lockdowns (though this isn't exclusive, "no one" implements app password-based limited access)

However, it means that FOSS apps are SOL and users must instead register their copy as a separate client because…the client secret has to come from somewhere and it's not very secret in a public repo (GitHub or F-Droid). FWIW, this has worked for me with Google's enterprise account, but I couldn't find how to register an app with my free account (e.g., for use with `offlineimap` or `rclone`).

Now I have no idea how the Gitea federation stuff is in practice, but if that's any indication, expect pain and suffering when you have to register as a "new app" at each service manually.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 2:25 UTC (Tue) by roc (subscriber, #30627) [Link] (4 responses)

Thanks for calling out the importance of Mozilla. The fight for the Web has been going on so long it's easy to imagine it's no longer relevant, but it is.

Thanks also for being positive about Rust in the kernel.

I actually hope Linux does have some high-profile losses to other OSes. That would help defuse the narrative that whatever Linux kernel devs do (or don't do) is justified because Linux keeps winning.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 5:21 UTC (Tue) by PengZheng (subscriber, #108006) [Link] (3 responses)

But I suspect Fuchsia could be a real competitor.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 12:24 UTC (Tue) by bluca (subscriber, #118303) [Link]

...until Google gets tired of it and kills it to chase the next squirrel, that is

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 12:28 UTC (Tue) by hkario (subscriber, #94864) [Link] (1 responses)

Unless Google's ADD activates again and they drop it unceremoniously like so many other projects that are not Google Ads or Google Ads direct delivery mechanism.

LWN's unreliable predictions for 2022

Posted Jan 7, 2022 21:18 UTC (Fri) by gutschke (subscriber, #27910) [Link]

Fuchsia is currently positioned to become a fundamental part of both Android and ChromeOS. We'll see how well that works out, and of course if you switch once, you can theoretically always switch back. But I am willing to bet that Fuchsia will be around for a good while; and even if it doesn't take off anywhere else, it'll have a guaranteed niche where it will find use.

On the other hand, I also expect that it will gain good support for hosting VMs. So, it is always possible that Linux will continue running on these devices inside of a container.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 2:37 UTC (Tue) by robertpostill (subscriber, #15684) [Link]

25 years, what an achievement! Congratulations and I hope the future is bright for LWN.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 3:47 UTC (Tue) by jkingweb (subscriber, #113039) [Link]

I renewed my subscription late last month. I'm looking forward to another year of peerless news!

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 5:46 UTC (Tue) by flussence (guest, #85566) [Link] (8 responses)

I predict one of the FAANG cloud hosting infrastructures will fail catastrophically for more than a day and motivate enough smaller companies to go back to self-owned hosting that it makes a brief blip on mainstream tech sites. It won't make much of a difference this year, but it'll be the start of something.

Also 8 weeks ago I made a cynical prediction in a comment thread that Mozilla would be abusing its brand to shill for cryptocurrency scams by year's end, and well, I'm sorry for jinxing it.

So instead this year I'll predict sufficiently motivated groups of hackers will take a sudden interest in making WebKit on Linux really good, with a power-user UI that puts Opera 12's to shame, a sync feature that anyone can self-host atop syncthing or whatever, and WebExtensions so it can run uBlock Origin properly.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 11:36 UTC (Tue) by roc (subscriber, #30627) [Link] (1 responses)

Shilling for cryptocurrency scams would mean encouraging people to *buy* cryptocurrency, not sell it.

I find accepting cryptocurrency donations a distasteful move, but it's hardly a big deal.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 21:55 UTC (Tue) by flussence (guest, #85566) [Link]

I'm with JWZ on this one - you should be witheringly ashamed of defending this.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 21:50 UTC (Tue) by Sesse (subscriber, #53779) [Link] (3 responses)

Would AWS being down for a day have any significance in motivating smaller companies to self-host? There's been multiple long cloud outages in 2021 (including the infamous us-east-1 outage), and essentially nobody moved. (Also, Facebook itself was completely down for 6–7 hours, I know zero people who switched from WhatsApp to other services.) Microsoft has also had huge Azure AD outages, yet people still use the service heavily. Slack has had long outages, prompting nobody to switch to Matrix.

You could very well be right in that there will be a day-long outage, but I don't think it will have the effect you describe. Sophisticated players may move to a multi-cloud strategy for redundancy, that's all.

LWN's unreliable predictions for 2022

Posted Jan 5, 2022 4:27 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

> You could very well be right in that there will be a day-long outage, but I don't think it will have the effect you describe. Sophisticated players may move to a multi-cloud strategy for redundancy, that's all.

I agree with this entirely. Unless there is a repeated interruption of several hours very often, revisiting choices would be highly unlikely given the large migration costs for many organizations. Even something like Slack has an API that organizations use to integrate with it heavily.

LWN's unreliable predictions for 2022

Posted Jan 5, 2022 13:33 UTC (Wed) by khim (subscriber, #9252) [Link] (1 responses)

Much more important is the fact that one-day outage is nothing rare for self-hosted affair.

Only if that one-day outage would be coupled with massive loss of data people would start thinking about moving.

The sad truth is that self-hosting protects you from legal shutdown, but from technical side it's definitely not a win.

LWN's unreliable predictions for 2022

Posted Jan 6, 2022 14:00 UTC (Thu) by geuder (guest, #62854) [Link]

> Only if that one-day outage would be coupled with massive loss of data people would start thinking about moving.

So why would an average small or medium-sized company running their own server not lose their data? Hiring competent people is hard and having enough of them to always do everything they know they should do maybe ever harder.

I am no friend of the current oligopolies. But I doubt that the risks of losing your data or security in general would always improve by self-hosting.

LWN's unreliable predictions for 2022

Posted Jan 5, 2022 4:50 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> I predict one of the FAANG cloud hosting infrastructures will fail catastrophically for more than a day and motivate enough smaller companies to go back to self-owned hosting that it makes a brief blip on mainstream tech sites. It won't make much of a difference this year, but it'll be the start of something.

We already had a day-long outage in us-east-1. Nobody cares.

It's like the electric grid. You can get occasional blackouts, but they affect your competitors too, so you just take a loss for that day and move on.

If you are a large manufacturing plant, then you might have redundant connections to the grid so that a partial failure won't bring you down. In case of AWS you can have multi-regional infrastructure to help avoid regional issues. For example, my company uses us-east-2 as a backup and we switched to it just fine and survived the outage with only minor interruptions.

And finally, if you absolutely NEED uninterrupted power then you build your own mini-grid (e.g. in a hospital or a flight control tower in an airport). This is an analogue of on-prem clusters that some companies still do for high-availability.

LWN's unreliable predictions for 2022

Posted Jan 5, 2022 19:47 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

> If you are a large manufacturing plant, then you might have redundant connections to the grid so that a partial failure won't bring you down. In case of AWS you can have multi-regional infrastructure to help avoid regional issues. For example, my company uses us-east-2 as a backup and we switched to it just fine and survived the outage with only minor interruptions.

Speaking as someone who, until fairly recently, was an SRE for one of the big cloud providers (I now work on non-cloud products), *please for the love of $DEITY do this.* The whole point of having multiple regions is redundancy. We try very hard to avoid multi-region outages, and when they do happen, we take them much more seriously than single-region outages. If you are running out of a single region, you should expect it to occasionally fail.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 7:19 UTC (Tue) by bojan (subscriber, #14302) [Link] (27 responses)

2022 will be the year of the Linux desktop. ;-)

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 9:15 UTC (Tue) by nilsmeyer (guest, #122604) [Link] (26 responses)

> 2022 will be the year of the Linux desktop. ;-)

Hah ;) Though for me it has been that way for the last two decades and I don't expect it to change.

More serious prediction: 2022 will see a lot more desktop users moving to Wayland.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 9:41 UTC (Tue) by Wol (subscriber, #4433) [Link] (16 responses)

Well, I finally (with a new computer) upgraded from KDE4 to wayland late last year.

Only snag is, qt5/plasma is - I gather - fairly tightly integrated into X, so disentangling the two has a long way to go ...

Cheers,
Wol

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 11:23 UTC (Tue) by jem (subscriber, #24231) [Link] (15 responses)

I gather you chose some other desktop environment than Plasma to upgrade to Wayland, then? Otherwise I can't see how you arrived at your conclusion.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 12:40 UTC (Tue) by Wol (subscriber, #4433) [Link] (14 responses)

No. I was trying to start plasma from the command line (I didn't want to activate graphical login until I knew everything was working), and I had LOADS of grief.

I finally debugged it as "plasma needs a graphical login", and the reason behind that, apparently, is that plasma needs at least PART of the X stack to be running. Don't ask me the details, I can't remember, but it was pretty clear that plasma sans at least some X is a loooong way off.

(And that's a pain because I'm currently running sddm, which doesn't appear to allow multiple users at once. I need to play with ldd instead.)

Cheers,
Wol

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 19:17 UTC (Tue) by dtlin (subscriber, #36537) [Link] (5 responses)

It needs a graphical session, which is somewhat unofficially defined by systemd/udev/pam, but I'm not sure how you interpret that as needing part of the X stack?

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 21:06 UTC (Tue) by Wol (subscriber, #4433) [Link] (4 responses)

All I know is, that while I was trying to debug why plasma would (or wouldn't) launch at random, I ended up on what I remember as an official plasma site saying that launching from the command line was DEFINITELY unsupported, experimental, and likely to go wrong. And it also said that plasma/qt5, as originally written, had a lot of deeply entrenched X dependencies, which were slowly being removed but it was a major undertaking.

And from what I can make out, Wayland is X13 - I seem to remember someone saying that if you modularised everything you could in X you would end up with something very similar to Wayland, and Wayland has re-used everything it can from X, so the two are pretty tightly coupled. However, starting from very different security paradigms they're incompatible at the base level. But seeing as you can have "X over Wayland" or "Wayland over X", I'm not sure where in all this Plasma fits in ...

Cheers,
Wol

LWN's unreliable predictions for 2022

Posted Jan 12, 2022 20:13 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

> I seem to remember someone saying that if you modularised everything you could in X you would end up with something very similar to Wayland, and Wayland has re-used everything it can from X, so the two are pretty tightly coupled

This is... extremely not true. Very extremely not true.

LWN's unreliable predictions for 2022

Posted Jan 17, 2022 5:26 UTC (Mon) by flussence (guest, #85566) [Link] (2 responses)

At this point in time it's sort of true, but only because nobody in their right mind writes X programs without a mountain of abstraction layers. Even the core X11 protocol is insulated behind xcb nowadays because it's *painful* without it.

LWN's unreliable predictions for 2022

Posted Feb 19, 2022 1:24 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

> Even the core X11 protocol is insulated behind xcb nowadays because it's *painful* without it.

Buh what? This too is basically the reverse of reality as I understand it. Everyone not doing something very strange used libX11 to interface with the X protocol for decades; almost nobody sent raw protocol messages. XCB is an attempt to get *closer* to the protocol, not further from it.

LWN's unreliable predictions for 2022

Posted Feb 26, 2022 6:40 UTC (Sat) by flussence (guest, #85566) [Link]

I explained that one badly, that's on me. The point is that libxcb's both better for the developer and the computer than the old "reference" implementation (libXfoo), where everything was synchronous API calls. X11 hasn't changed but the main way of interfacing with it is now completely different.

LWN's unreliable predictions for 2022

Posted Jan 5, 2022 10:13 UTC (Wed) by jem (subscriber, #24231) [Link] (7 responses)

I finally debugged it as "plasma needs a graphical login", and the reason behind that, apparently, is that plasma needs at least PART of the X stack to be running. Don't ask me the details, I can't remember, but it was pretty clear that plasma sans at least some X is a loooong way off.

If you use sddm to satisfy the requirement that "plasma needs a graphical login", then you need X, because sddm is still an X application. However, sddm is an independent application that is not part of Plasma.

Of course you need lots of bits from X to be able to run X client applications using XWayland, which is a modified X server running on top of Wayland. Because many apps are still old-fashioned X apps, you will probably not be able to go "pure" Wayland for some time still. Some applications (like Firefox) may need a setting to enable it to run as a Wayland app. Once again, this is not Plasma's fault: the apps, or (more likely) the toolkits they are using, need to be rewritten to use Wayland.

By the way, one fun way to check if an application is a Wayland app is to start xeyes. If xeyes can spy on you by following your mouse cursor when you hover it over the application window, then the application is not a native Wayland application.

LWN's unreliable predictions for 2022

Posted Jan 5, 2022 12:30 UTC (Wed) by Wol (subscriber, #4433) [Link] (6 responses)

What is the alternative then? Lightddm?

Bear in mind I want multiple simultaneous users ... (so I need to ditch sddm anyway, because that doesn't support it).

Cheers,
Wol

LWN's unreliable predictions for 2022

Posted Jan 8, 2022 12:32 UTC (Sat) by mkbosmans (subscriber, #65556) [Link] (5 responses)

What is exactly the problem with sddm?
I'm using OpenSUSE with sddm and plasma on X and have multiple simultaneous users working in the default setup. Is this somehow an unsupported, but might work kind of thing?

LWN's unreliable predictions for 2022

Posted Jan 8, 2022 13:37 UTC (Sat) by Wol (subscriber, #4433) [Link] (4 responses)

You're running on X. I guess plasma/X gives you the option of firing up sddm on tty8, tty9 etc.

I'm running plasma-wayland, which as far as I can tell is running on tty1. I don't have the option of firing off a second sddm on tty2. And from what I can make out, it's not possible.

Note my statement *from what I can make out*. If I'm wrong, I'd love to be enlightened.

Cheers,
Wol

LWN's unreliable predictions for 2022

Posted Jan 8, 2022 16:04 UTC (Sat) by mkbosmans (subscriber, #65556) [Link] (2 responses)

Ah yes, I didn't consider that the different TTYs would obiously be running separate X servers.
It is rather convenient to be able to switch users with a simple CTRL+ALT+Fn and leave each user either locked or unlocked depending on preference. (This is on our shared familiy computer)

So good to know that multiple active sessions is not supported on wayland+sddm+plasma at the moment. Each time I test wayland, I need to switch back to X because of some breakage or missing things. Last time it was font scaling and multiple plasma activities. I always presumed that it was due to a combination of my distribution having older versions of some components and perhaps video card drivers, but I will keep revisiting wayland periodically.

LWN's unreliable predictions for 2022

Posted Jan 8, 2022 17:35 UTC (Sat) by Wol (subscriber, #4433) [Link]

I believe lightddm can do it, but I haven't got round to trying it.

(The other problem I have is I want this system to run multi-head, but if I stick two graphics cards in, it seems grub gets confused and I don't see a boot screen ...)

Cheers,
Wol

LWN's unreliable predictions for 2022

Posted Jan 10, 2022 18:24 UTC (Mon) by jezuch (subscriber, #52988) [Link]

> Each time I test wayland, I need to switch back to X because of some breakage or missing things. (...) but I will keep revisiting wayland periodically.

So do I and so will I. For me it was some problems with switching ttys (don't remember the specifics, because I do it basically only in emergencies) and crashing when waking up from suspend (this one, on the other hand, was a solid deal breaker).

Sad 😔

LWN's unreliable predictions for 2022

Posted Jan 9, 2022 19:49 UTC (Sun) by jem (subscriber, #24231) [Link]

With Plasma you can start a new session with "Switch user" in the menu. You are prompted to log in as a new user. To switch back to the old session, choose "Switch user" again. This works regardless if you have chosen Plasma (X11) or Plasma (Wayland) in the initial SDDM greeter screen.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 9:55 UTC (Tue) by rsidd (subscriber, #2582) [Link] (6 responses)

I switched to wayland (i3 → sway) a few months ago. It's fantastic. I didn't *have* to switch, but my laptop runs noticeably cooler now and battery lasts longer, and no overheating incidents.

There are things that don't work, eg you can't share individual windows in video calls, only full screen (but I'm fine with that), and you can't take a screenshot from within gimp (but you can press PrtSc, select a region of the screen or the full screen, copy and paste into gimp). No deal-breakers, and plenty to like.

LWN's unreliable predictions for 2022

Posted Jan 6, 2022 14:06 UTC (Thu) by geuder (guest, #62854) [Link] (5 responses)

Overheating incidents? Caused by X11?? I have honestly no idea what you are referring to.

LWN's unreliable predictions for 2022

Posted Jan 6, 2022 14:54 UTC (Thu) by rsidd (subscriber, #2582) [Link] (1 responses)

Empirical observation. My guess is, caused by Firefox running on X11. (Firefox CPU usage was huge under X11/i3, much much less under Sway)

LWN's unreliable predictions for 2022

Posted Jan 7, 2022 8:41 UTC (Fri) by geuder (guest, #62854) [Link]

Hmm, I use Firefox and xfwm4 under Xorg and don't have such observations. So i3 would make the difference? Doesn't sound too likely, it doesn't even use compositing does it and should also otherwise be really lightweight. Of course there can always be bugs / poor implementations. There are a million of parameters different between 2 systems, so it could be something completely different.

LWN's unreliable predictions for 2022

Posted Jan 6, 2022 17:43 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> Overheating incidents? Caused by X11?? I have honestly no idea what you are referring to.

It's not uncommon for users to report getting better battery performance in Wayland and this appears to be backed by benchmarks as well

https://www.phoronix.com/scan.php?page=news_item&px=G...

https://www.phoronix.com/scan.php?page=news_item&px=K...

LWN's unreliable predictions for 2022

Posted Jan 7, 2022 9:03 UTC (Fri) by geuder (guest, #62854) [Link]

Yes, average savings of some 20%, but heat incidents? At least my machine normally doesn't run so high load that 20% difference would be immediately noticeable. 20% may sound significant, but if the difference is between 20% and 16% of maximum consumption / heat dissipation it should be hardly observable.

Of course parallel builds and video encoding are different, but we didn't talk about such cases. The maximum consumption shown by these benchmarks looks very much unchanged.

LWN's unreliable predictions for 2022

Posted Jan 14, 2022 16:48 UTC (Fri) by geuder (guest, #62854) [Link]

> Overheating incidents? Caused by X11?? I have honestly no idea what you are referring to.

I stand corrected. Switched an Intel laptop from xfwm4 to i3 yesterday because I needed several windows nicely arranged for a certain task. And it did not take long until things started failing badly (repeatedly) and the log was full of throttling messages because of overheating and worse.

I have used i3 on a Ryzen desktop with Nvidia and AMD GPUs for years. This has never happened to me before.

LWN's unreliable predictions for 2022

Posted Jan 13, 2022 10:41 UTC (Thu) by callegar (guest, #16148) [Link] (1 responses)

> 2022 will see a lot more desktop users moving to Wayland

Unless that is 2023.

Notwithstanding the desire I would have for switching, everytime I try I find something that bounces me back... and I am getting the impression that users have already been split in two well defined groups: those for which things that currently break with wayland are little, tolerable nuisances and those for whom they are true showstoppers. The gray area in between has already shrunk a lot and most of those in the first group have already migrated, so for 2022 you will probably have a core of people using X11 that are going to be extremely hard to win, particularly because X11 still does its job, not extremely well, but sufficiently well. I hope to be proved wrong.

My main points of grief all have to do with things for which there was a standard in X11 (so every toolkit and DE was doing them consistently) and that are not in wayland (so that every toolkit and DE does them in its own way or not at all). This means that when you mix apps based on different toolkits or made for different DEs it rapidly gets a complete mess and also that a lot of work is wasted as every toolkit/DE has to invent its own solution.

Some examples:

* Destkop sesssion (restarting what you had running when you log out and then log in again). That is totally needed on systems that you cannot suspend, but it is a total mess in wayland because there seems not to be a single idea on how to do it. Gnome has a protocol for it, KDE still has not and may well end up with its own solution. Other destkops will probably just stay without as there is no

* Forcing an application to run in X (Xwayland) mode (e.g., because you need to put it on another DISPLAY). There is not a single environment variable triggering it that works across toolkits. You get GDK_BACKEND, QT_QPA_PLATFORM, CLUTTER_BACKEND, SDL_VIDEODRIVER, WINIT_UNIX_BACKEND, and possibly others. And then not even the values to be passed to these environment variables are in any way consistent. If it was not true it would look so much like a joke. Really it was not possible to agree on a single one? The problem with this is that it is so much revealing of an attitude and so much comforting to the belief that free software is better avoided for lack of any bottom line of consistency.

* Network transparency for individual applications. There is still not a single approach nor a way to deploy it that is the same across toolkits.

This in addition to things that *just break* (e.g., I still cannot seem to run libreffice presentations reliably on a projector). But this latter group of things *is* the one getting fixed so it does not worry me that much. What is not getting fixed is really the proliferation of different ways to do things. The impression you get (but I may well be wrong) is that everything-wayland seems to be developed in a gnome/gtk-centric (-first?) world with little preliminary talk to others.

LWN's unreliable predictions for 2022

Posted Jan 28, 2022 10:08 UTC (Fri) by daenzer (subscriber, #7050) [Link]

> I hope to be proved wrong.

The trend on https://www.gamingonlinux.com/index.php?module=statistics... looks pretty clear. The percentage of Wayland users almost doubled over 2021, and the trend seems to be accelerating still. Note that this is specifically about gamers, which are more likely to actively want to stay on Xorg than the overall population, e.g. because the nvidia driver is only just starting to work well with Wayland.

> * Network transparency for individual applications. There is still not a single approach nor a way to deploy it that is the same across toolkits.

There's waypipe (https://gitlab.freedesktop.org/mstoeckl/waypipe), which works based on the same principle as X11 forwarding over SSH. BTW, the latter doesn't actually need X11's network transparency, which has been disabled by default in X servers for years.

> The impression you get (but I may well be wrong) is that everything-wayland seems to be developed in a gnome/gtk-centric (-first?) world with little preliminary talk to others.

Yeah, it's not like that. A Wayland protocol extension needs to have 3 separate implementations before it can be marked as stable, which is unlikely to happen without consensus. A lot of recent Wayland protocol work has been driven by KDE / wlroots / other non-GNOME developers, and there's a lot of discussion and collaboration between all of them. Anyone is welcome to join in on https://gitlab.freedesktop.org/wayland/wayland .

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 11:38 UTC (Tue) by stephanlachnit (subscriber, #151361) [Link] (3 responses)

The percentage of Linux users on Steam goes above 3% thanks to the Steam Deck.

LWN's unreliable predictions for 2022

Posted Jan 6, 2022 3:25 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

My non-techie daughter plays Steam games on her Ubuntu laptop, so she is making a small contribution to that eventual 3%.

LWN's unreliable predictions for 2022

Posted Jan 6, 2022 18:52 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

IMHO this depends on their compatibility story. Right now, it looks like this: https://www.steamdeck.com/en/verified

> The team is currently working on a way for you to be able to check the compatibility category of each of the games in your own library ahead of launch.
>
> In addition, you’ll soon be able to see which games in the Steam catalog have already gone through Steam Deck review, and what compatibility category they fall in. More on this soon.

This suggests to me that either A) they are still in the process of compatibility testing or B) they have finished compatibility testing and the numbers don't look good (because if they did look good, Valve would be shouting it from the rooftops instead of giving us this vague "wait and see" answer). What really surprises me is the fact that people are preordering a device which might not even run half their games.

(Yes, it's a PC, yes you can install whatever OS you want, including Windows, but in practice I don't think a large portion of the target audience intends to do that.)

LWN's unreliable predictions for 2022

Posted Jan 18, 2022 17:20 UTC (Tue) by nye (subscriber, #51576) [Link]

> This suggests to me that either A) they are still in the process of compatibility testing or B) they have finished compatibility testing and the numbers don't look good (because if they did look good, Valve would be shouting it from the rooftops instead of giving us this vague "wait and see" answer).

Based on my personal experience with Proton, I expect it's more A than B. It's *really* good. I just buy games now without even bothering to check the supported platforms. There are still some misses, and if I were 100% Linux-only I might make the occasional refund, but they really are rare.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 14:39 UTC (Tue) by tshow (subscriber, #6411) [Link] (5 responses)

I'm not sure if it's coming in 2022, but at some point we're going to see serious security exploits involving "tricking" machine learning systems. Most of the pieces are in place, and when (for instance) we start relying on ML for patch review, there will be bad actors who look for ways to exploit that.

From what I can see, machine learning is still in the alchemy/astrology phase. I have yet to see any papers explaining why a specific machine learning model produces the results it does, other than "we invoked the right celestial powers, sacrificed pleasing data on a properly blessed altar, and were granted a boon". Yes, the result often does useful things, but we don't really know _why_, nor what _else_ it will do if fed unexpected/malicious/tailored input.

You don't have to squint at that very hard to see a security nightmare.

Tricking machine learning algorithms

Posted Jan 4, 2022 16:37 UTC (Tue) by david.a.wheeler (subscriber, #72896) [Link] (3 responses)

There are already a number of papers describing how various ML systems have been tricked (search for "adversarial inputs").

Unfortunately, I know of no *effective* countermeasure. There are a lot of countermeasures described in the literature, but all of them fall trivially against counterattack. If someone developers an *effective* countermeasure I'd like to know.

Tricking machine learning algorithms

Posted Jan 5, 2022 16:19 UTC (Wed) by tshow (subscriber, #6411) [Link] (1 responses)

I know there are already ways of tricking ML algorithms; I guess my point was, once we're using ML as part of a security pipeline, we'll start to see attacks on the ML part of the pipe. In particular, I expect we'll see places where ML is being used to offload paranoia (like, say, vuln checking in patches) where ML makes things actively worse because "the patch passed ML review" and has the Computer Stamp of Approval. The mere presence of ML in such a process will tend to make people more likely to think "I don't have to concern myself with this, it passed the ML vuln checker".

Arguably it's a variant of social engineering; if people subconsciously think a tool is handling a problem, and you can make that tool secretly _not_ handle the problem, the people who might have spotted the problem normally are more likely to miss it.

Tricking machine learning algorithms

Posted Jan 5, 2022 18:02 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

This is a serious problem with any situation where you have multiple levels of protection. It's great if everyone does their part; you wind up with really great protection. But at least as often, people use the multiple levels as an excuse for slacking off, assuming the other levels will pick up the slack for them. In the worst case, you wind up with zero levels of protection while believing everything is OK. It's a problem that extends far beyond computer security.

Tricking machine learning algorithms

Posted Jan 12, 2022 20:17 UTC (Wed) by nix (subscriber, #2304) [Link]

Indeed, it has been proven for at least some classes of machine-learning system that there will always be *some* adversarial input for a given model (combination of network weights, whatever): all you get to do is choose what that set of inputs is (and perhaps restrict it more than otherwise might be the case).

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 23:19 UTC (Tue) by Paf (subscriber, #91811) [Link]

I think the blanket statement that there are no such papers is definitely incorrect (just Google “explainable AI” for one set of examples, there are others); understanding ML models is a rich and growing area of research. But, that said, I can’t disagree with the basic premise. Most are still some form of alchemy and the large majority go largely not-understood, and yes, exactly this sort of thing will occur. There’s already significant research in to fooling visual systems and given how lightly I follow this stuff, I imagine there’s significant research in to fooling other kinds as well despite not having seen it personally.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 17:15 UTC (Tue) by mtaht (subscriber, #11087) [Link] (5 responses)

I really hope 2022, given the demand for quality videoconferencing in particular, that more bufferbloat fixes arrive like what comcast deployed, and Mikrotik is protoyping, and that far far more ISPs and users realize that more bandwidth doesn't matter, especially for web traffic.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 17:45 UTC (Tue) by vadim (subscriber, #35271) [Link] (4 responses)

Bandwidth matters enormously. Not everything is websites.

Back when COVID19 started, we were caught unprepared. We had something like a 100 Mbps symmetric line used for VPN access, which was okay before. Suddenly everyone was going through the VPN. Then at the same time disaster struck: something had gone badly wrong with an old OpenStack setup. It was necessary to backup all the data before messing around with anything. It also happened there was not enough free space anywhere to back the servers up entirely. The office was empty and closed.

The improvised solution to that was downloading around 3 TB of data through that 100 Mbps connection, shared by several dozen employees, in a company that works with a lot of VMs. That transfer took around a week, accounting for other people's usage and that it had to be done mostly during nights.

That was a very interesting week to say the least, and upgrading the connection to something better was an immediate priority.

Even for home users, it's kind of a big deal. Inside a company most everyone has gigabit networking at least. Slowing down big transfers by 10X if not more can hurt a lot.

LWN's unreliable predictions for 2022

Posted Jan 5, 2022 2:21 UTC (Wed) by mtaht (subscriber, #11087) [Link] (3 responses)

I should have elided the comma between "more bandwidth doesn't matter" (the name of mike belshe's famous paper) "for websites".

Certainly in your scenario - well, sneakernet might have been a better option - more bandwidth would have been helpful, but I hope with better queue management that backup affected your users minimally? If it didn't, well, patches went into linux 5.7 for wireguard and cake (I forget which version prior to that for fq_codel and ipsec ) that made vpn traffic terminating on the bottleneck router work beautifully in the face of big flows like that.

We still have no good queue management solution for userspace vpns.

LWN's unreliable predictions for 2022

Posted Jan 5, 2022 9:11 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

TBF, sneakernet (and the famous "station wagon full of tapes/drives") is just a very high throughput and very high latency connection. It's a neat way to get more throughput for a one-off, though.

LWN's unreliable predictions for 2022

Posted Jan 8, 2022 1:22 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

It cannot be overemphasized just *how* high-throughput modern sneakernet is. See https://what-if.xkcd.com/31/ for some numbers, but in short, you can sneakernet all of the bits you want in a surprisingly small box, provided you're willing to pay for extremely dense storage media such as SD cards. Assuming you have a lot of data,[1] don't care about latency at all, and just want to maximize overall throughput, there is no reasonable[2] way to establish a network connection which can seriously compete with that.

[1]: https://www.google.com/search?q=24+hours+*+1+gigabit%2Fs
[2]: Widely available to consumers and/or businesses for general-purpose use, as opposed to some highly-specialized fabric in the NSA's basement or something.

LWN's unreliable predictions for 2022

Posted Jan 5, 2022 9:21 UTC (Wed) by vadim (subscriber, #35271) [Link]

Sneakernet would have meant using public transport for some of the people involved, in a time when covid was still a new thing, vaccines weren't being offered, and hospital staff weren't quite sure how to handle it. Avoiding that if at all possible was a very good idea.

Yes, of course disruption was minimized, but still, spending a week downloading stuff before real work can happen is far from ideal.

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 19:21 UTC (Tue) by MattBBaker (subscriber, #28651) [Link]

I hope the GIL one happens. There seems to be a critical mass of people who want to do concurrent programming on Python without having to resort to silly tricks

LWN's unreliable predictions for 2022

Posted Jan 5, 2022 5:25 UTC (Wed) by rustylife (subscriber, #102864) [Link]

Long live the LWN! Thank you for everything you do!

LWN's unreliable predictions for 2022

Posted Jan 5, 2022 14:02 UTC (Wed) by guus (subscriber, #41608) [Link] (2 responses)

While there is more competition in the embedded space, it's also the case that embedded devices are getting more and more powerful, requiring more advanced operating systems. Already we have multi-core microcontrollers like the Espressif ESP32 and the Raspberry Pi Pico that (can) run FreeRTOS, which is a small step away from running a BSD or Linux kernel. And a lot of ARM SBCs (like the regular Raspberry Pi lineup) are used in an embedded fashion, and they already run Linux. So even if marketshare drops by percentage, usage of Linux might still go up in absolute numbers.

LWN's unreliable predictions for 2022

Posted Jan 5, 2022 16:02 UTC (Wed) by excors (subscriber, #95769) [Link]

> Already we have multi-core microcontrollers like the Espressif ESP32 and the Raspberry Pi Pico that (can) run FreeRTOS, which is a small step away from running a BSD or Linux kernel.

I don't really see that as a small step. FreeRTOS is basically a task scheduler and some synchronisation primitives (plus a bunch of optional libraries for networking etc) - they advertise the kernel as using single-digit KBs of ROM and a few hundred bytes of RAM, in a minimal but usable configuration. I'm not sure what state-of-the-art embedded Linux is, but I'd expect it's about three orders of magnitude larger.

The Raspberry Pi Pico looks quite powerful for a microcontroller but it's still only 264KB of SRAM (and no MMU), so it seems clearly in the RTOS category and not the stripped-down-Linux category. (I guess it might fit the "soon-to-be-abandoned prototype of an absurdly stripped down Linux kernel with no room for any useful application code" category too, but that doesn't seem very useful in practice.)

LWN's unreliable predictions for 2022

Posted Jan 6, 2022 18:14 UTC (Thu) by ejr (subscriber, #51652) [Link]

Also remember the use cases. Linux is severe overkill for my uses of monitoring sensors and sending along the results. Overkill often results in more power draw, and these often are battery plus *maybe* solar systems.

I am curious why Fuschia even exists. The L4 ecosystem has been around for a long time, and there are others already in that space as well. While it might be pure NIH, I suspect the developers have/had some idea of specific uses they could not tackle. I'd love to know what they are.

LWN's unreliable predictions for 2022

Posted Jan 6, 2022 1:28 UTC (Thu) by luya (subscriber, #50741) [Link]

Gimp will see 3.0 release and Blender 3D will use Wayland as default and X server as fallback.

LWN's unreliable predictions for 2022

Posted Jan 6, 2022 23:56 UTC (Thu) by spwhitton (subscriber, #71678) [Link]

I'm not sure that the linked mail provides evidence that the Emacs maintainers are getting grumpy with the copyright assignment requirement -- in that mail, Lars is complaining specifically about how long the assignment process takes at present. From my own reading of emacs-devel, setting aside Stallman's own posts, I get the sense that there isn't a strong movement for or against the copyright requirement within the active contributor base. I'm not actually sure what Lars himself thinks, actually, and I wouldn't want to presume.

LWN's unreliable predictions for 2022

Posted Jan 7, 2022 7:14 UTC (Fri) by jabbapao (guest, #140992) [Link] (1 responses)

I just subscribed again because I was interested in seeing what kind of coverage of the Steam Deck and Valve's Proton technology this site had to offer. To my surprise, I could find very little, both in the articles and in a search I did. All the mentions seem to be in the comments.

Why is that?

Do people not see the Steam Deck and Proton as very consequential, potentially, to the whole Linux ecosystem?

LWN's unreliable predictions for 2022

Posted Jan 7, 2022 17:52 UTC (Fri) by tshow (subscriber, #6411) [Link]

I can't speak for anyone else here, but personally I find I take the long view on these things. There have been many, many (arguably) interesting Linux-based projects that have looked like they were going to be important and valuable, and in a high percentage of cases they have flamed out, lost the interest of their supporters or otherwise sank beneath the waves.

Note, this is (at least) a tech thing, not a thing specific to Linux; where other people ask where their personal robot butler and flying car are, I ask where my holographic storage is.

Consider Wayland, for instance, which has seen some discussion in this article. It's been going since 2008, if memory serves, and has been "right around the corner" for nearly as long. It looks like it's now getting to the point where it's actually a viable option, but it's been a long road, and I'd bet the majority of Linux machines (that are connected to monitors, at least) are still running XOrg. Mine still is. That's not a value judgement on Wayland, it's an indication of how much time and effort these projects can require before they're kinetically consequential, as opposed to potentially consequential.

You also have to factor in the whole "Linux Year of the Desktop" thing. Steam Deck and Proton are potentially exciting tech, but over the years we've watched a lot of potentially exciting and technically superior tech fail to be adopted for what are often entirely un-technical reasons.

At least for me, Steam Deck and Proton will move from being vaguely interesting to being worth paying attention to once they've shown some staying power, and I say that as a (formerly pro, now hobbyist) game dev who uses Linux as the lead platform even for games intended for console.

LWN's unreliable predictions for 2022

Posted Jan 8, 2022 1:02 UTC (Sat) by NightMonkey (subscriber, #23051) [Link]

Long live LWN! Thank you for a better-informed 25 years! :)