11 Jun 2013
Ieri sera è stato presentato iOS 7. Tantissime le reazioni, tantissimi i botta e risposta su Internet riguardo il nuovo design e, soprattutto (quasi), le nuove feature. Eh già, perché Apple se con il nuovo design ha fatto finta di tornare a fare qualcosa di nuovo - copiando e remixando fattori già noti, ma facendolo sicuramente in maniera caratterizzante, e facendoci anche una pessima figura con gli utenti - in quanto a feature non s'è certo sprecata a reinventare la ruota.
Il che non mi spiacerà, finché queste cose non verranno spacciate per innovazioni incredibili, esattamente come è stato tentato di fare sul palco ieri sera con una battuta tristissima: "Can't innovate anymore my ass" ha detto Phil Schiller, e per fortuna si riferiva al Mac Pro più che ad iOS. Mi è piaciuto, riassumendo, iOS 7 spiegato al mio cane, che ha fatto una summa di tutto quello che pensavo anch'io (lasciando fuori WebOS), e scrivendolo in tono molto ironico.
I pulsantini toggle per attivare al volo Wifi, Bluetooth, volume e musica, Google e altri cellulari li hanno da 5 anni. Non è esattamente quella che si può sbandierare come una nuova feature. Il multitasking che sfoglia le app aperte con l’anteprima ce l’hanno già tutti da una vita. Le mail che le scorri per cancellarle o archiviarle le ha già fatte Mailbox, lo scambio di files tra due dispositivi si poteva fare dieci anni fa con i primi cellulari ad infrarossi e l’avete impedito soltanto voi ridicolmente. In sostanza: quasi nulla delle novità software di oggi sono innovazioni, quanto più “portarsi in pari in ritardo”.
Insomma, un buon lavoro interno nelle app, doveroso più che altro visto che introduce caratteristiche da anni chieste a gran voce da migliaia di utenti, ma con un impianto visivo un po’ acerbo e non adatto ad un pubblico trasversale. Troppo colorato per un uso serio, troppo simile e monotono con la dominanza di bianco per essere funzionale. Per me è un parziale no, con la curiosità di provarlo sul campo e capire se le (poche) nuove funzionalità varranno la candela di un futuro update. Jonathan Ive, forse è meglio torni a forgiare metalli preziosi in attesa di ricevere qualche feedback dagli utenti della prima ora.
Sicuramente impararemo a gettarci alle spalle anche questa piccola scivolata. Apple ridiverrà la grande azienda rivoluzionaria che nelle menti (e, purtroppo, solo in quelle) di tutti è sempre stata, e le vere innovazioni secondo il volgo proverranno sempre da iOS, OS X, e compagnia cantante. Poco importa se il tagging dei file è stato implementato anni fa in KDE e Nepomuk, poco importa se i controlli veloci e i widget li aveva già Android. iOS 7 cambia tutto per non cambiare nulla, esattamente come nel celebre scritto di Tomasi di Lampedusa.
Ma c'è qualcosa da dire a riguardo: noi non dimentichiamo. E se l'utente di OS X è pronto a sbandierare le nuove caratteristiche del suo sistema operativo, deve essere anche sempre pronto a ricordare che nel 90% dei casi c'è chi ne ha fruito prima di lui, e senza pagare un computer migliaia di dollari/euro/yen.
Photo courtesy of Nehuén Mingote Kisler
07 Jun 2013
Da quando è arrivato il mio computer nuovo (si, ho comprato un altro giocattolo, e si, vi scasserò quanto prima con una pedissequa descrizione) ho ricominciato ad imbattermi nei problemi più assurdi che riguardano tutte le piccolezze del setup di base di una bella workstation con Linux. In particolare una cosa di cui non mi ero mai accorto è sempre stata come sia un fastidio immane dover riconfigurare il tema dei cursori di sistema.
Ho dovuto farlo infatti, dato che KDE non gestisce molto bene le preferenze dell'utente sui cursori, per cui ogni tanto mostra il tema deciso da noi (me, te, il mio vicino), e ogni tanto invece prende e di sua totale iniziativa mostra il tema di sistema. La soluzione è quindi impostare il tema del cursore system-wide e quello dell'utente sullo stesso valore, in modo da non dare più occasione a KDE di rovinare la nostra user experience.
Dato che non mi andava di andare a rovistare in decine di file di configurazione alla ricerca di quello giusto (tantomeno di leggere il manuale) ho fatto una ricerchina su Google per questo bel bug e mi sono accorto che su Launchpad viene consigliata l'esecuzione di update-alternatives per questo tipo di task.
Ci basta dare quindi il comando:
sudo update-alternatives --config x-cursor-theme
Che provvederà a mostrarci un piacevole dialogo numerico a riga di comando dove potremo scegliere il cursore di default semplicemente digitando il numero ad esso associato.
Fine dei giochi. Semplice no? Magari se gli sviluppatori di KDE mi evitassero di sbroccare per queste piccolezze. Eh.
Photo courtesy of fonso
03 Jun 2013
Qualche decina di minuti fa, preso da un irrefrenabile impulso per le cose pericolosamente fighe a mezzanotte e mezza con un occhio aperto e uno chiuso, mi sono preso il portatile e carezzandolo amorevolmente ho aggiornato Arch Linux, eseguendo l'update di cui si vociferava in giro che accorpa un sacco di roba (al momento non ho ricordi precisi, ho sonno) tra cui le varie /usr/bin, /usr/sbin, /vattelapesca/soreta/sbin, in un'unica directory.
Visto che è una roba strana e pericolosa, e che a me come al solito è andata parecchio liscia, lascio qualche nota sparsa ai "bambini meno fortunati di me", come li chiamava mia nonna, perché è sempre bene indicare la via ai nuovi adepti (dato che altrove gli archer vengono tacciati di essere una setta, e dato che probabilmente lo siamo: la setta dei Tafazzi).
- Occhio a quello che fate: questo aggiornamento vi può spaccare il sistema e se non sapete quello che state facendo con ogni singolo comando della procedura, lo dico per voi, cambiate spassionatamente distro oppure passate direttamente a Windows che fate prima;
- Occhio ai pacchetti che lasciano roba dentro le directory di cui fare il merge: potete controllare di non avere nemmeno un capello fuori posto con dei check specifici elencati nella news di riferimento;
- Se l'aggiornamento non vuole proseguire non è perché avete un computer capriccioso: non forzate assolutamente l'upgrade o rischiate di trovarvi davanti alla faccia un fermacarte, nel mio caso con un ottimo monitor da 15" e una ottima tastiera a isola. Ma se non aggiustate poi con parecchie bestemmie, rimane un fermacarte. Anche se è vero che, se forzate l'upgrade in circostanze simili, forse dovreste pensare a una conseguenza come quella del punto 1 (si, lo so, non li sto numerando ma tanto fate voi).
Adesso vado a letto ché c'ho sonno e voglio leggermi un po' dei libri di Martin. Mi raccomando, non spaccate il PC, voglio continuare a credere nella bontà del genere umano.
Sinceramente, a titolo del tutto personale, vorrei sperare di non ritrovarmi ugualmente domani con un fermacarte in mano: Arch Linux mi piace, ma questi aggiornamenti un po' buttati così (premesso che ho voglia di gestirli, comunque) certe volte fanno girare las pelotas, e non poco.
Photo courtesy of Richard Alexander Caraballo
21 May 2013
Si, non c'entra quasi niente con l'open source, ma io sono un nerd e che diamine, questa nuova Xbox One ha davvero catturato il mio interesse con un paio di mosse da vera/o catcher. A parte la nerdiness solita dei numeri e dei server che si accendono e spengono, una delle cose che mi ha colpito di più è stato il trailer di Quantum Break. All'interno infatti possiamo trovare una corposa sezione di video girata a mo' di film, con attori in carne e ossa.
Era un po' di tempo che mi domandavo quando questo sarebbe accaduto: intere sequenze di gioco live action. Finalmente adesso siamo arrivati al break point per questo tipo di esperienze di infotainment, per cui, beh, mi aspetto il prossimo passo. Trailer con le nostre facce? Una webcam che prenda i nostri tratti facciali e li riproponga sul protagonista del gioco?
Secondo me possiamo aspettarcelo. Basta attendere.
13 May 2013
Rispolvero un minuto il blog, dato che ultimamente posto poco per il semplice fatto che tra lavoro e università, scrivere di cose che mi stiano a cuore con la testa "a posto" (ossia non presa da mille pensieri) mi riesce un po' arduo. Ma ho appena scovato una cosa interessante, che ha mi ha svoltato qualche ora della mia esistenza.
Vi siete mai chiesti quanti cambiamenti il progetto Android abbia mai apportato al kernel Linux per renderlo compatibile con il documento di progetto iniziale? Io spesso me lo sono chiesto. E a prescindere dal fatto che da qualche versione di Linux tutto il codice prima separato è confluito nel sorgente ufficiale, è una domanda che qualche volta mi sono fatto anch'io, concludendo con un sonoro boh ogni mia riflessione. Fortunatamente qualcuno ha deciso di chiederlo su Quora, e qualcun altro, uno sviluppatore Google, ha risposto.
Traduco in italiano perché merita:
La cosa interessante riguardo il design di Android è quanto poco abbiamo modificato il kernel. La maggior parte dei sistemi embedded su cui ho messo mano hanno apportato cambiamenti drastici al kernel, solo per lasciare lo user space isolato - per esempio, un kernel "realtime" fortemente modificato, e poi X11 per la GUI.
Android è l'opposto: solo cambiamenti minimali al kernel, ma uno user space esclusivo, diversamente da ogni altro sistema Unix. Infatti, lo user space di Android è così differente dal Linux tradizionale, che si può dire che Android non sia un sistema Linux eccetto che per il kernel.
Ecco una lista concisa dei cambiamenti che abbiamo apportato al kernel di Linux:
- ashmem (Android Shared Memory), un sistema di memoria condivisa file-based;
- Binder, un sistema IPC ed RPC;
- logger, un sistema hi-speed interno al kernel di logging ottimizzato per le scritture;
- Paranoid Networking, un meccanismo per ridurre l'I/O di rete a determinati processi;
- pmem, un driver per mappare chunk grandi di memoria fisica nello user space;
- Viking Killer, un OOM killer di rimpiazzo che implementa la logica di Android "killa i processi recenti meno utilizzati" in condizioni di memoria libera scarsa;
- wakelock, la soluzione unica di Android per il power management, per cui lo stato di default del dispositivo è sleep e sono richieste azioni esplicite (via il wakelock) per svegliarlo.
E ovviamente tutto il solito assortimento di driver, port per architetture ARM, e altro codice a basso livello per supportare Android su ogni dispositivo.
Di questa lista, quasi tutti i punti sono stati implementati come driver di dispositivo con modifiche al core del kernel minimali o assenti. L'unico cambiamento significativo è l'implementazione dei wakelock.
Per cui, ecco la risposta: la cosa più invasiva che ha realizzato Google è il meccanismo di wakelock, mentre il resto è tutto farina del sacco di Mountain View che però non interferisce per nulla o quasi col lavoro predefinito del kernel del ramo Linus Torvalds "e figli". Molto molto bene. Non credo di aver mai trovato righe così interessanti su Android e su quale sia il rapporto che lega i due team di development (e i due code stack).
Ringrazio il mio ottimo "collega" Alessio Sergi per la segnalazione.
Photo courtesy of Tom Page
