Max

You can always do that though since you can dualboot to whatever other system you want. I thought their idea was to have a mode you turn on and off in your main system, but I think that’s just how kernel anti-cheat would already work.

I think what they’re suggesting is literally just kernel anti-cheat itself. Am I missing something?

Yeah. It has easier sandboxing. You can accomplish most of the same things with traditional packages with something like apparmour, but flatpak has motivated the development of portals which allows apps to request permissions on the fly more easily.

It fulfills a different purpose than system packages. First, it can be run without privileges/system modification, so it works on immutable distributions. Second, it doesn’t share libraries between apps (with some exceptions) or the system, so you don’t have to package separately for each. It essentially takes some of the container philosophy/tech and brings it to desktop apps. This also gives it some ability to do some sandboxing that isn’t as easy with system installed apps.

This approach comes with some downsides. Particularly larger storage requirement for apps, sometimes less integration with the system, and lack of ability for apps to easily call/interact each other unless they’re packaged together.

It’s meant for complete GUI apps and not small tools/packages that are the standard in system package managers

I like it a lot when I don’t need a full IDE or a terminal editor (which I use micro for).

The folding in Kate isn’t bound to a keyboard shortcut by default, but you can bind the katepart > Toggle current node in settings > configure keyboard shortcuts. It’s also available via mouse on the left side.

I believe Kate does that! It’s a GUI and not a TUI though. Not sure if that was a requirement as well

If you haven’t seen it, the open source driver for 3d connexion stuff is also pretty good, and I believe might be necessary for blender to work with it. It’s also probably packaged in the distro repositories.

https://github.com/FreeSpacenav/spacenavd

Sorry for the series of edits. Yeah, just starting timers.target or graphical.target again when you’re done without using isolate seems like a pretty good strategy!

I think if you switch back to the original target that depends on those services they should start again?

Like systemctl isolate yourtarget.target and then a systemctl isolate graphical.target to return to normal operation

Isolate will stop any services that aren’t required by the dependency chain.

Some of these might be user services though, in which case you’d need to create a user target

It’s possible that you don’t need to use isolate though, and can just start a target that conflicts and then instead of stopping it, start graphical.target

They didn’t mention licensing as the reason for the move. The community members in the discourse thread mentioned licensing as their reason for opposing the move. Canonical itself mentioned memory safety and speed as the main reasons, saying the licensing wasn’t part of the reason why