It's probably not your fault.

On a cache miss, there are two things a reverse proxy (which Fastly is to us) can do. It can make the client wait until the proxy itself fetches the requested content and then serve it, with subsequent requests being served from the cache. From a user's perspective, it means staring at "hung" process, and people tend not to be understanding when a program is stuck seemingly doing nothing.

Instead, the proxy can stream the response from the origin, caching it at the end. This makes the client receive the data right away, although it's not without drawbacks.

In a streaming setup like Flathub's, an all-MISS path adds some upstream latency before the first byte, but also limits the download speed to what the slowest link can deliver. As we don't run servers in the same datacenter or on a single backbone network, the hop from Fastly through the caching proxy to the master server incurs a penalty that may affect how quickly the data gets back.

In order to cache files larger than 20MB, Fastly expects customers who use streaming misses to use segmented caching. Anything larger than that gets broken down into smaller chunks. When Fastly wants the data from us, it will add a Range header specifying which bytes we should respond with. Fastly will then serve the request after reconstructing the file from various chunks. Our caching proxies also use the value of the Range header in the caching key to avoid requesting the full file over and over again from the master server as well.

While great for caching, many concurrent range MISSes can turn what would be a sequential file read into scattered, random reads. It wouldn't matter with SSD or NVMe, but as the repository is stored on HDDs, when combined with streaming misses, it can turn cold transfer speed into min(network bottleneck, ZFS random-read bottleneck).

Counterintuitively, you may improve your download speeds by aborting the ongoing Flatpak operation and starting it again. While the initial request was slow, there's a non-zero chance it went through all the caching layers and it will become a cache hit in the meantime. Flatpak

Let's talk Flatpak. When installing or upgrading applications, Flatpak will try to use delta files. A typical delta is an update file that contains only the difference between versions. There are also from-scratch deltas, which effectively are an archive with all files required to install an app from scratch, thus the name.

Flathub generates a single upgrade delta and a from-scratch delta for the latest version. Delta generation is an expensive process in terms of disk reads and writes, but also disk space. Because our ZFS setup isn't exactly the fastest, generating more delta files also affects how quickly we can publish an update. Yes, in theory we could be doing this out of band but we don't. In hindsight, Titanic wasn't unsinkable after all.

What happens if you are not updating often enough? A lot of suffering. Flatpak will download each missing file between the version you are on and the one you want to upgrade to, separately. This is an almost certain cache miss causing even more random seeks on the master server. At this point Flatpak would be better off downloading the from-scratch delta but it can't. The behaviour is controlled by OSTree, which doesn't offer any knobs to affect it. It is the right choice if the goal is to limit the bandwidth used by the client to fetch updates, but an incredibly bad one for anyone on a reliable connection; downloading a single large file is almost always faster than fetching multiple smaller ones.

What do? Some brave soul could fix OSTree to apply a better heuristic on when to use from-scratch deltas for upgrades, or at least make it expose an API that lets Flatpak choose. For the rest of us mere mortals, we can only update regularly or wait patiently for the update to finish

I just updated (I use arch btw) and had to reboot WaterFox. The default search engine got changed to 1.org and StartPage no longer shows up as a default option even. Has this happened to anybody else?

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