Alors la mise en page:
- les cadres autours de chaque équation sont affreux et bouffent beaucoup de place inutile, - ces équations sont parfois difficielment lisibles, ou sur deux colonnes ce qui rend assez bizarre car elles ne concernent que la première colonne.
- les tableaux ont une espèce d'en-tête 'design' censé rappeller le haut de la page là encore assez bizarre,
- les figures sont un peu trop grandes par rapport à ce qu'elles apportent.
- deux colonnes par page auraient peut être été plus adapté pour avoir une mise en page plus claire pour les formules. Les explications mathématiques sont peu agréablent à suivre quand elles sont compactes.
Pour l'article, ça devient encore plus sujectif, mais je vais essayer d'être clair...
- L'intro, même si elle est bien faite, est un peu trop longue. Je suppose que la taille de l'article est limité, donc il vaut mieux utiliser la place pour les explications qui vont suivre...
- L'exemple de l'alarme : il y n'y a pas assez d'explications formelles sur les outils mahématiques utilisé, alors que celle sur l'exemple lui même (les voleurs et le camion) abondent. Peut être que beaucoup n'ont pas envie de se taper un cours de math, mais une semi-vulgarisation manque un peu d'intérêt : soit on explique les choses en détail pour pouvoir se passer d'autres doc, soit on en reste à un résumé rapide.
- On ne comprend pas d'où sortent les résultats des tableaux (0.98, 0.05, 0.96...) il aurait fallu être plus clair sur ce qui est choisi arbitrairement et ce qui est calculé.
- Les choix de ces valeurs vers la fin ne sont pas très bonnes pour l'exemple : on a pas besoin de faire de calcul pour savoir que l'alarme dans un coin avec peu de voleur et beaucoup de camion risque de faire plus de fausse alerte qu'un dans un coin avec beaucoup de voleur et peu de camion ; un exemple plus ambigu mettant en avant l'utilité d'un calcul quantitatif aurait été plus pertinant. Il aurait été plus clair d'indiquer clairement dès le début ce qu'on veux calculer et à partir de quoi on le fait, çad quelles sont les probabilités déjà connues ; c'est un peu troublant d'être dans le noir toute cette partie et de ne comprendre le sens général qu'à la fin.
- Le cas général, est très résumé et se contente de renvoyer au référence en fin d'article, alors qu'une implémentatin avec un algo et du code aurait été le bienvenu
- enfin, on reprend encore le cas du début en le complexifiant, ce qui aurait plus eu sa place à la suite de la première partie.
- Il est de plus assez embrouillant de vouloir sortir le nom de tous les algos et techniques en les résumant en une ligne.
Bon tout ça en fait, ça fait pas mal de critiques qui sont un peu confuses, et d'autres lecteurs pourraient en fait faire des critiques exactement inverses. Pour résumer je dirais que l'article est trop long pour une introduction, et sans véritable exemple (code, algo...) pour une implémentation, même simple. Il aurait fallu faire un choix clair et s'y tenir.
Voilà, je critique, mais j'espère avoir été constructif, et il y a un peu de mauvaise foi car j'ai quand même trouvé l'article intéressant! :-)
Le problème n'est pas là, il au niveau de la description de la manipulation comme étant du « piratage de boîte électronique » et d' « intrusion informatique ». Si j'envoyais un faux courrier en signant à la fin Paul Dupont, je trouverais un peu fort que l'on m'accuse d'avoir cambriolé la maison de Paul Dupont, car seuls ses stylos et ses feuilles vierges peuvent être utilisé pour écrire "Paul Dupont".
Et heureusement que l'usurpation d'identité, même illégale, n'est pas forcement « séverement punie » sinon il y aurait beaucoup moins de Pierre Tramo dans le coin :-)
L'usurpateur lui même de l'histoire n'a d'ailleurs pas été puni du tout!
IA : pas mal mais assez vite compliqué. J'ai tout de même apprécié l'article.
J'ai été interessé par le sujet mais plutôt deçu de l'article. La première partie de l'explication est assez confuse et on ne comprend pas trop où l'auteur veut en venir (il est vrai que le sujet n'est pas évident). La mise en page est de plus affreuse et rend l'article encore moins clair...
Dans le même genre, il y a les attributs a (mode append only) et i (non modifiable) sur les fichiers et répertoires (man chattr, que sous ext2/3 et xfs je crois), et les options RM_STAR_WAIT et RM_STAR_SILENT avec zsh qui demandent confirmation.
Il y a aussi l'attribut u qui serait utile mais qui n'a pas été implémenté.
Clause 9: La licence ne doit pas contaminer d'autres logiciels. [...]
... et non d'autres bibliothèques ou fichiers sources compilés/liés avec du code GPL. Et dans ce cas, la GPL _est_ « contaminante » (ou tout autre synonyme que tu trouveras moins péjoratif, apparement ça a beaucoup d'importance) car elle force tout cet autre code à être GPL.
Concernant les logiciels propriétaires, ils peuvent bien faire ce qu'ils veulent de leur vie, et tu peux aussi en penser tout le mal que tu veux (après tout, ils sont quand même responsbale de l'extinction des dinosaures), ça ne change rien à ce qu'est la GPL.
Bin oui le pauvre il est pas très fort en math donc il se serait un peu planté dans sa déclaration... et il n'avait sans doute pas assez d'argent pour se payer un conseiller... et comme un malheur n'arrive jamais seul, et bien il a cartonné sa voiture de sport (qui devait être saisie), ses potes lui ont bu tous ses grands crus (qui devaient être saisis) et ses motos (qui devaient être saisies), je ne sais plus trop ce qu'il en a fait, mais ça ne m'étonnerais pas qu'elles se soient faites voler par des extraterrestres... c'est triste de voir le fisc s'acharner sur des bienfaiteurs de l'humanité qui font de si belles chansons comme "savoir donner"... moi ça me révolte très fort...
Il ne faut pas oublier de compter les charges patronales dans les salaires... je n'ai pas les chiffres sous les yeux, mais mon petit doigt me dit qu'il y a une différence non négligeable...
En attendant tu peux toujours te défouler avec america's army ou la demo d'ut2004, tous les deux téléchargeables pour linux et de très bonnes factures...
Et si t'es prêt à payer, ut2004 est une vraie merveille qui combine les joies du fps à celle du simulateur de vol, de buggy, de char d'assault, de vaisseau spatial et j'en passe, le tout avec une fludité impressionnante (bon c'est juste un peu le bordel par moment)
Il y a juste une petite différence entre un fichier référencé dans une base de donnée, utilisé pour des traitements réguliers et quelques octets qui trainent quelque part sur un disque dur, accessibles uniquement en mode bloc, au beau milieu de milliards d'autres, voire encore les réminicenses électromagnétiques de ces octets après récriture (quitte à enculer des mouches autant le faire en profondeur)...
Peut être que tu ne vois pas cette différence, mais la loi la verra surement, et c'est pour cela qu'elle demande du temps et l'appréciation de beaucoup de parties différentes afin de faire preuve d'un peu plus de discernement qu'un péquin qui débarque et à qui il faut 2 secondes et demi pour décréter un oui/non.
C'est pour les transports que ça serait pratique : « La RATP est en grève, mais les personnes qui sont solidaires pourront cependant prendre le métro ou le RER sans gène particulière »... Á mon avis les grèves auraient bien plus de succès...
Et divers FUD sur le « caractère viral/contaminant » de la GPL
Euh... FUD, je ne suis pas sûr que ça soit le bon terme, la GPL présentant effectivement un « caractère viral/contaminant », ce qui en fait justement son intérêt (mais pas celui de Microsoft)
Je ne mets pas en cause la qualité de la STL, qui est incontestement très bonne, mais son accessibilité pour un codeur C qui veut se mettre au C++ (ce qui est le cas ici).
Quand je dis que c'est "un sacré bordel", j'entends par là le coté assez ésotérique de la documentation, et non une éventuelle incohérence. Par ex:
issu de la doc de la stdc++ gnu (peut être s'agirait-il de la standard library et non de la standard template library? encore une subtilité pas évidente...) est pour moi assez imbitable, en tout cas bien plus que ce qu'on peut trouver dans la bibliothèque C standard. Il n'y a pas de doute que cette dernière est assez limitée mais elle reste efficace dans pas mal de cas, et en lui ajoutant la glib, on peut faire beaucoup de chose plus rapidement qu'en C++ (en comptant le temps d'apprentissage des subtilités de ce langage).
Pour les références, le problème n'est pas le principe mais la façon dont c'est implémenté en C++. Quand tu programmes en java, tu n'as pas de pointeurs, donc tu utilises forcement des références et tu n'as d'ailleurs pas à t'en soucier vu que la mémoire est gérée par le système grâce au garbage collector. Quand tu es en C++, tu dois jongler avec les variables dans la pile et dans le tas, les pointeurs et les références (le '&' pour les références n'aurait pas pu être plus mal choisi, bonjour la confusion avec le '&' "adresse de" et les 'et' logique et binaire), avec les types simples et complexes (tu passes une classe en argument, mais va tu passer un pointeur ou un bloc de 512 octet? tu fais une copie, mais va tu avoir une copie 'shallow', 'deep' ou 'copy-on-write'?) et ça n'est pas intuitif pour un codeur C. La doc du c++ le dit clairement : un référence est implémenté par un pointeur, mais celà doit être caché au programmeur. Je n'aime pas vraiment qu'un langage me cache des choses même si c'est pour mon bien. À chaque fois que j'utilise une chaîne en C++, je ne peux m'empécher de penser : mais va-t-elle être bien désallouée? (mauvaise habitude du C? peut être mais c'est ainsi...)
Ce sont effectivement des choses que l'on peut apprendre et qui deviennent très efficaces une fois maîtrisées, mais ça n'est pas évident lorsque l'on vient du C et que l'on a l'habitude de manipuler des types clairs. Le problème est que Stroustrup a voulu gardé la compatibilité entre le C et le C++, c'est l'un de ses avantage car ça a facilité sa propagation, mais c'est aussi l'un de ses inconveniants, car c'est devenu un langage syntaxiquement crade.
Enfin pour l'aspect objet (je répond aussi au msg dessous), on peut faire de l'objet avec n'importe quel langage, même assembleur. On profitera moins de la syntaxe qui guidera une architecture objet et des vérifications faites par le compilateur, mais ça n'a rien de particulièrement difficile, n'importe quel fichier C++ peut par exemple être entièrement traduit en C.
Euh, je ne dirais pas que le C++ est plus facile que le C... c'est plus concis, sans aucun doute, et tu peux faire des choses bien plus puissantes, mais il suffit de jeter un oeil à la doc de la STL pour s'appercevoir que c'est un sacré bordel, et il n'est pas toujours évident de bien saisir les subtilités de ce langage si tu as fais beaucoup de C car la logique est un peu différente (par ex, l'utilsation intensive de références au lieu de pointeurs).
Je te conseille de rester au C. C'est un peu chiant parfois de se taper la réinvention de la roue à chaque fois avec ce langage, mais en utilisant la glib tu peux t'éviter pas mal d'effort, et rien ne t'empêche de faire de l'orienté objet en C... il faut juste un peu plus de rigueur dans l'architecture de ton programme...
# Re: Easter Egg de Microsoft Word
Posté par calandoa . En réponse au journal Easter Egg de Microsoft Word. Évalué à 1.
N'essaye surtout pas emacs ou tu risques de sombrer dans une paranoïa profondement incurable... :-)
[^] # Re: LinuxMag de ce mois ci : coup de gueule
Posté par calandoa . En réponse au journal LinuxMag de ce mois ci : coup de gueule. Évalué à 1.
- les cadres autours de chaque équation sont affreux et bouffent beaucoup de place inutile, - ces équations sont parfois difficielment lisibles, ou sur deux colonnes ce qui rend assez bizarre car elles ne concernent que la première colonne.
- les tableaux ont une espèce d'en-tête 'design' censé rappeller le haut de la page là encore assez bizarre,
- les figures sont un peu trop grandes par rapport à ce qu'elles apportent.
- deux colonnes par page auraient peut être été plus adapté pour avoir une mise en page plus claire pour les formules. Les explications mathématiques sont peu agréablent à suivre quand elles sont compactes.
Pour l'article, ça devient encore plus sujectif, mais je vais essayer d'être clair...
- L'intro, même si elle est bien faite, est un peu trop longue. Je suppose que la taille de l'article est limité, donc il vaut mieux utiliser la place pour les explications qui vont suivre...
- L'exemple de l'alarme : il y n'y a pas assez d'explications formelles sur les outils mahématiques utilisé, alors que celle sur l'exemple lui même (les voleurs et le camion) abondent. Peut être que beaucoup n'ont pas envie de se taper un cours de math, mais une semi-vulgarisation manque un peu d'intérêt : soit on explique les choses en détail pour pouvoir se passer d'autres doc, soit on en reste à un résumé rapide.
- On ne comprend pas d'où sortent les résultats des tableaux (0.98, 0.05, 0.96...) il aurait fallu être plus clair sur ce qui est choisi arbitrairement et ce qui est calculé.
- Les choix de ces valeurs vers la fin ne sont pas très bonnes pour l'exemple : on a pas besoin de faire de calcul pour savoir que l'alarme dans un coin avec peu de voleur et beaucoup de camion risque de faire plus de fausse alerte qu'un dans un coin avec beaucoup de voleur et peu de camion ; un exemple plus ambigu mettant en avant l'utilité d'un calcul quantitatif aurait été plus pertinant. Il aurait été plus clair d'indiquer clairement dès le début ce qu'on veux calculer et à partir de quoi on le fait, çad quelles sont les probabilités déjà connues ; c'est un peu troublant d'être dans le noir toute cette partie et de ne comprendre le sens général qu'à la fin.
- Le cas général, est très résumé et se contente de renvoyer au référence en fin d'article, alors qu'une implémentatin avec un algo et du code aurait été le bienvenu
- enfin, on reprend encore le cas du début en le complexifiant, ce qui aurait plus eu sa place à la suite de la première partie.
- Il est de plus assez embrouillant de vouloir sortir le nom de tous les algos et techniques en les résumant en une ligne.
Bon tout ça en fait, ça fait pas mal de critiques qui sont un peu confuses, et d'autres lecteurs pourraient en fait faire des critiques exactement inverses. Pour résumer je dirais que l'article est trop long pour une introduction, et sans véritable exemple (code, algo...) pour une implémentation, même simple. Il aurait fallu faire un choix clair et s'y tenir.
Voilà, je critique, mais j'espère avoir été constructif, et il y a un peu de mauvaise foi car j'ai quand même trouvé l'article intéressant! :-)
[^] # Re: Un poisson d'avril qui aurait pu coûter cher
Posté par calandoa . En réponse au journal Un poisson d'avril qui aurait pu coûter cher. Évalué à 1.
Et heureusement que l'usurpation d'identité, même illégale, n'est pas forcement « séverement punie » sinon il y aurait beaucoup moins de Pierre Tramo dans le coin :-)
L'usurpateur lui même de l'histoire n'a d'ailleurs pas été puni du tout!
[^] # Re: LinuxMag de ce mois ci : coup de gueule
Posté par calandoa . En réponse au journal LinuxMag de ce mois ci : coup de gueule. Évalué à 1.
J'ai été interessé par le sujet mais plutôt deçu de l'article. La première partie de l'explication est assez confuse et on ne comprend pas trop où l'auteur veut en venir (il est vrai que le sujet n'est pas évident). La mise en page est de plus affreuse et rend l'article encore moins clair...
[^] # Re: Sondage: votre plus grosse boulette sous root
Posté par calandoa . En réponse au journal Sondage: votre plus grosse boulette sous root. Évalué à 1.
Il y a aussi l'attribut u qui serait utile mais qui n'a pas été implémenté.
[^] # Re: Novell choisit Qt comme environnement de développement.
Posté par calandoa . En réponse à la dépêche Novell choisit Qt comme environnement de développement.. Évalué à 1.
[^] # Re: Petits rappels (chat échaudé craint l'eau froide)
Posté par calandoa . En réponse à la dépêche Microsoft se met à l'open-source. Évalué à 1.
... et non d'autres bibliothèques ou fichiers sources compilés/liés avec du code GPL. Et dans ce cas, la GPL _est_ « contaminante » (ou tout autre synonyme que tu trouveras moins péjoratif, apparement ça a beaucoup d'importance) car elle force tout cet autre code à être GPL.
Concernant les logiciels propriétaires, ils peuvent bien faire ce qu'ils veulent de leur vie, et tu peux aussi en penser tout le mal que tu veux (après tout, ils sont quand même responsbale de l'extinction des dinosaures), ça ne change rien à ce qu'est la GPL.
[^] # Re: GRRRRRRRR :Un gros coup de gueule contre les développeurs du site du concours du personnels techniques du CNRS
Posté par calandoa . En réponse au journal GRRRRRRRR :Un gros coup de gueule contre les développeurs du site du concours du personnels techniques du CNRS. Évalué à 1.
[^] # Re: L'? et ses petites contrariétés
Posté par calandoa . En réponse au journal L' et ses petites contrariétés. Évalué à 2.
[^] # Re: Libr'East of Paris : 3 jours de conférences autour du Logiciel Libre
Posté par calandoa . En réponse à la dépêche Libr'East of Paris : 3 jours de conférences autour du Logiciel Libre. Évalué à 0.
Et dire que certains critiquent les blagues d'informaticiens... ils ne connaissent pas celles d'architectes...
# Re: enemy territory, marche plus :(
Posté par calandoa . En réponse au journal enemy territory, marche plus :(. Évalué à 1.
Et si t'es prêt à payer, ut2004 est une vraie merveille qui combine les joies du fps à celle du simulateur de vol, de buggy, de char d'assault, de vaisseau spatial et j'en passe, le tout avec une fludité impressionnante (bon c'est juste un peu le bordel par moment)
[^] # Re: Nous sommes le 5 !
Posté par calandoa . En réponse au journal Nous sommes le 5 !. Évalué à 1.
Peut être que tu ne vois pas cette différence, mais la loi la verra surement, et c'est pour cela qu'elle demande du temps et l'appréciation de beaucoup de parties différentes afin de faire preuve d'un peu plus de discernement qu'un péquin qui débarque et à qui il faut 2 secondes et demi pour décréter un oui/non.
# Re: Ahhh, les grèves.
Posté par calandoa . En réponse au journal Ahhh, les grèves.. Évalué à 5.
# Re: Libr'East of Paris : 3 jours de conférences autour du Logiciel Libre
Posté par calandoa . En réponse à la dépêche Libr'East of Paris : 3 jours de conférences autour du Logiciel Libre. Évalué à 3.
http://www.ntu.edu.sg/mpe/academic/graduate/msc/MSc%28MEMS%29/esiee(...)
http://www.jaist.ac.jp/~kouhou/2002/200211/images/esiee-exterieur.j(...)
http://images.google.com/images?q=+site:www.chez.com+Marne+la+Vall%(...) (désolé le site est mort)
Comment ça n'a rien à voir? Si, car selon une certaine théorie, le batiment représenterait en fait en clavier d'ordinateur...
[^] # Re: Petits rappels (chat échaudé craint l'eau froide)
Posté par calandoa . En réponse à la dépêche Microsoft se met à l'open-source. Évalué à 0.
Euh... FUD, je ne suis pas sûr que ça soit le bon terme, la GPL présentant effectivement un « caractère viral/contaminant », ce qui en fait justement son intérêt (mais pas celui de Microsoft)
[^] # Re: Libr'East of Paris : 3 jours de conférences autour du Logiciel Libre
Posté par calandoa . En réponse à la dépêche Libr'East of Paris : 3 jours de conférences autour du Logiciel Libre. Évalué à -2.
[^] # Re: les variables d'environnement
Posté par calandoa . En réponse au message [Terminal] les variables d'environnement. Évalué à 1.
[^] # Re: Monde de merde ou petit récapitulatif pasillustré.
Posté par calandoa . En réponse au journal Monde de merde ou petit récapitulatif pasillustré.. Évalué à 0.
[^] # Re: Linux 2.6.5 est sorti
Posté par calandoa . En réponse à la dépêche Linux 2.6.5 est sorti. Évalué à 5.
# Re: Monde de merde ou petit récapitulatif pasillustré.
Posté par calandoa . En réponse au journal Monde de merde ou petit récapitulatif pasillustré.. Évalué à 2.
# Re: USA ( suite)
Posté par calandoa . En réponse au journal USA ( suite). Évalué à 2.
[^] # Re: Quel langage choisir ?
Posté par calandoa . En réponse au journal Quel langage choisir ?. Évalué à 1.
Quand je dis que c'est "un sacré bordel", j'entends par là le coté assez ésotérique de la documentation, et non une éventuelle incohérence. Par ex:
template<typename _CharT, typename _Traits>
basic_ostream< _CharT, _Traits > & std::basic_ostream< _CharT, _Traits >::operator<< ( __streambuf_type * __sb ) [inherited]
issu de la doc de la stdc++ gnu (peut être s'agirait-il de la standard library et non de la standard template library? encore une subtilité pas évidente...) est pour moi assez imbitable, en tout cas bien plus que ce qu'on peut trouver dans la bibliothèque C standard. Il n'y a pas de doute que cette dernière est assez limitée mais elle reste efficace dans pas mal de cas, et en lui ajoutant la glib, on peut faire beaucoup de chose plus rapidement qu'en C++ (en comptant le temps d'apprentissage des subtilités de ce langage).
Pour les références, le problème n'est pas le principe mais la façon dont c'est implémenté en C++. Quand tu programmes en java, tu n'as pas de pointeurs, donc tu utilises forcement des références et tu n'as d'ailleurs pas à t'en soucier vu que la mémoire est gérée par le système grâce au garbage collector. Quand tu es en C++, tu dois jongler avec les variables dans la pile et dans le tas, les pointeurs et les références (le '&' pour les références n'aurait pas pu être plus mal choisi, bonjour la confusion avec le '&' "adresse de" et les 'et' logique et binaire), avec les types simples et complexes (tu passes une classe en argument, mais va tu passer un pointeur ou un bloc de 512 octet? tu fais une copie, mais va tu avoir une copie 'shallow', 'deep' ou 'copy-on-write'?) et ça n'est pas intuitif pour un codeur C. La doc du c++ le dit clairement : un référence est implémenté par un pointeur, mais celà doit être caché au programmeur. Je n'aime pas vraiment qu'un langage me cache des choses même si c'est pour mon bien. À chaque fois que j'utilise une chaîne en C++, je ne peux m'empécher de penser : mais va-t-elle être bien désallouée? (mauvaise habitude du C? peut être mais c'est ainsi...)
Ce sont effectivement des choses que l'on peut apprendre et qui deviennent très efficaces une fois maîtrisées, mais ça n'est pas évident lorsque l'on vient du C et que l'on a l'habitude de manipuler des types clairs. Le problème est que Stroustrup a voulu gardé la compatibilité entre le C et le C++, c'est l'un de ses avantage car ça a facilité sa propagation, mais c'est aussi l'un de ses inconveniants, car c'est devenu un langage syntaxiquement crade.
Enfin pour l'aspect objet (je répond aussi au msg dessous), on peut faire de l'objet avec n'importe quel langage, même assembleur. On profitera moins de la syntaxe qui guidera une architecture objet et des vérifications faites par le compilateur, mais ça n'a rien de particulièrement difficile, n'importe quel fichier C++ peut par exemple être entièrement traduit en C.
[^] # Re: incroyable
Posté par calandoa . En réponse au journal incroyable. Évalué à 2.
[^] # Re: Eloise Cerrennentaut refuse.
Posté par calandoa . En réponse au journal Eloise Cerrennentaut refuse.. Évalué à 3.
# Re: Quel langage choisir ?
Posté par calandoa . En réponse au journal Quel langage choisir ?. Évalué à 1.
Je te conseille de rester au C. C'est un peu chiant parfois de se taper la réinvention de la roue à chaque fois avec ce langage, mais en utilisant la glib tu peux t'éviter pas mal d'effort, et rien ne t'empêche de faire de l'orienté objet en C... il faut juste un peu plus de rigueur dans l'architecture de ton programme...