Laurent J a écrit 2948 commentaires

Nan mais faut l'ignorer. Il est vénère contre Mozilla parce que tu comprends, quand ils ont appuyés l'utilisation de VP8 &co, ça aurait pu faire chier son business (qui est principalement basé sur h264) "putin encore un codec à supporter", "putin en plus il est gratuit".

Et là, ils vont verrouiller les extensions en obligeant à signer ses extensions avec Mozilla : ça va grave faire chier son business car toutes les merdewares livrées avec son soft qui installent des extensions cochonwares ne vont plus pouvoir pourrir les profils Firefox.

Faut le comprendre quoi.

Ouai, et moi aussi (comme Zenitram envers Mozilla), je peux supputer/troller/dénigrer n'importe quoi sur un business (la video & mediainfo) que je ne connais pas.

si mais je ne les mets pas dans le svn et github ;)

Pourquoi ça ?? o_O

Personne ne peut contribuer donc ?

suivi des suppressions de méthodes devenus obsolètes

Je ne comprends pas trop ce que tu veux dire là. Si tu supprimes, tu casses forcement la rétro-compatibilité. Si tu ne supprimes pas, tu te retrouves forcément avec du code mort.

Les systèmes de modules (avec leurs propres vues, contrôleurs et cie…) dans les frameworks, ça ne date pas de ZF, Sf ou même de mk. Jelix le fait depuis 2006 (qui est un fork de Copix qui le faisait déjà en 2004). Et possible qu'on puisse en trouver d'autres avant 2009…

et puis un framework qui garde de la retrocompatibilité aussi longtemps que mkframework, ça me laisse songeur.

• soit c'est un framework qui n'évolue pas (en terme d'API et d'organisation), et donc que son auteur n'évolue pas dans sa manière de coder ou ne tient pas compte des problèmes rapportés par ses utilisateurs (ne vient pas me dire que l'API parfaite existe)
• soit c'est un framework qui est très minimaliste. Mais alors les utilisateurs auront tout de même des problèmes de rétrocompatibilités avec l'utilisation de lib externes. Et probablement aussi qu'ils n'utiliseront ce fmk que pour les petits projets.
• soit c'est un framework qui maintient N version de la même API, mais cela veut dire très certainement de plus en plus de code mort à chaque nouvelle version (celui qui utilise une version d'une API, n'utilise pas les autres forcément). Et le code mort, c'est mal (contributions compliquées si pas bien documenté, code parsé pour rien par PHP, ou fichiers inutiles etc…).

Il faut trouver un juste milieu quand on maintient une lib ou un framework. Les usages, les technologies, les besoins évoluent au fil du temps, et donc forcément, les APIs. Et il faut de temps en temps virer les vieux trucs, faire le ménage.

Alors j'aimerais bien comprendre dans quel cas tu te situe parmi ceux que je viens d'évoquer, ou alors comment arrives-tu à garder cette rétrocompatibilité aussi longtemps ?

Sur Jelix, j'ai fait des compromis :

• les versions (1.0, 1.1, 1.2….) sont maintenues pendant 3 ans environ (aboutissant à des releases 1.0.1, 1.0.2 …) : uniquement des corrections de bugs et de trous de sécu. Mais pas de changements d'API (sauf si vraiment la correction d'un bug majeur l'oblige mais ça n'est pas arrivé en 9 ans ou je ne m'en souviens pas).
• Une version peut faire évoluer une API. Déjà, très important, cette modification est documentée dans la documentation de migration (exemple), en plus des nouveautés (exemple). Si il s'agit de paramètres supplémentaires, j'essaye de faire en sorte que ce soit des paramètres optionnels. Ou alors je créé une nouvelle méthode ou classe et je marque l'ancienne "déprécié" quand cela reste pertinent. L'API dépréciée ne disparait du code source qu'au cours des futures version. Cela laisse le temps de migrer vers la nouvelle API.
• Pour une version majeure (de 1.x à 2.x) : je me laisse la liberté de casser les API (c'est ce qui se passe pour la future 2.x, après 9 ans de dev sur la 1.x). Il faut savoir un jour faire table rase sur certains aspects, et arrêter de se trainer des boulets (qui n'en étaient pas forcément à l'époque où ils ont été développé). Un code "moderne", une API moderne, ça attire plus les utilisateurs (et les contributeurs). Et puis ça fait du bien pour les nouveaux projets.

il suffit d'aller dans certaines confs informatiques pour s'en rendre compte

ça ne veut rien dire du tout. Il y en a qui utilisent des laptops légers quand ils sont en déplacement dans ce genre d'endroit (et les macbook air/netbook sont parfait pour ça) . Par contre, au bureau ils utilisent des vraies machines, avec des vraies écrans (oui je troll un poil, mais personnellement, je ne peux pas travailler 5 jours sur 7 sur des machines type macbook air avec leurs claviers et écrans minuscules).

Mon laptop n'est pas "léger", je le balade partout où je vais. Mais au bureau, j'utilise un desktop (avec double ecran). Et je branche mon laptop au réseau (pour faire les synchro ou autre), en ethernet, pas en wifi car l'ethernet a un débit plus grand (je suis en gigabit) et plus stable.

Donc oui, une prise ethernet, ça reste utile pour pas mal de monde.

oui enfin bon, c'est pas parce qu'il y a d'autres insectes pollinisateurs (dont il serait intéressant de savoir leur proportions par rapport à la population des abeilles), qu'il faut les détruire.

D'ailleurs, accessoirement, si les pesticides et autres produits à la con tuent les abeilles, ça doit certainement tuer aussi les autres insectes (pollinisateurs)…

Enfin, les petits animaux pollinisateurs sont loin d'égaler les abeilles en terme de volume de fleurs pollinisées il me semble….

Etre fin n'empêche pas d'avoir une prise ethernet. J'ai utilisé des portables "no-name" qui en avaient. Les contacts d'une prise ethernet n'étant que d'un seul coté de la prise, le coté opposé se referme sur le coté des broches (comme une pince) quand il n'y a pas de câble..

tek pour "technique". Les plongeurs tek sont des plongeurs qui font des plongées (très) techniques, donc très préparées, avec du matos "hightech". Il s'agit souvent de plongées avec recycleur, et/ou avec des mélanges gazeux spéciaux (trimix…), ou encore des plongées à +de 60m etc… Il faut donc soigneusement les préparer (profil de plongée, durées, paliers etc, à la minute près) à cause des contraintes imposées par l'utilisation des mélanges gazeux ou du matos "complexe".

Bref, les plongées tek ce ne sont généralement pas des balades de touristes. Auparavant, c'était réservé aux professionnels (ex: ceux qui bossent sous l'eau dans des conditions difficiles, comme sur les plateformes pétrolières, les "explorateurs" en eau profonde etc..), mais ça à tendance à se démocratiser dans le monde de la plongée loisir (parmi ceux qui ont les moyens).

En terme de fonctionnalité, il est peut-être encore jeune par rapport à d'autres. Mais il a quand même de gros atout de mon point de vue :

• ça fonctionne sous linux alors que toutes les autres solutions ne fonctionnent que sous windows et/ou mac
• c'est libre
• projet vivant et on peut contribuer/rapporter des bugs (va donc faire ça par exemple avec la solution Mares par exemple, qui est de plus en plus merdique à installer et à utiliser soit-dit en passant)
• c'est compatible avec une large gamme d'ordinateur de plongée : tu peux garder ton historique de plongée sur plusieurs années, même si tu changes d'ordi entre temps.
• pas besoin de connexion internet pour l'utiliser (pratique quand on est en vadrouille).

Je n'ai pas essayé les solutions web : mes données, je les garde pour moi ;-)

Bref, ce sont toutes les raisons qui m'ont fait choisir Subsurface (jusqu'à 3.9, puisque hélas depuis je ne plonge plus).

c'est un pistolet laser à gauche ?

Je dirais que c'est un Nerf, idéal pour se défouler sur les collègues :-)

À l'époque où je cherchais, j'avais vu des bureaux mécaniques chez Ergotron, comme ce modèle là. Par contre, pour se le procurer en france, c'est une autre paire de manche.

Du coup, j'ai opté pour un électrique, de chez MDD (Ergonomic master: pas de lien, car leur site est cassé en ce moment). On en trouve chez des revendeurs en France. J'en ai eu pour 900-1000 Euros HT (payé par ma boite). Et j'ai rajouté un range-cable ikea.

C'est plus cher qu'IKEA, mais : il ne bouge pas et le plateau est de très bonne facture. Bref, à priori donc de meilleure qualité. Je n'ai pas eu à me plaindre de la motorisation.

Cependant, il y a les mêmes reproches :

• boutons pas très ergonomiques
• à peu près le même temps de changement de position
• les colonnes télescopiques "inversées", et il m'est moi aussi arrivé de coincer la poubelle :-)

Mais je dirais qu'à part les boutons, les reproches sont inhérents à ce type de bureau.

Si un jour je dois changer, je prendrais mon courage à deux mains pour me procurer un bureau mécanique.

En ce qui concerne l'utilisation, je confirme que rester debout trop longtemps, c'est pas terrible. L'immobilisme trop long debout me créer des douleurs dans le dos. Du coup j'essaye de bouger un peu mais pas évident. Je pense moi aussi à essayer le tapis de marche :-)

Cependant, je ne reviendrais pas sur le bureau uniquement "assis". C'est agréable de pouvoir bosser debout de temps en temps, en particulier dans les moments de réflexion. Dans ces moments là, je peux "tourner en rond" debout dans la pièce, et de temps en temps noter/chercher des trucs sur mon ordi ou un calepin sans avoir à me pencher ou me rassoir. Idem aussi quand je fais des allers-retours entre mon bureau et mon tableau blanc. Pratique aussi quand je classe/range/cherche de la paperasse avec les aller-retour entre le bureau et l'armoire.

Toutefois, le bureau assis-debout n'est pas suffisant pour l'entretien du corps : il faut se forcer à bouger dans la journée (marche, vélo etc). Du coup, au lieu d'utiliser la voiture pour aller chercher le pain ou aller à la poste, j'y vais maintenant à pied :-)

J'ai un synology. C'est bien du linux mais ça ne repose pas sur une distro classique. On peut y accéder en SSH, et l’environnement c'est busybox.

Comme le QNAP, on a une belle interface web pour le gérer.

Par contre, le processeur est vraiment faiblard (j'ai un DS212+). ça va pour la plupart des tâches, mais pour certaines, pas du tout. Par exemple, il indexes les photos et vidéos pour qu'on puisse y accéder par dnla ou une appli web embarquée, et génère en même temps des miniatures : ça prend une éternité (plusieurs jours pour quelques giga de photos). Insupportable. Du coup je génère les miniatures sur mon desktop (avec les bons noms et repertoires), et je les balance sur le nas en même temps que les ladites photos. Il a ainsi juste l'indexation à faire (il liste les photos dans une base postgresql, pas sûr que ce soit le plus efficace d'ailleurs).

Sinon dans l'ensemble ça va j'en suis content.

Oui, c'est un peu de l'hébergement distribué en fin de compte.

Un peu la philosophie du net quoi…

On peut lancer un script, et c'est à peu près tout

Et c'est déjà énorme !

En fait, je trouve cela très sympa au final : c'est hyper souple, tu fais ce que tu veux. Tout ce que tu veux. C'est pas comme les trucs immonde comme jenkins où tout est finalement limité par ce que propose les plugins. Les plugins, soit ce sont des usines à gaz parce qu'ils veulent prendre en charge tous les paramètres de l'outil qu'ils proposent de manipuler, soit il n'y a pas tous les paramètres, et alors un jour on se retrouve coincé.

Au début j'étais un peu comme toi déçu, "ça ne fait que ça". Mais à l'usage en fait c'est très bien. j'utilise aussi dans le meme genre strider-cd. On peut se développer des plugins pour faciliter les choses si on en a marre de taper toujours les meme scripts.

De plus, l’accès au répo n’est pas nécessaire pour le rendre libre, un tgz avec les sources peut suffire, même si ce n’est pas pratique.

Ce n'est pas pratique si il espère recevoir des contributions. Mais à priori, ce n'est pas son but premier. Donc qu'il garde son dépôt git, et qu'il mette en téléchargement un tgz. Github n'est pas nécessaire.

Maintenant, si il accepte les contributions, alors là oui, un miroir sur github est nécessaire. ça sera plus simple pour les contributeurs et pour lui. (perso, les patchs par mail, je ne suis pas fan :-) )

Pour github ou autre : (…)

Autre solution que j'ai adopté : github comme repo principal + strider-cd sur mon serveur. On enregistre strider-cd sur github, on configure strider-cd pour qu'il lance les builds et tout le toutim (bref, le script qu'il a indiqué sur le hook du commit dans son dépot actuel), et il a ses builds et tests à chaque commit.

rien n'empêchera de faire un Firefox Desktop avec browser.html ou équivalent.
J'ai bon ?

tout à fait.

Qui plus est, si ces API sont standardisées (ce qui est le but ultime de mozilla), que le format "webapp" est lui aussi standardisé, et tout ça implémenté dans d'autres moteurs, on pourrait imaginer à terme lancer notre browser.html avec blink ou webkit par exemple.

Mais il y a encore beaucoup de chemin à parcourir, malgré que l'on puisse dés aujourd'hui lancer une webapp indifféremment avec Firefox desktop, Firefox pour Android ou encore FirefoxOS (sauf si ladite appli utilise les api de téléphonie par exemple : ça va moins bien fonctionner sur le desktop :-)).

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

De rien :-)

ça me semblerai être un sacré échec de ne pas pouvoir utiliser HTML5 pour implémenter les quelques controls/boite de dialogues de Firefox en HTML/JS/CSS.

Ce n'est pas implémenter des boites de dialogues qui posent problème, c'est tout ce qu'il y a dans un navigateur.

browser.html, ce n'est pas un fichier html que l'on va mettre dans firefox en remplacement de XUL, et qui va tourner en mode privilégié comme le XUL. browser.html est une webapp. qui tourne donc dans une sandbox.

Du coup, comment dans l'interface on affiche par exemple l'historique de navigation (pour le gestionnaire de l'historique) ? comment accéder à la liste des mots de passe (pour le dialog de gestion des mots de passe) ? Comment modifier les préférences (pour une bonne partie des paramètres de la boite de préférences) ? Il y a aussi la gestion des "commandes" de l'interface, la gestion du copier coller, la gestion de la fenetre etc…

Bref, un navigateur, ce n'est pas juste afficher une page web, c'est aussi est surtout pouvoir gérer plein de truc autour. Et pour cela, il faut utiliser des API interne. Chose facile quand on est en XUL, parce que le code JS/XUL de Firefox (et celui des extensions XUL) tourne en mode privilégié (le mode chrome), et donc on peut appeler n'importe quel composant interne XPCOM.

Et le souci ici est que l'interface de browser.html, comme toutes les webapps, comme toutes les applis de FirefoxOS, tournent dans une sandbox. Pas d’accès direct à ces composants internes.

Il faut donc exposer, dans le contexte HTML, des API qui permettent de pouvoir faire ce qu'on pouvait faire en mode chrome.
Ces API étant souvent "sensibles", il y a un système de permissions.

Un exemple d'API, c'est l'api de navigation. Ça l'air con de gérer des onglets et la navigation : suffit de gérer des iframes, et dans chaque iframe, tu charges un site. Oui mais pas seulement. Comment surveiller l'état du chargement d'une iframe, afin de pouvoir afficher un throbber dans la barre d'url ? Comment stopper le chargement d'une iframe ? comment detecter justement que l'iframe démarre le chargement d'une nouvelle page, pour mettre à jour l'url dans la barre d'url ? Comment récupérer les informations sur le certificat SSL du site chargé afin de pouvoir les afficher quand on clique sur le cadenas ? etc etc etc… En mode chrome, aucun souci. Mais quand tu es dans une page HTML qui n'a pas les privilèges chrome, t'es à poil. En html standard, tu n'as pas d'API pour tout ça.

Il faut donc développer ces API (qui, techniquement, à leur tour, appellerons les apis interne de gecko). Tu as un début avec la browser API, mais ce n'est pas suffisant. Il faut une API pour accéder au contenu de l'historique complet, une API pour accéder aux certificats, et des centaines d'autres API. Et créer/gérer les permissions qui vont avec.

Bref, il y a encore beaucoup, beaucoup de boulot. C'est d'ailleurs la raison pour laquelle le "navigateur" dans FirefoxOS est encore si pauvre en fonctionnalité.

D'ailleurs, tu remarqueras que pour faire les trucs de bases (copy/paste/undo/redo) de browser.html, tout ça est géré dans un fichier XUL lancé en mode chrome.

Note: il y a eu le même problème pour les extensions de type jetpack (non xul donc), qui tournent dans une sandbox JS. Il a fallu exposer dans cette sandbox un certain nombre d'API pour accéder aux API internes de Gecko. Et implémenter tout ça ne s'est pas fait en un jour (raison pour laquelle on a encore accès à un module "chrome" pour accéder directement aux composants internes).

les anti-virus décents ont un impact négligeable sur un desktop

Autant les autres points je suis à peu près d'accord (et encore, ça dépend ce qu'on fait exactement), autant pour les antivirus, non.

Parce que quand il faut que tu compiles, sur une machine un peu juste au niveau puissance, et qu'en plus tu ne peux pas toucher à l'antivirus (le mettre en pause par exemple), c'est juste horrible, j'en ai fait maintes fois l’expérience. Le pire étant l'antivirus programmé par les admin pour faire un scan complet en plein milieu de la journée (vécu) : la machine (assez vieille) freezait quasiement.

j'ai du mal à comprendre pourquoi ces décideurs ne comprendraient pas ta demande.

Tu dois faire un boulot. Il te faut un outil ayant certaines caractéristiques, sinon tu ne peux pas réaliser le boulot demandé.

Personnellement, je ne sais pas ce que je pourrais ajouter de plus comme argument. Pas de matos ? pas de développement.

Ah tiens, si, j'ai une idée. Demande à ces décideurs, ce qu'ils penseraient si on leur filait un nokia 3310 plutôt que leur iphone6, ou un ordi portable sans marque premier prix vieux de 10 ans pour réaliser leur powerpoint ou tableaux excel…

Sinon, il y a un contrat. Puisque le matériel est fourni par le client, n'y a-t-il pas une clause d'obligation de moyen par le client ?

pourquoi des modules comme Ghostery, AdBlock+

Ghostery ? le truc qui, si tu fais pas gaffe, envoi tout ce qu'il bloque à la société qui le développe, pour ensuite… revendre ces données aux sociétés de pub/tracker &co ?

Adblock+, qui a lui aussi un drôle business model ?

Je ne pense pas que ce soit une bonne idée pour Mozilla de les inclure de base… (même si je les utilise tous les deux)

Bon, on pourrait imaginer qu'ils développent ou choisissent une solution plus éthique, mais cela pose d'autres problèmes :

• il faut maintenir des filtres : ça prend beaucoup de temps à gérer
• j'imagine que cela est interdit dans les contrats commerciaux qu'ils ont avec les moteurs de recherche, en autre Google, qui sont aussi des régies publicitaires…

Pour Firefox, mon raisonnement est le même : on a un moteur html qui est lancé, pourquoi ne pas l'utiliser partout.

C'est exactement l'idée qu'ont eu les développeurs quand ils ont crée Gecko : utiliser le moteur de rendu pour l'interface utilisateur (1998). D'où le XUL (un langage XML + js pour le comportement + CSS pour l'apparence). Je pense qu'à l'époque, ils n'ont pas utilisé le HTML parce qu'il était très basique, cela aurait nécessité de trop gros changement dans le HTML et le CSS (trop de balises et styles propriétaires) : d'où un nouveau langage. De plus le XUL a des fonctionnalités très spécifiques comme les overlays, l'usage des DTD pour les traductions et bien d'autres choses.

Bref, on a un moteur qui sait prendre n'importe quel langage XML et HTML, et sait l'afficher en le stylant en CSS.

browser.html, c'est très bien, mais ils manquent encore des choses en HTML pour faire tout ce qu'on peut faire en XUL, pour qu'il remplace ce bon cher browser.xul.

Et puis abandonner XUL, cela voudrait dire abandonner une grosse majorité des extensions… XUL va disparaitre, mais c'est pas pour demain. Il y a énormément de boulot.

Ne serait-il pas plus pertinent de ne plus avoir de Xul/Gtk3/Gtk2 ni Xul/Cocoa ni Xul/(Windows je ne sais quoi), en utilisant une interface web dans gecko lui même, par exemple : browser.html

Euh… Non…

Gtk ne sert pas qu'au XUL. Je dirais même, pas trop à XUL. Conçernant XUL, GTK sert juste à savoir des infos comme les couleurs systèmes, accéder aux fontes système etc. XUL, ce n'est que du HTML++ : tout est stylé en CSS. Il est vrai aussi que XUL s'appuie sur le toolkit (gtk, cocoa ou Windows) pour dessiner les boutons et quelques autres trucs d'interfaces. Et tu sais quoi ? c'est dessiné en indiquant la propriété CSS appearance. Qui sert aussi en HTML puisque cette propriété était prévu dans la spec css3-ui et reportée dans css4, mais cela n’empêche pas qu'elle soit implémentée dans Firefox et Webkit.

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.

Bref, XUL ou HTML, un navigateur a besoin d'un toolkit comme gtk et autre, en plus d'une lib purement graphique.

Aujourd'hui je pense que Arch a vraiment imposé sa domination sur le monde GNU/Linux

mouahahah ptdr mdr lol

(désolé)
..
..
(ou pas, on est vendredi après tout :-) )

non, piraterie peut se dire : http://www.larousse.fr/dictionnaires/francais/piraterie/61129

Mais vu que je passe beaucoup de temps à coder et que je n'ai pas publié grand chose, j'aurais peut être pu passer ce temps à étudier Python plutôt que m'énerver contre la "mauvaise" modernisation de PHP :)

<Ironie> Ouuuuh là!! Attention, tu va être TRÈS décu. en effet, beaucoup de lib et d'applis s'installe avec PIP, qui est très similaire à Composer. Tu ne vas pas pouvoir faire totalement du dev à contre courant de ce que l'écosystème propose :-p </Ironie>