Alessio Biancalana Grab The Blaster di Alessio Biancalana

Apple che ti cambia il pavimento sotto i piedi

Oggi stavo leggendo un po' di news, e a un certo punto sono finito su un articoletto piccolino di Dave Winer, scritto più o meno una settimana fa, il quale descrive l'esperienza d'uso con il suo nuovo iMac - e soprattutto non ne descrive tanto le gioie (scontate) quanto le "piccole" cose che Apple ha cambiato in Mac OS Lion, e che l'hanno reso decisamente iroso. Traduco direttamente dal pezzo:

Hanno fottutamente cambiato il modo in cui funzionano le fottute scrollbar. Questo sarebbe un glitch. Ma la cosa ridicola è che ci sono cose che non si possono fare con le nuove scrollbar, che si potevano fare con quelle vecchie. Io sono un utente del computer professionale [e professionista NdT]. Sarebbe come se la Fender spostasse i fret su una Telecaster. O la manopola che controlla il tono di una delle corde. Forse posso aggiustare le cose componendo i miei brani con una chiave diversa, ma dimmi, che cazzo stavi pensando quando hai fatto questo, Apple??

Macbook

Ora, a prescindere dai toni per nulla concilianti, e dal paragone con la composizione musicale che al sottoscritto garba parecchio, credo che ci sia da riflettere su queste frasi di Winer, e sui tool che usiamo per la nostra produzione quotidiana. Un newbie può pensarla in maniera diversa, ma sicuramente Dave Winer è quel tipo di utente a cui uno possa andare a dire "ehi amico, se non ti sta bene questo comportamento, perché non ti scrivi una patch?"

È una soluzione estrema, ma penso che la possibilità del patching e della modifica del software acquistato insieme a una macchina - o installato come sistema operativo, o installato sul sistema operativo, sia un valore sacrosanto, che non dobbiamo dimenticare solo perché qualcuno ci ha regalato insieme a quel software un'interfaccia un po' più figa di quella di altri sistemi operativi.

Photo courtesy of harald walker

FTP e copia di file multipli da terminale con Midnight Commander

Proprio oggi mi serviva mettere a copiare dei file da un server remoto al mio muletto di casa, così ho scartabellato un po' greppando l'internet alla ricerca di un client FTP da terminale con una GUI recente. Dopo un po', greppa che ti greppa, ho ricordato che Midnight Commander ha una simpatica interfaccia ncurses e supporta sia FTP che SFTP (cioè FTP over SSH) integrandone le funzionalità. Mi sono ripassato quindi un po' di manualistica sull'interfaccia di Midnight Commander, che per un novellino può essere leggermente complicata, quindi ho cominciato subito a cercare.

Per connetterci via FTP ad un host remoto dobbiamo andare nel menù del pannello di destra o di sinistra (accedendo alla menubar con F9), a piacere, e dobbiamo selezionare "Connessione FTP". Successivamente, dobbiamo dare in pasto a Midnight Commander le nostre credenziali nel formato seguente:

ftp://user@indirizzo-ip:porta

E aspettare, dando conferma, che ci venga chiesta la password. Per copiare file multipli basta premere CTRL-t dentro una directory per cominciare a selezionare il materiale che vogliamo copiare. Una volta terminata la sezione, dal menù File scegliamo Copia - la cui location sarà di default la directory esplorata dall'altro pannello.

Midnight Commander

Una volta finito il tutto, voilà: diamo un Ok, e immediatamente il processo di FTP o SFTP comincerà a copiare i file mostrandoci l'avanzamento tramite una progressbar. Consiglio particolarmente l'uso di Midnight Commander per copiare file da una macchina all'altra usando la CLI, in combinazione con GNU screen, che ci consente di fare "detach" e chiudere la consolle senza che il processo di Midnight Commander si interrompa. In questo modo potremo lasciare che le due macchine remote (come nel mio caso) sbrighino i propri compiti mentre noi in locale - ad esempio - mandiamo in sospensione il nostro PC, e ce ne andiamo a farci una bella mangiata dal kebabbaro qua di fianco.

Il 2012 di fuoco di GitHub

Vi siete mai chiesti se GitHub avrebbe mai rilasciato qualche dato sulle collaborazioni attraverso il suo network di sviluppo? Magari non ve ne frega una mazza. Però a me è successo di chiederlo a me stesso - dato che mi piace starmene lì a leggere come cresce il panorama open source quando ho un po' di tempo libero.

GitHub in 2012

Non saranno dati eccessivamente interessanti, ma sicuramente buttargli un occhio non fa male, anche per leggere l'evoluzione di una piattaforma che secondo me ha fatto la storia e che sicuramente nel 2012 è stata uno dei servizi (nonché delle compagnie) imprescindibili per chi scrive codice, per chi investe in software, e perché no, visti gli speech di alto livello dei fondatori, a cui per alcuni dei quali ho avuto anche il piacere di assistere personalmente, anche riguardo i ricercatori e la ricerca nel campo del software, e degli algoritmi.

GitHub fa un sacco di cose interessanti: sul blog ufficiale trovate "The Octoverse in 2012". Leggetevelo tutto, merita. Anche la parte sulle emoji.

Image courtesy of GitHub - The Octoverse in 2012

E tuttavia, a me, il Nexus 4.

Lo sapevamo da quando è stato presentato: il Nexus 4 non sarebbe stato facile da trovare. Meno che mai però alcuni immaginavano quello che era già stato predetto da quelli che io personalmente ho classificato in parte come "hater" di LG, che tuttavia stavolta hanno avuto ragione: stando a quello che dice Google, le forniture sono scarse da parte della casa madre, e processare gli ordini per i Nexus 4 sta prendendo molto più tempo del previsto.

Nexus 4

Su Facebook e in giro per il web tutto, ho cominciato a vedere i primi segni di cedimento dalla community, lasciando spazio a chi sostiene cose malevole per LG: "Voglio sapere quanti acquirenti perderà Google con questo scivolone". E però io allora non mi spiego come mai, a sentire tutte queste colpe di LG, la voglia di acquistare un Nexus 4 (che avevo già documentato ampiamente parlando del rinnovo della gamma Nexus) non è passata per niente, anzi. Nonostante le critiche infatti, quello che mi è sembrato imputato della cattiva "user experience" è stato più che altro il cattivo (cattivissimo) sistema di distribuzione di cui sia Google che LG fanno parte. Questo non toglie nulla alle mie ragioni per l'acquisto, e cioè che il Nexus 4:

  • È il dev phone
  • È AOSP: supporto della community perfetto
  • È facilmente riparabile nonostante lo schermo saldato
  • È nel complesso un ottimo telefono
  • Costa poco

Tra il costo, e tutti i benefici sopra elencati, a me sembra che un Nexus 4 valga comunque l'acquisto, e ci si possa permettere per un gioiellino del genere di non infastidirsi troppo per colpa di ritardi nella spedizione. Ciò detto, comunque, non reputo superflue le scuse di Google, che ha fatto benissimo se non bene a porsi in questo modo, dando agli utenti ancora una volta l'impressione che "a Google importa".

Photo coutesy of abuakel

Linux dice addio al 386, senza lacrime

In questi giorni mi sono passate per le mani un sacco di email: una tra quelle che mi hanno colpito maggiormente è proprio quella di "addio" del kernel Linux all'architettura 386. Uno tra i supporti più antichi all'interno del kernel, tanto che tutte le distribuzioni "cardine" fino a non molto tempo fa continuavano a voler supportare con ottimizzazioni varie ed eventuali anche un'architettura antica come questa.

Python code

Beh, lungi da me piangere una modernizzazione dell'infrastruttura. Come da mail, questo comporta una riduzione della complessità e anche qualche miglioramento in quanto a performance (meno righe di codice, bla bla bla), quindi non posso che esserne contento. La nostalgia risale al fatto che io abbia ricordato come anni e anni fa scaricavo distribuzioni -i386, anche se una delle ultime che scaricai fu Arch Linux che, in avanti rispetto ad altri, ottimizzava già per i686. Che bella cosa.

Riporto integralmente il commit message di Linus Torvalds:

Merge branch 'x86-nuke386-for-linus' of git://git./linux/kernel/git/tip/tip

Pull "Nuke 386-DX/SX support" from Ingo Molnar:
"This tree removes ancient-386-CPUs support and thus zaps quite a bit
of complexity:

24 files changed, 56 insertions(+), 425 deletions(-)

... which complexity has plagued us with extra work whenever we wanted
to change SMP primitives, for years.

Unfortunately there's a nostalgic cost: your old original 386 DX33
system from early 1991 won't be able to boot modern Linux kernels
anymore.  Sniff."

I'm not sentimental.  Good riddance.

* 'x86-nuke386-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, 386 removal: Document Nx586 as a 386 and thus unsupported
x86, cleanups: Simplify sync_core() in the case of no CPUID
x86, 386 removal: Remove CONFIG_X86_POPAD_OK
x86, 386 removal: Remove CONFIG_X86_WP_WORKS_OK
x86, 386 removal: Remove CONFIG_INVLPG
x86, 386 removal: Remove CONFIG_BSWAP
x86, 386 removal: Remove CONFIG_XADD
x86, 386 removal: Remove CONFIG_CMPXCHG
x86, 386 removal: Remove CONFIG_M386 from Kconfig

:')

L'immagine non c'entra niente, è Python, ma mi piaceva molto.

Image courtesy of nyuhuhuu

Member of

Previous Random Next