cespo

Un altro blog

Following the blog post Installing and configuring Folding@Home in Fedora by jorti, I would like to talk of BOINC too.

I'm not a scientist, I only know that BOINC is a distributed computing system where you can donate CPU cycles of you computer to scientific projects. You can join various projects, from astrophysics to biology.

You can find more informations here: https://boinc.berkeley.edu/

On #Fedora you can find the boinc-client as well the boinc-manager in the official repository.

But to speed up configuration, you can use the BOINC Docker image with podman.

mkdir /home/youruser/boinc

podman run -d \
  --name boinc \
  --net=host \
  --pid=host \
  -v /home/youruser/rosetta:/var/lib/boinc:Z \
  -e BOINC_GUI_RPC_PASSWORD="1234" \
  -e BOINC_CMD_LINE_OPTIONS="--allow_remote_gui_rpc" \
  boinc/client

Now install the boinc-manager (the GUI) on your host:

sudo dnf install boinc-manager

Then connect to the boinc-client running inside the podman container.

boincmgr --verbose -n localhost -p 1234

If you run the boinc-client on a remote machine, configure the firewall allowing the 31416 TCP port.

sudo firewall-cmd --zone=public --permanent --add-port=31416/tcp

sudo firewall-cmd --reload

Now you can join the Rosetta@Home project.

More info: https://www.reddit.com/r/COVID19/comments/f5as77/distributed_computing_project_rosettahome_is/

Il 20 Febbraio si terrà un nuovo Test Day per Fedora. Questa volta alla ricerca di bug sulla versione di GNOME che troveremo su #Fedora 32.

Sicuramente un bel po' di bug :–)

Maggiori informazioni sulla pagina del wiki dedicata all'evento.

Il Kernel Team e il QA Team di #Fedora hanno organizzato una Fedora Test Week per il Kernel 5.5, che si terrà dal 10 al 17 febbraio.

Anche chi non è coinvolto nello sviluppo della distribuzione è invitato a partecipare.

Cos'è una Fedora Test Week

La comunità di Fedora, in occasione dell'uscita di una nuova release della distribuzione, dell'arrivo di una nuova release del kernel #Linux, o di qualche altro componente, organizza delle giornate, o come in questo caso delle settimane, in cui le persone sono invitate a eseguire dei test. A caccia di bug.

È possibile ritrovarsi su un canale IRC dove condividere esperienze o problemi riscontrati, oppure chiedere delucidazioni per l'esecuzione dei test.

Come funziona il test del kernel 5.5 su Fedora

Non è difficile partecipare. Sarà possibile eseguire i test sia in una macchina virtuale (KVM, Virtualbox, whatever) che su una macchina fisica. In questo caso è sconsigliato installare il nuovo kernel se è una macchina di produzione, ossia contiene dati e servizi importanti.

Verrà resa disponibile una Live, oppure si potrà installare l'RPM del nuovo kernel. Oltre a valutare se il sistema e le varie periferiche sono funzionanti, sarà possibile eseguire un tool che effettuerà dei test (robe che chi le capisce è bravo) e restituirà dei risultati.

I risultati ed eventuali bug riscontrati si dovranno poi inserire in un'apposita pagina web dedicata all'evento.

Maggiori informazioni

Leggete l'articolo su Fedora Magazine

Consultate la pagina del wiki dedicata all'evento per avere delle informazioni dettagliate.

Sarà il burn out, sarà l'età che avanza, ma ho come l'impressione che tutto si complichi andando avanti nel tempo.

Per esempio ho scoperto questo nuovo server HTTP: Caddy. Caddy is a powerful, enterprise-ready, open source web server with automatic HTTPS written in Go.

Al contrario dei classici #Apache e #Nginx, con due righe due di configurazione hai un webserver in funzione, con possibilità di fare agilmente un reverse proxy e tante altre cose con poche direttive. In più, fantastico, ha la gestione dei certificati #letsencrypt integrata (generazione e rinnovo). Ganzo.

Senonché vedo che c'è la versione 2 (ancora in beta, ma per poco). E diavolo, le opzioni per la configurazione sono più articolate. Oh sì, saranno più potenti. Punta molto sulle API per fare le configurazioni al volo senza dover riavviare il servizio, uuuh, molto utile forse per il sito di ecommerce. Introduce la sintassi in JSON anziché le classiche righe di testo (sebbene sia comunque possibile utilizzarle). E per configurare la stessa cosa che con la versione 1 ho messo due minuti, con questa nuova versione c'è voluta un'ora, perché sì, sono cambiate le opzioni e la logica (e io sono particolarmente duro di comprendonio, sicuramente).

E non è l'unico caso.

Prendiamo l'avvio dei servizi su #Linux (al solito: per chi vuole, legga #GNU/Linux). Non sono un detrattore di #Systemd, anzi. Però, se una volta dovevi far partire uno script stupido (e non parlo del programma di una banca o di una centrale nucleare) una volta completato l'avvio del sistema, lo mettevi in rc.local e avevi fatto il tuo lavoro. Ora, su alcune distribuzioni sarà ancora possibile fare così, ma è deprecato e non professionale, sei uno scarpone artigiano non degno di usare una tastiera. Adesso ci sono file di configurazione, dipendenze, ventimila opzioni, demoni da riavviare, posti precisi dove andare a mettere il file che invoca il tuo stupido script. Cioè, non parlo di un servizio di un programma importante. Parlo di un banale script da avviare al volo.

O il cron. Ora ci sono i timer di Systemd. Se impari a usarli sono bellissimi e potentissimi. Ma se il cron lo capiva anche mio nonno (più o meno), per impostare un timer di Systemd devi leggere il manuale, scrivere due file di configurazione, ricordarti dove metterli, abilitare uno e non l'altro, ecc.

UEFI? ... ... ...

Sviluppi uno script stupido, ma che vuoi condividere col mondo. Devi metterlo su un server git; e via a imparare git, e a ricordarti la sintassi Markdown per scrivere il readme, ecc. Certo nessuno ti obbliga a farlo.

O anche per esempio la documentazione di Fedora. La scrittura di un howto. Una volta c'era il wiki. Voglio dire, anche mio nonno arrivava a saperlo usare. Edit della pagina, e scrivi l'howto. Ora no. Devi imparare git, capire qual è il repository, capire asciidoc, seguire delle regole di scrittura, saper lanciare un container. Poi certo, il documento sarà più bello di una pagina sul wiki fatta in fretta, e passerà per un processo di revisione. Ma che fatica.

Ma Docker stesso. Certo, se usi un container preconfezionato, può sembrare semplice, come installare un pacchetto, dopotutto. Ma se vuoi fare un container tuo? Se vuoi mettere in ascolto il container su un'altra porta? Se vuoi che due container vadano a braccetto? Sarà che ho ancora da approfondire molto la questione, e ammetto di non averci capito molto, ma sento puzza di cose difficili.

O un altro esempio è l'IPv6. Bene o male l'IPv4 un umano qualsiasi con un minimo di dedizione e sforzo, arriva per lo meno a capire che sono 4 numeri divisi da dei punti. Poi ripeto, sarò io particolarmente ignorante.

E insomma sarò vecchio e ignorante, ma sento questa puzza. Una volta, vent'anni fa, le cose erano più difficili, sicuramente, ma umane. Mi posso sbagliare, ripeto. Ricordo che anche i documenti su pluto.it (esiste ancora ILDP, Italian Linux Documentation Project?), voglio dire, la sintassi non era delle più semplici, ma se volevi tradurre un documento, aprivi un editor di testi e quando avevi finito mandavi una mail per la revisione. Meno efficiente? Sicuramente. Le cose erano più difficili, ma più umane, anche un non laureato in ingegneria del software, sporcandosi le mani, poteva per lo meno fare l'artigiano di basso livello. Un lavoro brutto, sporco, poco professionale. Ma funzionante. Obiettivo raggiunto. Ora, invece, sembra che ci voglia una laurea anche per cambiare il dispositivo di boot.

Ah! Ma è un po' come le automobili. Le auto di una volta le aggiustavi con un pezzo di fil di ferro. Adesso per individuare un guasto ci vuole il computer (e non sempre torni a casa con la macchina riparata).

Una domanda (o forse un dubbio esistenziale) che spesso viene fatta dall'utente Linux (GNU/Linux come preferite) è: perché usate questa distribuzione piuttosto che un'altra?

Le risposte possono essere le più diverse. Ovviamente. Non credo proprio che esista la risposta oggettiva. Ognuno può sforzarsi di cercare le motivazioni le più convincenti, gli aspetti tecnici oppure gli aspetti relativi alla comunità che c'è dietro. Ma allo stesso modo, se uno vuole criticare una distribuzione, ha sempre in mano ottime ragioni e facili punti deboli da mettere sul piatto.

Quindi, porre questa domanda per cercare le proprie motivazioni, forse è solo uno scambio di opinioni filosofiche. DNF è meglio di APT? Troverai chi dice che DNF è il peggior sistema di gestione dei pacchetti. La comunità? Ogni distribuzione ha dietro una comunità, e poi, quale comunità? Quella nazionale? Quella internazionale? E anche qui, se uno vuol criticare, trova sempre qualche dietrologia o punto di vista distruttivo a cui fare riferimento. Per dire, nelle comunità italiane trovi sempre una gran quantità di saccenti addottorati che sanno tutto loro, a loro agio nel guardarti dall'alto in basso e che sono poco inclini ad accogliere i nuovi arrivati. Almeno nelle mie povere esperienze. Sempre che ci sia un qualcosa che si possa definire comunità e non orticello.

Personalmente il fatto è questo: ho iniziato a usare Linux (GNU/Linux, come preferite) con Red Hat Linux. Ho imparato il poco che so partendo da lì e continando con Fedora Core. A causa di varie peripezie ho usato Debian, Ubuntu, Arch e finanche Gentoo. Ho conosciuto persone che maneggiano Debian magnificamente. Se cerchi come fare qualcosa, trovi spesso la guida dove la distribuzione utilizzata è Ubuntu. Alcuni software forniscono il pacchetto solo per Ubuntu. Il wiki di Arch è pieno di informazioni. Ma come dire, mi sono sempre imbattuto in qualcosa di talmente frustrante (non ho esempi a portata di mano, anche perché qui vado a sensazioni) che mi ha sempre fatto rimpiangere il fatto che non fossi su #Fedora. Ma insomma, la mia scelta non ha niente di tecnicamente o filosoficamente convincente.

In conclusione, quindi, ognuno provi tutte le distribuzioni che vuole. Forse prima o poi troverà quella dove accasarsi. Certamente non bisogna assumere un'atteggiamento da stadio: questa è la migliore e quella è la peggiore. Dopotutto criticare le cose è sempre facile.

E c'è anche chi non riesce a stare con la stessa distribuzione per troppo tempo (ci si stufa di qualsiasi cosa, una distribuzione perché dovrebbe essere da meno?). Il bello delle distribuzioni Linux (GNU/Linux se preferite) è anche avere la libertà di cambiare quando ne abbiamo voglia.

Vediamo se riesco a tenere un blog in italiano che parla di #fedora, Fedora #Linux ovviamente.

Fino ad oggi ho sempre scritto qualcosa in inglese sull'altro blog. Scrivere in inglese è una cosa per me faticosa, purtroppo. Inglese... diciamo inglese maccheronico. Faticosa... è faticoso scrivere anche in italiano :-D

Ho sempre fatto questo pensando che la platea di lettori in questo modo sarebbe stata più ampia; non tanto per attirare click o diventare una web star, ma per condividere eventuali informazioni con un maggior numero di persone. Cosa che continuerò a fare.

Però se ho qualcosa che mi torna più agile scrivere in italiano, questo è il nuovo posto.

Come sempre, vediamo fra quanto tempo mi passa la voglia :-D

Finalmente non ci sono più solo Wordpress e i vari CMS elefantiaci, e anche io posso iniziare a bloggare agilmente.

Proviamo questo writefreely (anche come installazione self hosted, se si dice così), ma come sempre: viva i siti statici!