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.

[flagged]

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...

>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.

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]

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.

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.

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".

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.

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.

It also supports RDMA (sometimes called "SMB Direct").

Apple have dropped support for AFP, so SMB is the only game in town.

What are the alternatives to SMB for time machine?

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.

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.

The keyboard, a G915 TKL connected via Lightspeed, was missing from UPower.

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.

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.

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.

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?

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...

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.

Basically, they expect everyone to always use AI all the time anyway.

Linux maintainers: Yes, make them publicly admit their disgrace!

*Linus does it*

Linux maintainers: Goddammit!

People said the same about requiring a compiler to compile a compiler.

It worked out.

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.

[flagged]

And if Apple did it themselves, like Intel or AMD do, it would be released at the same time as 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?

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.

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.

That's awesome. Now what I want is an animated version that shows how the bugs lines change over time.

> 1. They weren't counting LOC though, but commits. It's a totally different metric.

Is this satire? :D

That's a big ask for those maintainers who are volunteers

There was a recent proof that he did

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.

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.

no.

slop is slop.

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.

no biggie... I just like how 'yu' looks. It's an aesthetic.

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.

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.

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

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....

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?

Thank you!