Jeremy Allison — Sam (Slashdot reader #8,157) is a Distinguished Engineer at Rocky Linux creator CIQ. This week he published a blog post responding to promises of Linux distros "carefully selecting only the most polished and pristine open source patches from the raw upstream open source Linux kernel in order to create the secure distribution kernel you depend on in your business."

But do carefully curated software patches (applied to a known "frozen" Linux kernel) really bring greater security? "After a lot of hard work and data analysis by my CIQ kernel engineering colleagues Ronnie Sahlberg and Jonathan Maple, we finally have an answer to this question. It's no." The data shows that "frozen" vendor Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream "stable" Linux kernel created by Greg Kroah-Hartman. How can this be? If you want the full details the link to the white paper is here. But the results of the analysis couldn't be clearer.

- A "frozen" vendor kernel is an insecure kernel. A vendor kernel released later in the release schedule is doubly so.

- The number of known bugs in a "frozen" vendor kernel grows over time. The growth in the number of bugs even accelerates over time.

- There are too many open bugs in these kernels for it to be feasible to analyze or even classify them....

[T]hinking that you're making a more secure choice by using a "frozen" vendor kernel isn't a luxury we can still afford to believe. As Greg Kroah-Hartman explicitly said in his talk "Demystifying the Linux Kernel Security Process": "If you are not using the latest stable / longterm kernel, your system is insecure."
CIQ describes its report as "a count of all the known bugs from an upstream kernel that were introduced, but never fixed in RHEL 8." For the most recent RHEL 8 kernels, at the time of writing, these counts are: RHEL 8.6 : 5034 RHEL 8.7 : 4767 RHEL 8.8 : 4594

In RHEL 8.8 we have a total of 4594 known bugs with fixes that exist upstream, but for which known fixes have not been back-ported to RHEL 8.8. The situation is worse for RHEL 8.6 and RHEL 8.7 as they cut off back-porting earlier than RHEL 8.8 but of course that did not prevent new bugs from being discovered and fixed upstream....

This whitepaper is not meant as a criticism of the engineers working at any Linux vendors who are dedicated to producing high quality work in their products on behalf of their customers. This problem is extremely difficult to solve. We know this is an open secret amongst many in the industry and would like to put concrete numbers describing the problem to encourage discussion. Our hope is for Linux vendors and the community as a whole to rally behind the kernel.org stable kernels as the best long term supported solution. As engineers, we would prefer this to allow us to spend more time fixing customer specific bugs and submitting feature improvements upstream, rather than the endless grind of backporting upstream changes into vendor kernels, a practice which can introduce more bugs than it fixes.
ZDNet calls it "an open secret in the Linux community." It's not enough to use a long-term support release. You must use the most up-to-date release to be as secure as possible. Unfortunately, almost no one does that. Nevertheless, as Google Linux kernel engineer Kees Cook explained, "So what is a vendor to do? The answer is simple: if painful: Continuously update to the latest kernel release, either major or stable." Why? As Kroah-Hartman explained, "Any bug has the potential of being a security issue at the kernel level...."

Although [CIQ's] programmers examined RHEL 8.8 specifically, this is a general problem. They would have found the same results if they had examined SUSE, Ubuntu, or Debian Linux. Rolling-release Linux distros such as Arch, Gentoo, and OpenSUSE Tumbleweed constantly release the latest updates, but they're not used in businesses.
Jeremy Allison's post points out that "the Linux kernel used by Android devices is based on the upstream kernel and also has a stable internal kernel ABI, so this isn't an insurmountable problem..."

An anonymous reader quotes a report from The New York Times: There's a big debate in the tech world over whether artificial intelligence models should be "open source." Elon Musk, who helped found OpenAI in 2015, sued the startup and its chief executive, Sam Altman, on claims that the company had diverged from its mission of openness. The Biden administration is investigating the risks and benefits of open source models. Proponents of open source A.I. models say they're more equitable and safer for society, while detractors say they are more likely to be abused for malicious intent. One big hiccup in the debate? There's no agreed-upon definition of what open source A.I. actually means. And some are accusing A.I. companies of "openwashing" -- using the "open source" term disingenuously to make themselves look good. (Accusations of openwashing have previously been aimed at coding projects that used the open source label too loosely.)

In a blog post on Open Future, a European think tank supporting open sourcing, Alek Tarkowski wrote, "As the rules get written, one challenge is building sufficient guardrails against corporations' attempts at 'openwashing.'" Last month the Linux Foundation, a nonprofit that supports open-source software projects, cautioned that "this 'openwashing' trend threatens to undermine the very premise of openness -- the free sharing of knowledge to enable inspection, replication and collective advancement." Organizations that apply the label to their models may be taking very different approaches to openness. [...]

The main reason is that while open source software allows anyone to replicate or modify it, building an A.I. model requires much more than code. Only a handful of companies can fund the computing power and data curation required. That's why some experts say labeling any A.I. as "open source" is at best misleading and at worst a marketing tool. "Even maximally open A.I. systems do not allow open access to the resources necessary to 'democratize' access to A.I., or enable full scrutiny," said David Gray Widder, a postdoctoral fellow at Cornell Tech who has studied use of the "open source" label by A.I. companies.

In a press release today, the best music player of the 1990s announced that it'll open up its source code to developers worldwide. "Winamp will open up its code for the player used on Windows, enabling the entire community to participate in its development," said the company. "This is an invitation to global collaboration, where developers worldwide can contribute their expertise, ideas, and passion to help this iconic software evolve."

Alexandre Saboundjian, CEO of Winamp, explains: "This is a decision that will delight millions of users around the world. Our focus will be on new mobile players and other platforms. We will be releasing a new mobile player at the beginning of July. Still, we don't want to forget the tens of millions of users who use the software on Windows and will benefit from thousands of developers' experience and creativity. Winamp will remain the owner of the software and will decide on the innovations made in the official version."

An anonymous reader quotes a report from ZDNet: IBM managed the open sourcing of Granite code by using pretraining data from publicly available datasets, such as GitHub Code Clean, Starcoder data, public code repositories, and GitHub issues. In short, IBM has gone to great lengths to avoid copyright or legal issues. The Granite Code Base models are trained on 3- to 4-terabyte tokens of code data and natural language code-related datasets. All these models are licensed under the Apache 2.0 license for research and commercial use. It's that last word -- commercial -- that stopped the other major LLMs from being open-sourced. No one else wanted to share their LLM goodies.

But, as IBM Research chief scientist Ruchir Puri said, "We are transforming the generative AI landscape for software by releasing the highest performing, cost-efficient code LLMs, empowering the open community to innovate without restrictions." Without restrictions, perhaps, but not without specific applications in mind. The Granite models, as IBM ecosystem general manager Kate Woolley said last year, are not "about trying to be everything to everybody. This is not about writing poems about your dog. This is about curated models that can be tuned and are very targeted for the business use cases we want the enterprise to use. Specifically, they're for programming."

These decoder-only models, trained on code from 116 programming languages, range from 3 to 34 billion parameters. They support many developer uses, from complex application modernization to on-device memory-constrained tasks. IBM has already used these LLMs internally in IBM Watsonx Code Assistant (WCA) products, such as WCA for Ansible Lightspeed for IT Automation and WCA for IBM Z for modernizing COBOL applications. Not everyone can afford Watsonx, but now, anyone can work with the Granite LLMs using IBM and Red Hat's InstructLab.

An anonymous reader shared this report from the Register: The co-author of SQL, the standardized query language for relational databases, has come out in support of the NoSQL database movement that seeks to escape the tabular confines of the RDBMS. Speaking to The Register as SQL marks its 50th birthday, Donald Chamberlin, who first proposed the language with IBM colleague Raymond Boyce in a 1974 paper [PDF], explains that NoSQL databases and their query languages could help perform the tasks relational systems were never designed for. "The world doesn't stay the same thing, especially in computer science," he says. "It's a very fast, evolving, industry. New requirements are coming along and technology has to change to meet them, I think that's what's happening. The NoSQL movement is motivated by new kinds of applications, particularly web applications, that need massive scalability and high performance. Relational databases were developed in an earlier generation when scalability and performance weren't quite as important. To get the scalability and performance that you need for modern apps, many systems are relaxing some of the constraints of the relational data model."

[...] A long-time IBMer, Chamberlin is now semi-retired, but finds time to fulfill a role as a technical advisor for NoSQL company Couchbase. In the role, he has become an advocate for a new query language designed to overcome the "impedance mismatch" between data structures in the application language and a database, he says. UC San Diego professor Yannis Papakonstantinou has proposed SQL++ to solve this problem, with a view to addressing impedance mismatch between heavily object-based JavaScript, the core language for web development and the assumed relational approach embedded in SQL. Like C++, SQL++ is designed as a compatible extension of an earlier language, SQL, but is touted as better able to handle the JSON file format inherent in JavaScript. Couchbase and AWS have adopted the language, although the cloud giant calls it PartiQL.
At the end of the interview, Chamblin adds that "I don't think SQL is going to go away. A large part of the world's business data is encoded in SQL, and data is very sticky. Once you've got your database, you're going to leave it there. Also, relational systems do a very good job of what they were designed to do...

"[I]f you're a startup company that wants to sell shoes on the web or something, you're going to need a database, and one of those SQL implementations will do the job for free. I think relational databases and the SQL language will be with us for a long time."

This week, The Register reported: If you are still running RHEL 7, which is now approaching a decade old, there's good news. Red Hat is offering four more years of support for RHEL 7.9, which it terms Extended Life Cycle Support or ELS.

If you are running the free version, CentOS Linux 7, that hits its end-of-life on the same date: June 30, 2024. CIQ, which offers CentOS Linux rebuild Rocky Linux, has a life cycle extension for that too, which it calls CIQ Bridge. The company told The Reg: "CIQ Bridge, essentially a long-term support service tailored for CentOS 7 users on the migration path to Rocky Linux, is offered under an annual, fixed-rate subscription. CIQ Bridge includes access to CentOS 7 extended life package updates for an additional three years and security updates for CVSS 7 issues and above. Security updates for CVSS 5 and 6 are available at an elevated subscription tier. CIQ Bridge is designed to support CentOS 7 users until they are ready for CIQ guidance and support in migration to Rocky Linux." CIQ believes there's a substantial market for this, and points to research from Enlyft that suggests hundreds of thousands of users still on CentOS Linux 7.

Red Hat Enterprise Linux 9.4 has been released. But also released is Rocky Linux 9.4, reports 9to5Linux: Rocky Linux 9.4 also adds openSUSE's KIWI next-generation appliance builder as a new image build workflow and process for building images that are feature complete with the old images... Under the hood, Rocky Linux 9.4 includes the same updated components from the upstream Red Hat Enterprise Linux 9.4
This week also saw the release of Alma Linux 9.4 stable (the "forever-free enterprise Linux distribution... binary compatible with RHEL.") The Register points out that while Alma Linux is "still supporting some aging hardware that the official RHEL 9.4 drops, what's new is largely the same in them both."

And last week also saw the launch of the AlmaLinux High-Performance Computing and AI Special Interest Group (SIG). HPCWire reports: "AlmaLinux's status as a community-driven enterprise Linux holds incredible promise for the future of HPC and AI," said Hayden Barnes, SIG leader and Senior Open Source Community Manager for AI Software at HPE. "Its transparency and stability empowers researchers, developers and organizations to collaborate, customize and optimize their computing environments, fostering a culture of innovation and accelerating breakthroughs in scientific research and cutting-edge AI/ML."
And this week, InfoWorld reported: Red Hat has launched Red Hat Enterprise Linux AI (RHEL AI), described as a foundation model platform that allows users to more seamlessly develop and deploy generative AI models. Announced May 7 and available now as a developer preview, RHEL AI includes the Granite family of open-source large language models (LLMs) from IBM, InstructLab model alignment tools based on the LAB (Large-Scale Alignment for Chatbots) methodology, and a community-driven approach to model development through the InstructLab project, Red Hat said.

The Dillo browser dates back to 1999, writes the Register, with its own rendering engine. And now Dillo "has returned with a new release, version 3.1.

"It's nearly nine years after version 3.05 appeared on the last day of June 2015." Version 3.1 incorporates dozens of fixes and improvements, as the official announcement describes.

Project lead Rodrigo Arias Mallo announced his resurrection attempt on Hacker News early this year. He has taken the last available code from the project's Mercurial repository, incorporated about 25 outstanding fixes, and added as many again of his own.

Dillo is a super-lightweight graphical web browser for Unix-like OSes, written using the Fast Light Toolkit. The latest version has a number of new features, although one of the most significant is support for Transport Layer Security. TLS is the successor to SSL, with a Microsoft-approved name. Dillo 3.1 supports it thanks to the Mbed-TLS library.
It doesn't support frames, embedded media playback, or JavaSccript — but it can run on very low-end hardware...

Thanks to Lproven (Slashdot reader #6,030) for sharing the news.

The blog It's FOSS is "pissed at the casual arrogance of Ubuntu and its parent company Canonical..... The sheer audacity of not caring for its users reeks of Microsoft-esque arrogance." If you download a .deb package of a software, you cannot install it using the official graphical software center on Ubuntu anymore. When you double-click on the downloaded deb package, you'll see this error, "there is no app installed for Debian package files".

If you right-click and choose to open it with Software Center, you are in for another annoyance. The software center will go into eternal loading. It may look as if it is doing something, but it will go on forever. I could even livestream the loading app store on YouTube, and it would continue for the 12 years of its long-term support period.
Canonical software engineer Dennis Loose actually created an issue ticket for the problem himself — back in September of 2023. And two weeks ago he returned to the discussion to announce that fix "will be a priority for the next cycle". (Though "unfortunately we didn't have the capacity to work on this for 24.04...)

But Its Foss accused Canonical of "cleverly booting out deb in favor of Snap, one baby step at a time" (noting the problem started with Ubuntu 23.10): There is also the issue of replacing deb packages with Snap, even with the apt command line tool. You use 'sudo apt install chromium', you get a Snap package of Chromium instead of Debian
The venerable Linux magazine argues that Canonical "has secretly forced Snap installation on users." [I]t looks as if the Software app defaults to Snap packages for everything now. I combed through various apps and found this to be the case.... As far as the auto-installation of downloaded .deb files, you'll have to install something like gdebi to bring back this feature.

Mishaal Rahman reports via Android Authority: Earlier today, a Senior Staff Software Engineer at Google who, according to their LinkedIn, leads the Android Systems Team and works on Android's Linux kernel fork, submitted a series of patches to AOSP that "remove ACK's support for riscv64." The description of these patches states that "support for risc64 GKI kernels is discontinued."

ACK stands for Android Common Kernel and refers to the downstream branches of the official kernel.org Linux kernels that Google maintains. The ACK is basically Linux plus some "patches of interest to the Android community that haven't been merged into mainline or Long Term Supported (LTS) kernels." There are multiple ACK branches, including android-mainline, which is the primary development branch that is forked into "GKI" kernel branches that correspond to a particular combination of supported Linux kernel and Android OS version. GKI stands for Generic Kernel Image and refers to a kernel that's built from one of these branches. Every certified Android device ships with a kernel based on one of these GKI branches, as Google currently does not certify Android devices that ship with a mainline Linux kernel build.

Since these patches remove RISC-V kernel support, RISC-V kernel build support, and RISC-V emulator support, any companies looking to compile a RISC-V build of Android right now would need to create and maintain their own fork of Linux with the requisite ACK and RISC-V patches. Given that Google currently only certifies Android builds that ship with a GKI kernel built from an ACK branch, that means we likely won't see certified builds of Android on RISC-V hardware anytime soon. Our initial interpretation of these patches was that Google was preparing to kill off RISC-V support in Android since that was the most obvious conclusion. However, a spokesperson for Google told us this: "Android will continue to support RISC-V. Due to the rapid rate of iteration, we are not ready to provide a single supported image for all vendors. This particular series of patches removes RISC-V support from the Android Generic Kernel Image (GKI)." Based on Google's statement, Rahman suggests that "there's still a ton of work that needs to be done before Android is ready for RISC-V."

"Even once it's ready, Google will need to redo the work to add RISC-V support in the kernel anyway. At the very least, Google's decision likely means that we might need to wait even longer than expected to see commercial Android devices running on a RISC-V chip."

After convincing the world to buy open source and give up the Morse Code test for ham radio licenses, Bruce Perens has a new gambit: develop a license that ensures software developers receive compensation from large corporations using their work. The new Post-Open Zero Cost License seeks to address the financial disparities in open source software use and includes provisions against using content to train AI models, aligning its enforcement with non-profit performing rights organizations like ASCAP. Here's an excerpt from an interview The Register conducted with Perens: The license is one component among several -- the paid license needs to be hammered out -- that he hopes will support his proposed Post-Open paradigm to help software developers get paid when their work gets used by large corporations. "There are two paradigms that you can use for this," he explains in an interview. "One is Spotify and the other is ASCAP, BMI, and SESAC. The difference is that Spotify is a for-profit corporation. And they have to distribute profits to their stockholders before they pay the musicians. And as a result, the musicians complain that they're not getting very much at all."

"There are two paradigms that you can use for this," he explains in an interview. "One is Spotify and the other is ASCAP, BMI, and SESAC. The difference is that Spotify is a for-profit corporation. And they have to distribute profits to their stockholders before they pay the musicians. And as a result, the musicians complain that they're not getting very much at all." Perens wants his new license -- intended to complement open source licensing rather than replace it -- to be administered by a 501(c)(6) non-profit. This entity would handle payments to developers. He points to the music performing rights organizations as a template, although among ASCAP, BMI, SECAC, and GMR, only ASCAP remains non-profit. [...]

The basic idea is companies making more than $5 million annually by using Post-Open software in a paid-for product would be required to pay 1 percent of their revenue back to this administrative organization, which would distribute the funds to the maintainers of the participating open source project(s). That would cover all Post-Open software used by the organization. "The license that I have written is long -- about as long as the Affero GPL 3, which is now 17 years old, and had to deal with a lot more problems than the early licenses," Perens explains. "So, at least my license isn't excessively long. It handles all of the abuses of developers that I'm conscious of, including things I was involved in directly like Open Source Security v. Perens, and Jacobsen v. Katzer."

"It also makes compliance easier for companies than it is today, and probably cheaper even if they do have to pay. It creates an entity that can sue infringers on behalf of any developer and gets the funding to do it, but I'm planning the infringement process to forgive companies that admit the problem and cure the infringement, so most won't ever go to court. It requires more infrastructure than open source developers are used to. There's a central organization for Post-Open (or it could be three organizations if we divided all of the purposes: apportioning money to developers, running licensing, and enforcing compliance), and an outside CPA firm, and all of that has to be structured so that developers can trust it." You can read the full interview here.

ReneR writes: A major T2 Linux milestone has been released, shipping with full support for 25 CPU architectures and several C libraries, as well as restored support for Intel IA-64 Itanium. Additionally, many vintage X.org DDX drivers were fixed and tested to work again, as well as complete support for the latest KDE 6 and GNOME 46.

T2 is known for its sophisticated cross compile support and support for nearly all existing CPU architectures: Alpha, Arc, ARM(64), Avr32, HPPA(64), IA64, M68k, MIPS(64), Nios2, PowerPC(64)(le), RISCV(64), s390x, SPARC(64), and SuperH x86(64). T2 is an increasingly popular choice for embedded systems and virtualization. It also still supports the Sony PS3, Sgi, Sun and HP workstations, as well as the latest ARM64 and RISCV64 architectures.

The release contains a total of 5,140 changesets, including approximately 5,314 package updates, 564 issues fixed, 317 packages or features added and 163 removed, and around 53 improvements. Usually most packages are up-to-date, including Linux 6.8, GCC 13, LLVM/Clang 18, as well as the latest version of X.org, Mesa, Firefox, Rust, KDE 6 and GNOME 46!

More information, source and binary distribution are open source and free at T2 SDE.

An anonymous reader shared a report this week from Reuters: The U.S. Department of Commerce is reviewing the national security implications of China's work in open-source RISC-V chip technology, according to a letter sent to U.S. lawmakers...

The technology is being used by major Chinese tech firms such as Alibaba Group Holding and has become a new front in the strategic competition over advanced chip technology between the U.S. and China. In November, 18 U.S. lawmakers from both houses of Congress pressed the Biden administration for its plans to prevent China "from achieving dominance in ... RISC-V technology and leveraging that dominance at the expense of U.S. national and economic security."

In a letter last week to the lawmakers that was seen by Reuters on Tuesday, the Commerce Department said it is "working to review potential risks and assess whether there are appropriate actions under Commerce authorities that could effectively address any potential concerns."

But the Commerce Department also noted that it would need to tread carefully to avoid harming U.S. companies that are part of international groups working on RISC-V technology.

1,000 petabytes.
A million terabytes.
One quintillion bytes (or 1,000,000,000,000,000,000).

That's the amount of storage reported by users of the Ceph storage solution (across more than 3,000 Ceph clusters).

The Ceph Foundation is a "directed fund" of the Linux Foundation, providing a neutral home for Ceph, "the most popular open source storage solution for modern data storage challenges" (offering an architecture that's "highly scalable, resilient, and flexible"). It's a software-defined storage platform, providing object storage, block storage, and file storage built on a common distributed cluster foundation.

And Friday they announced the release of Ceph Squid, "which comes with several performance and space efficiency features along with enhanced protocol support." Ceph has solidified its position as the cornerstone of open source data storage. The release of Ceph Squid represents a significant milestone toward providing scalable, reliable, and flexible storage solutions that meet the ever-evolving demands of digital data storage.

Features of Ceph Squid include improvements to BlueStore [a storage back end specifically designed for managing data on disk for Ceph Object Storage Daemon workloads] to reduce latency and CPU requirements for snapshot intensive workloads. BlueStore now uses RocksDB compression by default for increased average performance and reduced space usage. [And the next-generation Crimson OSD also has improvements in stability and read performance, and "now supports scrub, partial recovery and osdmap trimming."]

Ceph continues to drive the future of storage, and welcomes developers, partners, and technology enthusiasts to get involved.
Ceph Squid also brings enhancements for the CRUSH algorithm [which computes storage locations] to support more flexible and cost effective erasure coding configurations.

Microsoft releases one of the most popular versions of MS-DOS as open source today. stikves shares a post:Ten years ago, Microsoft released the source for MS-DOS 1.25 and 2.0 to the Computer History Museum, and then later republished them for reference purposes. This code holds an important place in history and is a fascinating read of an operating system that was written entirely in 8086 assembly code nearly 45 years ago.

Today, in partnership with IBM and in the spirit of open innovation, we're releasing the source code to MS-DOS 4.00 under the MIT license. There's a somewhat complex and fascinating history behind the 4.0 versions of DOS, as Microsoft partnered with IBM for portions of the code but also created a branch of DOS called Multitasking DOS that did not see a wide release.

prisoninmate shares a report from 9to5Linux: Canonical released today Ubuntu 24.04 LTS (Noble Numbat) as the latest version of its popular Linux-based operating system featuring some of the latest GNU/Linux technologies and Open Source software. Powered by Linux kernel 6.8, Ubuntu 24.04 LTS features the latest GNOME 46 desktop environment, an all-new graphical firmware update tool called Firmware Updater, Netplan 1.0 for state-of-the-art network management, updated Ubuntu font, support for the deb822 format for software sources, increased vm.max_map_count for better gaming, and Mozilla Thunderbird as a Snap by default.

It also comes with an updated Flutter-based graphical desktop installer that's now capable of updating itself and features a bunch of changes like support for accessibility features, guided (unencrypted) ZFS installations, a new option to import auto-install configurations for templated custom provisioning, as well as new default installation options, such as Default selection (previously Minimal) and Extended selection (previously Normal)."

An anonymous reader quotes a report from Ars Technica: Home Assistant, until recently, has been a wide-ranging and hard-to-define project. The open smart home platform is an open source OS you can run anywhere that aims to connect all your devices together. But it's also bespoke Raspberry Pi hardware, in Yellow and Green. It's entirely free, but it also receives funding through a private cloud services company, Nabu Casa. It contains tiny board project ESPHome and other inter-connected bits. It has wide-ranging voice assistant ambitions, but it doesn't want to be Alexa or Google Assistant. Home Assistant is a lot.

After an announcement this weekend, however, Home Assistant's shape is a bit easier to draw out. All of the project's ambitions now fall under the Open Home Foundation, a non-profit organization that now contains Home Assistant and more than 240 related bits. Its mission statement is refreshing, and refreshingly honest about the state of modern open source projects. "We've done this to create a bulwark against surveillance capitalism, the risk of buyout, and open-source projects becoming abandonware," the Open Home Foundation states in a press release. "To an extent, this protection extends even against our future selves -- so that smart home users can continue to benefit for years, if not decades. No matter what comes." Along with keeping Home Assistant funded and secure from buy-outs or mission creep, the foundation intends to help fund and collaborate with external projects crucial to Home Assistant, like Z-Wave JS and Zigbee2MQTT.

Home Assistant's ambitions don't stop with money and board seats, though. They aim to "be an active political advocate" in the smart home field, toward three primary principles:

- Data privacy, which means devices with local-only options, and cloud services with explicit permissions
- Choice in using devices with one another through open standards and local APIs
- Sustainability by repurposing old devices and appliances beyond company-defined lifetimes

Notably, individuals cannot contribute modest-size donations to the Open Home Foundation. Instead, the foundation asks supporters to purchase a Nabu Casa subscription or contribute code or other help to its open source projects. Further reading: The Verge's interview with Home Assistant founder Paulus Schoutsen

Remember when Apple filed a lawsuit against chip startup Rivos (saying that in one year Rivos hired more than 40 former Apple employees to work on competing system-on-a-chip technology)? Apple settled that suit in February.

And now Tuesday Rivos announced that it raised $250 million, according to Reuters, "in a funding round that will enable it to manufacture its first server chip geared for artificial intelligence," combining a CPU with an AI-accelerating component optimized for LLMs and data analytics. Nvidia gobbled up more than 80% market share of AI chips in 2023. But a host of startups and chip giants have started to launch competing products, such as Intel's Gaudi 3 and Meta's inference chip — both unveiled last week. Rivos is tight-lipped about the specifics of the product, but has disclosed that its plans include designing chips based on the RISC-V architecture, which is an open source alternative to the architectures made by Arm, Intel, and Advanced Micro Devices.. [U]sing the open source alternative means Rivos does not have to pay a license fee to Arm. "RISC-V doesn't have a (large) software ecosystem, so I decided to form a company and then build software-defined hardware — just like what CUDA did with Nvidia," said Lip-Bu Tan, founding managing partner at Walden Catalyst, one of Rivos' investors.
Meanwhile, there's a rumor that Allen Wu, former chief executive of Arm China, has founded a new company that will develop chips based on RISC-V. Tom's Hardware writes: Under the leadership of the controversial Allen Wu, Zhongzhi Chip is reportedly attracting a notable influx of talent, including numerous former employees of Arm, indicating the new company's serious ambitions in the chip sector... [T]he company's operational focus remains partially unclear, with speculation around whether it will primarily engage in its own R&D initiatives or represent Tenstorrent in China as its agent... which develops HPC CPUs and AI processors based on the RISC-V ISA... Based on the source report, Zhongzhi Chip is leveraging its connections and forming alliances with several other leading global RISC-V chip developers.

Michael Larabel reports via Phoronix: While Fedora 41 in late 2024 is aiming to have more reproducible package builds, openSUSE Factory has already achieved a significant milestone in bit-by-bit reproducible builds. Since last month openSUSE Factory has been producing bit-by-bit reproducible builds sans the likes of embedded signatures. OpenSUSE Tumbleweed packages for that rolling-release distribution are being verified for bit-by-bit reproducible builds. SUSE/openSUSE is still verifying all packages are yielding reproducible builds but so far it's looking like 95% or more of packages are working out. You can learn more via the openSUSE blog.

The Linux Foundation-backed project OpenTofu "has gotten legal pushback from HashiCorp," according to a report — just seven months after forking OpenTofu's code from HashiCorp's IT deployment software Terraform: On April 3, HashiCorp issued a strongly-worded Cease and Desist letter to OpenTofu, accusing that the project has "repeatedly taken code HashiCorp provided only under the Business Software License (BSL) and used it in a manner that violates those license terms and HashiCorp's intellectual property rights." It goes on to note that "In at least some instances, OpenTofu has incorrectly re-labeled HashiCorp's code to make it appear as if it was made available by HashiCorp originally under a different license." Last August, HashiCorp announced that it would be transitioning its software from the open source Mozilla Public License (MPL 2.0) to the Business Source License (BSL), a license that permits the source to be viewed, but not run in production environments without explicit approval by the license owner. HashiCorp gave OpenTofu until April 10 to remove any allegedly copied code from the OpenTofu repository, threatening litigation if the project fails to do so.
Others are also covering the fracas, including Steven J. Vaughan-Nichols at DevOps.com: OpenTofu replied, "The OpenTofu team vehemently disagrees with any suggestion that it misappropriated, mis-sourced, or otherwise misused HashiCorp's BSL code. All such statements have zero basis in facts." In addition, it said, HashiCorp's claims of copyright infringement are completely unsubstantiated. As for the code in question, OpenTofu claims it can clearly be shown to have been copied from older code under the Mozilla Public License (MPL) 2.0. "HashiCorp seems to have copied the same code itself when they implemented their version of this feature. All of this is easily visible in our detailed SCO analysis, as well as their own comments."

In a detailed source code origination (SCO) examination of the problematic source code, OpenTofu stated that HashiCorp was mistaken. "We believe that this is just a case of a misunderstanding where the code came from." OpenTofu maintains the code was originally licensed under the MPL, not the BSL. If so, then OpenTofu was perfectly within its right to use the code in its codebase...

[OpenTofu's lawyer] concluded, "In the future, if you should have any concerns or questions about how source code in OpenTofu is developed, we would ask that you contact us first. Immediately issuing DMCA takedown notices and igniting salacious negative press articles is not the most helpful path to resolving concerns like this."