Mozilla Firefox Quantum è ufficiale. Ecco cosa cambia

[insane74]

Originariamente inviato da Nicodemo Timoteo Taddeo

Uso da una vita e mezzo Xmarks e non ho mai avuto eccessivi problemi, neanche a sincronizzare tra browser diversi. Con Firefox sempre tranquillo.

https://www.xmarks.com/

L'estensione per Firefox è stata aggiornata recentemente e va senza problemi sulla 57:
https://addons.mozilla.org/it/firefo...n/xmarks-sync/


Recentemente ho provato a farne a meno affidandomi a Sync, ma non c'è storia.

La comodità di Xmarks è che si può andare anche a fare il login sul sito per utilizzare i segnalibri anche dal web, non serve necessariamente l'estensione installata, nel caso ci si trovi ad operare su computer o dispositivi non tuoi.

La scomodità per così dire è che si danno i propri bookmarks ad un terzo, ma insomma, li diamo a Google, Apple o Microsoft...

Lo usavo anch’io secoli fa, ma se non sbaglio c’è solo per desktop. Come li sincronizzo i preferiti con la versione mobile di FF (per iPad e telefono Android)?

Originariamente inviato da Erotavlas_turbo

Sembra che sia ancora presente per alcuni utenti un bug di circa 4 anni fa fonte
Per adesso meglio usare xmarks.

Sono il solito fortunato!!!

[cdimauro]

Originariamente inviato da El Tazar

Strano, avrai già provato ma dalla guida google


Inoltre molte volte è l'app che gestisce i contatti che fa casino (non so che telefonao hai quindi non è detto sia il tuo caso)

Originariamente inviato da gioloi

Questo è davvero strano.
A me è sempre andato liscio con i telefoni che ho avuto finora, ossia:
- Samsung S3
- Doogee X5
- Xiaomi Note 4X
Non solo i contatti, che se modifico da PC mi si aggiornano su telefono nel giro di pochi secondi, ma anche altre applicazioni della suite come Keep e Calendar. E non solo tra PC e smartphone (e viceversa), ma anche tra i vari smartphone dei contatti eventualmente invitati. Io e mia moglie condividiamo alcune liste di Keep e un calendario per appuntamenti e funziona sempre tutto bene. Se uno fa una modifica, l'altro la vede immediatamente sul suo telefono.
Tenderei a escludere Google dalla lista dei sospettati e, piuttosto, guarderei la gestione contatti e le impostazioni di sincronizzazione del tuo dispositivo.

Non ho controllato la guida, e non ho fatto nient'altro che collegare il mio account Google e poi sincronizzare i contatti.

Diciamo che, da utente, mi aspett(av)o che effettuando l'operazione la prima volta avrebbe poi dovuto automaticamente e trasparentemente sincronizzare il tutto.

Questo fine settimana controllo le impostazioni e/o la guida, come avete suggerito. Grazie.

[cdimauro]

Originariamente inviato da Erotavlas_turbo

Sembra che sia ancora presente per alcuni utenti un bug di circa 4 anni fa fonte

E ancora non risolto.

Per adesso meglio usare xmarks.

Io uso davdroid con cloud privato basato su nextcloud (gratis 1 GB sufficiente per calendario e contatti) e tutto funziona alla perfezione oltre al fatto che i dati sono nelle mie mani

Quando avrò un po' di tempo proverò Firefox e queste estensioni. Però sai qual è il casino per me? Dover perdere tempo a trovare soluzioni e/o estensioni per funzionalità che ritengo debbano essere già integrate in un browser moderno.

Originariamente inviato da insane74

Lo usavo anch’io secoli fa, ma se non sbaglio c’è solo per desktop. Come li sincronizzo i preferiti con la versione mobile di FF (per iPad e telefono Android)?

Infatti la sincronizzazione deve funzionare ovunque. Ormai molti abbiamo anche dispositivi mobile.

Sono il solito fortunato!!!

Originariamente inviato da fano

Rust & Firefox Quantum:

https://blog.rust-lang.org/2017/11/1...x-Quantum.html

in particolare:

che bello vedere sparire finalmente il C++ totalmente unsafe e ottenere il 30% di performance in più!

Sì, vero, però potevano anche dargli una sintassi migliore (e più leggibile) a Rust. Avevano l'occasione di realizzare un linguaggio sia "safe" sia leggibile e più facilmente manutenibile, e invece si sono impelagati nella solita accozzaglia di simboli e keyword allucinanti pur di farle corte, come se non bastassero già C & derivati.

[Nicodemo Timoteo Taddeo]

Originariamente inviato da insane74

Lo usavo anch’io secoli fa, ma se non sbaglio c’è solo per desktop. Come li sincronizzo i preferiti con la versione mobile di FF (per iPad e telefono Android)?

Con l'account premium, a pagamento

[insane74]

Originariamente inviato da Nicodemo Timoteo Taddeo

Con l'account premium, a pagamento

Beh... rimango con Chrome allora!
Magari tra un lustro avranno risolto questo problema di sync (se FF esisterà ancora... visto l’assottigliarsi delle sue “quote” non è così scontato) e tornerò a provarlo.

[fano]

Originariamente inviato da cdimauro

Sì, vero, però potevano anche dargli una sintassi migliore (e più leggibile) a Rust. Avevano l'occasione di realizzare un linguaggio sia "safe" sia leggibile e più facilmente manutenibile, e invece si sono impelagati nella solita accozzaglia di simboli e keyword allucinanti pur di farle corte, come se non bastassero già C & derivati.

Su questo concordo assolutamente ed apprezzo infatti la sintassi di C# in cui hanno evitato '&' e preferito il più chiaro 'ref'... infatti devo dire che non mi ci troverei a scrivere codice con Rust sinceramente preferisco il C a quel punto! Ma può pure essere che sia questione di abitudine...

La scelta è coraggiosa e va apprezzata comunque e come dice Erotavlas_turbo tra poco anche il Web Render sarà sostituito con uno scritto in codice safe e pure il 400% più veloce!

Mi chiedo quanto codice di Netscape Navigator e addirittura Mosaic stiano finalmente alla versione 57 cancellando!

[fano]

... e se il nostro OS basato su C# va in porto e se Microsoft riesce a finire CoreRT (Net Native open source) anche il piccolo gap di performance che avrebbe rispetto a C / Rust sparirebbe e finalmente si potrebbe usare un linguaggio con sintassi:

• Sintassi decente
• Feauture Rich
• Safe by design

anche per software Real Time.

[Erotavlas_turbo]

Originariamente inviato da cdimauro

E ancora non risolto.

Quando avrò un po' di tempo proverò Firefox e queste estensioni. Però sai qual è il casino per me? Dover perdere tempo a trovare soluzioni e/o estensioni per funzionalità che ritengo debbano essere già integrate in un browser moderno.

Ok per la sincronizzazione, ma al momento il bug riguarda solo un numero limitato di utenti.

Davdroid e nextcloud servono per evitare di usare google per la gestione di contatti e calendario, mozilla qui non ha nulla a che fare.

Originariamente inviato da fano

... e se il nostro OS basato su C# va in porto e se Microsoft riesce a finire CoreRT (Net Native open source) anche il piccolo gap di performance che avrebbe rispetto a C / Rust sparirebbe e finalmente si potrebbe usare un linguaggio con sintassi:

• Sintassi decente
• Feauture Rich
• Safe by design

anche per software Real Time.

Vorresti dire che C# avrà le stesse prestazioni di C/C++ o Rust? Nonostante la macchina virtuale CLR? Ne dubito sopratutto in presenza di I/O massicci e di elevato parallelismo dato che una macchina virtuale non consente un parallelismo a livello fisico.
Hai qualche fonte?

[cdimauro]

Originariamente inviato da fano

Su questo concordo assolutamente ed apprezzo infatti la sintassi di C# in cui hanno evitato '&' e preferito il più chiaro 'ref'... infatti devo dire che non mi ci troverei a scrivere codice con Rust sinceramente preferisco il C a quel punto! Ma può pure essere che sia questione di abitudine...

Lo è sicuramente.

La scelta è coraggiosa e va apprezzata comunque e come dice Erotavlas_turbo tra poco anche il Web Render sarà sostituito con uno scritto in codice safe e pure il 400% più veloce!

Non credo che quel 400% più veloce arrivi dalla sola adozione di Rust. Molto probabilmente la riscrittura in Rust ha portato a un cambiamento (radicale) dell'engine, ma è una cosa che si sarebbe potuta fare anche con altri linguaggi.

Mi chiedo quanto codice di Netscape Navigator e addirittura Mosaic stiano finalmente alla versione 57 cancellando!

Non penso ne sia rimasto tanto ormai.

Originariamente inviato da emiliano84

quoto, da quando sono passato a vs e c# ... non tornerei mai piu' indietro

Fra i linguaggi C moderni, C# è il mio preferito. Ma per roba a basso livello uso ancora il C, oppure (SE sono costretto) C++.

Originariamente inviato da fano

... e se il nostro OS basato su C# va in porto e se Microsoft riesce a finire CoreRT (Net Native open source) anche il piccolo gap di performance che avrebbe rispetto a C / Rust sparirebbe e finalmente si potrebbe usare un linguaggio con sintassi:

• Sintassi decente
• Feauture Rich
• Safe by design

anche per software Real Time.

Sarebbe possibile, compilando AoT.

Originariamente inviato da Erotavlas_turbo

Ok per la sincronizzazione, ma al momento il bug riguarda solo un numero limitato di utenti.

Davdroid e nextcloud servono per evitare di usare google per la gestione di contatti e calendario, mozilla qui non ha nulla a che fare.

Sì, chiaro. Per me la scocciatura è dovermi sbattere a cercare estensioni e/o servizi esterni.

Vorrei avere tutto già pronto al primo avvio del browser, oppure magari con un wizard in cui velocemente scegliere ciò che mi serve.

Vorresti dire che C# avrà le stesse prestazioni di C/C++ o Rust? Nonostante la macchina virtuale CLR? Ne dubito sopratutto in presenza di I/O massicci e di elevato parallelismo dato che una macchina virtuale non consente un parallelismo a livello fisico.
Hai qualche fonte?

Con .NET (quindi non solo C#) puoi anche compilare AoT, e quindi senza VM dietro.

[Erotavlas_turbo]

Originariamente inviato da cdimauro

Non credo che quel 400% più veloce arrivi dalla sola adozione di Rust. Molto probabilmente la riscrittura in Rust ha portato a un cambiamento (radicale) dell'engine, ma è una cosa che si sarebbe potuta fare anche con altri linguaggi.

Certo che no, arriva dallo spostamento del rendering da CPU a GPU reso possibile soprattutto grazie a Rust fonte.

Originariamente inviato da cdimauro

Con .NET (quindi non solo C#) puoi anche compilare AoT, e quindi senza VM dietro.

Si certo, migliora rispetto a linguaggi semi compilati (JIT) con virtual machine, ma non raggiunge i livelli di linguaggi compilativi "nativi".
Con C# e Java, python, non può avere le stesse prestazioni di un linguaggio più a "basso livello" come C++/C o Rust dove puoi gestire direttamente la memoria, gestire la vettorizzazione del codice e usare le funzioni intrinsic.
Tutto dipende da cosa tu debba fare con il tuo codice. Se cerchi le prestazioni non vedo altre scelte fuori da C++/C o Rust.
Per esempio, con l'arrivo di webAssembly aperto e supportato da tutti i browser, molto meglio usare codice C++/C o Rust e compilarlo per webAssembly anziché usare Java o .Net (proprietario) con le relative VM fonte.
Se secondo te non è cosi, riportami una review con la comparativa delle prestazioni.

[Trotto@81]

Originariamente inviato da Erotavlas_turbo

Certo che no, arriva dallo spostamento del rendering da CPU a GPU reso possibile soprattutto grazie a Rust fonte.

Il rendering tramite GPU non penso sia ancora attivo, perché il carico sulla VGA non aumenta in fase di rendering, aiuta solo nella riproduzione dei video.

[Erotavlas_turbo]

Originariamente inviato da Trotto@81

Il rendering tramite GPU non penso sia ancora attivo, perché il carico sulla VGA non aumenta in fase di rendering, aiuta solo nella riproduzione dei video.

Infatti non lo è, mai detto che lo fosse. E' in arrivo nei primi mesi del 2018 e permetterà a firefox di gestire fino a 4k fonte.

[Trotto@81]

L'importante è che arrivi quanto prima, con l'hardware degli attuali PC è un peccato usare solo la CPU per renderizzare le pagine. Grazie per l'articolo, lo sto leggendo ed è davvero interessante, oltre che semplice nella spiegazione.

[amd-novello]

questa cosa dello sfruttamento della gpu vale anche per le integrate un po' vecchiotte?

[Trotto@81]

L'articolo che mi hanno indicato lo dice chiaramente all'inizio, WebRender non renderà Firefox più veloce, ma più fluido.

[Erotavlas_turbo]

Originariamente inviato da amd-novello

questa cosa dello sfruttamento della gpu vale anche per le integrate un po' vecchiotte?

Non ho trovato dettagli in merito. Se su firefox scrivi about:support sulla barra di ricerca e scorri fino a Decision Log vedi cosa è attualmente abilitato.

Originariamente inviato da Trotto@81

L'articolo che mi hanno indicato lo dice chiaramente all'inizio, WebRender non renderà Firefox più veloce, ma più fluido.

Guarda tu stesso questo bechmark fonte.
Non so quale sia la tua definizione di fluido e veloce. Il numero di frame al secondo in un video li considero come velocità anche se tecnicamente sono una frequenza.
Con firefox con quantum webrender (servo) è 400% più fluido/veloce di chromium e 667% più fluido/veloce di firefox developer edition.

[Trotto@81]

L'estratto è questo <<WebRender is known for being extremely fast. But WebRender isn’t really about making rendering faster. It’s about making it smoother.>> ovvero "WebRender è noto per essere estremante veloce, ma non si occuperà di rendere più veloce il rendering della pagina".
Il filmato esplicativo riguarda la visualizzazione di un contenuto opengl, che è cosa ben diversa da renderizzare una normale pagina web.
Da quello che ho capito WebRender disegnerà la pagina, ma non si occuperà del rendering. Avremo una visualizzazione più snella e fluida, ma il tempo di elaborazione del contenuto non cambierà.
Quando lo avremo sotto mano vedremo quali saranno i reali benefici. Come scritto nell'articolo una GPU nasce per disegnare i pixel e verrà utilizzata per questo, sgravando la CPU da questo compito a lei poco congeniale, rendendola utilizzabile per altri lavori.
Sono anni che controllo su diversi OS se in "about:support" il WebRender è attivo e non vedo l'ora di provarlo.

[Erotavlas_turbo]

Originariamente inviato da Trotto@81

L'estratto è questo <<WebRender is known for being extremely fast. But WebRender isn’t really about making rendering faster. It’s about making it smoother.>> ovvero "WebRender è noto per essere estremante veloce, ma non si occuperà di rendere più veloce il rendering della pagina".
Il filmato esplicativo riguarda la visualizzazione di un contenuto opengl, che è cosa ben diversa da renderizzare una normale pagina web.
Da quello che ho capito WebRender disegnerà la pagina, ma non si occuperà del rendering. Avremo una visualizzazione più snella e fluida, ma il tempo di elaborazione del contenuto non cambierà.

Se avessi riportato almeno tutto il paragrafo della citazione:

WebRender is known for being extremely fast. But WebRender isn’t really about making rendering faster. It’s about making it smoother.

With WebRender, we want apps to run at a silky smooth 60 frames per second (FPS) or better no matter how big the display is or how much of the page is changing from frame to frame. And it works. Pages that chug along at 15 FPS in Chrome or today’s Firefox run at 60 FPS with WebRender.

So how does WebRender do that? It fundamentally changes the way the rendering engine works to make it more like a 3D game engine.

Originariamente inviato da Trotto@81

Quando lo avremo sotto mano vedremo quali saranno i reali benefici. Come scritto nell'articolo una GPU nasce per disegnare i pixel e verrà utilizzata per questo, sgravando la CPU da questo compito a lei poco congeniale, rendendola utilizzabile per altri lavori.
Sono anni che controllo su diversi OS se in "about:support" il WebRender è attivo e non vedo l'ora di provarlo.

Certo, primi mesi del 2018.

[Trotto@81]

Parla di applicazioni e di fps, non ti tempi di caricamento di una pagina. Avrai lo scrolling a 60 fps, ma il tempo che impiegherà il browser a visualizzare la pagina non varierà.

[Erotavlas_turbo]

Originariamente inviato da Trotto@81

Parla di applicazioni e di fps, non ti tempi di caricamento di una pagina. Avrai lo scrolling a 60 fps, ma il tempo che impiegherà il browser a visualizzare la pagina non varierà.

Certo, dove ho scritto caricamento di una pagina o avvio più veloce?!
Ho scritto solo che la velocità di firefox, nel rendering, sarà superiore del 400% a quella di chrome.
Con questa funzionalità, webVR e webAssembly, molti giochi pesanti verranno spostati sul web con la maggioranza dell'elaborazione in cloud.