It was long-time Slashdot reader uninet who argued "Apple Needs a Snow Sequoia." (That is, Apple needs an upgrade to MacOS Sequoia that's like it's earlier "Snow Leopard" upgrade to "Leopard" OS — an upgrade that's "all about how little it added and how much it took away".) "My recent column on Apple's declining software quality hit a nerve..." he writes in a follow-up. "So why do any of us put up with software that grows increasingly buggy?" "One word: hardware. And that's where I'd love to see someone help Linux take the next step." Apple knows how to turn out very good quality pieces of hardware and, for many purposes, stands alone. That's been largely true for the last couple of decades. The half-decade of Apple Silicon has cemented this position. At any price point Apple contends, Macs, iPads and iPhones are either without peers or at the top of the market in build quality and processing power... [I]f only there were hardware that was as good and worked together as well as Apple's, jumping ship to Linux would be awfully attractive at this juncture... For Apple aficionados troubled by the state of MacOS, the modern GNOME desktop on Linux beckons as a more faithful implementation of the ideals of MacOS than current MacOS does. GNOME is painstakingly consistent across its different apps and exudes the minimalist philosophy with which Apple's hardware shines... Now is a perfect moment for a modern Linux push to take that wind back. What it needs, though, is to solve its remaining weakness on the hardware side. One of the giants of electronics manufacturing, tired of being stuck between the Microsoft and Apple ecosystems, would only need to decide to commit the resources necessary to solve the hardware puzzle... ChromeOS has grown to the extent it does because there is hardware designed for it. Take that and carry it further by making it good hardware utilizing the best Linux software and you'd have something disruptive... Initially, the hardware could be "good enough" for the software, much as Apple's software today is merely "good enough" for the hardware. Iterating from there could lead to a genuine third way of computing. They titled their piece, "I Want a Better Mac, so I'm Cheering for a Better Linux." (Wondering if Dell or Sony could be the one to supply that good hardware...) "I say this not as someone who thinks Linux will ever dominate the personal computing world, but as someone who wants to see a spark of creativity and push beyond mediocrity in it again. "Apple needs a real competitor, one alternatives such as GNOME on Linux could actually be, if only the hardware rose to the occasion."

Read more of this story at Slashdot.

Software engineer and longtime Slashdot reader, Dmitry Grinberg (dmitrygr), shares a recent project they've been working on: "an interactive-speed Linux on a tiny board you can easily build with only 3 8-pin chips": There was a time when one could order a kit and assemble a computer at home. It would do just about what a contemporary store-bought computer could do. That time is long gone. Modern computers are made of hundreds of huge complex chips with no public datasheets and many hundreds of watts of power supplied to them over complex power delivery topologies. It does not help that modern operating systems require gigabytes of RAM, terabytes of storage, and always-on internet connectivity to properly spy on you. But what if one tried to fit a modern computer into a kit that could be easily assembled at home? What if the kit only had three chips, each with only 8 pins? Can it be done? Yes. The system runs a custom MIPS emulator written in ARMv6 assembly and includes a custom bootloader that supports firmware updates via FAT16-formatted SD cards. Clever pin-sharing hacks allow all components (RAM, SD, serial I/O) to work despite the 6 usable I/O pins. Overclocked to up to 150MHz, the board boots into a full Linux shell in about a minute and performs at ~1.65MHz MIPS-equivalent speed. It's not fast, writes Dmitry, but it's fully functional -- you can edit files, compile code, and even install Debian packages. A kit may be made available if a partner is found.

Read more of this story at Slashdot.

"The big set of open-source graphics driver updates for Linux 6.15 have been merged," writes Phoronix, "but Linux creator Linus Torvalds isn't particularly happy with the pull request." The new "hdrtest" code is for the Intel Xe kernel driver and is around trying to help ensure the Direct Rendering Manager header files are self-contained and pass kernel-doc tests — basic maintenance checks on the included DRM header files to ensure they are all in good shape. But Torvalds accused the code of not only slowing down the full-kernel builds, but also leaving behind "random" files for dependencies "that then make the source tree nasty," reports Tom's Hardware: While Torvalds was disturbed by the code that was impacting the latest Linux kernel, beginning his post with a "Grr," he remained precise in his objections to it. "I did the pull, resolved the (trivial) conflicts, but I notice that this ended up containing the disgusting 'hdrtest' crap that (a) slows down the build because it's done for a regular allmodconfig build rather than be some simple thing that you guys can run as needed (b) also leaves random 'hdrtest' turds around in the include directories," he wrote. Torvalds went on to state that he had previously complained about this issue, and inquired why the hdr testing is being done as a regular part of the build. Moreover, he highlighted that the resulting 'turds' were breaking filename completion. Torvalds underlined this point — and his disgust — by stating, "this thing needs to *die*." In a shot of advice to fellow Linux developers, Torvalds said, "If you want to do that hdrtest thing, do it as part of your *own* checks. Don't make everybody else see that disgusting thing...." He then noted that he had decided to mark hdrtest as broken for now, to prevent its inclusion in regular builds. As of Saturday, all of the DRM-Next code had made it into Linux 6.15 Git, notes Phoronix. "But Linus Torvalds is expecting all this 'hdrtest' mess to be cleaned up."

Read more of this story at Slashdot.

Sous le coude : les arguments pour choisir BSD au lieu de Linux.
Voir aussi : https://aumont.fr/posts/FreeBSD-Home-Server/
(Permalink)

What's Linux's marketshare on Steam? The Steam Survey numbers tell this story: 11/24: 2.03% 12/24: 2.29% 01/25: 2.06% 02:25: 1.45% "The February numbers show a staggering 0.61% drop to Linux use..." reports Phoronix. But they attribute this to an sampling error: According to the survey, it shows 50% of Steam users using the Simplified Chinese language pack [a 20% increase from the month before]. In prior months where there has been drops to Linux use, it's been correlated to wild swings in the Chinese use on Steam. This looks to be another such month. Of the Linux specific data, SteamOS continues to prove most popular for that Valve distribution powering the Steam Deck [at 34.67%, with Arch Linux coming in second at 9.7%]. AMD CPUs power around 70% of the Linux gaming systems thanks to the Steam Deck APU and AMD Ryzen being quite popular with Linux enthusiasts.

Read more of this story at Slashdot.

De nouvelles failles découvertes dans X.Org.
(Permalink)

Christoph Hellwig continues to voice strong opposition to Rust in the Linux kernel, arguing that its introduction creates fragmentation, unclear language guidelines, and additional burdens on maintainers. He also says Linus Torvalds has privately stated he will override objections to Rust code, effectively making its adoption inevitable. Phoronix's Michael Larabel has the latest: The latest on Hellwig's perspective of Rust code within the Linux kernel is below. Some interesting insight from a dissenting view. The thread in full can be found on the Rust for Linux mailing list. [Here's an excerpt from the thread:] "I don't think having a web page in any form is useful. If you want it to be valid it has to be in the kernel tree and widely agreed on. It also states factually incorrect information. E.g. 'Some subsystems may decide they do not want to have Rust code for the time being, typically for bandwidth reasons. This is fine and expected.' while Linus in private said that he absolutely is going to merge Rust code over a maintainers objection. (He did so in private in case you are looking for a reference). So as of now, as a Linux developer or maintainer you must deal with Rust if you want to or not. [...] Right now the rules is Linus can force you whatever he wants (it's his project obviously) and I think he needs to spell that out including the expectations for contributors very clearly."

Read more of this story at Slashdot.

Hector Martin has resigned as the project lead of Asahi Linux, weeks after stepping down from his role as a Linux kernel maintainer for Apple ARM support. His departure from Asahi follows a contentious exchange with Linus Torvalds over development processes and social media advocacy. After quitting kernel maintenance earlier this month, the conflict escalated when Martin suggested that "shaming on social media" might be necessary to effect change. Torvalds sharply rejected this approach, stating that "social media brigading just makes me not want to have anything at all to do with your approach" and suggested that Martin himself might be the problem. In his final resignation announcement from Asahi, Martin wrote: "I no longer have any faith left in the kernel development process or community management approach." The dispute reflects deeper tensions in the Linux kernel community, particularly around the integration of Rust code. It follows the August departure of another key Rust for Linux maintainer, Wedson Almeida Filho from Microsoft. According to Sonatype's research, more than 300,000 open source projects have slowed or halted updates since 2020.

Read more of this story at Slashdot.