What opinion just makes you look like you aged 30 years

  • argv_minus_one@beehaw.org
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    I mean, you could have GUI for some CLI tool.

    Yes, I’ve seen that pattern before, but:

    1. I wouldn’t expect them to have many libraries in common, other than platform libraries like libc, since they have completely different purposes.
    2. I was under the impression that Docker is for server applications. Is it even possible to run a GUI app inside a Docker container?

    Also, if you are going to make something that have more than one binary

    If they’re meant to run on the same machine and are bundled together in the same container image, I would call that a questionable design choice.

    Man, that’s underestimating compiling time and frequency of updates of various libs

    Well, I have only my own experience to go on, but I am not usually bothered by compile times. I used to compile my own Linux kernels, for goodness’ sake. I would just leave it to do its thing and go do something else while I wait. Not a big deal.

    Again, there are exceptions like Chromium, which take an obscenely long time to compile, but I assume we’re talking about something that takes minutes to compile, not hours or days.

    and overestimating overhead from dynamic linking (it’s so small it’s calculated in CPU cycles).

    No, I’m not. If you’re not using JIT compilation, the overhead of dynamic linking is severe, not because of how long it takes to call a dynamically-linked function (you’re right, that part is reasonably fast), but because inlining across a dynamic link is impossible, and inlining is, as matklad once put it, the mother of all other optimizations. Dynamic linking leaves potentially a lot of performance on the table.

    This wasn’t the case before link-time optimization was a thing, mind you, but it is now.

    Basically, dynamic linking reduces update overhead, like with static linking you’ll need to download full binary every update, even if lib is tiny, while with dynamic you’ll have to download only small lib.

    Okay, but I’m much more concerned with execution speed and memory usage than with how long it takes to download or compile an executable.

    • Hagarashi8
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      I mean, you could have GUI for some CLI tool.

      Yes, I’ve seen that pattern before, but:

      1. I wouldn’t expect them to have many libraries in common, other than platform libraries like libc, since they have completely different purposes.
      2. I was under the impression that Docker is for server applications. Is it even possible to run a GUI app inside a Docker container?

      Also, if you are going to make something that have more than one binary

      If they’re meant to run on the same machine and are bundled together in the same container image, I would call that a questionable design choice.

      In the time i was thinking about some kind of toolkit installed though distrobox. Distrobox, basically, allows you to use anything from containers as if it was not. It uses podman, so i guess it could be impossible to use docker for GUI, although i cant really tell.

      inlining is, as matklad once put it, the mother of all other optimizations. Dynamic linking leaves potentially a lot of performance on the table.

      Yes, but static linking means you’ll get security and performance patches with some delay, while dynamic means you’ll get patches ASAP.

        • Hagarashi8
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          1 year ago

          Yeah, but there’s by lot more security improvement by having ability to apply fix for severe vulnerability ASAP than weakening from possible incompativilities. Also, i wonder why i never brought it up, shared libs are shared, so you can use them across many programming languages. So, no, static is not the way to replace containers with dynamic linking, but yes, they share some use cases.

          • argv_minus_one@beehaw.org
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Yeah, but there’s by lot more security improvement by having ability to apply fix for severe vulnerability ASAP than weakening from possible incompativilities.

            Um, we’re talking about undefined behavior here. That creates potential RCE vulnerabilities—the most severe kind of vulnerability. So no, a botched dynamically-linked library update can easily create a vulnerability worse than the one it’s meant to fix.

            Also, i wonder why i never brought it up, shared libs are shared, so you can use them across many programming languages.

            Shared libraries are shared among processes, not programming languages.

            • Hagarashi8
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              Shared libraries are shared among processes, not programming languages.

              You still can use them in any programming language