Et voila, ça a l'air d'être un bug "chaud" avec plusieurs duplicats: https://bugs.kde.org/show_bug.cgi?id=295212. Et, surprise, c'est un bug KDE. LibreOffice n'y est pour rien, apparemment. Mais en tout cas, il s'en est pris plein la tronche dans ce journal, le monde est injuste.
Je viens d'enregistrer et de rouvrir un fichier testœøÀΔ.odt avec LibreOffice 3.5.3 sur mon Ubuntu. Donc, la description du problème est fausse, et tu ne donnes pas d'exemple reproductible. Je suppute qu'il y a un gros bug dans l'interface chaise-clavier.
Dans tous les cas, ça me semble absurde de changer de logiciel parce qu'il ne sait pas ouvrir un fichier avec des caractères spéciaux. Il suffit de renommer le fichier, voire de faire un lien symbolique, ce qui permet de gérer le problème de manière totalement transparente. À mon avis, ce que tu fais s'apparente à envoyer ta voiture à la casse parce que tu as toi-même monté les essuie-glaces à l'envers.
Sur le fond, oui, je sais, les pauvres chinois, ils ont le droit de mettre des caractères cabalistiques dans leurs noms de fichier. Les chinois ils font ce qu'ils veulent, mais personnellement je ne mets jamais de caractères non-ASCII dans les noms de fichier : ça n'a aucun intérêt, il serait stupide d'avoir des noms de fichiers qui ne diffèrent que par un accent ou un espace insécable, etc. Donc, quelque part, même si c'est un bug, c'est un bug généré par une demande (à mon avis) non-pertinente de l'utilisateur. Après, si le système l'autorise, alors ça doit marcher, j'avoue.
Oui, j'ajouterai même que R est devenu un véritable langage de programmation; on peut carrément exécuter des scripts en #!/usr/bin/env Rscript , il y a un générateur de bytecode pour les fonctions les plus gourmandes à interpréter, et de quoi jouer avec la programmation parallèle. On peu ajouter la capacité native à générer des graphes de très haute qualité directement dans le format souhaité (bitmap ou pdf), et 4000 paquets contribués. R est devenu incontournable en biologie, et je pense que ce n'est pas près de retomber (en 2012, R se classe 28e dans le classement des langages populaires, devant COBOL, Eiffel, D et Erlang…).
En plus, le langage S est assez esthétique et élégant, en plus d'être très concis. Je pense que c'est un excellent outil pour l'apprentissage de la programmation.
"pas compatible avec OOo" est mentionne comme inconvenient d'Office et "compatible avec Office" est mentionne comme avantage d'OpenOffice, bref une contradiction totale
Je ne vois pas où est la contradiction. OOo sait lire et produire (pas parfaitement) les documents MS Office, alors que MSO ne sait lire et produire que ses propres documents, et pas ceux générés par OOo. Ça me semble être limpide, question logique…
Ton commentaire est tellement biaise (tiens, il n'y a pas les accents sous Windows?) et incomplete (tiens, encore?) que c'en est franchement risible. Ca (tiens, pas de Ç non plus) manque tres tres serieusement d'objectivite. (L'objectivite, c'est comme la conjonctivite?).
Dans le document, inconvénients de MS Office: prix des licences, format de fichier propriétaire avec les problèmes de compatibilité qui vont avec, problèmes de sécurité avec les macros, mises à jour peu fréquentes. Je ne vois pas où est le problème, ça me semble assez objectif (même si pour les mises à jour, le compromis entre la fréquence peut être discuté, c'est pratique de mettre à jour souvent sur un poste perso, moins en production.
Avantages OpenOffice: interface unifiée (OK, je suis d'accord, c'est moyen comme argument), Licence libre, format ouvert XML (en 2005 ça n'était pas le cas pour MS Office), export natif en PDF (à l'époque, c'était une fonctionnalité très originale), compatible avec MS Office (argument à double tranchant), moins sensible aux virus (c'est factuel, même si on peut toujours balancer l'argument de la fréquence d'utilisation, qui n'est pas démontrable tant que les PDM ne bougent pas plus), multiplateforme.
Bref, c'est une liste d'avantages/inconvénients destinés à un public d'utilisateurs qui, comme presque tout le monde, n'utilise qu'une partie négligeable des fonctionnalités d'une suite bureautique, mais je ne vois rien de particulièrement faux ou choquant.
"Ça manque d'objectivité" est l'argument parfait pour ceux qui ont de la merde dans les yeux : pas besoin d'argumenter, on sait mieux que tout le monde (argumentum ad potentiam). J'aimerais bien connaitre les arguments objectifs que MS utilise pour refourguer MS Office, histoire d'être impressionnés par l'"objectivite".
Certes, mais si c'était vaible, ça serait fait depuis longtemps. Tu vas à Carrefour et à Auchan, tu ne trouves que des machines assemblées sous Windows. Pourquoi des grands groupes comme ça n'ont pas les moyens de vendre des PC avec une distrib Linux maison, 100€ moins cher que les PC Windows? C'est quelque chose que je n'ai jamais compris, et j'imagine qu'il y a une raison, c'est juste qu'elle m'échappe. Une piste serait peut-être que les PC sont vendus à prix coûtant, et que les marges sont faites principalement sur la logithèque (10 ou 15€ pour des softs qui impriment des cartes de visite ou d'autres trucs aussi inutiles). Sous Linux, la plupart de ces trucs existent déja; et en tout cas, on n'en achèterait plus en magasin. Ça serait cynique, mais les grandes enseignes ne sont pas à ça près…
Bah, il me semble que le deal évident, c'est que si tu administres ta machine, tu assumes, et tu corriges les boulettes (et tu réinstalles ta distrib si tu as tout pété).
Le problème, c'est qu'en recherche, tu as tout le temps besoin de faire des trucs sales : récupérer un programme écrit par des chinois, le compiler, l'exécuter, le modifier, le coller sur un serveur de calcul, et tout faire péter avec une fuite mémoire, par exemple, et le tout dans une seule journée. C'est la procédure normale, et toute autre procédure va simplement arriver au même résultat, sauf que ça prendra plus longtemps.
Dans mon cas, le service info me laisse gérer mon serveur de calcul et ma machine perso, plus les machines des étudiants. Je n'ai donc qu'à administrer un seul serveur, et j'ai déja l'impression de passer pas mal de temps à installer des trucs : des libs, des python-machin, des perl-machin, le même python-machin mais pas la même version, et des milliers de paquets pour R… ça ne s'arrête jamais, et ça peut être bloquant si tu en as besoin le vendredi soir. Et encore, on a imposé que les programmes perso ou non-packagés soient exécutés dans le /home , quitte à les dupliquer entre utilisateurs, de manière à n'avoir que les paquets de la distrib en root, sans /opt ni /usr/local. Franchement, je ne vois pas comment on peut réussir à gérer un parc de plusieurs dizaines de machines en production si on ne délègue pas ce genre de trucs. La seule solution serait de dire aux utilisateurs d'arrêter de faire des trucs crades, mais dans un labo de recherche, faire des trucs crades est justement ce pour quoi les gens sont payés.
Après, ça dépend aussi de l'environnement. Autant je trouve normal dans un environnement de production de ne pas laisser les utilisateurs jouer avec les ordinateurs, autant c'est assez contraignant dans un centre de recherche. Il y a quelques années, un service informatique m'avait «menacé» de m'installer une RedHat entreprise sur mon poste, sans les droits root—politique de l'université, je ne sais pas quoi. Je leur avais répondu que je les tiendrai pour responsables de ma perte de productivité sur le temps perdu à rootkiter ma propre machine. Résultat, ils m'ont laissé installer mon Ubuntu perso (mais pas Debian, les voies du Seigneur sont toujours aussi impénétrables).
Il faut quand même apprécier l'ingéniosité des assembleurs et des producteurs de logiciels pour contourner à la fois la loi et les licences existantes afin de d'atteindre de manière la plus discrète possible la liberté de leurs propres clients. Pense à tous ces noyaux linux qui tournent sur une majorité de smartphones, de tablettes, de TruxBox, tous ces beaux logiciels libres dont tu peux tout à fait récupérer les sources, mais pour lesquels tu ne peux ni vérifier que tu exécutes bien les binaires compilés à partir de ces sources, ni modifier et redistribuer… Tout ça avec la bénédiction de la répression des fraudes, et sans soulever de vagues de protestation parmi les consommateurs. Ils sont très, très forts, et leur détermination (ainsi que leur force financière) fait que, sans base législative ultra-forte, la lutte promet d'être très difficile.
Au lieu de militer contre telle ou telle technologie, ce qui est perdu d'avance étant donné l'accumulation de nouveaux projets liberticides, il serait beaucoup plus sain d'interdire purement et simplement la vente d'équipements munis de dispositifs non-contournables visant à empêcher le consommateur d'utiliser le produit comme il le souhaite.
D'un autre côté, si le problème des jeux libres n'était que l'artwork, on ne serait pas si mal. Il y a une tripotée de jeux libres qui sont instables, pas finis, bourrés de bugs, pas multiplateforme, etc. J'imagine qu'on peut ajouter à la liste des problèmes le fait que l'équipe de développement est souvent composée de gens qui ne sont pas des programmeurs professionnels, qui font des mauvais choix techniques dès le début, et qui ont du mal à gérer un projet, avec des releases, des périodes où on ne fait que corriger les bugs sans ajouter de fonctionnalités, etc.
Le problème de l'artwork reste réel, cependant. Il y a relativement peu de gens compétents dans le domaine, et encore moins désirent passer du temps sur un projet libre. Maintenant, l'ambition dévorante des gens qui lancent des jeux, l'idée de produire un jeu complet à partir de rien, est probablement irréaliste et déraisonnable, et reste à l'origine de beaucoup d'échecs. Beaucoup de jeux ont par exemple des musiques dégueulasses, alors que la musique, si elle contribue à l'ambiance du jeu, n'est pas un élément bloquant. Pourquoi ne pas réutiliser les musiques libres existantes (jeux libres, enregistrements de musique classique libres)? Ça permettrait de se concentrer sur les aspects fondammentaux, et ça serait tellement plus agréable pour les joueurs! En plus, ça permettrait de se culturer en musique classique, plutôt que de se pourrir les oreilles avec de la bouillasse.
C'est un peu facile de balancer des critiques quand on ne fait rien, mais je trouve que le paysage des jeux libres est un petit peu déprimant. À part BFW, qui est un modèle du genre, j'ai un peu l'impression que les jeux libres sont soit des mini-projets bien finis (type frozen bubble), soit des trucs ambitieux jamais fignolés. Des trucs somme "sable" par exemple sentent bon les années 1990, le jeu n'a plus de page officielle, il est mort. Des projets très intéressants, comme OpenTTD, Freeciv, Freecol, Lincity, se trainent un peu comme des limaces et ne sont soutenus que par des équipes très réduites, dont la plupart aimeraient certainement passer le flambeau et se consacrer à autre chose. Même des jeux super innovants comme globutaion semblent à l'arrêt. Est-ce que ça veut dire qu'on a atteint la limite de la "niche écologique" des jeux libres? Étant donné le nombre de joueurs dans le monde, c'est fou qu'aucun projet d'envergure avec un budget conséquent n'apparaisse.
Une preuve statistique est considérée comme suffisante par les scientifiques qui ont eu la chance ou l'intuition de quitter les cours de maths le plus tôt possible.
Oui, rien à voir, mais n'empêche, blanc c'est bien, et noir c'est mal. Pareil pour la magie blanche, pareil pour une explication claire ou obscure. Aux échecs, les blancs jouent en premier et ont plus de chances de gagner. À force, j'imagine qu'on peut mal le prendre si on est noir ET parano (ou qu'on broie du noir :-S).
Après, on doit pouvoir trouver quelques exemples contraires. Les mariages blancs? Mais on ne parle pas de mariages noirs. Mine de rien, les termes de "blanc" et "noir" sont connotés. J'ai souvenir de cette expérience terrible menée auprès de gamins de 5-6 ans, auxquels on donnait une série de visages qui ne différaient que par la couleur, et on leur demandait "lequel a des bonnes notes à l'école", "lequel veut devenir médecin", et les réponses étaient incroyablement racistes. On n'y peut pas grand chose, mais c'est comme ça.
L'avantage de passer par une lib telle que la STL, c'est de pouvoir utiliser tout ces algos "de base" avec des opérateurs personnalisés, ce qui est bien pratique quand on veut trier des choux-fleurs.
C'est sûr, mais (i) est-ce que ça arrive si souvent que ça de vouloir trier ou additionner des choux-fleurs, par rapport à trier ou additionner des nombres ou des chaines de caractères, et (ii) techniquement, je ne vois que peu d'exemples où on veut réellement trier des choux-fleurs selon leur chou-fleuritude : on veut les trier selon leur taille, selon leur couleur, selon tout un tas de trucs qui s'expriment par leur valeur numérique.
Après, je ne critique pas l'existence d'une STL, qui reste un outil utile dans des cas assez spécifiques. Ce que je critique, c'est le paradigme de programmation qui consiste à faire des appels non-standard à des fonctions triviales dont tout le monde a besoin, et qui elles font des appels à la bibliothèque standard.
Par exemple, M. Dupont va programmer une fonction somme(iterator, iterator) qui va appeler std::accumulate; alors que M. Smith va programmer une fonction sum(vector) qui va appeler std::accumulate. Bref, les deux ont les mêmes besoins, ils appellent les mêmes fonctions standard en arrière plan, mais leur interface n'est pas standard. Ça duplique les efforts, ça rend le code plus difficile à maintenir et à lire, les fonctions résultantes ont peut-être des bugs ou elles ne sont peut-être pas optimales. Je ne vois pas du tout l'intérêt d'intercaler les couches de trucs standard et de trucs non-standard.
Il est évident que si la bibliothèque standard possède des fonctions min() ou sum(), elles ne vont pas toujours se comporter comme le programmeur souhaiterait qu'elles se comportent. Dans ce cas, il faudra de toutes manières repasser par la STL ou équivalent, avec un commentaire du style // je veux le plus petit élément qui ne soit pas 0, alors que la fonction min() renvoie 0. Mais dans 95% des cas, ces fonctions se comporteront exactement comme il faut, et ça fera gagner un temps fou à tout le monde. Je trouve déraisonnable d'estimer qu'un programmeur sur un langage bas-niveau n'a que ça à faire que de chercher dans la littérature l'algorithme optimal pour réaliser telle ou telle tâche triviale.
C'est exactement le sens de ma remarque. D ne sera probablement jamais utilisé pour coder un système d'exploitation ou un pilote de périphérique. Si on regarde l'utilisation de C++, c'est principalement du logiciel utilisateur (bureautique, logiciels spécialisés, etc). Dans mon domaine, le C et le C++ sont utilisés principalement pour coder des modèles "maison" (simulations, etc) quand les langages haut niveau sont trop lents. Au passage, matlab est un peu déprécié en biologie, les gens préfèrent de plus en plus R.
Les langages C/C++/D ne sont pas faits pour manipuler des vecteurs (au sens mathématique)
Les vecteurs de caractères ou de chaines de caractères n'a aucun sens mathématique, et pourtant, ils sont manipulés par le langage.
Le problème, à mon avis, ne vient pas vraiment du "niveau" du langage, mais du présupposé sur l'utilisation qui en est faite. Un langage bien foutu devrait pouvoir être utilisé par tout type d'utilisateur, et ce n'est pas le cas, ni pour C, ni pour D. Quelqu'un qui veut faire des choses très simples ne devrait pas avoir à récupérer un char** en argument du main() (en gros, on devrait pouvoir utiliser le langage sans pointeurs), et la librairie standard devrait permettre tout un tas d'opérations de base sans avoir à les recoder soi-même : min(), max(), sum(), mean(), il me semble un peu ridicule de passer par une STL (ou équivalent) pour des opérations aussi triviales.
Je ne comprend pas vraiment où tu veux en venir. Le compilateur ne peut pas deviner que tu veux utiliser const, je ne vois donc pas de solution, à part ne pas l'utilisé, mais c'est aussi possible.
Tu dis que c'est difficile ou que c'est impossible? Il me semble que
double square(double x) {return x*x;}
peut être sagement tagguée "const" par le compilo, qui peut décider quels appels de fonction sont const et lesquels ne le sont pas. Après, j'ai l'impression que la philosophie de D est de mettre le curseur à peu près à mi-chemin entre le compilo et le programmeur, le compilo peut deviner quelques trucs, mais l'aide du programmeur est indispensable à l'optimisation poussée, en explicitant la structure du programme : telle partie ne change pas, cette fonction ne peut pas lancer d'exceptions, etc. Je ne vois pas dans quelle mesure c'est fondamentalement différent de ce qui se passe en C ou en C++, par exemple.
toto << "Bonjour " << name << ". Vous avez " << 3 << " nouveaux messages.";
Franchement, tu trouves la première plus lisible? Et de toutes manières, même à lisibilité égale, l'inférence de type est un avantage indéniable (recourir au programmeur pour une tâcha automatisable n'a aucun intérêt).
D'ailleurs, j'imagine que la deuxième instruction peut être algorithmiquement transformée vers la première par le compilo. C'est donc le langage qui impose une construction lourde.
Ah ouais, c'est limpide comme syntaxe. C'est exactement le même brainstorm que la STL C++ : un truc potentiellement puissant mais illisible.
Ma critique, c'était justement que le langage soit apporter un minimum de fonctions de base. Bien sûr qu'on peut recalculer une moyenne ou une variance à la main, on peut même créer des méthodes pour le faire, on peut même créer sa propre bibliothèque de gestion de vecteurs, avec des vector_int, vector_double, ce qui permettrait de faire des vec.sum() et des vec.mean(). Mais on s'en fout, ce qui est crucial, c'est que le langage vienne avec ça, parce que ça fait partie de ce qu'on fait tous les jours avec des vecteurs. Là, le langage vient tout nu, c'est un truc McGyver. À chaque début de projet, tu réinventes la roue, avec éventuellement des bugs ou des problèmes de performance. Ça me semble totalement inutile, et en plus c'est illisible.
C'est clair qu'à la place de supprimer la complexité, on peut simplement la cacher. Mais regarde le main() de D : on a déja un string[]. C'est mieux qu'un char** (!!!), mais on ne récupère pas non plus quelque chose de manipulable : par exemple, que donne un writeln(args)?
Ceci dit, c'est peut-être aussi que les exemples choisis sont étranges. Ces types size_t semblent très mystérieux, et le premier exemple propose déja des immutable et des pure nothow, alors que ces mots-clé ne sont peut-être pas indispensables ici?
# Bon, merci Google
Posté par arnaudus . En réponse au journal Je quitte LibreOffice et Icedove!. Évalué à 10.
Et voila, ça a l'air d'être un bug "chaud" avec plusieurs duplicats: https://bugs.kde.org/show_bug.cgi?id=295212. Et, surprise, c'est un bug KDE. LibreOffice n'y est pour rien, apparemment. Mais en tout cas, il s'en est pris plein la tronche dans ce journal, le monde est injuste.
# Mmmhhh bidon?
Posté par arnaudus . En réponse au journal Je quitte LibreOffice et Icedove!. Évalué à 8.
Je viens d'enregistrer et de rouvrir un fichier testœøÀΔ.odt avec LibreOffice 3.5.3 sur mon Ubuntu. Donc, la description du problème est fausse, et tu ne donnes pas d'exemple reproductible. Je suppute qu'il y a un gros bug dans l'interface chaise-clavier.
Dans tous les cas, ça me semble absurde de changer de logiciel parce qu'il ne sait pas ouvrir un fichier avec des caractères spéciaux. Il suffit de renommer le fichier, voire de faire un lien symbolique, ce qui permet de gérer le problème de manière totalement transparente. À mon avis, ce que tu fais s'apparente à envoyer ta voiture à la casse parce que tu as toi-même monté les essuie-glaces à l'envers.
Sur le fond, oui, je sais, les pauvres chinois, ils ont le droit de mettre des caractères cabalistiques dans leurs noms de fichier. Les chinois ils font ce qu'ils veulent, mais personnellement je ne mets jamais de caractères non-ASCII dans les noms de fichier : ça n'a aucun intérêt, il serait stupide d'avoir des noms de fichiers qui ne diffèrent que par un accent ou un espace insécable, etc. Donc, quelque part, même si c'est un bug, c'est un bug généré par une demande (à mon avis) non-pertinente de l'utilisateur. Après, si le système l'autorise, alors ça doit marcher, j'avoue.
[^] # Re: C'est amusant
Posté par arnaudus . En réponse au journal Étude migration vers OpenOffice de 2005. Évalué à 3.
Oui, j'ajouterai même que R est devenu un véritable langage de programmation; on peut carrément exécuter des scripts en #!/usr/bin/env Rscript , il y a un générateur de bytecode pour les fonctions les plus gourmandes à interpréter, et de quoi jouer avec la programmation parallèle. On peu ajouter la capacité native à générer des graphes de très haute qualité directement dans le format souhaité (bitmap ou pdf), et 4000 paquets contribués. R est devenu incontournable en biologie, et je pense que ce n'est pas près de retomber (en 2012, R se classe 28e dans le classement des langages populaires, devant COBOL, Eiffel, D et Erlang…).
En plus, le langage S est assez esthétique et élégant, en plus d'être très concis. Je pense que c'est un excellent outil pour l'apprentissage de la programmation.
[^] # Re: C'est amusant
Posté par arnaudus . En réponse au journal Étude migration vers OpenOffice de 2005. Évalué à 3.
R n'a rien à voir avec un tableur, je doute que la comparaison ait un sens.
[^] # Re: C'est amusant
Posté par arnaudus . En réponse au journal Étude migration vers OpenOffice de 2005. Évalué à 5.
Je ne vois pas où est la contradiction. OOo sait lire et produire (pas parfaitement) les documents MS Office, alors que MSO ne sait lire et produire que ses propres documents, et pas ceux générés par OOo. Ça me semble être limpide, question logique…
[^] # Re: C'est amusant
Posté par arnaudus . En réponse au journal Étude migration vers OpenOffice de 2005. Évalué à 10.
Ton commentaire est tellement biaise (tiens, il n'y a pas les accents sous Windows?) et incomplete (tiens, encore?) que c'en est franchement risible. Ca (tiens, pas de Ç non plus) manque tres tres serieusement d'objectivite. (L'objectivite, c'est comme la conjonctivite?).
Dans le document, inconvénients de MS Office: prix des licences, format de fichier propriétaire avec les problèmes de compatibilité qui vont avec, problèmes de sécurité avec les macros, mises à jour peu fréquentes. Je ne vois pas où est le problème, ça me semble assez objectif (même si pour les mises à jour, le compromis entre la fréquence peut être discuté, c'est pratique de mettre à jour souvent sur un poste perso, moins en production.
Avantages OpenOffice: interface unifiée (OK, je suis d'accord, c'est moyen comme argument), Licence libre, format ouvert XML (en 2005 ça n'était pas le cas pour MS Office), export natif en PDF (à l'époque, c'était une fonctionnalité très originale), compatible avec MS Office (argument à double tranchant), moins sensible aux virus (c'est factuel, même si on peut toujours balancer l'argument de la fréquence d'utilisation, qui n'est pas démontrable tant que les PDM ne bougent pas plus), multiplateforme.
Bref, c'est une liste d'avantages/inconvénients destinés à un public d'utilisateurs qui, comme presque tout le monde, n'utilise qu'une partie négligeable des fonctionnalités d'une suite bureautique, mais je ne vois rien de particulièrement faux ou choquant.
"Ça manque d'objectivité" est l'argument parfait pour ceux qui ont de la merde dans les yeux : pas besoin d'argumenter, on sait mieux que tout le monde (argumentum ad potentiam). J'aimerais bien connaitre les arguments objectifs que MS utilise pour refourguer MS Office, histoire d'être impressionnés par l'"objectivite".
[^] # Re: C'est moi, ou... ?
Posté par arnaudus . En réponse au journal Playnewton: la console vraiment libre. Évalué à 10.
Je crois que c'est toi.
[^] # Re: offre et demande
Posté par arnaudus . En réponse au journal La vente liée est autorisée en France. Évalué à 3.
Certes, mais si c'était vaible, ça serait fait depuis longtemps. Tu vas à Carrefour et à Auchan, tu ne trouves que des machines assemblées sous Windows. Pourquoi des grands groupes comme ça n'ont pas les moyens de vendre des PC avec une distrib Linux maison, 100€ moins cher que les PC Windows? C'est quelque chose que je n'ai jamais compris, et j'imagine qu'il y a une raison, c'est juste qu'elle m'échappe. Une piste serait peut-être que les PC sont vendus à prix coûtant, et que les marges sont faites principalement sur la logithèque (10 ou 15€ pour des softs qui impriment des cartes de visite ou d'autres trucs aussi inutiles). Sous Linux, la plupart de ces trucs existent déja; et en tout cas, on n'en achèterait plus en magasin. Ça serait cynique, mais les grandes enseignes ne sont pas à ça près…
[^] # Re: Premier boulot ?
Posté par arnaudus . En réponse au message Pratique professionnelle douteuse. Évalué à 6.
Bah, il me semble que le deal évident, c'est que si tu administres ta machine, tu assumes, et tu corriges les boulettes (et tu réinstalles ta distrib si tu as tout pété).
Le problème, c'est qu'en recherche, tu as tout le temps besoin de faire des trucs sales : récupérer un programme écrit par des chinois, le compiler, l'exécuter, le modifier, le coller sur un serveur de calcul, et tout faire péter avec une fuite mémoire, par exemple, et le tout dans une seule journée. C'est la procédure normale, et toute autre procédure va simplement arriver au même résultat, sauf que ça prendra plus longtemps.
Dans mon cas, le service info me laisse gérer mon serveur de calcul et ma machine perso, plus les machines des étudiants. Je n'ai donc qu'à administrer un seul serveur, et j'ai déja l'impression de passer pas mal de temps à installer des trucs : des libs, des python-machin, des perl-machin, le même python-machin mais pas la même version, et des milliers de paquets pour R… ça ne s'arrête jamais, et ça peut être bloquant si tu en as besoin le vendredi soir. Et encore, on a imposé que les programmes perso ou non-packagés soient exécutés dans le /home , quitte à les dupliquer entre utilisateurs, de manière à n'avoir que les paquets de la distrib en root, sans /opt ni /usr/local. Franchement, je ne vois pas comment on peut réussir à gérer un parc de plusieurs dizaines de machines en production si on ne délègue pas ce genre de trucs. La seule solution serait de dire aux utilisateurs d'arrêter de faire des trucs crades, mais dans un labo de recherche, faire des trucs crades est justement ce pour quoi les gens sont payés.
[^] # Re: Premier boulot ?
Posté par arnaudus . En réponse au message Pratique professionnelle douteuse. Évalué à 2.
Après, ça dépend aussi de l'environnement. Autant je trouve normal dans un environnement de production de ne pas laisser les utilisateurs jouer avec les ordinateurs, autant c'est assez contraignant dans un centre de recherche. Il y a quelques années, un service informatique m'avait «menacé» de m'installer une RedHat entreprise sur mon poste, sans les droits root—politique de l'université, je ne sais pas quoi. Je leur avais répondu que je les tiendrai pour responsables de ma perte de productivité sur le temps perdu à rootkiter ma propre machine. Résultat, ils m'ont laissé installer mon Ubuntu perso (mais pas Debian, les voies du Seigneur sont toujours aussi impénétrables).
[^] # Re: faut pas pousser non plus
Posté par arnaudus . En réponse au message Pratique professionnelle douteuse. Évalué à 9.
Bah, ça s'apparente à de la mauvaise gestion. Si c'était du harcèlement que de ne pas donner les droits root à tout le monde, ça se saurait :-)
[^] # Re: Ce qu'il faut faire
Posté par arnaudus . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 3.
Il faut quand même apprécier l'ingéniosité des assembleurs et des producteurs de logiciels pour contourner à la fois la loi et les licences existantes afin de d'atteindre de manière la plus discrète possible la liberté de leurs propres clients. Pense à tous ces noyaux linux qui tournent sur une majorité de smartphones, de tablettes, de TruxBox, tous ces beaux logiciels libres dont tu peux tout à fait récupérer les sources, mais pour lesquels tu ne peux ni vérifier que tu exécutes bien les binaires compilés à partir de ces sources, ni modifier et redistribuer… Tout ça avec la bénédiction de la répression des fraudes, et sans soulever de vagues de protestation parmi les consommateurs. Ils sont très, très forts, et leur détermination (ainsi que leur force financière) fait que, sans base législative ultra-forte, la lutte promet d'être très difficile.
Au lieu de militer contre telle ou telle technologie, ce qui est perdu d'avance étant donné l'accumulation de nouveaux projets liberticides, il serait beaucoup plus sain d'interdire purement et simplement la vente d'équipements munis de dispositifs non-contournables visant à empêcher le consommateur d'utiliser le produit comme il le souhaite.
[^] # Re: Jeux libres
Posté par arnaudus . En réponse à la dépêche Jouez en toute liberté avec la GameKey 700 série 1. Évalué à 2.
D'un autre côté, si le problème des jeux libres n'était que l'artwork, on ne serait pas si mal. Il y a une tripotée de jeux libres qui sont instables, pas finis, bourrés de bugs, pas multiplateforme, etc. J'imagine qu'on peut ajouter à la liste des problèmes le fait que l'équipe de développement est souvent composée de gens qui ne sont pas des programmeurs professionnels, qui font des mauvais choix techniques dès le début, et qui ont du mal à gérer un projet, avec des releases, des périodes où on ne fait que corriger les bugs sans ajouter de fonctionnalités, etc.
Le problème de l'artwork reste réel, cependant. Il y a relativement peu de gens compétents dans le domaine, et encore moins désirent passer du temps sur un projet libre. Maintenant, l'ambition dévorante des gens qui lancent des jeux, l'idée de produire un jeu complet à partir de rien, est probablement irréaliste et déraisonnable, et reste à l'origine de beaucoup d'échecs. Beaucoup de jeux ont par exemple des musiques dégueulasses, alors que la musique, si elle contribue à l'ambiance du jeu, n'est pas un élément bloquant. Pourquoi ne pas réutiliser les musiques libres existantes (jeux libres, enregistrements de musique classique libres)? Ça permettrait de se concentrer sur les aspects fondammentaux, et ça serait tellement plus agréable pour les joueurs! En plus, ça permettrait de se culturer en musique classique, plutôt que de se pourrir les oreilles avec de la bouillasse.
[^] # Re: Jeux libres
Posté par arnaudus . En réponse à la dépêche Jouez en toute liberté avec la GameKey 700 série 1. Évalué à 2.
Ah oui, B FW = Battle for Wesnoth :-)
# Jeux libres
Posté par arnaudus . En réponse à la dépêche Jouez en toute liberté avec la GameKey 700 série 1. Évalué à 4.
C'est un peu facile de balancer des critiques quand on ne fait rien, mais je trouve que le paysage des jeux libres est un petit peu déprimant. À part BFW, qui est un modèle du genre, j'ai un peu l'impression que les jeux libres sont soit des mini-projets bien finis (type frozen bubble), soit des trucs ambitieux jamais fignolés. Des trucs somme "sable" par exemple sentent bon les années 1990, le jeu n'a plus de page officielle, il est mort. Des projets très intéressants, comme OpenTTD, Freeciv, Freecol, Lincity, se trainent un peu comme des limaces et ne sont soutenus que par des équipes très réduites, dont la plupart aimeraient certainement passer le flambeau et se consacrer à autre chose. Même des jeux super innovants comme globutaion semblent à l'arrêt. Est-ce que ça veut dire qu'on a atteint la limite de la "niche écologique" des jeux libres? Étant donné le nombre de joueurs dans le monde, c'est fou qu'aucun projet d'envergure avec un budget conséquent n'apparaisse.
[^] # Re: Écrire bourré c'est mal m'voyez
Posté par arnaudus . En réponse au journal White List & Black List. Évalué à 2.
Une preuve statistique est considérée comme suffisante par les scientifiques qui ont eu la chance ou l'intuition de quitter les cours de maths le plus tôt possible.
[^] # Re: Écrire bourré c'est mal m'voyez
Posté par arnaudus . En réponse au journal White List & Black List. Évalué à 3.
Oui, rien à voir, mais n'empêche, blanc c'est bien, et noir c'est mal. Pareil pour la magie blanche, pareil pour une explication claire ou obscure. Aux échecs, les blancs jouent en premier et ont plus de chances de gagner. À force, j'imagine qu'on peut mal le prendre si on est noir ET parano (ou qu'on broie du noir :-S).
Après, on doit pouvoir trouver quelques exemples contraires. Les mariages blancs? Mais on ne parle pas de mariages noirs. Mine de rien, les termes de "blanc" et "noir" sont connotés. J'ai souvenir de cette expérience terrible menée auprès de gamins de 5-6 ans, auxquels on donnait une série de visages qui ne différaient que par la couleur, et on leur demandait "lequel a des bonnes notes à l'école", "lequel veut devenir médecin", et les réponses étaient incroyablement racistes. On n'y peut pas grand chose, mais c'est comme ça.
[^] # Re: Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par arnaudus . En réponse à la dépêche Le langage D. Évalué à 2.
C'est sûr, mais (i) est-ce que ça arrive si souvent que ça de vouloir trier ou additionner des choux-fleurs, par rapport à trier ou additionner des nombres ou des chaines de caractères, et (ii) techniquement, je ne vois que peu d'exemples où on veut réellement trier des choux-fleurs selon leur chou-fleuritude : on veut les trier selon leur taille, selon leur couleur, selon tout un tas de trucs qui s'expriment par leur valeur numérique.
Après, je ne critique pas l'existence d'une STL, qui reste un outil utile dans des cas assez spécifiques. Ce que je critique, c'est le paradigme de programmation qui consiste à faire des appels non-standard à des fonctions triviales dont tout le monde a besoin, et qui elles font des appels à la bibliothèque standard.
Par exemple, M. Dupont va programmer une fonction somme(iterator, iterator) qui va appeler std::accumulate; alors que M. Smith va programmer une fonction sum(vector) qui va appeler std::accumulate. Bref, les deux ont les mêmes besoins, ils appellent les mêmes fonctions standard en arrière plan, mais leur interface n'est pas standard. Ça duplique les efforts, ça rend le code plus difficile à maintenir et à lire, les fonctions résultantes ont peut-être des bugs ou elles ne sont peut-être pas optimales. Je ne vois pas du tout l'intérêt d'intercaler les couches de trucs standard et de trucs non-standard.
Il est évident que si la bibliothèque standard possède des fonctions min() ou sum(), elles ne vont pas toujours se comporter comme le programmeur souhaiterait qu'elles se comportent. Dans ce cas, il faudra de toutes manières repasser par la STL ou équivalent, avec un commentaire du style // je veux le plus petit élément qui ne soit pas 0, alors que la fonction min() renvoie 0. Mais dans 95% des cas, ces fonctions se comporteront exactement comme il faut, et ça fera gagner un temps fou à tout le monde. Je trouve déraisonnable d'estimer qu'un programmeur sur un langage bas-niveau n'a que ça à faire que de chercher dans la littérature l'algorithme optimal pour réaliser telle ou telle tâche triviale.
[^] # Re: Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par arnaudus . En réponse à la dépêche Le langage D. Évalué à 2.
C'est exactement le sens de ma remarque. D ne sera probablement jamais utilisé pour coder un système d'exploitation ou un pilote de périphérique. Si on regarde l'utilisation de C++, c'est principalement du logiciel utilisateur (bureautique, logiciels spécialisés, etc). Dans mon domaine, le C et le C++ sont utilisés principalement pour coder des modèles "maison" (simulations, etc) quand les langages haut niveau sont trop lents. Au passage, matlab est un peu déprécié en biologie, les gens préfèrent de plus en plus R.
Les vecteurs de caractères ou de chaines de caractères n'a aucun sens mathématique, et pourtant, ils sont manipulés par le langage.
Le problème, à mon avis, ne vient pas vraiment du "niveau" du langage, mais du présupposé sur l'utilisation qui en est faite. Un langage bien foutu devrait pouvoir être utilisé par tout type d'utilisateur, et ce n'est pas le cas, ni pour C, ni pour D. Quelqu'un qui veut faire des choses très simples ne devrait pas avoir à récupérer un char** en argument du main() (en gros, on devrait pouvoir utiliser le langage sans pointeurs), et la librairie standard devrait permettre tout un tas d'opérations de base sans avoir à les recoder soi-même : min(), max(), sum(), mean(), il me semble un peu ridicule de passer par une STL (ou équivalent) pour des opérations aussi triviales.
[^] # Re: Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par arnaudus . En réponse à la dépêche Le langage D. Évalué à 1.
Tu dis que c'est difficile ou que c'est impossible? Il me semble que
double square(double x) {return x*x;}
peut être sagement tagguée "const" par le compilo, qui peut décider quels appels de fonction sont const et lesquels ne le sont pas. Après, j'ai l'impression que la philosophie de D est de mettre le curseur à peu près à mi-chemin entre le compilo et le programmeur, le compilo peut deviner quelques trucs, mais l'aide du programmeur est indispensable à l'optimisation poussée, en explicitant la structure du programme : telle partie ne change pas, cette fonction ne peut pas lancer d'exceptions, etc. Je ne vois pas dans quelle mesure c'est fondamentalement différent de ce qui se passe en C ou en C++, par exemple.
[^] # Re: void et les templates?
Posté par arnaudus . En réponse à la dépêche Le langage D. Évalué à 2.
Mmmh, c'est pour bricoler des trucs avec des templates? Parce que je ne vois pas trop ce que tu peux faire du x, la variable n'a aucun sens, si?
[^] # Re: Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par arnaudus . En réponse à la dépêche Le langage D. Évalué à 1.
Franchement, tu trouves la première plus lisible? Et de toutes manières, même à lisibilité égale, l'inférence de type est un avantage indéniable (recourir au programmeur pour une tâcha automatisable n'a aucun intérêt).
D'ailleurs, j'imagine que la deuxième instruction peut être algorithmiquement transformée vers la première par le compilo. C'est donc le langage qui impose une construction lourde.
[^] # Re: Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par arnaudus . En réponse à la dépêche Le langage D. Évalué à 3.
C'est dommage que les gens en aient besoin, hein.
[^] # Re: Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par arnaudus . En réponse à la dépêche Le langage D. Évalué à 2.
Ah ouais, c'est limpide comme syntaxe. C'est exactement le même brainstorm que la STL C++ : un truc potentiellement puissant mais illisible.
Ma critique, c'était justement que le langage soit apporter un minimum de fonctions de base. Bien sûr qu'on peut recalculer une moyenne ou une variance à la main, on peut même créer des méthodes pour le faire, on peut même créer sa propre bibliothèque de gestion de vecteurs, avec des vector_int, vector_double, ce qui permettrait de faire des vec.sum() et des vec.mean(). Mais on s'en fout, ce qui est crucial, c'est que le langage vienne avec ça, parce que ça fait partie de ce qu'on fait tous les jours avec des vecteurs. Là, le langage vient tout nu, c'est un truc McGyver. À chaque début de projet, tu réinventes la roue, avec éventuellement des bugs ou des problèmes de performance. Ça me semble totalement inutile, et en plus c'est illisible.
[^] # Re: Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par arnaudus . En réponse à la dépêche Le langage D. Évalué à 3.
C'est clair qu'à la place de supprimer la complexité, on peut simplement la cacher. Mais regarde le main() de D : on a déja un string[]. C'est mieux qu'un char** (!!!), mais on ne récupère pas non plus quelque chose de manipulable : par exemple, que donne un writeln(args)?
Ceci dit, c'est peut-être aussi que les exemples choisis sont étranges. Ces types size_t semblent très mystérieux, et le premier exemple propose déja des immutable et des pure nothow, alors que ces mots-clé ne sont peut-être pas indispensables ici?