From a report: According to Statcounter, which should be taken with a pinch of salt of course like any sampling, the Linux share on the desktop hit nearly 4% in December 2023. Last month was a record too and a clear trend over time, as going back a couple of years, it was rarely coming close to 2% but now it's repeatedly nearing 4% so it's quite a good sign overall.

The latest from Statcounter shows for all of 2023 below:

January - 2.91%
February - 2.94%
March - 2.85%
April - 2.83%
May - 2.7%
June - 3.07%
July - 3.12%
August - 3.18%
September - 3.02%
October - 2.92%
November - 3.22%
December - 3.82%

Looking at December it shows Windows rising too, with macOS dropping down. If we actually take ChromeOS directly into the Linux numbers for December 2023 the overall number would actually be 6.24% (ChromeOS is Linux after all).

While Gentoo Linux is best-known as source-based Linux distribution, "our package manager, Portage, already for years also has support for binary packages," according to its web page. It notes that source- and binary-based package installations can be freely mixed.

But now... To speed up working with slow hardware and for overall convenience, we're now also offering binary packages for download and direct installation! For most architectures, this is limited to the core system and weekly updates — not so for amd64 and arm64 however. There we've got a stunning >20 GByte of packages on our mirrors, from LibreOffice to KDE Plasma and from Gnome to Docker. Gentoo stable, updated daily. Enjoy!
"We have a rather neat binary package guide on our Wiki that goes into much more detail..." the announcement points out.

The packages are cryptographically signed with the same key as the stages.

Thanks to Heraklit (Slashdot reader #29,346) for sharing the news.

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

Melbourne-based developer xssfox has championed a unique "diagonal mode" for monitors by utilizing Linux's xrandr (x resize and rotate) tool, finding a 22-degree tilt to the left to be the ideal angle for software development on her 32:9 aspect ratio monitor. As Tom's Hardware notes, Linux is the "only OS to support a diagonal monitor mode, which you can customize to any tilt of your liking." It begs the question, could 2024 be the year of the Linux diagonal desktop? From the report: Xssfox devised a consistent method to appraise various screen rotations, working through the staid old landscape and portrait modes, before deploying xrandr to test rotations like the slightly skewed 1 degree and an indecisive 45 degrees. These produced mixed results of questionable benefits, so the search for the Goldilocks solution continued. It turns out that a 22-degree tilt to the left was the sweet spot for xssfox. This rotation delivered the best working screen space on what looks like a 32:9 aspect ratio monitor from Dell. "So this here, I think, is the best monitor orientation for software development," the developer commented. "It provides the longest line lengths and no longer need to worry about that pesky 80-column limit."

If you have a monitor with the same aspect ratio, the 22-degree angle might work well for you, too. However, people with other non-conventional monitor rotation needs can use xssfox's javascript calculator to generate the xrandr command for given inputs. People who own the almost perfectly square LG DualUp 28MQ780 might be tempted to try 'diamond mode,' for example. We note that Windows users with AMD and Nvidia drivers are currently shackled to applying screen rotations using 90-degree steps. MacOS users apparently face the same restrictions.

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

Phoronix's Michael Larabel writes: With patches pending for creating an Acer Aspire 1 embedded controller driver, this Qualcomm Snapdragon powered ARM laptop has "almost full support" with the upstream Linux kernel. The Acer Aspire 1 (A114-61) is an aging ARM laptop design built on the Snapdragon 7c Gen1. It's no longer the latest and greatest with it being a two year old device, but for those wanting a low-power and long-battery-life laptop, the Acer Aspire 1 still has some potential for Linux enthusiasts.

Over the course of this year this eight-core ARM laptop has been seeing work on mainline Linux kernel support. Since Linux 6.5 much of that support has been in place while some bits remain. Sent out recently was this patch series creating an embedded controller (EC) driver for the Acer Aspire 1. This EC driver gets battery and charger monitoring working along with USB Type-C DP Alt Mode HPD monitoring, lid status detection, and some keyboard configuration. The EC functionality on the Acer Aspire 1 is implemented in ACPI but sadly ACPI cant be used to boot Linux on these Qualcomm devices -- thus leading to this new "acer-aspire1-ec" driver being created.

prisoninmate shares a report from 9to5Linux: Announced in early August and initially planned for the end of the month, the Fedora Asahi Remix distribution is finally here for those who want to install the Fedora Linux operating system on their Apple Silicon Macs. Previously a remix of Arch Linux ARM, the Fedora Asahi Remix distribution is the result of a multi-year collaboration between the Asahi Linux project and the Fedora Project, enabling you to have a proper daily driver on your Apple Silicon Mac thanks to Fedora Linux's excellent 64-bit ARM support.

The distro is based on the latest Fedora Linux 39 release and ships with the KDE Plasma 5.27 LTS desktop environment by default, using Wayland. This promises a smooth Linux desktop experience on Apple hardware similar to macOS. Fedora Asahi Remix also comes with XWayland for those who want to run X11 apps. In addition, it features non-conformant OpenGL 3.3 support including GPU-accelerated geometry shaders and transform feedback, PipeWire by default with WirePlumber, as well as the Calamares graphical installer. You can download and install Fedora Asahi Remix here.

Linux magazine interviewed an AlmaLinux official about what happened after their distro pivoted to binary compatibility with Red Hat Enterprise Linux rather than being a downstream build: Linux Magazine: What prompted AlmaLinux to choose ABI over 1:1 compatibility with RHEL?

benny Vasquez, chair of the AlmaLinux OS Foundation: The short answer is our users. Overwhelmingly, our users made it clear that they chose AlmaLinux for its ease of use, the security and stability that it provides, and the backing of a diverse group of sponsors. All of that together meant that we didn't need to lock ourselves into copying RHEL, and we could continue to provide what our users needed.

Moreover, we needed to consider what our sponsors would be able to help us provide, and how we could best serve the downstream projects that now rely on AlmaLinux. The rippling effects of any decision that we make are beyond measure at this point, so we consider all aspects of our impact and then move forward with confidence and intention.

LM: How did AlmaLinux's mission of improving the Linux ecosystem for everyone influence this decision?

bV: We strongly believe that the soul of open source means working together, providing value where there is a gap, and helping each other solve problems. If we participate in an emotional reaction to a business's change, we will then be distracted and potentially hurt users and the Enterprise Linux ecosystem overall. By remaining focused on what is best (though not easiest), and adapting to the ecosystem as it is today, we will provide a better and more stable operating system.

LM: What opportunities does the ABI route offer over 1:1 compatibility?

bV: By liberating ourselves from the 1:1 promise, we have been able to do a few small things that have proven to be a good testing ground for what will come in the future. Specifically, we shipped a couple of smallish, but extremely important, security patches ahead of Red Hat, offering quicker security to the users of AlmaLinux... This also opens the door for other features and improvements that we could add back in or change, as our users need. We have already seen greater community involvement, especially around these ideas.

LM: Does the ABI route pose any extra challenges?

bV: The obvious one is that building from CentOS Stream sources takes more effort, but I think the more important challenge (and the one that will only be solved with consistency over time) is the one of proving that we will be able to deliver on the promise... We will continue on our goal of becoming the home for all users that need Enterprise Linux for free, but in the next year I expect that we will see an expansion in the number of kernels we support and see some new and exciting SIGs spun up around other features or use cases, as the community continues to standardize on how to achieve their goals collectively.
Linux magazine notes that in August AlmaLinux added two new repositories, Testing and Synergy. "Testing, currently available for AlmaLinux 8 and 9, offers security updates before they are approved and implemented upstream. Synergy contains packages requested by community members that currently aren't available in RHEL or Extra Packages for Enterprise Linux (EPEL, a set of extra software packages maintained by the Fedora SIG that are not available in RHEL or CentOS Stream)."

The article also points out that "On the upside, AlmaLinux can now include comments in their patches for greater transparency. Users will see where the patch comes from, which was not an option before."

Vasquez tells the magazine, "I think folks will be seriously happy about what they find as we release the new versions, namely, the consistency, stability, and security that they've come to expect from us."

ZDNet reports that "At the Linux Foundation's Open Source Summit Japan, Linus Torvalds and his good friend Dirk Hohndel, the head of Verizon open source, talked about the current state of Linux: Speaking of maintainers, Hohndel brought up the question of "maintainer fatigue and how draining and stressful this role is...." Torvalds replied, "It's much easier to find developers; we have a lot of developers. Some people think that you have to be a superdeveloper who can do everything to be a maintainer, but that's not actually true...."

Hohndel commented that the aging of the kernel community is a "double-edged sword." Torvalds agreed, but he noted that "one of the things I liked about the Rust side of the kernel, was that there was one maintainer who was clearly much younger than most of the maintainers. We can clearly see that certain areas in the kernel bring in more young people...."

Hohndel and Torvalds also talked about the use of the Rust language in the Linux kernel. Torvalds said, "It's been growing, but we don't have any part of the kernel that really depends on Rust yet. To me, Rust was one of those things that made technical sense, but to me personally, even more important was that we need to not stagnate as a kernel and as developers." That said, Torvalds continued, "Rust has not really shown itself as the next great big thing. But I think during next year, we'll actually be starting to integrate drivers and some even major subsystems that are starting to use it actively. So it's one of those things that is going to take years before it's a big part of the kernel. But it's certainly shaping up to be one of those."
Torvalds also said he enjoyed the fact that open source "has become the standard within the industry."

But later Hohndel, calling AI "autocorrect on steroids," asked Torvalds if he thought he'd ever see submissions of LLM-written code. "I'm convinced it's gonna happen. And it may well be happening already, maybe on a smaller scale where people use it more to help write code." But, unlike many people, Torvalds isn't too worried about AI. "It's clearly something where automation has always helped people write code. This is not anything new at all...."

But, "What about hallucinations?," asked Hohndel. Torvalds, who will never stop being a little snarky, said, "I see the bugs that happen without AI every day. So that's why I'm not so worried. I think we're doing just fine at making mistakes on our own."

An anonymous reader quotes a report from Ars Technica: Windows' infamous "Blue Screen of Death" is a bit of a punchline. People have made a hobby of spotting them out in the wild, and in some circles, they remain a byword for the supposed flakiness and instability of PCs. To this day, networked PCs in macOS are represented by beige CRT monitors displaying a BSOD. But the BSOD is supposed to be a diagnostic tool, an informational screen that technicians can use to begin homing in on the problem that caused the crash in the first place; that old Windows' BSOD error codes were often so broad and vague as to be useless doesn't make the idea a bad one. Today, version 255 of the Linux systemd project honors that original intent by adding a systemd-bsod component that generates a full-screen display of some error messages when a Linux system crashes.

The systemd-bsod component is currently listed as "experimental" and "subject to change." But the functionality is simple: any logged error message that reaches the LOG_EMERG level will be displayed full-screen to allow people to take a photo or write it down. Phoronix reports that, as with BSODs in modern Windows, the Linux version will also generate a QR code to make it easier to look up information on your phone.

"Red Hat is going to do away with the X.Org server and support Wayland and XWayland for apps that currently (or only) run on X11," writes Slashdot reader motang. Red Hat's Carlos Soriano Sanchez confirmed on the Red Hat blog: "The result of this evaluation is that, while there are still some gaps and applications that need some level of adaptation, we believe the Wayland infrastructure and ecosystem are in good shape, and that we're on a good path for the identified blockers to be resolved by the time RHEL 10 is out, planned to be released on the first half of 2025.

With this, we've decided to remove Xorg server and other X servers (except Xwayland) from RHEL 10 and the following releases. Xwayland should be able to handle most X11 clients that won't immediately be ported to Wayland, and if needed, our customers will be able to stay on RHEL 9 for its full life cycle while resolving the specifics needed for transitioning to a Wayland ecosystem. It's important to note that "Xorg Server" and "X11" are not synonymous, X11 is a protocol that will continue to be supported through Xwayland, while the Xorg Server is one of the implementations of the X11 protocol.
[...]
This decision will allow us to focus our efforts starting from RHEL 10 solely on a modern stack and ecosystem. This means we will be able to tackle problems such as HDR, increased security, setups with mixed low and high density displays or very high density displays, better GPU/Display hot-plugging, better gestures and scrolling, and so on. We are confident that Wayland will provide a solid platform and we're excited to work with the community and all of our partners and customers on building the future for Linux."

Last January the Register reported that the Budgie desktop environment was planning to switch from using GNOME to Enlightenment. But this week Budgie's project lead David Mohammed and packaging guru Sam Lane "passed on news of a rift — and indeed possible divorce — between Budgie and Enlightenment," the Register reported. "And it's caused by Wayland." The development team of the Budgie desktop is changing course and will work with the Xfce developers toward Budgie's Wayland future...

While Enlightenment does have some Wayland support, in the project's own words this is "still considered experimental and not for regular end users." Mohammed told us... "Progress though towards a full implementation currently doesn't fit into the deemed urgent nature to move to Wayland (Red Hat dropping further X11 development, and questions as to any organisation stepping up, etc.)"

So, instead, Budgie is exploring different ways to build a Wayland-only environment. For now, as we mentioned when looking at Ubuntu's 23.10 release, there's a new windowing library, Magpie. Magpie 0.9 is what the project describes as "a soft-fork of GNOME's mutter at version 43" — the term soft fork meaning it's a temporary means to an end, rather than intended to form an on-going independent continuation.

For the future, though, Mohammed told us... "[T]he Budgie team has been evaluating options to move forward. XFCE are doing some really great work in this area with libxfce4windowing — a compatibility layer bridging Wayland and X11, allowing the move in a logical direction without needing a big-bang approach. To date, most of the current codebase has already been reworked and is ready for a Wayland-only approach without impacting further development and enhancements."
Mohammed later told the Register, "It makes sense for the more dynamic smaller projects to work together where there are shared aims."

An anonymous reader shared this report from ZDNet: At the Linux Plumbers Conference, the invite-only meeting for the top Linux kernel developers, ByteDance Linux Kernel Engineer Cong Wang, proposed that we use AI and machine learning to tune the Linux kernel for the maximum results for specific workloads... There are thousands of parameters. Even for a Linux expert, tuning them for optimal performance is a long, hard job. And, of course, different workloads require different tunings for different sets of Linux kernel parameters... What ByteDance is working on is a first attempt to automate the entire Linux kernel parameter tuning process with minimal engineering efforts.

Specifically, ByteDance is working on tuning Linux memory management. ByteDance has found that with machine learning algorithms, such as Bayesian optimization, automated tuning could even beat most Linux kernel engineers. Why? Well, the idea, as Wang wryly put it, "is not to put Linux kernel engineers out of business." No, the goal is "to liberate human engineers from tuning performance for each individual workload. While making better decisions with historical data, which humans often struggle with. And, last, but never least, find better solutions than those we come up with using our current trial and error, heuristic methods.
In short, ByteDance's system optimizes resource usage by making real-time adjustments to things like CPU frequency scaling and memory management.

ZDNet shares on update on "Rust in Linux: Where we are and where we're going next," citing a talk at the Linux Plumbers Conference in Richmond, Virginia by Linux/Rust developer Miguel Ojeda: In brief, Rust Linux is continuing to mature and is getting strong support from developers and vendors, such as Cisco, Samsung, and Canonical... Rust is taking the steps it needs to become — along with C — a fully-fledged member of the Linux language toolchain... That's not to say that we're ready to retire C for Rust just yet. In fact, that day is unlikely ever to come. But Rust is definitely on its way to becoming an important language for Linux development...

As for the day-to-day work that's required to make Rust fully integrated with Linux, the "official" website of the initiative is now the self-explanatory Rust for Linux. This site is your one-stop source for all things Rust on Linux... However, the move forward has not been straightforward. Rust on Linux developers have discovered some problems along the way. For example, while deadlocks, when two or more threads are waiting on the other to finish, are safe in Rust, because they don't result in undefined behavior, they're not safe in the Linux kernel. The programmers are working on fixing this issue...

A related issue is that there's growing interest in backporting Rust support into long-term support (LTS) versions of Linux, specifically 5.15 and 6.1. Some people are especially showing interest in the super LTS Linux 6.1 kernel. However, Linux doesn't generally allow backports into LTS Linuxes. So, if you really, really want fully featured Rust support in an older LTS kernel, you're going to need to pay for it in one way or the other. Another general rule that Rust developers have decided they're going to try to "break" is the rule against duplicate drivers. Usually, no one wants anyone wasting time reinventing the wheel, but some maintainers are open to the idea of experimenting with Rust, by starting simple with a driver they're already familiar with...

These movements are small steps forward, but they're all critical for making Rust equal to C as a Linux programming language.

Canonical hosted an amusingly failure-filled demo of its new easy-to-install, Ubuntu-powered tool for building small-to-medium scale, on-premises high-availability clusters, Microcloud, at an event in London yesterday. From a report: The intro to the talk leaned heavily on Canonical's looming 20th anniversary, and with good reason. Ubuntu has carved out a substantial slice of the Linux market for itself on the basis of being easier to use than most of its rivals, at no cost -- something that many Linux players still seem not to fully comprehend. The presentation was as buzzword-heavy as one might expect, and it's also extensively based on Canonical's in-house tech, such as the LXD containervisor, Snap packaging, and, optionally, the Ubuntu Core snap-based immutable distro. (The only missing buzzword didn't crop up until the Q&A session, and we were pleased by its absence: it's not built on and doesn't use Kubernetes, but you can run Kubernetes on it if you wish.)

We're certain this is going to turn off or alienate a lot of the more fundamentalist Penguinistas, but we are equally sure that Canonical won't care. In the immortal words of Kevin Smith, it's not for critics. Microcloud combines several existing bits of off-the-shelf FOSS tech in order to make it easy to link from three to 50 Ubuntu machines into an in-house, private high-availability cluster, with live migration and automatic failover. It uses its own LXD containervisor to manage nodes and workloads, Ceph for distributed storage, OpenZFS for local storage, and OVN to virtualize the cluster interconnect. All the tools are packaged as snaps. It supports both x86-64 and Arm64 nodes, including Raspberry Pi kit, and clusters can mix both architectures. The event included several demonstrations using an on-stage cluster of three ODROID machines with "Intel N6005" processors, so we reckon they were ODROID H3+ units -- which we suspect the company chose because of their dual Ethernet connections.

In Raleigh, North Carolina — the home of Red Hat — local newspaper the News & Observer takes an in-depth look at the "announcement that split the open source software community." (Alternate URL here.) [M]any saw Red Hat's decision to essentially paywall Red Hat Enterprise Linux, or RHEL, as sacrilegious... Red Hat employees were also conflicted about the new policy, [Red Hat Vice President Mike] McGrath acknowledged. "I think a lot of even internal associates didn't fully understand what we had announced and why," he said...

At issue, he wrote, were emerging competitors who copied Red Hat Enterprise Linux, down to even the code's mistakes, and then offered these Red Hat-replicas to customers for free. These weren't community members adding value, he contended, but undercutting rivals. And in a year when Red Hat laid off 4% of its total workforce, McGrath said, the company could not justify allowing this to continue. "I feel that while this was a difficult decision between community and business, we're still on the right side of it," he told the News & Observer. Not everyone agrees...

McGrath offered little consolation to customers who were relying on one-for-one versions of RHEL. They could stay with the downstream distributions, find another provider, or pay for Red Hat. "I think (people) were just so used to the way things work," he said. "There's a vocal group of people that probably need Red Hat's level of support, but simply don't want to pay for it. And I don't really have... there's not much we can tell them."

Since its RHEL decision, Red Hat has secured several prominent partnerships. In September, the cloud-based software company Salesforce moved 200,000 of its systems from the free CentOS Linux to Red Hat Enterprise Linux. The same month, Red Hat announced RHEL would begin to support Oracle's cloud infrastructure. Oracle was one of the few major companies this summer to publicly criticize Red Hat for essentially paywalling its most popular code. On Oct. 24, Red Hat notched another win when the data security firm Cohesity said it would also ditch CentOS Linux for RHEL.
The article delves into the history of Red Hat — and of Linux — before culminating with this quote from McGrath. "I think long gone are the times of that sort of romantic view of hobbyists working in their spare time to build open source. I think there's still room for that — we still have that — but quite a lot of open source is now built from people that are paid full time."

Red Hat likes to point out that 90% of Fortune 500 companies use its services, according to the article. But it also quotes Jonathan Wright, infrastructure team lead at the nonprofit AlmaLinux, as saying that Red Hat played "fast and loose" with the GPL. The newspaper then adds that "For many open source believers, such a threat to its hallowed text isn't forgivable."

It happened a quarter of a century ago. The New York Times wrote that "An internal memorandum reflecting the views of some of Microsoft's top executives and software development managers reveals deep concern about the threat of free software and proposes a number of strategies for competing against free programs that have recently been gaining in popularity." The memo warns that the quality of free software can meet or exceed that of commercial programs and describes it as a potentially serious threat to Microsoft. The document was sent anonymously last week to Eric Raymond, a key figure in a loosely knit group of software developers who collaboratively create and distribute free programs ranging from operating systems to Web browsers. Microsoft executives acknowledged that the document was authentic...

In addition to acknowledging that free programs can compete with commercial software in terms of quality, the memorandum calls the free software movement a "long-term credible" threat and warns that employing a traditional Microsoft marketing strategy known as "FUD," an acronym for "fear, uncertainty and doubt," will not succeed against the developers of free software. The memorandum also voices concern that Linux is rapidly becoming the dominant version of Unix for computers powered by Intel microprocessors.

The competitive issues, the note warns, go beyond the fact that the software is free. It is also part of the open-source software, or O.S.S., movement, which encourages widespread, rapid development efforts by making the source code — that is, the original lines of code written by programmers — readily available to anyone. This enables programmers the world over to continually write or suggest improvements or to warn of bugs that need to be fixed. The memorandum notes that open software presents a threat because of its ability to mobilize thousands of programmers. "The ability of the O.S.S. process to collect and harness the collective I.Q. of thousands of individuals across the Internet is simply amazing," the memo states. "More importantly, O.S.S. evangelization scales with the size of the Internet much faster than our own evangelization efforts appear to scale."
Back in 1998, Slashdot's CmdrTaco covered the whole brouhaha — including this CNN article: A second internal Microsoft memo on the threat Linux poses to Windows NT calls the operating system "a best-of-breed Unix" and wonders aloud if the open-source operating system's momentum could be slowed in the courts.

As with the first "Halloween Document," the memo — written by product manager Vinod Valloppillil and another Microsoft employee, Josh Cohen — was obtained by Linux developer Eric Raymond and posted on the Internet. In it, Cohen and Valloppillil, who also authored the first "Halloween Document," appear to suggest that Microsoft could slow the open-source development of Linux with legal battles. "The effect of patents and copyright in combating Linux remains to be investigated," the duo wrote.
Microsoft's slogain in 1998 was "Where do you want to go today?" So Eric Raymond published the documents on his web site under the headline "Where will Microsoft try to drag you today? Do you really want to go there?"

25 years later, and it's all still up there and preserved for posterity on Raymond's web page — a collection of leaked Microsoft documents and related materials known collectively as "the Halloween documents." And Raymond made a point of thanking the writers of the documents, "for authoring such remarkable and effective testimonials to the excellence of Linux and open-source software in general."

Thanks to long-time Slashdot reader mtaht for remembering the documents' 25th anniversary...

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.

Long-time Slashdot reader williamyf writes: In the ongoing battle between Red Hat and other "Enterprise Linux -- RHEL compatible" distros, today the OpenELA (Open Enterprise Linux Association), a body Consisting of CIQ (stewards of Rocky Linux), Oracle and Suse, released source code for a generic "Enterprise Linux Distro" (Sources available for RHEL 8 and RHEL 9). A Steering committee for the foundation was also formed.

War between Red Hat and what they call "clones" (mostly Oracle; CentOS, Rocky, Alma and others seem to be collateral damage) has been raging on for years. First, in 2011, Red Hat changed the way they distributed kernel patches. Then, in 2014, Red Hat absorbed CentOS. In 2019 Red Hat transformed CentOS to CentOS stream, and shortened support Timetables for CentOS 8, all out of the blue. Then, in 2023, RedHat severely restricted source code access to non-customers.

What will be RedHat's reaction to this development? My bet is that they will stop to release source code of distro modules under BSD, MIT, APACHE and MPL Licenses for RHEL and in certain Windows for CentOS Stream. What is your bet? Let us know in the comments.

Officially, Intel's Itanium chips and their IA-64 architecture died back in 2021, when the company shipped its last processors. But failed technology often dies a million little deaths. From a report: To name just a few: Itanium also died in 2013, when Intel effectively decided to stop improving it; in 2017, when the last new Itanium CPUs shipped; in 2020, when the last Itanium-compatible version of Windows Server stopped getting updates; and in 2003, when AMD introduced a 64-bit processor lineup that didn't break compatibility with existing 32-bit x86 operating systems and applications.

Itanium is dying another death in the next version of the Linux kernel. According to Phoronix, all code related to Itanium support is being removed from the kernel in the upcoming 6.7 release after several months of deliberation. Linus Torvalds removed some 65,219 lines of Itanium-supporting code in a commit earlier this week, giving the architecture a "well-earned retirement as planned."