flutter run -d 00007046-004082773524571B

per testare l’applicazione, scollegando il cavo l’appl’icazione non riparte e viene mostrato il messaggio:

In iOS 14+, debug mode Flutter apps can only be launched from Flutter tooling, IDEs with Flutter plugins or from Xcode.
Alternatively, build in profile or release modes to enable launching from the home screen.

approfitto per ricordarvi che Flutter in debug costruisce un “app sandbox” che comunica costantemente via USB/network con l’host per:

• Hot reload / hot restart
• DevTools (debugger, performance, logging)
• Dart VM service

Da iOS 14 in poi, per questioni di sicurezza, Apple blocca l’apertura di queste app dalla home se non sono state avviate dal tooling (Flutter/Xcode). Non è un bug: è una limitazione voluta.

Soluzione: installa in release o profile mode

Queste due modalità compilano AOT (codice macchina nativo ARM) e non richiedono connessione all’host. Funzionano a cavo scollegato.

Passaggi da fare:

1. Verifica prerequisiti sull’iPhone (solo 1a volta)

• Sblocca iPhone e tienilo sullo schermo home durante l’installazione.
• Developer Mode ON: Impostazioni → Privacy e sicurezza → Modalità sviluppatore → ON (riavvio richiesto).
• Fiducia computer: quando compare il popup "Fiducia di questo computer?" su iPhone → tocca Fiducia e inserisci il codice.

2. Controlla che Flutter veda il device

flutter devices

Dovresti vedere iPhone di XXXX (mobile) in elenco (non simulator). Se non lo vede:

brew install libimobiledevice ideviceinstaller ios-deploy

3. Installa in RELEASE mode (scelta consigliata per usarlo senza cavo)

flutter run --release -d 

oppure con il nome:

flutter run --release -d "iPhone di XXXX"

⚠️ Se ti chiede la password del keychain / permessi di accesso a Xcode: rispondi Consenti sempre (il sandbox dell’IDE spesso inghiotte questi dialoghi, per questo dal terminale esterno è più sicuro).

4. Alternative se flutter run fallisce per il signing

Se incontri errori di code signing / provisioning profile:

1. Apri Xcode → Apri progetto: ios/Runner.xcworkspace
2. Seleziona target Runner → Tab "Signing & Capabilities"
3. Team: seleziona il tuo account Apple Developer (anche free va bene)
4. Bundle Identifier: metti qualcosa di unico (es. com.tuonome.xxxxx)

Poi ridai:

flutter run --release -d "iPhone di XXXX"

5. Modalità Profile (utile se vuoi anche performance monitor, ma sempre standalone)

Se vuoi anche misurare performance:

BashRun

flutter run --profile -d "iPhone di XXXX"

6. Verifica cavo scollegato

Quando il terminale stampa:

💪  Running with sound null safety
🔥  To hot restart changes while running, press "r" or "R".

L’app è installata e avviata. Adesso puoi:

1. Premere q nel terminale per chiudere il processo Flutter (non disinstalla niente).
2. Staccare il cavo USB.
3. Aprire l’app dgtv direttamente dalla home di iOS: ✅ funzionerà.

enjoy!

Non si può saltare dalla 10 alla 13 direttamente

Debian non supporta l’aggiornamento diretto da una release vecchia a una recente saltando le versioni intermedie. Ogni salto di release ha la sua procedura documentata, i suoi repository e — soprattutto — le sue trappole. Il percorso corretto da Debian 10 (Buster) a Debian 13 (Trixie) passa quindi per tutte le tappe intermedie:

Buster → Bullseye → Bookworm → Trixie

Tre upgrade a catena, sì, ma nessuno di questi è complicato se si segue l’ordine giusto. In questa guida riporto la procedura completa che ho applicato, compresa la gestione dei repository archiviati e delle chiavi GPG legacy.

Prima di partire: le precauzioni (non saltatele)

Qualunque sia la tappa, alcune regole valgono sempre:

• Backup completo prima di ogni salto: al minimo /etc, /home, l’elenco dei pacchetti (dpkg --get-selections > pacchetti.txt) e, se possibile, uno snapshot o un’immagine della macchina.
• Spazio su disco: verificatelo con df -h, con attenzione a /boot che si riempie facilmente con vecchi kernel.
• Repository di terze parti: i file in /etc/apt/sources.list.d/ (GitLab, Docker, NodeSource, PostgreSQL…) sono la causa numero uno di upgrade falliti. Commentateli prima di ogni salto e riattivateli solo dopo aver verificato la compatibilità con la release di destinazione.
• Console, non SSH cieco: se operate da remoto, usate screen o tmux, così una connessione caduta non vi lascia a metà di un dpkg --configure -a.
• Una tappa alla volta: riavviate, verificate, solo poi passate alla successiva.

Tappa 1 — Da Buster a Bullseye (Debian 10 → 11)

Il problema: entrambe le release sono archiviate

Debian 10 e Debian 11 non sono più nei repository ufficiali: sono finite su archive.debian.org. I primi comandi quindi puntano lì.

Passaggio 1 — Portare Buster al massimo aggiornamento possibile

apt update && apt upgrade
apt full-upgrade

Passaggio 2 — Aggiornare le sorgenti di Buster verso l’archivio

Sostituire il contenuto di /etc/apt/sources.list con:

deb http://archive.debian.org/debian buster main contrib non-free
deb http://archive.debian.org/debian-security buster/updates main contrib non-free

Poi:

apt update
apt full-upgrade

Passaggio 3 — Impostare le sorgenti di Bullseye

Sovrascrivere /etc/apt/sources.list con:

deb http://archive.debian.org/debian bullseye main contrib non-free

Nota importante: non esiste una riga di sicurezza separata. Gli aggiornamenti di sicurezza di Bullseye (il cui LTS è terminato nell’agosto 2024) non sono più pubblicati — l’archivio contiene l’ultimo stato disponibile. Questa tappa è quella da fare per primo e più in fretta possibile: Bullseye archiviato non riceve più nulla.

Siccome i file Release archiviati hanno scadenze (Valid-Until) ormai passate, disattiviamo il controllo creando /etc/apt/apt.conf.d/99no-check-valid-until con:

Acquire::Check-Valid-Until "false";

Passaggio 4 — L’upgrade vero e proprio

apt update
apt upgrade --without-new-pkgs
apt full-upgrade

Durante il processo APT chiederà come gestire i file di configurazione modificati a mano: di regola conviene tenere la versione attuale e verificare dopo le differenze.

Passaggio 5 — Pulizia e riavvio

apt --purge autoremove
reboot

Verifica:

cat /etc/debian_version   # deve dire 11.x

Tappa 2 — Da Bullseye a Bookworm (Debian 11 → 12)

Da qui in poi le cose migliorano: Bookworm è ancora supportato, quindi si torna ai mirror ufficiali.

Passaggio 1 — Aggiornare Bullseye

apt update
apt full-upgrade

Passaggio 2 — Nuove sorgenti

Sovrascrivere /etc/apt/sources.list con:

deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
deb http://deb.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware

Due accorgimenti:

• Rimuovere il file di scorciatoia creato nella tappa precedente: rm /etc/apt/apt.conf.d/99no-check-valid-until — con i repository attivi vogliamo che il controllo di validità sia attivo.
• non-free-firmware è una componente introdotta con Bookworm: aggiungetela se usate firmware (schede Wi-Fi, GPU, ecc.).

Passaggio 3 — Upgrade

apt update
apt upgrade --without-new-pkgs
apt full-upgrade
apt --purge autoremove
reboot

Verifica: /etc/debian_version deve dire 12.x.

Tappa 3 — Da Bookworm a Trixie (Debian 12 → 13)

Procedura identica alla precedente, con sorgenti:

deb http://deb.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware
deb http://deb.debian.org/debian-security trixie-security main contrib non-free non-free-firmware

E poi:

apt update
apt upgrade --without-new-pkgs
apt full-upgrade
apt --purge autoremove
reboot

Trixie porta novità visibili come APT 3 (output più compatto e colorato) e versioni molto più recenti di Python, PHP e GCC: se sul server girano applicazioni con dipendenze specifiche, consultate le note di rilascio ufficiali prima del salto.

WARNING: database "gitlabhq_production" has a collation version mismatch
DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.
HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE gitlabhq_production REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

Significa che è necessario ricostruire gli indici del database postgreSQL. Vediamo in sequenza la procedura da fare:

Effettua prima un backup di sicurezza:

gitlab-backup create

Fermiamo gitlab:

gitlab-ctl stop

Avviamo solo postgreSQL:

gitlab-ctl start postgresql

Accediamo ora a postgreSQL per eseguire le query che ci interessano:

gitlab-psql -d gitlabhq_production

E qui digitiamo:

SET statement_timeout = 0; REINDEX DATABASE gitlabhq_production;

A seguire:

ALTER DATABASE gitlabhq_production REFRESH COLLATION VERSION;

Ed infine usciamo con:

\q

Riavviamo ora gitlab:

gitlab-ctl start

Verifichiamo che tutti i servizi siano UP:

gitlab-ctl status

e ricontrolliamo che non ci siano più messaggi di warning:

gitlab-rake gitlab:env:info

enjoy!

Si può in alternativa usare unar, procediamo in questo modo:

brew uninstall unrar
brew install unar

unar archivio.rar

enjoy!

Basta aprire una nuova scheda di Firefox e digitare nella barra degli indirizzi:

about:processes

Questo mostrerà un elenco di tutte le finestre con il titolo e la RAM usata e, oltretutto, la possibilità di scaricare direttamente la scheda per liberare RAM.

enjoy!

Uno dei principali punti di forza di UV è la velocità: l’installazione delle dipendenze e la creazione degli ambienti virtuali richiedono spesso solo pochi secondi, anche per progetti di grandi dimensioni. Questo è possibile grazie all’implementazione in Rust e a un sistema di caching molto efficiente.

Oltre alla rapidità, UV mette a disposizione un unico comando per gestire l’intero ciclo di vita di un progetto Python: creazione dell’ambiente virtuale, installazione delle librerie, sincronizzazione delle dipendenze e gestione del file di lock. Il risultato è un workflow più ordinato e facilmente riproducibile sia in sviluppo sia in produzione.

L’adozione di UV è in costante crescita anche grazie alla sua compatibilità con gli standard moderni dell’ecosistema Python, come il file pyproject.toml. Questo permette di integrarlo facilmente in progetti esistenti senza dover modificare radicalmente la struttura del codice.

Per chi sviluppa applicazioni Python, prova nuove librerie o gestisce pipeline di Continuous Integration, UV rappresenta oggi una valida alternativa agli strumenti tradizionali, capace di ridurre i tempi di lavoro e semplificare la gestione delle dipendenze.

Per installare UV possiamo digitare:

curl -LsSf https://astral.sh/uv/install.sh | sh
source $HOME/.local/bin/env

Per installare l’ultima versione di python digitiamo:

uv python install

una versione specifica di python, ad esempio la 3.13, digitiamo:

uv venv --python 3.13

A questo punto, per integrarlo in un progetto esistente possiamo digitare:

uv init
uv add -r requirements.txt
uv run main.py

enjoy!

Nel mio esempio il proxy è attivo sulla macchina host, pertanto lo si può “puntare” con il nome host.docker.internal avendo l’accortezza di aggiungere, come vedremo in avanti, nel file compose.yaml:

      extra_hosts:
        - "host.docker.internal:host-gateway"

Ipotizziamo che il Dockerfile contenga qualcosa di questo tipo:

# Stage 1: Dipendenze
FROM node:20-alpine AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app

dobbiamo aggiungere le necessarie variabili facendolo diventare:

# Stage 1: Dipendenze
FROM node:20-alpine AS deps
ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

ENV HTTP_PROXY=${HTTP_PROXY}
ENV HTTPS_PROXY=${HTTPS_PROXY}
ENV NO_PROXY=${NO_PROXY}
ENV http_proxy=${HTTP_PROXY}
ENV https_proxy=${HTTPS_PROXY}
ENV no_proxy=${NO_PROXY}

RUN apk add --no-cache libc6-compat
WORKDIR /app

Importante: Se l’applicativo cerca la variabile proxy in altro modo, ad esempio pip lanciato nel docker file, bisognerà dichiarare il proxy anche li in modo specifico, es:

COPY requirements.txt .
RUN python -m pip config --user set global.proxy $HTTP_PROXY
RUN pip install --no-cache-dir -r requirements.txt

ora passiamo a modificare il compose.yaml che da:

services:
  app:
    image: gest:latest
    build:
      context: .
      dockerfile: Dockerfile
      args:
        BUILD_GIT_SHA: ${BUILD_GIT_SHA:-unknown}
        BUILD_DATE: ${BUILD_DATE:-unknown}
    container_name: app-club
    restart: unless-stopped

dovrà diventare:

services:
  app:
    image: gest:latest
    build:
      context: .
      dockerfile: Dockerfile
      args:
        BUILD_GIT_SHA: ${BUILD_GIT_SHA:-unknown}
        BUILD_DATE: ${BUILD_DATE:-unknown}
        HTTP_PROXY: http://host.docker.internal:8888
        HTTPS_PROXY: http://host.docker.internal:8888
        NO_PROXY: 127.0.0.1,localhost
      extra_hosts:
        - "host.docker.internal:host-gateway"
    container_name: app-club
    restart: unless-stopped
    extra_hosts:
      - "host.docker.internal:host-gateway"

Nota: il TAG extra_hosts è ripetuto due volte, perché uno viene passato come ARG e l’altro viene usato dalla machcina docker.

enjoy!

Per l’isntallazione bastano pochi comandi:

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | bash
apt-get install -y gitlab-runner

Poi accediamo all’interfaccia web di GitLab, andiamo nel progetto che ci interessa, poi “Settings” e “CI/CD“. Qui apriamo la sezione “Runners” e clicchiamo sul pulsante “Create project runner“. La procedura mostrerà un comando da scrivere nel terminale per agganciare il runner del progetto, in particolare c’è una chiave che serve per abilitare il runner. Recuperiamo la chiave e poi digitiamo:

sudo gitlab-runner register \
  --non-interactive \
  --url "SITE_URL" \
  --token "RUNNER_TOKEN" \
  --executor "docker" \
  --docker-image alpine:latest \
  --docker-pull-policy "if-not-present" \
  --description "docker-runner"

sostituendo SITE_URL con l’url del sito dove avete installato GitLab e RUNNER_TOKEN con il token recuperato nella procedura “Create project runner” avviata prima.

enjoy!

Partiamo con docker:

apt-get update
apt-get install apt-transport-https ca-certificates curl gnupg lsb-release

Rimuoviamo eventuali pacchetti installati prima:

apt remove $(dpkg --get-selections docker.io docker-compose docker-doc podman-docker containerd runc | cut -f1)

Installiamo la chiave GPG

curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

Aggiungiamo il repository ad APT:

tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Effettuiamo l’installazione vera e propria dell’ultima versione disponibile:

apt-get update
apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Nota: per installare una versione specifica, al posto dell’ultimo comando, facciamo:

apt list --all-versions docker-ce

VERSION_STRING=5:29.6.1-1~debian.12~bookworm
apt install docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING containerd.io docker-buildx-plugin docker-compose-plugin

Ora verifichiamo se tutto è andato a buon fine:

systemctl status docker
systemctl start docker

e proviamo ad avviare un’immagine di esempio

docker run hello-world

Nota: per disinstallare docker:

apt purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras
rm -rf /var/lib/docker
rm -rf /var/lib/containerd

e rimuoviamo anche il riferimento al repository ed alla firma:

rm /etc/apt/sources.list.d/docker.sources
rm /etc/apt/keyrings/docker.asc

Infine, se vi interessa un sistema visuale per la gestione delle istanze docker, posso consigliarvi portainer che potete recuperare da github. Per l’installazione di default:

docker volume create portainer_data
docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Nota: se la macchina in questione è dietro un proxy, potreste ricevere il seguente errore:

docker: Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers).

Questo sicuramente è legato al fatto che docker non riesce ad utilizzare il proxy. Su Debian consiglio quanto segue:

mkdir /etc/systemd/system/docker.service.d

editare il file /etc/systemd/system/docker.service.d/http-proxy.conf ed inserire i parametri del proxy, es:

[Service]
Environment="HTTP_PROXY=http://proxyHost:proxyPort"
Environment="HTTPS_PROXY=http://proxyHost:proxyPort"
Environment="NO_PROXY=localhost,127.0.0.1"

Ricaricare l’unità di systemd:

systemctl daemon-reload

Verificare che le impostazioni siano state correttamente lette:

systemctl show --property Environment docker

riavviare il servizio docker, eseguire entrambe i comandi:

systemctl restart docker
service docker restart

E poi ripetere l’installazione di portainer, passando anche qui il proxy:

docker run -d -p 8000:8000 -p 9443:9443 -e "HTTPS_PROXY=http://proxyHost:proxyPort" --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Voglio ricordare che è possibile passare il proxy su docker in altri due modi:

Inserire nel file /etc/default/docker le informazioni del proxy, come segue:

export http_proxy='http://proxyHost:proxyPort'
export https_proxy='http://proxyHost:proxyPort'
export no_proxy=localhost,127.0.0.1

oppure creare il file ~/.docker/config.json ed inserire quanto segue:

{
"proxies": {
      "defaults": {
        "httpProxy":"http://proxyHost:proxyPort",
        "httpsProxy":"http://proxyHost:proxyPort",
        "noProxy":"localhost,127.0.0.1"
      }
    }
}

In ogni caso, ricordatevi di riavviare il servizio con:

service docker restart

Per verificare le impostazioni passate alle macchine guest, basterà eseguire questo comando:

docker container run --rm busybox env

enjoy!

Per quanto riguarda l’installazione basterà digitare nel terminale:

curl -fsSL https://pi.dev/install.sh | sh

Consiglio successivamente di installare il plugin :

pi install npm:pi-setup-custom-providers

A questo punto possiamo accedere a pi (scrivendo pi nel terminale) e poi avviando la configurazione del plugin:

pi
/setup-custom-providers

Verrà mostrato una maschera di scelta in cui selezioniamo “Add new provider“, poi “From preset“, poi “ollama” e completeremo con l’inserimenti del parametri richiesti.

Per scegliere il modello da usare di default bastaerà digitare nell’interfaccia di pi:

/models

enjoy!