Dirk Hohndel gets frequently mentioned on Slashdot. He was a very early contributor to Linux (and for the last five years the chief open source officer and vice president at VMware). But he's also the guy who interviews Linus Torvalds in the keynote sessions of Open Source Summits.

Hohndel "has a well known track record with Linux going back to the 1990's," reports Phoronix, and was even a member of the Linux Foundation Board of Directors.

But they add that now Hohndel has "somewhat surprisingly has moved on to promoting a blockchain effort."

Dirk Hohndel was CTO at SUSE going back to the mid-90's before joining Intel for a fifteen year run that ended in 2016 where he was Intel's Chief Linux and Open-Source Technologist...

When Dirk left VMware unexpectedly at the beginning of the year, he wrote on LinkedIn that he felt he completed his job at the company in driving open-source transformation. He was leaving to go "look for the next opportunity, the next step in my career" and now it apparently is with blockchain. The surprising news today is that he's joined the Cardano Foundation. The Cardano Foundation is a Swiss-based foundation built around the Cardano public blockchain platform. Cardano is open-source and is the most notable proof-of-stake blockchain that was started by Ethereum co-founder Charles Hoskinson. Cardano has its own cryptocurrency, ADA....

Dirk will be serving as the Cardano Foundation's Chief Open-Source Officer.
Interestingly, Linus Torvalds appears to be less enthralled with blockchain technologies. Last year ZDNet reported on the reaction when Linux Foundation executive director Jim Zemlin suggested Torvalds sell an NFT of the 1991 email that first announced Linux to the world.

"An amused and appalled Torvalds replied, "I'm staying out of the whole craziness with crypto and NFTs. Those people are cuckoo!"

A headline at Hot Hardware calls it "a sexy Linux laptop with deep learning chops... being pitched as the world's most powerful laptop for machine learning workloads."

And here's how Ars Technica describes the Razer x Lambda Tensorbook (announced Tuesday): Made in collaboration with Lambda, the Linux-based clamshell focuses on deep-learning development. Lambda, which has been around since 2012, is a deep-learning infrastructure provider used by the US Department of Defense and "97 percent of the top research universities in the US," according to the company's announcement. Lambda's offerings include GPU clusters, servers, workstations, and cloud instances that train neural networks for various use cases, including self-driving cars, cancer detection, and drug discovery.

Dubbed "The Deep Learning Laptop," the Tensorbook has an Nvidia RTX 3080 Max-Q (16GB) and targets machine-learning engineers, especially those who lack a laptop with a discrete GPU and thus have to share a remote machine's resources, which negatively affects development.... "When you're stuck SSHing into a remote server, you don't have any of your local data or code and even have a hard time demoing your model to colleagues," Lambda co-founder and CEO Stephen Balaban said in a statement, noting that the laptop comes with PyTorch and TensorFlow for quickly training and demoing models from a local GUI interface without SSH. Lambda isn't a laptop maker, so it recruited Razer to build the machine....

While there are more powerful laptops available, the Tensorbook stands out because of its software package and Ubuntu Linux 20.04 LTS.
The Verge writes: While Razer currently offers faster CPU, GPU and screens in today's Blade lineup, it's not necessarily a bad deal if you love the design, considering how pricey Razer's laptops can be. But we've generally found that Razer's thin machines run quite hot in our reviews, and the Blade in question was no exception even with a quarter of the memory and a less powerful RTX 3060 GPU. Lambda's FAQ page does not address heat as of today.

Lambda is clearly aiming this one at prospective MacBook Pro buyers, and I don't just say that because of the silver tones. The primary hardware comparison the company touts is a 4x speedup over Apple's M1 Max in a 16-inch MacBook Pro when running TensorFlow.
Specifically, Lambda's web site claims the new laptop "delivers model training performance up to 4x faster than Apple's M1 Max, and up to 10x faster than Google Colab instances." And it credits this to the laptop's use of NVIDIA's GeForce RTX 3080 Max-Q 16GB GPU, adding that NVIDIA GPUs "are the industry standard for parallel processing, ensuring leading performance and compatibility with all machine learning frameworks and tools."

"It looks like a fine package and machine, but pricing starts at $3,499," notes Hot Hardware, adding "There's a $500 up-charge to have it configured to dual-boot Windows 10."

The Verge speculates on what this might portend for the future. "Perhaps the recently renewed interest in Linux gaming, driven by the Steam Deck, will push Razer to consider Linux for its own core products as well."

The Fedora 37 development team is considering dropping support for non-UEFI BIOS. Linuxiac reports: The Unified Extensible Firmware Interface, or UEFI, is a modern method of handling the boot process. UEFI is similar to Legacy; however, the boot data is stored in a .efi file rather than the firmware. In the case of Fedora, while the change may take some time, the new Fedora x86_64 installations will no longer work on non-UEFI platforms. On x86_64 architectures, Fedora 37 will mark legacy BIOS installation as deprecated in favor of UEFI. While systems already using Legacy BIOS to boot will continue to be supported, new Legacy BIOS installations on these architectures will be impossible.

UnknowingFool writes: Google has proposed a change on how Linux kernel handles shutdowns specifically when NVMe drives are used. The issue that Google is finding is that the current NVMe drivers use synchronous APIs when shutting down and it can take 4.5 seconds for each NVMe drive. For a system with 16 NVMe drives that could take more than a minute longer. While this is a problem that only large enterprise systems face currently, more enterprises are replacing their mechanical disk RAID servers with SSD ones.

[...] The proposed patches from Google allow for an optional asynchronous shutdown interface at the bus level. The new interface maintains backwards compatibility with the synchronous implementation. As part of the patches, all PCI Express based devices are moved to use the async interface, implements the changes at the PCIe level, and then the changes to the NVMe driver to exploit the async shutdown interface.

"Rolling Rhino is a tool long ago created by Martin Wimpress, who until recently was part of the Canonical team," one Linux blog pointed out recently. "What it does is basically change the repositories of the DailyLive developers...."

Neowin sees it as a competitive advantage. After more than 17 years, there's a way to get a Ubuntu distro offering the same "rolling" release cycles that helped popularize Arch Linux: While there are many positive qualities that would draw a user into the world of Arch, its headlining feature would be the one that remains the most relevant in today's world of continuous integration and delivery and that's its rolling release strategy. While I don't think Judd Vinet could have predicted the proliferation of DevOps or the massive shift to cloud computing, it must be interesting to see that the entire industry is following the Arch strategy in all sorts of different places. One could even argue that Microsoft Windows has become a rolling release.

While many of Arch's contemporaries have joined the fray, one notable open-source giant has yet to make the leap.

Rolling Rhino looks to change that by converting Ubuntu into a rolling release.
Thanks to Slashdot reader segaboy81 for submitting the story...

An anonymous reader quotes a report from Ars Technica: For months, a small group of volunteers has worked to get this Arch Linux-based distribution up and running on Apple Silicon Macs, adapting existing drivers and (in the case of the GPU) painstakingly writing their own. And that work is paying off -- last week, the team released its first alpha installer to the general public, and as of yesterday, the software supports the new M1 Ultra in the Mac Studio. In the current alpha, an impressive list of hardware already works, including Wi-Fi, USB 2.0 over the Thunderbolt ports (USB 3.0 only works on Macs with USB-A ports, but USB 3.0 over Thunderbolt is "coming soon"), and the built-in display. But there are still big features missing, including DisplayPort and Thunderbolt, the webcam, Bluetooth, sleep mode, and GPU acceleration. That said, regarding GPU acceleration, the developers say that the M1 is fast enough that a software-rendered Linux desktop feels faster on the M1 than a GPU-accelerated desktop feels on many other ARM chips.

Asahi's developers don't think the software will be "done," with all basic M1-series hardware and functionality supported and working out of the box, "for another year, maybe two." By then, Apple will probably have introduced another generation or two of M-series chips. But the developers are optimistic that much of the work they're doing now will continue to work on future generations of Apple hardware with relatively minimal effort. [...] If you want to try Asahi Linux on an M1 Mac, the current installer is run from the command line and requires "at least 53GB of free space" for an install with a KDE Plasma desktop. Asahi only needs about 15GB, but the installer requires you to leave at least 38GB of free space to the macOS install so that macOS system updates don't break. From there, dual-booting should work similarly to the process on Intel Macs, with the alternate OS visible from within Startup Disk or the boot picker you can launch when your start your Mac. Future updates should be installable from within your new Asahi Linux installation and shouldn't require you to reinstall from scratch.

Slashdot reader mmanciop reminded us that Ubuntu released a new version of its "circle of friends" logo this week (which its designer says gives it "a more contemporary look and feel.")

From the Ubuntu blog: We proudly present to you the transformation of the Circle of Friends logo for Ubuntu. The new logo isn't a revolution; rather, it's an evolution of the Circle of Friends. As you can see at the top of the post, the classic white-on-orange colour scheme hasn't changed. But the new version sports sleek lines which bind the Circle of Friends even more closely together.

While it is important to have a respectful continuity with the previous Circle of Friends, the updated version is leaner, more focused, more sophisticated. It also makes a little more sense that the heads are now inside the circle, facing each other and connecting more directly. The rectangular orange tag is a break from the conventional square or circle, as it allows for the boldness of the orange to express itself and provides a recognisable colourful mark across media. Finally, the logo moves from a tiny superscript to a large, dynamic and leading presence.

Some might wonder why we had to touch the Ubuntu logo at all. As one can imagine, it is a daunting honour to work on something so many of us have such a strong connection to. But in the end, a logo should match what it represents. Similar to how Ubuntu continues to evolve and adapt to new uses in technology, its logo should follow suit to encapsulate and reflect such ongoing change.
For comparison, here's the original logo.

Share your reactions in the comments. (For example, how do you think it compares to other logos?) Do you like it more or less than, say, the logo for Raku?

An anonymous Slashdot reader summarizes some important news from the web page of Jason Donenfeld (creator of the open-source VPN protocol WireGuard): The Linux kernel's random number generator has seen its first set of major improvements in over a decade, improving everything from the cryptography to the interface used. Not only does it finally retire SHA-1 in favor of BLAKE2s [in Linux kernel 5.17], but it also at long last unites '/dev/random' and '/dev/urandom' [in the upcoming Linux kernel 5.18], finally ending years of Slashdot banter and debate:

The most significant outward-facing change is that /dev/random and /dev/urandom are now exactly the same thing, with no differences between them at all, thanks to their unification in random: block in /dev/urandom. This removes a significant age-old crypto footgun, already accomplished by other operating systems eons ago. [...] The upshot is that every Internet message board disagreement on /dev/random versus /dev/urandom has now been resolved by making everybody simultaneously right! Now, for the first time, these are both the right choice to make, in addition to getrandom(0); they all return the same bytes with the same semantics. There are only right choices.
Phoronix adds: One exciting change to also note is the getrandom() system call may be a hell of a lot faster with the new kernel. The getrandom() call for obtaining random bytes is yielding much faster performance with the latest code in development. Intel's kernel test robot is seeing an 8450% improvement with the stress-ng getrandom() benchmark. Yes, an 8450% improvement.

"Asahi Linux aims to bring you a polished Linux experience on Apple Silicon Macs," explains the project's web site.

And now that first Asahi Linux alpha release is out — ready for testing on M1, M1 Pro, and M1 Max machines (except Mac Studio): We're really excited to finally take this step and start bringing Linux on Apple Silicon to everyone. This is only the beginning, and things will move even more quickly going forward!

Keep in mind that this is still a very early, alpha release. It is intended for developers and power users; if you decide to install it, we hope you will be able to help us out by filing detailed bug reports and helping debug issues. That said, we welcome everyone to give it a try — just expect things to be a bit rough.... Asahi Linux is developed by a group of volunteers, and led by marcan as his primary job. You can support him directly via Patreon and GitHub Sponsors....

Can I dual-boot macOS and Linux?

Yes! In fact, we expect you to do that, and the installer doesn't support replacing macOS at this point. This is because we have no mechanism for updating system firmware from Linux yet, and until we do it makes sense to keep a macOS install lying around for that. You can have as many macOS and Linux installs as you want, and they will all play nicely and show up in Apple's boot picker. Each Linux install acts as a self-contained OS and should not interfere with the others.

Note that keeping a macOS install around does mean you lose ~70GB of disk space (in order to allow for updates, since the macOS updater is quite inefficient). In the future we expect to have a mechanism for firmware updates from Linux and better integration, at which point we'll be comfortable recommending Linux-only setups....

Is this just Arch Linux ARM?

Pretty much! Most of our work is in the kernel and a few core support packages, and we rely on Linux's excellent existing ARM64 support. The Asahi Linux reference distro images are based off of Arch Linux ARM and simply add our own package repository, which only adds a few packages. You can freely convert between Arch Linux ARM and Asahi Linux by adding or removing this repository and the relevant packages, although vanilla Arch Linux ARM kernels will not boot on these machines at this time.
The project's home page adds that "All contributors are welcome, of any skill level!"

"Doing this requires a tremendous amount of work, as Apple Silicon is an entirely undocumented platform," the team explains. "In particular, we will be reverse engineering the Apple GPU architecture and developing an open-source driver for it." But they're already documenting the Apple Silicon platform on their GitHub wiki. We will eventually release a remix of Arch Linux ARM, packaged for installation by end-users, as a distribution of the same name. The majority of the work resides in hardware support, drivers, and tools, and it will be upstreamed to the relevant projects....

Apple allows booting unsigned/custom kernels on Apple Silicon Macs without a jailbreak! This isn't a hack or an omission, but an actual feature that Apple built into these devices. That means that, unlike iOS devices, Apple does not intend to lock down what OS you can use on Macs (though they probably won't help with the development). As long as no code is taken from macOS to build the Linux support, the result is completely legal to distribute and for end-users to use, as it would not be a derivative work of macOS.
An interesting observataion from Slashdot reader mrwireless: It once again seems Apple is informally supportive of these efforts, as the recent release of OS Monterey 12.3 makes the process even simpler. As Twitter user Matthew Garrett writes:

"People who hate UEFI should read https://github.com/AsahiLinux/... — Apple made deliberate design choices that allow third party OSes to run on M1 hardware without compromising security, and with much less closed code than on basically any modern x86."

Sophos threat researcher Nick Gregory discovered a hole in Linux's netfilter firewall program that's "exploitable to achieve kernel code execution (via ROP [return-oriented programming]), giving full local privilege escalation, container escape, whatever you want." ZDNet reports: Behind almost all Linux firewalls tools such as iptables; its newer version, nftables; firewalld; and ufw, is netfilter, which controls access to and from Linux's network stack. It's an essential Linux security program, so when a security hole is found in it, it's a big deal. [...] This problem exists because netfilter doesn't handle its hardware offload feature correctly. A local, unprivileged attacker can use this to cause a denial-of-service (DoS), execute arbitrary code, and cause general mayhem. Adding insult to injury, this works even if the hardware being attacked doesn't have offload functionality! That's because, as Gregory wrote to a security list, "Despite being in code dealing with hardware offload, this is reachable when targeting network devices that don't have offload functionality (e.g. lo) as the bug is triggered before the rule creation fails."

This vulnerability is present in the Linux kernel versions 5.4 through 5.6.10. It's listed as Common Vulnerabilities and Exposures (CVE-2022-25636), and with a Common Vulnerability Scoring System (CVSS) score of 7.8), this is a real badie. How bad? In its advisory, Red Hat said, "This flaw allows a local attacker with a user account on the system to gain access to out-of-bounds memory, leading to a system crash or a privilege escalation threat." So, yes, this is bad. Worse still, it affects recent major distribution releases such as Red Hat Enterprise Linux (RHEL) 8.x; Debian Bullseye; Ubuntu Linux, and SUSE Linux Enterprise 15.3. While the Linux kernel netfilter patch has been made, the patch isn't available yet in all distribution releases.

juul_advocate shares a report from iTWire: A developer who had more than two decades of service in the Debian GNU/Linux project was stripped of his status in December leading to him deciding to leave the project. Norbert Preining told iTWire in response to a query he decided that having been graded down to Debian maintainer was not something he wanted after all these years. He has now joined the Arch Linux project.

Preining said what basically happened was that the [Debian account manager (DAM) team] thought he was bullying members of the project. "I guess they are referring to my run-in with Martina Ferrari where she called me out in very strange and unfounded ways, which started a long lasting disagreement between her and me, and the blog post about Lars [Wirzenius, a project member] which was nothing more than a selection of quotes from Lars' own blogs," he added.

"Anyway, these were all old things, but DAM still prefers to paint me in the light of 'You have been bullying members of the project for years' (quote from Enrico Zini on the debian-private mailing list) and that I cannot communicate with the Community Team, which back then included Martina, and which has again hit me in the back by allowing other members in Debian (I refrain from naming them here, but will do in my blog post) to bully me, even in unrelated forums and on IRC. The bottom line is that Martina, Lars, and those others are close friends of DAM and CT [community team] and the 'leading circle' in Debian, and thus it seems that they are exempted from adhering to the same community standards." Preining said the situation that led to his demotion was "more or less" about political correctness, adding that he'll explain more about the events in a blog post later on.

"Arch Linux, the rolling Linux distribution that powers Valve's Steam Deck is now 20 years old," reports Neowin.

Slashdot reader segaboy81 writes that "What's cool to see here is that everything changed behind the scenes, but on the surface, things are the same." From the article: Announced on March 11th, 2002, and codenamed Homer, version 0.1 was released to minor fanfare. The release notes were a far cry from today's, essentially announcing it had broken ground and the foundation was going in, as it were.

Homer's release notes:

I've finally got a bootable iso image on the ftp site. The bad news is that you don't get a pretty interactive installer. But if you wanted one of those, you would have gone with RedHat, right? ;)

I'll try to get the docs up for ABS (Arch Build System) which, IMHO, is one of the best advantages of Arch. With ABS, you can easily create new packages, and it's trivial to rebuild existing packages with your own customizations....

It shipped with Linux kernel 2.4.18 which many of the Linux old-timers (myself included) will remember was right before we started to get nice things like auto-mounting USB drives in kernel 2.6. XFree86 4.2.0 was also in stow, which is what we now call Xorg. If you wanted to build software, you had to use an absolutely ancient gcc toolchain (2.95.3). Web browsing was covered by the ghost of Netscape Navigator, Mozilla 0.9.9. Heady days, these were!

Red Hat, the Raleigh-based open-source software company, said Tuesday it is halting all sales and services to companies in Russia and Belarus -- a response to the Russian invasion of Ukraine that has put Red Hat employees in harm's way. Raleigh News & Observer reports: Paul Cormier, Red Hat's chief executive officer, announced the decision in an email to employees, saying: "As a company, we stand in unity with everyone affected by the violence and condemn the Russian military's invasion of Ukraine." Red Hat's announcement comes a day after its parent company, IBM, which also has a large presence in the Triangle, suspended all business operations in Russia.

"While relevant sanctions must guide many of our actions, we've taken additional measures as a company," Cormier wrote. "Effective immediately, Red Hat is discontinuing sales and services in Russia and Belarus (for both organizations located in or headquartered in Russia or Belarus)." Red Hat said it has approximately two dozen employees in Ukraine, which has become an important tech hub in Eastern Europe in recent years. It is home to tens of thousands of contractors and employees for U.S. firms. In his email, Cormier said that Red Hat has helped dozens of employees and family members in Ukraine relocate to safer locations. Many of them have gone to neighboring Poland, he noted. [...] However, Ukraine has barred men ages 18 to 60 from leaving the country, meaning many of Red Hat's employees can't be relocated from the country. We "continue to help those who remain in the country in any way possible," Cormier wrote.

Cognitive Dissident writes: Ars Technica is reporting a major new vulnerability in Linux. Named "Dirty Pipeline" it involves abuse of 'pipes' at the shell level as you might guess.

An anonymous reader quotes a report from The Verge: When will Bungie let Destiny 2 come to Valve's Steam Deck handheld gaming PC? It's looking like the answer is never -- because the soon-to-be Sony subsidiary has published a help page that not only says the game's unsupported, but outright threatens to ban prospective Steam Deck players (via Wario64). The help page has a new section titled "Steam Deck and Destiny 2," which reads: "Destiny 2 is not supported for play on the Steam Deck or on any system utilizing Steam Play's Proton unless Windows is installed and running. Players who attempt to launch Destiny 2 on the Steam Deck through SteamOS or Proton will be unable to enter the game and will be returned to their game library after a short time. Players who attempt to bypass Destiny 2 incompatibility will be met with a game ban."

To be fair, Bungie isn't the only one to reject the Steam Deck without necessarily providing a satisfying explanation -- Epic Games CEO Tim Sweeney explained to me why Fortnite won't get updated for the Steam Deck last month, even though Epic's own Easy Anti-Cheat (EAC) claims game developers can enable it with "just a few clicks." And while both Apex Legends and Elden Ring now fully work on Deck despite using anti-cheat, it's also true that many other top multiplayer games have yet to fully arrive.

"We all know Linux is written in C," writes ZDNet. "What you may not know is that it's written in a long-outdated C dialect: The 1989 version of the C language standard, C89."

But that's about to change, explains long-time Slashdot reader UnknowingFool: Linus Torvalds has decided that Linux will move to the C11 standard starting with kernel 5.18.... Linux had planned to move to a newer standard eventually with C99 being the next version. However a recent patch to a security problem revealed that there could be problems with C99.

In order to patch a potential security problem with Linux's linked-list primitive speculative-execution functions, it was found that C99 would require the iterator must be declared outside the loop which would expose it to another security problem. Since C99 was not very popular, it was agreed to skip it and use C11. Backwards compatibility with most compilers like gcc should allow for an easily transition of most of the code.
ZDNet adds that "This isn't as big a transition as it may seem. C89 still has almost universal support. Because any C compiler is backward compatible with earlier versions, you won't have any trouble compiling or running a C89 program. So, a C11 compliant compiler won't have any trouble with any C89 legacy code."

Intel has acquired Linutronix, the German-based Linux consulting firm that is focused on embedded Linux and real-time computing. From a report: Intel's acquisition of Linutronix appears to be primarily focused as an acqui-hire with getting Linutronix's very talented staff at Intel. Among the prominent Linutronix engineers is their CTO Thomas Gleixner as a longtime kernel maintainer and important contributor on the x86 side, including with Linux's CPU security mitigations and perhaps most notably for the real-time (PREEMPT_RT) work.

UnknowingFool writes: Linux kernel developers have discussed on the kernel developers forum to remove ReiserFS from the kernel starting in 2022. ReiserFS was added as Linux's first journaling file system 21 years ago with SUSE using it as the default filesystem until 2006. However, since Hans Reiser was sent to jail 15 years ago for murder, there has not been much development or interest in it. Noting that there have been no user-spotted fixes since 2019, longtime kernel developer Matthew Wilcox also cited that ReiserFS was only block for some kernel changes he wished to implement. These days there are better alternatives like EXT4, Btrfs, XFS, and OpenZFS.

Linux programmers fixed bugs faster than anyone — in an average of just 25 days (improving from 32 days in 2019 to just 15 in 2021). That's the conclusion of Google's "Project Zero" security research team, which studied the speed of bug-fixing from January 2019 to December 2021.

ZDNet reports that Linux's competition "didn't do nearly as well." For instance, Apple, 69 days; Google, 44 days; and Mozilla, 46 days. Coming in at the bottom was Microsoft, 83 days, and Oracle, albeit with only a handful of security problems, with 109 days.

By Project Zero's count, others, which included primarily open-source organizations and companies such as Apache, Canonical, Github, and Kubernetes, came in with a respectable 44 days.

Generally, everyone's getting faster at fixing security bugs. In 2021, vendors took an average of 52 days to fix reported security vulnerabilities. Only three years ago the average was 80 days. In particular, the Project Zero crew noted that Microsoft, Apple, and Linux all significantly reduced their time to fix over the last two years.

As for mobile operating systems, Apple iOS with an average of 70 days is a nose better than Android with its 72 days. On the other hand, iOS had far more bugs, 72, than Android with its 10 problems.

Browsers problems are also being fixed at a faster pace. Chrome fixed its 40 problems with an average of just under 30 days. Mozilla Firefox, with a mere 8 security holes, patched them in an average of 37.8 days. Webkit, Apple's web browser engine, which is primarily used by Safari, has a much poorer track record. Webkit's programmers take an average of over 72 days to fix bugs.

ZDNet reports: Cyber criminals are increasingly targeting Linux servers and cloud infrastructure to launch ransomware campaigns, cryptojacking attacks and other illicit activity — and many organisations are leaving themselves open to attacks because Linux infrastructure is misconfigured or poorly managed. Analysis from cybersecurity researchers at VMware warns that malware targeting Linux-based systems is increasing in volume and complexity, while there's also a lack of focus on managing and detecting threats against them.

This comes after an increase in the use of enterprises relying on cloud-based services because of the rise of hybrid working, with Linux the most common operating system in these environments. That rise has opened new avenues that cyber criminals can exploit to compromise enterprise networks, as detailed by the research paper, including ransomware and cryptojacking attacks tailored to target Linux servers in environments that might not be as strictly monitored as those running Windows. These attacks are designed for maximum impact, as the cyber criminals look to compromise as much as the network as possible before triggering the encryption process and ultimately demanding a ransom for the decryption key.

The report warns that ransomware has evolved to target Linux host images used to spin up workloads in virtualised environments, enabling the attackers to simultaneously encrypt vast swathes of the network and make incident response more difficult. The attacks on cloud environments also result in attackers stealing information from servers, which they threaten to publish if they're not paid a ransom.... Cryptojacking and other malware attacks are also increasingly targeting Linux servers. Cryptojacking malware steals processing power from CPUs and servers in order to mine for cryptocurrency....

Many of the cyberattacks targeting Linux environments are still relatively unsophisticated when compared with equivalent attacks targeting Windows systems — that means that with the correct approach to monitoring and securing Linux-based systems, many of these attacks can be prevented. That includes cybersecurity hygiene procedures such as ensuring default passwords aren't in use and avoiding sharing one account across multiple users.