Newsgroup: it.comp.os.linux.sys
Titolo: Paranoia da systemd

Dopo aver bellamente ignorato la questione per anni, mi sono incuriosito
sulla fmaosa diatriba circa systemd e le varie alternative per l'init
system.
 
A quanto ho capito, la preoccupazione principale dei detrattori di systemd
è il fatto che questo non aderisce alla Filosofia Unix, in quanto troppo
complesso. D'altra parte però vedo che praticamente tutte le distribuzioni
principali (ad eccezione di Gentoo e Slackware) l'hanno ormai adottato
come default.
 
Senza scatenare una flame, ma con genuino spirito di curiosità, mi
chiedevo come mai una cosa tanto controversa da generare grossi forks
abbia trovato una così importante adesione.
 
Qual'è la vostra opinione di scafati sysadmin in merito?
Vi siete mai trovati ad imprecare a causa di uno o dell'altro init?
Quacuno di voi ha esperienza diretta con OpenRC? Presenta qualche
svantaggio tangibile rispetto a Systemd (che immagino essere più completo,
in quanto più gettonato)?

abbia trovato una così importante adesione.
 
Pigrizia. Gradualmente è diventato più semplice seguire la corrente, che prendere
le armi contro un mare di rogne, ed opponendosi disperderle (cit.).
 
Può essere interessante questo recente articolone.
 
 
http://blog.darknedgy.net/technology/2015/10/11/0//
 
 
Leonardo
 
-- 
 
Now suppose -just suppose- I could show you a way to
manufacture a wall that would do the same job... but
was only one inch thick.

 	
http://blog.darknedgy.net/technology/2015/10/11/0//
 
 
Questo tizio ha un modo di scrivere davvero pesante (e forse vagamente
pretenzioso).
 
Ad ogni modo grazie per il link.
 
(spero di riuscire a digerirlo!
 
                               [[ BURP! ]]
 
) :D

 in quanto più gettonato)?
 
magari non saro' il piu' "scafato" tra i sistemisti, ma sul mio personale
e sui pochi server che ho continuo ad usare gentoo/openrc e cerco di
evitare il piu' possibile systemd !
 
openrc (a farla semplice) e' formato da una serie di script che tu
aggiungi/rimuovi da un runlevel (che puoi creare anche tu ex novo)
e che vengono configurati (dipendenze) in semplici file di testo.
 
a riprova di questa mia convinzione, il mio collega che usa debian
sul suo personale ogni tanto si impalla e smad***a systemd che
gli blocca completamente il sistema e ci mette un po' di
tempo a capire COSA e' andato male e rimettere le cose a posto.
 
con openrc al massimo avvii con un disco di boot e togli
momentaneamente lo script incriminato dal runlevel, oppure
riavvii in un runlevel di sicurezza in cui non vengano
avviati tutti i servizi.
 
ciao
 
-- 
Never try to teach a pig to sing.
It wastes your time and annoys the pig.


Vi sono due considerazioni "ortogonali".
 
Da un punto di vista puramente tecnico,
systemd rappresenta la parte user space
del kernel (che e` monolitico e rognoso).
Cioe` tutti quei servizi che, per varie
ragioni, sono da fare in user space, ma
non sono applicazioni.
Probabilmente qualcuno lo chiama middle-ware.
 
Da questo punto di vista, e` sicuramente
un'innovazione validi, specialmente per
desktop. Magari per server specializzati
non ha troppo senso.
Raccogliere miriadi di micro-funzionalita`
in un unico SW e` come la raccolta di
miriadi di funzionalita` che sono nel kernel.
 
Detto questo, il problema di systemd e` che
gli sviluppatori "sanno cosa e` giusto per
te" (tm). Inoltre, non sembrano avere lo
stesso rigore nella realizzazione del SW
che i kernel developer hanno.
 
Per cui riescono ad introdurre deficienze
e bug che si potevano evitare e, nonostante
tutti dicano che non va bene, insistono con
il dichiarare la loro soluzione "migliore" (tm).
 
Per es., per non aspettare in shutdown, avevano
introdotto un "kill -9" per tutti i processi
che non erano ancora morti.
Ovviamente, il "-9" non da scampo ed alcuni
processi perdevano dati. In particolare la
bash perdeva la history.
Bene, uno sviluppatore ha scritto che e` meglio
perdere dati, piuttosto che aspettare...
 
Per concludere, io ritengo che sia il futuro
dal punto di vista tecnico, spero solo che
cambino i developer.
 
bye,
 
-- 
 
piergiorgio

 rognoso).
 
Tanenbaum, è lei?
 

 Vi siete mai trovati ad imprecare a causa di uno o dell'altro init?
Sempre. Il problema direi più oggettivo contro cui ho sbattuto il naso è 
una certa difficoltà (non solo mia) nel debug dei meandri di systemd in 
caso di pippe. Fra le varia letture sul tema consiglio la 1088619° 
lettera di bugzilla ai corinzi:
https://bugzilla.redhat.com/show_bug.cgi?id=1088619
 
Un problema apparentemente banale (il sistema che non si spegne con un 
generico "a stop job is running...") ha scatenato un po' di tutto.

 
https://bugzilla.redhat.com/show_bug.cgi?id=1088619
 
 
Thanks for sharing!
 
Devo dire che la Lettera ai Corinzi pullula di italiani. Sulle prime
pensavo che il problema -nonsocome- abbia a che fare con il spaghetti e
mandolini. O con il locale.
 
Senza buttare benzina sul fuoco - 5 anni di incendio? Per la miseria, non
ci tengo - ho ricavato l'impressione che il signor Poettering abbia spesso
in mente il Desktop e poco il resto del mondo.  Sto pensando all'"accusa"
di violazione dei sistemi Unix e alla questione "svchost.exe" (di cui
leggo su wikipedia[1]).
 
Per altro, mi pare di aver visto passare sull'Internet qualcosa circa
l'integrazione "non ci si scappa" di Gnome3, che da per assoldata
la presenza di Systemd (se ho capito giusto).
 
E questo bug "dell'utente zombie" mi sembra un altro punto in favore di
questa possibile visione.
 
OT: Invidio tantissimo la gente che lavora su componenti così centrali al
    sistema. Nel bene o nel male. Sospetto che la mia invidia dipenda dal
    fatto che non ho le mani in componenti così centrali del sistema.
    Tuttavia questi guadagnano un'esperienza incredibile!
 
 
[1]: 
https://en.wikipedia.org/wiki/Systemd
 


:-)
 
Non credo...
 
bye,
 
-- 
 
piergiorgio

 in quanto più gettonato)?
 
non è che tu abbia modo di scegliere. Al massimo scegli la distro, ma 
sicuramente non togli systemd da redhat/debian. 
 
 
-- 
Massimiliano

la mia opinione è che sistemd spacca
 
Su soggetto e verbo sono tutti d'accordo.
 
Si discute se mai sul complemento oggetto.


 Non credo...
 
Anche perché IIRC Tanenbaum era per il microkernel.
 
Dai, confessa che usi MINIX in produzione.
 
-- 
Andrea
 

 la mia opinione è che sistemd spacca.
 
Ma ti sei imbattuto in qualche problema rognoso che sei poi riuscito a 
risolvere, magari con un brillante 'systemctl fix --all-problems'?
 
-- 
Andrea
 

 Dai, confessa che usi MINIX in produzione.
 
In cluster beowulf... :-)
 
bye,
 
-- 
 
piergiorgio

 Si discute se mai sul complemento oggetto.
 
il problema che vedo è che bisogna ricordare tutti i comandi. Ad esempio, 
in questo momento non mi ricordo come si va a passare alla modalità non 
grafica e devo cercare tra mie note: 
systemctl set-default multi-user.target
 
in questo senso rompe, perché per ottenere lo stesso risultato (niente di 
meglio) bisogna spremere inutilmente le meningi :) 
 
-- 
Massimiliano Adamo


 
A me questo turba non poco.
 
Ciò che mi inquieta non è la lista di comandi di system-d o le sue 30 
paginette da imparare a mente.
E' il fatto che dovrò farmi esperienza in tutti quei casi che fallirà (e 
fallirà! eccome.. Il mio pc di casa si è piantato nel passaggio a jessie 
chiedendo una cosa incomprensibile.. e non va di avere lo stesso 
messaggio sul server dall'altra parte del mondo)
 
Inoltre dubito che system-d sia l'ideale per l'embedded, e qua ne 
abbiamo di schede simili, a partire dalle alix a cose custom.
 
Ogni tanto guardo la ml di devuan, prima o poi lo provo.
 
Ale

 abbiamo di schede simili, a partire dalle alix a cose custom.
 
Vabbe`, ma se hai sistemi *embedded*, per definizione
hai quello che vuoi, non quello che ti danno.
 
Altrimenti non sono *embedded*.
 
Detto altrimenti, devi farti la tua distro, in quelle
situazioni, non puoi contare su una gia` fatta.
Puoi, ovviamente, *basarti* su qualcosa di esistente.
 
bye,
 
-- 
 
piergiorgio

 Ogni tanto guardo la ml di devuan, prima o poi lo provo.
 
Io più che Devuan, guardo con sempre più interesse gli altri due lati della
barricata, uno per il desktop (Windows, OS X), uno per i server (FreeBSD)
 
Enrico
P.S. ci sarebbe anche il divertentissimo caso in cui si pianta nello smontaggio
delle share di rete durante lo shutdown, ma quello è più impegnativo...

 che non erano ancora morti.
 
Oh giuoia, sapevo quella per cui "exotic filesystem like XFS"[1] non se li
inculavano, ma questa mi manca...
 
Enrico
[1] 
https://github.com/systemd/systemd/issues/560#issuecomment-124089792
 

 (FreeBSD)
 
Non ho mai usato un BSD abbastanza da poterne dare giudizi, ma sono stato 
costretto a usare Windows per 6 mesi in un precedente lavoro, e uno dei 
motivi per cui ho cercato altro era la frustrazione di doverlo usare. E 
non sto esagerando...
 
OSX lo sto usando da 3 mesi (sempre perchè costretto al lavoro) e, pur 
essendo anni luce avanti a Windows, preferisco studiarmi systemd piuttosto 
che passarci in pianta stabile.
 
Sarà buono per gli utonti, ma appena cerchi di fare qualcosa di più 
avanzato ti trovi davanti a quello che era Linux 10-15 anni fa, a partire 
dai comandi da shell che non accettano i flag dopo gli argomenti per 
arrivare a dover maneggiare il "registro di sistema" (per i servizi al 
boot, per esempio) da command line senza uno straccio di help in linea o 
interfaccia grafica. Più un milione di altre micro-rotture di balle.
 
Seriamente, capisco gli utenti occasionali, ma non riesco a capire gli 
sviluppatori cosa ci trovino.
 
Bye.

 sviluppatori cosa ci trovino.
 
Io sinceramente vorrei passare ad uno dei due OS che ho citato perché sono
stanco di stare dietro alle paturnie dei produttori di pc. Alla fine con
Windows ho tutto quello che mi serve, e se devo sviluppare su os serim posso
anche andare di VM
 
Enrico


cdparanoia
 
-- 
http://paskali80.antiblog.com
 

 sviluppatori cosa ci trovino.
 
Io uso OS X con MacPorts. Ho un sistema BSD, ho una GUI coerente, ho i port.
 
La parte dove pecca di più è nelle personalizzazioni non previste, ad 
esempio se vuoi un tiling wm in Quartz (non in Xorg dove ovviamente 
lanci quello che vuoi) devi pagare qualche programmino terze parti.
 
È chiaro che non esiste una soluzione che vada bene per tutti e per 
tutte le esigenze, ma IMHO questo è un ottimo compromesso.
 
 
-- 
Andrea
 

 tutte le esigenze, ma IMHO questo è un ottimo compromesso.
 
Io trovo Linux molto migliore, per esempio. Con i temi adatti hai la 
stessa uniformità di interfaccia anche tra app KDE e Gnome (2 e 3) e molto 
più personalizzabili.
 
Non dico che faccia schifo, eh. Anzi. Se Windows è 0 e Linux è 10, OSX è un 
8 abbondante.
 
L'unico vantaggio di OSX è il supporto di alcune software house. Per 
esempio il client VPN che usiamo in azienda c'è solo per Windows e OSX.
 
Ma lì è colpa dell'IT che si è fatta perculare da MS, non di Apple, che 
anzi almeno mi permette di non dover usare Windows. :P
 
Ma tornando in tema: se sono utente Linux mi viene molto più facile 
studiarmi systemd e tutte le sue paranoie, piuttosto che imparare a 
scrivere plist in XML con schema diversi per ogni software e indovinare 
dove metterli.
 
Bye.



On 2016-01-18 20:55:57 +0000, Alessandro Pellizzari said:


Svantaggio anche per gli altri
  
BSD, allora. :P




Dipende come la vedi.




 
Per attivare e disattivare servizi sì, era launchctl, ma ce n'era un
 


altro, qualcosa tipo pset, per configurare alcuni parametri.




Mai sentito. Launchd non è diverso come concetto da ogni altro sistema di init che sia mai stato usato, cambia solo l'implementazione. NextBSD (progetto in fieri) prende molto spunto da questo.




Per esempio le finestre inattive con bordo grigio #eeeeee


[…]


E, ripeto, migliaia di altre cose. Piccole, ma che tutte
 


insieme danno fastidio.




Taglio ma dico che è tutto condivisibilissimo, e che alla fine non importa.


Mi spiego: l'ambiente di OS X è più vincolato, le linee guida sono decise dall'alto cercando di mediare tra diverse esigenze. Il fatto che hanno gente pagata per stare lì a badare a queste cose (e Apple è gente che spende soldi per studiare come fare le _scatole di cartoncino_ più ergonomiche e logisticamente migliori), ho scoperto che alla fine le piccole correzioni che vorrei apportare non importano molto e il sistema è ben usabile se mi adatto al flusso principale.


Niente sacrifici enormi beninteso.




La differenza grossa che vedo io è che quando c'è un criterio "forte" a monte questo limita un po' l'utente da un lato ma gli permette una maggiore velocità dall'altro.


Un concetto che mi piace esprimere, forse derivato da "less is more" è "quando c'è una sola opzione è facile scegliere". Se lo strumento è efficace e non si oppone attivamente ad essere utilizzato andando contro l'utente (come capita a volte su certi sistemi) per me questo si traduce in una esecuzione migliore.




È un po' come votare alla elezione del governatore su Monkey Island, insomma.




Abitudine, forse. Ma se Linux mi consente di avere sia un comportamento
 


che l'altro e OSX no, per come la vedo io, Linux è superiore.




Dipende dal metro che usi, possibilità di personalizzazione ed efficienza non sono sullo stesso asse. Il tempo speso a personalizzare riduce l'efficienza.




Ho giusto
 


disinstallato BTT perché l'autore ha deciso che da adesso sarà shareware
 


in modo retroattivo, quindi non posso nemmeno usare una versione vecchia.




Non credo possa farlo, se hai il software vecchio vale la licenza di quando l'hai acquisito.




Io ho installato un sacco di roba con Brew, che salva parecchio il cu*o,
 


ma la GUI è coerente solo finché non trovi applicazioni che fanno quello
 


che vogliono. Esattamente come Gnome3. :P




No, la GUI intesa come framework applicazioni è coerente in tutto il sistema.


Il menu del programma è sempre il primo, ha sempre il pannello "about" e le preferenze dentro, ha sempre il menu "Help" con il campo di ricerca rapida dentro, ha sempre il menu "Edit" in terza posizione con dentro taglia/copia/incolla e così via.


Poi Cocoa è briscola rispetto a GTK+ , ;-)




Io trovo Linux molto migliore, per esempio. Con i temi adatti hai la
 


stessa uniformità di interfaccia anche tra app KDE e Gnome (2 e 3) e molto
 


più personalizzabili.




La questione secondo me ritorna su quel "less is more".


Per un assurdo se andiamo in un negozio e compriamo un calcolatore insieme in quanto tempo sei produttivo con un compatibile su cui istalli linux e un Mac?


So che è un caso tirato per i capelli ma vuole essere una semplificazione.


Con un Mac in linea di massima compri, vai a casa, colleghi l'alimentatore, accendi, cerchi di saltare queste maledette registrazioni ad icloud che hanno introdotto nelle ultime versioni, ti arrendi perchè hai l'iphone e alla fine è comodo, e sei pronto.




Ovviamente il discorso non è pari perché dire "postazione con linux" non vuol dire nulla, se prendi Ubuntu e trovi un computer con già istallato il sistema probabilmente hai una esperienza analoga.


Ma se prendi un sistema con una netinstall Debian (o altro sistema analogo) decisamente no.


Hai molta possibilità di personalizzazione ma questa possibilità la paghi con tempo speso.




Alla fine se a te piace stare lì a manutenere il sistema è chiaro che a fare questo ti diverti. Se vuoi uno strumento che funzioni come tale senza preoccuparti tanto della manutenzione allora OS X secondo me non lo batti.




La mia esperienza personale è che la differenza tra un sistema linux e uno Mac è il tempo speso ad occuparsene, non per aggiustarlo quanto per "accordarlo" inteso come "tuning". Sul Mac questo tempo è minimo e praticamente ti scordi di doverlo fare.


La differenza con un sistema Windows invece è il tempo speso ad aggiustarlo. Ho amici "windowsari" che dicono di non aver mai istallato un antivirus, di aver passato tutte le versioni, di non aver mai dovuto formattare. Ma io questo non l'ho visto, l'ho solo sentito.


La mia esperienza con altri utenti (non ho mai avuto un sistema windows personale) è che invece stanno sempre a istallare antivirus, antimalware, poi si beccano un malware (ma ovviamente non c'è scampo su nessun sistema con un utente che accetta tutto e magari è amministratore) e poi "è rallentato moltissimo", manco fosse un sistema meccanico di ingranaggi che si usurano nel tempo, e alla fine via di formatta-e-reistalla.
 




Non dico che faccia schifo, eh. Anzi. Se Windows è 0 e Linux è 10, OSX è un
 


8 abbondante.


L'unico vantaggio di OSX è il supporto di alcune software house. Per
 


esempio il client VPN che usiamo in azienda c'è solo per Windows e OSX.




È l'effetto collaterale di essere diventati "quasi-mainstream".




Ma tornando in tema: se sono utente Linux mi viene molto più facile
 


studiarmi systemd e tutte le sue paranoie, piuttosto che imparare a
 


scrivere plist in XML con schema diversi per ogni software e indovinare
 


dove metterli.




Guarda che è il contrario, una forse gestione centrale significa che si sa esattamente dove metterli. Lo schema mi pare sia unico (almeno per versione del sistema operativo). I demoni vanno in LaunchDaemons, gli agenti (daemon per sessione, in genere roba che ha una GUI in menubar) in LaunchAgent. La roba di sistema è in /System, quella dell'istallazione locale è in /Library, quella dell'utente in ~/Library. Fine dei giochi.






--
 


Andrea





 Svantaggio anche per gli altri  BSD, allora. :P
 
Di fatto lo è. Ho visto dei colleghi lavorare in OSX da linea di comando,
e mi veniva scomodo per transitività. Allora sono andato a guardare sul
mio, di schermo.
 
A quanto leggo sugli annali della storia antica, le utility da command
line di BSD ereditano dai vecchi Unix, mentre GNU è stato scritto da zero
con delle linee guida del tipo "oggi giorno abbiamo memoria, perciò tanto
vale avere buffers larghi, algoritmi buoni per gestire le opzioni, numero
di argomenti illimitati ecc ecc".
 
(Per non parlare di EMACS che era considerato un enorme bestione. Oggi
come oggi EMACS si apre in qualche nanosecondo, e Firefox ci mette
vent'anni.)
 
Ad ogni modo, non saprei le vere ragioni sul perché la command line sotto
OSX sia così scomoda, ma così senza guardare fonti autorevoli direi che
l'idea di ereditare licenze GPL con librerie GNU non piaceva, e nessuno ha
considerato utile spendere risorse per migliorare una cosa che, tutto
sommato, funziona. Frustrante per un utente GNU, ma funziona.

 praticamente ti scordi di doverlo fare.
 
Per me è il contrario.
Come dicevo sopra: se ti accontenti di quello che ti danno, che sia OSX, 
Linux o Windows, OSX è il più lento di tutti, visto che anche con Windows 
hai già i driver preinstallati e devi solo cliccare "accetto" sulla 
licenza.
 
Se ti metti a configurarlo per renderlo più comodo... ci ho messo 3 
settimane a configurare OSX come lo volevo io. E non ho ancora finito, ma 
pare che non esista quello che voglio.
 
La stessa cosa con Debian/Ubuntu, e pure installando Mate da rete assieme 
a un'altra quintalata di software, la faccio in 2-3 ore.
 
Come dicevo: abitudine, forse. In Linux so esattamente cosa installare  e 
come configurarlo. Il mio punto è proprio: se già conosci Linux, OSX non è 
la Mecca. Non dà niente in più, e ti tocca anche ripartire da zero a capire 
come funziona.
Meglio leggersi le 40 paginette su systemd, e in un paio di giorni sono 
operativo tanto quanto con sysvinit.
 
Bye.