zendnez

Members
  • Posts

    9
  • Joined

  • Last visited

Posts posted by zendnez

  1. I started a thread here in November of last year asking about explicit support for M1 Macs. Everyone on this thread is already well aware that we haven't seen or heard anything since that time.

    In fact, the last Mac release (2.72) was motivated by another Mac issue I reported which made it impossible to sync a Photos Library on Big Sur.

    Resilio continues to function on M1 Macs but it stands out as a high consumer of both CPU and battery. I rarely see it drop below 4% CPU, and it's often using much more CPU than that. This is when there is no disk activity whatsoever in any of the folders that it syncs (on the local or remote machines). At least according to Activity Monitor, the only process that provides any real competition for energy consumption is Time Machine.

    There are a couple of other bugs/issues that I consistently run into but it doesn't seem worthwhile to report them.

    We can speculate on why Resilio seems to have become abandonware - lack of market opportunity / support, focus on other products, legitimate and sincerely awful geopolitical issues - but unless someone knows otherwise, it's just speculation. With respect to Mac software, we're now seeing the second generation of M1 devices hit the market and there is obviously no going back. Resilio needs to see some M1 love in the form of a focus on CPU and energy use reduction. My guess - which is reasonably informed - is that the shortest path to that outcome is a native ARM build, but I think there's work left to do around change detection, too.

    The original poster asked "Should I pay?" Frankly, a Resilio license is a good deal and it's a great product. But it seems possible that we are never going to see another release. So the decision to buy a license surely is not an easy one.

  2.  

    7 hours ago, AntoineJ said:

    ....if Resilio became yet another abandonware. 

    You're being generous when you speak about this as an event that might occur. It's not clear that it hasn't happened already.

    Resilio is a great product but the prosumer/hobbyist niche that it fits into must be small and it's possible there's not enough market demand to generate the volume necessary to fund support and development.

  3. @jdrch - I don't understand what horse you have I this race but you are digging in on mis-informative posts.

    I started this thread with the intent of asking about the timeline for an M1 build. Your suggestion to run the iOS build isn't helpful. Not only is such an option not available (Resilio hasn't published a Catalyst based build to the App Store) but it's just not going to behave the right way. So please stop promoting the notion that it's an option. It's not.

    As @muse points out above, the few diagnostics we have to help us understand how the Intel / Rosetta version runs suggest that there is room for improvement. Batter consistently lists Resilio (and often only Resilio) as the significant user of energy on my Air even when no inbound or outbound sync is occurring. Activity monitor similarly shows Resilio using significant energy. Compared to other sync apps such as DropBox or OneDrive, Resilio has always run hot. But this behavior - just anecdotally and without the tools to truly understand - looks worse. It's easy to guess that whatever combination of polling and file system notifications are being used is hitting longer, more expensive codepaths due to Rosetta.

    I see Resilio consume a constant 5.0+% CPU (assume that means a core) is pretty unexpected. I'm running the M1 targeted version of Outlook (a beta) and even that app stays at a pretty constant 0.5%.

    I do hope to see some comment or progress on this from Resilio. BTW - I am a paying (and generally very happy) customer.

     

    260364065_ScreenShot2020-12-06at3_07_37PM.png.083be64cd662206040c3833117494a5d.png266912501_ScreenShot2020-12-06at3_09_15PM.thumb.png.179ff2a0dd1563dd7b8663c7aa1a56be.png

     

  4. 12 minutes ago, Nick Artman said:

    +1 on this.  Apple's adoption of the ARM based processor will only increase and will need addressed at some point.  I am not familiar with the frameworks involved, however is this something that will require a ground-up rebuild, or just a recompile?

    They need to build a Universal Binary using Xcode 12. So, minimally, an Xcode update, build config changes, and a recompile. Could be more complex depending on their dependencies, how many binaries they produce, any x64-specific hand-coded optimizations.

    Essentially, though, it's this: https://developer.apple.com/documentation/xcode/building_a_universal_macos_binary

  5. Thanks for the response. I addition to the outstanding question about if/when we can anticipate a universal binary from Resilio, you bring up a bunch of fun topics.

    The comparisons to WOW/Wow64 aren't quite accurate, though they did both address a similar scenario in which an operating system and/or processor architecture evolved and app compatibility was maintained. WOW/WOW64 were thin layers that did things like shim OS API calls, fiddle without pointers, and flip the OS (in some cases) between 32-bit and 64-bit mode since X64 processors were designed with that capability.

    Rosetta 2 is different. It derives from the earlier instance of Rosetta which facilitated Apple's processor transition from PowerPC to x64. Rosetta was at least partially informed by the work Apple did to transition from Motorola 68k to IBM PowerPC. Back when that happened in the mid 90's, none of us thought it would work but Apple pulled it off. Initially with a very brute force emulation strategy (emulating not just 3rd party code but large portions of MacOS itself) and, not long after, with their "dynamic recompilation" emulator which seemed like total science fiction to most of the industry. If you're looking for a fun history lesson, take a peek at https://en.wikipedia.org/wiki/Dynamic_recompilation. In other words, it's not about supporting the evolution of an architecture, it's about getting code to run on a completely different architecture. I don't know the extent to which it does this via one-time recompilation (and caching on disk) versus runtime translation versus a combination of both (which I think is probably closer to the truth).

    I haven't checked to see if the iOS app for Resilio is available in the MacOS app store. Unless they actively blocked it, my understanding is that it will be. But I don't think it's a legitimate alternative to the MacOS version - iOS apps run as sandboxed on MacOS as they do on iOS. I suspect it'll sync a file structure in its own sandbox which isn't really what we need.

    Emulation is awesome. It gets stuff running. I have a new MacBook Air and I can attest that the early reports about its performance are spot on including native and emulated code. I don't have enough time with it to state with confidence that the emulated Resilio app works flawlessly. Microsoft had to ship an update to Office just to get it to work. Google had to ship Chrome for the same reason. Microsoft's Edge beta channel works, the release channel doesn't. The issues that apps have won't necessarily prevent launch - they can cause other issues. So, minimally, it's worth it for every software vendor to vet compatibility, update if necessary, and share longer term support plans.

    Anyhow, fun conversation and the kind of thing that would likely be even more fun to chat about over a beer. At some point, I'd still love to hear from Resilio on their thoughts and plans!

     

  6. 54 minutes ago, jdrch said:

    M1 Macs run x86 code just fine transparently via Rosetta 2 with very little performance penalty (or at least none that you'd notice in an app like Resilio Sync.) So just what's already there.

    I'm not clear if you are representing Resilio on this or just sharing an opinion. Can you clarify, please?

    We don't yet have clear benchmarks regarding battery consumption of emulated apps vs native apps. On my machines, Resilio tends to use a consistent 0.7% CPU. That's not a huge amount and I'm not in a position to claim definitively that a native app will use less, but power management is certainly one of the reasons that apps will go native over time.

    In any case, I'd love to hear from the source.

  7. I've pretty conclusively determined that @davidmarshalljr is close to correct about the issue he's reporting.

    This capability broke with the 2.7 release. The difference in security bits between 2.64 and 2.7 is that the "Hardened" bit has been set in the 2.7 release.

    With 2.64, when I attempt to set up Resilio to sync a Pictures library on a clean install, I'm prompted to grant Resilio access to Photos (by MacOS). Once permission is granted, Resilio works fine.

    With 2.7 on a clean install, no prompt is seen and Resilio starts spewing permissions errors into its Activity history.

    I have a colleague who upgraded from 2.64 -> 2.7 and did not have issues. I'm assuming that this is because Resilio was previously granted rights to Photos.

    The outcome of the permissions grant is clear. If granted correctly, Resilio will show up as having access to Photos under the Photos tab of the Security and Privacy preferences pane. If 2.7 is the first version of the software used, this will never happen.

    @davidmarshalljr - if you can get ahold of a 2.64 dmg, you can get moving. Otherwise, you'll have to wait for an update.