>>>>> "fn" == franchi@modula net <fran...@modula.net> writes:
>> > Peraltro non capisco tutta questa acrimonia contro systemd. >> >> Problemi eliminati dalla configurazione di Debian: >> >> - cambiamento dei nomi dei device di rete - log (solo) binario >> >> Se non cogli i problemi di queste due cosine, mi sa che non sei un >> sysadmin professionista. >> fn> Mi sembra una risposta piuttosto impertinente: ma ? normale quando fn> si vuol difendere a tutti i costi una causa persa. Impertinente? Sicuramente schietta e frettolosa forse. ? quest'ultimo l'unico motivo per cui potrebbe rincrescermi di essere stato ruvido. fn> Quando uno ? a corto di argomenti passa all'attacco personale fn> cercando di delegittimare chi lo contraddice. Nessun attacco personale. Comprendo benissimo che possa non fare ne caldo ne freddo se oggi sui server le schede di rete si chiamano in modo diverso da ieri. Penso che la cosa non importi a nessuno se non ad un sysadmin che si trova a dover cambiare degli script locali(1) di una batteria di server di produzione solo perch? qualcuno ha avuto una brillante e innovativa idea stile IBM(*). Non c'? nulla di male. Ci sono esperienze e sensibilit? diverse. (1) locali, ovvero non della distribuzione. Diciamo legati all'applicazione che porta i soldi a casa. (*) Quando ho raccontato ad una sysadmin decisamente in gamba (e che conosce MOLTO bene anche AIX) come volevano cambiare i nomi delle schede di rete, mi ha detto "Ma gli ? venuta una grave forma di IBM-ite"? Parlando di impertinenza, saresti peraltro tu presuntuoso (e non poco) a definirmi privo di argomenti. Ma penso che al momento ti girassero un tantino. fn> Piuttosto sarebbe meglio riflettere sul perch? Red Hat Enterprise fn> Linux Red Hat ? la mamma di Systemd. Se non lo usano loro... Avere un boot pi? veloce su un server serve a molto poco. I server teoricamente non dovrebbero fermarsi mai. Se si fermano qualcosa ? andato storto. Il tempo di riavvio non ? cos? importante n? se lo confronti con gli uptime n? (spesso) coi downtime. L'unica utilit? la vedo per il commerciale che deve mostrare quanto ? reattivo il servizio di cloud elastico che deve vendere (peccato che nella realt? il tempo per l'utente sar? diverso). (Sulle macchine personali un boot rapido ? comodo. Ma a volte scegliere cosa far partire e come farlo partire ? meglio che parallelizzare. Mi rendo conto che forse non tutti sono in grado di fare questa scelta) Reagire ai cambiamenti dell'HW? Un server lo compri con la configurazione che ti server e quando lo dismetti per sostituirlo ? ancora tale e quale. Anche quelli creati in macchine virtuali sul cloud. La reazione ai cambiamenti nell'HW e nelle reti circostanti ? una pacchia su un portatile e probabilmente anche in un desktop. Devo dire che il mio portatile ha imparato a reagire con soluzioni che mi sa siano pi? leggere di systemd :) :). fn> e Suse Enterprise Linux, che sono due bellissime Alcuni suoi developers "hanno peso" anche in altre distribuzioni e questo spiega buona parte della diffusione. fn> distribuzioni OPEN SOURCE a pagamento, Open Source a volte per finta. Qualche anno fa provo a creare un cluster con CentOS. CentOS ? una distribuzione ottenuta compilando le sole parti libere di RH. Creo il cluster, all'inizio tutto bene, poi un casino della madonna, si perdeva i nodi... Un bordello. Qualche tempo dopo parlo con un collega certificato RH che candidamente mi dice "la prima versione che avevano rilasciato libera era dannatamente bacata"... Allegria! fn> hanno adottato sistemd per fn> default: gli mancher? un sysadmin professionista anche a loro? Sul bellissime ho qualcosa da ridire. Bellissima ? Debian, non solo ha quantit? di programmi maggiore, un sistema di pacchettizzazione migliore, ma quando Debian dice che una release ? stabile, quella release ? una roccia. Magari il software ? pi? datato, non ci sono le ultimissime novit?. Ma ci puoi contare che la tua macchina sia stabile. Cosa che non si pu? sempre dire di RH (Suse la conosco meno). A loro (come a Canonical) fa specie non avere il software pi? recente. E tornando alla tua domanda: si pu? mancargli il syasadmin professionista che ha anni di esperienza a tener funzionanti batterie di macchine che "portano i soldi a casa". RH e Suse il software lo scrivono, non lo amministrano. Lo scrivono ingaggiando giovani menti brillanti ma non sempre esperte. Giovani e brillanti menti che magari un server non lo hanno mai visto da vicino, anche perch? i server come computer per l'utente finale sono un po' noiosi, solo le CPU, le schede di rete e i dischi sono tosti, le schede video e audio no, nemmeno servono nel 99.99% dei casi. Usati come macchine desktop risultano un po' una palla. E a volte fanno un casino della madonna. Aggiungi che c'? un ottica diversissima tra chi sviluppa e chi amministra, uno sviluppatore fa spesso scelte sistemistiche che funzionano solo perch? ? l'unico ad usare il suo PC, e lo stesso si pu? dire del software scritto a un sistemista (le eccezioni ovviamene ci sono). I sysadmin che lavorano su quelle versioni interprais stanno con quelli che hanno pagato le licenze solo per avere il diritto di lamentarsi con qualcuno se le cose vanno male. Sono questi qui che smadonnano dietro ai problemi e si domandano quanto fossero potenti i funghi del risotto della mensa di Red Hat. -- /\ ___ Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_____ African word //--\| | \| | Integralista GNUslamico meaning "I can \/ coltivatore diretto di software not install gi? sistemista a tempo (altrui) perso... Debian" Warning: gnome-config-daemon considered more dangerous than GOTO -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21610.28046.559521.926...@cyrano.gianoziaorientale.it