Bose is end-of-lifing its SoundTouch smart speakers but softened the blow by open-sourcing the SoundTouch API and preserving limited local features, AirPlay, and Spotify Connect. Ars Technica reports: In October, Bose announced that its SoundTouch Wi-Fi speakers and soundbars would become dumb speakers on February 18. At the time, Bose said that the speakers would only work if a device was connected via AUX, HDMI, or Bluetooth (which has higher latency than Wi-Fi). After that date, the speakers would stop receiving security and software updates and lose cloud connectivity and their companion app, the Framingham, Massachusetts-based company said. Without the app, users would no longer be able to integrate the device with music services, such as Spotify, have multiple SoundTouch devices play the same audio simultaneously, or use or edit saved presets. The announcement frustrated some of Bose's long-time customers, some of whom own multiple SoundTouch devices that still function properly. Many questioned companies' increasingly common practice of bricking expensive products to focus on new devices or to minimize costs, or because they've gone through acquisitions or bankruptcy. SoundTouch speakers released in 2013 and 2015 with prices ranging from $399 to $1,500. Today, Bose had better news. In an email to customers, Bose announced that AirPlay and Spotify Connect will still work with SoundTouch speakers after EoL, expanding the wireless capabilities that people will still be able to access. Additionally, SoundTouch devices that support AirPlay 2 can play the same audio simultaneously. The SoundTouch app will also live on, albeit stripped of some functionality. "On May 6, 2026, the app will update to a version that supports the functions that can operate locally without the cloud. No action will be required on your part. Opening the app will apply the update automatically," Bose said. Bose also provided instructions (PDF) for a workaround for saving presets that uses the favorites options in music service apps.

Read more of this story at Slashdot.

Even after its acquisition by Qualcomm, the EFF believes Arduino "isn't imposing any new bans on tinkering with or reverse engineering Arduino boards," (according to Mitch Stoltz, EFF director for competition and IP litigation). While Adafruit's managing editor Phillip Torrone had claimed to 36,000+ followers on LinkedIn that Arduino users were now "explicitly forbidden from reverse engineering," Arduino corrected him in a blog post, noting that clause in their Terms & Conditions was only for Arduino's Software-as-a-Service cloud applications. "Anything that was open, stays open." And this week EE Times spoke to Guneet Bedi, SVP of Arduino, "who was unequivocal in saying that Arduino's governance structure had remained intact even after the acquisition." "As a business unit within Qualcomm, Arduino continues to make independent decisions on its product portfolio, with no direction imposed on where it should or should not go," Bedi said. "Everything that Arduino builds will remain open and openly available to developers, with design engineers, students and makers continuing to be the primary focus.... Developers who had mastered basic embedded workflows were now asking how to run large language models at the edge and work with artificial intelligence for vision and voice, with an open source mindset," he said. According to Bedi, this was where Qualcomm's technology became relevant. "Qualcomm's chipsets are high performance while also being very low power, which comes from their mobile and Android phone heritage. Despite being great technology, it is not easily accessible to design engineers because of cost and complexity. That made this a strong fit," he said. The most visible outcome of this acquisition is Uno Q, which Bedi described as being comparable to a mid-tier Android phone in capability, starting at a price of $44. For Arduino, this marked a shift beyond microcontrollers without abandoning them. "At the end of the day, we have not gone away from our legacy," Bedi said. "You still have a real-time microcontroller, and you still write code the way Arduino developers are used to. What we added is compute, without forcing people to change how they work." Uno Q combines a Linux-based compute system with a real-time microcontroller from the STM32 family. "You do not need two different development environments or two different hardware platforms," Bedi added... Rather than introducing a customized operating system, Arduino chose standard Debian upstream. "We are not locking developers into anything," Bedi said. "It is standard Debian, completely open...." Pre-built models covering tasks like object detection and voice recognition run locally on the board.... While the first reference design uses Qualcomm silicon, Bedi was careful to stress that this does not define the roadmap. "There is zero dependency on Qualcomm silicon," he said. "The architecture is portable. Tomorrow, we can run this on something else." That distinction matters, particularly for developers wary of vendor lock-in following the acquisition. Uno Q does compete directly with platforms like Raspberry Pi and Nvidia Jetson, but Bedi framed the difference less in terms of raw performance and more in flexibility. "When you build on those platforms, you are locked to the board," he said. "Here, you can build a prototype, and if you like it, you can also get access to the chip and design your own hardware." With built-in storage removing the need for external components, Uno Q positions itself less as a faster board and more as a way to simplify what had become an increasingly messy development stack... Looking a year ahead, Bedi believes developers should experience continuity rather than disruption. The familiar Arduino approach to embedded and real-time systems remains unchanged, while extending naturally into more compute-intensive applications... Taken together, Bedi's comments suggest that Arduino's post-acquisition direction is less about changing what Arduino is, and more about expanding what it can realistically be used for, without abandoning the simplicity that made it relevant in the first place. "We want to redefine prototyping in the age of physical artificial intelligence," Bedi said...

Read more of this story at Slashdot.

The nonprofit Open Source Initiative offers "enriched" license pages with "relevant metadata to provide deeper insights and better support". So which pages got the most pageviews in 2025? The MIT license, Apache 2.0 license, BSD licenses (3-clause and 2-clause), and GNU General Public license: mit (1.5M) apache-2-0 (344k) bsd-3-clause (214k) bsd-2-clause (128k) gpl-2-0 (76k) gpl-3-0 (55k) isc-license-txt (35k) lgpl-3-0 (34k) OFL-1.1 (31k) lgpl-2-1 (24k) . . From the Open Source Initiative's announcement: Please note that these are aggregated pageviews from actual humans along the year of 2025... Actual humans (presumably) because the number of requests by bots or crawlers is several orders of magnitude higher (e.g. requests just for the MIT license are on the range of 10M per month). We do provide an API service that gives access to the canonical list of OSI Approved Licenses — this is a very new service, which hopefully will be adopted by automated requests from CI/CD pipelines. One final observation is that the number of human pageviews is likely higher because we are using Plausible as our data source and a high percentage of our target audience uses Ad blockers, which by design are not accounted by Plausible. Users from China are also likely undercounted by Plausible for the same reason.

Read more of this story at Slashdot.

Intel has quietly stopped maintaining its open-source user-space driver stack for Gaudi accelerators. Phoronix reports: It turns out earlier this year Intel archived the SynapseAI Core open-source code and is no longer maintained by Intel. The open-source Synapse AI Core GitHub repository was archived in February and README updated with: "This project will no longer be maintained by Intel. Intel has ceased development and contributions including, but not limited to, maintenance, bug fixes, new releases, or updates, to this project. Intel no longer accepts patches to this project. If you have an ongoing need to use this project, are interested in independently developing it, or would like to maintain patches for the open source software community, please create your own fork of this project."

Read more of this story at Slashdot.

OpenAI, alongside Anthropic and Block, have launched the Agentic AI Foundation under the Linux Foundation, describing it as a neutral home for standards as agentic systems move into real production. It may sound well-meaning, but Slashdot reader and NERDS.xyz founder BrianFagioli isn't buying the narrative. In a report for NERDS.xyz, Fagioli writes: Instead of opening models, training data, or anything that would meaningfully shift power toward the community, the companies involved are donating lightweight artifacts like AGENTS.md, MCP, and goose. They're useful, but they're also the safest, least threatening pieces of their ecosystem to "open." From where I sit, it looks like a strategic attempt to lock in influence over emerging standards before truly open projects get a chance to define the space. I see the entire move as smoke and mirrors. With regulators paying closer attention and developer trust slipping, creating a Linux Foundation directed fund gives these companies convenient cover to say they're being transparent and collaborative. But nothing about this structure forces them to share anything substantial, and nothing about it changes the closed nature of their core technology. To me, it looks like Big Tech trying to set the rules of the game early, using the language of openness without actually embracing it. Slashdot readers have seen this pattern before, and this one feels no different.

Read more of this story at Slashdot.

It runs locally, a free/open source home automation platform connecting all your devices together, regardless of brand. And GitHub's senior developer calls it "one of the most active, culturally important, and technically demanding open source ecosystems on the planet," with tens of thousands of contributors and millions of installations. That's confirmed by this year's "Octoverse" developer survey... Home Assistant was one of the fastest-growing open source projects by contributors, ranking alongside AI infrastructure giants like vLLM, Ollama, and Transformers. It also appeared in the top projects attracting first-time contributors, sitting beside massive developer platforms such as VS Code... Home Assistant is now running in more than 2 million households, orchestrating everything from thermostats and door locks to motion sensors and lighting. All on users' own hardware, not the cloud. The contributor base behind that growth is just as remarkable: 21,000 contributors in a single year... At its core, Home Assistant's problem is combinatorial explosion. The platform supports "hundreds, thousands of devices... over 3,000 brands," as [maintainer Franck Nijhof] notes. Each one behaves differently, and the only way to normalize them is to build a general-purpose abstraction layer that can survive vendor churn, bad APIs, and inconsistent firmware. Instead of treating devices as isolated objects behind cloud accounts, everything is represented locally as entities with states and events. A garage door is not just a vendor-specific API; it's a structured device that exposes capabilities to the automation engine. A thermostat is not a cloud endpoint; it's a sensor/actuator pair with metadata that can be reasoned about. That consistency is why people can build wildly advanced automations. Frenck describes one particularly inventive example: "Some people install weight sensors into their couches so they actually know if you're sitting down or standing up again. You're watching a movie, you stand up, and it will pause and then turn on the lights a bit brighter so you can actually see when you get your drink. You get back, sit down, the lights dim, and the movie continues." A system that can orchestrate these interactions is fundamentally a distributed event-driven runtime for physical spaces. Home Assistant may look like a dashboard, but under the hood it behaves more like a real-time OS for the home... The local-first architecture means Home Assistant can run on hardware as small as a Raspberry Pi but must handle workloads that commercial systems offload to the cloud: device discovery, event dispatch, state persistence, automation scheduling, voice pipeline inference (if local), real-time sensor reading, integration updates, and security constraints. This architecture forces optimizations few consumer systems attempt. "If any of this were offloaded to a vendor cloud, the system would be easier to build," the article points out. "But Home Assistant's philosophy reverses the paradigm: the home is the data center..." As Nijhof says of other vendor solutions, "It's crazy that we need the internet nowadays to change your thermostat."

Read more of this story at Slashdot.

"Homebrew, the package manager for macOS and Linux, just got a handy new feature in the latest v5.0.4 update," reports How-To Geek. Brewfile install scripts "are now more like a one-stop shop for installing software, as Flatpaks are now supported alongside Brew packages, Mac App Store Apps, and other packages." For those times when you need to install many software packages at once, like when setting up a new PC or virtual machine, you can create a Brewfile with a list of packages and run it with the 'brew bundle' command. However, the Brewfile isn't limited to just Homebrew packages. You can also use it to install Mac App Store apps, graphical apps through Casks, Visual Studio Code extensions, and Go language packages. Starting with this week's Homebrew v5.0.4 release, Flatpaks are now supported in Brewfiles as well... This turns Homebrew into a fantastic setup tool for macOS, Linux, and Windows Subsystem for Linux (WSL) environments. You can have one script with all your preferred software, and use 'if' statements with platform variables and existing file checks for added portability.

Read more of this story at Slashdot.

An anonymous reader quotes a report from The Verge's Sean Hollister If you wrote off the Steam Frame as yet another VR headset few will want to wear, I guarantee you're not alone. But the Steam Frame isn't just a headset; it's a Trojan horse that contains the tech gamers need to play Steam games on the next Samsung Galaxy, the next Google Pixel, perhaps Arm gaming notebooks to come. I know, because I'm already using that tech on my Samsung Galaxy. There is no official Android version of Hollow Knight: Silksong, one of the best games of 2025, but that doesn't have to stop you anymore. Thanks to a stack of open-source technologies, including a compatibility layer called Proton and an emulator called Fex, games that were developed for x86-based Windows PCs can now run on Linux-based phones with the Arm processor architecture. With Proton, the Steam Deck could already do the Windows-to-Linux part; now, Fex is bridging x86 and Arm, too. This stack is what powers the Steam Frame's own ability to play Windows games, of course, and it was widely reported that Valve is using the open-source Fex emulator to make it happen. What wasn't widely reported: Valve is behind Fex itself. In an interview, Valve's Pierre-Loup Griffais, one of the architects behind SteamOS and the Steam Deck, tells The Verge that Valve has been quietly funding almost all the open-source technologies required to play Windows games on Arm. And because they're open-source, Valve is effectively shepherding a future where Arm phones, laptops, and desktops could freely do the same. He says the company believes game developers shouldn't be wasting time porting games if there's a better way. Remember when the Steam Deck handheld showed that a decade of investment in Linux could make Windows gaming portable? Valve paid open-source developers to follow their passions to help achieve that result. Valve has been guiding the effort to bring games to Arm in much the same way: In 2016 and 2017, Griffais tells me, the company began recruiting and funding open-source developers to bring Windows games to Arm chips. Fex lead developer Ryan Houdek tells The Verge he chatted with Griffais himself at conferences those years and whipped up the first prototype in 2018. He tells me Valve pays enough that Fex is his full-time job. "I want to thank the people from Valve for being here from the start and allowing me to kickstart this project," he recently wrote.

Read more of this story at Slashdot.

During last month's KubeCon North America in Atlanta, Kubernetes maintainers announced the upcoming retirement of Ingress NGINX. "Best-effort maintenance will continue until March 2026," noted the Kubernetes SIG Network and the Security Response Committee. "Afterward, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered." In a recent op-ed for The Register, Steven J. Vaughan-Nichols reflects on the decision and speculates about what might have prevented this outcome: Ingress NGINX, for those who don't know it, is an ingress controller in Kubernetes clusters that manages and routes external HTTP and HTTPS traffic to the cluster's internal services based on configurable Ingress rules. It acts as a reverse proxy, ensuring that requests from clients outside the cluster are forwarded to the correct backend services within the cluster according to path, domain, and TLS configuration. As such, it's vital for network traffic management and load balancing. You know, the important stuff. Now this longstanding project, once celebrated for its flexibility and breadth of features, will soon be "abandonware." So what? After all, it won't be the first time a once-popular program shuffled off the stage. Off the top of my head, dBase, Lotus 1-2-3, and VisiCalc spring to my mind. What's different is that there are still thousands of Ingress NGINX controllers in use. Why is it being put down, then, if it's so popular? Well, there is a good reason. As Tabitha Sable, a staff engineer at Datadog who is also co-chair of the Kubernetes special interest group for security, pointed out: "Ingress NGINX has always struggled with insufficient or barely sufficient maintainership. For years, the project has had only one or two people doing development work, on their own time, after work hours, and on weekends. Last year, the Ingress NGINX maintainers announced their plans to wind down Ingress NGINX and develop a replacement controller together with the Gateway API community. Unfortunately, even that announcement failed to generate additional interest in helping maintain Ingress NGINX or develop InGate to replace it." [...] The final nail in the coffin was when security company Wix found a killer Ingress NGINX security hole. How bad was it? Wix declared: "Exploiting this flaw allows an attacker to execute arbitrary code and access all cluster secrets across namespaces, which could lead to complete cluster takeover." [...] You see, the real problem isn't that Ingress NGINX has a major security problem. Heck, hardly a month goes by without another stop-the-presses Windows bug being uncovered. No, the real issue is that here we have yet another example of a mission-critical open source program no one pays to support...

Read more of this story at Slashdot.