Feed aggregator

Linux Hit a New All-Time High for Steam Market Share in December

Linux.Slashdot.org - Mon, 01/12/2026 - 07:34
A year ago the Steam Survey showed a 2.29% marketshare for Linux. Last May it reached 2.69%, its highest level since 2018. November saw another all-time high of 3.2%. But December brought a surprise, reports Phoronix: Back on the 1st Valve published the Steam Survey results for December 2025 and they put the Linux gaming marketshare at 3.19%, a 0.01% dip from November. But now the December results have been revised... [and] put the Linux marketshare at 3.58%, a 0.38% increase over November. Valve didn't publish any explanation for the revision but occasionally they do put out monthly revised data. This is easily an all-time high... both in percentage terms and surely in absolute terms too.

Read more of this story at Slashdot.

Categories: Linux

Linux Hit a New All-Time High for Steam Market Share in December

Slashdot.org - Mon, 01/12/2026 - 07:34
A year ago the Steam Survey showed a 2.29% marketshare for Linux. Last May it reached 2.69%, its highest level since 2018. November saw another all-time high of 3.2%. But December brought a surprise, reports Phoronix: Back on the 1st Valve published the Steam Survey results for December 2025 and they put the Linux gaming marketshare at 3.19%, a 0.01% dip from November. But now the December results have been revised... [and] put the Linux marketshare at 3.58%, a 0.38% increase over November. Valve didn't publish any explanation for the revision but occasionally they do put out monthly revised data. This is easily an all-time high... both in percentage terms and surely in absolute terms too.

Read more of this story at Slashdot.

Joint statement from Google and AppleJoint statement from Google and Apple

GoogleBlog - Mon, 01/12/2026 - 06:33
Apple and Google have entered into a multi-year collaboration under which the next generation of Apple Foundation Models will be based on Google's Gemini models and clou…
Categories: Technology

January 12, 2026 - Hackaday

Linux News - Mon, 01/12/2026 - 04:00
January 12, 2026  Hackaday
Categories: Linux

Ubisoft Closes Game Studio Where Workers Voted to Unionize Two Weeks Ago

Slashdot.org - Mon, 01/12/2026 - 03:44
Ubisoft announced Wednesday it will close its studio in Halifax, Nova Scotia — two weeks after 74% of its staff voted to unionize. This means laying off the 71 people at the studio, reports the gaming news site Aftermath: [Communications Workers of America's Canadian affiliate, CWA Canada] said in a statement to Aftermath the union will "pursue every legal recourse to ensure that the rights of these workers are respected and not infringed in any way." The union said in a news release that it's illegal in Canada for companies to close businesses because of unionization. That's not necessarily what happened here, according to the news release, but the union is "demanding information from Ubisoft about the reason for the sudden decision to close." "We will be looking for Ubisoft to show us that this had nothing to do with the employees joining a union," former Ubisoft Halifax programmer and bargaining committee member Jon Huffman said in a statement. "The workers, their families, the people of Nova Scotia, and all of us who love video games made in Canada, deserve nothing less...." Before joining Ubisoft, the studio was best known for its work on the Rocksmith franchise; under Ubisoft, it focused squarely on mobile games. Ubisoft Halifax was quickly removed from the Ubisoft website on Wednesday...

Read more of this story at Slashdot.

How Long Does It Take to Fix Linux Kernel Bugs?

Slashdot.org - Mon, 01/12/2026 - 00:44
An anonymous reader shared this report from It's FOSS: Jenny Guanni Qu, a researcher at [VC fund] Pebblebed, analyzed 125,183 bugs from 20 years of Linux kernel development history (on Git). The findings show that the average bug takes 2.1 years to find. [Though the median is 0.7 years, with the average possibly skewed by "outliers" discovered after years of hiding.] The longest-lived bug, a buffer overflow in networking code, went unnoticed for 20.7 years! [But 86.5% of bugs are found within five years.] The research was carried out by relying on the Fixes: tag that is used in kernel development. Basically, when a commit fixes a bug, it includes a tag pointing to the commit that introduced the bug. Jenny wrote a tool that extracted these tags from the kernel's git history going back to 2005. The tool finds all fixing commits, extracts the referenced commit hash, pulls dates from both commits, and calculates the time frame. As for the dataset, it includes over 125k records from Linux 6.19-rc3, covering bugs from April 2005 to January 2026. Out of these, 119,449 were unique fixing commits from 9,159 different authors, and only 158 bugs had CVE IDs assigned. It took six hours to assemble the dataset, according to the blog post, which concludes that the percentage of bugs found within one year has improved dramatically, from 0% in 2010 to 69% by 2022. The blog post says this can likely be attributed to: The Syzkaller fuzzer (released in 2015) Dynamic memory error detectors like KASAN, KMSAN, KCSAN sanitizers Better static analysis More contributors reviewing code But "We're simultaneously catching new bugs faster AND slowly working through ~5,400 ancient bugs that have been hiding for over 5 years." They've also developed an AI model called VulnBERT that predicts whether a commit introduces a vulnerability, claiming that of all actual bug-introducing commits, it catches 92.2%. "The goal isn't to replace human reviewers but to point them at the 10% of commits most likely to be problematic, so they can focus attention where it matters..."

Read more of this story at Slashdot.

How Long Does It Take to Fix Linux Kernel Bugs?

Linux.Slashdot.org - Mon, 01/12/2026 - 00:44
An anonymous reader shared this report from It's FOSS: Jenny Guanni Qu, a researcher at [VC fund] Pebblebed, analyzed 125,183 bugs from 20 years of Linux kernel development history (on Git). The findings show that the average bug takes 2.1 years to find. [Though the median is 0.7 years, with the average possibly skewed by "outliers" discovered after years of hiding.] The longest-lived bug, a buffer overflow in networking code, went unnoticed for 20.7 years! [But 86.5% of bugs are found within five years.] The research was carried out by relying on the Fixes: tag that is used in kernel development. Basically, when a commit fixes a bug, it includes a tag pointing to the commit that introduced the bug. Jenny wrote a tool that extracted these tags from the kernel's git history going back to 2005. The tool finds all fixing commits, extracts the referenced commit hash, pulls dates from both commits, and calculates the time frame. As for the dataset, it includes over 125k records from Linux 6.19-rc3, covering bugs from April 2005 to January 2026. Out of these, 119,449 were unique fixing commits from 9,159 different authors, and only 158 bugs had CVE IDs assigned. It took six hours to assemble the dataset, according to the blog post, which concludes that the percentage of bugs found within one year has improved dramatically, from 0% in 2010 to 69% by 2022. The blog post says this can likely be attributed to: The Syzkaller fuzzer (released in 2015) Dynamic memory error detectors like KASAN, KMSAN, KCSAN sanitizers Better static analysis More contributors reviewing code But "We're simultaneously catching new bugs faster AND slowly working through ~5,400 ancient bugs that have been hiding for over 5 years." They've also developed an AI model called VulnBERT that predicts whether a commit introduces a vulnerability, claiming that of all actual bug-introducing commits, it catches 92.2%. "The goal isn't to replace human reviewers but to point them at the 10% of commits most likely to be problematic, so they can focus attention where it matters..."

Read more of this story at Slashdot.

Categories: Linux

Syndicate content
Comment