@Noremak Also surprisingly producing some music in the past also helped because also in that you tend deduce stuff from frequency distributions. And also I've written a couples of 3D engines in the past, which has helped a lot understanding unit transformations :-) Enjoyed so far because I really need to stretch all my experience to get shit together in my head (and without being a physician).

Just sharing my experiences for anyone who might give a shot in this area. The mindset with semiconductors is computing. The mindset with quantum IMHO is observation (when put to a single word).

@Noremak I still know nothing about physics but that was the whole point of this learning experiment because in the end of the day it must detach out of physics literature in order to be successful. Early days of semiconductor programming was also more tied to the physics so I expect similar development here.

I've studied algebra and discrete math so I know the binary side, and also vector analysis and linear algebra a bit, so combining that knowledge and thinking superposition states as base transformations helped a lot to cope the topic. It is a game of unit vector spaces with complex factors or that is how I see it like for a regular programmer (like me).

@Noremak My high school friend is one of the founders of a quantum computer company called IQM: https://www.meetiqm.com/. He is quantum computing professor at Aalto University in Helsinki.

https://www.youtube.com/watch?v=m0GqCxMmyF4

Here’s my #mbsync #GCC workaround for #Fedora:

commit ebf6bcea7ebdba15553692777d292e59ec1d5e2e (HEAD -> master)
Author: Jarkko Sakkinen <jarkko@kernel.org>
Date:   Thu Aug 1 21:36:37 2024 +0300

    work around a GCC-14 optimizer issue
    
    mbsync throws SIGSEGV in sync_opened(). As it turns out for some
    reason the second entry in the local array 'boxes' is optimized
    out:
    
    (gdb) print boxes
    $1 = {0x5555556c4540, <optimized out>}
    
    Fix this by pinning the variable using a dummy inline assembly
    statement:
    
    __asm__ __volatile__("" :: "m" (boxes));
    
    This sets an invariant, which should guarantee that the compiler
    leaves 'boxes' untouched.
    
    As a comparative measure mbsync was compiled also with clang without the
    fix, and the resulting ELF binary does not have this issue.
    
    Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2302132
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

diff --git a/src/main_sync.c b/src/main_sync.c
index 226e324..afb23ca 100644
--- a/src/main_sync.c
+++ b/src/main_sync.c
@@ -623,6 +623,7 @@ sync_opened( main_vars_t *mvars, int t )
        if (!mvars->chanptr->boxlist && mvars->chan->patterns) {
                mvars->chanptr->boxlist = 2;
                char **boxes[2];
+               __asm__ __volatile__("" :: "m" (boxes));
                boxes[F] = filter_boxes( mvars->boxes[F], mvars->chan->boxes[F], mvars->chan->patterns );
                boxes[N] = filter_boxes( mvars->boxes[N], mvars->chan->boxes[N], mvars->chan->patterns );
                box_ent_t **mboxapp = &mvars->chanptr->boxes;

Also attached to https://bugzilla.redhat.com/show_bug.cgi?id=2302132

@adamw @gromit I compiled mbsync from upstream without my workaround using clang, and that version works also without glitches, so I'm pretty sure that this might be an actual GCC 14 bug..

@adamw @gromit It totally works now. Creative workarounds...

(gdb) print boxes
$1 = {0x5555556c4540, <optimized out>}

I noticed this so I tried:

diff --git a/src/main_sync.c b/src/main_sync.c
index 226e324..afb23ca 100644
--- a/src/main_sync.c
+++ b/src/main_sync.c
@@ -623,6 +623,7 @@ sync_opened( main_vars_t *mvars, int t )
if (!mvars->chanptr->boxlist && mvars->chan->patterns) {
mvars->chanptr->boxlist = 2;
char **boxes[2];
+ __asm__ __volatile__("" :: "m" (boxes));
boxes[F] = filter_boxes( mvars->boxes[F], mvars->chan->boxes[F], mvars->chan->patterns );
boxes[N] = filter_boxes( mvars->boxes[N], mvars->chan->boxes[N], mvars->chan->patterns );
box_ent_t **mboxapp = &mvars->chanptr->boxes;

That literally fixed the bug! I.e. could this be a #GCC bug?

RT @gromit, @adamw

#mbsync #gcc #fedora #bug #isync

When using #m2sync, compared to #mbsync, you need to use "maildirpp:" instead of maildir "maildir:".

Just though to mention since I was puzzling around this for few hours, and wondering why #notmuch finds everything, and aerc finds nothing.

EDIT: Had some issues with this but it seems interesting and relevant so I keep tracking this project. Now I at least got the mbsync bug fixed in Fedora.

@vathpela I just learned Shor's algorithm i.e. total newbie, and still have all kinds of crazy ideas (most of which are probably horribly wrong) ;-) Still excited that I could cope at least the basics.

@vathpela Yeah, right semiconductor CPU's used to be like 10-15 years of the current state of art.

To understand quantum, one needs to not think e.g. a cooking recipes, like in procedural programming.

Instead a closer ever day example for their programming model could be tuning a Swiss pocket watch, or understanding that it detail.

Near 0 K is required for super position states, which are distributions on a unit surface.

QPU's do not compute, they get results by deducing from multiple qubits in superposition. They work exactly and precisely as a natural phenomenon that distributes to the tuned environment.

I wonder if quantum computers were better off deployed to space.

I mean it is colder out the so it should take less energy to cool down to near 0 Kelvin.

All kinds of cargo and even space tourists are going to space anyway so that is not as high coast when amortized, as are the operating costs.

#quantum #computing

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!

I realized that despite #mbsync crashing in #Fedora I could use #rsync as a backup because I have also SSH shell to my Maildir.

So I give a shot for that, i.e. ssh+rsync, but over longer period of time, I still would prefer to use mbsync. Anyway, it is a workaround.

https://www.upwork.com/research/ai-enhanced-work-models

systemd timers are factors better than cron for periodic stuff *during the session*, such as GIO mounts and mbsync. Outside the session the user timers simply are not there, which actually makes them also more secure than having cron jobs. My fav feature in systemd so far.

My complete systemd experience enlisted:

1. systemctl start/stop/restart/status
2. man journalctl && journalctl blabalbaa (always forget how it was used for some reason)
3. systemd timers (wrote this down so that I will forget it: https://jarkko.codeberg.page/2024/07/11/unprivileged-systemd-timers.html).

#coredumpctl is pretty cool! I tried it first time yesterday while debugging a SIGSEGV issue with mbsync (aka isync, I hate this name ambiguity) in #Fedora.

I'm surprised that mbsync segfaults with Fedora 40 given despite being niche it is a popular choice among kernel developers.

EDIT: s/journalctl/coredumpctl/ ;-)

#linux #gdb #systemd