While it's been argued that Linux has four different "birthdays," last Friday saw the 30th anniversary of Linux's very, very first release — version 0.01. That special first release "was never publicly announced, and I only emailed a handful of people in private about the upload," Torvalds remembered on the Linux kernel mailing list. He no longer has copies of those announcement emails, "so there's no real record of that. The only record of the date is in the Linux-0.01 tar-file itself, I suspect." "Alas, the dates in that tar-file are for the last modification dates, not the actual creation of the tar-file," Torvalds wrote, "but it does seem to have happened around 7:30pm (Finnish time), so the exact anniversary was technically a couple of hours ago." So when the exact moment arrived for its 30th anniversary, Torvalds couldn't resist sharing the moment on the Linux kernel mailing list. "Just thought I'd mention it, since while unannounced, in many ways this is the true 30th anniversary date of the actual code."

Read more of this story at Slashdot.

Despite Linux reaching its 30th anniversary, "most outside the tech industry will be unaware that Linux has reached such a milestone," writes ZDNet, "even though the project has had a huge impact on everything from smartphones to cloud computing." They add that Linus Torvalds "poked fun at that lack of recognition in his usual Sunday release note for a new stable version of the Linux kernel." "So I realize you must all still be busy with all the galas and fancy balls and all the other 30th anniversary events, but at some point you must be getting tired of the constant glitz, the fireworks, and the champagne," Torvalds said. "That ball gown or tailcoat isn't the most comfortable thing, either. The celebrations will go on for a few more weeks yet, but you all may just need a breather from them." Linux 5.14 includes additional features for Intel's Alder Lake mobile-ready CPUs, extra AMD support and better support for the Raspberry Pi 400 PC. "Because 5.14 is out there, just waiting for you to kick the tires and remind yourself what all the festivities are about," notes Torvalds... Torvalds is upbeat about Linux's future, predicting decades more work for the kernel's several thousand contributors who help shape the Linux kernel and drivers. "Of course, the poor tireless kernel maintainers won't have time for the festivities, because for them, this just means that the merge window will start tomorrow. We have another 30 years to look forward to, after all. But for the rest of you, take a breather, build a kernel, test it out, and then you can go back to the seemingly endless party that I'm sure you just crawled out of," he wrote.

Read more of this story at Slashdot.

Long-time Slashdot reader ArchieBunker writes: Slackware, one of oldest Linux distributions, has just announced the long awaited version 15.0 RC1 is available for download from the usual mirrors. Here's the changelog. Phoronix points out it's been nearly a decade since Slackware 14

Read more of this story at Slashdot.

With the 30th birthday of Linux coming up, TechRepublic's Jack Wallen argues that its distros "are so much better today." I remember like it was yesterday. The very first time I booted into the Linux desktop. The distribution in question was Caldera Open Linux 1.0, which installed with kernel 2.0 and the desktop was Fvwm95... It was just unsightly. The colors were decidedly too Microsoftian, and it was all so ... clinical.... The Linux desktop has morphed from an ugly, awkward, and less-than-productive state, to an almost avant-garde work of art, into an elegant, productive and professional environment. All the while, it offered more choices than most users had time to consider. Even today, I could go back to Enlightenment, or opt for the likes of Pantheon, Budgie, KDE, Openbox, Fluxbox, i3, Gala, Windowmaker or numerous other takes on the desktop... If I were to go back in time and look over the shoulder at a younger me, I would probably see someone who loved the desktop he was using, but wished it could be a bit more productive. I would then whisper into his ear and say, "Give it time."

Read more of this story at Slashdot.

According to Steam Survey numbers for July 2021, Steam on Linux hit a 1.0% marketshare, or a +0.14% increase over the month prior. Phoronix reports: This is the highest we have seen the Steam on Linux marketshare in a number of years and well off the lows prior to introducing Steam Play (Proton) since which point there has been the gradual increase in marketshare. Back when Steam on Linux first debuted there was around a 2% marketshare for Linux before gradually declining. Back when Steam first debuted for Linux, the overall Steam customer base was also much smaller than it is today. While many believe the Steam Survey is inaccurate or biased (or just buggy towards prompting Linux users to participate in the survey), these initial numbers for July are positive in hitting the 1.0% mark after largely floating around the 0.8~0.9% mark for most of the past three years. The Steam Deck isn't shipping until the end of the year so we'll see how the number fluctuates to that point.

Read more of this story at Slashdot.

mrflash818 writes: The Internet Security Research Group (ISRG) -- parent organization of the better-known Let's Encrypt project -- has provided prominent developer Miguel Ojeda with a one-year contract to work on Rust in Linux and other security efforts on a full-time basis. Rust is a low-level programming language offering most of the flexibility and performance of C -- the language used for kernels in Unix and Unix-like operating systems since the 1970s -- in a safer way. Efforts to make Rust a viable language for Linux kernel development began at the 2020 Linux Plumbers conference, with acceptance for the idea coming from Linus Torvalds himself. Torvalds specifically requested Rust compiler availability in the default kernel build environment to support such efforts -- not to replace the entire source code of the Linux kernel with Rust-developed equivalents, but to make it possible for new development to work properly. Using Rust for new code in the kernel -- which might mean new hardware drivers or even replacement of GNU Coreutils -- potentially decreases the number of bugs lurking in the kernel. Rust simply won't allow a developer to leak memory or create the potential for buffer overflows -- significant sources of performance and security issues in complex C-language code.

Read more of this story at Slashdot.

The nonprofit Linux Foundation "asked the open source community: How has Linux impacted your life? Needless to say, responses poured in from across the globe sharing memories, sentiments and important moments that changed your lives forever." Their web site now features a selection of stories from America, Canada, Brazil, Chile, Costa Rica, Ireland, Germany, France, Italy, Sweden, the Netherlands, Nigeria, South Africa, India, Nepal, Sri Lanka, Kuwait, the Philippines, Bosnia & Herzegovina and China. And each story's author received a special honor... We are grateful you took the time to tell us your stories. We're thrilled to share 30 of the responses we received, randomly selected from all submissions. As a thank you to these 30 folks for sharing their stories, and in celebration of the 30th Anniversary of Linux, 30 penguins were adopted from the Southern African Foundation for the Conservation of Coastal Birds in their honor, and each of our submitters got to name their adopted penguin. One Kuwait-based developer had written "when I was able to use it instead of Windows, it made me happier because I didn't have to restart it every couple of days for instability." And a story from Nepal says "Linux enabled me to become a software engineer. I would not have been able to afford Microsoft Windows... I had the opportunity to interact with various people from great communities and learn from their contributions. So I am very much thankful to Linus and each and every member of the free and open source community for helping me become a better programmer and a better person."

Read more of this story at Slashdot.

An anonymous reader quotes a report from ZDNet: The Linux Foundation Public Health (LFPN) is getting the Global COVID Certificate Network (GCCN) ready for deployment. The GCCN [...] really is a coronavirus vaccine passport. It will do this by establishing a global trust registry network. This will enable interoperable and trustworthy exchanges of COVID certificates among countries for safe reopening and provide related technology and guidance for implementation. It's being built by the Linux Foundation Public Health and its allies, Affinidi, AOKPass, Blockchain Labs, Evernym, IBM, Indicio.Tech, LACChain, Lumedic, Proof Market, and ThoughtWorks. These companies have already implemented COVID certificate or pass systems for governments and industries. Together they will define and implement GCCN. This, it's hoped, will be the model for a true international vaccine registry. Once completed, the GCCN's trust registry network will enable each country to publish a list of the authorized issuers of COVID certificates that can be digitally verified by authorities in other countries. This will bridge the gap between technical specifications (e.g. W3C Verifiable Credentials or SMART Health Card) and a complete trust architecture required for safe reopening. This is vital because as Brian Behlendorf, the Linux Foundation's General Manager for Blockchain, Healthcare, and Identity explained, "The first wave of apps for proving one's COVID status did not allow that proof to be shown beyond a single state or nation, did not avoid vendor lock-in and did not distinguish between rich health data and simple passes. The Blueprint gives this industry a way to solve those issues while meeting a high bar for privacy and integrity, and GCCN turns those plans into action." Once in place, the GCCN will support Global COVID Certificates (GCC). These certificates will have three use cases: Vaccination, recovery from infection, and test results. They will be available in both paper and digital formats. Participating governments and industry alliances will decide what COVID certificates they issue and accept. The GCC schema definitions and minimal datasets will follow the recommendations of the Blueprint, as well as GCCN's technical and governance documents, implementation guide, and open-source reference implementations, which will be developed in collaboration with supporting organizations and the broader LFPH community. Besides setting the specs and designs, the GCCN community will also offer peer-based implementation and governance guidance to governments and industries to help them implement COVID certificate systems. This will include how to build national and state trust registries and infrastructure. They'll also provide guidance on how to leverage GCC into their existing coronavirus vaccine systems.

Read more of this story at Slashdot.

destinyland writes: LWN has a terrific update what's happened since the discovery of University of Minnesota researchers intentionally submitting buggy code to the Linux kernel: The writing of a paper on this research [PDF] was not the immediate cause of the recent events; instead, it was the posting of a buggy patch originating from an experimental static-analysis tool run by another developer at UMN. That led developers in the kernel community to suspect that the effort to submit intentionally malicious patches was still ongoing. Since then, it has become apparent that this is not the case, but by the time the full story became clear, the discussion was already running at full speed. The old saying still holds true: one should not attribute to malice that which can be adequately explained by incompetence. On April 22, a brief statement was issued by the Linux Foundation technical advisory board (TAB) stating that, among other things, the recent patches appeared to have been submitted in good faith. Meanwhile, the Linux Foundation and the TAB sent a letter to the UMN researchers outlining how the situation should be addressed; that letter has not been publicly posted, but ZDNet apparently got a copy from somewhere. Among other things, the letter asked for a complete disclosure of the buggy patches sent as part of the UMN project and the withdrawal of the paper resulting from this work. In response, the UMN researchers posted an open letter apologizing to the community, followed a few days later by a summary of the work they did [PDF] as part of the "hypocrite commits" project. Five patches were submitted overall from two sock-puppet accounts, but one of those was an ordinary bug fix that was sent from the wrong account by mistake. Of the remaining four, one of them was an attempt to insert a bug that was, itself, buggy, so the patch was actually valid; the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers, though the reasons for rejection were not always the bugs in question. The paper itself has been withdrawn and will not be presented in May as was planned... One of the first things that happened when this whole affair exploded was the posting by Greg Kroah-Hartman of a 190-part patch series reverting as many patches from UMN as he could find... As it happens, these "easy reverts" also needed manual review; once the initial anger passed there was little desire to revert patches that were not actually buggy. That review process has been ongoing over the course of the last week and has involved the efforts of a number of developers. Most of the suspect patches have turned out to be acceptable, if not great, and have been removed from the revert list; if your editor's count is correct, 42 patches are still set to be pulled out of the kernel... A look at the full set of UMN patches reinforces some early impressions, though. First is that almost all of them do address some sort of real (if obscure and hard to hit) problem...

Read more of this story at Slashdot.

Earlier this week Greg Kroah-Hartman of the Linux kernel development team banned the University of Minnesota from contributing after researchers there submitted what he called "obviously-incorrect patches" believed to be part of a research project into whether buggy code would be accepted. Today the professor in charge of that project, as well as two of its researchers, sent an email to the Linux kernel mailing list saying they "sincerely apologize for any harm our research group did to the Linux kernel community." Our goal was to identify issues with the patching process and ways to address them, and we are very sorry that the method used in the "hypocrite commits" paper was inappropriate. As many observers have pointed out to us, we made a mistake by not finding a way to consult with the community and obtain permission before running this study; we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches. While our goal was to improve the security of Linux, we now understand that it was hurtful to the community to make it a subject of our research, and to waste its effort reviewing these patches without its knowledge or permission. We just want you to know that we would never intentionally hurt the Linux kernel community and never introduce security vulnerabilities. Our work was conducted with the best of intentions and is all about finding and fixing security vulnerabilities... We are a research group whose members devote their careers to improving the Linux kernel. We have been working on finding and patching vulnerabilities in Linux for the past five years... This current incident has caused a great deal of anger in the Linux community toward us, the research group, and the University of Minnesota. We apologize unconditionally for what we now recognize was a breach of the shared trust in the open source community and seek forgiveness for our missteps. We seek to rebuild the relationship with the Linux Foundation and the Linux community from a place of humility to create a foundation from which, we hope, we can once again contribute to our shared goal of improving the quality and security of Linux software... We are committed to following best practices for collaborative research by consulting with community leaders and members about the nature of our research projects, and ensuring that our work meets not only the requirements of the Institutional Review Board but also the expectations that the community has articulated to us in the wake of this incident. While this issue has been painful for us as well, and we are genuinely sorry for the extra work that the Linux kernel community has undertaken, we have learned some important lessons about research with the open source community from this incident. We can and will do better, and we believe we have much to contribute in the future, and will work hard to regain your trust. Their email also says their work did not introduce vulnerabilities into the Linux code. ("The three incorrect patches were discussed and stopped during exchanges in a Linux message board, and never committed to the code.") And the email also clarifies that their research was only done in August of 2020, and "All the other 190 patches being reverted and re-evaluated were submitted as part of other projects and as a service to the community; they are not related to the 'hypocrite commits' paper. These 190 patches were in response to real bugs in the code and all correct — as far as we can discern — when we submitted them... Our recent patches in April 2021 are not part of the 'hypocrite commits' paper either." UPDATE (4/25): Late Saturday night the kernel team's Greg Kroah-Hartman rejected the apology, writing that "the Linux Foundation and the Linux Foundation's Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community. "Until those actions are taken, we do not have anything further to discuss about this issue."

Read more of this story at Slashdot.

Greg Kroah-Hartman, who is one of the head honchos of the Linux kernel development and maintenance team, has banned the University of Minnesota (UMN) from further contributing to the Linux Kernel. The University had apparently introduced questionable patches into the kernel of Linux. From a report: The UMN had worked on a research paper dubbed "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits". Obviously, the "Open-Source Software" (OSS) here is indicating the Linux kernel and the University had stealthily introduced Use-After-Free (UAF) vulnerability to test the susceptibility of Linux. So far so good perhaps as one can see it as ethical experimenting. However, the UMN apparently sent another round of "obviously-incorrect patches" into the kernel in the form of "a new static analyzer" causing distaste to Greg Kroah-Hartman who has now decided to ban the University from making any further contributions.

Read more of this story at Slashdot.

Slashdot reader LeeLynx shares news from The Register about a Slackware 15 beta release (following the debut of February's alpha), "nearly five years after the distribution last saw a major update." (And nearly 28 years after its initial release back in 1993...) Created by Patrick Volkerding (who still lays claim to the title Benevolent Dictator For Life), the current release version arrived in the form of 2016's 14.2... The Linux kernel has been updated to 5.10.30 (at time of writing) with 5.11.14 available for testing. Desktop fans may be pleased to see, among the many updates, KDE Plasma hitting 5.21.4 as well as updates for old faithfuls, such as Mozilla Firefox and Thunderbird. The beta itself dropped on 12 April (with the 5.10.29 kernel) and Volkerding noted: "I'm going to go ahead and call this a beta even though there's still no fix for the illegal instruction issue with 32-bit mariadb. But there should be soon." Tinkering has continued since, judging by the change log, although the beta tag brings hope there will be a release before long.

Read more of this story at Slashdot.

Long-time Slashdot reader xiando quotes LinuxReviews: The community distribution Arch Linux has up to now required you to manually install it by entering a whole lot of scary commands in a terminal. Arch version 2021.04.01 features a new guided installer [reached by] typing python -m archinstall guided into the console you get when you boot the Arch Linux installation ISO. It is not very novice-friendly, or user-friendly, but it gets the job done and it will work fine for those with some basic GNU/Linux knowledge. Tech Radar writes that previously Arch Linux had "a rather convoluted installation process, which has given rise to a stream of Arch-based distros that are easier to install," adding that the new installer "was reportedly promoted as an official installation mechanism back in January, and was actively worked upon leading to its inclusion in the installation medium." Users have been calling on Arch Linux for simplifying the installation process for a long time, to bring it in line with other Linux distros. However, the Arch philosophy has always been to put the users in charge of every aspect of their installation, which is the antithesis of automated installers. Phoronix calls the new installer "very quick and easy," although "granted not as user-friendly / polished as say the Debian Installer, Red Hat's Anaconda installer, even Ubuntu's Subiquity, and other TUI/GUI Linux installers out there." They also note that Archinstall "does allow automatically partitioning the drive with your choice of file-system options, automatically installing a desktop environment if desired, configuring the network interfaces, and all the other basics." The method is quick enough that I'll likely use archinstall for future Arch Linux benchmarks on Phoronix as it also then applies a sane set of defaults for users... Five minutes or less and off to the races, ready for Arch Linux." But Slashdot reader I75BJC still favors "scary commands in a terminal," leaving this comment on the original submission: If you can't type with the big adults, stay on your PlayStation. Even Apple, with its very good GUI has a command line. The command line commands are more flexible, more specific, more subtle than the pointy-clicky GUI.

Read more of this story at Slashdot.

Slashdot reader b-dayyy quotes the Linux Security blog: While all Linux 'distros' — or distributed versions of Linux software — are secure by design, certain distros go above and beyond when it comes to protecting users' privacy and security. We've put together a list of our favorite specialized secure Linux distros and spoken with some of their lead developers to find out first-hand what makes these distros so great. This "favorites" list cites six "excellent specialized secure Linux distros." Some highlights from the article: In a conversation with the LinuxSecurity editors, Qubes OS Community Manager Andrew David Wong elaborated, "Rather than attempting to fix all of the security bugs in software, Qubes assumes that all software is buggy and compartmentalizes it accordingly, so that when flaws are inevitably exploited, the damage is contained and the user's most valuable data is protected." A Kali Linux contributor provides some insight into the distro's history and the benefits it offers users: "Named after a Hindu goddess, Kali has been around for a long time — but it's still updated weekly, can be run in live mode or installed to a drive, and can also be used on ARM devices like Raspberry Pi." Obviously there's strong opinions among Slashdot readers. So share your own thoughts in the comments. What's the best Linux distro for enhanced privacy and security?

Read more of this story at Slashdot.

Slashdot reader Finuz writes: Offensive Security has released Kali Linux 2021.1, the latest version of its popular open source penetration testing platform. You can download it or upgrade to it. Kali NetHunter, the distro's mobile pentesting platform, now has an upgraded BusyBox engine and tools updated to the latest version (or, in some cases, completely rewritten). There are two new Kali ARM images: one that can be used with VMs on Apple Silicon Macs (Apple M1) and the other for the Raspberry Pi 400's wireless card.

Read more of this story at Slashdot.

SiFive today announced it is creating a platform for Linux-based personal computers based on RISC-V processors. VentureBeat reports: Assuming customers adopt the processors and use them in PCs, the move might be part of a plan to create Linux-based PCs that use royalty-free processors. This could be seen as a challenge to computers based on designs from Intel, Advanced Micro Devices, Apple, or Arm, but giants of the industry don't have to cower just yet. The San Mateo, California-based company unveiled HiFive Unmatched, a development design for a Linux-based PC that uses its RISC-V processors. At the moment, these development PCs are early alternatives, most likely targeted at hobbyists and engineers who may snap them up when they become available in the fourth quarter for $665. The SiFive HiFive Unmatched board will have a SiFive processor, dubbed the SiFive FU740 SoC, a 5-core processor with four SiFive U74 cores and one SiFive S7 core. The U-series cores are Linux-based 64-bit application processor cores based on RISC-V. These cores can be mixed and matched with other SiFive cores, such as the SiFive FU740. These components are all leveraging SiFive's existing intellectual property portfolio. The HiFive Unmatched board comes in the mini-ITX standard form factor to make it easy to build a RISC-V PC. SiFive also added some standard industry connectors -- ATX power supplies, PCI-Express expansion, Gigabit Ethernet, and USB ports are present on a single-board RISC-V development system. The HiFive Unmatched board includes 8GB of DDR4 memory, 32MB of QSPI flash memory, and a microSD card slot on the motherboard. For debugging and monitoring, developers can access the console output of the board through the built-in microUSB type-B connector. Developers can expand it using PCI-Express slots, including both a PCIe general-purpose slot (PCIe Gen 3 x8) for graphics, FPGAs, or other accelerators and M.2 slots for NVME storage (PCIe Gen 3 x4) and Wi-Fi/Bluetooth modules (PCIe Gen 3 x1). There are four USB 3.2 Gen 1 type-A ports on the rear, next to the Gigabit Ethernet port, making it easy to connect peripherals. The system will ship with a bootable SD card that includes Linux and popular system developer packages, with updates available for download from SiFive.com. It will be available for preorders soon. For some more context: Could RISC-V processors compete with Intel, ARM, and AMD?

Read more of this story at Slashdot.

The Linux 5.10 kernel's XFS file-system will have two new on-disk meta-data capabilities, reports Phoronix: 1. The size of inode btrees in the allocation group is now recorded. This is for increasing redundancy checks and also allowing faster mount times. 2. Support for timestamps now until the year 2486. This "big timestamps" feature is the refactoring of their timestamp and inode encoding functions to handle timestamps as a 64-bit nanosecond counter and bit shifting to increase the effective size. This now allows XFS to run well past the Year 2038 problem (where storing the time since 1970 in seconds will no longer fit in a signed 32-bit integer and thus wraparound) to now the Year 2486. Making a new XFS file-system with bigtime enabled allows a timestamp range from December 1901 to July 2486 rather than December 1901 to January 2038. For preserving backwards compatibility, the big timestamps feature is not currently enabled by default.

Read more of this story at Slashdot.

FSGSBASE support in Linux "has the possibility of helping Intel/AMD CPU performance especially in areas like context switching that had been hurt badly by Spectre/Meltdown and other CPU vulnerability mitigations largely on the Intel side," Phoronix wrote back in August. As it started its journey into the kernel, they provided a preview on August 10: The FSGSBASE support that was finally mainlined a few days ago for Linux 5.9 is off to providing a nice performance boost for both Intel and AMD systems... FSGSBASE support for the Linux kernel has been around a half-decade in the making and finally carried over the finish line by one of Microsoft's Linux kernel engineers... FSGSBASE particularly helps out context switching heavy workloads like I/O and allowing user-space software to write to the x86_64 GSBASE without kernel interaction. That in turn has been of interest to Java and others...On Linux 5.9 where FSGSBASE is finally mainlined, it's enabled by default on supported CPUs. FSGSBASE can be disabled at kernel boot time via the "nofsgsbase" kernel option. Today on the Linux kernel mailing list, Linus Torvalds announced the release of Linux 5.9: Ok, so I'll be honest - I had hoped for quite a bit fewer changes this last week, but at the same time there doesn't really seem to be anything particularly scary in here. It's just more commits and more lines changed than I would have wished for. And Phoronix reported: Linux 5.9 has a number of exciting improvements including initial support for upcoming Radeon RX 6000 "RDNA 2" graphics cards, initial Intel Rocket Lake graphics, NVMe zoned namespaces (ZNS) support, various storage improvements, IBM's initial work on POWER10 CPU bring-up, the FSGSBASE instruction is now used, 32-bit x86 Clang build support, and more. See our Linux 5.9 feature overview for the whole scoop on the many changes to see with this kernel.

Read more of this story at Slashdot.

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

Read more of this story at Slashdot.

Krystalo writes: Edge is finally coming to Linux. At Ignite 2020 today, Microsoft announced that Edge for Linux will be available in the Dev preview channel starting in October. Linux users will be able to download the preview from the Microsoft Edge Insider website or from their native Linux package manager. Microsoft will start with the Ubuntu and Debian distributions, with support for Fedora and openSUSE coming afterwards. "Linux stands out in that, while it has a relatively small desktop population in terms of what you might call typical consumer or end user, developers are often overrepresented in that population, and especially in areas like test automation, or CI/CD workloads for their web apps," Edge program manager Kyle Pflug told VentureBeat. "Edge on Linux is a natural part of our strategy to reduce fragmentation and test overhead for web developers. By providing the same rendering behavior and tools across platforms, developers can build and test sites and web apps in their preferred environment and be confident in the experience their customers will have."

Read more of this story at Slashdot.