Wikimania 2024/Report/Valerio Bozzolan

BOZZA

Questo è il report personale della partecipazione di User:Valerio Bozzolan a Wikimania 2024 come volontario. Il report è condiviso da tutte le persone a cui è stata assegnata una borsa di viaggio (per conoscere la commissione borse vedi Wikimania 2024).

Il punto di vista è strettamente personale. Edit comunque ovviamente benvenuti.

Extra: risoluzione problema tecnico su computer aziendale di Wikimedia Italia

Martedì 6 agosto - prima mattinata

Questa sezione segue lo schema dei report degli incidenti tecnici in produzione in uso in Wikimedia Foundation - w:wikitech:Incident status.

Segnalazione:

Il membro dello staff Utente:Dario Crespi si presenta a Wikimania con il suo amato computer portatile aziendale "Tuxedo" che purtroppo ha iniziato a non avviarsi correttamente da circa 1-2 giorni «dopo un aggiornamento di sistema». Ci siamo dati allora appuntamento all'hackaton room in cui c'era sempre dello spazio libero per lavorare in tranquillità.

Sintomo:

Ad ogni avvio del portatile, il computer si fermava sulla ("schermata nera") shell interattiva di emergenza di w:it:GNU GRUB. Il bootloader GRUB non riusciva a lanciare il sistema operativo.

Ipotesi:

Si è escluso fosse un problema noto legato a dual-boot con Windows 10+ perché il computer ne era sprovvisto (mi è noto che Windows 10+ dopo certi aggiornamenti rompe a prescindere il dual-boot, qualsiasi sistema operativo ci metti di fianco).

Ho informato Dario che nella migliore e più verosimile delle ipotesi avremmo risolto in pochi minuti dopo aver a rigenerato i "menù di avvio di GRUB" eventualmente usando strumenti grafici e semplici da usare come Boot Repair. Questa ipotesi deriva dal fatto che l'aggiornamento dei menu di avvio GRUB è effettuata automaticamente proprio dopo ogni installazione di ogni nuova versione minore del kernel inclusa con gli aggiornamenti di sistema (APT), e mi era già capitato che durante questi aggiornamenti non si completasse con successo `update-grub` per varie ragioni. All'Officina Informatica Libera di San Salvario a Torino consiglio di solito di usare tool grafici, poiché spesso funzionano, punto, dando anche alle nuove utenze GNU/Linux un senso di maggiore controllo del proprio computer, invece che affidarsi ciecamente a persone esterne che digitano "comandi a caso sul mio computer". Inoltre questi tool grafici evitano alle utenze inesperte di commettere errori molto più gravi in futuro quando ri-utilizzati.

Ho informato anche Dario che nella peggiore delle ipotesi aveva perso irrimediabilmente tutti i dati presenti a bordo nella partizione principale, per un problema irreversibile al disco o al filesystem... magari per un precedente impatto al computer o cose del genere che solitamente le utenze non ammettono mai. asd. Questa seconda ipotesi deriva sempre da diverse esperienze dirette (che non c'entrano niente con Dario asd).

Preparazione:

Siccome non mi trovo a mio agio ad operare dal terminale di emergenza di GRUB senza poter aprire neanche un browser di fianco per documentarmi, e siccome risolvere i problemi senza interfaccia grafica spesso fa sollevare il panico nelle utenze che osservano vicino; ho riavviato il computer da una mia chiavetta USB esterna che tengo per queste occasioni per analizzare la situazione da un sistema operativo funzionante. Per avviare il sistema dalla periferica esterna ho dovuto riavviare il computer premendo ripetutamente il pulsante F2 (ho impiegato circa tre tentativi - se ricordo correttamente F12 non avviava il menu di selezione che mi aspettavo, e F1 avviava il boot via rete PXE).

Analisi:

Una volta avviato il sistema live dalla mia chiavetta, ho potuto lanciare w:it:gparted per analizzare le partizioni. La partizione di boot in formato FAT32 risultava - in effetti - danneggiata.

Azioni:

Ho applicato la risoluzione automatica della partizione danneggiata usando gparted stesso (onestamente senza sperare troppo in una risoluzione, poiché il formato FAT32 è un formato proprietario di Microsoft e mi era capitato che `parted` si lamentasse dell'impossibilità di auto-correggere la partizione. Invece....) gparted ha risolto il problema segnalato nella partizione di boot. Ho allora riavviato il computer, constatando però che il problema originario non era ancora rientrato.

Ho allora investito altri 10 minuti sull'attivazione di un ambiente `chroot` funzionante (https://superuser.com/a/111215/390314) con l'intenzione di lanciare `update-grub` come faccio di solito. Nonostante avessi montato tutti i dispositivi speciali come al solito, ho avuto questo problema nel lancio di `update-grub`:

/usr/sbin/grub-probe:error:failed to get canonical path of /cow

Mi sono documentato (https://unix.stackexchange.com/q/96977) senza però risolvere, neanche creando il file vuoto come suggerito in https://unix.stackexchange.com/a/659712 o altro.

Ho allora utilizzato semplicemente Boot Repair come proposto fin dall'inizio. È stato come sempre sufficiente installarlo come da guida. Si avvia da solo dopo l'installazione. Si pigia "OK OK OK avanti avanti avanti OK" a caso spegnendo il cervello, e di solito il problema rientra. Così è stato. asd.

Ho informato Dario che il suo problema era stato risolto magicamente da Boot Repair - e che se proprio ci teneva potevo leggergli a voce 2K righe di report tecnico di Boot Repair per capire quale fosse davvero il problema originario. Dario ha sorriso e ha rimesso nello zainetto il suo portatile aziendale - ora funzionante - e ci siamo salutati cordialmente. Ho scorso velocemente il report di Boot Repair per vedere se qualche cosa assurda saltava all'occhio. Non ho notato niente di particolarmente interessante, quindi ho buttato il report nell'immondizia. asd

Cosa è andato bene:

Per Dario è andata bene che un membro volontario della commissione tecnica (e quindi con NDA firmata) avesse tempo per prestare assistenza e avesse con sè una chiavetta USB pronta e avesse già incontrato quel problema in precedenza. In generale è andata bene che Dario è potuto tornare operativo durante l'evento.

Per Wikimedia Italia è andata bene perché non è stato necessario disturbare l'assistenza tecnica di Tuxedo, cosa che ha fatto risparmiare tempo all'amministrazione e denaro all'organizzazione.

(Attenzione a non fraintendermi: in altri contesti NON raccomando a Wikimedia Italia di affidarsi a persone tecniche "a caso" in una stanza di un hackaton. Bisognerebbe sempre affidarsi all'assistenza ufficiale come prima opzione, o, a persone con una NDA firmata - siccome durante questo tipo di assistenza tecnica si ha ovviamente totale accesso ai dati della persona coinvolta, e questa persona potrebbe accedere, estrarre, manipolare, compromettere i dati e i software sul dispositivo, installando malware o spyware ecc.)

Per Valerio è andata bene che Boot Repair nel 2024 sia ancora un tool decisamente semplice e funzionale e lo consiglierei ancora per risparmiare tempo.

Con tutto il rispetto per il nostro movimento, è anche andata bene che era il primo giorno, quindi, l'aria nell'hackaton room non profumava ancora di "80 calzini di 40 Wikipediani molto operosi" - come spesso irrimediabilmente capita quando metti così tante persone a produrre codice per tre giorni di fila. asd (cosa che comunque si è puntualmente verificata al terzo giorno di hackaton - inutile tentare di negarlo in questo report in cui ho dovuto giurare di non omettere alcuna verità asd)

Cosa è andato male:

Se avesse funzionato la multi-selezione di avvio che si attiva solitamente con F12 avrei avviato prima la mia chiavetta, risparmiando 5 minuti.

Se avesse funzionato il primo tentativo di `update-grub` da `chroot` avrei risparmiato altri 10 minuti.

Dove abbiamo avuto fortuna:

Dario ha avuto fortuna di poter risolvere in pochi minuti un problema che era potenzialmente legato a corruzione del filesystem / problemi hardware / perdita irreversibile di dati.

Valerio ha avuto fortuna che la chiavetta live-USB Ventoy in tasca fosse ancora perfettamente funzionante. Altrimenti sarebbero stati investiti altri 10-20 minuti per scaricare l'immagine ISO e ri-scrivere la chiavetta.

Tempo totale del disservizio:

"1-2 giorni"

Tempo totale della risoluzione:

20-30 minuti saluti compresi.

Extra: aiuto con Eventyay e Giggity

Martedì 6 agosto - per tutta la settimana

Siccome il software libero Eventyay è stato (fortunatamente) adottato per la seconda Wikimania di fila, e siccome non mi faccio i fatti miei, e siccome ho incontrato diverse persone nei corridoi che trovavano fastidioso doversi collegare ad un sito web (Eventyay) per vedere il programma completo e aggiornato, e siccome in effetti ho alcune critiche costruttive su Eventyay ma non mi piace quando questo si estende ad un generale risentimento negativo nei confronti di tutto il mondo del software libero...;

Ho quindi informato più persone possibili sul fatto che Eventyay supportasse diversi formati aperti di export proprio per dover evitare di navigare sul sito ufficiale (cosa che invece non era possibile durante Wikimania 2021 e 2022 online e questo quindi lo considero un nettissimo miglioramento - vedi mio report m:wikimania:2021:Present and future e m:wikimania:2022:Present and future); ho quindi informato dell'esistenza di una comoda app per Android chiamata Giggity, usata soprattutto durante la conferenza annuale w:it:FOSDEM, per navigare appunto nel fitto e bestiale programma del FOSDEM, comodamente offline, con aggiornamenti non appena torna la rete, e con notifiche sul prossimo evento di interesse, visuale a griglia oppure corrente / futura, ecc. Questo è stato anche un motivo per far conoscere il FOSDEM.

Per far funzionare l'app è sufficiente installarla, per esempio dallo store proprietario Google Play o dallo store libero w:it:F-Droid:

https://f-droid.org/it/packages/net.gaast.giggity/

E poi incollando in Giggity il seguente indirizzo che si otteneva visitando Eventyay e cliccando su Add to Calendar > Sessions XML (da desktop):

https://wikimania.eventyay.com/2024/schedule/export/schedule.xml

Mi hanno consigliato di promuovere l'app Giggity anche nella chat di Wikimania (https://t.me/wikimaniachat/23995) cosa che ha spinto circa una decina di persone a farmi domande in privato su come funzionasse l'app. Alcune persone si sono lamentate della modalità a griglia che aveva le gesture un po' caotiche. Siccome è un problema noto e concordo (https://github.com/Wilm0r/giggity/issues/370), ho consigliato a diverse persone la modalità "Now and Later" che è nettamente più accessibile e hanno tutti apprezzato.

P.S.

Con alcune persone a caso che invece erano già abituate al FOSDEM ho potuto avere una bella conversazione sul formato XML di interscambio, formato che personalmente considero molto funzionale ma un po' limitato, e che comunque vorrei fosse adottato da altri siti di eventi proprietari (affinché sia possibile evitare di navigare sui loro siti proprietari). Sul formato dell'evento ho potuto scambiare pareri in qualità di autore del CMS del Linux Day Torino (https://gitlab.com/LinuxDayTorino/LinuxDay-Torino-website) che appunto esporta gli eventi in quel formato, nonché come contributore di un'app per vedere il programma del Linux Day Torino e che appunto si basa su FOSDEM companion per ingestire quel formato (https://github.com/LinuxDayTorino/LinuxDay-Torino-companion-Android). Generalmente ho raccomandato a tutti di NON creare nuove app come abbiamo fatto noi ma di rafforzare quelle già esistenti, data la quantità di lavoro mostruosa dietro la creazione di ogni app.

Almeno altre 3-4 persone con iOS sono riuscite comunque ad importarsi il programma sul telefono esportando gli eventi in formato iCal da Eventyay (da un menù che è nascosto da mobile). Anche questa è una funzionalità che generalmente non è concessa da soluzioni proprietarie, o comunque non è generalmente possibile senza registrarsi, e invece Eventyay lo permette. Lo svantaggio di questa soluzione è che poi non è semplicissimo aggiornare gli eventi ottenuti in locale. Quindi consiglio comunque Giggity.

Data la quantità di feedback che ho raccolto su Eventyay ho poi partecipato alla apposita sessione nel programma.

Vedi #Sessione: Eventyay Insights and Feedback: AMA with Mario Behling and Wojciech Pędzich

Sessione: Eventyay Insights and Feedback: AMA with Mario Behling and Wojciech Pędzich

Mercoledì 7 agosto 2024 - https://wikimania.eventyay.com/2024/talk/NF8MDL/

Questa è stata una Meta-sessione per incoraggiare a ricevere segnalazioni di problemi tecnici di Eventyay (il software libero in uso per mostrare il programma a Wikimania Katowice). Sessione tenuta dal carismatico Mario Behling di FOSSASIA, il quale è la principale persona con cui parlare riguardo l'aver portato Eventyay già da Wikimania a Singapore ed essere riuscito a continuare questa direzione anche qui a Katowice.

Il clima generale dei partecipanti sembrava... "finalmente posso andare in questa stanza a parlare con qualcuno per dire quanti problemi ho trovato su Eventyay". Clima comprensibile, perché Eventyay alla versione corrente aveva davvero molte evidenti criticità, ma non sarebbe stato simpatico mantenere questo clima di sfogo per mezz'ora di fila. Mario è subito riuscito a stimolare i partecipanti a condividere sì le molte critiche nell'aria, ma in modo positivamente Wikimediano, quindi, con pazienza, accuratezza, comprensione reciproca e spirito di collaborazione e avanzamento.

La sessione è iniziata mostrando i punti di forza filosofici ma soprattutto pratici, unici di Eventyay (export in 4 formati, varie modalità di visualizzazione, nessuna necessità di login, neanche per mettere i preferiti, possibilità di esportare solo i preferiti, programma multi-lingua ecc.). Questo ha aiutato molto ad aumentare il valore percepito di questo strumento.

La sessione di 30 minuti è avanzata dando la parola a più di 15 persone e alle loro relative segnalazioni. Si capiva che Mario aveva già parlato con diverse persone nei corridoi nei giorni precedenti e aveva già un'idea abbastanza chiara di molti problemi, ma durante la sessione li ha comunque catalogati tutti alla lavagna. Esempi (tradotti):

• "su mobile non si vede il tasto login"

  (problema che onestamente ho riscontrat

  → problema grafico spirito di collaborazione e valorizzando il tempo dei partecipanti in un modo che spero tutti abbiano apprezzato.

Questo spazio ha sicuramente riscattato un po' Eventyay.

Ho avuto infatti la sensazione che Mario Behling, già prima di quella sessione, avesse già ricevuto nei corridoi una marea di feedback possibili immaginabili, e quindi - per davvero quasi tutta la sessione - mi è sembrato che quello fosse uno spazio - dovuto - in cui le persone potessero lamentarsi di un problema e potersi sentire ascoltate. Onestamente non ho trovato molto sano lanciare critiche a Eventyay per un'ora sul dorso di Mario, ma Mario se le è segnate tutte, lì davanti a tutti, su appunti appesi sul muro, ringraziando chiunque e fermandosi a spiegare dettagli utili per possibili miglioramenti.

Per diversi partecipanti che andrebbe riproposta ogni anno. Per esempio, è evidente che in piedi abbiamo una persona che sul muro sta con pazienza raccogliendo in modo certosino ogni singolo feedback condiviso da noi dal pubblico per catalogarli su dei post-it sulla lavagna. Ma NON è per niente scontato che questa persona non vada completamente in burnout per la quantità di tono di polemica e lamentele (che è abbastanza fisiologico ricevere).

Penso sinceramente che molte persone si fossero sedute per scagliare problemi e dimostrare "questa piattaforma non va bene". Invece, Mario è riuscito a convincere tutti che "siamo qui per migliorare grazie a voi" che è una cosa onestamente commovente e che ha tranquillizzato molte persone, rompendo la "sindrome delle Poste" (cioè, evitando che si creasse quel clima passivo di essere dietro ad uno sportello, ricevere delle cose che evidentemente non funzionano, ed essere impotenti nel sapere di non poterle migliorare).

Onestamente e senza mezzi termini mi sento di condividere che nell'aria fra diversi partecipanti c'era una papabile sensazione di "questo software fa schifo". Onestamente, fin dai primi 10 secondi in cui sono entrato, ho sperato che almeno una persona ricordasse che, nel software proprietario, se una cosa non piace allora significa che bisogna abbandonare quel software; mentre nel software libero se una cosa non piace significa che si può migliorare molto più facilmente quel software

Durante tutto il tempo della sessione, ogni persona alzava educatamente la mano per intasare Mario sulle più disparate segnalazioni di anomalie su Eventyay. Quello che non mi aspettavo, è che

Onestamente sono rimasto un po' deluso dal pubblico che ha colto l'occasione di qu

Incontro di persona con Mario Behling di FOSSASIA

Mercoledì 7 agosto 2024

BOZZA

Ho potuto incontrare nuovamente dal vivo Mario Behling di FOSSASIA (https://fossasia.org/team/), ovvero la persona che si occupa di Eventyay in Wikimania, per condividere alcune proposte "minimo sforzo massimo risultato" per migliorare l'accettazione del software libero Eventyay in Wikimania, tipo:

1. segnalazione del menu di login
2. https://github.com/Wilm0r/giggity/pull/367