I’d used Linux a bit out of curiosity in the Windows XP era
Windows Vista came out and was completely unusable on the computers I or anyone around me owned. It was also harder to configure than Linux and the new UI looked worse than the Linux UIs at the time
So I switched and haven’t been back to Windows since
If an attacker gets access to your system, they will be able to ensure you can’t get rid of their access
It will persist across operating system installs
However, this requires them to get access first
The summary here and in the paper isn’t very helpful to check what CVEs are relevant
The kernels referenced aren’t supported, and it says the issues were reported upstream
Checking some of the references of the paper, it says
By the time we posted this writeup, all the distros have patched this vulnerability.
Do you know what CVEs users should check against?
It’s a strange suggestion after very recently working closely with openSUSE to ensure Leap can use the same binaries as SLE, though
Well, a.out doesn’t make much sense these days.
Gotta move to .elf
It looks like an alternative to LocalSend rather than Syncthing
Yeah, that’s bizarre. I’d never have guessed /home was created by tmpfiles
The developer image, dx, includes rocm-hip and rocm-opencl:
https://github.com/ublue-os/bluefin/blob/main/packages.json
The packages under “dx” are the main reason I’m considering it over stock Fedora
Yeah, I can’t stop laughing at
If you can’t parse tabs, you can’t have page sizes.
It’s like how I’d admonish my pet
There’s been an experimental HTTP response to support that for a long time, but no one has decided on a standardized way to collect the micro payments
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402
Presumably. The company was made by an ex-Apple designer
Yeah, Ubuntu pulls in the development version of Debian
“Sid” is the unstable name for Debian - where packages are being tested for the next release
Debian Bookworm was released 2023
Ubuntu LTS and Debian have tended to release on a two year cadence offset by a year
Ubuntu 22.04 is long before Bookworm
It looks like Ubuntu pulled in Bookworm’s version in 23.10
If Mint is sticking to LTS Ubuntu versions, it will get it whenever it rebases on top of Ubuntu 24.04
Edit: Debian (Bookworm) polkitd version 122: https://packages.debian.org/bookworm/polkitd
Ubuntu 22.04 polkitd version 105: https://packages.ubuntu.com/jammy/polkitd
Ubuntu 24.04 pre-release polkitd version 124: https://packages.ubuntu.com/noble/polkitd
Vtable equivalents are used extensively in the kernel
You’ll find structs all over the place setting them up, e.g. every driver sets up a .probe function that the core will call, since it doesn’t know what driver it’s loading
Bookworm looks to be on version 122, so as downstream distros update to newer Debian versions, it should be updated now
The ext4 driver can read ext2/ext3 partitions while supporting the 2038 time issue
The only change here is the driver loading the filesystem
Ext3 support is already only available through the ext4 driver
That doesn’t really surprise me, as most of those are the same requirements from any embedded development use case using c++ that I’ve worked on
4 and 5 are the only ones stricter than I’m used to
In that post, his critiques were around the problems with the STL and everyone using Boost. The STL has improved significantly since then, and it would be a limited subset of c++ if it was ever allowed
There have been mailing list conversations earlier this year, citing that clang/gcc now allowing c++ in their own code might mean they’ve taken care of the issues that made it unusable for kernel code
https://lore.kernel.org/lkml/[email protected]/
I’m not saying it will happen, but it’s not being shot down as an absolute insanity anymore, and I wouldn’t have expected Rust to be allowed in the kernel, either
That’s my guess, but there was a conversation on the mailing list a few months ago that wasn’t just immediately shut down, even by other prolific developers
Ts’o seems skeptical, but is at least asking whether c++ has improved
Both GNU and GrapheneOS have staunch requirements and will accept no compromises.
This is a situation where their requirements don’t align, so they’ll never reach an agreement.
GrapheneOS, for example, is also strictly against making the Fairphone line of phones a little more secure because it doesn’t meet all of their security requirements
In this case GNU won’t certify GrapheneOS as fully open because it includes binaries that aren’t open
The FSF is more along your line of improving the situation where they can