04 Aug 2011
Voglio dire, non farò tutto lo scalpore del mondo, come ha fatto Linus, con la mia dichiarazione, la quale probabilmente era pure prevedibile: alla fine non ho resistito, e ho installato anch'io XFCE sul netbook. Ovviamente sulla workstation casalinga KDE regna ancora sovrano, dato che con questa 4.7.0 ha trovato ancora meno occasioni per deludermi, ma sul mio piccolino che uso in mobilità per lavorare, scrivere e sbrigare le mie cose, direi che XFCE va più che bene.
Ora, perchè il motivo di un gesto del genere? Beh, direi che è lampante: se per Linus infatti il motivo poteva essere l'innaturalezza di certi gesti, la pazzia di alcune decisioni prese dal Design Team, per me semplicemente il motivo è che il mio povero netbook non regge mica una roba del genere. Mutter e GNOME Shell sono pesanti come un ippopotamo col colesterolo a mille, e di certo gli scatti non mancavano. Con Compiz invece come al solito, situazione completamente diversa: fluidità negli effetti e un po' di "retrogusto vintage" con XFCE come ambiente desktop, che non guasta mai.
Alla fine è funzionale, e per me è ciò che conta.
Questo, naturalmente, con buona pace di Lapo: sicuramente darò ancora tante chance a GNOME che resta, almeno con il ramo 2.X, il desktop environment del mio cuore, solo che... per il momento va così. Non posso permettere che mi venga sottratto anche un solo secondo di operatività da qualche scatto di troppo. Poi, se devo essere proprio sincero, tutto ciò s'è riflesso anche sulla temperatura (ovviamente) della CPU.
Ecco.
03 Aug 2011
Ho parlato nel mio precedente post di come sia flessibile Arch Linux in virtù delle possibilità che Pacman ci dà, di ricompilare grazie ad ABS qualunque pacchetto presente nei repository ufficiali, o di crearcene di nuovi. Oggi voglio dirvi un paio di cose interessanti su KDE 4.7.0 e KWin: la nuova release di KDE infatti tra le novità vede proprio tanta carne al fuoco per il suo gestore di finestre, rinnovato in tanti aspetti, e facente uso adesso, se ricompilato con le giuste flag, di OpenGL ES.
OpenGL ES, ossia OpenGL for Embedded Systems è un particolare comparto del famoso framework grafico che si avvantaggia delle API messe a disposizione dai dispositivi integrati per aumentare le prestazioni, specialmente sui chipset Tegra2 e altri componenti di quel "parentado". Kwin fa uso di tutto ciò? Dall'ultima release, certo. Possiamo quindi ricompilare un pezzo di KDE (compreso il gestore di finestre) per abilitare tutto ciò, e possiamo farlo facilmente dal momento che abbiamo ABS come nostro potente alleato. Andiamo quindi in una directory vuota che adotteremo come workspace:
$ yaourt -G kdebase-workspace
Al posto di usare yaourt potete anche sincronizzare con il comando abs tutto il tree e copiarvi il PKGBUILD a mano, ma sinceramente così è più comodo, anche se richiede che abbiate installato, ovviamente, il blasonatissimo tool.
Purtroppo dobbiamo ricompilare tutto il workspace solo per quattro cose di KWin, ma pazienza. Dobbiamo solo aspettare che il processore faccia il suo sporco lavoro per compiacerci. Intanto installatevi libgles e libegl, poi a questo punto:
$ cd kdebase-workspace && vim PKGBUILD
Al posto di vim potete usare l'editor di testo che preferite, basta che agiate con cognizione di causa :D
Dopo aver aperto il file, localizzate facilmente queste righe:
-DKWIN_MOBILE_EFFECTS=OFF \
-DWITH_OpenGLES=OFF \
-DKWIN_BUILD_WITH_OPENGLES=OFF
E tramutatele in:
-DKWIN_MOBILE_EFFECTS=OFF \
-DWITH_OpenGLES=ON \
-DKWIN_BUILD_WITH_OPENGLES=ON
Perfetto. Abbiamo abilitato ciò che ci serve. Adesso, possiamo tranquillamente lanciare il processo di build:
$ makepkg
Attendiamo. Io ho un dual core e tutto il compilame vario ha impiegato una quindicina di minuti per finire il tutto; sicuramente sul vostro esacore con hypertreading ci metterà molto meno. Appena finito, dopo una breve (spero per voi o dovete far controllare l'hard drive) fase di impacchettamento, makepkg ci sputerà fuori un pacchetto pronto per essere installato sul nostro sistema.
# pacman -U *.pkg.*
Con questo comando andiamo a sostituire il pacchetto creato dal buon Andrea 'BaSh' Scarpino (che ringrazio per la distribuzione di KDE che ci offre, sempre impeccabile) con il nostro. Riavviate e godetevi lo spettacolo... spettacolo che, ovviamente, per chi non gode di OpenGL ES si concluderà con un imbombamento generale del compositing di KWin. Per voi fortunati che avete schede video compatibili con queste estensioni, se non fate questo procedimento sarete passibili di pena di morte. Ché io non posso.
01 Aug 2011
Negli ultimi tempi, mi è stata fatta spesso e volentieri la domanda clue del perchè uso Arch Linux: cosa rende Pacman un package manager migliore? O comunque, in cosa esso si distingue da gestori di pacchetti blasonatissimi come APT o Yum, o anche Zypper? In questo articolo che scrivo adesso, provo a fare mente locale, sia per me che per le persone che mi hanno fatto spesse volte questa domanda; in quanto AUR packager, cercherò di mantenere comunque un tono critico sulla questione e non convincervi che il vino è buono solo perchè io sono l'oste. Un grazie speciale a Zidagar che mi ha per così dire triggerato, dato che senza il suo domandone di sabato (e successivi commenti) su Linux Italia non sarei stato stimolato così intensamente a scrivere un post del genere. Allora, pronti? ;)
Semplicità prima di tutto
Pacman è un gestore di pacchetti semplice, sia come ovvio nel funzionamento e nel comportamento, che nella sintassi: è infatti molto più comodo, almeno per me, usare Pacman piuttosto che qualsiasi altro gestore di pacchetti. Appendendo infatti lettere singole alle opzioni più generali possiamo generare comandi che eseguano più di una azione, così se di solito abbiamo bisogno di più comandi o di stringhe chilometriche ed espressioni regolari lunghe un miglio, il package manager di Arch Linux ci viene incontro mettendo a nostra disposizione la possibilità di fare millemila cose con un solo, brevissimo comando.
In cosa si traduce questo? Beh, ovviamente si traduce nel fatto che possiamo usare tutte quelle ore sprecate a digitare caratteri su caratteri in qualcosa di molto più proficuo, come patchare un software o rimediare a qualche configurazione errata di sistema che sicuramente avrete dimenticato nel posto sbagliato al momento sbagliato. Quindi insomma, niente di trascendentale se uno ha le competenze, ma tutto di guadagnato.
C'è poi un discorso di funzionamento di base, che almeno a me è molto comodo: se altri gestori complicati incorrono per esempio in problemi di dipendenze e configurazioni lasciate in sospeso, grazie al fatto che la configurazione viene svolta in gran parte dall'utente e c'è molta poca dinamicità in fase di installazione, comunque una volta dato un comando di gestione dei pacchetti è veramente molto difficile se non impossibile che il package manager si pianti a metà del lavoro dicendo che c'è quel pacchetto non configurato e quell'altro in attesa di cose mistiche. Altro tempo libero dunque, che possiamo dedicare a leggere un buon libro, ad esempio L'Etica Hacker di Pekka Himanen.
Flessibilità quanto basta (cioè molto)
Sicuramente Pacman è concepito in maniera tale da risultare molto flessibile. Il suo concetto di semplicità fa si che con un comando io possa agire chirurgicamente sui pacchetti installati, rimuovendone alcuni senza compromettere il funzionamento del sistema di gestione del software, fregandomene poi di tutto ciò che è il sistema di dipendenze. Questo significa che per sostituire un pacchetto dipendenza di altri, mi basta rimuoverlo e, facendo un po' d'attenzione, inserire il mio nuovo pacchetto non dando troppo fastidio ai software in esecuzione: in questo modo avrò personalizzato il sistema senza dover scoperchiare necessariamente tutto; la magia è resa possibile dal fatto che Pacman viene distribuito insieme ad un set di script che lo completano e che sono il suo vero punto di forza.
Se infatti la gestione del software risulta semplice ed agevole, comunque la flessibilità estrema (anche se non quanto Portage ovviamente) viene raggiunta concependo Pacman non come un sistema di gestione dei pacchetti, ma come un sistema di ibridazione tra la manutenzione tradizionale dei programmi tramite il paradigma a pacchetti, e la gestione dei ports. I ports sono quella cosa che ha reso tanto famosi BSD e Gentoo: file di testo addetti a istruire un sistema di script su come compilare ed installare un determinato tarball. Assieme a Pacman abbiamo quindi makepkg che si occupa di creare pacchetti dai PKGBUILD, ossia i file testuali che noi o altri scriviamo per compilare un software senza problemi. E assieme a Pacman e makepkg, ci viene fornito l'ABS, ossia l'Arch Build System, il quale consiste di tutti i file PKGBUILD dei pacchetti presenti nei repository ufficiali.
Avete capito bene. Questo significa che se non ci sta bene come è stato compilato un pacchetto dagli sviluppatori della distro, possiamo prenderci il PKGBUILD, personalizzare tutto in base alle nostre esigenze, dai metadati di pacchetto alle flag, al processo di build, e poi darlo in pasto a makepkg che ci sputerà fuori dopo la fase di compilazione e impacchettamento, un pacchetto fatto da noi secondo le nostre esigenze. Questa modularità fa si che Pacman possa essere utilizzato in maniera assolutamente proficua anche per server, o per configurazioni particolari che magari hanno bisogno del tale software compilato in una certa maniera (flag particolari, e quant'altro).
In aggiunta a questo, è anche semplicissimo e facilissimo mantenere un repository per Pacman, soprattutto con l'ausilio di un paio di scriptini editi dalla comunità, ma di questo magari ve ne parlo un'altra volta.
Pacman sa farsi da parte
Volete il pezzo forte? Il bello di Pacman è che se non ci sta bene come funziona, possiamo sostituirlo. Ebbene si, possiamo mandarlo a quel paese allegramente e gestire il nostro software in mille altre maniere :D
Questo è possibile grazie alle libalpm, ossia le LIBraries for Arch Linux Package Management, scritte in maniera separata da Pacman, il quale è solo un wrapper di questi file: esistono package manager alternativi, come il famosissimo Clyde, che purtroppo è defunto da poco per mancanza di tempo da parte dello sviluppatore principale; tra l'altro, essendo stato io un utente di Clyde in passato, invito fortemente chi sa programmare (non io che sono, detto chiaramente, una pippa come developer) a prendere in mano il progetto. Insomma, Pacman sa fare le cose in maniera semplice, pulita, non sporca, mangia poco e disturba ancora meno, come abbiamo visto. Ma vale veramente la pena passare ad Arch Linux (e a Pacman) se si vive bene senza?
Pacman VS The Others
Non ho molte parole da spendere in questo caso. Posso dire che, sicuramente, utilizzare una distro come Arch Linux che ha un approccio radicale e assolutamente nuovo al software, è un'esperienza di vita. Se quindi siete un po' annoiati una domenica pomeriggio, anzichè sbragarvi sul divano a fare niente, prendetevi Virtualbox e mettete su una bella macchina virtuale con l'ultimo media di installazione di Arch impostato per il boot. Sicuramente, non solo vi divertirete un mondo, ma forse vi piacerà così tanto come è fatta la distribuzione, e come è fatto Pacman, da dargli una chance sulla vostra workstation.
Sicuramente il buon Pacman manca di un'interfaccia grafica adeguata; APT possiede ad esempio Synaptic, ma proprio per questo, se per fare operazioni complesse con APT abbiamo bisogno del suo blasonato frontend, grazie alla semplicità di cui sopra Pacman non ha bisogno di queste cose: dalla CLI abbiamo tutto ciò che ci serve, senza doverci complicare ulteriormente la vita.
Che la Forza sia con voi.
29 Jul 2011
Vediamo. Da un po' di settimane, ormai, è stata rilasciata questa nuova spettacolosissima versione dell'Android Market, che apporta modifiche pesanti sia all'interfaccia, come risulta sin da subito, sia, come è meno visibile, a tutta una serie di algoritmi sottostanti per il download e la gestione delle applicazioni. Avendo usato un po' tutta questa robaccia sin da subito, dato che da buon curiosone ho immediatamente sostituito il "vecchio" Market con l'ultimo, posso dire di essermi fatto un'opinione su questa release e sul suo primo update, ovviamente correttivo di alcune delle lacune che andrò a descrivere.
La nuova interfaccia
Tutto ciò ha portato una polemica molto grande. La nuova interfaccia dell'Android Market infatti si palesa con una nuova schermata per le app "pubblicizzate" che a molti ha ricordato, per via sul suo stile un po' a blocchi, Windows Phone 7. In realtà dopo due minuti di uso approfondito ci si accorge che lo stile grafico forse un po' Metro-style (got the point) viene abbandonato nelle altre tab, le quali godono di un design pulito, funzionale, e introducono delle belle cosette fondamentali di cui sentivamo molto la mancanza, come tutte quelle fantastiche sciccherie fattibili attraverso il sistema di rating e che Google ha tardato ad implementare per mancanza di tempo, mancanza di voglia, o semplicemente la necessità di portare a tutti un sistema funzionante piuttosto che sprecarsi in queste - diciamolo - scemenze di secondo piano.
Ora però che abbiamo il re dei sistemi mobile tra le nostre mani, era necessario adottare un marketplace più maturo, ed eccoci qua. Interfaccia rinnovata, molto bella sia nel suo comparto a blocchetti per le "featured apps" che nel suo layout più tradizionale a lista di coppie. Il problema è che tutto ciò, incredibilmente, si è riflesso in una scattosità del tutto: il Market nella sua ultima release è diventato elefantiaco in quanto a prestazioni grafiche, cosa inaccettabile, e anche se con l'ultimo update le cose sono migliorate sensibilmente, comunque lo scrolling è poco fluido, e l'interfaccia molto poco reattiva.
Il substrato
Insieme all'interfaccia grafica, è cambiato anche il modo di gestire le applicazioni nell'Android Market. Per carità, non mi riferisco ai link sulla memoria fisica, i quali sono rimasti invariati, bensì agli algoritmi utilizzati per l'installazione parallela di più applicazioni: se infatti prima le applicazioni venivano scaricate ed installate in parallelo, sforzando parecchio la CPU e producendo anche più di un errore, il nuovo gestore di download e installazioni procede in una finestra di due applicazioni installate in contemporanea, e anzi è maggiormente restrittivo, nel senso che mentre un'app viene installata la successiva viene scaricata. Non vengono quindi mandati in esecuzione due processi di installazione (e di download, anche) simultanei, per favorire l'assenza di errori durante il processo di aggiornamento.
Purtroppo l'aggiornamento andato a buon fine non è qualcosa che il nuovo Market contempla :D
Con questo intendo dire che nonostante la bontà dei nuovi algoritmi, il marketplace risulta ancora in uno stato embrionale: una volta aggiornata una specifica applicazione, questa risulta ancora in download. E l'ultimo update non ha corretto questo fastidioso comportamento. Bisogna quindi (lo suggerisco) fare riferimento al sistema di notifiche il quale ci dice correttamente cosa sta succedendo.
Conclusioni
Che dire quindi? Tutto ciò mi stuzzica. Mi aspetto che mentre Google lavora al sistema operativo rimedi a un po' di questi bachi che sinceramente sono molto fastidiosi, dato che comunque in fase di gestione del software installato non mi fanno avere le idee molto chiare su cosa ha finito di scaricare, cosa no, eccetera eccetera. Inoltre, purtroppo, se questo aggiornamento per l'interfaccia dell'Android Market poteva essere una cosa decisamente buona, giusta e benvenuta, comunque l'interfaccia grafica così poco snella mi fa rabbrividire, e se penso che posseggo un Desire (1GHz di CPU), tremo al pensiero di come può viaggiare un'applicazione del genere su dispositivi con una CPU un po' più ristretta.
28 Jul 2011
Che poi, pensavo, in uno dei miei deliri, che effettivamente il fatto che una macchina si pianti è un episodio abbastanza comune, specialmente con sistemi che gestiscono i problemi alla solita vecchia maniera, e cioè con un freeze totale delle risorse.
Ma allora, perchè diavolo invece di inventare combinazioni palesemente per le emergenze, i produttori non hanno introdotto, o meglio il form factor comune delle tastiere non è stato modificato per inserire un centoseiesimo tasto che svolga la funzione di CTRL-ALT-CANC, anche solo quella? Tanto, sono sicuro che sarebbe consumato quasi quanto la mia "a", che già non si vede più.
