This week a new open image model came out of Spain 🇪🇸: Iris-3B, with just 3B parameters. I set it up on a GPU and put it against GPT Image, FLUX and friends with the same prompts.

One image per prompt, no fuss. Here are the results, since the prompts and the details don’t fit in the Twitter thread (in Spanish).

Before anyone jumps at me: I know this isn’t a fair comparison. I’m not claiming a 3B model beats GPT Image. What I wanted to see is how far such a small model is from the best ones and what it can be useful for.

What Iris-3B is

It comes from speridlabs and it’s Apache 2.0. It has 3B parameters, plus a frozen 4B text encoder (Qwen3-VL-4B-Instruct).

On their site they compare it with much bigger models, and it ties with them on one of the benchmarks:

Keep in mind these numbers are their own. On DPG and GenEval it trails Z-Image and Qwen-Image, but beats FLUX.1-dev, which has 12B.

They also say where it struggles: long text inside the image, positions and counting objects.

What “no VAE” means

What caught my eye the most is that it generates the image directly in pixels, with no VAE.

Almost every image model (Stable Diffusion, FLUX…) doesn’t generate the image as such. A VAE (Variational Autoencoder) compresses it into something much smaller, the latent space. The model works on that, and at the end the same VAE turns it back into pixels. In FLUX, for example, a 1024×1024 image is handled as a 128×128 grid.

Like everything, this has its upsides and downsides. Compressing saves a huge amount of compute, but you lose information, and it shows mostly in textures and fine detail.

Iris skips that compression step and generates the pixels directly. It’s more expensive to compute, but nothing in between eats away detail.

How I tested it

I took the prompts from BudgetPixel Arena. There, around 20 models render the same prompt and people vote without knowing which is which. Once voting closes, you can see which model made each image and by how much it won.

With Iris I did this:

• The prompt text as is, untouched.
• 1024×1024, seed 42, 100 steps and CFG 3.
• A single run per prompt. Whatever came out, goes.

In each comparison the Iris image comes first, with the arena winner next to it. The arena images are by BudgetPixel AI, licensed CC BY 4.0.

Architecture: the sauna

Exterior of a Scandinavian modernist lakeside sauna pavilion, blackened timber cladding, pale granite plinth, copper roof, winter blue-hour light glowing through narrow windows, viewed from a snowy reed-lined path, straight structural geometry and plausible construction.

One of my favourites. Charred timber, granite, copper roof, everything in place and with clean geometry.

That said, the prompt asked for warm light coming through the windows and there’s no trace of it, and it looks a bit like a render. In the arena, GPT Image 2 won with 80% of the votes (see all 20 versions).

Landscape: the swamp

A cypress swamp at foggy sunrise after overnight drizzle, dark tea-colored water threading between moss-draped trunks; slick root knees and floating leaves lead toward pale trees disappearing into layered mist.

The fog, the roots and the floating leaves look great. But the water was supposed to be tea-coloured and it came out almost red.

In the arena, Muse Image 1.0 and Qwen Image 3.0 won with 68% (see all 20 versions).

Photography: portrait and documentary

Editorial portrait of an adult man in his early 40s wearing a charcoal wool fisherman’s sweater, one hand loosely holding its ribbed cuff. His thoughtful, slightly tired expression rests against a muted ochre studio backdrop, shaped by gentle directional window light.

Candid documentary photograph of an adult bicycle mechanic repairing a flat tire outside a neighborhood workshop, soft overcast daylight, 35mm lens with moderate depth of field, greasy fingerprints, dust, and tiny metal shavings visible on the workbench.

Photography is where it surprised me the most. Both pass for real photos, and the mechanic one has the grease and the metal shavings on the bench.

Where it slips is the details. The sweater was supposed to be a cable-knit fisherman’s sweater and it came out as a plain crew neck, plus a few small artefacts in the top left. FLUX 3 Image won with 91% (portrait) and Kling v3 with 88% (mechanic).

Illustration: watercolour and mechanical heart

Ink-and-watercolour illustration of an adult astronomer mapping constellations from a glass-domed observatory, surrounded by brass instruments and flowering night plants. Indigo, lavender, and pale gold palette, delicate linework, serene atmospheric detail.

A beautifully intricate mechanical heart floating alone in deep darkness, designed like an exquisite piece of horological sculpture. Its polished brass, copper, and dark steel chambers are partially open, revealing layers of tiny interlocking gears, delicate springs, pistons, and precision mechanisms within. Sections of crystal-clear glass expose deeper workings, while slender tubes carry a faintly glowing fluid through the heart like an artificial bloodstream. Tiny gears turn and pistons move, suggesting that the heart is genuinely functioning. Fine mechanical filaments curl outward like veins and arteries, catching subtle highlights from the warm inner glow. Elegant steampunk aesthetic, dramatic cinematic lighting, rich metallic textures, intricate reflections, mysterious atmosphere.

The watercolour nails the style, the palette, the brass and the flowers. The heart is very good, glowing fluid tube and all, though less intricate than the prompt asks for.

GPT Image 2.5 Sunburst won both, the heart with 100% of the votes, so the bar was high (watercolour, heart).

Its weak spots: counting and text

Since they say it struggles with counting objects and with long text, I went straight for that.

Exactly three green apples and two yellow pears on a white plate, the plate on a blue tablecloth, nothing else on the table.

Three apples and two pears, first try. In the arena, ImagineArt 1.5 Pro won with 100% (see all 20 versions).

Inside a quiet clockmaker’s workshop, brass gears and tiny tools gleam beneath green-shaded lamps; “ORRERY HOUSE” is engraved in crisp serif letters on a dark walnut sign above the repair counter.

It got the text right too. Not a single wrong letter, green lamps included, although the sign looks painted rather than engraved.

Mind you, it’s two words. They say it struggles with long sentences and I haven’t tried that. GPT Image 2.5 Flare won with 88% (see all 20 versions).

And before anyone gets carried away: in an earlier run, at 1344×768 and with another seed, the fruit came out as 2 and 2. With one image per prompt there’s a lot of luck involved, so if you try it, generate several.

How long it takes

I ran it on an NVIDIA RTX PRO 6000 Blackwell Max-Q (96 GB) I had set up for a talk. PyTorch 2.11 with CUDA 13.0, the official code and its Gradio demo as they come: FP32 weights, BF16 generation, no quantisation and no tuning.

Batching doesn’t help. A single image already keeps the GPU at 100% (about 325 W), so it’s a compute-bound workload, the opposite of generating text with an LLM.

Wrapping up

For an open 3B model, I’m pretty impressed. It doesn’t beat the best ones, but it gets closer than I expected, and you can run it on a single GPU under Apache 2.0.

If you want to try it:

• Model: huggingface.co/speridlabs/iris-3b
• Paper: arXiv 2610.09450
• Code: github.com/speridlabs/iris-3b
• Demo: huggingface.co/spaces/speridlabs/iris-3b
• Arena prompts and images: BudgetPixel Arena (BudgetPixel AI, CC BY 4.0)

Basic Concepts:

• Metrics: These are quantitative measures that provide information about the performance of a system. Examples include CPU usage, memory, network latency, and more. In Grafana, these are usually visualized in dashboards using time series.

• Logs: These are records of events that occur within an application or system. They contain detailed information about system performance, errors, transactions, etc. Loki is a popular tool to manage logs, allowing their storage, search and visualization.

Correlation in Grafana and Loki:

1. Data Integration: Grafana allows you to integrate metrics and logs into a single dashboard. For example, you can have time series graphs showing resource usage along with dashboards showing relevant logs.

2. Contextual Searching: When examining specific metrics, such as a spike in CPU usage, you can query Loki to find logs during that specific period. This helps to quickly identify the root cause of problems observed in the metrics.

3. **Log Enrichment: Loki allows the enrichment of logs with tags and metadata, which facilitates their correlation with specific metrics. For example, you can tag logs with information about the environment, the service or the application instance, facilitating its search and correlation with metrics.

4. **Alerts and Analytics: Grafana allows you to configure alerts based on metrics and logs. For example, a high CPU usage alert can be correlated with specific error logs, providing a more detailed view of potential problems.

5. Temporal Visualization: Grafana’s ability to visualize temporal data facilitates visual correlation. You can see how events recorded in the logs align with changes in metrics over time.

Best Practices:

• Consistency in Labeling: Maintain consistent nomenclature for labels in both metrics and logs.
• Synchronized Timing**: Ensure that timestamps on metrics and logs are synchronized to facilitate correlation.
• Integrated Dashboards**: Design dashboards that combine metrics and logs in a way that reflects the relationship between the different types of data.

In summary, the correlation of metrics and logs in Grafana, leveraging Loki tools, provides a comprehensive view of the status and performance of systems, allowing to identify and solve problems more efficiently and effectively.

Loki

Loki is a log management tool that focuses on indexing only log metadata, such as Prometheus-style tags. The log data is stored compressed in blocks in storages such as S3, GC or locally. Loki’s index is based on these tags, leaving the original log message unindexed. However, this implies that queries in LoqQL that filter based on log content require loading all corresponding blocks.

Key features of Loki include:

• Efficient memory usage for indexing logs.
• Multitenancy.
• LogQL, a query language similar to Prometheus’ PromQL, which allows generating metrics from log data.
• Scalability, being able to operate both in a single binary and in microservices.

Loki stands out for splitting queries into small parts and executing them in parallel to speed up the search in large volumes of data. Unlike other systems that require large full-text indexes, Loki’s index is significantly smaller than the volume of logs ingested, which keeps static costs low and allows controlling query performance through horizontal scaling.

Tags in Loki define a flow and any change in the value of a tag creates a new flow. High cardinality in tags (many tags or tags with wide range of values) can lead to a large number of different flows, which can slow down and make operation expensive.

Modes

Loki operates in different modes:

• Monolithic: all components in a single binary.
• Simple scalable: separation between read and write.
• Microservices: distribution in several services that can be deployed with Helm.

:warning: Monolithic is only intended for development and testing, not for production.

Components

Loki components include:

• Distributor: validates and preprocesses log streams, rate limits and distributes them to ingestors.
• Ingestor: writes log data to long-term storage and responds to in-memory queries.
• Query Frontend (optional): optimizes queries, handling large loads and distributing them evenly.
• Querier: handles queries using LogQL, fetching data from both ingestors and long-term storage.

Architecture

Distributor

The Distributor is responsible for handling incoming log streams, being the first stop on the write path. It performs validation of each stream to ensure its correctness and that it complies with the established limits. Valid chunks are split and sent to multiple ingesters. It is a stateless component, which facilitates scalability.

• Reference: Distributor at Loki

Ingester

The Ingester writes log data to long-term storage backends and returns log data for in-memory queries. It handles a lifecycle within the hash ring, with states such as PENDING, JOINING, ACTIVE, LEAVING, UNHEALTHY. Each log stream is accumulated in chunks in memory and then flushed to storage. It is key in data replication to mitigate data loss. On the write path, they temporarily store the logs in memory and periodically dump them to storage systems such as DynamoDB, S3, Cassandra, among others. In addition, on the read path, they return log data that is in their memory.

• Reference: Ingester on Loki

Query Frontend

The Query Frontend is an optional service that provides API endpoints for queriers and accelerates the read path. It performs query tuning and keeps queries in an internal queue. It works in conjunction with queriers, which act as workers. It is a stateless component, and it is recommended to run some replicas to benefit from fair scheduling.

• Reference: Query Frontend in Loki

Querier

Querier handles queries using the LogQL query language, fetching logs from both ingesters and long-term storage. It performs internal deduplication of data that have the same timestamp, tag set and log message. It plays a crucial role in the read path.

• Reference**: Querier on Loki

Index Gateway

If indexed storage, such as DynamoDB or Cassandra, is used for log indexes, the Index Gateway can be used to download and query indexes, thus reducing the number of direct queries to these indexed storage services.

Compactor

In configurations using indexed storage, the Compactor is responsible for compacting the indexes and improving their efficiency, both in terms of cost and query performance.

Ruler

This service is used for the evaluation of rules and alerts. It allows [[Loki]] to evaluate LogQL expressions on a regular schedule and execute actions based on the results of these evaluations.

Write and Read Path

Write Path

The write path manages how log data is collected, processed and stored. It involves the following steps and components:

1. Log Collection: It starts with log collection, usually through agents such as Promtail, Fluentd or Fluent Bit.

2. Distributor: The collected logs are sent to the distributor. The distributor validates the logs and distributes them to the ingesters. The validation includes verifying the tags and the size and time limits of the logs.

3. **Ingester: The ingesters receive and temporarily store the logs in memory. The logs are organized in “chunks”.

4. Long-Term Storage: Compressed chunks are stored in long-term storage systems.

Read Path

The read path describes how stored log data is queried and retrieved. The steps and components involved are:

1. Query: Queries are generally performed through Grafana using the LogQL query language.

2. Query Frontend: If in use, the query frontend receives the query and performs optimizations.

3. Querier: The querier is the service that actually executes the query. It first queries the ingesters for recent data and then queries the long-term storage.

4. Results: The results of the query are returned to the user.

I hope it has helped you.

Well, since practically all my services are self-hosted on my server, I decided to buy a UPS (Uninterruptible Power Supply) so that if the power goes out for any reason, the server won’t shut down abruptly and potentially damage a component, especially an HDD.

Since I only wanted it for the server and not much else, I chose the Salicru SPS 500 ONE, which is more than enough for the server and anything else I might connect to it in the future.

Once I had it connected, I started looking into how to integrate it with Home Assistant. I had previously seen people who had integrated UPS systems into their HASS, so I began to investigate.

First, the obvious part: for the UPS to communicate with our Home Assistant, we need to connect the UPS via USB to the device where we have Home Assistant running.

For our Home Assistant to communicate with the UPS, we need NUT, a tool that acts as a bridge between the UPS and Home Assistant.

In our case, we are going to run NUT in Docker along with Home Assistant in the same docker-compose.yml.

Detecting the New USB Device of the UPS

We will execute the following command:

(We need to have usbutils installed)

# lsusb

Docker

Once we have these two figures, we will substitute them into our compose file (the complete compose is later in the post).

    devices:
      - /dev/bus/usb/001/003

Once we have this information, it’s time to deploy our two services in Docker:

With Traefik

version: '3.9'

services:

  homeassistant:
    image: homeassistant/home-assistant:latest
    restart: unless-stopped
    volumes:
      - /data/homeassistant:/config
    environment:
      - TZ=Europe/Madrid
    network_mode: host
    labels:
      - traefik.enable=true
      - traefik.http.routers.homeassistant.entryPoints=web-secure
      - traefik.http.routers.homeassistant.rule=Host(`homeassistant.crstian.me`)
      - traefik.http.services.homeassistant.loadbalancer.server.port=8123
      
  nut-upsd:
    container_name: nut-upsd
    image: upshift/nut-upsd
    restart: unless-stopped
    environment:
      - UPS_DRIVER=blazer_usb
    ports:
      - '3493:3493'
    devices:
      - /dev/bus/usb/001/003

Without Traefik

version: '3.9'

services:

  homeassistant:
    image: homeassistant/home-assistant:latest
    restart: unless-stopped
    volumes:
      - /data/homeassistant:/config
    environment:
      - TZ=Europe/Madrid
    ports:
      - '8123:8123'
    network_mode: host
      
  nut-upsd:
    container_name: nut-upsd
    image: upshift/nut-upsd
    restart: unless-stopped
    environment:
      - UPS_DRIVER=blazer_usb
    ports:
      - '3493:3493'
    devices:
      - /dev/bus/usb/001/003

Important

In my case, the UPS driver is “blazer_usb” but not all UPS devices use the same driver. To find out which driver you would need if you are not using an SPS 500, you can check here by entering your model which will tell you the required driver.

Home Assistant

Now let’s go to our Home Assistant to add our NUT:

We add a new NUT integration and set up the connection with ours.

Here are the default username and password; if you want to change them, you can add it as an environment variable in the compose. More info here.

And once added, we can set up a dashboard with all the information.

I hope this has been helpful!

List of routers that I recommended:

• BPI-R4
• Linksys MR7350

Cloudflare Token

First of all we will need a cloudflare token, we can get it from here https://dash.cloudflare.com/profile/api-tokens with our account.

Create a new token with this configuration:

Zone, Zone: Read
Zone, DNS: Edit

Configure OpenWRT

Now we need to install the following packages (in my case via shell but it can also be done from Luci):

For OpenWRT 19.07 we need to install ddns-scripts_cloudflare.com-v4 For OpenWRT 20.02 or higher the package is ddns-scripts-cloudflare.

For OpenWRT 20.02 or higher the package is ddns-scripts-cloudflare.

opkg update
opkg install ddns-scripts-cloudflare luci-app-ddns
opkg install wget ca-certificates
opkg install curl ca-bundle

Once everything is installed we go to the router IP in the browser Services -> Dynamic DNS.

Edit the IPv4:

• Select DDNS Service provider cloudflare.com-v4.
• In Lookup Hostname we place our subdomain or domain for example in my case murcia.crstian.me, in Domain the same but in this format murcia@crstian.me
• In username Bearer and in password our cloudflare token.

Once this is done, click on Save and Apply.

Testing

To see that it is working we can see it in Services -> Dynamic DNS and we see how it takes our IP and if we go to the DNS of cloudflare we see that it has changed it.

First we need to create an OAuth application in github and our RPC secret can be seen in this post or also in the drone docs.

To create our RPC secret we will do the following:

$ openssl rand -hex 16 bea26a2221fd8090ea38720fc445eca6

Once we have our client ID and our client secret we proceed to create our docker-compose.yml to deploy our drone container.

version: '3.7'

services:
  drone-server:
    container_name: drone-server
    image: drone/drone:1
    restart: unless-stopped
    volumes:
      - ./drone:/data
    environment:
      - DRONE_GITHUB_CLIENT_ID=<Your_Client_ID>
      - DRONE_GITHUB_CLIENT_SECRET=<Your_Client_secret>
      - DRONE_RPC_SECRET=<Your_RPC_secret>
      - DRONE_SERVER_HOST=<Your_URL>
      - DRONE_SERVER_PROTO=https
      - DRONE_USER_CREATE=username:<Your_Github_username>,admin:true
    labels:
      - traefik.enable=true
      - traefik.http.routers.drone.entryPoints=web-secure
      - traefik.http.routers.drone.rule=Host(`Your_URL`)
      - traefik.http.routers.drone.tls.certresolver=default

Then we deploy our container with:

$ docker-compose up -d

Once our server is up, we are going to run our host runner executor and for this we download the drone-exec binary from the drone web site:

$ curl -L https://github.com/drone-runners/drone-runner-exec/releases/latest/download/drone_runner_exec_linux_amd64.tar.gz | tar zx

Once downloaded we have to move it to /root/bin/ and then in the configuration.nix add the following:

environment.etc.drone-runner-exec = {
  target = "drone-runner-exec/config";
  text = ''
  DRONE_RPC_PROTO=https
  DRONE_RPC_HOST=<Your_URL>
  DRONE_RPC_SECRET=<Your_RPC_secret>
  DRONE_UI_USERNAME=root
  DRONE_UI_PASSWORD=root
  '';
};

systemd.services.drone-runner-exec = {
  description = "Drone Exec Runner";
  startLimitIntervalSec = 5;
  serviceConfig = {
    ExecStart = "/root/bin/drone-runner-exec service run --config /etc/drone-runner-exec/config";
  };
  wantedBy = [ "multi-user.target" ];
  path = [ pkgs.git pkgs.docker pkgs.docker-compose ];
};

Next:

nixos-rebuild switch

Now we access our Drone URL and authenticate with our Github account.

So far we have set up our infrastructure with Drone, from here on everyone can do what they need, in my case let’s see how I have it set up so that every time I create a post and push it to the github repo, the deployment is automatically done and the nginx container is updated with the modifications.

Once inside the web of our drone, we activate the repository that we want in my case the repository of this blog.

To perform the configuration our repository must have 3 essential files in the repository root:

.drone.yml

In this file we basically configure the actions to be performed by drone in our case simply performs the docker build and then raises the container.

kind: pipeline
type: exec
name: default

platform:
  os: linux
  arch: amd64

steps:
- name: build
  commands:
    - docker build -t bloglord .

- name: run
  commands:
    - docker-compose down -v
    - docker-compose up -d --build

Dockerfile

Little to comment on this file, simply copy the contents of public in the html folder of the nginx container.

FROM nginx:alpine
COPY public/ /usr/share/nginx/html

docker-compose.yml

The compose of the container where we provide traefik labels.

version: '3.7'

services:
  bloglord:
    image: bloglord
    container_name: blog
    restart: unless-stopped
    labels:
      - traefik.enable=true
      - traefik.http.routers.bloglord.entryPoints=web-secure
      - traefik.http.routers.bloglord.rule=Host(`blog.crstian.me`)
      - traefik.http.routers.bloglord.tls.certresolver=default

networks:
  default:
    name: bloglord-network

Once all this is done we can check it by performing a commit where we will see how we have automated the modifications to the blog.

If something went wrong we could see it in the activity feed of each commit.

And our Drone would be ready for everything we need.

I hope you found it useful.

Sources

• https://github.com/Raniita/app-drone-tests
• https://rubynor.com/blog/2020/06/setting-up-drone-ci-for-rails-apps/
• https://docs.drone.io/server/provider/github/

Introduction

A robust reverse proxy configuration is critical for any self-hosted setup that has elements exposed across the Internet. While reverse proxy services are often used for load balancing and security reasons, most home server owners use them to route requests directed to different domains or subdomains to different hosts or internal services. In my case you can see all my services at https://server.crstian.me/.

In this post we are going to see how to configure Traefik as a reverse proxy such as NGINX.

Let’s see how to securely route requests to a subdomain pointing to a specific port in a container, all securely through HTTPS.

What is a reverse proxy?

A reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as if they originated from the Web server itself.

Which explained in a more vulgar way would be in our case to access different services that we have locally but from the outside and in this case Traefik does the routing work and depending on the subdomain it takes us to one service or another.

Load balancing

A reverse proxy can distribute the load of incoming requests to multiple servers, with each server running its own application area.

Reverse proxies provide an additional layer of security by never revealing the IP address of the backend server that actually handles the requests. This means that attackers will normally only be able to attack the reverse proxy servers themselves.

SSL encryption

A reverse proxy can be configured with SSL encryption in order to automatically generate certificates for each route with Let’s Encrypt.

Configure Traefik v2

In our case we are going to set it up with a docker-compose.yml

version: '3.7'

services:
  traefik:
    image: traefik:latest
    network_mode: host
    volumes:
      - ./config/:/etc/traefik/
      - /var/run/docker.sock:/var/run/docker.sock

Now let’s configure Traefik with its configuration file traefik.toml.

api:
  dashboard: true

entryPoints:
  web:
    address: ":80"
  web-secure:
    address: ":443"

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false
  file:
    filename: /etc/traefik/config.yml
    watch: true

certificatesResolvers:
  default:
    acme:
      email: your email
      storage: /etc/traefik/acme/acme.json
      tlsChallenge: {}

Docker Integration

Traefik uses the API of each provider to find routing information and configure itself accordingly.

Entry points

Entry points simply define the ports on which Traefik will listen to receive packets. Two entry points are configured here, web and websecure for ports 80 and 443.

Container configuration

The last step to expose our container using Traefik is to add some Docker tags that will allow Traefik to find it.

These are the necessary tags:

labels:
      - traefik.enable=true
      - traefik.http.routers.yourservicename.entryPoints=web-secure
      - traefik.http.routers.yourservicename.rule=Host(`subdomain.your.domain`)
      - traefik.http.routers.yourservicename.tls=true
      - traefik.http.routers.yourservicename.middlewares=user:password
      - traefik.http.services.yourservicename.loadbalancer.server.port=serviceport    

• yourservicename tenemos que cambiarlo por el nombre de nuestra aplicación, por ejemplo netdata

• subdomain.your.domain tenemos que cambiarlo por nuestro subdominio que queremos que apunte a nuestra aplicación, por ejemplo netdata.crstian.me

• serviceport aquí tenemos que cambiarlo por el puerto que use nuestro servicio

• user:password en caso de que queramos ponerle usuario y contraseña para entrar a ese servicio debemos usar usuario y contraseña como si fuera htaccess

An example of a service I have running on my server with its docker-compose.yml

version: '3'
services:
  caddy:
    image: abiosoft/caddy
    volumes:
      - '/storage/shared:/srv'
    labels:
      - traefik.enable=true
      - traefik.http.routers.caddy.entryPoints=web-secure
      - traefik.http.routers.caddy.rule=Host(`downloads.crstian.me`)
      - traefik.http.routers.caddy.tls.certresolver=default
      - traefik.http.services.caddy.loadbalancer.server.port=2015
      - traefik.http.routers.caddy.middlewares=torrent
      - traefik.http.middlewares.torrent.basicAuth.users=mypasswordbro
    restart: unless-stopped

Traefik Dashboard

Finally we are going to configure inside traefik itself so that we can access its dashboard through a subdomain.

Inside the config.yml file we have to have the following:

traefik:
      rule: Host(`traefik.crstian.me`)
      entryPoints:
        - "web-secure"
      service: api@internal
      middlewares:
        - auth
      tls:
        certResolver: default

It should show this dashboard

How to configure and use Logitech G502 on Arch Linux

After switching to Arch Linux from Windows and having a Logitech G502 I needed to configure both dpi and configurable buttons, even turn off the leds at night.

Thanks to a friend who taught me piper program made in Python which allows us to configure our G502 and more models here the list

In my case using Arch Linux I already had the package in the AUR, but in the github repository of piper we have explained how to install it Wiki

Once installed it is as easy as launching the program.

In this screen we can modify the dpi and sensitivity.

In this we can change the functions of the different buttons.

Finally here we can modify the leds.

To apply the changes we simply have to push the right corner “Apply”.

Git is the most popular version control system.

Git is the most popular version control system and for good reason. In this post, we will go over the basics of what git is and how to use it inside the command line. We will examine and work with all the basic and most important commands, such as add, commit, push…

Git is an essential version control technology for developers and programmers.

A version control system allows us to track the history of a collection of files. These versions are stored in a specific location, usually called a repository.

Prerequisites

If you have a GitHub account and have installed and configured Git on your computer, skip to the next step.

If you don’t have a GitHub account, go here and sign up for a free one. See how to install and configure Git here. We need the tool with terminal in case we are on windows. Follow the links to download and install it.

You can check if Git is installed using the following command:

git—version

Creating our first repository

In our pc we are going to create a folder for our project. We will call it for example demo-git.

Using the command console we move to that folder and add a local repository using the following command:

git init

With this command we simply initialize an empty local repository, now our folder is initialized as a Git repository and we can do all the git stuff in it.

Adding files to our local repository

After we have been working on our project and created some files, it is time to prepare those files for uploading.

For example we are going to add the files named index.html and style.css.

To add each file separately we use the following command:

git add index.html

In case you want to add both files at the same time:

git add index.html style.css

Finally, if you want to add all the files contained in the folder:

git add .

To see the files we have added we can use the following command:

git status

“Commit” the changes

After adding those files to the staging area, we can create a checkpoint called a commit. Each commit is usually created after we have finished working on a certain feature or fixing a certain bug. These commits can be used to control which features were added in which commits and by whom, so we can easily control or even revert the whole commit if there are any bugs in the code.

A commit in a repository could be said to be like a giant copy and paste, but even better!

To add a commit we use the following command:

git commit -m “commit message”

The -m means that we are going to add a certain message.

In this example, we are going to create our first commit, we are going to make a commit with the message “First commit”.

We can do this by typing git commit -m “First commit”.

The commit message should indicate what code changes were made in that particular commit.

“Pushing” your changes to your master branch

When all the files are added and committed, the only thing left to do is to “push/upload” them to our remote repository.

But before that we have to so to speak link our local repository to our github repository with the following command:

git remote add origin (Link de nuestro repo)

The first time we push files to a remote directory, we have to execute the following command:

git push -u origin master

From the second push we will only have to execute the following:

git push

Some commands that may also be useful:

List all branches

git branch

Switching between different branches

git checkout -b

Revert last commit changes

git revert

That’s all!

I hope it served as an introduction to create your first repository 😉.