Dans la communauté scientifique, l'anglais s'impose de manière assez logique.
Les pays anglophones (notamment les USA), sont productifs en articles scientifiques et financent bon nombre de conférences. Beaucoup des revues les plus réputées sont anglo-saxonnes. Les chercheurs apprennent naturellement l'anglais, d'abord pour lire les articles de leur domaine, puis pour obtenir un maximum de visibilité, finissent par publier en anglais.
De plus, l'anglais est une langue germano-latine, donc plus facile à apprendre que la mandarin pour les européens et américains, et a une grammaire bien plus simple que le français, la rendant très accessible à une grande partie de la communauté scientifique.
Au final, le français et l'anglais sont les deux langues les plus logiquement adaptées aux publications internationales. L'anglais a gagné, peut-être parce que les américains savent mieux vendre leurs publications scientifiques, c'est tout.
Non, je n'ai jamais ça. Par défaut xargs découpe automatiquement la ligne en plusieurs si elle est trop longue.
Par contre, ça peut avoir une importance pour les commandes qui ne traitent pas tous leur paramètres de la même manière.
$ find /dir -exec commande {} \;
En effet, ça marche très bien.
L'objectif de mon commentaire était juste de montrer que les guillemets ne résolvent pas les problèmes d'espace, rien de plus.
$ commande $(find /dir)
-> Problème avec les espaces
$ commande "$(find /dir)"
-> Encore pire, concatène tous les noms de fichiers en un seul
$ find /dir|xargs commande
-> Problème avec les retours charriot dans les noms de fichiers. Il faut être fou pour en mettre, mais un BON outil doit gérer.
$ find /dir -print0|xargs -0 commande
-> Gère correctement tous les noms de fichiers.
L'informatique est un outil, pas une fin en soit, que ce soit libre ou ferme ne change strictement rien a ce qu'on y enseigne pour la bonne raison que ce qu'on l'on y enseigne c'est essentiellement de la theorie.
Tu peux par exemple compiler du C sous windows ou linux un unix ferme, tu peux faire du web sur toute les plateformes, etc.
Justement, c'est possible parce que C et le Web sont basés sur des standards ouverts.
Les pauvres gars aux quels on a appris à développer en Visual Basic 4.0 à l'époque où ça existait encore, se sont bien fait avoir. La connaissance pratique de la grammaire et du modèle objet du langage sont bons à jeter à la poubelle.
Le C, quand à lui, tient toujours debout, après environ 40 ans d'histoire.
sanctionner les dépôts de brevets invalides (« déposer un brevet merdique, c'est mal »).
Il faudrait avoir des critères définissant les brevets invalides.
De mon point de vue, tous les brevets logiciels que j'ai lus sont des idées triviales, avec souvent du prior art.
Et pourtant ces brevets tiennent assez solidement devant des cours.
Exemple: Brevets de Microsoft sur Android:
US patent #5889522: Brevet sur les bibliothèques de Widgets:
Ne s'applique pas à Android, ou alors, prior art évident avec Motif/libXt.
US patent #5778372: Rendu progressif des pages Web pour les images de fond. Prior art évident avec d'autres navigateurs pour les images qui ne sont pas des images de fond.
US patent #6339780: Affichage d'une icône indiquant le chargement au dessus du contenu en chargement. Prior art évident avec les curseurs de souris d'attente animées sur Mac.
US patent #6891551: Redimensionnement d'une sélection de texte. Trivial. Je ne sais pas s'il y a du prior art, par contre.
US patent #6957233: Annotations dans les documents balisés. Trivial. Prior art avec des documents annotés, pas forcément pour des langages balisés.
Les brevets sont toujours suffisamment précis pour que l'on puisse faire croire au juge qu'il n'y a pas de prior art, alors que ça se résume toujours à rajouter des adjectifs. Par exemple, alors que le rendu progressif de documents existe déjà, on a qu'à l'appliquer aux images de fond des navigateurs Web, et, tout d'un coup, on fait croire au juge que c'est une idée super-innovante.
Même si le sel protège contre les tables arc-en-ciel, ça ne protège pas contre la force brute.
Un mot de passe parmi les 100 000 combinaisons les plus fréquentes se casse toujours en une seconde si on a le haché salé.
Même aux mises à jour mineures ? Tu as un exemple ?
À toutes les versions, il y a un changelog très bien fait.
Même immédiatement après une mise à jour majeure, des changements rétro-incompatibles sont faits:
Par exemple, le changement des règles de visibilité des variables dans python 2.1: http://docs.python.org/whatsnew/2.1.html#pep-227-nested-scop(...)
Les autres versions aussi ont fait des changements incompatibles.
2.6 a supprimé les exceptions chaîne de caractères.
2.5 à supprimé la possibilité de renvoyer None dans __reduce__ (module pickle).
2.4 a changé le module email de telle sorte qu'aucune exception n'est lancée en cas de message mal formé parce qu'il ne décode pas tout d'un coup, mais utilise maintenant l'attribut defect pour signaler les erreurs au moment où il les rencontrent...
2.2 a changé la règle de recherche des méthodes en cas d'héritage multiple avec problème du diamant.
Ces incompatibilités touchent habituellement très peu de code, mais, à cause de la nature dynamique du langage, et de la subtilité des modifications, elles peuvent être silencieuses. Par exemple, un filtre de mailing list chargé de vérifier la validité des messages va silencieusement ignorer les erreurs à la 2.4.
Ce n'est pas une aberration. Quand il y a des choses à corriger ou améliorer et que cela nécessite de casser la compatibilité, il faut bien s'y résoudre un jour.
C'est une idée séduisante sur le plan théorique, mais, en pratique, ça divise la communauté en deux clans incompatibles. C'est pire que la division perl/ruby/python parce que ces langages étant clairement incompatibles, les communautés sont mieux séparées et on ne risque pas de mélanger du code accidentellement, vu qu'ils ont un syntaxe très différente.
La migration au 3 ne fournissant aucun retour sur investissement, les entreprises ne la feront qu'à contrecoeur, et uniquement quand la nécessité sans fera sentir.
On pourrait espérer que python 3 a supprimé d'un seul coup tout ce qu'il y avait de "mauvais" dans python 2.x, mais pas tout à fait, puisque dès python 3.0 ils sont prêts à déprécier une fonctionnalité en vue de la supprimer à la 3.2: http://docs.python.org/dev/3.0/whatsnew/3.0.html#pep-3101-a-(...)
En fait, il semblerait qu'un bon rythme de dépréciation/suppression soit retenu pour python 3.x.
Je crois que les développeurs de python sous-estiment la taille de leur base d'utilisateurs et ne se rendent pas compte des conséquences socio-économiques du fork.
Sans compter le dilemme pour les nouveaux programmeurs: 2.x (plus large base installée, plus de librairies) ou 3.x (l'avenir, en théorie), mais on a pas toujours le choix (dépendance d'un librairie d'une tierce partie).
En effet, car il s'agit d'un changement sans conséquence de rétro-incompatibilité.
Par contre, les changements à la python sont beaucoup plus gênants, parce qu'ils changent la signification du code silencieusement (même aux mises à jour mineures), et que ça ne peut se révéler que dans des cas de code rarement exécuté, du coup, on risque de ne même pas voir de Warning durant les deux ans de transition.
Sans compter l'aberration d'avoir un langage qui forke de lui même (python 2.6 vs python 3). Dès que plusieurs projets ou librairies doivent interagir, c'est le cauchemar.
Pour la programmation système, je suis toujours fan du C90. Au moins, ça compile partout sans incompatibilité artificielle.
Un script cron lance getmail toutes les 10 minutes.
getmail télécharge tout dans un maildir.
courier-imap expose le dossier en local via IMAP.
claws-mail utilise ce dossier IMAP en appellant directement le programme de courier-imap via un tuyau UNIX (chouette fonctionnalité de claws-mail).
Grace à ça:
1) ça rame pas.
2) j'ai tout en local sur mon disque dur
3) Il m'est facile d'employer d'autres clients mail, sans avoir à faire des conversions entre les formats pourris comme mboxo et mboxcl.
> Dans le même genre, si je me contente d'écrire l'URL
> de la page web sans autant en faire un lien
> (c.a.d un <a href=...>), est-ce que ça constitue quand
> même un lien ?
Bien sûr. Un lien n'est qu'une référence, et toute référence est une forme de lien.
En fait, même donner le nom du site, s'il n'y a pas d'ambiguité, est interdit.
Il faut dire: "Le site dont on ne doit prononcer le nom".
>il n'y a aucune différence au niveau technique.
D'autant plus que dans du text/plain, certains navigateurs auto-détectent l'URL et permettent de "cliquer dessus".
Tiens, dans le même ordre d'idée, pourquoi est-ce que je ne pourrais pas interdire à qui que ce soit de prononcer mon nom?
Je deviendrais "celui dont on ne doit prononcer le nom"...
[^] # Re: La question du choix
Posté par NanoTech . En réponse à la dépêche Est‐il démocratique, adapté et rentable que l’anglais soit la langue internationale ?. Évalué à 0.
Dans la communauté scientifique, l'anglais s'impose de manière assez logique.
Les pays anglophones (notamment les USA), sont productifs en articles scientifiques et financent bon nombre de conférences. Beaucoup des revues les plus réputées sont anglo-saxonnes. Les chercheurs apprennent naturellement l'anglais, d'abord pour lire les articles de leur domaine, puis pour obtenir un maximum de visibilité, finissent par publier en anglais.
De plus, l'anglais est une langue germano-latine, donc plus facile à apprendre que la mandarin pour les européens et américains, et a une grammaire bien plus simple que le français, la rendant très accessible à une grande partie de la communauté scientifique.
Au final, le français et l'anglais sont les deux langues les plus logiquement adaptées aux publications internationales. L'anglais a gagné, peut-être parce que les américains savent mieux vendre leurs publications scientifiques, c'est tout.
[^] # Re: Il fallait y penser
Posté par NanoTech . En réponse à la dépêche ack 1.96 — mieux que grep. Évalué à 0.
Non, je n'ai jamais ça. Par défaut xargs découpe automatiquement la ligne en plusieurs si elle est trop longue.
Par contre, ça peut avoir une importance pour les commandes qui ne traitent pas tous leur paramètres de la même manière.
En effet, ça marche très bien.
L'objectif de mon commentaire était juste de montrer que les guillemets ne résolvent pas les problèmes d'espace, rien de plus.
[^] # Re: Il fallait y penser
Posté par NanoTech . En réponse à la dépêche ack 1.96 — mieux que grep. Évalué à 1.
Les guillemets n'avancent à rien
$ commande $(find /dir)
-> Problème avec les espaces
$ commande "$(find /dir)"
-> Encore pire, concatène tous les noms de fichiers en un seul
$ find /dir|xargs commande
-> Problème avec les retours charriot dans les noms de fichiers. Il faut être fou pour en mettre, mais un BON outil doit gérer.
$ find /dir -print0|xargs -0 commande
-> Gère correctement tous les noms de fichiers.
[^] # Re: Moral bas
Posté par NanoTech . En réponse à la dépêche Retour d’expérience d’utilisation de logiciels libres en école d’ingénieur. Évalué à 2.
Justement, c'est possible parce que C et le Web sont basés sur des standards ouverts.
Les pauvres gars aux quels on a appris à développer en Visual Basic 4.0 à l'époque où ça existait encore, se sont bien fait avoir. La connaissance pratique de la grammaire et du modèle objet du langage sont bons à jeter à la poubelle.
Le C, quand à lui, tient toujours debout, après environ 40 ans d'histoire.
[^] # Re: Brevets: proposition
Posté par NanoTech . En réponse à la dépêche Revue de presse de l'April pour la semaine 28 de l'année 2011. Évalué à 2.
Il faudrait avoir des critères définissant les brevets invalides.
De mon point de vue, tous les brevets logiciels que j'ai lus sont des idées triviales, avec souvent du prior art.
Et pourtant ces brevets tiennent assez solidement devant des cours.
Exemple: Brevets de Microsoft sur Android:
US patent #5889522: Brevet sur les bibliothèques de Widgets:
Ne s'applique pas à Android, ou alors, prior art évident avec Motif/libXt.
US patent #5778372: Rendu progressif des pages Web pour les images de fond. Prior art évident avec d'autres navigateurs pour les images qui ne sont pas des images de fond.
US patent #6339780: Affichage d'une icône indiquant le chargement au dessus du contenu en chargement. Prior art évident avec les curseurs de souris d'attente animées sur Mac.
US patent #6891551: Redimensionnement d'une sélection de texte. Trivial. Je ne sais pas s'il y a du prior art, par contre.
US patent #6957233: Annotations dans les documents balisés. Trivial. Prior art avec des documents annotés, pas forcément pour des langages balisés.
Les brevets sont toujours suffisamment précis pour que l'on puisse faire croire au juge qu'il n'y a pas de prior art, alors que ça se résume toujours à rajouter des adjectifs. Par exemple, alors que le rendu progressif de documents existe déjà, on a qu'à l'appliquer aux images de fond des navigateurs Web, et, tout d'un coup, on fait croire au juge que c'est une idée super-innovante.
[^] # Re: Réponse de masse
Posté par NanoTech . En réponse au journal La solidité des mots de passe. Évalué à 2.
Même si le sel protège contre les tables arc-en-ciel, ça ne protège pas contre la force brute.
Un mot de passe parmi les 100 000 combinaisons les plus fréquentes se casse toujours en une seconde si on a le haché salé.
[^] # Re: C++, un langage moderne ?
Posté par NanoTech . En réponse à la dépêche C++ 0xB enfin finalisé ?. Évalué à 2.
À toutes les versions, il y a un changelog très bien fait.
Même immédiatement après une mise à jour majeure, des changements rétro-incompatibles sont faits:
Par exemple, le changement des règles de visibilité des variables dans python 2.1:
http://docs.python.org/whatsnew/2.1.html#pep-227-nested-scop(...)
Les autres versions aussi ont fait des changements incompatibles.
2.6 a supprimé les exceptions chaîne de caractères.
2.5 à supprimé la possibilité de renvoyer None dans __reduce__ (module pickle).
2.4 a changé le module email de telle sorte qu'aucune exception n'est lancée en cas de message mal formé parce qu'il ne décode pas tout d'un coup, mais utilise maintenant l'attribut defect pour signaler les erreurs au moment où il les rencontrent...
2.2 a changé la règle de recherche des méthodes en cas d'héritage multiple avec problème du diamant.
Ces incompatibilités touchent habituellement très peu de code, mais, à cause de la nature dynamique du langage, et de la subtilité des modifications, elles peuvent être silencieuses. Par exemple, un filtre de mailing list chargé de vérifier la validité des messages va silencieusement ignorer les erreurs à la 2.4.
Ce n'est pas une aberration. Quand il y a des choses à corriger ou améliorer et que cela nécessite de casser la compatibilité, il faut bien s'y résoudre un jour.
C'est une idée séduisante sur le plan théorique, mais, en pratique, ça divise la communauté en deux clans incompatibles. C'est pire que la division perl/ruby/python parce que ces langages étant clairement incompatibles, les communautés sont mieux séparées et on ne risque pas de mélanger du code accidentellement, vu qu'ils ont un syntaxe très différente.
La migration au 3 ne fournissant aucun retour sur investissement, les entreprises ne la feront qu'à contrecoeur, et uniquement quand la nécessité sans fera sentir.
On pourrait espérer que python 3 a supprimé d'un seul coup tout ce qu'il y avait de "mauvais" dans python 2.x, mais pas tout à fait, puisque dès python 3.0 ils sont prêts à déprécier une fonctionnalité en vue de la supprimer à la 3.2:
http://docs.python.org/dev/3.0/whatsnew/3.0.html#pep-3101-a-(...)
En fait, il semblerait qu'un bon rythme de dépréciation/suppression soit retenu pour python 3.x.
Je crois que les développeurs de python sous-estiment la taille de leur base d'utilisateurs et ne se rendent pas compte des conséquences socio-économiques du fork.
Sans compter le dilemme pour les nouveaux programmeurs: 2.x (plus large base installée, plus de librairies) ou 3.x (l'avenir, en théorie), mais on a pas toujours le choix (dépendance d'un librairie d'une tierce partie).
[^] # Re: C++, un langage moderne ?
Posté par NanoTech . En réponse à la dépêche C++ 0xB enfin finalisé ?. Évalué à 5.
Par contre, les changements à la python sont beaucoup plus gênants, parce qu'ils changent la signification du code silencieusement (même aux mises à jour mineures), et que ça ne peut se révéler que dans des cas de code rarement exécuté, du coup, on risque de ne même pas voir de Warning durant les deux ans de transition.
Sans compter l'aberration d'avoir un langage qui forke de lui même (python 2.6 vs python 3). Dès que plusieurs projets ou librairies doivent interagir, c'est le cauchemar.
Pour la programmation système, je suis toujours fan du C90. Au moins, ça compile partout sans incompatibilité artificielle.
# getmail + IMAP sur localhost + claws-mail
Posté par NanoTech . En réponse au sondage Je lis mes mails avec. Évalué à 6.
getmail télécharge tout dans un maildir.
courier-imap expose le dossier en local via IMAP.
claws-mail utilise ce dossier IMAP en appellant directement le programme de courier-imap via un tuyau UNIX (chouette fonctionnalité de claws-mail).
Grace à ça:
1) ça rame pas.
2) j'ai tout en local sur mon disque dur
3) Il m'est facile d'employer d'autres clients mail, sans avoir à faire des conversions entre les formats pourris comme mboxo et mboxcl.
Enfin, exim pour envoyer les mail.
[^] # Re: mode neuneu
Posté par NanoTech . En réponse à la dépêche Cachez ce lien que je ne saurais voir (4 ans plus tard). Évalué à 1.
> de la page web sans autant en faire un lien
> (c.a.d un <a href=...>), est-ce que ça constitue quand
> même un lien ?
Bien sûr. Un lien n'est qu'une référence, et toute référence est une forme de lien.
En fait, même donner le nom du site, s'il n'y a pas d'ambiguité, est interdit.
Il faut dire: "Le site dont on ne doit prononcer le nom".
>il n'y a aucune différence au niveau technique.
D'autant plus que dans du text/plain, certains navigateurs auto-détectent l'URL et permettent de "cliquer dessus".
Tiens, dans le même ordre d'idée, pourquoi est-ce que je ne pourrais pas interdire à qui que ce soit de prononcer mon nom?
Je deviendrais "celui dont on ne doit prononcer le nom"...