En ce qui me concerne, Haiku est mon système principal depuis quelques années et j'ai vraiment du mal à utiliser Windows et même GNU/Linux (ou j'ai réussi à avoir un système qui fonctionne à peu près comme je veux après plusieurs années à ajuster des fichiers de configuration).
Même si on ne remplace pas Windows sur les PC de bureau, ça fonctionne au moins sur ma machine et c'est dans mon intérêt qu'il y aie plus d'utilisateurs et j'espère, plus de contributeurs. Même si les ambitions ne sont pas forcément gigantesques.
Le côté expérience est également un point important. J'ai appris plein de choses sur le C++ en travaillant dans Haiku, mais aussi sur la façon de gérer un projet libre avec des contributeurs bénévoles, un management sans chef de projet, ce qui a ses avantages et ses inconvénients. Et aussi l'encadrement d'étudiants dans le cadre du Google Summer of Code et du Google Code-In, qui nous oblige à réfléchir à la façon dont de nouveaux contributeurs peuvent aborder le projet.
Il y a aussi un peu un intérêt historique à découvrir le fonctionnement de ces applications BeOS, qui parfois ont essayé de faire des choix différents, en profitant d'être sur une plateforme toute nouvelle, qui pouvait se permettre de bousculer un peu les habitudes. On peut donc avoir un regard avec un peu de recul sur ce qui a marché ou pas.
Le projet HaikuArchives essaie de récupérer le code source d'un grand nombre d'applications pour BeOS. On assure la maintenance de ces applications mais pour les tenur vraiment à jour ce serait un travail beaucoup plus important, donc on fait le minimum pour l'instant…
En parallèle, on a des applications Qt qui sont portées avec une assez bonne intégration (c'est ce qui nous permet d'avoir LibreOffice, par exemple). Mais ces applications ne sont pas "natives", et ne s'intègrent jamais parfaitement dans l'environnement de Haiku, donc on les considère comme une étape de transition, ça permet de combler les trous quand une application native pour Haiku n'existe pas encore.
On pourrait faire la même chose avec GTK, mais pour l'instant on considère plus important le travail sur l'OS et les applications natives.
Je vais répondre en reprenant la description présente sur le site de Haiku:
Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.
L'objectif est donc de fournir un système open source, taillé spécialement pour l'informatique personelle (on entend par là: pas les smartphones, pas l'embarqué, et pas les serveurs). On le voudrait rapide, simple à utiliser et à apprendre, mais cependant puissant (que je traduirait plutôt par flexible).
Un certains nombres de contributeurs à Haiku ne croient pas à "Linux sur le Desktop". Les contraintes sont différentes entre un système embarqué, un serveur, et un PC de bureau, et il nous semble difficile d'arriver à répondre à tous ces besoins à la fois de façon optimale. L'adaptabilité d'un système GNU/Linux à tous ces marchés le force à faire des compromis pour aller plus dans un sens que dans un autre. Et actuellement, on a avec Android des gens qui poussent le support des smartphones, et avec RedHat des gens qui poussent plutôt le côté serveurs. Il y a Ubuntu qui essaie de s'attaquer au segment du desktop, mais je ne sais pas si ça durera encore longtemps. Visiblement leur succès n'a pas été aussi grand qu'attendu.
Il y a donc toujours une place pour un système libre sur ce marché.
Maintenant, la question qui fache, c'est comment on s'y prend pour arriver à prendre cette place avec Haiku. On va avoir besoin de faire évoluer encore plein de choses. Certaines ne posent pas vraiment question, par exemple, il va falloir mettre des efforts sur l'accélération 3D, un meilleur support des imprimantes, améliorer encore le port de LibreOffice. Mais à un peu plus long terme, on a un gros travail à faire pour prendre des décisions importantes pour la version "R2" de Haiku. Quelques exemples: doit-on remplacer les APIs de BeOS par celles de Qt (éventuellement avec quelques extensions)? Combien de temps va-t-on encore s'embêter à maintenir une version à base de gcc2 pour faire fonctionner les applications BeOS? Comment procèdera-t-on pour faire une transition en douceur? Jusqu'à quel point doit-on assurer la maintenance des vieilles applications BeOS? Doit-on conserver le système de fichiers BFS, essayer d'utiliser un système concurrent (par exemple ZFS, XFS ou btrfs), ou bien doit-on développer notre propre système de fichiers pour conserver les particularités de BFS (en particulier l'indexation des attributs étendus)? Jusqu'à quel point doit-on encourager le portage et l'intégration d'applications Qt et est-ce qu'il ne vaudrait pas mieux pousser les gens à écrire des applicatons natives?
Pour l'instant, ces sujets n'ont pas vraiment été abordés. La priorité est d'arriver à faire une version R1, et ensuite de voir si on arrive à construire un écosystème d'applications autour de notre OS. Si vous avez déjà vu ce qu'on démontre sur notre stand, il y a beaucoup d'idées intéressantes (gérer les mails ou une collection de medias avec des attributs étendus, par exemple), mais souvent on fait ça sous forme de démo bricolée avec le navigateur de fichier. La technologies est là mais ça manque souvent d'une interface utilisateur vraiment bien pensée, et au final personne n'utilise vraiment toutes ces belles fonctions. Je pense que le gros du travail va se trouver là dans les années à venir. Et une fois qu'on aura plein d'applications modernes, on aura un peu plus de recul sur les évolutions à apporter à l'API (même si on a déjà quelques idées).
Voilà, c'est ma vision des choses. Cependant j'en ai pas forcément beaucoup discuté avec tous les autres contributeurs du projet, et nous n'avons donc pas forcément fait converger nos idées sur ces différents points, pour l'instant.
Pour Cosmoe, une partie du code devra être modifiée pour fournir les mêmes APIs de façons différente. Par exemple, les BMessages et une grande partie du Media Kit sont implémenté dans Haiku via les "ports", une IPC qui n'existe pas dans POSIX. Mais il est possible de réaliser la même chose en utilisant d'autres IPCs. On est curieux de voir ce que cela donnera au niveau des performances.
D'autres choses sont et resteront impossibles sur un noyau Linux, par exemple la possibilité d'ouvrir un fichier en connaissant uniquement son numéro d'inode (ce qui est possible dans l'API de BeOS mais un gros trou de sécurité).
La notion de window manager est plus ou moins présente. Il ne s'agit pas d'un exécutable séparé, mais plutôt d'un add-on du serveur graphique (appelé "decorator"). Cela dit, l'un ou l'autre choix est valable et n'a pas vraiment d'influence sur l'API publique.
Pour les drivers, en dehors du problème des licences, les deux gros soucis du côté de Linux sont que le code est souvent assez peu lisible (peu de commentaires, etc), et que les API internes ont tendance à beaucoup changer d'une version à l'autre. FreeBSD est, en comparaison, relativement stable, ce qui nous permet de suivre plus facilement leurs évolutions.
On regarde quand même du côté de Linux, par exemple pour les drivers graphiques. Supposément, Gallium3D permet d'avoir des drivers en userland, portables d'un OS à l'autre, mais ça n'a pas l'air d'avoir vraiment marché comme ça. On va peut-être s'inspirer de ce qu'on fait FreeBSD ou DragonFlyBSD pour récupérer les pilotes Linux.
En ce qui concerne les licences, d'une part, certains pilotes Linux sont sous licence BSD, ce qui nous va très bien (par exemple pour les cartes graphiques Intel, il me semble). D'autre part, même si un pilote est sous GPL, il peut être compilé indépendament du noyau et installé séparément, donc ce ne serait pas forcément un problème (l'avantage d'avoir une ABI propre et stable pour les pilotes de périphériques ;) ).
Tu installes mupdf et tu pourras utiliser des commandes vim du type 42g pour aller à la page 42 ou /mot pour chercher un mot (puis n pour passer au résultat suivant). Je ne peux plus m'en passer pour naviguer dans des PDFs.
C'est assez peu mentionné, mais les "anciens" compteurs électroniques (la génération avant Linky) permettait de récupérer ces infos directement chez soit, via un port série situé directement sur le compteur. Pourquoi il faudrait envoyer cette information au fournisseur d'énergie puis… leur demander pour y avoir accès? (accès qu'ils pourraient très bien rendre payant, d'ailleurs).
Donc le côté éducation/information, ça existait déjà, mais ça n'intéressait pas grand monde.
L'intérêt du relevé heure par heure, c'est que le fournisseur d'énergie va pouvoir facturer ça comme il veut (par exemple Direct Energie propose des heures "super creuses" à certaines périodes). On est plus limité à un modèle heures pleines/heures creuses avec des horaires fixes imposés par le distributeur d'énergie.
C'est rigolo 3 minutes mais pas terrible pour communiquer. J'aurais préféré un site plus classique, avec quelques images des années précédentes, ce genre de choses.
Je dirais bien d'aller voir du côté de Jam (la version de Perforce, celle de Boost, celle de Freetype ou celle de Haiku), si c'était pas un outil non maintenu avec 3 forks incompatible… C'est dommage, parce que c'est un bon remplacement de make, avec la possibilité de définir des règles génériques, qui conviendrait pas mal pour ce genre d'usage.
Alors je dois prendre la défense de CMake sur ce point: il y a bien une méthode standard pour la prise en charge des dossiers d'installation, c'est GNUInstallDirs. Le problème, c'est que c'est un ajout relativement récent (ça fait quelques années quand même) et que beaucoup de projets ne l'utilisent pas et codent tout en dur. Et quand c'est utilisé, ça marche tout aussi bien que les autotools (et je dis ça en ayant packagé pas mal de choses pour Haiku, qui fait des trucs bien plus tordus que slackware en terme de chemin standardisés pour les bibliothèques, les manpages, …)
Donc ce n'est pas vraiment la faute de l'outil, mais plutôt d'une mauvaise utilisation (bon et aussi du fait que les dévs de CMake ont pendant quelques temps "oublié" de documenter GNUInstallDirs…
Il y a aussi toute la gestion du packaging (avec CPack) qui de mon expérience, fonctionne plutôt bien, pour générer des tarballs. Et il y a le support de la compilation croisée.
La vraie raison c'est qu'il y a des distributions Linux qui vont gérer la compilation et le packaging. Donc peu de projets ont besoin de le faire d'eux-même.
Non mais RMS plus personne en a grand chose à faire de ce qu'il raconte. Il y a plein d'autres organisations que la FSF qui font la promotion du libre plus efficacement et de façon pertinente. Va voir la SFC ou la FSFE par exemple.
Je vois les choses d'une façon un peu plus positive: le logiciel libre progresse plus vite que les notions d'éthique qui y étaient souvent associées. ça ne veut pas dire que la partie éthique régresse, au contraire.
Je précise que la communauté cmake (et son canal IRC) est pas mal réactive et disponible pour faire les modifications quand c'est nécessaire. Si tu n'es pas forcé de supporter de vieilles versions de cmake, tu pourras donc obtenir de l'aide pour régler ces problèmes, et s'il y a lieu, ce sera intégré dans cmake directement.
Je mentionne aussi au passage le très pratique cpack, qui permet de générer un .deb, un .rpm et/ou un installeur windows sans trop s'embêter. Mais peut être pas encore les .apk (ce n'est pas trop compliqué d'ajouter le support d'un nouveau format de distribution à cpack, cela dit…)
Je plussoie complètement l'utilisation de ninja. Juste pour le plaisir de le lancer une deuxième fois quand le build est fini et de le voir dire tout de suite "nothing to do". Sur un projet comme WebKit, make dans la même situation mets chez moi presque une minute pour arriver à la même conclusion.
Autres avantages:
- Pas besoin de choisir un -j à la main comme avec make, ninja surveille le system load et s'ajuste tout seul (en tenant compte de la charge CPU effective, donc il lancera plus de jobs en parallèle si la compilation est limitée par les accès disques, et moins si elle est limitée par le CPU ou si on fait autre chose sur la machine pendant ce temps).
- Affichage correct de la sortie de la compilation, sans mélanger la sortie de différent threads
- Affichage du nombre de cibles à compiler, ce qui permet de savoir où on en est dans le build du projet
Tu peux expliquer dans ce cas, quel est l'intérêt de faire du libre si on ne veut rien gérer? J'ai un peu de mal à voir ce que ça peut apporter dans ce cas?
Certes. Tu peux faire un "lancer de code" avec une licence sur Github et on en parle plus. Mais dans ce cas il ne faut pas s'attendre à avoir automagiquement des retours positifs et plein de gens qui contribuent. Je suis d'accord, c'est quand même du libre on a rien à reprocher et c'est déjà très bien.
Mais si on veut profiter des retours de la communauté, des contributions d'autres gens, etc, il faut s'investir un peu plus que ça. ça n'est pas nécessaire, mais ça peut être une bonne justification pour faire du logiciel libre.
Les bugs ne sont jamais "hyper évidents". Je suis dev, je teste mon code autant que je peux mais j'ai pas un temps infini, et dans la plupart des projets il n'y a pas d'équipe QA. Donc c'est souvent moins léché qu'un truc développé correctement par une entreprise (on essaie d'améliorer ça mais c'est loin d'être facile).
Donc, contribue: plains toi que la doc est moisie, que ça plante dans tous les sens et que ça tient pas la charge. Avec des exemples précis. Y'a des chances que tu tombes sur un dev qui sera content de t'aider à régler les problèmes (c'est la contrepartie de ne pas avoir d'équipe QA ou support: tu as une ligne directe pour discuter avec les devs du projet, alors profites-en).
ça me rappelle les histoires avec XChat qui a voulu faire payer les binaires Windows. Sauf que c'est un logiciel libre et qu'une autre personne (silverex) fournissait déjà gratuitement les dits binaires. ça s'est mal fini et ça a forké, et maintenant tout le monde utilise hexchat à la place.
Ce modèle ne me semble pas être le plus malin. Je me dirigerais plus volontiers vers la vente de support, et éventuellement le financement du développement de nouvelles fonctionnalités. Faire payer le travail des devs plutôt que le produit fini, donc.
Si, mettre du code sous licence libre a un coût. Tu ne peux pas le nier sinon ça va jamais marcher en entreprise. Par contre, tu peux le justifier et le "vendre": expliquer les bénéfices (en termes d'image, de contributions externes, etc) et montrer que finalement, le coût initial n'est pas si important que ça en regard.
Mais si tu essaies de faire du libre sans investir sérieusement dedans, ça ne marchera pas. Et le décideur pressé va retenir ça: "le libre, ça marche pas on a essayé". Ne gâche pas ta chance et fait les choses proprement dès le début, merci :)
ça va te coûter plus cher de maintenir ton code, qu'à quelqu'un d'autre de faire un fork et de passer un peu de temps à le nettoyer. Et en plus le fork sera 10 fois moins lourd, aura moins de bugs, etc.
Je ne vois pas comment cette recette peut être gagnante.
[^] # Re: Projet intéressant académiquement
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 17 ans. Évalué à 8.
En ce qui me concerne, Haiku est mon système principal depuis quelques années et j'ai vraiment du mal à utiliser Windows et même GNU/Linux (ou j'ai réussi à avoir un système qui fonctionne à peu près comme je veux après plusieurs années à ajuster des fichiers de configuration).
Même si on ne remplace pas Windows sur les PC de bureau, ça fonctionne au moins sur ma machine et c'est dans mon intérêt qu'il y aie plus d'utilisateurs et j'espère, plus de contributeurs. Même si les ambitions ne sont pas forcément gigantesques.
Le côté expérience est également un point important. J'ai appris plein de choses sur le C++ en travaillant dans Haiku, mais aussi sur la façon de gérer un projet libre avec des contributeurs bénévoles, un management sans chef de projet, ce qui a ses avantages et ses inconvénients. Et aussi l'encadrement d'étudiants dans le cadre du Google Summer of Code et du Google Code-In, qui nous oblige à réfléchir à la façon dont de nouveaux contributeurs peuvent aborder le projet.
Il y a aussi un peu un intérêt historique à découvrir le fonctionnement de ces applications BeOS, qui parfois ont essayé de faire des choix différents, en profitant d'être sur une plateforme toute nouvelle, qui pouvait se permettre de bousculer un peu les habitudes. On peut donc avoir un regard avec un peu de recul sur ce qui a marché ou pas.
[^] # Re: Logiciels disponibles
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 17 ans. Évalué à 5.
Le projet HaikuArchives essaie de récupérer le code source d'un grand nombre d'applications pour BeOS. On assure la maintenance de ces applications mais pour les tenur vraiment à jour ce serait un travail beaucoup plus important, donc on fait le minimum pour l'instant…
En parallèle, on a des applications Qt qui sont portées avec une assez bonne intégration (c'est ce qui nous permet d'avoir LibreOffice, par exemple). Mais ces applications ne sont pas "natives", et ne s'intègrent jamais parfaitement dans l'environnement de Haiku, donc on les considère comme une étape de transition, ça permet de combler les trous quand une application native pour Haiku n'existe pas encore.
On pourrait faire la même chose avec GTK, mais pour l'instant on considère plus important le travail sur l'OS et les applications natives.
[^] # Re: Avenir de Haiku
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 17 ans. Évalué à 10.
Je vais répondre en reprenant la description présente sur le site de Haiku:
L'objectif est donc de fournir un système open source, taillé spécialement pour l'informatique personelle (on entend par là: pas les smartphones, pas l'embarqué, et pas les serveurs). On le voudrait rapide, simple à utiliser et à apprendre, mais cependant puissant (que je traduirait plutôt par flexible).
Un certains nombres de contributeurs à Haiku ne croient pas à "Linux sur le Desktop". Les contraintes sont différentes entre un système embarqué, un serveur, et un PC de bureau, et il nous semble difficile d'arriver à répondre à tous ces besoins à la fois de façon optimale. L'adaptabilité d'un système GNU/Linux à tous ces marchés le force à faire des compromis pour aller plus dans un sens que dans un autre. Et actuellement, on a avec Android des gens qui poussent le support des smartphones, et avec RedHat des gens qui poussent plutôt le côté serveurs. Il y a Ubuntu qui essaie de s'attaquer au segment du desktop, mais je ne sais pas si ça durera encore longtemps. Visiblement leur succès n'a pas été aussi grand qu'attendu.
Il y a donc toujours une place pour un système libre sur ce marché.
Maintenant, la question qui fache, c'est comment on s'y prend pour arriver à prendre cette place avec Haiku. On va avoir besoin de faire évoluer encore plein de choses. Certaines ne posent pas vraiment question, par exemple, il va falloir mettre des efforts sur l'accélération 3D, un meilleur support des imprimantes, améliorer encore le port de LibreOffice. Mais à un peu plus long terme, on a un gros travail à faire pour prendre des décisions importantes pour la version "R2" de Haiku. Quelques exemples: doit-on remplacer les APIs de BeOS par celles de Qt (éventuellement avec quelques extensions)? Combien de temps va-t-on encore s'embêter à maintenir une version à base de gcc2 pour faire fonctionner les applications BeOS? Comment procèdera-t-on pour faire une transition en douceur? Jusqu'à quel point doit-on assurer la maintenance des vieilles applications BeOS? Doit-on conserver le système de fichiers BFS, essayer d'utiliser un système concurrent (par exemple ZFS, XFS ou btrfs), ou bien doit-on développer notre propre système de fichiers pour conserver les particularités de BFS (en particulier l'indexation des attributs étendus)? Jusqu'à quel point doit-on encourager le portage et l'intégration d'applications Qt et est-ce qu'il ne vaudrait pas mieux pousser les gens à écrire des applicatons natives?
Pour l'instant, ces sujets n'ont pas vraiment été abordés. La priorité est d'arriver à faire une version R1, et ensuite de voir si on arrive à construire un écosystème d'applications autour de notre OS. Si vous avez déjà vu ce qu'on démontre sur notre stand, il y a beaucoup d'idées intéressantes (gérer les mails ou une collection de medias avec des attributs étendus, par exemple), mais souvent on fait ça sous forme de démo bricolée avec le navigateur de fichier. La technologies est là mais ça manque souvent d'une interface utilisateur vraiment bien pensée, et au final personne n'utilise vraiment toutes ces belles fonctions. Je pense que le gros du travail va se trouver là dans les années à venir. Et une fois qu'on aura plein d'applications modernes, on aura un peu plus de recul sur les évolutions à apporter à l'API (même si on a déjà quelques idées).
Voilà, c'est ma vision des choses. Cependant j'en ai pas forcément beaucoup discuté avec tous les autres contributeurs du projet, et nous n'avons donc pas forcément fait converger nos idées sur ces différents points, pour l'instant.
[^] # Re: Content, enfin presque :)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 17 ans. Évalué à 3.
Pour Cosmoe, une partie du code devra être modifiée pour fournir les mêmes APIs de façons différente. Par exemple, les BMessages et une grande partie du Media Kit sont implémenté dans Haiku via les "ports", une IPC qui n'existe pas dans POSIX. Mais il est possible de réaliser la même chose en utilisant d'autres IPCs. On est curieux de voir ce que cela donnera au niveau des performances.
D'autres choses sont et resteront impossibles sur un noyau Linux, par exemple la possibilité d'ouvrir un fichier en connaissant uniquement son numéro d'inode (ce qui est possible dans l'API de BeOS mais un gros trou de sécurité).
La notion de window manager est plus ou moins présente. Il ne s'agit pas d'un exécutable séparé, mais plutôt d'un add-on du serveur graphique (appelé "decorator"). Cela dit, l'un ou l'autre choix est valable et n'a pas vraiment d'influence sur l'API publique.
Pour les drivers, en dehors du problème des licences, les deux gros soucis du côté de Linux sont que le code est souvent assez peu lisible (peu de commentaires, etc), et que les API internes ont tendance à beaucoup changer d'une version à l'autre. FreeBSD est, en comparaison, relativement stable, ce qui nous permet de suivre plus facilement leurs évolutions.
On regarde quand même du côté de Linux, par exemple pour les drivers graphiques. Supposément, Gallium3D permet d'avoir des drivers en userland, portables d'un OS à l'autre, mais ça n'a pas l'air d'avoir vraiment marché comme ça. On va peut-être s'inspirer de ce qu'on fait FreeBSD ou DragonFlyBSD pour récupérer les pilotes Linux.
En ce qui concerne les licences, d'une part, certains pilotes Linux sont sous licence BSD, ce qui nous va très bien (par exemple pour les cartes graphiques Intel, il me semble). D'autre part, même si un pilote est sous GPL, il peut être compilé indépendament du noyau et installé séparément, donc ce ne serait pas forcément un problème (l'avantage d'avoir une ABI propre et stable pour les pilotes de périphériques ;) ).
[^] # Re: ruche de registre ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Dark Moon : une distribution GNU/Cygwin portable pour Windows. Évalué à 9.
La version anglaise dit la même chose:
Donc ce n'est pas une traduction bizarre. La base de registre est découpée en plusieurs ruches.
Je ne connaissais pas ce terme, moi non plus.
[^] # Re: digital, vraiment ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Pollution numérique. Évalué à 6. Dernière modification le 01 août 2018 à 18:04.
Tu installes mupdf et tu pourras utiliser des commandes vim du type 42g pour aller à la page 42 ou /mot pour chercher un mot (puis n pour passer au résultat suivant). Je ne peux plus m'en passer pour naviguer dans des PDFs.
[^] # Re: Mouai...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 3.
C'est assez peu mentionné, mais les "anciens" compteurs électroniques (la génération avant Linky) permettait de récupérer ces infos directement chez soit, via un port série situé directement sur le compteur. Pourquoi il faudrait envoyer cette information au fournisseur d'énergie puis… leur demander pour y avoir accès? (accès qu'ils pourraient très bien rendre payant, d'ailleurs).
Donc le côté éducation/information, ça existait déjà, mais ça n'intéressait pas grand monde.
L'intérêt du relevé heure par heure, c'est que le fournisseur d'énergie va pouvoir facturer ça comme il veut (par exemple Direct Energie propose des heures "super creuses" à certaines périodes). On est plus limité à un modèle heures pleines/heures creuses avec des horaires fixes imposés par le distributeur d'énergie.
[^] # Re: Rions avec Microsoft
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Prononciation des options. Évalué à 3. Dernière modification le 17 juillet 2018 à 13:53.
Dans ce cas précis, on fait la liaison avec le nom de l'option, dès fois qu'il vienne l'idée de mettre une espace entre le - et l'option.
[^] # Re: et c'est dommage
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Bashing Kaspersky. Évalué à 10.
Pourquoi tu crois que ST Microelectronics est toujours vivant et présent en Europe?
Je ne suis pas certain que personne ne s'en soucie…
[^] # Site internet
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Les RMLL 2018 Strasbourg arrivent à grand pas !. Évalué à 10.
C'est rigolo 3 minutes mais pas terrible pour communiquer. J'aurais préféré un site plus classique, avec quelques images des années précédentes, ce genre de choses.
[^] # Re: Une défense des autotools
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 2.
Je dirais bien d'aller voir du côté de Jam (la version de Perforce, celle de Boost, celle de Freetype ou celle de Haiku), si c'était pas un outil non maintenu avec 3 forks incompatible… C'est dommage, parce que c'est un bon remplacement de make, avec la possibilité de définir des règles génériques, qui conviendrait pas mal pour ce genre d'usage.
[^] # Re: Une défense des autotools
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 4.
Alors je dois prendre la défense de CMake sur ce point: il y a bien une méthode standard pour la prise en charge des dossiers d'installation, c'est GNUInstallDirs. Le problème, c'est que c'est un ajout relativement récent (ça fait quelques années quand même) et que beaucoup de projets ne l'utilisent pas et codent tout en dur. Et quand c'est utilisé, ça marche tout aussi bien que les autotools (et je dis ça en ayant packagé pas mal de choses pour Haiku, qui fait des trucs bien plus tordus que slackware en terme de chemin standardisés pour les bibliothèques, les manpages, …)
Donc ce n'est pas vraiment la faute de l'outil, mais plutôt d'une mauvaise utilisation (bon et aussi du fait que les dévs de CMake ont pendant quelques temps "oublié" de documenter GNUInstallDirs…
Il y a aussi toute la gestion du packaging (avec CPack) qui de mon expérience, fonctionne plutôt bien, pour générer des tarballs. Et il y a le support de la compilation croisée.
[^] # Re: Mon expérience à deux balles
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 4.
gcc sait le faire, avec la famille d'options qui commencent par -M. Je crois qu'il peut même te générer un Makefile.
C'est ce que cmake utilise pour gérer les dépendances, par exemple.
[^] # Re: Valeur pécuniaire du logiciel libre
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 2.
La vraie raison c'est qu'il y a des distributions Linux qui vont gérer la compilation et le packaging. Donc peu de projets ont besoin de le faire d'eux-même.
[^] # Re: Le libre dans mon travail
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal France Culture: que reste-t-il du logiciel libre ?. Évalué à -3.
Non mais RMS plus personne en a grand chose à faire de ce qu'il raconte. Il y a plein d'autres organisations que la FSF qui font la promotion du libre plus efficacement et de façon pertinente. Va voir la SFC ou la FSFE par exemple.
Je vois les choses d'une façon un peu plus positive: le logiciel libre progresse plus vite que les notions d'éthique qui y étaient souvent associées. ça ne veut pas dire que la partie éthique régresse, au contraire.
[^] # Re: Cmake non ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 4.
Je précise que la communauté cmake (et son canal IRC) est pas mal réactive et disponible pour faire les modifications quand c'est nécessaire. Si tu n'es pas forcé de supporter de vieilles versions de cmake, tu pourras donc obtenir de l'aide pour régler ces problèmes, et s'il y a lieu, ce sera intégré dans cmake directement.
Je mentionne aussi au passage le très pratique cpack, qui permet de générer un .deb, un .rpm et/ou un installeur windows sans trop s'embêter. Mais peut être pas encore les .apk (ce n'est pas trop compliqué d'ajouter le support d'un nouveau format de distribution à cpack, cela dit…)
[^] # Re: Analyse très subjective!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 10.
Je plussoie complètement l'utilisation de ninja. Juste pour le plaisir de le lancer une deuxième fois quand le build est fini et de le voir dire tout de suite "nothing to do". Sur un projet comme WebKit, make dans la même situation mets chez moi presque une minute pour arriver à la même conclusion.
Autres avantages:
- Pas besoin de choisir un -j à la main comme avec make, ninja surveille le system load et s'ajuste tout seul (en tenant compte de la charge CPU effective, donc il lancera plus de jobs en parallèle si la compilation est limitée par les accès disques, et moins si elle est limitée par le CPU ou si on fait autre chose sur la machine pendant ce temps).
- Affichage correct de la sortie de la compilation, sans mélanger la sortie de différent threads
- Affichage du nombre de cibles à compiler, ce qui permet de savoir où on en est dans le build du projet
[^] # Re: Variant observée: projet dont tout les commentaires ont été supprimés
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 4.
Ma code review préférée:
[^] # Re: Mettre à dispo du code coûte cher
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à -1.
Tu peux expliquer dans ce cas, quel est l'intérêt de faire du libre si on ne veut rien gérer? J'ai un peu de mal à voir ce que ça peut apporter dans ce cas?
[^] # Re: Mettre à dispo du code coûte cher
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 1.
Certes. Tu peux faire un "lancer de code" avec une licence sur Github et on en parle plus. Mais dans ce cas il ne faut pas s'attendre à avoir automagiquement des retours positifs et plein de gens qui contribuent. Je suis d'accord, c'est quand même du libre on a rien à reprocher et c'est déjà très bien.
Mais si on veut profiter des retours de la communauté, des contributions d'autres gens, etc, il faut s'investir un peu plus que ça. ça n'est pas nécessaire, mais ça peut être une bonne justification pour faire du logiciel libre.
[^] # Re: Des exemples ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 6.
Les bugs ne sont jamais "hyper évidents". Je suis dev, je teste mon code autant que je peux mais j'ai pas un temps infini, et dans la plupart des projets il n'y a pas d'équipe QA. Donc c'est souvent moins léché qu'un truc développé correctement par une entreprise (on essaie d'améliorer ça mais c'est loin d'être facile).
Donc, contribue: plains toi que la doc est moisie, que ça plante dans tous les sens et que ça tient pas la charge. Avec des exemples précis. Y'a des chances que tu tombes sur un dev qui sera content de t'aider à régler les problèmes (c'est la contrepartie de ne pas avoir d'équipe QA ou support: tu as une ligne directe pour discuter avec les devs du projet, alors profites-en).
[^] # Re: Valeur pécuniaire du logiciel libre
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 3.
ça me rappelle les histoires avec XChat qui a voulu faire payer les binaires Windows. Sauf que c'est un logiciel libre et qu'une autre personne (silverex) fournissait déjà gratuitement les dits binaires. ça s'est mal fini et ça a forké, et maintenant tout le monde utilise hexchat à la place.
Ce modèle ne me semble pas être le plus malin. Je me dirigerais plus volontiers vers la vente de support, et éventuellement le financement du développement de nouvelles fonctionnalités. Faire payer le travail des devs plutôt que le produit fini, donc.
[^] # Re: Mettre à dispo du code coûte cher
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 2.
Si, mettre du code sous licence libre a un coût. Tu ne peux pas le nier sinon ça va jamais marcher en entreprise. Par contre, tu peux le justifier et le "vendre": expliquer les bénéfices (en termes d'image, de contributions externes, etc) et montrer que finalement, le coût initial n'est pas si important que ça en regard.
Mais si tu essaies de faire du libre sans investir sérieusement dedans, ça ne marchera pas. Et le décideur pressé va retenir ça: "le libre, ça marche pas on a essayé". Ne gâche pas ta chance et fait les choses proprement dès le début, merci :)
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 3.
ça va te coûter plus cher de maintenir ton code, qu'à quelqu'un d'autre de faire un fork et de passer un peu de temps à le nettoyer. Et en plus le fork sera 10 fois moins lourd, aura moins de bugs, etc.
Je ne vois pas comment cette recette peut être gagnante.
[^] # Re: Pas forcément commercial
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à -2.
« ce n'est pas la politique de la compagnie »
On dit pas compagnie en Français. On dit entreprise. Merci.