When Dave McKay first used computers, punched paper tape was in vogue, "and he has been programming ever since," according to his biography page at How-To Geek. It adds that "His use of computers pre-dates the birth of the PC and the public release of Unix."

Now long-time Slashdot reader sbinning shares McKay's "short history of UNIX and how Linux got its start," which ultimately asks if commercial Unix was killed by Linux: Unix is still out there, running mission-critical systems that are functioning correctly, and operating stably. That'll continue until the support for the applications, operating systems or hardware platform ceases. If something's genuinely mission-critical and it's working, you leave it working. I suspect someone, somewhere, will always be running a commercial UNIX or Unix-like operating system.

But for new installs? There are enough variations of Linux to make the case to go for a commercial Unix very, very difficult.

Tokolosh writes: On February 13, 2018 the FreeBSD Foundation posted its Code of Conduct. This included a system for reporting offenders, plus a Code of Conduct Committee to review charges and issue sanctions. The resulting story on Slashdot on February 17 triggered 859 comments. Needless to say, it was controversial.

In 2020, a survey indicated that some 35% of the FreeBSD developer community was dissatisfied with their 2018 Code of Conduct, 34% were neutral, and only 30% satisfied. So they set out to adopt a new CoC. A second survey asked which code of conduct should FreeBSD adopt? 4% favored keeping the 2018 code of conduct, 33% favored the Go-derived code of conduct, 63% favored the LLVM-derived code of conduct. The LLVM Project code was thus adopted.

My pragmatic question back in 2018 was, will this CoC lead to a better FreeBSD, more engagement, a larger, more productive community, and more market share for FreeBSD? In other words, does the CoC give FreeBSD an evolutionary advantage? If a different or no CoC had been imposed, would the FreeBSD of today be different? If so, in what way? The answer is not clear, so I am submitting this story to gather input.

A British security researcher has discovered this week that a recent security flaw in the Sudo app also impacts the macOS operating system, and not just Linux and BSD, as initially believed. From a report: The vulnerability, disclosed last week as CVE-2021-3156 (aka Baron Samedit) by security researchers from Qualys, impacts Sudo, an app that allows admins to delegate limited root access to other users. Qualys researchers discovered that they could trigger a "heap overflow" bug in the Sudo app to change the current user's low-privileged access to root-level commands, granting the attacker access to the whole system. The only condition to exploit this bug was that an attacker gain access to a system, which researchers said could be done by either planting malware on a device or brute-forcing a low-privileged service account. In their report last week, Qualys researchers said they only tested the issue on Ubuntu, Debian, and Fedora. They said that are UNIX-like operating systems are also impacted, but most security researchers thought the bug might impact BSD, another major OS that also ships with the Sudo app.

Wine 6.0 has been released today and contains over 8,300 changes, according to its full release notes. Windows Central reports: The new release of version 6.0 has thousands of changes, but Wine's website highlights some of the biggest improvements: Core modules in PE format; Vulkan backend for WineD3D; DirectShow and Media Foundation support; and Text console redesign. The full release notes for Wine 6.0 explain that the core DLLs, which include NTDLL, KERNEL32, GDI32, and USER32 are now built in the Portable Executable (PE) format. As a result, people should see improvements for certain copy protection schemes.

The update also includes a new mechanism to associate a Unix library with the PE module. This change makes it so systems can call Unix libraries from PE when trying to perform a function that can't be handled by Win32 APIs. Wine 6.0 also includes an experimental Vulkan rendered that translates Direct3D shaders to SPIR-V shaders. In another change related to Direct3D, the Direct3D graphics card database now recognizes more graphics cards and includes updated driver versions.

Long-time programmer/researcher/former MIT research fellow Jonathan Edwards writes a blog called "Alarming Development: Dispatches from the User Liberation Front."

He began the new year by arguing that software "is eating the world. But progress in software technology itself largely stalled around 1996." Slashdot reader tonique summarizes Edwards' argument: In 1996 there were "LISP, Algol, Basic, APL, Unix, C, Oracle, Smalltalk, Windows, C++, LabView, HyperCard, Mathematica, Haskell, WWW, Python, Mosaic, Java, JavaScript, Ruby, Flash, Postgress [sic]". After that we're supposed to have achieved "IntelliJ, Eclipse, ASP, Spring, Rails, Scala, AWS, Clojure, Heroku, V8, Go, React, Docker, Kubernetes, Wasm".

Edwards's main thesis is that the Internet boom around 1996 caused this slowdown because programmers could get rich quick. Then smart and ambitious people moved into Silicon Valley, and founded startups. But you can't do research at a startup due to time and money constraints. Today only "megacorps" like Google, Facebook, Apple and Microsoft are supposedly able to do relevant research because of their vast resources.

Computer science wouldn't help, either, because "most of our software technology was built in companies" and because computer science "strongly disincentivizes risky long-range research". Further, according to Edwards, the aversion to risk and "hyper-professionalization of Computer Science" is part of a larger and worrisome trend throughout the whole field and all of western civilisation.
Edwards' blog post argues that since 1996 "almost everything has been cleverly repackaging and re-engineering prior inventions. Or adding leaky layers to partially paper over problems below. Nothing is obsoleted, and the teetering stack grows ever higher..."

"[M]aybe I'm imagining things. Maybe the reason progress stopped in 1996 is that we invented everything. Maybe there are no more radical breakthroughs possible, and all that's left is to tinker around the edges. This is as good as it gets: a 50 year old OS, 30 year old text editors, and 25 year old languages.

"Bullshit. No technology has ever been permanent. We've just lost the will to improve."

"POSIX has been the standard file system interface for Unix-based systems (which includes Linux) since its launch more than 30 years ago," writes Enterprise Storage Forum, noting the POSIX-compliant Lustre file system "powers most supercomputers."

Now Slashdot reader storagedude writes: POSIX has scalability and performance limitations that will become increasingly important in data-intensive applications like deep learning, but until now it has retained one key advantage over the infinitely scalable object storage: the ability to process data in memory. That advantage is now gone with the new mmap_obj() function, which paves the way for object storage to become the preferred approach to Big Data applications.
POSIX features like statefulness, prescriptive metadata, and strong consistency "become a performance bottleneck as I/O requests multiply and data scale..." claims the article.

"The mmap_obj() developers note that one piece of work still needs to be done: there needs to be a munmap_obj() function to release data from the user space, similar to the POSIX function."

"Steve Jobs is now known for revolutionizing just about every part of the tech world, but back in 1988, he was perhaps best known for getting fired," remembers SFGate: In his first product reveal since his dismissal from Apple in 1985, Jobs unveiled a new project called NeXT at a meeting of the Boston Computer Society. An audio recording of the event was unearthed and released as part of a trove of early tech recordings released by Charles Mann, as reported in an extensive feature by Fast Company...

Computing advances included a UNIX operating system that allows multi-tasking, a one million pixel display, CD quality sound and a then unprecedented 256 MB of storage. The computer would be completely built by robots rather than a human assembly line, which he said resulted in a defect rate 10 times lower than its competitors. The partnership with academia makes even more sense once you consider the price-tag of $6,500.
Fast Company's tech editor Harry McCracken was at the 1988 event, and quotes Jobs as saying "The Macintosh architecture is going to peak next year sometime. And that means that there's enough cracks in the wall already, and enough limitations to the architecture, that the Mac's pretty much going to be everything it's ever going to be sometime next year."

Some clips are available on Soundcloud, but the full trove of tech recordings includes 200 full hours of audio and 16 more of video (available on a USB drive for $59.95) showing luminaries from the early days of personal technology. "In 1985, for instance, a month after Commodore announced its groundbreaking Amiga computer in New York City, president Tom Rattigan came to Boston to show it to BCS members and argue that it left the Mac in the dust." Other recordings include Dan Bricklin, co-creator of VisiCalc, Osborne computer designer Adam Osborne, and investor Esther Dyson, McCracken writes:

Jobs is on three recordings — one from his first Apple tenure, and two from NeXT. Bill Gates is on five. There are folks who were already legends (mobile-computing visionary Alan Kay, marketer extraordinaire Regis McKenna) and up-and-comers (budding PC tycoon Michael Dell, age 23). Everyone from Sony cofounder Akio Morita to psychedelics advocate and part-time technologist Timothy Leary is represented; just the Apple-related material, including CEO John Sculley talking about the company in the 21st century and Hypercard creator Bill Atkinson demoing his brainchild, is a feast...

The audio of Jobs's NeXT demo at the BCS — and dozens of other recordings — exist solely because Mann realized more than 35 years ago that the talks going on at computer user-group meetings and conferences were history in the making... In May 1982, the BCS hosted Applefest, an Apple II-centric fair that featured already-iconic Apple cofounders Jobs and Wozniak as keynote speakers. In this excerpt, fielding a question from the audience, they talk about software copy protection. Woz does so from a technical bent; Jobs, who speaks of a future involving low prices and convenient electronic distribution, sounds like he was thinking about the App Store decades before it appeared. This is rare, rare stuff; if you know of even one other example of surviving audio or video of Jobs and Wozniak talking about Apple together, I'd love to hear about it.

This week brings a special event honoring the IBM Z line of mainframes, writes long-time Slashdot reader theodp: As part of this week's IBM Z Day event, looking-for-young-blood IBM is teaming up with tech-backed K-12 CS nonprofits Code.org and CSforALL and calling on students 14-and-up to Master The Mainframe during the 24-hour code-a-thon to open doors to new opportunities with Fortune 500 companies.

"The rewards for participants are substantial," explains Big Blue. "For every student who finishes Level 1, IBM will donate to the UN World Food Programme #ShareTheMeal... In celebration of IBM Z day, we will double the donation for all students that complete Master the Mainframe Level 1 between Sept 15 — 30 2020. Just 1 hour of your time will feed 4 children for a day." "Through three interactive Levels, you will access a mainframe and get skilled up on the foundations of Mainframe," according to IBM's announcement at MasterTheMainframe.com, "including JCL, Ansible, Python, Unix, COBOL, REXX, all through VS Code. Round it all out with a grand challenge where you craft your own fully-equipped Mainframe creation."

"One mainframe is equivalent to 1,500 x86 servers," the site notes. It also points out that mainframes handle 30 billion transactions every day, "more than the number of Google searches every day" — including 87% of all credit card transactions, nearly $8 trillion payments a year.

O'Reilly media's Vice President of Content Strategy (also the coauthor of Unix Power Tools) recently explored why several popular programming languages wound up on the "most dreaded" list in StackOverflow's annual developer survey: There's no surprise that VBA is #1 disliked language. I'll admit to complete ignorance on Objective C (#2), which I've never had any reason to play with. Although I'm a Perl-hater from way back, I'm surprised that Perl is so widely disliked (#3), but some wounds never heal. It will be interesting to see what happens after Perl 7 has been out for a few years. Assembly (#4) is an acquired taste (and isn't a single language)...
But he eventually suggests that both C and Java might be on the list simply because they have millions of users, citing a quote from C++ creator Bjarne Stroustrup: "there are only two kinds of languages: the ones people complain about and the ones nobody uses." Dislike of a language may be "guilt by association": dislike of a large, antiquated codebase with minimal documentation, and an architectural style in which every bug fixed breaks something else. Therefore, it's not surprising to see languages that used to be widely used but have fallen from popularity on the list... Java has been the language people love to hate since its birth. I was at the USENIX session in which James Gosling first spoke about Java (way before 1.0), and people left the room talking about how horrible Java was — none of whom had actually used the language because it hadn't been released yet...

If there's one language on this list that's associated with gigantic projects, it's Java. And there are a lot of things to dislike about it — though a lot of them have to do with bad habits that grew up around Java, rather than the language itself. If you find yourself abusing design patterns, step back and look at what you're doing; making everything into a design pattern is a sign that you didn't understand what patterns are really for... If you start writing a FactoryFactoryFactory, stop and take a nice long walk. If you're writing a ClassWithAReallyLongNameBecauseThatsHowWeDoIt, you don't need to. Java doesn't make you do that... I've found Java easier to read and understand than most other languages, in part because it's so explicit — and most good programmers realize that they spend more time reading others' code than writing their own.
He also notes that Python only rose to #23 on the "most dreaded" languages list, speculating developers may appreciation its lack of curly braces, good libraries, and Jupyter notebooks. "Python wins the award for the most popular language to inspire minimal dislike. It's got a balanced set of features that make it ideal for small projects, and good for large ones."

"And what shall we say about JavaScript, sixteenth on the list? I've got nothing. It's a language that grew in a random and disordered way, and that programmers eventually learned could be powerful and productive... A language that's as widely used as JavaScript, and that's only 16th on the list of most dreaded languages, is certainly doing something right. But I don't have to like it."

The U.S. National Security Agency on Thursday warned government partners and private companies about a Russian hacking operation that uses a special intrusion technique to target operating systems often used by industrial firms to manage computer infrastructure. Reuters reports: "This is a vulnerability that is being actively exploited, that's why we're bringing this notification out," said Doug Cress, chief of the cybersecurity collaboration center and directorate at NSA. "We really want... the broader cybersecurity community to take this seriously." Cress declined to discuss which business sectors had been most affected, how many organizations were compromised using the Russian technique, or whether the cyber espionage operation targeted a specific geographic region.

The NSA said the hacking activity was tied directly to a specific unit within Russia's Main Intelligence Directorate, also known as the GRU, named the Main Center for Special Technologies. The cybersecurity research community refers to this same hacking group as "Sandworm," and has previously connected it to disruptive cyberattacks against Ukrainian electric production facilities. A security alert published by the NSA on Thursday explains how hackers with GRU, Russia's military intelligence, are leveraging a software vulnerability in Exim, a mail transfer agent common on Unix-based operating systems, such as Linux. The vulnerability was patched last year, but some users have not updated their systems to close the security gap.

Camel Pilot (Slashdot reader #78,781) writes: Leannart Poettering is proposing homed to alter the way Linux systems handle user management. All user information will be placed in a cryptographically signed JSON record, such as username, group membership, and password hashes. The venerable /etc/passwd and /etc/shadow will be a thing of the past. One of the claimed advantages will be home directory portability.

"Because the /home directory will no longer depend on the trifecta of systemd, /etc/passwd, and /etc/shadow, users and admins will then be able to easily migrate directories within /home," writes Jack Wallen at TechRepublic. "Imagine being able to move your /home/USER (where USER is your username) directory to a portable flash drive and use it on any system that works with systemd-homed. You could easily transport your /home/USER directory between home and work, or between systems within your company."

What is not clear is that for portability, systems would have to have identical user_id, group names, group_id, etc. And what mechanism is going to provide user authorization to login to a system?
"At the moment, systemd 245 is still in RC2 status," the article notes, adding "The good news, however, is that systemd 245 should be released sometime this year (2020).

"When that happens, prepare to change the way you manage users and their home directories."

Dan Luu, writing in a blog post: The sleight of hand that's happening when someone says that we can keep software simple and compatible by making everything handle text is the pretense that text data doesn't have a structure that needs to be parsed4. In some cases, we can just think of everything as a single space separated line, or maybe a table with some row and column separators that we specify (with some behavior that isn't consistent across tools, of course). That adds some hassle when it works, and then there are the cases where serializing data to a flat text format adds considerable complexity since the structure of data means that simple flattening requires significant parsing work to re-ingest the data in a meaningful way. Another reason commands now have more options is that people have added convenience flags for functionality that could have been done by cobbling together a series of commands. These go all the way back to v7 unix, where ls has an option to reverse the sort order (which could have been done by passing the output to tac).

[...] Over time, more convenience options have been added. For example, to pick a command that originally has zero options, mv can move and create a backup (three options; two are different ways to specify a backup, one of which takes an argument and the other of which takes zero explicit arguments and reads an implicit argument from the VERSION_CONTROL environment variable; one option allows overriding the default backup suffix). mv now also has options to never overwrite and to only overwrite if the file is newer. mkdir is another program that used to have no options where, excluding security things for SELinux or SMACK as well as help and version options, the added options are convenience flags: setting the permissions of the new directory and making parent directories if they don't exist. If we look at tail, which originally had one option (-number, telling tail where to start), it's added both formatting and convenience options For formatting, it has -z, which makes the line delimiter null instead of a newline. Some examples of convenience options are -f to print when there are new changes, -s to set the sleep interval between checking for -f changes, --retry to retry if the file isn't accessible.

January 19, 2038 is for Linux what Y2K was for mainframe and PC computers in 2000, reports ZDNet. It's the day that the value for time "runs out of numbers" and, in the case of 32-bit Unix-based operating systems like Linux and older versions of macOS, "starts counting time with negative numbers..."

"But the fixes are underway to make sure all goes well when that fatal time rolls around." nickwinlund77 shared their report: Linux developers have seen this coming for decades. So, Linux kernel developer Arnd Bergmann and others have been working on a repair. These corrections are now in the forthcoming Linux 5.6 kernel. Bergmann explained, "Linux-5.6, or my backport of the patches to 5.4, should be the first release that can serve as a base for a 32-bit system designed to run beyond year 2038."

There are some caveats:

- All user space must be compiled with a 64-bit time_t, which will be supported in the coming musl-1.2 and glibc-2.32 releases, along with installed kernel headers from Linux-5.6 or higher.

- Applications that use the system call interfaces directly need to be ported to use the time64 syscalls added in Linux-5.1 in place of the existing system calls.

- Applications that use a private copy of kernel uapi header files or their contents may need to update to the Linux-5.6 version.

- A few remaining interfaces cannot be changed to pass a 64-bit time_t in a compatible way, so they must be configured to use CLOCK_MONOTONIC times...

After we fix this, we won't have to worry about 64-bit Linux running out of seconds until 15:30:08 GMT Sunday, December 4, 29,227,702,659. Personally, I'm not going to worry about that one.

"Under the age of 39? Odds are that most of your peers learned to code in C.

"Most Baby Boomers and Gen Xers — or, those between the ages of 40 and 74 in 2020 — learned to code in BASIC."

That's just one of the interesting conclusions from HackerRank's third annual "Developer Skills Report," which this year compiled responses from over 116,000 developers (from 162 different countries). Developed for educational use in 1964, BASIC was a popular instructional language in college classrooms. But that began to change in 1972, when Bell Labs invented C, allowing portability of the Unix operating system. Though it wasn't an instant hit, the language rose to popularity in the late 70s and early 80s alongside the growth of Unix. Today, the language is celebrated for its longevity, flexibility, and ease of use — just some of the reasons it's still popular for Gen Zers learning to code today.

Gen Z is more likely than any previous generation to utilize bootcamps. Nearly one in six say they've leveraged bootcamps to learn new skills. On the flip side, they're less likely to learn coding skills from older generations' go-tos, like books and on-the-job training. As Gen Z comes to rely more heavily on non-traditional education sources like bootcamps, they're poised to become a key talent pool.
Jaxenter also summarizes another interesting finding from the survey. "72% of hiring managers reported that bootcamp grads were equally or better equipped for their job." The I-Programmer site even noted the top reasons managers gave the surveyors for why bootcamp grads exceed:

• Ability to learn new technologies & languages quickly (71%)
• Strong practical experience (61%)
• Eager to take on new responsibilities (52%)

And they also summarize another interesting result. "Almost a third of developers at small companies (1-49 employees) haven't obtained a Bachelor's degree -- a proportion that drops to only 9% in companies with 10,000 or more employees."

An anonymous reader quotes a report from Ars Technica: Sudo, a utility found in dozens of Unix-like operating systems, has received a patch for a potentially serious bug that allows unprivileged users to easily obtain unfettered root privileges on vulnerable systems. The vulnerability, tracked as CVE-2019-18634, is the result of a stack-based buffer-overflow bug found in versions 1.7.1 through 1.8.25p1. It can be triggered only when either an administrator or a downstream OS, such as Linux Mint and Elementary OS, has enabled an option known as pwfeedback. With pwfeedback turned on, the vulnerability can be exploited even by users who aren't listed in sudoers, a file that contains rules that users must follow when using the sudo command.

"Exploiting the bug does not require sudo permissions, merely that pwfeedback be enabled," an advisory published by sudo developers said. "The bug can be reproduced by passing a large input to sudo via a pipe when it prompts for a password." The advisory lists two flaws that lead to the vulnerability. The first: pwfeedback isn't ignored as it should be when reading from something other than a terminal. As a result, the saved version of a line erase character remains at its initialized value of 0. The second contributor is that the code that erases the line of asterisks doesn't properly reset the buffer position if there is an error writing data. Instead, the code resets only the remaining buffer length. As a result, input can write past the end of the buffers. Systems with unidirectional pipe allow an attempt to write to the read end of the pipe to result in a write error. Because the remaining buffer length isn't reset correctly when write errors result from line erasures, the stack buffer can be overflowed. The report notes the vulnerability was introduced in 2009 and remained active until 2018, with the release of 1.8.26b1. "Systems or software using a vulnerable version should move to version 1.8.31 as soon as practical," reports Ars. "Those who can't update right away can prevent exploits by making sure pwfeedback is disabled."

Former Slashdot contributor Nick Kolakowski is now a senior editor at Dice Insights, where he's just published a list of the top programming skills employers were looking for during the last 30 days.
If you're a software developer on the hunt for a new gig (or you're merely curious about what programming skills employers are looking for these days), one thing is clear: employers really, really, really want technologists who know how to build, maintain, and scale everything database- (and data-) related.

We've come to that conclusion after analyzing data about programming skills from Burning Glass, which collects and organizes millions of job postings from across the country.
The biggest takeaway? "When it comes to programming skills, employers are hungriest for SQL." Here's their ranking of the top most in-demand skills:

1. SQL
2. Java
3. "Software development"
4. "Software engineering"
5. Python
6. JavaScript
7. Linux
8. Oracle
9. C#
10. Git

The list actually includes the top 18 programming skills, but besides languages like C++ and .NET, it also includes more generalized skills like "Agile development," "debugging," and "Unix."

But Nick concludes that "As a developer, if you've mastered database and data-analytics skills, that makes you insanely valuable to a whole range of companies out there."

Slashdot reader The8re still remembers the Y2K bug. Now he shares a New Scientist article explaining how it led directly to this year's Y2020 bug -- which affected more than just parking meters: WWE 2K20, a professional wrestling video game, also stopped working at midnight on 1 January 2020. Within 24 hours, the game's developers, 2K, issued a downloadable fix. Another piece of software, Splunk, which ironically looks for errors in computer systems, was found to be vulnerable to the Y2020 bug in November. The company rolled out a fix to users the same week -- which include 92 of the Fortune 100, the top 100 companies in the US....

The Y2020 bug, which has taken many payment and computer systems offline, is a long-lingering side effect of attempts to fix the Y2K, or millennium bug. Both stem from the way computers store dates. Many older systems express years using two numbers -- 98, for instance, for 1998 -- in an effort to save memory. The Y2K bug was a fear that computers would treat 00 as 1900, rather than 2000. Programmers wanting to avoid the Y2K bug had two broad options: entirely rewrite their code, or adopt a quick fix called "windowing", which would treat all dates from 00 to 20, as from the 2000s, rather than the 1900s. An estimated 80 percent of computers fixed in 1999 used the quicker, cheaper option. "Windowing, even during Y2K, was the worst of all possible solutions because it kicked the problem down the road," says Dylan Mulvin at the London School of Economics....

Another date storage problem also faces us in the year 2038. The issue again stems from Unix's epoch time: the data is stored as a 32-bit integer, which will run out of capacity at 3.14 am on 19 January 2038.

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!"

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.

During his Open Source Summit Europe keynote speech, Greg Kroah-Hartman, the stable Linux kernel maintainer, said Intel CPU's security problems "are going to be with us for a very long time" and are "not going away." He added: "They're all CPU bugs, in some ways they're all the same problem," but each has to be solved in its own way. "MDS, RDDL, Fallout, Zombieland: They're all variants of the same basic problem." ZDNet reports: And they're all potentially deadly for your security: "RIDL and Zombieload, for example, can steal data across applications, virtual machines, even secure enclaves. The last is really funny, because [Intel Software Guard Extensions (SGX)] is what supposed to be secure inside Intel ships" [but, it turns out it's] really porous. You can see right through this thing." To fix each problem as it pops up, you must patch both your Linux kernel and your CPU's BIOS and microcode. This is not a Linux problem; any operating system faces the same problem.

OpenBSD, a BSD Unix devoted to security first and foremost, Kroah-Hartman freely admits was the first to come up with what's currently the best answer for this class of security holes: Turn Intel's simultaneous multithreading (SMT) off and deal with the performance hit. Linux has adopted this method. But it's not enough. You must secure the operating system as each new way to exploit hyper-threading appears. For Linux, that means flushing the CPU buffers every time there's a context switch (e.g. when the CPU stops running one VM and starts another). You can probably guess what the trouble is. Each buffer flush takes a lot of time, and the more VMs, containers, whatever, you're running, the more time you lose. "The bad part of this is that you now must choose: Performance or security. And that is not a good option," Kroah-Hartman said. He added: "If you are not using a supported Linux distribution kernel or a stable/long term kernel, you have an insecure system."