linux

Per poter fare il mount di un account google drive su un path possiamo usare l'applicazione google-drive-ocamlfuse:

https://github.com/astrada/google-drive-ocamlfuse

Attraverso il filesystem FUSE è possibile usare lo spazio google drive come un normale disco.

Una volta installata l'app, occorre usare il comando senza opzioni per generare la directory con le configurazioni di sistema (~/.gdfuse/default), e creare il collegamento con google drive (attraverso un processo di autorizzazione).

google-drive-ocamlfuse [-label XXX]

(L'opzione -label è facoltativa, e serve solo per poter fare più autorizzazioni ad account google diversi, ognuno con una sua label).

Non funziona più il touchpad del vostro notebook? Per me la soluzione funzionante è stata questa:

ln -s /usr/share/X11/xorg.conf.d/50-synaptics.conf /etc/X11/xorg.conf.d/50-synaptics.conf

(Ovviamente da eseguire come root)

Il motivo per cui arch linux ha parte delle configurazioni su /usr/share/X11 e parte in /etc/X11 (ma solo quest'ultimo realmente funzionante) non lo so. Ci sarebbe da indagare... ad avere il tempo...

Avendo necessita di fare l'upgrade del firmware del mio nuovo PC ho dovuto fare un boot nel buon vecchio MS-DOS... usando FreeDOS!

L'operazione è stata più travagliata che fare il flash del firmware!

Il problema principale è stato mettere un FreeDOS che funzionasse su USB. Unetbootin non ne voleva sapere di creare un file system bootabile realmente, e dopo aver seguito varie guide ho lasciato perdere.

La soluzione più veloce è venuta da questo sito:

http://chtaube.eu/computers/freedos/bootable-usb/

Che fornisce direttamente delle ISO belle e pronte da bootare. Allego qui la ISO che ho usato io (quella da 2Gb) e il metodo per schiaffarla in chiavetta:

X2go è una soluzione interessante per il controllo remoto di una macchina. Assieme almodulo "x2go desktop sharing" è anche possibile "subentrare" da remoto in una sessione desktop presistente, soluzione ideale se avete più macchine da comandare (ad esempio, come nel mio caso: PC di lavoro e PC di casa).

Può capitare di eseguire un programma che non parte per la mancanza di qualche libreria condivisa, ma magari l'errore mostrato non è sufficientemente chiaro da permetterci di capire quale dipendenza manca. Oppure capiamo quale libreria è cercata, e ci risulta installata, ma il programma riporta comunque errore (Situazione che capita in genere quando usiamo software scaricati già compilati).

Per avere un elenco delle librerie richieste e dove vengono cercate/trovate (o se non sono trovate) è sufficiente usare il comando LDD

ldd [file binario o libreria]
LD_LIBRARY_PATH=mypath/lib ldd lib_test.so

In uno dei miei pc, guardando i messaggi di sistema tramite "journalctl -f" o "dmesg", ogni tanto mi accorgevo di questi errori ciclici:

lug 25 00:01:02 golconda kernel: sd 6:0:0:0: [sda] Test WP failed, assume Write Enabled
lug 25 00:01:02 golconda kernel: sd 6:0:0:0: [sda] Asking for cache data failed
lug 25 00:01:02 golconda kernel: sd 6:0:0:0: [sda] Assuming drive cache: write through

Non c'erano sempre, ma quando c'erano iniziavano ad apparire ogni 30 secondi circa. L'ultima volta sono partiti dopo aver usato il lettore SD.

Comunque, la soluzione per me è stata questa:

[bash]

sudo sh -c 'echo "options ums_realtek ss_en=0" > /etc/modprobe.d/ums-realtek.conf'

sudo rmmod ums_realtek

Il comando screen permette di avere una interfaccia tra un terminale fisico (in pratica: noi) e un comando (in genere la shell). Tale interfaccia, che agisce da proxy, permette anche ad altri terminali fisici di "agganciarsi".

In sostanza: possiamo interagire con la stessa shell da più terminali.

Screen fa molte altre cose: ad esempio agisce da vero e proprio "window manager di terminale", permettendo di avere in una sessione più finestre di shell aperte. Ma sono funzionalità che in questo articolo non verranno trattate.

Sto modificando /etc/default/grub e mi viene un dubbio... che differenza c'è tra le voci GRUB_CMDLINE_LINUX_DEFAULT e GRUB_CMDLINE_LINUX?

Dopo aver fatto una verifica, solo questa: i modificatori in GRUB_CMDLINE_LINUX vengono applicati a tutte le voci, mentre quelli in GRUB_CMDLINE_LINUX_DEFAULT solo alle voci che non sono recovery.

In pratica: l'opzione "quiet" meglio metterla in default (così in modalità recovery vediamo tutti i log), così come tutte le opzioni "facoltative" per il boot. Le opzioni fondamentali per il corretto funzionalmento del kernel invece meglio metterle in GRUB_CMDLINE_LINUX, così vanno anche in recovery.

Se non riusciamo a fare un unmount perchè ci viene detto che la periferica è in uso usiamo il comando:

fuser -m /dev/sdd1

Otterremo i PID dei processi. (Al posto di /dev/sdd1 c'è il device, oppure il mountpoint).

Aggiungendo "-k" faremo automaticamente il kill di quei processi.

Se il nostro sistema linux diventa spesso lento e "non responsivo" in genere questa cosa si riflette nel fattore di carico del sistema (system load). Una analisi di questo fattore ci può permettere di individuare il collo di bottiglia della nostra macchina (in genere riconducibile a 2 fattori: cpu o disco).

Per vedere il carico di sistema occorre eseguire il comando "uptime" (o il comando "w"):

11:54:57 up 1 day,  2:00,  2 users,  load average: 0,77, 0,84, 1,05

Gli ultimi 3 numeri rappresentano il carico medio nell'ultimo minuto, negli ultimi 5 minuti e negli ultimi 15.