Nix Milan - Public Room Timeline

	Nix Milan	107 Members
	https://milano.nix.pizza/	7 Servers

Load older messages

Sender	Message	Time
31 Oct 2025
Francesco	Riguardo a rimuovere gli eseguibili di nixos: puoi specificare `nix.enable = false`	11:31:47
Francesco	In reply to x71c9 Ottimo, grazie Poi se vuoi disabilitare delle altre robe di default dai un'occhiata a `nixos/modules/profiles/minimal.nix` su nixpkgs	11:33:24
Nonno Felice	In reply to x71c9 Avevo letto che per evitare modifiche alla macchina, si potevano eliminare anche i comandi di nix. Ma comunque non è la parte fondamentale. Volevo capire appunto se utilizzare container, come con docker, oppure ci sono soluzioni migliori. Io ho provato a pacchettizzare un'applicazione Go usando container2nix ed ho avuto un'immagine con la runtime minima per eseguirlo	11:32:20
x71c9	E invece utilizzando sempre e solo NixOS, scegliereste i Container OCI o i Container di NixOS?	11:51:13
Alex0	In reply to x71c9 Ah ok, non ci devono essere downtime. Per downtime si puo' intendere anche un paio di secondi chiariamo Ecco cosa intendo per "critico" Alcune aziende non possono nemmeno andare down per qualche secondi siccome gli costerebbe tantissimo	12:02:42
Alex0	In reply to x71c9 Cosa intendi per critico? Comunque mi interessa di più sapere il processo di sviluppo per avere facilemente lo stesso sistema sulla macchina locale e sul server di produzione. Posso stare sicuro con nix-shell? Oppure è meglio utilizzare i container? (Scusate l'ignoranza ma sono alle prime armi con Nix) Ahh capito Container2nix è un modo per buildare immagini docker se vuoi usare containers In ogni caso nix-shell è usato per la shell di sviluppo, non del "pacchetto" in sé, cosa che in realtà a te in produzione interessa di più (però sì, i pacchetti dentro la nix-build sono in subset solitamente della tua nix-shell) Il problema che potresti avere con il pacchetto è se chiama altri programmi a runtime ad esempio Puoi sempre runnarlo in locale o usare nixos tests per fare tests che puoi usare sia in locale che in ci ad esempio Un'altra cosa che ti consiglio è di pinnare le versioni di nixpkgs o qualsiasi dipendenza su nix che usi (se non stai usando già i flakes)	11:49:57
Alex0	In reply to x71c9 Ah ok, non ci devono essere downtime. Dipende tutto da ciò Se hai 1 solo server ed usi systemd (nativo quindi), il servizio verrà restartato quindi finché il servizio non riparte ed inizia ad accettare richieste, there will be downtime Also, se fallisce lo start del servizio rip, there will definitely be downtime Se hai più macchine/vm di nixos puoi fare blue/green deployment (qualcuno ne parlava ieri, se vuoi ti menziono sul messaggio) Se usi containers/kubernetes puoi fare la stessa roba analoga Non so come funziona a livello di setup dichiarativo però	11:57:51
Alex0	In reply to Tonio È fatto apposta per fare blue/green deployment. Gestiamo il rollout delle macchine nuove, tirandone giù una vecchia e deviando con il load balancer il traffico sulle altre nove, istanziandone una nuova e spostando il traffico anche su quella. Nel caso in cui abbiamo migrazioni di DB schema, topic pulsar o altro che richieda uno stop the world programmiamo un outage. Avere un mercato limitato ad un solo fuso orario è comodo per programmare le cose alle 3 di notte quando hai un picco negativo di utenti connessi. @x71c9	11:58:24
Federico T	fortunatamente non si è spaccato niente	12:13:38
Federico T	In reply to Alex0 Per downtime si puo' intendere anche un paio di secondi chiariamo Ecco cosa intendo per "critico" Alcune aziende non possono nemmeno andare down per qualche secondi siccome gli costerebbe tantissimo una volta stavo per fare una attività in una emittente televisiva nazionale il cliente mi chiede se sono sicuro che non ci sarà disservizio, gli dico si certo mi guarda, e mi fa: "in alcuni posti i downtime si misurano in minuti. In altri, in secondi. Noi li misuriamo in fotogrammi persi. Sei sicuro?"	12:13:30
x71c9	Credo che proverò i container NixOS	13:07:24
x71c9	Vorrei utilizzarlo a lavoro. Sì, direi che “secondi” possa andare bene. Poi immagino dipenda anche dall’applicazione ovviamente.	13:07:10
Alessandro Bertulli	In reply to Andrea Ciceri https://www.meetup.com/nix-milano/events/311737096 Ho conosciuto i ragazzi di rev.ng, sono una startup del Politecnico	13:16:03
Lucio	Esatto	18:53:59
Lucio	Domanda per voi: sarebbe possibile in un flake avere tutti i packages definiti in systemPackages, home.packages e programs come output del flake? L'obbiettivo sarebbe poter eseguire nix run di un singolo pacchetto nix (con o senza configurazione program) tra quelli definiti nel flake senza referenziarli uno a uno come output con devshell o packages. Quindi, ad esempio, potrei fare nix run flakeRemoto#neovim e avere nella shell il mio neovim/nixvim (configurato tramite hm programs) oppure una certa versione di flameshot con overlay. A volte mi capita di eseguire tasks per qualche giorno su dispositivi non miei e questo mi aiuterebbe a fare un porting temporaneo della parte di mia configurazione che serve per quel task (senza riscrivermela o modificarla al momento).	18:48:11
Lucio	Eh ma non la voglio tutta, perché magari è un sistema con poco spazio e mi servono solo 2-3 programmi	18:51:49
Marco Turchetto	Magari puoi fare una funzione che prende una config home-manager valutata ed estrae la lista di packages e la mette in flake.packages	18:52:05
Marco Turchetto	Magari puoi fare una Shell che importa come package la tua config home-manager?	18:50:51
Marco Turchetto	Per programs è più complicato probabilmente devi creare una Shell, mettere i packages e poi linkare tramite envvar la home e chissà cosa altro...	18:58:04
Marco Turchetto	Però packages è diverso da programs... Ad esempio per git, avrai la versione di git che vuoi, ma non la config del nome utente e email	18:53:21
Marco Turchetto	E tu invece vuoi programs?	18:56:33
Marco Turchetto	Però mentre packages è una lista, programs è un ambiente unico, quindi qua secondo me ti schianti ad avere una shell per program, magari fai un mini HM per queste evenienze?	19:01:31
1 Nov 2025
Alessandro Candido	Nella shell puoi metterci esattamente quello che vuoi tu, sia in termini di configurazioni che di pacchetti. Tra l'altro, puoi comporle a piacimento. Alla fine Nix e' un linguaggio completo, per cui puoi definirti una o piu' shell base, mixin vari, e generare le combinazioni dinamicamente	03:16:26
Alessandro Candido	Come per i pacchetti che puoi eseguire con `nix run`, le shell le puoi eseguire con `nix develop` https://nix.dev/manual/nix/2.23/command-ref/new-cli/nix3-develop	03:12:15
Alessandro Candido	Ma perche' non ti crei semplicemente una serie di shell come output del flake?	03:10:20
Alessandro Candido	Tra l'altro, se vuoi un ambiente di sviluppo per un certo linguaggio, o un certo tipo di servizi abbastanza frequenti, puoi anche non costruirti tutto da zero, ma usare componenti fatti da altri https://devenv.sh/	03:18:46
Alessandro Candido	`nix develop` ti permette anche di entrare nell'ambiente in cui viene fatta la build di un pacchetto. Ma se tu non hai gia' un pacchetto di riferimento, anziche' farne uno fittizio (che non ti serve separatamente) fai direttamente una `devShell`	03:17:39
Lucio	In reply to Alessandro Candido Ma perche' non ti crei semplicemente una serie di shell come output del flake? Si, il punto era non definire a priori le shell come output perché non so a priori cosa mi servirà della mia conf.	07:39:29
Lucio	In reply to Alessandro Candido Nella shell puoi metterci esattamente quello che vuoi tu, sia in termini di configurazioni che di pacchetti. Tra l'altro, puoi comporle a piacimento. Alla fine Nix e' un linguaggio completo, per cui puoi definirti una o piu' shell base, mixin vari, e generare le combinazioni dinamicamente Fare una shell base e poi usare dei mixin non è male come idea. Dici che si potrebbe generare dinamicamente a runtime una shell con le cose che servono? Tipo specificando il nome dei vari moduli? (Es. Binary, android, wapt, ...)	07:42:21
Alessandro Candido	Ma... cosa intendi esattamente con "a priori"?	07:42:42

Show newer messages

Back to Room ListRoom Version: 10