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.

Yes and this decision haunts distros like Ubuntu over and over again. There's no easy win though.

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.

That's fine. They didn't want it on linux-distros anyway!

To hold you accountable for the things you do with their network maybe?

Or Trust Wallet 0 day.

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.

https://discourse.ubuntu.com/t/why-is-extended-security-main...

``` 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 ```

> Canonical has never provided security updates for universe packages until this week

Is that true, though? Until now, wasn't it just that they weren't guaranteed? Didn't Canonical make security patches available in universe on a "best-effort" basis, or at least say they did?

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.

That seems deliberately misleading. They may not have “provided” security updates, but they did “distribute” them when they were provided by community package maintainers.

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.

Without a more granular solution in apt, this seems to require Ubuntu to halt the practice of allowing maintainers to provide their own updates for those packages. In other words, they seem to be taking away the community maintainers ability to provide updates for those packages. I am not sure how they can claim nothing is being lost here.

I use wine to play Roblox with my kids and I don't have to dual boot windows. Works great on Linux mint and pop os

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.