Linux 6.5 has many great features from the AMD P-State EPP driver default rather than ACPI CPUFreq for Zen 2 and newer supported AMD Ryzen systems, initial USB4 v2 enablement, initial MIDI 2.0 kernel driver work, more Intel hybrid CPU tuning, and a whole lot more.
USB4 v2
Why is USB insistent on having terrible naming schemes?
They want manufacturers to stop writing the USB specification on the packaging and instead focus on the speed.
Of course, this backfired since manufacturers are glad to have another opportunity to confuse potential buyers into purchasing a sub-par product.
I can’t really blame the manufacturers because the USB-IF’s suggested schemes would just confuse people even more. If people see 10Gbps on the box they’re gonna assume it can do 10Gbps, but tons of stuff ends up capped well below the USB link speed (most everything based on SATA<->USB converters internally is 6Gbps max).
It’s choosing between a bad naming scheme or something a lot of consumers would interpret as a straight up lie.
But that isn’t USBs fault sata is capped at 6. That’s like saying well I plugged in a usb 1 hard drive adapter and I’m not getting 10 Gbps.
Yes it was never intended that any consumer hears about something like “USB 3.2 Gen 2” that was strictly internal naming for people developing USB devices.
In fact the naming guidelines we’re simplified even further than in the older version you linked: https://cdn.arstechnica.net/wp-content/uploads/2022/09/USB-IF-language-usage-guideliens.pdf
But yea borderline fraudulent manufacturers and uninformed tech journalists are to blame for all this confusion
Bought a “usb 3.2” usb-a/c combo thumb drive.
Not only 5gbps, but usb-storage so not even uas queued command speed.
Thats going back quick.
The v2 part here really just refers to the fact that it’s version 2 of the specification. Consumerrs only need to know the term USB4 and the speed that their device operates at. It’s sort of like complaining that the ietf has terrible naming schemes because HTTP is defined in half a dozen RFCs with 4 digit numbers. This versioning is just meant for people developing USB things.
Actually this article here is one of the few times where even mentioning the version 2 part is reasonable since the details of these specifications actually matter to kernel developerrs. For everybody else it’s just USB4 80 gbps.
and the speed that their device operates at.
That is expecting a lot of the average consumer and is rather unreasonable to do so.
Well you have to differentiate somehow and USB 5, 10, 20, 40 or 80 gbps sound like reasonable terms for normal people.
usb 3.1 gen 1 vs gen 2 vs 3.0 vs 4 vs 4 v2
yes these are the terms that are not supposed to be used in product naming or by consumers and are just intended for use by people developing USB devices.
Hopefully bcachefs will be merged with 6.6.
For those who may not know, bcachefs (bcachefs.org) was written by the same developer as bcache (wikipedia.org) - TIL! I was always confused when reading headlines about bcachefs but never looked into why someone might give their filesystem such a conflicting name. Now it makes sense. I’ve used bcache briefly and it worked really well for my use case. Anyone using bcachefs that can speak to their own experience? How does it compare to btrfs?
I love it. I have a pool of 9x10tb spinning rust as bulk storage (background target in bcachefs terms) and 6x3.84tb SSD as cache and metadata (foreground, promote, metadata targets). It’s proven to be incredibly solid, I’ve written tons (on the order of 50+tb) to the FS and actually hit a few edge cases during my early testing in terms of scaling limits and the like.
This ~100Tb array replaced a Synology-flavoured btrfs 30Tb which had been running up against capacity limits for a while. I looked into alternative FSes: btrfs RAID wasn’t quite there for me, and zfs won’t be mainlined.
The only ‘not 100% stable’ feature is Erasure Coding, which I look forward to enabling at some point in the future.
wow! happy to hear that. May have to play around with it before I fully commit.
The new EEVDF scheduler would also be nice.
patiently waiting for it to land on Arch
Patiently waiting for it to crash my Arch.
Switch to the LTS kernel until 6.5.1
I switch to LTS as soon as I install Arch.
This is the best summary I could come up with:
Linux 6.5 was just published rather than going into overtime without any extra release candidate.
Linux 6.5 has many great features from the AMD P-State EPP driver default rather than ACPI CPUFreq for Zen 2 and newer supported AMD Ryzen systems, initial USB4 v2 enablement, initial MIDI 2.0 kernel driver work, more Intel hybrid CPU tuning, and a whole lot more.
See the Linux 6.5 feature list to learn more about all of the great changes in this end of summer 2023 kernel debut.
With nothing overly scaring coming up, Linus decided to go ahead and release Linux 6.5 stable.
Now it’s onward to the Linux 6.6 cycle with many features to look out for with what will be an autumn 2023 kernel release.
The timing now of the Linux 6.6 merge window for the next two weeks will mean that it runs through the US Labor Day holiday when a number of the kernel developers may be taking time off for holiday.
The original article contains 222 words, the summary contains 163 words. Saved 27%. I’m a bot and I’m open source!
Does anyone have a quick ELI5 for the AMD P-state or a link to some good info around it? Seems people are excited about and I’ve been out of the news cycle loop lately.
From my understanding, the old acpi only allowed for the kernel to request three levels of voltage/frequency on zen2 based CPUs. The new P-state driver allows for finer grain control of the voltage/frequency which may lead to a lower power draw and faster clocks for a given task.
