https://servo.org/blog/2024/07/31/this-month-in-servo/

A wrote a book on how debuggers work!

It guides you through writing a complete native debugger from scratch.

Available Spring 2025 from @nostarch (probably not with this cover)

One add to #C 's memory safety is that you can almost decompile it in your head so that it is trivial to map even raw binary to meaningful language statements. I like that Ghidra and Rizin have decompilers but I almost never use them because I do not NEED them for anything. Especially since the return of frame pointers assembly simple and awesome again.

Also reviewing C code is factors easier than any other programming language I'm aware or because you don't have to guess how statements translate.

In most more modern systems you really have to do research sometimes because of unnecessarily complex language constructs and vast amount of generated code, meaning that there are filters obfuscating how the final machine language code is generated.

Finally, like with any software, more complex shit you produce, more likely you are gong to hit to bugs. This applies also to GCC and LLVM.

What is a Rust crate that could handle also cache directory, not just config (i.e. #confy like), which is pointed XDG_CACHE_HOME in Linux and in macOS it exists in Library/Caches?

#rust #rustlang

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

One critical angle towards #AI from my side is that software engineering is not about producing code.

Even if I wrote all my code in Notepad and slowed my productivity down on purpose let's say to 10%, it would not affect much to my ability to deliver all that much.

The thing is that analysis is the key with minimum amount of false positives, and AI is not an #algorithm.

learning #cutter with trivial crackme's #rizin

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

(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.

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

#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

#Gmail is my #landfill.

I prefer to register web crap there because then I don't have to spend my #email time on unsubscribing the silly notifications that they keep sending.

Then I go there every six months or so and delete All Mail because garbage is all it contains.

#subscription #lifehack

The dedicated slab buckets series by @kees has been merged into 6.11.

This change allows putting chosen dynamically-sized slab allocations into separate caches instead of generic kmalloc ones.

Patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b32801d1255be1da62ea8134df3ed9f3331fba12
@LWN's overview: https://lwn.net/Articles/965837/

So far, only msg_msg [1] and memdup [2] allocations got their own buckets.

1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=734bbc1c97ea7e46e0e53b087de16c87c03bd65f
2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d73778e4b86755d527a0c6b249cde846770b2f66

this is almost like art https://computernewb.com/vncresolver/browse/#id/43056785

IP Address: 108.165.96.183
Port: 5900
Location: Boca Raton, Florida 🇺🇸
ASN: AS398395 Dot-Tech LLC
Client Name: wimpywoodpeck
Hostname: None
ComputerNewb ID: 51606348
https://computernewb.com/vncresolver/browse/#id/51606348