• henfredemars@infosec.pub
    link
    fedilink
    English
    arrow-up
    24
    arrow-down
    1
    ·
    edit-2
    1 year ago

    It’s a cool feature, and I played with it some, but I don’t really see how to use it in a home or small office environment unless you’re willing to subscribe to someone who can generate the live patches for you.

    I can certainly generate the patches myself, but it’s much faster to let the maintainer of my distro’s kernel handle shipping new packages and accepting the reboot. My system reboots really quickly.

    If high reliability is a concern, I would suggest load balancing or some other horizontally scaled solution such that you’re not impacted by one machine going down. Because they will go down for things other than updates!

    • Chewy@discuss.tchncs.deOP
      link
      fedilink
      arrow-up
      16
      ·
      edit-2
      1 year ago

      Not rebooting for a long time makes me nervous once I actually reboot, as I might’ve changed something but didn’t make it persistent. Luckily I’ve become much better with documenting chabges after switching to NixOS.

      • taladar@sh.itjust.works
        link
        fedilink
        arrow-up
        4
        ·
        1 year ago

        It also means booting is untested until something like a hardware fault or a power outage forces it onto you and you have to deal with any reboot issues at the worst possible time and a time you did not choose.

    • AggressivelyPassive@feddit.de
      link
      fedilink
      arrow-up
      5
      ·
      1 year ago

      There are some cases, where scaling is relatively hard to achieve in a sane manner. Especially when you’re in that weird place where you’ve grown out of the SME solutions, but can’t really justify the enterprise solution yet. I’ve worked on such a project, switching to the big boy DB cluster was pushed back again and again because of very high upfront costs (licenses and staff).

  • taanegl@beehaw.org
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    1 year ago

    I can see this being useful for NixOS. It’s still a glimmer in the postman’s eye, and we’re WAITING for systemd src to come with certain options to make the attaching and reattaching of systemd easier.

    But I could easily see nixpkgs implement functions that allow nixos-rebuild switch to use either live patching method, or even implementing one specifically for NixOS.

    This would be twice as neat, because switch is already magical in how it shifts from one system to another. If you could then also live patch the kernel? It just adds another super power.

    • Atemu@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      11 months ago

      But I could easily see nixpkgs implement functions that allow nixos-rebuild switch to use either live patching method, or even implementing one specifically for NixOS.

      Sadly, I could not. Live patching requires extensive knowledge of the previous system state and that is the antithesis to NixOS where any system state is fully independent of any other possible system state.

      nixos-rebuild switch isn’t very magical at all once you understand this principle.

      Live patching is also not really something you want to use or use frequently. It’s more intended for “this super critical box can only be taken down next Saturday but there’s a fix for a 0-day in the kernel today that we need ASAP”. If it’s at all possible to simply reboot, simply reboot (or kexec).

      • fl42v@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        Wtf, guys, don’t be mean to the bot: they’re doing the job to the best of their ability. Besides, I’ve linked to farside that redirects to piped, and it’s kinda weird to expect the bot’s dev to know of all the possible redirecters (or whatever they’re called).