This change is a little bit different. Jujutsu is great because it works well WITH git. I don’t need to move or convert all my repositories. It uses git as its backing storage. My coworkers can continue using git, and won’t even notice that I switched. If it wasn’t for this, I would probably not even have considered it (i.e., it wouldn’t be worth the effort)

There’s a lot of detail in there so I recommend reading it. But some highlights from me:

Mythos raised 5 vulnerabilities total: 3 of them were false positives, 1 was a non-security bug, and the other was a low-criticality vulnerability that will be patched in their normal release cadence.

It kinda points to Mythos being overhyped by Anthropic (not surprising) as it wasn’t that much better compared to other LLMs. On the flip side, other LLMs have been blasting through these codebases and finding vulnerabilities for the past year or so and helping to ensure things are at a better baseline.

The Problem: When Harakiri Goes Too Far

Picture this: You’re running a Python web app, and suddenly one request decides to take a leisurely stroll through molasses. Maybe it’s waiting on a slow database query, or perhaps it’s gotten lost in an infinite loop of contemplation about the meaning of life (and JSON parsing).

Because of that, I’ve written a small filter plugin called json_query, that allows you to do some cool transformations with ansible. The filter uses jmespath ( http://jmespath.org/ ) a query language for json data. The plugin is already merged to devel branch and will be released on 2.2 version of ansible.

Motivation

First of all I need to say that I love AWS’ ELB. It is cost-effective and works just fine for most of the cases.

So why would I create a custom-crafted ELB? Well, there are some features that AWS’ ELB just don’t support. Things like:

• A static IP or elastic IP entry point
• UDP load balancing
• Customized balancing strategy
• Custom backend routing
• One load balancer for multiple backends
• SNI resolution(SSL routing)

So if the ELB is not suited for your use case, do it yourself :-)

Because we have a central point where we define per-environment networks, I recently got stuck with having to convert a list of subnets (just strings) to a list of dicts to be used by the ec2_group module. My list of subnets was something like:

internal_networks:
  - 10.100.32.0/20
  - 10.100.128.0/20
  - 10.100.144.0/20
  - 10.50.128.0/20
  - 10.50.144.0/20

While the ec2_group expects its rules to be something like:

#converts an int to a netmask as 24 -> 255.255.255.0
netmask()
{
    local mask=$((0xffffffff << (32 - $1))); shift
    local ip n
    for n in 1 2 3 4; do
        ip=$((mask & 0xff))${ip:+.}$ip
        mask=$((mask >> 8))
    done
    echo $ip
}

#receives a ip/mask parameter and returns the nth ip in that range:
get_nth_ip()
{
    IFS=". /" read -r i1 i2 i3 i4 mask <<< $1
    IFS=" ." read -r m1 m2 m3 m4 <<< $(netmask $mask)
    printf "%d.%d.%d.%d\n" "$((i1 & m1))" "$((i2 & m2))" "$((i3 & m3))" "$(($2 + (i4 & m4)))"
}

To find the 10th ip in a subnet you just need to:

One example I had to deal with recently was the tags attribute of ec2_asg and ec2_tag. You cannot just pass the same value for both of them because ec2_asg tags attribute expects a list of dicts, while ec2_tag expects just a dict. That difference is because ec2_asg’s dicts have an optional attribute called propagate_at_launch.