If it required a remote kernel debugger to get things going why not add a quick screenshot of the assembly instead of saying there aren't "any identifiable marks for...64 bit build"? Identifiers are everywhere if you think outside the box.
For modern distros, the nft package includes an alternative binary that takes the place of /sbin/iptables and translates the input to an nft compatible format. As far as the kernel is concerned, iptables is still iptables. Old iptables can be accessed by calling the iptables-legacy binary which will auto load the old iptables ko.
Maybe linux-distros has a poc or GTFO rule in place to keep the unchecked "I can get root on your box with this one weird trick but I won't tell you how" emails to a minimum. Just a guess though.
I'm not sure as I've never followed how OSS projects get patched w.r.t security in particular. I've always groaned at my employer for running EOL operating systems and tell them about upgrading to a supported OS to prevent getting into this type of situation.
My reasoning was that if we were running a supported version of $oss_project then we'd get security updated naturally.
The way I interpret that paragraph is that now with an additional revenue stream (Pro/ESM) they can develop security patches and only subscribers will get them. I think their attempt to get the conversation started (putting ambiguous sentences inside of apt) has back fired however.
I think this discourse comment by a Canonical employee should be read by everyone before making a judgement. It's really easy to make assumptions as an end user, myself included.
```
Canonical has never provided security updates for universe packages until this week, so nothing has changed for you if you decide to simply ignore the message
```
I think that bin+cue had trouble with mixed mode disks. This was my experience many, many years ago. It may have changed.
Back in the day, the format that worked for me (for mixed mode) was CloneCD's CCD+IMG+SUB. Looks like CloneCD is still maintained and for sell.
www.redfox.bz/en/clonecd.html
But containers are not just chroot + marketing. Some containers offer real security advantages not found with using straight up chroot. I would agree that the __basis__ of containers is chroot however.
Any search of "chroot vs docker" or "chroot vs lxc" will immediately show that there are some attempts made to isolate the container from the host.
But I will say that I use docker images on a regular basis in chroots for the simple fact that I don't have to wait for debootstrap (or similar) to build a chroot for me.