Alyx.pink

I benchmarked 21 local LLMs on real MCP tool calling. Here's what actually works.

Thu, 26 Feb 2026 00:00:00 GMT

I spent the past few weeks building a tool-calling benchmark for local LLMs and running 21 models through it. Not synthetic evals, not vibes. Real MCP tool calls against a real API (Workunit, which I built) with real database state, scored with semantic validation.

Three things surprised me. I'll start with those, then get into the data.

The three findings that matter

1. A 4B model beat models 9x its size. qwen3-4b-thinking-2507, at 4B parameters and 2.3 GB on disk, scored 89.3% in agentic mode. It outperformed 11 of the 20 other models, including models up to 36B. A 3B model (ministral-3-3b, 2.8 GB) scored 85.1% and beat four models in the 20-36B range. If you've been assuming you need a big model for reliable tool calling, these results say otherwise.

2. Single-shot benchmarks are lying to you. Every model scored higher in agentic mode (iterative with real API feedback) than in single-shot mode (one response, no correction). The average gap was +18.3 percentage points, but on multi-step reasoning tasks it was +37.3pp. The single-shot pass rate on reasoning tasks was 2.0%. Agentic: 49.7%. If you're picking models based on single-shot evals, you're probably making the wrong choice.

3. Reasoning beats tool training. phi-4-reasoning-plus (15B) was not fine-tuned for tool calling at all. It scored 91.4% in agentic mode, beating most tool-trained models. But here's the catch: it scored 35.1% in single-shot. It couldn't even format a basic explicit tool call without feedback (36.4% on L0). Give it the agentic loop, and it figures out the format, self-corrects, and performs at the top of the pack. Tool training gives consistency; reasoning gives ceiling.

What I tested

21 models, 3B to 80B parameters, mostly Q4_K_M quantization. All running locally on a single RTX 4080 SUPER (16GB VRAM) with LM Studio. No cloud APIs.

The target was the Workunit MCP server, which exposes 19 tools for project management: creating projects, tracking work items, managing tasks, handling assets, searching. Tool calls had real consequences: creating a project returned a real UUID that subsequent tasks had to reference.

28 tasks across three difficulty levels:

L0 (Explicit, 11 tasks): "Call create_project with name=X, status=Y." The model just needs to format the call.
L1 (Natural language, 10 tasks): "I need to track work on fixing our login page..." The model figures out which tool and what parameters.
L2 (Multi-step reasoning, 7 tasks): "Set up everything for a dark mode feature." The model plans a tool sequence, chains entity IDs across calls, and generates semantically appropriate content.

Two evaluation modes: single-shot (one prompt, one response, no feedback) and agentic (model gets real API responses back, iterates until pass or 300s timeout, 25-turn cap).

The full rankings

Rank	Model	Params	Disk	Tool-trained	L0	L1	L2	Overall
1	`glm-4.7-flash`	30B	16.9 GB	Yes	100.0	97.0	89.3	95.4
2	`qwen3-coder-next`	80B	45.2 GB	Yes	100.0	100.0	85.7	95.2
3	`devstral-small-2-2512`	24B	12.4 GB	Yes	100.0	100.0	82.1	94.0
3	`ministral-3-14b-reasoning`	14B	8.5 GB	Yes	100.0	100.0	82.1	94.0
3	`qwen3.5-35b-a3b`	35B	20.6 GB	Yes	100.0	100.0	82.1	94.0
6	`magistral-small-2509`	24B	14.2 GB	Yes	100.0	98.5	77.6	92.0
7	`qwen3-coder-30b`	30B	17.4 GB	Yes	100.0	100.0	75.0	91.7
8	`phi-4-reasoning-plus`	15B	8.4 GB	No	100.0	96.5	77.6	91.4
9	`gpt-oss-20b`	20B	11.3 GB	Yes	100.0	92.0	81.2	91.1
10	`qwen3-4b-thinking-2507`	4B	2.3 GB	Yes	100.0	100.0	67.9	89.3
11	`lfm2-24b-a2b`	24B (MoE)	13.4 GB	Yes	100.0	92.0	75.4	89.1
12	`rnj-1`	8.3B	4.8 GB	Yes	100.0	100.0	64.8	88.3
13	`granite-4-h-tiny`	7B	3.9 GB	Yes	98.6	91.5	69.9	86.7
14	`nemotron-3-nano`	30B	22.8 GB	Yes	100.0	98.5	59.3	85.9
14	`gemma-3-12b`	12B	7.6 GB	No	100.0	91.0	66.7	85.9
14	`ernie-4.5-21b-a3b`	21B	12.6 GB	No	100.0	100.0	57.6	85.9
17	`ministral-3-3b`	3B	2.8 GB	Yes	100.0	92.0	63.2	85.1
18	`glm-4.6v-flash`	9.4B	7.4 GB	Yes	90.9	83.5	67.1	80.5
19	`seed-oss-36b`	36B	20.3 GB	Yes	86.8	71.3	41.7	66.6
20	`qwen2.5-coder-32b`	32B	18.5 GB	No	72.7	40.0	17.9	43.5
21	`deepseek-r1-0528-qwen3-8b`	8B	4.7 GB	No	97.3	22.0	0.0	39.8

Per-level and overall scores for all 21 models in agentic mode.

The winner is glm-4.7-flash (30B, 95.4%), with qwen3-coder-next (80B, 95.2%) close behind. 17 of 21 models exceeded 85% overall. For basic and natural-language tool calling, the problem is mostly solved. L2 multi-step reasoning is where models separate: scores range from 0% to 89.3%, and only two models broke 85%.

The single-shot vs agentic gap

The per-level breakdown tells the story:

Level	Single-shot (mean)	Agentic (mean)	Lift
L0 (Explicit)	92.4%	97.4%	+5.0pp
L1 (Natural language)	76.2%	88.8%	+12.6pp
L2 (Reasoning)	28.6%	65.9%	+37.3pp

At L0, the lift is small because most models can format a tool call correctly on the first try. At L1, the lift comes from models correcting tool selection or parameter mapping after seeing the error. At L2, the lift is qualitatively different: multi-step tool chains require iterating with real responses. You can't predict the UUID of a project you haven't created yet.

The two biggest lifts came from models with strong reasoning but poor zero-shot formatting:

phi-4-reasoning-plus: +56.3pp (35.1% → 91.4%). Could not format basic tool calls without feedback. Once the agentic loop let it observe and correct, it performed at the top.
qwen3-4b-thinking-2507: +49.6pp (39.7% → 89.3%). Same pattern. Strong reasoning, needs the loop.

The smallest lift: deepseek-r1-0528-qwen3-8b at +0.6pp. The agentic loop can't help when the problem isn't formatting but a fundamental inability to map natural language to tools or plan multi-step chains.

Tool training: helpful, not decisive

I included 5 control-group models that had no tool-specific fine-tuning. The numbers:

Group	N	Agentic (mean)	Std Dev
Tool-trained	16	88.7%	7.2pp
Control	5	69.3%	25.4pp

The 19.4pp gap is real. But look at the standard deviations. Tool training raises the floor and tightens the spread. Without it, you're rolling the dice: phi-4-reasoning-plus hits 91.4% (top 8), while deepseek-r1 hits 39.8% (bottom 2) and qwen2.5-coder hits 43.5%.

The phi-4 result is worth sitting with. A 15B model with no tool training, performing at the level of the best tool-trained models, purely through in-context learning within the agentic loop. It suggests that tool training is most valuable for single-shot reliability (tool-trained single-shot average: 70.2%, control: 51.6%), with diminishing returns when models get real feedback.

Practical picks by VRAM budget

Disk size is a reasonable floor for VRAM requirements. Here's what I'd pick at each tier:

Under 4 GB: qwen3-4b-thinking-2507 (4B, 2.3 GB, 89.3%) if your agent framework supports agentic loops. ministral-3-3b (3B, 2.8 GB, 85.1%) if you need single-shot reliability (76.0% SS vs 39.7% for the 4B).

8-12 GB: ministral-3-14b-reasoning (14B, 8.5 GB, 94.0%). Tied for 3rd place. 100% on both L0 and L1. This is the sweet spot for most setups.

12-16 GB: devstral-small-2-2512 (24B, 12.4 GB, 94.0%) edges out magistral-small-2509 on both L1 and L2, and is 1.8 GB smaller.

16+ GB: glm-4.7-flash (30B, 16.9 GB, 95.4%). The overall winner.

48+ GB: qwen3-coder-next (80B, 45.2 GB, 95.2%). Only 0.2pp behind the winner, 100% on L0 and L1.

Things that bit me

Jinja templates can silently break everything. seed-oss-36b initially scored 0% on all agentic tasks. Not because the model was bad, but because LM Studio's Jinja engine didn't support Python's in operator for tuple/array membership testing. Three constructs in the chat template were incompatible. After rewriting them, it scored 66.6%. If a model scores surprisingly badly, check the inference stack before blaming the model.

Code completion models don't transfer. qwen2.5-coder-32b is a 32B model that scored 43.5%. It emits FIM tokens (<|fim_suffix|>, <|fim_middle|>) and is designed for code completion, not chat-based tool calling. Code pretraining does not transfer to structured tool calling.

One model had a cliff, not a slope. deepseek-r1-0528-qwen3-8b: 97.3% on L0, 22% on L1, 0% on L2. It can follow explicit formatting instructions, but it falls off completely the moment it needs to interpret natural language or reason about tool sequences.

Caveats

Single hardware config (RTX 4080 SUPER 16GB, 64GB RAM). Mostly Q4_K_M quantization. One MCP domain (Workunit's project management tools). Temperature 0.0. Single run per model. 8192 token context for all models. The exact numbers should be taken with the appropriate grain of salt, but the relative rankings and structural findings (agentic > single-shot, small models viable, reasoning > raw size) should hold.

All data is open

Full source code, all 28 task definitions, runner scripts, and every result JSON with complete audit trails are in the repo. Each result file contains the exact prompt sent, every tool call with arguments, every API response received, and scoring details. You can open any result, pick a task, and see exactly what happened.

Repository: github.com/3615-computer/workunit-benchmarks

The full research paper has formal methodology, all tables, validation details, and appendices.

Workunit: The missing context layer for working with AI

Fri, 24 Oct 2025 00:00:00 GMT

Hey everyone,

I've been building with AI for a while now, and I kept running into the same frustrating problem: no matter how powerful these models get—Claude, GPT, Gemini—they all eventually lose track of what you're doing. You know the drill: you're deep into building a feature, the context window fills up, the conversation compresses, and suddenly the LLM forgets the plan it carefully crafted an hour ago.

But here's what really bugged me: you can't easily move work between different models. Say you want Claude's planning brilliance but GPT's design chops? Good luck manually copying context between chats. Want two models working on the same codebase? You're basically maintaining two separate conversations that have no idea what the other is doing.

So I built Workunit to fix this.

The Problem: Context Fragmentation

Here's what I was dealing with:

Context windows are still too small. Even the best models compress your conversation after a while. That detailed architecture plan you made at the start? Reduced to a summary. Those important decisions about why you chose approach A over B? Gone. The model starts improvising based on incomplete memory.

No context sharing between models. Each AI lives in its own bubble. You can't start planning with Claude, move to Gemini for implementation, then ask GPT to review the code—at least not without manually copying a ton of context every single time.

Teams can't collaborate with AI. When you're working with others, everyone's having separate conversations with their preferred models. There's no shared understanding, no single source of truth. Your coworker using GPT has no idea what you just asked Claude to do.

What is Workunit?

Think of Workunit as a context and memory layer that sits between you and any AI model. It's also a project management tool, but the real magic is how it lets you share context across different models seamlessly.

Here's how it works: instead of just chatting with an AI, you create a Workunit. Each workunit contains:

The problem you're solving - clearly defined
Success criteria - what "done" looks like
AI context - a persistent knowledge base where models can dump what they've learned
Tasks - specific work items with their own focused context

Once you've created a workunit, any AI with access to the MCP (Model Context Protocol) integration can read and update it. That means Claude, GPT, Gemini, or whatever new model comes out next month—they all see the same information.

Assets: Building your context graph

Here's where Workunit gets really interesting. Beyond just tracking tasks, you can define Assets—the building blocks of your project's context. Think of them as the things your AI needs to understand before it starts working.

There are four types of assets:

Knowledge - Your documentation, coding standards, API docs, architecture decisions
People - Team members, stakeholders, even your AI assistants
Product - The actual things you're building (apps, features, platforms)
System - Technical infrastructure (databases, APIs, deployment pipelines)

When you link assets to a workunit, you're creating what I call a "context graph." Now when an AI looks at your workunit, it automatically knows which systems are involved, what documentation to reference, who's working on what, and which products are affected.

And here's the cool part: LLMs can manage these assets themselves through the MCP tools. They can create new assets as they discover them, search for existing ones, and update them when information changes. So if you're working with Claude and mention "we're using PostgreSQL with this specific schema," Claude can create a System asset for it. Later, when GPT needs that context, it can search for and find that PostgreSQL asset without you having to explain it again.

No more "hey Claude, remember we're using PostgreSQL with that specific schema I told you about 50 messages ago?" The context is right there, persistent and accessible.

The best part? Start small. I usually begin with 5-10 core assets—my main database, API documentation, coding guidelines, team members. As projects grow, the asset library grows with them. It's documentation that actually stays useful instead of going stale in some wiki nobody reads.

How I actually use it

Let me show you a real example. Say I'm building a new authentication system:

I start by planning with Claude: "Let's add a 'Won't Do' task status"
Claude uses the Workunit MCP to create the structure, defines the problem, sets success criteria, breaks it into tasks
I get a URL like https://workunit.app/workunits/abc123
Later, I can tell GPT: "Take a look at this workunit https://workunit.app/workunits/abc123 and focus on the database schema task" - with the task URL
GPT sees all the context, implements that specific piece, and updates the task status
My teammate can comment on tasks, see progress, and even jump in with their own preferred AI

The killer feature? I can tell any model to "update task status as you work" and I get a real-time view of what's in progress, what's done, and what's blocked. No more wondering if the AI actually completed something or just said it did.

Setting up the MCP integration

Getting your AI tools connected to Workunit is straightforward. The Model Context Protocol (MCP) is what makes all this magic happen—it's the bridge that lets AI assistants access Workunit directly from your development environment.

The beauty of using MCP is that Workunit works with any LLM that supports the Model Context Protocol. Claude, GPT, Gemini, or whatever comes next—if it supports MCP, it can connect to Workunit. That means you're future-proof as the AI landscape evolves.

Here are setup examples for the most commonly documented tools:

For Claude Code

Just run this in your terminal:

claude mcp add --transport http workunit https://workunit.app/mcp

Then open Claude Code and ask about available Workunit tools to verify it's working.

For Gemini CLI

Add the integration with:

gemini mcp add --transport http workunit https://workunit.app/mcp

Once connected, your AI assistant can:

Create and modify workunits
Generate and assign tasks
Link assets to your work
Access and update context across conversations

The setup process is similar for any MCP-compatible tool—just point it to https://workunit.app/mcp and you're good to go. It takes maybe two minutes, and then you've got persistent context across all your AI interactions. Worth it.

For more details and troubleshooting, check out the MCP integration guide.

Beyond solo work

Workunit isn't just for working with multiple AI models—though that's incredibly powerful. It's also built for teams:

Comments on tasks - your team can discuss specific work items
Check-ins - gather status updates from everyone in your organization
Shared understanding - humans and AI working from the same source of truth

It's designed for small teams and solo builders who want AI assistance without enterprise complexity. You know, those of us who don't need fancy Gantt charts but do need to actually ship things.

Why this matters

The AI landscape is moving fast. New models launch every month, each with different strengths. Workunit means you're not locked into one model's ecosystem—you can use the best tool for each job.

More importantly, it solves the memory problem. Context doesn't disappear when a conversation gets long. The AI can always reference back to what you've built together, decisions you've made, and patterns you've established.

And when your team grows? The context layer grows with you. Everyone works from the same foundation instead of scattered conversations across different tools.

Try it out

Workunit is live in beta right now, completely free while I refine things. I'm looking for feedback from builders who are tired of fighting context windows and want to use multiple AI models effectively.

If you've ever lost a great plan halfway through a conversation, or wished you could seamlessly move work between different models, give Workunit a shot. I'd love to hear what you think.

Found my perfect image hosting solution: Slink

Wed, 17 Sep 2025 00:00:00 GMT

Hey everyone,

I've been searching for the perfect image hosting solution for my blog, and I finally found it! Meet Slink, a self-hosted image sharing platform that actually gets it right.

Here's what had me hooked: it strips EXIF data from images automatically. You know, all that metadata that can reveal your location, camera model, and other personal info? Gone. This is something I really needed, especially since PicoShare (which I use for other needs, keeping this lack of feature in mind) keeps files exactly as uploaded.EXIF data and all.

But it's not just about privacy. The UI/UX is great. Upload an image, get a clean link, done. No fuss, no bloated interface, just a smooth experience that makes adding images to my static blog actually enjoyable. It supports everything from PNG and JPG to modern formats like AVIF and HEIC.

I've already uploaded a bunch of images for my previous posts to Slink (you're looking at one right now!). Having complete control over my media while keeping things private and simple? That's exactly what I was after.

If you're tired of wrestling with image hosting or worried about metadata privacy, give Slink a shot. It's been a game-changer for my workflow.

Update everything on macOS with one Fish command

Wed, 17 Sep 2025 00:00:00 GMT

Picture from Andras Vas on Unsplash

Got tired of running multiple apps and commands to keep my Mac updated? Here's a Fish shell function that handles everything in one go:

function upall --description "Update all the things"
    brew update-reset && \
    brew update && \
    brew upgrade --formulae && \
    brew cu --all --cleanup --no-brew-update --interactive --include-mas && \
    brew cleanup --prune=all
end

Just run upall and you're set! Here's what each part does:

brew update-reset - Resets Homebrew to fix any potential issues
brew update - Fetches the latest package definitions
brew upgrade --formulae - Updates all your CLI tools and libraries
brew cu --all --cleanup --no-brew-update --interactive --include-mas - Updates cask applications and Mac App Store apps (requires brew-cask-upgrade)
brew cleanup --prune=all - Removes old versions and cleans up the cache

The --interactive flag is particularly nice—it lets you choose which cask apps to update, perfect for when you want to skip that one app that always breaks after updates.

To add this to your Fish shell, paste the function into a function file, mine is .config/fish/functions/upall.fish. No more remembering multiple commands or running them one by one!

Note: You'll need to install brew-cask-upgrade first, see github.com/buo/homebrew-cask-upgrade.

A new chapter: 3615.computer

Fri, 12 Sep 2025 00:00:00 GMT

Hey everyone,

I've launched 3615.computer, my new umbrella for software projects. The name's a nod to those funny little Minitel "computers" we had at home in France—our own internet before the internet, where you'd dial "3615" for services over the landline.

::github{org="3615-computer"}

Right now, I'm focusing on two main projects that solve very different problems I care about.

Workunit: AI for Focused Teams

Workunit tackles a problem I've experienced firsthand—context fragmentation. You know the drill: scattered conversations across Slack, decisions buried in email threads, and that one crucial detail lost somewhere in your note-taking app.

Workunit consolidates your team's scattered tools into one AI-powered workspace. Think of it as having a thoughtful team member who remembers every decision, understands your project's context, and helps you stay focused instead of constantly context-switching.

It's built for small teams and solo entrepreneurs who want AI assistance without the complexity.

Aeronef: Guild Wars 2 Companion

Aeronef started as a personal itch I needed to scratch. As a Guild Wars 2 player, I was tired of juggling multiple wikis, calculators, and spreadsheets to track my progress and manage my in-game economy.

So I built a comprehensive companion app that handles account value tracking, crafting calculations, daily quest management, and real-time trading post analytics—all in one place. It's built by a gamer, for gamers, with no affiliation to ArenaNet.

If you're managing multiple characters or trying to optimize your gold-making strategies, Aeronef might save you some headaches.

Cloudflare's Bold Documentation: Just Let the AI Do It

Fri, 12 Sep 2025 00:00:00 GMT

Picture from Sharad Bhat on Unsplash

I stumbled across something fascinating in Cloudflare's documentation recently—something that made me do a double-take and then immediately try it out.

Hidden in their migration guides is this wonderfully matter-of-fact suggestion: "or if you want to just do the migration automatically by your LLM, feed it this file and let it happen."

Not buried in a footnote. Not hedged with disclaimers. Just a casual "hey, your AI can probably handle this entire migration for you."

The Documentation Revolution

This is remarkable for a few reasons. First, it's Cloudflare—a major infrastructure company—officially endorsing AI automation for non-trivial technical tasks. Second, they're not just mentioning it as a possibility; they're providing structured documentation specifically designed to be consumed by LLMs.

Most documentation is written for humans, with context and explanations that help us understand the "why" behind each step. But when you're feeding instructions to an AI, you want something different: precise, structured information that can be parsed and executed systematically.

Cloudflare seems to have cracked this code. Their migration files are clean, comprehensive, and apparently LLM-friendly enough that they can confidently tell developers to "just let it happen."

The One-Shot Migration

I tested this approach, and it worked exactly as advertised. Fed the migration guide to an AI assistant, pointed it at my project, and watched it methodically work through the entire migration process.

No back-and-forth debugging sessions. No missed steps. No "oh wait, I forgot to update that config file" moments. Just a systematic, thorough migration that actually worked on the first try.

This isn't some toy example either—we're talking about migrating real projects with real complexity, dependencies, and edge cases.

The AI-Optimized Structure

What makes this documentation so effective becomes clear when you look at how it's structured. Here's a section that perfectly demonstrates the AI-friendly approach:

### 3. Determine Project Type

**First, check for Pages Functions:**

- Look for a `functions/` directory with .js/.ts files
- If found, you **must** add `wrangler pages functions build` to your build process (see step 6)

**Then, run your build command and check the output directory:**

- **If _worker.js exists**: You have a Workers script project
  - Add `"main": "./path/to/_worker.js"`
  - Add binding to assets: `"assets": {"directory": "path", "binding": "ASSETS"}`
- **If no _worker.js**: You have an assets-only project
  - Just use `"assets": {"directory": "path"}` without main field

### 6. Pages Functions Migration (if applicable)

**ONLY if you have a `functions/` directory with .js/.ts files:**

- **Always add** the Pages Functions build command to your build process

Notice the clear conditional logic, the explicit use of "must" and "ONLY if", and the decision trees. This isn't documentation—it's a structured algorithm that an AI can follow step-by-step without ambiguity.

What This Means for Documentation

Cloudflare's approach hints at something bigger: the future of technical documentation might be dual-purpose. Written for humans to understand, but structured for machines to execute.

This could fundamentally change how we approach complex technical processes. Instead of hoping developers follow 47 steps correctly, why not provide instructions that an AI can execute flawlessly?

The implications go beyond migrations. Think about deployment guides, security audits, refactoring tasks, or any process that involves systematic changes across a codebase.

The Trust Factor

What strikes me most is the confidence behind that casual suggestion. Cloudflare didn't arrive at "just let the AI do it" overnight. They've clearly tested this extensively and found it reliable enough to recommend to their users.

That level of trust in AI automation for production systems feels like a significant shift. We're moving from "AI might help with some tasks" to "AI can handle entire categories of work better than humans."

Looking Forward

This feels like one of those moments where the future quietly announces itself. Not with fanfare or keynotes, but with a single line in technical documentation that changes how we think about automation.

Other companies will likely follow suit. The pattern is too useful to ignore: provide structured, AI-consumable documentation alongside human-readable guides.

The question isn't whether this approach will spread—it's how quickly, and what other technical processes will benefit from this dual-purpose documentation strategy.

Cloudflare just showed us what confident AI integration looks like: practical, tested, and casually revolutionary.

How to use 1Password to authenticate to your favorite IRC server

Wed, 23 Apr 2025 00:00:00 GMT

How to use 1Password to authenticate to your favorite IRC server

1Password is a password manager that can help you securely store and manage your passwords, including those for IRC servers. In this guide, we'll show you how to use 1Password to authenticate to your favorite IRC server using the Halloy IRC client.

Prerequisites

You need to have 1Password installed and set up on your device. Any other password manager that supports the same features can be used, check your password manager's documentation for more information.
- 1Password CLI (op) must be installed and configured. You can find the installation instructions here.
You need to have the Halloy IRC client installed on your device. Other IRC clients may also work, but this guide was tested with Halloy.
You need to have an account on the IRC server you want to connect to. I'll be usng libera.chat as an example.

Step 1: Create a new login in 1Password

Open 1Password and click on the "+ New Item" button.
Select "Login".
Enter the following information:
- Name: The name of the IRC server (e.g., "libera.chat").
- Username: Your IRC username.
- Password: Your IRC password.
- Website: The URL of the IRC server (e.g., "irc://libera.chat").
Select a vault and click "Save".

Step 2: Configure Halloy to get password from 1Password on startup

Open the Halloy IRC client configuration file. This file is usually located at :
- Windows: %AppData%\halloy
- Mac: ~/Library/Application Support/halloy or $HOME/.config/halloy
- Linux: $XDG_CONFIG_HOME/halloy or $HOME/.config/halloy
In 1Password, copy the UUID of the login you created in Step 1. You can find the UUID by clicking on the login > three-dots menu > "Copy item UUID".
Add the following lines to the configuration file:

[servers.<server>]
server = "<server>"
nickname = "<nickname>"
channels = []
sasl.plain.username = "<username>"
sasl.plain.password_command = "op read op://<vault>/<uuid>/<field-name>"

Save the configuration file.
Restart the Halloy IRC client.

Step 3: Connect to the IRC server

Open the Halloy IRC client.
You should see a prompt asking to unlock your 1Password vault, asked by Halloy's app.
Enter your 1Password master password to unlock the vault.
Once unlocked, Halloy will automatically retrieve your IRC password from 1Password and connect to the IRC server using the credentials you provided.
You should now be connected to the IRC server and can start chatting!

Conclusion

Using 1Password to authenticate to your favorite IRC server with the Halloy IRC client is a secure and convenient way to manage your passwords. By following the steps outlined in this guide, you can easily connect to your IRC server without having to remember or type in your password every time.

This method also helps to keep your passwords secure (not hardcoded) and reduces the risk of password leaks or breaches.

Running a local PDS in dev mode and create a custom record

Sat, 29 Mar 2025 00:00:00 GMT

I wanted to play around with ATProto and Personal Data Server (PDS). My goal was just to see how to write a record to the PDS, using a custom type. Here are some quick notes just in case it can help anyone, and so it does not get "lost".

I haven't made an extended search for everything: I'm not sure what PDS_DEV_MODE does entirely. Maybe I could have used something else than PDS_INVITE_REQUIRED=0 to not require an invitation code on signup. It's your turn to scratch around and find out!

Launch a local PDS in dev mode

This will launch a container running the PDS, the blobs (files, uploads) are stored on disk but not on a volume, so it's ephemeral. The secrets are generated automatically. Invitations are disabled. Dev mode is enabled. The container is named pds-dev.

$ docker run --rm \
  -e PDS_DATADIR=/pds \
  -e PDS_BLOBSTORE_DISK_LOCATION=/pds/blocks \
  -e PDS_BLOBSTORE_DISK_TMP_LOCATION=/pds/tmp \
  -e PDS_PLC_ROTATION_KEY_K256_PRIVATE_KEY_HEX=$(openssl ecparam --name secp256k1 --genkey --noout --outform DER | tail --bytes=+8 | head --bytes=32 | xxd --plain --cols 32) \
  -e PDS_JWT_SECRET=$(openssl rand --hex 16) \
  -e PDS_DEV_MODE=true \
  -e PDS_ADMIN_PASSWORD=$(openssl rand --hex 16) \
  -e LOG_ENABLED=true \
  -e LOG_LEVEL=debug \
  -e PDS_INVITE_REQUIRED=0 \
  -p 3000:3000 \
  --name pds-dev \
  ghcr.io/bluesky-social/pds:0.4

Create a custom record

In my case, example.alyx.customRecord is obviously not registered. Click here to learn more about the NSID and Lexicon.

Create a new account

$ export pds_account_password=$(openssl rand --hex 16)

$ curl -X POST localhost:3000/xrpc/com.atproto.server.createAccount \
  -H "Content-Type: application/json" \
  -d '{"handle": "alyx.example", "email": "alyx@alyx.example", "password": "'$pds_account_password'"}'

Get the JWT access token

$ curl -s -X POST localhost:3000/xrpc/com.atproto.server.createSession \
  -H "Content-Type: application/json" \
  -d '{"identifier": "alyx.example", "password": "'$pds_account_password'"}' | jq -r '.accessJwt'

Or:

$ export pds_access_session=$(curl -s -X POST localhost:3000/xrpc/com.atproto.server.createSession \
  -H "Content-Type: application/json" \
  -d '{"identifier": "alyx.example", "password": "'$pds_account_password'"}' | jq -r '.accessJwt')

Create your custom record

$ curl -X POST localhost:3000/xrpc/com.atproto.repo.createRecord \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer xxx" \
  -d '{"repo": "alyx.example", "collection": "example.alyx.customRecord", "record": {"custom": "Hello, world!"}}'

Or:

$ curl -X POST localhost:3000/xrpc/com.atproto.repo.createRecord \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer "$pds_access_session"" \
  -d '{"repo": "alyx.example", "collection": "example.alyx.customRecord", "record": {"custom": "Hello, world!"}}'

Inspect your PDS using a web app

You can also use pdsls.dev to inspect any records stored on your PDS. Yes, everything stored on your PDS is public, keep this in mind.

Hello, World!

Sun, 23 Feb 2025 00:00:00 GMT

Hello, World!

Hi there! I'm thrilled to launch my very own (new) blogging platform. After spending time on micro-blogging platforms, and a while self-hosting Ghost, I've decided to move away from social networks and create a space where I can express myself more freely and openly. Ghost was a great platform to write long articles, but it felt inappropriate for short updates or heavy customization.

I started developing my own theme, but when I saw how good Fuwari was, I couldn't resist using it.

Here’s what you can expect from my blog:

Short and Sweet Posts: Think microblogging but less social media focused. I’ll be sharing quick thoughts, snippets of code, or interesting links I come across throughout my day.
Thoughtful Quotes: If I stumble upon an intriguing article or paper, I might feature a compelling quote to spark some reflection.
Programming Projects: Updates on side projects I’m tinkering with. I’ll highlight challenges and solutions, giving a glimpse behind the scenes of my coding adventures.

I want to show a bit of who I am, and sharing my thoughts and learnings, in case it could help anyone out there. I hope I'll feel at home here, like I used to on microbbloging platforms.

Comment se passer de ChatGPT Plus à 20 $ par mois, au profit de LobeChat ?

Fri, 22 Mar 2024 00:00:00 GMT

J'ai récemment arrêté mon abonnement ChatGPT Plus et j'ai pu le remplacer par une simple souscription à leur API, me permettant de payer juste ce que j'utilise. Beaucoup moins cher, et proposant – selon moi – plus d'options que leur interface assez sommaire, sans pour autant ne plus pouvoir profiter de toutes les fonctionnalités que OpenAI propose.

Qu'est-ce que LobeChat ?

LobeChat est un projet open source, disponible sur https://github.com/lobehub/lobe-chat, qui se décrit ainsi :

An open-source, modern-design ChatGPT/LLMs UI/Framework. Supports speech-synthesis, multi-modal, and extensible (function call) plugin system. One-click FREE deployment of your private ChatGPT/Gemini/Ollama chat application.

C'est un front-end qui peut se brancher à diverses API, que ce soit ChatGPT ou d'autres, comme votre propre instance locale via Ollama.

L'interface ressemble beaucoup à celle de ChatGPT, ce qui rend l'adoption très facile.

Comment lancer LobeChat ?

Personnellement, j'ai utilisé Unraid pour lancer le container Docker de LobeChat avec la configuration suivante :

$ docker run -d -p 3210:3210 \
  -e OPENAI_API_KEY=sk-xxxx \
  -e ACCESS_CODE=lobe66 \
  --name lobe-chat \
  lobehub/lobe-chat

Cette configuration :

Expose le container sur le port 3210
Fournit votre clé API OpenAI
Définit un mot de passe d'accès
Utilise l'image Docker officielle

Comment l'utiliser ?

Pour utiliser LobeChat, vous devez :

Configurer votre clé API OpenAI dans les variables d'environnement
Accéder à l'interface web via votre navigateur
Saisir le code d'accès que vous avez défini
Commencer à discuter avec l'IA

L'interface est intuitive et offre de nombreuses options de personnalisation.

Analyse des coûts

Avant LobeChat, je payais 20 $ par mois pour ChatGPT Plus. Avec l'API OpenAI via LobeChat :

En février : j'ai dépensé 9 $ d'utilisation API
En mars (jusqu'au 16) : 6,61 $ seulement

Je recommande de configurer des limites de crédit pour éviter les mauvaises surprises sur votre facture.

Fonctionnalités supplémentaires de LobeChat

LobeHub et marketplace d'agents

LobeChat propose un "LobeHub" avec des agents de conversation prédéfinis pour différents cas d'usage.

Plugin Store

Un magasin de plugins permet d'étendre les fonctionnalités avec diverses intégrations.

Application Web Progressive (PWA)

LobeChat peut être installé comme une PWA sur vos appareils, offrant une expérience native sur mobile et desktop.

Support multi-providers

En plus d'OpenAI, LobeChat supporte :

AWS Bedrock
Google AI
Azure OpenAI
Et bien d'autres fournisseurs d'IA

Conclusion

Pour moi, c'est un succès. J'économise de l'argent tout en ayant plus de flexibilité et d'options. Le seul inconvénient est que les conversations ne sont stockées que dans le navigateur, ce qui peut être gênant si vous changez d'appareil.

Cette solution est particulièrement adaptée pour les utilisateurs avec une utilisation occasionnelle de l'IA. Les utilisateurs plus intensifs pourraient encore préférer l'abonnement ChatGPT Plus pour sa simplicité.

LobeChat représente une excellente alternative open-source qui vous donne le contrôle sur vos coûts et vos données.

Comment fonctionne mon NAS UNRAID à domicile ?

Sun, 17 Dec 2023 00:00:00 GMT

J'ai depuis longtemps un NAS à la maison. Je ne sais plus vers quel âge, probablement vers 15 ans. J'avais récupéré des pièces d'une décheterie pour assembler mon premier serveur. Autant vous dire que les performances n'étaient pas au rendez-vous.

Un vieux petit boîtier tout jauni, dans lequel j'avais coupé un trou au Dreml pour lui coller un ventilateur tant il avait chaud dans mon placard. Ma mère ne voulait pas le voir en dehors, il était trop moche. Je m'amusais bien avec, un petit serveur LAMP et je ne sais plus trop quoi d'autres dessus. Ça m'a fait les bases de l' admininistration système et de serveur web.

J'ai pu m'acheter une vraie config de NAS quelques années plus tard, très light en performance, mais me permettant de faire tourner Plex correctement et d'avoir du stockage de dispo. Je faisais tourner Ubuntu Server dessus. Ça demandait beaucoup d'interventions manuelles pour le mettre à jour, et le faire évoluer (installer des nouvelles applications par exemple). J'ai écrit quelques scripts pour me simplifier la tâche mais c'était assez relou. J'ai vite su que c'était pas pour moi d'avoir un truc comme ça à gérer à la maison, ou même dans mon métier. Je voulais déjà tout automatiser.

J'ai déménagé à Paris vers mes 20 ans, et j'ai emmené mon PC gaming ainsi que mon serveur. J'ai un peu repris la main dessus, collectant les films de vacances sur mon NAS pour les regarder entre amis. Ça demandait toujours autant de maintenance cependant.

J'avais envie d'un NAS autonome dont j'aurais juste à m'occuper des films de vacances et des logiciels, rien d'autres. Un truc bête genre un Synology... mais c'est hors de prix, et pas le choix du software qui tourne dessus.

Et j'ai fini par trouvé la solution. J'ai un NAS très autonome, j'ai besoin de faire que très peu de maintenance, l'installation était d'une facilitée déconcertante, et le grand choix d'applications disponibles en one-click install est un vrai plaisir. Je vais bien sûr vous parler de Unraid.

Mais d'abord, c'est quoi un NAS exactement ?

Un NAS, aussi appelé "Network Attached Storage" et un système de stockage connecté en réseau qui permet de centraliser les données et de les mettre à disposition des utilisateurs.

Ce NAS fait un peu plus que ça, puisque'il héberger également des services, c'est devenu un abus de langage je pense de dire NAS pour en fait ce qui est un simple serveur de stockage et plus encore. Peut-être que le terme de serveur à domicile serait plus approprié ?

Mon utilisation

On peut répartir l'utilisation de mon NAS en deux catégories, qui se complètement l'une et l'autre. La partie donc je m'occupe très peu, et dont je suis heureuse de laisser Unraid laisser ça, et l'autre partie qui m'amuse: lancer et gérer des services.

Stockage de masse

J'ai une grappe totale de 5x16TB de données, soit 80TB. Cependant, deux des disques sont utilisé pour la parité. Ce sont des disques servant à sauvegarder des informations qui permettent de récupérer les données en cas de panne d'un autre disque. Si l'un de mes disques venaient à mourir, alors Unraid peut recalculer les données manquantes.

J'ai fait le choix d'avoir 2 disques de parité: avec autant de données disponible (48TB), je veux surtout pas avoir un soucis lors de la perte d'un disque par exemple. Elles me sont précieuses, ça vaut le coup d'investir pour les protéger. Il faut noter que le re-calcul de la parité peut prendre des heures et des heures, et est très intensive sur l'utilisation des disques. Pas question de perdre un second disque pendant la restauration.

Mais tout de même, 48TB ça me laisse une belle marge d'utilisation, et il est tout à fait possible de continuer à l'étendre comme bon me semble. Unraid permet d'ajouter des disques à une grappe existante d'une manière extrêmement simple. Seul problème: vous ne pouvez pas dépasser la taille du plus petit disque de parité. Dans mon cas, je ne pourrais jamais mettre un disque plus gros que 16TB.

Pour faire simple et vous donner un exemple, pour installer un nouveau dissque, il vous suffit d'éteindre le NAS, brancher vos nouveaux disques, rallumer le NAS, assigner les nouveaux disques à la grappe de votre choix (vous pouvez en avoir plusieurs), lui dire de le formater, et il s'occupe de faire le reste pour vous. Une fois que tout est prêt, le stockage disponible est automatiquement mis à disposition.

Hébergement de services

Unraid tire sa puissance de sa facilité à installer des applications, en utilisant la technologie des containers Docker, ainsi qu'un "marketplace" rendant encore plus simple le lancement des apps proposés.

Le "marketplace," c'est ce qui peut s'apparenter à des templates, souvent pré-rempli pour vous faciliter la tâche, avec des exemples. Par exemple, pour un serveur Redis, vous aurez ça:

La plupart des options peuvent être laissés par défaut et votre container se lancera automatiquement. Vous avez un accès rapide aux logs pour voir ce qu'il se passe au lancement. Si le container expose une Web UI, et que le template est bien fait, alors un bouton "Web UI" apparaitra en cliquant sur le logo du container déployé.

Unraid intègre un système qui détecte si une nouvelle version du container est disponible, et en un seul clic, il le mettra à jour. Attention aux notes de mises à jour cependant ! Il arrive parfois que vous deviez effectuer une action manuelle avant/après la mise à jour, ne vous faites pas avoir.

Vous vous retrouvez alors avec une interface d'admistration de vos applications déployées, en cours ou stoppées:

Services utilisés

J'utilise de nombreux services accumulés au fil du temps. Prenez le temps de les prendre en main et comprendre ce qu'ils peuvent faire pour vous. Amusez vous aussi, si le service vous plait pas, supprimez le tout simplement, il n'y a rien d'instrusif dans l'OS à supprimer qui pourrait être laisser derrière, sauf peut-être les appdata, mais c'est juste un dossier à un seul endroit donc pas de panique pour les nettoyage.

Tailscale

Je commence par celui-ci car il est intégré nativement – via un plugin disponible – à Unraid et vous permet de vous connecter à votre serveur depuis n'importe où, comme si vous étiez chez vous.

Pour rappel, Tailscale est un service de réseau privé virtuel (VPN) qui permet de connecter de manière sécurisée et facile des appareils et des services à travers internet. Il utilise la technologie WireGuard pour établir des connexions rapides et cryptées, offrant ainsi un accès sécurisé aux ressources de votre réseau, dans le monde entier. Tailscale se distingue par sa configuration simple, ne nécessitant pas de matériel spécialisé ni de configuration réseau complexe. Il offre également tout un tas de features très utiles, comme la possibilité d'envoyer des fichiers entre les appareils du réseau, ou encore une meilleure gestion de DNS pour tous vos appareils.

Ça vous ouvre des possibilités incroyable: un point de montage sur Files.app de votre iPhone vers vos Partages Samba, l'utilisation de Adguard-Home en dehors de chez vous, sans jamais avoir besoin d'exposer vos services sur internet. Peu importe où vous êtes, sur n'importe quel réseau, vous êtes comme chez vous.

Vous pouvez même vous servir de votre serveur comme un nœud de sortie VPN: dans ce cas, toute votre connexion sera tunnelée vers votre serveur et sortira de chez vous. Pas mal si vous voulez regarder un contenu géo-bloqué de votre pays pendant un voyage par exemple.

AdGuard Home

Un bloqueur de publicités et de tracking pour tout votre réseau, qui protège tous les appareils connectés. Fonctionne uniquement via les DNS cependant, donc impossible de supprimer les pré-roll de pubs YouTue ou Twitch.

Cloudflared Tunnel

Crée un tunnel sécurisé entre votre serveur Unraid et les services Cloudflare pour un accès distant sécurisé. Ça vous permet d'exposer vos services publiquement, comme blog.alyxpractice.com par exemple ou bien files.alyxpractice.com.

db-backup

Un outil pour automatiser les sauvegardes de vos bases de données.

Ghost

Une plateforme de blogging élégante et moderne, idéale pour ceux qui cherchent une alternative à WordPress. C'est sur celle-ci que vous me lisez !

C'est beaucoup centré sur la génération de contenu payant, mais vous pouvez très facilement désactiver tout ça et rendre tout gratuit et accessible. Je n'ai pas encore trop fouillé si il existait beaucoup de plugins, thèmes, etc... mais son interface de base me permet de me focus sur mon contenu et c'est très bien comme ça.

Homarr

Un tableau de bord personnalisable pour centraliser et accéder facilement à vos applications et services web. Plus simple que de passer par Unraid > Docker > Web UI systématiquement.

Home Assistant

Une solution de domotique pour contrôler et automatiser votre maison intelligente. Apporte de nombreuses solutions pour combler le manque des plateformes classiques type Siri, Alexa, Google Assistant, etc...

icloudpd

Un service pour télécharger automatiquement vos photos iCloud sur votre serveur Unraid. Attention le token doit être renouveler régulièrement, mais je me sens plus safe d'avoir toutes mes photos en backup chez moi.

MariaDB

Un système de gestion de base de données, compatible avec MySQL, pour stocker et gérer vos données.

Picoshare

Un outil simple pour partager des fichiers et des images via votre serveur. Disponible via files.alyxpractice.com

Plex Media Server

Un serveur de médias pour organiser et diffuser votre collection de vidéos, musiques et photos, pour vous et vos amis. Parfait pour partager vos films de vacances ! Disponible sur toutes les plateformes.

Prowlarr

Un gestionnaire pour indexer des sites de torrents et Usenet, facilitant la recherche de médias. Il vous permet de centraliser la configuration de vos clients de torrents et indexers, et synchroniser les paramètres avec la suite logiciels *arr comme radarr ou sonarr...

qBittorrent

Un client torrent léger et puissant pour télécharger et partager des fichiers.

Radarr

Un gestionnaire de films qui automatise le processus de recherche, téléchargement et organisation de votre collection de films.

Red-DiscordBot

Un bot Discord personnalisable avec un système de "cogs" ou plugins, créés par la communauté, pour améliorer l'interaction sur vos serveurs Discord. Il est utilisé sur le discord de 3615.computer.

Sonarr

Un gestionnaire de séries TV qui automatise le téléchargement et l'organisation de vos émissions télévisées.

Soulseek

Une application de partage de fichiers axée sur la musique, idéale pour découvrir et télécharger de la musique rare ou spécifique. Fonctionne en pair à pair, voir friends to peers, puisque chacun a un pseudo et vous pouvez discuter avec la personne. C'est toujours sympa de se faire remercier d'avoir partager des fichiers avec quelqu'un !

Tautulli

Un outil de surveillance et de suivi pour Plex Media Server, offrant des statistiques détaillées sur l'utilisation. Pratique pour savoir si votre serveur fait plaisir à vos invités. Il me permet aussi d'envoyer des notifications sur Discord et bien d'autres pour savoir quand un nouvel épisode ou film de vacances est disponible.

UptimeKuma

Un moniteur de disponibilité pour garder un œil sur l'état et la performance de vos sites web et services. Il vous permet de vous envoyer une alerte où vous le souhaitez.

YouTube-DL

Un outil pour télécharger des vidéos de YouTube et d'autres sites de partage de vidéos, directement sur votre serveur. Ça me permet d'avoir les vidéos de mes chaînes favorite en local pour les regarder via Plex par exemple.

Mes services favoris

Unraid, le coeur du serveur

Unraid, c'est un peu le couteau suisse des systèmes d'exploitation pour serveurs. Basé sur Linux, il est très souple et "facile d'entretien". Vous pouvez mixer des disques durs de différentes tailles pour créer un espace de stockage sur mesure.

Vous pouvez créer un pool de stockage de masse, une partie cache pour accélérer l'upload des fichiers vers celui-ci, faire une grappe de SSD pour vos applications et machines virtuelles, etc... Il s'adapte à vos besoins.

Son gros plus ? La redondance des données, grâce à un système de parité qui protège contre la perte de données. Il est très intuitif et convivial avec une interface web facile à gérer. Vous n'aurez quasiment pas besoin de la ligne de commande, pour pas dire du tout.

Vous pouvez faire plus encore: par exemple, lancer une machine virtuelle Windows, installer une carte graphique de gaming dans le NAS, et grâce à une configuration de mise, vous pourriez très bien en faire votre PC de jeu en plus de votre NAS. L'exemple idéal me semble être pour les invités qui viennent chez moi: on est toujours frustré de pas pouvoir se faire une game de Overwatch ensemble. Peut-être que je pourrais régler ce soucis...

À noter qu'il est payant et n'est pas open-source. Mais son prix est tellement faible par rapport au gain de temps assuré, croyez moi c'est un bon investissement. Vous pouvez l'essayer 30 jours avant de vous faire un avis unraid.net/pricing.

Fun fact: l'OS est stocké sur clé USB (puis chargé en RAM ?) donc prévoyez d'en condamner une, ou en acheter une pour l'occasion.

Personnellement, j'ai essayé TrueNAS (et peut-être FreeNAS aussi, je me souviens plus ?): non merci. Si vous rêvez d'avoir constamment les mains dans le cambouis, et d'un OS libre et open-source, peut-être vous y trouverez votre bonheur.

Hardware

C'est une vielle machine – mon très ancien PC de jeu – qui fait désormais tourner mon NAS. Il est prévu de faire un gros rafraichissement dans quelques mois:

MSI Z77A-G45 (MS-7752) , Version 1.0
American Megatrends Inc., Version V2.5
BIOS dated: Tue 19 Jun 2012 12:00:00 AM CEST

Intel® Core™ i3-2120 CPU @ 3.30GHz

Memory: 8 GiB DDR3

5x16TB HDD

Honnêtement, il est assez stable. N'espérer du transcode Plex, ou pouvoir installer un container rapidement, mais il tient la route.

Il est parfois dans les choux, et me fait parfois très peur quand je dois le force reboot cependant, ça reste très rare.

Conclusion

Sans lui ma vie quotidienne serait bien différente. Il me permet d'explorer énormément de choses, facilement, de lancer des services à droite à gauche, et enfin avoir un serveur de stockage redondant pour y sauvegarder tout ce dont j'ai besoin depuis mes différents appareils (attention à ne jamais confondre redondance et sauvegarde/backup !).

J'ai tous mes media en un seul endroit, et plusieurs petits services qui sont chez moi, qui ne dépendent presque de personne (tousse tousse cloudflare tunnel tousse tousse).

Un rafraichissement de la configuration est à venir, je n'ai pas encore d'idée précise en tête mais je veux pas non plus casser la banque. Je pense tabler sur un budget de 500-600€ pour carte-mère, CPU, mémoire vive, alimentation, disque NVMe pour ce qui nécessite vraiment de la grande vitesse (genre des base de données) et double disque SSD (dont un de parité) pour ce qui est entre le stockage et le besoin de performance (applications Docker et machines virtuelle).

Une nouvelle alimentation au meilleur rendement ne serait pas de trop également, ainsi que quelques ventilateurs plus silencieux. Je pense partir sur des composants "grand public" plutôt que des gammes orientés serveurs professionnels, pour des raisons de coût.

Je ne pense pas me tourner vers un serveur de type professionnel, mais qui sait, si je trouve une affaire sur eBay par exemple...

Screenshots divers

Parlez-moi de votre expérience !

Pour plus d'information sur Unraid, rendez-vous sur unraid.net.

Vous avez déjà un NAS, souhaitez le mettre à niveau ou simplement partager votre expérience et les services les plus cools que vous faites tourner ? Parlez-en moi sur Mastodon (3615.computer/@alyx), je me ferais un plaisir d'échanger avec nous !

Comment fonctionne mon bot qui poste des paysages Minecraft aléatoires ?

Thu, 14 Dec 2023 00:00:00 GMT

Qu'est-ce que c'est ?

J'ai créé le bot @CraftViews qui envoie toutes les 4h une "photo" d'un paysage Minecraft entièrement aléatoire sur le réseau social Mastodon.

Le script, écrit en Go, va lancer Minecraft, créer un nouveau monde, se téléporter à un endroit aléatoire à la surface, prendre une capture d'écran et la poster sur Mastodon.

Exemples

Voici quelques exemples de captures générées par le bot :

Idée

J'ai toujours trouvé les paysages de Minecraft absolument fantastique. Généré aléatoirement et procéduralement, ils sont toujours uniques et peuvent être d'une incroyable beauté.

Ajoutant à cela des shaders, permettant de rendre le jeu encore plus beau, on obtient des vues magnifiques. Ajoutez à ça quelques éléments tel que de l'eau, une source de lave brillante de mille feux, un lever ou coucher de soleil et on a le plus beau des paysages.

Pour nous vieux joueurs (je joue depuis la version Alpha du jeu en décembre 2010), il y a aussi un côté nostalgique à voir ces paysages. À la façon de Edward Hopper, souvent vides de vie, ils ont quelque chose d'un peu étrange, comme si c'était abandonné de toute vie.

Dans les grandes lignes

Ce projet de bot se compose de deux fichiers Go principaux :

main.go

Ce fichier contient la logique principale pour :

Prendre les captures d'écran de Minecraft
Les publier sur Mastodon avec l'API appropriée
Gérer les erreurs et la configuration

minecraft.go

Ce fichier contient toutes les fonctions spécifiques à Minecraft :

Lancement du jeu
Création d'un nouveau monde
Téléportation à des coordonnées aléatoires
Prise de capture d'écran
Fermeture du jeu

Comment tout ça fonctionne

Le processus est relativement simple mais nécessite plusieurs étapes coordonnées :

1. Lancement de Minecraft

Le script utilise la bibliothèque robotgo pour automatiser les interactions avec l'interface utilisateur et lancer Minecraft.

2. Création d'un nouveau monde

Une fois Minecraft ouvert, le bot navigue dans les menus pour créer un nouveau monde avec des paramètres aléatoires.

3. Téléportation aléatoire

Le bot utilise la commande /spreadplayers de Minecraft pour se téléporter à un endroit aléatoire à la surface du monde généré. Cette commande est particulièrement utile car elle garantit que le joueur apparaît toujours sur un bloc solide.

4. Configuration de l'environnement

Le bot configure ensuite :

Le mode de jeu (créatif ou spectateur pour une meilleure vue)
L'heure de la journée (aléatoire)
Les conditions météorologiques

5. Prise de capture d'écran

Une fois positionné, le bot prend une capture d'écran haute résolution du paysage.

6. Publication sur Mastodon

Finalement, la capture d'écran est postée sur Mastodon avec une description générée automatiquement.

Qu'est-ce qu'on peut améliorer

Automatisation

Actuellement, le script doit être lancé manuellement. Une amélioration évidente serait de l'automatiser via :

Un serveur dans le cloud avec une tâche cron
Un service Windows/Linux qui tourne en arrière-plan
Une instance Docker déployée sur un VPS

Stockage en masse des captures

Au lieu de poster immédiatement, le bot pourrait :

Générer plusieurs captures d'écran à la fois
Les stocker localement ou dans le cloud
Les poster selon un planning défini

Shaders et resource packs aléatoires

Pour encore plus de variété, le bot pourrait :

Choisir aléatoirement parmi différents shaders
Utiliser différents resource packs
Varier les générateurs de terrain

Partager les informations du monde

Une fonctionnalité intéressante serait de partager :

Le seed du monde généré
Les coordonnées exactes de la capture
Les paramètres utilisés (heure, météo, etc.)

Cela permettrait aux joueurs de revisiter ces lieux s'ils le souhaitent.

Génération de texte alternatif

Pour l'accessibilité, le bot pourrait générer automatiquement des descriptions textuelles des images pour les personnes malvoyantes.

Conclusion

Ce petit projet m'a permis d'explorer l'automatisation d'un jeu vidéo tout en créant du contenu intéressant pour les réseaux sociaux. C'est pas grand chose mais c'est du travail honnête !

Le code source est disponible sur GitHub pour ceux qui souhaiteraient l'adapter ou l'améliorer.

Article original publié le 14 décembre 2023

Create a Mastodon Instance with Fly.io

Wed, 05 Jul 2023 00:00:00 GMT

Photo by frame harirak / Unsplash

Introduction

I wanted to create my own Mastodon instance for a few days and I went ahead during the night.

It went pretty smoothly, outside of some unrelated issues I had:

The Fly.io CLI version I was using had some weird issues where it was losing the connection to their machines
The name I used caused troubles with the DB because it was starting with digits (3615-computer).

Other than that, it took me about an hour in total from buying the domain to having a Mastodon instance up and running.

Here are the services I'm using to run my instance:

Web hosting: fly.io (~7$/month)
DNS: Cloudflare (Free)
Media storage: Cloudflare R2 (~2$/month)
Mailing: SendGrid (Free, 100 emails/day)

This guide will consider that you want to use the same stack.

Don't worry about messing something up: you should not have any issues deleting and recreating multiple times every resource we are using. The web hosting machines, the DNS records, the R2 bucket, etc… Take your time, and when you feel like everything is working, start using the instance and see how it goes.

Requirements

You will need to install:

Setup media storage with Cloudflare R2

Go to Cloudflare dashboard (https://dash.cloudflare.com/)
Click on "Create bucket"
Enter a name for your bucket. It must be unique and you won't be able to rename it later
Once created, go to "Settings" and copy your "S3 API" URL, we will use it later
Create your API keys:
- In the sidebar, "R2" > "Overview" > "Manage R2 API Tokens" > "Create API token"
- Name your token however your want
- Select "Permissions" > "Edit"
- Don't set any TTL
- Click "Create API token"
Copy your "Access Key ID" and "Secret Access Key" for later

You are done with R2.

Setup emails with SendGrid

Authenticate your domain

Go to your SendGrid dashboard
Go to "Settings" > "Send Authentication"
Authenticate your domain

Create an API key

To create your API key, go to "Settings" > "API Keys"
"Create API key"
Set a name, and select "Restricted Access"
Select "Mail Send" > "Mail Send" and enable this setting
Click on "Create and View"
Copy your secret key, you can't see it ever again

Disable tracking

Don't forget to disable tracking by going to app.sendgrid.com/settings/tracking.

Set the env vars and secrets on Fly.io

Use your secret key:

fly secrets set SMTP_LOGIN=apikey SMTP_PASSWORD=your_secret_key

In your fly.toml file:

## Sending email via SMTP also requires secrets
## named SMTP_LOGIN and SMTP_PASSWORD
SMTP_SERVER = "smtp.sendgrid.net"
SMTP_PORT = "587"
SMTP_ENABLE_STARTTLS = "always"
SMTP_FROM_ADDRESS = "noreply@example.com" # Set your from email

Deploy Mastodon using Fly.io

To deploy Mastodon with Fly.io, I've used the work of @tmm1: flyapp-mastodon.

It gives you a lot of sane defaults, a guide to explain what to do, when, and why, and also a guide to scale your instance further if needed.

Edit your fly.toml following the guide on the repository.

Some notes:

I suggest creating a fly.io organization inside your account and setting the --org parameter for the commands that require it (apps create and pg create). It makes it easier to manage your billing and projects. Otherwise, everything will get mixed up in your default personal space.
Don't forget to update the location of your services (sjc in this example) to the one you want to use (complete list).
You won't need to attach an IPv4 as Cloudflare will proxy everything for you, exposing your instance with IPv4 and IPv6.
Some commands are in the wrong order like the fly scale memory 1024 can't be run just after fly apps create xxx. No worries, here's an order that I think is better and easier to follow:

# Create your organization
flyctl orgs create my-org

# Create the machine for the mastodon app
fly apps create --org my-org mastodon-example

# Set required secrets
export SECRET_KEY_BASE=$(docker run --rm -it tootsuite/mastodon:latest bin/rake secret)
export OTP_SECRET=$(docker run --rm -it tootsuite/mastodon:latest bin/rake secret)
fly secrets set OTP_SECRET=$OTP_SECRET SECRET_KEY_BASE=$SECRET_KEY_BASE
docker run --rm -e OTP_SECRET=$OTP_SECRET -e SECRET_KEY_BASE=$SECRET_KEY_BASE -it tootsuite/mastodon:latest bin/rake mastodon:webpush:generate_vapid_key | sed 's/\r//' | fly secrets import
fly secrets set AWS_ACCESS_KEY_ID=xxx AWS_SECRET_ACCESS_KEY=yyy
fly secrets set SMTP_LOGIN=<public token> SMTP_PASSWORD=<secret token>

# Create the redis machine
fly apps create --org my-org mastodon-example-redis
bin/fly-redis volumes create --region sjc --size 1 mastodon_redis
bin/fly-redis deploy

# Create the PostgreSQL machine
fly pg create --org my-org --region sjc --name mastodon-example-db
fly pg attach mastodon-example-db
fly deploy -c fly.setup.toml # run `rails db:schema:load`, may take 2-3 minutes

# Deploy the application
fly deploy

# Scale the app machine to 1GB of RAM
fly scale memory 1024

# Set yourself as the owner of your own instance, after signing up
fly ssh console -C 'tootctl accounts modify <username> --confirm --role Owner'

Setup DNS with Cloudflare

Add your domain to Cloudflare

Go to Cloudflare dashboard (https://dash.cloudflare.com/)
Click "Add a site" and enter your domain name (example.com)
Select the Free plan and click on "Continue"
They are going to scan your DNS records, if you have any, to copy them
Update your domain's nameservers as described

If everything is ok, the check will pass.

Follow their quick start guide

During the quick start guide:

Improve security
- Enable "Automatic HTTPS Rewrites"
- Enable "Always Use HTTPS"
Optimize performance
- Enable "Brotli"
Summary: check all our options are "ON" and click "Finish"

Setup your DNS records for Mastodon

In Cloudflare's sidebar, go to "DNS > Records"
Click on "Add record"
You need to add:
- The AAAA records for your instance
  - fly ips list will show it
- The CNAME for your fly.io certificate validation
  - In the fly.io dashboard, go to your mastodon app instance > Certificates > View > Domain ownership verification
In Cloudflare's sidebar, go to "SSL/TLS > Overview"
Set the encryption mode to "Full"

Setup your DNS records to redirect any inbound emails to your personal email

In Cloudflare's sidebar, go to "Email > Email Routing"
Follow their guide to set any DNS records required (they do everything for you)
Once done, in the "Routes" tab, you should have something similar to:
- Custom addresses: noreply@example.com | Send to an email | your personal email | Active
- Catch-all address: enabled | Send to an email | your personal email as destination
- Destination addresses: your personal email | Verified

SendGrid takes care of sending emails from Mastodon, and Cloudflare takes care of redirecting any inbound emails to your personal address.

Setup your DNS records for Cloudflare R2

Go to Cloudflare dashboard (https://dash.cloudflare.com/)
In the sidebar, go to "R2" > "Overview"
Click on your bucket name > "Settings"
In the "Public access" section, click on "Connect Domain" and enter the domain or subdomain name you want to use (example: mastodon-files.example.com).
Review the settings and click on "Connect domain" and you are done

Setup Cloudflare R2 as your media storage

In your fly.toml file, add:

[env]
S3_ENABLED = true
S3_BUCKET = "3615-computer-mastodon" # Name of your R2 bucket
S3_ALIAS_HOST = "mastodon-files.3615.computer" # Subdomain of your bucket public access
S3_ENDPOINT = "https://xxx.r2.cloudflarestorage.com/" # Endpoint for your bucket (click on your bucket to see it)
S3_PERMISSION = "private"
S3_PROTOCOL = "https"

Comment the "mount" section of your fly.toml file:

## Comment out this section if you use cloud storage
# [mounts]
#   source = "mastodon_uploads"
#   destination = "/opt/mastodon/public/system"

Generate your API keys:
1. Go to Cloudflare > R2 > Manage R2 API Tokens
2. Permissions: Edit
3. No TTL (Forever)
4. Copy your access and secret keys for the next step
Set your secrets:

fly secrets set AWS_ACCESS_KEY_ID=xxx
fly secrets set AWS_SECRET_ACCESS_KEY=xxx

Improve Docker build time by using BuildKit and SemaphoreCI

Sun, 13 Sep 2020 00:00:00 GMT

Context

At my current job, we use Docker on all our environments: from local to production, and for our CI pipelines.

The first CI step is to build a Docker image that will be used during the whole pipeline and eventually deployed if tests pass.

The faster the build, the faster the tests and others things developers care about will start, so it's crucial to not "waste" minutes on builds.

We mostly have web projects, and they all have some kind of dependencies:

PHP packages through composer
JS packages through npm
PHP extensions
etc...

All of these dependencies can require a lot of time to be installed. And so, in order to keep the build time as short as possible, caching their installation could make our build much shorter.

While most CI providers have tools to cache these dependencies in one way or another, ideally, you'd like to cache Docker layers to make things easier. You won't have to set up different tools for different package providers, and you can even cache other things like apt-get, apk, etc... that you might run during your build.

Here's a typical multi-stage Dockerfile that we use for our PHP applications:

FROM composer:2 as composer-build
...
FROM node:10-alpine as npm-build
...
FROM php:7.4-apache as php-extensions-build
...
# Final build, "app", our base for others
FROM php:7.4-apache as app
...
# Various stages for release/dev/etc...
FROM app as release
...
# Back dev stage, install backend dev tools here
FROM app as dev-back
...
# Front dev stage, install frontend dev tools here
FROM npm-build as dev-front
...
# Test stage, used during CI/CD and local testing
FROM app as test
...
# Default docker build target will be 'app'
FROM app

We use multi-stage Docker build so we can pick exactly what we want for release images, or for our dev environments, keeping our images as light as we can.

Issues we were facing

Caching all docker stages manually is hard

The easiest solution, at first sight, would be to build each stage separately and tag them:

docker build -t my-project:composer-build --target=composer-build .
docker build -t my-project:npm-build --target=npm-build .
docker build -t my-project:php-extensions-build --target=php-extensions-build .
# etc...

And send everything to a container registry such as AWS ECR:

docker push aws_account_id.dkr.ecr.region.amazonaws.com/my-project:composer-build
docker push aws_account_id.dkr.ecr.region.amazonaws.com/my-project:npm-build
docker push aws_account_id.dkr.ecr.region.amazonaws.com/my-project:php-extensions-build
# etc...

Then you'd have to pull each of these stages before starting to build your image.

But you may have noticed it's now a lot of things to manually setup, and maintain if you add a new stage at some point.

Running builds in parallel is hard

For example, composer-build and npm-build do not depend on each other, so you could build them in parallel.

But you would have to write your own parser, or just come up with some bash scripts to do that, and maintain it over time too. That would be tedious! Especially when you know this dependency graph is already described in your Dockerfile.

Maybe I'm missing something, but as far as I know, without BuildKit, you can't easily build stages in parallel.

AWS ECR or any other remote registry is too slow to cache our stages

Another issue that might depend on your CI provider: pushing Docker images to the remote registry (AWS ECR, GCP Container Registry, etc...) is taking a long time.

Pulling/pushing each stage to a remote registry is going to take a significant amount of your build time step. Plus, it would clutter your registry with intermediate stages that you don't care about long-term wise.

Solution: Using BuildKit

To solve our issues related to caching and parallel builds, we are now using BuildKit.

Thanks to BuildKit project, we can easily solve all our issues with a single command:

buildctl build ... \
  --output type=image,name=localhost:5000/myrepo:image-test,push=true \
  --export-cache type=registry,ref=localhost:5000/myrepo:buildcache,push=true \
  --import-cache type=registry,ref=localhost:5000/myrepo:buildcache \
  --opt target=test

As we are asking to target the test stage, we are also sure to build only what we want without having to maintain any kind of manual script.

What we are saying to BuildKit is:

The final image created must be pushed to localhost:5000/myrepo:image-test
Export/Import cache to/from localhost:5000/myrepo:buildcache
We want to build the test image, so we pass --opt target=test as a parameter.
- This way all our test tools will be there for next CI steps.
- To create the release image, just change it to --opt target=release and name the new image as you'd like.

Solution: Use your CI provider's private Docker registry

I'm not sure if other CI providers have something similar, but SemaphoreCI had a good idea to deploy their own Docker registry, where it's much faster to push your cache and images.

The push time is excellent, much better than on AWS ECR.

Thanks to this, we can use their private Docker registry to push/pull our intermediate stages and cache layers.

Before / after + screenshots

On a basic Laravel application, here are the results.

Before BuildKit:

After BuildKit:

Before using BuildKit, the pipeline was taking around ~3min30s. It's now taking ~2min. Though, it depends on what cache layers need to be rebuilt. If none of them are changing, like if you are running again the same build and it's already cached, it takes ~14s.

What improvements I'd like to make?

Tracing our CI pipelines

I'm a fan of observability and I want to apply this methodology on our CI/CD pipelines too. BuildKit comes with a way to export traces to Jaeger, and it can be visualized like so:

By doing so, we could track over time the build time easily for each step. We could see the effects on what steps. We can also avoid wasting time optimizing a step if there is another that takes 90% of the build time.

Move out from CI the push/tag release steps

You may have noticed that I am building, pushing, and tagging the release candidate image during the CI pipeline. I did not realize while upgrading our CI/CD pipelines that it does not make sense to have these things there.

Ideally, I'd like to have something like:

CI:
- Build test image
- Run tests
- Build release candidate image
CD:
- Push release candidate image to AWS ECR
- Tag release candidate as "release" on AWS ECR
- Deploy to X
  - Deploy to Kubernetes development
  - Deploy to Kubernetes staging
  - Deploy to Kubernetes production

By doing so, I could make the CI pipeline even shorter and our developers would receive automated feedback faster.

That would give something like: