| 15 Mar 2026 |
 Nonno Felice | Grazie | 09:46:35 |
| 16 Mar 2026 |
 Andrea Ciceri | @gecko4242 come si chiamava il provider di gpu che ci hai mostrato? | 11:35:35 |
| Andrea Ciceri | era vast.ai ? | 11:42:32 |
 gecko | Yup | 12:27:10 |
 Alessandro 🤔➖☀️🖌 | Io ho una soluzione molto becera con file browser al momento, ma non è molto mantenuto quindi non lo espongo al pubblico | 17:26:18 |
 Francesco | Non so se è quello che cerchi ma un mio amico mantiene questo https://github.com/9001/copyparty | 23:09:48 |
| Francesco | Ha una UI un po' complicata ma fa veramente di tutto ed è molto veloce | 23:10:21 |
 Lorenzo | Il mio tool preferito in assoluto | 23:10:42 |
| Lorenzo | Però sadly non ha ancora abbastanza features per sostituire nextcloud per dire | 23:11:04 |
| 17 Mar 2026 |
| Nonno Felice | Sembra bello ma a me servirebbe anche un minimo di gestione utenti | 05:59:41 |
| Alessandro 🤔➖☀️🖌 | https://github.com/9001/copyparty#user-changeable-passwords
Qualcosina sembra esserci | 06:11:33 |
| Nonno Felice | Ho letto meglio il README e sembra ci sia la gestione dei permessi su file e directory | 06:15:27 |
| Nonno Felice | Può essere un buon candidato | 06:15:58 |
 Edoardo Piccolotto | Ne ho sentito parlare bene, ma non l'ho mai provato. Me lo segno per una guida. | 06:32:59 |
| Andrea Ciceri | Opencloud altrimenti, c'é il modulo su NixOS
https://opencloud.eu/ | 07:11:33 |
| Nonno Felice | Avevo visto questo ma mi ero perso la parte di self hosting | 07:13:52 |
| Andrea Ciceri | Io lo self-hosto ma ho avuto qualche problema a capire come configurarlo. Tra l'altro con lo uso con kanidm per gli utenti | 07:14:55 |
| Andrea Ciceri | Se vuoi ti mando la mia config | 07:15:05 |
| Nonno Felice | Che vita da kanidm | 07:15:19 |
| Nonno Felice | Kanidm è tipo Keycloak / Zitadel? | 07:15:48 |
| Andrea Ciceri | Sì, più minimale ma ti lascia dichiarare tutto da modulo; utenti, client, etc... | 07:28:49 |
| Francesco | Le password e i secret come vengono gestiti? | 07:48:54 |
| Andrea Ciceri | Per le password degli utenti se ricordo correttamente con un comando cli generavo un qrcode/url che poi davo all'utente per settare la sua password (e passkey o otp). Pero' gli utenti e i ruoli sono dichiarati nella config.
La password dell'utente admin la ho dichiarata con agenix.
Per i segreti dei client mi sa che facevo sempre imperativamente con la cli, e poi li mettevo in agenix per essere usati dai vari servizi. Pero' forse si possono generare separatamente e "provisionare" direttamente a kanidm | 10:48:26 |
| Andrea Ciceri | https://github.com/oddlama/kanidm-provision
Comunque non e' kanidm a permetterti di fare tutto dichiarativamente, e' oddlama che ha scritto in tool apposta che poi viene usato nel modulo nixos | 10:49:50 |
| Andrea Ciceri | Tra l'altro mi sa che me lo consiglio qualcuno di questo gruppo, non ricordo chi pero' | 10:50:37 |
| 18 Mar 2026 |
| Edoardo Piccolotto | 
Download Giusto per ridere... | 11:46:53 |
| gecko | Ah che bello, ora ho woodpecker-ci attacato a GitHub e che autoscala gli agenti su hetzner su macchine badass. Also atticd. Son un bimbo felice ora. | 21:38:08 |
| 19 Mar 2026 |
| Andrea Ciceri | sono curioso di sapere meglio come lo hai implementato, ho fatto molti esperimenti analoghi. | 11:21:56 |
| gecko | Ho messo woodpecker-server sul mio server insieme all'autoscaler configurato per tirare su istanze sul cloud di Hetzner on demand (default 0 agenti).
Ho installato l'app GitHub così ho i pallini verdi sui commit.
Sullo stesso server ho messo atticd usando come backing storage un bucket S3 di Hetzner e poi mi creo grossomodo una cache per progetto.
Nella CI metto come segreto un token di GitHub (che uso per ghcr, il container registry di GitHub) e il token per poter pullare e pushare sulla cache atticd.
Non ho un forge (Gitea, Gitlab o simili) perché mi va bene usare GitHub.
Non ho un container registry perché i container devo usarli in giro per il mondo e la mia speranza è che ghcr abbia una CDN fatta benino.
C'è qualcosa in particolare che ti interessa? | 15:15:01 |
| 20 Mar 2026 |
| Andrea Ciceri | I vari repo sono tutti flake, giusto? E la CI dei progetti e' semplicemente buildare tutti gli output?
Ogni job (triggerato da push o eventi simili su GitHub suppongo) crea una istanza su hetnzer nel senso di un host cloud (una vps proprio) con su nix che esegue un comando per buildare i vari output quindi? Quindi 1 job = 1 comando che builda tutti gli output?
Chiedo perche' in passato facevo una cosa simile usando nix-fast-build (tra l'altro supporta attic nativamente) che in output ti da un json con lo stato (build fallita o meno) per ogni output del flake, e poi partendo da quel json popolavo i vari checks di GitHub (le varie spunte verdi di fianco al commit, una per ogni output).
Il problema e' nix-fast-build loggava tutto assieme e non si capiva niente quando qualcosa falliva, quindi poi ho deciso di creare un job per ogni output del flake ed eseguirli in parallelo sulla stessa macchina (stesso nix store e demone) cosi' da non avere il rischio che la stessa cosa venga buildata due volte (nix ti dice tipo "waiting for lock blah blah" e aspetta che la stessa derivazione venga buildata in un altro job), almeno cosi' ho i log separati per output. Anche questa soluzione non mi soddisfa appieno pero'.
Comunque parlando di cache ho appena scoperto questa: https://github.com/Mic92/niks3
Altra cosa che ho fatto (altro ambito qui) e' stata decidere di usare un singolo server bare metal corazzato di hetzner invece, non scala come soluzione ma avere un unico store sull'ssd condiviso tra tutti i repo dell'organizzazione velocizzava parecchio le build. Se uno ha clienti diversi e non vuole "mischiare gli store" non va bene come soluzione poi. | 09:43:35 |
