Google Removes RISC-V Support From Android Common Kernel, Denies Abandoning Its Efforts

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

Read more of this story at Slashdot.

Redis To Adopt ‘Source-Available Licensing’ Starting With Next Version

Longtime Slashdot reader jgulla shares an announcement from Redis: Beginning today, all future versions of Redis will be released with source-available licenses. Starting with Redis 7.4, Redis will be dual-licensed under the Redis Source Available License (RSALv2) and Server Side Public License (SSPLv1). Consequently, Redis will no longer be distributed under the three-clause Berkeley Software Distribution (BSD). The new source-available licenses allow us to sustainably provide permissive use of our source code.

We’re leading Redis into its next phase of development as a real-time data platform with a unified set of clients, tools, and core Redis product offerings. The Redis source code will continue to be freely available to developers, customers, and partners through Redis Community Edition. Future Redis source-available releases will unify core Redis with Redis Stack, including search, JSON, vector, probabilistic, and time-series data models in one free, easy-to-use package as downloadable software. This will allow anyone to easily use Redis across a variety of contexts, including as a high-performance key/value and document store, a powerful query engine, and a low-latency vector database powering generative AI applications. […]

Under the new license, cloud service providers hosting Redis offerings will no longer be permitted to use the source code of Redis free of charge. For example, cloud service providers will be able to deliver Redis 7.4 only after agreeing to licensing terms with Redis, the maintainers of the Redis code. These agreements will underpin support for existing integrated solutions and provide full access to forthcoming Redis innovations. In practice, nothing changes for the Redis developer community who will continue to enjoy permissive licensing under the dual license. At the same time, all the Redis client libraries under the responsibility of Redis will remain open source licensed. Redis will continue to support its vast partner ecosystem — including managed service providers and system integrators — with exclusive access to all future releases, updates, and features developed and delivered by Redis through its Partner Program. There is no change for existing Redis Enterprise customers.

Read more of this story at Slashdot.

OpenTTD (Unofficial Remake of ‘Transport Tycoon Deluxe’ Game) Turns 20

In 1995 Scottish video game designer Chris Sawyer created the business simulator game Transport Tycoon Deluxe — and within four years, Wikipedia notes, work began on the first version of an open source version that’s still being actively developed. “According to a study of the 61,154 open-source projects on SourceForge in the period between 1999 and 2005, OpenTTD ranked as the 8th most active open-source project to receive patches and contributions. In 2004, development moved to their own server.”

Long-time Slashdot reader orudge says he’s been involved for almost 25 years. “Exactly 21 years ago, I received an ICQ message (look it up, kids) out of the blue from a guy named Ludvig Strigeus (nicknamed Ludde).”

“Hello, you probably don’t know me, but I’ve been working on a project to clone Transport Tycoon Deluxe for a while,” he said, more or less… Ludde made more progress with the project [written in C] over the coming year, and it looks like we even attempted some multiplayer games (not too reliable, especially over my dial-up connection at the time). Eventually, when he was happy with what he had created, he agreed to allow me to release the game as open source. Coincidentally, this happened exactly a year after I’d first spoken to him, on the 6th March 2004…

Things really got going after this, and a community started to form with enthusiastic developers fixing bugs, adding in new features, and smoothing off the rough edges. Ludde was, I think, a bit taken aback by how popular it proved, and even rejoined the development effort for a while. A read through the old changelogs reveals just how many features were added over a very short period of time. Quick wins like higher vehicle limits came in very quickly, and support for TTDPatch’s NewGRF format started to be functional just four months later. Large maps, improved multiplayer, better pathfinders, improved TTDPatch compatibility, and of course, ports to a great many different operating systems, such as Mac OS X, BeOS, MorphOS and OS/2. It was a very exciting time to be a TTD fan!

Within six years, ambitious projects to create free replacements for the original TTD graphics, sounds and music sets were complete, and OpenTTD finally had its 1.0 release. And while we may not have the same frantic addition of new features we had in 2004, there have still been massive improvements to the code, with plenty of exciting new features over the years, with major releases every year since 2008. he move to GitHub in 2018 and the release of OpenTTD on Steam in 2021 have also re-energised development efforts, with thousands of people now enjoying playing the game regularly. And development shows no signs of slowing down, with the upcoming OpenTTD 14.0 release including over 40 new features!
“Personally, I would like to say thank you to everyone who has supported OpenTTD development over the past two decades…” they write, adding “Finally, of course, I’d like to thank you, the players! None of us would be here if people weren’t still playing the game.

“Seeing how the first twenty years have gone, I can’t wait to see what the next twenty years have in store. :)”

Read more of this story at Slashdot.

Hugging Face Launches Open Source AI Assistant Maker To Rival OpenAI’s Custom GPTs

Carl Franzen reports via VentureBeat: Hugging Face, the New York City-based startup that offers a popular, developer-focused repository for open source AI code and frameworks (and hosted last year’s “Woodstock of AI”), today announced the launch of third-party, customizable Hugging Chat Assistants. The new, free product offering allows users of Hugging Chat, the startup’s open source alternative to OpenAI’s ChatGPT, to easily create their own customized AI chatbots with specific capabilities, similar both in functionality and intention to OpenAI’s custom GPT Builder â” though that requires a paid subscription to ChatGPT Plus ($20 per month), Team ($25 per user per month paid annually), and Enterprise (variable pricing depending on the needs).

Phillip Schmid, Hugging Face’s Technical Lead & LLMs Director, posted the news on the social network X (formerly known as Twitter), explaining that users could build a new personal Hugging Face Chat Assistant “in 2 clicks!” Schmid also openly compared the new capabilities to OpenAI’s custom GPTs. However, in addition to being free, the other big difference between Hugging Chat Assistant and the GPT Builder and GPT Store is that the latter tools depend entirely on OpenAI’s proprietary large language models (LLM) GPT-4 and GPT-4 Vision/Turbo. Users of Hugging Chat Assistant, by contrast, can choose which of several open source LLMs they wish to use to power the intelligence of their AI Assistant on the backend, including everything from Mistral’s Mixtral to Meta’s Llama 2. That’s in keeping with Hugging Face’s overarching approach to AI — offering a broad swath of different models and frameworks for users to choose between — as well as the same approach it takes with Hugging Chat itself, where users can select between several different open source models to power it.

Read more of this story at Slashdot.