Donc bon, si, ça reste bizarre de se faire héberger par un logiciel proprio, à moins de dire que le libre est un moyen, pas un but, et que les fonctionnalités sont prioritaire sur la liberté (et alors la, c'est très logique d'utiliser Github)
Un des très gros avantages de GitHub et Gitorious, c'est le nombre d'utilisateurs. Héberger son projet sur ce genre de site permet d'avoir plus de contributeurs potentiels (la facilité de faire un fork/clone, meilleure visibilité…). Sur ce point, GitHub a -- il me semble -- une plus grande communauté.
Donc pour moi, le principal avantage de GitHub/Gitorious, c'est la communauté qu'il y a autour. Sinon cgit fait très bien l'affaire. Et pour un projet ayant plus d'importance, je trouve que GitHub n'est pas adapté (pour gérer les traductions par exemple, ou le bugtracker, qui est très limité comparé à un bugzilla).
Donc, pour un petit projet, GitHub/Gitorious permet un hébergement très facile (pas besoin de serveur perso, etc.), tout en profitant du « réseau social » du site. Quand le projet a une plus grande ampleur, il faut se tourner vers une plateforme plus complète, avec un vrai bugzilla etc.
Quel est donc l'intérêt de faire tourner son propre Gitorious sur un serveur perso ? On ne profite pas de la communauté de Gitorious, et on n'a pas une plateforme ayant suffisamment de fonctionnalités pour gérer un gros projet.
Le seul intérêt que je vois, c'est si un jour le site web Gitorious ferme ses portes, comme le code source est là, le développement web n'est pas perdu. Par contre, pour faire revivre le site, il faut déjà des serveurs assez puissants, une très bonne bande passante, etc. Et aussi, mettre en place tous ces serveurs demande certainement beaucoup de boulot et de connaissances. Est-ce que Gitorious explique vraiment comment leur infrastructure est organisée, les scripts qu'ils ont écris pour la maintenance, et tout ce genre de choses ?
Pour pas mal de développeurs, le fait que le genre de service comme GitHub ou Gitorious soit libre ou pas ne change pas grand chose. C'est vu plutôt comme un service, pas comme une application. Et ce qui compte pour un service, c'est la portabilité des données, et le fait de pouvoir changer facilement de service si besoin. Git est de nature décentralisé, donc ça ne pose aucun soucis. Pour d'autres trucs comme le bugtracker, j'ai entendu qu'il y avait moyen très facilement de récupérer toutes les données.
En fait je rejoins assez bien l'avis de Karl Fogel (4e question de l'entretien).
Je suis pas sûr à 100% que ce soit la faute de systemd (au début je pensais à un bug du noyau), mais parfois l'ordinateur redémarre au lieu de s'éteindre avec Fedora 15, alors que Fedora 14 n'avait pas ce bug. J'ai eu ce problème sur deux machines différentes (les deux seules où j'ai installé F15…).
Il faudrait que j'essaye Fedora 16 pour voir s'il y a toujours ce bug.
Un des problèmes d'Asterisk est que les versions que la plupart utilisent ne sont plus supportées. Pour Firefox, ce problème a une moins grande ampleur à vue de nez, puisque la plupart des utilisateurs de Firefox sont sur Windows et qu'il y a normalement des mises à jour qui sont proposées régulièrement.
Mais Asterisk a d'autres problèmes. Comme la dernière phrase du paragraphe le dit, Digium commercialise une version fort différente d'Asterisk, et ils ne testent pas suffisamment Asterisk lui-même et donc il y a des problèmes de stabilité. Mozilla ne commercialise pas une version différente de Firefox, et je n'ai aucun problème avec la dernière version (la 7).
Donc non, Firefox n'est évidemment pas du fauxpen source…
Non, je ne fais pas partie de la communauté d'Asterisk, donc je suis loin d'être une référence.
Ce qui me fait dire que c'est du fauxpen source, c'est en lisant le paragraphe suivant (voir le lien donné par nud) :
The root of the problem in the Asterisk world is that we now find ourselves with one and only one supported version of Asterisk: Asterisk 1.8. And it happens to be a version that few people actually use to run their businesses. The reason for this dilemma is that, other than security fixes, Digium now has dropped support for both Asterisk 1.4 and 1.6, the two products that most folks regard as the “stable releases” and deploy in production systems. So we’re left with a supported version of Asterisk that no one actually is using or selling for a production environment. Indeed, Digium, The Asterisk Company markets a commercial product based upon a completely different version of Asterisk!
C'est un bon exemple du fauxpen source, il me semble. Si Asterisk était développé de manière beaucoup plus communautaire, il y aurait certainement moins de problèmes de stabilité.
Si Digium a un trop grand contrôle sur le développement d'Asterisk, peut-être qu'un fork est encore la meilleure solution. LibreOffice par exemple se porte beaucoup mieux maintenant, à ce que je sache. Pour LibreOffice, pas mal de sociétés se sont regroupées pour créer une fondation. Peut-être est-ce envisageable pour Asterisk ?
Bon, peut-être qu'un fork ne vaut pas vraiment la peine, si par exemple le design général du code d'Asterisk est pourri, et qu'il est difficile d'améliorer ça sans une réécriture complète… Dans ce cas, le mieux (à long terme) est sans doute de se tourner vers FreeSWITCH ou autre. Le problème c'est qu'il manque certainement beaucoup de fonctionnalités par rapport à Asterisk, et que migrer tous les scripts de configuration vers un autre système qui est potentiellement complètement différent, ça demande beaucoup de boulot…
D'autres commits ont suivi, celui que tu pointes est le premier, donc forcément y a pas encore grand chose… Si on regarde le code actuel du fichier, c'est déjà plus compréhensible (le fait que ce code fasse marcher une wiimote, pas le fait de comprendre le code lui-même ;).
Linus continue donc de creuser la question et son patch, qui implémente plusieurs micro‐caches, permet de gagner entre 1 et 2 % de performances sur un noyau compilé avec « make -j ».
La phrase est bizarrement formulée je trouve. J'ai compris d'abord que les 1 à 2% de performances n'étaient atteints (en permanence) que si on compile le noyau avec « make -j », ce qui est complètement absurde.
En fait, ce qu'il faut comprendre (voir message du commit) c'est qu'un « make -j » effectué sur le noyau est maintenant de 1 à 2% plus rapide, car c'est une opération assez couteuse en recherche de chemin de fichiers (ce que le patch optimise).
Si on utilise un nombre non-signé pour représenter le nombre de secondes depuis le 1er janvier 1970, on tiendrait jusqu'en 2106, ce qui est déjà beaucoup mieux.
Le bug de l'an 2038, c'est pcq c'est un nombre signé qui est utilisé, et donc en théorie, avec ce système, on peut dire qu'un fichier date de 1902. Ou mieux, envoyer un mail datant de 1902, ce qui serait assez rigolo (mais je n'ai pas été lire la RFC pour voir si c'était possible, et si ça tombe le mail se base sur une autre unité).
D'ailleurs, pourquoi ils n'installent pas les outils GNU ?
Solaris, HP-UX, AIX, c'est du UNIX, mais c'est aussi du proprio…
Par exemple Solaris est livré avec le compilateur Sun Studio. Ça peut être intéressant de l'utiliser sur une machine SPARC pcq Sun Studio contient des options de compilations spécifiques à ce processeur qui n'existent pas dans GCC.
Pourquoi ils ne contribuent pas plutôt à GCC ou LLVM/Clang ? Ça je n'en sais rien. Peut-être que si Oracle n'avait pas racheté Sun, ce serait le cas, vu que Sun était plus « libre-friendly » (OpenSolaris, …).
Donc le fait qu'ils n'installent pas les outils GNU est sans doute dû au fait que ces OS sont quand même propriétaire, et qu'ils ont développé depuis de nombreuses années des logiciels maisons qui s'intègrent bien à leur OS.
OK, merci pour ces explications, je comprends mieux maintenant. Mais on peut imaginer d'autres systèmes plus simples (si c'est scripté), dans ce cas.
Par exemple, je veux créer un tout nouveau paquet debian pour latexila. Je demande au script de m'initialiser un nouveau dépôt git avec dedans un dossier debian/ vide, et la tarball désarchivée (on donne le lien vers le tarball). On écrit les fichiers qu'il faut dans debian/, on commit, on crée éventuellement des branches, etc.
Le principe est d'avoir un dépôt complètement différent de celui de l'upstream. Quand une nouvelle version sort, on demande au script de prendre la nouvelle version (là, seul le numéro de version serait nécessaire, pas le lien complet). Ce que ferait simplement le script, c'est de tout supprimer sauf le répertoire debian/, et de désarchiver le nouveau tarball.
Ce système suppose qu'on a pas besoin de l'historique complet du dépôt Git upstream. À chaque nouvelle version, il y aurait juste un gros commit, avec plusieurs petits commits contenant les modifications nécessaires dans debian/.
Qu'est-ce qui ne va pas à ce système pour ne pas l'utiliser ? Pour moi ça me semble plus simple, et plus générique.
Je comprends tout à fait l'utilité d'utiliser Git ou tout autre gestionnaire de versions pour gérer le packaging.
Par contre ce que je ne comprends pas, c'est de vouloir avoir dans Git l'équivalent du tarball. Pour un paquet RPM ou un ebuild de Gentoo, une simple URL vers le tarball suffit. Ce qui se trouve dans Git à ce moment-là, c'est uniquement ce qui est spécifique au paquet : le .spec pour RPM, le .ebuild et d'autres petites choses pour Gentoo.
Je ne sais pas comment est construit un paquet DEB, mais je ne pense pas que beaucoup de distribs ont besoin d'avoir dans Git l'équivalent du tarball.
C'est ce que je faisais avant avec les branches releases-x-y, qui correspondaient exactement aux tarballs, et qui étaient parallèles aux branches latexila-x-y. C'est ça qui était reproché.
Rah. Bon, eh bien on se passera de documentation, si je n'ai pas moyen de la compiler.
C'est utilisé entre autres pour les traductions de la documentation, mais pas seulement. Il y a aussi les traductions des templates et des outils de constructions.
Donc comme tu l'as dit plus bas, le mieux est d'empaqueter ITS Tool. De toute façon il sera normalement de plus en plus utilisé à l'avenir. Hé, LaTeXila est à la pointe de la technologie ! (bon, il ne faut pas dire trop fort que GTK+ 2 est toujours utilisé ;)
Ça, ce n'est pas cool, mais au pire, je les ferai moi-même, les commits en question
En-dehors des fichiers *.c, il n'y a vraiment pas beaucoup de différences (2 lignes).
pourquoi fournir les fichiers C générés dans le tarball ? Cela supprime la dépendance à Vala, mais à quoi cela sert-il vu que Vala n'est pas un outil exotique
Vala n'est pas exotique, mais ici c'est la version 0.12.x >= 0.12.1 qui doit être utilisé (donc pas 0.13 ou supérieur, ni les versions précédentes). C'est ça qui est exotique. Sur Gentoo ça ne pose aucun problème puisque plusieurs versions de Vala peuvent installées en parallèle. Mais ce n'est pas le cas de Fedora par exemple.
Pour Fedora, la version 15 utilise Vala 0.12, donc là on peut compiler à partir du Vala. Mais si on veut packager latexila pour F14 (Vala 0.10) ou F16 (Vala 0.14), ce n'est pas possible. Dans ce cas-là, si le C n'était pas distribué avec la tarball, ils devraient le fournir via un patch par exemple, ou faire en sorte de pouvoir installer plusieurs versions de Vala en parallèle.
Ce n'est pas peut-être. Qt est complètement indépendant de Kde
Merci pour cette confirmation.
Pour GTK+, ce n'est pas pcq c'est un des principaux modules du projet GNOME, que c'est utilisé que par et pour GNOME. Mais le développement de GTK est quand même plus orienté pour convenir en premier lieu à GNOME, ce qui est logique, mais qui n'est pas le cas pour Qt/KDE.
C'est sans doute une des raisons pour lesquelles Qt est plus facile pour faire des applis portables.
Rejeter entièrement la faute sur GNOME, c'est du simple troll. La situation est bien plus complexe que ça, comme l'explique très bien ce billet de Dave Neary, dont le premier point est :
Je ne connaissais pas le nombre de Graham (c'est tout simplement impressionnant !), mais la série du nombre parfait ne fait pas du tout le poids (en grammes).
Dire que GNOME a un comportement autiste, ce n'est vraiment pas respectueux. On pourrait dire exactement la même chose envers LaTeXila sur le fait que ce ne soit pas installable sur Windows ou MacOS X. Mais comme on est ici sur LinuxFr, ça va, on ne me traite pas d'autiste. Si ça tombe, en une journée de travail, pour quelqu'un qui s'y connait bien, c'est faisable de porter LaTeXila sur un système d'exploitation exotique. Mais pourquoi ça n'a jamais été fait ? Je pourrais tenter de le faire moi-même. Mais pour ça il faut premièrement que j'ai accès à l'OS en question, et il faut que je passe du temps pour l'installation, et du temps pour le portage en lui-même. D'autres personnes peuvent s'atteler à la tâche, j'en serais ravi. Mais personne ne s'est encore manifesté. La priorité pour moi est tout d'abord de satisfaire mes propres besoins, et ceux des personnes utilisant la même chose que moi (GNU/Linux, GNOME).
Les journées n'ont que 24h, et ça arrive aussi d'avoir une vie IRL. Aussi, beaucoup de développeurs contribuent parce qu'ils en ont simplement l'envie, sur leur temps libre. Donc pour eux, généralement ce n'est pas une mission. D'autres évidemment sont payés pour ça, là c'est différent. Mais les intérêts des entreprises peuvent être différents de l'intérêt de certains utilisateurs.
Donc pour moi le fait qu'une application GTK+ ne s'intègre pas aussi bien dans KDE qu'une application Qt dans GNOME, ce n'est pas du tout dû au fait que les développeurs seraient contre, ou qu'ils ne veulent pas entendre parler de portabilité etc (ce que tu sous-entend je pense par le fait qu'ils seraient autiste). C'est dû à un manque de main d'œuvre. C'est normal que la priorité, pour eux, est que les utilisateurs de GNOME soient tout d'abord satisfaits.
Je ne connais pas bien Qt, mais je pense que plus de développeurs sont payés pour travailler dessus (Nokia, …). Une autre différence est peut-être que Qt est un projet presque complètement indépendant de KDE (quelqu'un pour confirmer ?). Tandis que GTK+ fait clairement partie du projet GNOME.
Pour systemd, c'est différent. Lennart est clairement contre la portabilité, mais ça se comprend, puisque plein de choses spécifiques à Linux sont utilisées. Essayer de rendre systemd portable rendrait le code ingérable.
Si GNOME utilise systemd, et si je ne dis pas de bêtise, ça ne se fera que de manière indirecte via une interface. systemd serait une implémentation de cette interface, qui est optimisée pour Linux. Mais rien n'empêche d'écrire une implémentation portable de cette interface (en gros, adapter le code actuel gérant la session de GNOME pour qu'il colle à l'interface). Évidemment c'est bcp plus facile à dire qu'à faire, et ce qu'il risque de se passer est que systemd soit la seule implémentation de l'interface pendant une ou plusieurs versions de GNOME. À ce moment-là, peut-être que les développeurs ne décideront d'utiliser systemd que quand l'implémentation portable sera écrite. Tout dépend de ce que décident les mainteneurs des modules impactés. Wait and see :)
L'objectif est bien d'avoir une gestion séparée des versions fournies par GSRC et celles fournies par la distribution, en installant par exemple les outils dans un sous-répertoire de son home directory.
Ah oui, donc le principe est assez proche de jhbuild, qui est utilisé intensivement par les développeurs de GNOME pour installer la version en développement de certains modules, sans interférer avec ce qui est installé par la distribution.
Ça risque de ne pas être si simple, malheureusement. Je ne pense pas que ITS Tool soit déjà packagé sur Debian. Mais ITS Tool est plus ou moins le successeur de gnome-doc-utils si j'ai bien compris, donc de plus en plus de modules de GNOME l'utiliseront (bien que ce ne soit pas du tout spécifique à GNOME).
Autre chose, j'ai finalement opté pour une seule tarball qui contient le code source C généré (comme avant donc), mais il n'y a plus de commit dans Git qui correspond exactement au tarball, puisque c'est déconseillé de mettre dans Git des fichiers générés.
Sinon, j'ai créé un ebuild pour Gentoo, j'espère que ça ne prendra pas trop longtemps pour qu'il débarque dans l'arbre de Portage.
[^] # Re: githubçapue, c'est pas libre
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Évolutions du site. Évalué à 1.
Non, c'est séparé du dépôt git.
[^] # Re: github ça pue, c'est pas libre
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Évolutions du site. Évalué à 2.
Un des très gros avantages de GitHub et Gitorious, c'est le nombre d'utilisateurs. Héberger son projet sur ce genre de site permet d'avoir plus de contributeurs potentiels (la facilité de faire un fork/clone, meilleure visibilité…). Sur ce point, GitHub a -- il me semble -- une plus grande communauté.
Donc pour moi, le principal avantage de GitHub/Gitorious, c'est la communauté qu'il y a autour. Sinon cgit fait très bien l'affaire. Et pour un projet ayant plus d'importance, je trouve que GitHub n'est pas adapté (pour gérer les traductions par exemple, ou le bugtracker, qui est très limité comparé à un bugzilla).
Donc, pour un petit projet, GitHub/Gitorious permet un hébergement très facile (pas besoin de serveur perso, etc.), tout en profitant du « réseau social » du site. Quand le projet a une plus grande ampleur, il faut se tourner vers une plateforme plus complète, avec un vrai bugzilla etc.
Quel est donc l'intérêt de faire tourner son propre Gitorious sur un serveur perso ? On ne profite pas de la communauté de Gitorious, et on n'a pas une plateforme ayant suffisamment de fonctionnalités pour gérer un gros projet.
Le seul intérêt que je vois, c'est si un jour le site web Gitorious ferme ses portes, comme le code source est là, le développement web n'est pas perdu. Par contre, pour faire revivre le site, il faut déjà des serveurs assez puissants, une très bonne bande passante, etc. Et aussi, mettre en place tous ces serveurs demande certainement beaucoup de boulot et de connaissances. Est-ce que Gitorious explique vraiment comment leur infrastructure est organisée, les scripts qu'ils ont écris pour la maintenance, et tout ce genre de choses ?
[^] # Re: github ça pue, c'est pas libre
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Évolutions du site. Évalué à 9.
Pour pas mal de développeurs, le fait que le genre de service comme GitHub ou Gitorious soit libre ou pas ne change pas grand chose. C'est vu plutôt comme un service, pas comme une application. Et ce qui compte pour un service, c'est la portabilité des données, et le fait de pouvoir changer facilement de service si besoin. Git est de nature décentralisé, donc ça ne pose aucun soucis. Pour d'autres trucs comme le bugtracker, j'ai entendu qu'il y avait moyen très facilement de récupérer toutes les données.
En fait je rejoins assez bien l'avis de Karl Fogel (4e question de l'entretien).
[^] # Re: systemd
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Lennart casse les logs!. Évalué à 1.
Je suis pas sûr à 100% que ce soit la faute de systemd (au début je pensais à un bug du noyau), mais parfois l'ordinateur redémarre au lieu de s'éteindre avec Fedora 15, alors que Fedora 14 n'avait pas ce bug. J'ai eu ce problème sur deux machines différentes (les deux seules où j'ai installé F15…).
Il faudrait que j'essaye Fedora 16 pour voir s'il y a toujours ce bug.
[^] # Re: Qualité du logiciel
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Asterisk 10 est disponible. Évalué à 2.
Un des problèmes d'Asterisk est que les versions que la plupart utilisent ne sont plus supportées. Pour Firefox, ce problème a une moins grande ampleur à vue de nez, puisque la plupart des utilisateurs de Firefox sont sur Windows et qu'il y a normalement des mises à jour qui sont proposées régulièrement.
Mais Asterisk a d'autres problèmes. Comme la dernière phrase du paragraphe le dit, Digium commercialise une version fort différente d'Asterisk, et ils ne testent pas suffisamment Asterisk lui-même et donc il y a des problèmes de stabilité. Mozilla ne commercialise pas une version différente de Firefox, et je n'ai aucun problème avec la dernière version (la 7).
Donc non, Firefox n'est évidemment pas du fauxpen source…
[^] # Re: Qualité du logiciel
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Asterisk 10 est disponible. Évalué à 1.
Non, je ne fais pas partie de la communauté d'Asterisk, donc je suis loin d'être une référence.
Ce qui me fait dire que c'est du fauxpen source, c'est en lisant le paragraphe suivant (voir le lien donné par nud) :
[^] # Re: Qualité du logiciel
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Asterisk 10 est disponible. Évalué à 2.
C'est un bon exemple du fauxpen source, il me semble. Si Asterisk était développé de manière beaucoup plus communautaire, il y aurait certainement moins de problèmes de stabilité.
Si Digium a un trop grand contrôle sur le développement d'Asterisk, peut-être qu'un fork est encore la meilleure solution. LibreOffice par exemple se porte beaucoup mieux maintenant, à ce que je sache. Pour LibreOffice, pas mal de sociétés se sont regroupées pour créer une fondation. Peut-être est-ce envisageable pour Asterisk ?
Bon, peut-être qu'un fork ne vaut pas vraiment la peine, si par exemple le design général du code d'Asterisk est pourri, et qu'il est difficile d'améliorer ça sans une réécriture complète… Dans ce cas, le mieux (à long terme) est sans doute de se tourner vers FreeSWITCH ou autre. Le problème c'est qu'il manque certainement beaucoup de fonctionnalités par rapport à Asterisk, et que migrer tous les scripts de configuration vers un autre système qui est potentiellement complètement différent, ça demande beaucoup de boulot…
[^] # Re: Wiimote driver
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 6.
D'autres commits ont suivi, celui que tu pointes est le premier, donc forcément y a pas encore grand chose… Si on regarde le code actuel du fichier, c'est déjà plus compréhensible (le fait que ce code fasse marcher une wiimote, pas le fait de comprendre le code lui-même ;).
# Compilation du noyau avec « make -j » plus rapide
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 9.
La phrase est bizarrement formulée je trouve. J'ai compris d'abord que les 1 à 2% de performances n'étaient atteints (en permanence) que si on compile le noyau avec « make -j », ce qui est complètement absurde.
En fait, ce qu'il faut comprendre (voir message du commit) c'est qu'un « make -j » effectué sur le noyau est maintenant de 1 à 2% plus rapide, car c'est une opération assez couteuse en recherche de chemin de fichiers (ce que le patch optimise).
# 5 ans de support pour Ubuntu 12.04 desktop
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche En bref : du 17 au 21 octobre. Évalué à 2.
Au lieu de 3 ans. Voir annonce.
[^] # Re: J'approuve
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 1.
Si on utilise un nombre non-signé pour représenter le nombre de secondes depuis le 1er janvier 1970, on tiendrait jusqu'en 2106, ce qui est déjà beaucoup mieux.
Le bug de l'an 2038, c'est pcq c'est un nombre signé qui est utilisé, et donc en théorie, avec ce système, on peut dire qu'un fichier date de 1902. Ou mieux, envoyer un mail datant de 1902, ce qui serait assez rigolo (mais je n'ai pas été lire la RFC pour voir si c'était possible, et si ça tombe le mail se base sur une autre unité).
[^] # Re: Inconvénient des autotools
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 3.
Solaris, HP-UX, AIX, c'est du UNIX, mais c'est aussi du proprio…
Par exemple Solaris est livré avec le compilateur Sun Studio. Ça peut être intéressant de l'utiliser sur une machine SPARC pcq Sun Studio contient des options de compilations spécifiques à ce processeur qui n'existent pas dans GCC.
Pourquoi ils ne contribuent pas plutôt à GCC ou LLVM/Clang ? Ça je n'en sais rien. Peut-être que si Oracle n'avait pas racheté Sun, ce serait le cas, vu que Sun était plus « libre-friendly » (OpenSolaris, …).
Donc le fait qu'ils n'installent pas les outils GNU est sans doute dû au fait que ces OS sont quand même propriétaire, et qu'ils ont développé depuis de nombreuses années des logiciels maisons qui s'intègrent bien à leur OS.
[^] # Re: Exemple concret de line(1)
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Line meurt. Évalué à 1.
Ça ne m'avance pas du tout pour comprendre l'utilité dans un script…
# Exemple concret de line(1)
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Line meurt. Évalué à 3.
Je ne connaissais pas cette commande, et je ne vois pas trop dans quel cas ça peut être utile.
Tu as un exemple concret ?
[^] # Re: Paquet Debian
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. Évalué à 1.
OK, merci pour ces explications, je comprends mieux maintenant. Mais on peut imaginer d'autres systèmes plus simples (si c'est scripté), dans ce cas.
Par exemple, je veux créer un tout nouveau paquet debian pour latexila. Je demande au script de m'initialiser un nouveau dépôt git avec dedans un dossier debian/ vide, et la tarball désarchivée (on donne le lien vers le tarball). On écrit les fichiers qu'il faut dans debian/, on commit, on crée éventuellement des branches, etc.
Le principe est d'avoir un dépôt complètement différent de celui de l'upstream. Quand une nouvelle version sort, on demande au script de prendre la nouvelle version (là, seul le numéro de version serait nécessaire, pas le lien complet). Ce que ferait simplement le script, c'est de tout supprimer sauf le répertoire debian/, et de désarchiver le nouveau tarball.
Ce système suppose qu'on a pas besoin de l'historique complet du dépôt Git upstream. À chaque nouvelle version, il y aurait juste un gros commit, avec plusieurs petits commits contenant les modifications nécessaires dans debian/.
Qu'est-ce qui ne va pas à ce système pour ne pas l'utiliser ? Pour moi ça me semble plus simple, et plus générique.
[^] # Re: Paquet Debian
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. Évalué à 2.
Je comprends tout à fait l'utilité d'utiliser Git ou tout autre gestionnaire de versions pour gérer le packaging.
Par contre ce que je ne comprends pas, c'est de vouloir avoir dans Git l'équivalent du tarball. Pour un paquet RPM ou un ebuild de Gentoo, une simple URL vers le tarball suffit. Ce qui se trouve dans Git à ce moment-là, c'est uniquement ce qui est spécifique au paquet : le .spec pour RPM, le .ebuild et d'autres petites choses pour Gentoo.
Je ne sais pas comment est construit un paquet DEB, mais je ne pense pas que beaucoup de distribs ont besoin d'avoir dans Git l'équivalent du tarball.
[^] # Re: Paquet Debian
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. Évalué à 1.
Enfin, ce que je veux dire, c'est que peut importe la branche dans laquelle le C se trouve, il ne devrait pas être dans git.
[^] # Re: Paquet Debian
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. Évalué à 1.
C'est ce que je faisais avant avec les branches releases-x-y, qui correspondaient exactement aux tarballs, et qui étaient parallèles aux branches latexila-x-y. C'est ça qui était reproché.
[^] # Re: Paquet Debian
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. Évalué à 3.
C'est utilisé entre autres pour les traductions de la documentation, mais pas seulement. Il y a aussi les traductions des templates et des outils de constructions.
Donc comme tu l'as dit plus bas, le mieux est d'empaqueter ITS Tool. De toute façon il sera normalement de plus en plus utilisé à l'avenir. Hé, LaTeXila est à la pointe de la technologie ! (bon, il ne faut pas dire trop fort que GTK+ 2 est toujours utilisé ;)
En-dehors des fichiers *.c, il n'y a vraiment pas beaucoup de différences (2 lignes).
Vala n'est pas exotique, mais ici c'est la version 0.12.x >= 0.12.1 qui doit être utilisé (donc pas 0.13 ou supérieur, ni les versions précédentes). C'est ça qui est exotique. Sur Gentoo ça ne pose aucun problème puisque plusieurs versions de Vala peuvent installées en parallèle. Mais ce n'est pas le cas de Fedora par exemple.
Pour Fedora, la version 15 utilise Vala 0.12, donc là on peut compiler à partir du Vala. Mais si on veut packager latexila pour F14 (Vala 0.10) ou F16 (Vala 0.14), ce n'est pas possible. Dans ce cas-là, si le C n'était pas distribué avec la tarball, ils devraient le fournir via un patch par exemple, ou faire en sorte de pouvoir installer plusieurs versions de Vala en parallèle.
[^] # Re: Précisions
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. Évalué à 3.
Merci pour cette confirmation.
Pour GTK+, ce n'est pas pcq c'est un des principaux modules du projet GNOME, que c'est utilisé que par et pour GNOME. Mais le développement de GTK est quand même plus orienté pour convenir en premier lieu à GNOME, ce qui est logique, mais qui n'est pas le cas pour Qt/KDE.
C'est sans doute une des raisons pour lesquelles Qt est plus facile pour faire des applis portables.
[^] # Re: Précisions
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. Évalué à 1.
Rejeter entièrement la faute sur GNOME, c'est du simple troll. La situation est bien plus complexe que ça, comme l'explique très bien ce billet de Dave Neary, dont le premier point est :
[^] # Re: une série qui grandit vite
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Qui à la plus grande. Évalué à 1.
Je ne connaissais pas le nombre de Graham (c'est tout simplement impressionnant !), mais la série du nombre parfait ne fait pas du tout le poids (en grammes).
C'est d'ailleurs marrant de tomber sur Knuth.
[^] # Re: Précisions
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. Évalué à 2.
Bon il faut peut-être mettre les choses au clair.
Dire que GNOME a un comportement autiste, ce n'est vraiment pas respectueux. On pourrait dire exactement la même chose envers LaTeXila sur le fait que ce ne soit pas installable sur Windows ou MacOS X. Mais comme on est ici sur LinuxFr, ça va, on ne me traite pas d'autiste. Si ça tombe, en une journée de travail, pour quelqu'un qui s'y connait bien, c'est faisable de porter LaTeXila sur un système d'exploitation exotique. Mais pourquoi ça n'a jamais été fait ? Je pourrais tenter de le faire moi-même. Mais pour ça il faut premièrement que j'ai accès à l'OS en question, et il faut que je passe du temps pour l'installation, et du temps pour le portage en lui-même. D'autres personnes peuvent s'atteler à la tâche, j'en serais ravi. Mais personne ne s'est encore manifesté. La priorité pour moi est tout d'abord de satisfaire mes propres besoins, et ceux des personnes utilisant la même chose que moi (GNU/Linux, GNOME).
Les journées n'ont que 24h, et ça arrive aussi d'avoir une vie IRL. Aussi, beaucoup de développeurs contribuent parce qu'ils en ont simplement l'envie, sur leur temps libre. Donc pour eux, généralement ce n'est pas une mission. D'autres évidemment sont payés pour ça, là c'est différent. Mais les intérêts des entreprises peuvent être différents de l'intérêt de certains utilisateurs.
Donc pour moi le fait qu'une application GTK+ ne s'intègre pas aussi bien dans KDE qu'une application Qt dans GNOME, ce n'est pas du tout dû au fait que les développeurs seraient contre, ou qu'ils ne veulent pas entendre parler de portabilité etc (ce que tu sous-entend je pense par le fait qu'ils seraient autiste). C'est dû à un manque de main d'œuvre. C'est normal que la priorité, pour eux, est que les utilisateurs de GNOME soient tout d'abord satisfaits.
Je ne connais pas bien Qt, mais je pense que plus de développeurs sont payés pour travailler dessus (Nokia, …). Une autre différence est peut-être que Qt est un projet presque complètement indépendant de KDE (quelqu'un pour confirmer ?). Tandis que GTK+ fait clairement partie du projet GNOME.
Pour systemd, c'est différent. Lennart est clairement contre la portabilité, mais ça se comprend, puisque plein de choses spécifiques à Linux sont utilisées. Essayer de rendre systemd portable rendrait le code ingérable.
Si GNOME utilise systemd, et si je ne dis pas de bêtise, ça ne se fera que de manière indirecte via une interface. systemd serait une implémentation de cette interface, qui est optimisée pour Linux. Mais rien n'empêche d'écrire une implémentation portable de cette interface (en gros, adapter le code actuel gérant la session de GNOME pour qu'il colle à l'interface). Évidemment c'est bcp plus facile à dire qu'à faire, et ce qu'il risque de se passer est que systemd soit la seule implémentation de l'interface pendant une ou plusieurs versions de GNOME. À ce moment-là, peut-être que les développeurs ne décideront d'utiliser systemd que quand l'implémentation portable sera écrite. Tout dépend de ce que décident les mainteneurs des modules impactés. Wait and see :)
[^] # jhbuild
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Le projet GNU s'enrichit d'un gestionnaire de paquets. Évalué à 2.
Ah oui, donc le principe est assez proche de jhbuild, qui est utilisé intensivement par les développeurs de GNOME pour installer la version en développement de certains modules, sans interférer avec ce qui est installé par la distribution.
[^] # Re: Paquet Debian
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. Évalué à 2.
Ça risque de ne pas être si simple, malheureusement. Je ne pense pas que ITS Tool soit déjà packagé sur Debian. Mais ITS Tool est plus ou moins le successeur de gnome-doc-utils si j'ai bien compris, donc de plus en plus de modules de GNOME l'utiliseront (bien que ce ne soit pas du tout spécifique à GNOME).
Autre chose, j'ai finalement opté pour une seule tarball qui contient le code source C généré (comme avant donc), mais il n'y a plus de commit dans Git qui correspond exactement au tarball, puisque c'est déconseillé de mettre dans Git des fichiers générés.
Sinon, j'ai créé un ebuild pour Gentoo, j'espère que ça ne prendra pas trop longtemps pour qu'il débarque dans l'arbre de Portage.
Bonnes vacances !