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

Yeah, that’s bizarre. I’d never have guessed /home was created by tmpfiles

deleted by creator

I didn’t after breaking it and rebooting

I restored the snapshot from before breaking the system and tried to see what would happen if I didn’t just reboot after apt bailed out

You can’t - it’s just asking what runlevel to launch, and there are no files for any runlevel

You’d need to add init=/bin/sh through grub at that point

(As the tester above) It is a broken state

It failed to install the initscripts package because apt bailed out

apt —fix-broken install got you a little closer, but the screenshot didn’t say they tried that

My bet is this worked when systemd was first introduced, but since there’s not much use for it now, and sysvinit is deprecated, it just doesn’t accidentally work anymore

I was curious too, so I tried it in a virtual machine

It half installed sysvinit, systemd failed to get fully removed, and apt gave up due to too many post-install errors

The reboot threw me into an init that asked for me to specify the runlevel (since there wasn’t anything in init.d)

I guess they didn’t understand the difference between that question and a logged in shell

My guess before trying it was that they somehow got stuck in Grub’s shell

https://portableapps.com/apps

You should look into unattended-upgrades

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

• Debian Stretch (2017)
• Ubuntu 18.04 (2018)
• Debian Buster (2019)
• Ubuntu 20.04 (2020)
• Debian Bullseye (2021)
• Ubuntu 22.04 (2022)
• Debian Bookworm (2023)
• Ubuntu 24.04 (2024)

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

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/e5949a27-999d-4b6e-8c49-3dbed32a00bc@zytor.com/

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

https://lore.kernel.org/lkml/20240110175755.GC1006537@mit.edu/

There’s assembly and makefiles too

Less of a joke answer, there has been work to allow Rust bindings for drivers.

For an example from the other poster’s explanation:

https://lwn.net/Articles/249460/

This was pre c++11 - not sure if he’s changed his mind at all with more modern c++

Unless they’ve changed it very recently, Wells Fargo’s passwords are case insensitive

Even in open source, responsible disclosure is generally possible.

See, e.g. Spectre/Meltdown, where they worked privately with high level Linux Kernel developers for months to have patches ready on all supported branches before they made the vulnerability public