Hacker News Reader

Comment by DCKing | Hacker News Reader

Great. This will mean wonders for the short-term adoption of Wireguard, as it's now in a "stable" Linux distro. After Ubuntu 20.04 there's a big gap in new "stable/enterprise" releases.

Debian 11 - Mid 2021, probably

OpenSUSE Leap/SLES 16 - Mid 2021, probably

Ubuntu 22.04 LTS - April 2022

Red Hat 9 - probably 2024 ?

So if Ubuntu hadn't included this, we would have to wait more than a year to have it in the kernel of a "server-grade" Linux system by default. Most people don't like running more cutting edge distros or fiddling with the kernel on their servers. Defaults matter, so this will be great for Wireguard adoption.

View on HN

Red Hat is known to backport features into RHEL kernels. Could Wireguard conceivably make it into RHEL 8.x?

Red Hat still ships ancient versions of PHP in their official packages.

I wouldn't bet on a backport unless you have a lot of clout (a.k.a. purchasing power) behind you.

I can understand why RHEL would still ship ancient PHP versions to keep legacy apps running, but I think WireGuard would be an easier sell considering it's so unobtrusive and has no legacy software to worry about breaking.

The problem isn't "RHEL ships ancient PHP for legacy apps".

The problem is "RHEL doesn't also ship newer PHP as an alternative and you need to instead rely on third-party repositories".

RHEL themselves vendor RHSCL -- https://developers.redhat.com/products/softwarecollections/o...

For CentOS and friends there is https://www.softwarecollections.org/en/

https://access.redhat.com/products/Red_Hat_Enterprise_Linux/... are maintained by RedHat directly.

RHEL 8.2 beta brings in some kernel changes that are (maybe coincidentally) also used by Wireguard, so I don't think it's far-fetched.

I hope that it does, in the offchance that I need to do anything running on RHEL 10-15 years from now.

Likely yes. I'm discussing that possibility with them.

That sounds incredible. What kind of kernel-version differences are we talking about here? Basically... how many conflicts and what's the diffstats :)

Actually, that's not even relevant. For the last several years, I've been developing WireGuard on top of the latest kernel from Linus, while maintaining a "compat" layer to seamlessly backport it using horrendous tricks with the C preprocessor. That's allowed me to keep the codebase clean and ready for mainline Linux, while enabling people to use it on all the old kernels. I've maintained this backport layer for every kernel since Linux 3.10, including the RHEL-7 and RHEL-8 ports. This has been quite a lot of ugly work, but ultimately worth it as its given us enormous amounts of testing in odd environments, so what's shipping now in Linux 5.6 is rather polished, as opposed to being brand new and untested. We maintain some CI for this, too, testing lots of kernels and architectures. Scroll down to the "wireguard-linux-compat" section of https://www.wireguard.com/build-status/ to see.

All this is to say that there's not really much work that needs to be done by Ubuntu or RHEL or anyone else that wants to ship WireGuard -- the backporting stuff has already been done and is fairly widely deployed by now.

Wow. Non-systems dev here, but that sounds seriously impressive.

Thanks for your work. I know I will benefit from it.

Go look at the kernel source RPM for RHEL 6 or 7. The amount of backporting they do to keep the kernel version string from incrementing is insane.

Why not just continue using the dkms module?

Mostly to keep my personal sanity. Joking aside, IMO having to depend DKMS to correctly build the kernel module on kernel update every time for something that is network related isn't something I would consider rock solid for production. It is great when it works. Not so great when it doesn't.

Packaging WireGuard for Fedora, CentOS, and RHEL has been super fulfilling over the years, but DKMS is super fickle and buggy. wireguard-dkms is a package I would love to see drift off into the sunset if RH backports WireGuard into EL kernels.

I thought it was fair to wait for 2022.04 when Wireguard is only about to be included in mainline and few years in the kernel will certainly make it feel stable for the next LTS inclusion, so I was kind of surprised they went for it now as a backport.

Perhaps the code is good enough there aren't many weird bug reports to make it feel unstable.

WireGuard by now is a several-years-old codebase that has seen quite a bit of deployment, thanks to our compat layer for older kernels.

Well, it worked for ZoL.

(I mean that in a positive way. I'm a fan of both... although only theoretically about WireGuard.)

Reply on news.ycombinator.com