Di Sandboxed Applications e di come cambieranno il modo di distribuire software in Linux

Il sistema di gestione delle applicazioni in Linux si basa sul concetto di pacchetti.
Una singola applicazione è divisa in uno o più pacchetti, e per funzionare richiede l’installazione, oltre che dei propri, anche dei pacchetti relativi alle sue dipendenze , ossia programmi/librerie scritti da terzi e liberamente utilizzabili da chiunque. Questi pacchetti sono organizzati nei depositi (notoriamente detti repository ).

Vantaggi di questo sistema:

  • Basta un semplice comando da terminale o pochi click nel gestore di pacchetti della distro per avere installato il proprio programma preferito.
  • I repository contengono software sicuro e controllato, usandoli si è – relativamente – sicuri di ciò che si installa.
  • Gli aggiornamenti di programmi e librerie sono centralizzati, non dovremo aggiornare i vari programmi singolarmente uno alla volta o, peggio, ricevere infinite richieste di aggiornamento all’avio del computer se non lo usiamo da molto (mi riferisco a te, odiato winzozzo…).
  • Riduzione dello spazio occupato, su hd e in memoria, poichè applicazioni che utilizzano le stesse librerie possono condividerle automaticamente.

Tutti ottimi motivi, ma ci sono anche diversi svantaggi :

  • Impossibile o molto difficile avere differenti versioni dello stesso programma installate contemporaneamente nella propria linux-box .
  • Nessuna separazione concettuale tra librerie di sistema e applicazioni utente.
  • Ogni distribuzione fa storia a se: non è possibile creare un pacchetto di un programma che sia valido per tutte le distro.
  • Impossibile (o complicato) pacchettizzare programmi per distro le cui librerie sono meno aggiornate rispetto a quelle richieste, o che non hanno fra i loro pacchetti quelli richiesti dal programma.

Come risolvere il problema?

Gli sviluppatori Gnome/Fedora stanno da tempo lavorando sulle Sandboxed Applications che offriranno i seguenti vantaggi:

  • Utilizzare un sistema di bundle del programma che, una volta creato, sarà valido su qualunque distro si scelga di installarlo, indipendentemente dalle librerie in esso contenute.
  • Migliorare la privacy dell’utente limitando l’accesso delle applicazioni alle risorse strettamente necessarie per il loro funzionamento: un editor di testo non potrà per esempio accedere alla rubrica della mia mail o alla webcam installata sul mio portatile (da qui il termine ” sandboxed “).
  • Rendere più agevole la creazione del software da parte dei programmatori permettendogli di lavorare in una sandbox apposita.

Ok, ma tecnicamente di che si tratta?

La vera novità riguarda l’introduzione del concetto di runtime , ove per runtime si intende un ambiente ( environment ) ben definito in cui una applicazione possa funzionare.
Esempi tipici di runtime potranno essere “Gnome 3.14″ o “KDE 5.6″.
Potremo avere più runtime diversi installati contemporaneamente, come pure differenti versioni dello stesso runtime .

Un’applicazione pensata per un determinato runtime potrà utilizzare tutte le risorse disponibili in quello specifico runtime. Se avrà bisogno di ulteriori librerie dovrà includerle nel bundle con cui verrà distribuita.
Quindi per capirci meglio, se ho una ubuntu LTS con librerie obsolete potrò installarci sopra il runtime “Gnome 3.x” e grazie ad esso potrò installare versioni recenti altrimenti non disponibili per il mio sistema, se non tramite ppa appositi. Il tutto con i vantaggi della sandbox e col vantaggio, per gli sviluppatori di terze parti, di poter creare un unico bundle valido per ogni distribuzione linux che supporta i runtime .

Considerazioni personali

Il progetto in atto è molto ambizioso, smuove dalle fondamenta il concetto stesso di distribuzione Linux. I lavori sono già molto avanti (come prossimo obiettivo c’è la definizione di un runtime di riferimento per la prossima versione di Gnome, la 3.16) e sarà interessante seguirli.
Personalmente ritengo che sia ottimo il tentativo di tutelare la privacy degli utenti tramite sandbox , in fondo è proprio questo che mi aspetto da un sistema free software che pone l’utente al centro della propria esistenza.
Ottimo anche l’idea del runtime , che potrebbe eliminare per sempre la classica risposta dello sviluppatore quando qualcosa non funziona, ossia: “funziona sulla mia macchina”.
I dubbi sono semplici. Come le distro accetteranno questo cambiamento? Un sistema tale non rischia di creare un altro ” walled garden ” come i tanto criticati app store di Android e iOS?
Di certo sarà interessante seguire gli sviluppi di tutto ciò.

Link per approfondire

Wiki ufficiale delle Sandboxed Applications
Blog post originale

Pubblicato in informatica, linux | Contrassegnato , , , , , , , , , , | 1 commento

Come copiare il risultato di uno script Python3 nella clipboard su Linux

Terzo post in poco tempo, mi ci sto (ri)mettendo d’impegno a quanto  pare.

Recentemente ho ripreso a programmare e mi è preso il vezzo di creare uno script che creasse un separatore per il mio codice, qualcosa del tipo

######----------     GESTORE EVENTI      ----------######

Dato il testo centrale del separatore (in questo caso “GESTORE EVENTI”) lo script mi crea un separatore come sopra che occupi esattamente le 72 colonne di uno script Python;  In pratica mi ‘centra’ il testo nel separatore.

Lo script, che riporto qui in basso, è abbastanza banale (e andrebbe raffinato), ciò che invece mi ha creato problemi è stato il capire come fare a passare il separatore appena creato alla clipboard di Linux, in modo che possa essere facilmente inserito con un CTRL-V nel mio editor preferito.

Pensavo che Python avesse un sistema bult-in per un operazione così banale, ma così non è. I suggerimenti trovati in rete consigliavano di usare pyperclip (da installare, non presente nei repository della mia Fedora 21) o xclip. Ho ovviamento optato per quest’ultimo.

Lo snippet trovato (per windows) e riadattato, è il seguente:

import subprocess
def copy2clip(txt):
    cmd='echo "' + txt +'"|xclip -selection clipboard'
    return subprocess.check_call(cmd, shell=True)

copy2clip('now this is on my clipboard')

In pratica tramite subprocess si simula l’invio del comando echo “nostro divisore” e tramite la pipe lo si passa a xclip (N.B., xclip, non clip come in Windows).
I parametri finali del comando servono a selezionare la clipboard relativa al CTRL-V, altrimenti di default xclip passa il testo alla clipboard che si attiva con il tasto centrale del mouse o con SHIFT + INS.

Se vuoi vedere lo script completo clicca su continua Continua a leggere

Pubblicato in informatica, linux, mini guide | Contrassegnato , , , , , | Lascia un commento

Clonazione di un proprio repository GitHub

Due appunti al volo, più che altro ad uso personale, su come clonare un proprio repository github su una nuova installazione Linux.

Considerando di essere già iscritti a GitHub, e di avere già installato git sulla propria Linux box, apriamo il terminale e digitiamo:

git config --global user.name "YOUR NAME"
git config --global user.email "YOUR EMAIL ADDRESS"

quindi cloniamo il nostro repository, tenendo conto che verrà creata una cartella .\YOUR_REPOSITORY_NAME

git clone https://github.com/YOUR_NAME/YOUR_REPOSITORY_NAME.git

a questo punto avremo tutti i nostri file salvati in locale, pronti per essere modificati

Pubblicato in informatica, linux, mini guide | Contrassegnato , , | Lascia un commento

di Fedora Workstation, Server e dei suoi utenti

logo

Salve a tutti,

sono passato di recente a Fedora 21 e ho iniziato a seguire il Fedora Magazine, sito che ci tiene aggiornati sugli sviluppi di questa fantastica distribuzione.

Un post in particolare ha attirato la mia attenzione spingendomi a riprendere in mano questo blog: il 5tFTW di questa settimana (ovvero 5 things in Fedora This Week).

Questa settimana la rubrica fa chiarezza sulla nuova divisione di Fedora in tre rilasci – Server, Cloud e Workstaion.

Fedora Server: Is this for crazy people?

Questa la prima domanda: ha senso utilizzare Fedora, da sempre attenta a distribuire le ultime novità tecnologiche, su installazioni Server la cui principale caratteristica è, e deve essere, la stabilità del sistema?

La risposta, in breve, è che Fedora distribuisce le ultime novità ma pur sempre in versione stabile (e grazie al piffero…) e che per chi vuole tenersi aggiornato e preparato sulle ultime “tendenze” in fatto di virtualizzazione, networking e in generale tecnologie di basso livello ha in Fedora Server la scelta migliore.

Uhm, non mi occupo di Server, lascio ai lettori ogni eventuale considerazione.

Does Fedora Workstation mean Fedora is abandoning regular users?

Essì, perché non l’hanno chiamata Fedora Desktop ma Workstation. La differenza di focus non è casuale nè di poca importanza. Si punta non tanto all’utenza domestica (navigazione internet, visione filmati, gestione foto, pornazzi) quanto a chi col computer ci lavora, quindi principalmente sviluppatori software ma non solo.

Ora, prima di tutto bisogna dire una cosa: Fedora NON È MAI STATA una distribuzione desktop. Mai. E a dirla tutta sono pochissime le distribuzioni desktop nel panorama Linux (fattivamente Ubuntu, Linux Mint e Elementary OS). Per quanto ne so io Fedora è ed è sempre stata la versione di sviluppo di Red Hat, pensata per provare e sperimentare le nuove idee-tecnologie per poi poterle inserire pettinate e imbellettate nella distribuzione mamma. Ora ha questa nuova incarnazione di “Distro del fare”, bene, ottimo e abbondante. Approvo e sottoscrivo. Questo non significa che l’utente normale non possa usarla con soddisfazione, anzi. Solo, non si aspetti di essere coccolato come in altre distro: alla fine il regular user in Fedora è un second class citizen. Ma tutto sommato era così anche prima, quindi ben venga che si sia fatto chiarezza e si sia individuato con precisione l’utente tipo. So far so good.

Questo è quanto, se volete leggere il post originale fiondatevi qui.

Cheers e buone feste!

Pubblicato in informatica, linux | Contrassegnato , , , , , , | 2 commenti

Come impostare un autocompletamento “umano” per Python in Geany

Da tempo il mio editor preferito per programmare è geany (con gedit buon secondo), così come il mio linguaggio dei sogni è e resta Python.

Uno dei problemi che ho sempre riscontrato in geany era l’autocompletamento del testo: attivandolo ottenevo oltre ai termini pertinenti al file in modifica, una pletora di metodi e classi che nulla hanno a che fare con il mio progetto.

completationWRONG

Indagando un po’ sono arrivato a questa mail del 2009 sulla mailing list degli sviluppatori che dice:

Geany has a file named python.tags, probably located
in /usr/share/geany on your system. This files contains the 
available symbol names for Python. [...]
However, this is far from being good. For instance, the symbol
completion is not context-sensitive, i.e. it doesn't take into 
account of which class the current object is when showing 
completions. It is a more or less a basic or stupid completion 
without any scope information.
"Geany ha un file di nome python.tags, con tutta probabilità 
presente nella directory /usr/share/geany del tuo sistema. Questo 
file contiene i nomi simbolici disponibili per Python. [...].
Comunque, questo (metodo) è lontano dall'essere ottimale. Per 
esempio, il completamento dei simboli non è sensibile al contesto, 
quindi non tiene in conto il tipo di classe a cui l'oggetto corrente
 appartiene mentre mostra i suggerimenti per l'autocompletameno. Si
 tratta più o meno di un basilare/stupido completamento privo di
 qualsiasi informazione sullo scope (del testo)."

Quindi la situazione già nel 2009 non era delle più rosee, e a quanto pare non è migliorata di molto da allora. Cosa fare dunque? Beh, semplicemente basta liberarci da quest’inutile file rinominandolo (così da poterlo ripristinare in caso di ripensamento):

sudo mv /usr/share/geany/python.tags /usr/share/geany/python.tagsBACKUP

ed ecco come cambia il completamento:

completationRIGHT

Certo, l’autocompletamento non è ancora ottimale ma alla fine fa il suo lavoro senza inondare lo schermo di inutili “suggerimenti”.

Enjoy

Pubblicato in informatica, linux, mini guide | Contrassegnato , , , , , , | 1 commento

Come usare più distro Linux e mantenere sincronizzati i propri programmi

Salve a tutti!
Questo pezzo è una premessa ad un altro che scriverò a breve sulla modifica dei PKGBUILD in archlinux.

Una delle cose che preferisco di Linux è la possibilità di ‘saltimbancare’ tra diversi programmi, desktop environment, distribuzioni etc.

Questo mi porta ad avere almeno 2 distro contemporaneamente sul computer di lavoro. In questo periodo ho infatti installati e pronti all’uso elementary OS luna beta e l’onnipresente rolling release archlinux. Oltre a windows 7 che però non fa testo, specie in questo post.

Ora, il problema di quest’approccio è che anche usando gli stessi programmi in entrambi gli OS, questi non vengono sincronizzati.

Facciamo un esempio con Thunderbird, il mio amato client email.
Immaginiamo di stare su elementary OS: scarico la posta e la leggo.
Se poi mi sposto su archlinux, aprendo Thunderbird e scaricando la posta otterrò che tra i messaggi nuovi avrò anche quelli già scaricati (e letti) su elementary OS. Cosa fastidiosa direi, che vanifica il divertimento di utilizzare più distro sul proprio computer.
Stesso discorso lo si può fare con Liferea, il mio lettore di feed RSS.

Ora, il problema non è comune solo al mondo Linux: tutti noi accediamo ai nostri dati (email, feed, bookmarks) da diversi dispositivi e da diversi OS. I modi per risolverlo sono i più svariati, solitamente ci si appoggia alla “nuvola” (cloud computing) e ad opportune opzioni di sincronizzazione dei vari programmi.Fortunatamente però, nel caso specifico di distro Linux si può ovviare al problema in modo banale e senza far passare i nostri dati attraverso oscure connessioni ad internet: basta far condividere la cartella impostazioni del programma tra i due OS.Ogni programma infatti salva le proprie impostazioni nella home dell’utente (solitamente in ~/.nomeProgramma o in ~/.config/nomeProgramma)

 nota 1: ~ è usato in Linux per indicare la home dell’utente, nel mio caso equivale a /home/medeo

nota 2: una cartella il cui nome inizia con il punto (.) in Linux è una cartella nascosta, se siete nella vostra home e non vedete le cartelle di configurazione provate a premere CTRL+H ;-)

Per esempio liferea salva i propri dati in ~/.liferea_1.8, quindi basta creare un collegamento (a.k.a. link simbolico) tra queste cartelle per fare in modo che i programmi siano automaticamente sincronizzati!

Entriamo nello specifico.

  • Indichiamo i due OS con OS_1 e OS_2.
  • Definiamo con OS_1 il sistema operativo principale (solitamente quello che usiamo più spesso e che prevediamo starà più a lungo sul nostro hard disk) in cui tenere le cartelle reali di configurazione. In OS_2 avremo i collegamenti alle cartelle reali.
  • Prerequisito  per questa operazione è che i due OS ‘si vedano’, ossia che posso accedere ai dati di OS_1 da OS_2 e viceversa. Se non si vedono consultate questa guida o chiedete nei commenti.
  • Non è strettamente necessario che i programmi installati nei due OS siano alla stessa versione: il trucchetto solitamente funziona anche tra versioni diverse dello stesso programma, tranne eccezioni.

Ora vediamo come eseguire l’operazione per Liferea, la cui cartella di configurazione si trova nella home utente.

L’operazione può essere compiuta da file manager o da terminale, vediamo come:

dal file manager di OS_2 (l’OS secondario) procediamo come segue:

1) rinominiamo ~/.liferea_1.8 in ~/.liferea_1.8_BACKUP
2) creiamo nella nostra home un collegamento alla cartella .liferea_1.8 di OS_1
3) testiamo che tutto sia andato come deve
4) cancelliamo tranquillamente la cartella di backup creata al punto 1

come eseguire le operazioni sopra indicate dipende ovviamente dal file manager che usate.

da terminale invece procediamo come segue:

1) creiamo una copia di backup della configurazione semplicemente rinominando la cartella relativa

mv ~/.liferea_1.8 ~/.liferea_1.8_BACKUP

2) creiamo il collegamento alla cartella di configurazione di OS_1.

ln -s /path_per_OS1_home/.liferea_1.8 ~/

(nel mio caso path_per_OS1_home è /archHome/medeo)

3) lanciamo il programma e vediamo se tutto è ok

liferea

4) se tutto ok cancelliamo la cartella di backup precedentemente creata

rm -r ~/.liferea_1.8_BACKUP

Un altra alternativa sarebbe quella di condividere l’intera home tra i due OS, magari ponendo quest’ultima in una postazione separata; Questa soluzione però comporta problemi in caso di Desktop Environment differenti, o di versioni differenti dello stesso DE.

Spero di essere stato utile, se avete dubbi… beh, i commenti sono li apposta per voi :-)

Pubblicato in informatica, linux, mini guide | Contrassegnato , , , , , , , | Lascia un commento

Gnome 3 you are doing it wrong: the close button

Hi all!
In the first release of the new Gnome 3 there was an interesting post of Allan Day  that explained why the classic 3 buttons configuration (minimize, maximize and close) in windows was antiquate.
In the post there was nothing against close button but now things seem to be changed.
The new guidelines for the “new generation gtk3/gnome3 applications” (still a draft) say “Your application’s primary windows should typically be maximized by default and their title bars hidden.
No more title bars? no more close button. So you need one more click to close a window:

first click on Web, than go down and click close (chiudi in the screenshoot)

So let’s examine this solution:

pro: you get less clutter and more space on a maximized windows (since you don’t have the title bar anymore)

cons: close button disappear, new user can’t find it. If you know how to close windows, you still need one additional click for such a common operation.

Please don’t underestimate the importance of one additional click

So here again: trying to give a better interaction to the user ends with force him to do extra tasks. Is it what we all want?

Pubblicato in informatica, linux | Contrassegnato , , , , , , , | Lascia un commento