VirtualTam's bookmarks

  1. AI Flame Graphs 2025-01-20

    AI developers think about their bit of code, but with AI Flame Graphs they can now see the entire stack for the first time, including the HW, and many layers they don't usually think about or don't know about. It basically looks like a pile of gibberish with their code only a small part of the flame graph.

    This reaction is similar to people's first experiences with CPU flame graphs, which show parts of the system that developers and engineers typically don't work on, such as runtime internals, system libraries, and kernel internals.

    1. The Technologies - A more in-depth look at Rust plugin systems
    2. Getting Started - First steps trying to implement the plugin system
    3. Diving into Dynamic Loading - A closer look at dynamic loading in Rust
    4. Reducing the Pain with Dependencies - Taking a look at the state of dynamic loading in the Rust ecosystem
    5. Getting our Hands Dirty - Finally implementing the plugin system!
    6. Wrapping Up - The last finishing touches and ideas
  2. This is what war in the 21st century looks like: you can practically monitor a missile or a drone that is trying to kill you right from your phone. This is like a Black Mirror episode in real life.

    1. Blocking TCP port 53 traffic leads to very strange failures. Don't.
    2. The source you're looking at is not the code running in production.
    3. "Prod" is just another name for "staging".
  3. A whole buncha' links with contradictory information on how to properly set up a mail server ;-)

    Disclaimer - My primary goal is to add proper Spamassassin (SA) filtering to an existing Postfix / Dovecot / roundcube installation, i.e.:

    • use SA as a milter (mail filter) to attribute a spam score to incoming mail
    • keep SA up-to-date
    • train SA with spam/ham from the users' virtual mailboxes
    • train SA according to user decisions (actual user or trained mail client with automatic/trained spam detection)

    Here we go!

    Most useful links; I stumbled upon them as soon as I knew what to look for:

    Official:

    Debian:

    CentOS:

    RHEL:

  4. "Any way you look at it, a drum solo is a shitty gift for a newborn!"

  5. Python's built-in unittest module is quite cool, but a bit limited and way too verbose (read: it's quite not easy to incite developers to write unit tests)

    I'm currently looking for more dev-friendly solutions, the key points being:

    • writing test code should be easy and straight-forward -keep the focus on "what to test" instead of "how to transcribe a process to a test"
    • parallelization! -we, spoiled developers, should make good use of our way-too-many-cores build machines...
    • complete feature set!
      • we don't want to just run tests...
      • coverage reports (find dead/weak/untested code sections)
      • output formatting (JUnit-XML seems to be quite a common format out there)

    There seem to be 3 solutions in Python:

    • stock unittest + project-dependent customizations / test helpers
    • nosetests
    • py.test

    And 2 ways of gettings things done:

    • keeping things stock: no external dependency, project-specific implementation...
    • using a test framework: one more module in your (test) virtualenv, more concise tests, more features (// run, code coverage, etc.)

    Some links: