[Verdebinario] [Hacklab-Cosenza] Linux Day

[Giuseppe De Marco]

Il 21 ottobre 2014 22:08, Kbyte <kbyte a snowpenguin.org> ha scritto:
> Il giorno 21 ottobre 2014 21:43, Francesco De Francesco
> <francesco.defrancesco a gmail.com> ha scritto:
>>
>> Boh, a me personalmente (ma è da poco che mi sto informando, quindi magari
>> dico una sciocchezza) garba assai poco l'approccio, più che il coso in sé e
>> per sé.
>
>
> Bhe, quello che ti posso dire è che puoi benissimo iniziarlo a provare in
> test. La documentazione è molto ricca e apre molte possibilità specie dal
> lato sistemistico, soprattutto lato server.
>
>>
>> Della seria: UNIX e derivati funzionano perché ci sono tanti componenti
>> piccoli ciascuno dei quali funziona benissimo, systemd mi sembra andare
>> nella direzione esattamente opposta.
>
>
> Attenzione, già in passato abbiamo visto questa filosofia ignorata, basti
> pensare ai vari udev, pulseaudio, dbus e kde. Inoltre init come lo
> conosciamo è stato eliminato da anni in ubuntu con upstart ed esistono già
> alcuni tentativi per sostituirlo perché i tempi oggi richiedono funzionalità
> maggiori e maggiormente integrate con il kernel linux. Lo stesso concetto di
> "piccolo" è relativo, lo stesso vim da allora è notevolmente cambiato ed
> incicciottito, eppure viene considerato uno strumento "piccolo". Se poi
> consideriamo emacs possiamo dire che lui è l'eccezione fatta persona.
>
> Qui puoi trovare tante informazioni interessanti seguendo questi post
> dedicati ai sysadmins
>
> http://0pointer.de/blog/projects/systemd-for-admins-1.html
>
>>
>> IMVHO sarebbe cmq un dibattito interessante, magari non va bene come talk
>> generalista ma si potrebbe sfruttare il topic per una discussione dal vivo
>> (che magari produca un documento finale? Chiedo troppo?)
>
>
> Il problema, come dicevo e come in effetti dimostra come è stato portato
> avanti questo piccolo dibattito in lista, è che un tema come questo è per un
> pubblico troppo mirato, perché oltre alle questioni ideologiche usate per
> criticarlo (imho esagerate e anacronistiche), il nocciolo della questione è
> spulciare le reali potenzialita/difetti tecnici di systemd. Ciò richiede che
> interlocutori e pubblico abbiano una conoscenza tecnica avanzata che
> sinceramente dubito si possa garantire.
>
> Il risultato sarebbe un talk show politico, non tecnico.

Di fatto a rallentare i sistemi è l' I/O disco.
Di fatto è meglio che tutto sia un file, personalmente è utile che
l'approccio a tutto sia il più semplice possibile. Un file descriptor
è un'interfaccia classica, qualcosa di confortevole.

La tendenza è quella mantenere più roba in RAM, specie nei giorni
nostri dove di questa c'è ne in abbondanza. Si pensi al preload in Mac
OS X o agli allegri amici nella systray di windows.

Tutti i software pensati per abbattere i passaggi con il kernel,
ridurre le transazioni e l'I/O generale, sono scelte fisiologiche per
stare al passo degli altri sistemi.

Si pensi Android e all'evoluzioni di Linux per uso industriale, si
pensi a uci per OpenWRT e via dicendo.
Si pensi all'abbattimento dei costi energetici dei dispositivi,
riducendo l' I/O disco questi diventano concreti.

E' comodo sfruttare un' API integrata di tutte le funzioni, piuttosto
che scriptare chiamate che di distribuzione in distribuzione risentono
di path assolute, incoerenza dell' LSB e via dicendo. Gli script vanno
sempre adattati all'ambiente, un programma che sfrutta una API è
discorso diverso.

Se si può mantenere il FD è meglio, altrimenti anche socket va bene,
l'importante non è il formato ma sapere dove puntare, poi la scelta
vincente è quella più efficiente e ed è l'utenza globale a premiare le
scelte migliori.

Si pensi al log binario, certo è antipatico ma mi è capitato nel
monitoraggio che loggare su binario facesse risparmiare un sacco di
banda e risorse. Vediamo dove arriviamo ma secondo me systemd anche se
non sarà stabilmente nelle nostre distribuzioni stà cercando di dirci
qualcosa, conosciamo il suo linguaggio ? :)