This is using Thunderbolt networking as transport, which incurs a bit of overhead.
But starting with the upcoming Linux v7.2, there's a new feature called USB4STREAM to use raw Thunderbolt packets as transport with minimum overhead and a super simple user interface:
Release of v7.2-rc1 is predicted for Jul 5, that's when this will first be available as a tarball. Until then you have to clone from thunderbolt.git/next:
Somebody is spamming kernel mailing lists under the name Marian Corcodel with a 26 MByte message multiple times per day containing a collection of nonsensical patches. Looks AI-generated, perhaps with the intention to poison LLMs. This has been going on for a few days now.
As Eric has correctly stated above, we believe iwd (Intel Wireless Daemon), or rather the ell library it relies on (Embedded Linux Library) is the only relatively widespread user space application relying on it.
I believe Carl Malamud (Internet Multicasting Service) was behind these.
The audio files are in Sun Audio format, which all browsers supported natively back then. Chromium apparently no longer does, requires saving and opening in VLC.
If you need a lot of RAM, usually you need to buy servers with multiple CPUs to which you can attach the memory. Because the amount of DRAM you can attach to one CPU is limited.
If you don't have the need for all the extra CPUs, just being able to attach more memory to a single CPU through CXL may be cheaper.
The original Raspberry Pi SoC (BCM2835) is ARMv6 with VFP2 Hard Float support.
Debian's "arm" architecture is ARMv7 with VFP3. It doesn't support BCM2835.
Debian's "armel" architecture is ARMv4. It doesn't use BCM2835 to its full potential.
So the BCM2835 is awkwardly positioned in-between Debian's two stock ARM 32-bit architectures, which motivated the decision to recompile all packages for a BCM2835-specific "armhf" distribution.
The point here is likely to pull the rug out from under scalpers' feet.
With the Raspberry Pi 5 out in two weeks, all the held-back inventory of older models will be dumped, prices will plummet, availability will become a non-issue.
A lot of RISC CPU arches which were popular in the 1990's declined because their promulgators stopped investments and bet on switching to IA64 instead. Around the year 2000, VLIW was seen as the future and all the CISC and RISC architectures were considered obsolete.
That strategic failure by competitors allowed x86 to grow market share at the high end, which benefited Intel more than the money lost on Itanium.
The PCI resource allocation code is fairly intricate and everyone is scared that changing it may cause regressions. Sergei's patch set is quite intrusive and it would be necessary to somehow break it up into smaller pieces that are slowly fed into mainline over several release cycles, always watching out for regression reports. So, the problem is known, but the engineers working on PCI code in the kernel are given higher priority stuff to work on by their employers, hence the issue hasn't gotten the attention it deserves.
Actually I forgot to mention there's another solution: A PCIe feature called Flattening Portal Bridge (PCIe Base Spec r6.0 section 6.26). That was introduced with PCIe 5.0. It's more likely that FPB support is added in mainline than the pause/unpause feature. It's supported by recent Thunderbolt chips and it's an official feature of the PCIe standard, so companies will prefer dedicating resources to it rather than some non-standard approach.
Thunderbolt devices appear in the OS as a PCIe switch, so you need two additional bus numbers (one for the Switch Upstream Port and one for the Switch Downstream Port). If the device is hotplugged to a port which has run out of bus numbers, you'll get this error message.
Mika Westerberg is constantly fine-tuning the allocation of PCI resources in the Linux kernel to avoid such scenarios. Some recent patches:
We don't have that on Linux unfortunately, so we depend on getting the initial resource allocation right.
Sergei Miroshnichenko has worked on such a reallocation feature for Linux but it hasn't been accepted into mainline yet and he hasn't posted a new version of his patches for almost two years, so the effort seems stalled:
Bad management made the wrong bet, thought Itanium and Windows would take over the world.
But what really broke all UNIX workstation manufacturers' backs was the unwillingness to cannibalize their products with affordable machines. SGI workstations were not affordable to students, so they got x86 machines instead and installed Linux. Google was built with x86-based Linux boxes because that's what the founders were using and could afford. UNIX workstation manufacturers lost an entire generation of young engineers that way. Apple eventually offered what they should have: Sleek, affordable machines with a rock-solid UNIX underneath a polished UI.
A heartfelt thank you Cameron, TenFourFox has kept my Pismo 7410/550 alive and useful for another ten years after Camino's sad demise. I've gotten so used to the regular TenFourFox updates that I already feel withdrawal symptoms now. It's always been mindboggling to me that you've done all this almost single-handedly.
But starting with the upcoming Linux v7.2, there's a new feature called USB4STREAM to use raw Thunderbolt packets as transport with minimum overhead and a super simple user interface:
https://lore.kernel.org/r/20260511102744.1867485-1-mika.west...
Release of v7.2-rc1 is predicted for Jul 5, that's when this will first be available as a tarball. Until then you have to clone from thunderbolt.git/next:
https://git.kernel.org/pub/scm/linux/kernel/git/westeri/thun...
Or alternatively linux-next:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...
Press coverage:
https://www.phoronix.com/news/Intel-Linux-USB4STREAM