This commit is contained in:
2024-08-25 17:18:20 +02:00
parent dda72042fd
commit 00130ace72
171 changed files with 3464 additions and 240 deletions

View File

@ -0,0 +1,39 @@
// % Categories = Note
// % CreatedOn = 2022-09-18
// % EditedOn = 2022-09-19
// % Index: None
<!-- Dovrei finire di scrivere sto coso... --->
# Aggirare i DRM dei libri di scuola
**(in una maniera che probabilmente rende possibile l'operazione anche per testi non-scolastici.)**
Eccomi nella mia ennesima piccola avventura.
Stavolta sono alle prese con dei DRM stupidi, che potrei, come molte persone, tentare di aggirare in maniera super-studiata e perfetta.. ma, anche in questo caso, le soluzioni più semplici sono le migliori.
La mia soluzione, per quanto brutta e inelegante, è universale.
Non mi sono messa a scrivere dei programmi di scraping per magari scaricare dai siti dei libri, o per convertire i formati strani dei lettori offline in formati più comuni. Chi ha voglia di mettersi a reversare tutto quello che serve, e per ben 4 volte, una per diverso fornitore del libro digitale?
Ho deciso di usare la cattura di schermata. Non fatta a mano, chiaramente.
Ad ogni modo, è proprio da qui che nasce un percorso, orientato al risolvere piccoli problemi usciti fuori all'improvviso, e all'aumentare l'efficienza sotto diversi fattori.
## Perché tutto ciò?
I motivi che mi spingono ad imbarcarmi in questo casino sono molteplici.
Certo, è perché mi servono i libri digitali, considerando quanto comodi sono. Da quando ho iniziato la scuola superiore porto solo il mio tablet laggante, nessun libro-mattone di carta (eccetto alcune mele marce, tipo il libro di fisica e di letteratura italiana, che non sono forniti in digitale...). Se non facessi così, lo zaino esploderebbe e la mia schiena da esile loli si frantumerebbe.
Ma perché devo estrapolare i libri, e non usare le applicazioni degli editori?
**Le app non funzionano**
: Il primo motivo è banalmente questo. Alcune app funzionano semplicemente male, essendo lente a caricare il menu, un libro, o addirittura una pagina.. quando con un PDF o anche delle immagini viste in galleria non avrei il minimo problema. Altre non funzionano proprio! Perdono la sessione in continuazione, o addirittura sono completamente rotte e pensano che io sia offline, e non riesco ad accedere ai miei libri.
<meta>
**Non mi piacciono il software proprietario e i DRM**
: In generale, ogni volta che è possibile cerco sempre di fare a meno del software proprietario, preferendo strumenti liberi per fare le cose che devo fare. Il software proprietario in sé, però, non è necessariamente sempre cattivo al 100%, perché a volte ti lascia comunque la libertà 0<sup>[[↗️](https://it.m.wikipedia.org/wiki/Software_libero#Le_%C2%ABquattro_libert%C3%A0%C2%BB){[:MdTgtBlank:]}]</sup>, ossia la possibilità di usare il software sempre per qualsiasi scopo. Bene, i DRM tolgono anche questo, sono il male assoluto inscusabile e, se già tutto ciò che uso per scopi miei non ha i DRM (perché non li ha mai avuti, o perché sono stati tolti, da me o altre persone), sarebbe carino risolvere questa questione anche per i libri di scuola, che uso solo perché il programma di studi lo richiede.
<meta>
**Poter preservare e condividere i libri**
: I libri di carta, una volta che li hai comprati, li possiedi. Puoi farci il cavolo che vuoi, e non spariscono da un giorno all'altro perché qualche testa di noce bruciata ha deciso che la licenza è scaduta. Perché per quelli digitali allora non deve essere così? Io non ci sto, e allora voglio preservarli - per una questione di principio, non perché credo che li riaprirò più dopo la scuola.. personalmente preferisco cercare sul web la qualsiasi cosa che scopro di voler o dover sapere. Come bonus, li caricherò anche online, in modo che chi li vuole scaricare possa farlo (se lo desidera per studio personale e non per uso scolastico, visto che 'sti editori ristampano i libri ogni anno e le scuole cascano sempre nella loro truffa).
_...Ancora in scrittura... Queste note verranno aggiornate di tanto in tanto._

View File

@ -0,0 +1,92 @@
+++
Title = "2⃣ Gaming sincronizzato tra PlayStation 2 e smartphone"
Date = 2023-10-17
Lastmod = 2023-10-18
Downsync = "/it/posts/Notes/Gaming-Sincronizzato-PS2-Smartphone.html"
Description = "Per filo e per segno, come ho ideato un sistema per avere giochi e salvataggi sempre sincronizzati tra emulatore e console PS2 reale, condiviso qui."
Categories = [ "Note", "Gaming" ]
+++
<!-- Autogenerated by ListedDownsync.js. Do not edit (unless also set "% Downsync = False") - it would be overwritten. -->
<h1><span class="twa twa-2⃣"><span>2</span></span> Gaming sincronizzato tra PlayStation 2 e smartphone</h1>
<p>Chi segue le mie avventure da abbastanza tempo e con dovuta attenzione forse lo sa, ma il più grande problema dell'informatica è: come conciliare bene le discrepanze che si vengono a creare quando ci si pone il problema di videogiocare sia a casa che in portatilità? Tra giochi che in un caso sono comodi da giocare e in un altro magari nemmeno girano, e i salvataggi che si spargono per innumerevoli dispositivi diversi, risolvere questo problema in toto non sarà mai possibile...<br>
Eppure, certe volte, l'entropia del cervello è in grado di generare idee particolarmente utili anche a questo proposito, come mi è successo l'altro giorno per la PS2.</p>
<p>Io ho infatti una reale PlayStation 2, console domestica che quando si trova modo di usare è certamente apprezzabile... e che io spesso mi trovavo a non usare, per i motivi sopracitati: né direttamente, perché a casa spesso non mi va, né con emulatore sullo smartphone, perché sentirei che a casa non sfrutterei la vera console dato che i salvataggi aggiornati starebbero solo sul telefono.<br>
E allora, proprio l'altro giorno, fissando la console (non so bene perché), penso che dovrebbe esistere un modo per avere i salvataggi facilmente sincronizzati tra quella e il telefono...</p>
<h2>Intoppo 1: chiavetta o memory card?</h2>
<p>Sul momento, l'idea più semplice a cui ho pensato è stata: esistono <a href="https://www.amazon.it/Adattatore-Memoria-Lettore-Sostitutivo-trasparente/dp/B0C8TTQFJY" rel="noopener nofollow" target="_blank">degli adattatori</a> per usare una scheda microSD come memory card PlayStation (che usano invece un'interfaccia non-standard)... potrebbe convenire comprare uno di quelli, così tengo lì tutti i salvataggi, e a desiderio posso accedervi anche da altri dispositivi spostando la scheda in giro.<sup id="fnref1"><a class="footnote-ref" href="#fn1">1</a></sup><br>
Con una scheda da diversi GB (tanto ormai in giro non se ne trovano di piccole comunque), inoltre, potrei anche fare a meno della chiavetta USB e tenere tutti i giochi solo sulla scheda di memoria!</p>
<p>Per fortuna, questo non è l'unico modo, almeno per certi giochi: <a href="https://github.com/ps2homebrew/Open-PS2-Loader" rel="noopener nofollow" target="_blank">Open PS2 Loader</a>, l'homebrew che esegue giochi commerciali da memorie di backup (come le chiavette USB), supporta l'uso di memory card virtuali (VMC) che sono salvate come file sull'unità USB. I giochi sono alquanto lenti a salvare su quella (la PS2 supporta solo USB 1.1, e in più c'è dell'overhead strano), però è una soluzione apparentemente agibile.</p>
<h2>Intoppo 2: conversione dei salvataggi</h2>
<p>Indipendentemente dalla precedente scelta, scopro però un altro ostacolo: i salvataggi andrebbero convertiti per essere passati dalla console all'emulatore (almeno <a href="https://aethersx2.com" rel="noopener nofollow" target="_blank">AetherSX2</a>, nel bene e nel male l'unico veramente decente ad oggi) e poi viceversa.<br>
Fortunatamente, trovo subito <a href="http://www.csclub.uwaterloo.ca:11068/mymc" rel="noopener nofollow" target="_blank">mymc</a>, un programma talmente antico che richiede Python 2 (mentre al momento siamo da anni e anni al 3), che però funziona, e grazie al cielo offre un'interfaccia a riga di comando.</p>
<p>Di per sé non fa vere conversioni di memory card virtuali, ma permette di manipolare i file contenuti in vari modi. Tutto molto grezzo, ma per fortuna abbastanza sfruttabile per fare proprio quello che serve a me, dopo aver assemblato uno script ideale.<br>
Non mi metto a spiegare come funziona, in fondo all'articolo potete scaricarlo e leggerlo, è una noia. Ho pacchettizzato mymc dentro lo script, così che non vada installato a parte.</p>
<h3>Intoppo 3: convertire dal telefono</h3>
<p><em>Nota 2023-10-18: ho trovato un fork moderno (in Python 3) di mymc, <a href="https://sr.ht/%7Ethestr4ng3r/mymcplus/" rel="noopener nofollow" target="_blank">mymc+</a>... non l'ho (ancora) provato, ma è possibile che questo possa funzionare anche su Android, eliminando il setup intricato che segue, quindi lo menziono.</em></p>
<p>Purtroppo, mymc ha qualche problema a funzionare in <a href="https://termux.dev/en" rel="noopener nofollow" target="_blank">Termux</a> (l'ambiente Linux nativo molto comodo per questo tipo di integrazioni) sul mio Android: non so di cosa sia la colpa, ma in pratica il programma ha problemi a leggere i file VMC, tirando un errore del tipo di <code class="prettyprint">file.vmc: Bad file descriptor</code>. Non ho trovato soluzioni online, nemmeno per ricerche generiche del problema, quindi ho dovuto arrangiarmi. Forse usare un sistema GNU+Linux containerizzato in proot, con le sue librerie e una build diversa di Python 2.7, basterebbe a risolvere il problema, ma chissà.<br>
Dal canto mio, mi stavo iniziando a scocciare, e allora ho optato per delegare la conversione al mio server Debian, facendo svolgere ad uno script in Termux il semplice compito di caricare la VMC sul server, eseguire lì sopra il vero script di conversione, e poi scaricare il file convertito nella giusta posizione in locale.</p>
<p>Prima che mi dimentichi: su Android 13 e superiori (ma già da alcune versioni passate) servono i permessi di root per far leggere e scrivere file da/su memorie esterne (come la chiavetta USB) e cartelle private delle applicazioni (come quella dove AetherSX2 conserva le memory card virtuali).<br>
A quanto ho potuto provare, se non si ha il root bisognerà per forza usare un gestore di file adeguato (e non credo ne esistano di scriptabili, quindi bisogna usare le manine), o forse ADB, per spostare i file in giro... ringraziate Google.<br>
In ogni caso, i miei script hanno scritti dentro i percorsi speciali usati per tutto l'ambaradan.</p>
<p>Usando <a href="https://wiki.termux.com/wiki/Termux:Widget" rel="noopener nofollow" target="_blank">Termux:Widget</a>, ho aggiunto infine due collegamenti al mio launcher di sistema, per la conversione della VMC:</p>
<ul>
<li>uno che va dal formato PS2 a quello emulatore, da eseguire quando voglio giocare su telefono ma i salvataggi sulla pennetta sono stati modificati l'ultima volta dalla PS2;</li>
<li>l'altro per la conversione inversa, da eseguire quando voglio andare a giocare sulla PS2 una volta che è stato l'emulatore ad aggiornare i miei salvataggi.</li>
</ul>
<p>A spiegarlo mi rendo conto che appaia complicatissimo, nella pratica devo solo premere un tasto e aspettare una manciata di secondi.</p>
<h2>Nella pratica: il pregio della memoria unica</h2>
<p>Eliminati gli intoppi, la configurazione è fatta, ed il suo punto di forza sta nella centralizzazione di giochi e salvataggi su un unico dispositivo: la chiave USB. In questo modo:</p>
<ul>
<li>evito la confusione generata da giochi che ho da una parte ma non l'altra, specialmente quando voglio modificare la mia raccolta;</li>
<li>non mi serve una microSD tanto più grande nello smartphone per contenere tutti i giochi che ho già su un'altra memoria portatile, con vantaggi per la stabilità degli altri dati ed il peso del portafogli;</li>
<li>non c'è confusione extra per la gestione di anche i salvataggi, essendo questi gestiti come ho detto prima.</li>
</ul>
<p>Sulla PS2 attacco la pennetta normalmente quando mi serve, invece sullo smartphone devo usare un adattatore USB-C OTG, cosa mediamente scomoda ma c'è poco da fare. Per evitare di perdere 'sti robi in giro, ho attaccato poi un moschettone alla pennina USB, e un anello portachiavi nel buco per i laccetti che ho sulla cover del telefono.</p>
<h2>Concludendo: idee a catena</h2>
<p>Credo che questo sia il sistema più ideale date le mie condizioni iniziali, e nei giorni a seguire lo proverò per bene.<br>
Probabilmente, dovrò comunque procurarmi una memoria esterna più capiente per conservare più giochi, perché quella da 32 GB che uso ora mi è sempre stata strettina.</p>
<p>Magari, prendendone una abbastanza grande, e scrivendo un homebrew apposito, credo di poter adattare questo mio sistema anche per i giochi Wii, usando la stessa memoria anche per quelli... spoiler? 👀</p>
<p>In vera fine, ecco le risorse aggiuntive per questo articolo:</p>
<ul>
<li>La mia domanda iniziale e la breve discussione del sistema su Sony Hacking Zone: <a href="https://t.me/SonyHacking/46784" rel="noopener nofollow" target="_blank">https://t.me/SonyHacking/46784</a>;</li>
<li>Guida all'uso delle VMC su OPL: <a href="https://youtube.com/watch?v=tBrKcJC_E4U" rel="noopener nofollow" target="_blank">https://youtube.com/watch?v=tBrKcJC_E4U</a></li>
<li>I miei script di conversione (su GitLab): <a href="https://gitlab.com/octospacc/Snippets/-/blob/main/Ps2EmuVmcConvert.sh" rel="noopener nofollow" target="_blank">diretto</a>, <a href="https://gitlab.com/octospacc/Snippets/-/blob/main/Ps2EmuVmcConvertCloud.sh" rel="noopener nofollow" target="_blank">via server</a>;</li>
<li>Build Android di AetherSX2 con cui gioco (ultima senza adware): <a href="https://www.apkmirror.com/apk/aethersx2/aethersx2/aethersx2-v1-4-3060-release/aethersx2-v1-4-3060-android-apk-download/" rel="noopener nofollow" target="_blank">https://www.apkmirror.com/apk/aethersx2/aethersx2/aethersx2-v1-4-3060-release/aethersx2-v1-4-3060-android-apk-download/</a>.</li>
</ul>
<div class="footnotes">
<ol>
<li id="fn1">
<p>Su questo riscontro opinioni contrastanti o consigli non troppo chiari, quindi attenzione: non si capisce se questi adattatori funzionino anche come normali memory card per i salvataggi dei giochi (e dunque anche possibilmente come scheda per FMCB), oppure solo come memoria esterna per homebrew come OPL... in ogni caso sarebbe un acquisto potenzialmente valido, considerando le inconvenienze tecniche della USB su PS2.&nbsp;<a href="#fnref1"></a></p>
</li>
</ol>
</div>

View File

@ -0,0 +1,60 @@
// % Categories: Note
// % CreatedOn: 2022-08-05
// % Index: None
# Evitare di richiamare comandi per sbaglio nel terminale
Lavorando nel terminale, magari allo sviluppo di programmi, mi capita spesso di richiamare per sbaglio un comando che non dovrei.
Ciò mi succede perché lavoro in questo modo: modifico qualcosa nella finestra del mio editor di testo di fiducia, quindi passo alla finestra del terminale, e premo `[Freccia Su]` (che richiama l'ultimo comando eseguito) ed `[Invio]` per eseguirlo.
Quello che ho notato è che certe volte, nella fretta, mi capita di premere una volta di troppo `[Freccia Su]`, cosa che richiama il penultimo comando eseguito, o quello ancora prima.
Visto che praticamente queste sequenze di azioni le faccio quasi in automatico, senza leggere per accertarmi che il comando selezionato sia effettivamente quello che voglio prima di premere `[Invio]` (perché solo quello mi aspetto), accade diverse volte che io esegua un comando che non dovrei: spesso, si tratta del comando per fare un commit [Git](https://en.wikipedia.org/wiki/Git){[:MdTgtBlank:]} delle mie modifiche alla cartella di lavoro, e subito caricarle in cloud.
Ora, questa cosa non va bene, perché significa che nella cronologia di Git avrò certi punti "sbagliati": con descrizioni dal testo duplicato, e il codice in uno stato inadatto, non funzionante, perché ero nel pieno di testare alcune modifiche.
Avere una cronologia di Git così conciata intacca decisamente la sua qualità, perché è più difficile trovare un punto specifico passato del codice in futuro, cosa che nullifica una delle funzionalità utili di Git - e in generale è qualcosa che non mi piace, mi da fastidio, vedere la cronologia sporca.
## Lo script
Per risolvere il problema, mi sono inventata questo scriptino (testato con _sh_ e _bash_), l'idea è di avviare i comandi "pericolosi" attraverso di lui nelle situazioni in cui devo fare quelle mie mosse con il terminale (ma, volendo, lo si può impostare come alias per richiamarlo in maniera implicita sempre per un dato comando).
<pre class="CodeScroll"><code>
Profile="~/.bashrc"
a=${RANDOM: -1}
b=${RANDOM: -1}
echo "[!] Confirm your command"
echo "[?] $a + $b = ?"
read Input
if [ "$Input" -eq "$((a+b))" ] 2>/dev/null
then
$SHELL -c "source "$Profile"; $@"
else
echo "[!] Wrong input"
fi
</code></pre>
## Come si usa
Ho salvato il codice all'interno di una funzione `function comconf() { }` nel mio file di profilo bash.
Ora, quando devo eseguire un comando marso, mi basta fare `comconf '<comando>'`; il programma mi chiederà di scrivere il risultato di un'operazione aritmetica semplice generata casualmente, e solo se ciò che scrivo è giusto (quindi, solo se sto prestando attenzione) il mio comando verrà eseguito.
<pre class="CodeScroll"><code>
$ # Esempio
$ comconf 'echo "Prova"; echo "Provina"'
[!] Confirm your command
[?] 1 + 3 = ?
4
Prova
Provina
$
</code></pre>
---
Lo script ha qualche aspetto strano, per esempio il fatto che non funziona se eseguito direttamente dalla shell corrente (ed è per questo che esegue il comando desiderato in un altro processo di shell, con l'argomento `-c`). Per questo motivo, devo anche caricare esplicitamente il mio file di profilo nella nuova shell, perché non viene fatto in automatico e lì ho altri alias e funzioni che mi servono.
Come se non bastasse, se non uso i singoli apici per racchiudere il comando che voglio chiamare, se questo contiene altri apici è come se questi venissero ignorati, e quindi il comando finale si può rompere.
Vabbe, problema risolto ad ogni modo. Niente più incidenti a causa di un `[Freccia Su]` di troppo.

View File

@ -0,0 +1,88 @@
// % Categories: Note
// % CreatedOn: 2022-08-09
# Controllare statistiche interessanti e sulla salute di partizioni su Linux
Le memorie di archiviazione, di qualunque categoria siano, con l'usura si degradano.
Niente si può fare per evitare di doverle cambiare, prima o poi, dopo tanti anni. È però possibile tenere d'occhio il loro stato di salute, per poter identificare eventuali problemi.
Quando si parla di dischi HDD o SSD, il protocollo [SMART](https://en.m.wikipedia.org/wiki/S.M.A.R.T.){[:MdTgtBlank:]} corre in aiuto ma, se, come me, si usano i computer in maniera poco convenzionale, allora il controllare dischi classici non basta.
## Linux va oltre
Un qualcosa di abbastanza segreto, che non molti sanno (così mi è parso, almeno), è che su Linux è possibile accedere alle statistiche di partizioni con alcuni filesystem.
Ciò, ovviamente, in modo indipendente da se si stia usando una pennetta, una scheda SD, un disco rigido, un floppy disk, o anche una memoria ancora meno usuale.
[Ext4](https://en.m.wikipedia.org/wiki/Ext4){[:MdTgtBlank:]} fornisce diversi dati curiosi - e lo stesso dovrebbero fare anche le sue versioni precedenti, Ext3 ed Ext2, ma non ho controllato.
Anche [F2FS](https://en.m.wikipedia.org/wiki/F2FS){[:MdTgtBlank:]} ho visto, direttamente dal mio smartphone Android, espone delle informazioni interessanti.. che non affronterò in dettaglio, perché sono tutte molto oscure e non so cosa significhino; e se non so cosa significano, non sono per me curiose. Capita.
Per quanto riguarda altri file system, non ho visto proprio. Come compito per casa, quindi, vi do quello di vedere se roba come FAT32, exFAT, NTFS, o perché no, BTRFS, espone informazioni belline, su Linux. E come?
## Ottenere i dati
Su Linux, basta navigare nei percorsi `/sys/fs/<filesystem>/<device>` per trovare qualche file interessante.
Si può stampare a schermo il contenuto di ciascuno, affiancato al suo nome, con un semplice comando (eseguito nel relativo percorso): `for i in *; do echo "$i: $(cat $i)"; done`. A meno di avere SELinux attivo - in genere, di default lo è solo sui dispositivi Android, non sui sistemi desktop - non servono nemmeno i permessi di root.
Metto qui sotto in tabella i più interessanti, riguardanti la microSD del mio server (una povera Nintendo Switch che fa girare Ubuntu senza sosta), ci torneremo tra poco.
| Nome | Valore |
| --- | --- |
| errors_count | 0 |
| first_error_time | 0 |
| last_error_time | 0 |
| lifetime_write_kbytes | 1959125105 |
| session_write_kbytes | 1423172308 |
Parlando nello specifico dei file system Ext: per conoscere persino qualche dettaglio in più, e affiancato da un nome comprensibile, ci sarebbe anche il comando `tune2fs -l /dev/<device>`. Questo richiede però i permessi di root e, mentre riporta anche alcuni dei dati che si possono ottenere sbirciando i file di prima, come il numero di lifetime_write, questi possono essere non aggiornati, e relativi solo all'ultimo montaggio della partizione. Quindi, meglio prestare attenzione a questi.
Anche stavolta, riporto le cose interessanti.
| Nome | Valore |
| --- | --- |
| Filesystem created | Mon Jul 26 04:33:17 2021 |
| Last mount time | Fri Apr 15 11:55:30 2022 |
| Mount count | 16 |
## Cose da osservare
Vediamo, uno per uno, l'utilità di questi valori.
Bisogna tenere in conto, però, nel caso non si fosse capito, che i valori parlano dello stato **della partizione, non del media** di archiviazione. Possiamo leggerli solo perché Ext4 li salva e, di conseguenza, se la partizione viene formattata, allora anche questi valori si resettano. Inoltre, consideriamo che potrebbero tranquillamente essere alterati da chiunque con programmi semplici come tune2fs, quindi non sono dati da prendere come perfettamente buoni se persone non fidate hanno accesso alla memoria.
**Filesystem created**:
: La data di creazione della partizione. Semplice, ma può tornare utile per fare stime sulla salute, assieme ai prossimi dati.
**Mount count**:
: Il numero di volte in cui la partizione è stata montata. Questo può essere interessante, se parliamo di una memoria che non è usata in modo permanente su una macchina sempre accesa. Se non esistesse SMART, che dà questo e anche più dati, questo valore sarebbe molto utile sugli HDD.
**Last mount time**:
: La data dell'ultimo montaggio della partizione. Ci può servire in combinazione con altri dati, e basta, credo.
**session_write_kbytes**:
: La quantità, in KB, di dati scritti durante la sessione corrente, ossia dal momento dell'ultimo montaggio. Assieme al valore descritto appena sopra, possiamo usare questo per sapere quanto abbiamo scritto in un periodo di tempo attivo (il corrente).
**lifetime_write_kbytes**:
: La quantità, in KB, di dati scritti da quando la partizione è stata creata. Questa informazione è particolarmente utile sulle microSD, almeno se se ne fa un uso intensivo come me. C'è anche su F2FS.
**errors_count**:
: Il numero di errori, credo sia di lettura che di scrittura, avvenuti nel tempo. Errori frequenti possono essere sintomo di una memoria inaffidabile o semplicemente degradata.
**first_error_time** e **last_error_time**:
: Date, rispettivamente della prima e dell'ultima volta in cui un errore è stato registrato. Può essere utile a capire se eventuali errori capitano di continuo, e quindi bisogna investigare oltre; oppure, se un errore è capitato una volta e poi mai più dopo molto tempo, e quindi si sta bene così.
## Quando serve controllare la salute così?
Bene, OK, queste informazioni sono interessanti, ma: quando servono effettivamente?
Se la memoria di archiviazione in uso - che, se abbiamo deciso di ricorrere a queste misure anziché usare SMART, è probabilmente una microSD o una chiavetta - inizia a dare segni di cedimento, magari rallentandosi nel tempo, oppure corrompendo dati.. Sarebbe opportuno almeno controllare che sia tutto a posto.
Se poi i dati non fanno paura, ma sembrano in regola.. allora è il caso prima di fare una formattazione completa (incluso il ricreare la tabella delle partizioni da zero), cosa resa semplice da programmi come [GParted](https://gparted.org){[:MdTgtBlank:]}, e poi si vede come continua la storia.
In ogni caso, giusto per scrupolo, sarebbe bene fare sempre controlli di routine, così da poter prevedere problemi prima che accada qualcosa di grave.
## Tenere d'occhio le microSD?
Parlando di schede microSD: sono quasi usa e getta, hanno una vita estremamente limitata, visto che i loro chip di memoria sono gli scarti degli scarti della fabbricazione di altre memorie, di gamma più alta, come gli SSD.
Sulla loro effettiva durata, almeno di quelle uscite bene dalla fabbrica e non di sottomarche, cosa si sa?
Se ne leggono di tutti i colori online: chi dice che ogni singola cella di memoria resiste 10000 riscritture, chi dice che puoi al massimo scrivere 1000 volte la capacità della memoria prima che questa fallisca completamente (andando in modalità di sola lettura)... non si arriva ad alcuna conclusione.
Ho avuto schede come quella esaminata oggi, della capacità di 32 GB, che, a parte i quasi 2 TB scritti dall'ultima formattazione, secondo me minimo 3 TB totali in tutta la sua vita li ha visti, eppure sembra ancora a posto; e poi, ho avuto schede che hanno iniziato a dare problemi per molto meno. Sarà che quest'ultime le ho usate con file system schifosi però, come FAT32 o exFAT, e per questo si corrompevano in continuazione.
In conclusione: se abusiamo di schedine, è bene riuscire a controllarle, nei limiti del possibile, nel modo in cui abbiamo imparato oggi.