KDE Flickering

Problema: KDE 5.9 su Kubuntu 15.10 e scheda grafica NVIDIAGeforce 9600M GT e lo scherma sfarfalla ad ogni visualizzazione/cambio di finestra.

Nelle impostazoni del Composer ho modificato il rendered ad OpenGL 2 a OpenGL 3.1 e tutto ha iniziato subito a funzionare.

NOn è la prima volta che mi capita, ma solitamente questa impostazione sballata aveva solo l'effetto noioso di non far funzionare bene i cambi di desktop (tridimensionali), ma questa volta si è presentato con uno sfarfallio veramente molto noioso.

java: No such file or directory (!)

Ci sono applicazioni che richiedono un JDK per eseguire correttamente, così l'unica cosa che si può fare è quella di scaricare dal sito Oracle una qualche versione, installarla, configurare JAVA_HOME o qualcosa di simile (a seconda dell'applicazione) e lanciare il programma desiderato.

Abbastanza semplice, no?

Eppure oggi ho dovuto combattere con una installazione della JDK 1.8 (111) e un errore abbastanza subdolo riportato dalla shell:

/opt/jdk1.8.0_111/bin/java: No such file or directory

quando ovviamente il file era al suo posto, eseguibile e pronto a servire il sistema.

Inizialmente ero protato a pensare ad un classico problema di permessi, ma come ho già scritto il file era correttamente eseguibile. Forse un problema di exec sul filesystem? No, nemmeno questo.

Dopo un po' di ricerca ho scoperto che il mio pc mancava di una libreria, e quindi ben presto si è fatto un passo avanti:

sudo apt-get install libc6-i386

ma questo ancora non era sufficiente a far funzionare tutto l'ambiente, specialmente quello grafico, e così ho dovuto installare anche

sudo apt-get install libxrender1:i386 libxtst6:i386 libxi6:i386

e finalmente ho un jdk funzionante perfettamente.

Certo che il primo errore, quello riportato dalla shell, è piuttosto fuorviante!

Linux & UEFI boot...mannaggia a WIn8

Mannaggia a Windows 8 e al sistema UEFI!

Installare Linux su macchine recenti puo' diventare un vero macello se non si tiene in considerazione delle nuove disposizioni (perche' mi rifiuto di chiamarla tecnologia) di avvio.

Ora capita che debba installare Linux come unico sistema oeprativo su un computer recente con Windows 8 pre-installato.

Dimenticamendomi completamente dei requisiti UEFI cancello tutto il disco e procedo all'installazione.

Pessima idea: cancellare la partizione UEFI preimpostata previene il boot del computer, anche se l'installazione va a buon fine.

Occorre allora rimediare, e in effetti il trucco e' abbastanza semplice (e per certi versi mi riporta indietro alle prime installazioni che facevo ove anche /boot aveva la sua partizione): occorre creare una partizione di tipo EFI (EF00) come prima partizione su disco e assegnarle il mount point /boot/efi. Il filesystem deve essere comprensibile da "tutti", quindi deve essere un vfat.

E' sufficiente questo per permettere il regolare boot del sistema.

% sudo gdisk -l /dev/sda
...

Number Start (sector) End (sector) Size Code Name
1 2048 1050623 512.0 MiB EF00 EFI System Partition
2 1050624 137768959 65.2 GiB 8300
3 137768960 274487295 65.2 GiB 8300
4 274487296 323315711 23.3 GiB 8300
5 323315712 342847487 9.3 GiB 8300
6 342847488 733472767 186.3 GiB 8300
7 733472768 741285887 3.7 GiB 8200
8 741285888 976771071 112.3 GiB 8300

% mount | grep sda1
/dev/sda1 on /boot/efi type vfat
(rw,relatime,fmask=0077,dmask=0077,codepage=437,
iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

Compilare Emacs 25.1 (per Spacemacs): segmentation fault

Se si tenta di compilare Emacs 25.1 su una Kubuntu 16.10 si potrebbe avere un errore di segmentation fault.

La soluzione e' abbastanza semplice: occorre impostare un flag del compilatore e ritentare.

./configure --prefix=/opt/emacs25.1 CFLAGS=-no-pie

Il flag no-pie produce un eseguibile che non puo' essere posizionato arbitrariamente, e questa e' una misura di sicurezza per evitare exploit sulla memoria.

Se poi si usa Spacemacs, una nuova installazione risolve diversi problemi e consente anche di far funzionare tutti i layer correttamente (ad esempio con PHP avevo alcuni problemi legati ai font-face), ma per un uso ottimale occorre che sia presente la libxml2 (-dev) affinche' si possa compilare anche il supporto alla documentazione. Ovviamente quest'ultimo punto non dipende da Spacemacs.

Ubuntu do-releease-upgrade: worst update manager ever (?)

Ok, I'm not the right person to judge the good quality efforts behind the Ubunt/Kubuntu update manager, but I have to say that I was never able to do a clean upgrade without any problems. The last time I upgraded my whole system I spent almost a week trying to get 3D video card acceleration back, as well as tuning again my Perl library and RT.

Sounds like it is not a well-automated upgrading...at least in my experience.

Kubuntu upgrade...

Quando programmo un upgrade di sistema con Kubuntu so gia' in partenza che devo aspettarmi qualche casino.

Non so se sia solo un problema mio, diciamo che non ho mai speso molto tempo per comprendere bene il sistema di upgrade Debian, sta di fatto che nel caso di Kubuntu ho sempre avuto dei problemi.

Che si tratti di una distribuzione LTS o meno, al termine dell'upgrade ci sono parecchie cose che non funzionano.

Spesso si tratta del desktop che non parte piu'.

A volte la stampante non funziona.

Ma con l'ultimo aggiornamento è stato peggio.

Apparentemente Eclipse non proponeva piu' l'autocompletamento con CTRL-space, ma subito non gli ho dato importanza.

Molto piu' grave: Perl non funzionava piu'.

Quello che ho scoperto è che Perl è stato aggiornato dalla versione 5.14.2 alla 5.18.2, peccato che tutte le librerie installate con CPAN fossero in una cartella specifica /usr/local/share/perl/5.14.2 e che ora Perl avesse @INC impostato alla corrispondente 5.18.2, vuota!

Così ho "invertito" le due cartelle, cosa che mi è sembrata la soluzione piu' rapida e ho lanciato un upgrade completo dalla shell CPAN.

Nel mentre che attendevo ho scoperto che la combinazione CTRL-space non funzionava anche in Emacs, orrore!

Ebbene colpa questa volta del selettore della tastiera, che appunto con tale combinazione modificava il layout e la lingua di input. Ecco quindi che disabilitando questa (per me) inutile funzione gli editor hanno ripreso a funzionare correttamente.

kwin dove sei finito (ossia l'ennesimo update sbagliato)

Ancora una volta il sistema di update automatico di (k)Ubuntu mi ha deluso.

A seguito di un normale upgrade, e pur avendo letto tutte le informazioni, il mio desktop KDE ha smesso di funzionare correttamente. In particolare kwin, il gestore di finestre, non reagiva lasciando le finestre prive di bordo e titolo. Il resto del desktop sembrava funzionare regolarmente e anche lo switch fra le applicazioni si comportava correttamente, ma nulla da fare per le window-decorations. E a nulla e' servito un ben assestato

kwin --replace

Unica soluzione fare un nuovo aggiornamento pulito con installazione fresca della nuova versione del desktop.

Ritengo che Linux sia una buona scelta per il desktop, ma occorre che le distribuzioni risolvano questo fastidioso problema dell'aggiornamento-che-spacca-tutto-il-sistema. O quantomeno prevedano un buon sistema di rollback (a chi viene in mente BootEnvironment di OpenSolaris e FreeBSD?).

Ubuntu & Qt

Come si puo' leggere da un post di Mark Shuttleworth la prossima release di Ubuntu verra' distribuita con applicazioni basate su Qt all'interno del cd di installazione. L'idea di fondo e' buona: si apre la strada a configurazioni Qt-based e binding per far convivere una applicazione Qt all'interno del desktop Gnome come fosse una applicazione nativa. Va notato che si parla di applicazioni Qt, non KDE, che sono a loro volta uno "strato" sopra quello normale delle applicazioni Qt. Cio' significa anche che, nel breve termine, e' piu' facile vedere integrata una applicazione Qt pura che una KDE, anche se lo stesso Mark non esclude che in futuro le applicazioni KDE, forti dei nuovi binding Qt, possano integrarsi meglio con il desktop Ubuntu.
La notizia e' sicuramente positiva, poiche' una maggiore adozione di Qt non puo' che incidere positivamente su KDE, che potrebbe essere brutalmente considerato il "Qt-desktop". Tuttavia penso che le ragioni dietro a questa scelta da parte di Canonical non siano cosi' Open Source come le si vuole vendere. Anzitutto non capisco perche' spingere per questa integrazione Qt quando KDE ha sempre aderito agli standard OpenDesktop; sarebbe sicuramente meglio che entrambi i desktop aderissero appieno agli standard per una maggiore interoperabilita'. Analoga considerazione puo' essere fatta nei confronti delle impostazioni utente e della configurazione di entrambi i desktop. Ma ancora non mi convince il fatto che questo processo di integrazione sia rivolto a Qt e non a KDE. Ubuntu vuole avvicinarsi al mondo Nokia, grande sostenitore di Qt? Non posso poi fare a meno di notare che questa apertura verso il mondo Qt arriva proprio nel momento "vivo" della migrazione a GTK+3 e al relativo desktop Gnome 3, e anche se Mark specifica nel suo post che non si tratta di una critica a Gnome/GTK+, penso che questa cosa non sia completamente scorrelata.
Infine non bisogna dimenticare che, mentre KDE ha sempre cercato di lavorare in modo compatibile con GTK+, lo stesso non vale per Gnome. Da un certo punto di vista KDE e' sempre risultato piu' aperto alle altre realta', basti pensare che molti widget di Plasma sono stati portati verso altre piattaforme, o che esiste la possibilita' di applicare temi specifici alle applicazioni GTK+ sotto KDE (non sono a conoscenza di un'analogo sistema sotto Gnome); Gnome dall'altra parte e' sempre stato molto GTK+ centrico, e anche per motivi ideologici (si vedano i commenti di Stallman e l'idea dietro all'intero progetto) e' sempre stato riluttante ad accettare lavori "esterni".
Francamente non riesco a giudicare pienamente positiva questa notizia, ma devo anche riconoscere che Ubuntu ha la potenza, la diffusione e il bacino di utenti tale per smuovere le comunita' verso una vera integrazione, obbiettivo fallito miseramente in passato. Vedremo in futuro se questi sforzi saranno a vantaggio esclusivo di Canonical/Ubuntu o se forniranno qualcosa di utile anche agli sviluppatori.

Kubuntu 10.04 & Network Management Disabled

Una cosa piuttosto noiosa del network manager di KDE (KNetworkManager) è l'incapacità di ripristinare la funzionalità delle schede di rete, soprattutto quelle wireless, qualora il sistema venga sospeso o vada in stand-by.
Quando il network manager continua, insistentemente, a riportare che il network management è disabilitato, la soluzione consiste nel:

- editare il file /var/lib/NetworkManager/NetworkManager.state impostando lo stato del networking da disabilitato ad abilitato (NetworkingEnabled=true)
- riavviare il servizio di network management con service network-manager restart