nud a écrit 941 commentaires

Après faut voir aussi les droits sur l'univers BSG, le design des appareils, tout ça.

tout dépends de ce qu'on entend par "installer",

make vs make install.

Compiler quelque chose n'impose pas de l'installer, par contre cela impose d'installer toutes les dépendances de compilation. C'est le problème mentionné ici: le mainteneur de lfs ne veut pas installer systemd mais la fusion lui impose d'installer les dépendances de compilation de celui-ci, qui comprennent la libdbus.

Après il pourrait probablement installer la libdbus sans installer le dbus complet, comme c'est déjà le cas sur une debian serveur par exemple.

systemd dépend de la libdbus car il propose une "activation dbus" similaire à l'activation par socket, mais utilisant un nom dbus. Si on avait un autre mode d'IPC de type bus répandu il dépendrait probablement de la lib idoine pour fournir également une activation paresseuse pour ce protocole d'IPC.

Tu n'as pas bien suivi.

la fusion nous oblige à installer systemd

Non, la fusion oblige juste à compiler systemd, mais udev reste fonctionnellement indépendant.

les dev de Dbus avaient plus ou moins promis que la fusion n'empêcherait pas l'usage de Dbus sans systemd

Non, On peut toujours utiliser dbus sans systemd… Le problème est ici udev, qui est compilé avec systemd, qui nécessite la libdbus.

Gnome (et sa galaxie d'applications) qui va nécessiter systemd

Non, Gnome utilise juste de certaines interfaces dbus simples implémentées par systemd et qui pourraient être implémentées par d'autres démons de la même façon (genre org.freedestktop.hostname1). On ne peut pas même parler de dépendance: si tu n'as pas de démon qui implémente cette interface tu peux juste pas changer ton hostname depuis la GUI.

les gars de LFS ont déjà fait un script pour compiler Dbus sans systemd

Non, dbus a pas besoin de systemd, c'est udev qui a été fusionné, pas dbus.

Sauf que systemd est idéalement placé pour se rendre compte que le service disparaît au moment où il disparaît. Idem s'il bloque. Il reçoit le sigchld, il contrôle le socket, bref, il est où il faut pour ça.

Les services externes de monitoring (mon, monit, god et consorts) ne font que du polling, donc si tu vérifies tes services une fois toutes les 5 minutes tu cours le risque de rester avec un service down pendant 4:59 au pire des cas. Systemd peut réagir immédiatement.

J'attends la sortie de wheezy justement pour pouvoir utiliser systemd sur des serveurs, justement pour avoir cette surveillance qui fonctionne bien mieux avec systemd qu'avec mon.

Juste car c'est le même auteur, tu peux tout à fait faire tourner ces petits programmes triviaux sans systemd, certaines distro le font. Ça utilise probablement un .so commun mais ça marche aussi avec sysvinit.

la tentative de dépendance obligatoire dans GNOME.

Ce point a déjà été discuté précédemment. Gnome ne dépend pas de systemd, mais il dépend d'interfaces D-Bus diverses (genre org.freedesktop.hostname1) spécifiées au sein de freedesktop.org, et qui sont pour l'instant uniquement implémentées par des petits utilitaires fournis par systemd. Ces interfaces sont triviales (vraiment) et peuvent être implémentées facilement par un autre outil.

Il s'agit juste de déplacer la maintenance des outils spécifiques aux distros au sein des distros au lieu de les garder au niveau de l'upstream, car de toute façon les outils upstream (system-tools-backend) ne supportaient que redhat, debian et opensuse.

Note que la distinction PC vs Mac n'a plus vraiment de sens, de nos jours c'est plutôt PC livré avec Windows vs PC de marque Apple livré avec MacOSX.

Non je suis le pape et j'attends ma sœur.

Non, c'est à côté

Par contre Samsung risque d'empocher des indemnités de rupture pas piquées des vers.

Et encore, tout le monde n'était pas là.

Il ne me demande pas de l'accepter, je sais afficher l'image. Et ça marche sur les autres pages. Vous voyez l'image sur la page des journaux vous?

Bon en fait c'est nul, le logo n'apparaît pas sur la page d'accueil, juste le texte.

Elles sont toutes innovantes ?

La liste n'est peut-être pas exhaustive mais elle n'est pas non plus limitée à XUL, une bonne dose des applications citées utilisent juste NSS, SpiderMonkey ou Rhino…

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 pourquoi le ferait-il? En quoi utiliser une version forkée de xulrunner change-t-il quelque chose à cela? Ou bien le problème est-il pour l'éditeur de logiciel d'attendre que Mozilla ne release une nouvelle version de xulrunner ? Côté éditeur, on peut soit packager une nouvelle version de xulrunner soi-même, soit compiler son paquet statiquement. On fait des trucs similaires dans ma boite. Si au contraire c'est Debian qui veut la nouvelle version de Thunderbird, elle se débrouillera pour fournir un package du dernier xulrunner.

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.

Comme Qt, qui fournit QtQuick, Webkit, un client HTTP, un environnement de scripting javascript et plein d'autres trucs. Qt n'est pas une lib classique, c'est une plateforme, un framework embarquable. Est-ce pour autant que tout le monde forke et patche ? Non. Il s'agit juste de faire en sorte que la plateforme fournisse tout ce qui est nécessaire, et d'ajouter ce qui manque pour avoir une plateforme satisfaisante pour tous les usages, et réduire d'autant les coûts de maintenance des différentes applications.

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.

Je sais que Mozilla assume pleinement le fait que xulrunner est avant tout la plateforme de Firefox et refuse d'implémenter des choses qui ne sont pas dans l'intérêt immédiat de Firefox. Il n'y a pas de problème intrinsèque avec cela, il faut juste alors arrêter de promouvoir xulrunner comme une plateforme de développement généraliste.

Et ce genre de situation arrive souvent dans les projets XulRunner conséquents, que j'ai vu passé.

Pourquoi cela n'arrive-t-il pas avec les éditeurs basés sur webkit ? Peut-être est-ce un problème de design ou de modularité du moteur gecko, ou de refus d'ajouter des fonctionnalités qui ne sont pas directement nécessaires à Firefox (bien que avec les nouveaux webdev tools…) ? D'un autre côté, j'imagine mal un truc comme sunbird ou thunderbird nécessiter une modification du moteur de rendu. Un cas particulier ne devrait pas servir de justification pour une mauvaise pratique généralisée.

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)

Non, c'est un raccourci malsain, car comme dit plus haut, le fait de pouvoir le faire n'implique pas qu'on ne peut pas faire autrement. On peut distribuer une appli compilée statiquement, et de toute façon le problème est le même pour les dépendances déjà présentes dans la distro (cairo, gtk+, libx* et toutes les autres). Un cas particulier ne devrait pas servir de justification pour une mauvaise pratique généralisée.

Ben, en fait, oui. On travaille avec deux projets libres, l'un en GPL et l'autre sous copyright attribution double licence. Dans l'un des cas on remonte les patches, dans l'autre pas (la politique, tout ça, je passe les détails). On est une très petite boite.

Donc oui, dans les faits ça me coûte moins cher en temps de remonter les patches une fois que de maintenir ma pile de patches et de les mettre à jour à chaque nouvelle version mineure du projet. Dans le premier cas il m'a fallu quelques jours pour faire accepter le patch, dans l'autre il me faut chaque fois une journée, au mieux, pour adapter les patches. Après genre cinq versions, la première façon de faire est clairement gagnante en terme de temps dépensé.

Quant à l'intérêt, encore une fois c'est l'intérêt immédiat comparé à un intérêt à plus long terme. Au moment de commencer le jeu il est bien plus facile de forker. Après un an ou deux de galère et de patches divers je me demande si certains ne préféreraient pas avoir moins de code à maintenir et utiliser un moteur commun. Moins de code à maintenir, c'est aussi plus de temps à investir dans d'autres aspects du développement, comme de nouvelles fonctionnalités, un meilleur gameplay ou de nouveaux niveaux. Cependant, passer d'un fork à l'utilisation d'un moteur commun ne se fait pas en une nuit, et donc, encore une fois l'efficacité à court terme est de conserver son fork.

Qt et Gtk sont utilisés sous Windows, pas de fork. Donc en utilisant votre logique, ce n'est pas un problème de Windowsien. Merci de m'aider à la démonstration.

En terme de conclusions hâtives tu ne te fais pas prier non plus. Gtk et Qt sont développés principalement sur un environnement Linux et donc profitent de l'idéologie locale du packaging, tandis que les moteurs de jeux et xulrunner sont principalement développés sous Windows et donc souffrent du fait que les développeurs sont moins familiers avec le concept de packager les choses une fois pour toute. Il n'y a strictement rien de plus à en conclure.

Google forke pas mal de projets (y compris Linux pour Android)

Et ils sont en train de remonter plein de patches dans le noyau upstream. Le fork est très efficace en terme de ressources sur le court terme, mais très coûteux sur le long terme. Le fait de tout forker pour lancer un nouveau projet est différent du fait de maintenir tout cela sur le long terme.

De plus, sans vouloir pinailler, comparer google et ses milliers de développeurs avec des projets libres qui luttent pour en trouver quatre…

Elle peut le faire. Elle peut aussi ne pas le faire. Ah oui, on oubliais le monde parfait des packageurs…

L'idée ici est de laisser aux distros l'option de le faire. Le cas actuel est que les distros ne peuvent pas le faire car les versions de xulrunner ou ioquake3 utilisées sont intrinsèquement incompatibles.

Pour le cas du "je veux la dernière nightly", il existe toujours l'option générique du tarball lié statiquement, c'est tout à fait orthogonal avec le fait d'avoir une version patchée du moteur de jeu. Skype fournit une version linux compilée statiquement avec Qt, mais je doute fortement que leur version de Qt soit patchée.

Tant que tu payes le mec pour remonter le patch upstream et le faire valider… Encore de la théorie. Les gens vivent dans la pratique (même sous Linux).

Sauf qu'en pratique, pousser un patch upstream est plus efficace (moins coûteux) que de le maintenir. Et je ne parle même pas des forks "complets" qui imposent de maintenir la totalité du moteur une fois pour chaque jeu plutôt qu'une fois pour toute, en corrigeant toujours les mêmes bugs et en redéveloppant toujours les mêmes features.

Cela ne nécessite pas d'être payé. Les gens qui maintiennent Ogre ne sont pas payés il me semble (ça a peut-être changé récemment), il s'agit d'un moteur de jeu sous la forme d'une lib, et tous les gens qui l'utilisent l'utilisent tel quel sans patches. Ils distribuent les jeux sous windows, et souvent il est également possible de les packager sous linux en utilisant le package existant libogre3d (hors jeux proprios évidemment). Ceci prouve que c'est surtout une question de manque d'intérêt et/ou de mésentente ou compétition entre les projets, sur l'idée que "cet effet génial va différencier mon jeu donc j'aurai plus de succès".

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..

La distro peut aussi tout simplement packager la nouvelle version, c'est comme cela que cela fonctionne. Sinon, autant packager tout en statique et on évite du même coup les différences de version des autres paquets.

utilisation d'une version patchée de XulRunner ou buildée différement.

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. Les fonctionnalités spécifiques (comme le support python) pourraient tout à fait être des plugins. Pour les patches custom, il suffit d'attendre la release de xulrunner, comme pour toutes les autres bibliothèques sous linux.

Pour moi, le fait que tout le monde utilise sa propre version patchée de xulrunner exhibe juste un problème dans la maintenance de xulrunner lui-même, probablement parce que Mozilla n'est pas intéressé à maintenir celui-ci comme une lib classique (ceci a déjà été vu avec les histoires autours de mozembed par exemple)

Bref, le paquet XulRunner officiel de Debian n'est pas très utile pour pas mal de projets xulrunner, à cause de son ancienneté notamment.

Idem, si Debian package une application, ils se débrouillent pour que les dépendances soient à jour. Cela fonctionne pour tous les autres programmes.

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.

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.

Reposer sur des versions patchées des libs n'est jamais une bonne idée.

liboobs n'a pas encore été descendu en flammes?

faire appel à un maître d’œuvre pourrait me revenir à moins cher?

Il doit y avoir confusion. Si tu construis ta maison, de facto c'est toi le maître d'œuvre.

Pour construire ta maison, soit tu passes par une entreprise générale, soit tu fais par corps de métier séparés (càd le gros œuvre, puis les châssis, la couverture, la plomberie, l'électricité, etc.).

Tu paies toujours une commission à l'entreprise générale qui sous-traite habituellement la plupart (parfois tous) des corps de métier. Ça peut quand même revenir moins cher si tu ne prends pas d'options car ils achètent les composants en grande quantité, mais cet avantage disparaît dès que tu choisis un carrelage non standard, par exemple.

Si tu fais par corps de métier séparés, alors ça peut revenir moins cher, mais ça prend plus longtemps car tu n'auras pas la possibilité d'aussi bien gérer le planning. Forcément, l'entrepreneur a cinq chantiers en parallèle, s'il a un retard sur l'un il peut mettre son couvreur sur un autre chantier, et vu qu'il est bon client il passe avant.

De toute façon, le prix en fonction de la surface habitable c'est juste une première approximation.

Si tu montres ton intérêt tu auras sans doute un devis plus détaillé, car le prix dépend également de la structure de la maison. Une maison de deux étages, carrée et à toit plat coûtera moins chère qu'une maison baroque aux volumes compliqués. Les matériaux jouent énormément également.

Le premier prix permet juste de donner le ton et de faire fuir les rêveurs sans le sou.

http://blog.assembla.com/assemblablog/tabid/12618/bid/87044/Trimming-the-Application-Fat.aspx

Personne ne cherche la vérité ici. Le seul souci, c'est que si les gens viennent sur linuxfr c'est (trop) souvent pour casser du bois sur les projets qu'ils n'aiment pas pour une raison ou pour une autre.