freem a écrit 5059 commentaires

A chaud, je connais pas. Mais le temps et l'expérience m'ont donné une préférence pour les softs qui font qu'une chose, parce que je suis pas assez intelligent pour en faire plus. Du coup, en faire faire plus que je ne saurais moi-même faire à une machine plus conne que moi… non, clairement. Je suppose que ça rejoint ton auteur, que je vais aller lire de suite, ça pourra en fonction me faire rire, ou réfléchir. L'un comme l'autre étant bon à prendre, j'y vais :)

Juste, auparavant, qu'a ma prose de particulier (enfin, vu que quelqu'un semble avoir le même type, pas tant que ça) ou de commun avec cet auteur? Si mon opinion est proche, quel intérêt? Je vais lire de ce pas de toute façon, mais, pour les suivants…. on est côté forum ici, pas côté nourjal :)

Du coup, 3ème réponde à un même message….

Je connaissais le grymoire, mais j'avoue… le CTRL-F que j'y ai fait n'est pas pour ceux qui ont 1) un coup dans le nez (comme moi à cette heure) ou ceux qui sont du genre à taper la nuit blanche (encore, comme moi pour le moment, mais, vraiment, il est arrivé à de nombreuses reprises de lire des erreurs de compilation C++ et les comprendre sous les mêmes conditions! entraînement, je pense.)

donc, tu es l'auteur d'anvil… désolé, je retiens pour le moment plus le nom des projets que des devs :) ne le prend pas mal surtout!!!

Toujours est-il que j'ai entendu parler (enfin, lu, bref) en bien de ce projet, bravo. Ce mot semble tellement insignifiant quand on l'écrit, par rapport a ce que l'on pense… bref.

Pour en revenir au shell, j'ai commencé la journée d'hier (zut, il fait jour, donc, oui, hier…) à bouquiner la doc de netBSD en l'installant sur une VM. je suis sur la route de comprendre le sentiment engendré par sysvinit. Mais pas celui engendré par systemd.

Je ne sais pas si c'est malheureux ou pas, mais je suis un développeur C++, habitué à mélanger gestion de la mémoire, RTTI, RAAI et j'en passe, du coup j'ai du mal avec le shell brut. qui n'a aucune de ces notions. C'est difficile de passer de l'enfance ou maman compilo nous évite les faux pas au monde des vieux ou l'on bégaie tout le temps :) (juste une image, je ne considère pas le shell comme un langage de vieux, juste comme étant l'outil dont je me sers pour lancer vingt fois une appli binaire sur un ensemble de fichier…. fin bon, je pourrais pas l'expliquer à l'écrit: disons que je préfère la ligne de commande à la majeure partie des IHM, et que je sais pas pourquoi)

Bon… la flemme de chercher à faire un diff avec mon message précédent la. J'admets. Alors, voila, j'aurai voulu remplacer par ceci:

Je connais grymoire, oui. Mon dieu, si je croyais en toi, je penserai que c'est toi qui l'a pondu!

Franchement, c'est une référence, sur laquelle je suis tombé pour la première fois cette année. Hé oui, je suis un débutant sous unix, et ça va durer (que je me considère comme tel), parce que je compte passer aux BSD. Donc apprendre encore plus. Et celui qui apprend, apprend le plus souvent qu'il ne sait rien :) c'est pas pour rien que j'ai choisi le dev après tout. Ce sentiment de s'améliorer, d'être meilleur tout en sachant être toujours moyen dans le meilleur des cas, j'adore! Maso… peut-être un peu.

En tout cas, merci à toi pour partager ta connaissance du bs (bullshit? Non, bon sang, BourneShell!). Il est regrettable que trop de personnes sur le net se basent sur le bash ou ksh ou csh. Se baser sur les standards me semble être souvent une bonne chose, malgré les difficultés que ça implique parfois. Mais avec de bons documents, y'a jamais de soucis. Mais ils sont encore plus rares que les bons profs.

Pour ce qui est de grymoire, je dirai que c'est un ouvrage a destination des gens qui connaissent l'ordinateur. Pas des informaticiens en général.
J'aime beaucoup, pour expliquer à mes proches, expliquer que mon métier de dev (auto-proclamé, l'état refuse de me filer le papier…) consiste à traiter des informations, peu importe la science d'ou elles proviennent. Je préfère notre mot français au terme anglo-saxon de computer-scientist. Un bon dev, malgré le peu que j'ai croisé IRL me semble plus le type ouvert d'esprit, donc capable de traiter n'importe quelle informatiion, que le type capable de donner des ordres à une machine. J'ai envie de dire, le code, c'est comme le français au fond: de la philo.
Cela n'empêche pas grymoire d'être excellent. Les machines étant pour le moment plus connes que les humains, il faut leur parler de façon simple, et la simplicité est difficile (philo, encore?). Grymoire nous apprend à la maîtriser. Enfin, les bases, la syntaxe, le langage, juste lire le … grimoire…. C'est tout. et c'est déjà très bien.

Je connais grymoire, oui. Mon dieu, si je croyais en toi, je penserai que c'est toi qui l'a pondu!

Franchement, c'est une référence, sur laquelle je suis tombé pour la première fois cette année. Hé oui, je suis un débutant sous unix, et ça va durer (que je me considère comme tel), parce que je compte passer aux BSD. Donc apprendre encore plus. Et celui qui apprend, apprend le plus souvent qu'il ne sait rien :) c'est pas pour rien que j'ai choisi le dev après tout. Ce sentiment de s'améliorer, d'être meilleur tout en sachant être toujours moyen dans le meilleur des cas, j'adore! Maso… peut-être un peu.

En tout cas, merci à toi pour partager ta connaissance du bs (bullshit? Non, bon sang, BourneShell!). Il est regrettable que trop de personnes sur le net se basent sur le bash ou ksh ou csh. Se baser sur les standards me semble être souvent une bonne chose, malgré les difficultés que ça implique parfois. Mais avec de bons documents, y'a jamais de soucis. Mais ils sont encore plus rares que les bons profs.

Malheureusement, de nombreux programmeurs de métier tombent dans le même panneau.

Un langage de programmation, c'est une syntaxe qui permets de donner des ordres à un machine.
Une bibliothèque (ou library en anglais) c'est un ensemble de raccourcis permettant de donner des phrases à une machine.
Un cadriciel (arf, j'avoue, je ne parviens pas à mieux traduire ce terme en moins de 3 minutes!!! ok, donc, framework…. mais snif quoi) est un ensemble de bibliothèques permettant de traduire une façon de penser dans un langage qui n'a pas été prévu pour, ainsi que d'y ajouter des fonctionnalités.

C'est une définition personnelle et improvisée pour te répondre, à toi de juger de l'imbécilité de ma réponse.
Par exemple, Qt ou WxWidgets sont des cadriciels pour le langage C++ qui permettent une approche «complètement» objet à un langage qui se contente d'être orienté objet.
Pour ma part, je ne saurait te recommander qu'une chose: ne pense que par toi-même. N'utilise ces cadriciels que quand tu ne sais pas quoi utiliser d'autre, car, de mon opinion très personnelle, ils finiront par te bloquer. Bien sûr, être bloqué peut parfois être une bonne chose…. cela dépends de l'existant, et c'est un sujet de gestion de projet, pas de programmation.

En l'occurrence, ObjC c'est pas la propriété d'apple (ou p'tet que c'set libre, je sais plus exactement). Par contre, gnustep est libre, mais à une alternative non-libre (ben vi, je connais pas le nom de cette alternative, je sais juste que c'est elle qui est utilisée par l'objC sous apple….'fin, je m'embrouille moi-même la)

J'espère avoir aidé plus qu'embrouillé….

Franchement… qualifier ça de virus… c'est stupide.

Ouai, désolé, je suis dur. Mais, ici, c'est un forum de techniciens, on est censé savoir qu'exécuter une commande sans la comprendre à la fois stupide et dangereux.

Accessoirement, cette commande n'est pas un virus. Oui, c'est moi qui t'ai «moinssé» ou plutôt, t'ai «impertinenté». Une fois encore, ici, c'est un forum technique. Une commande, aussi néfaste qu'elle soit, n'est un virus que si elle s'intègre d'elle-même dans un autre exécutable (binaire ou non) sur le même système (sur un système tiers, c'est alors un vers, qui peut éventuellement être également un virus).

En l'occurrence, ce n'est pas le cas.
On à une commande, certes dangereuse, mais qui ne peux se propager excepté par stupidité de l'utilisateur (point qu'il est, cependant, utile de rappeler ici), et est d'ailleurs un usage valide, bien que peu prudent, d'une commande UNIX.
UNIX serait-il un virus pour toi?
Qualifies-tu rm -rf * de virus?

Mon opinion à ce sujet est peu glorieuse, et j'avais espéré que quelqu'un l'exprime de façon plus raffinée que je n'ai pu le faire. Malheureusement, je tombe sous le coup de certains dessins d'XKCD par moments, notamment quand personne ne réagit avant quelques heures à des propos d'incultes sur un forum technique.
Je n'ai pas arrêté de fréquenter développez.com pour rien. Ici, le moindre de mes propos peut être critiqué, en bien ou en mal, par tout le monde, et j'ai beaucoup appris ainsi, y compris de propos acerbes. Je suis acerbe ici, et ne me corriges pas volontairement parce que sinon, je serai condescendant, ce qui est encore pire pour moi. Mais ne le prend pas mal. Si je me trompe, il te suffit de me contredire en argumentant. Ainsi ce sera moi qui apprendrai. Malgré l'acide peut-être injustifié de mes mots.

Alors, si ça, ça ne vaut pas un pertinentage, je veux bien… heu… disons… p'tet pas me pendre, mais… je sais pas en fait.

C'est du bash, ou juste du sh? Parce que j'admets: si c'est du simple bash, ça ne m'intéresse pas tant que ça :) en revanche, pour du shell standard… je tomberai surement amoureux d'une fille (ouai, j'suis sexiste, j'aime que les demoiselles, pas les damoiseaux) qui me sort un truc de ce genre!
D'ailleurs, bash ou sh, va falloir que je me documente sur ce que c'est exactement, même si ça risque de virer à l'inutile (point de vue personnel, pas pro) vu que je compte passer à netBSD à la maison asap.

Ce genre de trucs m'arrive tout le temps avec bash. Souvent, retaper la commande à l'«identique» résout le problème. C'est à cause du fait qu'il m'arrive régulièrement d'omettre de lever mon doigt de la touche alt.gr. à un moment ou un autre, et du coup ce n'est plus un espace normal, donc find accepte pas.
C'est très pénible.

Commences par vérifier ça, on sait jamais. En tout cas, remplacer rm par cat ne m'affiche pas d'erreurs. Et je suis pas motivé pour mettre rm :p

Enfin, ceci étant dit, tu devrais vraiment songer à mettre + au lieu de \; : niveau perfs, ça risque d'être autre chose si ton dossier est un peu chargé.

2ème conseil: force un sous dossier de la racine, ou t'auras des surprises un jour: comme je l'ai dis, et d'autres, c'est déjà arrivé à des gens chevronné de se rater.

Héhé c'est arrivé à un collègue en prod ça :) et vu les mails, ça lui était arrivé un vendredi: il l'a bien cherché, je me moque encore de lui de temps en temps avec ça, alors qu'on est tous les deux partis :p

Enfin, c'était pas avec find, mais ça revenais au même.

Je plaide coupable, je n'ai même pas vérifié.

Bon, je vais faire semblant de défendre l'indéfendable: je me suis contenté de faire la synthèse de 2 billets de blogs, alors que cette dépêche semble créer du contenu.

Bon en fait même pas… ça semblait parler du projet entier, mais au final après une lecture en diagonale, ça parle quasi que du changement de techno. Vraiment indéfendable moi donc.

Il me semble que trac ne supporte (supportait?) qu'un projet par instance par exemple? Sinon, le template graphique est, de ce dont je me souviens, plus agréable.
Bon, c'est pas énorme non plus, et comme je l'ai dis, ça fait longtemps que j'ai pas regardé trac.

D’après le lien que tu donnes la version Linux c’est un .jar

Hé zut, j'avais oublié le cas Java… :)

Le lien vers l'image semble ne pas fonctionner. Mais bon, peu importe, je pense savoir ce que tu as: un fichier, soit avec l'extension .deb, soit avec une extension .tar.gz.

Dans le premier cas de figure, (aka, un .deb) il te faut les droits d'administration (sudo, su, peu importe) sur ta machine. A partir de là, la solution que je connais (il me semble qu'il en existe de plus "intuitives" mais j'aime bien les lignes de commande moi, en plus c'est facile à indiquer sur un forum ;)) est d'utiliser dpkg.
Pour cela, il te faut ouvrir un émulateur de terminal dans le dossier ou tu as téléchargé ton archive, puis taper su -c dpkg -i mon_fichier_.deb.
Si il y à un problème avec su (il me semble qu'Ubuntu n'active pas le compte root par défaut) tu devrais pouvoir le remplacer par sudo dpkg -i mon_fichier_.deb.

Si c'est un fichier de type .tar.gz, la solution en ligne de commande est ceci: tar -xzf mon_fichier_.tar.gz. Enfin, j'espère. J'ai toujours un doute avec tar… entre les -xzf ou -xjf… bref.
Ceci décompressera ton archive dans ton dossier, et tu devrais y avoir un fichier exécutable, que tu devrais pouvoir lancer en double cliquant dessus (ou simple clic, ça dépend de ta configuration pardi!).

PS: la prochaine fois, essaies d'ajouter un lien vers la page qui te permets de télécharger le fichier, ce sera plus clair. Et puis j'espère que ce n'est pas le code source du projet… parce que dans ce cas mon explication est à refaire complètement!

À la fois on est dans un mouvement qui la recherche, mais aussi d'un autre côté si pour réussir à aider il faut faire la psychanalyse de la personne que tu veux aider c'est un frein certain.

ça s'appelle les relations humaines. C'est vrai partout: au taf, tu peux pas proposer une amélioration sans comprendre comment la vendre, avec les potes tu sais de quels sujets et sur quels tons il vaut mieux éviter de parler, au bar tu évites certains sujets sensibles…
Là, on parle d'aider un type seul à gérer un projet d'ampleur, donc, de s'impliquer dans un gros truc. Ouai, ça me semble logique qu'il faille faire autre chose que juste proposer son aide. Démontrer qu'on est capable de faire un truc seul étant un excellent premier pas.

Bon, après, il y à l'art et la manière d'envoyer chier. Mais on n'est pas toujours d'humeur… j'ai lu vite fait les logs, jusqu'à la proposition d'aide et quelques lignes ensuite. Je pense que ce qui à mis la discussion dans la mauvaise direction, c'est ça:

04:36 < maatunix> but can't we make new images after solving a major bug ?
04:36 < xtraeme> "we" or myself?

Perso, si j'avais voulu aider, j'aurai amené la chose de façon plus délicate. Là, l'impression qu'il à pu avoir c'est que l'OP se croyait déjà dans le projet… ça peut froisser des sensibilités.

D'un autre côté, manjaro est probablement bien moins rentable pour SF que gimp ou filezilla hein. C'est une distribution (probablement) minoritaire utilisant un noyau minoritaire (sur les machines de bureau, du moins).
Du coup, ça doit pas mal aider.

Ensuite, il y à aussi le problème qu'un certain nombre de téléchargeurs utilisent peut-être les torrents ou d'autres miroirs (je ne sais pas s'ils ont d'autres miroirs en place que SF pour le coup) voire, pourquoi pas, les hash qui sont hébergés sur le site de manjaro eux-même, et donc «impossibles» à modifier (du moins, pas sans attaquer manjaro directement).

Dans le cas d'une SVG, pas de problème :)

Sinon, je dirais que c'est dommage de ne pas utiliser de système pour générer les images finales à partir d'un set d'images.
Je veux dire, imaginons un écran d'accueil, avec un logo et un menu dessus.
Versionner directement la version finale me semble être une erreur, il me paraît plus sage de versionner N images, une contenant le logo, une autre contenant chaque entrée du menu (dans le cas ou ce n'est pas géré directement par le programme, mais c'est pour essayer d'avoir plus de fichiers ;)), et une dernière contenant le fond.
Lors de la compilation (du make, ou peu importe le processus), il devrait alors être possible d'assembler les images pour obtenir une image finale.

Du coup, il serait possible de réutiliser le fichier de logo, et donc de ne modifier qu'une seule image (ou N images s'il existe N versions du logo, de différentes tailles par exemple). Ok, on ne pourrait pas le faire avec sed… ou alors si: si le nouveau logo est stocké dans un fichier différent, il devient possible de faire un sed sur le nom de fichier.

Pour comparer avec les binaires, il sera difficile de faire un sed sur l'exécutable de ton projet. Par contre sur les sources, c'est très simple.

Certes, j'aurai du préciser que ma réponse était un raccourcis :)

C'est aussi le cas de GitHub!

CF ma réponse un peu plus loin.

je passe souvent mon temps à explorer des patrons de contenu “ce projet n'a publié aucune documentation”, “ce projet n'a publié aucun X” etc. plus que du contenu lui-même

Personnellement, le soin apporté à l'init du projet me permet de jauger quelques peu le sérieux du projet. Ce qui est une donnée en soit.
Je pense que si OpenMW s'approche de la bêta à grands pas, c'est grâce au fait que le projet soit super bien encadré depuis sa reprise. Pour des projets moins ambitieux, c'est vrai que ce serait excessif, mais des infos telles que le stade de complétion selon l'auteur me semblent très importantes.
À une époque sur SF il était possible de faire une recherche des projets ayant dépassé un stade précis (spécifié par l'utilisateur).
Je ne sais pas si c'est encore possible aussi facilement, mais ça me semble impossible sur github.

les tables HTML des années 90 donnent un aspect vieillissant au site, et j'en passe.

Aucun rapport avec la clarté ou la légèreté, si? Pour ce qui est du goût du jour, je préfère personnellement les interfaces des sites web des années 90-00: je les trouve moins tape-à-l'œil. Même si les choix de couleur sont parfois, faut avouer, douteux (savannah à effectivement merdé de ce côté). Mais, c'est une question de goûts.

Ça m'intéresse de savoir par exemple ce que Savannah a de plus de gitlab par exemple en terme d'interface.

J'ai comparé avec github, pas gitlab que je ne connais pas.

Niveau légèreté, le fait de n'être pas bourré de JS dans tous les sens pour faire des trucs aussi triviaux que répondre à un bug doit certainement jouer. Github est une calamité en terme de perf, par moments je suis obligé de faire une pause dans ma frappe pour que ce que j'ai écrit s'affiche à l'écran!
Bref, une calamité.

Niveau clarté… ce n'est peut-être que mon opinion, mais certaines informations qui me semblent importantes quand je cherche un projet manquent sur github. Je parle de clarté pour la personne qui cherche un soft, hein, pas pour les développeurs.
Parce que je pense que les forges ont aussi pour rôle de permettre de faire découvrir les projets au grand public.

Le stade de complétion par exemple.
Dans la discussion, quelqu'un à abordé le fait que sur SF la plus grande part des projets n'est pas finie. Ça peut se savoir assez facilement (bon, sur SF l'info à été planquée, ce qui est stupide mais bon…) sur savannah: il y à un champ «Stade de développement : 1 - Planning» (un projet au hasard) que l'on peut noter directement, juste en dessous de la licence, elle-même en dessous de la description du projet.
Sur github, je ne vois pas cette information.

Ensuite, on peut accéder au site web du projet très simplement, que ce soit sur SF ou savannah: il y à un lien que l'on peut voir sans scroller.
Dans le cas de github, la «solution» est de le mettre dans le readme. Déjà que c'est peu pertinent (l'info ne me semble pas à sa place dans le readme) en plus ça ne sera jamais au même endroit, et pas nécessairement mis en valeur.

Les forges classiques offrent également un système de news, qui permets d'informer l'utilisateur de ce qui s'est passé autour du projet, genre, un évènement type… je sais pas… bug squashing party, rencontre irl, tournoi, remerciements à un contributeur, arrivée d'un nouveau dev dans l'équipe, que sais-je?
Ou, tout simplement, des information pré-digérée pour un utilisateur non codeur, qui soient plus adaptées que des commits. Genre, nouvelle version stable, avec, soyons fous, un changelog allégé (genre ceux que battle for wesnoth publient pour les joueurs).

Il reste encore pas mal de détails ici et là qui font que, pour moi, github ne peux pas battre les forges classiques auprès des utilisateurs de logiciel. Encore une fois, je parle des utilisateurs, pas des contributeurs. Et sans utilisateur, difficile d'avoir des contributeurs.
Bref, pour moi, github est une solution d'hébergement de code source, pas une forge complète.

Après, pour être totalement honnête, certaines fonctionnalités seraient intéressantes, si github n'était pas aussi lourd. Pour discuter d'un bout de code, le fait de pouvoir annoter est potentiellement très utile. Dommage, c'est tellement lourd en JS que c'est quasi inutilisable pour moi.

J'espère avoir un peu explicité mon point de vue, de manière pas trop subjective.

Merci pour la bonne blague.

De rien.

Parce que tu juges sérieusement Savannah possible pour l'utilisateur final?

Oui.

Tu m'excuseras de développer autant que toi.

mais on peut se réjouir de voir qu'ils offrent une API claire

En fait, je parlais d'interface utilisateur, claire et légère, pas d'API. Niveau clarté, c'est peut-être mon opinion personnelle, mais question lenteur, c'est flagrant comparé aux autres forges. Afficher certaines pages me prend parfois plus de 10s, quand ça ne bug pas.

je trouve trac mille fois plus clair et léger

Je lui préfère redmine. Du moins c'était le cas la dernière fois que j'ai comparé les deux.

Tu vas aller loin tout seul…

Hum… Bof. Sauf obfuscation volontaire, un coup de sed suffit. Ou alors, proposer un premier patch pour nettoyer ça, histoire de faire autre chose que juste forker.

Dans ce cas, il est surprenant que la majorité des sites de l'époque était optimisée pour IE , non? Bon, ok, j'ai pas de sources, mais ça tombe bien je suis pas le seul hehe