De ma maigre expérience un projet consiste en une création de logiciel qui passé le moment où il répond au cahier des charges
Quand tu vends du logiciel ce concept n'existe pas. Ça fait 30 ans que Word est développé et tant qu'il répondra aux besoins des gens et qu'il y aura des gens pour acheter ça continuera.
En terme de SI je pense que le boulot vraiment le plus gratifiant c'est de travailler dans une entreprise qui n'est pas informatique et à développer leur logiciel,
Tu arrives à dire ça sans rigoler ? A partir du moment où tu parles de SI en tant que dev il faut prendre ses jambes à son coup. Aucun vrai problème à résoudre, tu utilises des boîtes, tu pisses de la glue et basta.
Bha oui on est d'accord ce n'est clairement pas un problème d'outil. Si tu fais les choses proprement avec l'un des outils tu le feras proprement avec un autre. Je ne vois aucune différence. Et c'est bien le sens de ma remarque.
Et il pense vraiment qu'en échangeant github par git request-pull qui demandent exactement les mêmes informations et produisent la même chose (sous une présentation différente) ça changerait quelque chose au contenu ?
On parlait de la contribution aux projets open source y'a pas longtemps. Ce genre de fonctionnalités intégrés dans un bon workflow ca déchire. Ça permet de mentorer ou de se faire relire son code super facilement, de manière itérative et très précise.
Ça va dépendre de beaucoup de choses. Je suis parti de l'hypothèse que ce n'est pas une activité à 100% (que ce soit à temps partagé ou par période) et qu'il n'y a grosso modo aucun frais pour un projet comme ça. Le matos tu l'as, ça demande rien comme investissement etc. et que c'est le montant à partir duquel tu peux commencer estimer que ton activité est rentable.
Après l’intérêt n'est pas de chipoter pour savoir si ça paie 50 ou 150h, ce n'est pas très important. C'est simplement que le chiffre est ridiculement bas par rapport à ce qui me semble le travail requis. Je ne bosse pas du tout dans ce domaine, mais de mon expérience en 50h ou 150h t'as vraiment pas grand chose. Le point qui me semble intéressant est que pour passer à un statut autre que bénévole qui touche de l'argent de poche il faut rentrer beaucoup beaucoup beaucoup plus d'argent.
Posté par ckyl .
En réponse au journal Vendre du jeu-vidéo libre.
Évalué à 8.
Dernière modification le 28 octobre 2012 à 19:15.
Ça demande combien de temps de faire des jeux comme ça ? Par ce que les 4000€ récoltés ça paie grosso modo 100h de développement, soit vraiment rien du tout.
J'ai du mal à voir ça comme un succès, sauf si le but était de l'argent de poche en bonus. Après j'ai aucune idée de la qualité et de l'adéquation au marché de ce dont on parle.
J'avoue qu'avec le nombre de failles dans ce genre d'applis (Flash, Java), j'ai du mal à faire la différence ;)
Le problème c'est qu'on ne comprend plus du tout de quoi on parle si on va part là. Vu la question posée à la base ainsi que son domaine il me semble très important de bien expliquer chaque partie, comment elles interagissent et l'état de l'art actuel.
C'est Flash qui a accès à X, pas les applis Flash. Elles, elles ne peuvent accéder qu'à ce qu'expose Flash/ActionScript. Les problèmes arrivent quand Flash est troué. C'est le même problème que pour les VM JS des browser.
Pour que les applis Flash puissent chopper les événements X, elles auraient besoin d'avoir fait tourner un bout de code natif sous l'UID de l'utilisateur pour aller chercher lesdits événement. À partir de la le problème de sécu à déjà eu lieu. Si tu enlèves ça elles feront autrement, elles peuvent faire exactement ce que l'utilisateur peut faire.
Après il est aussi intéressant de s'intéresser à comment on limite les dégats quand on se fait trouer. Adobe à bossé à sandboxer le processus Flash pour que quand il se fait trouer, l'attaquant ne puisse pas faire grand chose. Ca repose sur un design de type séparation de privilège. La VM tourne avec les droits les plus minimaux possibles, et quand il y a une interaction à faire avec le système elle doit demander à un autre processus qui à gardé les droits de l'utilisateur. Ca c'est dispo que sous Windows AFAIK. Si c'était dispo sous Linux alors là oui, pouvoir écouter les événements clavier serait un problème. Mais sans ca, ca ne sert pas à grand chose.
Posté par ckyl .
En réponse à la dépêche JRuby 1.7.0.
Évalué à 4.
J'ai laché le suivi du JDK depuis un an donc il se peut que je dise des choses qui ne sont plus vrai (fix dans une mineur).
Dans les JDK7 l'utilisation d'invokedynamic desactive pas mal d'optimisation de Hotspot. Il était prévu d'adresser ces problèmes dans le JDK8. Il est donc a prévoir une deuxième grosse ameilloration des perfs quand Ruby sera capable d'utiliser pleinement Hotspot. J'ai pas réussi à trouvé un résumé de l'état d'Hotspot sur ce sujet. Si quelqu'un a des infos…
D'autres bonnes choses devraient arriver avec le JDK8 pour les langages dynamiques commme la suppression de l'horrible pergem space.
Posté par ckyl .
En réponse à la dépêche JRuby 1.7.0.
Évalué à 5.
Attention tout ce qui repose sur la JVM est assez biaisé niveau consommation mémoire puisque par design elle va utiliser sa heap size en maximum sans rien garbage collecter avant. Très grossièrement c'est comme si free(3) ne faisait rien tant qu'un certain seuil n'était pas atteind.
Donc sur tout les bench de ce type la mesure est assez inutile. Après ce comportement est ou n'est pas problématique selon les cas d'usage.
Non c'es sandboxé. Par contre le jour ou la sandbox se fait trouer… Mais de toute facon à partir du moment ou on peut executer du code sous l'uid de l'utilisateur c'est game over, juste plus ou moins facile .
Bref utilisez une VM pour browser l'interweb et autre;)
À contrario, 95% du design hardware d'NVidia est purement génial. On pousse quelques coups de gueules parfois car on a besoin de souffler un coup mais c'est en général justifié quelques années plus tard quand on comprend mieux les contraintes sur les ingénieurs NVidia. Pour les 5% restant, on a de grosses surprises et on se demande sous quelles drogues étaient les ingénieurs quand ils ont conçu ce matériel!
C'est clairement la citation de la semaine. On voit souvent les gens tirer à boulet rouge sur des choses qu'ils ont juste survolées en méprisant les gens et leur travail, alors qu'avec un peu de recul et d'information supplémentaire on comprend le pourquoi. Quand c'est pas beau ou qu'on s'écarte du chemin de moindre résistance, il y a souvent une raison.
Tu as une vision bêtement binaire. Tout temps de developpement est limité, il faut donc toujours définir les priorités. Ce qui est complexe et dont tu ne vois pas l'intêret, où dont l'intêret n'équivaut pas au coût, va inévitablement partir à la poubelle. C'est le principe de la "business value" d'une fonctionnalité.
Si ca a une forte "business value" pour ton projet alors de toute facon ca va pas t'emmerder de le coder vu que ca va nettement ammeillorer ton projet.
Envoyer des demandes à la poubelle ca arrive tout le temps. Même à des clients qui signent des chèques à 5,6 ou 7 chiffres. Si ca fait pas son chemin en haut du backlog rapidement alors ca sera jamais fait. La bande passante est bornée.
Même pour un projet personnel il y a plein de chose à tirer des méthodes agiles. Notament sur toute la planification, découpage, et focus. Cela force à devoir penser avant et à se donner des objectifs clair. Ce qui peut éviter l'éparpillement, ton en gardant la motivation avec des résultats concrets à court terme. En travaillant tout seul sur un temps limité des objectifs clairs avec une approche "good enough" prend tout son sens. Ca peut aussi donner une très bonne visibilité de l'état du projet et de son avenir probable.
Hormis pour spécifier le ignore-count du continue (et plus généralement n'importe quel argument d'une commande usuelle qui va demenander un popup insupportable) j'ose prétendre que n'importe quel IDE fourni les mapping clavier et que tu n'as pas besoin du mulot.
es IDE intègrent la majorité des points cités, mais retire en 1, et tu pleures le jour où tu en a besoin, et je n'ai aucune envie de me poser la question avant le lancement de devoir choisir quel debugger.
Ce point m'interpelle. En général tu choisis ton environement de travail, tu y restes et tu le maitrise parfaitement. Tu ne lances ou choisi pas clairement un IDE pour debugger quelque chose. Par contre tu utilises son debugger si il fourni ce dont tu as besoin, autrement tu le degages et tu y vas a l'ancienne.
De vos commentaire je pense pouvoir en déduire que 1- Les dev C n'aiment toujours pas le IDE et donc ne les connaisses par forcément bien (ce qui fait une boucle). 2- Les IDE pour le C ne semblent pas avoir un stade fonctionnel où on ne se pose même plus la question de leur utilisation.
A partir de combien de demande te remets tu en question ?
Ca n'a rien de particulier au logiciel libre. Dès qu'un projet à des utilisateurs tu as une liste de chose qu'ils voudraient longue comme le bras que tu ne pourras jamais faire. Donc tu prioritises ce que tu veux selon tes critères. Ca s'applique que tu sois tout seul ou dans une équipe de 100 personnes.
Je comprends parfaitement la remarque qui est a comprendre comme "si tu ne vois pas l'intêret ET que ca te fait chier de le faire
ne le fait pas". Évidement que si tu en vois l'intêret pour ton projet et que le coût est raisonnable tu vas le faire; enfin si il arrive un jour en haut des priorités.
Juste pour préciser ma question n'était pas réthorique, quand je pose une question c'est que je pense que la réponse devrait être intéressante. Je comprends totalement l'intêret de pouvoir basculer sur gdb au besoin, mais je me demandais à quel point c'était actuellement nécéssaire.
Dans les langages que j'utilise depuis, tu as grosso modo un mapping 1-1 entre les debuggers bruts et l'intégration dans les IDE. Les IDE étaient tout moisis quand j'ai arrêter d'écrire du C. Donc ma question comportait deux volets: quelles actions ne sont actuellement pas disponibles dans les IDE et quelles actions de GDB ne sont conceptuellement pas insérable de manière satisfaisante dans les IDE.
Avec vos deux réponses je pense réussir à distinguer les deux catégories. Ca m'étonne que la plupart de ce qui a été listé ne soit pas dispo, les fonctionalités équivalentes existent dans d'autres langages (rbreak, tbreak, break conditionnel, catch, completion, print, remote debug) et sont "parfaitement" intégrés.
Ca va faire 7/8 ans que j'ai pas lancé gdb pour autre chose que des conneries mais y'a quoi comme fonctionnalité qui n'est pas accessible depuis l'IDE ?
Par contre, la documentation n'a rien d'un service critique, c'est de l'hypocrisie de dire ça.
Comme souvent, faire des généralités implique de dire des bétises. Tout dépend du type de projet. Il y a des dizaines de projets que je n'ai téléchargé qu'une fois (et encore même pas puisque j'ai tiré un paquet) mais dont je consulte la doc en ligne tout les jours. C'est ma principale interface avec le projet en lui même (le reste étant ML/bugtracker/repository source des trucs souvent moins génant niveau dispo)
A l'époque Sourceforge avait une section help wanted. Je crois pas que ca ait fait son chemin jusqu'aux plateformes d'aujourd'hui.
D'une manière générale le problème c'est que assez difficile de faire un truc avec un bon ratio bruit/signal et avec de l'info pertinente.
Pour la traduction et pour le francais en particulier tu devrais aller jeter un oeil à traduc.org. De longues années que j'y ai pas mis le pied et je ne sais absolument pas ce que c'est devenu mais normalement c'est quelque chose comme ca que tu cherches.
Non. J'ai dit que l'affirmation « si t'es pas d'accord, tu peux forker » revient à supposer que tous ceux qui manifestent leur désaccord sont soit des développeurs soit capables de coder.
[^] # Re: Est-ce est-ce Dezi ?
Posté par ckyl . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #44. Évalué à 1.
Quand tu vends du logiciel ce concept n'existe pas. Ça fait 30 ans que Word est développé et tant qu'il répondra aux besoins des gens et qu'il y aura des gens pour acheter ça continuera.
Tu arrives à dire ça sans rigoler ? A partir du moment où tu parles de SI en tant que dev il faut prendre ses jambes à son coup. Aucun vrai problème à résoudre, tu utilises des boîtes, tu pisses de la glue et basta.
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par ckyl . En réponse à la dépêche Nouveautés autour de Git. Évalué à 4.
Bha oui on est d'accord ce n'est clairement pas un problème d'outil. Si tu fais les choses proprement avec l'un des outils tu le feras proprement avec un autre. Je ne vois aucune différence. Et c'est bien le sens de ma remarque.
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par ckyl . En réponse à la dépêche Nouveautés autour de Git. Évalué à 3.
Et il pense vraiment qu'en échangeant github par git request-pull qui demandent exactement les mêmes informations et produisent la même chose (sous une présentation différente) ça changerait quelque chose au contenu ?
[^] # Re: Faire une recherche DuckDuckGo avant de poster, c'est mieux
Posté par ckyl . En réponse au journal Minitel 2.0 et auto-hébergement, quelles différences ?. Évalué à 3.
https://github.com/features/projects/codereview
https://github.com/blog/42-commit-comments
On parlait de la contribution aux projets open source y'a pas longtemps. Ce genre de fonctionnalités intégrés dans un bon workflow ca déchire. Ça permet de mentorer ou de se faire relire son code super facilement, de manière itérative et très précise.
[^] # Re: gitlab
Posté par ckyl . En réponse au journal Minitel 2.0 et auto-hébergement, quelles différences ?. Évalué à 2.
http://blog.gitlabhq.com/screenshots/
Wha ils se sont déchirés sur l'UI. Je me demande où ils ont été chercher ca !
[^] # Re: En parlant de TCP...
Posté par ckyl . En réponse à la dépêche MPTCP, TCP dans un monde ultra‐connecté. Évalué à 3.
Pour 20 euros t'as un câble Ethernet de 30m ;)
[^] # Re: Succès ?
Posté par ckyl . En réponse au journal Vendre du jeu-vidéo libre. Évalué à 4.
Ça va dépendre de beaucoup de choses. Je suis parti de l'hypothèse que ce n'est pas une activité à 100% (que ce soit à temps partagé ou par période) et qu'il n'y a grosso modo aucun frais pour un projet comme ça. Le matos tu l'as, ça demande rien comme investissement etc. et que c'est le montant à partir duquel tu peux commencer estimer que ton activité est rentable.
Après l’intérêt n'est pas de chipoter pour savoir si ça paie 50 ou 150h, ce n'est pas très important. C'est simplement que le chiffre est ridiculement bas par rapport à ce qui me semble le travail requis. Je ne bosse pas du tout dans ce domaine, mais de mon expérience en 50h ou 150h t'as vraiment pas grand chose. Le point qui me semble intéressant est que pour passer à un statut autre que bénévole qui touche de l'argent de poche il faut rentrer beaucoup beaucoup beaucoup plus d'argent.
# Succès ?
Posté par ckyl . En réponse au journal Vendre du jeu-vidéo libre. Évalué à 8. Dernière modification le 28 octobre 2012 à 19:15.
Ça demande combien de temps de faire des jeux comme ça ? Par ce que les 4000€ récoltés ça paie grosso modo 100h de développement, soit vraiment rien du tout.
J'ai du mal à voir ça comme un succès, sauf si le but était de l'argent de poche en bonus. Après j'ai aucune idée de la qualité et de l'adéquation au marché de ce dont on parle.
[^] # Re: Sécurité dans la pile graphique
Posté par ckyl . En réponse à la dépêche Entretien avec Martin Peres, développeur Nouveau. Évalué à 5.
Le problème c'est qu'on ne comprend plus du tout de quoi on parle si on va part là. Vu la question posée à la base ainsi que son domaine il me semble très important de bien expliquer chaque partie, comment elles interagissent et l'état de l'art actuel.
Soit dit au passage il est très difficile à trouver pour Linux soit dit en passant. Pour Windows on peut se faire une idée là: https://media.blackhat.com/bh-us-12/Briefings/Sabanal/BH_US_12_Sabanal_Digging_Deep_Slides.pdf
[^] # Re: Sécurité dans la pile graphique
Posté par ckyl . En réponse à la dépêche Entretien avec Martin Peres, développeur Nouveau. Évalué à 4.
C'est Flash qui a accès à X, pas les applis Flash. Elles, elles ne peuvent accéder qu'à ce qu'expose Flash/ActionScript. Les problèmes arrivent quand Flash est troué. C'est le même problème que pour les VM JS des browser.
Pour que les applis Flash puissent chopper les événements X, elles auraient besoin d'avoir fait tourner un bout de code natif sous l'UID de l'utilisateur pour aller chercher lesdits événement. À partir de la le problème de sécu à déjà eu lieu. Si tu enlèves ça elles feront autrement, elles peuvent faire exactement ce que l'utilisateur peut faire.
Après il est aussi intéressant de s'intéresser à comment on limite les dégats quand on se fait trouer. Adobe à bossé à sandboxer le processus Flash pour que quand il se fait trouer, l'attaquant ne puisse pas faire grand chose. Ca repose sur un design de type séparation de privilège. La VM tourne avec les droits les plus minimaux possibles, et quand il y a une interaction à faire avec le système elle doit demander à un autre processus qui à gardé les droits de l'utilisateur. Ca c'est dispo que sous Windows AFAIK. Si c'était dispo sous Linux alors là oui, pouvoir écouter les événements clavier serait un problème. Mais sans ca, ca ne sert pas à grand chose.
[^] # Re: Les performances ?
Posté par ckyl . En réponse à la dépêche JRuby 1.7.0. Évalué à 4.
J'ai laché le suivi du JDK depuis un an donc il se peut que je dise des choses qui ne sont plus vrai (fix dans une mineur).
Dans les JDK7 l'utilisation d'invokedynamic desactive pas mal d'optimisation de Hotspot. Il était prévu d'adresser ces problèmes dans le JDK8. Il est donc a prévoir une deuxième grosse ameilloration des perfs quand Ruby sera capable d'utiliser pleinement Hotspot. J'ai pas réussi à trouvé un résumé de l'état d'Hotspot sur ce sujet. Si quelqu'un a des infos…
D'autres bonnes choses devraient arriver avec le JDK8 pour les langages dynamiques commme la suppression de l'horrible pergem space.
[^] # Re: Les performances ?
Posté par ckyl . En réponse à la dépêche JRuby 1.7.0. Évalué à 5.
Attention tout ce qui repose sur la JVM est assez biaisé niveau consommation mémoire puisque par design elle va utiliser sa heap size en maximum sans rien garbage collecter avant. Très grossièrement c'est comme si free(3) ne faisait rien tant qu'un certain seuil n'était pas atteind.
Donc sur tout les bench de ce type la mesure est assez inutile. Après ce comportement est ou n'est pas problématique selon les cas d'usage.
[^] # Re: Sécurité dans la pile graphique
Posté par ckyl . En réponse à la dépêche Entretien avec Martin Peres, développeur Nouveau. Évalué à 2. Dernière modification le 26 octobre 2012 à 14:38.
Non c'es sandboxé. Par contre le jour ou la sandbox se fait trouer… Mais de toute facon à partir du moment ou on peut executer du code sous l'uid de l'utilisateur c'est game over, juste plus ou moins facile .
Bref utilisez une VM pour browser l'interweb et autre;)
[^] # Re: 3D
Posté par ckyl . En réponse à la dépêche Entretien avec Martin Peres, développeur Nouveau. Évalué à 10.
C'est clairement la citation de la semaine. On voit souvent les gens tirer à boulet rouge sur des choses qu'ils ont juste survolées en méprisant les gens et leur travail, alors qu'avec un peu de recul et d'information supplémentaire on comprend le pourquoi. Quand c'est pas beau ou qu'on s'écarte du chemin de moindre résistance, il y a souvent une raison.
[^] # Re: Documenté ou pas, ce sera non!
Posté par ckyl . En réponse à la dépêche Documentation du format du Journal. Évalué à 5.
Et ca te choque pas tout le bloat dans grub2 qui devient un mini OS ? Un cat dans un bootloader ! ;)
[^] # Re: Code pour toi avant tout
Posté par ckyl . En réponse au journal Deux ans de projet libre : bilan. Évalué à 3.
Tu as une vision bêtement binaire. Tout temps de developpement est limité, il faut donc toujours définir les priorités. Ce qui est complexe et dont tu ne vois pas l'intêret, où dont l'intêret n'équivaut pas au coût, va inévitablement partir à la poubelle. C'est le principe de la "business value" d'une fonctionnalité.
Si ca a une forte "business value" pour ton projet alors de toute facon ca va pas t'emmerder de le coder vu que ca va nettement ammeillorer ton projet.
Envoyer des demandes à la poubelle ca arrive tout le temps. Même à des clients qui signent des chèques à 5,6 ou 7 chiffres. Si ca fait pas son chemin en haut du backlog rapidement alors ca sera jamais fait. La bande passante est bornée.
Même pour un projet personnel il y a plein de chose à tirer des méthodes agiles. Notament sur toute la planification, découpage, et focus. Cela force à devoir penser avant et à se donner des objectifs clair. Ce qui peut éviter l'éparpillement, ton en gardant la motivation avec des résultats concrets à court terme. En travaillant tout seul sur un temps limité des objectifs clairs avec une approche "good enough" prend tout son sens. Ca peut aussi donner une très bonne visibilité de l'état du projet et de son avenir probable.
[^] # Re: Juste une question
Posté par ckyl . En réponse au journal KDevelop 4.4 est sorti. Évalué à 2.
Hormis pour spécifier le ignore-count du continue (et plus généralement n'importe quel argument d'une commande usuelle qui va demenander un popup insupportable) j'ose prétendre que n'importe quel IDE fourni les mapping clavier et que tu n'as pas besoin du mulot.
Ce point m'interpelle. En général tu choisis ton environement de travail, tu y restes et tu le maitrise parfaitement. Tu ne lances ou choisi pas clairement un IDE pour debugger quelque chose. Par contre tu utilises son debugger si il fourni ce dont tu as besoin, autrement tu le degages et tu y vas a l'ancienne.
De vos commentaire je pense pouvoir en déduire que 1- Les dev C n'aiment toujours pas le IDE et donc ne les connaisses par forcément bien (ce qui fait une boucle). 2- Les IDE pour le C ne semblent pas avoir un stade fonctionnel où on ne se pose même plus la question de leur utilisation.
[^] # Re: Code pour toi avant tout
Posté par ckyl . En réponse au journal Deux ans de projet libre : bilan. Évalué à 3.
si ca t'emmerde…
[^] # Re: Code pour toi avant tout
Posté par ckyl . En réponse au journal Deux ans de projet libre : bilan. Évalué à 4.
Ca n'a rien de particulier au logiciel libre. Dès qu'un projet à des utilisateurs tu as une liste de chose qu'ils voudraient longue comme le bras que tu ne pourras jamais faire. Donc tu prioritises ce que tu veux selon tes critères. Ca s'applique que tu sois tout seul ou dans une équipe de 100 personnes.
Je comprends parfaitement la remarque qui est a comprendre comme "si tu ne vois pas l'intêret ET que ca te fait chier de le faire
ne le fait pas". Évidement que si tu en vois l'intêret pour ton projet et que le coût est raisonnable tu vas le faire; enfin si il arrive un jour en haut des priorités.
[^] # Re: Juste une question
Posté par ckyl . En réponse au journal KDevelop 4.4 est sorti. Évalué à 2.
Juste pour préciser ma question n'était pas réthorique, quand je pose une question c'est que je pense que la réponse devrait être intéressante. Je comprends totalement l'intêret de pouvoir basculer sur gdb au besoin, mais je me demandais à quel point c'était actuellement nécéssaire.
Dans les langages que j'utilise depuis, tu as grosso modo un mapping 1-1 entre les debuggers bruts et l'intégration dans les IDE. Les IDE étaient tout moisis quand j'ai arrêter d'écrire du C. Donc ma question comportait deux volets: quelles actions ne sont actuellement pas disponibles dans les IDE et quelles actions de GDB ne sont conceptuellement pas insérable de manière satisfaisante dans les IDE.
Avec vos deux réponses je pense réussir à distinguer les deux catégories. Ca m'étonne que la plupart de ce qui a été listé ne soit pas dispo, les fonctionalités équivalentes existent dans d'autres langages (rbreak, tbreak, break conditionnel, catch, completion, print, remote debug) et sont "parfaitement" intégrés.
[^] # Re: Juste une question
Posté par ckyl . En réponse au journal KDevelop 4.4 est sorti. Évalué à 1.
Ca va faire 7/8 ans que j'ai pas lancé gdb pour autre chose que des conneries mais y'a quoi comme fonctionnalité qui n'est pas accessible depuis l'IDE ?
[^] # Re: Fin de panne
Posté par ckyl . En réponse au journal SourceForge dans les choux. Évalué à 2.
Comme souvent, faire des généralités implique de dire des bétises. Tout dépend du type de projet. Il y a des dizaines de projets que je n'ai téléchargé qu'une fois (et encore même pas puisque j'ai tiré un paquet) mais dont je consulte la doc en ligne tout les jours. C'est ma principale interface avec le projet en lui même (le reste étant ML/bugtracker/repository source des trucs souvent moins génant niveau dispo)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par ckyl . En réponse à la dépêche Documentation du format du Journal. Évalué à 1.
Le plus étonnant c'est qu'il y ait encore des gens qui prennent la peine de lui répondre. Ca ça m’impressionne !
[^] # Re: L'esprit du libre disparait...
Posté par ckyl . En réponse au journal Deux ans de projet libre : bilan. Évalué à 2.
A l'époque Sourceforge avait une section help wanted. Je crois pas que ca ait fait son chemin jusqu'aux plateformes d'aujourd'hui.
D'une manière générale le problème c'est que assez difficile de faire un truc avec un bon ratio bruit/signal et avec de l'info pertinente.
Pour la traduction et pour le francais en particulier tu devrais aller jeter un oeil à traduc.org. De longues années que j'y ai pas mis le pied et je ne sais absolument pas ce que c'est devenu mais normalement c'est quelque chose comme ca que tu cherches.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par ckyl . En réponse à la dépêche Documentation du format du Journal. Évalué à 2.
Non. Il en suffit d'un. Un seul.