Link alla notizia: http://www.hwfiles.it/news/stop-allo-sviluppo-di-firefox-in-versione-a-64bit_44782.html

Non ci sarà più una versione di Firefox a 64 bit. Problemi di plug-in e necessità di ottimizzare lo sviluppo su altri progetti

Click sul link per visualizzare la notizia.

con l'avvento di sistemi operativi per lo + a 64 bit (ormai la quasi totalità dei seven preinstallati è di questo tipo) anche per gestire quantitativi di ram che si assestano sopra i 4Gb, vedrei + l'abbandono dei 32 bit piuttosto che i 64.

ma poi la realtà non è cosi'

anzi mio zio che lavora con programmi anche costosi e particolari, vuole ancora l'XP (ovviamente a 32bit) per incompatibilità verso SO nuovi.

boh!

Capisco il supporto ai vecchi sistemi, io avrei visto più fruttuoso lo sviluppo sui 64 bit, dato che ora il 99% dei pc sugli scaffali hanno questo tipo si OS.

Il futuro magari darà ragione a loro!

Quindi invece di andare avanti preferiscono rimanere indietro, evidentemente temono di perdere clientela.

onestamente quali sarebbero i vantaggi di un firefox a 64 bit? imho nulli

vorrei sentire un parere costruttivo a riguardo, che non sia "è piu figo che ci sia scritto 64bit"

Eccerto! se non esce una versione definitiva perchè qualcuno dovrebbe preoccuparsi di far ucire i PLUGINS???

E poi le build nightly erano anche abbastanza stabili, a parte l'ultima uscita (azz proprio quella poi, adesso ceh non aggiornarann più!!! UFF) che crasha spesso.

Mannaggia dovrò cercarmi uno spinoff....

E dire che mi trovavo così bene ...

Crisa i vantaggi si vedono quando hai tanta ram impiegata in altro e magari devi aprire tante schede.
A quel punto la differenza di gestione della ram, e la capacità dell'os di allocare più di 3.2 gb fanno la differenza in termini di reattività e stabilità.

Crisa i vantaggi si vedono quando hai tanta ram impiegata in altro e magari devi aprire tante schede.
A quel punto la differenza di gestione della ram, e la capacità dell'os di allocare più di 3.2 gb fanno la differenza in termini di reattività e stabilità.
Questo è certo, ma per quanto riguarda un browser c'è effettiva necessità?
Un browser a 32 bit sarà più lento di uno a 64?

@franlelli e per quale ragione uno dovrebbe far allocare al browser piu' di 3 gb di ram? 200k schede di youporn in contemporanea? Le differenze tra 32 e 64 bit sono per lo piu' una questione di figaggine. E nell'articolo c'e' scritto chiaramente. "E piuttosto che proporre un prodotto insoddisfacente è preferibile dedicare maggiori sforzi allo sviluppo del ramo a 32bit e a tutte le altre novità."

Io avrei trovato più logico sosprendre la 32bit.
Gli os 32bit sono ancora usati, ma non succede nulla se usano un browser vecchio.
Dall'altro lato il futuro è a 64bit, ormai montano 4giga di ram anche le calcolatrici, e un browser a 64bit ci vorrebbe anche in ottica dei nuovi sviluppi web (giochi 3d nel browser per esempio)
Il futuro è a 64 bit ma il presente è assolutamente a 32 bit, sospendere il supporto ai SO a 32 bit è un suicidio.
C'è un mondo fatto di Windows XP aziendali fuori da questo forum.

@franlelli e per quale ragione uno dovrebbe far allocare al browser piu' di 3 gb di ram? 200k schede di youporn in contemporanea? Le differenze tra 32 e 64 bit sono per lo piu' una questione di figaggine. E nell'articolo c'e' scritto chiaramente. "E piuttosto che proporre un prodotto insoddisfacente è preferibile dedicare maggiori sforzi allo sviluppo del ramo a 32bit e a tutte le altre novità."
Per poi lamentarsi, fra l'altro, che Firefox consuma un sacco di ram... :asd:

Waterfox e passa la paura ( http://www.waterfoxproject.org/ )

Mi meraviglia la superficialità della notizia riguardo un aspetto che evidentemente si è dato per scontato: la versione 64bit "cassata" è solo per i SO Microsoft. Il motivo, semplificando, è che alcune API del SO non funzionano come dovrebbero e Mozilla si è stancata di cercare work-around.

Altra musica per Linux e MACOS: qui le versioni 64 bit sono ancora attivamente manutenute e sviluppate, anche perché già oggi sono molto più diffuse le architetture 64bit delle 32bit.

Io avrei trovato più logico sosprendre la 32bit.
Gli os 32bit sono ancora usati, ma non succede nulla se usano un browser vecchio.

Ah sì? Pensa te che fessi ci sono nelle software house. Tutti i mesi a correggere falle di sicurezza che tanto non succede nulla...
I 32bit vivranno ancora parecchi anni e anche quando i processori saranno solo 64bit ci saranno gli emulatori software. E' enormemente più logico postporre la versione 64bit visto inoltre che non è un'applicazione che richiede chissà quali risorse.

Il futuro è a 64 bit ma il presente è assolutamente a 32 bit, sospendere il supporto ai SO a 32 bit è un suicidio.
C'è un mondo fatto di Windows XP aziendali fuori da questo forum.

Ah sì? Pensa te che fessi ci sono nelle software house. Tutti i mesi a correggere falle di sicurezza che tanto non succede nulla...
I 32bit vivranno ancora parecchi anni e anche quando i processori saranno solo 64bit ci saranno gli emulatori software. E' enormemente più logico postporre la versione 64bit visto inoltre che non è un'applicazione che richiede chissà quali risorse.

E' presto per abbandonare i 32 bit, ma tutto il mondo che è rimasto indietro come quello aziendale non sta dietro all'ultima versione di firefox, anzi se si fermassero e rilasciassero solo dei fix sarebbero contenti.
Poi se mi dite che i 64 bit non porterebbero nessun vantaggio ok, di questo non me ne intendo ma pensavo che a 64 bit i programmi girassero in maniera nativa e non emulata e quindi andassero meglio, ho detto una castroneria?

Ah sì? Pensa te che fessi ci sono nelle software house. Tutti i mesi a correggere falle di sicurezza che tanto non succede nulla...
I 32bit vivranno ancora parecchi anni e anche quando i processori saranno solo 64bit ci saranno gli emulatori software. E' enormemente più logico postporre la versione 64bit visto inoltre che non è un'applicazione che richiede chissà quali risorse.

tra l'altro il software 32bit sul 64bit si può installare... viceversa no, quindi non è che il 64bit rimane senza programmi

tra l'altro il software 32bit sul 64bit si può installare... viceversa no, quindi non è che il 64bit rimane senza programmi

Beh io ho un Linux 64 bit in ufficio e rimango completamente scoperto dato che il 32 bit non è compatibile con le librerie installate... a meno che non facciano una build che risolva tutte le dipendenze agilmente...

Che razza di idioti! :mad:

Ringrazio VK per aver segnalato Waterfox :) Purtroppo sono un po' indietro con lo sviluppo... :(

Forse non è abbastanza chiaro quello che c'è scritto sulla news, è il caso di ribadirlo. Lo sviluppo dalla versione 64 bit viene cessato solo ed esclusivamente per MS Windows. Linux e OS-X continueranno ad avere la loro versione di FF 64 bit.

Che razza di idioti! :mad:
E già, come fare a meno dei 64 bit su un browser.

E già, come fare a meno dei 64 bit su un browser.

ok
pero' e come se si sospendesse la ricerca sulla fusione nucleare intanto chi la usa?

se il futuro è a 64 bit, (e magari a 128 chissà) puo' anche darsi che 64 bit per un browser non servano a granchè, pero' se l'so e a 64 bit e sara' sempre + cosi', perchè non sviluppare o tentare di sviluppare sempre in tal senso?

il fatto che ci sono software house pigre che non vogliono dedicarsi al 64 perchè intanto gira lo stesso e evitare di spendere soldi in sviluppo non porta da nessuna parte

vorrei vedere un ipotetico windows 9-10 che abbandona il supporto a 32 bit per le applicazioni.

poi ci sarà da ridere

qui mi sembra più un'abbandono per motivi "tecnici".
Dato che l'unica versione a 64 bit a venire "eliminata" è quella per Windows penso che ci sia un motivo serio dietro.
Le altre versioni (per Linux e MacOS) sono tutte a 64 bit.

Brutto segno quando un'azienda abbandona lo sviluppo nell'ambito dell'innovazione e comincia a rinchiudersi nell'esistente.
A me sembra che le ultime scelte (a cominciare dagli aggiornamenti ravvicinati) siano il sintomo di problemi crescenti dal punto di vista industriale.

E già, come fare a meno dei 64 bit su un browser.

Un processo a 32bit non può allocare più di 2GB di RAM, e per il resto che si fa? Abbiamo PC con minimo 4-8 GB che non possiamo usare...

Ok che usare più di 2GB per il browser è difficile e che volendo basta suddividere le schede su due processi ma, il punto è che hanno troncato lo sviluppo per il futuro! Il futuro è sempre più browser e richiederà sempre più RAM! I video su HTML5 ne richiedono, e anche le app Javascript! Basta vedere il solo Facebook. Se hai aperto diverse pagine del genere sei finito... :rolleyes:

E poi i SW a 64bit sono generalmente più veloci, se fatti bene

Forse non è abbastanza chiaro quello che c'è scritto sulla news, è il caso di ribadirlo. Lo sviluppo dalla versione 64 bit viene cessato solo ed esclusivamente per MS Windows. Linux e OS-X continueranno ad avere la loro versione di FF 64 bit.

Chi se ne frega di Linux! :asd:

@Raghnar-The coWolf-
Viene sospeso lo sviluppo esclusivamente della versione per sistemi microsoft, se tu lo usi su linux non sei colpito dal "taglio".

@leddlazarus
Non è questione di pigrizia, ma di risorse limitate. Devi decidere cosa è meglio fare per potare avanti i tuoi progetti che davvero contano.

Inoltre non è questione di "ricerca". I 64 bit non sono un mostro sconosciuto su cui occorre fare ricerca, semplicemente occorre lavoro per tenere costantemente la build aggiornata e risolvere i problemi.
Quando sarà il momento semplicemente riprenderanno in mano il progetto a ne creeranno una versione a 64 bit, sempre che le versioni non ufficiali non riescano a mantenere una base così buona da essere riutilizzabile.

Ultima nota: sui sistemi MS a 32 bit puoi indirizzare al più 2GB di ram. Penso che questo valga anche per le applicazioni a 32 bit sui sistemi a 64 bit, ma non ne sono sicuro: qualcuno può smentire o confermare?

AlPaBo
Non c'è nessun abbandono dello sviluppo nell'ambito dell'innovazione, anzi, semmai il contrario.
Per poter spingere ancora più sull'innovazione, Mozilla ha sospeso i progetti che riteneva superflui e problematici.
Gli aggiornamenti ravvicinati non sono sintomo di nessun problema, ma la risposta ad un problema che c'era in precedenza.

E poi i SW a 64bit sono generalmente più veloci, se fatti bene


se fatti bene e l'app non usa più di 2Gb di ram non c'è assolutissima differenza

E poi i SW a 64bit sono generalmente più veloci, se fatti bene


Non c'e' differenza, in compenso i processori sono piu' lenti, per questo non si fanno a 128 bit.


Chi se ne frega di Linux! :asd:

Veramente mozilla sta dicendo che quello di cui frega poco e' windows :cool:

se fatti bene e l'app non usa più di 2Gb di ram non c'è assolutissima differenza

C'è diferenza invece, perchè se usi 10 app da 200MB ciascuna arrivi a 2GB cmq. E sei nella mer**. Il problema non sussiste (o meglio, è molto raro) se Firefox creasse un nuovo processo per ogni tab, come fa Chrome, ma questo è uno spreco assurdo di risorse (e poi consumi un pacco di RAM in più, proprio come Chrome) a meno che non crei un gestore di processi interno che crea nuovi processi solo per quelle schede che ospitano contenuto troppo esoso di memoria, ma anche è difficile capirlo a priori, soprattutto perchè una pagina può inizialmente visualizzare Google e GMail e poi passare di botto a qualche cosa di pesante, chessò un FB con pagine molto ricche di immagini e video. Quindi un sistema del genere mi pare complicato.

Personalmente uso FF 32bit, ma perchè non apro mai tante schede pesanti, ma c'è molta gente che lo fa, specialmente chi sviluppa web app complesse. E questo se non è un grosso problema ora lo diventerà in futuro.

Che confusione!!!
L'idea che mi sono fatto io è la seguente.

Performance 32 vs 64 bit
A livello di performance i 64 bit e i 32 bit NON si equivalgono, semplicemente in alcuni casi è meglio avere 64 bit, in altri è meglio averne solo 32. I programmi che lavorano a 64 bit già di per sé occupano un po' più RAM di quelli a 32, ma se movimentano grossi blocchi di memoria, i 64 bit sono più indicati, sia come transfer-rate sia perché consentono di indirizzare più di 2GB. Esempi di utilizzo: compressione di grossi file, video e foto editing.
Se si lavora con programmi che movimentano piccoli pezzettini di memoria, allora i 32 bit sono più snelli; se hai poca memoria, raggiungi dopo il momento in cui il sistema comincia a fare paging sul disco rispetto ai 64 bit.

Firefox e i 64 bit su SO non-MS
E' una vita che esiste e funziona correttamente. Su Linux, oggi come oggi, i problemi relativi alle librerie 32/64 bit sono stati per lo più risolti, anzi c'è il "rischio" che i 64 bit siano più stabili dei 32. Nessun problema quindi a manutenere questa versione

Firefox e i 64 bit su SO MS
E qui casca l'asino: i problemi derivanti dalla cattiva implementazione di certe API, da parte di MS, stava facendo aumentare a dismisura le segnalazioni di crash, segnalazioni che diventano sempre più ingestibili in quanto non si tratta di errori di Firefox, ma bisogna cmq trovare dei workaround con tanta fantasia e tanto :ciapet: , per non parlare del fatto che tali WA sarebbero validi solo per MS, magari sono meno efficienti, e cmq bisogna ricordarsi di ripristinare la situazione una volta che MS ha risolto il problema (cosa che non ti verrà mai notificata, dovresti pollare ogni tanto...)
E allora: ma chi me lo fa fare? Tanto la versione 32 bit gira lo stesso e con le stesse performance su windows a 64 bit, che mi sbatto a fare?
Prendo quei 4 ragazzi che sono frustrati, che non ce la fanno più a spalare m...a e li metto a fare qualcosa di più interessante, che gratifichi loro e magari anche noi utilizzatori finali.
I 64 bit saranno da riprendere in considerazione solo quando dal browser si cominceranno ad eseguire operazioni più impegnative dal punto di vista della memoria occupata.

Non si deve troppo preoccupare. Al momento è tutto sospeso, non hanno mica detto che cancellano tutto il lavoro fatto fin'ora. Sarebbe illogico e stupido. Hanno solo bisogno di allocare più risorse in altri progetti e un FF Win-x64 non è al momento una priorità per loro.
Quando FFOS e FF con interfaccia Metro saranno ben avviati, sicuramente riapriranno il ramo Win-x64.
Nel fra tempo, per quelli che non possono sopportare la stellina (*) a fianco a firefox.exe, ci sono sempre le alternative Waterfox e Palemoon.

non mi spiego la ragione di questa scelta... soprattutto perchè la tendenza è quella di sostituire ai sistemi 32 bit i 64 bit.

Personalmente questa scelta mi lascia abbastanza indifferente e credo che impatterà gran poco sull'utilizzo reale, lascio a chi ha competenze specifiche sulle architetture software considerazioni più tecniche piuttosto che addentrarmi in diatribe da bar sport.

Trovo comunque che sarebbe più utile assegnare risorse ad altre modifiche, come un modello di gestione dei processi separati per ciascuna tab (alla Chrome per intenderci), una cosa che avrebbe certamente un impatto più significativo per l'utente e che renderebbe di fatto irrealizzabili gli scenari ipotizzati da qualcuno (trovatemi una singola pagina web che arrivi a saturare 2GB di ram :O ), scenari che già ora sono pura fantasia nonostante tutto l'html5 e il javascript di questo pianeta...

E' curioso poi notare come quando si parla di software a 64bit ci sia sempre qualcuno che accolla sempre la responsabilità della mancata migrazione del sw da architettura x86 a x64 alla "pigrizia" degli sviluppatori o delle software house.
A parte che si tratta di una lamentela tanto sterile quanto inutile (roba da "piove, governo ladro" :rolleyes: ) ma che dimostra più di tante altre quanto a volte questo forum sia distante dalla vita reale e dal mondo del lavoro.
Mi sorge una domanda, ma chi si lamenta in questo modo ha mai lavorato un giorno in vita sua? :mbe:
Ha mai pensato al lavoro che richiede una riscrittura del codice? Ha mai pensato che probabilmente questo lavoro richiede delle risorse, e se non c'è un cliente disposto a cacciare i soldi per queste risorse il software non si modifica da se?
Forse vi sfugge che una cosa del genere è una modifica evolutiva, e come tale è giusto, normale e sacrosanto che abbia un costo e anche non indifferente...
Oppure forse pensate che internet sia il solito "regno del gratis"? :stordita:

E qui casca l'asino: i problemi derivanti dalla cattiva implementazione di certe API, da parte di MS,

quando ad avere problemi sono SOLO gli sviluppatori di firefox non trovo che sia giusto incolpare MS per nascondere l'incapacità degli sviluppatori.

Quotone per Tasslehoff, che ha espresso la filosofia forse andata persa nel mare di dettagli del mio post precedente.

@Benjamin Reilly chiederei cosa non condivide o non crede sufficientemente esplicativo del mio post precedente e/o di quello di Tasslehoff, entrambi stiamo provando a dare una risposta alla domanda che lui ed altri prima di lui hanno ribadito.

quando ad avere problemi sono SOLO gli sviluppatori di firefox non trovo che sia giusto incolpare MS per nascondere l'incapacità degli sviluppatori.

E chi lo dice che ce li hanno solo loro? non c'è tantissima gente che produce software di livello a 64 bit. Magari alcuni hanno trovato dei workaround che a loro facevano comodo e in FFox non andavano bene, oppure anche altri software sono semplicemente bacati per questo motivo ma non lo si nota, chi lo sa? Certo, ci sono "solo quelle mezze calzette degli sviluppatori FFox" a dire che le API MS sono bacate ...
Io, ingenuo, tendo cmq a fidarmi delle loro affermazioni, non fosse altro che perché finora non le hanno mai sparate grosse... Quindi o mi si chiarisce perché hanno torto oppure rimango della mia idea

il mio interrogativo è limitato alla semplice perplessità: nulla da contestare.

probabilmente i plug.-in incidono notevolmente nella fruizione del browser ed hanno determinato questa decisione.

io in un sistema operativo a 64 bit prediligo software a 64 bit per evitare l'applicazione dei programmi di transizione che generano latenze e questioni di compatibilità tra differenti piattaforme.

attualmente in lubuntu 64bit oltre a Srware Iron impiego anche firefox nella versione nightly perchè pare che migliori la riproduzione audio: quindi specificatamente per l'ascolto dei filmati youtube.

A chi si domanda quali benefici ci sarebbero con una versiobe64 bit la risposta è molto semplice. Teoricamente performances migliori visto che l'applicazione sarebbe in grado di indirizzare in memoria piu dati, all'atto pratico probabilmente non ci sarebbero grosse variazioni visibili. Le differenze si notano con software piu' complessi e "pesanti" di un semplice browser per sistemi desktop.

E chi lo dice che ce li hanno solo loro? non c'è tantissima gente che produce software di livello a 64 bit.

Quindi o mi si chiarisce perché hanno torto oppure rimango della mia idea

il fato che nessun altro se è mai lamentato in questi termini.

Cioè tu mi dici che le api di microsoft sono bacate e rendono lo sviluppo di firefox difficile e chiedi a me le prove che non è vero? ma in un mondo normale non se i tu che dovresti dimostrare il contratrio? non ti sembra un po assurdo il tuo ragionamento e come se ti dicessi che linux non funziona ma quando mi chiedi del perche io ti dico "dimostrami il contrario", ma non dovrei essere io a dettagliare il motivo tecnico che mi ha portato a fare la mia affermazione?.

Le api di windows non sono perfette come non lo sono da nessuna parte ma da questo a essere causa dell'interruzione dello sviluppo di firefox mi sembra esagerato a essere buoni.

se posso esprimere la mia opinione: w chrome tutta la vita!

E' curioso poi notare come quando si parla di software a 64bit ci sia sempre qualcuno che accolla sempre la responsabilità della mancata migrazione del sw da architettura x86 a x64 alla "pigrizia" degli sviluppatori o delle software house.

a parte che le software house non sono tutte conosciute e americane.
io lavoro in ambiente sanitario.

abbiamo delle applicazioni che sono ancora certificate solo per IE6 e windows xp sp2
e sono programmi che fanno parte di progetti da milioni di euro mica bruscolini.

eppure se gli chiedi di aggiornare l'applicativo .....aaahhhrggh

e poi non devo parlare di pigrizia?

x chi vuole firefox 64bit consiglio waterfox, ormai lo uso da piu di un anno soddisfatissimo e pure aggiornato...

Credo ci sia moltissima confusione sui programmi a 64 bit.

Intanto, per rispondere a chi ha parlato di 128 bit, vorrei far notare che questo bisogno comparirà quando avremo più di 2^64 = 2 Exbibyte ( 1 exbibyte = 1024 pebibyte = 1 048 576 tebibyte = 1 073 741 824 gibibyte, quello che comunemente viene chiamato gigabyte) byte di ram. Direi che non è un problema a breve.

Un sistema a 64 bit ha semplicemente uno spazio di indirizzamento più esteso.
Le prestazioni sono peggiori (un indirizzo a 64 bit occupa più spazio in cache di un indirizzo a 32 bit, per cui a parità di codice e ottimizzazione un programma nativo a 32 bit è più veloce di uno a 64 bit).

Allora perchè il 64 bit?
Si è giunti a livelli in cui alcuni tipi di applicazioni avevano bisogno di più di 4GB di ram (simulazioni fisiche, esplorazioni di alberi(per i più svariati problemi), rendering, previsioni finanziarie, etc.), per cui è iniziata una migrazione verso i 64 bit.
In aggiunta a questo, i sistemi operativi hanno iniziato a implementare controlli della ram più evoluti, (semplificando di molto la faccenda) diventando più sicuri.

Un'applicazione a 32 bit emulata da un sistema operativo a 64 bit sarà millisecondi meno performante di una a 64 bit nativa (a causa dell'emulazione) e più veloce di una 64 bit nativa se eseguita su sistema operativo 32 bit nativo.

Inoltre il sistema operativo può allocare tutta la memoria che vuole (dubito esauriate lo spazio di indirizzamento), per cui di fatto Firefox ha a disposizione tutti i suoi 4Gb allocabili, dato che il SO e le altre applicazioni sfrutteranno gli altri.

Vuol dire che Mozzilla ha i vantaggi di sicurezza dei 64 bit, può concentrare tutta la forza di sviluppo su cose più importanti del "io ho i 64 bit!", non avrà problemi di memoria, perchè già la gente si lamenta se arriva a 1GB, figurati se arriva a 4, e per il futuro non ci sono problemi, perchè in HTML5 tutta la grafica è gestita dai driver di sistema, e se si arriverà a implementare qualcosa di simile a NaCl si chrome, verrà gestito nel suo processo apposito, che potrà richiedere ancora i suoi 4 GB di ram! Senza contare la possibilità di usare il caching!

Insomma, per favore, cercate di evitare giudizi a freddo su gente che invece le cose che dice le sa, e non fatevi prendere dalla mania e dai bisogni indotti dalle campagne di marketing per cose di cui non avete bisogno

La questione è sin troppo semplice: il port di Firefox per win64 per una serie di ragioni non è sufficientemente stabile e Microsoft ha annunciato giusto questo anno che rottamerà le API win32/win64 in favore delle API WinRT.

Visto che Mozilla non ha risorse infinite, semplicemente ha deciso di non sprecare ora ulteriori risorse su Firefox per win64 ed attendere per vedere cosa succederà con WinRT.

La versione win32 va più che bene e per quando serviranno davvero i 64bit per i web browser, ci sarà per tempo una versione a 64bit basata su WinRT (ma decisamente non ora, specialmente se si considerano gli accrocchi misto-win32/WinRT necessari per far girare un browser con Windows 8 con UI Metro).

Sia ben chiaro, un S.O. a 64bit ha i suoi bei vantaggi come pure applicazioni a 64bit che forniscono prestazioni nettamente migliori con molta più ram a loro disposizione, ma nel caso dei web browser per ora con Windows non è che ci siano vantaggi tali da usare per forza la versione a 64bit.

Pale Moon è LO spinoff e decisamente meglio di Firefox/Waterfox, poi che lo vogliate x86 o in build x64, fate vobis :) (ovviamente io prediligo la x64 :p )

x chi vuole firefox 64bit consiglio waterfox, ormai lo uso da piu di un anno soddisfatissimo e pure aggiornato...

esiste per le distro linux?

@Makers_F

Solo un appunto: non è necessario un sistema operativo a 64 bit per allocare una maggiore quantità di memoria.

Esempio: vecchio PC con 8086, processore a 16 bit, sistema operativo a 16 bit, 20 bit di indirizzamento (1MB di ram).

Il poter gestire in un unico passaggio istruzioni a 64 bit ha i suoi vantaggi in certi contesti, e i suoi svantaggi in altri.
Quale dei due sia migliore dipende quindi dal tipo di operazione da compiere e dall'impatto che questi vantaggi/svantaggi hanno sui sistemi moderni (ossia se adeguare l'hardware è poco costoso per la tecnologia usata, allora i vantaggi possono superare i vantaggi).

a parte che le software house non sono tutte conosciute e americane.
io lavoro in ambiente sanitario.

abbiamo delle applicazioni che sono ancora certificate solo per IE6 e windows xp sp2
e sono programmi che fanno parte di progetti da milioni di euro mica bruscolini.

eppure se gli chiedi di aggiornare l'applicativo .....aaahhhrggh

e poi non devo parlare di pigrizia?Beh io lavoro come consulente IT da 12 anni, molti dei quali passati in grosse realtà di PA (negli ultimi due anni poi stiamo sviluppando parecchio anche nel settore sanitario) per cui ti posso assicurare che un po' di esperienza in questo ambito me la sono fatta.

Anche noi abbiamo applicazioni sviluppate per versioni di prodotti risalenti al 2002, sviluppate quando il browser di riferimento era IE6 e ancora oggi quelle applicazioni sono immutate.
E secondo te noi dovremmo automaticamente testare e modificare applicazioni solo per adattarle ai cambi di browser o alle versioni dei prodotti, così per la gloria?
Scusa ma se lo pensi hai una visione un po' distorta del mondo del lavoro... :stordita:

Noi proponiamo le attività, quotando le giornate che servono, se poi i responsabili dell'ente o del cliente in generale non hanno budget o non approvano le attività sono fattacci loro, mica lavoriamo gratis...
La garanzia sul software dura qualche mese, se poi non vogliono sottoscrivere un contratto di manutenzione sono problemi loro, ammesso e non concesso che questo genere di attività ricadano nel calderone della manutenzione, perchè dal mio punto di vista sono attività di evoluzione belle e buone :O

I milioni di euro non cambiano nulla, negli ultimi mesi il mio gruppo ha lavorato in preparazione ad una gara per il rinnovo di servizi per un totale di qualche milione, ma tu pensi che questo includa aggiornamenti a tempo indeterminato per star dietro a ogni upgrade dei prodotti usati o delle piattaforme client?
Le applicazioni e i prodotti vengono sviluppati con delle specifiche ben precise, ogni modifica futura non inclusa a contratto e non manutentiva è un'evoluzione e si paga...

Potrei capire lamentele poi se fossimo in un momento storico in cui le aziende (PA in particolare) pagano bene, ma in un momento in cui le gare escono con quotazioni al ribasso, partendo da prezzi totalmente fuori mercato e dove si riscuote a distanza di 2 anni... beh scusa ma mi pare che la tua sia un'obiezione un po' fuori luogo e pretestuosa...
Fai conto che uscire a 350-400 euro al giorno per una figura senior è un prezzo medio, diciamo medio-basso (c'è chi non scende sotto 600-700 euro eh...) e le gare ora sono al ribasso e partono da 160 euro al giorno. :asd:
Poi non lamentiamoci se le applicazioni non vanno, gli sviluppatori sono junior che non sanno nemmeno di cosa si stanno occupando e l'informatica nella PA fa acqua da tutte le parti... :rolleyes:

a livevvo software il 64Bit implica di solito 2 vantaggi: maggiore usabilità della ram, maggiore sfruttamento del Bus e quindi dell'elaborazione CPU.
un browser al massimo deve richiamare API per lo streaming da passare direttamente al sottosistema video quindi che sia a 32 o a 64 non cambia niente.

il 64 è di una instabilità totale e anche se beta era cmq inusabile; abbandonato dopo 2 settimane di test.
concordo con gli sviluppatori; si dovrà passare al 64B obbligatoriamente solo con SO a 128Bit e questo accadrà molto lontano!

concordo con gli sviluppatori; si dovrà passare al 64B obbligatoriamente solo con SO a 128Bit e questo accadrà molto lontano!

un os a 128 bit non ha senso che esita perche se intendi 128bit come indirizzamento di memoria allora non ci arriveremo se non fra centinaia di anni.
Non confonderti con i bit dei registri quelli del bus verso la memoria e verso le fpu, le cpu attuali a 64bit per eesmpio hanno la fpu a 128/256bit ma questo non vuole dire che il so deve essere fatto a 128/256bit per sfruttarle. Tu puoi avere anche un SO a 32bit ma com la parte fpu a 1024bit le 2 cose non solo legate.

Inoltre le cpu attuali a 64bit non possono indirizzare la memoria a 64bit fisicamente perche il bus fisico è piu piccolo diciamo 48bit qusto perche appunto il quantitativo di ram che si potrebbe indirizzare con un bus fisico a 64bit non è possibile averlo su nessun sistema al mondo nemmneo su un HPC da petaflopc e quindi si risparmia il linee.

Io uso Opera a 64 bit, e posso dire che la differenza tra la versione 32 e quella 64 bit, seppure molto ridotta, c'è(Il caricamento delle pagine è appena appena + veloce, e mi sembra anche un poco più leggero).
Per quanto riguarda il cessato sviluppo di FF 64 bit,è un peccato, perchè sfrutterebbe meglio le risorse.

Le ditte è ovvio che passino lentamente a nuovi SO e SW nuovi, perchè non possono rischiare.

Ho un PC che seppure vecchio (è del 2006), con il processore AMD athlon 64 3500+(i primi 64 Bit), e windows 7 pro 64 bit, va bene(voglio solo passare da 2GB a 3-4 GB di ram, visto che la mia Asus A8V Deluxe va fino a 4 gb DDR400)

un os a 128 bit non ha senso che esita perche se intendi 128bit come indirizzamento di memoria allora non ci arriveremo se non fra centinaia di anni.
Non confonderti con i bit dei registri quelli del bus verso la memoria e verso le fpu, le cpu attuali a 64bit per eesmpio hanno la fpu a 128/256bit ma questo non vuole dire che il so deve essere fatto a 128/256bit per sfruttarle. Tu puoi avere anche un SO a 32bit ma com la parte fpu a 1024bit le 2 cose non solo legate.

Inoltre le cpu attuali a 64bit non possono indirizzare la memoria a 64bit fisicamente perche il bus fisico è piu piccolo diciamo 48bit qusto perche appunto il quantitativo di ram che si potrebbe indirizzare con un bus fisico a 64bit non è possibile averlo su nessun sistema al mondo nemmneo su un HPC da petaflopc e quindi si risparmia il linee.

non metto in dubbio ma io mi riferivo ovviamente al SO dove si va di step 32-64-128 con un WOW allo step precedente 16-32-64 bit.
win a 32 esegue anche 16 bit
win 64 esegue anche 32 ma lascia stare il 16 bit
così accadrà che win 128 bit potrà eseguire 64 bit ma non 32 o 16.

credo sia chiaro a tutti che si palesa già l'arrivo di win 128 per il 2015 ma stabile per il 2020 quindi parecchio tempo.

il wow non comporta perdita di prestazioni per le rispettive applicazioni?

n

credo sia chiaro a tutti che si palesa già l'arrivo di win 128 per il 2015 ma stabile per il 2020 quindi parecchio tempo.

guarda che nessn sistema operativo di nessuna marca ha nessn progetto nemmeno a lungo termina di avere una versione a 128bit per imotivi che ti citavo prima e inutile proprio concettualmente. Un sistema a 64bit puo indirizzare 16 exbibyte, quando questo valore diventera un limite fra un centinaio di anni o piu magari allora avrà senso pensare a un sostituto. Non confondere indirizzamento di memoria con dimensione dii registri per esempio della FPU non sono legati tu puoi avere una cpu a 32bit con sistema operativo a 32bit che magari ha una FPU da 128/256/512/1024bit ecc e le 2 cose non sono legate.

il wow non comporta perdita di prestazioni per le rispettive applicazioni?

no, anzi puoi avere anche un miglioramento grazie al kernel a 64bit

guarda che nessn sistema operativo di nessuna marca ha nessn progetto nemmeno a lungo termina di avere una versione a 128bit per imotivi che ti citavo prima e inutile proprio concettualmente. Un sistema a 64bit puo indirizzare 16 exbibyte, quando questo valore diventera un limite fra un centinaio di anni o piu magari allora avrà senso pensare a un sostituto. Non confondere indirizzamento di memoria con dimensione dii registri per esempio della FPU non sono legati tu puoi avere una cpu a 32bit con sistema operativo a 32bit che magari ha una FPU da 128/256/512/1024bit ecc e le 2 cose non sono legate.

beh io di architettura non ho fatto molto e sono rimasto alla base hobbystica della cosa ma ora mi chiedo:

questa notizia è quindi falsa?
windows-9-arriva-nel-2015-con-la-versione-a-128-bit-e-interfaccia-3d/ (http://vistablog.it/windows-9-arriva-nel-2015-con-la-versione-a-128-bit-e-interfaccia-3d/)

il wow non comporta perdita di prestazioni per le rispettive applicazioni?

no, anzi puoi avere anche un miglioramento grazie al kernel a 64bit

il sistema WOW accoppia 2 istruzioni 32bit per generarne una intera a 64Bit (però non ho fonti certe su questo fatto)

se così fosse la cosa dovrebbe pertanto velocizzare l'applicazione.

Fai conto che uscire a 350-400 euro al giorno per una figura senior è un prezzo medio, diciamo medio-basso (c'è chi non scende sotto 600-700 euro eh...) e le gare ora sono al ribasso e partono da 160 euro al giorno. :asd:

160 euro al giorno significa 20 euro all'ora.
Mi hanno appena quotato 38 euro all'ora un operaio metalmeccanico in trasferta.
Con 20 euro all'ora puoi offrire solo - con rispetto parlando- un muratore. Muratore non specializzato, fra l'altro.

160 euro al giorno significa 20 euro all'ora.
Mi hanno appena quotato 38 euro all'ora un operaio metalmeccanico in trasferta.
Con 20 euro all'ora puoi offrire solo - con rispetto parlando- un muratore. Muratore non specializzato, fra l'altro.Esattamente, queste gare invece prevedono personale senior per figure tecniche estremamente specializzate (analisti, sviluppatori, sistemisti per servizi enterprise di nicchia, che lavoreranno su architetture che tra hardware e software richiederanno qualche milione di euro e con un bacino d'utenza di milioni di persone, non smanettoni html a tempo perso). 160 euro poi come cifra massima, ma la gara è al ribasso :(

Poi tieni presente un dettaglio tutt'altro che trascurabile, le società che vinceranno questa gara i soldi li riscuoteranno se va bene a distanza di mesi, più realisticamente a distanza di un paio di anni a causa dei tempi geologici della PA nel pagare i propri fornitori, delle scatole cinesi di subappalti necessari per partecipare alle gare e per una serie di altre lungaggini burocratiche.
Tu trovami un settore dove i pagamenti sono gestiti in questo modo, di solito se il cliente è affidabile o consolidato ci si fa pagare a 30, 60 o 90gg, dai facciamo anche a 120 gg... ma 2 anni? :rolleyes:
Capisci bene che certe cifre (scommetto che sentendo parlare di 700 euro a giornata/uomo ci sarà stato qualcuno che avrà pensato scandalizzato ai soliti consulenti sanguisughe...) sono influenzate anche da questo, viste le premesse anche 350-400 euro a giornata non sono poi questa grande cifra, figurati 160. :mad:

beh io di architettura non ho fatto molto e sono rimasto alla base hobbystica della cosa ma ora mi chiedo:

questa notizia è quindi falsa?
windows-9-arriva-nel-2015-con-la-versione-a-128-bit-e-interfaccia-3d/ (http://vistablog.it/windows-9-arriva-nel-2015-con-la-versione-a-128-bit-e-interfaccia-3d/)

Mi sa che chi ha scritto quell'articolo aveva le idee un pochino confuse.
Prima parla di S.O. a 128bit e di cpu di quel tipo rilasciate nel 2013, poi
parla di nuovamente di tali cpu dando come caratteristiche supporto di DDR4 e di ... SSE5, quando invece le estensioni successive ad SSE4 sono le AVX e le prossime estensioni si chiameranno AVX2 e compariranno nelle cpu Haswell che guardacaso escono nel 2013.
Le AVX (ed AVX2) usano registri YMMn a 256bit che sono estensioni degli XMMn a 128bit delle SSE, ma l'indirizzamento delle cpu x86 che supportano AVX resta sempre a 64bit.

Mi sa che chi ha scritto quell'articolo aveva le idee un pochino confuse.
Prima parla di S.O. a 128bit e di cpu di quel tipo rilasciate nel 2013, poi
parla di nuovamente di tali cpu dando come caratteristiche supporto di DDR4 e di ... SSE5, quando invece le estensioni successive ad SSE4 sono le AVX e le prossime estensioni si chiameranno AVX2 e compariranno nelle cpu Haswell che guardacaso escono nel 2013.
Le AVX (ed AVX2) usano registri YMMn a 256bit che sono estensioni degli XMMn a 128bit delle SSE, ma l'indirizzamento delle cpu x86 che supportano AVX resta sempre a 64bit.

vedi che queste info sono utili? adesso abbiamo sfatato il mito dell' OS da 128 bit (che a dire il vero anche io non capivo a cosa potesse servire...)

speriamo che anche altri leggano fin qui i post ;)

in cosa prevalgono praticamente i sistemi a 64 bit rispetto a quelli a 32?

Il futuro è a 64 bit ma il presente è assolutamente a 32 bit, sospendere il supporto ai SO a 32 bit è un suicidio.
C'è un mondo fatto di Windows XP aziendali fuori da questo forum.
Si, perchè tu pensi che sui pc aziendali, passa un tecnico ad aggiornare Firefox & Co. ogni volta che esce una versione nuova?

Quelli si tengono le vecchie versioni dei programmi finchè non gli muore il pc. Ci sono dei posti che viaggiano ancora con Windows 98.

Mi pare sia stata anche la scelta di Chrome, però creando un processo distinto per ogni tab (2GB per pagina sono ancora difficili da raggiungere).
Secondo me è stata una scelta pragmatica dettata dalle difficoltà nel debug del codice a 64 bit, optando naturalmente per il forking per ciascun nuovo tab.

in cosa prevalgono praticamente i sistemi a 64 bit rispetto a quelli a 32?

In primo luogo la quantità di memoria indirizzabile.
Un S.O. a 64bit anche se fa girare solo applicazioni a 32bit può sfruttare più di 4GB di ram per il caching dei dati o per permettere a più applicazioni che usano 1..2GB di ram ognuna di girare completamente in ram anche se complessivamente superano i 4GB.
Con applicazioni tipo Office o IE/Firefox non si notano grandi vantaggi, ma se si fa editing di video, fotoritocco a qualità di stampa di roba grossa e cose simili la differenza può essere notevole.

Poi il set d'istruzioni a 64bit (per quel che riguarda gli x86) fornisce 16 registri interi a 64bit invece degli 8 accessibili in modalità a 32bit, inoltre è garantita la presenza di 16 (invece di 8 come in modalità 32bit) registri XMM a 128bit di SSE/SSE2.
Questo torna molto utile per aumentare di fino al 30% l'efficenza del codice assembly a partire dagli stessi sorgenti in C/C++ o compilati Jit da sorgenti Java o di linguaggi .Net

Poi il set d'istruzioni a 64bit (per quel che riguarda gli x86) fornisce 16 registri interi a 64bit invece degli 8 accessibili in modalità a 32bit, inoltre è garantita la presenza di 16 (invece di 8 come in modalità 32bit) registri XMM a 128bit di SSE/SSE2.
Questo torna molto utile per aumentare di fino al 30% l'efficenza del codice assembly a partire dagli stessi sorgenti in C/C++ o compilati Jit da sorgenti Java o di linguaggi .Net


questo pero a livello teorico perche a livello pratico grazie alla OoO del processore e la funzione di rinomina dei registri fa si che alla fine i registri realmente diponibili per contenere i dati siano molti di piu e il vantaggio di prestazioni si ha solo per certi tipi di elaborazioni. Inolte il codice a 64bit occupa piu spazio fisico sia come sorgente che come ram occupata e banda verso la cache quindi per certe tipi di elaborazioni si ottiene anche un risultato peggiore dello stesso codice a 32bit. L'unico caso dove i vantaggi sono evidenti sono qundo si usano le unita mmx sse ecc per il resto si ha un susseguirsi di pareggi vittorie e sconfitte in base al codice utilizzato.

Molto dipende anche dalla ram del sistema se guardi benchmark con un pc da 2GB vedi che perde quasi nella totalita dei casi quando usa un SO a 64bit mentre solo da 4GB in su a parità di hardware e software la situazione si ribalta.

quindi un sistema completamente a 64 bit dovrebbe risultare più performante.

qui mi sembra più un'abbandono per motivi "tecnici".
Dato che l'unica versione a 64 bit a venire "eliminata" è quella per Windows penso che ci sia un motivo serio dietro.
Le altre versioni (per Linux e MacOS) sono tutte a 64 bit.


Ci scommetto le palle da flipper che adesso è colpa di Microsoft. :rolleyes:

questo pero a livello teorico perche a livello pratico grazie alla OoO del processore e la funzione di rinomina dei registri fa si che alla fine i registri realmente diponibili per contenere i dati siano molti di piu e il vantaggio di prestazioni si ha solo per certi tipi di elaborazioni. Inolte il codice a 64bit occupa piu spazio fisico sia come sorgente che come ram occupata e banda verso la cache quindi per certe tipi di elaborazioni si ottiene anche un risultato peggiore dello stesso codice a 32bit. L'unico caso dove i vantaggi sono evidenti sono qundo si usano le unita mmx sse ecc per il resto si ha un susseguirsi di pareggi vittorie e sconfitte in base al codice utilizzato.

Per questo ho parlato di un miglioramento sino al 30% (che non è poco, ma che è il miglioramento medio più elevato che si riscontra in pratica).

Come avevo scritto prima, in modalità a 64bit le SSE e le SSE2 sono disponibili "di serie", ma anche il raddoppio dei registri indirizzabili direttamente è significativo, solo che non lo è tanto se si fa il confronto con x86 + SSE2.

Anche con esecuzione out-of-order passare da 8 a 16 registri permette di migliorare le prestazioni perchè si possono compiere ottimizzazioni più sofisticate rispetto a quelle più limitate che si ottengono solo con lo scheduler OoO e con il renaming.

Dati alla mano, lo "sweet spot" per le architetture a registri di uso generale è di 16..32 registri (con meno registri le prestazioni degradano, con più registri non ci sono vantaggi significativi causa maggior numero di registri non utilizzati con sufficiente frequenza).

La differenza nel passare da 8 a 16 registri quindi in linea generale si sente, solo che negli x86 se si fa il confronto con x86 + SSE2 (8 registri interi di uso generale ed 8 registri XMM a 128bit) si è già "quasi" nel caso a 16 registri (8+8) mentre con x86-64 si è "certamente" nel caso a 16 registri (16 registri interi a 64bit oppure 16 registri XMM a 128bit) e "quasi" nel caso a 32 registri (16 + 16).
Visto che il caso ottimale è tra 16..32 registri, se si fa il confronto con x86 + SSE2 non c'è il gran salto che ci si potrebbe aspettare.

Ci scommetto le palle da flipper che adesso è colpa di Microsoft. :rolleyes:

Ti piace vincere facile, eh? ;)
Comunque una volta tanto le ragioni sono solo tecniche e dettate più dalle risorse limitate di Mozilla che da colpe di Microsoft.

beh io di architettura non ho fatto molto e sono rimasto alla base hobbystica della cosa ma ora mi chiedo:

questa notizia è quindi falsa?
windows-9-arriva-nel-2015-con-la-versione-a-128-bit-e-interfaccia-3d/ (http://vistablog.it/windows-9-arriva-nel-2015-con-la-versione-a-128-bit-e-interfaccia-3d/)

Chi ha scritto sto articolo? :asd:

Un S.O. a 64bit anche se fa girare solo applicazioni a 32bit può sfruttare più di 4GB di ram per il caching dei dati o per permettere a più applicazioni che usano 1..2GB di ram ognuna di girare completamente in ram anche se complessivamente superano i 4GB.

questo è il motivo per cui si migra ai 64 in qualsiasi ambito...io uso xp64 da 6/7 anni e i primi anni ero obbligato ad usarlo e sorbirmi i suoi problemi (senza SP era peggio di windows ME)....

le applicazioni a 32 bit su sistemi a 32 bit possono allocare massimo 3.2 gb (circa) di ram per processo...quelle stesse applicazioni a 32 su un sistema a 64 bit non hanno limite teorico di ram allocabile....e 6/7 anni fa alcuni software di calcolo che utilizzavo non avevano una versione a 64 bit...

ormai i 64 sono una costante (ho forse solo 3/4 macchine su una cinquantina a 32 bit solo perchè ad uso office)...

bio

Sono due anni che oramai uso waterfox, e fino ad ora non ho trovato broswer migliore....
Quindi se tagliano il supporto a firefox x64.... :ciapet:

questo è il motivo per cui si migra ai 64 in qualsiasi ambito...io uso xp64 da 6/7 anni e i primi anni ero obbligato ad usarlo e sorbirmi i suoi problemi (senza SP era peggio di windows ME)....

le applicazioni a 32 bit su sistemi a 32 bit possono allocare massimo 3.2 gb (circa) di ram per processo...quelle stesse applicazioni a 32 su un sistema a 64 bit non hanno limite teorico di ram allocabile....e 6/7 anni fa alcuni software di calcolo che utilizzavo non avevano una versione a 64 bit...Quoto Veradun, per un maggiore dettaglio invito a consultare questa pagina di msdn (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx).

Dire poi che i sistemi x64 non hanno limite teorico poi è falso, di limiti ce ne sono eccome, ora ci sembrano astronomici ricordiamoci però che era lo stesso negli anni '60 e '70 per i limiti imposti dalle architetture a 32bit.

Attenzione poi a un dettaglio tutt'altro che insignificante, un conto sono i limiti architetturali, un conto sono i limiti imposti dai produttori dell'OS o di uno specifico prodotto nell'uso delle risorse.
Come puoi vedere dalla pagina che ho linkato le soglie di occupazione ram per i sistemi operativi MS sono infinitamente più basse rispetto a quanto permetterebbe l'architettura x64, e non c'è "smanettamento" del registro che possa sbloccare tutto questo.

ormai i 64 sono una costante (ho forse solo 3/4 macchine su una cinquantina a 32 bit solo perchè ad uso office)...
Non sono così d'accordo, sistemi a 32bit sono ancora molto diffusi, e non solo per un retaggio del passato.
Questo è vero non solo un ambito client ma anche server, il mio lavoro mi permette di mettere il naso in molti ced di tantissime aziende ed enti pubblici (dall'ente in cui sto lavorano ora ho a perimetro 124 sistemi e una ventina di dispositivi tra san, bladecenter, switch fc e altre quisquilie) e ti posso assicurare che i 32bit sono ben lungi dall'essere abbandonati.
Anzi in molte condizioni sono più vantaggiose architetture distribuite a 32bit piuttosto che far girare il tutto a 64bit, il tutto senza considerare le implicazioni lato sviluppo e test, impensabili anche solo da pensare, specialmente in un momento storico come questo :O

anche i chipset delle motherboard passate rappresentano un limite.