Linus Torvalds oversees every line of code added to the Linux kernel, but in recent years the male-dominated community has become increasingly divided, reports BBC. Rows about sexism and rudeness led to the creation of a Code of Conflict (CoC) in 2015 which was short -- simply recommending people "be excellent to each other." That has now been replaced by a more detailed Code of Conduct -- which retains the acronym, but attempts to be more inclusive and eliminate insulting and derogatory comments and behaviour. Reader sinij writes: Recently Linux Community adopted a new controversial Code of Conduct authored by Contributor Covenant also known for authoring the Post-Meritocracy Manifesto. In an exclusive email interview with the BBC, Mr Torvalds shared his thoughts on his decision to temporarily step aside, the controversy behind the CoC, and the defects of the community he set up. His thoughts on CoC: The advantage of concentrating on technology is that you can have some mostly objective measures, and some basis for agreement, and you can have a very nice and healthy community around it all. I really am motivated by the technology, but the community around Linux has been a big positive too. But there are very tangible and immediate common goals in any technical project like Linux, and while there is occasionally disagreement about how to solve some particular issue, there is a very real cohesive force in that common goal of improving the project. And even when there are disagreements, people in the end often have fairly clear and objective measures of what is better. Code that is faster, simpler, or handles more cases naturally is just objectively 'better', without people really having to argue too much about it.

In contrast, the arguments about behaviour never seem to end up having a common goal. Except, in some sense, the argument itself. Have you read the Twitter feeds and other things by the people who seem to care more about the non-technical side? I think your 'hyped stories' is about as polite as you can put it. It's a morass of nastiness. Instead of a 'common goal', you end up with horrible fighting between different 'in-groups'. It's very polarising, and both sides love egging the other side on. It's not even a 'discussion', it's just people shouting at each other. That's actually the reason I for the longest time did not want to be involved with the whole CoC discussion in the first place. That whole subject seems to very easily just devolve and become unproductive. And I found a lot of the people who pushed for a CoC and criticised me for cursing to be hypocritical and pointless. I could easily point you to various tweet storms by people who criticise my 'white cis male' behaviour, while at the same time cursing more than I ever do.

So that's my excuse for dismissing a lot of the politically correct concerns for years. I felt it wasn't worth it. Anybody who uses the words 'white cis male privilege' was simply not worth my time even talking to, I felt. "And I'm still not apologising for my gender or the colour of my skin, or the fact that I happen to have the common sexual orientation. What changed? Maybe it was me, but I was also made very aware of some of the behaviour of the 'other' side in the discussion. Because I may have my reservations about excessive political correctness, but honestly, I absolutely do not want to be seen as being in the same camp as the low-life scum on the internet that think it's OK to be a white nationalist Nazi, and have some truly nasty misogynistic, homophobic or transphobic behaviour. And those people were complaining about too much political correctness too, and in the process just making my public stance look bad. And don't get me wrong, please -- I'm not making excuses for some of my own rather strong language. But I do claim that it never ever was any of that kind of nastiness. I got upset with bad code, and people who made excuses for it, and used some pretty strong language in the process. Not good behaviour, but not the racist/etc claptrap some people spout. So in the end, my 'I really don't want to be too PC' stance simply became untenable. Partly because you definitely can find some emails from me that were simply completely unacceptable, and I need to fix that going forward. But to a large degree also because I don't want to be associated with a lot of the people who complain about excessive political correctness.

The Fedora Project announced Tuesday the beta availability of Fedora 29 -- the latest version of the free and open-source Fedora OS. From a report: It features updated packages, improved support for Raspberry Pi, and more. "Highlighting Fedora 29 Beta is the addition of modularity across all Fedora editions. First delivered in Fedora 28 Server, modularity enables multiple versions of the same software (like Node.js) to be selected on a per-system basis, with parallel installation done through containers. This can provide some users the ability to use tried-and-true versions of software while enabling other users to work with just-released innovation without impacting the overall stability of the Fedora operating system," says Matthew Miller, Fedora Project Leader.

Miller further says, "The importance of ARM to IoT has not been lost on Fedora, and Fedora 29 Beta aims to make the Fedora operating system a home for both ARM and IoT. These features start with enhanced ZRAM support for swap on ARMv7 and aarch64, which can improve the performance and reliability of Fedora 29 Beta on ARM Single Board Computers, like the Raspberry Pi. These devices are used by 'makers' and in developmental IoT solutions."

An anonymous reader quotes MSPowerUser: Nearly every Linux distro is already available in the Microsoft Store, allowing developers to use Linux scripting and other tools running on the Windows Subsystem for Linux (WSL). Now another distro has popped up in the Store, and unlike the others it claims to be specifically optimised for WSL, meaning a smaller and more appropriate package with sane defaults which helps developers get up and running faster.

WLinux is based on Debian, and the developer, Whitewater Foundry, claims their custom distro will also allow faster patching of security and compatibility issues that appear from time to time between upstream distros and WSL... Popular development tools, including git and python3, are pre-installed. Additional packages can be easily installed via the apt package management system... A handful of unnecessary packages, such as systemd, have been removed to improve stability and security.
The distro also offers out of the box support for GUI apps with your choice of X client, according to the original submission.

WLinux is open source under the MIT license, and is available for free on GitHub. It can also be downloaded from Microsoft Store at a 50% discount, with the development company promising the revenue will be invested back into new features.

Linus Torvalds announced on Sunday that he was sorry for how he treated the community over the years. Torvalds, 48, said he planned to make some changes to how he conducted himself, and on that part, he said he would be taking some time off from Linux kernel development work. The New Yorker has published a story on Torvalds today in which it notes that it reached out to Torvalds days before he made the big announcement. From the story, which may be paywalled for some readers: Torvalds's decision to step aside came after The New Yorker asked him a series of questions about his conduct for a story on complaints about his abusive behavior discouraging women from working as Linux-kernel programmers. In a response to The New Yorker, Torvalds said, "I am very proud of the Linux code that I invented and the impact it has had on the world. I am not, however, always proud of my inability to communicate well with others -- this is a lifelong struggle for me. To anyone whose feelings I have hurt, I am deeply sorry."

Torvalds's response was conveyed by the Linux Foundation, which supports Linux and other open-source programming projects and paid Torvalds $1.6 million in annual compensation as of 2016. The foundation said that it supported his decision and has encouraged women to participate but that it has little control over how Torvalds runs the coding process. "We are able to have varying degrees of impact on these outcomes in newer projects," the statement said. "Older more established efforts like the Linux kernel are much more challenging to influence."

Linux's elite developers, who are overwhelmingly male, tend to share their leader's aggressive self-confidence. There are very few women among the most prolific contributors, though the foundation and researchers estimate that roughly ten per cent of all Linux coders are women. "Everyone in tech knows about it, but Linus gets a pass," Megan Squire, a computer-science professor at Elon University, told me, referring to Torvalds's abusive behavior. "He's built up this cult of personality, this cult of importance."

LLVM release manager Hans Wennborg announced Wednesday the official availability of LLVM 7.0 compiler stack as well as associated sub-projects including the Clang 7.0 C/C++ compiler front-end, Compiler-RT, libc++, libunwind, LLDB, and others. From a report: There is a lot of LLVM improvements ranging from CPU improvements for many different architectures, Vega 20 support among many other AMDGPU back-end improvements, the new machine code analyzer utility, and more. The notable Clang C/C++ compiler has picked up support for function multi-versioning (FMV), initial OpenCL C++ support, and many other additions. See my LLVM 7.0 / Clang 7.0 feature overview for more details on the changes with this six-month open-source compiler stack update. Wennborg's release statement can be read on the llvm-announce list.

Liam Tung reporting for ZDNet: Ubuntu maintainer Canonical and Microsoft have teamed up to release an optimized Ubuntu Desktop image that's available through Microsoft's Hyper-V gallery. The Ubuntu Desktop image should deliver a better experience when running it as a guest on a Windows 10 Pro host, according to Canonical. The optimized version is Ubuntu Desktop 18.04.1 LTS release, also known as Bionic Beaver. Microsoft's work with Canonical was prompted by its users who wanted a "first-class experience" on Linux virtual machines (VMs) as well as Windows VMs. To achieve this goal, Microsoft worked with the developers of XRDP, an open-source remote-desktop protocol (RDP) for Linux based on Microsoft's RDP for Windows. Thanks to that work, XRDP now supports Microsoft's Enhanced Session Mode, which allows Hyper-V to use the open-source implementation of RDP to connect to Linux VMs. This in turn gives Ubuntu VMs on Windows hosts a better mouse experience, an integrated clipboard, windows resizing, and shared folders for easier file transfers between host and guest. Microsoft's Hyper-V Quick Create VM setup wizard should also help improve the experience. "With the Hyper-V Quick Create feature added in the Windows 10 Fall Creators Update, we have partnered with Ubuntu and added a virtual machine image so in a few quick minutes, you'll be up and developing," said Clint Rutkas, a senior technical product manager on Microsoft's Windows Developer Team. "This is available now -- just type 'Hyper-V Quick Create' in your start menu."

Google has released a Chrome OS 69 update that introduces a range of new features. From a report: Most notably, there's now support for running Linux apps. You'll need a supported machine (a handful of machines from Acer, ASUS, HP, Lenovo, Samsung and Google itself). Still, this could be more than a little helpful if you want to run a conventional desktop app or command line terminal without switching to another PC or a virtual environment. The new software also adds the long-in-the-making Night Light mode to ease your eyes at the end of the day. Voice dictation is now available in any text field, and there's a fresh Files interface that can access Play files and Team Drives.

An anonymous reader shares a report: Over on the EEVblog, someone noticed an interesting chip that's been apparently flying under our radar for a while. This is an ARM processor capable of running Linux. It's hand-solderable in a TQFP package, has a built-in Mali GPU, support for a touch panel, and has support for 512MB of DDR3. If you do it right, this will get you into the territory of a BeagleBone or a Raspberry Pi Zero, on a board that's whatever form factor you can imagine. Here's the best part: you can get this part for $1 USD in large-ish quantities. A cursory glance at the usual online retailers tells me you can get this part in quantity one for under $3. This is interesting, to say the least.

The chip in question, the Allwinner A13, is a 1GHz ARM Cortex-A8 processor. While it's not much, it is a chip that can run Linux in a hand-solderable package. There is no HDMI support, you'll need to add some more chips (that are probably in a BGA package), but, hey, it's only a dollar. If you'd like to prototype with this chip, the best options right now are a few boards from Olimex, and a System on Module from the same company. That SoM is an interesting bit of kit, allowing anyone to connect a power supply, load an SD card, and get this chip doing something. Currently, there aren't really any good solutions for a cheap Linux system you can build at home, with hand-solderable chips.

Following Linus Torvalds' public apology for his behavior over the years, the Linux Community said it will be adopting a new "Code of Conduct", which pledges to make "participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation."

On Sunday, Linus Torvalds spoke about the confusion he had regarding Maintainer's Summit, but more importantly, how this incident gave him a chance to realize "that I really had been ignoring some fairly deep-seated feelings in the community." In an email to the Linux Kernel Mailing List, Torvalds apologized for hurting people with his behavior over the years, and possibly driving some people "away from kernel development entirely." On that end, said Torvalds, "I am going to take time off and get some assistance on how to understand people's emotions and respond appropriately." He wrote: [...] It's one thing when you can ignore these issues. Usually it's just something I didn't want to deal with. This is my reality. I am not an emotionally empathetic kind of person and that probably doesn't come as a big surprise to anybody. Least of all me. The fact that I then misread people and don't realize (for years) how badly I've judged a situation and contributed to an unprofessional environment is not good. This week people in our community confronted me about my lifetime of not understanding emotions. My flippant attacks in emails have been both unprofessional and uncalled for. Especially at times when I made it personal. In my quest for a better patch, this made sense to me. I know now this was not OK and I am truly sorry.

The above is basically a long-winded way to get to the somewhat painful personal admission that hey, I need to change some of my behavior, and I want to apologize to the people that my personal behavior hurt and possibly drove away from kernel development entirely.I am going to take time off and get some assistance on how to understand people's emotions and respond appropriately.

Put another way: When asked at conferences, I occasionally talk about how the pain-points in kernel development have generally not been about the _technical_ issues, but about the inflection points where development flow and behavior changed. These pain points have been about managing the flow of patches, and often been associated with big tooling changes - moving from making releases with "patches and tar-balls" (and the _very_ painful discussions about how "Linus doesn't scale" back 15+ years ago) to using BitKeeper, and then to having to write git in order to get past the point of that no longer working for us. We haven't had that kind of pain-point in about a decade. But this week felt like that kind of pain point to me. To tie this all back to the actual 4.19-rc4 release (no, really, this_is_ related!) I actually think that 4.19 is looking fairly good, things have gotten to the "calm" period of the release cycle, and I've talked to Greg to ask him if he'd mind finishing up 4.19 for me, so that I can take a break, and try to at least fix my own behavior.

This is not some kind of "I'm burnt out, I need to just go away" break. I'm not feeling like I don't want to continue maintaining Linux. Quite the reverse. I very much *do* want to continue to do this project that I've been working on for almost three decades. This is more like the time I got out of kernel development for a while because I needed to write a little tool called "git". I need to take a break to get help on how to behave differently and fix some issues in my tooling and workflow.

And yes, some of it might be "just" tooling. Maybe I can get an email filter in place so at when I send email with curse-words, they just won't go out. Because hey, I'm a big believer in tools, and at least _some_ problems going forward might be improved with simple automation. [...]

Here's an analysis of the Linux kernel repository that attempts to find some fresh numbers on the current kernel development trends. He writes: The kernel repository is at 782,487 commits in total from around 19.009 different authors. The repository is made up of 61,725 files and from there around 25,584,633 lines -- keep in mind there is also documentation, Kconfig build files, various helpers/utilities, etc. So far this year there has been 49,647 commits that added 2,229,836 lines of code while dropping 2,004,759 lines of code. Or a net gain of just 225,077 lines. Keep in mind there was the removal of some old CPU architectures and other code removed in kernels this year so while a lot of new functionality was added, thanks to some cleaning, the kernel didn't bloat up as much as one might have otherwise expected. In 2017 there were 80,603 commits with 3,911,061 additions and 1,385,507 deletions. Given just over one quarter to go, on a commit and line count 2018 might come in lower than the two previous years.

Linus Torvalds remains the most frequent committer at just over 3% while the other top contributions to the kernel this year are the usual suspects: David S. Miller, Arnd Bergmann, Colin Ian King, Chris Wilson, and Christoph Hellwig. So far in 2018 there were commits from 3,320 different email addresses. This is actually significantly lower than in previous years.

Longtime Slashdot reader DrYak writes: Phoronix is reporting that multiple users who all use Wine and DXVK compatibility layers have seen their Overwatch accounts banned by Blizzard. Previously, Blizzard has stated: "playing on Linux or even a Mac while on an emulated Windows environment is not bannable." But users report on Reddit getting banned simply after testing some rendering options. Tech support has answered that they are escalating the ticket and trying to take a closer look, hoping to avoid this from happening to other Linux users. According to Phoronix, the most common explanation for the bans "is a false-positive from Blizzard's anti-cheat technology having issue with DXVK."

An anonymous reader quotes a report from ZDNet: Users of Kodi, a popular media player and platform designed for TVs and online streaming, have been the targets of a malware campaign, ZDNet has learned from cyber-security firm ESET. According to a report that will be published later today and shared with ZDNet in advance, the company's malware analysts have uncovered that at least three popular repositories of Kodi add-ons have been infected and helped spread a malware strain that secretly mined cryptocurrency on users' computers.

ESET researchers say they found malicious code hidden in some of the add-ons found on three add-on repositories known as Bubbles, Gaia, and XvBMC, all offline at the time of writing, after receiving copyright infringement complaints. Researchers said that some of the add-ons found on these repositories would contain malicious code that triggered the download of a second Kodi add-on, which, in turn, would contain code to fingerprint the user's OS and later install a cryptocurrency miner. While Kodi can run on various platforms, ESET says that the operators of this illicit cryptocurrency mining operation only delivered a miner for Windows and Linux users. The crooks reportedly mined for Monero, infecting over 4,700 victims and generating over 62 Monero coins, worth today nearly $7,000.

Designed to run on minimal hardware, Elive is very much a passion project of its leader, Samuel F Baggen. Based on Debian, the first version took a bow in 2005. The second stable version made an appearance in 2010 and it has been a long eight years for the third stable version to become available. The Register: Elive has an impressively low bar to entry, with hardware requirements for the distribution coming in at 256 MB RAM and a 500 MHz CPU, meaning that some very elderly silicon is theoretically going to be able to enjoy the highly polished Enlightenment desktop. "Theoretically" because after The Register took Elive 3.0.0 out for a spin on a relatively low-powered laptop, we'd frankly baulk at running it on anything much slower than a 533MHz Core 2 with at least 512 MB RAM. However, the Enlightenment UI is undeniably an attractive desktop, particularly if a macOS-alike dock is your thing, and runs at an impressive lick even on hardware that lacks graphics acceleration.

At its core, Elive is based on the Debian 8 distribution (aka Jessie), using the 3.16 kernel and version 0.17.6 of the Enlightenment X11 Window Manager. It comes replete with a full set of applications, including the ubiquitous LibreOffice and Gimp, along with a variety of productivity and entertainment tools, some of which are Elive's own. Unlike the previous version of Elive, 3.0.0 removes the requirement of donating to the project in order to install the thing locally (although Baggen was quick to tell The Reg that cost-free alternatives existed, but often with annoying processes).

At this year's Open Source Summit, Linus Torvalds sat for a wide-ranging "keynote" interview with Dirk Hohndel, chief open source officer at VMWare, which has been partially transcribed below. And Linus explained, among other things, why the last merge window was harder than others: One of the issues we have is when we've had these hardware security issues, and they've kept happening now, the last year -- they're kept under wraps. So we knew about the issue for the last several months, but because it was secret and we weren't allowed to talk about it, we couldn't do our usual open development model. We do the best we can, and people really care deeply about getting a good product out, but when you have to do things in secret, and when you can't use all the nice infrastructure for development and for testing that we have for all the usual code, it just is way more painful than it should be. And then that just means that, especially when the information becomes public during what is otherwise a busy period anyway, it's just annoying...

I still love speculative execution. Don't get me wrong. I used to work for a CPU company. We did it in software, back when I worked there. I think a CPU has to do speculative execution. It's somewhat sad that then people didn't always think about or didn't always heed the warnings about what can go wrong when you take a few shortcuts in the name of making it slightly simpler for everybody, because you're going to throw away all that work anyway, so why bother to do it right. And that's when the security -- every single security problem we've had has been basically of that kind, where people knew that "Hey, this is speculative work. If something goes wrong we'll throw all the data away, so we don't need to be as careful as we would otherwise." I think it was a good lesson for the industry, but it was certainly not a fun lesson for us on the OS side, where we had to do a lot of extra work for problems that weren't our problems.

It feels somehow unfair. I mean, when we have a security bug that was our own fault, it's like, "Okay, it was us screwing up. It's fair that we have to do all the work to then fix our own bugs." But it feels slightly less fair when you have to fix somebody else's...
"The good news -- I mean the really good news, and I'm serious about this -- is that the bugs have become clearly more and more esoteric," Linus adds. "So it impacts fewer and fewer cases, and clearly hardware people at Intel and other places are now so aware of it that I'm hoping we're really getting to the dregs of the hardware security bugs, and going forward we'll have much fewer of them. I think we're going to the better days, when A.) we got the bugs fixed, and B.) people were thinking about them beforehand."

There's a lot more, so read on for more excerpts...

From The Linux Foundation's mailing list: Last Friday (just before Labor Day) I learned that Linus had gotten confused about when and where the Maintainer's Summit was going to be held this year. And most unfortunately, he has already scheduled a family vacation overlapping with the week of the Maintainer's Summit. Over the weekend, I've been conferring with folks from the Linux Foundation, Linus, and the Maintainer's / Kernel Summit program committee. We explored a lot of options, but ultimately there were only two choices that were workable:
1) Have the Maintainer's Summit in Vancouver, without Linus.
2) Move the Maintainer's Summit to Edinburgh, with Linus.

Curiously enough, Linus suggested option #1. And while holding the Maintainer's Summit without Linus might be an interesting experiment, ultimately, the Program Committee had a strong consensus that moving it Summit to Edinburgh was the better option.

This means that the Maintainer's Summit will take place in Edinburgh, on Monday afternoon, October 22nd. As a reminder, the Maintainer's Summit is an invite-only workshop, with ~30 people attending. The focus of the Maintainer's Summit is process and development issues, *not* technical issues. The Kernel Summit track will still be held in Vancouver alongside Plumber's. Technical discussions will take place there; we simply won't have the time, or necessarily, the right people, to have technical discussions at the Maintainer's Summit.

This week in Vancouver, Linux kernel developer Greg Kroah-Hartman criticized Intel's slow initial response to the Spectre and Meltdown bugs in a talk at the Open Source Summit North America. An anonymous reader quotes eWeek: Kroah-Hartman said that when Intel finally decided to tell Linux developers, the disclosure was siloed.... "Intel siloed SUSE, they siloed Red Hat, they siloed Canonical. They never told Oracle, and they wouldn't let us talk to each other." For an initial set of vulnerabilities, Kroah-Hartman said the different Linux vendors typically work together. However, in this case they ended up working on their own, and each came up with different solutions. "It really wasn't working, and a number of us kernel developers yelled at [Intel] and pleaded, and we finally got them to allow us to talk to each other the last week of December [2017]," he said. "All of our Christmas vacations were ruined. This was not good. Intel really messed up on this," Kroah-Hartman said...

"The majority of the world runs Debian or they run their own kernel," Kroah-Hartman said. "Debian was not allowed to be part of the disclosure, so the majority of the world was caught with their pants down, and that's not good." To Intel's credit, Kroah-Hartman said that after Linux kernel developers complained loudly to the company in December 2017 and into January 2018, it fixed its disclosure process for future Meltdown- and Spectre-related vulnerabilities... "Intel has gotten better at this," he said.

An interesting side effect of the Meltdown and Spectre vulnerabilities is that Linux and Windows developers are now working together, since both operating systems face similar risks from the CPU vulnerabilities. "Windows and Linux kernel developers now have this wonderful back channel. We're talking to each other and we're fixing bugs for each other," Kroah-Hartman said. "We are working well together. We have always wanted that."

"Using the newly minted Linux 4.19 feature code, fresh benchmarks were carried out looking at the performance cost of Spectre/Meltdown/Foreshadow mitigations on Intel Xeon v. AMD EPYC CPUs," writes an anonymous Slashdot reader: Workloads affected by these CPU vulnerabilities mainly deal with I/O and frequent kernel calls while CPU bound tests are still found to be minimally impacted. When toggling these mitigations on Linux 4.19, Intel Xeon CPUs were found to be 10~15% slower with the default kernel while AMD EPYC CPUs dropped to about 5% slower.

darthcamaro writes: In a wide-ranging conversation at the Open Source Summit, Linus Torvalds admitted that he no longer knows everything that's in LInux. "Nobody knows the whole kernel anymore," Torvalds said. "Having looked at patches for many years, I know the big picture of all the areas in the kernel and I can look at a patch and know if it's right or wrong." Overall, he emphasized that being open source has enabled Linux to attract new developers that can pick up code and maintain all the various systems in Linux. In his view, the only way to deal with complexity is to be open. "When you have complexity you can't manage it in a closed environment, you need to have the people that actually find problems and give them the ability to get involved and help you to fix them," Torvalds said. "It's a complicated world and the only way to deal with complexity is the open exchange of ideas."

Will Townsend, a senior analyst at Moor Insights & Strategy research firm, writes: As it relates to networking, the Linux Foundation is currently focused on a number of projects that are bringing top networking vendors, operators, service providers, and users together. Among the top initiatives are the Open Network Automation Platform (ONAP) and Data Plane Development Kit (DPDK). In this article, I would like to dive into both of these initiatives and share my perspective on how each is transforming the nature of networking [Editor's note: the website may have auto-playing videos; an alternative link was not available].

It makes sense that ONAP's releases are named after global cities, considering the platform's growing global footprint. ONAP is aimed at bringing real-time automation and orchestration to both physical and virtualized network functions. The first release in the fall of 2017, named Amsterdam, delivered a unified architecture for providing closed-loop networking automation. The underlying framework ensured a level of modularity to facilitate future functionality as well as standards harmonization and critical upstream partner collaboration. Initial use cases centered on Voice Over LTE (VoLTE) services as well as Virtualized Consumer Premise Equipment (vCPE). Both are extremely cost disruptive from a deployment and management perspective and deliver enhanced service provider agility. What I find extremely compelling is that Amsterdam was only an eight-month development cycle from start to release. That's an amazing feat even in the fast-paced technology industry.

[...] DPDK was an effort initially led by Intel at its inception nearly eight years ago, but became a part of the Linux Foundation back in 2017. At a high level, the technology accelerates packet processing workloads running on a variety of CPU architectures. DPDK is aimed at improving overall network performance, delivering enhanced encryption for improved security and optimizing lower latency applications that require lightning-fast response time. The transformative power of 5G networks lies in their potential to deliver low latency for applications such as augmented/virtual reality and self-driving cars -- DPDK will further extend that performance for next-generation wireless wide area networks. I had the opportunity recently to speak to project chair Jim St. Leger after the fifth DPDK release, and I was impressed with the depth and breadth of the open source project. Over 25 companies and 160 technologists are involved in advancing the effort. With the proliferation of data, cord cutting at home, and growing consumption of video over wired and wireless networks, high-quality compression techniques will dramatically improve performance and reliability. DPDK appears to be poised to contribute significantly to that effort.