3 ms·

I still don't understand why they want to bypass APT here. I saw the FAQ about this and it still doesn't make sense to me and just feels like some kind of a loc

I still don't understand why they want to bypass APT here. I saw the FAQ about this and it still doesn't make sense to me and just feels like some kind of a lock-in attempt.

rlpb 10y ago
You can continue to use apt and just reboot when your kernel package is updated. If you don't want to reboot, then you can add livepatching. It works with the existing kernel packages to fill the gap before you reboot. In other words, it's not a bypass for apt; it works in addition to it. But livepatching doesn't cover all situations. Currently it's only high priority CVEs, and the article talks of situations where it's not possible at all. Given that apt is the fallback, I don't see how anyone could consider it to be lock-in.
fragmede 10y ago
There are a couple pieces to that, not the least of which is Canonical wanting to push their new 'snap' format, for better or worse. The other thing is that Apt is not a good fit for the task - say it's daemonized programs instead of live patches. Apt only takes responsibility for downloading the bits onto the machine and unpacking them, and init/systemd is responsible for actually running programs. However, for live patches, it's critical the program be running/the patch installed, and Apt doesn't manage running processes, nor does it have a UI whos purpose is to report on patches that have successfully downloaded but fail to install. These aren't fatal problems, but those aren't features upstream apt is likely to want (maybe systemd wants to swallow apt), so then you're forking apt, with all the work that entails. Might as well just write your own thing in that case.
- digi_owl 10y ago
  > maybe systemd wants to swallow apt Say hello to Flatpak...
- IgorPartola 10y ago
  But APT does. It can run the post-install script for the package, which can certainly include the live-patching bits. It's not like live-patching needs a continuously running daemon. Saying that APT can't do this is nearly equivalent to saying that APT should not be trusted to run any post-install scripts at all, which basically means it shouldn't be trusted to install half the software out there.

I still don't understand why they want to bypass APT here. I saw the FAQ about this and it still doesn't make sense to me and just feels like some kind of a lock-in attempt.

rlpb 10y ago

You can continue to use apt and just reboot when your kernel package is updated. If you don't want to reboot, then you can add livepatching. It works with the existing kernel packages to fill the gap before you reboot. In other words, it's not a bypass for apt; it works in addition to it. But livepatching doesn't cover all situations. Currently it's only high priority CVEs, and the article talks of situations where it's not possible at all. Given that apt is the fallback, I don't see how anyone could consider it to be lock-in.

fragmede 10y ago

There are a couple pieces to that, not the least of which is Canonical wanting to push their new 'snap' format, for better or worse. The other thing is that Apt is not a good fit for the task - say it's daemonized programs instead of live patches. Apt only takes responsibility for downloading the bits onto the machine and unpacking them, and init/systemd is responsible for actually running programs. However, for live patches, it's critical the program be running/the patch installed, and Apt doesn't manage running processes, nor does it have a UI whos purpose is to report on patches that have successfully downloaded but fail to install. These aren't fatal problems, but those aren't features upstream apt is likely to want (maybe systemd wants to swallow apt), so then you're forking apt, with all the work that entails. Might as well just write your own thing in that case.

digi_owl 10y ago
> maybe systemd wants to swallow apt Say hello to Flatpak...
IgorPartola 10y ago
But APT does. It can run the post-install script for the package, which can certainly include the live-patching bits. It's not like live-patching needs a continuously running daemon. Saying that APT can't do this is nearly equivalent to saying that APT should not be trusted to run any post-install scripts at all, which basically means it shouldn't be trusted to install half the software out there.