for people wondering what “folios” in Linux memory management are: https://lwn.net/Articles/937239/

Are Anti-AI Linux distributions practical?

It’s not possible to have a 100% no-LLM-coding-involved Linux distro anymore now that the kernel itself is welcoming LLM-assisted contributions, but it’s still possible to say that everything which the distro produces itself will not use AI.

How can AI commits be responsible?

What Debian means is: by reading what it produces and not just blindly accepting it but having humans review it carefully. The quality of LLM-assisted software is highly variable. Experienced people like Debian and Linux kernel developers are much less likely to publish very bad slop than inexperienced developers who are newly able to make a thing work well enough to ship it.

I am concerned about the extent of Debian’s embrace of LLMs but I still have a lot more confidence in them than most other distros (especially small hardcore-anti-AI distro projects lacking sufficient developer capacity to even keep up with security updates).

I expect we’ll be seeing lots more things like this non-upstreamable-because-AI hardware enablement and distros like Nura (formerly postmarketOS) will either either adopt more nuanced LLM policies or be forked.

I am doubtful about if there will be any serious distros with hard LLM bans in a few years from now. But also, perhaps the bubble will have burst by then, so hosted inference won’t be so cheap and the use of LLMs will probably be quite different.

the primary reason is AI is a thief

This is not the primary reason for most people, I don’t think. I think the fact that it increases complexity while reducing human understanding is the biggest problem; it’s possible (easy even) now to produce mountains of good-enough-by-many-metrics source code which the person doing the prompting has very little comprehension of. The fact that it is also a plagiarism machine is far less of a problem than this. (There are a litany of other problems too of course, several others of which I would also rate as worse than the plagiarism aspect.)

Arch doesn’t seem to have an ARM version

it’s “unofficial” but arch has had an arm port for years: https://en.wikipedia.org/wiki/Arch_Linux_ARM / https://archlinuxarm.org/

where is the source code?

Steam has a bunch of code on the page you linked, including some Steam Frame-specific code. Note however that SteamOS is not an entirely free software (open source) operating system; it contains lots of free/libre software but also contains some proprietary parts. They are only required to ship source code for the copyleft-licensed components in it; nothing requires them to actually distribute a complete working distribution for hardware they don’t want to. And, it appears that in the case of their ARM port, they do not currently distribute an image for anything besides their Frame device.

As you can see, it says nothing about researching, troubleshooting, reverse-engineering, etc. As long as you write and understand the code yourself AI is allowed for everything else. As long as you’re not using generative AI it’s fine.

I’m not sure if you’re joking or legitimately confused, but, assuming the latter, fyi the “AI” that people use for “researching, troubleshooting, reverse-engineering, etc” is part of what is called “generative AI”. Given this, it’s not much a stretch to read it as saying that even posting in Nura forums about the existence of @sv1sjp@lemmy.world’s github repo would actually be a violation of Nura’s policy (as of today; I expect it will evolve in the not-too-distant future).

Nura will not accept generated patches, by the way.

If you click OP’s github link and scroll down you’ll find this section which acknowledges that: https://github.com/sv1sjp/mi-max2-oxygen-msm8953-nura-drivers#about-ai-assistance-and-contributing-upstream

The drivers, patches, scripts and write-ups here were produced in collaboration with an AI assistant and tested on a real Mi Max 2 (oxygen).

The Nura project does not accept LLM-generated contributions. One of its maintainers explains the reasons in this post: the social and environmental cost of these models, and the risk that people use them to produce private knowledge instead of joining and strengthening the community whose work the models learned from. We respect that decision. So:

• This repository is not a contribution to Nura or pmaports, and its code should not be submitted there as it is.
• It is public documentation, not private notes. The reusable part is the knowledge: how the hardware is wired, register addresses and meanings, root causes, what was tried and ruled out, and how to test safely. These are facts anyone can check on their own device. It can save time for anyone who wants to understand what works and what does not, and then write their own code to submit upstream.
• If you want to get this into Nura or upstream, learn from it, verify it on your hardware and write your own implementation, following the rules of the project you contribute to (Nura, the Linux kernel and libcamera each have their own contribution policies).
• Please engage with the community. The Nura wiki, the msm8953-mainline project and the people credited below did the groundwork this builds on.

@OP (@sv1sjp@lemmy.world) what isn’t clear to me is why you don’t try to upstream the kernel parts, since Linux is accepting LLM-assisted contributions (as is Nura actually, just only indirectly after their upstreams like Linux accept them).

This might be useful for some Linux users who want (but don’t need) to run Microsoft 365 occasionally, but actually relying on this kind of hack is a terrible idea.

Once fully implemented, this will help draw in people into Linux, as many shudder at the thought of switching to the platform because their preferred office suite doesn’t work here.

I certainly hope this doesn’t “help draw in people into Linux”. It’s sad to think about people and organizations switching to Linux on the basis of someone misleading them into thinking that relying on this kind of thing is a good idea because when it breaks it will give them a bad impression and they’ll blame “Linux” instead of Microsoft (or Bottles or whoever told them it was a good idea).

When the lack of a Linux version of a specific proprietary program is the blocker preventing someone from switching to Linux, relying on a workaround which remains unsupported by the proprietary/adversarial software vendor is… a recipe for a bad time.

Even if this mostly works today, it is extremely likely that (either intentionally or inadvertently) Microsoft will break it in the future.

So, although I do see how this can be useful for some people when/while it works, in my opinion Linux and the world at large would be better off if this software didn’t exist. I hope Microsoft breaks it sooner than later!

iirc the Linux kernel dropped support for pre-Pentium x86 in the last few years, so any distro with 486 support now would be using an unmaintained kernel.

I think if you want a maintained operating system for your 486 today, NetBSD is probably the thing to run.

AUR is bad, actually

But why rewrite programs that existed for decades and have proven their stability and safety? Rewriting them to Rust won’t make them safer, it will just introduce the kind of issues original versions have got fixed long ago.

Of course rewriting them will introduce some new issues, but it will also eliminate classes of bugs from which there are definitely still a great many in old “stable” C code (bugs which are now being discovered and will presumably continue to be discovered at a much faster pace due to LLMs).

The whole project is about abolishing GPL. And Rust is just an excuse.

I don’t think it is just an excuse; I believe that improving security is also a goal… but removing GPL code is clearly also part of their motivation :(

No, it is not a good time. A project like Ubuntu should now be in freeze as they had about 3 months before release

This bug was reported (and resolved by rolling back to the GNU coreutils version of cp) on June 30, a little over 15 weeks prior to the scheduled release date.

Which distros have a feature freeze that far in advance?

Ubuntu hasn’t even scheduled theirs for this release yet; if you edit that url to look at previous releases’ schedules you can see their feature freeze and debian import freezes are typically about 2 months prior to release. (See here for descriptions of all of the different types of freezes…)

What an absolute shitshow

I’d say the month of June is actually a good time to be breaking and fixing things in a release that is due to come out in (checks notes) October.

that kernel release (which most distros have still not shipped yet) fixes only one of the two vulnerabilities (CVE-2026-43284); afaik even upstream still doesn’t have a patch for the second one (CVE-2026-43500) at this time.

(for people relying on Linux privilege separation, here are mitigation instructions.)

unfortunately, like its predecessor (Nokia’s Maemo/Meego), Jolla’s SailfishOS has never been (and has never had plans to be) fully free/libre open source software.

many components of it are freely licensed, but not nearly enough to constitute an actual mobile operating system you can use.

Activity lights are useful

in even more ways than one might think.

(see also this and this later work from the same author…)

based on the other comments here i had to double check if this thread was in !shittyasklemmy@lemmy.ml smh my head

You’re correct on both points (🤦‍♂️ indeed).

I’ve now edited this post to link to their advisory text file instead of their advertising-heavy blog post about it which I had initially linked when the above comment was posted. Thanks.