6 ms·

This is called "What Andy giveth, Bill taketh away."

by SSLy 6y ago

homarp 6y ago
and this is now called Electron trading speed of development with 'hardware optimization'. Mac being a small market, some users are still opiniated/loud enough to reward nicer/native UI vs cross-ish platform lowest common denominator UI. Maybe there is hope Arm mac stays fast.
- mixmastamyk 6y ago
  + Mac OS checking every binary you run over the internet.
  - walterbell 6y ago
    Pihole and others can block those Apple queries.
    - bonestamp2 6y ago
      What happens if you block them.. do they eventually stop working if they haven't been validated in a long time?
  - Klonoar 6y ago
    It's slightly more nuanced than that - you can of course just block it from doing so, and there's certainly an argument for it being updated to not need a network call each time, but phrasing it like this makes it sound worse than it actually is. I'll just quote Jeff Johnson, who's looked into this and written about it - his comment[1] on this is post is quite useful: https://eclecticlight.co/2020/11/25/macos-has-checked-app-signatures-online-for-over-2-years/ https://eclecticlight.co/2020/11/25/macos-has-checked-app-si... >The request to http://crl.apple.com/root.crl http://crl.apple.com/root.crl is simply checking the revocation status of Apple’s own Developer ID Certification Authority intermediate signing certificate. If you examine the cert in the System Roots keychain, you can see that URL under CRL Distribution Points. This request contains no information specific to third-party developers or apps. In contrast, there’s no CRL for third-party Developer ID leaf certs signed by Apple’s intermediate cert. Their status is only available via OCSP. Notably, this: >This request contains no information specific to third-party developers or apps. https://eclecticlight.co/2020/11/25/macos-has-checked-app-signatures-online-for-over-2-years/#comment-53659 https://eclecticlight.co/2020/11/25/macos-has-checked-app-si...
    - mixmastamyk 6y ago
      You added detail, yet didn't refute the statement. That it isn't easy to simply and specifically turn off is not acceptable.
      - Klonoar 6y ago
        No, I'm fairly certain I refuted it. The parent comment is incorrectly stating that each request to Apple is checking a binary, and it's not. This has been well documented both here on HN and across the web.
        mixmastamyk 6y ago
        That's not the definition of refute. The distinction between a lazy-implied always and merely often is pedantic. The point is that it happens enough to reduce performance, while doing something no end-user asked for and is difficult, if not impossible to disable without reducing other security protections.
        Klonoar 6y ago
        There is no measurable performance loss from that one time check - it's not something happening constantly.
- whatever1 6y ago
  I would say that 90% of my pc resources are consumed to execute JavaScript code. If we need dedicated hardware to execute this more efficiently so be it. We do it anyway for so many other domains. Video, graphics, encryption etc.
  - deleted 6y ago
    [deleted]
  - Jetrel 6y ago
    One of the big deals with electron-et-al is that we're not married to JavaScript, really; we're married to "the DOM and css" as our gui, and things like FF/Chrome/Safari devtools to develop that gui. Most javascript developers are already using babel-et-al pipelines to build electron apps, which are already transpiling between major variants of javascript, and I wouldn't at all surprised to see a thing where it gets compiled into WebAssembly rather than interpreting javascript. I also think there's a thing, right now, where it's possible to build electron apps with Rust+WebASM; I'm not sure, but I think the main thrust here is it definitely would eliminate a huge chunk of the slowdown. I guess the main takeaway is just that the development revolution that's happened recently is mainly about how insanely good browser dev tools have become, and not about javascript - javascript was just along for the ride. As an aside - I recently saw a video of someone demoing one of the old Symbolics LISP workstations, and I was shocked to realize how much they had in common with a modern browser console - specifically of being able to inspect all of your gui components, live, and look at all the properties set on them. It's provided a hell of a way for me to explain what the deal was with all the old gurus in the 80s "AI Winter" diaspora who were pretty butthurt about having to move from programming in that environment, to having to write C on DOS (or whatever else paid the bills at the time).
    - xvilka 6y ago
      WebAssembly is just another JVM which is notoriously slow for GUI compared to the native alternatives like Qt.
  - rmorey 6y ago
    There basically already is in the M1: https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2 https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de... tl;dr it has really sick floating point double performance which directly translates to JS performance
- imwillofficial 6y ago
  Yep, see the success of the Nova editor.
  - Hamuko 6y ago
    It's a success?
    - imwillofficial 6y ago
      Yes
    - 1123581321 6y ago
      I don't know what qualifies as a success, but I saw in Git Tower's developer survey that it has about 5% share. The share of the whole developer industry should be lower, because Tower's audience is interested in premium tools, but I expected it to be struggling to break 1%. https://www.git-tower.com/blog/mac-dev-survey-2021-results https://www.git-tower.com/blog/mac-dev-survey-2021-results
  - homarp 6y ago
    discussion of Nova Editor: https://news.ycombinator.com/item?id=24495330 https://news.ycombinator.com/item?id=24495330
  - realityking 6y ago
    Funnily enough, I dropped it after the trial expired because the plug-ins - which I belobe are written in JavaScript - were incredibly unstable.

This is called "What Andy giveth, Bill taketh away."

by SSLy 6y ago

This is called "What Andy giveth, Bill taketh away."

and this is now called Electron trading speed of development with 'hardware optimization'. Mac being a small market, some users are still opiniated/loud enough to reward nicer/native UI vs cross-ish platform lowest common denominator UI. Maybe there is hope Arm mac stays fast.

mixmastamyk 6y ago
+ Mac OS checking every binary you run over the internet.
- walterbell 6y ago
  Pihole and others can block those Apple queries.
  - bonestamp2 6y ago
    What happens if you block them.. do they eventually stop working if they haven't been validated in a long time?
- Klonoar 6y ago
  It's slightly more nuanced than that - you can of course just block it from doing so, and there's certainly an argument for it being updated to not need a network call each time, but phrasing it like this makes it sound worse than it actually is. I'll just quote Jeff Johnson, who's looked into this and written about it - his comment[1] on this is post is quite useful: https://eclecticlight.co/2020/11/25/macos-has-checked-app-signatures-online-for-over-2-years/ https://eclecticlight.co/2020/11/25/macos-has-checked-app-si... >The request to http://crl.apple.com/root.crl http://crl.apple.com/root.crl is simply checking the revocation status of Apple’s own Developer ID Certification Authority intermediate signing certificate. If you examine the cert in the System Roots keychain, you can see that URL under CRL Distribution Points. This request contains no information specific to third-party developers or apps. In contrast, there’s no CRL for third-party Developer ID leaf certs signed by Apple’s intermediate cert. Their status is only available via OCSP. Notably, this: >This request contains no information specific to third-party developers or apps. https://eclecticlight.co/2020/11/25/macos-has-checked-app-signatures-online-for-over-2-years/#comment-53659 https://eclecticlight.co/2020/11/25/macos-has-checked-app-si...
  - mixmastamyk 6y ago
    You added detail, yet didn't refute the statement. That it isn't easy to simply and specifically turn off is not acceptable.
    - Klonoar 6y ago
      No, I'm fairly certain I refuted it. The parent comment is incorrectly stating that each request to Apple is checking a binary, and it's not. This has been well documented both here on HN and across the web.
      - mixmastamyk 6y ago
        That's not the definition of refute. The distinction between a lazy-implied always and merely often is pedantic. The point is that it happens enough to reduce performance, while doing something no end-user asked for and is difficult, if not impossible to disable without reducing other security protections.
        Klonoar 6y ago
        There is no measurable performance loss from that one time check - it's not something happening constantly.
whatever1 6y ago
I would say that 90% of my pc resources are consumed to execute JavaScript code. If we need dedicated hardware to execute this more efficiently so be it. We do it anyway for so many other domains. Video, graphics, encryption etc.
- deleted 6y ago
  [deleted]
- Jetrel 6y ago
  One of the big deals with electron-et-al is that we're not married to JavaScript, really; we're married to "the DOM and css" as our gui, and things like FF/Chrome/Safari devtools to develop that gui. Most javascript developers are already using babel-et-al pipelines to build electron apps, which are already transpiling between major variants of javascript, and I wouldn't at all surprised to see a thing where it gets compiled into WebAssembly rather than interpreting javascript. I also think there's a thing, right now, where it's possible to build electron apps with Rust+WebASM; I'm not sure, but I think the main thrust here is it definitely would eliminate a huge chunk of the slowdown. I guess the main takeaway is just that the development revolution that's happened recently is mainly about how insanely good browser dev tools have become, and not about javascript - javascript was just along for the ride. As an aside - I recently saw a video of someone demoing one of the old Symbolics LISP workstations, and I was shocked to realize how much they had in common with a modern browser console - specifically of being able to inspect all of your gui components, live, and look at all the properties set on them. It's provided a hell of a way for me to explain what the deal was with all the old gurus in the 80s "AI Winter" diaspora who were pretty butthurt about having to move from programming in that environment, to having to write C on DOS (or whatever else paid the bills at the time).
  - xvilka 6y ago
    WebAssembly is just another JVM which is notoriously slow for GUI compared to the native alternatives like Qt.
- rmorey 6y ago
  There basically already is in the M1: https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2 https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de... tl;dr it has really sick floating point double performance which directly translates to JS performance
imwillofficial 6y ago
Yep, see the success of the Nova editor.
- Hamuko 6y ago
  It's a success?
  - imwillofficial 6y ago
    Yes
  - 1123581321 6y ago
    I don't know what qualifies as a success, but I saw in Git Tower's developer survey that it has about 5% share. The share of the whole developer industry should be lower, because Tower's audience is interested in premium tools, but I expected it to be struggling to break 1%. https://www.git-tower.com/blog/mac-dev-survey-2021-results https://www.git-tower.com/blog/mac-dev-survey-2021-results
- homarp 6y ago
  discussion of Nova Editor: https://news.ycombinator.com/item?id=24495330 https://news.ycombinator.com/item?id=24495330
- realityking 6y ago
  Funnily enough, I dropped it after the trial expired because the plug-ins - which I belobe are written in JavaScript - were incredibly unstable.