Dopo una lunga attesa il grande giorno è arrivato: Canonical ha annunciato il rilascio di Zesty Zapus.

Ubuntu 17.04 è stato sviluppato incessantemente durante gli scorsi sei mesi. Il desktop environment a bordo è Unity 7, scelta conservativa da parte di Canonical dettata anche dal fatto che, come sapete, Unity 8 non verrà più sviluppato in futuro. Ubuntu 17.04 si basa sul kernel 4.10, presenti X.Org Server 1.19.3 e Mesa 17.0.3 3D. Queste ultime tecnologie apportano significativi miglioramenti soprattutto in ambito gaming, ecco perchè, soprattutto chi possieda una scheda AMD Radeon, dovrebbe aggiornare a ZZ.

Ubuntu 17.04 non è una versione LTS e verrà pertanto supportato per solo 9 mesi da Canonical, quindi sino a Gennaio 2018.

Ubuntu 17.04 – Zesty Zapus

Abbiamo seguito tutto il ciclo di sviluppo di questa ventiseiesima release di Ubuntu e i nostri lettori più attenti saranno già a conoscenza delle (poche) novità introdotte dagli sviluppatori, eccone un sunto che è valevole per tutti i flavor di Ubuntu 17.04:

  • Assente il supporto alla versione powerpc;
  • Il DNS resolver di default è ora systemd-resolved;
  • Per le nuove installazioni è possibile usare un file di swap al posto di una partizione di swap;
  • LibreOffice 5.3;
  • Supporto alle stampanti che permettono la stampa senza driver specifici;

Per quanto riguarda specificatamente la versione di Canonical:

  • Le applicazioni provenienti da GNOME sono state aggiornate alla versione 3.24, tranne Nautilus 3.20, Terminal (3.20), Evolution (3.22) e Software (3.22);
  • L’applicazione Calendario ha ora la visualizzazione settimanale;
  • gconf viene sostituito da gsettings;

Come aggiornare da Ubuntu 16.10

upgrade-poll zesty zapus

Prima di eseguire un aggiornamento vi conviene effettuare un backup dei dati più importanti. Dopodichè è essenziale installare tutti gli aggiornamenti, aprite il terminale e date:

  • sudo apt update && sudo apt dist-upgrade

Per perfezionare l’aggiornamento potete usare il Software Updater o il terminale. Ubuntu vi notificherà automaticamente una nuova versione disponibile, questo potrebbe però richiedere qualche giorno.

Per un aggiornamento manuale invece dovete dare il seguente comando:

  • sudo do-release-upgrade -d

Al termine delle operazioni riavviate il sistema.

Come aggiornare da Ubuntu 16.04

zz

Per aggiornare da Xenial Xerus le cose sono un tantino più noiose, questo perchè le versioni LTS sono pensate per aggiornarsi solo ad una LTS successiva.

Per ricevere la notifica di un aggiornamento abilitate la ricerca di aggiornamenti non-LTS nel Software Updater. Fatto ciò dovrete prima aggiornare a Ubuntu 16.10 (si, Yakkety Yak) mediante il seguente comando:

  • sudo do-release-upgrade -d

Una volta finito l’aggiornamento e riavviato il sistema eseguite il login e date il seguente comando per installare Zesty Zapus:

  • sudo do-release-upgrade -d

Sicuramente gli aggiornamenti di Ubuntu da una versione all’altra sono, salvo problematiche inattese, perfettamente funzionanti. Scoraggio però gli utenti di Xenial Xerus ad aggiornare a ZZ se non vi fossero motivi particolari in quanto è più probabile che qualcosa possa andare storto.

Qualcuno di voi ha già aggiornato? Come vi trovate con Zesty Zapus?

sharing-caring

Vi ricordiamo che seguirci è molto semplice: tramite la pagina Facebook ufficiale, tramite il nostro canale notizie Telegram e la nostra pagina Google Plus. Da oggi, poi, è possibile seguire il nostro canale ufficiale Telegram dedicato ad Offerte e Promo!

Qui potrete trovare le varie notizie da noi riportate sul blog. È possibile, inoltre, commentare, condividere e creare spunti di discussione inerenti l’argomento.

  • Perry

    Segnalo che anche su questa release bisogna settare “enabled=0” in /etc/default/apport per non ricevere ogni 3×2 l’avviso di errore di sistema.

    Queste piccolezze, queste quisquilie…

    • Rehdon Dysigbana

      Le novità sembrano davvero poche.

    • Aster

      Come sempre 🙂

    • Aury88

      quale avviso di errore del sistema ogni 3×2? non ho mai settato quella cosa e fino ad ora avrò ricevuto quel genere di messaggi un paio di volte a release (i primi giorni)

      • Aster

        Non uso ubuntu da molto ma confermo a volte lo fa quando lo installo nuovo al inizio su qualche pc

        • Aury88

          ma ogni 2×3? l’ho avuto anche io, ma comunque non più di un paio di volte a release.

          • Aster

            Si concordo non così spesso

          • Kim Allamandola

            Io lo disabilito normalmente da anni, la teoria non sarebbe malvagia ma la pratica lo rende poco utile per fare veri bugreport, ad oggi serve comunque un umano che sappia come riportare un bug e all’utente i suoi messaggi non aiutano a risolver nulla…

          • Aury88

            sono d’accordo, ma se il sistema lo pensi per utenti non esperti questo è l’unico sistema comodo e forse l’unico in grado di generare un bugreport accettabile (già me li immagino i bugreport di un utente medio: ” non mi parte x” “mi si blocca y” xD). la cosa poteva essere fatta in background ma penso che sia giusto comunque chiedere all’utent eil permesso di inviare informazioni sul proprio computer ad un’azienda…semmai forse mancava l’opzione per rendere questo processo in background

          • Kim Allamandola

            Mh, personalmente mi son stancato del discorso “bisogna pensare all’utonto tipo”: lo siamo certo stati tutti e quando abbiamo iniziato non siam morti, non siam passati sotto particolari forche caudine, non abbiam causato seri disastri (se almeno altri han fatto il loro lavoro). Come facevamo noi? Se qualcosa non andava si chiedeva all’amico che ne sapeva di più, a qualche ng/ml/forum/*ug/… Alla fine si risolveva e pian piano si imparava sempre di più.

            Perché dobbiamo supportare gli utonti odierni in maniera diversa? Il FOSS non è un’azienda con clienti paganti, la community supporta (molto spesso assai meglio dei supporti business, di ogni livello) chi vuol far parte della community, crescere, contribuire. Se qualcuno non vuol imparare un minimo di dritte si danno, poi s’arrangi.

            Nello specifico i bugreport di apport contengono un mare di informazioni, nella maggior parte dei casi inutili, scomode da leggere, anche con find+grep e alla fine son di nessuna utilità: se ogni crash o problema fosse segnalato via apport nessuno guarderebbe più un tracker, sarebbe semplicemente inutile. IMVHO è meglio che un bug sia segnalato da chi sa farlo, per il resto il classico chiedi all’amico, su ng/ml/…. funziona assai meglio e se veramente di bug si tratta passa per mani opportune senza andare a romper le scatole agli sviluppatori/maintainers per cose che bug non sono.

          • Aury88

            l’apport non impedisce a te agli altri esperti di segnalare il bug. fino ad ora apport mi è comparso per crash che, evidentemente, sono stati generati da qualche bug. il fatto che una cosa venga pensata per un utente non esperto non è necessariamente un male…potrebbe anche aiutare utenti più esperti a non perdere tempo dietro procedure semplificabili o automatizzabili.

            tu non devi supportare alcunché e non è stata la community a perdere tempo per sviluppare quello strumento, è stata canonical che a quanto pare era interessata a quella tipologia di utenti. a te non interessa? ci sono altri lidi e sopratutto stiamo parlando di una cosa che compare normalmente abbastanza raramente e puoi chiudere istantaneamente con un click….non so perchè sul tuo sistema comapaia ogni 2×3, ma a me spunta mediamente un paio di volte a release (solo nei primi tempi) e li ho chiusi perdendo in totale 3s …e certo per 3s persi non mi metterò a montare una polemica inutile sul come gli utonti siano la rovina della nostra comunità

            devi poi anche capire che per alcuni utonti il computer è una passione e una cosa che gli interessa e sono quindi disposti ad imparare, per altri è uno strumento e quindi vogliono unicamente utilizzarlo senza dover imparare a fare cose che non sono tenuti a fare per lavoro…un ambiente non adatto a quest’ultima tipologia di utenti è un ambiente che non verrà mai scelto in ambito lavorativo (li ti pagano per lavorare, non per imparare ad usare il computer e a fare bugreport o a chiedere ad amici o in mailinglist varie come fare cosa)e forse è anche a causa di questo che io a lavoro, nonostante sappia fare bugeport alla classica maniera, sono costretto ad usare un altro sistema operativo scelto per tutti gli altri utonti quello si facendomi perdere del tempo.
            la community faccia quello che vuole e assuma pure l’atteggiamento elittario che più gli aggrada…ma poi non si lamenti se i soldi dei contribuenti vengono spesi in software, infrastrutture e formati proprietari

          • Kim Allamandola

            A me non compare mai: è disabilitato nel deploy 😀 era un altro utente che si lamentava…
            Il punto cmq, per me, non è che sia un nagware è che quel che raccoglie&spedisce è di sostanziale inutilità ovvero in mano a utenti inesperti, unico target a cui si rivolge, serve o da nagware se non inviano segnalazioni o da spammatore di bugtracker altrimenti. Se Canonical pensa (e son abbastanza sicuro che non lo pensi) di supportare usando il bugtracker come strumento d’elezione, tutti gli utenti non in grado di fare un bugreport è meglio che faccia un tracker dedicato che diverrà utile come i forum di Google: GIGO.

            Il sistema classico: l’utente inesperto che chiede all’amico, su un ng/ml/forum/… permette alcune cose:
            – l’utente inesperto in genere contatta qualcuno vicino a lui che al posto di perder tempo a estorcergli informazioni utili può avere un accesso alla macchina e veder da se cosa non va, il risultato è che l’utente ha il problema rapidamente risolto e nessun altro ha perso gran tempo (ci vuol più tempo a capire cosa non va sentendo l’utente o cercando di tirar fuori qualcosa dai report di Apport che non guardar direttamente coi propri occhi)

            – l’utente inesperto in genere non arriva a romper le scatole agli sviluppatori (numericamente pochi) ma ad altri utenti un po’ più esperti di lui (numericamente molti di più), in pratica si crea una gerarchia che fa da cuscinetto filtrando e risolvendo “i ticket” per strada senza problemi, al massimo scalando via via verso le più alte vette

            Il sistema “automatizzato” farcisce di roba inutile (GIGO, appunto) i bugtracker, fa si che nessun esperto, a meno di non farlo per lavoro, vada a guardare bug segnalati in maniera che solo per capire di cosa sono, ammesso che sian veramente bug c’è da lavorare e non porta risposte. Se googli per un problema in genere finisci in un blog/archivio di un’ml/stack* ecc dove appunto c’è stata un discussione tra umani di un problema, risolvi molto prima che non trovarti un asettico mostro di testo pomposamente chiamato bugreport. Apport vuole essere uno di quei tanti sistemi di ticketing che cert’uni manager cresciuti a pane&ITIL vorrebbero nelle “loro” aziende. Il risultato in questi casi è che al posto di segnalare via mail un problema, magari con qualche info utile ci si trova a perder più tempo, da ambo le parti, a far da braccio meccanico del sistema di ticketing che non a segnalare/risolvere il problema. Gli unici contenti son i manager di turno che si vedono la bella dashboard luccicosa e magari vedon pure le segnalazioni diminuire perché per non rompersi le scatole la gente passa dalla mail al telefono.

            Ultima cosa sugli utenti che voglion lo strumento senza imparare nulla: hai certo ragione a dire che ci sono, e son tanti, ma questi sono quasi sicuramente anche cattivi dipendenti, per mera attitudine. Se usi uno strumento e non vuoi conoscerlo, manco per migliorare l’uso che ne fai tu, ovvero migliorare il tuo lavoro è meglio che ti dedichi ad altro, non per elitarismo ma per opportunità: sarai sempre un pericolo con in mano qualcosa che non conosci, fuori dall’ordinario non saprai mai cosa fare e cosa aspettarti ecc. Alla fin fine hai un buon esempio: tanto più un’azienda è compartimentata, proceduralizzata in stile business di scuola inglese tanto meno funziona, ha cicliche crisi e può solo viver sulle spalle di altri. Guarda la produttività della aziende USA, è da sempre più bassa di ogni paese europeo. Questo vale ad ogni livello. Anche la commessa che non vuol “studiarsi” la carta con cui fascia un pacchetto non lavorerà bene come chi l’ha fatto.

          • Aury88

            non sono assolutamente d’accrodo, sarei d’accordo se lo studiare il sistema fosse pertinente alle finalità produttive ma qui stiamo parlando di una procedura, il bugreport, che non centra nulla con la produttività se non per vie traverse. il fatto quindi di imparare a fare bugreport non ti migliora di una virgola il lavoro o l’efficacia con cui fai il lavoro (sempre che tu non sia tipo un programmatore o uno del reparto IT)…solo perchè uso la macchina per andare a lavoro non significa che mi debba mettere a studiarne il sistema per fare la diagnostica per facilitare il lavoro del meccanico in caso di guasto o mi debba mettere a studiarne come funziona la centralina che coordina il motore a scoppio. ho un problema? la porto dal meccanico e se posso gli dico cosa è successo.punto. il fatto di sapere come funziona la macchina non mi rende più efficacie nella guida o più produttivo a lavoro con cui arrivo con la suddetta macchina.
            il fatto che non me ne sia mai interessato non significa che sia un cattivo dipendente o che applichi lo stesso disinteresse ai programmi che utilizzo per lavoro, ma anche li parlo di studio nell’utilizzo del programma per le finalità che mi servono…non mi metto certo a studiare come posso utilizzare quel programma per fare altro o come fare il bugreport, e questa cosa diventa tanto più vera quanto più complesso è il lavoro e quanti più strumenti si è costretti ad utilizzare…nel mio caso (e aggiungo purtroppo perchè a me piacerebbe saper usare bene i programmi) se facessi quello che dici tu sarei necessariamente costretto a non lavorare (bloccando un intero ufficio, perdendo finanziamenti e accreditamenti per migliaia di euro ed avendo ripercussioni inail per decine di migliaia) per poter studiare bene la trentina di applicativi e procedure che stanno dietro il mio lavoro…ma questa imho non è cattiva attitudine, ma essere pragmatici e concreti nel dare la precedenza alla conoscenza di altre cose.
            è chiaro che l’utente è giusto e sacrosanto che si metta a studiare come funziona l’applicativo che usa per lavoro per poterlo usare più efficaciemente , ma qui stiamo parlando di cose totalmente diverse che non interessano (direi giustamente) ne al lavoratore, ne al suo datore di lavoro, in quanto non hanno attinenza diretta con la produttività (lo scopo del programma e quindi dell’utilizzatore non è fare bugreport)

            forse elittario è un termine errato e sicuramente ingeneroso (anche se in certi casi ho visto essere così) per descrivere la community…è in realtà proprio il pragmatismo in cui si pecca…tu puoi avere passione per certe cose ma altri no per motivi più o meno giustificati. la community deve capire cosa vuole. se vuole che i propri strumenti siano usati diffusamente bisogna fare e accettare certe scelte, se vuole rimanere isolata ed utilizzata solo in precisi e limitati ambiti tecnici (alla fine costringendo anche i propri membri ad usare altro quando si rientra in ambiti produttivi di diversa natura) continui come desidera, ma per me è un peccato e alla fine una perdita anche per la community.

            il sistema che descrivi tu è certamente un buon sistema, o non si sarebbe arrivati dove siamo ora visto che tutto è partito da li, ma in altri ambiti è inefficacie e assolutamente non possibile …in ambito lavorativo (medio) uno che si ritrova un bug chiama l’IT e gli dice “non mi funziona più il programma yy sul computer XXX” e di certo, giustamente, non sentirai mai il suo capo lamentarsi del fatto che non abbia generato un bugreport corretto o che la sciatteria nel fare questo bugreport orale sia dimostrazione di una cattiva attitudine dal punto di vista lavorativo. non è il suo compito. non serve al lavoro che deve essere fatto. e se non è il suo compito probabilmente, anche sapesse come affrontarlo, non sarebbe la persona più qualificata in azienda per farlo nel minor tempo possibile e più efficaciemente.

          • Kim Allamandola

            La “divisione dei compiti” che descrivi tu (e io preferisco chiamare compartimentazione) non è parte dei concetti del FOSS bensì delle prassi “aziendali”, nel FOSS non c’è il guidatore, il concessionario, il meccanico, il benzinaio ecc ci sono solo individui eguali, totipotenti, qualcuno più esperto, qualcuno meno.

            Il lavoratore che sul proprio desktop aziendale ha un problema non lo segnala certo a Canonical, lo segnala all’IT interno che se riscontra esser un bug segnala come si deve, a chi di dovere. L’utente privato idem, se non ha competenze si appoggia al “supporto della community” attraverso ng/ml/forum/lug/… che magari comprende anche uno sviluppatore upstream ma non fa bugreport. Il bugreport è uno strumento tecnico, non un modo d’aver aiuto generico, serve agli sviluppatori, packagers, admin, non agli “utenti finali” se questi non rientrano appunto in una di queste categorie. L’utente di cui parli non è parte della community, è un utente che utilizza software libero ma non ha (ancora) le competenze necessarie per partecipare, è per forza ai margini e magari anche lo vuol essere.

            Tieni presente che la community non è un’azienda che deve sfruttare al massimo le sue risorse, normalmente limitate, costose ecc. La community è alcuni ordini di grandezza più vasta della più grossa multinazionale del mondo, i suoi “componenti” sono un’eterogenea massa di individui e aziende che ha interessi, obiettivi e competenze diversi accomunati solo da strumenti al loro interno sviluppati e via via adattati da ciascuno ai propri gusti e necessità; non c’è un prodotto da vendere, clienti da supportare, gerarchie ecc, c’è solo uno scopo comune. Oggi c’è la moda di applicare logiche aziendali ovunque (e questa è la causa principale del disastro economico e sociale che viviamo) ma non tutto è o può esser positivamente gestito in quest’ottica.

          • Aury88

            imho anche il bugreport automatizzato fatto in maniera passiva da questi utenti può essere d’aiuto…canonical quei bugreport li fa generare da un proprio programma e li fa spedire alla propria infrastruttura…perchè quindi continuerebbero a tenere in piedi una cosa del genere se per loro fosse, come affermi tu, bugreport inutili? imho non c’è nessuna logica aziendale dietro nel senso stretto del termine, semplicemente se hai 100 utenti e 30 non sono in grado di generare bugreport è giusto poter raccogliere informazioni utili anche da quei 30 senza per questo doverli costringere ad imparare a fare bugreport. quei bugreport poi ti potrebbero consentire di migliorare la situazione anche per gli altri 70 utenti esperti e quindi anche a vantaggio della community. lo scopo comune quale sarebbe? immagino che tra gli scopi ci sia realizzare software utile, stabile e performante, no? lo stabile lo puoi ottenere anche studiando i bugreport automatici fatti da chi della community non frega nulla.
            scusami ma io continuo a non vederci nulla di male.

  • ma gnome software essendo sempre alla stessa versione, sarà lento come lo era su ubuntu 16.04 e 16.10? no perchè era lentissimo a caricare, mentre su altre distribuzioni che ho provato (opensuse, fedora, debian) le versione 3.22 e 3.24 sono molto veloci, adesso non so se è un problema specifico della versione 3.20, oppure se è l’implementazione in ubuntu che lo rendeva così lento, ma comunque per la sua lentezza, lo rendeva inutilizzabile.

    • Aury88

      penso fosse un problema di implementazione. ho visto da altre parti la versione 3.20 e non mi sembrava lenta. da quello che so comunque avevano messo mano anche al software center ma forse solo nell’ambito della visualizzazione snap. non so se hanno apportato qualche cambiamento all’implementazione sul so

      • bo ma a questo punto mi chiedo… non si sono mai resi conto che il primo avvio richiede anche 1 minuto per caricarsi?
        il software center è indicato sopratutto all’utente poco esperto, io sinceramente mi trovo meglio da terminale, ma se all’utente poco esperto che è appena passato a linux (ubuntu essendo la più diffusa) si vede il software center (equivalente dell’app store e del play store per loro) impiegare tutto questo tempo solo per aprirsi ed essere pronto, allora fa passar la voglia di usarlo per installare applicazioni e fare aggiornamenti

        • Aury88

          immagino di si, ma l’idea di canonical era ormai concentrarsi su alcuni aspetti tra i quali imho non compariva la realizzazione di applicativi per l’accesso allo store. alla fine hanno reso le API di accesso allo store disponibili a tutti (vedi sito terzo uAppExplorer che le sfrutta) e l’ultima modifica è stata la possibilità di installare snap tramite link, …penso in realtà siano più interessati allo store in se che alla modalità di accesso (ed è imho una mossa furba se vuoi che il tuo store, da cui forse guadagni, sia usato da quante più distro possibili) e devi considerare che l’implementazione dello gnome center è abbastanza recente (solo dopo l’avvento degli snap, quindi da aprile dell’anno scorso) e che era su un sistema che si pensava di abbandonare per unity8…hanno usato gnome center e modificato tanto per dare qualcosa, ma non era di certo una strategia di lungo periodo in cui investire numerose risorse

  • Maudit

    Ma questa con la lettera Z è anche l’ultima release di Ubuntu con Unity? Una coincidenza voluta?

    • ctretre

      se ricordo bene anche la prossima avrà unity, non ne vedo il motivo…

      • Ibis

        Non sarei sicuro di ciò. Avrebbe senso passare a gnome già da ottobre per essere pronti come si conviene per prossima lts

        • ctretre

          Anche per me è strano, ma questo sembra essere il piano.
          Non sarà un passaggio difficile, Ubuntu gnome esiste già basta sponsorizzarlo.

          • Kim Allamandola

            A naso penso che renderanno Gnome Shell una sorta di brutta copia di Unity 7, magari importando le buone trovate (menù nella barra del titolo, hud, controlli finestra, …) e mitigando per quanto possibile le assurdità di G.S., del resto è più o meno la stessa cosa che facevano una volta con Gnome 2.x…

            Per questo serve un po’ di tempo…

    • Falegnamino

      Particolare interessante….

  • Aster

    Anche se ho abbandonato xubuntu temporaneamente,dico finalmente 😉

  • Riccardo Magrini

    Forse nn ha neanche senso testare/installare o usare queste ultime release, visto il passaggio a GNOME sulla 18.04. Scelta secondo me valida visto che di novità sul desktop c’era solo la Dash il resto delle utility utilizzate sono firmate GNOME, di Canonical ce’ ben poco. Inoltre G e’ un desktop environment completo a tutto ciò che serve ad un utilizzatore. Unity ottimo lavoro ma nn completo, secondo me, doveva essere considerato da Canonical un progetto in parallelo da portare avanti ma come desktop secondario, e prima della sua completezza avere e mantenere G. come desktop principale.

  • Fabio Pellico

    con Ubuntu gnome 16.10 niente aggiornamento ancora…

    speriamo nei giorni successivi.

  • Mrholiday

    Unico motivo per installarla era vedere i progressi di unity 8. Visto come è a data a finire la cosa sembra a dir poco inutile

    • Aury88

      per vedere i progressi credo sia comunque meglio usare i silos che sono le versioni più aggiornate in assoluto…non credo per unity8 adottino una strategia di aggiornamento differente rispetto al resto del sistema (o avremmo avuto un aggiornamento o più ogni settimana) e, se è così, questo significa che di default puoi testare unity8 con features pari a quelle presenti al momento del features freeze che è di un mesetto fa se non vado errato….i cambiamenti da allora sono stati non indifferenti (ultimo aggiornamento tre giorni fa: aggiornamento automatico delle icone sul launcher)

  • Aury88

    gnome va bene per la strategia di ripiego che sta adottando canonical…serviva un DE che non necessitasse di troppe modifiche prima di essere utilizzabile…e allo stesso tempo fornire abbastanza capacità di scelta/adattabilità per accontentare una buona fetta di utenti, specialmente i develop. e poi ricordiamoci che gli snap vengono installati tramite ubuntu center che è in realtà uno gnome center e che molti applicativi di default di ubuntu provenivano da gnome…quindi come ripiego era imho l’unica scelta più conveniente e logica

  • ghirlandaio

    Probabilmente passerà alla storia come una delle più inutili release di Ubuntu.

    • marcovaldo

      Nessuna semestrale è inutile perché serve a preparare la LTS futura.

No more articles