A causa delle nuove policy di distribuzione che Oracle ha stabilito per Java, dal 24 agosto del 2011 non è più possibile distribuire nuove versioni Java su macchine Ubuntu.

Per questo motivo il 16 febbraio di quest’anno verranno rimosse dal repository “partner” tutte le versioni di Java JDK.

Su Ubuntu 10.04, 10.10 e 11.04  il pacchetto Sun Java JDK (sun-java6) non sarà più disponibile e successivamente rimosso del tutto al fine di evitare problemi.

A quanto pare sui sistemi Ubuntu già in uso non verranno neanche più resi disponibili aggiornamenti di sicurezza sui pacchetti Java già installati, mentre su questa pagina del Wiki Ubuntu è spiegato come migrare a soluzioni alternative per continuare ad usare piattaforme simili a quella Java. Maggiori informazioni sul messaggio mandato da Marc Deslauriers sulla mailing list “ubuntu-security”.

Tutte le informazioni presenti su questo articolo sono protette dalla licenza CC Attribution-ShareAlike . 

Fonte: TuxJournal.net

Già da tempo si vociferava di una possibile introduzione di Google Chrome come browser predefinito in Ubuntu ma ora sembra che ci sia una notizia ufficiale e concreta. A confermarlo è proprio Mark Shuttleworth che, in un’intervista, ha dichiarato che esiste “una reale possibilità che Chrome venga introdotto in Ubuntu al posto di Firefox“.

Sicuramente il cambiamento non sarà effettuato in Ubuntu 11.10 Oneiric, ha sempre aggiunto Mark, ma qualche versione più in là e non sto parlando di Ubuntu 12.04 (che sarà anche la prossima LTS del sistema di Canonical) ma di almeno Ubuntu 12.10! Shuttleworth si è rivelato essere grande sostenitore di Google e del suo operato e non si è soltanto limitato a parlare di Chrome ma ha anche elogiato il lavoro svolto dal motore di ricerca numero uno al mondo in merito a Chrome OS.

Secondo Shuttleworth “non capita spesso di vedere un tale progetto cross-platform” ed ha aggiunto che “potremmo anche trovarci in una posizione dove Chrome su Ubuntu e Chrome su Linux sarà una migliore esperienza rispetto agli altri sistemi (Windows e Mac)“.

“Penso che Chrome OS è affascinante per diversi aspetti [...] Il suo massimo livello di adozione ed il fatto che si vorrà utilizzare il Web come piattaforma principale è davvero un idea interessante”.

Dopo aver elogiato Google ed aver aggiunto che è “in una posizione molto potente per quanto riguarda i dati“, Mark ha risposto alle domande inerenti adUnity:

“Vediamo Unity come parte del progetto GNOME, questo è certamente il modo in cui è stato concepito. Ora però siamo un pò in un limbo perché GNOME sta avendo alcuni dibattiti interni: vogliono avere più interfacce o no? Questo ci lascia in una situazione imbarazzante.”

L’intervista di Mark è davvero lunga e potete continuare la lettura in questa pagina. Gli altri argomenti trattati sono stati l’Open Source, Microsoft, gli smartphone e tanto altro!

Fonte:http://www.chimerarevo.com/2011/06/15/shuttleworth-chrome-al-posto-di-firefox-e-una-reale-possibilita/

Uno dei tool più apprezzati dagli utenti di Ubuntu è sicuramente Ubuntu Tweak, rilasciato da poche ora nella sua ultima versione stabile: 0.5.14. Si tratta sostanzialmente di un’ennesimo aggiornamento bug-fixed del ramo 0.5.x in attesa dell’arrivo del rivoluzionario Ubuntu Tweak 0.6; nello specifico in questa versione è stata migliorata la funzionalità PPA purge.

Stando a ciò che si legge dal blog ufficiale, il bug è stato riscontrato mentre lo sviluppatore provava a fare il purge del PPA di Gnome 3! Tutto è stato risolto e non dovete fare altro che aprire il terminale e digitare:

sudo add-apt-repository ppa:tualatrix/ppa

sudo apt-get update

sudo apt-get install ubuntu-tweak

e troverete Ubuntu Tweak 0.5.14 installato sul vostro sistema

Fonte: http://www.chimerarevo.com/2011/06/01/ubuntu-tweak-0-5-14-rilasciato-installiamolo-su-ubuntu/

Alla domanda: “Ma su Linux c’è bisogno di un antivirus?” a me viene semplicemente da rispondere: dipende dal caso! Solitamente gli utenti home che utilizzano antivirus su Linux sono davvero pochissimi, mentre sulle macchine server la cosa cambia notevolmente. Nonostante sia difficile contrarre un virus su Linux (a meno che non siate davvero degli assoluti sprovveduti), avere un antivirus installato su questo sistema operativo può risultare davvero utile, in qualche caso.

Vi faccio un esempio: se avete…

• una workstation pubblica, di uso comune;
• una macchina server;
• una macchina che utilizzate per fare assistenza tecnica;
• una buona dose di buonsenso e tanta prudenza

…allora l’antivirus, anche su Linux, è una cosa che fa assolutamente per voi!

Ebbene, oggi voglio presentarvene uno assolutamente efficiente, leggero e totalmente free scritto ad-hoc per le piattaforme *nix, ed utilizzato comestandard de facto (= standard ufficioso) all’interno dei mailservers: sto parlando di Clam Antivirus.

Sono sicura che vi aspettiate qualcosa di complicato da configurare e tenere aggiornato, ma Clam non è nulla di tutto ciò: potrete ad esempio aggiornare il database delle definizioni con un solo comando, oppure eseguire la scansionedi una determinata cartella facendo click destro su questa e selezionando l’apposita opzione (Clam è integrato completamente con Nautilus).

Altrettanto semplice è l’installazione, che avviene via repository: sebbene Clam sia già presente nei repository Universe di Ubuntu il mio consiglio è di utilizzare i repository del progetto stesso, che risulteranno sicuramente più aggiornati. Ragion per cui aprite un terminale (utilizzando la combinazione di tasti ALT+CTRL+T) e andate ad aggiungere i repository, aggiornare la lista ed installare l’antivirus con i seguenti comandi:

sudo add-apt-repository ppa:ubuntu-clamav/ppa

sudo apt-get update

sudo apt-get install clamav nautilus-clamscan

A questo punto per poter utilizzare l’estensione di Clam per Nautilus non dovrete far altro che riavviare quest’ultimo. Ossia, da terminale, dare il seguente comando

nautilus -q

La prima cosa che si fa una volta installato un antivirus è aggiornare le sue definizioni: dicevo il vero quando vi ho spiegato che basta un solo comando per farlo. Sempre da terminale, quindi, digitiamo

sudo freshclam

e aspettiamo il completamento dell’operazione per aggiornare il nostro antivirus. Questa è un’operazione che va fatta piuttosto spesso, per cui vi consiglio di aggiungere una linea di codice al vostro crontab per pianificarlo. Potrete trovare una buona guida per l’utilizzo di cron in questa pagina, oppure potrete utilizzare questo procedimento (che io personalmente utilizzo) per aggiornare le definizioni alle 18 di ogni giorno: aprite un terminale e digitate

crontab -e

Se è la prima volta che eseguite quest’operazione vi sarà chiesto di scegliere il vostro editor di testo preferito. Per semplicità io utilizzo /bin/nano, che dovrebbe corrispondere all’opzione 2. Per cui, alla domanda, rispondete 2 e premete invio.

Scendete, con la freccia in basso, fino alla fine del file che vi sarà aperto e, a capo rigo, incollate il seguente testo:

0 18 * * * sudo /usr/bin/freshclam --quiet

Andate a capo premendo invio, poi salvate il file premendo prima i tastiCTRL+X (comando “Salva”), poi premete S (per dare conferma al salvataggio), poi premete INVIO (per confermare il nome del file). Da questo momento in poi le vostre definizioni saranno aggiornate alle 18 di ogni giorno.

Ed ora, ultima domanda ma solo in ordine di tempo, come si usa Clam? Sebbene le modalità di utilizzo possano essere molteplici (potremmo pianificare, sempre tramite cron, delle scansioni di sistema con delle particolari opzioni per l’autoclean) noi analizzeremo quella più semplice, che interessa gli utenti casalinghi: non è un caso se vi ho fatto scaricare l’estensione per Nautilus, visto che per effettuare la scansione con Clam su una cartella bastaclickare destro sulla cartella e selezionare Scan For Viruses.

Piccolo bug (almeno a me succede così): a scansione terminata, se fate click su chiudi, vi sarà notificato che “la scansione non è ancora terminata” e vi sarà chiesta conferma per la chiusura della finestra: anche premendo su SI la finestra non si chiuderà! Dovrete utilizzare il tastino di chiusura (la X in alto) per chiuderla

Clamscan, comunque, rappresenta a mio avviso un’ottima soluzione per lamanutenzione del sistema. Vi rimando alla home page del progetto per ulteriori informazioni, per i sorgenti e per l’installazione anche su Windows!

Prima di chiudere, voglio fare una domanda ai miei lettori: che livello di utilità ha, secondo voi, un antivirus su Linux? Fatecelo sapere!

Fonte: http://www.chimerarevo.com/2011/05/28/clam-antivirus-un-ottimo-antivirus-per-ubuntu/

La notizia era già nell’aria ma solo ieri, durante l’UDS che si sta svolgendo a Budapest in questi giorni, Lubuntu è divenuta finalmente una derivata ufficiale di Ubuntu. Mark Shuttleworth ha annunciato che Canonical sosterrà il progetto e gli sviluppi futuri e, già a fine anno, sarà annunciato Lubuntu 11.10 che sarà quindi la prima release ufficialmente supportata nella storia di questa distribuzione.

Lubuntu è una distribuzione rivolta principalmente a computer con hardware minimo o poco potente; i requisiti, infatti, sono davvero bassi: processore Pentium II e solo 128 MB di memoria RAM! In Lubuntu troverete, attualmente, come il leggerissimo LXDE come desktop environment, PCManFM come file manager, Sylpheed come client email e Chromium come browser di default.

Fonte: http://www.chimerarevo.com/2011/05/12/uds-budapest-lubuntu-diventa-derivata-ufficiale/

Da parecchi anni si pone l’esigenza di un sistema universale per gestire i pacchetti nelle principali distribuzioni GNU/Linux, senza che si sia mai raggiunto il minimo accenno di soluzione condivisa.

I sistemi attuali sono equivalenti, pur variando in funzionalità e utilizzo: RPM e DEB si contendono la scena come motori principali, mentre varie interfacce utente hanno il compito di nascondere all’utente tutto il lavoro sporco da essi svolto.

Ci sono stati parecchi tentativi di semplificazione, tra soluzioni precarie, tradizionaliste, rivoluzionarie, sperimentali o semplicemente insostenibili. Nomi come Autopackage, PackageKit, Klik/Glick e vari strumenti che ogni distributore è stato obbligato ad escogitare di volta in volta.

Adesso, in quella che potrebbe essere una svolta storica, finalmente sembra aprirsi uno spiraglio di luce in fondo al tunnel affettuosamente denominato “dependency hell”…

Il problema

Installare software è un compito abbastanza complesso in ogni sistema operativo. Idealmente si tratta solo di copiare qualche file, e in alcuni casi non ci si scosta troppo da questa semplice operazione; nella realtà però una gestione dei pacchetti deve tenere conto di molte esigenze:

• Installazione, rimozione e aggiornamento dei pacchetti
• Gestione di un database di pacchetti installati/installabili/aggiornabili
• Risoluzione di eventuali (inter)dipendenze e/o conflitti
• Esecuzione di script di autoconfigurazione e/o d’avvio
• Già detto “Risoluzione di eventuali (inter)dipendenze e/o conflitti”?

Tali esigenze rendono difficoltosa l’idea di affidarsi ad una semplice copia dei file da installare, specialmente se consideriamo che nei sistemi unix è tradizione suddividere e spargere il contenuto di ogni pacchetto per tutto il filesystem, in base al tipo di file: i binari vanno in /bin, /usr/bin /usr/share/bin e altro ancora, le librerie in /lib, /usr/lib, ecc, secondo un complicato sistema di precedenze e di criticità delle singole componenti.

Se consideriamo che ogni distributore si è sempre trovato a creare un’albero delle directory leggermente diverso dall’altro, un sistema di script di init leggermente diverso dall’altro, un sistema di configurazione leggermentediverso dall’altro, un naming scheme dei pacchetti leggermente diverso dall’altro, una politica di aggiornamento dei pacchetti leggermente diversa dall’altro… capirete bene come si sia arrivati alla situazione attuale, in cui praticamente non esistono due distribuzioni compatibili.

Le soluzioni tradizionali

Ogni distributore ha dunque sviluppato un sistema di gestione dei pacchetti, magari storicamente legato al nome della distribuzione o dell’azienda sviluppatrice, magari con corredo di spunti per garantire anni di ferocissime, intense e inutili dispute su quale sia il migliore, più tecnologicamente avanzato, veloce, affidabile, sicuro, eccetera.

Ciascuno di noi ha le sue preferenze, che – come tutte le religioni – non è il caso di mettere in dubbio, possiamo però ostentatamente ignorare i gestori di pacchetti più casalinghi o legati a distribuzioni minori ed evidenziare i due principali sistemi, gli unici contemplati dalla idealmente importante quanto in pratica inutile Linux StandardBase: RPM e DEB. Il primo viene da Red Hat ed è adottato da distribuzioni quali Fedora, openSUSE, Mandriva/Magiea e altre; il secondo da Debian ed è adottato da Debian stessa e dalle innumerevoli distribuzioni derivate, tra cui Ubuntu.

Anche annullando il motivo d’esistere di ogni buon troll e ponendo che RPM e DEB siano equivalenti (grosso modo lo sono), per tutta la serie di motivi elencati più su, ugualmente non esistono due distribuzioni che usano lo stesso gestore esatto, in quanto molto raramente un pacchetto rpm per openSUSE potrà essere installato su Fedora, o allo stesso modo un deb di Debian su Ubuntu. Dunque due principali tecnologie, usate per creare decine di implementazioni leggermente incompatibili, quel che basta a non permettere l’uso di uno stesso pacchetto su più di una distribuzione. Ma non è questo il punto.

Per rendere meno anale la gestione dei pacchetti da parte dei semplici utenti che vogliono semplicemente installare Firefox, fregandosene bellamente di librerie e dipendenze, sono stati escogitati varie interfacce ad RPM e DEB. Da APT a Synaptic, da YAST a YUM alle decine di altre utilità create con questo scopo. Un primo tentativo sensato di unificare tutte queste piccole divergenze sotto un ombrello che garantisse delle API un’esperienza d’uso uguali e coerenti, a prescindere dal funzionamento reale del motore, è stato PackageKit, tuttora non del tutto implementato.

Le soluzioni sperimentali

Oltre a questo, molto oltre  a questo, c’è sempre stato un impulso al rinnovamento, da parte di utenti e sviluppatori insoddisfatti da alcuni aspetti della gestione dei pacchetti in GNU/Linux, principalmente dalla intensa frammentarietà che porta alla compatibilità suddetta. Sono dunque nati diversi sistemi alternativi, ma semprecomplementari, per gestire pacchetti in maniera più omogenea e pratica per tutte le distribuzioni o quasi.

Uno degli esempi più riusciti, ma sempre largamente fallimentare, è/era Autopackage, un gestore che offre un leggero strato di compatibilità con il gestore della distribuzione, e ponendosi come gestore ulteriore, da usare per quei pochi progetti che nel tempo hanno fornito versioni autopackage dei loro software. Non è mai stato nemmeno ufficiosamente supportato da alcun distributore, che io sappia.

Se Autopackage è stato largamente ignorato, pur essendo forse il migliore esempio, potete immaginare gli altri. Un progetto che ho seguito con molta attenzione è stato Klik, che a differenza di Autopackage e dei sistemi tradizionali, si rifà al concetto di app bundle tipico di Mac OS e implementa un paradigma di 1 file = 1 app, nell specifico si tratta di una immagine in cramfs contenente un piccolo albero di directory con tutte le librerie e i binari dell’applicazione, che in quel modo non vengono sparsi per il filesystem ma rimangono appunto contenute nel file.  In maniera simile funziona(va) anche Glick e così pure un progetto italianissimo: SpatialBundle di Luca Cappelletti.

LA soluzione?

Tutte queste soluzioni sono sempre state caratterizzate dall’assoluta mancanza di coordinazione tra i distributori: quelle tradizionali per motivi che a mio avviso, ripetuto in varie occasioni, possono solo essere visti come la mancanza di prospettiva di chi imbriglia soluzioni aperte in strategie chiuse; quelle sperimentali perché semplicemente non interessavano davvero a nessuno.

Oggi però Frafra ha segnalato una notizia che non esito a definire storica. Sviluppatori di Red Hat, Fedora, Debian, Ubuntu, openSUSE, Mandriva e Mageia si sono incontrati per discutere le caratteristiche di un nuovo gestore di pacchetti universale. Al momento si chiamerebbe AppStream e sarebbe basato sull’interessante progetto Bretzn, presentato dal team di KDE, per quanto riguarda le funzionalità multipiattaforma e multiarchitettura, e idealmente su Ubuntu Software Center per quanto riguarda l’interfaccia utente. Funzionalità molto interessanti, quali la possibilità da parte degli utenti di attribuire e condividere votazioni o commenti ai pacchetti sarebbe prevista tramite Open Collaboration Services.

La parte più interessante è che l’intero progetto non sarà un sistema per distribuire i tanto temuti et famigerati Universal Binaries From Hell, ma si limiterà a fornire metadati, che saranno interpretati da cliente per scaricare i bit necessari. Questo significa che il sistema di installazione dei pacchetti rimarrà di tipo tradizionale, e che dunque le parti che verranno innovate saranno solo quelle che permetteranno di avere un installer universale per tutte le distribuzioni.

Nessuna rivoluzione, ok, ma una benvenuta evoluzione all’insegna della razionalità.

Fonte: http://pollycoke.org/2011/01/25/un-gestore-di-pacchetti-universale-per-linux/

Installare Java sull'ultima versione di Ubuntu e' un'operazione  davvero semplice.

Java rappresenta ovviamente una componente fondamentale da installare su ogni sistema operativo ed anche Ubuntu necessita delle librerie necessarie per il corretto funzionamento di applet e programmi che vedono sfruttare le pontezialità del linguaggio di Oracle.

Per installare questo indispensabile componente, i passi da seguire sono i seguenti:

sudo add-apt-repository "deb http://archive.canonical.com/ natty partner"

sudo apt-get update

sudo apt-get install sun-java6-jre sun-java6-jdk sun-java6-plugin sun-java6-fonts

Finito!

Per controllare la versione di java installata è possibile lanciare il seguente comando:

java -version

Wine (Wine Is Not an Emulator, un acronimo ricorsivo, Wine non è un emulatore) è un software scritto in C nato originariamente per GNU/Linux, poi esteso ad altri sistemi operativi, con lo scopo di permettere il funzionamento dei programmi sviluppati per il sistema operativo Microsoft Windows. Da notare è il fatto che il nome Wine assomiglia a WINdows Emulator, anche se come citato in precedenza esso non lo è affatto.

Ecco uno dei comandi base e fondamentali che ogni utente dovrebbe conoscere:  wget.

Wget non è altro che una piccola utility a riga di comando in grado di recuperare file tramite i più famosi protocolli internet come HTTP, HTTPS, FTP!

Inoltre questo tool è non interattivo, può quindi funzionare in background senza che l’utente sia sempre presente.
 

Con wget potrete scaricare un’intera pagina web e leggerla offline o addirittura l’intera struttura e l’intero sito che verranno salvati sul vostro HD grazie ad un processo ricorsivo. Viene rispettato il Robot Exclusion Standard (robots.txt), e la cosa bella di wget è che insisterà nello scaricare un file anche se questo è momentaneamente non disponibile a causa di qualche problema di rete fino a quando non sarà disponibile nuovamente; addirittura se il server lo supporta, si può continuare il download da dove era stato interrotto.

Wget è stato realizzato in modo robusto per supportare connessioni lente o instabili.

Vediamo ora come utilizzare wget. Se possedete Ubuntu non dovrete installarlo essendo già presente di default nel sistema ma questo vale anche per molte distro linux.

Da dire che wget è un tool stracolmo di opzioni,che permette di fare davvero tantissime cose. Oggi vi mostro come scaricare un intero sito web, in background, dando soltanto una linea di comando. La sintassi esatta è:

wget -k -r -p -D dominio.org --restrict-file-names=sistema http://www.sitoweb.org

E, adesso, capiamo cosa significano tutti gli argomenti che abbiamo dato in pasto a wget.

• -k (o --convert-links): questo argomento fa si che, alla fine del processo di download, tutti i links alle pagine siano convertiti a links relativi, in modo da permettere la navigazione offline;
• -r (o --recursive): questo argomento permette il download – in gergo – di tipo ricorsivo, così da scaricare sicuramente l’intero sito web;
• -p (o --page-requisites): questo argomento permette di scaricare anche ciò di cui si ha bisogno per visualizzare correttamente la pagina (fogli di stile,immagini, javascripts eccetera eccetera);
• -D (o --domains): questo è un argomento importantissimo, per non ritrovarvi la macchina piena di pagine web inutili: scarica soltanto i links interni al dominio (o ai domini, separati l’un l’altro da una virgola) da voi specificati, in genere si usa quello del sito stesso;
• --restrict-file-names: altro argomento importante, permette di modificare i nomi dei files così da non andare in contrasto con il sistema operativo che state usando. I possibili parametri sono unix (se dovrete visualizzare il sito su un sistema Unix) o windows (se dovrete visualizzarlo su Windows).
• L’ultimo parametro, come avrete capito, è l’url del sito web che andrete a scaricare.

Se, quindi, io volessi scaricare l’intero sito http://www.chimerarevo.com, andrei a scrivere a terminale

wget -k -r -p -D chimerarevo.com --restrict-file-names=unix http://www.chimerarevo.com

Alla fine del processo, avrete bello e pronto il vostro sito web in una cartellache si chiamerà esattamente www.vostrosito.org. Qualora dovreste avere problemi con il download (se, per caso, dovesse cadervi la connessione ad esempio) potrete utilizzare il comando precedente per continuare il download, aggiungendo però anche il parametro -nc (o --no-clobber), che permette di non sovrascrivere i files già scaricati.

Semplice, veloce e indipendente: cosa c’è di meglio?
 

Fonte: http://www.chimerarevo.com/2010/06/16/wget-un-comodo-comando-da-terminale-per-scaricare-interi-siti-web/

This opera is licensed under a Creative Commons Attribuzione 2.5 Italia License.