Tuxedo Computers "has teamed up with Manjaro to tease not one, not two, but several" Linux laptops, Forbes reports:
The Tuxedo Computers InfinityBook Pro 15...can be loaded with up to 64GB of RAM, a 10th-generation Intel Core i7 CPU, and as high as a 2TB Samsung EVO Plus NVMe drive. You can also purchase up to a 5-year warranty, and user-installed upgrades will not void the warranty...

Manjaro Lead Project Developer Philip Müller also teased a forthcoming AMD Ryzen laptop [on Forbes' "Linux For Everyone" podcast]. "Yes, we are currently evaluating which models we want to use because the industry is screaming for that," Müller says. "In the upcoming weeks we might get some of those for internal testing. Once they're certified and the drivers are ready, we'll see when we can launch those." Müller also tells me they're prepping what he describes as a "Dell XPS 13 killer."

"It's 10th-generation Intel based, we will have it in 14-inch with a 180-degree lid, so you can lay it flat on your desk if you like," he says.
The Manjaro/Tuxedo Computers partnership will also offer some intense customization options, Forbes adds.

"Want your company logo laser-etched on the lid? OK. Want to swap out the Manjaro logo with your logo on the Super key? Sure, no problem. Want to show off your knowledge of fictional alien races? Why not get a 100% Klingon keyboard?"

"I've grown quite fond of the docker container runtime. It's easy to install and use, and many of the technologies I write about depend upon this software," writes TechRepublic/Linux.com contributor Jack Wallen.

"But Red Hat has other plans." The company decided -- seemingly out of the blue -- to drop support for the docker runtime engine. In place of docker came Podman. When trying to ascertain why Red Hat split with Docker, nothing came clear. Sure, I could easily draw the conclusion that Red Hat had grown tired of the security issues surrounding Docker and wanted to take matters in their own hands. There was also Red Hat's issue with "no big fat daemons." If that's the case, how do they justify their stance on systemd?

Here's where my tinfoil hat comes into play. Understand this is pure conjecture here and I have zero facts to back these claims up... Red Hat is now owned by IBM. IBM was desperate to gain serious traction within the cloud. To do that, IBM needed Red Hat, so they purchased the company. Next, IBM had to score a bit of vendor lock-in. Using a tool like docker wouldn't give them that lock-in. However, if Red Hat developed and depended on their own container runtime, vendor lock-in was attainable....

Red Hat has jettisoned a mature, known commodity for a less-mature, relatively unknown piece of software -- without offering justification for the migration.... Until Red Hat offers up a sound justification for migrating from the docker container engine to Podman, there's going to be a lot of people sporting tinfoil hats. It comes with the territory of an always-connected world. And if it does turn out to be an IBM grab for vendor lock-in, there'll be a lot of admins migrating away from RHEL/CentOS to the likes of Ubuntu Server, SUSE/openSUSE, Debian, and more.
Red Hat's product manager of containers later touted Podman's ability to deploy containers without root access privileges in an interview with eWeek. "We felt the sum total of its features, as well as the project's performance, security and stability, made it reasonable to move to 1.0. Since Podman is set to be the default container engine for the single-node use case in Red Hat Enterprise Linux 8, we wanted to make some pledges about its supportability."

And a Red Hat spokesperson also shared their position with The New Stack. "We saw our customer base wanting the container runtime lifecycle baked-in to the OS or in delivered tandem with OpenShift."

Pine64 will finally start shipping the pre-order units of PinePhone Braveheart Edition on January 17, 2020. Fossbytes reports: A year ago, PinePhone was made available only to developers and hackers. After getting better responses and suggestions, the Pine64 developers planned to bring Pinephone for everyone. In November last year, pre-orders for PinePhone Braveheart Edition commenced for everyone. But due to manufacturing issues coming in the way, the shipment date slipped for weeks, which was scheduled in December last year.

PinePhone Braveheart Edition is an affordable, open source Linux-based operating system smartphone preloaded with factory test image running on Linux OS (postmarketOS) on inbuilt storage. You can check on PinePhone Wiki to find the PinePhone compatible operating system such as Ubuntu Touch, postmarketOS, or Sailfish OS, which you can boot either from internal storage or an SD card.

"Linux kernel head Linus Torvalds has warned engineers against adding a module for the ZFS filesystem that was designed by Sun Microsystems -- and now owned by Oracle -- due to licensing issues," reports ZDNet: As reported by Phoronix, Torvalds has warned kernel developers against using ZFS on Linux, an implementation of OpenZFS, and refuses to merge any ZFS code until Oracle changes the open-source license it uses.

ZFS has long been licensed under Sun's Common Development and Distribution License as opposed to the Linux kernel, which is licensed under GNU General Public License (GPL). Torvalds aired his opinion on the matter in response to a developer who argued that a recent kernel change "broke an important third-party module: ZFS". The Linux kernel creator says he refuses to merge the ZFS module into the kernel because he can't risk a lawsuit from "litigious" Oracle -- which is still trying to sue Google for copyright violations over its use of Java APIs in Android -- and Torvalds won't do so until Oracle founder Larry Ellison signs off on its use in the Linux kernel.

"If somebody adds a kernel module like ZFS, they are on their own. I can't maintain it and I cannot be bound by other people's kernel changes," explained Torvalds. "And honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's OK to do so and treat the end result as GPL'd," Torvalds continued.

"Other people think it can be OK to merge ZFS code into the kernel and that the module interface makes it OK, and that's their decision. But considering Oracle's litigious nature, and the questions over licensing, there's no way I can feel safe in ever doing so."

New submitter profi shares a report from Computing: Huawei has released the source code of openEuler, its distribution of Linux based on CentOS. The operating system was formally launched by Huawei in September 2019 in response to U.S. sanctions, which had briefly affected the company's access to Windows and Android operating systems. The source code has now been published on Gitee, the Chinese version of Github.

OpenEuler comprises two organizations on Gitee, one for source code and one for package sources. The openEuler organization was keen to highlight two particular packages, iSulad and A-Tune, among the openEuler source code. "iSulad is a lightweight gRPC service-based container runtime. Compared to runc, iSulad is written in C, but all interfaces are compatible with OCI. A-Tune is a system software to auto-optimize the system adaptively to multiple scenarios with embedded AI-engine." The announcement continues: "You will also see several infrastructure-supported projects that set up the community's operating systems... these systems are built on the Huawei Cloud through script automation."

Among the package sources, covered by the src-openeuler organization on Gitee, are around 1,000 packages with versions in both ARM64 and X86 architecture packages. Huawei claims its developers have made a number of enhancements to ARM64 openEuler code to improve multi-core efficiency. It is also working on a "green computing" ecosystem with Linaro and the Green Industry Alliance. At the moment, the organization claims, there are more than 50 contributors and just under 600 commits. The openEuler community has around 20 SIGs or project groups.

On Wednesday Phoronix cited a blog post by C++ game developer Malte Skarupke claiming his spinlocks experiments had discovered the Linux kernel had a scheduler issue affecting developers bringing games to Linux for Google Stadia.

Linus Torvalds has now responded: The whole post seems to be just wrong, and is measuring something completely different than what the author thinks and claims it is measuring.

First off, spinlocks can only be used if you actually know you're not being scheduled while using them. But the blog post author seems to be implementing his own spinlocks in user space with no regard for whether the lock user might be scheduled or not. And the code used for the claimed "lock not held" timing is complete garbage.

It basically reads the time before releasing the lock, and then it reads it after acquiring the lock again, and claims that the time difference is the time when no lock was held. Which is just inane and pointless and completely wrong...

[T]he code in question is pure garbage. You can't do spinlocks like that. Or rather, you very much can do them like that, and when you do that you are measuring random latencies and getting nonsensical values, because what you are measuring is "I have a lot of busywork, where all the processes are CPU-bound, and I'm measuring random points of how long the scheduler kept the process in place".

And then you write a blog-post blamings others, not understanding that it's your incorrect code that is garbage, and is giving random garbage values...

You might even see issues like "when I run this as a foreground UI process, I get different numbers than when I run it in the background as a batch process". Cool interesting numbers, aren't they?

No, they aren't cool and interesting at all, you've just created a particularly bad random number generator...

[Y]ou should never ever think that you're clever enough to write your own locking routines.. Because the likelihood is that you aren't (and by that "you" I very much include myself -- we've tweaked all the in-kernel locking over decades, and gone through the simple test-and-set to ticket locks to cacheline-efficient queuing locks, and even people who know what they are doing tend to get it wrong several times).

There's a reason why you can find decades of academic papers on locking. Really. It's hard.
"It really means a lot to me that Linus responded," the blogger wrote later, "even if the response is negative." They replied to Torvalds' 1,500-word post on the same mailing list -- and this time received a 1900-word response arguing "you did locking fundamentally wrong..." The fact is, doing your own locking is hard. You need to really understand the issues, and you need to not over-simplify your model of the world to the point where it isn't actually describing reality any more...

Dealing with reality is hard. It sometimes means that you need to make your mental model for how locking needs to work a lot more complicated...

An anonymous reader quotes Forbes: If you've been following the steady march of progress from Dell's Linux-first Project Sputnik team, you're no doubt aware that the "Developer Edition" variant of the XPS 13 is one of the finest Linux-ready ultrabooks you can buy. Just ahead of CES 2020, Dell is pushing out a few more improvements including a feature that's been hotly requested: fingerprint-reader support. It's one of several enhancements Dell is promising to Linux users for its 10th-generation XPS 13, including a new maximum of 32GB RAM and a redesigned "InfinityEdge" display that adds even more screen real estate, resulting in an adjusted 16:10 aspect ratio to match... Details on fingerprint-reader support are still a bit vague, but Dell says it will be released shortly after the system's February 2020 launch as an OTA (over-the-air) update, and then as part of the preloaded Ubuntu Developer Edition image it ships with the system.
Dell's lead on Project Sputnik developer systems, Barton George, also blogged about Dell's new 86-inch 4K interactive touch monitor, as well as their upcoming Latitude 9510 notebook and 2-in-1 laptops, promising "a new ultra-premium class of products" offering 5G mobile broadband capabilities, AI-based productivity capabilities, and 30-plus hours of battery life.

The blog post ends by noting that "While project Sputnik is the most visible Linux-based offerings from Dell, it is only a small fraction of the over 150 systems that make up Dell's Linux portfolio."

Phoronix reports that on New Year's Day, the Linux kernel's Git source tree showed 27,852,148 lines of code, divided among 66,492 files (including docs, Kconfig files, user-space utilities in-tree, etc).

Over its lifetime there's been 887,925 commits, and around 21,074 different authors: During 2019, the Linux kernel saw 74,754 commits, which is actually the lowest point since 2013. The 74k commits is compares to 80k commits seen in both 2017 and 2018, 77k commits in 2016, and 75k commits in both 2014 and 2015. Besides the commit count being lower, the author count for the year is also lower. 2019 saw around 4,189 different authors to the Linux kernel, which is lower than the 4,362 in 2018 and 4,402 in 2017.

While the commit count is lower for the year, on a line count it's about average with 3,386,347 lines of new code added and 1,696,620 lines removed...

Intel and Red Hat have remained the top companies contributing to the upstream Linux kernel.

Many users have taken to the Lutris Forums to report that EA is permanently banning Linux players on Battlefield V. "Good friends, finally after some time without being able to play Battlefield V for Linux, this week I was using lutris-4.21, I was having fun when my anti-cheat, FairFight, blew me out of the game, so I was banned," writes one user. "As I was not using any cheating, I think the anti-cheat considered dxvk or the table layer that used at the time as cheating..." Another user said the "same problem" happened to them, and they "got banned on tuesday for cheating."

While some users await a response from EA, others have received an email confirming the action that was taken on their account. "... After thoroughly investigating your account and concern, we found that your account was actioned correctly and will not remove this sanction from your account," the email states.

We've seen this happen on multiple occasions with Blizzard, but they eventually fixed the problem the first time. In a comment on Hacker News, user jchw writes: "Anti-cheat software is an absolute shit show of cat-and-mouse tactics. It's often difficult to distinguish anti-cheat software from rootkits or spyware. They're invasive and user hostile, and they frequently cause collateral damage that is swept under the rug and that support tacitly refuses to acknowledge..."

Slashdot reader DevNull127 writes: CNBC Explores released a 14-minute documentary this month called "The Rise Of Open-Source Software." It's already racked up 558,802 views on YouTube, arguing that open-source software "has essentially taken over the world. Companies in every industry, from Walmart to Exxon Mobile to Verizon, have open-sourced their projects. Microsoft has completely changed its point of view, and is now seen as a leader in the space. And in 2016 the U.S. government even promised to open-source at least 20% of all its new custom-developed code."

The documentary does mention the 1990s, when Microsoft "even went so far as to call Open Source 'Unamerican' and bad for intellectual property rights." But two and a half minutes in, they also tell the famous story of that 1970s printer jam at MIT which led to the purchase of a proprietary printer that inspired Richard Stallman to quit his job to develop the GNU operating system and spearhead the free software movement. And at three and a half minutes in, they also describe how Linus Torvalds "unceremoniously released" Linux in 1991, and report that "By the turn of the century, NASA, Dell, and IBM were all using it." And at 4:18, they mention "other open source projects" gaining popularity, including MySQL, Perl, and Apache.

"But for the layperson at the turn of the century, the rise of these technologies could have gone unnoticed. After all, hardly anyone ran Linux on their personal computers. But then in 2008, Google released Android devices, which ran on a modified version of Linux. Suddenly the operating system blew up the smartphone market..." (Chen Goldberg, Google's Director of Engineering, cites 2.5 billion active Android devices.) The documentary then traces the open source movement up through our current decade, even mentioning Microsoft's acquisition of GitHub, IBM's acquisition of Red Hat, and various monetization models (including GitHub's new "Sponsors" program). And it ends with the narrator calling open source development "the new norm..."

"After all, the success of Open Source reveals that collaboration and knowledge-sharing are more than just feel-good buzzwords. They're an effective business strategy. And if we're going to solve some of the world's biggest problems, many believe that we can't afford to hoard our resources and learnings."
Here's a list (in order of appearance) of the people interviewed:

• Nat Friedman, CEO of GitHub
• Devon Zuegel, Open-Source Product Manager, GitHub
• Chris Wright, CTO of Red Hat
• Jim Zemlin, Executive Director of the Linux Foundation
• Feross Aboukhadijeh, Open-Source Maintainer
• Chen Goldberg, Google's Director of Engineering

Jim Zemlin, Executive Director of the Linux Foundation, even tells CNBC that 10,000 lines of code are added to Linux every day. "It is by far the highest-velocity, the most effective software development process in the history of computing... As the idea of sharing technology and collaborating collectively expands, we're moving into open hardware initiatives, data-sharing initiatives. And that's really going to be the future...

"The complexity of building these technologies isn't going down, it's only going up. We can get that technology out there faster when everybody works together."

Long-time Slashdot reader twocows writes: Hyperbola GNU/Linux, a FSF-approved distribution of GNU/Linux, has declared their intent to fork OpenBSD and become HyperbolaBSD..."
The news came earlier this week in a roadmap announcement promising "a completely new OS derived from several BSD implementations" (though Hyperbola was originally based on Arch snapshots and Debian development).

"This was not an easy decision to make, but we wish to use our time and resources to create a viable alternative to the current operating system trends which are actively seeking to undermine user choice and freedom." In 2017 Hyperbola dropped its support for systemd -- but its concerns go far beyond that: This will not be a "distro", but a hard fork of the OpenBSD kernel and userspace including new code written under GPLv3 and LGPLv3 to replace GPL-incompatible parts and non-free ones.

Reasons for this include:

- Linux kernel forcing adaption of DRM, including HDCP.

- Linux kernel proposed usage of Rust (which contains freedom flaws and a centralized code repository that is more prone to cyber attack and generally requires internet access to use.)

- Linux kernel being written without security and in mind. (KSPP is basically a dead project and Grsec is no longer free software)

- Many GNU userspace and core utils are all forcing adaption of features without build time options to disable them. E.g. (PulseAudio / SystemD / Rust / Java as forced dependencies....)

HyperbolaBSD is intended to be modular and minimalist so other projects will be able to re-use the code under free license.

DevNull127 writes: The Debian Project has announced the results of its vote on how much to support non-systemd init systems. The eight options voted on included "Focus on systemd" and "Support for multiple init systems is required" (as well as milder choices like "Support for multiple init systems is Important" and "Support non-systemd systems, without blocking progress.") The winning option?

"Systemd but we support exploring alternatives."

Here's the position for the Debian project described by that option:

The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features.

Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner.

Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.

Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative.

From a report: Calculate Linux 20, a Gentoo-based operating system, is ready to be installed on your computer. Calculate Linux 20 is based on Gentoo 17.1 and comes with several desktop environment choices, such as Cinnamon, KDE, Xfce, MATE, and more. Unfortunately for some users, the operating system is now 64-bit only. Yes, with version 20, the developers have chosen to kill the 32-bit variants. While some people will be upset, it is definitely the correct choice -- 32-bit only processors are very old at this point. You can likely get a better 64-bit machine for a steal at a thrift store these days.

Computer engineer George Hilliard says he has built an electronic business card running Linux. From his blog post: It is a complete, minimal ARM computer running my customized Linux firmware built with Buildroot. It has a USB port in the corner. If you plug it into a computer, it boots in about 6 seconds and shows up over USB as a flash drive and a virtual serial port that you can use to log into the card's shell. The flash drive has a README file, a copy of my resume, and some of my photography. The shell has several games and Unix classics such as fortune and rogue, a small 2048, and a small MicroPython interpreter.

All this is accomplished on a very small 8MB flash chip. The bootloader fits in 256KB, the kernel is 1.6MB, and the whole root filesystem is 2.4MB. So, there's plenty of space for the virtual flash drive. It also includes a writable home directory, on the off chance that anyone creates something they want to keep. This is also saved on the flash chip, which is properly wear leveled with UBI. The whole thing costs under $3. It's cheap enough to give away. If you get one from me, I'm probably trying to impress you. In a detailed write-up, Hilliard goes on to explain how he came up with the design and assembled all the components. Naturally, there were some problems that arose during the construction that he had to troubleshoot: "first, the USB port wasn't long enough to reliably make contact in many USB ports. Less critically, the flash footprint was wrong, which I worked around by bending the leads under the part by hand..."

Impressively, the total cost of the card (not including his time) was $2.88 -- "cheap enough that I don't feel bad giving it away, as designed!"

b-dayyy shared this article from Linux Security: The United States government's respect for and acceptance of open-source development has steadily grown stronger over the past decade, and the U.S. government is increasingly using open-source software as a way to roll out advanced, highly secure technology in an economical manner. On August 8, 2016, the White House CIO released a Federal Source Code Policy that calls for new software to be built, shared, and adapted using open-source methods to capitalize on code that is "secure, reliable, and effective in furthering our national objectives."

The United States Department of Defense recognizes the key benefits associated with open-source development and trusts Linux as its operating system. In fact, the U.S. Army is the single largest installed base for Red Hat Linux and the U.S. Navy nuclear submarine fleet runs on Linux, including their sonar systems. Moreover, the Department of Defense just recently enlisted Red Hat, Inc., the world's largest provider of open-source solutions, to help improve squadron operations and flight training.
In a comment on the original submission, long-time Slashdot reader bobs666 remembers setting up Minix 30 years ago "for running email for a part of the U.S. Army. It's too bad the stupid people made me stop working on the project."

But the world may be changing. The article notes that Linux has now already been certified to meet the three different security certifications required by the United States Department of Defense.

An anonymous reader writes: Microsoft today launched Microsoft Teams for Linux in public preview. No, that's not a typo -- Microsoft Teams is indeed the first Office app that the company has ported to Linux. You can download Microsoft Teams as a native Linux package in .deb and .rpm formats from here.

WireGuard has now been committed to the mainline Linux kernel. "While there are still tests to be made and hoops to be jumped through, it should be released in the next major Linux kernel release, 5.6, in the first or second quarter of 2020," reports ZDNet. From the report: WireGuard has been in development for some time. It is a layer 3 secure VPN. Unlike its older rivals, which it's meant to replace, its code is much cleaner and simple. The result is a fast, easy-to-deploy VPN. While it started as a Linux project, WireGuard code is now cross-platform, and its code is now available on Windows, macOS, BSD, iOS, and Android. It took longer to arrive than many wished because WireGuard's principal designer, Jason Donenfeld, disliked Linux's built-in cryptographic subsystem on the grounds its application programming interface (API) was too complex and difficult. He suggested it be supplemented with a new cryptographic subsystem: His own Zinc library. Many developers didn't like this. They saw this as wasting time reinventing the cryptographic well.

But Donenfeld had an important ally. Torvalds wrote, "I'm 1000% with Jason on this. The crypto/ model is hard to use, inefficient, and completely pointless when you know what your cipher or hash algorithm is, and your CPU just does it well directly." In the end, Donenfeld compromised. "WireGuard will get ported to the existing crypto API. So it's probably better that we just fully embrace it, and afterward work evolutionarily to get Zinc into Linux piecemeal." That's exactly what happened. Some Zine elements have been imported into the legacy crypto code in the forthcoming Linux 5.5 kernel. This laid the foundation for WireGuard to finally ship in Linux early next year.

"It's been five years already since the vote to transition to systemd in Debian over Upstart," reports Phoronix, noting that the Debian developer community has now begun a 20-day ranked-choice vote on eight different proposals for "'init system diversity' and just how much Debian developers care (or not) in supporting alternatives to systemd."

The eight options they're voting on:

• Choice 1: F: Focus on systemd

• Choice 2: B: Systemd but we support exploring alternatives

• Choice 3: A: Support for multiple init systems is Important

• Choice 4: D: Support non-systemd systems, without blocking progress

• Choice 5: H: Support portability, without blocking progress

• Choice 6: E: Support for multiple init systems is Required

• Choice 7: G: Support portability and multiple implementations

• Choice 8: Further Discussion

There's detailed descriptions of each option on the Debian developers mailing list. "This is a non-secret vote," the post explains. "After the voting period is over the details on who voted what will be published."

"Linux users can now stream shows and movies from the Disney+ streaming service after Disney lowered the level of their DRM requirements," reports Bleeping Computer: When Disney+ was first launched, Linux users who attempted to watch shows and movies were shown an error stating "Something went wrong. Please try again. If the problem persists, visit the Disney+ Help Center (Error Code 83)."

As explained by Hans de Goede, this error was being caused by the Disney+ service using the highest level of security for the Widevine Digital Rights Management (DRM) technology. As some Linux and Android devices did not support this higher DRM security level, they were unable to stream Disney+ shows in their browsers... Yesterday, Twitter users discovered that Disney+ had suddenly started working on Linux browsers after the streaming service tweaked their DRM security levels...

Even with Disney+ lowering the DRM requirements, users must first make sure DRM is enabled in the browser. For example, Disney+ will not work with Firefox unless you enable the "Play DRM-controlled content" setting in the browser.

An anonymous reader writes: Security researchers found a new vulnerability allowing potential attackers to hijack VPN connections on affected *NIX devices and inject arbitrary data payloads into IPv4 and IPv6 TCP streams. They disclosed the security flaw tracked as CVE-2019-14899 to distros and the Linux kernel security team, as well as to others impacted such as Systemd, Google, Apple, OpenVPN, and WireGuard. The vulnerability is known to impact most Linux distributions and Unix-like operating systems including FreeBSD, OpenBSD, macOS, iOS, and Android. A currently incomplete list of vulnerable operating systems and the init systems they came with is available below, with more to be added once they are tested and found to be affected: Ubuntu 19.10 (systemd), Fedora (systemd), Debian 10.2 (systemd), Arch 2019.05 (systemd), Manjaro 18.1.1 (systemd), Devuan (sysV init), MX Linux 19 (Mepis+antiX), Void Linux (runit), Slackware 14.2 (rc.d), Deepin (rc.d), FreeBSD (rc.d), and OpenBSD (rc.d).

This security flaw "allows a network adjacent attacker to determine if another user is connected to a VPN, the virtual IP address they have been assigned by the VPN server, and whether or not there is an active connection to a given website," according to William J. Tolley, Beau Kujath, and Jedidiah R. Crandall, Breakpointing Bad researchers at University of New Mexico. "Additionally, we are able to determine the exact seq and ack numbers by counting encrypted packets and/or examining their size. This allows us to inject data into the TCP stream and hijack connections," the researchers said.