bigo72′s

Archivi per la categoria ‘Trucchetti’

Anche questa per la serie “lo sapevate tutti ed io no”, una notizia flash (aggettivo mai più azzeccato!).

Se per caso come me qualcuno si chiedesse se è il caso di aggiornare il proprio plugin Adobe Flash, o semplicemente che versione c’è installata nel suo sistema, ecco il link del sito Adobe che ci mostra la versione a caratteri cubitali (non proprio cubitali, anzi, piuttosto piccoli, ma mi è sempre piaciuto dire “cubitale”).

Massacratemi nei commenti con cose del tipo “ma lo sanno pure i bambini!” oppure “ma se si aggiorna da solo!” … lo so! L’ho scritto solo per Pino, va bene?!

Tuttavia, se qualcuno fosse a conoscenza di un sistema più sbrigativo e sicuro, si faccia pure avanti.

Premetto che non so che cosa ho fatto di preciso, ma giuro a me stesso che approfondirò questo argomento, anche perchè pare funzionare alla grande!

Molto spesso ci capita di lamentarci della lentezza delle nostre connessioni a banda larga, ma non sempre tutto questo è dovuto al brand del fornitore di servizi internet, o meglio, solo in parte.

Occhio che sto per scrivere una frase riscrita milioni di volte negli anni: ad ogni indirizzo web corrisponde un indirizzo IP quindi scrivere nella barra indirizzi del browser http://www.google.com o http://74.125.43.103/ è esattamente la stessa cosa, ma col vantaggio che il caricamento del secondo indirizzo sarà più immediato del primo.

Se moltiplichiamo tutti i piccoli ritardi accumulati nel surfing giornaliero ci accorgiamo che clicka di qua e clicka di là, alla fine della giornata abbiamo passato 1/5 del nostro tempo aspettando il caricamento delle pagine (stima un tantino esagerata, comunque, dai, fate i bravi, un bloger deve esagerare, è risaputo! Lo fanno tutti i blog fighi).

In pratica se ci ricordassimo l’indirizzo IP di tutti i siti che frequentiamo saremmo a cavallo, ma dovremmo anche linkare i siti inserendone l’IP e poi….insomma, sarebbe un’incubo! E’ qui che ci vengono incontro i server DNS (Domain Name System), che memorizzano per noi tutte le coppie NomeDominio-IP presenti nel WEB. Ogni ISP consiglia i suoi server DNS, una massa incolore di nerd pseudo-geek spinge per l’adozione in massa dei famosi OpenDNS (che ogni tanto rallentano talmente tanto la navigazione da ricordare i “vecchi tempi”…..ma è solo un’esperienza personale, in giro c’è gente entusiasta).

Quello che qui mi accingo a descrivere è l’impostazione di un Servizio di Domain Name proprio sul nostro mac, in modo che le coppie nome-numero vengano memorizzate in locale, per un accesso praticamente istantaneo, senza interrogare DNS esterni, che devono poi interrogare altri DNS e così via.

Cominciamo allora, per me ha funzionato, poi magari cercherò pure di capire cosa ho fatto

Creiamo prima di tutto una chiave rndc col seguente comando in terminale

$ sudo rndc-confgen -a

ci verrà richiesta la password da amministratore e la inseriremo. Fatto il primo passo, ora, visto che abbiamo il terminale aperto e la maggior parte del lavoro va fatto qui, usiamo anche l’editor di testo nano così poco preso in considerazione, in modo da far tutto nel terminale.

Prima trasformiamoci nell’onnipotente root

$ sudo su -

Inseriamo la nostra password

$ cd /System/Library/StartupItems

$ mkdir BIND
$ cd BIND
$ nano -w BIND

Ora siamo in nano e stiamo creando il file BIND che riempiremo con le seguenti righe:

#!/bin/sh

. /etc/rc.common

if [ "${DNSSERVER}" = "-YES-" ]; then
ConsoleMessage “Starting BIND DNS Server”
/usr/sbin/named
fi

Chiudiamo con ctrl-X e salviamo il file con Y e poi INVIO. Ora ci serve un’altro file, che prontamente andremo a creare:

$ nano -w StartupParameters.plist

aggiungendo queste righe:

{
Description = “Local DNS”;
Provides = (”DNS Server”);
OrderPreference = “None”;
Messages =
{
start = “Starting DNS Server”;
stop = “Stopping DNS Server”;
};
}

Rendiamo il file eseguibile:

$ chmod +x BIND

E assicuriamoci che si avvii ad ogni reboot del mac:

$ nano -w /etc/hostconfig

E aggiungiamo questa riga alla fine, se non esiste già:

DNSSERVER=-YES-

Se esiste già nel file avrà valore -NO-, quindi cambiamo -NO- con -YES- ed abbandoniamo la condizione di root:

$ exit

Ora lanciamo il nostro script:

$ sudo /System/Library/StartupItems/BIND/BIND

Adesso possiamo uscire dal terminale, abbiamo attivato il servizio locale di DomainName BIND, ma non è ancora finita, perchè dobbiamo utilizzarlo:

andiamo in Preferenze > Network
Cancelliamo i DNS presenti e inseriamo 127.0.0.1.

FATTO!

Per verificare che il DNS in uso sia effettivamente quello locale ricorriamo nuovamente al terminale:

$ nslookup www.apple.com
Server:        127.0.0.1
Address:    127.0.0.1#53

Non-authoritative answer:
www.apple.com    canonical name = www.apple.com.akadns.net.
Name:    www.apple.com.akadns.net
Address: 17.149.160.10

Sinceramente ho notato un miglioramento che definirei bestiale, davvero non me l’aspettavo!

[Fontissima!]

Questa è proprio catalogabile a pieno titolo col tag LoSapevateTuttiEioNO. E comunque me la son cercata, visto che Safari lo uso poco e mi sta sulle balle, l’ho sempre dichiarato apertamente. Tuttavia in questi ultimi giorni lo sto rivalutando, devo esser sincero, anche grazie al rinnovato look di Safari 4beta che mi ispira un tantino.

A Cesare quel che è di Cesare: è grazie a RunAway di #mela che ho scoperto GreaseKit, il GreaseMonkey per applicazioni WebKit, tra cui Safari, davvero una gran bella storia, visto che per quanto mi riguarda lo avvicina di più all’uso che personalmente faccio del browser (in pratica ci installo la peggiore merda che gira per la rete, fino a quando non son costretto a creare un nuovo profilo per morte prematura del precedente per over-dose da script e add-on).

Uno degli script carini e senza dubbio utili è YouTube Perfect che mostra la pagina di un video su YouTube sotto una veste rinnovata, con un bel po’ di comandi in più, tra cui un mitico tasto dal sibillino nome di “Download” che non lascia spazio a nessun tipo di dubbio circa la sua funzione.

Quello che avremo al primo avvìo, tuttavia è una cosa simile a questa, non appena clickeremo sul play:

In effetti non si tratta di un bug, come potrebbe sembrare ad un primo sguardo, ma di una funzione attivata di default, esattamente quella che “spegne la luce” e focalizza la nostra attenzione sul video che stiamo guardando, attivabile e disattivabile clickando sull’icona che rappresenta una lampadina sotto al player.

Ma a noi non piace che le cose ci vengano imposte, se io voglio guardare il video con la luce accesa come la mettiamo? Poco male, basta clickare sull’icona della lampadina, ma se non vogliamo che questa funzione sia attivata di default, purtroppo non basterà urlarlo a gran voce: dovremo agire sullo script, da buoni smanettoni.

Anche qui il tributo in diamanti e pietre preziose va pagato a RunAway che ha scoperto che per non avere la “luce spenta” di base, basta impostare a false due variabili all’interno dello script (che si edita aprendo il menu di GreaseKit e scegliendo la voce “Manage Scripts”): autoExpand e autoLightsOut.

Fatto questo di default avremo una situazione come questa:

Ed eccoci qui, basta clickare sull’icona della lampadina, se ci pare, per spegnere le luci e il tutto è molto più usabile. Davvero interessante quello che si ottiene girando la rotella del mouse su un video in modalità mp4.

Grazie RunAway!

Non so voi, ma io sono paranoico: ogni volta che mi fisso su un qualcosa che voglio cambiare nel sistema (quello con la S minuscola, visto che quello con la maiuscola ho rinunciato a cambiarlo già da molto tempo), non mi fermo fino a quando non la vinco!

Erano giorni che mi soffermavo a studiare le preferenze di X-Chat Acqua per cercare di capire come disabilitare la funzione di scrollback, che permette a X-Chat di salvare vecchie conversazioni all’interno dei tab di canali e query. Una cosa un tantino fastidiosa, visto che il logging l’ho disabilitato e non ho voglia di rivedere le cazzate che ho sparato ieri notte alle due quando mi si chiudevano gli occhi dalla stanchezza.

Ecco che dopo ricerche assurde, visto che ancora non sapevo che keyword utilizzare, ho scoperto prima di tutto che questa cosa si chiamava scrollback, poi che per disabilitarla basta dare il comando

/set text_replay off

Questo blocca la registrazione dei cavoli nostri da questo momento in poi, ma c’è ancora memorizzata tanta robina vecchia, da cancellare dalla directory /Users/nome_utente/Library/Application Support/X-Chat Acqua/scrollback buttare nel cestino, chiudere X-Chat, svuotare cestino e riavviare un X-Chat più pulito. Fatto!

Lo scorso anno, in questo articolo, avevo descritto come disabilitare il check della compatibilità dei plugin di FireFox, cosa interessante, ma, ahimè, non sempre sufficiente a rendere i plugin completamente fruibili.

Oggi ho scoperto, grazie a questo articolo, che il vero responsabile di tutta la storia è un file dall’arcano nome di extensions.rdf situato nella directory del profilo di FireFox in uso. E’ lì che sono elencate le compatibilità di tutti i plugin.

Spesso, come risaputo, un plugin è potenzialmente funzionante su versioni successive del nostro beneamato browser, ma tale potenzialità è castrata dall’intervento degli sviluppatori del plugin che barricano la compatibilità aspettando di collaudare lo stesso su versioni successive del browser di casa Mozilla.

Ebbene, non sempre questa “revisione” è concomitante con una nuova release di FireFox, e non è raro che passino dei mesi.

A questo punto interveniamo noi, editando il file di cui parlavo, situato in MacOSX nella directory /Users/nome_utente/Library/Application Support/Firefox/Profiles/xxxxxx.nome_profilo.

Basterà cambiare tutte le occorrenze del tipo NS1:maxVersion=”X.y.*” con nuneri relativi a versioni successive; io ci ho messo 3.2, così non ho rotture di coglioni per un bel po’ (anche se dicono che si passerà al 3.5, boh, staremo a vedere).

Importante è salvare una copia del file prima di aprirlo ed editarlo con TextEdit, in modo da formattarlo nella giusta maniera.

Ahimè quanto spesso ci capita di imbatterci in pagine d’errore navigando in giro per il WEB; il più delle volte si tratta del risultato di link forniti da MastroGoogle che memorizza per secoli cose non più esistenti. A quel punto un server Apache non fa altro che restituire un codice d’errore che porta ad una pagina preconfezionata veramente orribile con un difetto di fondo: è un punto d’arrivo ed invita alla fuga.

In pratica la pagina d’errore 404 base non fa altro che dirci che qualcuno ha sbagliato e ci fa sbattere contro un muro. Da questa situazione si esce solo ridigitando l’indirizzo corretto….che di solito non è quello del sito su cui siamo, che ci è già diventato antipatico!

In WordPress la pagina 404 può essere personalizzata a seconda del tema che si utilizza, infatti è customizzata in ogni tema e il suo codice è visibile nella DashBoard, nel menu “Aspetto –> Editor”.

Confesso che ho provato a modificare questa pagina, nel mio tema (Freshy2) carica l’header compreso di menu, ma non le sidebar laterali e su sfondo bianco scrive “Non trovato – Hai cercato qualcosa che non si trova qui”. Molto meglio della pagina del server sicuramente, ma comunque utile solo a metà.

A questo punto ho pensato di creare una pagina perfettamente caratterizzata dallo stile del blog, inserita nel tema come qualunque post ed ho escogitato uno di mille sistemi, nato dall’unione di diverse informazioni colte in giro per forum in cui c’è un’enorme confusione.

In pratica non ho toccato il codice di 404.php tranne che per l’inserimento di due righe in testa:

<?php
header(“Status: 301 Moved Permanently”);
header(“Location:http://www.bigo72.com/404″);
?>

In questa maniera, qualunque cosa segua nel codice della pagina 404.php relativa al tema in uso non viene considerata, perchè si viene sbalzati sulla pagina 404 che sono andato a creare come avrei creato qualunque altra pagina, come ho creato “tag”, “contatti”, “legalese” ecc.

Ciò che però restava un problema era la sua visualizzazione all’interno del menù dell’header, cosa abbastanza antipatica, che cavolo ci sta a fare la pagina 404 in un menu del genere, per essere scelta di proposito? HaHa, solo Pino sarebbe così folle da scegliere quella voce di menù!

Altre ricerchine Google e forum in tutte le lingue, fino a quando non ho trovato la maniera di escludere delle pagine, anche se pubblicate, dal menù dell’header: il file da modificare in questo caso è header.php, sempre contenuto tra le pagine che WordPress ci permette di modificare in “Aspetto –> Editor” e la riga che ci interessa è quella che contiene il comando wp_list_pages.

Qui devo dire che nel mio caso il tema inserisce suoi comandi particolari, infatti wp_list_pages è rappresentato da freshy_wp_list_pages, quindi non escludo che altri autori di temi introducano cose di questo genere. Non ci importa, perchè wp_list_pages dovrebbe essere comunque contenuto e quella è l’unica riga di codice che lo contiene, quindi non si scappa, la riga da modificare è quella, nel mio caso:

<?php freshy_wp_list_pages(‘sort_column=menu_order&title_li=’); ?>

diventa:

<?php freshy_wp_list_pages(‘exclude=280&sort_column=menu_order&title_li=’); ?>

Capiamo tutti perfettamente (tranne Pino) cosa si intende con “exclude” spero, ma ciò che ho faticato a capire cosa fosse è quello che nel mio caso corrispondeva a 280, detto “Page ID”. Trattandosi di un numero, ero sicuro che fosse il numero d’ordine della pagina, visibile in dashboard nel menù “Pagine” sotto la colonna “Ordine delle pagine”….INVECE NO! (infatti non funzionava ghgh).

Il PageID è quel numero che compare alla fine della URL relativa alla modifica della pagina, nel mio caso

http://www.bigo72.com/wp-admin/page.php?action=edit&post=280

Ecco fatto: la pagina 404 non compare più nel menù ed è raggiungibile ogni qualvolta si digita un permalink inesistente.

Detto tutto ciò, andate pure a vedere fino a che punto può arrivare la mia follìa

MacOSX sta alle mele come Microsoft sta alle pere!

Si nota niente? No? …. Si!