Re: Debian systemd maintainer resigns due to online bullying
>>>>> "fn" == franchi@modula net <franchi@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
Reply to: