Conversation
Jarkko Sakkinen
jarkko
I found a modern actively updated alternative for #isync (or #mbsync): #m2sync
It is part of #vomit project: https://sr.ht/~bitfehler/vomit/
Compared to the complexity of ~/.mbsyncrc, my config is now dead simple:
cat .config/vomit/config.toml
[kapsi]
local = "~/.cache/mail/kapsi"
remote = "mail.kapsi.fi:993"
user = "jjs"
pass-cmd = "pass show imap/mail.kapsi.fi"
I love vomit!
1
0
2
@vbabka after some testing and "unfixing" mbsync bug [1] I don't think it is yet ready for production use but sure going to try the latest main every once in a while and might even fix a bug or something.
Normally I hate the whole "Rust fork scene" but in the case of IMAP sync there would be really an actual need for a modern robust alternative. Maybe even something that would handle both IMAP and EWS in the same package. And also email is somewhat fuzzy data to make deductions of so a strong type system can actually make a difference here.
[1] https://social.kernel.org/notice/AkX1oAnWFMXja3uN84
Normally I hate the whole "Rust fork scene" but in the case of IMAP sync there would be really an actual need for a modern robust alternative. Maybe even something that would handle both IMAP and EWS in the same package. And also email is somewhat fuzzy data to make deductions of so a strong type system can actually make a difference here.
[1] https://social.kernel.org/notice/AkX1oAnWFMXja3uN84
1
0
1
Jarkko Sakkinen
jarkko
0
0
1
Jarkko Sakkinen
jarkko
@oleksandr @gromit @vbabka I'll put that to the same queue as compiler flags. Thank you!
Cannot say anything before testing the patch because Murphy's law clearly states if you judge without testing you always get it wrong ;-)
Cannot say anything before testing the patch because Murphy's law clearly states if you judge without testing you always get it wrong ;-)
0
0
1
Christian Heusel
gromit@chaos.social@jarkko @oleksandr @vbabka So any new ideas about the issue/fixes?
1
0
0
Jarkko Sakkinen
jarkko
@oleksandr @gromit @vbabka I made my own independent fork that I use from now on ;-) mbsync should almost never change to anything, and it is only 15 KSLOC program.
I have some ideas how to modernize it too a bit (to make it easier to maintain) so might work on that too. Got familiar with the code base thanks this bug.
I have some ideas how to modernize it too a bit (to make it easier to maintain) so might work on that too. Got familiar with the code base thanks this bug.
1
0
0
@oleksandr @gromit @vbabka I'm looking into how I could possibly make it compile Zig by stealing ideas from https://dev.yorhel.nl/ncdu, which did such conversion (used to be a C project). If a few core data structures were a bit more robust and safe that would make a difference (but since zig is very interoperable with C no need to turn all things around).
I.e. first just replace main.c with with main.zig, autotools with build.zig and rewrite perl generator scripts in zig but no other changes. That makes it easier compilation job at least ("./autogen.sh && ./configure && ./make" vs "zig build"). And rename the program as "zmbsync" so that it does not name conflict with the Fedora package.
I.e. first just replace main.c with with main.zig, autotools with build.zig and rewrite perl generator scripts in zig but no other changes. That makes it easier compilation job at least ("./autogen.sh && ./configure && ./make" vs "zig build"). And rename the program as "zmbsync" so that it does not name conflict with the Fedora package.
0
0
0