mastodon
4.6.4+glitch-th
@gentoo@fosstodon.org developer. Spends a lot of time on alternative platforms.
Why are Xen security issues allowed to retain their security marking in commit messages, like in https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.0.3 ?
@alwayscurious@infosec.exchange Could you share a bit more detail on your wpa_supplicant thoughts? There's a lot of reevaluation of iwd right now and I'm interested in what you had in mind.
(re https://www.openwall.com/lists/oss-security/2026/05/01/12)
Away from kernelposting finally..
I find Rust's LTO implementation curious in a few ways.
First, there's the very unfortunate term collisions with both LLVM and GCC [0].
But I find it interesting that they both somewhat advertise, and projects make use of, -C codegen-units [1], because you then don't get consistent results with LTO.
As far as I know, in LLVMland, nobody encourages you to mess with partitioning, and it seems like it'd be a better idea for Rust to work on partitioning instead so nobody would need to set it.
I see people recommend =1 quite often but needing to do that in GCC is basically unheard of (seen some very rare cases where it might have been useful), and I don't know if LLVM even has a strict equivalent.
[0] https://wiki.gentoo.org/wiki/LTO#Terminology
[1] https://doc.rust-lang.org/cargo/reference/profiles.html#codegen-units
Deprecating Linux support for #gentoo: https://www.gentoo.org/news/2026/04/01/gentoo-hurd.html
Today, we changed the default recommended filesystem in the #gentoo handbook from ext4 to xfs.
XFS is robust and has all the niceties of ext4 (modulo shrinking) but with modern features on top.
(It helps that xfsprogs doesn't have weird endianness bugs too..)
btrfs is of course another option for the future but our users are conservative in some respects, and baby steps > none.
The main benefit of this is reflinks and copy_file_range which automatically takes advantage of that.
Now, as for using it.. 🧵
