Flarum - scritto in PHP ed usati componenti di Laravel per il livello chiamato “core” - nasce con tutte le concezioni moderne viste nei migliori forum e fondamentalmente è un simile di Discourse in Ruby. Potrebbe Flarum essere una buona idea per alleggerire il peso sulle risorse dei nostri server?
Ho visto che Flarum è in versione beta e sconsigliano di usarlo in produzione… Però, è da tener d’occhio. Un programma più maturo, sempre veloce ed in PHP è NodeBB.
Il vantaggio sarebbe che sono scritti in PHP piuttosto che in Ruby? È un vantaggio?
“Il vantaggio sarebbe che sono scritti in PHP piuttosto che in Ruby? È un vantaggio?”
hum non si riduce a questo, comunque NodeBB è scritto in js con Node.js o come si chiama
ma la cosa che fa la differenza è, supponendo un forum in PHP generico rispetto a Discourse, che potrebbe essere installato velocemente e semplicemente con metodi standard (fast-cgi-quello che vuoi, reversproxy-e-co etc etc) praticamente ovunque
con Discourse all’atto pratico se vuoi ricevere supporto devi usare il loro Docker shipped chiavi in mano…quasi
Se tenti di installare tutto il loro carrozzone apriti cielo, ad un quarto del tragitto le mani sudano, gocciolina sulla fronte, ed una strana sensazione comincia ad assalirti…fai finta di nulla ma poi all’improvviso sulla tua spalla una mano si poggia, ti giri, è quella di un demone assetato…e tu sei la sua birra fresca…
Un Docker con un carrozzone dentro Ruby & co, tutto da far girare ad un host GNU/Linux dentro una VPS
metto in colonna per capire meglio:
docker con carrozzone ruby host linux vps
cioe l’iper superficie di attacco e di “attappo”
pero in cambio abbiamo un forum veramente fico come si presenta
docker non aggiunge granche’ di overhead. In realta’, a parte la questione disco, che ormai e’ una risorsa ‘abbondante’ non ne aggiunge proprio, dato che si tratta semplicemente di una ‘chroot’ evoluta. Per lo meno su linux e’ un uso furbo dei cgroup. Io trovo Discourse un buon software, sicuremente ce ne sono altri altrettanto validi scritti in altri linguaggi. Personalmente, nodejs non mi sta molto simpatico.
Bwahahaha… cavolo, tutto ciò non lo sapevo quando proposi di provare Discourse. Condivido che fidarsi ciecamente di tutto un palazzone dockerato è contrario ai nostri principi di security e autosufficienza informatica… non è questione di efficienza… uso BSD jails da molti anni e quasi non si sente differenza… Docker è l’imitazione Linux delle jails di BSD… 
Di nodejs mi disturbano due cose, uno che non è così veloce ed efficiente come i suoi fans ci vogliono fare credere e due che non è bootstrappable, cioè che non si può compilare da codice sorgente senza l’uso di un precompilato di origini oscure ed inaffidabili.
Di php mi dispiace solo che è una brutta copia di perl e facevamo prima a restare con perl, ma ormai è andata e non ho granché altro da criticare…
Ma il problema più grosso: come salvare il prezioso tesoro dei dibattiti che abbiamo intrattenuto qui dentro? Io ci faccio riferimento spesso, e se non ci fosse la barriera linguistica lo farei quotidianamente! Facciamo la classica versione statica non più modificabile?
Io sono un autodidatta e ho poco compreso gli aspetti tecnici che sono stati tirati fuori.
Molto basilarmente ho letto svariate recensioni e visto qualche benchmark da cui Ruby risulta il linguaggio interpretato più pesante di tutti. Siccome non credo potremo disporre di chissà quali server e tanta banda… ritengo saggio ottimizzare le risorse. Senza arrivare a sofisticate soluzioni, credo che la scelta più semplice e valida sia usare un’applicazione web / CMS scritta in PHP e rinnovata in funzione di PHP7 il quale era già tra i linguaggi interpretati più veloci ed ha fatto uno straordinario salto di qualità, sia in termini di prestazioni, sia in termini di sicurezza, coerenza ed altre caratteristiche di cui PHP5 era difettoso.
Sopravvaluti un po’ l’incidenza della velocità dei linguaggi… in questo caso per esempio è molto più importante come il codice accede alla banca dati, a quale velocità ne estrae i contenuti e li trasforma in pagine html… in pratica la competenza informatica degli autori del software pesa di più della scelta linguistica.
I benchmark che confrontano i linguaggi spesso misurano il linguaggio stesso, mentre le applicazioni spesso fanno da collante tra il network e le funzioni delle librerie in C o Assembler– perciò se il tempo passato nel collante è minimo, non importa molto se è in C++, Rust, Javascript, bash o Python.
Considera una applicazione di crittografia scritta in Python: Dipende tantissimo dal fatto se le operazioni matematiche sono davvero implementate in Python oppure se risiedono in una library in C. Sul mio computer per esempio ci sta un file
/usr/lib/python3.4/site-packages/cryptography/hazmat/backends/openssl/rsa.py
che contiene codice collante per accedere alla libreria openssl (in C). Python non usa quel file. In realtà genera ed usa quest’altro file qui:
/usr/lib/python3.4/site-packages/cryptography/hazmat/backends/openssl/pycache/rsa.cpython-34.pyc
Questo file contiene il byte code, cioè il codice binario precompilato derivato da “rsa.py” per accelerare i tempi d’esecuzione anche del codice collante.
Resta un marginale vantaggio di efficienza se il collante è esso stesso scritto in un linguaggio macchina, ma ne risultano enormi svantaggi in tempi di sviluppo e manutenzione.
Grazie per i chiarimenti.
Questo significa che di fronte a Discourse o NodeBB o altro dobbiamo vedere: quali librerie usa, quanto il codice collante è usato per elaborare i dati e produrre le pagine html (in genere mi risulta, almeno per CMS / web app che sia molto usato), quale database usa e con quale linguaggio di interrogazione, oltre alle scelte di architettura per sapere se è stato fatto un lavoro ben ottimizzato o si è penalizzata la performance a beneficio della produttività (però sul web e non solo - per me - la performance è importante, a costo di avere meno funzioni).
esattamente cosi diciamo che sto Docker è un accrocco post lxc API zzato ed il suo design è interessante se visto con i loro occhi virtual-quel-che vogliono Ma rimane comunque un approccio da API zzatore che API zza tutto a qualsiasi costo Le jails si confrontano piu direttamente con l’orchestrazione dei cgroup & co piuttosto che con Docker che è un layer sopra, non a caso il progetto commerciale di Docker spingendo ovunque è riuscito ad entrare in FreeBSD ma fatto alla modalita FreeBSD proprio perche prima di tutto Docker è API e poi implementazione verticale Per certi versi tracende indipendentemente dalla sua storia comunque non è UNIX e questo mi rende guardingo su tutti i fronti
Di nodejs mi disturbano due cose, uno che non è così veloce ed efficiente come i suoi fans ci vogliono fare credere e due che non è bootstrappable, cioè che non si può compilare da codice sorgente senza l’uso di un precompilato di origini oscure ed inaffidabili.
si vero questo è assolutamente grave La storia di Node non mi piace per nulla, riesce a farmi sembrare la jvm una cosa ancora possibile (giusto perche ci gira tanta roba interessante tipo Scala)
Di php mi dispiace solo che è una brutta copia di perl e facevamo prima a restare con perl, ma ormai è andata e non ho granché altro da criticare… wink
Il problema è che Perl è stato sfigato perche di BASIC ce ne vuole per far avvicinare programmatori del w-e (gli stessi che usano Visual BASIC e le macro di excel)e PHP è il Basic dei tempi del web pero grazie al Perl la cosa doveva finire li…ed invece!!!
Ma il problema più grosso: come salvare il prezioso tesoro dei dibattiti che abbiamo intrattenuto qui dentro? Io ci faccio riferimento spesso, e se non ci fosse la barriera linguistica lo farei quotidianamente! Facciamo la classica versione statica non più modificabile?
Pero se in cambio dobbiamo mettere quel Node allora teniamoci Ruby che almeno rimaniamo su livelli alti Sul PHP abbiamo il reverse proxy con Nginx o httpd di OpenBSD e stiamo tranquilli a far fare a loro la terminazione TLS quindi rimarrebbe la superficie dell’applicazione stessa, ma gia sarebbe un passo avanti Nel senso ad esempio usando httpd di OpenBSD praticamente riduciamo di un colpo solo la superficie alla sola applicazione PHP, non ci sarebbe scampo dovrebbero passar eper forza da li Non so pero se hanno ancora il big giant lock ma con la 6 hanno fatto dei passi avanti, sperem almeno per far lavorare i core tutti della VPS (TODO da approfondire)
considerando cgroup / namespaces e la presenza di un layer com lxc/lxd che ancora sanno di retrogusto UNIX penso che Docker per come lo hanno impastato è un vero e proprio attacco frontale del tipo systemd
C’è un problema culturale in corso…una vera e proria guerra…sostanzialmente c’è un mondo che non sa e non vuole piu gestire metropoli e reagisce di conseguenza costruendo cose tipo systemd o docker
E’ una guerra aperta a UNIX
Personalmente, nodejs non mi sta molto simpatico.
Per Node.js per me la prova del 9 la faccio banalmente con due framework:
-
NetBSD pkgsrc compila? Si allora pkgsrc su GNU/Linux compila? Si allora OK , non compila? cestinare
-
FreeBSD ports compila? Si allora ok altrimenti cestinare
cestinare dopo aver prodotto bug report non risolti etc etc
e node.js soffre di problemi di bootstrap…è un po imbarazzante