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

I say this out loud: I love MS-DOS. I've written some protected mode extender stuff to run in #86box and it is incredibly fun environment to play. Maybe some day put something out but I want to fix my MZ EXE compilation pipeline first ;-)

I got this idea already in 2012 that it would be fun to do DOS stuff when I worked on arch/x86/realmode blob. With those learnings I have now a working .COM pipeline.

#dos #msdos #programming

Might sound contradicting but both best use of Rust I've seen and worth of investment to use its complex type system is stuff that processes fuzzy or somehow stochastic data.

There you want to hit all inconsistencies and corner cases. Scripting languages allow to easily quickly address such data but it leaks ;-) Strong typing system and refining that more robust over time is a better long-term investment.

#rust #rustlang

More that I #cook and #bake myself, a better #programmer I also feel ;-) Somehow it puts your mind into the right place.

Has anyone in #Mastodon took away knobs (not the plastic hats) from #1010music #Bluebox?

I took away the back cover and plastic hats but I have no idea how to take away the knobs so that I could take away also the front cover.

The goal here is to switch a replacement display panel.

https://1010music.com/product/bluebox

I like a lot #BabyAudio's BA-1 and also the effect rack version. Superb sound.

Lot's of stuff that I really need to take over the weekend:

1. mbsync bug in fedora
2. address a question in rust-vmm/vm-memory Github issue.
3. address a question m4b/goblin Github issue.

Mostly because my shit kept piling up given the first issue ;-) Should not work over weekends but I really want this table to be cleaned up by Monday.

@rjzak: So I'm actively researching feasibility of vm-memory.

Post-Profian I think it would be best for Enarx if as much as possible is done by external crates not maintained by the project. It makes it less stressing to maintaiin and also lowers the barrier to contribute (given the familiar idioms from other Rust projects).

This is why I'm doing this...

Time to prepare some pie!

LOL, I have work interview every single working day next week, and some after that. This will be exhausting.

I guess it is time to look back into #TPM2 #asymmetric #keys series. I did latest version of the series in Apr/May.

My wild guess is that it won't work and I have no idea WHY. At least for me this happens on patch series that i don't work on for some months. Then after debugging and cursing for a day or two find a missing CONFIG_ flag or similar ;-)

#Linux #kernel #hacking

I've seldomly tried #Rizin over the years but only after I switched to #Fedora early this year, I've really got into using it.

The stack is pretty well packaged, including #Cutter, in Fedora, which lowered the barrier. I hate to self-compile, everything must be low-hanging fruit unless I'm actually doing paid work :-)

I've also played with #Ghidra but the problem is that it does not fit to my workflow as well where everything else is a command-line tool.
But since I learned that I can use Ghidra's decompiler Rizin I get best possible reverse engineering for *my personal needs*. Also, one big thing in Rizin is out-of-the box RISC-V support.

I've also got into developing some tools with libcapstone disassembler Rust bindings, and a crate called Goblin. My ultimate goal here would be to automate the way i do analysis for kernel oops without using anything from scripts/, addr2line, gdb or objdump. Rizin is a great prototyping tool because it is also based on libcapstone.

For great tutorials on Rizin, I can warmly recommend this YouTube channel:

https://www.youtube.com/@ConsoleCowboys

Tutorials are for #Radare2 but they apply equally to Rizin.

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