BrianFagioli shares a report from BetaNews: Mozilla has announced Firefox Nightly for ARM64. This release will cater to the growing demand for support on ARM64 platforms, commonly referred to as AArch64. Feedback from the community has led Mozilla to expand the availability of Firefox Nightly. Users can now access the browser as both .tar archives and .deb packages, depending on their preference and requirements for installation.

For those who favor traditional methods, the .tar.bz2 binaries are accessible through Mozilla's downloads page by selecting the option for Firefox Nightly for Linux ARM64/AArch64. Meanwhile, users looking to utilize updates and installation through Mozilla's APT repository can follow specific instructions to install the firefox-nightly package.

Ubuntu 24.10 [expected this October] and Debian GNU/Linux 13 "Trixie" [expected June-July 2025] "will feature a refined APT command-line interface," reports 9to5Linux: APT developer and Canonical engineer Julian Andres Klode took to LinkedIn to present the revamped APT interface powered by the upcoming APT 3.0 package manager that looks to give users a more concise and well-laid-out command-line output when updating, installing, or removing packages via the terminal emulator.

The new APT 3.0 UI brings a columnar display that will make it easier for users to quickly scan for a package name, support for colors (red for removals and green for other changes), which makes it easier to quickly distinguish commands at a glance, and smoother install progress bars using Unicode blocks.

In addition, the new APT 3.0 command-line interface will be less verbose and offer more padding to make it easier to separate sections and extract the relevant information for you.
"Bleeding-edge users and Linux enthusiasts who want to try this right now can check out Debian Unstable..."

Bill Toulas reports via BleepingComputer: Firmware security firm Binarly has released a free online scanner to detect Linux executables impacted by the XZ Utils supply chain attack, tracked as CVE-2024-3094. CVE-2024-3094 is a supply chain compromise in XZ Utils, a set of data compression tools and libraries used in many major Linux distributions. Late last month, Microsoft engineer Andres Freud discovered the backdoor in the latest version of the XZ Utils package while investigating unusually slow SSH logins on Debian Sid, a rolling release of the Linux distribution.

The backdoor was introduced by a pseudonymous contributor to XZ version 5.6.0, which remained present in 5.6.1. However, only a few Linux distributions and versions following a "bleeding edge" upgrading approach were impacted, with most using an earlier, safe library version. Following the discovery of the backdoor, a detection and remediation effort was started, with CISA proposing downgrading the XZ Utils 5.4.6 Stable and hunting for and reporting any malicious activity.

Binarly says the approach taken so far in the threat mitigation efforts relies on simple checks such as byte string matching, file hash blocklisting, and YARA rules, which could lead to false positives. This approach can trigger significant alert fatigue and doesn't help detect similar backdoors on other projects. To address this problem, Binarly developed a dedicated scanner that would work for the particular library and any file carrying the same backdoor. [...] Binarly's scanner increases detection as it scans for various supply chain points beyond just the XZ Utils project, and the results are of much higher confidence. Binarly has made a free API available to accomodate bulk scans, too.

"2004 was already an eventful year for Linux," writes ZDNet's Jack Wallen. "As I reported at the time, SCO was trying to drive Linux out of business. Red Hat was abandoning Linux end-user fans for enterprise customers by closing down Red Hat Linux 9 and launching the business-friendly Red Hat Enterprise Linux (RHEL). Oh, and South African tech millionaire and astronaut Mark Shuttleworth [also a Debian Linux developer] launched Canonical, Ubuntu Linux's parent company.

"Little did I — or anyone else — suspect that Canonical would become one of the world's major Linux companies."

Mark Shuttleworth answered questions from Slashdot reader in 2005 and again in 2012. And this year, Canonical celebrates its 20th anniversary. ZDNet reports: Canonical's purpose, from the beginning, was to support and share free software and open-source software... Then, as now, Ubuntu was based on Debian Linux. Unlike Debian, which never met a delivery deadline it couldn't miss, Ubuntu was set to be updated to the latest desktop, kernel, and infrastructure with a new release every six months. Canonical has kept to that cadence — except for the Ubuntu 6.06 release — for 20 years now...

Released in October 2004, Ubuntu Linux quickly became synonymous with ease of use, stability, and security, bridging the gap between the power of Linux and the usability demanded by end users. The early years of Canonical were marked by rapid innovation and community building. The Ubuntu community, a vibrant and passionate group of developers and users, became the heart and soul of the project. Forums, wikis, and IRC channels buzzed with activity as people from all over the world came together to contribute code, report bugs, write documentation, and support each other....

Canonical's influence extends beyond the desktop. Ubuntu Linux, for example, is the number one cloud operating system. Ubuntu started as a community desktop distribution, but it's become a major enterprise Linux power [also widely use as a server and Internet of Things operating system.]
The article notes Canonical's 2011 creation of the Unity desktop. ("While Ubuntu Unity still lives on — open-source projects have nine lives — it's now a sideline. Ubuntu renewed its commitment to the GNOME desktop...")

But the article also argues that "2016, on the other hand, saw the emergence of Ubuntu Snap, a containerized way to install software, which --along with its rival Red Hat's Flatpak — is helping Linux gain some desktop popularity."

Back in 2006 Slashdot reported on a 50-megabyte "micro" distro called Damn Small Linux. (And in 2012 we wrote that it "rose from the dead" with a new release candidate.)

Now Damn Small Linux has been reborn again, according to its developer's web site: Creating the original DSL, a versatile 50MB distribution, was a lot of fun and one of the things I am most proud of as a personal accomplishment. However, as a concept, it was in the right place at the right time, and the computer industry has changed a lot since then. While it would be possible to make a bootable Xwindows 50MB distribution today, it would be missing many drivers and have only a handful of very rudimentary applications. People would find such a distribution a fun toy or something to build upon, but it would not be usable for the average computer user out of the gate....

The new goal of DSL is to pack as much usable desktop distribution into an image small enough to fit on a single CD, or a hard limit of 700MB. This project is meant to service older computers and have them continue to be useful far into the future. Such a notion sits well with my values. I think of this project as my way of keeping otherwise usable hardware out of landfills.

As with most things in the GNU/Linux community, this project continues to stand on the shoulders of giants. I am just one guy without a CS degree, so for now, this project is based on antiX 23 i386... a fantastic distribution that I think shares much of the same spirit as the original DSL project. AntiX shares pedigree with MEPIS and also leans heavily on the geniuses at Debian.
The blog It's FOSS News describes it as "a unique experience in a sea of Debian-based and Fedora-based distros." It is offered with two window managers, Fluxbox and JWM, with apt being fully enabled by default for easy package installations... At the time of writing, only the Alpha ISOs were made available on the official downloads page. It is only a matter of time before we get a stable release.

Klaus Zimmermann (a self-described "friendly hacker") recently posted a "State of the Distro" post, choosing his favorite distributions for things like portable installation from a USB drive (Alpine Linux) and for a desktop OS (Debian Linux or Devuan).

But when it comes to a distro for the Raspberry Pi, (at least until the 4), Zimmerman argues that FreeBSD's performance is "unlike any other Linux distribution I've ever seen, even with cpupower activated and overclocking." Nope, no match — FreeBSD's performance on the Pi is still way better, even without overclocking. You can browse a modern web, have things scroll smoothly, watch videos and even play some 3D games like Quake with it! And if you overclock it a little (2GHz) you can even make it run that gargantua MS Teams.

But what about all that lackluster driver support? WiFi drivers still on the 802.11g standard and all? Surely you can't be serious about it when Linux offers all that support out of the box, right? Wrong, actually. For starters, the drivers provided for the Pi's hardware are often half-assed proprietary blobs... I no longer think FreeBSD is really at fault if the driver support for the hardware is not helpful to begin with. Even drivers you find for Linux are shaky at best.

So yes, I will keep using FreeBSD on the Pi. As a desktop. With USB WiFi and audio adapters for those services, because the existing hardware is sort of moot even otherwise. And with those USB adapters — and FreeBSD — the Pi works really well, truly desktop-like.
I'd be curious to hear from Slashdot's readers about their own experiments with Linux (and FreeBSD) on a Raspberry Pi. Zimmerman's final winner, for the "Server" category, was Debian — though of his two servers, one is just an XMPP server set up on a Raspberry Pi. "I found that using Debian on the Pi is a real joy. Easy and simple to set up, familiar environment and all. So I'm keeping it.

"This concept is about to be overshadowed, however, by my growing like of FreeBSD lately..."


Thanks to long-time Slashdot reader walterbyrd for sharing the article.

They create a dedicated desktop icon for your favorite web-based application — a simplified browser that opens to that single URL. Yet while Linux usually offers the same functionality as other operating systems, "Peppermint OS's Ice and its successor Kumo are the only free software versions of Site-Specific Browsers available on Linux," according to Linux magazine.

"Fortunately for those who want this functionality, Peppermint OS is a Debian derivative, and both can be installed on Debian and most other derivatives." Since SSBs first appeared in 2005, they have been available on both Windows and macOS. On Linux, however, the availability has come and gone. On Linux, Firefox once had an SSB mode, but it was discontinued in 2020 on the grounds that it had multiple bugs that were time-consuming to fix and there was "little to no perceived user benefit to the feature." Similarly, Chromium once had a basic SSB menu item, Create Application Shortcut, which no longer appears in recent versions. As for GNOME Web's (Epiphany's) Install Site as Web Application, while it still appears in the menu, it is no longer functional. Today, Linux users who want to try SSBs have no choices except Ice or Kumo.

Neither Ice or Kumo appears in any repository except Peppermint OS's. But because Peppermint OS installs packages from Debian 12 ("bookworm"), either can be installed to Debian or a derivative... To install successfully, at least one of Firefox, Chrome, Chromium, or Vivaldi also must be installed... Because both Ice and Kumo are written in Python, they can be run on any desktop.
The article concludes that Site-Specific Browsers might make more sense "on a network or in a business where their isolation provides another layer of security. Or perhaps the time for SSBs is past and there's a reason browsers have tried to implement them, and then discarded them."

An anonymous reader quotes a report from The Register: Bruce Perens, one of the founders of the Open Source movement, is ready for what comes next: the Post-Open Source movement. "I've written papers about it, and I've tried to put together a prototype license," Perens explains in an interview with The Register. "Obviously, I need help from a lawyer. And then the next step is to go for grant money." Perens says there are several pressing problems that the open source community needs to address. "First of all, our licenses aren't working anymore," he said. "We've had enough time that businesses have found all of the loopholes and thus we need to do something new. The GPL is not acting the way the GPL should have done when one-third of all paid-for Linux systems are sold with a GPL circumvention. That's RHEL." RHEL stands for Red Hat Enterprise Linux, which in June, under IBM's ownership, stopped making its source code available as required under the GPL. Perens recently returned from a trip to China, where he was the keynote speaker at the Bench 2023 conference. In anticipation of his conversation with El Reg, he wrote up some thoughts on his visit and on the state of the open source software community. One of the matters that came to mind was Red Hat.

"They aren't really Red Hat any longer, they're IBM," Perens writes in the note he shared with The Register. "And of course they stopped distributing CentOS, and for a long time they've done something that I feel violates the GPL, and my defamation case was about another company doing the exact same thing: They tell you that if you are a RHEL customer, you can't disclose the GPL source for security patches that RHEL makes, because they won't allow you to be a customer any longer. IBM employees assert that they are still feeding patches to the upstream open source project, but of course they aren't required to do so. This has gone on for a long time, and only the fact that Red Hat made a public distribution of CentOS (essentially an unbranded version of RHEL) made it tolerable. Now IBM isn't doing that any longer. So I feel that IBM has gotten everything it wants from the open source developer community now, and we've received something of a middle finger from them. Obviously CentOS was important to companies as well, and they are running for the wings in adopting Rocky Linux. I could wish they went to a Debian derivative, but OK. But we have a number of straws on the Open Source camel's back. Will one break it?"

Another straw burdening the Open Source camel, Perens writes, "is that Open Source has completely failed to serve the common person. For the most part, if they use us at all they do so through a proprietary software company's systems, like Apple iOS or Google Android, both of which use Open Source for infrastructure but the apps are mostly proprietary. The common person doesn't know about Open Source, they don't know about the freedoms we promote which are increasingly in their interest. Indeed, Open Source is used today to surveil and even oppress them." Free Software, Perens explains, is now 50 years old and the first announcement of Open Source occurred 30 years ago. "Isn't it time for us to take a look at what we've been doing, and see if we can do better? Well, yes, but we need to preserve Open Source at the same time. Open Source will continue to exist and provide the same rules and paradigm, and the thing that comes after Open Source should be called something else and should never try to pass itself off as Open Source. So far, I call it Post-Open." Post-Open, as he describes it, is a bit more involved than Open Source. It would define the corporate relationship with developers to ensure companies paid a fair amount for the benefits they receive. It would remain free for individuals and non-profit, and would entail just one license. He imagines a simple yearly compliance process that gets companies all the rights they need to use Post-Open software. And they'd fund developers who would be encouraged to write software that's usable by the common person, as opposed to technical experts.

Pointing to popular applications from Apple, Google, and Microsoft, Perens says: "A lot of the software is oriented toward the customer being the product -- they're certainly surveilled a great deal, and in some cases are actually abused. So it's a good time for open source to actually do stuff for normal people." The reason that doesn't often happen today, says Perens, is that open source developers tend to write code for themselves and those who are similarly adept with technology. The way to avoid that, he argues, is to pay developers, so they have support to take the time to make user-friendly applications. Companies, he suggests, would foot the bill, which could be apportioned to contributing developers using the sort of software that instruments GitHub and shows who contributes what to which products. Merico, he says, is a company that provides such software. Perens acknowledges that a lot of stumbling blocks need to be overcome, like finding an acceptable entity to handle the measurements and distribution of funds. What's more, the financial arrangements have to appeal to enough developers. "And all of this has to be transparent and adjustable enough that it doesn't fork 100 different ways," he muses. "So, you know, that's one of my big questions. Can this really happen?" Perens believes that the General Public License (GPL) is insufficient for today's needs and advocates for enforceable contract terms. He also criticizes non-Open Source licenses, particularly the Commons Clause, for misrepresenting and abusing the open-source brand.

As for AI, Perens views it as inherently plagiaristic and raises ethical concerns about compensating original content creators. He also weighs in on U.S.-China relations, calling for a more civil and cooperative approach to sharing technology.

You can read the full, wide-ranging interview here.

"This is a proposed Change for Fedora Linux..." emphasizes its page on the Fedora project Wiki. "As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee."

But Phoronix reports that "One of the latest change proposals filed for Fedora 40 is to unify their /usr/bin and /usr/sbin locations." The change proposal explains:

"The /usr/sbin directory becomes a symlink to bin, which means paths like /usr/bin/foo and /usr/sbin/foo point to the same place. /bin and /sbin are already symlinks to /usr/bin and /usr/sbin, so effectively /bin/foo and /sbin/foo also point to the same place. /usr/sbin will be removed from the default $PATH."

Fedora years ago merged /bin and /usr/bin and as the last step they want to unify /usr/bin and /usr/sbin.
The change proposal argues that with this change, "Fedora becomes more compatible with other distributions."


- We have /sbin/ip while Debian has /bin/ip

- We have /bin/chmem and /bin/isosize, but Debian has /sbin/chmem and /sbin/isosize

- We also have /sbin/{addpart,delpart,lnstat,nstat,partx,ping,rdma,resizepart,ss,udevadm,update-alternatives}, while Debian has those in under /bin, etc.

- Fedora becomes more compatible with Arch, which did the merge a few years ago.


The proposal on the Fedora project Wiki offers this summary: The split between /bin and /sbin is not useful, and also unused. The original split was to have "important" binaries statically linked in /sbin which could then be used for emergency and rescue operations. Obviously, we don't do static linking anymore. Later, the split was repurposed to isolate "important" binaries that would only be used by the administrator. While this seems attractive in theory, in practice it's very hard to categorize programs like this, and normal users routinely invoke programs from /sbin. Most programs that require root privileges for certain operations are also used when operating without privileges. And even when privileges are required, often those are acquired dynamically, e.g. using polkit. Since many years, the default $PATH set for users includes both directories. With the advent of systemd this has become more systematic: systemd sets $PATH with both directories for all users and services. So in general, all users and programs would find both sets of binaries...

Since generally all user sessions and services have both directories in $PATH, this split actually isn't used for anything. Its main effect is confusion when people need to use the absolute path and guess the directory wrong. Other distributions put some binaries in the other directory, so the absolute path is often not portable. Also, it is very easy for a user to end up with /sbin before /bin in $PATH, and for an administrator to end up with /bin before /sbin in $PATH, causing confusion. If this feature is dropped, the system became a little bit simpler, which is useful especially for new users, who are not aware of the history of the split.

It's a geek tradition that started online back in 2000. Programming language "advent calendars" offer daily tips about a programming language (if not a Christmas-themed programming puzzle) -- one a day through December 25th.

And 2023 finds a wide variety of fun sites to choose from:

• li>For example, there's 24 coding challenges at the Advent of JavaScript site (where "each challenge includes all the HTML and CSS you need to get started, allowing you to focus on the JavaScript.") And there's another 24 coding challenges on a related site... Advent of CSS.

• The cyber security training platform "TryHackMe.com" even coded up a site they call "Advent of Cyber," daring puzzle-solvers to "kickstart your cyber security career by engaging in a new, beginner-friendly exercise every day leading up to Christmas!"

• The programming puzzles at Advent of Code are continuing through the 25th (though so far less than 30,000 people have solved both parts of Saturday's challenge.)

• Every year since 2000 there's also been a new edition of the Perl Advent Calendar, and this month Year 23 started off with goodies from Perl's massive module repository, CPAN. (Specifically its elf-themed story references the Music::MelodicDevice::Ornamentation module) -- along with the MIDI::Util library and TiMidity++, a software synthesizer that can play MIDI files without a hardware synthesizer.)

• Meanwhile, since 2009 there's also been an advent calendar for Raku (the programming language formerly known as Perl 6), promising an article a day. (Day One's entry was titled "Rocking Raku Meets Stodgy Debian...")

• James Bennett, from the Django project's core team, is even attempting a Python/Django Advent calendar.

• There's also a JVM advent calendar for the Java Virtual Machine, plus another advent calendar promising daily posts about C#.

• The HTMHell site â" which bills itself as "a collection of bad practices in HTML, copied from real websites" -- is celebrating the season with the "HTMHell Advent Calendar," promising daily articles on security, accessibility, UX, and performance.

Recently the Register pointed out that the new (Debian-based) Raspberry Pi OS 5.0 has "a completely new Wayland desktop environment replacing PIXEL, the older desktop based on LXDE and X.org, augmented with Mutter in its previous release."

And when elementary OS 8 finally arrives, "the development team plans to finally shift to the Wayland display server by default," reports Linux magazine (adding "If you'd like to get early access to daily builds, you can do so by becoming an elementary OS sponsor on GitHub.")

"This is a transition that we have been planning and working towards for several years," writes CEO/co-founder Danielle Foré, "and we're finally in the home stretch... Wayland will bring us improved performance, better app security, and opens the doors to support more complex display setups like mixed DPI multi-monitor setups." There are other things that we're experimenting with, like the possibility of an immutable OS, and there are more mundane things that will certainly happen like shipping Pipewire. You'll also see on the project board that we're looking to replace the onscreen keyboard and it's time to re-evaluate some things like SystemD Boot. You can expect lots more little features to be detailed over the coming months.
Meanwhile, Linux Mint is getting "experimental" Wayland support next month. And also in December, Firefox will let Wayland support be enabled by default.

And last month the Register noted a merge request for GNOME to remove the gnome-xorg.desktop file. "To put this in context, the Fedora project is considering a comparable change: removing or hiding the GNOME on X.org session from the login menu, which is already the plan for the Fedora KDE spin when it moves to KDE version 6, which is still in development."

In Chrome, JavaScript (and WebAssembly) code are both executed by Google's open source V8 engine — which already has garbage-collecting capabilities. "This means developers making use of, for example, PHP compiled to Wasm, end up shipping a garbage collector implementation of the ported language (PHP) to the browser that already has a garbage collector," writes Google developer advocate Thomas Steiner, "which is as wasteful as it sounds."

"This is where WasmGC comes in." WebAssembly Garbage Collection (or WasmGC) is a proposal of the WebAssembly Community Group [which] adds struct and array heap types, which means support for non-linear memory allocation... In simplified terms, this means that with WasmGC, porting a programming language to WebAssembly means the programming language's garbage collector no longer needs to be part of the port, but instead the existing garbage collector can be used.
Sometime on Halloween, Steiner wrote that in Chrome, WebAssembly garbage collection is now enabled by default. But then he explored what this means for high-level programming languages (with their own built-in garbage collection) being compiled into WebAssembly: To verify the real-world impact of this improvement, Chrome's Wasm team has compiled versions of the Fannkuch benchmark (which allocates data structures as it works) from C, Rust, and Java. The C and Rust binaries could be anywhere from 6.1 K to 9.6 K depending on the various compiler flags, while the Java version is much smaller at only 2.3 K! C and Rust do not include a garbage collector, but they do still bundle malloc/free to manage memory, and the reason Java is smaller here is because it doesn't need to bundle any memory management code at all. This is just one specific example, but it shows that WasmGC binaries have the potential of being very small, and this is even before any significant work on optimizing for size.
The blog post includes two examples of WasmGC-ported programming languages in action:

• "One of the first programming languages that has been ported to Wasm thanks to WasmGC is Kotlin in the form of Kotlin/Wasm."

• "The Dart and Flutter teams at Google are also preparing support for WasmGC. The Dart-to-Wasm compilation work is almost complete, and the team is working on tooling support for delivering Flutter web applications compiled to WebAssembly."

Mozilla has some news for users of Debian-based Linux distributions (such as Debian, Ubuntu, Linux Mint, and others): installing, updating, and testing the latest Firefox Nightly builds just got a lot easier. We've set up a new APT repository for you to install Firefox Nightly as a .deb package... These packages are compatible with the same Debian and Ubuntu versions as our traditional binaries. If you've previously used our traditional binaries (distributed as .tar.bz2 archives), switching to Mozilla's APT repository allows Firefox to be installed and updated like any other application... You will not have to restart Firefox after updating the package with APT...

For those of you who would like to use Firefox Nightly in a different language than American English, we have also created .deb packages containing the Firefox language packs.
Some context from 9to5Linux: Back in April, I reported that Mozilla was offering a DEB package of the Firefox 113 release during the beta testing phase. Unfortunately, that was the only time a DEB package was available for download and, of course, it didn't make it into the final release of Firefox 113, nor future releases. It would appear that Mozilla needed more time to work on the DEB package for Debian and Ubuntu-based distributions, and it looks like it will finally become a thing starting with an upcoming Firefox release, like Firefox 121 or later...

Using the DEB package over Snap or the official binary package offers some benefits like better performance due to advanced compiler-based optimizations, hardened binaries with all security flags enabled, access to the latest Firefox releases as fast as possible [because the .deb is integrated into Firefox's release process], and you won't have to create your own .desktop file anymore.

Thursday ZDNet reported... As security holes go, CVE-2023-4911, aka "Looney Tunables," isn't horrid. It has a Common Vulnerability Scoring System score of 7.8, which is ranked as important, not critical.

On the other hand, this GNU C Library's (glibc) dynamic loader vulnerability is a buffer overflow, which is always big trouble, and it's in pretty much all Linux distributions, so it's more than bad enough. After all, its discoverers, the Qualys Threat Research Unit, were able to exploit "this vulnerability (a local privilege escalation that grants full root privileges) on the default installations of Fedora 37 and 38, Ubuntu 22.04 and 23.04, and Debian 12 and 13." Other distributions are almost certainly vulnerable to attack. The one major exception is the highly secure Alpine Linux. Thanks to this vulnerability, it's trivial to take over most Linux systems as a root user. As the researchers noted, this exploitation method "works against almost all of the SUID-root programs that are installed by default on Linux...."

The good news is that Red Hat, Ubuntu, Debian, and Gentoo have all released their own updates. In addition, the upstream glibc code has been patched with the fix. If you can't patch it, Red Hat has a script that should work on most Linux systems to mitigate the problem by setting your system to terminate any setuid program invoked with GLIBC_TUNABLES in the environment.

Liam Proven writes via The Register: Steam OS is the Arch-based distro for a handheld Linux games console, and Valve is aggressively pushing Linux's usability and Windows interoperability for the device. Two unusual companies, Valve Software and Igalia, are working together to improve the Linux-based OS of the Steam Deck handheld games console. The device runs a Linux distro called Steam OS 3.0, but this is a totally different distro from the original Steam OS it announced a decade ago. Steam OS 1 and 2 were based on Debian, but Steam OS 3 is based on Arch Linux, as Igalia developer Alberto Garcia described in a talk entitled How SteamOS is contributing to the Linux ecosystem.

He explained that although Steam OS is built from some fairly standard components -- the normal filesystem hierarchy, GNU user space, systemd and dbus -- Steam OS has quite a few unique features. It has two distinct user interfaces: by default, it starts with the Steam games launcher, but users can also choose an option called Switch to Desktop, which results in a regular KDE Plasma desktop, with the ability to install anything: a web browser, normal Linux tools, and non-Steam games.

Obviously, though, Steam OS's raison d'etre is to run Steam games, and most of those are Windows games which will never get native Linux versions. Valve's solution is Proton, an open-source tool to run Windows games on Linux. It's formed from a collection of different FOSS packages, notably: [Wine, DXVK, VKD3D-Proton, and GStreamer]. The result is a remarkable degree of compatibility for some of the most demanding Windows apps around [...]. You can view Garcia's 49-page presentation here (PDF).

This week saw the public beta-testing release of "Linux Mint Debian Edition". Besides listing download locations, its release notes also list out the project's three goals:

- Ensure Linux Mint would be able to continue to deliver the same user experience
- See how much work would be involved if Ubuntu was ever to disappear.
- Guarantee the software we develop is compatible outside of Ubuntu.

9to5Linux reports: Based on the Debian GNU/Linux 12 "Bookworm" operating system series, Linux Mint Debian Edition 6 is powered by the long-term supported Linux 6.1 LTS kernel series and features the latest Cinnamon 5.8 desktop environment that was introduced with the Linux Mint 21.2 "Victoria" release in July 2023⦠[T]his release comes with a new look and feel thanks to newly added folder icons with different color variants, improved consistency of tooltips to look the same across different apps and desktops, support for symbolic icons that adapt to their background, and full support for HEIF and AVIF

Debian blog: Over 30 years ago the late Ian Murdock wrote to the comp.os.linux.development newsgroup about the completion of a brand-new Linux release which he named "The Debian Linux Release." He built the release by hand, from scratch, so to speak. Ian laid out guidelines for how this new release would work, what approach the release would take regarding its size, manner of upgrades, installation procedures; and with great care of consideration for users without Internet connection. Unaware that he had sparked a movement in the fledgling F/OSS community, Ian worked on and continued to work on Debian. The release, now aided by volunteers from the newsgroup and around the world, grew and continues to grow as one of the largest and oldest FREE operating systems that still exist today.

Debian at its core is comprised of Users, Contributors, Developers, and Sponsors, but most importantly, People. Ians drive and focus remains embedded in the core of Debian, it remains in all of our work, it remains in the minds and hands of the users of The Universal Operating System. The Debian Project is proud and happy to share our anniversary not exclusively unto ourselves, instead we share this moment with everyone, as we come together in celebration of a resounding community that works together, effects change, and continues to make a difference, not just in our work but around the world. Debian is present in cluster systems, datacenters, desktop computers, embedded systems, IoT devices, laptops, servers, it may possibly be powering the web server and device you are reading this article on, and it can also be found in Spacecraft.

Why aren't more people using Linux on the desktop? Slashdot reader technology_dude shares one solution: Jack Wallen at ZDNet says establishing an "official" version of Linux may (or may not) help Linux on the desktop increase the number of users, mostly as someplace to point new users. It makes sense to me. What does Slashdot think and what would be the challenges, other than acceptance of a particular flavor?
Wallen argues this would also create a standard for hardware and software vendors to target, which "could equate to even more software and hardware being made available to Linux." (And an "official" Linux might also be more appealing to business users.) Wallen suggests it be "maintained and controlled by a collective of people from users, developers, and corporations (such as Intel and AMD) with a vested interest in the success of this project... There would also be corporate backing for things like marketing (such as TV commercials)." He also suggests basing it on Debian, and supporting both Snap and Flatpak...

In comments on the original submission, long-time Slashdot reader bobbomo points instead to kernel.org, arguing "There already is an official version of Linux called mainline. Everything else is backports." And jd (Slashdot user #1,658) believes that the official Linux is the Linux Standard Base. "All distributions, more-or-less, conform to the LSB, which gives you a pseudo 'official' Linux. About the one variable is the package manager. And there are ways to work around that."

Unfortunately, according to Wikipedia... The LSB standard stopped being updated in 2015 and current Linux distributions do not adhere to or offer it; however, the lsb_release command is sometimes still available.[citation needed] On February 7, 2023, a former maintainer of the LSB wrote, "The LSB project is essentially abandoned."
That post (on the lsb-discuss mailing list) argues the LSB approach was "partially superseded" by Snaps and Flatpaks (for application portability and stability). And of course, long-time Slashdot user menkhaura shares the obligatory XKCD comic...

It's not exactly the same thing, but days after ZDNet's article, CIQ, Oracle, and SUSE announced the Open Enterprise Linux Association, a new collaborative trade association to foster "the development of distributions compatible with Red Hat Enterprise Linux."

So where does that leave us? Share your own thoughts in the comments.

And should there be an "official" version of Linux?

Last weekend in Portland, Oregon, the Software Freedom Conservancy hosted a new conference called the Free and Open Source Software Yearly.

And long-time free software activist Bradley M. Kuhn (currently a policy fellow/hacker-in-residence for the Software Freedom Conservancy) hosted a lively panel discussion on "the recent change" to public source code releases for Red Hat Enterprise Linux which shed light on what may happen next. The panel also included:

• benny Vasquez, the Chair of the AlmaLinux OS Foundation
• Jeremy Alison, Samba co-founder and software engineer at CIQ (focused on Rocky Linux). Allison is also Jeremy Allison - Sam Slashdot reader #8,157.
• James (Jim) Wright, Oracle's chief architect for Open Source policy/strategy/compliance/alliances

"Red Hat themselves did not reply to our repeated requests to join us on this panel... SUSE was also invited but let us know they were unable to send someone on short notice to Portland for the panel."

One interesting audience question for the panel came from Karsten Wade, a one-time Red Hat senior community architect who left Red Hat in April after 21 years, but said he was "responsible for bringing the CentOS team onboard to Red Hat." Wade argued that CentOS "was always doing a clean rebuild from source RPMS of their own..." So "isn't all of this thunder doing Red Hat's job for them, of trying to get everyone to say, 'This thing is not the equivalent to RHEL.'"

In response Jeremy Alison made a good point. "None of us here are the arbiters of whether it's good enough of a rebuild of Red Hat Linux. The customers are the arbiters." But this led to an audience member asking a very forward-looking question: what are the chances the community could adopt a new (and open) enterprise Linux standard that distributions could follow. AlmaLinux's Vasquez replied, "Chances are real high... I think everyone sees that as the obvious answer. I think that's the obvious next step. I'll leave it at that." And Oracle's Wright added "to the extent that the market asks us to standardize? We're all responsive."

When asked if they'd consider adding features not found in RHEL ("such as high-security gates through reproducible builds") AlmaLinux's Vasquez said "100% -- yeah. One of the things that we're kind of excited about is the opportunities that this opens for us. We had decided we were just going to focus on this north star of 1:1 Red Hat no matter what -- and with that limitation being removed, we have all kinds of options." And CIQ's Alison said "We're working on FIPS certification for an earlier version of Rocky, that Red Hat, I don't believe, FIPS certified. And we're planning to release that."

AlmaLinux's Vasquez emphasized later that "We're just going to build Enterprise Linux. Red Hat has done a great job of establishing a fantastic target for all of us, but they don't own the rights to enterprise Linux. We can make this happen, without forcing an uncomfortable conversation with Red Hat. We can get around this."

And Alison later applied a "Star Wars" quote to Red Hat's predicament. "The more things you try and grab, the more things slip through your fingers." That is, "The more somebody tries to exert control over a codebase, the more the pushback will occur from people who collaborate in that codebase." AlmaLinux's Vasquez also said they're already "in conversations" with independent software vendors about the "flow of support" into non-Red Hat distributions -- though that's always been the case. "Finding ways to reduce the barrier for those independent software vendors to add official support for us is, like, maybe more cumbersome now, but it's the same problem that we've had..."

Early in the discussion Oracle's Jim Wright pointed out that even Red Hat's own web site defines open source code as "designed to be publicly accessible — anyone can see, modify, and distribute the code as they see fit." ("Until now," Wright added pointedly...) There was some mild teasing of Oracle during the 50-minute discussion -- someone asked at one point if they'd re-license their proprietary implementation of ZFS under the GPL. But at the end of the panel, Oracle's Jim Wright still reminded the audience that "If you want to work on open source Linux, we are hiring."

Read Slashdot's transcript of highlights from the discussion.

williamyf writes: Today, Mozilla released Firefox 115. Changes most visible to users include:

But the most important feature is that this release is the new ESR. Why this is important? y'all ask, well: