fidzu : geek

LEGO has responded to concerns that its newly announced Smart Brick technology represents a departure from the company's foundation in physical, non-digital play, a day after the official reveal at CES drew criticism from child development advocates. Federico Begher, SVP of Product, New Business, told IGN the sensor-packed bricks are "an addition, a complementary evolution" and emphasized that the company would "still very much nurture and innovate and keep doing our core experience." A BBC News report on the CES announcement noted "unease" among "play experts" at the unveiling. Josh Golin, executive director of children's wellbeing group Fairplay, said he believed Smart Bricks could "undermine what was once great about Lego" and curtail imagination during play. Begher compared the rollout to the Minifigure's gradual introduction decades ago. The Smart Brick launches in March in Star Wars sets including an X-Wing that produces engine sounds based on movement. The technology is screen-free and physical, Begher said, drawing on learnings from previous projects like Super Mario figures where "some of the levels were very prescriptive."

Read more of this story at Slashdot.

08 Jan 2026 2:05pm GMT

An anonymous reader quotes a report from Ars Technica: SteamOS's slow march across the Windows-dominated PC gaming landscape is continuing to creep along. At CES this week, Lenovo announced it will launch a version of last year's high-priced, high-powered Legion Go 2 handheld with Valve's gaming-focused, Linux-based OS pre-installed starting in June. And there are some intriguing signs from Valve that SteamOS could come to non-AMD devices in the not-too-distant future as well. [...] Valve has also been working behind the scenes to expand SteamOS's footprint beyond its own hardware. After rolling out the SteamOS Compatible software label last May, SteamOS version 3.7 offered support for manual installation on AMD-powered handhelds like the ROG Ally and the original Legion Go. Even as SteamOS slowly spreads across the AMD-powered hardware landscape, the OS continues to be limited by a lack of compatibility with the wide world of Arm devices. That could change in the near future, though, as Valve's upcoming Steam Frame VR headset will sport a new version of SteamOS designed specifically for the headset's Arm-based hardware. [...] It's an especially exciting prospect when you consider the wide range of Arm-based Android gaming handhelds that currently exist across the price and performance spectrum. While emulators like Fex can technically let players access Steam games on those kinds of handhelds, official Arm support for SteamOS could lead to a veritable Cambrian explosion of hardware options with native SteamOS support. [...] That's great news for fans of PC-based gaming handhelds, just as the announcement of Valve's Steam Machine will provide a convenient option for SteamOS access on the living room TV. For desktop PC gamers, though, rigs sporting Nvidia GPUs might remain the final frontier for SteamOS in the foreseeable future. "With Nvidia, the integration of open-source drivers is still quite nascent," [Valve's Pierre-Louis Griffais] told Frandroid about a year ago. "There's still a lot of work to be done on that front So it's a bit complicated to say that we're going to release this version when most people wouldn't have a good experience."

Read more of this story at Slashdot.

08 Jan 2026 1:00pm GMT

Astronomers using the Vera C. Rubin Observatory have discovered a record-setting asteroid, known as 2025 MN45, nearly half a mile wide and spinning once every 1.88 minutes -- the fastest known rotation for an object of its size. "This is now the fastest-spinning asteroid that we know of, larger than 500 meters," said Sarah Greenstreet, University of Washington astronomer and lead author of the study. The findings have been published in the The Astrophysical Journal Letters. GeekWire reports: 2025 MN45 is one of more than 2,100 solar system objects that were detected during the observatory's commissioning phase. Over time, the LSST Camera tracked variations in the light reflected by those objects. Greenstreet and her colleagues analyzed those variations to determine the size, distance, composition and rate of rotation for 76 asteroids, all but one of which are in the main asteroid belt between the orbits of Mars and Jupiter. (The other asteroid is a near-Earth object.) The team found 16 "super-fast rotators" spinning at rates ranging between 13 minutes and 2.2 hours per revolution -- plus three "ultra-fast rotators," including 2025 MN45, that make a full revolution in less than five minutes. Greenstreet said 2025 MN45 appears to consist of solid rock, as opposed to the "rubble pile" material that most asteroids are thought to be made of. "We also believe that it's likely a collisionary fragment of a much larger parent body that, early in the solar system's history, was heated enough that the material internal to it melted and differentiated," Greenstreet said. She and her colleagues suggest that the primordial collision blasted 2025 MN45 from the dense core of the parent body and sent it whirling into space.

Read more of this story at Slashdot.

08 Jan 2026 10:00am GMT

The new EX60 will be unveiled later this month; here's what we know.

08 Jan 2026 8:00am GMT

"The matter involved a single crew member who is stable," NASA said in a statement.

08 Jan 2026 1:58am GMT

The Blue Oval is also working on new hands-free driver assists.

08 Jan 2026 12:00am GMT

Four years ago, I reviewed a truly fully open source desktop computer, from operating system down to firmware: the Raptor Blackbird, built entirely around IBM's POWER9 processor. The overall conclusion was that using was mostly an entirely boring experience, which was a very good thing - usually ideologically-fueled computers come with a ton of downsides and limitations for average users, but Raptor's POWER9 machines bucked this trend by presenting a bog-standard, run-of-the-mill desktop Linux experience, almost indistinguishable from using an x86 machine. Almost indistinguishable. The one thing that was missing from using desktop Linux on POWER9 was Firefox' JIT, which meant that many websites, especially more complex ones, would bring the browsing experience down to a crawl. One area where this affected me quite a bit was our own WordPress backend, which is effectively unusable on Firefox without its JIT. The only other option was to use Chromium, which was fully ported to POWER9 - but I don't like Chromium, and want to use Firefox to be able to share tabs, history, passwords, and so on. Since then, back in 2021, things have improved. The ongoing effort to port Firefox' JIT to POWER9, led by Cameron Kaiser, made a ton of progress, to the point where community Firefox builds with Kaiser's JIT integrated became available through a dedicated Fedora copr. Sadly, the last build is from four months ago, and covers Firefox 128.14.0-1, an old ESR release. Since I recently set up the other machine Raptor sent to me - a Talos II workstation with two POWER9 processors - I was curious what the state of the POWER9 JIT effort was, so I inquired on the related bug report for Firefox. Kaiser replied, and explained that due to a critical error with wasm against later versions of the JIT, as well as a change in his personal circumstances forcing him to work on this effort remotely - obviously not great for a client application like Firefox - there simply hasn't been much progress, until last week (what a coincidence!). Last week I took some time off work and dragged the JIT up to the current ESR. This compiles and links. However, although it passes the majority of the test suite, there are still too many serious failures to make it useable. I'm continuing work on this in whatever free time I actually have on my workstation. If I can restore test compliance in Baseline mode, this would suffice for a community third-party build like what Dan Horak generates now, since that is what is in 128. To get it in tree, however, I would also need to solve that critical wasm fault which manifested in the interim and fix the remaining gaps in the CodeGenerator to get it to a point of sufficient quality. ↫ Cameron Kaiser There are two main problems at the moment that make it harder than it needs to be to work on this effort. First, the state of debugging tools on ppc64le - to which POWER9 belongs - is apparently not great, requiring Kaiser to step through thousands of instructions manually using gdb just to fix the last bug he discovered. That's clearly deeply suboptimal, not fun, and not something somebody should spend their precious free time on. At this point in the discussion, Raptor's Timothy Pearson jumped in and noted that getting rr-debugger to work on POWER9 is something Raptor would be interested in, but it wouldn't be cheap: On the topic of the debugger (rr-debugger), while this isn't on our internal roadmap at the moment it is something that Raptor could do under a development contract. The main question is whether there is enough interest to make that viable; the work is significant so the cost would probably be in the mid to upper 5 figures range (USD), assuming no major roadblocks are discovered. When I was looking into it before I was fairly certain the PMU on POWER9 supports the overall structure of rr-debugger's methods, and that our load-store idioms are generally compatible. The former is what stops it working on most arm64 devices IIRC, and the latter is relevant mainly to non-POWER RISC architectures. ↫ Timothy Pearson Kaiser noted that while having rr-debugger available wouldn't be a magic bullet, it would make the whole process a lot easier. The second major issue is, of course, the same one as it always is for such niche efforts: a lack of manpower. According to Kaiser, there's enough interest and awareness in getting Firefox' JIT ported to POWER9, with the real problem being that there simply aren't a lot of people with enough knowledge of both Firefox' JIT and the modern ppc64le ISA. Understandably, Kaiser would like to avoid having to deal with people who are well-intentioned but don't fully grasp the complexity of the undertaking at hand. This is not exactly an easy effort, and it's honestly downright amazing how far along the project already is. Even if it's an older version, being able to run Firefox 128ESR on POWER9 with a working JIT makes such a huge difference to the overall desktop user experience, and I'm sure I speak for the entire POWER9 community when I say I'm incredibly grateful for it. Still, it would be amazing if we could find someone with just the right skillset to help Kaiser out, to be able to get the JIT stable enough again for community Firefox builds - and perhaps even look at what lies beyond: getting it upstreamed into Firefox as a whole. The odds of finding that person are slim - if you're into this sort of stuff, you're most likely already aware of the POWER9 JIT effort - but who knows, maybe shining some renewed light on this task will make a difference. If you happen to have the right skillset and appreciate the complexities involved in this effort, you might want to reach out.

07 Jan 2026 4:41pm GMT

About half a year ago, I wrote an article about persistent rumours I'd heard from Android ROM projects that Google was intending to discontinue the Android Open Source Project (AOSP). AOSP has been gutted by Google over the years, with the company moving more and more parts of the operating system into closed-source, non-AOSP components, like Google Play Services. While you can technically still run bare AOSP if you're really hardcore, it's simply unusable for 99% of smartphone users out there. Google quickly responded to these widespread rumours, stating that "AOSP is not going away", and a lot of people, clearly having learned nothing from human history, took this at face value and believed Google word-for-word. Since corporations can't be trusted and lying is their favourite activity, I drew a different conclusion at the time: This seems like a solid denial from Google, but it leaves a lot of room for Google to make a wide variety of changes to Android's development and open source status without actually killing off AOSP entirely. Since Android is licensed under the Apache 2.0 license, Google is free to make "Pixel Android" - its own Android variant - closed source, leaving AOSP up until that point available under the Apache 2.0 license. This is reminiscent of what Oracle did with Solaris. Of course, any modifications to the Linux kernel upon which Android is built will remain open source, since the Linux kernel is licensed under the GPLv2. If Google were indeed intending to do this, what could happen is that Google takes Android closed source from here on out, spinning off whatever remains of AOSP up until that point into a separate company or project, as potentially ordered during the antitrust case against Google in the United States. This would leave Google free to continue developing its own "Pixel Android" entirely as proprietary software - save for the Linux kernel - while leaving AOSP in the state it's in right now outside of Google. This technically means "AOSP is not going away", as Chau claims. ↫ Thom Holwerda at OSNews Ever since the claim that "AOSP is not going away", Google has taken numerous steps to further tighten the grip it has on Android, much to the detriment of both the Android Open Source Project and the various ROM makers that depend on it. Device-specific source code for Pixel devices is no longer being released, Google dabbled with developer certification even for developers outside of Google Play, and Google significantly scaled back the release of security patches to AOSP. And now it's early 2026, and Google is about to take the next step in the slow killing of the Android Open Source Project. On the main page of the Android Open Source Project, there's now a new message: Effective in 2026, to align with our trunk stable development model and ensure platform stability for the ecosystem, we will publish source code to AOSP in Q2 and Q4. For building and contributing to AOSP, we recommend utilizing android-latest-release instead of aosp-main. The android-latest-release manifest branch will always reference the most recent release pushed to AOSP. This means that instead of four AOSP code releases every year, Google is now scaling back to just two every year. The gutting and eventual killing of AOSP has now reached the point where the open source nature of AOSP is effectively meaningless, and we're yet a few more big steps closer to what I outlined above: eventually, Google will distance itself from AOSP entirely, focusing all of its efforts on Pixel Android alone - without any code contributions to AOSP at all. If you still think "AOSP is not going away", you're delusional. OASP is already on life support, and with this latest move Google is firmly gripping the plug.

06 Jan 2026 10:39pm GMT

Since we moved to a new year, we also moved to a new month, and that means a new monthly report from Redox, the general purpose operating system written in Rust. The report obviously touches on the news we covered a few weeks ago that Redox now has the first tidbits of a modesetting driver for Intel hardware, but in addition to that, the project has also taken the first steps towards basic read-only APIs from Linux DRM, in order to use Linux graphics drivers. ARM64 now has dynamic linking support, POSIX compliance has been improved, and countless other improvements. Of course, there's also the usual massive list of bug fixes and minor changes to the kernel, relibc, drivers, and so on. I genuinely wish the Redox project another successful year. The team seems to have its head screwed on right, and is making considerable progress basically every month. I don't know what the end goal is, but the way things are looking right now, I wouldn't be surprised to see it come preinstalled on system76 laptops somewhere over the coming five years.

06 Jan 2026 9:16pm GMT

2025 was a crazy simulation. A lot of glitches, plot twists and fun stuff™.

31 Dec 2025 12:00am GMT

Same as last year, this is a summary of what I've been up to throughout the year. See also the recap/retrospection published by my friends (antiz, jvoisin, orhun).

• Uploaded 467 packages to Arch Linux
  • Most of them being reproducible, meaning I provably didn't abuse my position of compiling the binaries
  • 35 of them are signal-desktop
  • 29 of them are metasploit
• Made 53 uploads to Debian
  • All of them being related to my work in the debian-rust team, that I've been a part of since 2018
  • …

31 Dec 2025 12:00am GMT

With the update to driver version 590, the NVIDIA driver no longer supports Pascal (GTX 10xx) GPUs or older. We will replace the nvidia package with nvidia-open, nvidia-dkms with nvidia-open-dkms, and nvidia-lts with nvidia-lts-open. Impact: Updating the NVIDIA packages on systems with Pascal, Maxwell, or older cards will fail to load the driver, which may result in a broken graphical environment. Intervention required for Pascal/older users: Users with GTX 10xx series and older cards must switch to the legacy proprietary branch to maintain support:

• Uninstall the official nvidia, nvidia-lts, or nvidia-dkms packages.
• Install nvidia-580xx-dkms from the AUR

Users with Turing (20xx and GTX 1650 series) and newer GPUs will automatically transition to the open kernel modules on upgrade and require no manual intervention.

20 Dec 2025 12:00am GMT