Opera Developer 40 : lecteur RSS, Chromecast et version 64 bits pour Windows

Opera Developer 40 : lecteur RSS, Chromecast et version 64 bits pour Windows

Une version expérimentale d'une Developer c'est stable ?

Avatar de l'auteur
Sébastien Gavois

Publié dans

Logiciel

21/07/2016 3 minutes
20

Opera Developer 40 : lecteur RSS, Chromecast et version 64 bits pour Windows

La version Developer 40.0.2296.0 d'Opera est en ligne et propose plusieurs nouveautés : un lecteur RSS personnalisable, la prise en charge de Chromecast et une version expérimentale pour Windows en 64 bits.

Alors que le rachat d'Opera vient de capoter pour des raisons réglementaires (voir cette actualité), la société pourrait finalement revendre son navigateur (et de certaines licences) pour 600 millions de dollars. En attendant, elle vient d'annoncer une mise à jour de celui-ci, dans la branche Developer. Estampillée 40.0.2296.0 (basée sur Chromium 53.0.2782.2), elle apporte des nouveautés intéressantes.

Un lecteur de flux RSS personnalisable, avec des limitations

La première concerne l'arrivée d'un lecteur RSS. Opera annonce sans détour que « cette fonctionnalité est très limitée pour le moment », mais elle a au moins le mérite d'exister ce qui n'est par exemple pas le cas par défaut sur Chrome. Pour en profiter, il faut cliquer sur l'icône Actualités du menu de gauche, puis sur Ajouter des sources.

En plus des sites préenregistrés, vous pouvez ajouter un flux RSS de votre choix (http://www.nextinpact.com/rss/news.xml par exemple). Néanmoins, le temps de lecture estimé n'est pas disponible pour les sites ajoutés manuellement précise l'éditeur.

Opera RSSOpera RSS

Plusieurs limitations sont pour le moment de la partie. Tout d'abord, il n'existe pas (encore) de bouton permettant de supprimer simplement un flux ajouté manuellement. Une solution de contournement existe néanmoins : refaire la manipulation pour ajouter ce flux, puis cliquer sur la coche qui s'affiche (voir capture de gauche ci-dessus).

De plus, l'URL est affichée à la place du titre de l'actualité pour les flux RSS maison. Il s'agit dans tous les cas d'une version Developer d'Opera et l'équipe a donc le temps de peaufiner cette fonctionnalité avant qu'elle ne soit proposée plus largement.

Prise en charge de Chromecast et version 64 bits expérimentale pour Windows

Autre changement de taille : la prise en charge de Chromecast. Opera explique que « lorsque vous installez l'extension Google Cast à partir du magasin d'applications, que vous avez une clé Chromecast branchée sur votre écran et connectée au même réseau Wi-Fi, elle doit être détectée et les liens d'envoi devraient fonctionner ».

Enfin, cette mouture d'Opera Developer est disponible de manière expérimentale en version 64 bits pour Windows, en plus de la version 32 bits. Comme toujours, elle est également proposée pour Mac et Linux (32/64 bits). Pour la télécharger, il suffit de cliquer sur l'un des liens ci-dessous :

 

20

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Un lecteur de flux RSS personnalisable, avec des limitations

Prise en charge de Chromecast et version 64 bits expérimentale pour Windows

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (20)


Cool j’espère qu’il va arriver vite le stable x64.


Dire qu’on est en 2016 et que le 64 bits reste toujours un truc en bêta/on-est-pas-trop-sur sur un paquet de softs…. :/



Et certains se moquaient quand une certaine boite faisait le forcing 64 bits bien avant que ce soit réellement nécessaire, si ça évite de revivre le phénomène…


Ça doit faire 5 ans que le x86 est vraiment dépassé, faudrait peut-être qu’ils réagissent au bout d’un moment..








Nb5 a écrit :



Ça doit faire 5 ans que le x86 est vraiment dépassé, faudrait peut-être qu’ils réagissent au bout d’un moment..





Y’a pas que Opera de concerné, après les nouveautés sont vraiment la bienvenue ! Ca se bouge plus que chez la concurrence en ce moment, bien content d’être sur Opera, par contre le rachat Chinois … 









Nb5 a écrit :



Ça doit faire 5 ans que le x86 est vraiment dépassé, faudrait peut-être qu’ils réagissent au bout d’un moment..





la différence entre un navigateur 32 bits et le même en 64 bits?



Allocation ram non ?


Programmes plus rapides (plus de registres, et plus larges), plus de mémoire disponible (surtout avec Chrome/Firefox qui pompent pas mal, c’est utile). Aussi sur Windows x64, le 32-bit n’est qu’émulé avec WoW64.. Et puis on est en 2016, faut se mettre à jour.


Oui tu vas pouvoir allouer plus de RAM et gérer donc plus d’onglet avec du flash ou autre.

Mais ça c’est la théorie, en pratique le soft va être plus lent car tous le code n’a pas besoin d’être en 64 bits (ex: un compteur du nombre d’onglets se contentera très bien du 32 bits. De plus, un process peut se forker par onglet et là encore, à moins d’utiliser 4G de RAM pour afficher une page web, il ne devrait pas y avoir de soucis.

 

Donc contrairement à ce qui a été dit au dessus, la plupart des développeurs compétents ne recommandent pas nécessairement le 64 bits pour toutes les applications (cf Visual Studio dernièrement), le 64 bits est surtout intéressant pour les systèmes. Donc à moins de réécrire ou de revalider plusieurs milliers de lignes de code pour passer seulement ce qu’il faut en 64 bits, le 32 bits restera toujours moins risquer et marchera très bien.


Enfin tout passer en 64 bits pour ceux qui ont encore un ordinateur 32 bits c’est moyen. Et maintenir 2 versions en parallèle demande plus d’effort. Si les équipes de dev peuvent le faire, on ne crache pas dessus, mais ce n’est pas nécessaire actuellement.




…que vous avez une clé Chromecast branchée sur votre écran , … les liens d’envoi devraient fonctionner



Devraient ? C’est “au petit bonheur la chance” ou bien ?








Vipear a écrit :



Y’a pas que Opera de concerné, après les nouveautés sont vraiment la bienvenue ! Ca se bouge plus que chez la concurrence en ce moment, bien content d’être sur Opera, par contre le rachat Chinois … 





+1









Kriska a écrit :



Oui tu vas pouvoir allouer plus de RAM et gérer donc plus d’onglet avec du flash ou autre.

Mais ça c’est la théorie, en pratique le soft va être plus lent car tous le code n’a pas besoin d’être en 64 bits (ex: un compteur du nombre d’onglets se contentera très bien du 32 bits. De plus, un process peut se forker par onglet et là encore, à moins d’utiliser 4G de RAM pour afficher une page web, il ne devrait pas y avoir de soucis.

 

Donc contrairement à ce qui a été dit au dessus, la plupart des développeurs compétents ne recommandent pas nécessairement le 64 bits pour toutes les applications (cf Visual Studio dernièrement), le 64 bits est surtout intéressant pour les systèmes. Donc à moins de réécrire ou de revalider plusieurs milliers de lignes de code pour passer seulement ce qu’il faut en 64 bits, le 32 bits restera toujours moins risquer et marchera très bien.







Hum, tu as déjà programmé pour une architecture 64 bits ? Déjà rien que pouvoir utiliser 4 registres pour les passages de paramètres de fonctions/méthodes au lieu de passer par la pile permet pas mal d’optimisations, ensuite tous les CPU x86_64 supportent le SSE2 ce qui permet d’optimiser encore plus les programmes au lieu de les compiler pour Pentium 2… voire 386 si on veut que ça passe vraiment partout (quitte à sacrifier des optimisations).



Ensuite ce dont tu parles est la place que va prendre un entier en mémoire, effectivement un entier 64 bits prend le double d’un entier 32 bits, c’est surprenant non ? :p Par contre, qu’est-ce qui t’obliges à utiliser des entiers 64 bits ? Tu peux très bien utiliser des entiers 8, 16 ou 32 bits en 64 bits. De plus, en 32 bits un entier 64 bits pourra être lu plus lentement qu’un entier 64 bits (ça dépend des optimisations du compilo), par contre en 64 bits les deux seront lus aussi rapidement.



Pour info, je suis un programmeur C++ et je compile tous mes programmes en 64 bits depuis au moins 2010. C’est vraiment pas la mer à boire de porter du code 32 bits en 64 bits, il suffit juste de prendre des bonnes habitudes (exemple : ne pas caster de pointeur dans un entier 32 bits…).






Et l’abandon progressif du 32 par les OS.

Par exemple Ubuntu compte arrêter le 32bits en 2017.








Kervala a écrit :



Hum, tu as déjà programmé pour une architecture 64 bits ? Déjà rien que pouvoir utiliser 4 registres pour les passages de paramètres de fonctions/méthodes au lieu de passer par la pile permet pas mal d’optimisations, ensuite tous les CPU x86_64 supportent le SSE2 ce qui permet d’optimiser encore plus les programmes au lieu de les compiler pour Pentium 2… voire 386 si on veut que ça passe vraiment partout (quitte à sacrifier des optimisations).



Ensuite ce dont tu parles est la place que va prendre un entier en mémoire, effectivement un entier 64 bits prend le double d’un entier 32 bits, c’est surprenant non ? :p Par contre, qu’est-ce qui t’obliges à utiliser des entiers 64 bits ? Tu peux très bien utiliser des entiers 8, 16 ou 32 bits en 64 bits. De plus, en 32 bits un entier 64 bits pourra être lu plus lentement qu’un entier 64 bits (ça dépend des optimisations du compilo), par contre en 64 bits les deux seront lus aussi rapidement.



Pour info, je suis un programmeur C++ et je compile tous mes programmes en 64 bits depuis au moins 2010. C’est vraiment pas la mer à boire de porter du code 32 bits en 64 bits, il suffit juste de prendre des bonnes habitudes (exemple : ne pas caster de pointeur dans un entier 32 bits…).





Gros +1

Un code ecrit proprement marchera tres bien qu il soit en 32 ou en 64 bits.

Je pense que leur probleme c est la legacy



Pour info je suis un développeur kernel et système embarqués donc je connaîs pas trop mal la manière dont marche un compilo et justement, par défaut la plupart des dev utilisent int mavariable; en C/C++, hors le mot clé int ne garantis en rien la taille utilisée. Selon les architectures ça peut être un 32 ou un 64 bits voir un 16 bits sur les proc spécialisés.

Porter mes propres programmes de 32 vers 64 bits n’est pas la mort en effet mais qu’en est-il des projets sur lesquels je travaille et qui font plusieurs millions de lignes de codes.

Donc on est bien d’accords si la taille des variables étaient controllés comme en embarqué et qu’un minimum de best practices étaient utilisés sur les casts notamment et les alignements de structure par rapport au ligne de cache, que le code était bien modulaire pour faire une migration progressive, il n’y aurait pas de soucis mais prends un bon gros projet open source au pif et regarde la qualité du code. Les codes propriétaires étant souvent (mais pas toujours) encore pire.



 Pour info on peut faire du 32 bits et utiliser des optimations sans rester en 386, le SSE2 et 3 ayant été introduit dans la génération des pentium 4 donc il ne faut pas mélanger deux choses bien distinctes.


Justement je vais bien dans ce sens les OS sont obligés de migrer mais pas les applications, sur ubuntu comme sur Windows il restera toujours des libs pour le 32 bits.



Après je ne dis pas que je suis contre le passage au 64 bits bien au contraire mais je reste pragmatique sur la manière dont sont gérés le code dans les entreprises notamment (risques de régression vs rentabilité estimé du passage par exemple).


Si ramon passe par là (news opera ;) ) ou si une autre personne a une idée de l’avancé de l’intégration d’un lecteur RSS à Vivaldi (M2 je crois). Ça me manque beaucoup, j’ai Vivaldi et Opera V12 en //, si je pouvais n’avoir plus que Vivaldi.








Kriska a écrit :



Pour info je suis un développeur kernel et système embarqués donc je connaîs pas trop mal la manière dont marche un compilo et justement, par défaut la plupart des dev utilisent int mavariable; en C/C++, hors le mot clé int ne garantis en rien la taille utilisée. Selon les architectures ça peut être un 32 ou un 64 bits voir un 16 bits sur les proc spécialisés.

Porter mes propres programmes de 32 vers 64 bits n’est pas la mort en effet mais qu’en est-il des projets sur lesquels je travaille et qui font plusieurs millions de lignes de codes.

Donc on est bien d’accords si la taille des variables étaient controllés comme en embarqué et qu’un minimum de best practices étaient utilisés sur les casts notamment et les alignements de structure par rapport au ligne de cache, que le code était bien modulaire pour faire une migration progressive, il n’y aurait pas de soucis mais prends un bon gros projet open source au pif et regarde la qualité du code. Les codes propriétaires étant souvent (mais pas toujours) encore pire.



 Pour info on peut faire du 32 bits et utiliser des optimations sans rester en 386, le SSE2 et 3 ayant été introduit dans la génération des pentium 4 donc il ne faut pas mélanger deux choses bien distinctes.







Pour ma part, dans pas mal de projets, soit on utilise les types standards uint32_t, uint64_t, int64_t, etc… soit des redéfinitions de ces types avec un autre nom mais pour être sûr qu’on connaisse la taille de cette variable surtout lorsque les données doivent être sérialisées.



Pour les optimisations, il est en effet possible d’utiliser certains jeux d’instructions conditionnellement à l’exécution (bon, par contre, faut passer par de l’ASM :p).



Sinon pour le portage de 32 à 64, je pense que je peux te dire que ce n’est pas tant la mort que ça :) Je bosse sur le MMORPG open-source Ryzom et je me suis chargé du portage en 64 bits et il y a effectivement plusieurs millions de lignes de code :https://bitbucket.org/ryzom/ryzomcore/commits/all



Le code du jeu a été libéré en 2010, il ne tournait que sous Windows en 32 bits, je me suis occupé du port Linux et 64 bits (Linux et Windows).



Ca doit être sympa de bosser sur un MMO :)



Sinon pour les optimisations pas besoin de passer directement par l’assembleur, si tu utilises GCC par exemple :

“For the i386 compiler, you need to use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For the x86-64 compiler, these extensions are enabled by default.”



Donc oui en x86_64 le SSE est par défaut mais cela ne veut pas dire qu’il n’est pas utilisable en x86 et donc en i386 ;)