Menu Chiudi

Categoria: Informatica

Rilasciata Slackware Linux 14.1

LoneStar 0 Commenti
letture

slackware_sDopo un anno di sviluppo, il 7 novembre 2013 Patrick Volkerding ha annunciato e rilasciato la versione 14.1 di Slackware.

Non mancano le novità ma, come sempre, non vengono stravolte l’esperienza generale offerta dalla distribuzione, e l’organizzazione sempre tendente ad offrire un ambiente semplice e ad implementare i pacchetti software nel modo più aderente possibile alle intenzioni dei rispettivi autori, senza modificarli o patcharli.

Gli ambienti grafici disponibili in questa versione sono XFCE 4.10.x e KDE 4.10.5 (le versioni più recenti vengono come al solito fornite separatamente da Eric Hameleers sul suo blog). Per gli amanti di Gnome, da un po’ di tempo è possibile sperimentare separatamente l’ambiente MATE, che è un fork di Gnome 2.x distaccatosi dalla scia di Gnome 3.x per continuare a portare avanti un paradigma desktop tradizionale rispetto ai cambiamenti introdotti da Gnome Shell.

L’ambiente KDE offerto da Slackware segue tutte le raccomandazioni di freedesktop.org per consentire la gestione semplificata di periferiche USB, alimentazione, schermo, lettori mp3, ecc. in modo da risultare utilizzabile da utenti di qualsiasi livello di esperienza.

Il kernel adottato è la versione 3.10.17, ma vengono forniti come opzionali anche la versione 3.4.66 per chi desidera una versione LTS, e il nuovissimo kernel 3.12 per chi vuole invece sperimentare le nuove features.

Le Glibc sono alla versione 2.17, insieme al più recente GCC 4.8.2 ed a LLVM 3.3. Come server grafico viene utilizzato X.org versione 1.4.3.

La principale novità di questa release è comunque l’implementazione dell’installazione e del boot in sistemi dotati di firmware UEFI 64 bit, in maniera nativa. Per questo sono stati aggiunti, come opzionali, i system loader elilo e grub2.

Come esplicitato da Eric Hameleers nel suo articolo di presentazione, non sono invece presenti né SystemD né Wayland.

Va poi ricordato che oltre alle due versione di Slackware per processori x86 (32 bit) e x86_64 (64 bit), è presente anche la release per ARM, che può essere usata su dispositivi come il Raspberry Pi e altri sistemi embedded. E’ anche possibile che in un futuro non lontano venga messa a punto una versione installabile su tablet e cellulari, sulla falsariga di Ubuntu Mobile.

Slackware può essere scaricata gratuitamente come torrent, ma è anche possibile contribuire finanziariamente al progetto acquistando una sottoscrizione dallo store ufficiale, la quale dà diritto a ricevere la distribuzione in confezione DVD.

20 anni di Slackware!

LoneStar 1 Commento
letture

Patrick VolkerdingL’11 luglio 2013 Patrick Volkerding ha pubblicato sul forum Slackware di LinuxQuestions un post celebrativo per il ventennale del suo primo annuncio relativo a Slackware Linux. Altri preferiscono considerare il 16 luglio come data dell’anniversario, in quanto è il giorno in cui la Slackware 1.0 fu effettivamente resa disponibile per il download in FTP.

Personalmente preferisco la prima data per la ricorrenza, in quanto più vicina al mio compleanno che cade il 12 luglio. La Slackware è senza alcuna ombra di dubbio una delle cose più importanti nella mia vita informatica – insieme a Fidonet, le BBS, e le chat online -, quindi mi piace l’idea che sia collegata al mio compleanno.

Come viene ripetuto in occasione di ogni uscita di release, la Slackware è la più antica distribuzione Linux ancora in attività, anche se la differenza rispetto a Debian è di poche settimane. D’altronde quando si parla di record anche pochi istanti di differenza hanno un peso!

Io ho iniziato ad usare Slackware nell‘estate del 1996, di conseguenza ne ho attraversato gran parte della storia. Mentre per molti l’uso di Slackware ha rappresentato una fase di passaggio nella loro vita informatica, spesso legata agli inizi della loro esperienza Linux, per me è stata una costante immutabile. Anzi la conoscenza e l’uso di altre distribuzioni nel corso del tempo, ha rafforzato sempre più la mia preferenza, dandomi ripetuti riscontri pratici della convoluta complicazione degli altri sistemi.

Linux è nato con lo scopo ideale di essere un clone libero di Unix, e sebbene sia comunque difficile individuare nella frastagliata storia di Unix un sistema ideale a cui far riferimento per generarne un clone, è comunque innegabile che Slackware è l’unica distribuzione che abbia mantenuto negli anni una certa continuità di logica e di organizzazione con i sistemi Unix classici. Secondo molti il sistema Unix ideale è stato Solaris. Personalmente ritengo che questo trofeo spetti a DigitalUnix/Tru64/OSF1. In ogni caso Slackware non è certamente una “copia sputata” di nessuno di questi sistemi, però ha un look&feel generale che fa sentire l’utente perfettamente a casa quando accede ad uno di questi altri sistemi.

Allo stato attuale la salute di Slackware è buona, ma i problemi all’orizzonte rimangono quelli che ho già citato in un precedente articolo: Systemd, Wayland, udisks2.

L’adozione di Systemd stravolge completamente la struttura di una distribuzione tradizionale, e rischia di diventare pressoché obbligatoria man mano che passa il tempo, a causa delle dipendenze che gli sviluppatori stanno iniziando a inserire in altri software rilevanti. E’ di questi giorni la voce che le prossime versioni di KDE potrebbero iniziare a dipendere da Systemd, e questo porrà la Slackware su un bivio inevitabile: abbandonare KDE ed utilizzare solo desktop manager “minori” come XFCE, LXDE, ecc., oppure adottare Systemd.

Anche Wayland, nonostante di per se sia un cambiamento molto meno radicale, sembra portare con se delle dipendenze da Systemd.

Persino Debian, che inizialmente si era schierata tra le distribuzioni che rifiutavano l’adozione di Systemd, adesso ha avviato un processo più morbido di valutazione dell’impatto dell’inserimento di Systemd come pacchetto facoltativo e successivamente anche come pacchetto di default. In ogni caso tutte le maggiori distribuzioni sono passate a systemd oppure lo offrono come sistema alternativo, e nessuna ha seguito la strada di non considerarlo per niente (come sarebbe giusto fare per qualsiasi progetto di Lennard Poettering, IMHO 😀 )

Purtroppo Slackware è costretta in casi del genere a seguire il carro delle altre distribuzioni, in quanto non ha i mezzi per poter portare avanti in maniera autonoma dei progetti rilevanti come un intero sistema coerente di patch da applicare a tutti i software legati a systemd per eliminarne la dipendenza. E’ quindi probabile che se questa adozione generalizzata di systemd continua lungo questa linea di diffusione, presto o tardi Slackware dovrà compiere il passaggio.

Non sarà la fine del mondo, alla fine si comincerà anche ad apprezzarlo, ma rimane il fatto che se fosse possibile scegliere tutti noi slackwaristi vorremmo rimanere con sysvinit.

Buon anniversario Slackware!!

Da Google Reader a TT-RSS

LoneStar 0 Commenti
letture

google-readerE così ci siamo. Domani, 1 luglio 2013, Google Reader chiude definitivamente.

Quando Google ha annunciato tra i servizi di prossima dismissione il nome di Google Reader, la notizia ha fatto scalpore, in quanto si tratta di un servizio usatissimo, per quanto non molto appariscente, e non si riteneva che fosse “a rischio” tra la pletora di servizi utili e inutili che Google avvia e dismette nel corso degli anni.

Ma in un certo senso si tratta comunque di un servizio di nicchia, anche se una grossa nicchia, in quanto rivolto a persone di una certa competenza tecnica, che sanno ricercare i link RSS dei propri siti preferiti, sanno organizzarseli in gruppi, sanno usare un lettore di news locale, ecc.

Inoltre si era già manifestata una certa intenzione di Google di passare ad un modello di offerta di notizie con sottoscrizione non necessariamente gratuita, in modo da poter siglare accordi con testate giornalistiche a cui rigirare una parte degli utili, per tirarsi fuori dalle svariate accuse di assassinio della stampa e del giornalismo professionale. In questo senso il servizio Google Currents si inserisce meglio del Reader, pur essendo basato sostanzialmente sulle stesse tecnologie, in quanto si presenta come qualcosa di più “patinato“, usabile da utenti meno esperti, e vendibile come piattaforma per servizi a pagamento da parte degli editori di carta stampata.

Ad ogni modo, dal momento dell’annuncio si è aperta la caccia al sostituto di Google Reader per chi vuole continuare a gestire il proprio flusso di notizie in maniera sostanzialmente invariata. Quasi tutti i servizi alternativi erano comunque dipendenti da Reader in qualche modo, quindi chi ha voluto sopravvivere ha dovuto spendere tempo e denaro nella creazione di un motore autonomo. Ce ne sono comunque parecchi e quindi la situazione non è disperata.

Il successore più votato ed accreditato è Feedly. Un servizio principalmente orientato a smartphone e tablet, quindi tramite l’uso di un’app specifica. Reader invece era un servizio nato prima del boom del mobile, e quindi pensato per essere usato essenzialmente da web, anche se era dotato di apposite app. Ovviamente anche Feedly può essere usato da web.

Tuttavia la mia scelta fin da subito si è orientata verso qualcosa che non dipendesse più dalle decisioni di un provider esterno. A qualunque altro servizio si passi dopo la chiusura di Google Reader, esiste sempre il pericolo latente che tra qualche tempo il servizio venga chiuso, che l’azienda venga acquisita da altri, che il servizio passi da gratuito a pagamento, e così via dicendo.

Quindi ho preso in considerazione solo due strade: l’uso di un client locale che scarichi le news direttamente dai vari feed dei siti, oppure l’uso di un portale web autonomo che vada a scaricare i feed inserendoli in un db sql e che sia poi consultabile via web e tramite client.

Per la prima strada, esistono alcune soluzioni “storiche” come Liferea, Akregator, ecc. le quali però hanno limitazioni varie e inoltre tendevano comunque ad appoggiarsi sempre al motore di Google per la fase di effettiva aggregazione delle notizie. Siccome sono già dotato di server esposto su internet, l’idea del portale web pubblico, accedibile dall’esterno e dai vari dispositivi che possiedo, è quella che mi ha attirato di più fin da subito.

Di conseguenza la mia scelta è caduta su Tiny Tiny RSS (TT-RSS). Si tratta di un software in PHP che esiste da diverso tempo, ma che ha avuto una spinta particolare da quando si è sparsa la notizia della chiusura di Google Reader. Richiede un server http, un database SQL e il PHP. Nulla di particolarmente difficile per chi utilizza normalmente Linux. E’ dotato anche di un client Android che è abbastanza completo ed efficace. Utilizza inoltre una tecnologia di plugin che consente di espanderlo con varie funzionalità, compresa quella particolarmente utile di poter condividere gli articoli desiderati sui social network o via email. Le feature crescono di continuo e sono già da molti punti di vista superiori a quelle che offriva Reader, senza contare poi che negli ultimi mesi sono fioccati i temi grafici per la parte web che tendono a riprodurre in maniera pressoché perfetta l’aspetto esteriore dell’interfaccia di Google Reader.

Il pregio più importante di questa soluzione, dal mio punto di vista, è che si tratta di una soluzione definitiva. Non dovrò cambiarla mai più, in quanto non è un servizio che potrà mai chiudere o cambiare, a meno che non sia io a volerlo per una mia necessità.

Inutile dire che TT-RSS si aggiunge quindi ai servizi che LoneStar Network offre ai suoi utenti, anche se poi in effetti lo uso solo io. Ad ogni modo se qualcuno dei miei users legge questo articolo ed è interessato, non ha che da scrivermi.

Cairo Dock

LoneStar 0 Commenti
letture

Qualche tempo fa avevo scritto un post trionfante sull’essere riuscito ad installare Avant Window Navigator (AWN) sulla mia Slackware.

Da allora l’ho sempre usato con soddisfazione sul mio laptop, e la dock si è dimostrata sempre funzionale, veloce e gradevole.

Tuttavia col passare del tempo si sono manifestati dei problemi, dovuti principalmente alla mancata evoluzione di AWN nel tempo. Infatti il software è rimasto dal 2010 alla versione 0.4.0 e non sono più usciti aggiornamenti, a parte una 0.4.1-trunk scaricabile dal sito di sviluppo ma anch’essa risalente ormai a molto tempo fa.

Con l’evolversi delle versioni di KDE, arrivato adesso alla 4.10.2, alcune funzioni di integrazione  tra la dock e il desktop environment hanno cominciato ad avere problemi, ed in particolare ha smesso di funzionare la possibilità di vedere le varie finestre aperte da un’applicazione cliccando sull’icona dell’applicazione stessa nella dock di awn. Di conseguenza non è stato più possibile passare da una finestra all’altra di uno stesso programma tramite l’icona della dock. E’ evidente che questo toglie moltissimo alla funzionalità della dock, costringendo a usare la taskbar tradizionale di KDE o il menu di ALT-Tab per passare da una finestra all’altra.

Per questa ragione alla fine mi sono convinto ad abbandonare AWN al suo destino, e a passare a qualcos’altro, nello specifico la nuova Cairo Dock versione 3.2.0.

cairo1Cairo Dock è attivamente sviluppata e la versione in questione è di recente uscita. E’ sviluppata principalmente per l’ambiente Gnome, come del resto era AWN e come lo sono un po’ tutte le dock, ma supporta l’integrazione in KDE ed è quindi usabile senza problemi. E’ molto configurabile e prevede diversi temi dagli aspetti più svariati, compresa la classica emulazione della dock di Mac OS X, che è un po’ il punto di partenza e di ispirazione di tutte le dock su Linux, ma dalla quale poi tutte si dipartono realizzando effetti, funzioni e parametrizzazioni che non sono assolutamente possibili su un desktop Mac.

cairo2

 

Su Slackware, Cairo Dock è disponibile tramite SlackBuilds.org insieme ai relativi plugin. E’ sufficiente editare i riferimenti ai numeri di versione negli script di compilazione per ottenere il pacchetto binario della release attuale.

Slackware Linux 14.0, e il futuro

LoneStar 0 Commenti
letture

Il 26 settembre, dopo ben 5 release candidate, a testimonianza di lunga riflessione, è uscita la Slackware 14.0.

L’annuncio ufficiale cita le svariate novità di questa versione, che spaziano dal kernel Linux 3.2.29, a XOrg X11R7; la Glibc 2.15; Firefox & Thunderbird 15.0.1; KDE 4.8.5 (anche se è possibile reperire già la versione 4.9.2 dai repository di AlienBOB); le ultime versioni di Perl e Python, la versione 2.8.x di Gimp, in cui viene finalmente introdotta l’interfaccia a finestra singola.

Spicca inoltre la presenza del compilatore Clang/LLVM, di origine Apple e ormai divenuto il compilatore ufficiale per FreeBSD, che ha guadagnato la scena negli ultimi tempi come realistica alternativa a GCC, il quale è anche lui presente alla release 4.7.1.

Viene inoltre introdotto l’utilizzo di NetworkManager come metodo unificato per la gestione delle interfacce di rete sia ethernet che wireless, e tutta la struttura di script della distribuzione è stata adattata  per la gestione dinamica degli indirizzi sulle interfacce, anche se rimane sempre possibile configurarle con il metodo tradizionale del file .conf. Rimane anche presente Wicd, l’altro gestore di interfacce di rete, che ha meno diffusione nel mondo Linux ma è ugualmente stabile e valido.

A margine della felicità per la release, voglio anche citare quelle che sono le preoccupazioni che si stagliano all’orizzonte per il futuro delle distribuzioni come Slackware, ossia quelle che non si assimilano alle scelte mainstream. Mi riferisco all’avvento di Systemd e Udisks2.

Systemd si propone come gestore dell’init di sistema a soppiantare integralmente sysvinit e l’intera filosofia di gestione avvio e servizi in stile System V o BSD, che da decenni sono alla base di tutti i sistemi operativi di derivazione Unix. Negli ambienti legati a Redhat e GNOME si è affermata l’idea che sia necessario liberare Linux da ogni eredità della tradizione Unix. Immagino che anche il successo di Android, il quale unisce il kernel Linux a una struttura di sistema non di derivazione GNU/Unix, abbia alimentato questa teoria. Non ci sarebbe di per se nulla di male, dato che nel mondo OpenSource da sempre tutti sono liberi di sviluppare nuove soluzioni e alternative, ma in questo caso i sostenitori e gli sviluppatori di Systemd pongono forti pressioni sul fatto che non ci si preoccupi di mantenere più alcun tipo di compatibilità con il sistema init tradizionale, e ne incoraggiano apertamente l’abbandono e la scomparsa, definendo obsoleti e irrilevanti i sistemi che vogliono ancora legarsi a una concezione di stretta derivazione Unix, tra i quali l’intera famiglia *BSD. E’ evidente che questo tipo di approccio, espresso anche in maniere irrispettose e arroganti, se dovesse diffondersi su larga scala potrebbe segnare la fine delle distribuzioni che non volessero adeguarsi ad adottare questo nuovo init, in quanto i vari servizi necessari al funzionamento di un sistema Linux andrebbero a legarsi in maniera sempre più stretta e indissolubile a Systemd rendendo difficile, se non addirittura impossibile, riadattarli all’uso in un sistema init tradizionale.

Systemd inoltre, ed è questo l’aspetto più minaccioso per ragioni che chiarisco poco più avanti, avoca a se le funzioni di dialogo con l’hardware che finora sono state svolte da Udev, il quale è stato fuso in Systemd cessando di esistere come software autonomo.

Udisks2 si inserisce sulla stessa scia, come nuovo metodo di gestione del montaggio dei dispositivi di storage che si distacca dal metodo tradizionale a tal punto che non è più possibile montare i device da linea di comando usando il comando mount!

Vale la pena di sottolineare poi che questi due nuovi software portano con se anche altri due effetti. Il primo è che GNOME 3.2 è totalmente dipendente da systemd e Udisks2, e questo lo lega in maniera esclusiva a Linux e ne impedisce l’uso su BSD. Devo però ammettere che questo è l’aspetto che mi preoccupa di meno, dato che Gnome non mi è mai piaciuto, e non vedo nessun disagio nel non poterlo usare. L’altro effetto è quello di togliere il terreno sotto i piedi a tutti gli altri desktop environment e desktop manager, tra cui appunto KDE, ma anche Xfce e gli altri minori, i quali sono stati integralmente costruiti per dialogare con l’hardware di sistema attraverso Udev e messagebus, e modificarli per lavorare con Systemd sarebbe un lavoro non indifferente, quando fosse possibile.

Le principali ragioni in positivo che spingono all’adozione di questi nuovi sistemi sono il desiderio di velocizzare l’avvio iniziale di un sistema Linux, parallelizzando la partenza dei servizi in modo tale che in pochissimi secondi tutto sia attivo, e il pieno supporto all’inserimento e disinserimento a caldo delle periferiche di storage esterne.

I punti di forza di un sistema init tradizionale invece sono la semplicità e leggibilità delle configurazioni, e la predicibilità della sequenza di avvio, che segue un ordine di partenza dei servizi ben preciso e calcolato, al prezzo di una lentezza nella partenza del sistema, che a mio avviso è assolutamente irrilevante e trascurabile considerate le prestazioni dei moderni sistemi.

Ora, è chiaro che tutto ciò assume un aspetto negativo solo nella misura in cui si attribuisca importanza al mantenimento di un’architettura Unix tradizionale all’interno di una moderna distribuzione Linux, e il tutto sarebbe legittimo e rispettabile se non ci fossero gli espliciti incoraggiamenti e le effettive spinte all’abbandono di ogni compatibilità con il sistema tradizionale.

Bisognerà quindi vedere se nel futuro Slackware sarà obbligata ad adottare Systemd e ad abbandonare la sua proverbiale struttura di file di avvio leggibili e comprensibili, o se si apriranno spazi per la sopravvivenza di un init tradizionale. Tempi duri.

CC BY-NC-SA 4.0 .