Firefox 3 RC1: ancora 9 gravi bug da correggere

[blackshard]

Originariamente inviato da Wolfenstein

bò per me ci stanno mettendo un casino di tempo e sinceramente credo che finchè non uscirà questo maledetto firefox 3 io userò internet explorer 7 che fin'ora non mi ha dato problemi!!!

e poi basta con 100000 beta e ora ancora la rc, ma quando si decideranno a farlo uscire??? dovremo aspettare ancora 20 anni???

Perchè hai paura che ti succeda qualcosa nel frattempo?
Ci metteranno il tempo che ci vorrà, lo userai (se vuoi) quando sarà disponibile.
Lamentarsi in questo modo mi ricorda molto un atteggiamento tipico dei bambini, stile "voglio tutto e lo voglio subito".

E se le beta sono pubbliche è solo per il bene sia della comunità che dell'azienda. Ma attenzione, usare una beta/RC senza sapere a cosa si va incontro è da incoscienti.

[AleLinuxBSD]

Dalla beta 5 lo trovo molto stabile però preferirei che uscisse una rc2 piuttosto che rilasciare una versione definita stabile che contine all'interno errori gravi che necessitano di tempi lunghi per essere corretti.
E' una questione di serietà.

[Mezzelfo]

In questo momento quella lista conta 3 bug (comuni a tutte le piattaforme)...

[November]

Originariamente inviato da mjordan

Non proprio. Il vero problema sono i miti da sfatare, invece, perchè Microsoft è stata classificata come l'azienda con il piu' basso rapporto bug/fix negli ultimi periodi. Primato che di certo non possiamo dare alla Mozilla

I miti da sfatare sono esattamente questi, e prima di tutto il fatto che più bug noti = prodotto più scadente. Solitamente è l'esatto contrario, uguale numero di falle ma non note e corrette, ovvero prodotto più scadente. Del resto a parte alcune applicazioni mission critical (dove per altro si usa ad esempio hw vecchissimo e affidabile proprio perchè bug free) e alcuni software per i quali si è usato qualche tecnica di testing e verifica automatica, di bachi è pieno il mondo. Ma la bestemmia più grande è che è "Microsoft è stata classificata come l'azienda con il più basso rapporto bug/fix negli ultimi periodi": peccato che questi "studi" siano perennemente commissionati da MS stessa a "terzi" di loro fiducia, tanto per farsi pubblicità (cosa per altro in linea con le loro politiche, oltre al fatto che chi lavora nell'open source difficilmente si ha così tanti soldi da permettersi una tale promozione). E peccato anche che in questi studi non spieghino mai quali parametri abbiano usato.
Tanto per fare degli esempi:
- le fonti: non si sa mai quali bachi abbiano conteggiato e da dove li abbiano presi, parlano sempre di una-due distribuzioni ma senza spiegare bene come li conteggino (se solo del software GNU + kernel, solo distro ecc...) e cosa intendano per bachi di sicurezza (perchè per altro lo scopo è sempre dimostrare che windows è il più sicuro in assoluto).
- un paragone sensato: soprattutto considerando che in una qualunque normale installazione di una qualsiasi distribuzione c'è una vagonata di software in più rispetto a quello in dotazione a windows nudo e crudo, portandosi dietro quindi molti più bachi. Per altro nel kernel c'è tutto il supporto hw che in windows viene solitamente fornito dai produttori stessi e che quindi non viene conteggiato.
- bachi segnalati: normalmente l'utente linux o OS X è un po' più colto e consapevole, almeno in media, ed è decisamente più attivo nella segnalazione dei bachi. Anche perchè solitamente si crede che davvero vengano risolti in tempi ragionevoli, cosa che ad esempio non succede in casa MS (un baco viene risolto se conviene perderci del tempo o è importante dal punto di vista della funzionalità o dell'immagine per l'azienda. Non a caso è successo che per lunghi periodi non avessero nemmeno provato a risolvere bug marcati come gravi).
- tipologia di bachi: premesso il punto precedente, si può ovviamente concordare che ci siano tipologie di bachi diverse tra loro. Io stesso ho aperto un bug report at kernel.bugzilla.org per chiedere di supportare il watchdog timer di un SuperIO chip montato su una scheda che possiedo, visto che erano state rilasciate le specifiche. Eppure conta come baco. Così come un altro problema che ho segnalato e per il quale ho chiesto aiuto alla ricerca di un workaround (come una whitelist nel driver) per la mancanza del riconoscimento del connettore da 80 poli su una Compact Flash (che è in realtà un difetto dell'HW). A parte il fatto che segnalazioni del genere per windows non le potrai mai fare, la patch era già disponibile ma non ancora in upstream.

Ben vengano i bug report, che sono il primo passo per avere software migliore, e ben vengano anche le correzioni, cosa che nell'open source avviene abbastanza facilmente, rapidamente e frequentemente.

[willytax]

Io su debian a 64bit me lo sono compilato da sorgente e per ora nessun rallentamento...incrocio le dita....

[The_misterious]

uso la RC1 da una settimana e và tutto bene

[dieghe]

Originariamente inviato da Fabio Gozzo

In particolare si fa riferimento al bug indicato con il numero 421482, che da solo è in grado di mettere in ginocchio le prestazioni di un sistema Linux.

ma... veramente... il bug pare essere già stato risolto....

https://bugzilla.mozilla.org/show_bug.cgi?id=421482

Sbaglio o qui dice: RESOLVED/FIXED ?
A volte le vostre news sembrano copiate e incollate senza nemmeno un piccolo controllino...

[menora]

"dieghe" mi ha preceduto di pochi secondi, è la stessa cosa che ho pensato io...

[antoniotequila]

Io lo uso su Mac da quando è uscito, tutti i giorni, minimo una decina di ore al giorno. Non ha mai crashato e sembra anche molto più veloce del vecchio.
:-)
Bho...

[topo loco]

Scusa il ritardo X sierrodc ma hai letto tutto il mio (su)post(1)? Ho specificato scherzando che non è prorpiamente così ma per esemplificare il tutto ho detto che era come una beta e come se parlassi del sesso e dell'api e dei fiori solo che non è la stessa cosa (se lo sai) ma si semplifica o e come per esemplicare i circuiti elettrici fare ricorso all'idraulica.
So cosa vuol dire beta e so cosa vuol dire rc1 rc2 so ache cosa vuol dire crc
o cdma conosco i significati di sigle e di acronimi utili o me no utili ma se tu Le-gg-essi tutto il post capiresti che dovevo arrivare al topos che era scomposizione in acronimo per deridere Vista.

[Rand]

Originariamente inviato da dieghe

ma... veramente... il bug pare essere già stato risolto....

https://bugzilla.mozilla.org/show_bug.cgi?id=421482

Sbaglio o qui dice: RESOLVED/FIXED ?
A volte le vostre news sembrano copiate e incollate senza nemmeno un piccolo controllino...

La news è giusta (a parte forse il "lungo tempo per correggere i problemi", ma è più che altro un modo non chiarissimo di rendere la situazione), semplicemente il bug è stato corretto nella linea di sviluppo che porterà alla RC2 o alla 3.0.1. Da qui il "resolved/fixed".. (e il bug è stato chiuso dopo l'uscita della news).

[leoneazzurro]

Originariamente inviato da axse

come se non bastassero i problemi di configurazione di un so linux, come se non bastassero i problemi derivati da tutti i vari software i versione pre-alfa alfa/beta ecc. che cascano in continuazione.
Se rilasciano anche un firefox che inchioda il pc allora vuol proprio dire che i linuxiani se ne fregano degli utenti comuni, quelli che vogliono un sistema che va. e basta.

Evitiamo i soliti post da flame. Per il momento vale un'ammonizione.

Per il resto: per piacere, evitate le polemiche tra utenti, perchè a parte qualche post la discussione è interessante

[Flybyme]

Beh io cn RC1 ho notato solo su XP ho dei rallentamenti rispetto a FF2....e non so se disinstallarlo e rimettere il buon vecchio FF2....
Che dite?

[spettacolo78]

Originariamente inviato da tyco74

L'ho dovuto disinstallare. Non mi si installa il plugin di Adobe Flash. Spero che risolvano questo gravissimo bug prima di rilasciare la versione definitiva.

Esatto, ho fatto una simulazio su VirtualBox e il Flash di installarsi proprio nn ne voleva sapere... ...
X il resto come uso particolare... nn ho notato "stranezze"
Comunque aspettiamo fiduciosi!!!

[riva.dani]

Dopo un primo momento di diffidenza devo dire che Firefox 3 mi piace molto. Sono sempre di più le estensioni a cui ero affezionato che vengono aggiornate per funzionare anche con questa nuova versione. Quindi mi aggrego a chi difende le debolezze di Firefox 3 dicendo che, per il momento, è comunque una RC e quindi non una versione finale!

Stavo pensando di segnalare anch'io un bug, ma prima chiedo a voi, per sapere se è un problema diffuso: quando apro gmail in una scheda, la chiusura della scheda stessa (dopo che ho finito di controllare la posta) manda firefox in crash. Ovviamente basta riaprirlo per riavere tutte le schede che erano aperte, però non è il massimo della comodità...

[K Reloaded]

un consiglio buono a tutti quelli che passano alla RC venendo dalla versione 2: cancellare TUTTI i vecchi profili e installare FF ex-novo ...

[®_Flash_®]

.
tutti i bug gia' corretti

Firefox 3 RC2 gia' pronta

download Zip senza installer


http://ftp.mozilla.org/pub/mozilla.o...0.it.win32.zip


non usare il profilo di FF 2 su FF 3

[K Reloaded]

Originariamente inviato da ®_Flash_®

.
tutti i bug gia' corretti

Firefox 3 RC2 gia' pronta

download Zip senza installer


http://ftp.mozilla.org/pub/mozilla.o...0.it.win32.zip


non usare il profilo di FF 2 su FF 3

asd

[mjordan]

Originariamente inviato da dieghe

ma... veramente... il bug pare essere già stato risolto....

https://bugzilla.mozilla.org/show_bug.cgi?id=421482

Sbaglio o qui dice: RESOLVED/FIXED ?
A volte le vostre news sembrano copiate e incollate senza nemmeno un piccolo controllino...

Veramente al momento della pubblicazione della news, quel bug era ancora aperto ed in stato "reopened".

[mjordan]

Originariamente inviato da November

I miti da sfatare sono esattamente questi, e prima di tutto il fatto che più bug noti = prodotto più scadente.

Io non ho mai detto il contrario.

Solitamente è l'esatto contrario, uguale numero di falle ma non note e corrette, ovvero prodotto più scadente. Del resto a parte alcune applicazioni mission critical (dove per altro si usa ad esempio hw vecchissimo e affidabile proprio perchè bug free) e alcuni software per i quali si è usato qualche tecnica di testing e verifica automatica, di bachi è pieno il mondo.

Mai detto il contrario.

Ma la bestemmia più grande è che è "Microsoft è stata classificata come l'azienda con il più basso rapporto bug/fix negli ultimi periodi": peccato che questi "studi" siano perennemente commissionati da MS stessa a "terzi" di loro fiducia, tanto per farsi pubblicità (cosa per altro in linea con le loro politiche, oltre al fatto che chi lavora nell'open source difficilmente si ha così tanti soldi da permettersi una tale promozione). E peccato anche che in questi studi non spieghino mai quali parametri abbiano usato.

Mi dai la fonte di questa notizia per cortesia?
Perchè se è "una bestemmia" allora di fonti ce ne saranno a bizzeffe che contrastano questa affermazione.

Tanto per fare degli esempi:
- le fonti: non si sa mai quali bachi abbiano conteggiato e da dove li abbiano presi, parlano sempre di una-due distribuzioni ma senza spiegare bene come li conteggino (se solo del software GNU + kernel, solo distro ecc...) e cosa intendano per bachi di sicurezza (perchè per altro lo scopo è sempre dimostrare che windows è il più sicuro in assoluto).
- un paragone sensato: soprattutto considerando che in una qualunque normale installazione di una qualsiasi distribuzione c'è una vagonata di software in più rispetto a quello in dotazione a windows nudo e crudo, portandosi dietro quindi molti più bachi. Per altro nel kernel c'è tutto il supporto hw che in windows viene solitamente fornito dai produttori stessi e che quindi non viene conteggiato.
- bachi segnalati: normalmente l'utente linux o OS X è un po' più colto e consapevole, almeno in media, ed è decisamente più attivo nella segnalazione dei bachi.

Si parlava esclusivamente di rapporto "numero di bachi / numero di bug fix". Dove siano quei bachi, come siano classificati, ecc. ecc. sono irrilevanti ai fini del discorso che facevo. Forse stai facendo confusione con le notizie su chi è il sistema piu' sicuro. Io non mi riferivo a quelle.

Anche perchè solitamente si crede che davvero vengano risolti in tempi ragionevoli, cosa che ad esempio non succede in casa MS (un baco viene risolto se conviene perderci del tempo o è importante dal punto di vista della funzionalità o dell'immagine per l'azienda.

Esattamente come nel software open source. Non ho mai visto nessun progetto svenarsi per fixare un bug che non sia considerato critico o evitare una release per una P4 in giu. E poi "bug" non è mica sempre sinonimo di "risolvibile in tempi brevi". Ci sono bug che per essere risolti necessitano di cambiamenti architetturali anche pesanti, da cui la non risolvibilità nel ciclo di vita di una point release e ai quali si demanda il fix alla prossima major release. E questo non ha nulla a che vedere con l'essere closed o open. Ha sicuramente a che vedere, invece, sul mancato fix di qualche bug critico in alcune circostanze: non si può fixare un determinato bug senza rompere la compatibilità con qualcosa. Questo nel software open in alcuni casi lo si fa volentieri. Nel software commerciale closed non lo puoi fare. Quindi "il non succede in casa Microsoft" non è di certo il demerito che vuoi mostrare, sono semplicemente due obiettivi di sviluppo differenti. E' semplicemente che non lo possono fare per ovvie ragioni. Stop. Senza andare a scomodare closed o open. I progetti open in genere rilasciano quando hanno fixato tutti i bug "P1" o giu di li, quando non ci sono regression o giu di li. I bug classificati come "P4" in giu nemmeno vengono classificati per determinare la rilasciabilità di una release o meno. Tutto il fixabile viene fixato, ma se la release è arrivata in fase temporale, si rilascia lo stesso e i restanti bug vanno a finire nella sezione "known bugs". Non facciamo credere che l'open è il santo venuto da cielo e il closed è il demonio da cacciare dalla terra, perchè oltre a non essere cosi, le metodologie di sviluppo sono uguali in entrambi i casi. Vogliamo parlare di KDE 4.x e in che stato è stato rilasciato?
Queste questioni non hanno nulla a che vedere con "closed" o "open", se non per il fatto che l'open ha il vantaggio di poter includere patch esterne. Ma anche questa è una piccola chimera, perchè comunque il numero di bug fratto il numero di patch risolte esternamente al progetto è comunque molto basso.

Io stesso ho aperto un bug report at kernel.bugzilla.org per chiedere di supportare il watchdog timer di un SuperIO chip montato su una scheda che possiedo, visto che erano state rilasciate le specifiche. Eppure conta come baco.

Veramente sulla LKML si lamentano sempre di queste richieste, perchè queste sono feature request, non bug report. Una mancanza di feature non è affatto classificata come bug. E non deve esserlo.

A parte il fatto che segnalazioni del genere per windows non le potrai mai fare, la patch era già disponibile ma non ancora in upstream.

Uhm, veramente i bug report per i prodotti Microsoft si fanno in genere sul sito Connect, addirittura da circa 2 anni.

Ben vengano i bug report, che sono il primo passo per avere software migliore, e ben vengano anche le correzioni, cosa che nell'open source avviene abbastanza facilmente, rapidamente e frequentemente.

In alcuni progetti open source. Non in tutti. E "open source" è decisamente troppo generico, come categoria, per fare questi tipi di discorsi.