Now that I leaned to use Goblin with Mach-O binaries, and how I find my way to symbol address through those ways, I think as next step I'll write a my-purposes-only disassembler using Goblin and Capstone's #Rust bindings.

I have sort of this fuzzy big picture in my head what I might want to do with that and perhaps with using Aya EBPF sheanigans but have to do bunch or trials and errors first

Sort of interesting territory experiment anyhow despite successes and failures. Generally I'm more interested on Rust when it comes to kernel what can be done in QA side from user space than kernel code per se.

🤷

This was my "hello world" for binary analysis with Rust https://jarkko.codeberg.page/2024/07/13/binary-parsing-with-goblin.html

For better or worse very C-programmer alike Rust code :-) You can still read it without knowing anything about Rust.

@aks No and I hate learning new languages tbh :-) Latest I've learned before Rust was Python in 2005. Rust is sort of more "have to deal with" than whether it is in my own preferences,

@aks Because we have to deal with Rust in any case I'm just trying to make best of it I guess 🤷 So it is like "C++ thing" for me I guess. It is sort of like best practices modern C++ enforced by the compiler with a new syntax, isn't it?

@aks Stuff that Ueber has done with Zig is amazing tho. This is not the same that I would disagree with the "Rust-decision", just saying that it is now industry-proven tool. I consider Ueber as "industry-proven" in this context.

@aks It is actually a problem with many new comers to software industry. Always looking for better tools, and not enough focus on solving the *actual* problem, no matter what the tools or languages are :-)

Like CoPilot writing your Rust syntax shenanigans for you because it is too terrible mess for a humanbeing to write it by hand, is IMHO a "cult classic" of moden software development.

@jarkko i agree with you there, although sometimes exploring what different style of programming languages can offer is pretty fun (at least to me)

@aks I’ve actually quite excited on getting back to vim from neovim but have done also some experiments like this Haskell one from 2010-11. Let’s just say that I did not pursue a career as a Haskell programmer after this ;-)

Looking back 2D maze is actually pretty good test probe for any language. It has a algorithm, I/O and graphics so it gives me fairly good evaluation how much I like or dislike a language :-)

module Maze where

import Control.Monad
import Foreign
import qualified Graphics.UI.SDL as SDL
import System.Random
import Data.List
import Data.Array

data Cell = Cell {
    top :: Bool,
    left :: Bool,
    visited :: Bool
} deriving (Show, Eq)

type Maze = Array (Int, Int) Cell

newCell = Cell {top = True, left = True, visited = False}

newMaze :: Int -> Int -> Maze
newMaze rows columns = listArray ((0, 0), (rows - 1, columns - 1)) (repeat newCell)

genMaze maze (r, c) (seed:seeds)
    | visited (maze ! (r, c)) == True = maze
    | otherwise = foldl traverse maze' ((permutations neighbours) !! index)
    where maze' = maze//[((r, c), (maze ! (r, c)) { visited = True })]
          locs = [(r - 1, c), (r + 1, c), (r, c - 1), (r, c + 1)]
          ((_, _), (rmax, cmax)) = (bounds maze)
          neighbours = [(r', c') | (r', c') <- locs,
                        r' >= 0 && r' <= rmax, c' >= 0 &&  c' <= cmax]
          index = seed `mod` (length neighbours)
          moveTo maze (r, c) (r', c')
              | visited cell'  = maze
              | r' < r = maze//[((r, c), cell { top = False })]
              | r' > r = maze//[((r', c'), cell' { top = False })]
              | c' < c = maze//[((r, c), cell { left = False })]
              | c' > c = maze//[((r', c'), cell' { left = False })]
              | otherwise = error "Invalid move"
              where cell = maze ! (r, c)
                    cell' = maze ! (r', c')
          traverse maze' (r', c') = genMaze (moveTo maze' (r, c) (r', c')) (r', c') seeds

hline :: Int -> Int -> Int -> SDL.Pixel -> SDL.Surface -> IO ()
hline x y width (SDL.Pixel pixel) screen = do
    screenWidth <- return (SDL.surfaceGetWidth screen)
    pixels <- castPtr `liftM` SDL.surfaceGetPixels screen
    forM_ [0..(width - 1)] $ \dx -> do
        pokeElemOff pixels (y * screenWidth + x + dx) pixel

vline :: Int -> Int -> Int -> SDL.Pixel -> SDL.Surface -> IO ()
vline x y height (SDL.Pixel pixel) screen = do
    screenWidth <- return (SDL.surfaceGetWidth screen)
    pixels <- castPtr `liftM` SDL.surfaceGetPixels screen
    forM_ [0..(height - 1)] $ \dy -> do
        pokeElemOff pixels ((y + dy) * screenWidth + x) pixel

main :: IO()
main = do
    startRow <- randomRIO (0 :: Int, rows - 1)
    startColumn <- randomRIO (0 :: Int, columns - 1)
    seeds <- replicateM (rows * columns) (randomRIO (0 :: Int, (max rows columns)))

    maze <- return (genMaze (newMaze rows columns) (startRow, startColumn) seeds)
    SDL.init [SDL.InitEverything]
    screen <- SDL.setVideoMode screenWidth screenHeight 32 []

    hline 0 0 screenWidth whitePixel screen
    hline 0 (screenHeight - 1) screenWidth whitePixel screen
    vline 0 0 screenHeight whitePixel screen
    vline (screenWidth - 1) 0 screenHeight whitePixel screen

    forM (assocs maze) $ \((r, c), cell) ->
        if (top cell) then do
            hline (blockWidth * c) (blockHeight * r) blockWidth whitePixel screen
        else do return ()

    forM (assocs maze) $ \((r, c), cell) ->
        if (left cell) then do
            vline (blockWidth * c) (blockHeight * r) blockHeight whitePixel screen
        else do return ()

    SDL.flip screen
    eventLoop
    SDL.quit

    where
        eventLoop = SDL.waitEvent >>= checkEvent
        checkEvent SDL.Quit = return()
        checkEvent (SDL.KeyUp _) = return()
        checkEvent _ = eventLoop

        blockWidth = 32
        blockHeight = 32
        rows = 16
        columns = 16
        screenWidth = columns * blockWidth
        screenHeight = rows * blockHeight
        whitePixel = SDL.Pixel 0x00FFFFFF

@aks See the comment about 2D maze. I've found it in many cases a pretty nice tool test. If it becomes too tedious to implement, the language has no opportunity. And preferably it should be written without auto-complete or any other possible additional helpers.

@aks Like think of "AI assisting with writing code"

Then I'd like think that why not make better constructs so that extra computational power required for AI is pursued for something more useful computation. So from that gist I think tools should be thought off.

For me the sign that e.g. a programming language needs an AI assistant, it is not about AI replacing a human as a programmer but that there is something inherently wrong in the tool or ecosystem in the first place. This is not same as saying that ML's etc would not have any good purpose use.

@jarkko i agree! This industry puts often cart before the horse then invents their own bullcrap solution instead of improving the existing one..

@aks In kernel or any other big open source project, we have had that privilege of getting code for free for decades. So we've had AI privilege before modern AI industry even existed, or even anyone pursued of that opportunity even in distant dreams. That is sort of how open source works or is the core idea.

@aks And also in any major open source platform: it is all about decision making and argumentation. Code itself is totally 1% club.