Problemi raggiungibilità mozillaitalia.org
23 Dicembre 2011
Da ieri pomeriggio risulta particolarmente problematico raggiungere i domini mozillaitalia.org (sito e forum).
Il problema non è sicuramente legato al server, visto il carico ridottissimo che risulta accedendo via ssh, secondo il “sysadmin” che ci segue il problema è legato al sovraccarico dei DNS, a me sembrerebbe un problema di routing visto che il risultato non cambia cercando di raggiungere l’IP del server :-\
traceroute to 69.64.58.98 (69.64.58.98), 64 hops max, 52 byte packets 1 192.168.133.20 (192.168.133.20) 1.994 ms 0.855 ms 0.823 ms 2 * * * 3 172.17.121.45 (172.17.121.45) 31.736 ms 31.762 ms 30.381 ms 4 172.17.120.1 (172.17.120.1) 30.565 ms 31.453 ms 31.977 ms 5 172.17.10.129 (172.17.10.129) 34.452 ms 33.577 ms 32.612 ms 6 172.17.10.89 (172.17.10.89) 32.181 ms 32.645 ms 32.834 ms 7 pos1-10-0-0.milano26.mil.seabone.net (195.22.192.29) 35.270 ms 36.815 ms 35.213 ms 8 ge12-0.franco32.fra.seabone.net (89.221.34.55) 54.930 ms 53.671 ms 53.926 ms 9 te0-7-0-0.mpd21.fra03.atlas.cogentco.com (130.117.15.45) 61.616 ms 61.365 ms 60.586 ms 10 te0-0-0-2.mpd21.ams03.atlas.cogentco.com (130.117.48.137) 64.813 ms te0-4-0-2.mpd21.ams03.atlas.cogentco.com (154.54.39.173) 68.272 ms te0-3-0-2.mpd21.ams03.atlas.cogentco.com (130.117.2.41) 67.981 ms 11 te0-4-0-2.ccr21.lpl01.atlas.cogentco.com (154.54.58.62) 71.509 ms te0-3-0-2.mpd22.ams03.atlas.cogentco.com (154.54.39.185) 68.140 ms te0-0-0-2.ccr22.ams03.atlas.cogentco.com (130.117.3.89) 67.236 ms 12 te0-3-0-4.ccr21.ymq02.atlas.cogentco.com (154.54.6.141) 143.779 ms te0-2-0-4.ccr21.ymq02.atlas.cogentco.com (154.54.0.70) 145.520 ms te0-0-0-7.ccr22.lpl01.atlas.cogentco.com (154.54.37.106) 75.592 ms 13 te0-1-0-4.ccr22.ymq02.atlas.cogentco.com (66.28.4.21) 144.662 ms te0-2-0-7.mpd21.yyz02.atlas.cogentco.com (154.54.7.213) 175.277 ms te0-4-0-4.ccr22.ymq02.atlas.cogentco.com (154.54.44.213) 145.563 ms 14 te0-1-0-6.ccr22.yyz02.atlas.cogentco.com (154.54.42.237) 149.700 ms te0-1-0-3.mpd21.ord01.atlas.cogentco.com (154.54.42.9) 180.738 ms te0-2-0-6.mpd22.ord01.atlas.cogentco.com (66.28.4.57) 163.137 ms 15 te0-2-0-6.ccr22.ord01.atlas.cogentco.com (66.28.4.137) 180.530 ms te0-2-0-0.ccr22.ord01.atlas.cogentco.com (154.54.7.109) 176.713 ms te0-5-0-2.ccr22.ord01.atlas.cogentco.com (154.54.7.169) 162.576 ms 16 * * * 17 38.104.162.66 (38.104.162.66) 179.616 ms 230.761 ms 182.787 ms 18 static-ip-209-239-125-4.inaddr.ip-pool.com (209.239.125.4) 170.469 ms 167.386 ms 169.566 ms 19 colossus913.server4you.de (69.64.58.98) 165.629 ms 165.805 ms 166.072 ms
UPDATE ore 17: come peraltro suggerito via mail da un gentile lettore, il routing non c’entrava una fava. Dopo aver perso un paio d’ore per capire da che parte guardare Plesk e trovare i relativi log (bleah!), ho trovato un errore relativo al raggiungimento del limite di MaxClients. A quel punto mi sono accorto che il file apache2.conf risultava modificato giusto ieri a mezzogiorno, reimpostato il valore di MaxClients a 150 e tutto è tornato a funzionare (spero…).
Internet Explorer 6
23 Dicembre 2011
Da qualche tempo medito di alleggerire e ottimizzare il tema WordPress di Mozilla Italia, lavorando soprattutto sul fronte immagini, in modo da ridurre il consumo di banda e velocizzare il caricamento della pagine.
Stamattina, complice la mancanza di sonno e la necessità di tenere le mani occupate per non scorticarmi vivo, ho deciso di dare un’occhiata alle statistiche del sito, in particolare per capire se là fuori ci sono ancora dei malati di mente che navigano con Internet Explorer 6. Risultato:
Il 12,90% degli utenti che utilizza Internet Explorer è ancora fermo alla 6 e rappresenta il 6,49% delle visite totali. Forse la fine del mondo ce la meritiamo…
Off to Berlin in 48 hours
9 Novembre 2011
Nel fine settimana l’orso oracolo si trasferisce a Berlino per l’European MozCamp 2011 in compagnia di un folto manipolo di italiani. Vediamo che ne esce 😉
A proposito dei 6.000 bug di Firefox
29 Agosto 2011
Leggo in un articolo pubblicato su Tom’s hardware dal titolo «Firefox ha 6000 bug e nessuno che se ne occupi»
Firefox ha circa 6000 difetti potenzialmente pericolosi, e nessuno farà nulla per risolverli. La fondazione Mozilla non è abbastanza attiva su questo aspetto, e il processo di analisi e correzione (triage) semplicemente non funziona.
Si parla di Tyler Downer (mettere un link all’articolo originale pareva brutto?), peccato che il senso delle sue parole venga stravolto.
In Spring 2010, we hit roughly 13,000 UNCO bugs in the Firefox product on BMO. 13,000!!! We currently have 5934.
I 5934 bug nel prodotto Firefox1 sono UNCONFIRMED (UNCO), in altre parole nessuno ha avuto il tempo di leggerli, stabilire se si tratti di un problema reale e impostarne lo stato a NEW. Cinque minuti su BugZilla sono sufficienti per rendersi conto che molti di questi bug sono incompleti, riguardano situazioni ben documentate o non sono semplicemente bug di Firefox. E se qualcuno avesse mai visto una puntata di E.R., saprebbe anche che il triage non è “analizzare e correggere”, ma selezionare e smistare i problemi in base alla gravità.
Sarà ma di questi tempi ho l’impressione che si debba criticare Mozilla a prescindere…
[1] BugZilla è suddiviso in prodotti, non sempre intuitivi per chi non ha esperienza nel mondo Mozilla. Nello specifico si parla di bug aperti per il prodotto Firefox, in alcuni casi questi bug verranno spostati verso componenti più specifici, in altri casi verranno chiusi. Questo è esattamente uno dei compiti del triage.
Mozilla e il nuovo “life cycle”
24 Giugno 2011
Come spero avrete notato in settimana è uscito Firefox 5, primo risultato del nuovo ciclo di rilascio rapido che ci porterà ad avere Firefox 6 prima di settembre.
Da tutte le parti si critica la scelta di Mozilla di utilizzare il “metodo Chrome” per la numerazione delle versioni, personalmente trovo la discussione poco utile. Che la versione sia 5 o 4.1 poco cambia, più interessanti sono altri aspetti:
- a quanto pare pochi si lamentano del fatto che il passaggio alla versione 5 sia stato proposto come minor update, in altre parole non è stata richiesto all’utente se volesse passare alla nuova versione (come avviene per un major update, ad es. 3.6.x -> 4). Questo è positivo se l’obiettivo è arrivare ad avere un sistema di silent update (tanto per cambiare in stile Chrome);
- il problema principale è legato alla compatibilità delle estensioni. In questo caso il nodo non è certo il numero 5 – se si fosse chiamata 4.1 la situazione non sarebbe cambiata – quanto la difficoltà pratica per gli autori, quasi sempre volontari che sviluppano per puro hobby, di verificare la compatibilità delle estensioni con un ciclo di vita di sole sei settimane.
Interessante è la (lunga) discussione su dev-planning, in particolare alcune risposte di Asa Doztler che, stando al suo profilo Linkedin, adesso occupa il ruolo di “Director of Firefox”:
- a chi gli fa notare che esistono estensioni non ospitate su AMO, ad esempio utilizzate per la gestione di intranet aziendali, viene risposto che la diffusione in ambito corporate di Firefox non è un obiettivo. Opinione già sentita più volte in passato e poco condivisibile.
- sulla questione compatibilità delle estensioni
Add-on authors who use the Add-on SDK and host at addons.mozilla.org (and their users) will be rewarded with add-ons that don’t require any developer intervention across Firefox rapid releases.
In altre parole: il futuro è quello di estensioni basate su Add-on SDK (qualcuno ricorda la “vecchia” querelle su JetPack?). A questo punto il vero problema è: il nuovo SDK è maturo per estensioni complesse? Se la risposta è no, quando lo sarà? Gli utenti saranno disposti ad aspettare?
Aggiungo una nota: chi ospita le proprie estensioni su AMO ha a disposizione un pannello di controllo che permette di modificare agevolmente la compatibilità senza bisogno di rilasciare una nuova versione del componente aggiuntivo. Molte estensioni sono state automaticamente aggiornate dallo staff di AMO per aggiungere la compatibilità a Firefox 5.
Personalmente non ho avuto alcun problema nel passaggio 4->5, al contrario ne ho avuti diversi nel passaggio 3.6->4 (ho dovuto riscrivere la parte del codice relativa alla gestione delle preferenze).
Mozilla e Rapid Release Cycle
13 Aprile 2011
Qualche annotazione sul nuovo ciclo di sviluppo rapido adottato da Mozilla:
- gli sviluppatori, come è sempre avvenuto, lavorano sul repository mozilla-central (trunk). Le nightly vengono realizzate a partire dal codice presente in questo repository e ovviamente si tratta delle versioni meno stabili;
- ogni sei settimane le modifiche vengono spostate nel repository mozilla-aurora. Questo repository non prevede la possibilità di modifiche alle stringhe (è “string frozen”), lo scopo è quello di stabilizzare il codice prima di distribuirlo a un pubblico più ampio. Questo significa che i localizzatori possono lavorare su questo repository o, se lo decidono, direttamente su mozilla-central.
- dopo altre sei settimane il contenuto di mozilla-aurora viene spostato nel repository mozilla-beta;
- sei settimane dopo si passa da mozilla-beta a mozilla-release.
L’immagine seguente dovrebbe essere sufficientemente chiara, anche sui numeri di versione. Mentre la versione 5 inizia il ciclo “aurora”, sul trunk inizia il lavoro sulla versione 6 e così via. Di conseguenza ogni sei settimane si avrà una nuova versione.
Ad ogni repository corrisponde un canale di aggiornamento (nightly, aurora, beta, release), selezionabile nella finestra Informazioni su Firefox (come sempre design e localizzazione non sono necessariamente definitivi).