Je pertinente cet article, et j'ajouterai une petite anecdote sur le logo de la disquette :
En rangeant chez mes parents avec mon cousin, qui a une dizaine d'années, on est tombé sur un tas de disquettes et sa réaction m'a vraiment fait prendre conscience que j'étais devenu vieux, il a dis : "c'est marrant, c'est comme le logo pour sauvegarder" …
Et finalement je penses que si on montre une disquette à des enfants qui ont déjà manipulé un ordinateur ça serait très logique qu'ils aient tous cette réaction.
Euh, je n'ai jamais vu un crash graphique de X11 où tu récupérais tes applications comme avant.
Oui c'est ce que je dis : X11 ne plante quasiment jamais donc toutes les applis survivent à un plantage du gestionnaire de fenêtres Mutter/Compiz (je viens de tuer mon compiz pour vérifier: aucun soucis).
Par contre avec Wayland un plantage de Mutter/Gnome-Shell c'est comme un plantage de X11. Ce que je n'ai jamais rencontré, et qui est beaucoup plus embêtant qu'un Compiz qui par en vrille (rarement).
Sinon merci pour le lien, ça veut dire que c'est quand même dans les "pending features". J'ai peur qu'ils doivent ré-écrire pas mal de code de gnome-shell pour y arriver mais c'est bien que ça soit pas juste un "wontfix".
Après, GNOME reste très stable au quotidien, je ne trouve pas que cette absence soit vraiment bloquante. J'utilise Wayland depuis 2 ans maintenant avec GNOME.
2 ans ! Wouha je suis beaucoup plus prudent pour ce genre de chose (je laisse lâchement les autres essuyer les plâtres sur des composants critique comme ça).
Donc effectivement ça semble très peu nécessaire, mais je suis quand même déçu que les développeurs Gnome-Shell n'y aient pas pensés dès la conception.
Ce qui m’ennuie un peu c'est qu'on peut très bien ne pas avoir de soucis puis suite à une maj/installation d'une extension de Gnome-Shell des soucis commencent à apparaitre, et avec l'architecture actuel c'est quand même potentiellement du gros soucis.
Je n'ai pour l'instant jamais utilisé Wayland mais ce genre de bug ne m'y encourage pas vraiment.
Pour résumer (et corrigez moi si je m’égare) : avec X11 le x11-server était plutôt stable (je ne me souviens pas l'avoir vu planter) donc le gestionnaire de fenêtres qui plante n'est pas un gros problème : il se relance et comme toutes les applis sont attachées au server-x11 tout repars comme avant.
Mais avec Wayland le gestionnaire de fenêtre devient aussi x11-server-équivalent et donc un plantage de celui ci équivaut à la perte de toutes les applications en cours et donc du travail en cours.
Hors le gestionnaire de fenêtre de Gnome (Gnome-shell) utilise beaucoup de technologies un peux risqué, genre javascript, ce qui est très bien pour l'étendre et ajouter des extensions etc, mais aussi ce qui le rend plus dépendant au niveau de la stabilité : stabilité du code C plus du moteur JS plus de toutes les extensions.
Alors même si je ne doute pas des compétences des développeurs Gnome/RedHat et que donc les plantages de Gnome-shell seront extrêmement rare, je serais quand même plus tranquille si Gnome-shell était "crash-proof".
Il y a plusieurs idées lancés dans le bugzilla pour résoudre le problème, mais par contre je n'ai pas l'impression qu'il y ai une solution choisie ni un début de travail/réflexion sur ce point.
Quelqu'un a des informations la dessus ?
Pour ceux qui utilisent Wayland : est ce que je me fais du soucis pour rien ?
C'est moi ou l'architecture de MIR aurait évité ce soucis ? (Pour celle là, la coutume voudrait que vous attendiez vendredi pour répondre)
Pour c++17 n'est il pas possible de linker statiquement toute les lib utilisées notamment la libc++ (avec un petit -static-libstdc++) ? Ok ça a l'inconvénient de ne plus avoir les maj de sécurité de la libstdc++ et toutes celles utilisé … peut être pas idéal.
Et effectivement flatpak n'a pas été pensé pour les serveurs, dommage.
Il reste snap ou docker et peut être appimage mais faut demander à l'utilisateur de l'installer.
Donc effectivement pas de solution parfaite, snap/docker est peut être la moins pire mais pas directement clé en main pour les utilisateurs (je sais pas trop j'ai jamais vraiment utilisé).
Sinon faut tout recoder en Go qui n'as pas de dépendance ni même à la libc (je plaisante hein). Sérieusement, je compati : c'est vrai que le vieux GCC de debian c'est vraiment pas pratique. Mais il arrive et je crois avoir lu que debian allait faire des efforts sur ce point (mais je retrouve pas où).
En dehors du fait de savoir qui a commencé le premier : on va pouvoir comparer 2 solutions, au lieu de se plaindre on va pouvoir regarder d'un point de vu strictement technique quelle approche semble la mieux.
Par exemple en regardant vite fait voilà ce qui ressort :
- Flatpak ne semble pas prévu pour être utilisé sur serveur / snap est annoncé comme idéal pour serveur et IOT
- Flatpak a prévu (pas encore implémenté) des "portals" permettant à l'utilisateur de refuser ou accorder des droit à une application / Snap ne semble pas avoir ceci de prévu
- Flatpack a prévu de s'appuyer sur SElinux+seccomp / Snap s'appuis sur appArmor+seccomp
- … etc, ça vaudra le coup de faire une comparaison plus détaillé, mais flatpak semble avoir été sorti bien avant d'être finalisé (ce n'est pas une critique j'ai l'impression que les objectifs sont plus ambitieux que ceux de snap) donc c'est encore un peu tôt
Puis les 2 projets vont pouvoir être utilisé conjointement. Rien ne devrait empêcher la distribution hôte de supporter les flatpak comme les snap conjointement.
Ça a été supporté par la version 44, puis Mozilla a fait marche arrière.
Aujourd'hui il faut activer le support dans about:config (flag "webspeech.recognition.enable" ) Une demo pour tester le support
Firefox est pas si en retard : le seul gros manque c'est les formulaires de date/semaine/mois/heure, surtout que ça fait longtemps que Chrome/Opera les ont et maintenant même Edge a pris de l'avance sur Firefox… Ce qui est quand même embarrassant, car avec quelque ligne de code de HTML simple n'importe qui peut très facilement faire une démo genre "Voyez Edge supporte plus de standard que Firefox".
Sinon ce qui manquera encore c'est le formulaire keygen et la speech recognition mais ça me semble beaucoup moins courant qu'un formulaire de date/semaine/mois/heure.
Sinon je ne pense pas que l'intégration du calendrier utilisateur soit prévu dans le standard HTML, déjà ça serait super que Firefox ait quelque chose d'équivalent à Chrome/Opera.
Demi bonne nouvelle parce que Firefox est vraiment en retard sur le support du sélecteur de date … mais depuis peu le rapport de bug bouge pas mal
J'ai bon espoir cette fois, peut être pour Firefox 51.
J'ai volontairement cité PolarSSL et pas GnuTLS qui n'avait (selon certain ouï-dire) pas bonne réputation niveau sécurité/audit.
Pour l'API incompatible, j'entends bien par "fuite vers PolarSSL" fuir le code et également l'API de OpenSSL, qui n'a pas bonne réputation et apparemment la doc c'est pire (le mainteneur d'hiwatha justifiait la migration à cause de la documentation d'OpenSSL). Donc oui, ça a un coût, mais justement je suis étonné que si peu de personne aient trouvé que ce coût en vaille la peine.
Surtout que depuis que ARM a repris PolarSSL pour en faire mbedTLS, ils y ont ajouté la licence Apache qui, à mon sens, rend possible l'utilisation partout où OpenSSL est utilisé (ils sont d’ailleurs pas tendre avec OpenSSL).
[mes 2cts d'expérience]
Lorsqu'une bibliothèque logiciel employable pour l'embarqué entre en concurrence avec une autre inutilisable pour l’embarqué, c'est très souvent celle pour l'embarqué qui devient la solution technique supérieur; bien que son développement soit plus lent au début.
[/mes 2cts d'expérience]
Rust n'est pas aussi portable que le C (pour l'instant) et si on veut quelque chose d'utilisable (compilable à peu prés partout x86/POWER/SPARC/ARM/MIPS/AVR/…) le C est encore pour longtemps un (le seul?) choix pragmatique.
Ce que je ne comprend pas, c'est pourquoi il n'y a pas eu plus de fuite vers PolarSSL, comme Hiwatha web server avait eu la bonne idée de le faire avant l'apparition des problèmes de sécurité d'OpenSSL.
Y a un truc qui m'embête avec tout ses "superset" de JS/HTML/DOM : c'est qu'on perd la visibilité dans le navigateur du code exécuté.
Je m'explique : un truc que je trouve génial en web c'est que en faisant du html/JS/CSS ont peu faire une web-app assez simplement et surtout on l’exécute dans le navigateur et lorsqu'on ouvre la console web on a directement accès à son code, ont peut tout déboguer/changer facilement; et les outils de débogue/profilage des navigateurs sont vraiment au poil.
Pour faire du C embarqué et du C++ de temps à autre, je trouve ça génial : jamais mettre en place le débogage/profilage d'une application ne m'a été rendu si simple !
Franchement, je m’accommode bien des défaut du JS et je ne suis pas prêt de passer à CoffeScript/Typescript/SASS/Elm/etc car en les utilisant ce que je verrais dans la console web sera généré par ses outils ça ne sera plus mon code, ça ajoute une couche d'indirection et je trouve que ça n'en vaut donc pas la peine.
Est ce que je passe à côté de quelque chose ? Elm a-t-il des outils pour déboguer/visualiser/modifier aussi facilement son code que du vanilla HTML/JS ?
NOTE : oups je voulais répondre à @macadoum sur Elm ( "Elm, c'est la grande classe." ), si qqn peut déplacer mon commentaire
Juste une question subsidiaire sur Mikrotik que je te remercie de me faire découvrir :
As tu des retours d'expérience sur cette marque, en utilisant des switchs POE : est ce fiable ?
On a eu quelques problèmes avec pas mal de marques, souvent pas cher, ce qui exclu Cisco et Hp : ports POE tombant en panne, alim qui lâche étaient des problèmes arrivant rarement (mais trop souvent).
OK, merci pour la précision sur les IP, j’étais passé à côté de tout ça.
Du coup laisser à mes clients la possibilité de mettre en place leurs certificats et être capable de convenir aux power-user tout comme aux clients ayant moins de connaissance réseau va être un défit plus subtile que simplement mettre en place SSL dans le dispositif…
Merci, ça peut être intéressant de regarder comment ils ont fait pour faire pareil … par contre les prix du nexus 7000 ouch !! Je pensais pas que ça existait des équipements réseau à ce prix.
Sinon les HP procurve ont de l'https activable aussi
Merci pour la réponse détaillée, c'est très instructif.
À part obtenir, de la part d’une CA reconnue, un certificat intermédiaire autorisé à signer des certificats finaux sans limitation, je ne vois pas.
Ça serait la solution la plus simple.
Si je comprend bien c'est justement comme cela que fonctionne let's encrypt : les certificats issus de let's encrypt sont signés par identTrust qui est reconnu par les navigateurs; ce qui permet que let's encrypt même tout jeune soit lui aussi reconnu par les navigateurs. J'ai bon ?
Mais j'imagine que d'obtenir ce type de certificat est hors de prix ?
…
Pour la suite je fais des précisions/réflexions issue de mes recherches faites depuis (mais vous pouvez me corriger si je fais fausse route) :
Question subsidiaire : peut on faire un certificat pour une adresse IP (voir adresse IP locale*) et non un DNS ? *et oui je voulais bien parler d'adresses privées au sens RFC 1918. Mais ma question portait aussi sur les IP publique (genre 172.217.18.227)
Après quelque recherches j'ai trouvé quelqu'un qui a posé exactement la même question que moi sur stackoverflow et la réponse qui y est faite est qu'une adresse IP peut être utilisé à la place d'un hostname (RFC 2818). Mais effectivement il ne précise pas le type d'IP et les "Private Address Space" font sûrement exception.
Je suis certain que je vais avoir des clients qui vont utiliser des IP du coup pour les IP publiques ça devrait être bon, mais pas les privées.
Donc, pour mon dispositif l'idéal serait que le client puisse :
1. Installer ses certificats sur le dispositif (que le dispositif utilisera pour signer son certificats https). En fait j'ai découvert depuis que les switchs hp et cisco font comme ça.
2. Pour rendre l'utilisation du SSL plus simple pour l'utilisateur je pense implémenter un client let's encrypt (ça marche à la condition que mon dispositif soit mis en place de sorte qu'il soit accessible depuis internet)
Le point 2 ça serait vraiment la "classe à Dallas", et du coup j'ai regardé le principe de fonctionnement de let's encrypt à l'air plutôt simple. Mais par contre les clients let's encrypt ont l'air assez complexe… parce qu'ils automatisent tout et font la config de apache/nginx.
Et la limite du port 80 pour l’authentification HTTP-01 risque d'être gênante : je vois pas mal de nos clients utiliser des ports complètement exotique pour faire une redirection publique sur leur dispositif, du coup pas de let's encrypt pour eux.
Je pensais pouvoir faire du https simplement depuis que ARM avait rendu libre PolarSSL, mais je découvre que la certification est peut être un problème plus ardu a bien intégrer.
Je pose ma question à 3 sous ici, car je ne suis pas un expert en certification TLS et j'ai bon espoir que les personnes venant lire cette news en soient (des experts ou au moins des personnes ayant mis en place du https, ce qui n'est pas mon cas).
Si je vends un objet connecté disposant d'une interface web de configuration, qu'il est possible pour l'utilisateur de changer l'adresse IP et pourquoi pas de le placer derrière un DNS.
De ce que je comprends pour ne pas avoir dans le navigateur le message de connexion https non vérifiée qui fait fuir les utilisateurs, il faut obtenir un certificat auprès d'un organisme reconnu et utilisé par les navigateur web.
Le hic c'est que le certificat délivré par l'organisme est associé à un DNS unique, hors mon objet connecté est paramétrable.
Y a t'il une solution existante pour avoir du https transparent pour l'utilisateur (pas de message de certificat inconnu) pour ce cas d’utilisation ? J'ai l'impression que non, mais à tout hasard mieux poser cette question d'abord.
J'ai l'impression que la seule solution serait de laisser la possibilité à l'utilisateur d'uploader des certificat sur le dispositif.
Du coup vu que let's encrypt à l'air automatisable c'est peut être un bon candidat pour intégration direct dans mon dispositif (arrêtez moi si je me trompe) ce qui serait peut être encore plus simple pour l'utilisateur.
Question subsidiaire : peut on faire un certificat pour une adresse IP (voire adresse IP locale) et non un DNS ?
Question subsidiaire2 : si quelqu'un sait comment ceci est géré sur les switch configurable avec interface web (genre les CISCO d'entreprise ou autre truc bien sérieux/chère) ?
Merci d’avance, désolé pour la question un peu décousue et juste un tout petit peu en lien avec let’s encrypt
IE/Edge supporte les inputs de type date/mois/heure … et Firefox est maintenant le dernier des navigateurs moderne à ne pas l'implémenter (non Safari ça compte pas dans les navigateurs moderne).
C'est vraiment dommageable car des développeurs de webapp qui vont avoir besoin d'un input de type date ou time c'est quand même beaucoup plus courant que ceux qui vont ressentir un manque de Reflect API.
Mais bon apparemment y a du nouveau sur ce bug et j'espère que finalement tout viendra à point à qui sait attendre.
C'est pas faux : je sais pas pourquoi j'ai mis RAII dans me dernière phrase, ça la fausse en partie; toutes mes confuses.
Il fallait donc lire :
"Et si Gecko n'utilise pas C++11 (en tout cas pas dans les endroit concernés) c'est sûrement simplement car sa création date d'avant l'arrivé de C++11."
Car pour faire un moteur comme Gecko, il doit y avoir à quelque endroits l'utilisation de pointeurs, qui à l'époque n'ont sûrement pas étaient écris à l'aide de pointeurs intelligents (encore que, avec boost ça aurait peut être était possible, je ne sais pas depuis combien de temps ces pointeurs existent dans boost)
Posté par trancheX .
En réponse à la dépêche Firefox : version 38.
Évalué à 6.
Dernière modification le 15 mai 2015 à 14:38.
Et de préciser une chose, puisqu'on compare C++ à Java :
Existe-t-il ne serait-ce qu'un seul moteur de rendu Web+JS codé en Java qui soient utilisable pour faire un navigateur web capable de concurrencer Firefox/Chrome/IE/Opera ?
La réponse est : non, aucun PC n'aurait assez de CPU et surtout de mémoire vive pour faire tourner cette merveille.
Note: on pourrait penser que je viens de faire un troll, mais non je n'ai pas trouvé de navigateur écrit en java qui arrive à la cheville des navigateur actuel (qui utilise tous des moteurs de rendu en C++ : Gecko/WebKit/Presto/Trident)
Par contre :
Oui si tu utilises les fonctionnalités très haut niveau de C++ que 99% des développeurs C++ honnissent tu es tranquille
ça oui, sans aucun doute c'est du troll
Et si Gecko n'utilise pas C++11 et la RAII (en tout cas pas dans les endroit concernés) c'est sûrement simplement car sa création date d'avant l'arrivé de C++11
Merci, c'est beaucoup plus clair.
J'avais déjà vu la Browser API, mais je me rendais pas compte de tous ce qu'il y manquait.
Donc en gros : y a encore beaucoup de travail, mais lorsque Gecko aura les API nécessaires (historique, navigation, certificats, …), et lorsque ce sera finalisé : le navigateur de FirefoxOS (qui lui n'utilise pas XUL) sera complet et rien n'empêchera de faire un Firefox Desktop avec browser.html ou équivalent.
J'ai bon ?
PS: Grâce à cette discussion je viens de découvrir SlimerJS. Je ne savais même pas que ce genre d'outil existait, faudra que je test à l'occasion pour les units test dans au moins 1 projet. Donc encore une fois merci
C'est sympa de la part de RedHat et de Collabora de collaborer contribuer.
À ma connaissance, Mozilla n'embarque pas Cairo
En fait je me référais à ces explications, et c'était ce que je comprenais de :
It’s possible that we will decide to modify our internal copy of Cairo to allow us to use the internal stateless surface API directly, since we think Cairo’s surface API is a pretty good match to Azure’s 2D API.
Mais ces explications semble ne plus être d'actualité, et en cherchant un peu il apparaît que tu as raison : Cairo est une dépendance, donc Mozilla-Azure n'embarque pas ou plus son propre Cairo. (et je note au passage qu'il y a maintenant un backend Skia, l'équivalent de Cairo utilisé par Chrome)
Je rejoins ton avis sur la non intégration de chromium à l'OS, et sa mauvaise gestion des écrans haute résolution sous Linux. Moi perso avec Firefox je configure la police système en plus gros : ça s'applique sur les barres de titres et onglets et après dans Firefox je vais dans préférence->contenu augmenter la police.
… mais si Firefox était encore mieux intégré au système, il pourrait aller chercher cette info tout seul plutôt que j'aie à la changer dans about:config. Il me semble que le support des écrans HiDPI sous Gnome sera vraiment pris en charge correctement via gtk3/Wayland donc pour moi c'est un bon exemple de ce qu'apporte le portage vers gtk3.
Là je ne vois pas en quoi un toolkit tout entier est nécessaire pour aller chercher une info système. Et la gestion du HiDPI c'est hyper simple à faire en web (depuis le temps que tous le monde fait du responsive design).
Mozilla développe et maintient son toolkit web (Gecko) avec son moteur de dessin (Azure) qui est multiplate-forme, qui dispose de plusieurs backend etc. Gtk fait beaucoup doublon au milieux de tout ça.
L'interface de Firefox OS est géré entièrement par cette pile graphique (Gecko/Azure) alors il doit pas manquer grand chose pour gérer entièrement celle de Firefox Desktop.
Effectivement d'après ceci, le problème est double : si Mozilla veut passer à Wayland/Mir en continuant de s'appuyer sur Gtk il faut :
1. passer de Gtk2 à Gtk3 (nécessaire pour Wayland), ne pose pas de problème à Gecko en lui même mais en pose tous plein pour les plugins (comme flash) faisant des appels à Gtk2
2. enlever+remplacer dans le code tout les appels spécifique à X11
Je penses que les dev Mozilla savent ce qu'ils font mais j'ai l'impression que maintenant que le web (HTML5) est un outil pouvant remplacer un toolkit, on pourrait en profiter pour remplacer Gtk.
La présence de GTK/Cairo/Windows est surtout là pour gérer les fenêtres, ouvrir les boites de dialogues de fichier, d'impression etc du système, accéder au presse papier et de beaucoup d'autres choses.
Peut être que je ne me rend pas compte mais j'ai l'impression que Gtk n'est utilisé que pour quelque trucs accessoires : aller lire la config système (couleur/font etc) et la boite dialogue système d'impression (sur ce dernier point Chrome m'ouvre sa boite de dialogue, faite en web je suppose).
Je comprend très bien qu'il soit plus rapide à court terme d'utiliser Gtk, mais je trouve que c'est beaucoup un toolkit tout entier* pour juste quelque actions qui pourrait être remplacés par un code plus beaucoup plus simple.
*: (et à fortiori un Gtk3 qui va embarquer son propre Cairo en plus de celui déjà présent dans Mozilla-Azure)
Je trouverai dommage que beaucoup d'heure de R&D soient utilisées à passer de Gtk2 à Gtk3 (puisque ça fait longtemps qu'on a parle c'est que ça doit pas être simple ce portage) alors qu'elles pourraient être employées sur Mozilla-Azure + browser.html pour mettre au point une interface qui serait utile à toute les plate-forme Win/OSX/Linux-Gtk-Qt et pourquoi pas même android etc.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par trancheX . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 3.
Je pertinente cet article, et j'ajouterai une petite anecdote sur le logo de la disquette :
En rangeant chez mes parents avec mon cousin, qui a une dizaine d'années, on est tombé sur un tas de disquettes et sa réaction m'a vraiment fait prendre conscience que j'étais devenu vieux, il a dis : "c'est marrant, c'est comme le logo pour sauvegarder" …
Et finalement je penses que si on montre une disquette à des enfants qui ont déjà manipulé un ordinateur ça serait très logique qu'ils aient tous cette réaction.
[^] # Re: Est il prévu de rendre la session Wayland "crashproof"
Posté par trancheX . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 4.
Oui c'est ce que je dis : X11 ne plante quasiment jamais donc toutes les applis survivent à un plantage du gestionnaire de fenêtres Mutter/Compiz (je viens de tuer mon compiz pour vérifier: aucun soucis).
Par contre avec Wayland un plantage de Mutter/Gnome-Shell c'est comme un plantage de X11. Ce que je n'ai jamais rencontré, et qui est beaucoup plus embêtant qu'un Compiz qui par en vrille (rarement).
Sinon merci pour le lien, ça veut dire que c'est quand même dans les "pending features". J'ai peur qu'ils doivent ré-écrire pas mal de code de gnome-shell pour y arriver mais c'est bien que ça soit pas juste un "wontfix".
2 ans ! Wouha je suis beaucoup plus prudent pour ce genre de chose (je laisse lâchement les autres essuyer les plâtres sur des composants critique comme ça).
Donc effectivement ça semble très peu nécessaire, mais je suis quand même déçu que les développeurs Gnome-Shell n'y aient pas pensés dès la conception.
Ce qui m’ennuie un peu c'est qu'on peut très bien ne pas avoir de soucis puis suite à une maj/installation d'une extension de Gnome-Shell des soucis commencent à apparaitre, et avec l'architecture actuel c'est quand même potentiellement du gros soucis.
# Est il prévu de rendre la session Wayland "crashproof"
Posté par trancheX . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 8.
Je n'ai pour l'instant jamais utilisé Wayland mais ce genre de bug ne m'y encourage pas vraiment.
Pour résumer (et corrigez moi si je m’égare) : avec X11 le x11-server était plutôt stable (je ne me souviens pas l'avoir vu planter) donc le gestionnaire de fenêtres qui plante n'est pas un gros problème : il se relance et comme toutes les applis sont attachées au server-x11 tout repars comme avant.
Mais avec Wayland le gestionnaire de fenêtre devient aussi x11-server-équivalent et donc un plantage de celui ci équivaut à la perte de toutes les applications en cours et donc du travail en cours.
Hors le gestionnaire de fenêtre de Gnome (Gnome-shell) utilise beaucoup de technologies un peux risqué, genre javascript, ce qui est très bien pour l'étendre et ajouter des extensions etc, mais aussi ce qui le rend plus dépendant au niveau de la stabilité : stabilité du code C plus du moteur JS plus de toutes les extensions.
Alors même si je ne doute pas des compétences des développeurs Gnome/RedHat et que donc les plantages de Gnome-shell seront extrêmement rare, je serais quand même plus tranquille si Gnome-shell était "crash-proof".
Il y a plusieurs idées lancés dans le bugzilla pour résoudre le problème, mais par contre je n'ai pas l'impression qu'il y ai une solution choisie ni un début de travail/réflexion sur ce point.
[^] # Re: Vivement la suivante
Posté par trancheX . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 1.
Pour c++17 n'est il pas possible de linker statiquement toute les lib utilisées notamment la libc++ (avec un petit -static-libstdc++) ? Ok ça a l'inconvénient de ne plus avoir les maj de sécurité de la libstdc++ et toutes celles utilisé … peut être pas idéal.
Et effectivement flatpak n'a pas été pensé pour les serveurs, dommage.
Il reste snap ou docker et peut être appimage mais faut demander à l'utilisateur de l'installer.
Donc effectivement pas de solution parfaite, snap/docker est peut être la moins pire mais pas directement clé en main pour les utilisateurs (je sais pas trop j'ai jamais vraiment utilisé).
Sinon faut tout recoder en Go qui n'as pas de dépendance ni même à la libc (je plaisante hein). Sérieusement, je compati : c'est vrai que le vieux GCC de debian c'est vraiment pas pratique. Mais il arrive et je crois avoir lu que debian allait faire des efforts sur ce point (mais je retrouve pas où).
[^] # Re: XML sapu et autres billevesées
Posté par trancheX . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 3.
C'est quoi le rapport entre MQTT et XML ?
MQTT n'est il pas data agnostique ?
[^] # Re: Flatpak
Posté par trancheX . En réponse au journal Mon premier snap sur Xenial. Évalué à 0.
En dehors du fait de savoir qui a commencé le premier : on va pouvoir comparer 2 solutions, au lieu de se plaindre on va pouvoir regarder d'un point de vu strictement technique quelle approche semble la mieux.
Par exemple en regardant vite fait voilà ce qui ressort :
- Flatpak ne semble pas prévu pour être utilisé sur serveur / snap est annoncé comme idéal pour serveur et IOT
- Flatpak a prévu (pas encore implémenté) des "portals" permettant à l'utilisateur de refuser ou accorder des droit à une application / Snap ne semble pas avoir ceci de prévu
- Flatpack a prévu de s'appuyer sur SElinux+seccomp / Snap s'appuis sur appArmor+seccomp
- … etc, ça vaudra le coup de faire une comparaison plus détaillé, mais flatpak semble avoir été sorti bien avant d'être finalisé (ce n'est pas une critique j'ai l'impression que les objectifs sont plus ambitieux que ceux de snap) donc c'est encore un peu tôt
Puis les 2 projets vont pouvoir être utilisé conjointement. Rien ne devrait empêcher la distribution hôte de supporter les flatpak comme les snap conjointement.
[^] # Re: HTML5 date-time → toujours pas mais ça vient
Posté par trancheX . En réponse à la dépêche Firefox 47, version de transition. Évalué à 1.
Ça a été supporté par la version 44, puis Mozilla a fait marche arrière.
Aujourd'hui il faut activer le support dans about:config (flag "webspeech.recognition.enable" )
Une demo pour tester le support
[^] # Re: HTML5 date-time → toujours pas mais ça vient
Posté par trancheX . En réponse à la dépêche Firefox 47, version de transition. Évalué à 0.
Firefox est pas si en retard : le seul gros manque c'est les formulaires de date/semaine/mois/heure, surtout que ça fait longtemps que Chrome/Opera les ont et maintenant même Edge a pris de l'avance sur Firefox… Ce qui est quand même embarrassant, car avec quelque ligne de code de HTML simple n'importe qui peut très facilement faire une démo genre "Voyez Edge supporte plus de standard que Firefox".
Sinon ce qui manquera encore c'est le formulaire keygen et la speech recognition mais ça me semble beaucoup moins courant qu'un formulaire de date/semaine/mois/heure.
Sinon je ne pense pas que l'intégration du calendrier utilisateur soit prévu dans le standard HTML, déjà ça serait super que Firefox ait quelque chose d'équivalent à Chrome/Opera.
# HTML5 date-time → toujours pas mais ça vient
Posté par trancheX . En réponse à la dépêche Firefox 47, version de transition. Évalué à 4. Dernière modification le 13 juin 2016 à 16:52.
Demi bonne nouvelle parce que Firefox est vraiment en retard sur le support du sélecteur de date … mais depuis peu le rapport de bug bouge pas mal
J'ai bon espoir cette fois, peut être pour Firefox 51.
[^] # Re: sécurisée et moderne
Posté par trancheX . En réponse à la dépêche LibreSSL 2.3.3. Évalué à 3.
J'ai volontairement cité PolarSSL et pas GnuTLS qui n'avait (selon certain ouï-dire) pas bonne réputation niveau sécurité/audit.
Pour l'API incompatible, j'entends bien par "fuite vers PolarSSL" fuir le code et également l'API de OpenSSL, qui n'a pas bonne réputation et apparemment la doc c'est pire (le mainteneur d'hiwatha justifiait la migration à cause de la documentation d'OpenSSL). Donc oui, ça a un coût, mais justement je suis étonné que si peu de personne aient trouvé que ce coût en vaille la peine.
Surtout que depuis que ARM a repris PolarSSL pour en faire mbedTLS, ils y ont ajouté la licence Apache qui, à mon sens, rend possible l'utilisation partout où OpenSSL est utilisé (ils sont d’ailleurs pas tendre avec OpenSSL).
[mes 2cts d'expérience]
Lorsqu'une bibliothèque logiciel employable pour l'embarqué entre en concurrence avec une autre inutilisable pour l’embarqué, c'est très souvent celle pour l'embarqué qui devient la solution technique supérieur; bien que son développement soit plus lent au début.
[/mes 2cts d'expérience]
[^] # Re: sécurisée et moderne
Posté par trancheX . En réponse à la dépêche LibreSSL 2.3.3. Évalué à 5.
Rust n'est pas aussi portable que le C (pour l'instant) et si on veut quelque chose d'utilisable (compilable à peu prés partout x86/POWER/SPARC/ARM/MIPS/AVR/…) le C est encore pour longtemps un (le seul?) choix pragmatique.
Ce que je ne comprend pas, c'est pourquoi il n'y a pas eu plus de fuite vers PolarSSL, comme Hiwatha web server avait eu la bonne idée de le faire avant l'apparition des problèmes de sécurité d'OpenSSL.
[^] # Re: Changement en dépêche
Posté par trancheX . En réponse à la dépêche Et si JavaScript allait droit dans le mur ?. Évalué à 2. Dernière modification le 09 mars 2016 à 12:34.
Y a un truc qui m'embête avec tout ses "superset" de JS/HTML/DOM : c'est qu'on perd la visibilité dans le navigateur du code exécuté.
Je m'explique : un truc que je trouve génial en web c'est que en faisant du html/JS/CSS ont peu faire une web-app assez simplement et surtout on l’exécute dans le navigateur et lorsqu'on ouvre la console web on a directement accès à son code, ont peut tout déboguer/changer facilement; et les outils de débogue/profilage des navigateurs sont vraiment au poil.
Pour faire du C embarqué et du C++ de temps à autre, je trouve ça génial : jamais mettre en place le débogage/profilage d'une application ne m'a été rendu si simple !
Franchement, je m’accommode bien des défaut du JS et je ne suis pas prêt de passer à CoffeScript/Typescript/SASS/Elm/etc car en les utilisant ce que je verrais dans la console web sera généré par ses outils ça ne sera plus mon code, ça ajoute une couche d'indirection et je trouve que ça n'en vaut donc pas la peine.
Est ce que je passe à côté de quelque chose ? Elm a-t-il des outils pour déboguer/visualiser/modifier aussi facilement son code que du vanilla HTML/JS ?
NOTE : oups je voulais répondre à @macadoum sur Elm ( "Elm, c'est la grande classe." ), si qqn peut déplacer mon commentaire
[^] # Re: Le titre est trop long
Posté par trancheX . En réponse à la dépêche Reparlons de Let’s Encrypt. Évalué à 0.
Juste une question subsidiaire sur Mikrotik que je te remercie de me faire découvrir :
As tu des retours d'expérience sur cette marque, en utilisant des switchs POE : est ce fiable ?
On a eu quelques problèmes avec pas mal de marques, souvent pas cher, ce qui exclu Cisco et Hp : ports POE tombant en panne, alim qui lâche étaient des problèmes arrivant rarement (mais trop souvent).
[^] # Re: Est ce une solution Certification pour objets connectés
Posté par trancheX . En réponse à la dépêche Reparlons de Let’s Encrypt. Évalué à 0.
OK, merci pour la précision sur les IP, j’étais passé à côté de tout ça.
Du coup laisser à mes clients la possibilité de mettre en place leurs certificats et être capable de convenir aux power-user tout comme aux clients ayant moins de connaissance réseau va être un défit plus subtile que simplement mettre en place SSL dans le dispositif…
[^] # Re: Le titre est trop long
Posté par trancheX . En réponse à la dépêche Reparlons de Let’s Encrypt. Évalué à 1.
Merci, ça peut être intéressant de regarder comment ils ont fait pour faire pareil … par contre les prix du nexus 7000 ouch !! Je pensais pas que ça existait des équipements réseau à ce prix.
Sinon les HP procurve ont de l'https activable aussi
[^] # Re: Est ce une solution Certification pour objets connectés
Posté par trancheX . En réponse à la dépêche Reparlons de Let’s Encrypt. Évalué à 1.
Merci pour la réponse détaillée, c'est très instructif.
Ça serait la solution la plus simple.
Si je comprend bien c'est justement comme cela que fonctionne let's encrypt : les certificats issus de let's encrypt sont signés par identTrust qui est reconnu par les navigateurs; ce qui permet que let's encrypt même tout jeune soit lui aussi reconnu par les navigateurs. J'ai bon ?
Mais j'imagine que d'obtenir ce type de certificat est hors de prix ?
…
Pour la suite je fais des précisions/réflexions issue de mes recherches faites depuis (mais vous pouvez me corriger si je fais fausse route) :
Après quelque recherches j'ai trouvé quelqu'un qui a posé exactement la même question que moi sur stackoverflow et la réponse qui y est faite est qu'une adresse IP peut être utilisé à la place d'un hostname (RFC 2818). Mais effectivement il ne précise pas le type d'IP et les "Private Address Space" font sûrement exception.
Je suis certain que je vais avoir des clients qui vont utiliser des IP du coup pour les IP publiques ça devrait être bon, mais pas les privées.
Donc, pour mon dispositif l'idéal serait que le client puisse :
1. Installer ses certificats sur le dispositif (que le dispositif utilisera pour signer son certificats https). En fait j'ai découvert depuis que les switchs hp et cisco font comme ça.
2. Pour rendre l'utilisation du SSL plus simple pour l'utilisateur je pense implémenter un client let's encrypt (ça marche à la condition que mon dispositif soit mis en place de sorte qu'il soit accessible depuis internet)
Le point 2 ça serait vraiment la "classe à Dallas", et du coup j'ai regardé le principe de fonctionnement de let's encrypt à l'air plutôt simple. Mais par contre les clients let's encrypt ont l'air assez complexe… parce qu'ils automatisent tout et font la config de apache/nginx.
Et la limite du port 80 pour l’authentification HTTP-01 risque d'être gênante : je vois pas mal de nos clients utiliser des ports complètement exotique pour faire une redirection publique sur leur dispositif, du coup pas de let's encrypt pour eux.
Je pensais pouvoir faire du https simplement depuis que ARM avait rendu libre PolarSSL, mais je découvre que la certification est peut être un problème plus ardu a bien intégrer.
# Est ce une solution Certification pour objets connecté avec interface web et adresse IP paramétrable
Posté par trancheX . En réponse à la dépêche Reparlons de Let’s Encrypt. Évalué à 3.
Je pose ma question à 3 sous ici, car je ne suis pas un expert en certification TLS et j'ai bon espoir que les personnes venant lire cette news en soient (des experts ou au moins des personnes ayant mis en place du https, ce qui n'est pas mon cas).
Si je vends un objet connecté disposant d'une interface web de configuration, qu'il est possible pour l'utilisateur de changer l'adresse IP et pourquoi pas de le placer derrière un DNS.
De ce que je comprends pour ne pas avoir dans le navigateur le message de connexion https non vérifiée qui fait fuir les utilisateurs, il faut obtenir un certificat auprès d'un organisme reconnu et utilisé par les navigateur web.
Le hic c'est que le certificat délivré par l'organisme est associé à un DNS unique, hors mon objet connecté est paramétrable.
Y a t'il une solution existante pour avoir du https transparent pour l'utilisateur (pas de message de certificat inconnu) pour ce cas d’utilisation ? J'ai l'impression que non, mais à tout hasard mieux poser cette question d'abord.
J'ai l'impression que la seule solution serait de laisser la possibilité à l'utilisateur d'uploader des certificat sur le dispositif.
Du coup vu que let's encrypt à l'air automatisable c'est peut être un bon candidat pour intégration direct dans mon dispositif (arrêtez moi si je me trompe) ce qui serait peut être encore plus simple pour l'utilisateur.
Question subsidiaire : peut on faire un certificat pour une adresse IP (voire adresse IP locale) et non un DNS ?
Question subsidiaire2 : si quelqu'un sait comment ceci est géré sur les switch configurable avec interface web (genre les CISCO d'entreprise ou autre truc bien sérieux/chère) ?
Merci d’avance, désolé pour la question un peu décousue et juste un tout petit peu en lien avec let’s encrypt
# Date Time input en retard sur IEedge
Posté par trancheX . En réponse à la dépêche Firefox ? 42 !. Évalué à 6.
IE/Edge supporte les inputs de type date/mois/heure … et Firefox est maintenant le dernier des navigateurs moderne à ne pas l'implémenter (non Safari ça compte pas dans les navigateurs moderne).
C'est vraiment dommageable car des développeurs de webapp qui vont avoir besoin d'un input de type date ou time c'est quand même beaucoup plus courant que ceux qui vont ressentir un manque de Reflect API.
Mais bon apparemment y a du nouveau sur ce bug et j'espère que finalement tout viendra à point à qui sait attendre.
[^] # Re: Développeur en C++
Posté par trancheX . En réponse à la dépêche Firefox : version 38. Évalué à 1.
C'est pas faux : je sais pas pourquoi j'ai mis RAII dans me dernière phrase, ça la fausse en partie; toutes mes confuses.
Il fallait donc lire :
"Et si Gecko n'utilise pas C++11 (en tout cas pas dans les endroit concernés) c'est sûrement simplement car sa création date d'avant l'arrivé de C++11."
Car pour faire un moteur comme Gecko, il doit y avoir à quelque endroits l'utilisation de pointeurs, qui à l'époque n'ont sûrement pas étaient écris à l'aide de pointeurs intelligents (encore que, avec boost ça aurait peut être était possible, je ne sais pas depuis combien de temps ces pointeurs existent dans boost)
[^] # Re: Développeur en C++
Posté par trancheX . En réponse à la dépêche Firefox : version 38. Évalué à 6. Dernière modification le 15 mai 2015 à 14:38.
Et de préciser une chose, puisqu'on compare C++ à Java :
Existe-t-il ne serait-ce qu'un seul moteur de rendu Web+JS codé en Java qui soient utilisable pour faire un navigateur web capable de concurrencer Firefox/Chrome/IE/Opera ?
La réponse est : non, aucun PC n'aurait assez de CPU et surtout de mémoire vive pour faire tourner cette merveille.
Note: on pourrait penser que je viens de faire un troll, mais non je n'ai pas trouvé de navigateur écrit en java qui arrive à la cheville des navigateur actuel (qui utilise tous des moteurs de rendu en C++ : Gecko/WebKit/Presto/Trident)
Par contre :
ça oui, sans aucun doute c'est du troll
Et si Gecko n'utilise pas C++11 et la RAII (en tout cas pas dans les endroit concernés) c'est sûrement simplement car sa création date d'avant l'arrivé de C++11
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . En réponse à la dépêche Firefox 35 heures. Évalué à 1.
Merci, c'est beaucoup plus clair.
J'avais déjà vu la Browser API, mais je me rendais pas compte de tous ce qu'il y manquait.
Donc en gros : y a encore beaucoup de travail, mais lorsque Gecko aura les API nécessaires (historique, navigation, certificats, …), et lorsque ce sera finalisé : le navigateur de FirefoxOS (qui lui n'utilise pas XUL) sera complet et rien n'empêchera de faire un Firefox Desktop avec browser.html ou équivalent.
J'ai bon ?
PS: Grâce à cette discussion je viens de découvrir SlimerJS. Je ne savais même pas que ce genre d'outil existait, faudra que je test à l'occasion pour les units test dans au moins 1 projet. Donc encore une fois merci
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . En réponse à la dépêche Firefox 35 heures. Évalué à 0.
C'est sympa de la part de RedHat et de Collabora de
collaborercontribuer.En fait je me référais à ces explications, et c'était ce que je comprenais de :
Mais ces explications semble ne plus être d'actualité, et en cherchant un peu il apparaît que tu as raison : Cairo est une dépendance, donc Mozilla-Azure n'embarque pas ou plus son propre Cairo.
(et je note au passage qu'il y a maintenant un backend Skia, l'équivalent de Cairo utilisé par Chrome)
Je rejoins ton avis sur la non intégration de chromium à l'OS, et sa mauvaise gestion des écrans haute résolution sous Linux. Moi perso avec Firefox je configure la police système en plus gros : ça s'applique sur les barres de titres et onglets et après dans Firefox je vais dans préférence->contenu augmenter la police.
Là je ne vois pas en quoi un toolkit tout entier est nécessaire pour aller chercher une info système. Et la gestion du HiDPI c'est hyper simple à faire en web (depuis le temps que tous le monde fait du responsive design).
Mozilla développe et maintient son toolkit web (Gecko) avec son moteur de dessin (Azure) qui est multiplate-forme, qui dispose de plusieurs backend etc. Gtk fait beaucoup doublon au milieux de tout ça.
L'interface de Firefox OS est géré entièrement par cette pile graphique (Gecko/Azure) alors il doit pas manquer grand chose pour gérer entièrement celle de Firefox Desktop.
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . En réponse à la dépêche Firefox 35 heures. Évalué à 1.
Effectivement d'après ceci, le problème est double : si Mozilla veut passer à Wayland/Mir en continuant de s'appuyer sur Gtk il faut :
1. passer de Gtk2 à Gtk3 (nécessaire pour Wayland), ne pose pas de problème à Gecko en lui même mais en pose tous plein pour les plugins (comme flash) faisant des appels à Gtk2
2. enlever+remplacer dans le code tout les appels spécifique à X11
Je penses que les dev Mozilla savent ce qu'ils font mais j'ai l'impression que maintenant que le web (HTML5) est un outil pouvant remplacer un toolkit, on pourrait en profiter pour remplacer Gtk.
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . En réponse à la dépêche Firefox 35 heures. Évalué à 1.
Il est vrai que d'avoir des applications toute dépareillés n'est pas du plus bel effet.
Cela dit ce qu'il y a de beaux avec une application web c'est qu'en changeant de CSS ont peut s'adapter au look de l'OS (c'est ce que fait Qt avec son propre gestionnaire de style très inspiré de CSS).
Sur ce point Chrome et Gtk* sont des mauvais exemples puisque l'un ne reprend pas la charte graphique de l'OS et l'autre s'accorde très mal avec KDE.
*: donc par extension Firefox sous linux/KDE est un mauvais exemple d'intégration.
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . En réponse à la dépêche Firefox 35 heures. Évalué à 2.
Peut être que je ne me rend pas compte mais j'ai l'impression que Gtk n'est utilisé que pour quelque trucs accessoires : aller lire la config système (couleur/font etc) et la boite dialogue système d'impression (sur ce dernier point Chrome m'ouvre sa boite de dialogue, faite en web je suppose).
Je comprend très bien qu'il soit plus rapide à court terme d'utiliser Gtk, mais je trouve que c'est beaucoup un toolkit tout entier* pour juste quelque actions qui pourrait être remplacés par un code plus beaucoup plus simple.
*: (et à fortiori un Gtk3 qui va embarquer son propre Cairo en plus de celui déjà présent dans Mozilla-Azure)
Je trouverai dommage que beaucoup d'heure de R&D soient utilisées à passer de Gtk2 à Gtk3 (puisque ça fait longtemps qu'on a parle c'est que ça doit pas être simple ce portage) alors qu'elles pourraient être employées sur Mozilla-Azure + browser.html pour mettre au point une interface qui serait utile à toute les plate-forme Win/OSX/Linux-Gtk-Qt et pourquoi pas même android etc.