When publishing Go code, the usual practice is to distribute the sources directly from the forge that hosts them: github.com/org/project, framagit.org/org/project, and so on. It is convenient, but it durably ties the import path to the chosen provider. The day you migrate from one forge to another, all your users have to update their imports, and every historical fork keeps pointing at the old address.

Fortunately, the go-import mechanism lets you decouple the import path from the actual hosting location of the code. All it takes is exposing, on a domain of your choosing, an HTML page containing a <meta name="go-import"> tag that describes where the sources live.

In software engineering, complexity is often seen as a sign of competence.

Indeed, a simple system looks suspicious, while a complex system looks serious.

What is the value of a decade of success?

In my final year of engineering school, I built a CTF platform. At the time, no software like CTFd existed. Everything had to be built from scratch.

It took me a lot of thinking to arrive at an architecture that looks simple in hindsight: serve static files, generated on demand, to reduce the attack surface. Standard Unix services glued the components together. Low-level containers isolated services from one another.

Reading some discussions between developers or software architects, one might think that the smallest web application today requires a distributed infrastructure, a Kubernetes cluster, and several specialized cloud services.

Yet many web services (including those that receive several thousand visitors per day) can work perfectly well with a much simpler architecture.

Here is a hands-on account of the infrastructure I use for my production projects, some of which exceed 5,000 daily visitors, and which I also applied for years during a cybersecurity competition with more than 250 on-site participants.

Southern China is not an obvious destination for digital nomads. When you think of digital nomadism, you imagine Bali, Lisbon, or Chiang Mai. Not Shenzhen, Guangzhou, or Huizhou. And yet, I spent three weeks exploring these three Chinese cities, one week in each, and it’s an experience I won’t soon forget!

This article is obviously not a tourist guide, but rather an account of what it’s really like to live and (try to) work in Southern China when you have the freedom to choose your workplace. With the difficulties, the surprises, and especially that Great Firewall I’ll be talking about.

Remember when listening to music was as simple as pressing a single button? Those days when you’d walk into a room, flip a switch on your amplifier, and instantly be surrounded by your favorite tunes? There was something magical about that simplicity—no computers to boot up, no apps to navigate, no complex digital interfaces to wrestle with.

The Problem with Modern Audio Systems

As our music collections went digital and streaming services became the norm, we gained incredible access to virtually unlimited music libraries. But something was lost along the way: simplicity.

Today, generative AIs meet many uses, and it would be a shame not to take advantage of them. However, in the age of the GDPR, it’s legitimate to question the exposure of customer or partner data when relying solely on AI providers whose data processing remains opaque.

Having myself participated in the construction of one of these new virtual assistant services, I offer here a simple guide to starting up a machine and evaluating the performance of your AI application, or to offering your employees access to sovereign AI, with the aim of easily comparing the different models available.

It’s possible to use generative AI without sharing your data with companies or states that raid our data.

The world of free software is full of applications for evaluating and using generative AI. After extensive testing, I present here the cloud-init file for deploying your own LocalAI instance in under 5 minutes.

Why LocalAI?

LocalAI is a free software application designed to offer a local, self-hosted alternative to AI service providers. The application features an API compatible with that of OpenAI. The idea is to be able to replace calls to OpenAI from any existing application in the blink of an eye: simply change the domain to which the API points.

As an engineering school teacher and technical lecturer, I’m often asked to give demonstrations, in addition to the classic slide show. Like any organized lecturer, I can’t do without my notes, elapsed time, etc., which are given to me by presenter screen software. This kind of software requires an extended display, i.e. the computer screen and the video projector display 2 different things.

The disadvantage of demonstrations is that the application window you want to show cannot be displayed on both screens at the same time. I’ve tried to solve this problem, in particular to avoid having to do demos while craning my neck, as the window necessarily had to be on the video projector screen, which is really not comfortable.

Union file systems are a mechanism for merging two or more file systems, to present them unified, under a single mount point for the user.

The main idea behind this mechanism is to be able to alter the contents of the first file system (e.g. the contents of a CD-ROM) by writing all changes (additions, deletions, modifications) to the second (which could be a disk partition, a USB stick, …).

I installed the continuous integration service Woodpecker, to replace DroneCI, which the company that bought it decided to bury. As Woodpecker is a fork of the latest free version of Drone, its use is broadly similar.

However, the teams have taken different directions on certain aspects, and communication with agents/runners, which used to be via websockets, is now carried out in Woodpecker using the GRPC protocol.

The solution proposed by the Woodpecker documentation is to use 2 domains: one will be used for the web interface and the REST API, the second will be used for GRPC. Is this really necessary?