Laurent J a écrit 2933 commentaires

Okay merci :-) J'essaierai ça ce week-end

Merci pour l'astuce. Je crois que je vais configurer mon laptop comme ça :-)

Maintenant, juste une question de newbie en utilisation des niveaux d’exécution (disons que je ne me suis jamais amusé avec) : le fait d'appeler une commande init, ça ne va pas te déconnecter ou relancer certains programmes ? On peut lancer ça quand on est sous gnome/kde par exemple ? ça ne va pas redémarrer gnome/kde ?

PS: j'imagine bien que ça va arrêter les services qui sont en K dans le nouveau level, mais pour les services qui sont communs à l'ancien et au nouveau ?

Beaucoup préfèrent un github tout joli avec des effets javascript à un gitweb (ou carrément l'utilisation de git en ligne de commande).

mmm… tu n'as pas dû regarder ce qu'était github.

gitweb, ce n'est qu'un navigateur pour un dépôt Git. Github ça comporte quand même beaucoup plus de fonctionnalités.

Après je ne vois pas l'utilisation de github en contradiction avec l'utilisation de git en ligne de commande.

J'utilise git tout les jours, en ligne de commande, et pour partager, j'utilise github. ça m'évite de monter un serveur git, ça évite à mes contributeurs de monter eux aussi leur serveur git pour que je puisse récupérer leur contributions, et ça me permet de faire de la review de code plus facilement.

Bref, tu compares des choux et des carottes.

Et utiliser des applis web/gui desktop, n'est pas en contradiction avec utiliser des outils en ligne de commande. Ils sont tout les deux complémentaires.

oups. oui en effet désolé. Je me suis mélangé les pédales. Les vacances, c'est décidément trop fatiguant.

On utilise pas des dénominations différentes pour désigner une voiture en fonction de son pays d'origine.

Bah, si, en anglais, voiture se dit "car". En allemand "wagen" etc..

Donc pourquoi faudrait-il avoir le même mot dans toutes les langues pour désigner un être humain qui va dans l'espace ?

J'ai été déçu quand la France a eu ses premiers cosmonautes, grâce à l'Union soviétique avec Jean-Loup Chrétien et grâce aux États unis d'Amérique avec Patrick Baudry, et qu'elle s'est crue obligée de forger un nouveau terme sans justification autre qu'un orgueil national mal placé

Il y a peut-être un orgeil national mal placé, mais je crois qu'il y a plutôt une autre raison. Il faut se replacer dans le contexte : à cette époque, surtout avec Jean-Loup Chrétien, nous sommes en pleine guerre froide. Avec ce partenariat (proposé par les russes), la France est prise en sandwich : d'un coté, allié des américains, et de l'autre, cette opportunité d'envoyer un français dans l'espace, avec l'aide de "l'ennemi" qui est de l'autre coté du mur. Si, officiellement, on avait appelé Mr Chrétien, un "astronaute", ça aurait probablement déplu aux russes. Si cela avait été "cosmonaute", cela aurait déplu aux américains. Bref, diplomatiquement, d'un coté comme de l'autre, cela aurait été tendu. Alors hop, appelons le, un "spationaute", cela ne va froisser personne. Et en plus c'est plus logique dans notre langue.

D'ailleurs si on suit ta logique, pourquoi tout le monde n'a pas appelé une voiture "voiture" dans les autres pays. Pourquoi d'ailleurs tout le monde ne parles-t-il pas la même langue ?

bof, c'est pas l'économie des salaires de 4-5 gars qui vont permettre de payer toutes ces pubs…

et un os qui t'interdit d'installer autre chose que ce qui est fourni par une boutique unique

à priori, tu as encore quelques libertés sur Mac : tu n'es pas obligé de passer par cette boutique pour installer un logiciel.

parfois/souvent ( rayer la mention inutile)

il faut que je raye les deux. Il manque le choix "toujours".

Elles sont toutes innovantes ?

à toi de voir..

Joost, Zoomcreator, Etna etc, oui c'était innovant. De mon point de vue en tout cas…

Est-ce pour autant que tout le monde forke et patche ? Non.

Tu es allé dans toutes les boites qui font du Qt ? et sur des projets internes ? Je suis sûr que non, donc tu ne peux pas affirmer cela.

Si ce n'est pas possible, c'est que xulrunner n'était pas le bon framework pour développer l'application. Si c'est suite à un manque de volonté de la part de Mozilla, tout pareil.

Le choix d'un framework ne se fait pas seulement sur la facilité de patcher en upstream etc.. Le choix se fait aussi sur les technologies, sur ce que cela offre pour répondre à des besoins. Par exemple, développer (ou intégrer dans l'application) un navigateur web basique avec xulrunner, se fait en 5 minutes, et sans environnement de compilation ou autre. Avec webkit, c'est quand même moins évident, faut quand même un minimum d'heures.

il faut juste alors arrêter de promouvoir xulrunner comme une plateforme de développement généraliste.

Je ne sais pas où tu as vu où Mozilla, ou quiconque, y compris moi, promeut encore XulRunner. J'ai arrêté de promouvoir XulRunner le jour où Mozilla avait annoncé qu'ils n'en ferait pas un produit. Même si cela ne m'empêche pas de l'utiliser pour certains projets, ce n'est pas quelque chose que je propose absolument à mes clients ou que je le cri sur tout les toits.

Pourquoi cela n'arrive-t-il pas avec les éditeurs basés sur webkit ?

C'est une blague ? Tu prend les versions stables de toutes les applis et navigateurs utilisant webkit, pas une n'utilise la même version de webkit. D'ailleurs les développeurs web s'en plaignent. Surtout qu'avec Webkit, tu as plusieurs backend possible pour telle ou telle partie, ce qui fait que tu n'as pas un webkit identique.

D'ailleurs, si tu regardes dans debian, libqt4-webkit n'utilise pas par exemple le paquet libwebkit-1.0-2. Tu as donc au moins deux versions de webkit dans debian.

D'un autre côté, j'imagine mal un truc comme sunbird ou thunderbird nécessiter une modification du moteur de rendu.

XulRunner, ce n'est pas seulement un moteur de rendu.. M'enfin, je n'ai plus trop le temps d'expliquer ce qu'est XulRunner, Gecko, l'ecosystème Mozilla etc…

On peut distribuer une appli compilée statiquement

Oui, et bien ? Je ne comprend pas. C'est ce que je dis non ? Des projets fournissent leur propre XulRunner (d'ailleurs le binaire xulrunner est souvent renommé). C'est pareil que de fournir une appli avec des libs compilées statiquements, donc non partagées avec d'autres applis.

(ne sommes nous pas en train de nous prendre la tête alors qu'on est d'accord ?)

https://developer.mozilla.org/en-US/docs/List_of_Mozilla-Based_Applications

https://developer.mozilla.org/en-US/docs/List_of_Former_Mozilla-Based_Applications

Et encore ce n'est pas exhaustif, et il y a plein de projets non publics.

Tu parles de payer le dév pour remonter les patches, je me demande comment quantifier les ressources gaspillées à porter les modifs de chaque appli d'une version à l'autre de XulRunner.

Quand tu suis un projet un minimum et que tu connais bien les sources, je t'assure que porter les modifs d'une version à une autre est souvent bien moins couteux que de proposer en upstream.

Proposer en upstream sur un projet aussi gros que Mozilla, peut consommer énormément de temps, parce que le patch ne peut pas plaire, parce qu'on te demande de le refaire comme-ci, comme-ça. Corriger ton patch, ça peut être bénéfique bien sûr. Et puis il y a tout un workflow à suivre : proposition du patch, review du patch, vérifier que tout les tests passent, commiter, attendre une nouvelle fois que les tests des machines de build passent etc. Et pour Mozilla, attendre 12 à 18 semaines que ce soit dans une release officielle (et encore, avant le fast release cycle, fallait attendre 1 ou 2 ans). Pour d'autres projets, attendre peut-être des mois et des mois…

Chez Mozilla, j'ai eu des patchs refusés parce que ça impactait ou était incompatible avec tel ou tel composant externe ou appli mozilla. Le souci, c'est que moi, pour mon appli, j'en avait rien à fiche. Le patch fonctionnait parfaitement pour mon appli, c'était le principal. Parce que la majorité des applis que je développe, c'est pour des clients, ou pour mon employeur (quand j'étais salarié :-)). J'ai des délais pour réaliser une appli. Dans mon exemple, rajouter des heures et des heures pour adapter le patch pour qu'il fonctionne pour tout le monde en upstream n'aurait pas été possible dans le planning du projet. Donc voilà, pas d'intégration upstream pour certains patchs (en tout cas, pas dans un premier temps, et pas dans les délais de réalisation du projet).

Dans bon nombre d'entreprise, c'est pareil (et j'en vois plein des boites…). les patchs sont proposés en upstream que si le budget le permet, que si on a le temps, ou que si c'est vraiment critique. Ou que si la boite est impliqué à fond dans le développement de la lib, du framework etc..

Et encore, je ne parle pas des cas où il faut attendre qu'un contributeur en face se bouge pour faire la review ou commiter (quand on n'a pas le "karma" nécessaire dans le projet upstream). Et pour les projets de libs un peu mort…

Bref, voilà, ça peut être coûteux de contribuer en upstream, dans le cadre d'un projet d'entreprise. Alors oui, on se retrouve avec des applis qui nécessitent des versions personnalisées de bibliothèque, comme c'est souvent le cas avec XulRunner.

La distro peut aussi tout simplement packager la nouvelle version, c'est comme cela que cela fonctionne

dans un monde idéal. Mais un éditeur de logiciel ne va pas attendre 4 ans que la nouvelle Debian sorte, pour avoir le paquet officiel de la dernière version de XulRunner. Et encore, quand une debian sort, bon nombre de paquet ne contiennent pas les dernières releases des libs.

"Bonjour monsieur le client, alors, je vous ai développé votre appli avec XulRunner comme vous le souhaitez, mais il va vous falloir attendre 3 ans ou plus que la prochaine debian stable sorte pour en profiter, parce que la version actuelle de XulRunner est bien trop vieille pour les besoins de l'application."

C'est principalement une conséquence du fait que xulrunner n'est pas pensé comme étant une bibliothèque partagée par plusieurs applications. Du coup ils doivent la modifier.

Non, ils doivent la modifier, parce qu'ils ont des besoins spécifiques que ne fourni pas le XulRunner standards.

Il ne faut pas voir XulRunner comme une lib classique, mais comme une plateforme, un framework embarquable.

Les fonctionnalités spécifiques (comme le support python) pourraient tout à fait être des plugins.

Tout ne peut pas se faire par des plugins. Par exemple, à l'époque où je développais mon éditeur XML wysywyg, j'avais plein de modification dans le coeur du code de l'éditeur de gecko. Impossible d'avoir l'éditeur sous forme de plugin, ça fait parti intégralement du coeur de gecko pour plein de raisons (liés très intimement au moteur de rendu par exemple). Et ce genre de situation arrive souvent dans les projets XulRunner conséquents, que j'ai vu passé.

Pour les patches custom, il suffit d'attendre la release de xulrunner, comme pour toutes les autres bibliothèques sous linux.

Tout les patchs customs ne sont pas forcément utile en upstream car trop spécifiques (c'était le cas de mon éditeur). Donc ça ne sert à rien d'attendre une release de XulRunner.

si Debian package une application, ils se débrouillent pour que les dépendances soient à jour.

Toutes les applications ne sont pas forcément packagées, et encore moins pour toutes les distros ou versions de distros. Donc l'utilisateur devrait utiliser le XulRunner proposé dans sa distro, bien souvent incompatible pour les applis complexes (surtout celles qui contiennent des composants binaires)

Si le patch en lui-même n'est pas intéressant, c'est probablement qu'il faut ajouter un hook au bon endroit, ou que le programme devrait faire autrement.

Oui genre, on peut mettre des hooks partout et puis surtout, en upstream, ils vont accepter ta tonne de patchs insérant des hooks partout… (et je passe sur le coté performance quand il y a des tonnes de hooks)

XulRunner a souvent été utilisé pour des applis innovantes, qui avaient besoin de choses en plus, ou des comportements différents dans le moteur de rendu ou dans des composants.

à l'interface incompréhensible… Faut lire tout une page pour commencer à comprendre comment ça fonctionne. En terme de facilité d'utilisation, on a vu mieux…

On pourrait comparer cette situation avec l'exemple (ouhouh, l'appeau à troll) des projets Mozilla

Non, je ne pense pas :-)

Si la plupart des projets d'applis basés sur XulRunner, sont livrées avec leur propre xulrunner, c'est pour d'autres raisons :

• utilisation d'une version de XulRunner plus récente que celle proposée par le paquet officiel de la distrib. Et si l'appli a besoin d'une version plus récente, c'est bien souvent pour profiter des dernières API de Gecko etc..
• utilisation d'une version patchée de XulRunner ou buildée différement. Par exemple, BlueGriffon, en plus d'utiliser une version plus récente de XulRunner pour permettre aux utilisateurs d'utiliser les dernières nouveautés HTML5 / CSS3 dans la création de leur page web, contient aussi des patchs, qui ne sont pas encore intégrés en upstream (mais peut-être ce n'est plus le cas aujourd'hui, je crois que Glazou a fait le maximum pour pouvoir utiliser une version non patchée). Autre exemple, l'éditeur Komodo, qui utilise lui aussi XulRunner, a besoin du support python dans les XPCOM. Le flag de build pour cette fonctionnalité n'est pas activée par défaut dans XulRunner. etc..

Bref, le paquet XulRunner officiel de Debian n'est pas très utile pour pas mal de projets xulrunner, à cause de son ancienneté notamment. Cela peut convenir pour des petits projets 100% XUL, mais dés que l'on veut faire une appli complexe, on a souvent besoin d'un XulRunner spécifique en version ou patché.

D'ailleurs, pour ioQuake3, tu as souligné un peu le même souci : divers projets de jeux utilisent une version patchée différente de ioQuake3. L'utilisation d'un libioquake3 commun n'est donc pas possible, non pas parce que les développeurs ils ont la culture windows, mais parce que techniquement ce n'est pas possible. Une solution serait de porter les patchs upstream. mais il y en a probablement qui ne sont pas intéressants pour ioQuake3 et tout les jeux basés dessus.

ok, je comprend.

il refuseront d'héberger du matériel qu'ils ne connaissent pas

Juste une précision, au cas où certains lecteurs auraient des doutes : le matos en question n'est pas tombé d'un camion ou autre, il vient d'une ancienne boîte où j'ai bossé, et acquis légalement :-) (suite à dépôt de bilan)

ça vous intéresserait d'avoir un serveur de secours, même si il date de 2008 ? j'en ai quelques uns à refourguer (gratos pour les associations). Ce sont des Dell, 1U ou 2U, de diverses puissances/capacités.
Si oui, il vous faudrait quoi comme machine en terme de processeur, mémoire et disque ?

y a t'il des personnes autres que chez Mozilla qui ont des accès en écriture aux repository

Bien sûr !!! quelle question  !!??

Moi j'en ai un par exemple. Tout ceux qui contribuent régulièrement peuvent demander un accès en écriture.

J'ai toujours eu l'impression, peut être fausse (ce que j'espère), que Mozilla contrôlait l'intégralité du central.

Euh… non. Ils contrôlent l’accès, c'est à dire qu'ils donnent pas non plus l’accès en écriture au premier venu. Il faut avoir contribuer.

Ensuite, tout contributeur, qu'il soit employé Mozilla ou externe, doit d'abord proposer ses patchs en relecture, avant commit définitif sur le dépôt. C'est la qualité qui est contrôlée, pas la fonctionnalité proposée (enfin bon, on ne peut pas non plus proposer n'importe quoi comme patch, il faut que ça ait un intérêt ou que ça ne casse pas tout et empêche d'avoir un produit inutilisable).

Bref, mes codes ne sont pas réellement collaboratif ;-)

Mozilla est donc plus ouvert que ton projet.

Ok, j'exagère au niveau "unlimited". Mais les budgets de développements et marketing des ces trois grosses boites, sont largement supérieurs à ceux de Mozilla. En comparaison, alors oui, ces budgets paraissent "unlimited".

Ne viens pas me dire que chez MS, IE est développé par 3 gus dans un garage, JE sais, de source sûre, qu'ils sont toute une armada par rapport à Mozilla. Il a bien fallu rattraper d'une part tout le retard, et maintenant tenter de dépasser tout le monde.

mais est-ce aussi ouvert que Linux ou libre office

Je ne vois pas ce qu'on pourrait faire de plus en terme d'ouverture chez Mozilla. Tout est ouvert chez Mozilla.

Tu vas sur le bug tracker, tu proposes ton patch, tu le corriges éventuellement en prenant en compte les remarques des reviewers, et voilà, tu as contribué.

Tu télécharges TB, tu l'installes où tu veux, autant de fois que tu veux, tu peux le modifier, redistribuer .

Bref, Un logiciel GPL classique…

Mozilla possède une trademark sur Thunderbird, tout comme la fondation linux possède la trademark sur "Linux".

Tu peux aussi contribuer sur le code des sites web, le code des outils systemes de Mozilla, et tu peux même devenir sys-admin contributeur.

Tu peux participer aux réunions hebdomadaires sur l'avancement des projets, poser des questions, tu peux participer aux discussions en tou genre sur les newsgroup mozilla, que ce soit pour le dev, la gouvernance du projet etc..

Sérieux, je vois pas en quoi Mozilla serait plus fermé que Linux.

'ai arrêté Thunderbird sur un coup de tête, gonflé par l'auto-détection des comptes qui ne marche jamais et ne te laisse pas le choix de les entrer manuellement.

Tu n'as pas beaucoup cherché. j'ai toujours pu entrer mes paramètres manuellement.

Je ne pense pas qu'ils soient au bord de la banque route. C'est juste qu'ils ont des moyens beaucoup plus limités que Google, Apple, ou Microsoft, qui, eux, ont des équipes beaucoup plus grosses sur leurs projets de navigateurs et d'OS Mobile.

Pour rappel, ces trois grosses compagnies ont des centaines de millions, voir des milliards de dollars en trésorerie. Financement de ces projets : unlimited. Les moyens de Mozilla, même si ça se compte en dizaine de millions, c'est presque pinuts par rapport aux autres. Un exemple : le budget marketing de Google pour Chrome, quand ils ont fait plein de pub en france et ailleurs dans le monde, c'était équivalent au budget de fonctionnement de Mozilla. Sachant ça, tout est dit hein ?

Donc voilà, Mozilla essaye de rationaliser, d'utiliser au mieux les ressources humaines et financières dont elle dispose. Et si elles ne met pas assez de moyens sur Firefox et Firefox OS, on finira par n'avoir que du webkit partout, donc du google/apple partout. Ce serait bien dommage pour le choix de l'utilisateur.

L'avenir est au mobile. Il faut donc investir là dedans. En particulier dans un OS totalement libre et pré-installé sur les appareils mobiles. Ceci afin d'offrir plus de choix aux utilisateurs.

Maintenant, je suis triste aussi que Mozilla n'investissent plus autant dans Thunderbird. C'est mon client mail depuis toujours. C'est le client mail de beaucoup d'entreprises.

Mais il faut se rendre à l'évidence :
- le webmail est utilisé maintenant par une majorité de gens
- il n'y a pas assez de contributeurs sur Thunderbird. Et c'est assez désolant quand on sait que des grosses boites l'utilisent, mais n'investissent pas assez dans le développement. Les développeurs de chez IBM et d'autres boites comme ça, qui bossaient à plein temps sur les projets Mozilla, sont de moins en moins nombreux hélas. Voir ont disparu. Par exemple, l'extension de calendrier, Lightning, ça a été développé en grande partie par des boites comme Oracle et Sun. Et depuis, ils ont retiré leurs billes, et il n'y a presque plus personne qui bosse dessus à plein temps, que des bénévoles ici et là.

Enfin bon voilà, beaucoup vont se plaindre, mais peu ont contribué (que ce soit pour des bonnes ou mauvaises raisons, peu importe, c'est juste un constat). Il faut faire avec. Et peut-être que ça va faire réagir des gens, et qui vont se mettre à contribuer pour faire évoluer les choses…

l'archivage de TB s'active régulièrement en occupant un core à 100% pendant 10-30s.

OH MON DIEU ! Un logiciel utilise le processeur ! VITE, DISONS DU MAL DE LUI !

Oui donc, si tu as 4 cores, ça ne prend au final que 25% des ressources processeur. Avec 8 cores, seulement 12,5% etc..

Et si tu te plains que ça ralentit ta machine, bah désolé, c'est la faute au système, pas au logiciel.

Le logiciel demande des ressources, il les obtient, donc il les utilise. Logique non ?

Moi je me souviens de l'époque où tu avais toujours un court métrage avant le film, deux-trois pub entre les deux + entracte pendant laquelle un(e) vendeu(r|se) parcourait les allées avec ses friandises à vendre. Sans oublier l’hôtesse qui te guidait dans le noir avec sa lampe jusqu'à ton siège quand tu arrivais en retard. Et puis il n'y avait pas tout ces connards (ou connasses) qui prennent la salle pour une cour de récré, ou qui n’éteignent pas leur portable.

Ah, on me dit dans l'oreillette qu'à cette époque, il n'y avait pas ou pas trop encore de portable.

Enfin bon bref, c'était mieux avant.

Les incivilités, le prix, la 3d-qui-sert-à-rien, l'accueil à chier des cinémas d'aujourd'hui, m'ont fait fuir les ciné. Et malheureusement je n'ai pas de petit cinéma de quartier par chez moi ou il ferait bon d'aller voir un film sur un grand écran.

Diantre, ça y est, je suis un vieux (con).