linux user group brescia

Minchia ragazzi ho ADSL hahahaha! ok ora torno in me.
Ok D'accordo. Per l'aggiornamento degli eventi ci vuole per dare una
certa visibilità alle cose che fa il lug. Se si decide un CMS
preferirei Joomla perchè lo uso da un pò e so metterci le mani se poi
non devo aiutare ad aggiornare e pasticciare sul server usate quello
che più vi è congegnale, anche il metodo attuale potrebbe andare bene.
Purché sia facile e veloce da aggiornare. Detto questo un CMS sarebbe
anche bello installarlo perchè graficamente si riescono a fare belle
cose stupende senza impazzire utilizzando fogli di stile già presenti
in internet e gratuiti e poi con i miliardi di plug in e componenti
presenti in joomla si possono fare cose veramente fiche, ma sopratutto
funzionali. (anche con Drupal ma non conosco bene)
Credo che alla fine per aggiornare il sito non servano 1000
amministratori ma 3 o 4 persone che si prendono la briga di farlo. Io
per i miei limiti conoscitivi vi dico che mi piacerebbe darvi una
mano, così mi rendo utile a far qualcosa e magari imparo qualcosa di
nuovo, ma il sistema attuale descritto parzialmente a gelmini e altri,
mi spaventa nel senso che non conosco una riga di codice php e quindi
aggiornare il sito modificando liste di  codice non mi fido. Quindi la
mia disponibilità per darmi una mano la darei se si utilizzasse un
CMS, questo non per imporre oper mia pigrizia, ma una cosa è paciugare
per i cavoli miei una cosa è fare esperimenti e poi accorgersi troppo
tardi, che per un mio errore piallo il server del Lug BS e questo non
me lo perdonerei mai. :)

Un abbraccio a tutti voi. Siete fantastici a presto Emanuele :)

ps: volantino linux day BS sul calendario meetup e presto mando la
mail list a tutti gli iscritti Meetup (857 iscritti ad oggi)


Il 08 ottobre 2009 12.31, Andrea Gelmini <andrea.gelmini a lugbs.linux.it> ha scritto:
> Il 08 ottobre 2009 11.35, Stefano Pedretti
> <stefano.pedretti a gmail.com> ha scritto:
>> Nell'ordine suggerisco: Drupal, joomla, ma non escludo cose tipo plone.
>
> a tendere si arrivera' a questo, ma nel frattempo c'è un'urgenza da risolvere.
> vorrei ricordare le problematiche legate alla migrazione di tutto il
> materiale vecchio.
> la cosa non è banale, soprattutto perchè abbiamo in giro tanti/tutti i
> riferimenti con il vecchio sistema ordinato di URL, che è stato usato
> fino ad ora (dai documenti/annunci prodotti da noi, a tutte le
> referenze interne al sito, ecc).
> secondo me sarebbe una completa follia far saltare lo schema.
>
> vorrei inoltre ricordare, e bada bene che non lo dico in tono
> polemico, che la migrazione su Wordpress è saltata per il classico
> problema da CMS, ovvero, talune cose che per noi erano la norma, non
> erano piu' possibili, a meno che di non cominciare a pasticciare
> pesantemente con il codice o scriversi plugin ad hoc (e addio
> aggiornamenti smooth di sicurezza, ecc).
>
> ora, la semplicita' dell'attuale sito del lug permette, in primis, un
> veloce aggiornamento fintantochè si accetta di usare ssh e vi, e si
> vuole permettere un aggiornamento anche offline.
> non dimentichiamoci che il sito del lug è nato quando i modem erano
> l'unico tipo di connessione, e pure a caro prezzo.
>
> tolti questi paletti diventa sicuramente piu' interessante un CMS normale.
>
> ribadisco, senza alcun intento polemico, giacchè sono io il primo a
> voler risolvere la questione, tutti mi raccontano di queste migrazioni
> veloci, ma nessuno che mi abbia mandato un link del tipo
> http://migrazione-lugbs.example.com
> dove in quattro e quattr'otto tutto sia stato migrato, intendo, con
> tutto funzionante.
>
> ci tengo a ribadire la questione, pero': non confondiamo i due problemi, ovvero:
> a) c'è un problema di aggiornamento dei contenuti
> b) c'è un problema di scelta di tecnologia
>
> ora, il sito del lug, parlo dell'aspetto tecnico, nella sua
> semplicita', a oggi non ha chiesto mai interventi urgenti, nè di
> sicurezza, nè di aggiornamento. (Questo banalmente per rispondere a
> Pedretti, che ringrazio per la disponibilita', ma non si tratta di
> avere un nuovo sistemista che segue il milionesimo sito web, e che
> deve correre quando esce la milionesima vulnerabilita' di qualsivoglia
> CMS).
> nel suo essere semplice non dipende da motori o configurazioni
> particolari di apache/php, puo' girare anche senza php (e la cosa non
> era affatto stupida, all'epoca, perchè con poca banda permetteva ai
> client di cachare pesantemente, di comprimere tutto a monte e un'unica
> volta), e non necessita di alcun DB.
> tutta questa semplicita' fa sparire per magie tutte le problematiche
> del tipo "non vedo i contenuti perchè il DB è fermo", oppure perchè
> "l'aggiornamento non è andato a buon fine, ecc".
>
> sempre per la sua semplicita' aggiungere delle sezioni ordinate, ecc,
> non richiede piu' di un cp.
>
> la necessita' di cambiare lo strumento non nasce, pertanto, da una
> inadeguatezza dello stesso (le nostre esigenze sono talmente banali),
> quanto dal problema dell'aggiornamento dei contenuti.
> ora, poichè non si vuole piu' usare ssh per farlo, ne consegue la
> necessita' di cambiare lo strumento.
>
> quindi il problema piu' immediato è *l'aggiornamento dei contenuti*.
>
> questo si puo' velocemente risolvere dando l'accesso diretto ai file a
> un paio di persone.
> veloce, agile, funzionale... esattamente come unix...
>
> poi con calma potremo impelagarci in qualche mastodontica migrazione
> (non sai quanta roba c'è dentro il sito del lug finchè non cominci a
> metterci mano). Giusto per i curiosi: sono circa una decina di mega,
> di puri *dati*, per lo piu' testuali.
>
> ribadisco, sto rispondendo di fretta, sicchè non prendete l'assenza di
> diplomazia come poca disponibilita'.
>
> ciao,
> gelma
>
> --
>