Linux.Slashdot.org

Linux Mint Debian Edition 7 "will come with full support for OEM installations," according to their monthly newsletter, so Linux Mint "can be pre-installed on computers which are sold throughout the World. It's a very important feature and it's one of the very few remaining things which wasn't supported by Linux Mint Debian Edition." Slashdot reader BrianFagioli speculates that "this could be a sign of something much bigger." OEM installs are typically reserved for operating systems meant to ship on hardware. It's how companies preload Linux on laptops without setting a username, password, or timezone... Mint has supported this for years — but only in its Ubuntu-based version. So why is this feature suddenly coming to Linux Mint Debian Edition, which the team has repeatedly described as a contingency? In other words, if the Debian variant is merely a plan B, why make it ready for OEMs? Their blog post goes on to speculate about possible explanations (like the hypothetical possibility of dissatisfaction with Snap packages or Canonical's decisions around telemetry and packaging). Slashdot reached out to Linux Mint project leader Clement Lefebvre, who responded cheerfully that "I know people love to speculate on this. There's no hidden agenda on our side though. "Improving LMDE is a continuous effort. It's something we do regularly." "Any LMDE improvement facilitates a future potential transition to Debian, of course. But there are other reasons to implement OEM support. "We depend on Ubiquity in Linux Mint. We have a much simpler installer, with no dependencies, no technical debt and with a design we're in control of in LMDE. Porting LMDE's live-installer to Linux Mint is something we're looking into. Implementing OEM support in live-installer kills two birds with one stone. It improves LMDE and opens the door to switching away from Ubiquity in Linux Mint."

Read more of this story at Slashdot.

Celebrating Git's 20th anniversary, GitHub hosted a Q&A with Linus Torvalds, writes Its FOSS News. Among the other revelations: He says his college-age daughter sent a texting saying he's better known at her CS lab for Git than for Linux, "because they actually use Git for everything there." Which he describes as "ridiculous" because he maintained it for just four months before handing it off to Junio Hamano who's been heading up development for more than 19 years now. "When it did what I needed," Torvalds says, "I lost interest." Linus then goes on to share how Git was never a big thing for him, but a means to an end that prevented the Linux kernel from descending into chaos over the absence of a version control system. You see, before Git, Linux used BitKeeper for version control, but its proprietary licensing didn't sit too well with other Linux contributors, and Linus Torvalds had to look for alternatives. As it turned out, existing tools like CVS and Subversion were too slow for the job at hand, prompting him to build a new tool from scratch, with the coding part just taking 10 days for an early self-hostable version of Git. In its initial days, there were some teething issues, where users would complain about Git to Linus, even finding it too difficult to use, but things got calmer as the tool developed further. Torvalds thinks some early adopters had trouble because they were coming from a background that was more like CVS. "The Git mindset, I came at it from a file system person's standpoint, where I had this disdain and almost hatred of most source control management projects, so I was not at all interested in maintaining the status quo."

Read more of this story at Slashdot.

Celebrating Git's 20th anniversary, GitHub hosted a Q&A with Linus Torvalds, writes Its FOSS News. Among the other revelations: He says his college-age daughter sent a texting saying he's better known at her CS lab for Git than for Linux, "because they actually use Git for everything there." Which he describes as "ridiculous" because he maintained it for just four months before handing it off to Junio Hamano who's been heading up development for more than 19 years now. "When it did what I needed," Torvalds says, "I lost interest." Linus then goes on to share how Git was never a big thing for him, but a means to an end that prevented the Linux kernel from descending into chaos over the absence of a version control system. You see, before Git, Linux used BitKeeper for version control, but its proprietary licensing didn't sit too well with other Linux contributors, and Linus Torvalds had to look for alternatives. As it turned out, existing tools like CVS and Subversion were too slow for the job at hand, prompting him to build a new tool from scratch, with the coding part just taking 10 days for an early self-hostable version of Git. In its initial days, there were some teething issues, where users would complain about Git to Linus, even finding it too difficult to use, but things got calmer as the tool developed further. Torvalds thinks some early adopters had trouble because they were coming from a background that was more like CVS. "The Git mindset, I came at it from a file system person's standpoint, where I had this disdain and almost hatred of most source control management projects, so I was not at all interested in maintaining the status quo."

Read more of this story at Slashdot.

Fedora has proposed a major change for its upcoming version 43 release that aims to achieve 99% package reproducibility, addressing growing concerns about supply-chain security. According to the change proposal announced March 31, Fedora has already reached 90% reproducibility through infrastructure changes including "clamping" file modification times and implementing a Rust-based "add-determinism" tool that standardizes metadata. The remaining 10% will require individual package maintainer involvement, treating reproducibility failures as bugs. The effort will use a public instance of rebuilderd to independently verify that binary packages can be reproduced from source code. Unlike Debian's bit-by-bit reproducibility definition, Fedora allows differences in package signatures and some metadata while requiring identical payloads. The initiative follows similar efforts by Debian and openSUSE, and comes amid heightened focus on supply-chain security after the recent XZ backdoor incident.

Read more of this story at Slashdot.