6 ms·
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 "sta
by DCKing 7y ago
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.
- curt15 7y agoRed Hat is known to backport features into RHEL kernels. Could Wireguard conceivably make it into RHEL 8.x?
- CiPHPerCoder 7y agoRed 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.
- jagger27 7y agoI 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.
- CiPHPerCoder 7y agoThe 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".
- chucky_z 7y agoRHEL themselves vendor RHSCL -- https://developers.redhat.com/products/softwarecollections/overview https://developers.redhat.com/products/softwarecollections/o... For CentOS and friends there is https://www.softwarecollections.org/en/ https://www.softwarecollections.org/en/ https://access.redhat.com/products/Red_Hat_Enterprise_Linux/Developer/#rhscl=&dev-page=5 https://access.redhat.com/products/Red_Hat_Enterprise_Linux/... are maintained by RedHat directly.
- ihalip 7y agoRHEL 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.
- CiPHPerCoder 7y agoI hope that it does, in the offchance that I need to do anything running on RHEL 10-15 years from now.
- protanopia 7y agoWhy not just continue using the dkms module?
- jdoss 7y agoMostly 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.
- zx2c4 7y agoLikely yes. I'm discussing that possibility with them.
- Quekid5 7y agoThat sounds incredible. What kind of kernel-version differences are we talking about here? Basically... how many conflicts and what's the diffstats :)
- bityard 7y agoGo 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.
- zx2c4 7y agoActually, 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/ 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.
- ficklepickle 7y agoWow. Non-systems dev here, but that sounds seriously impressive. Thanks for your work. I know I will benefit from it.
- Quekid5 7y agoWell, it worked for ZoL. (I mean that in a positive way. I'm a fan of both... although only theoretically about WireGuard.)
- mekster 7y agoI 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.
- zx2c4 7y agoWireGuard by now is a several-years-old codebase that has seen quite a bit of deployment, thanks to our compat layer for older kernels.