Howdy folks! It's time once again for our tongue-twister of a meeting. Please join us for our monthly meeting; for open discussion, show and tell, troubleshooting, and Linux install help instruction. This is also LibreLocal month so we may have a video conference as well.

I have a Truenas Scale server set up on my LAN serving an SMB share. My desktop is running Debian trixie all up to date. There is a 2.5G ethernet link between them (10g on the NAS, limited by 2.5G on the desktop).

Debian is set up to automount the share via CIFS on boot time into a folder in /media.

When writing large groups of media files to the NAS, performance from Linux is very slow. It sends data only intermittently. When monitoring network traffic, you can see where the Debian file transfer window will show progress while network traffic is paused; then the file transfer window will stop moving when network traffic increases. It does this for the entire contents of a single file (e.g, 1.5gb at a time for the media I was moving). It almost acts like it is filling an internal cache with the file then writing that cache out before streaming the next file... Now, this is a Debian only problem. When I reboot into my Windows 11 install, this problem disappears- transfers run at full line speed as expected, no delays. So I am ruling out an issue with the Truenas box.

Is there a configuration setup in Linux that I may have set wrong for interfacing with an SMB share? Something I need to do to change? I'm not that good at the Linux, I was able to get the SMB share working from a guide but that's about the limits of my knowledge lol.

edit: if it helps, I am just using CIFS to mount the drive using the following line in /etc/fstab:

//truenas.local/bruh2 /media/bruh2 cifs credentials=/home/<username>/.smbcredentials,rw,uid=1000,gid=1000 0 0

That is the only configuration I set.

cross-posted from: https://piefed.world/c/tech/p/1131733/linus-torvalds-says-ai-powered-bug-hunters-have-made-linux-security-mailing-list-almost

The continued flood of AI reports has basically made the security list almost entirely unmanageable, with enormous duplication due to different people finding the same things with the same tools. People spend all their time just forwarding things to the right people or saying "that was already fixed a week/month ago" and pointing to the public discussion.

Which is all entirely pointless churn, and we're making it clear that AI detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved - and only makes that duplication worse because the reporters can't even see each other's reports.

AI tools are great, but only if they actually help, rather than cause unnecessary pain and pointless make-believe work. Feel free to use them, but use them in a way that is productive and makes for a better experience.

The documentation may be a bit less blunt than I am, but that's the core gist of it. So just to make it really clear: if you found a bug using AI tools, the chances are somebody else found it too. If you actually want to add value, read the documentation, create a patch too, and add some real value on top of what the AI did. Don't be the drive-by "send a random report with no real understanding" kind of person. Ok?

I think one helpful trick when thinking about AI hype is to replace mentions of "AI" with "Blockchain" to see how silly it all sounds.

This adds support for running crystal-dock on the COSMIC desktop environment (System76, currently in alpha).

An intresting talk on Is Everything a File, IO Models, Is C a Low Level Language, and a quick comparison on Interfacing with USB devices on Mac OS, Linux and Windows.