- Add opt-in Apple Time Machine support
Implement the AAPL negotiation and related Finder, stream,
COPYCHUNK, sparse-file, CHANGE_NOTIFY, and RPC compatibility
required for Time Machine shares, allowing macOS backupd to use
ksmbd for backups
I'm not sure if ksmbd still makes all that much sense. A user-space daemon can saturate almost any network link using a single CPU core. And the attack surface... if you control ksmbd, you immediately own the machine.
The link will be whatever the fastest network port you can get on an apple machine is. Its not 200Gbps - the apple end will be the limiting factor. A single core can probably fill that just fine.
And being pedantic - 200Gbps links are not a significant percentage of installed network ports in the computers in the world... so "almost any" is pretty accurate.
Over my life I have found that with any Apple technology it may work great with anything outside Apple's control... Until it doesn't, usually out of nowhere.
My father is mostly on Apple and tries to use his iPad as a PC, ie with files and "the filesystem", he tries to get out of using extra iCloud for pictures (using Proton, or he asks me about Immich, or he wants to use an external HDD, or use Synology Photos and backup). He's mostly on the iPad + keyboard because it's a nicely managed device update-wise and "what I can install"-wise, virus-wise.
But I recent told him: Just give up. Buy (rent!) the storage, you are too depended on me, there is always something with the non-Apple solutions. Yes, your iTunes library is a mess on the filesystem, just don't look at it through anything else than "Music". Yes, Proton Drive eats 400 GB of your iPad storage now, I don't know how to trim that regularly. I'm sorry, it's either Linux and I can help set some things up, or full Apple. Choose. His current mixed, "trying to get best-of-both-worlds", approach is just pure unexpected pain, every time again.
Edit: I also have an iPad, it does work for me, but where my father is trying to use his iPad as a central, primary device (the hub), for me it is a client (spoke) of my own infra. Apps get access to information and I never use Apple services for anything. So indeed, Immich, Proton, Home Assistant, government and banking apps, etc. My iPad is throw-away: If it dies, it dies... I buy a new one, log into all (self-hosed) services and I'm 100% back up and running. Doing the same for my father is also pain, because his Home Assistant will have issues, or his Immich instance, and it's real work to fix, and he won't tell me for months if it does not work and work piles up. So, I tell him to surrender to Apple... It die a little inside.
>My father (...) tries to use his iPad as a PC (...) He's mostly on the iPad + keyboard because it's a nicely managed device update-wise and "what I can install"-wise, virus-wise. (...) But I recent told him: Just give up
Since he apparently wants a PC, isn't the logical conclusion the opposite? "Just give up. Buy a Windows/Linux laptop, you are too dependent on Apple, there is always something with the Apple solutions."
We made the call to go Apple years and years ago when he was always fighting viruses and virus scanners on Windows. His Macbook was still (hardware-wise) perfectly functional, but does not receive security updates anymore, so he went iPad. Indeed there are more problems than expected. I expected even less IT support from me was needed. Instead he now complains about the lack of control (which I am certainly ok with btw, the complaining I mean.)
The current plan is to put Ubuntu on the Macbook, not sure what to do with the iPad but make it less "primary computer" will be one of the policies to implement indeed. Maybe he will be happy with an external disk and f-spot, and his music nicely sorted into files. Then some generic backup solution to a Synology NAS or something...
Macbooks are great devices, but Linux is a great "fire-and-forget" OS for situations tech-illiterate loved ones. I've done it many times, with much succes and satisfaction (on both ends) without barely any aftercare. All you really need to do is teach them to install those updates and install a major upgrade every few years (or not, Ubuntu will run fine for a decade).
I beg to differ, I tried that approach a few years back with my folks, only to discover on my next visit a few months later that they went down to a local PC store and got Windows re-installed.
They never managed to get it working for their liking, it wasn't able to run the stuff their friends used to talk about or share via CD/DVD/USB sticks, and they did not wanted to bother me with "dumb" questions.
So I rather that they have Windows, go down to the local PC store when something isn't working as it should.
I do the same with acquaintances whom I sometimes sell secondhand gear, I don't want to do any support so they get Windows. For my father it's different, I can do support, plus he really appreciates and is willing to make sacrifices for, the privacy angle.
I can confirm. That is basically what I did for my father-in-law. The laptop is quite ancient by now (more than 10 years old) but still good enough for running current version of Ubuntu.
> Linux is a great "fire-and-forget" OS for situations tech-illiterate loved ones.
Only if the device is truly 'forgotten'. As in, it is an appliance that's going to do that task forever and ever. Be it web browsing or what have you.
If requirements change, it becomes a problem. If they have to do work on them and interact with companies, you may need either Windows or Linux. Thankfully online Office365 removed a big use-case. But there are others. It is very likely that whatever package you need will be available on Windows or OSX.
Linux is the opposite of fire-and-forget. Eventually a papercut always turns up that will require the terminal.
macOS also has (well, had) extreme UI stability. You could transport someone from 2003 used to Mac OS X 10.0 two decades into the future and they would be able to use macOS Ventura (and all previous versions) purely by muscle memory. Good luck doing that with Windows and Linux with their constant UI churn.
Interestingly enough, by iOS-ifying macOS, they've made it much easier to shift someone using an iPhone from Windows to macOS, because they already recognize many of the UI and UX paradigms.
Linux is not fire and forget for people who use technology without really understanding it, but for people who don't use technology and just need to check their mails and connect to government website to pay their taxes, it is the best.
Once it's configured for these kind of people, it's really fire and forget, and it was already that in 2016.
> Linux is the opposite of fire-and-forget. Eventually a papercut always turns up that will require the terminal.
When I say it's been fire-and-forget, I mean that for at least two decades.
If papercuts turn up, you are running the wrong distro or secretly a power user that naturally causes problems for themselves every now and then. This won't happen with normal users on a long term stable distro.
My daughter has Kinoite set up for her boyfriend's grandparents. It's immutable, so there's not much damage they can do without admin access, and she made it look much like Windows. They were already doing everything with Firefox as it was, so it wasn't a huge transition for them.
She did go back to fix things because the grandma managed to delete the printer, and she said that the downloads folder was full of exe files with sketchy names.
I'm with you on the macOS stability in the past. The thing that gets me is that Windows somehow gets a pass in this regard, but there have been some pretty big changes over the years.
Yes, they are always changing, I know Linux since 1996, use it as part of my work, last time I used a system like Ubuntu was last year, where it failed to work with a GIGABYTE BRIX Mini-PC UEFI firmware when starting from internal SSD, which I eventually gave up after several weeks trying various workarounds.
My mother wanted a device to just access internet banking. Gave her a netbook (remember those?). Only successful Linux use-case for non techies I've succeeded at.
This is why I don't do tech support for family. I just say "I work with servers, I don't know anything about [phones|iPads|laptops]." And indeed, I try to keep my own phone and laptop utterly bone stock or "as configured by employer."
Same philosophy as doctors who don't provide medical care for their family.
I can't fathom using Windows voluntarily these days. Even for gaming, Bazzite is janky but it's serviceable, and anything is better than Windows. It's almost shocking how much worse things are than Windows 10, which itself was a major victory in Microsoft's war against its own users.
> Yes, Proton Drive eats 400 GB of your iPad storage now, I don't know how to trim that regularly.
I love Proton services and have been a subscriber for years. I do not understand what is going on with this. I have proton drive on my iPhone, I manually open it monthly to let my photos sync. I pay for the storage on proton drive to _save_ space locally, but whenever I sync to proton drive the storage space used locally by the app is almost equal to a local photo library! Yes I can delete the app, re-install it monthly to sync my library once, but it quickly balloons to dozens of gigabytes when I start to sync my local photos.
Can anyone at proton explain what is going on here?
I haven't used Proton, but based on my experience with other cloud storage products and seeing other people's reports thereon, it looks to me like you are running into the problem that there are two different use cases for them with opposite requirements:
1. Local storage is cheap, I have lots of it. I want multiple copies of my data so that they will serve as backups. I want everything in the cloud to be copied locally. (I'm in this category.)
2. Local storage is cheap if you look at the price of external hard disks, but my phone or tablet only has a limited amount of it, and no way to upgrade without buying a whole new device, so it is scarce for me. I want nothing in the cloud to be copied locally, unless I am specifically using it on this device. (Sounds like you're in this category.)
Half the people think the first use case is the obvious one. Half the people think the second is the obvious one. And that includes developers, who will design the product accordingly without giving it much thought. So either half the users get a nasty surprise in the form of running out of disk space, or the other half risk an even nastier surprise in the form of data loss.
Obviously, computers pester us with too many questions these days, but I think this is one case where the software really does need to ask the user which behavior they want. Perhaps with a hint based on how much local disk space seems to be available.
Apple will also use AI to make it at least as painful and as unexpected as before. It's their business model (I have come to believe).
Edit: But good point of course, but I believe it will remain cat and mouse, no idea how Apple internally sees it, whether they really don't care, or actively break stuff (break your ** face tonight).
I suspect what we might actually see in that regard is something similar to Minecraft (the Java based one): people were regularly modding it because it was Java based and easy to decomp and know where to inject a mod.
So the Minecraft crew would regularly release updates and obfuscate the code again - most updates were to fix issues/add features, but some were purely for obfuscation. So if you wanted your mod to work it meant not playing any other version.
I'm guessing we'll start seeing more regular updates from software makers; will the updates be fixing bugs or adding features - sure - but I'm guessing that quite a few updates will be simply to obfuscate the code and change addresses around so that any mods that worked before, won't in the new version. Sure an LLM could just decomp it again, but I figure most people won't want to spend the tokens/time it takes for the LLM to actually do the work on that new decomp effort. And with the fact that most people have "auto-update" defaulted to on, I'm foreseeing that apps will get auto-updated likely daily in the near future to combat this.
Years ago, someone once told me "I hope you live in interesting times" ... I don't think this is what they had in mind.
This already happens and has been happening for a while, especially in the Apple ecosystem. I can’t even count the number of apps that did something novel, got popular, had that novelty restricted by some update, then got “replaced” by an Apple app/feature as though they never existed.
Reverse engineering is not a magic wand you can wave on everything and expect something good to come out of it. You need to actually know what you are trying to get out of it.
Your comment, ending in "let's go back to the abacus", only makes sense if "let's stop doing reverse engineering" is a message which can be read out from your parent comment. Is it?
No, their argument was not "we should do reverse engineering exclusively by hand". Their argument was that automating reverse engineering to some degree doesn't automatically fix the issue.
Suggesting that there are these things called computers that are now a lot simpler and reliable would be met with derision because it is a valueless comment
The issue is rarely to have some working setup at a given time, IMHO the real fight is to keep it working thought the updates and ecosystem changes.
That was the same issue with jailbreaking, it gave a lot of freedom, while also being a PITA to deal with at every security fix and system change. Many jailbreakers came to parent's conclusion and just "give up".
Gotta say, using SMB with Apple clients is a massive pain in the ass. I imagine a large part of that is just Microsoft cruft, leaving you to deal with limitations designed around Windows. And you don't really have another option after Apple deprecated AFP.
Apple refuse to pay Microsoft the license for their SMB stack and have dropped open source Samba due to license conflicts with GPL, and so have developed their own implementation (SMBX). This is the reason it is so buggy, and there are loads of articles and posts all over the internet about it. Heres one example from the top of google.
It’s the insane having these discussions in 2026 given samba issues have been a thing as long I’ve been using OSX/macOS. Mixed windows/mac network shares have always been a PITA.
Time Machine support has been working on TrueNAS Scale, just via one checkbox on a SMB share config, for years. I thought it was just something in a share config that was always there. Now I wonder how did they do it.
It has been working on upstream Samba for years too, and it is just a couple of lines in smb.conf [1]
If Samba is built with mDNS support, that’s all you need, but it typically isn’t, so you also need to advertise the share using avahi-daemon or systemd-resolved on their respective configurations.
This never really worked for me. It would start a backup, very slowly send over a tiny amount of preliminary data, and then fail after several hours. I'm hoping the in-kernel support will get this working for me, but who knows...
Correct. TrueNAS uses Samba, which has supported this for a while. On TrueNAS it also creates a ZFS snapshot after a successful TimeMachine backup which is really nice for the times MacOS decides to corrupt a TimeMachine volume for no apparent reason.
Is that the reason? In the past, a kernel webserver called tux (IIRC) was removed because it was just rediculous and the performance gap was considered a solved problem, not worth keeping an in-kernel server around.
I tried setting up SAMBA by itself (on Debian) for Time Machine, but for it to work it seems to want Avahi running for mDNS; the problem is there is some weird bug or maybe user-related blooper where it collides with itself from time to time, leading to local DNS weirdness
> Still sucks that it has to be reverse-engineered
With AI and stuff like rea.tools does that really matter anymore?
Let's just accept that this is the new norm: Giant companies who had over 20 years to open their shit up, chose to be ass about it and refused, and now we can just take it. Screw them.
It does. It's the difference between "be my guest" and "catch me if you can". Currently we have better luck catching, but there's no promise that it should stay this way.
This really makes me sad. They devoted time and effort to support something as locked and as broken as Apple Time Machine. That thing is a bad choice even within a 100% Apple ecosystem.
> If you have a USB drive or other external storage device, you can use Time Machine to automatically back up your files, including apps, music, photos, email, and documents.
The "3-2-1" strategy is even possible if you rotate drives between locations:
> For extra security and convenience, you can back up to multiple disks. If you work in two locations, you may want to keep backup disks in both places.
You’d think a network drive would be included. Apple used to also provide instructions for connecting a network drive but they stopped with macOS 15 or 26. Now a drive that is physically connected to a Mac is the only method of using Time Machine that Apple officially recognizes.
edit: to be clear you can still use a network drive, but how well that works is the big question. It will probably depend on the user and the setup. The Macs in my house backup to a share on a Pi 4. They can still restore files from it just fine.
Thunderbolt external SSD, would be the only Apple-ish thing. (Formerly of course, FireWire.)
To be absolutely complete, I could mention that at least one SAS HBA PCIe card exists on the market with support for macOS 27, even. Sometimes bundled with other products...
What would be the benefit of a thunderbolt to PCIe enclosure with an HBA SAS SSD card inside, instead of just a regular external thunderbolt SSD drive? Apart from many thousands of dollars of course.
The point would be to have an enclosure of several/many SAS HDD's that you want to connect. The Thunderbolt to PCIe enclosure holds the PCIe card only, and a separate SAS enclosure holds disks. (The spinning rust type, surely.)
People also connect LTO tape drives using this interface.
Having many SAS drives on the end of a single Thunderbolt connection completely defeats the point though. whats the point of the fast PCIe link and the fast SAS drives when you are bottlenecking them all on a single thunderbolt cable?
I’ve been using Time Machine with my synology nas for ~5 years. Works pretty well. I’d say once every 2 months it looses connection but seems to re-connect itself after a few minutes.
> This release is a record-breaker on all fronts; it brought in 18,765 non-merge commits from 3,021 developers, 807 of whom were first-time kernel developers.
I'm reading that as many new AI assisted code patches. Not everyone does an obviously bad job at submitting AI assisted code.
My first patch is in this release, it was for battery level reporting of a wireless keyboard.
The main AI assistance was in determining why my mouse's battery level was easy to see, but not my keyboard's battery level. Having assistance identifying the information pipeline (kernel -> UPower -> xfce4-power-manager) and then identifying which step was broken was vital for me starting the project. The patch itself was trivial, so no coding assistance was needed.
IMHO this is where AI truly shines; being able to understand a system and its components and analyze them is institutional knowledge that requires a long time for an individual to obtain. AI can do this in a much shorter period and allow contributors otherwise unfamiliar with a codebase to make a meaningful contribution.
The keyboard is a Logitech G915 TKL. The problem is that when the keyboard was connected via the Logitech Lightspeed adapter the battery levels did not appear in xfce4-power-manager (the taskbar widget). When connected via bluetooth the battery level was visible. The root cause was that the lightspeed usb connector (device id 0xc545), one of many from Logitech, was not associated with the kernel driver needed and defaulted to hid-generic. Keyboard functionality worked, but not the battery level reporting. So my kernel patch was a simple mapping telling the kernel to use the proper, already existing recvr_type_gaming_hidpp_ls_1_3, driver for this previously unknown device id.
So what was actually broken? Just yesterday I set up my wireless keyboard on Ubuntu LTS 26.04 using bluetoothctl and BlueZ seemed to report the battery fine but I didn’t check upower.
The kernel didn't know to use the proper driver for my usb wireless dongle. Adding a few lines of code telling the kernel this usb device id requires this driver was the only change needed.
Broadly it says: you can use AI as much as you like. You have to disclose use of AI. You, as a person, not the AI, are responsible for the quality of Linux kernel submissions.
> You, as a person, not the AI, are responsible for the quality
As someone who doesn't know much about linux kernel work: what does being responsible for the submission look like in practice? Are you expected to find fixes if your change causes unanticipated issues?
I think what it means is "we will judge you based on the code you submit, we don't care if it comes from an AI". Also probably "we will judge you if you obviously don't understand the code you submit".
At least that's how I do it. When someone offers a patch to an open source project, I don't really care if that person has a PhD, or if that person does this in their free time, or if that patch is actually the result of a whole team working together. I judge the patch based on the value it brings to me as a maintainer.
Obviously the code has to be good, but also the interaction with whoever offers the patch has to be smooth: if I have a question, if I need them to confirm/change/test/elaborate on something, I need that to work.
If I feel like I would be faster doing the work myself AND this author is not putting effort into it (e.g. they just copy-paste an AI), I will not review that work. Possibly I will distrust that author. If too many contributions end up wasting my time, I will start limiting the contributions to people I know/trust, etc.
In terms of maintenance, I don't see a difference between getting a contribution from a stranger or from a stranger using an AI.
In terms of philosophy, that's obviously different: One may not want to accept contributions from people using AI because they think that AI is bad for society, for instance. And I would totally understand that. But if the stance (and it seems to be Linus' stance) is that a patch is only judged based on its technical merit, then I don't see why AI-in-the-loop would be an issue.
This was my take on it as well. Which in many ways makes a lot of sense and is pragmatic.
The thing which I think is going to be a very sore lesson for everyone at some point is that if anyone uses AI it becomes a burden for everyone. Even in projects that reject all AI usage.
What I can do is create 50 personas that all contribute patches. 40 of them get called out and are distrusted, but 10 make it through. I can give more focus on those 10 to ensure their trust level increases. Then slowly have them all come together to shepard some subsystem where I'm going to be the only real person involved and can sign off on my own work in a that looks like I have oversight from the outside.
In the past this was possible but took a very high cost. You need a bunch of competent software engineers who you can trust not to blab their secret mission. Today anyone can give it a try.
I don't disagree, and AI helps scaling many things: good work, bad work, malware.
However, I remember that a couple of university researchers (PhD candidates maybe?) thought it would be a good idea to introduce security issues in Linux, and managed to do it. Without AI and without a lot of resources.
A consequence of that was that Linux immediately reverted all the patches coming from that university, saying "we don't know if we can trust you guys" (but really I guess as a way to tell universities "if you fuck with us we ban you, now keep your people in line").
And that's what I was thinking about when I said that if too many contributors misbehave, as a maintainer I will just stop accepting contributions from people I don't know. And maybe that will happen. Maybe it will be harder and harder to just be accepted into the club of the people who can send a contribution and have it reviewed at all.
I meant as a maintainer. As a maintainer, I receive patches from contributors, I decide if I merge them or not (and under which conditions), and then I take ownership of the merged patch (as in, if it breaks I am responsible for getting it fixed).
Which means that "as a maintainer", I don't write anything. I merge code that falls from the sky. Whether it was an AI cloud or a manual-coding cloud, I don't know: from where I stand, it falls from the sky.
> there is a significant difference between "I wrote this." and "I found this."
Of course. When I write code ("I wrote this"), then it does not fall from the sky: I wrote it. I know, it's me :-). But in the open source world, being a maintainer means that you deal with code that falls from the sky. Unless you decide to close your project to contributions and only accept people you trust.
I've never been involved with Linux kernel work, but in terms of the "You, as a person, not the AI, are responsible for the quality" policy, this to me is a just an "obvious" policy that should be applied to any non-vibe-coded software.
It's just another way of saying, you can't have AI submit things on its own and you can't "blame" AI for anything you submit, you're expected to understand and be able to explain anything you're putting forward, if there is an issue with your submission, doesn't matter at all if you go back to AI to address it, so long as all issues are properly addressed.
The code is either of sufficient quality, or it's not, doesn't matter whether you or AI wrote it, it's your name on it, you're responsible for it and its your reputation on the line.
The problem with this policy is that it works well when dealing with individuals, but you can still be swamped by "first-time sloppers" - sure, each one cannot ever submit again because it's low-quality slop, but the damage is done.
(And in reality EVERYONE's AI policy is a variation of this no matter how strict they get, because very few people will suddenly rip all of tridge's code out of Samba if he admits he used AI once, and nobody can withstand slopspam for long.)
Being responsible for the quality of the submission means that when other kernel developers say, "hey this part sucks, please fix it," you are obligated to fix it or defend your position, if you want the patch to be accepted into the kernel.
That last part is worth highlighting: you always have the option to not follow-up and abandon your proposed change, in which case it won't make it into the kernel. (Unless someone else picks it up and volunteers to get it into shape for that is acceptable for merging into the kernel, but that is vanishingly rare, unless the change is trivial.)
You aren't expected to hang around and maintain your patch once merged, that's what subsystem maintainers are for. But you would be making their lives a lot easier and earn a lot of respect if you did.
Basically, you can't just post slop and then say, "Oh, sorry, the AI did that." If the comments are too wordy, or the patch is unnecessary or poorly written or contains errors or doesn't follow the style guide, you submitted it, so that's on you. If you get in the habit of posting bad patches, people may start ignoring you.
Don't forget having Linus Torvalds ridicule you in front of the entire world. That alone is reason to be vigilant that your code submitted isn't hot garbage.
How long until we get "all FOSS code is made by AI and so it's not copyrighted" arguments when using code in unlicensed ways?
It also hides what would be a great signal on which ML models to use to get the best quality code. Like, wouldn't the community like to know which models made the code with the least bugs?
Its a pointless tag. You can say a tag is required if you use AI, but the linux maintainers know some people are still just going to lie. And they know having this rule will lead to the occasional witch huntwhen someone tries to sus out code that seems AI written but does not have the tag.
They dont think the juice is worth the squeeze. LLMs are just another tool.
Except writing patches to an existing project creates a derivative work, and the original copyright still applies to the project, even though your individual changes are owned by you.
(This is why fan made videos using copyrighted characters can be taken down.)
That sounds reasonable.
I would even go one step further and drop requirements to disclose AI use.
I think the person submitting the work should be fully responsible for what they submit and is more than enough.
If you have a karma system for contributors, you get a pretty good idea of who does a good job.p
I hear you, but I don't think is a good idea to say that someone who used AI for a patch, did not understand the changes.
We can't conflate the two.
If you spent 20 seconds to generate a patch and just hurled over the fence to be reviewed is no worse than spending 3 hours to manually write a fix that fixes 1 thing and break 2 others.
100% of AI use should have to be disclosed in all cases, not just software. A person using an AI is foregoing responsibility from the get go by using an AI to do things that they can't personally do. What would it even mean for them to be responsible if they submit a patch to a project written by an AI as their own work? Such a person submitting a patch they don't understand that is rejected is in exactly the same place as if they had never submitted a patch. They have nothing to lose.
Or they don't care whether the code was produced with vim, VScode with an autocomplete tool or AI; they will judge the code based on the quality of the code and the quality of the interaction with whoever submits it?
Nothing says you have to use AI. Just like nothing says you have to use a computer. You could have someone print the code for you, write your patch with a pencil on paper, get a pigeon to send your patch to someone who can then submit it, and it would be judge in the same manner. Granted, it's probably more efficient to use a computer.
Well if my employer was willing to pay me to contribute to open source projects like Linux, under the condition that I used AI, I would gladly do it :-).
On the one hand it is concerning, on the other hand… I was getting quite worried the iPad generation was going to be incapable of developing operating systems. If AI is now capable of maintaining it, that will save us from collapse.
As long as "the iPad generation" can write and maintain ML tools? Because otherwise all software gets locked behind the tools which as they grow more complex will require more access to more resources to produce.
Doesn't this just end up with the tech billionaires being the only ones who can make software. Will they decide to allow their models to maintain/create FOSS? Seems unlikely.
Oh this is incredible.. HaLow has been one of my favorite new wireless tech implementations, and I feel almost like a preacher with how much I have been pushing the gospel to the people around me for the last ~2 years. being introduced into the kernel should really help integration and usage. I am just hoping chips start being produced by more than one (?) company eventually for more market capture. Any thoughts on that front?
I'm not the expert in this area, but the current state of play AFAIK in terms of working chips is:
- Morse Micro
- Newracom
- Taixin are mostly not compliant (but cheap)
- Amazon have a proprietary not quite compatible HaLow in their Blink cameras
There's varying levels of interest in WFA compliance/interop. Morse and Newracom are the most interoperable, but even then there are gotchas.
The Morse ones, are, of course, the best ;)
Aside from upstreaming, one of the other things we're chasing is a better regulatory environment. In particular, the EU S1G bands are very tightly constrained.
It's low-energy like Bluetooth/Zwave/Zigbee, long range like any other 900Mhz Band protocol (LoRA does 10km or so in normal conditions, can go even further), but for when you need higher datarates. According to the Wikipedia chart it can max out at ~300 Mbps depending on modulation, though I don't know enough to speak to range/bandwidth tradeoffs, though I imagine there are.
Honestly seems pretty interesting. I had a lot of fun setting up a 4G carrier for my home so I can get decent speeds out on my back porch (5GHz can't cut through my ancient balloon frame walls/door, and 2.4GHz is a congested soup around me, useless), I wonder if I can wrangle some hardware together and start experimenting with this. Could be nice to get some remote SDR workloads off of 2.4GHz while still getting WPA3 encryption.
I personally looked into their code an patches. This is an absolute mess of workarounds, permissioning negligence and other types of antipatterns.
They are truly and utterly a definition of a slop. And, expectedly, their work is unstable and not efficient, just look into Reddit discussion complaining about power draining.
I am afraid no one, or very few, has any deep understanding of low level architecture of these platforms or even Linux kernel and hardware in general, looking at their contributors’ previous front end NodeJS projects.
The only good thing is you can take their otherwise time-consuming work, have an agent infer and write a spec and use that to implement proper improvements in an, ironically, truly clean-room fashion.
> If you took the time to really analyze their codebase and judge, why don't you submit some PRs to help them improve?
You think it's the same amount of time for both?
> It makes no sense to put them down on HN
Put them down? How, by sharing what I saw in their codebase, which anyone else can also do?
That's some apologist nonsense here and you sound super biased with those suggestions. I made and effort to assess the technicality of what I saw and I would absolutely stay away from what they do.
> Critical Bugs get caught quick too.
This is not just about kernel oops kind of bugs with a nice trace that LLM will fix in 5 minuyes. It's the race conditions, the lockups, all type of architectural, high-level things that their code does that create non-deterministic bugs, i.e. untraceable and virtually unfixable by LLMs nor a human being.
As someone who hasn't looked at the repositories in question;
> why don't you submit some PRs to help them improve?
Is often a non-starter. If you believe a codebase is poor quality, any changes to improve it have a strong risk of making it worse and/or wasting your own time. In the case that you aren't a key player in said codebase already, it is even more likely your attempts to make changes will fail. Its not impossible to improve these repositories however doing so is quite a different skill-set to identifying their failings.
> I coudln't care less about what's going on under the hood.
This is why there will likely be fragmented efforts for bringing up the hardware. Asahi already struggled merging all of their patches into the kernel, there's a 99%+ chance that Omarchy's patches will never be fully upstreamed if the reverse engineered devicetree is uninterpretable vibeslop.
So, even though Asahi's the slow-and-steady side, it makes a lot more sense to channel your effort there.
> will never be fully upstreamed if the reverse engineered devicetree is uninterpretable vibeslop.
The device tree is the least of a problem, it's a very limited, highly structured language, you don't need super deep understanding of things to get it right.
Problem is the drivers they write. The hacks, the workarounds, the utter mess. There's hundreds of commits that I am certain no one keeps track of and understands their true purpose.
Intel and AMD sell to customers that build computers running Linux, especially servers. Apple sells to itself, to build computers that run their own OS.
No one said otherwise. We’re discussing the speed of onboarding here. Intel is fast, Apple support via Asahi can do what they can do, but it must be and is slow without any documentation whatsoever.
Furthermore we are lucky that Apple at least tolerates Asahi and does not throw at them more technical hurdles, legal issues (DMCA?) or whatever. Based on past history (in the 90s, so a lot of management changes) Apple would shut them down if they were a threat to their bottom line. I remember the shortly allowed Mac clones so, a possible scenario: a significant fraction of sold Macs is immediately reinstalled with Linux and provide zero dollars to cloud services and followup sales of other hardware. Apple is not going to like that.
Sure. But is that a reason to complain? If Apple made bikes, they may be nice bikes. But I don't see a reason to complain about Apple not making bikes. I mean... they don't have to, do they?
Would be cool if Apple decided to support Linux, of course. But why would they? If it was profitable for them, they would do it. Instead they think it's more profitable to enshittify their products. That's life.
Now people who reverse engineer that to help us run Linux on Apple hardware... I would guess they don't make a fortune doing that, and I find it impressive work.
> I don't see a reason to complain about Apple not making bikes. I mean... they don't have to, do they?
This analogy is really tortured. Apple doesn't make bikes.
But they do make software, and hardware. People want to use them however they choose.
This is more like a bike company choosing a proprietary air valve that only lets you inflate your bike tires with their own company-branded air pump, even though there's been other air pumps for many decades before them, and their design isn't particularly better than the others. And you say "well they don't have to design an air valve adapter to use other air pumps" and -- yeah, that's true. But people are gonna bitch.
So we agree :-). Of course I would like it if Apple was making my life better. I just find it naive to consider that companies are anything other than profit-maximizing machines. If they happen to do something you like, it's because it is profitable for them. They couldn't care less about you.
> But people are gonna bitch.
Whatever you do, people are gonna bitch. Again it would be a bit naive to think that if you do "your best", or if you do "what's right", or if you "genuinely try", then everybody will appreciate. There will always be enough people bitching, of that I am certain.
Some people like Apple hardware, but not Apple software. I wouldn't be surprised to find out, that some of them might even work in the Apple. Not everything must be about immediate consumer profit. Developer goodwill also worth something. Remember Steve Ballmer? Developers, developers, developers, developers...
It's perfectly reasonable to complain about things you aren't entitled to. My Surface brand laptop has similarly ad-hoc Linux driver support. I don't expect Microsoft to support it better, but I'm still annoyed they don't.
I have this dream that previous gen M chips will be worth more than current gen M chips b/c people want to run local inference on Apple silicon... but they want to use Linux and not OS X.
I'm curious on why you think that, say, an M2 running linux will ever be a better choice for AI workloads than an M5 Pro running MacOS? What is it that you think is in the hardware that you'd be able to unlock with linux but isn't exposed by MacOS?
I'm sure a lot has changed since cough 2004, but that was the state with the PowerPC G4 and G5. Machine learning Linux applications used the IBM Power architecture because of their vectorization features, and that hardware was ridiculously expensive. When Apple started using Motorola and IBM's cheaper PowerPC chips with Altivec this small market was pumped, but none of their groovy scientific applications worked on OSX.
This created a large enough market for Linux distros installed on Apple hardware to make it a sustainable business model the makers of Yellow Dog Linux to buy the hardware through a reseller channel, ship it to the building, install Linux on it, then ship the device to customers. I worked there and it was fun.
Lots has changed since then of course, one of which being that Apple controls the chip from top to bottom, and their near-indifference in 2004 now seems to have transformed into something more adversarial.
> I'm curious on why you think that, say, an M2 running linux will ever be a better choice for AI workloads than an M5 Pro running MacOS?
I mean that if Asahi starts to gain on Apple with respect to generation of M chip they support. If Asahi supported M4 chips...
But clearly, my dream hasn't come true yet :-)
> What is it that you think is in the hardware that you'd be able to unlock with linux but isn't exposed by MacOS?
I believe that Linux would give me more control over exactly what is running on the machine (and using up precioius memory). Maybe it would also have better support for the toolchain/ecosystem needed to run local inference?
On the other hand - I just had to send my Asus vivobook s15 to repair, because Linux (most likely) fried the wifi chip.
Pretty disappointed in Qualcomm's promise of upstream support for Snapdragon X Elite turning out to be: lol, not actually so you can run Linux on devices, only so you can maybe boot without most devices working...
Hope things will keep improving despite lack of help from vendors.
The radio limits are very heavily guarded by the firmware solely because its regulatory compliance: different jurisdictions have different limits and you can’t just let userspace or kernel change it at will. Heck, most manufacturers don’t let you change WiFi card anymore or allow only a whitelisted WWAN card for same reason.
So, I would be super interested how you inferred it was Linux’ fault but I sssume b/s at this point.
Well, I'd say it's Asus fault for having crappy firmware - but Linux triggers it - causing the card to permanently no longer come up on boot.
"Fried" was a poor choice of words - the device is dead - but it's due to firmware and probably something to do with sleep states.
I didn't mean to imply the radio was actually fried.
It'll be interesting to see what the technicians end up doing to get it working. It might be enough to disconnect the card and force some even deeper reset than a power cycle with drained laptop battery does - but as I still have valid guarantee on the machine, I stopped short of opening it up. Especially since I might need a new wifi card anyway.
If I were to wild-guess here, it sounds like and rfkill in nvram that isn't properly handled by the Asus EC driver for your laptop model. This is a fairly common issue for Windows-first laptops and Asus EC drivers are reverse engineered because they don't support Linux themselves. I assume switching to Windows was not bringing it back anymore?
Chance is you could probably have Claude or Codex had look into it and have them fix it for you.
I had ai look into it, and that took it from works in windows, shows up in Linux - to dead and gone from both os'.
Ed: user AI on the Linux side, to help with getting firmware blobs etc - might be random combination of flaky firmware, flaky Linux support and reboots that did it - not AI or any particular driver/firmware version.
It's the first time I've seen drivers knock out a hw component completely on a consumer product - but I gather the platform is fickle.
The arm64 Snapdragon elite support is very poor unfortunately (due to there being zero upstream support).
Which wouldn't be so bad if they weren't marketed with a promise of Linux support.
Well, thanks for the write up. Will be interesting to hear what they fixed, but chances are they'll just replace the board and not think twice about it.
It's not the radio actually frying the chip - poor choice of words on my part.
It's the firmware that locks up - with Bluetooth and wifi devices not working at all anymore (does not show up in Linux or Windows device manager). And even a complete power drain and reboot can't resurrect them.
I want to see the same graph but for number of CVEs introduced. ie, when we find a CVE, find out which kernel version introduced it. This would only be useful for kernel versions that were a few years old, so we'd have had time to find most of the CVEs. But it'd still be interesting.
There's a graph for bugs and bug-fixes (not CVEs, but in linux close) near the end of this article that looks approximately like what you are interested in: https://lwn.net/Articles/1088776/
> This release is a record-breaker on all fronts; it brought in 18,765 non-merge commits from 3,021 developers, 807 of whom were first-time kernel developers.
hopefully without kernel-slops :P good job everyone btw!
1. They weren't counting LOC though, but commits. It's a totally different metric.
2. This type of stat was always being shared with each new release, giving a general indication of the size of changes. They did not started posting it all of a sudden due to AI.
I think in Linux world commits usually mean something which isn’t always the case at random company X. A commit being a meaningful change where number of lines doesn’t matter.
A commit can delete or modify lines, it at least isn't as bad as the "more code = better" approach, though perhaps it's still flawed in that you could have lots of very minor commits to increase the count, or do and then undo a change to get 2 free commits.
Linus thinks AI is no different from a compiler, so it's likely that none of these commits are being reviewed. After all, how often do you doubt your compiler's output?
During peer review a race condition was found in his code. Would he have spotted it himself when writing the code manually? Maybe, maybe not. He's only human, and the AI is only AI.
I think this is yet another case where Linus is leading the pack and showing the industry how to adapt to new technology, and indeed, adopt standard best practices for its application.
I'm in the "AI is great!" optimist camp myself, which is how I felt in the very early days of "this little crappy hobbyist Linux kernel thing that'll never go anywhere important" minix-list flamewars.
Once again, Linus demonstrating that those who understand the code, own the code.
"Showing the industry how to adapt to new technology", as in, don't blindly trust whatever the big probability box committed to your repo but actually perform a good code review with the same standards as human-written code?
I think this says way more about the industry being completely out of touch and less about Linus leading the pack.
Yes, usually when the flock is lost in the wilderness, its leaders need to raise their heads and lead the way. Linus is applying the same great engineering methods he's always had.
Please stop with the "AI assisted development" = "Vibe coding slop" narrative. It comes across as pretty dumb (sorry, I mean "uninformed") nowadays. Please experiment with LLMs, find your way (or don't, but), learn to talk about it in an informed way and don't post obviously inflammatory one liners that are essentially just "AI is bad m'kay".
There are intelligent arguments against using AI, your comment is not referring to any of them.
In short: Linus feels responsible for the quality of the Kernel, he expects the same of other devs. He does not care about the tools used to generate the code. He (or some other human) will call out submitted slop, whether LLM generated or human generated.
It's increasingly the other way around, actually. You are being sloppy if you don't use the tools available to you. Including AI, static code analysis, testing tools, etc. to check if your work is any good. That doesn't mean you have to surrender to the AI tools and blindly generate everything and then commit without testing or any form of validation. That would be sloppy. But then if you manually write your code and did that, that would be sloppy too. Whether you manually type in all your code or have it generated is immaterial. What matters is the work you do to ensure it all works as advertised and is fit to be merged.
The kernel developers are probably a bit further in their thinking then some developers. They've been dealing with many thousands of contributors for decades. Git was invented by Linus Torvalds specifically to deal with ensuring only the best patches make it into the kernel.
Somebody posted a video with Greg Kroah-Hartman last week or so commenting on how he's been dealing with all the AI generated security bug reports. His key point is that AI generated reports are meaningless unless they come with a suggested fix as well. If you are going to generate the report, you might as well generate the fix. And it's a lot easier for him to review if the fix fixes anything worth fixing then to piece together a fix from a lengthy report. The larger the report, the less likely it is to get any attention. If the person contributing can't articulate why the fix is needed or how it works, they just reject the change and toss it back. That strikes me as very pragmatic. Judge a change on its merits. Not on how it was created. A report without a suggested fix is relatively meaningless.
There’s such a breadth of slop quality. Like I’ve seen people using ChatGPT with thinking disabled, which is just garbage. But you can also use an LLM to do automated testing of your product, in a real browser window, where it actually sees how it looks via screenshots. That’s insanely useful.
And it can read all of the logs in the backend and browser simultaneously and understand what is causing issues. I’ve used that a few times and it is such a game changer for weird bugs.
100%. I think there are a lot of people here on HN that are very threatened by LLMs, rightly so. I'm also afraid of my future and my day-to-day work has already changed from "loosing myself in a flow state solving technical puzzles" to "micro-managing LLMs". I don't like it, but hope I will learn to, at some point, or perhaps I find different work. I feel like I don't have a choice right now but to adapt and learn.
The answer to this issue is not to equate any code generated by LLMs to slop. It is just not true. As you say, the latest models often flag things that I would definitely miss, or they simplify my code significantly with a just-released feature. I see benefits to code quality all day from using LLMs.
I'm just saying (not to you but to comments below): Lets keep it constructive, which means: lets keep it real, as in close to truth. Yes vibe coding exists, and it has it's place (ie in prototyping?). But not in the kernel, and also not in my own line of works. LLMs do have a place there though.
The rate at which AI introduces bugs is higher than human ones about 2x more bugs than humans.
Human slop is equally as bad, but this is not what Linus chose in this case, he chose to accept the higher risk of almost 2x as much more bugs using LLMs which lead to the introduction of LLM slop.
I don't care if it is Linus or anyone else, slop is slop human or not, with LLMs it is far worse.
If the human is doing a proper workflow for the AI, I'm not so sure it's big central. Yes, AI needs to be guided strongly, and if it's not, it makes very poor choices/decisions routinely, but that's why you keep an engineer controlling the process.
I force all work to be split up into chunks, properly investigated, spiked, and planned out, and then implemented via TDD (with only system-boundary mocking permitted). It's not perfect, but I've seen regression bugs very much cut so far.
Beyond that, if it's a GUI app, I also require the TDD cycle to require GUI tests with screenshot evidence, and proper assert statements.
Making LLM write code is super susceptible to generating problems imo.
You know it won't be properly reviewed and understood.
Using LLMs to review code is much more useful imo but it can also cause problems due to the natural lazyness of a person.
You wouldn't want the OS you are using to be developed by a dilligent but a low IQ and mediocre skill level programmer.
I'm not saying other people can't possibly use LLMs to generate code effectively but it seems super suspicious from my experience as it triggers laziness and reluctance to put effort into understanding every piece of code.
> You know it won't be properly reviewed and understood
Do you now?
> You wouldn't want the OS you are using to be developed by a dilligent but a low IQ and mediocre skill level programmer.
So you also know that people using LLMs to produce code are diligent but low IQ and mediocre skill?
> it triggers laziness and reluctance to put effort into understanding every piece of code.
Linus has been mostly reviewing code for what... decades? The rest of the contributors have been his LLM in some way. Would you say that he has gotten "reluctant to put effort into understanding every piece of code" he reviews?
I think they did, "You know it won't be properly reviewed and understood." This is just a lie, I review and understand LLM generated code daily. So do many others. Maybe you should be more clear?
If I had to guess, I would say that what you meant was that LLMs can be used to produce worse code and worse programmers, and we don't want that.
And then somehow consider that because LLMs can make bad programmers worse, it has to mean that it will make all programmers worse. And therefore Linus Torvalds using LLMs will necessarily make Linux worse.
> You know it won't be properly reviewed and understood.
This reads a bit weird in hindsight but what I meant was it just feels like that to me.
> I'm not saying other people can't possibly use LLMs to generate code effectively but it seems super suspicious from my experience as it triggers laziness and reluctance to put effort into understanding every piece of code.
This part is my personal experience with trying to use LLMs for code review and sometimes to write a bit of code via opencode.
> diligent but low IQ and mediocre skill
This is how I see LLMs.
In my personal experience, it is not worth to make it write code because then reviewing the code becomes more work than actually writing myself and get LLM review + fix and review again myself.
It can be very good at writing code but the instances where it messes up just cost too much for me to disentangle and making it write things I don't understand doesn't work because I can't review.
I can't judge Linus Torvald's ability but this is my perspective so if I had to guess, I would guess that it isn't necessarily efficient for him to generate code with an LLM because he is spending more time reviewing it compared to him writing the code.
> In my personal experience, it is not worth to make it write code
Sure, totally fine with that! I am completely okay with people not using LLMs, just like I am completely okay with people using an IDE instead of vim. Do what works for you.
> I would guess that it isn't necessarily efficient for [Linus Torvalds] to generate code with an LLM
It seems like he disagrees: sometimes it makes him more efficient. But in any case, I think it is his choice. I won't judge him for using an LLM, or an IDE, or even if he wanted to develop on Windows. Why should I care? I care about his contributions.
My problem is that many people say "I don't like working with LLMs, so I don't want other to use them". If you don't like working with LLMs, just don't. And let others use the tools they want.
Except if it is philosophical: something like "I believe LLMs are bad for society because X and Y, and I don't want to be related to them". Similar to "I don't want to work with weapons" or "I refuse to open source my code because it could be used to build weapons". Sure, I respect such ideas. I don't respect the "I don't like this tool so I think people who use that tool are unprofessional".
Failfs is a pretty cool pseudo-filesystem where every path lookup fails. So if yu place a statically-linked process into failfs with ONLY pre-allocated file-descriptors at process birth, close down unneeded sockets and enforce a default-deny firewall discipline, compromised applications are effectively isolated and unable to access local files or spawn shells during an exploit. An attacker can NOT move adjacently from the exploited process to other parts of the system because to do so they'll need to navigate from root and that would fail since yu set root as failfs and you've got yourself a pure, isolated data-processing pipe that can only interact via the exact file descriptors it was given!!
Unfortunately, yu can't use dynamically-linked apps anyway since failfs would break absolute path resolution loading system libraries.
EDIT::
But I guess yu could put a statically linked app on the socket, wrap it in failfs and gave it proxy requests to a dynamically-linked app process if your app must use something like python.
Is it possible to load the dynamic libraries before fork()ing and somehow prevent the path lookup and library loading? This will open up new possibilities for hardened security models.
That's a fun idea but take python (very familiar)... It's very deeply dynamic and even if yu run imports at the top of your code yu still have many large libs with lazy code execution baked deep inside their internal functions so that assumes yu actually know what code paths the application will hit later. More importantly this goes in the opposite direction of Python's lazy imports thingy.. basically you've got a bomb and yu wouldn't wanna do that. Also, imagine the startup time for large apps. I'd just put a statically-linked binary in front and proxy back to the dynamically-linked process if I can't rewrite the main app in something like Go or Rust.
You explicitly stated as such, I just want to emphasize it again: it only breaks dynamically linked libraries, which - from a stability point of view - is an antipattern anyway.
Almost always youre better off producing a bundle which has everything (excluding the runtime) included... Or just use better languages which categorically don't even have this scenario, eg golang, Java, rust, etc pp
ah, first sentence I thought yu was a typo. Second sentence I saw it I thought it might be a linux component of sorts. So it's not just a stylistic choice, it's actually harming my comprehension of what they're writing.
A process which is chrooted into failfs cannot open new files. It is limited to the set of filesystem file descriptors it already has open (presumably set up before the chroot or inherited into the process from some container runtime).
I'd love if chrooting would become easier. In particular a
requirement to have bash or a specific shell is annoying;
imo a simple REPL should suffice already there. I wrote one
that works years ago, need to look into what is all needed
for a chroot (I always used bash for this but I'd also want
to change to my own shell eventually).
We wanted capabilities[1]. Instead we get this over-complicated series of system calls with no design consistency that you have to use very carefully, else they can be bypassed (see the list of caveats on the failfs page).
I'd love to have one that randomly fails, so we could debug e.g. databases and other apps that are supposed to be resilient. I'd call it "havocfs". Doesn't corrupt data, just randomly fails reads/writes/etc. Some software is supposed to handle that gracefully. Would be a great test tool...
proposed by John Ericsson (Nix core contributor) for the idea of Null namespaces to make namespaces cheaper for when doing finegrained sandboxed builds.
It looks like this release will likely unlock the ability to develop relocatable Nix packages on Linux, thanks to some great work by Farid Zakaria and Christian Brauner! I'm hopeful that it also eventually improves the story for mixing Nix and non-Nix software.
But it could be DKMS module or something other run as separate project? I got software arch point, but it seems very odd having such things in kernel project, no?
If the kernel had a standard ABI, an out-of-tree kernel module would be the way. As it is, DKMS is a pain and so in-tree modules are the easiest where license allows it.
Linus decided it's OK, so it's there. If Linus wouldn't approve it, DKMS would be an alternative. There are plenty of stuff in kernel, which might look weird to be there.
1) why does it matter “my” patch was submitted? I am simply a bystander but can’t help notice a tone of being admitted to a tribe? Am I wrong ? (It’s ok if it’s a tribe just validating my observation is correct or incorrect)
2) is the Linux kernel on its way to obsolescence? Our field of software engineering and how and what it’s applied to is changing at a drastic rate. The os was built for programs to run which were built by programmers. The programmers thought about what the users of their programs needed to get stuff done and use the programs. This paradigm is changing - fast - an in 10 years it’s going to be very diff place where the users simply build programs or their agents etc. thier expectations of the OS and what “services” and interfaces the os exposes is going to change. And at some point the current os architecture is just not relevant. To build an AI first OS it’s prolly easier to build it from the ground up than keep changing Linux. It’s like we can keep trying to slap on jets to the car to make it go faster but it’s prolly just better to build a plane. We still will need to travel just what we use is going to be diff and as such older mechanisms of traveling will just be irrelevant. Why am I wrong ? What am I missing ?
If you want your code in the kernel, it has to be accepted. If you don't care, then it doesn't matter at all.
> is the Linux kernel on its way to obsolescence?
Only if computers are, which is unlikely.
> Our field of software engineering and how and what it’s applied to is changing at a drastic rate.
Rate of change is not a useful metric here.
> The os was built for programs to run which were built by programmers.
AI code is still programs written by programmers, it's just some of the programmers are AI.
> The programmers thought about what the users of their programs needed to get stuff done and use the programs.
Yes, this is how you build software useful to the users. This won't change. If you make a program without thinking about how it's used, you haven't made a useful program. There are lots of apps throughout history in this pile, programs that were never fit for use.
> This paradigm is changing - fast
It's not, and it never will. Programs always have to be fit for use, and have to be useful tools for the users.
> - an in 10 years it’s going to be very diff place where the users simply build programs or their agents etc.
This doesn't change anything about Linux or applications, though. 100 years ago you bought meat and veggies grown nearby so your home because we didn't have transportation. Refrigerated trains made it possible to ship food long distances quickly and while cold. However, this did not change the way people ate the food, they still used pots and pans to cook, plates and utensil to eat, etc. Same thing here. Rather than artisanal, hand crafted code we'll use robot-generated code, and it won't matter at all to the user, or how applications need to be fit to the job.
The kernel doesn't follow conventional semver practices, meaning that the major number incrementing has no effect beyong the minor number got too large. So there's nothing inherently different in a 7.X release from a 6.X release.
Either way, an LTS appears to be released ~every 6th version, 6.18 is the newest LTS, so after that there's 6.19, 7.0, 7.1, 7.2, 7.3, 7.4 maybe LTS?
I'm surprised the FAQ does not mention it, but the pattern is that the last release of the year is made the LTS version. Notice the release date is always EOY. This is nothing strictly documented but it has been that way for years.
People may have specific hardware issue that's blocking them and a new kernel release fixes the issue. In that situation they see this announcement and they may be technically brave enough to want to install and check it. Currently they have to find and go to something like https://kernel.ubuntu.com/~kernel-ppa/mainline/ , find the right versions, download multiple files and then `sudo dpkg -i linux-*.deb` and then confirm if their issue is fixed.
I'm not saying it's a great idea, but I'm explaining why people may expect to have a smoother path here.
Which will just put pressure to improve the testing situation, not necessarily change stance on AI written patches. In fact AI is quite good at catching issues and root causing them back to recent changes so they could automate that journey a bit better as well to fill in any gaps not caught at review time.
Remember, you are "not allowed" to criticize Linus about how he uses LLMs on patches he himself doesn't understand in the Linux Kernel, despite screaming at others in doing the exact same thing (with him and Claude introduces a bug in the process).
This is especially with C code which has hundreds of foot-guns and you can just look at how Linus does not care about code quality in something as critical like an OS kernel and then carelessly introduces a race condition.
If that was anyone else and Linus caught it, they would be completely smoked by his wrath in the mailing list.
SMB improvements (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...), I've moved to borg, but depending on how this goes may give time machine another try:
https://www.phoronix.com/news/Linux-7.3-KSMBDStill sucks that it has to be reverse-engineered
I'm not sure if ksmbd still makes all that much sense. A user-space daemon can saturate almost any network link using a single CPU core. And the attack surface... if you control ksmbd, you immediately own the machine.
Even if I did have a requirement that SMB saturate a network, I would probably still not want it to be implemented in the kernel.
> A user-space daemon can saturate almost any network link using a single CPU core.
Not 200Gbps of 16kB block writes, that's for sure.
Agree with you on the rest about kernel vs userspace, just taking issue with the bit about a single CPU core.
In context of time machine backups...
The link will be whatever the fastest network port you can get on an apple machine is. Its not 200Gbps - the apple end will be the limiting factor. A single core can probably fill that just fine.
And being pedantic - 200Gbps links are not a significant percentage of installed network ports in the computers in the world... so "almost any" is pretty accurate.
> A user-space daemon can saturate almost any network link using a single CPU core.
Certainly not a guarantee at today's link speeds. We're increasingly leaning into RDMA and other forms of offloading for a reason.
[flagged]
Over my life I have found that with any Apple technology it may work great with anything outside Apple's control... Until it doesn't, usually out of nowhere.
My father is mostly on Apple and tries to use his iPad as a PC, ie with files and "the filesystem", he tries to get out of using extra iCloud for pictures (using Proton, or he asks me about Immich, or he wants to use an external HDD, or use Synology Photos and backup). He's mostly on the iPad + keyboard because it's a nicely managed device update-wise and "what I can install"-wise, virus-wise.
But I recent told him: Just give up. Buy (rent!) the storage, you are too depended on me, there is always something with the non-Apple solutions. Yes, your iTunes library is a mess on the filesystem, just don't look at it through anything else than "Music". Yes, Proton Drive eats 400 GB of your iPad storage now, I don't know how to trim that regularly. I'm sorry, it's either Linux and I can help set some things up, or full Apple. Choose. His current mixed, "trying to get best-of-both-worlds", approach is just pure unexpected pain, every time again.
Edit: I also have an iPad, it does work for me, but where my father is trying to use his iPad as a central, primary device (the hub), for me it is a client (spoke) of my own infra. Apps get access to information and I never use Apple services for anything. So indeed, Immich, Proton, Home Assistant, government and banking apps, etc. My iPad is throw-away: If it dies, it dies... I buy a new one, log into all (self-hosed) services and I'm 100% back up and running. Doing the same for my father is also pain, because his Home Assistant will have issues, or his Immich instance, and it's real work to fix, and he won't tell me for months if it does not work and work piles up. So, I tell him to surrender to Apple... It die a little inside.
Same here. I setup a few Macs for my family to use LDAP and NFS. Gave up after some time due to Apple changing things at will.
>My father (...) tries to use his iPad as a PC (...) He's mostly on the iPad + keyboard because it's a nicely managed device update-wise and "what I can install"-wise, virus-wise. (...) But I recent told him: Just give up
Since he apparently wants a PC, isn't the logical conclusion the opposite? "Just give up. Buy a Windows/Linux laptop, you are too dependent on Apple, there is always something with the Apple solutions."
We made the call to go Apple years and years ago when he was always fighting viruses and virus scanners on Windows. His Macbook was still (hardware-wise) perfectly functional, but does not receive security updates anymore, so he went iPad. Indeed there are more problems than expected. I expected even less IT support from me was needed. Instead he now complains about the lack of control (which I am certainly ok with btw, the complaining I mean.)
The current plan is to put Ubuntu on the Macbook, not sure what to do with the iPad but make it less "primary computer" will be one of the policies to implement indeed. Maybe he will be happy with an external disk and f-spot, and his music nicely sorted into files. Then some generic backup solution to a Synology NAS or something...
Macbooks are great devices, but Linux is a great "fire-and-forget" OS for situations tech-illiterate loved ones. I've done it many times, with much succes and satisfaction (on both ends) without barely any aftercare. All you really need to do is teach them to install those updates and install a major upgrade every few years (or not, Ubuntu will run fine for a decade).
I beg to differ, I tried that approach a few years back with my folks, only to discover on my next visit a few months later that they went down to a local PC store and got Windows re-installed.
They never managed to get it working for their liking, it wasn't able to run the stuff their friends used to talk about or share via CD/DVD/USB sticks, and they did not wanted to bother me with "dumb" questions.
So I rather that they have Windows, go down to the local PC store when something isn't working as it should.
I do the same with acquaintances whom I sometimes sell secondhand gear, I don't want to do any support so they get Windows. For my father it's different, I can do support, plus he really appreciates and is willing to make sacrifices for, the privacy angle.
Of course you need to help them to alternatives, if they are not that tech-illiterate that they have very specific wishes for software.
It's been a while since I experienced people sharing software one discs by the way, it's been a while since I saw discs at all ;)
I can confirm. That is basically what I did for my father-in-law. The laptop is quite ancient by now (more than 10 years old) but still good enough for running current version of Ubuntu.
> Linux is a great "fire-and-forget" OS for situations tech-illiterate loved ones.
Only if the device is truly 'forgotten'. As in, it is an appliance that's going to do that task forever and ever. Be it web browsing or what have you.
If requirements change, it becomes a problem. If they have to do work on them and interact with companies, you may need either Windows or Linux. Thankfully online Office365 removed a big use-case. But there are others. It is very likely that whatever package you need will be available on Windows or OSX.
Linux is the opposite of fire-and-forget. Eventually a papercut always turns up that will require the terminal.
macOS also has (well, had) extreme UI stability. You could transport someone from 2003 used to Mac OS X 10.0 two decades into the future and they would be able to use macOS Ventura (and all previous versions) purely by muscle memory. Good luck doing that with Windows and Linux with their constant UI churn.
Interestingly enough, by iOS-ifying macOS, they've made it much easier to shift someone using an iPhone from Windows to macOS, because they already recognize many of the UI and UX paradigms.
Linux is not fire and forget for people who use technology without really understanding it, but for people who don't use technology and just need to check their mails and connect to government website to pay their taxes, it is the best.
Once it's configured for these kind of people, it's really fire and forget, and it was already that in 2016.
This. A competent admin and a clueless user is a perfect match for Linux. Either clueless admin or "competent" user however... not so much.
> Linux is the opposite of fire-and-forget. Eventually a papercut always turns up that will require the terminal.
When I say it's been fire-and-forget, I mean that for at least two decades.
If papercuts turn up, you are running the wrong distro or secretly a power user that naturally causes problems for themselves every now and then. This won't happen with normal users on a long term stable distro.
My daughter has Kinoite set up for her boyfriend's grandparents. It's immutable, so there's not much damage they can do without admin access, and she made it look much like Windows. They were already doing everything with Firefox as it was, so it wasn't a huge transition for them.
She did go back to fix things because the grandma managed to delete the printer, and she said that the downloads folder was full of exe files with sketchy names.
I'm with you on the macOS stability in the past. The thing that gets me is that Windows somehow gets a pass in this regard, but there have been some pretty big changes over the years.
When did you last evaluate a system like Ubuntu? I'd have agreed with you 10, perhaps 5 years ago. But things have changed.
Yes, they are always changing, I know Linux since 1996, use it as part of my work, last time I used a system like Ubuntu was last year, where it failed to work with a GIGABYTE BRIX Mini-PC UEFI firmware when starting from internal SSD, which I eventually gave up after several weeks trying various workarounds.
That's the point.
Have you considered open core legacy? I am running macOS Sonoma nearly perfectly on a 2010 iMac.
Viruses were a problem and you're suggesting an old unpatched system.
Viruses are not a problem on macos and have never been. Unless we dive into purely theoretical scenarios.
This is why I direct most family to Apple devices. Otherwise it’s constant tech support.
Yes, did the same more than 10 years ago.
My mother wanted a device to just access internet banking. Gave her a netbook (remember those?). Only successful Linux use-case for non techies I've succeeded at.
I gave a normal notebook. The browser is the OS, it might as well run in TempleOS, it doesn't matter except for vulnerabilities in the browser.
This is why I don't do tech support for family. I just say "I work with servers, I don't know anything about [phones|iPads|laptops]." And indeed, I try to keep my own phone and laptop utterly bone stock or "as configured by employer."
Same philosophy as doctors who don't provide medical care for their family.
>Just give up. Buy a Windows/Linux laptop
I can't fathom using Windows voluntarily these days. Even for gaming, Bazzite is janky but it's serviceable, and anything is better than Windows. It's almost shocking how much worse things are than Windows 10, which itself was a major victory in Microsoft's war against its own users.
> Yes, Proton Drive eats 400 GB of your iPad storage now, I don't know how to trim that regularly.
I love Proton services and have been a subscriber for years. I do not understand what is going on with this. I have proton drive on my iPhone, I manually open it monthly to let my photos sync. I pay for the storage on proton drive to _save_ space locally, but whenever I sync to proton drive the storage space used locally by the app is almost equal to a local photo library! Yes I can delete the app, re-install it monthly to sync my library once, but it quickly balloons to dozens of gigabytes when I start to sync my local photos.
Can anyone at proton explain what is going on here?
I haven't used Proton, but based on my experience with other cloud storage products and seeing other people's reports thereon, it looks to me like you are running into the problem that there are two different use cases for them with opposite requirements:
1. Local storage is cheap, I have lots of it. I want multiple copies of my data so that they will serve as backups. I want everything in the cloud to be copied locally. (I'm in this category.)
2. Local storage is cheap if you look at the price of external hard disks, but my phone or tablet only has a limited amount of it, and no way to upgrade without buying a whole new device, so it is scarce for me. I want nothing in the cloud to be copied locally, unless I am specifically using it on this device. (Sounds like you're in this category.)
Half the people think the first use case is the obvious one. Half the people think the second is the obvious one. And that includes developers, who will design the product accordingly without giving it much thought. So either half the users get a nasty surprise in the form of running out of disk space, or the other half risk an even nastier surprise in the form of data loss.
Obviously, computers pester us with too many questions these days, but I think this is one case where the software really does need to ask the user which behavior they want. Perhaps with a hint based on how much local disk space seems to be available.
[flagged]
[flagged]
[flagged]
Apple will also use AI to make it at least as painful and as unexpected as before. It's their business model (I have come to believe).
Edit: But good point of course, but I believe it will remain cat and mouse, no idea how Apple internally sees it, whether they really don't care, or actively break stuff (break your ** face tonight).
I suspect what we might actually see in that regard is something similar to Minecraft (the Java based one): people were regularly modding it because it was Java based and easy to decomp and know where to inject a mod.
So the Minecraft crew would regularly release updates and obfuscate the code again - most updates were to fix issues/add features, but some were purely for obfuscation. So if you wanted your mod to work it meant not playing any other version.
I'm guessing we'll start seeing more regular updates from software makers; will the updates be fixing bugs or adding features - sure - but I'm guessing that quite a few updates will be simply to obfuscate the code and change addresses around so that any mods that worked before, won't in the new version. Sure an LLM could just decomp it again, but I figure most people won't want to spend the tokens/time it takes for the LLM to actually do the work on that new decomp effort. And with the fact that most people have "auto-update" defaulted to on, I'm foreseeing that apps will get auto-updated likely daily in the near future to combat this.
Years ago, someone once told me "I hope you live in interesting times" ... I don't think this is what they had in mind.
This already happens and has been happening for a while, especially in the Apple ecosystem. I can’t even count the number of apps that did something novel, got popular, had that novelty restricted by some update, then got “replaced” by an Apple app/feature as though they never existed.
Reverse engineering is not a magic wand you can wave on everything and expect something good to come out of it. You need to actually know what you are trying to get out of it.
[flagged]
Your comment, ending in "let's go back to the abacus", only makes sense if "let's stop doing reverse engineering" is a message which can be read out from your parent comment. Is it?
No it's "let's do it the oldfashioned way".
No, their argument was not "we should do reverse engineering exclusively by hand". Their argument was that automating reverse engineering to some degree doesn't automatically fix the issue.
Suggesting that there are these things called computers that are now a lot simpler and reliable would be met with derision because it is a valueless comment
The issue is rarely to have some working setup at a given time, IMHO the real fight is to keep it working thought the updates and ecosystem changes.
That was the same issue with jailbreaking, it gave a lot of freedom, while also being a PITA to deal with at every security fix and system change. Many jailbreakers came to parent's conclusion and just "give up".
Gotta say, using SMB with Apple clients is a massive pain in the ass. I imagine a large part of that is just Microsoft cruft, leaving you to deal with limitations designed around Windows. And you don't really have another option after Apple deprecated AFP.
Apple refuse to pay Microsoft the license for their SMB stack and have dropped open source Samba due to license conflicts with GPL, and so have developed their own implementation (SMBX). This is the reason it is so buggy, and there are loads of articles and posts all over the internet about it. Heres one example from the top of google.
https://www.reddit.com/r/MacOS/comments/18sjnwb/state_of_mac...
Sometimes I wish Apple had gone-head-to-head with Samba and forked v4 and kept it GPL-2 - they might have had enough power to force the issue.
It’s the insane having these discussions in 2026 given samba issues have been a thing as long I’ve been using OSX/macOS. Mixed windows/mac network shares have always been a PITA.
I feel the same about Linux clients. I wish there was some focus there.
Time Machine support has been working on TrueNAS Scale, just via one checkbox on a SMB share config, for years. I thought it was just something in a share config that was always there. Now I wonder how did they do it.
It has been working on upstream Samba for years too, and it is just a couple of lines in smb.conf [1]
If Samba is built with mDNS support, that’s all you need, but it typically isn’t, so you also need to advertise the share using avahi-daemon or systemd-resolved on their respective configurations.
[1]: https://www.samba.org/samba/docs/4.9/man-html/vfs_fruit.8.ht...
This never really worked for me. It would start a backup, very slowly send over a tiny amount of preliminary data, and then fail after several hours. I'm hoping the in-kernel support will get this working for me, but who knows...
I think this is in-kernel smb?
Correct. TrueNAS uses Samba, which has supported this for a while. On TrueNAS it also creates a ZFS snapshot after a successful TimeMachine backup which is really nice for the times MacOS decides to corrupt a TimeMachine volume for no apparent reason.
Wait ... the linux kernel has an SMB server?
And basically only used by those allergic to Samba's GPLv3.
Is that the reason? In the past, a kernel webserver called tux (IIRC) was removed because it was just rediculous and the performance gap was considered a solved problem, not worth keeping an in-kernel server around.
I don't think tux was ever included in the mainline kernel. It was closer to a proof-of-concept than a serious http server alternative.
It also supports RDMA (sometimes called "SMB Direct").
Hmmm...this is separate from using SAMBA?
I tried setting up SAMBA by itself (on Debian) for Time Machine, but for it to work it seems to want Avahi running for mDNS; the problem is there is some weird bug or maybe user-related blooper where it collides with itself from time to time, leading to local DNS weirdness
> Still sucks that it has to be reverse-engineered
With AI and stuff like rea.tools does that really matter anymore?
Let's just accept that this is the new norm: Giant companies who had over 20 years to open their shit up, chose to be ass about it and refused, and now we can just take it. Screw them.
It does. It's the difference between "be my guest" and "catch me if you can". Currently we have better luck catching, but there's no promise that it should stay this way.
This really makes me sad. They devoted time and effort to support something as locked and as broken as Apple Time Machine. That thing is a bad choice even within a 100% Apple ecosystem.
Wait so Time Machine works over SMB? Huh
Works might be a stretch. Every time I hear someone complaining about Time Machine it turns out they are trying to do it over SMB.
Apple have dropped support for AFP, so SMB is the only game in town.
What are the alternatives to SMB for time machine?
A locally attached drive.
Is this the recommended way to use time machine then, as opposed to over a network?
> If you have a USB drive or other external storage device, you can use Time Machine to automatically back up your files, including apps, music, photos, email, and documents.
* https://support.apple.com/en-ca/104984
The "3-2-1" strategy is even possible if you rotate drives between locations:
> For extra security and convenience, you can back up to multiple disks. If you work in two locations, you may want to keep backup disks in both places.
* https://support.apple.com/en-ca/guide/mac-help/mh40739/mac
What would an example of "other external storage device" be in this instance?
You’d think a network drive would be included. Apple used to also provide instructions for connecting a network drive but they stopped with macOS 15 or 26. Now a drive that is physically connected to a Mac is the only method of using Time Machine that Apple officially recognizes.
edit: to be clear you can still use a network drive, but how well that works is the big question. It will probably depend on the user and the setup. The Macs in my house backup to a share on a Pi 4. They can still restore files from it just fine.
They recognize NAS, still, though for instructions they refer you to the manufacturer: https://support.apple.com/en-us/102423#nas
Thunderbolt external SSD, would be the only Apple-ish thing. (Formerly of course, FireWire.)
To be absolutely complete, I could mention that at least one SAS HBA PCIe card exists on the market with support for macOS 27, even. Sometimes bundled with other products...
> at least one SAS HBA PCIe card exists on the market with support for macOS 27
Really? I guess now that the Mac Pro is discontinued, products like that are on borrowed time.
You can still have an external Thunderbolt-to-PCIe slots box too.
What would be the benefit of a thunderbolt to PCIe enclosure with an HBA SAS SSD card inside, instead of just a regular external thunderbolt SSD drive? Apart from many thousands of dollars of course.
The point would be to have an enclosure of several/many SAS HDD's that you want to connect. The Thunderbolt to PCIe enclosure holds the PCIe card only, and a separate SAS enclosure holds disks. (The spinning rust type, surely.)
People also connect LTO tape drives using this interface.
Having many SAS drives on the end of a single Thunderbolt connection completely defeats the point though. whats the point of the fast PCIe link and the fast SAS drives when you are bottlenecking them all on a single thunderbolt cable?
I think you're off base regarding the speeds attainable by Thunderbolt (and/or the speeds of hard drives). Feel free to peruse e.g. https://www.sonnettech.com/product/thunderbolt/pcie-card-exp... ; https://docs.broadcom.com/doc/12353459 (on PCIe and SAS bottlenecks).
Besides that, whether a throughput limit defeats the point depends on what the "point" was to begin with, as well as what the alternatives are.
Since macOS 26, it’s SMB only. Time Machine over AFP is no longer supported.
Yep. My household backs up to a Synology NAS via Time Machine: https://kb.synology.com/en-global/DSM/tutorial/How_to_back_u...
For like 15 years.
I’ve been using Time Machine with my synology nas for ~5 years. Works pretty well. I’d say once every 2 months it looses connection but seems to re-connect itself after a few minutes.
It doesn’t have to be reverse engineered. Apple publishes the source of its SMB client licensed as BSD-4 on GitHub.
https://github.com/apple-oss-distributions/SMBClient
I’m not sure where Phoronix/the author got the information that this was reverse-engineered, because the patch doesn’t say that either.
[flagged]
[dead]
> This release is a record-breaker on all fronts; it brought in 18,765 non-merge commits from 3,021 developers, 807 of whom were first-time kernel developers.
I'm reading that as many new AI assisted code patches. Not everyone does an obviously bad job at submitting AI assisted code.
Not a criticism, just an observation.
My first patch is in this release, it was for battery level reporting of a wireless keyboard.
The main AI assistance was in determining why my mouse's battery level was easy to see, but not my keyboard's battery level. Having assistance identifying the information pipeline (kernel -> UPower -> xfce4-power-manager) and then identifying which step was broken was vital for me starting the project. The patch itself was trivial, so no coding assistance was needed.
IMHO this is where AI truly shines; being able to understand a system and its components and analyze them is institutional knowledge that requires a long time for an individual to obtain. AI can do this in a much shorter period and allow contributors otherwise unfamiliar with a codebase to make a meaningful contribution.
Congrat for your patch. Would you mind sharin the merge mail?
Good job :) It sounds daunting enough. Which model of keyboard was that and why were you having trouble with battery levels?
The keyboard is a Logitech G915 TKL. The problem is that when the keyboard was connected via the Logitech Lightspeed adapter the battery levels did not appear in xfce4-power-manager (the taskbar widget). When connected via bluetooth the battery level was visible. The root cause was that the lightspeed usb connector (device id 0xc545), one of many from Logitech, was not associated with the kernel driver needed and defaulted to hid-generic. Keyboard functionality worked, but not the battery level reporting. So my kernel patch was a simple mapping telling the kernel to use the proper, already existing recvr_type_gaming_hidpp_ls_1_3, driver for this previously unknown device id.
So what was actually broken? Just yesterday I set up my wireless keyboard on Ubuntu LTS 26.04 using bluetoothctl and BlueZ seemed to report the battery fine but I didn’t check upower.
The kernel didn't know to use the proper driver for my usb wireless dongle. Adding a few lines of code telling the kernel this usb device id requires this driver was the only change needed.
Nice, congrats on the first patch. Was the keyboard missing from UPower entirely, or was it showing up there and the xfce side just wasn't reading it?
The keyboard, a G915 TKL connected via Lightspeed, was missing from UPower.
You can see the curreny Linux AI policy here:
https://docs.kernel.org/process/coding-assistants.html
Broadly it says: you can use AI as much as you like. You have to disclose use of AI. You, as a person, not the AI, are responsible for the quality of Linux kernel submissions.
> You, as a person, not the AI, are responsible for the quality
As someone who doesn't know much about linux kernel work: what does being responsible for the submission look like in practice? Are you expected to find fixes if your change causes unanticipated issues?
I think what it means is "we will judge you based on the code you submit, we don't care if it comes from an AI". Also probably "we will judge you if you obviously don't understand the code you submit".
At least that's how I do it. When someone offers a patch to an open source project, I don't really care if that person has a PhD, or if that person does this in their free time, or if that patch is actually the result of a whole team working together. I judge the patch based on the value it brings to me as a maintainer.
Obviously the code has to be good, but also the interaction with whoever offers the patch has to be smooth: if I have a question, if I need them to confirm/change/test/elaborate on something, I need that to work.
If I feel like I would be faster doing the work myself AND this author is not putting effort into it (e.g. they just copy-paste an AI), I will not review that work. Possibly I will distrust that author. If too many contributions end up wasting my time, I will start limiting the contributions to people I know/trust, etc.
In terms of maintenance, I don't see a difference between getting a contribution from a stranger or from a stranger using an AI.
In terms of philosophy, that's obviously different: One may not want to accept contributions from people using AI because they think that AI is bad for society, for instance. And I would totally understand that. But if the stance (and it seems to be Linus' stance) is that a patch is only judged based on its technical merit, then I don't see why AI-in-the-loop would be an issue.
This was my take on it as well. Which in many ways makes a lot of sense and is pragmatic.
The thing which I think is going to be a very sore lesson for everyone at some point is that if anyone uses AI it becomes a burden for everyone. Even in projects that reject all AI usage.
What I can do is create 50 personas that all contribute patches. 40 of them get called out and are distrusted, but 10 make it through. I can give more focus on those 10 to ensure their trust level increases. Then slowly have them all come together to shepard some subsystem where I'm going to be the only real person involved and can sign off on my own work in a that looks like I have oversight from the outside.
In the past this was possible but took a very high cost. You need a bunch of competent software engineers who you can trust not to blab their secret mission. Today anyone can give it a try.
I don't disagree, and AI helps scaling many things: good work, bad work, malware.
However, I remember that a couple of university researchers (PhD candidates maybe?) thought it would be a good idea to introduce security issues in Linux, and managed to do it. Without AI and without a lot of resources.
A consequence of that was that Linux immediately reverted all the patches coming from that university, saying "we don't know if we can trust you guys" (but really I guess as a way to tell universities "if you fuck with us we ban you, now keep your people in line").
And that's what I was thinking about when I said that if too many contributors misbehave, as a maintainer I will just stop accepting contributions from people I don't know. And maybe that will happen. Maybe it will be harder and harder to just be accepted into the club of the people who can send a contribution and have it reviewed at all.
> In terms of maintenance, I don't see a difference between getting a contribution from a stranger or from a stranger using an AI.
Perhaps not in terms of maintenance. In terms of provenance there is a significant difference between "I wrote this." and "I found this."
I meant as a maintainer. As a maintainer, I receive patches from contributors, I decide if I merge them or not (and under which conditions), and then I take ownership of the merged patch (as in, if it breaks I am responsible for getting it fixed).
Which means that "as a maintainer", I don't write anything. I merge code that falls from the sky. Whether it was an AI cloud or a manual-coding cloud, I don't know: from where I stand, it falls from the sky.
> there is a significant difference between "I wrote this." and "I found this."
Of course. When I write code ("I wrote this"), then it does not fall from the sky: I wrote it. I know, it's me :-). But in the open source world, being a maintainer means that you deal with code that falls from the sky. Unless you decide to close your project to contributions and only accept people you trust.
I've never been involved with Linux kernel work, but in terms of the "You, as a person, not the AI, are responsible for the quality" policy, this to me is a just an "obvious" policy that should be applied to any non-vibe-coded software.
It's just another way of saying, you can't have AI submit things on its own and you can't "blame" AI for anything you submit, you're expected to understand and be able to explain anything you're putting forward, if there is an issue with your submission, doesn't matter at all if you go back to AI to address it, so long as all issues are properly addressed.
The code is either of sufficient quality, or it's not, doesn't matter whether you or AI wrote it, it's your name on it, you're responsible for it and its your reputation on the line.
> should be applied to any non-vibe-coded software
Should be applied to anything someone is releasing without big disclosures.
At least until a few months from now when it will be clear that human code is the weak point.
I agree, I was writing something along those lines but with more words (which is not a good thing) :-).
The problem with this policy is that it works well when dealing with individuals, but you can still be swamped by "first-time sloppers" - sure, each one cannot ever submit again because it's low-quality slop, but the damage is done.
(And in reality EVERYONE's AI policy is a variation of this no matter how strict they get, because very few people will suddenly rip all of tridge's code out of Samba if he admits he used AI once, and nobody can withstand slopspam for long.)
Being responsible for the quality of the submission means that when other kernel developers say, "hey this part sucks, please fix it," you are obligated to fix it or defend your position, if you want the patch to be accepted into the kernel.
That last part is worth highlighting: you always have the option to not follow-up and abandon your proposed change, in which case it won't make it into the kernel. (Unless someone else picks it up and volunteers to get it into shape for that is acceptable for merging into the kernel, but that is vanishingly rare, unless the change is trivial.)
You aren't expected to hang around and maintain your patch once merged, that's what subsystem maintainers are for. But you would be making their lives a lot easier and earn a lot of respect if you did.
Basically, you can't just post slop and then say, "Oh, sorry, the AI did that." If the comments are too wordy, or the patch is unnecessary or poorly written or contains errors or doesn't follow the style guide, you submitted it, so that's on you. If you get in the habit of posting bad patches, people may start ignoring you.
Don't forget having Linus Torvalds ridicule you in front of the entire world. That alone is reason to be vigilant that your code submitted isn't hot garbage.
The docs have not been properly updated to reflect the changes. Linux developers voted to stop requiring "Assisted-by" attribution.
Surprised by that. I expected more openness.
How long until we get "all FOSS code is made by AI and so it's not copyrighted" arguments when using code in unlicensed ways?
It also hides what would be a great signal on which ML models to use to get the best quality code. Like, wouldn't the community like to know which models made the code with the least bugs?
> Surprised by that. I expected more openness.
You should read reasoning behind the decision.
https://www.theregister.com/ai-and-ml/2026/10/14/linux-kerne...
Its a pointless tag. You can say a tag is required if you use AI, but the linux maintainers know some people are still just going to lie. And they know having this rule will lead to the occasional witch huntwhen someone tries to sus out code that seems AI written but does not have the tag.
They dont think the juice is worth the squeeze. LLMs are just another tool.
Except writing patches to an existing project creates a derivative work, and the original copyright still applies to the project, even though your individual changes are owned by you.
(This is why fan made videos using copyrighted characters can be taken down.)
The documentation update has been applied, you'll see it in linux-next; it should move to the mainline in the next few days.
Nowadays it's more correct to require commit be signed by AI - with Assisted-by: Human row...
Voted to be removed attribution in the last meeting [0], but the patch thread is a bit controversial and ongoing at the moment. [1]
[0] https://lwn.net/Articles/1099594/ (user required).
[1] https://lore.kernel.org/lkml/20261009083137.3-1-sashal@kerne...
That sounds reasonable. I would even go one step further and drop requirements to disclose AI use. I think the person submitting the work should be fully responsible for what they submit and is more than enough. If you have a karma system for contributors, you get a pretty good idea of who does a good job.p
I hear you, but I don't think is a good idea to say that someone who used AI for a patch, did not understand the changes. We can't conflate the two.
If you spent 20 seconds to generate a patch and just hurled over the fence to be reviewed is no worse than spending 3 hours to manually write a fix that fixes 1 thing and break 2 others.
100% of AI use should have to be disclosed in all cases, not just software. A person using an AI is foregoing responsibility from the get go by using an AI to do things that they can't personally do. What would it even mean for them to be responsible if they submit a patch to a project written by an AI as their own work? Such a person submitting a patch they don't understand that is rejected is in exactly the same place as if they had never submitted a patch. They have nothing to lose.
In their last meeting they've agreed to give up on the disclosing part.
Basically, they expect everyone to always use AI all the time anyway.
Or they don't care whether the code was produced with vim, VScode with an autocomplete tool or AI; they will judge the code based on the quality of the code and the quality of the interaction with whoever submits it?
Nothing says you have to use AI. Just like nothing says you have to use a computer. You could have someone print the code for you, write your patch with a pencil on paper, get a pigeon to send your patch to someone who can then submit it, and it would be judge in the same manner. Granted, it's probably more efficient to use a computer.
> Nothing says you have to use AI.
Except your employer, usually.
Well if my employer was willing to pay me to contribute to open source projects like Linux, under the condition that I used AI, I would gladly do it :-).
I think there's very few if any unpaid contributors to the linux kernel these days.
I didn't get paid for my recent contributions. And I suspect many of these 800 first time contributors that are mentioned also didn't get paid.
You are right, that many of the more serious, less casual contributors are probably paid.
I review patches and don't get paid :)
I'm sure of that. Still my employer doesn't pay me to do that.
> You have to disclose use of AI.
This is no longer true.
Linux maintainers: Yes, make them publicly admit their disgrace!
*Linus does it*
Linux maintainers: Goddammit!
On the one hand it is concerning, on the other hand… I was getting quite worried the iPad generation was going to be incapable of developing operating systems. If AI is now capable of maintaining it, that will save us from collapse.
As long as "the iPad generation" can write and maintain ML tools? Because otherwise all software gets locked behind the tools which as they grow more complex will require more access to more resources to produce.
Doesn't this just end up with the tech billionaires being the only ones who can make software. Will they decide to allow their models to maintain/create FOSS? Seems unlikely.
People said the same about requiring a compiler to compile a compiler.
It worked out.
[dead]
[dead]
I'm excited because of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin..., which is the first kernel driver to use the new Wi-Fi HaLow (s1g/900MHz Wi-Fi) support.
(Disclosure: I work for Morse)
Oh this is incredible.. HaLow has been one of my favorite new wireless tech implementations, and I feel almost like a preacher with how much I have been pushing the gospel to the people around me for the last ~2 years. being introduced into the kernel should really help integration and usage. I am just hoping chips start being produced by more than one (?) company eventually for more market capture. Any thoughts on that front?
I'm not the expert in this area, but the current state of play AFAIK in terms of working chips is:
- Morse Micro - Newracom - Taixin are mostly not compliant (but cheap) - Amazon have a proprietary not quite compatible HaLow in their Blink cameras
There's varying levels of interest in WFA compliance/interop. Morse and Newracom are the most interoperable, but even then there are gotchas.
The Morse ones, are, of course, the best ;)
Aside from upstreaming, one of the other things we're chasing is a better regulatory environment. In particular, the EU S1G bands are very tightly constrained.
Can you elaborate a bit on the use cases of HaLow?
It's low-energy like Bluetooth/Zwave/Zigbee, long range like any other 900Mhz Band protocol (LoRA does 10km or so in normal conditions, can go even further), but for when you need higher datarates. According to the Wikipedia chart it can max out at ~300 Mbps depending on modulation, though I don't know enough to speak to range/bandwidth tradeoffs, though I imagine there are.
Honestly seems pretty interesting. I had a lot of fun setting up a 4G carrier for my home so I can get decent speeds out on my back porch (5GHz can't cut through my ancient balloon frame walls/door, and 2.4GHz is a congested soup around me, useless), I wonder if I can wrangle some hardware together and start experimenting with this. Could be nice to get some remote SDR workloads off of 2.4GHz while still getting WPA3 encryption.
Kinda sad that there are so many thousands of lines of code here, yet at its core this is much the same as any other WiFi device.
Surely some code reuse would have been possible? Especially when the same team who write the driver are also making the firmware
The code is right there. You can go look and see if your guess is right.
You can tell that I'm skeptical. Kernel code tends to be pretty tight.
Now we just need hostapd and wpa_supplicant support? (Minus the things missing from the driver.)
Yes, we're trying to upstream this (and iw support) currently. This was blocked on having S1G and a driver in the kernel.
I've never seen a tag block that long.
>ARM
> Device Tree Updates
> Apple platform gains support for M3 Pro, Max and Ultra SoC
Incredible how fast support for Apple silicon is progressing.
The Omarchy M team is doing great work with this. They are currently working on the M6 bring-up already!
https://x.com/JoshuaSWarren/status/2111923039378211100?s=20
I personally looked into their code an patches. This is an absolute mess of workarounds, permissioning negligence and other types of antipatterns.
They are truly and utterly a definition of a slop. And, expectedly, their work is unstable and not efficient, just look into Reddit discussion complaining about power draining.
I am afraid no one, or very few, has any deep understanding of low level architecture of these platforms or even Linux kernel and hardware in general, looking at their contributors’ previous front end NodeJS projects.
The only good thing is you can take their otherwise time-consuming work, have an agent infer and write a spec and use that to implement proper improvements in an, ironically, truly clean-room fashion.
[flagged]
> If you took the time to really analyze their codebase and judge, why don't you submit some PRs to help them improve?
You think it's the same amount of time for both?
> It makes no sense to put them down on HN
Put them down? How, by sharing what I saw in their codebase, which anyone else can also do?
That's some apologist nonsense here and you sound super biased with those suggestions. I made and effort to assess the technicality of what I saw and I would absolutely stay away from what they do.
> Critical Bugs get caught quick too.
This is not just about kernel oops kind of bugs with a nice trace that LLM will fix in 5 minuyes. It's the race conditions, the lockups, all type of architectural, high-level things that their code does that create non-deterministic bugs, i.e. untraceable and virtually unfixable by LLMs nor a human being.
The fact this needs explaining even...
As someone who hasn't looked at the repositories in question;
> why don't you submit some PRs to help them improve?
Is often a non-starter. If you believe a codebase is poor quality, any changes to improve it have a strong risk of making it worse and/or wasting your own time. In the case that you aren't a key player in said codebase already, it is even more likely your attempts to make changes will fail. Its not impossible to improve these repositories however doing so is quite a different skill-set to identifying their failings.
> I coudln't care less about what's going on under the hood.
This is why there will likely be fragmented efforts for bringing up the hardware. Asahi already struggled merging all of their patches into the kernel, there's a 99%+ chance that Omarchy's patches will never be fully upstreamed if the reverse engineered devicetree is uninterpretable vibeslop.
So, even though Asahi's the slow-and-steady side, it makes a lot more sense to channel your effort there.
> will never be fully upstreamed if the reverse engineered devicetree is uninterpretable vibeslop.
The device tree is the least of a problem, it's a very limited, highly structured language, you don't need super deep understanding of things to get it right.
Problem is the drivers they write. The hacks, the workarounds, the utter mess. There's hundreds of commits that I am certain no one keeps track of and understands their true purpose.
Why take the time to help them improve when they havent even taken the time to write it?
I wouldn't call it fast, these are several years old and no GPU, Thunderbolt, etc. support still. It's steady, but not fast.
If I was to do it myself, it would take centuries. I guess it's a matter of perspective :-).
And if Apple did it themselves, like Intel or AMD do, it would be released at the same time as macOS.
Intel and AMD sell to customers that build computers running Linux, especially servers. Apple sells to itself, to build computers that run their own OS.
No one said otherwise. We’re discussing the speed of onboarding here. Intel is fast, Apple support via Asahi can do what they can do, but it must be and is slow without any documentation whatsoever.
We agree on that, it is inevitable.
Furthermore we are lucky that Apple at least tolerates Asahi and does not throw at them more technical hurdles, legal issues (DMCA?) or whatever. Based on past history (in the 90s, so a lot of management changes) Apple would shut them down if they were a threat to their bottom line. I remember the shortly allowed Mac clones so, a possible scenario: a significant fraction of sold Macs is immediately reinstalled with Linux and provide zero dollars to cloud services and followup sales of other hardware. Apple is not going to like that.
Sure. But is that a reason to complain? If Apple made bikes, they may be nice bikes. But I don't see a reason to complain about Apple not making bikes. I mean... they don't have to, do they?
Would be cool if Apple decided to support Linux, of course. But why would they? If it was profitable for them, they would do it. Instead they think it's more profitable to enshittify their products. That's life.
Now people who reverse engineer that to help us run Linux on Apple hardware... I would guess they don't make a fortune doing that, and I find it impressive work.
> I don't see a reason to complain about Apple not making bikes. I mean... they don't have to, do they?
This analogy is really tortured. Apple doesn't make bikes.
But they do make software, and hardware. People want to use them however they choose.
This is more like a bike company choosing a proprietary air valve that only lets you inflate your bike tires with their own company-branded air pump, even though there's been other air pumps for many decades before them, and their design isn't particularly better than the others. And you say "well they don't have to design an air valve adapter to use other air pumps" and -- yeah, that's true. But people are gonna bitch.
> and -- yeah, that's true.
So we agree :-). Of course I would like it if Apple was making my life better. I just find it naive to consider that companies are anything other than profit-maximizing machines. If they happen to do something you like, it's because it is profitable for them. They couldn't care less about you.
> But people are gonna bitch.
Whatever you do, people are gonna bitch. Again it would be a bit naive to think that if you do "your best", or if you do "what's right", or if you "genuinely try", then everybody will appreciate. There will always be enough people bitching, of that I am certain.
> Whatever you do, people are gonna bitch.
So we agree :-)
Some people like Apple hardware, but not Apple software. I wouldn't be surprised to find out, that some of them might even work in the Apple. Not everything must be about immediate consumer profit. Developer goodwill also worth something. Remember Steve Ballmer? Developers, developers, developers, developers...
It's perfectly reasonable to complain about things you aren't entitled to. My Surface brand laptop has similarly ad-hoc Linux driver support. I don't expect Microsoft to support it better, but I'm still annoyed they don't.
I guess I don't like that people complain against the Asahi team because Apple would be faster.
Sure, Apple (like all other BigTech) suck. But the Asahi project is quite amazing. I don't see a reason to complain about the Asahi project.
I have this dream that previous gen M chips will be worth more than current gen M chips b/c people want to run local inference on Apple silicon... but they want to use Linux and not OS X.
I'm curious on why you think that, say, an M2 running linux will ever be a better choice for AI workloads than an M5 Pro running MacOS? What is it that you think is in the hardware that you'd be able to unlock with linux but isn't exposed by MacOS?
I'm sure a lot has changed since cough 2004, but that was the state with the PowerPC G4 and G5. Machine learning Linux applications used the IBM Power architecture because of their vectorization features, and that hardware was ridiculously expensive. When Apple started using Motorola and IBM's cheaper PowerPC chips with Altivec this small market was pumped, but none of their groovy scientific applications worked on OSX.
This created a large enough market for Linux distros installed on Apple hardware to make it a sustainable business model the makers of Yellow Dog Linux to buy the hardware through a reseller channel, ship it to the building, install Linux on it, then ship the device to customers. I worked there and it was fun.
Lots has changed since then of course, one of which being that Apple controls the chip from top to bottom, and their near-indifference in 2004 now seems to have transformed into something more adversarial.
> I'm curious on why you think that, say, an M2 running linux will ever be a better choice for AI workloads than an M5 Pro running MacOS?
I mean that if Asahi starts to gain on Apple with respect to generation of M chip they support. If Asahi supported M4 chips...
But clearly, my dream hasn't come true yet :-)
> What is it that you think is in the hardware that you'd be able to unlock with linux but isn't exposed by MacOS?
I believe that Linux would give me more control over exactly what is running on the machine (and using up precioius memory). Maybe it would also have better support for the toolchain/ecosystem needed to run local inference?
Just because you have a device tree file, doesn't mean its correct, or even accurate.
On the other hand - I just had to send my Asus vivobook s15 to repair, because Linux (most likely) fried the wifi chip.
Pretty disappointed in Qualcomm's promise of upstream support for Snapdragon X Elite turning out to be: lol, not actually so you can run Linux on devices, only so you can maybe boot without most devices working...
Hope things will keep improving despite lack of help from vendors.
The radio limits are very heavily guarded by the firmware solely because its regulatory compliance: different jurisdictions have different limits and you can’t just let userspace or kernel change it at will. Heck, most manufacturers don’t let you change WiFi card anymore or allow only a whitelisted WWAN card for same reason.
So, I would be super interested how you inferred it was Linux’ fault but I sssume b/s at this point.
Well, I'd say it's Asus fault for having crappy firmware - but Linux triggers it - causing the card to permanently no longer come up on boot.
"Fried" was a poor choice of words - the device is dead - but it's due to firmware and probably something to do with sleep states.
I didn't mean to imply the radio was actually fried.
It'll be interesting to see what the technicians end up doing to get it working. It might be enough to disconnect the card and force some even deeper reset than a power cycle with drained laptop battery does - but as I still have valid guarantee on the machine, I stopped short of opening it up. Especially since I might need a new wifi card anyway.
If I were to wild-guess here, it sounds like and rfkill in nvram that isn't properly handled by the Asus EC driver for your laptop model. This is a fairly common issue for Windows-first laptops and Asus EC drivers are reverse engineered because they don't support Linux themselves. I assume switching to Windows was not bringing it back anymore?
Chance is you could probably have Claude or Codex had look into it and have them fix it for you.
I had ai look into it, and that took it from works in windows, shows up in Linux - to dead and gone from both os'.
Ed: user AI on the Linux side, to help with getting firmware blobs etc - might be random combination of flaky firmware, flaky Linux support and reboots that did it - not AI or any particular driver/firmware version.
It's the first time I've seen drivers knock out a hw component completely on a consumer product - but I gather the platform is fickle.
The arm64 Snapdragon elite support is very poor unfortunately (due to there being zero upstream support).
Which wouldn't be so bad if they weren't marketed with a promise of Linux support.
Well, thanks for the write up. Will be interesting to hear what they fixed, but chances are they'll just replace the board and not think twice about it.
i want to know weather the windows will detect it just driver issue are real fried
Not one of the downvoters. How would the kernel fry the Wi-Fi chip?
It's not the radio actually frying the chip - poor choice of words on my part.
It's the firmware that locks up - with Bluetooth and wifi devices not working at all anymore (does not show up in Linux or Windows device manager). And even a complete power drain and reboot can't resurrect them.
Number of CVEs fixed at an all-time high:
https://pages.skybrian.com/2026/kernel-cve-fixes/
I want to see the same graph but for number of CVEs introduced. ie, when we find a CVE, find out which kernel version introduced it. This would only be useful for kernel versions that were a few years old, so we'd have had time to find most of the CVEs. But it'd still be interesting.
There's a graph for bugs and bug-fixes (not CVEs, but in linux close) near the end of this article that looks approximately like what you are interested in: https://lwn.net/Articles/1088776/
That's awesome. Now what I want is an animated version that shows how the bugs lines change over time.
Number of CVEs added must be at an all-time high as well.
> This release is a record-breaker on all fronts; it brought in 18,765 non-merge commits from 3,021 developers, 807 of whom were first-time kernel developers.
hopefully without kernel-slops :P good job everyone btw!
BTW, here we are: LOC metric everyone made fun of has suddenly became commit count metric.
Features? Bugfixes? What? Look how many commits we've got!
1. They weren't counting LOC though, but commits. It's a totally different metric.
2. This type of stat was always being shared with each new release, giving a general indication of the size of changes. They did not started posting it all of a sudden due to AI.
> 1. They weren't counting LOC though, but commits. It's a totally different metric.
Is this satire? :D
I think in Linux world commits usually mean something which isn’t always the case at random company X. A commit being a meaningful change where number of lines doesn’t matter.
A commit can delete or modify lines, it at least isn't as bad as the "more code = better" approach, though perhaps it's still flawed in that you could have lots of very minor commits to increase the count, or do and then undo a change to get 2 free commits.
It felt to me like it's more of a neat fact rather than a measure of quality.
Is Linus still checking every commit?
That‘s what subsystem maintainers are for.
That's a big ask for those maintainers who are volunteers
Do people still think that Linux is being developed by unpaid hackers in a garage?
Most, if not all, are employed by different companies or Kernel.org.
Linux is big business.
It's a big ask to expect people to do the thing they volunteered to do and can step back from doing any time they want?
Unless we think he's some kind of software god, it doesn't really matter if he does or doesn't. The real question is how many other people are?
Only if he finds something odd in the pull request summary.
Linus thinks AI is no different from a compiler, so it's likely that none of these commits are being reviewed. After all, how often do you doubt your compiler's output?
[dead]
[flagged]
It might be written by the LLM, but I'm pretty sure Linus hasn't vibe coded it. Do you think he won't look at the output and nitpick to death?
There was a recent proof that he did
https://lwn.net/Articles/1100449/
During peer review a race condition was found in his code. Would he have spotted it himself when writing the code manually? Maybe, maybe not. He's only human, and the AI is only AI.
I wonder if humans would have spotted this one if no one knew a LLM wrote it. Obviously it's nearly impossible to test that though.
It's not necessarily a human who found this one. Coding assistants are so widespread that people don't bother mentioning them.
Such LLM defensive positions seems fun to me for some reason.
[flagged]
[dead]
I think this is yet another case where Linus is leading the pack and showing the industry how to adapt to new technology, and indeed, adopt standard best practices for its application.
I'm in the "AI is great!" optimist camp myself, which is how I felt in the very early days of "this little crappy hobbyist Linux kernel thing that'll never go anywhere important" minix-list flamewars.
Once again, Linus demonstrating that those who understand the code, own the code.
"Showing the industry how to adapt to new technology", as in, don't blindly trust whatever the big probability box committed to your repo but actually perform a good code review with the same standards as human-written code?
I think this says way more about the industry being completely out of touch and less about Linus leading the pack.
Yes, usually when the flock is lost in the wilderness, its leaders need to raise their heads and lead the way. Linus is applying the same great engineering methods he's always had.
Please stop with the "AI assisted development" = "Vibe coding slop" narrative. It comes across as pretty dumb (sorry, I mean "uninformed") nowadays. Please experiment with LLMs, find your way (or don't, but), learn to talk about it in an informed way and don't post obviously inflammatory one liners that are essentially just "AI is bad m'kay".
There are intelligent arguments against using AI, your comment is not referring to any of them.
In short: Linus feels responsible for the quality of the Kernel, he expects the same of other devs. He does not care about the tools used to generate the code. He (or some other human) will call out submitted slop, whether LLM generated or human generated.
It's increasingly the other way around, actually. You are being sloppy if you don't use the tools available to you. Including AI, static code analysis, testing tools, etc. to check if your work is any good. That doesn't mean you have to surrender to the AI tools and blindly generate everything and then commit without testing or any form of validation. That would be sloppy. But then if you manually write your code and did that, that would be sloppy too. Whether you manually type in all your code or have it generated is immaterial. What matters is the work you do to ensure it all works as advertised and is fit to be merged.
The kernel developers are probably a bit further in their thinking then some developers. They've been dealing with many thousands of contributors for decades. Git was invented by Linus Torvalds specifically to deal with ensuring only the best patches make it into the kernel.
Somebody posted a video with Greg Kroah-Hartman last week or so commenting on how he's been dealing with all the AI generated security bug reports. His key point is that AI generated reports are meaningless unless they come with a suggested fix as well. If you are going to generate the report, you might as well generate the fix. And it's a lot easier for him to review if the fix fixes anything worth fixing then to piece together a fix from a lengthy report. The larger the report, the less likely it is to get any attention. If the person contributing can't articulate why the fix is needed or how it works, they just reject the change and toss it back. That strikes me as very pragmatic. Judge a change on its merits. Not on how it was created. A report without a suggested fix is relatively meaningless.
There’s such a breadth of slop quality. Like I’ve seen people using ChatGPT with thinking disabled, which is just garbage. But you can also use an LLM to do automated testing of your product, in a real browser window, where it actually sees how it looks via screenshots. That’s insanely useful.
And it can read all of the logs in the backend and browser simultaneously and understand what is causing issues. I’ve used that a few times and it is such a game changer for weird bugs.
100%. I think there are a lot of people here on HN that are very threatened by LLMs, rightly so. I'm also afraid of my future and my day-to-day work has already changed from "loosing myself in a flow state solving technical puzzles" to "micro-managing LLMs". I don't like it, but hope I will learn to, at some point, or perhaps I find different work. I feel like I don't have a choice right now but to adapt and learn.
The answer to this issue is not to equate any code generated by LLMs to slop. It is just not true. As you say, the latest models often flag things that I would definitely miss, or they simplify my code significantly with a just-released feature. I see benefits to code quality all day from using LLMs.
I'm just saying (not to you but to comments below): Lets keep it constructive, which means: lets keep it real, as in close to truth. Yes vibe coding exists, and it has it's place (ie in prototyping?). But not in the kernel, and also not in my own line of works. LLMs do have a place there though.
no.
slop is slop.
Hard to argue against X = X. Just curious, are you are including human slop in your statement?
The rate at which AI introduces bugs is higher than human ones about 2x more bugs than humans.
Human slop is equally as bad, but this is not what Linus chose in this case, he chose to accept the higher risk of almost 2x as much more bugs using LLMs which lead to the introduction of LLM slop.
I don't care if it is Linus or anyone else, slop is slop human or not, with LLMs it is far worse.
If the human is doing a proper workflow for the AI, I'm not so sure it's big central. Yes, AI needs to be guided strongly, and if it's not, it makes very poor choices/decisions routinely, but that's why you keep an engineer controlling the process.
I force all work to be split up into chunks, properly investigated, spiked, and planned out, and then implemented via TDD (with only system-boundary mocking permitted). It's not perfect, but I've seen regression bugs very much cut so far.
Beyond that, if it's a GUI app, I also require the TDD cycle to require GUI tests with screenshot evidence, and proper assert statements.
This is the kind of argument Linus was attacking. His tone against the anti-ai commitment in Linux now makes sense.
It sounds like you've defined "slop" as "anything an LLM produces". Seems unlikely you're going to get much agreement here.
Why yes, it is "slop" and Linus introduced a bug based on what the LLM produced.
He didn't even review the code. [0] Someone else did.
[0] https://lwn.net/ml/all/as6vBoWQGglxXxb0@thinkstation/
This is what happens when you use LLMs and this is far more irresponsible of Linus because he is vibe coding C code in the kernel.
Making LLM write code is super susceptible to generating problems imo.
You know it won't be properly reviewed and understood.
Using LLMs to review code is much more useful imo but it can also cause problems due to the natural lazyness of a person.
You wouldn't want the OS you are using to be developed by a dilligent but a low IQ and mediocre skill level programmer.
I'm not saying other people can't possibly use LLMs to generate code effectively but it seems super suspicious from my experience as it triggers laziness and reluctance to put effort into understanding every piece of code.
> You know it won't be properly reviewed and understood
Do you now?
> You wouldn't want the OS you are using to be developed by a dilligent but a low IQ and mediocre skill level programmer.
So you also know that people using LLMs to produce code are diligent but low IQ and mediocre skill?
> it triggers laziness and reluctance to put effort into understanding every piece of code.
Linus has been mostly reviewing code for what... decades? The rest of the contributors have been his LLM in some way. Would you say that he has gotten "reluctant to put effort into understanding every piece of code" he reviews?
I don't think you understood what I wrote.
I think they did, "You know it won't be properly reviewed and understood." This is just a lie, I review and understand LLM generated code daily. So do many others. Maybe you should be more clear?
If I had to guess, I would say that what you meant was that LLMs can be used to produce worse code and worse programmers, and we don't want that.
And then somehow consider that because LLMs can make bad programmers worse, it has to mean that it will make all programmers worse. And therefore Linus Torvalds using LLMs will necessarily make Linux worse.
Something like this?
> You know it won't be properly reviewed and understood.
This reads a bit weird in hindsight but what I meant was it just feels like that to me.
> I'm not saying other people can't possibly use LLMs to generate code effectively but it seems super suspicious from my experience as it triggers laziness and reluctance to put effort into understanding every piece of code.
This part is my personal experience with trying to use LLMs for code review and sometimes to write a bit of code via opencode.
> diligent but low IQ and mediocre skill
This is how I see LLMs.
In my personal experience, it is not worth to make it write code because then reviewing the code becomes more work than actually writing myself and get LLM review + fix and review again myself.
It can be very good at writing code but the instances where it messes up just cost too much for me to disentangle and making it write things I don't understand doesn't work because I can't review.
I can't judge Linus Torvald's ability but this is my perspective so if I had to guess, I would guess that it isn't necessarily efficient for him to generate code with an LLM because he is spending more time reviewing it compared to him writing the code.
Ok, I hadn't understood what you meant.
> In my personal experience, it is not worth to make it write code
Sure, totally fine with that! I am completely okay with people not using LLMs, just like I am completely okay with people using an IDE instead of vim. Do what works for you.
> I would guess that it isn't necessarily efficient for [Linus Torvalds] to generate code with an LLM
It seems like he disagrees: sometimes it makes him more efficient. But in any case, I think it is his choice. I won't judge him for using an LLM, or an IDE, or even if he wanted to develop on Windows. Why should I care? I care about his contributions.
My problem is that many people say "I don't like working with LLMs, so I don't want other to use them". If you don't like working with LLMs, just don't. And let others use the tools they want.
Except if it is philosophical: something like "I believe LLMs are bad for society because X and Y, and I don't want to be related to them". Similar to "I don't want to work with weapons" or "I refuse to open source my code because it could be used to build weapons". Sure, I respect such ideas. I don't respect the "I don't like this tool so I think people who use that tool are unprofessional".
It’d be interesting to see if rust pickup is improving or not.
https://rusted-kernel.com/
though not updated yet, but the script is on GitHub
https://github.com/tb0hdan/rusted-kernel
https://github.com/torvalds/linux/compare/v7.2...v7.3
unfortunately no stats displayed :)
> a long list of SMB server improvements
This is how I learned there's a mainline kernel-mode SMB server!
https://docs.kernel.org/filesystems/smb/ksmbd.html
First time hearing about failfs. Does it have a niche use case or is it just for testing?
Failfs is a pretty cool pseudo-filesystem where every path lookup fails. So if yu place a statically-linked process into failfs with ONLY pre-allocated file-descriptors at process birth, close down unneeded sockets and enforce a default-deny firewall discipline, compromised applications are effectively isolated and unable to access local files or spawn shells during an exploit. An attacker can NOT move adjacently from the exploited process to other parts of the system because to do so they'll need to navigate from root and that would fail since yu set root as failfs and you've got yourself a pure, isolated data-processing pipe that can only interact via the exact file descriptors it was given!!
Unfortunately, yu can't use dynamically-linked apps anyway since failfs would break absolute path resolution loading system libraries.
EDIT:: But I guess yu could put a statically linked app on the socket, wrap it in failfs and gave it proxy requests to a dynamically-linked app process if your app must use something like python.
Sorry man I've been out of the loop with the hip crowd for a good while, but is "yu" now a thing like "thru" once was?
no biggie... I just like how 'yu' looks. It's an aesthetic.
Thanks, at first I thought it was the name of another tool or library ;)
I immediately parsed it as some CLI i don't know about as well
Is it possible to load the dynamic libraries before fork()ing and somehow prevent the path lookup and library loading? This will open up new possibilities for hardened security models.
That's a fun idea but take python (very familiar)... It's very deeply dynamic and even if yu run imports at the top of your code yu still have many large libs with lazy code execution baked deep inside their internal functions so that assumes yu actually know what code paths the application will hit later. More importantly this goes in the opposite direction of Python's lazy imports thingy.. basically you've got a bomb and yu wouldn't wanna do that. Also, imagine the startup time for large apps. I'd just put a statically-linked binary in front and proxy back to the dynamically-linked process if I can't rewrite the main app in something like Go or Rust.
You explicitly stated as such, I just want to emphasize it again: it only breaks dynamically linked libraries, which - from a stability point of view - is an antipattern anyway.
Almost always youre better off producing a bundle which has everything (excluding the runtime) included... Or just use better languages which categorically don't even have this scenario, eg golang, Java, rust, etc pp
idk if it's just me but deliberately using "yu" instead of "you" is annoying and makes me not really take whatever you say seriously
Yeah, it feels "not ND friendly" too. Totally breaks my reading flow.
I am the person addressed when someone says "you", not "yu". Why is that person changing how I'm addressed?
It's also confusing because it feels initially like it's some new Linux command or user, like "su".
ah, first sentence I thought yu was a typo. Second sentence I saw it I thought it might be a linux component of sorts. So it's not just a stylistic choice, it's actually harming my comprehension of what they're writing.
Lil' TAFKAP, the modern version of Saint Exupery.
Is it different from using seccomp with SECCOMP_RET_ERRNO and return code of EOPNOTSUPP for all filesystem syscalls?
How is that different from putting an app in a chroot jail or container?
For sandboxing: https://hackaday.com/2026/08/07/this-filesystem-is-born-to-f...
A process which is chrooted into failfs cannot open new files. It is limited to the set of filesystem file descriptors it already has open (presumably set up before the chroot or inherited into the process from some container runtime).
So basically more fine tuned jail controls.
I'd love if chrooting would become easier. In particular a requirement to have bash or a specific shell is annoying; imo a simple REPL should suffice already there. I wrote one that works years ago, need to look into what is all needed for a chroot (I always used bash for this but I'd also want to change to my own shell eventually).
We wanted capabilities[1]. Instead we get this over-complicated series of system calls with no design consistency that you have to use very carefully, else they can be bypassed (see the list of caveats on the failfs page).
[1] https://en.wikipedia.org/wiki/Capability-based_security
Capability-based security might be the bees knees, but how would one retrofit it into an existing kernel without breaking backwards compatibility?
They’ll do everything but adopt Capsicum. Shame.
[dead]
I'd love to have one that randomly fails, so we could debug e.g. databases and other apps that are supposed to be resilient. I'd call it "havocfs". Doesn't corrupt data, just randomly fails reads/writes/etc. Some software is supposed to handle that gracefully. Would be a great test tool...
Devices rather than filesystems, but .. https://libguestfs.org/nbdkit-error-filter.1.html & https://libguestfs.org/nbdkit-evil-filter.1.html
Such a filesystem could be done with FUSE. Devices can be done by Linux itself: https://docs.kernel.org/admin-guide/device-mapper/dm-flakey....
It looks like it's useful for sandboxing by preventing any possible filesystem movement.
https://docs.kernel.org/next/filesystems/failfs.html
proposed by John Ericsson (Nix core contributor) for the idea of Null namespaces to make namespaces cheaper for when doing finegrained sandboxed builds.
Reading the description, looks like a stricter chroot for purely-network applications, maybe?
It looks like this release will likely unlock the ability to develop relocatable Nix packages on Linux, thanks to some great work by Farid Zakaria and Christian Brauner! I'm hopeful that it also eventually improves the story for mixing Nix and non-Nix software.
Linux has an in-kernel SMB server like Solaris? When the hell did this happen?
~2021: https://news.ycombinator.com/item?id=28355754
Btw, never understood why do we need it in kernel as a part of kernel project.
For performance.
But it could be DKMS module or something other run as separate project? I got software arch point, but it seems very odd having such things in kernel project, no?
If the kernel had a standard ABI, an out-of-tree kernel module would be the way. As it is, DKMS is a pain and so in-tree modules are the easiest where license allows it.
Linus decided it's OK, so it's there. If Linus wouldn't approve it, DKMS would be an alternative. There are plenty of stuff in kernel, which might look weird to be there.
Because Samba is GPLv3
Development statistics for 7.3 dropped: https://news.ycombinator.com/item?id=50155075
Congrats to the kernel team! The pace of releases over the last year has been impressive. Looking forward to testing this on my machines this weekend.
Genuine question(s):
1) why does it matter “my” patch was submitted? I am simply a bystander but can’t help notice a tone of being admitted to a tribe? Am I wrong ? (It’s ok if it’s a tribe just validating my observation is correct or incorrect)
2) is the Linux kernel on its way to obsolescence? Our field of software engineering and how and what it’s applied to is changing at a drastic rate. The os was built for programs to run which were built by programmers. The programmers thought about what the users of their programs needed to get stuff done and use the programs. This paradigm is changing - fast - an in 10 years it’s going to be very diff place where the users simply build programs or their agents etc. thier expectations of the OS and what “services” and interfaces the os exposes is going to change. And at some point the current os architecture is just not relevant. To build an AI first OS it’s prolly easier to build it from the ground up than keep changing Linux. It’s like we can keep trying to slap on jets to the car to make it go faster but it’s prolly just better to build a plane. We still will need to travel just what we use is going to be diff and as such older mechanisms of traveling will just be irrelevant. Why am I wrong ? What am I missing ?
> why does it matter “my” patch was submitted?
If you want your code in the kernel, it has to be accepted. If you don't care, then it doesn't matter at all.
> is the Linux kernel on its way to obsolescence?
Only if computers are, which is unlikely.
> Our field of software engineering and how and what it’s applied to is changing at a drastic rate.
Rate of change is not a useful metric here.
> The os was built for programs to run which were built by programmers.
AI code is still programs written by programmers, it's just some of the programmers are AI.
> The programmers thought about what the users of their programs needed to get stuff done and use the programs.
Yes, this is how you build software useful to the users. This won't change. If you make a program without thinking about how it's used, you haven't made a useful program. There are lots of apps throughout history in this pile, programs that were never fit for use.
> This paradigm is changing - fast
It's not, and it never will. Programs always have to be fit for use, and have to be useful tools for the users.
> - an in 10 years it’s going to be very diff place where the users simply build programs or their agents etc.
This doesn't change anything about Linux or applications, though. 100 years ago you bought meat and veggies grown nearby so your home because we didn't have transportation. Refrigerated trains made it possible to ship food long distances quickly and while cold. However, this did not change the way people ate the food, they still used pots and pans to cook, plates and utensil to eat, etc. Same thing here. Rather than artisanal, hand crafted code we'll use robot-generated code, and it won't matter at all to the user, or how applications need to be fit to the job.
Is anyone already running this seeing /dev/input/events appear as usual? Last rc didn't work for me, events was gone :( same config 7.2.10 was fine
I see /dev/input/event# files as usual. I don't think the kernel ever created events/ subdir by itself. Might be your udev configuration issue.
I didn't touch any of that, only the usual git checkout, gmake oldconfig and such dance.
Can someone explain to me what failfs is relevent for?
Helps prevent chroot escapes - see discussion at https://lwn.net/Articles/1089244/
Does anyone know if there has been any guidance or discussion on when a 7.x release might become a longterm supported release?
The kernel doesn't follow conventional semver practices, meaning that the major number incrementing has no effect beyong the minor number got too large. So there's nothing inherently different in a 7.X release from a 6.X release.
Either way, an LTS appears to be released ~every 6th version, 6.18 is the newest LTS, so after that there's 6.19, 7.0, 7.1, 7.2, 7.3, 7.4 maybe LTS?
kernel.org has a nice FAQ about this topic.
https://www.kernel.org/category/releases.html
I'm surprised the FAQ does not mention it, but the pattern is that the last release of the year is made the LTS version. Notice the release date is always EOY. This is nothing strictly documented but it has been that way for years.
edit: it is on purpose that gkh doesn't make that an official stance, see reason here: https://lore.kernel.org/lkml/Y8JnHyKNTHMjsHSb@kroah.com/
Thank you!
Thank you!
I wonder how many people nowadays see something like this, clicking on it and expecting a "Download and Install" button.
Can you point me to the `.msi` file?
There's WUBI:
https://github.com/hakuna-m/wubiuefi
I'll take an NSIS installer meself :)
You missed this internet classic https://github.com/twitter/the-algorithm/issues/1999
Why would people expect that?
People may have specific hardware issue that's blocking them and a new kernel release fixes the issue. In that situation they see this announcement and they may be technically brave enough to want to install and check it. Currently they have to find and go to something like https://kernel.ubuntu.com/~kernel-ppa/mainline/ , find the right versions, download multiple files and then `sudo dpkg -i linux-*.deb` and then confirm if their issue is fixed.
I'm not saying it's a great idea, but I'm explaining why people may expect to have a smoother path here.
not an apple or anthropic announcement, so hackernews will be tumbleweeds on this.
Linux now is LLM friendly, Hacker News will be all over this.
How big change is this?
A record breaker on all fronts according to post
more rust?
nice
[flagged]
Beware - this was Torvalds' fever dream of suddenly discovering vibe coding and unleashing it on the kernel like a five year old with candy.
Expect catastrophic problems. There is likely a lot of slop in the code now + testers already found race conditions.
Torvalds' behavior in the past few weeks has been alarming.
Which will just put pressure to improve the testing situation, not necessarily change stance on AI written patches. In fact AI is quite good at catching issues and root causing them back to recent changes so they could automate that journey a bit better as well to fill in any gaps not caught at review time.
Remember, you are "not allowed" to criticize Linus about how he uses LLMs on patches he himself doesn't understand in the Linux Kernel, despite screaming at others in doing the exact same thing (with him and Claude introduces a bug in the process).
This is especially with C code which has hundreds of foot-guns and you can just look at how Linus does not care about code quality in something as critical like an OS kernel and then carelessly introduces a race condition.
If that was anyone else and Linus caught it, they would be completely smoked by his wrath in the mailing list.