- 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
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).
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.
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.
> 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!
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.
> 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.
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.
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...
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).
Still sucks that it has to be reverse-engineered
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.
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).
> Device Tree Updates
> Apple platform gains support for M3 Pro, Max and Ultra SoC
Incredible how fast support for Apple silicon is progressing.
hopefully without kernel-slops :P good job everyone btw!
Update accordingly.
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'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.
I think this says way more about the industry being completely out of touch and less about Linus leading the pack.
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.
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.
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.
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.
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).
[1] https://en.wikipedia.org/wiki/Capability-based_security
https://docs.kernel.org/next/filesystems/failfs.html