Why are reproducible builds only on one platform (Android)? Desktop version could have a built-in backdoor and data would be transferred not from the phone, but from the PC)

    • DarkenLM@kbin.social
      link
      fedilink
      arrow-up
      18
      arrow-down
      5
      ·
      1 year ago

      I’ve seen a lot of native applications run way worse compared to their electron alternatives. The problem is most devs don’t give a shit about code optimization.

      • crispy_kilt@feddit.de
        link
        fedilink
        arrow-up
        13
        ·
        1 year ago

        It’s not that the devs don’t care, it’s that they’re not given the time to do it properly. Developer time is expensive, that’s why most companies ship the very first rough draft that kinda works. If the shittyness affects profits then they will invest the absolute minimum in one specific area affecting business and nothing more.

        • DarkenLM@kbin.social
          link
          fedilink
          arrow-up
          6
          ·
          1 year ago

          Yes, I also realised that a while after posting my comment. Corporativism is a plague that turns everything into a shittier version of itself.

        • crispy_kilt@feddit.de
          link
          fedilink
          arrow-up
          4
          ·
          1 year ago

          Linux users aren’t a very interesting target audience for any business intending to make money because they’re not used to paying for software

          Steam, JetBrains and many more would disagree

          • JetBrains isn’t exactly a product for the general audience like Signal is. Even then they’re using the Electron approach (by building their IDE on Java, and Java doesn’t use the native OS UI in any way). They do support some Linux elements (shortcut schemes and such) but in practice they’re no different from any Electron app. If anything, Jetbrains’ success on Linux shows that Linux users don’t care about native apps as much as you may think.

            Steam is successful on Linux (though it’s also mostly Chromium-based, except their Chromium is even more out of date). They’ve invested heavily into their Linux ecosystem for Intel/AMD GPU PC’s for their failed Steam Machines and successful Steam Deck (Steam is quite laggy and shit on Nvidia+Linux but that’s Nvidia for you). However, most games sold aren’t built for Linux. Linux gamers buy Windows games and run compatibility software, so the games companies are still targeting Windows. I would give you an example from my sizeable Steam library, but the checkbox to disable listing Proton-based games is broken (just doesn’t turn off lol).

            Jetbrains and Steam are excellent examples of “don’t develop for Linux, develop for other platforms and port to Linux while you’re at it”. Valve tries its hardest but most of their income still comes from the Windows products they sell.

            • crispy_kilt@feddit.de
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              1 year ago

              they’re using the Electron approach

              Java isn’t the massive pile of shit that the JS ecosystem is. If you think these two are comlarable it is obvious you don’t know what you’re talking about. The landscape is a tiny bit more complex thn “C++ and then not C++”

    • Max-P@lemmy.max-p.me
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      Electron isn't all that bad honestly. The bad part is people slap the same pile of massive and bloated node modules and framework in it that's the same cause as to why the modern web is so horrible.

      A well written web app in Electron can feel quite good and snappy. It's just that the companies that own most of those apps don't care and won't give the developers time to build an optimized app, because that doesn't bring in money, but new features do.

      Especially if you share the system electron runtime between apps, even the memory overhead isn't all that bad even compared to modern toolkits like GTK4 and Qt5/6.

      But then you load like 5MB of poorly written CSS and a 10MB JS bundle plus all the assets and full screen background image and yeah, it'll chew through resources fast.


      Sometimes when I have to debug a modern website, I'm amazed at the amount of crap it's there. Just checking the inspector in the browser, half the elements have hundreds of overriden CSS rules and hacks to make it display correctly instead of writing the CSS proper. Boatload of unnecessary divs and whatnot everywhere. That strains any layout engine.

      The profiler in the browser console? Yeah nobody uses it, or even knows it exists and how to use it. I wow'd a lot of people just making a quick flamegraph and speeding up the code 10x like it's nothing.

      We have the tools, but not the will to optimize.

    • FarLine99@lemm.eeOP
      link
      fedilink
      English
      arrow-up
      7
      arrow-down
      8
      ·
      1 year ago

      Just because an application is written using Electron does not give it the right not to support reproducible builds. One has nothing to do with the other.

      • crispy_kilt@feddit.de
        link
        fedilink
        arrow-up
        16
        arrow-down
        2
        ·
        edit-2
        1 year ago

        Yeah it does. The whole toolchain sucks ass. Knowing JS and its ecosystem running the same build command directly one after another on the same machine will probably yield different hashes. It’s just shit heaped upon mountains of garbage.

        • NPM has version pins and every tool I know of is, or can be, deterministic. Code obfuscators often introduce randomness but an open source app like this has no reason to be obfuscated in the first place.

          I’ve worked with JS for years and it’s not like reproducible builds are impossible. They’re not often done, because who even develops JS and cares about this type of thing, but it’s not like there’s an inherent limitation here.

          The only problem I can think of is transpilers inserting different line endings depending on the platform they’re run on, but if you use a Docker container for the build then there’s no good reason why that should be an issue.

          • FarLine99@lemm.eeOP
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            And I mean that too. The Reproducible Android build was done via Docker, so I think absolutely the same thing could be done here.

        • FarLine99@lemm.eeOP
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          5
          ·
          1 year ago

          More like guesswork/assumptions than reality. I agree that Electron is meh. But I think it could still be done, f.e. with docker container as it is on Android.

          • ubergeek77@lemmy.ubergeek77.chat
            link
            fedilink
            arrow-up
            4
            arrow-down
            2
            ·
            1 year ago

            More like guesswork/assumptions than reality

            Sorry to be blunt, but you’re not a developer and it shows. Android’s build system was purpose made to be reproducible. Electron was not.

            There is so much going on in an Electron build, most of which is out of Signal’s control unless they maintain an entire fork of the Electron build stack. That is an enormous engineering effort for basically zero benefit.

            It probably is functionally reproducible, apart from checksums differing due to build dates baked into the artifacts somewhere. It’s not as easy as you think.

            If you think it’s as easy as “building it in a Docker container,” then by all means, try.

            • FarLine99@lemm.eeOP
              link
              fedilink
              English
              arrow-up
              1
              arrow-down
              2
              ·
              edit-2
              1 year ago

              I will not enter into disputes because… not too tech savvy. But I’m still sure that it could be realized. They just decided not to bother.