OK, je ne remet pas en cause le fait que a soit fun et tout, c'est un argument tout à fait acceptable. Par contre, j'ai quelques remarque sur les autres arguments.
Pour commencer, pour moi un gestionnaire de paquets c'est un (ou plusieurs) outils automatisant le processus d'installation, désinstallation, mise-à-jour de logiciels installés sur un système informatique. Il me semble, en tant que béotien incompétent, que cette définition de Wikipédia colle bien à Zen, quand bien même ce serait un gestionnaire très simple et léger par rapport à ce que peuvent faire des trucs comme APT/DEB et compagnie.
Ensuite, en tant qu'utilisateur lambda, ce que je perçoit (mais c'est sans nul doute un biais, d'où mes questions), c'est que je vais encore devoir me rappeler une autre commande d'installation, qui ne sera pas incluse dans mon interface graphique favorite, que je devrais réussir à faire maintenir par mon adminsys dans un autre dépôt séparé (et qu'il va raler), etc.
J'imagine (mais je peux me tromper) que si l'on avait un FORMAT de données et un protocole unifié, ça n'enlèverait rien à la portabilité (on peut recoder le système dans le langage de son choix), mais ça aiderait beaucoup à la facilité d'emploi (j'installe avec mon gestionnaire favoris, sans avoir à en apprendre un nouveau).
Bien sûr, on va me rétorquer que c'est pas compliqué d'apprendre une commande, que ça impose des contraintes aux devs... certes, mais ça ne me parait pas être des arguments très pertinents (on peut en discuter, mais ce serait tellement pénible que ça ne me tente pas trop).
Bon, désolé que la question soit tombé sur vous, vu que Zen est vraiment le truc tellement simple que ça justifie presque tout, mais il fallait quand même que je pose la question, et il n'y a pas de news sur Python setuptools en ce moment.
J'ai une vraie question en forme troll : pourquoi un énième système de paquetage ?
Python a son distuil, TeX son CTAN, Perl son CPAN, sans compter les DEB et autres RPM, etc.
Je n'arrive pas à trouver un argument rationnel suffisamment fort pour justifier l'absence de coordination au niveau des formats et des protocoles à ce niveau. Qu'est-ce qui empêcherait d'avoir un système unifié au niveau format, quitte à avoir des implémentations dans tel ou tel langage, quand on veut minimiser les dépendances ?
On m'a soufflé à l'oreille que CPAN6 cherchait à faire ça ? Le putch raté de LSB pour RPM aurait-il stoppé net des velléités de type freedesktop dans ce domaine ? quidquid latine dictum sit, altum sonatur ?
En même temps, comme je n'y connais rien, je dois rater l'argument massue qui justifie tout ce temps perdu, cette interopérabilitée ratée et cette complexification inutile... aidez-moi à comprendre.
Pour ceux qui ne sont pas versés dans l'art - difficile - des locutions latines, sachez que Horresco referens signifie "je frémis en le racontant".
En surfant sur Wikipédia, vous apprendrez que c'est "l'exclamation d'Énée racontant la mort de Laocoon (Virgile, L'Énéide, chant II), souvent utilisée ironiquement" (cf. NFFNSNC#H).
Si les médias en parlent en ce moment, et n'en ont pas du tout parlé pendant le passage au sénat, c'est surtout que le gouvernement a un service presse efficace.
Bon exemple sur France Culture ce matin : débat entre l'efficace M. Riesler, rapporteur du projet de loi, et le médiocre M. Ridouan, président des Audionautes. Riesler a haché menu son interlocuteur, qui n'a fait que répéter bêtement « de toute façon tout le monde télécharge », alors même que le journaliste a tout fait pour lui tendre des perches sur les risques en matière de liberté, les dommages collatéraux de la loi, les études scientifiques sur les pratiques, etc.
Bilan, si j'étais à la place d'un citoyen indécis, après cette émission j'aurais clairement l'impression que le gouvernement allège les choses pour l'individu lambda, en tentant d'apprendre les bonnes manières à des adolescents immatures qui veulent voler le pain des français.
Si les opposants au projet n'ont que ce genre de gus à envoyer aux journalistes, ça ne m'étonne plus que les médias préfèrent s'en tenir aux membres du gouvernement.
Donc, contactez si vous voulez, mais proposez des intervenants de qualité, sans quoi le remède est pire que le mal.
Je ne vois pas le rapport. Par exemple quand tu ouvres un nouveau shell après quelques temps, tu ne te souviens pas forcément de ton historique immédiat. L'équivalent dans un shell consisterait soit à faire de la recherche incrémentale, mais l'historique est limité et ça demande à taper plus, soit à mettre des liens symboliques à la main, mais c'est chiant à maintenir.
Avec autojump, tu as un raccourcis rapide à taper et qui apprend tout seul, c'est original, c'est utile, c'est bien.
Et puis d'abord, d'où viens cette propension idiote à vouloir expliquer aux gens comment se passer d'une chose dont ils ont besoin ? Une enfance malheureuse ? Un manque de reconnaissance ? Un déficit en calcium ?
En ce qui me concerne, autojump rentre tout à fait bien dans la manière dont j'utilise le shell (et j'utilise déjà la recherche dans l'historique de bash), donc je suis preneur.
Pour éviter les erreurs dont tu parles, je pense qu'une simple autocomplétion suffirait à régler le problème : quand on est pas sur du motif, un coup de [TAB] et on voit tout de suite si c'est bon.
De même, j'imaginerais assez bien qu'un double [TAB] permette de rechercher dans l'ensemble des répertoires (en utilisant la base de locate ça devrait aller vite)...
Le titre parle de "combinatorial search", or, il n'y a pas que la programmation par contrainte qui rentre dans ce cadre, il y aussi les algorithmes évolutionnistes/métaheuristiques/recherche locales stochastiques qui rentrent dans ce cadre. Et aller, on peut même parler des méthodes d'approximation, génération de colonne, etc. même les réseaux de neurones peuvent faire de l'optimisation combinatoire... et toutes sont soumises à des programmes de recherche visant au paramétrage automagique, gros problème très répandu.
Certains enseignants prennent la peine d'écrire des articles Wikipédiens sur les sujets qu'ils enseignent, afin de donner une synthèse et des liens pour compléter le cours.
Certains vont même jusqu'à faire des cours via "Wikiversité", projet soeur de Wikipédia, où le but est de proposer des cours avec une coloration pédagogique forte : http://fr.wikiversity.org
Pour openesub (cité dans le journal), le moteur du jeu est tellement libre qu'il y a même des systèmes d'aide à la décision qui l'utilise.
La solution retenue pour que le jeu reste intéressant est de ne proposer qu'une information imparfaite sur l'état du jeu. Le jeu combine donc des incertitudes sur la positions des sous-marins et sur les choix tactiques des joueurs. Tout est donc public (code source et fichiers de configuration), sauf que dans une partie, le serveur filtre les informations renvoyées aux joueurs. Les logiciels de simulation permettent de réduire l'incertitude, mais pas complètement, et ils rajoutent un petit coté technique amusant (surtout pour de développeurs).
Openesub est d'ailleurs un bon exemple que la peur de l'installation parallèle est tout de même un peu irrationnelle en pratique. Je trouverais par exemple particulièrement intéressant que le jeu soit proposé en anglais, ou avec une ambiance "vaisseaux spatiaux" plutôt que "guerre sous-marine"... Pourtant, ça n'est jamais arrivé !
J'avoue être un peu largué, quelle est la différence entre le comité et le reste ? Le comité a organisé un truc sans en avertir ceux qui font la communication ? Quel problème technique justifie une absence totale de retour, j'imagine que les participants peuvent tout de même comprendre, même si on leur dit que le concours est à l'eau.
Enfin, bref, d'une manière générale je ne serais pas contre une petite explication, même si elle doit se faire uniquement à destination des contributeurs...
Sinon, j'ai choisi le journal parce que les messages sur la page du concours sont restés sans réponse, et quand on a pas de réponse, il vaut mieux viser plus large. Que baud123 n'y voit aucune malice, ce sont juste des considérations d'efficacité qui m'ont poussé à choisir le journal.
Ce qui est d'autant plus surprenant qu'il y avait eu un concours de design de modèles, voilà longtemps. J'avais soumis un truc, mais je n'ai jamais eu de nouvelles... je me demande ce que c'est devenu, ce concours, tiens.
LyX est clairement un très bon compromis entre les deux mondes, dans le sens où il permet de masquer les commandes LaTeX les plus courantes par une mise en page visuelle. De plus, pour ceux qui ne rédigent pas suffisamment souvent pour se souvenir facilement des commandes, il permet de s'y retrouver rapidement en parcourant les différents menus, ce qui est une manière d'apprendre qui marche mieux que de lire un bouquin (même excellent) chez beaucoup de personne.
Un gros document est par exemple beaucoup plus agréable à parcourir sous LyX que dans un éditeur LaTeX, même bien fait (comme Kile).
En plus, tu peux insérer des commandes LaTeX directement dans le document, bidouiller le préambule, etc. LyX a donc peu de limitations par rapport à un éditeur LaTeX pur.
Tu n'es pas obligé de faire des boulettes avec S5. Vu que ça reste finalement une page HTML, tu peux même y mettre des vidéos. De même, le style est assez simple à gérer, avec CSS. Il y a même des extensions pour faire des animations à la con (mais qui rament).
Du coup, tu as l'avantage d'avoir un langage répandu (éditer du HTML n'est pas hyper compliqué) et facile à lire (il y a toujours un navigateur où que tu sois).
Donc au final, pour faire des présentations à images, c'est tout à fait approprié.
Je constate qu'il y a une majorité qui se réclame admin-sys, et que personne ne se dit hacker... c'est une injuste violation du principe de saine répartition démocratiquement égalitaire, il va falloir recruter du codeur, les enfants.
Les outils « moderne » de compilation (c'est à dire les autotools, scons, cmake, etc.) ont clairement beaucoup d'avantage sur la construction « à la main » d'un Makefile. En deux mots, tu lui dit juste de compiler, et il va te chercher ce qu'il faut tout seul pour te sortir ton executable, là où avec make il faut penser à tout avant. C'est en quelque sorte l'étape d'abstraction au dessus de make.
Le vrai débat, est plus « lequel choisir » ? La plupart des gens semblent d'accord pour penser que les autotools sont assez peu amicaux avec l'utilisateur, donc le débat est plutôt « SCons ou CMake ? ».
Pour la compilation, regarde du coté de SCons [1] ou de CMake [2]. Une fois qu'on a pris le temps de s'y mettre, on ne reviens plus en arrière.
Sinon, ça fait plusieurs fois que je me dis en lisant ton code de CIMG que tu devrais absolument te mettre à boost [3], ça t'éviterais pas mal de corvées. Pour G'MIC, je ne dis rien, je n'ai pas réussi à trouver où était le code (je suis d'ailleurs étonné que les habituels raleurs n'ait pas relevé... ah merde, je viens de le faire, en fait).
Sinon, c'est chouette de voir que tu continues à faire du bon boulot, on en veut encore :-)
J'aime bien SCons pour le coté python, qui permet de rajouter des fonctionnalités exotiques (je me suis par exemple amusé à le brancher sur Kdevelop pour faire des zip de release : http://nojhan.free.fr/article.php3?id_article=91 ).
J'aime moins SCons sur la longueur, car il tend naturellement à produire des gros scripts baveux difficiles à maintenir... effet de bord de la souplesse, à mon avis.
CMake à l'avantage d'être plus clair dans sa conception, mais moins souple à l'usage, avec une syntaxe peu ragoutante, là où SCons... bah, c'est du joli python, quoi.
Je trouve également SCons un poil plus intuitif pour mon esprit tordu, mais CMake est plus carré pour des gros projets.
Par exemple, faire un script qui télécharge le dernier SVN, le compile, en fait un zip pour la release et envoie le tout par FTP, il n'y à que sous SCons que c'est agréable.
Au final, j'utilise CMake pour des gros projets avec pleins d'autres gens, et SCons pour des petits où je veux tout automatiser sans risquer de faire chier mes collègues.
Avantage : le SVG s'édite avec plaisir sous Inkscape, l'interactivité n'est pas loin et c'est du web.
Inconvénients : je ne connais pas d'interface propre pour gérer l'animation, il faut faire le JS à la main, ce n'est pas hyper répandu... je ne suis même pas sûr que ça passe bien sous Firefox (si qqun a testé, je suis intéressé).
En France, si quelqu'un emet des doutes sur la portée historique du génocide en Arménie, s'il affirme qu'un animateur d'émission télévisuelle ringarde est mort, ou s'il reprend un ragot concernant la vie amoureuse d'un acteur de cinéma, il verse dans l'illégalité. L'hébergeur du contenu incriminé et le fournisseur d'accès sont obligés par la loi de fournir ses coordonnées, sous peine d'être poursuivis à leur tour, et éventuellement fermés.
Par exemple, Linuxfr.org pourrait être obligé de fermer parce qu'il aurait refusé de donner l'IP d'un internaute qui aurait mis un commentaire mettant en doute les capacités sexuelles de l'occupant de l'élysée.
Autre exemple, on pourrait très bien (en capillotractant un peu) imaginer que l'association des utilisateurs de Wikipédia soit obligé de fermer parce qu'un quebecquois y aurait inséré les doutes de M. LePen sur l'importance de la Shoah...
Alors, bien ou pas bien ? Vit-on dans une dictature qui nous oprime ? Sommes-nous des moutons ? Les indiens devraient-ils venir prendre des cours en France ? L'inverse ? La morale ne serait-elle donc qu'une notion culturelle relative ? etc.
À mon humble avis, il est fort délicat de se poser en arbitre des définitions et des limites des libertés indivuelles.
Une licence « libre » oblige à citer l'auteur, mais pas à l'informer.
Dans les faits, il faut bien garder à l'esprit que demander à prévenir l'auteur, c'est empécher un très grand nombre de réutilisations. Dans les faits, les gens ne souhaitent pas le faire, ça perd du temps, c'est chiant, ça ne marche pas.
D'autre part, la peur que quelqu'un d'autre se fasse des sous sur notre dos est, dans les faits, infondée également. D'abord parce que très peu de gens le font, et ensuite parce qu'ils ne gagnent rien dessus.
Bref, ce sont pour beaucoup des peurs irrationnelles (j'ai eu les mêmes, c'est normal) :-)
Il y a Fedora, oui, mais de mon point de vue d'utilisateur, ça reviens exactement au même que vouloir Ubuntu ou n'importe quelle distribution de ce genre... dans tous les cas, ce n'est pas celle que m'installe mon administrateur.
Le problème ici est qu'il y a un conflit d'intérêt entre les administrateurs systèmes, qui veulent une machine robuste à administrer, et les utilisateurs qui ont besoin de logiciels récents. Avoir les deux est impossible, et c'est bien pour ça que je dis qu'un discours simplistes sur ce que l'« on » souhaite en entreprise est à éviter.
[Les entreprises] veulent du service ! Elles en ont rien à foutre de changer de distribution si c'est pour 3 fois rien. En tout cas, c'est ainsi pour les serveurs.
Si je puis me permettre, « les entreprises », ça ne veut rien dire, pour la bonne et simple raison que, maintenant, l'informatique est utilisée partout. Et quand bien même tu aurais identifié un type d'entreprise, ça ne voudrait pas dire grand chose non plus, parce qu'au sein d'une boite, tu as des utilisations très différentes.
Par exemple, dans la grande entreprise de haute technologie où je travaille, les administrateurs systèmes nous imposent une RHEL 5, pour les raisons que tu cites. Et bien moi, j'y travaille dans cette boite, et je peux te dire que ça me casse les pieds.
La RedHat est certes bien pratique pour faire de l'administration système sur les PC bureautique des secrétaires, mais elle est grave à la ramasse pour faire de la recherche informatique, par exemple. Les logiciels sont trop anciens, les dépôts fournis trop restreints, les compatibilités trop chiantes, etc. Là où une Ubuntu est un vrai plaisir.
Bref, un peu de subtilité et de compassion pour les utilisateurs (par opposition aux administrateurs) ne ferait sans doute pas de mal à ton discours, pourtant certes intéressant sur l'improbable naiveté de Shuttleworth.
[^] # Re: Gestionnaires de paquetage
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Restez ZEN avec ZSH. Évalué à 3.
Pour commencer, pour moi un gestionnaire de paquets c'est un (ou plusieurs) outils automatisant le processus d'installation, désinstallation, mise-à-jour de logiciels installés sur un système informatique. Il me semble, en tant que béotien incompétent, que cette définition de Wikipédia colle bien à Zen, quand bien même ce serait un gestionnaire très simple et léger par rapport à ce que peuvent faire des trucs comme APT/DEB et compagnie.
Ensuite, en tant qu'utilisateur lambda, ce que je perçoit (mais c'est sans nul doute un biais, d'où mes questions), c'est que je vais encore devoir me rappeler une autre commande d'installation, qui ne sera pas incluse dans mon interface graphique favorite, que je devrais réussir à faire maintenir par mon adminsys dans un autre dépôt séparé (et qu'il va raler), etc.
J'imagine (mais je peux me tromper) que si l'on avait un FORMAT de données et un protocole unifié, ça n'enlèverait rien à la portabilité (on peut recoder le système dans le langage de son choix), mais ça aiderait beaucoup à la facilité d'emploi (j'installe avec mon gestionnaire favoris, sans avoir à en apprendre un nouveau).
Bien sûr, on va me rétorquer que c'est pas compliqué d'apprendre une commande, que ça impose des contraintes aux devs... certes, mais ça ne me parait pas être des arguments très pertinents (on peut en discuter, mais ce serait tellement pénible que ça ne me tente pas trop).
Bon, désolé que la question soit tombé sur vous, vu que Zen est vraiment le truc tellement simple que ça justifie presque tout, mais il fallait quand même que je pose la question, et il n'y a pas de news sur Python setuptools en ce moment.
# Gestionnaires de paquetage
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Restez ZEN avec ZSH. Évalué à 3.
Python a son distuil, TeX son CTAN, Perl son CPAN, sans compter les DEB et autres RPM, etc.
Je n'arrive pas à trouver un argument rationnel suffisamment fort pour justifier l'absence de coordination au niveau des formats et des protocoles à ce niveau. Qu'est-ce qui empêcherait d'avoir un système unifié au niveau format, quitte à avoir des implémentations dans tel ou tel langage, quand on veut minimiser les dépendances ?
On m'a soufflé à l'oreille que CPAN6 cherchait à faire ça ? Le putch raté de LSB pour RPM aurait-il stoppé net des velléités de type freedesktop dans ce domaine ? quidquid latine dictum sit, altum sonatur ?
En même temps, comme je n'y connais rien, je dois rater l'argument massue qui justifie tout ce temps perdu, cette interopérabilitée ratée et cette complexification inutile... aidez-moi à comprendre.
# Locution latine
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Rhythmbox 0.12 "Flood Victim" est sorti. Évalué à 10.
En surfant sur Wikipédia, vous apprendrez que c'est "l'exclamation d'Énée racontant la mort de Laocoon (Virgile, L'Énéide, chant II), souvent utilisée ironiquement" (cf. NFFNSNC#H).
Libido sciendi ? Doctus cum libro !
[^] # Re: Mauvaise impression
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal Contactons les médias!. Évalué à 10.
Bon exemple sur France Culture ce matin : débat entre l'efficace M. Riesler, rapporteur du projet de loi, et le médiocre M. Ridouan, président des Audionautes. Riesler a haché menu son interlocuteur, qui n'a fait que répéter bêtement « de toute façon tout le monde télécharge », alors même que le journaliste a tout fait pour lui tendre des perches sur les risques en matière de liberté, les dommages collatéraux de la loi, les études scientifiques sur les pratiques, etc.
Bilan, si j'étais à la place d'un citoyen indécis, après cette émission j'aurais clairement l'impression que le gouvernement allège les choses pour l'individu lambda, en tentant d'apprendre les bonnes manières à des adolescents immatures qui veulent voler le pain des français.
Si les opposants au projet n'ont que ce genre de gus à envoyer aux journalistes, ça ne m'étonne plus que les médias préfèrent s'en tenir aux membres du gouvernement.
Donc, contactez si vous voulez, mais proposez des intervenants de qualité, sans quoi le remède est pire que le mal.
[^] # Re: Tant pis pour les décourageurs...
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Autojump : une manière plus rapide de naviguer dans le système de fichiers avec la ligne de commande. Évalué à 2.
Avec autojump, tu as un raccourcis rapide à taper et qui apprend tout seul, c'est original, c'est utile, c'est bien.
Et puis d'abord, d'où viens cette propension idiote à vouloir expliquer aux gens comment se passer d'une chose dont ils ont besoin ? Une enfance malheureuse ? Un manque de reconnaissance ? Un déficit en calcium ?
[^] # Re: Tant pis pour les décourageurs...
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Autojump : une manière plus rapide de naviguer dans le système de fichiers avec la ligne de commande. Évalué à 3.
Pour éviter les erreurs dont tu parles, je pense qu'une simple autocomplétion suffirait à régler le problème : quand on est pas sur du motif, un coup de [TAB] et on voit tout de suite si c'est bon.
De même, j'imaginerais assez bien qu'un double [TAB] permette de rechercher dans l'ensemble des répertoires (en utilisant la base de locate ça devrait aller vite)...
[^] # Re: Tuning automatique de paramètres
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal Le labo commun Inria-Microsoft. Évalué à 1.
Bref, le titre ne dit pas grand chose, en fait.
[^] # Re: Wikipedia "en"
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal 3/4 de million d'articles pour wikipedia en français. Évalué à 5.
Certains vont même jusqu'à faire des cours via "Wikiversité", projet soeur de Wikipédia, où le but est de proposer des cours avec une coloration pédagogique forte : http://fr.wikiversity.org
[^] # Re: Moi aussi
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal Les jeux par navigateur et le libre. Évalué à 1.
La solution retenue pour que le jeu reste intéressant est de ne proposer qu'une information imparfaite sur l'état du jeu. Le jeu combine donc des incertitudes sur la positions des sous-marins et sur les choix tactiques des joueurs. Tout est donc public (code source et fichiers de configuration), sauf que dans une partie, le serveur filtre les informations renvoyées aux joueurs. Les logiciels de simulation permettent de réduire l'incertitude, mais pas complètement, et ils rajoutent un petit coté technique amusant (surtout pour de développeurs).
Openesub est d'ailleurs un bon exemple que la peur de l'installation parallèle est tout de même un peu irrationnelle en pratique. Je trouverais par exemple particulièrement intéressant que le jeu soit proposé en anglais, ou avec une ambiance "vaisseaux spatiaux" plutôt que "guerre sous-marine"... Pourtant, ça n'est jamais arrivé !
[^] # Re: réponse d'un "proche de l'organisation"
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal Concours de logo RMLL 2009 : flop. Évalué à 8.
Enfin, bref, d'une manière générale je ne serais pas contre une petite explication, même si elle doit se faire uniquement à destination des contributeurs...
Sinon, j'ai choisi le journal parce que les messages sur la page du concours sont restés sans réponse, et quand on a pas de réponse, il vaut mieux viser plus large. Que baud123 n'y voit aucune malice, ce sont juste des considérations d'efficacité qui m'ont poussé à choisir le journal.
[^] # Re: Impress
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal OpenOffice 3.0 : lacunes & améliorations possibles. Évalué à 6.
[^] # Re: Discussion...
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Un nouveau framabook sur LaTeX. Évalué à 4.
Un gros document est par exemple beaucoup plus agréable à parcourir sous LyX que dans un éditeur LaTeX, même bien fait (comme Kile).
En plus, tu peux insérer des commandes LaTeX directement dans le document, bidouiller le préambule, etc. LyX a donc peu de limitations par rapport à un éditeur LaTeX pur.
À mon avis, il faut au moins l'essayer.
http://www.lyx.org
# S5
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal Faire une présentation pour une conférence ?. Évalué à 3.
Du coup, tu as l'avantage d'avoir un langage répandu (éditer du HTML n'est pas hyper compliqué) et facile à lire (il y a toujours un navigateur où que tu sois).
Donc au final, pour faire des présentations à images, c'est tout à fait approprié.
# Et des codeuses ?
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Dix ans de DLFP : entretien avec l'équipe LinuxFR 1/3. Évalué à 1.
Et sinon, elles sont où les modératrices ? (|)
# Différences avec OTRS ?
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Ouverture de Tosca. Évalué à 1.
Quels sont les principales différences entre ces deux logiciels ?
[^] # Re: Pourquoi SCons ?
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche SCons 1.0. Évalué à 3.
Le vrai débat, est plus « lequel choisir » ? La plupart des gens semblent d'accord pour penser que les autotools sont assez peu amicaux avec l'utilisateur, donc le débat est plutôt « SCons ou CMake ? ».
Pour le troll les arguments, voir ce fil récent, sur la même nouvelle :
http://linuxfr.org/comments/957416.html#957416
Sinon, on peut aussi lire les discussions autour du choix du projet KDE, qui a fait couler beaucoup d'encre.
[^] # Re: bon ben c' est simple....
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. Évalué à 2.
Sinon, ça fait plusieurs fois que je me dis en lisant ton code de CIMG que tu devrais absolument te mettre à boost [3], ça t'éviterais pas mal de corvées. Pour G'MIC, je ne dis rien, je n'ai pas réussi à trouver où était le code (je suis d'ailleurs étonné que les habituels raleurs n'ait pas relevé... ah merde, je viens de le faire, en fait).
Sinon, c'est chouette de voir que tu continues à faire du bon boulot, on en veut encore :-)
[1] http://www.scons.org/
[2] http://www.cmake.org
[3] http://www.boost.org/
[^] # Re: scons pas bien
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal scons 1.0. Évalué à 2.
J'aime moins SCons sur la longueur, car il tend naturellement à produire des gros scripts baveux difficiles à maintenir... effet de bord de la souplesse, à mon avis.
CMake à l'avantage d'être plus clair dans sa conception, mais moins souple à l'usage, avec une syntaxe peu ragoutante, là où SCons... bah, c'est du joli python, quoi.
Je trouve également SCons un poil plus intuitif pour mon esprit tordu, mais CMake est plus carré pour des gros projets.
Par exemple, faire un script qui télécharge le dernier SVN, le compile, en fait un zip pour la release et envoie le tout par FTP, il n'y à que sous SCons que c'est agréable.
Au final, j'utilise CMake pour des gros projets avec pleins d'autres gens, et SCons pour des petits où je veux tout automatiser sans risquer de faire chier mes collègues.
[^] # Re: Tableau blanc
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Le client Jabber/XMPP Psi en version 0.12. Évalué à 2.
# SVG, Javascript, SMIL
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal [cherche] outils de réalisation d'animation 2D. Évalué à 4.
* http://www.w3.org/TR/SVG11/animate.html
* http://srufaculty.sru.edu/david.dailey/svg/SVGAnimations.htm
Avantage : le SVG s'édite avec plaisir sous Inkscape, l'interactivité n'est pas loin et c'est du web.
Inconvénients : je ne connais pas d'interface propre pour gérer l'animation, il faut faire le JS à la main, ce n'est pas hyper répandu... je ne suis même pas sûr que ça passe bien sous Firefox (si qqun a testé, je suis intéressé).
[^] # Re: bientôt en prod' ?
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal Sortie de Strip-It version 0.5. Évalué à 3.
Pour la faute, la réponse est dans la question :-)
[^] # Re: Et ?
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal Google aide le gouvernement indien à arrêter les méchants blasphémateurs. Évalué à 10.
Par exemple, Linuxfr.org pourrait être obligé de fermer parce qu'il aurait refusé de donner l'IP d'un internaute qui aurait mis un commentaire mettant en doute les capacités sexuelles de l'occupant de l'élysée.
Autre exemple, on pourrait très bien (en capillotractant un peu) imaginer que l'association des utilisateurs de Wikipédia soit obligé de fermer parce qu'un quebecquois y aurait inséré les doutes de M. LePen sur l'importance de la Shoah...
Alors, bien ou pas bien ? Vit-on dans une dictature qui nous oprime ? Sommes-nous des moutons ? Les indiens devraient-ils venir prendre des cours en France ? L'inverse ? La morale ne serait-elle donc qu'une notion culturelle relative ? etc.
À mon humble avis, il est fort délicat de se poser en arbitre des définitions et des limites des libertés indivuelles.
[^] # Re: Belle initiative
Posté par nojhan (site web personnel, Mastodon) . En réponse à la dépêche Création de l'association culture-libre. Évalué à 5.
Dans les faits, il faut bien garder à l'esprit que demander à prévenir l'auteur, c'est empécher un très grand nombre de réutilisations. Dans les faits, les gens ne souhaitent pas le faire, ça perd du temps, c'est chiant, ça ne marche pas.
D'autre part, la peur que quelqu'un d'autre se fasse des sous sur notre dos est, dans les faits, infondée également. D'abord parce que très peu de gens le font, et ensuite parce qu'ils ne gagnent rien dessus.
Bref, ce sont pour beaucoup des peurs irrationnelles (j'ai eu les mêmes, c'est normal) :-)
[^] # Re: Ayons une pensée pour les utilisateurs
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal Mark Shuttleworth : il remet ça. Évalué à 2.
Le problème ici est qu'il y a un conflit d'intérêt entre les administrateurs systèmes, qui veulent une machine robuste à administrer, et les utilisateurs qui ont besoin de logiciels récents. Avoir les deux est impossible, et c'est bien pour ça que je dis qu'un discours simplistes sur ce que l'« on » souhaite en entreprise est à éviter.
# Ayons une pensée pour les utilisateurs
Posté par nojhan (site web personnel, Mastodon) . En réponse au journal Mark Shuttleworth : il remet ça. Évalué à 8.
Si je puis me permettre, « les entreprises », ça ne veut rien dire, pour la bonne et simple raison que, maintenant, l'informatique est utilisée partout. Et quand bien même tu aurais identifié un type d'entreprise, ça ne voudrait pas dire grand chose non plus, parce qu'au sein d'une boite, tu as des utilisations très différentes.
Par exemple, dans la grande entreprise de haute technologie où je travaille, les administrateurs systèmes nous imposent une RHEL 5, pour les raisons que tu cites. Et bien moi, j'y travaille dans cette boite, et je peux te dire que ça me casse les pieds.
La RedHat est certes bien pratique pour faire de l'administration système sur les PC bureautique des secrétaires, mais elle est grave à la ramasse pour faire de la recherche informatique, par exemple. Les logiciels sont trop anciens, les dépôts fournis trop restreints, les compatibilités trop chiantes, etc. Là où une Ubuntu est un vrai plaisir.
Bref, un peu de subtilité et de compassion pour les utilisateurs (par opposition aux administrateurs) ne ferait sans doute pas de mal à ton discours, pourtant certes intéressant sur l'improbable naiveté de Shuttleworth.