A few years ago we were able to upgrade everything (OS and Apps) using a single command. I remember this was something we boasted about when talking to Windows and Mac fans. It was such an amazing feature. Something that users of proprietary systems hadn’t even heard about. We had this on desktops before things like Apple’s App Store and Play Store were a thing.

We can no longer do that thanks to Flatpaks and Snaps as well as AppImages.

Recently i upgraded my Fedora system. I few days later i found out i was runnig some older apps since they were Flatpaks (i had completely forgotten how I installed bitwarden for instance.)

Do you miss the old system too?

Is it possible to bring back that experience? A unified, reliable CLI solution to make sure EVERYTHING is up to date?

  • gerdesj
    link
    fedilink
    English
    arrow-up
    11
    ·
    9 months ago

    Never used Flatpak or Snap in nearly 30 years of using Linux. I might one day but not yet.

    I don’t use Fedora these days but your package manager will probably have some hooks. Add one to update your Flatpaks when it has finished its main job.

    • gronjo45@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      9 months ago

      I’ve seen the term “hooks” used all the time and have always wondered what the need for them is. I was a Windows user my entire life since childhood and recently rectified that a couple months ago.

      Unlearning the Windows paradigm of operating systems has been annoying. So many functional aspects of my machine abstracted away made me have to create an entirely new scaffold for learning technology…

      • Hopscotch
        link
        fedilink
        arrow-up
        1
        ·
        9 months ago

        A hook is a mechanism for adding functionality at a certain point in a program’s normal flow. As a simple example, imagine a program that works by doing three things in order. It could have hooks that allow the user to add actions before or after any individual steps. Each possible point in the flow is a separate hook. One way to implement it is with a directory for each hook in the program’s configuration directory, where executables can be placed; the hook runs each executable in sorted order.

        I didn’t look up any of this, so it may not be the best explanation, but I hope it is helpful.

        • gronjo45@lemm.ee
          link
          fedilink
          arrow-up
          1
          ·
          9 months ago

          Thanks for the explanation! I always wondered why would describe hooks so trivially. I’m still bleaching my brain of the Windows habits I developed from lifs-long usage.

          I looked a little more into hooks, and am curious if a patch can kind of be like a hook? Where you create a config file that has symlinks to all the executables like you mentioned? Still a noob when it comes to software creation :D

          • Hopscotch
            link
            fedilink
            arrow-up
            2
            ·
            9 months ago

            [Can] a patch can kind of be like a hook?

            In the free software world, a patch usually describes a file that lists lines to be added to or removed from another file (or multiple files). The most common use for this is probably with actual source code.

            Binary (non-text) patches are also possible, and in Windows a software bug-fix “patch” would likely be mostly binary. In the free software world, it’s uncommon to use binary patches for updates; instead the source is patched (either in the main upstream project or by a distribution) and a new binary package is built and published.

            Where you create a config file that has symlinks to all the executables like you mentioned?

            I don’t really understand how those two questions relate, so I may not be able to give you a good answer. Often a configuration file has a variable=value structure, but it would certainly possible to have a list of file paths in a configuration. However, this might instead be implemented as an actual directory (like ~/.config/app/pre-hook.d/) where each executable file in that directory is executed by the “pre” hook in the app. (Configuration directories often work very similarly also.)

            Whether the paths are symlinks is likely to be irrelevant, as this is more a filesystem level feature that would often be ignored entirely by the application.

            I hope this is helpful.