- 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
> 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.
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.
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.
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).
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.
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
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?
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".
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.
>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 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 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 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.
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.
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.
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.
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.
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.
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...
> 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 an ass 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 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.
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.
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.
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?
> 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'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.
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.
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.
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.
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
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.
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.
> 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 in always the case at random company X. A commit being a meaningful change where number of lines doesn’t matter.
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).
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
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...
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)
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-KSMBD
Still sucks that it has to be reverse-engineered
Wait so Time Machine works over SMB? Huh
Yep. My household backs up to a Synology NAS via Time Machine: https://kb.synology.com/en-global/DSM/tutorial/How_to_back_u...
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
For like 15 years.
Since macOS 26, it’s SMB only. Time Machine over AFP is no longer supported.
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.
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.
I think AI might change that. Reverse engineering has just become a lot simpler and more reliable.
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).
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.
Computers are not a magic wand that will solve all your problems. Let's go back to the abacus!
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
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?
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".
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.
>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 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 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.
When did you last evaluate a system like Ubuntu? I'd have agreed with you 10, perhaps 5 years ago. But things have changed.
That's the point.
> 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.
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.
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.
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...
I feel the same about Linux clients. I wish there was some focus there.
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 ... the linux kernel has an SMB server?
And basically only used by those allergic to Samba's GPLv3.
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.
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.
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...
> 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 an ass 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 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.
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.
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.
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?
Nowadays it's more correct to require commit be signed by AI - with Assisted-by: Human row...
> 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'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.
I agree, I was writing something along those lines but with more words (which is not a good thing) :-).
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.
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.
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.
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
>ARM
> Device Tree Updates
> Apple platform gains support for M3 Pro, Max and Ultra SoC
Incredible how fast support for Apple silicon is progressing.
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.
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.
Just because you have a device tree file, doesn't mean its correct, or even accurate.
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.
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
> 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!
Is Linus still checking every commit?
That‘s what subsystem maintainers are for.
That's a big ask for those maintainers who are volunteers
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?
Do people still think that Linux is being developed by unpaid hackers in a garage?
Only if he finds something odd in the pull request summary.
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 in always the case at random company X. A commit being a meaningful change where number of lines doesn’t matter.
It felt to me like it's more of a neat fact rather than a measure of quality.
Number of CVEs fixed at an all-time high:
https://pages.skybrian.com/2026/kernel-cve-fixes/
It’d be interesting to see if rust pickup is improving or not.
First time hearing about failfs. Does it have a niche use case or is it just for testing?
Reading the description, looks like a stricter chroot for purely-network applications, maybe?
It looks like it's useful for sandboxing by preventing any possible filesystem movement.
https://docs.kernel.org/next/filesystems/failfs.html
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
They’ll do everything but adopt Capsicum. Shame.
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
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
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".
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?
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
I wonder how many people nowadays see something like this, clicking on it and expecting a "Download and Install" button.
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.
Can you point me to the `.msi` file?
I'll take an NSIS installer meself :)
There's WUBI:
https://github.com/hakuna-m/wubiuefi
Why would people expect that?
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.
Because Samba is GPLv3
How big change is this?
A record breaker on all fronts according to post