M1 Mac

[bodohinz]

Can I use it on a M1 Mac?

[tasn]

Not with the pre-built binaries (not yet anyway).

[Zvezdin]

I'd love to see an M1 mac build

[tasn]

Yeah, it would be great. I just need help with adding the github action. I dunno if that's supported for ARM yet on github actions.

[hectour3]

Just started using Etesync and I have an M1 Mac. It seems to work good at first sight through Rosetta 2.

An M1 Mac prompts you to install Rosetta the first time you want to run something that is built for x86. When you install Rosetta you can't uninstall it anymore unless you do a complete factory reset of your Mac. For users who would otherwise not have to use Rosetta (which is more and more the case since a majority of Mac software has been ported for M1 at this point) a native build would be really nice as not installing Rosetta would reduce your attack surface a lot by not being able to run x86 code.

[hectour3]

Unfortunately it does not seem to work anymore after a reboot

EDIT: it seems to work fine now after reinstalling. Don't know what went wrong/

[Zvezdin]

Can't confirm - have it working fine on my end with Rosetta 2, just a resource hog.

[tasn]

How bad of a resource hog?

As for a native build: defo, we just need to have CI that supports build on the M1. I think we use github actions and M1 isn't supported yet?

[Zvezdin]

It seems like we'll be waiting for a while for that. Are there any alternative CIs you could use?

[hectour3]

Would it also not be possible to just release it as a regular Mac app with code signing? That way MacOS would not block the app on launch and then require you to explicitly grand permission to open the app in the security settings. That is what threw me off the first time trying Etesync. It might also make it possible for the app to make use of the MacOS sandbox for better security, and building the app for M1 might be easier too. It would be possible to release the app as one single universal binary so that it can run natively both on Intel Macs and M1 Macs.

[hectour3]

I found out that the iPad app is available from the App Store to download on M1 Macs. I tried it and the setup works flawlessly by giving the app access to Calendar, Reminders and Contacts. All the data is downloaded to the clients very fast without any problems. The only problem is that the app crashes when trying to sync manually after the setup. If this is a small problem that can be overcome easily then this would be a very user friendly option to run Etesync on arm Macs in my opinion. If the developer is interested I can give a crash report.

[pseacrest]

How did you get it to work, I keep getting

Calendar: failed to find selected source 5DE3C489-C881-XXXXXX. Please contact developers.

I found out that the iPad app is available from the App Store to download on M1 Macs. I tried it and the setup works flawlessly by giving the app access to Calendar, Reminders and Contacts. All the data is downloaded to the clients very fast without any problems. The only problem is that the app crashes when trying to sync manually after the setup. If this is a small problem that can be overcome easily then this would be a very user friendly option to run Etesync on arm Macs in my opinion. If the developer is interested I can give a crash report.

[pseacrest]

How did you get it to work, I keep getting

Calendar: failed to find selected source 5DE3C489-C881-XXXXXX. Please contact developers.

I found out that the iPad app is available from the App Store to download on M1 Macs. I tried it and the setup works flawlessly by giving the app access to Calendar, Reminders and Contacts. All the data is downloaded to the clients very fast without any problems. The only problem is that the app crashes when trying to sync manually after the setup. If this is a small problem that can be overcome easily then this would be a very user friendly option to run Etesync on arm Macs in my opinion. If the developer is interested I can give a crash report.

Solved it myself by deleting said calendar and adding it a new

[benjaminrwilson]

@tasn, what changes would you recommend to build etesync-dav against osx-arm64?

[Zvezdin]

Hey @tasn, would github actions happen to support arm now?

[foliovision]

I'd love to see an M1 build for Apple Silicon Macs, as most of the time eteSync is the only Intel/Rosetta 2 application I have running. Just having Rosetta 2 open ties up memory and slows down an M1 Mac.

[tasn]

@Zvezdin, I don't think they do, no. :(

@foliovision, @benjaminrwilson: there are no changes needed on our end at all, it's just a matter of adding a CI task. Additionally, etesync-dav is just Python. If you don't care about having a pre-built binary, and are OK with running Python code you can already run it on an M1 mac without Rosetta or anything.

[hectour3]

I have been using the iOS app on my Mac for a day now again and it seems to work fine. I don't know what caused the error when I first tried it. I actually like it more than the bridge because the bridge was quite buggy for me (sometimes not syncing things properly) and I like to be able to access my data within the app.

EDIT: the error has returned just after I wrote this :( The app crashes when trying to sync. The issue only seems to be related to calendar. After I remove those from Etesync reminders still sync fine.

[foliovision]

If you don't care about having a pre-built binary, and are OK with running Python code you can already run it on an M1 mac without Rosetta or anything.

Thanks @tasn very much for the suggestion. I can of course set up Python and set up a cron for eteSync. But as I'm paying (or will be paying) $24/year for privilege of access to eteSync, I don't want to have to think a lot about the internal workings of eteSync and maintaining it myself.

I.e. those of us on M1 Macs (and there will only be more of us, as many existing eteSync users migrate over to Apple Silicon: normally I'm not excited about new computers, before the M1 Max I was running 2009 Mac Pros and 2011 MBP 17" but these Apple Silicon MBP are finally silent, the Apple Studio is not, it has a constant fan running like an iMac) would like to have a pre-built binary which just works.

[tasn]

I understand @foliovision, I'd like to have it too. It's Github not having ARM build runners, not us being lazy.

[foliovision]

@tasn Tom, there has to be another way to build and attach M1 binaries. Most of the other open source or shareware projects that I either sponsor or license have M1 binaries. A difficult issue with programmers is that you assume that it's fair to outsource your work onto the user, instead of just providing working binaries which would save thousands of people from having to build such binaries themselves. Make users lives easier.

This is a different issue btw from building websites for instance, where the work is done better if it's not done in a page builder and the designer/site owner learn to write minimalist semantic code. The binary is the binary. There's little point in my learning to build binaries for the dozens of open source apps I use. It's just more admin work. And time is short as is.

Do you see some money from a subscription to eteSync hosting or are you a separate project/entity?

[AlecKinnear]

This is Foliovision back, except on my personal account, as Alec Kinnear.

Since there's no ARM binary and eteSync runs constantly in the background (which means Rosetta2 has to run continuously wasting precious memory), I'm giving up testing eteSync and won't be subscribing. I'll have to go and make sure I haven't been billed now.

A real pity. eteSync is a great project, if you would support your users platforms with native versions. Let me know if you ever change this @tasn.

[tasn]

Thanks for the feedback @AlecKinnear, hopefully we get it sorted at some point.

[tasn]

@tasn Tom, there has to be another way to build and attach M1 binaries. Most of the other open source or shareware projects that I either sponsor or license have M1 binaries. A difficult issue with programmers is that you assume that it's fair to outsource your work onto the user, instead of just providing working binaries which would save thousands of people from having to build such binaries themselves. Make users lives easier.

I've been toiling on this open source project away for years to make privacy and security better for everyone. Blaming me for not immediately jumping to support a platform I don't even have access to, when there are alternatives (Rosetta 2) available is just unfair. In a perfect world I'd have everything implemented for everyone immediately as they want it, but I can't do everything. I've been focusing on improvements to the server and infrastructure recently, and that's been taking my time.

It's open source though, everyone can change, improve, remix, and rebuild as they see fit. I'm not trying to push work to the user by saying this, I'm literally just pointing out the benefits of having all of the code open source. The reason why you think programmers "assume it's fair to outsource your work onto the user", is because when you interact with programmers directly (rather than marketing/sales/whatever) it's with open source projects that actually ENABLE YOU to do all of that. If open source projects had sales people, you'd have heard them saying the same.

In short: I'm not trying to get users to do extra work, and again, if you've solved it and you think you have a solution that could benefit everyone, please share it. If you haven't, give us the benefit of the doubt and assume it's just a bit more work than you think it is.

[AlecKinnear]

@tasn I'm not asking for customisation or anything extraordinary. Apple M1 computers represent a large and growing market share. In particular people who owns these computers are those who will pay for software.

I'm not sure why it's so difficult for you to create binaries for M1 computers. Running Rosetta 2 in the background slows downs the computer and ties up a large amount of memory, just like running any VM within an OS.

As I said before, I'd like to sign up for the paid service of etedav but won't do it unless there's a binary for M1. You'd do better to just ask for a donation or something. I regularly donate to open source projects. We participate in open source projects which are primarily PHP or javascript based as that's where our expertise is. Rolling my own for etedav would be a real distraction.

@tasn This attitude of pushing the work back at the user doesn't really work for hybrid open-source/commercial projects. You do have a paid service so it should be in your interest to add more paid users.

---

For those considering using etedav on an M1 Mac, don't do it until there's a proper binary. The etedav binary runs 24/7 so it's not something you want to have on Rosetta as it means you can never bring your M1 down to native apps only and Rosetta will always be running even when you are video editing, composing audio or doing large photo edits, slowing down your M1 and giving little IO hiccups when your creative app is running hard.

[AlecKinnear]

For those still struggling with an M1 Mac native solution, I found one which works, albeit it requires third-party software as the contacts client on macOS.

NextCloud will work with:

1. iOS devices Calendar and Contacts
2. BusyContacts ($30 with cross-grade, easy enough)
3. Thunderbird CardDAV (v.90+) (free)

BusyContacts is great for quickly cleaning up contacts.

NextCloud CardDAV will not work with macOS Contacts. NextCloud CalDAV does work with macOS Calendar.

Advantage over eteSync: it's possible to share address books with other users in NextCloud.

Disadvantage: field labels are mangled by VCF export/import. eteSync doesn't mangle them. eteSync is also more reliable. When multiple changes collide on NextCloud with changes coming from two sources at the same time, NextCloud just prefers one whole set of changes instead of merging the changes. When the changes happen one at a time with no overlap in checkin/checkout, NextCloud seems to do just fine.

[Brog33]

Any news regarding an apple silicon build?

[AlecKinnear]

@Brog33 Sadly, the release binary has not been touched since December 2021.

Just circling around myself to see if I can/should subscribe to ete-dav. How many years of subscription has @tasn already given up by neglecting to create an M1 binary for ete-dav? It's a real pity. Open Source software is amazing and so are the people who make it. Unfortunately their stubbornness in not supporting users' platforms or enabling simple core features (CSV export for instance, insisting on .vcf as it's modern, hello @fruux) is their fatal weakness. This leaves commercial software more or less the entire field. In the case of ete-sync, it leaves spyware (Google, Apple, Microsoft) in control of the field.

For our own open-source projects, I offer those who request features not on the current immediate roadmap the opportunity to sponsor the new feature (partly as a test to see if people really want the feature instead and aren't just making noise).

[Zvezdin]

I'd pledge $10 if it helps getting this prioritised :). I'm a longtime user of @tasn's work and I appreciate the huge effort he's spent on impacting privacy. I understand that open source is a collaborative effort (with time or resources), so I am happy to put up a tip if it moves the needle. Really don't want to move to a less specialised solution such as Nextcloud, but etesync's the only thing running on rosetta on my mac.