Hum…
Personnellement, pour découvrir un jeu avec ma debian, j'utilise aptitude => vue par debtags et je vais dans la catégorie que j'ai envie.
Après, pour les catégories du menu "démarrer"… Aucune idée, j'en ai pas ^
Pour ce qui est du coup de gueule sur la packaging, j'ai envie de dire deux choses:
1) ".configure && make && make install" ça me semble dépassé, les dernières compilations que j'ai vues c'était "mkdir build && cd build && cmake .. && make && make install". Au moins la sortie est lisible et la procédure peut fonctionner sur n'importe quel OS.
2) avec cmake, il est possible de générer les paquets pour la plupart des distros en se prenant moins la tête. Moins, mais il faut quand même maintenir la liste des dépendances, et je me demande toujours pourquoi diable boost n'a pas de méta-package chez debian, chose qui oblige les dev à préciser le numéro de version dans le nom du paquet…
Pour le coup, la situation me semble meilleure (ou peut s'améliorer) grâce a cmake (je sais pas si les autres ont un mécanisme idoine aussi simple à gérer), mais il n'empêche que ça reste du boulot de maintenir le cmake pour chaque distro (combien, déjà? 400? de toute façon: trop pour maintenir). Et si le jeu n'utilise pas ce procédé sous prétexte qu'ils utilisent les PPA d'ubuntu, ben… à qui la faute?
Bien sûr, je parle de cmake, et peut-être existe-t-il d'autres mécanismes aussi chiadés (portable et simple), mais je ne les connais pas, alors je vais pas en parler ;)
Après, forcément, cmake n'est pas conforme à la philosophie POSIX, puisqu'il est capable de faire plusieurs choses, mais je ne veux pas lancer un débat sur le fait que ".configure" soit obsolète ou pas (bien que, personnellement, je pige pas comment ça marche, je me dis que d'autres ont peut-être le problème inverse)
Posté par freem .
En réponse à la dépêche OpenBSD 5.2.
Évalué à 5.
C'est surtout que quand on ajoute des fonctionnalités, on risque d'ajouter des bugs, tandis que l'usage d'une version un peu plus ancienne permet d'avoir eu plus de temps pour corriger ceux existants.
Je pense qu'il vaut donc mieux dire qu'ils pensent qu'il vaut mieux avoir un bug connu avec son contournement, plutôt que 2 bugs inconnus (et donc, sans contournement ou potentiellement dangereux pour la stabilité/l'intégrité du système).
Autant je comprend ceux qui t'on déconseillé, autant je ne suis pas d'accord avec les points abordés dans diverses réponses.
Je suis un contributeur jeune (je reprend depuis presque un an un projet* qui était mort depuis… 2006 je crois) mais ce genre d'outil existe, et fonctionne.
Sourceforge et savannah (qui ont la même base logicielle à l'origine) ont effectivement un outil pour que les gens d'un projet demandent des contributions. Et mon expérience actuelle montre qu'en moins de 2 semaines on peut se retrouver avec une 15aine de réponses. Certes, rien ne me dis qu'ils contribueront réellement, et même je doute avoir plus de 3 réels contributeurs dans cette masse, mais il me semble que le fonctionnement est réel.
D'un autre côté, ce projet, même s'il est mort (0 contrib depuis 6 ans) reste quand même à près de 600 dl/semaine. Je récupère donc une base d'utilisateurs non négligeable plutôt que de partir de rien du tout, ça doit aider à attirer (malgré une réécriture totale du code, pour rendre la bête utilisable en natif sur linux).
Autre point, ce logiciel était bien foutu côté simplicité d'utilisation (public visé: joueurs de jdr sur table/papier, pour créer des cartes et plans) et les dev ont donc eu une certaine reconnaissance. Parce que je sais pas pour vous, mais je pense que les logiciels de dessin simple à manier sous linux, à part xpaint (qui est mieux que mspaint mais quand même assez cru) ne sont pas légion.
En fait, même sous windows, on parle toujours de photoshop ou gimp… mais ce ne sont pas exactement des logiciels simples d'accès.
Du coup, le public visé est potentiellement large (tout en étant assez spécifique puisque centré sur les "rôlistes du papier" qui ne sont pas légion).
Après, il est évident que si on veut créer un logiciel, tant qu'aucune version exploitable n'existe, ça va être dur d'avoir des contributions.
Il est aussi évident que si le logiciel en question est YATEFD (Yet Another Text Editor For Developpers) ça va pas attirer: l'offre existante est déjà tellement conséquente.
Dans le cas qui t'intéresse, tu parles d'une fonctionnalité de forge logicielle. Ca implique:
_ public très restreint: techniciens seulement
_ nécessité d'intégration dans l'existant, pas évident vu le nombre de forge existantes
_ fonctionnalité déjà existante
_ nécessité d'auto hébergement, donc d'auto administration, alors que les contributeurs vont vouloir un truc qui permet de renter rapidement sur le projet auquel ils veulent contribuer
Sans vouloir être négatif, je doute effectivement que des gens soient attirés…
Quant au fait que "l'esprit du libre disparaisse"… Il m'a fallu 10 ans pour passer d'utilisateur à contributeur, et encore, je ne me sens pas capable de contribuer du code à ce que j'utilise quotidiennement: Codeblocks, linux, i3, lxterminal, vim, wxwidgets… trop complexe pour moi tout ça. (Il y avait bien flare qui m'intéressais, mais la politique de faire d'abord du code qui tombe en marche avant de refactorer ne m'a pas trop séduit).
Ce n'est pas surprenant qu'il y ait moins de contributions: avant, le libre était moins répandu, ceux qui le connaissaient savaient à quoi s'attendre et on édifié des logiciels impressionnants. Y contribuer du code rapidement n'est clairement pas à la portée de tous, et les petits projets, qui sont accessibles, sont les moins connus. Les gros projets séduisent parce qu'ils sont complets (y font même le café pour certains… et ce, même quand on aime pas le café) mais font peur aux contributeurs potentiels.
Mais pour autant, dire que l'esprit du libre disparaît… le public apprend l'existance de linux, pour certains, ils l'utilisent comme successeur aux logiciels fermés. On ne peut pas attendre de tout ces gens qu'ils contribuent. Il y aura toujours plus de sangsues que de gens pour aider, mais ça ne veut pas dire qu'il y a moins de contributeurs.
*: le projet en question sourceforge.net/projects/autorealm dès fois que ;)
Perso, le pilote nouveau me va bien:
_ support de randr
_ pas de config Xorg à faire (en tout cas sous debian)
Seul "bémol" impossible d'utiliser 2 cartes branchées en même temps (cela dis, c'est précisé sur le site officiel) et il me semble que les jeux 3D soufrent d'une perf moindre, mais pas testé depuis longtemps avec NVidia et/ou windows.
Vu le peu de temps ou je joue à des jeux 3D, je préfère le confort d'un WM qui marche à celui de jeux qui carburent (en attendant les deux en simultané peut-être?).
Et puis tant qu'openMW arrive à fonctionner, donc ça me va.
[^] # Re: schtroumpf grognon
Posté par freem . En réponse à la dépêche De nouveaux jeux libres à découvrir. Évalué à 2.
Hum…
Personnellement, pour découvrir un jeu avec ma debian, j'utilise aptitude => vue par debtags et je vais dans la catégorie que j'ai envie.
Après, pour les catégories du menu "démarrer"… Aucune idée, j'en ai pas ^
Pour ce qui est du coup de gueule sur la packaging, j'ai envie de dire deux choses:
1) ".configure && make && make install" ça me semble dépassé, les dernières compilations que j'ai vues c'était "mkdir build && cd build && cmake .. && make && make install". Au moins la sortie est lisible et la procédure peut fonctionner sur n'importe quel OS.
2) avec cmake, il est possible de générer les paquets pour la plupart des distros en se prenant moins la tête. Moins, mais il faut quand même maintenir la liste des dépendances, et je me demande toujours pourquoi diable boost n'a pas de méta-package chez debian, chose qui oblige les dev à préciser le numéro de version dans le nom du paquet…
Pour le coup, la situation me semble meilleure (ou peut s'améliorer) grâce a cmake (je sais pas si les autres ont un mécanisme idoine aussi simple à gérer), mais il n'empêche que ça reste du boulot de maintenir le cmake pour chaque distro (combien, déjà? 400? de toute façon: trop pour maintenir). Et si le jeu n'utilise pas ce procédé sous prétexte qu'ils utilisent les PPA d'ubuntu, ben… à qui la faute?
Bien sûr, je parle de cmake, et peut-être existe-t-il d'autres mécanismes aussi chiadés (portable et simple), mais je ne les connais pas, alors je vais pas en parler ;)
Après, forcément, cmake n'est pas conforme à la philosophie POSIX, puisqu'il est capable de faire plusieurs choses, mais je ne veux pas lancer un débat sur le fait que ".configure" soit obsolète ou pas (bien que, personnellement, je pige pas comment ça marche, je me dis que d'autres ont peut-être le problème inverse)
[^] # Re: KDE en retard ?
Posté par freem . En réponse à la dépêche OpenBSD 5.2. Évalué à 5.
C'est surtout que quand on ajoute des fonctionnalités, on risque d'ajouter des bugs, tandis que l'usage d'une version un peu plus ancienne permet d'avoir eu plus de temps pour corriger ceux existants.
Je pense qu'il vaut donc mieux dire qu'ils pensent qu'il vaut mieux avoir un bug connu avec son contournement, plutôt que 2 bugs inconnus (et donc, sans contournement ou potentiellement dangereux pour la stabilité/l'intégrité du système).
[^] # Re: L'esprit du libre disparait...
Posté par freem . En réponse au journal Deux ans de projet libre : bilan. Évalué à 2.
Autant je comprend ceux qui t'on déconseillé, autant je ne suis pas d'accord avec les points abordés dans diverses réponses.
Je suis un contributeur jeune (je reprend depuis presque un an un projet* qui était mort depuis… 2006 je crois) mais ce genre d'outil existe, et fonctionne.
Sourceforge et savannah (qui ont la même base logicielle à l'origine) ont effectivement un outil pour que les gens d'un projet demandent des contributions. Et mon expérience actuelle montre qu'en moins de 2 semaines on peut se retrouver avec une 15aine de réponses. Certes, rien ne me dis qu'ils contribueront réellement, et même je doute avoir plus de 3 réels contributeurs dans cette masse, mais il me semble que le fonctionnement est réel.
D'un autre côté, ce projet, même s'il est mort (0 contrib depuis 6 ans) reste quand même à près de 600 dl/semaine. Je récupère donc une base d'utilisateurs non négligeable plutôt que de partir de rien du tout, ça doit aider à attirer (malgré une réécriture totale du code, pour rendre la bête utilisable en natif sur linux).
Autre point, ce logiciel était bien foutu côté simplicité d'utilisation (public visé: joueurs de jdr sur table/papier, pour créer des cartes et plans) et les dev ont donc eu une certaine reconnaissance. Parce que je sais pas pour vous, mais je pense que les logiciels de dessin simple à manier sous linux, à part xpaint (qui est mieux que mspaint mais quand même assez cru) ne sont pas légion.
En fait, même sous windows, on parle toujours de photoshop ou gimp… mais ce ne sont pas exactement des logiciels simples d'accès.
Du coup, le public visé est potentiellement large (tout en étant assez spécifique puisque centré sur les "rôlistes du papier" qui ne sont pas légion).
Après, il est évident que si on veut créer un logiciel, tant qu'aucune version exploitable n'existe, ça va être dur d'avoir des contributions.
Il est aussi évident que si le logiciel en question est YATEFD (Yet Another Text Editor For Developpers) ça va pas attirer: l'offre existante est déjà tellement conséquente.
Dans le cas qui t'intéresse, tu parles d'une fonctionnalité de forge logicielle. Ca implique:
_ public très restreint: techniciens seulement
_ nécessité d'intégration dans l'existant, pas évident vu le nombre de forge existantes
_ fonctionnalité déjà existante
_ nécessité d'auto hébergement, donc d'auto administration, alors que les contributeurs vont vouloir un truc qui permet de renter rapidement sur le projet auquel ils veulent contribuer
Sans vouloir être négatif, je doute effectivement que des gens soient attirés…
Quant au fait que "l'esprit du libre disparaisse"… Il m'a fallu 10 ans pour passer d'utilisateur à contributeur, et encore, je ne me sens pas capable de contribuer du code à ce que j'utilise quotidiennement: Codeblocks, linux, i3, lxterminal, vim, wxwidgets… trop complexe pour moi tout ça. (Il y avait bien flare qui m'intéressais, mais la politique de faire d'abord du code qui tombe en marche avant de refactorer ne m'a pas trop séduit).
Ce n'est pas surprenant qu'il y ait moins de contributions: avant, le libre était moins répandu, ceux qui le connaissaient savaient à quoi s'attendre et on édifié des logiciels impressionnants. Y contribuer du code rapidement n'est clairement pas à la portée de tous, et les petits projets, qui sont accessibles, sont les moins connus. Les gros projets séduisent parce qu'ils sont complets (y font même le café pour certains… et ce, même quand on aime pas le café) mais font peur aux contributeurs potentiels.
Mais pour autant, dire que l'esprit du libre disparaît… le public apprend l'existance de linux, pour certains, ils l'utilisent comme successeur aux logiciels fermés. On ne peut pas attendre de tout ces gens qu'ils contribuent. Il y aura toujours plus de sangsues que de gens pour aider, mais ça ne veut pas dire qu'il y a moins de contributeurs.
*: le projet en question sourceforge.net/projects/autorealm dès fois que ;)
[^] # Re: Merci !
Posté par freem . En réponse à la dépêche Entretien avec Martin Peres, développeur Nouveau. Évalué à 4.
"les cas où il fait bon l'utiliser. "
En hiver?
Perso, le pilote nouveau me va bien:
_ support de randr
_ pas de config Xorg à faire (en tout cas sous debian)
Seul "bémol" impossible d'utiliser 2 cartes branchées en même temps (cela dis, c'est précisé sur le site officiel) et il me semble que les jeux 3D soufrent d'une perf moindre, mais pas testé depuis longtemps avec NVidia et/ou windows.
Vu le peu de temps ou je joue à des jeux 3D, je préfère le confort d'un WM qui marche à celui de jeux qui carburent (en attendant les deux en simultané peut-être?).
Et puis tant qu'openMW arrive à fonctionner, donc ça me va.
En tout cas, merci bien à l'équipe de dev.