Si mon programme C# a 8 ans, je fais quoi en C ? je recode tout. Je comprends rien à ton argument foireux.
Il y a 8 ans :
- Tu pouvais coder en C# sans pb avec les int
- Tu pouvais coder en C sans pb avec les int.
Ex-aequo.
Tu a parlé de vieux code en C. Donc supérieur à 8 ans (sinon int=32 bits partout, et tu as int64_t pour le 64-bits et même int32_t pour être sur du 32-bits).
Donc tu ne pouvais pas avoir la même chose en C# (qui n'existait pas à l'époque!), donc tu dois tout recoder en C#.
CQFD.
Tu inventes des problèmes qui n'existent pas et apporte des solutions impossibles (chronologiquement tout ça...)
Si il marche.
Rappel : serveur auto-hébergé = disponibilité minimale. Loi de Murfy oblige, c'est quand tu sera en voyage que tu auras une coupure de courant ou autre.
En plus si un ami vient chez moi il peut utiliser mon serveur pour faire sortir ses mails.
Ou bien utiliser son SMTP habituel ou celui de ton FAI, le choix ne manquent pas.
Pas d'avantage particulier ici.
Qu'elle est alors la différence entre un serveur chez toi et un serveur chez un hébergeur?
Car la, tout ce que tu racontes, c'est utile quel que soit l'endroit où tu héberges ton serveur, ce n'est absolument pas lié à l'auto-hébergement.
Je ne vois donc pas l'intérêt d'appeler ce wiki un wiki sur l'auto-hébergement, faudrait plutôt l'appeler un wiki sur l'hébergement (en général).
Bref, l'idée de faire un wiki pour parler des problèmes serveur, OK, dire que c'est typique à l'auto-hébergement, je ne vois pas la raison : tu devient admin système, et tu as exactement les mêmes problèmes que les autres qui administrent des serveurs chez OVH.
Pour que ton Wiki soit un wiki sur l'auto-hébergement, il faudrait que tu parles de choses différentes d'un hébergement chez OVH (et la, ton Wiki va être à 100% rempli rapidement, car il n'y a pas beaucoup de différence!)
Ok autant pour moi. M'enfin le problème est bien réel pour le long.
Pourquoi est-ce une problème? c'est voulu.
Je ne comprend pas comment une fonctionnalité se transforme en défaut pour toi.
Tu te raccroches aux branches car tu vois que ton int argumenté ne tient pas la route, et va sur long dont l'offre est faite pour ce qu'il fait (dépendant de la plate-forme), hum...
Oué je développe sous un OS 64 bits et je constate qu'un long me permet d'avoir un algo fonctionnel.
Quand une personne demande expressément que son entier soit de taille différente suivant la plate-forme, j'ai du mal à admettre qu'elle demande un type qui soit identique quelque soit la personne. C'est la personne qui ne sait pas communiquer, si je dis A quand je pense B, personne ne peut savoir que je pense B.
mais tu peux aussi te retrouver à compiler un code écrit par une tierce personne, y'a 5 ou 10 ans,
L'avantage avec C# est évident : tu ne peux pas.
En fait, tu reproches au C des choses qui viennent avec des fonctionnalités qui n'existent pas avec C#, c'est débile comme argumentation!
Désolé, mais non : tu donnes des exemples qui ont pour résultat :
- C : on a des problème car ça a mal été codé.
- C# : on doit tout recoder.
Tu y vois un avantage à C#, j'en vois un inconvénient.
Question de point de vue.
Suffit d'utiliser les options -m32 et -m64 de GCC pour s'en persuader.
Euh...
Generate code for a 32-bit or 64-bit environment. The 32-bit environment sets int, long and pointer to 32 bits. The 64-bit environment sets int to 32 bits and long and pointer to 64 bits.
Un int (le plus utilisé) reste sur 32 bits.
Donc que je me persuade de quoi? Que j'aurai les même problème de int partout?
Quelqu'un qui a mis "long" doit le faire en sachant ce qu'il fait, donc il connait le problème du 32 bits où long n'est pas en 64 bits (sinon il utilise int).
Le programmeur n'est pas parfait et ne connais pas tout.
Donc puisque le programmeur ne connait pas tout, vaut mieux le apprendre un langage nouveau plutôt que de lui apprendre int64_t? Gloups.
OK, je comprend un peu ta réaction : tu reproches au C/C++ d'etre compatible avec l'existant. int est pour l'existant. Si tu apprends, tu apprends int64_t (10 ans déja!), donc pour un nouveau, ça ne change pas grand chose entre le 64 bits de C# ou celui du C... c'est int partout. Juste qu'il peut mal programmer si besoin (ou si envie) avec des long.
Style je code sur une machine 64bits, je déploie sur 32bits
int est de 32 bits dans les 2 cas, le test échouera ou réussira de la même manière.
Certes, int n'est pas garanti à 32 bits, il peut faire 64 bits sur une machine 64 bits et 32 sur une machine 32 bits (en pratique : jamais vu).
Quand on joue avec des grands chiffres, on le dit, on met "long long int " (ou plus standard int64_t, qui date de 1999!)
Après si tu joues avec des size_t et les débordements, c'est toi qui l'a voulu.
Pourquoi vouloir changer complètement de langage alors qu'il suffit de dire ce que tu veux (et donc mettre int64_t quand tu joue avec des chiffres qui peuvent faire un débordement)?
Aucun ingénieur n'est à l'abri d'une erreur comme celle là.
Si : il utilise les types qui correspondent à son besoin, ce n'est pas parce que le langage a 20 ans qu'il ne faut pas utiliser ses évolutions.
Ah OK. Si le programmer fait une connerie et dit ce qu'il ne veut pas faire, c'est la faute du langage.
Hum.
Bon, les VM peuvent aider les mauvais développeurs, mais c'est limité.
Si tu dis que tu veux effacer un fichier alors que tu pensais l'ouvrir, la VM ne corrigera pas la bêtise.
Euh... Mais il est où le problème???
void*, size_t pour les pointeurs.
int pour des entiers.
Qu'ils soient différents ou pareil ne devrait rien changer au programme.
Après, si le développeur a mis des int dans des pointeurs ou vice-versa, c'est le développeur qu'il faut changer!
C/C++ permettent des bidouilles, c'est pas une raison pour le faire quand on a envie, juste quand on a besoin.
J'attend la démonstration avec un exemple qui fait qu'un programme correctement codé se chie sur les tailles des entiers qui changent et qui sont différent des pointeurs avant de te laisser balancer des affirmations de ce type.
Je pense qu'il serait intéressant, sur le Wiki, d'évoquer les aspects négatifs. Je pense notamment au coût électrique.
Si il n'y avait que cet aspect...
Liste en vrac des points négatifs, puisque seuls les points positifs ont été mis dans la dépêche, un peu façon "plaquette publicitaire".
* On ne dépend de son accès à Internet (c'est positif dans la dépêche, mais la dépêche est fausse : quand on est hébergé chez un hébergeur, on ne dépend pas de son accès Internet, on peut aller dans un cyber café quand elle merde.). QoS d'une connexion perso très inférieure à un hébergeur.
* Si ton FAI tombe en panne, plus d'accès (et un FAI tombe plus souvent en panne qu'une hébergeur)
* Debit fourni par un serveur inférieur au débit d'un seul client (le monde à l'envers!), donc ça marche poru des petits besoins.
* Backup sur un autre site impossible à faire (upload trop limité), besoin d'un copain pour héberger le backup (ne doit pas être sur le même site)
* Envoi d'email délicat (les blocs FAI étant souvent black listés)
* Gestion des déménagements?
* Gestions des vacances? (si ton serveur auto-hébergé se crash et que tu es à 1000 km de chez toi, tu fais comment? Indisponibilité longue)
Et surtout, libérez-vous !
Mais pas avec un hébergement avec un lien à Internet aussi peu fiable!
(sauf si c'est pour faire joujou...)
La taille des pointeurs et la taille d'un int qui change, ca perturbe aucun programme en C
Ca ne perturbe pas un programme bien écrit.
Après, le passage en 64 bits peut montrer des bugs venant du programmeur.
* int reste 32 bits, donc ça ne change pas.
* void*, size_t passent en 64 bits, ce sont des pointeurs, si passer en 64 bits fait des problèmes, c'est que ta version 32 bits couvent un bug/crash, à corriger.
- gestion mémoire (on parle de garantie, pas de l'utilisation parfaite et sans erreur d'une lib)
La seule garantie d'une VM c'est de libérer la mémoire à la fin, comme en C. La VM garantie qu'elle fera à un moment donné (elle décide de ce moment) du vide, mais c'est tout, ça peut faire monter le besoin en RAM rapidement (oups : ça le fait).
Oui, j'ai jamais compris le truc génial de la gestion laissée à la VM, je suis sans doute vieux jeu.
Comment travaille une personne de manière générale?
- Elle cherche la classe qui va bien
- Une fois la classe trouvée, elle cherche la méthode dont elle a besoin. Elle ne connait pas le nom de cette méthode (parce que bon, si elle connait, 99% du temps c'est bon, son IDE va faire l'autocompletion, sinon changer d'IDE). Elle va donc fouiller et regarder en un coup d'oeil la liste des méthodes disponibles :
* MSDN, ou plein d'autres : on trouve assez rapidement, car il y a le nom et une description succincte de chaque méthode. Reste plus qu'à cliquer pour avoir plus d'info.
* javadoc/doxygen : tout est balancé en vrac, faut virer de sa vue les paramètres (on s'en fou quand on cherche une méthode!), et les doublons (bordel, c'est bon, j'ai compris qu'elle existe la méthode)
- Une fois la méthode trouvée, elle s'intéresse à son utilisation
3 étapes, 3 pages facilitant ces étapes, c'est plus pratique qu'un "tout est la, démerde-toi".
Dans l'exemple de String, il y a 2x plus de méthodes chez MS que Java, n'empêche si je cherche la méthode pour formater je la trouve plus rapidement en passant les yeux sur la colonne des noms de méthodes chez MS qu'en décryptant la doc Java (bon, c'est pas la pire, mais peut mieux faire).
C'est peut-être subjectif, mais je connais pas mal de monde que râle sur la doc, sauf sur celle de MS (les seuls qui râlent sont des intégristes anti-MS "linux c'est le meilleur" qui ne peuvent philosophiquement pas dire qu'un truc est bien si ça vient de mal)
Mon reproche va sur la forme présentée du site de référence.
Que ce soit "CSS" ou autre charabia, je m'en fout, mes yeux ne voient que ce qui s'affiche. Quelqu'un parle présentation, tu parles technique, et hop le quelqu'un va aller sur le MSDN parce que la c'est correct sans charabia.
Plus techniquement, oui la CSS par défaut joue, mais pas que ça (les 50 possibilités d'une méthodes sont affichées d'un coup, immonde à lire quelque soit la CSS)
Mais je parie que dans 2s tu va me dire que la formation ne sert à rien, qu'un diplome d'ingé ne vaut rien
Allez, c'est moi qui le dit : pour la compétence d'une personne, non, ça ne sert à rien (et c'est un diplômé d'ingé qui le dit).
J'ai vu des bons non-ingés et de mauvais ingés à jeter le plus rapidement possible sinon ils font couler la boite : ce qu'on apprend en école d'ingé prépare plus que la fac au monde de l'entreprise, mais ce n'est pas encore ça, il manque pas mal de choses qu'on apprend dans la vraie vie, donc diplôme ou pas, c'est pareil.
Maintenant, oui, ça sert dans la vraie vie car c'est un critère de sélection des recruteurs, donc faut le faire.
qu'un dea non plus.
Ca ne vaut pas rien, mais bon, ça ne vaut pas grand chose non plus dans des métiers techniques (je met de côté les DEA "non techniques" où il n'y a souvent pas d'école qui fait la même chose)... (a part si tu veux faire de la recherche).
A moins que ça ai changé en quelques années? (j'en doute...)
Je ne comprends pas très bien le terme: Blu-Ray Linear PCM ...
Le PCM du blu-ray a un header (le truc pour dire la fréquence, nombre de canaux etc...) à lui (le PCM n'ayant pas de header normalisé), donc faut bien gérer ce "format" à part.
VLC lira-t-il les disques Blu-Ray, si oui alors grande nouvelle, je vais pouvoir lire les Blu-Ray sous tous mes systèmes ;-)
VLC lit les fichiers M2TS.
Donc tant que tu ne veux pas de menu et que le fichier M2TS est linéaire (pas de bidouille dans les chapitres par le "moteur" blu-ray), ça passe, oui.
il seront toujours à la traine et à la remorque des décisions de Microsoft.
le "comité de décision" de Mono est Microsoft, qui comme je te l'ai montré est plus démocratique que le "comité de décision" de Python.
Donc il est plus facile de modifier C# que Python quand notre proposition va à l'encontre d'un choix, je te l'ai déjà démontré.
Tu veux absolument voir en Microsoft le mal, et en conclu que comme Mono est un vassal de MS tu n'as pas de pouvoir.
Tu détournes l'argumentation en supposant que MS est pire que Python dans le processus de décision, et part sur cette supposition pour faire tes conclusion.
Comme la base de ton raisonnement est faux, la conclusion est fausse...
Arrête de voir Microsoft comme le mal par défaut, et regarde le processus de décision quand tu veux changer changer quelque chose au langage contraire à ce qui se fait :
- Python : seul moyen est de forker (blocage possible par le dictateur bienveillant), ce qui est très lourd (un fork n'est pas simple! Et il faut tout gérer)
- C#/Mono : acheter des parts de MS, ou convaincre les détenteurs de parts (pas gratuit certes, mais les détenteurs de parts sont nombreux et aiment l'argent donc avoir des utilisateurs donc c'est plus facile)
Désolé, mais bon, c'est un peu kif-kif comme difficulté.
Alors, si tu contre-argumentais sur le principe de la dictature de Python, ça serait plus dans la discussion, je constate que tu évite soigneusement ce passage... Et je t'ai déja démontré que beaucoup de monde voit en Microsoft un dictateur bienveillant comme tu aime chez Python, question de point de vue donc...
Tu n'aimes pas Microsoft, donc tu le considères comme dictateur non bienveillant.
Tu aimes le dictateur de Python, donc tu le considères comme dictateur bienveillant.
Mais au final, ça reste des dictateurs, la seule différence entre les deux étant ton point de vue sur leurs actions.
Le dictateur de Python n'est pas mieux que Microsoft quand on compare Python vs C#.
Ou prouve moi le contraire, mais pas en disant "ça vient de Microsoft donc c'est nul", ce n'est pas un argument. Pas non plus "ça va dans mon sens donc c'est bien", ce n'est pas un argument non plus (tous les dictateurs ont une base de fans solide pour pouvoir rester en place...)
Comment dévier la conversation sur le "monopole" de Microsoft...
On parlait langage, donc Python vs C#.
On est autant libre de quitter C# que Python, ex-aequo.
Bon, pour forker, c'est peut-être plus dur à cause de la propriété intellectuelle certes, mais bon j'ai d'un côté une personne+fork possible, de l'autre une entreprise (plusieurs personnes qui décident) + fork moins facilement possible, bof bof... Non, désolé, je ne vois pas trop la différence.
un pouvoir sans contre-pouvoir est a fortiori dangereux et donc à bannir.
Sur ça, on est d'accord :).
Oui, le libre apporte un contre-pouvoir plus costaud (fork plus facile), mais il amène aussi son lot de "leaders" un peu chiants et obtus (cas de XFree...), ce n'est pas toujours bon.
Et dans le cas spécifique de Python vs C#, ça reste quand même une différence très petite entre chaque mode de gouvernance...
Euh... Un vieux HtmlHelp de Windows 95 c'est sensé être au goût des amateurs de Microsoft???
Faut reinstaller un Windows, le monde a bien changé depuis 10 ans, et il faut aller voir un peu le MSDN plutôt que d'avoir des préjugés sur le design de MS d'aujourd'hui...
Le dictateur bienveillant c'est celui qui prend des décisions pour le peuple, bref, utiliser son pouvoir à bon escient.
Je vais te donner un exemple de subjectivité : pour beaucoup de monde, MS est un gentil dictateur car il a fait sortir l'informatique de sa niche de geek en faisant un OS adapté au grand public.
Il a en plus fait C#, qui est génial pour faciliter le développement, il répond au besoin des développeur, il écoute les développeurs, et en plus il met le framework en installation forcée (très aidée) lors des Windows Update. Pour les développeurs, que du bonheur.
Toi, tu n'es pas d'accord, et tu trouves C# dangereux, qu'il ne faut pas l'utiliser pour raison x ou y.
Mais... Je n'ai fait que remplacer Python par C# et le gentil dictateur par MS, pas plus, juste que tu n'es pas du bon côté, que tu n'aime pas ce que fais le "gentil dictateur"... Mais c'est la seule différence : ton gout.
--> Un "gentil dictateur" reste un dictateur, qui ne sera pas gentil pour certaines personnes. Des fois tu as de la chance ça va dans ton sens, des fois non.
e dictateur bienveillant c'est celui qui prend des décisions pour le peuple, bref, utiliser son pouvoir à bon escient.
Si le peuple n'arrive pas à se décider tout seul, et que le dictateur bienveillant décide, ne crois-tu pas qu'il y aura au minimum 50% des gens qui se sentiront trahis?
Par opposition au dictateur qui est là pour opprimer son peuple et faire taire les opposants, abuser de son pouvoir.
Pour les 50% mini des gens contre une décision du dictateur bienveillant, ce sera exactement ce qu'il pensent du dictateur bienveillant.
Un dictateur bienveillant fait moins de dégât qu'un dictateur pays dirigeant d'un pays juste parce que :
- Il ne dirige pas d'armée
- pour l'open-source, il est à la merci d'un Fork.
- les gens peuvent quitter le "pays" sans problème
Sinon, l'idée du dictateur bienveillant est exactement la même qu'un dictateur normal... Il décide à la place des autres ce qui l'arrange lui (ce qui lui plait), en faisant taire les opposants ("on est parti sur xxx, la solution concurrente n'a plus à être discutée").
Dans le logiciel, il en faut, sinon on a du mal à avancer rapidement, mais ça n'enlève pas le fait que c'est une dictature... L'avenir de Python peut être décidé par un seul homme qui n'a pas de contre-pouvoir (exemple : une "loi" qui dit que si x% de la communauté vote contre une solution proposée par le gentil dictateur, le gentil dictateur ne peut pas imposer) gravé dans le marbre (l'intérêt étant de connaitre les limites démocratiques avant de les atteindre...)
Ne t'en déplaise, une bonne documentation est un point essentiel pour un langage quand tu veux le diffuser partout.
Une mauvaise documentation ne va pas attirer les développeurs du dimanche, qui demain seront les développeurs professionnels et feront l'effet de volume.
C'est sur ce genre de détail que certaines choses peuvent échouer... Pas celui-ci tout seul, mais une mauvaise documentation aide à faire fuir les gens si ils ont d'autres reproches à faire.
Bon, après, 99% des logiciels sont mono-plate-forme Windows, une bonne partie des applis web sont en PHP qui a une documentation tout aussi lisible (à défaut d'être 100% exacte ;-) ), alors bon, c'est vous qui voyaient...
Certes Guido a formellement le droit de décider mais en pratique il suit les votes de la communauté.
La démocratie, le vote démocratique, est un vote qui ne peut être rejeté si le "gentil dictateur" peut décider que le vote ne va pas dans la bonne direction.
Tant qu'un dictateur, aussi gentil soit-il aujourd'hui (ce qui ne garanti pas qu'il le sera demain), peut poser un veto sans qu'il y ai un recours possible [1], le vote reste qu'une proposition, pas une obligation, et le langage est alors contrôlé par une personne.
Car c'est au moment ou on voudra aller à l'encontre du gentil dictateur qu'on s'apercevra qu'il n'est pas si gentil que ça.
Donc OK, je met Java en dehors de tout ça, si j'ai bien compris SUN ne peut plus poser de Veto, mais pour Python, désolé tu ne m'a pas convaincu : Microsoft écoute les développeurs et fait évoluer le language en fonction de la demande, ça revient en pratique et en théorie exactement au même que pour Python, la mise en form "comité" pour faire joli en moins pour MS. Tant que Python sera une démocratie sous condition, ce ne sera pas une démocratie, ce sera un langage contrôlé par une personne.
Ce qui, en théorie est encore plus dangereux que le cas Microsoft : On ne peut changer le dictateur de Python, mais on peut changer Microsoft (on peut acheter 50% + 1 actions de MS, ou convaincre les actionnaires qu'il faut changer de direction).
Plus j'y réfléchis, et plus je vois Python comme plus directif que C# au niveau du "management"... (reste alors à forker, mais c'est aussi faisable pour C#....)
Le "méchant" n'est pas forcement celui auquel on croit en premier.
[1] ça me fait penser à la Belgique dont si je me souviens bien le parlement a mis le roi "dans l'incapacité de signer" pendant quelques jours pour faire passer une loi sur l'homosexualité qui demandait une signature du roi pour être valide mais que le roi ne souhaitait pas signer, bref il y a moyen de contourner ;-) Corrigez-moi si je me trompe.
Merci pour l'info.
Donc pour paraphraser patrick_g, dans le cas de Python on a une seule personne (c'est mieux qu'une entité?) qui décide de tout et on a la communauté qui ne décide de rien et qui a juste le droit de proposer des choses sans être sûre que ce sera pris en compte (si le gentil dictateur fait la tête, quelques soit tes arguments et la popularité de ta demande, elle peut être rejetée sans avoir à fournir de raison.)
Mouais, finalement Java ou Python, ce n'est pas beaucoup mieux que C# de ce côté... Pas un argument contre C#.
Et ajoutons que le développement de Python, de Java, etc est un développement qui n'est pas sous le contrôle d'une seule société.
Bon, admettons pour Python, c'est une fondation qui s'en occupe, je ne sais pas quel est le degré de liberté laissé aux proposeurs (j'ai quand même du mal à croire qu'il n'y a pas un "gentil dictateur", vu le temps que les organismes W3C, C ou C++ mettent pour mettre tout le monde d'accord quand il y a une démocratie bien affichée...)
Par contre pour Java je tique : à ma connaissance si tu n'es pas d'accord avec SUN, ce sera SUN qui aura le dernier mot. Java est sous le contrôle de SUN autant que C# est sous le contrôle de Microsoft.
Tu donnes un magnifique exemple :
- La doc Java est une horreur à lire, un truc de vieux informaticien au niveau de la mise en page (j'ai les 36 variante d'une méthode dont je ne veux pas, ça noit la méthode que je cherche)
- La doc MSDN est agréable à lire, bien plus présentable, les choses sont bien séparées, l'important est affiché sur la première page pour m'aider à trouver ce que je cherche.
C'est sans doutes une question de gouts, mais clairement, MSDN dépasse JavaDoc de loin pour ma rapidité de recherche de méthode dont je ne connait pas le nom (le plus souvent, pour le reste il y a l'aut-completion de mon IDE)
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Il y a 8 ans :
- Tu pouvais coder en C# sans pb avec les int
- Tu pouvais coder en C sans pb avec les int.
Ex-aequo.
Tu a parlé de vieux code en C. Donc supérieur à 8 ans (sinon int=32 bits partout, et tu as int64_t pour le 64-bits et même int32_t pour être sur du 32-bits).
Donc tu ne pouvais pas avoir la même chose en C# (qui n'existait pas à l'époque!), donc tu dois tout recoder en C#.
CQFD.
Tu inventes des problèmes qui n'existent pas et apporte des solutions impossibles (chronologiquement tout ça...)
[^] # Re: Je ne comprend pas ?
Posté par Zenitram (site web personnel) . En réponse à la dépêche Un wiki sur l'auto-hébergement. Évalué à 2.
Si il marche.
Rappel : serveur auto-hébergé = disponibilité minimale. Loi de Murfy oblige, c'est quand tu sera en voyage que tu auras une coupure de courant ou autre.
En plus si un ami vient chez moi il peut utiliser mon serveur pour faire sortir ses mails.
Ou bien utiliser son SMTP habituel ou celui de ton FAI, le choix ne manquent pas.
Pas d'avantage particulier ici.
[^] # Re: Je ne comprend pas ?
Posté par Zenitram (site web personnel) . En réponse à la dépêche Un wiki sur l'auto-hébergement. Évalué à 4.
Car la, tout ce que tu racontes, c'est utile quel que soit l'endroit où tu héberges ton serveur, ce n'est absolument pas lié à l'auto-hébergement.
Je ne vois donc pas l'intérêt d'appeler ce wiki un wiki sur l'auto-hébergement, faudrait plutôt l'appeler un wiki sur l'hébergement (en général).
Bref, l'idée de faire un wiki pour parler des problèmes serveur, OK, dire que c'est typique à l'auto-hébergement, je ne vois pas la raison : tu devient admin système, et tu as exactement les mêmes problèmes que les autres qui administrent des serveurs chez OVH.
Pour que ton Wiki soit un wiki sur l'auto-hébergement, il faudrait que tu parles de choses différentes d'un hébergement chez OVH (et la, ton Wiki va être à 100% rempli rapidement, car il n'y a pas beaucoup de différence!)
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Pourquoi est-ce une problème?
c'est voulu.
Je ne comprend pas comment une fonctionnalité se transforme en défaut pour toi.
Tu te raccroches aux branches car tu vois que ton int argumenté ne tient pas la route, et va sur long dont l'offre est faite pour ce qu'il fait (dépendant de la plate-forme), hum...
Oué je développe sous un OS 64 bits et je constate qu'un long me permet d'avoir un algo fonctionnel.
Quand une personne demande expressément que son entier soit de taille différente suivant la plate-forme, j'ai du mal à admettre qu'elle demande un type qui soit identique quelque soit la personne. C'est la personne qui ne sait pas communiquer, si je dis A quand je pense B, personne ne peut savoir que je pense B.
mais tu peux aussi te retrouver à compiler un code écrit par une tierce personne, y'a 5 ou 10 ans,
L'avantage avec C# est évident : tu ne peux pas.
En fait, tu reproches au C des choses qui viennent avec des fonctionnalités qui n'existent pas avec C#, c'est débile comme argumentation!
Désolé, mais non : tu donnes des exemples qui ont pour résultat :
- C : on a des problème car ça a mal été codé.
- C# : on doit tout recoder.
Tu y vois un avantage à C#, j'en vois un inconvénient.
Question de point de vue.
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Euh...
Generate code for a 32-bit or 64-bit environment. The 32-bit environment sets int, long and pointer to 32 bits. The 64-bit environment sets int to 32 bits and long and pointer to 64 bits.
Un int (le plus utilisé) reste sur 32 bits.
Donc que je me persuade de quoi? Que j'aurai les même problème de int partout?
Quelqu'un qui a mis "long" doit le faire en sachant ce qu'il fait, donc il connait le problème du 32 bits où long n'est pas en 64 bits (sinon il utilise int).
Le programmeur n'est pas parfait et ne connais pas tout.
Donc puisque le programmeur ne connait pas tout, vaut mieux le apprendre un langage nouveau plutôt que de lui apprendre int64_t? Gloups.
OK, je comprend un peu ta réaction : tu reproches au C/C++ d'etre compatible avec l'existant. int est pour l'existant. Si tu apprends, tu apprends int64_t (10 ans déja!), donc pour un nouveau, ça ne change pas grand chose entre le 64 bits de C# ou celui du C... c'est int partout. Juste qu'il peut mal programmer si besoin (ou si envie) avec des long.
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Genre?
Style je code sur une machine 64bits, je déploie sur 32bits
int est de 32 bits dans les 2 cas, le test échouera ou réussira de la même manière.
Certes, int n'est pas garanti à 32 bits, il peut faire 64 bits sur une machine 64 bits et 32 sur une machine 32 bits (en pratique : jamais vu).
Quand on joue avec des grands chiffres, on le dit, on met "long long int " (ou plus standard int64_t, qui date de 1999!)
Après si tu joues avec des size_t et les débordements, c'est toi qui l'a voulu.
Pourquoi vouloir changer complètement de langage alors qu'il suffit de dire ce que tu veux (et donc mettre int64_t quand tu joue avec des chiffres qui peuvent faire un débordement)?
Aucun ingénieur n'est à l'abri d'une erreur comme celle là.
Si : il utilise les types qui correspondent à son besoin, ce n'est pas parce que le langage a 20 ans qu'il ne faut pas utiliser ses évolutions.
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Ah OK. Si le programmer fait une connerie et dit ce qu'il ne veut pas faire, c'est la faute du langage.
Hum.
Bon, les VM peuvent aider les mauvais développeurs, mais c'est limité.
Si tu dis que tu veux effacer un fichier alors que tu pensais l'ouvrir, la VM ne corrigera pas la bêtise.
Le mieux est de changer de programmeur.
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Euh... Mais il est où le problème???
void*, size_t pour les pointeurs.
int pour des entiers.
Qu'ils soient différents ou pareil ne devrait rien changer au programme.
Après, si le développeur a mis des int dans des pointeurs ou vice-versa, c'est le développeur qu'il faut changer!
C/C++ permettent des bidouilles, c'est pas une raison pour le faire quand on a envie, juste quand on a besoin.
J'attend la démonstration avec un exemple qui fait qu'un programme correctement codé se chie sur les tailles des entiers qui changent et qui sont différent des pointeurs avant de te laisser balancer des affirmations de ce type.
[^] # Re: Et les aspects négatifs
Posté par Zenitram (site web personnel) . En réponse à la dépêche Un wiki sur l'auto-hébergement. Évalué à 9.
Si il n'y avait que cet aspect...
Liste en vrac des points négatifs, puisque seuls les points positifs ont été mis dans la dépêche, un peu façon "plaquette publicitaire".
* On ne dépend de son accès à Internet (c'est positif dans la dépêche, mais la dépêche est fausse : quand on est hébergé chez un hébergeur, on ne dépend pas de son accès Internet, on peut aller dans un cyber café quand elle merde.). QoS d'une connexion perso très inférieure à un hébergeur.
* Si ton FAI tombe en panne, plus d'accès (et un FAI tombe plus souvent en panne qu'une hébergeur)
* Debit fourni par un serveur inférieur au débit d'un seul client (le monde à l'envers!), donc ça marche poru des petits besoins.
* Backup sur un autre site impossible à faire (upload trop limité), besoin d'un copain pour héberger le backup (ne doit pas être sur le même site)
* Envoi d'email délicat (les blocs FAI étant souvent black listés)
* Gestion des déménagements?
* Gestions des vacances? (si ton serveur auto-hébergé se crash et que tu es à 1000 km de chez toi, tu fais comment? Indisponibilité longue)
Et surtout, libérez-vous !
Mais pas avec un hébergement avec un lien à Internet aussi peu fiable!
(sauf si c'est pour faire joujou...)
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Ca ne perturbe pas un programme bien écrit.
Après, le passage en 64 bits peut montrer des bugs venant du programmeur.
* int reste 32 bits, donc ça ne change pas.
* void*, size_t passent en 64 bits, ce sont des pointeurs, si passer en 64 bits fait des problèmes, c'est que ta version 32 bits couvent un bug/crash, à corriger.
- gestion mémoire (on parle de garantie, pas de l'utilisation parfaite et sans erreur d'une lib)
La seule garantie d'une VM c'est de libérer la mémoire à la fin, comme en C. La VM garantie qu'elle fera à un moment donné (elle décide de ce moment) du vide, mais c'est tout, ça peut faire monter le besoin en RAM rapidement (oups : ça le fait).
Oui, j'ai jamais compris le truc génial de la gestion laissée à la VM, je suis sans doute vieux jeu.
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
- Elle cherche la classe qui va bien
- Une fois la classe trouvée, elle cherche la méthode dont elle a besoin. Elle ne connait pas le nom de cette méthode (parce que bon, si elle connait, 99% du temps c'est bon, son IDE va faire l'autocompletion, sinon changer d'IDE). Elle va donc fouiller et regarder en un coup d'oeil la liste des méthodes disponibles :
* MSDN, ou plein d'autres : on trouve assez rapidement, car il y a le nom et une description succincte de chaque méthode. Reste plus qu'à cliquer pour avoir plus d'info.
* javadoc/doxygen : tout est balancé en vrac, faut virer de sa vue les paramètres (on s'en fou quand on cherche une méthode!), et les doublons (bordel, c'est bon, j'ai compris qu'elle existe la méthode)
- Une fois la méthode trouvée, elle s'intéresse à son utilisation
3 étapes, 3 pages facilitant ces étapes, c'est plus pratique qu'un "tout est la, démerde-toi".
Dans l'exemple de String, il y a 2x plus de méthodes chez MS que Java, n'empêche si je cherche la méthode pour formater je la trouve plus rapidement en passant les yeux sur la colonne des noms de méthodes chez MS qu'en décryptant la doc Java (bon, c'est pas la pire, mais peut mieux faire).
C'est peut-être subjectif, mais je connais pas mal de monde que râle sur la doc, sauf sur celle de MS (les seuls qui râlent sont des intégristes anti-MS "linux c'est le meilleur" qui ne peuvent philosophiquement pas dire qu'un truc est bien si ça vient de mal)
[^] # Re: est-ce qu'il lit le closed caption ?
Posté par Zenitram (site web personnel) . En réponse à la dépêche VLC 1.0.0 : Nom de code "Goldeneye". Évalué à 7.
MediaInfo!
(tout attaché, avec des majuscules)
(codé par quelqu'un qui traine d'ailleurs sur linuxfr! ).
Chut ;-)
Pour l'instant, tous mes VLC ont échoués au test de lecture du CC. Je suis pressé d'etre ce soir pour tester!
Les samples que j'ai passent au moins depuis la v0.9.9, il n'y a pas de raison.
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Que ce soit "CSS" ou autre charabia, je m'en fout, mes yeux ne voient que ce qui s'affiche. Quelqu'un parle présentation, tu parles technique, et hop le quelqu'un va aller sur le MSDN parce que la c'est correct sans charabia.
Plus techniquement, oui la CSS par défaut joue, mais pas que ça (les 50 possibilités d'une méthodes sont affichées d'un coup, immonde à lire quelque soit la CSS)
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Allez, c'est moi qui le dit : pour la compétence d'une personne, non, ça ne sert à rien (et c'est un diplômé d'ingé qui le dit).
J'ai vu des bons non-ingés et de mauvais ingés à jeter le plus rapidement possible sinon ils font couler la boite : ce qu'on apprend en école d'ingé prépare plus que la fac au monde de l'entreprise, mais ce n'est pas encore ça, il manque pas mal de choses qu'on apprend dans la vraie vie, donc diplôme ou pas, c'est pareil.
Maintenant, oui, ça sert dans la vraie vie car c'est un critère de sélection des recruteurs, donc faut le faire.
qu'un dea non plus.
Ca ne vaut pas rien, mais bon, ça ne vaut pas grand chose non plus dans des métiers techniques (je met de côté les DEA "non techniques" où il n'y a souvent pas d'école qui fait la même chose)... (a part si tu veux faire de la recherche).
A moins que ça ai changé en quelques années? (j'en doute...)
[^] # Re: Blu-Ray?
Posté par Zenitram (site web personnel) . En réponse au journal VLC 1.0.0. Évalué à 4.
Le PCM du blu-ray a un header (le truc pour dire la fréquence, nombre de canaux etc...) à lui (le PCM n'ayant pas de header normalisé), donc faut bien gérer ce "format" à part.
VLC lira-t-il les disques Blu-Ray, si oui alors grande nouvelle, je vais pouvoir lire les Blu-Ray sous tous mes systèmes ;-)
VLC lit les fichiers M2TS.
Donc tant que tu ne veux pas de menu et que le fichier M2TS est linéaire (pas de bidouille dans les chapitres par le "moteur" blu-ray), ça passe, oui.
[^] # Re: Drôle
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
le "comité de décision" de Mono est Microsoft, qui comme je te l'ai montré est plus démocratique que le "comité de décision" de Python.
Donc il est plus facile de modifier C# que Python quand notre proposition va à l'encontre d'un choix, je te l'ai déjà démontré.
Tu veux absolument voir en Microsoft le mal, et en conclu que comme Mono est un vassal de MS tu n'as pas de pouvoir.
Tu détournes l'argumentation en supposant que MS est pire que Python dans le processus de décision, et part sur cette supposition pour faire tes conclusion.
Comme la base de ton raisonnement est faux, la conclusion est fausse...
Arrête de voir Microsoft comme le mal par défaut, et regarde le processus de décision quand tu veux changer changer quelque chose au langage contraire à ce qui se fait :
- Python : seul moyen est de forker (blocage possible par le dictateur bienveillant), ce qui est très lourd (un fork n'est pas simple! Et il faut tout gérer)
- C#/Mono : acheter des parts de MS, ou convaincre les détenteurs de parts (pas gratuit certes, mais les détenteurs de parts sont nombreux et aiment l'argent donc avoir des utilisateurs donc c'est plus facile)
Désolé, mais bon, c'est un peu kif-kif comme difficulté.
Alors, si tu contre-argumentais sur le principe de la dictature de Python, ça serait plus dans la discussion, je constate que tu évite soigneusement ce passage... Et je t'ai déja démontré que beaucoup de monde voit en Microsoft un dictateur bienveillant comme tu aime chez Python, question de point de vue donc...
Tu n'aimes pas Microsoft, donc tu le considères comme dictateur non bienveillant.
Tu aimes le dictateur de Python, donc tu le considères comme dictateur bienveillant.
Mais au final, ça reste des dictateurs, la seule différence entre les deux étant ton point de vue sur leurs actions.
Le dictateur de Python n'est pas mieux que Microsoft quand on compare Python vs C#.
Ou prouve moi le contraire, mais pas en disant "ça vient de Microsoft donc c'est nul", ce n'est pas un argument. Pas non plus "ça va dans mon sens donc c'est bien", ce n'est pas un argument non plus (tous les dictateurs ont une base de fans solide pour pouvoir rester en place...)
[^] # Re: Drôle
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Comment dévier la conversation sur le "monopole" de Microsoft...
On parlait langage, donc Python vs C#.
On est autant libre de quitter C# que Python, ex-aequo.
Bon, pour forker, c'est peut-être plus dur à cause de la propriété intellectuelle certes, mais bon j'ai d'un côté une personne+fork possible, de l'autre une entreprise (plusieurs personnes qui décident) + fork moins facilement possible, bof bof... Non, désolé, je ne vois pas trop la différence.
un pouvoir sans contre-pouvoir est a fortiori dangereux et donc à bannir.
Sur ça, on est d'accord :).
Oui, le libre apporte un contre-pouvoir plus costaud (fork plus facile), mais il amène aussi son lot de "leaders" un peu chiants et obtus (cas de XFree...), ce n'est pas toujours bon.
Et dans le cas spécifique de Python vs C#, ça reste quand même une différence très petite entre chaque mode de gouvernance...
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Faut reinstaller un Windows, le monde a bien changé depuis 10 ans, et il faut aller voir un peu le MSDN plutôt que d'avoir des préjugés sur le design de MS d'aujourd'hui...
[^] # Re: Drôle
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Je vais te donner un exemple de subjectivité : pour beaucoup de monde, MS est un gentil dictateur car il a fait sortir l'informatique de sa niche de geek en faisant un OS adapté au grand public.
Il a en plus fait C#, qui est génial pour faciliter le développement, il répond au besoin des développeur, il écoute les développeurs, et en plus il met le framework en installation forcée (très aidée) lors des Windows Update. Pour les développeurs, que du bonheur.
Toi, tu n'es pas d'accord, et tu trouves C# dangereux, qu'il ne faut pas l'utiliser pour raison x ou y.
Mais... Je n'ai fait que remplacer Python par C# et le gentil dictateur par MS, pas plus, juste que tu n'es pas du bon côté, que tu n'aime pas ce que fais le "gentil dictateur"... Mais c'est la seule différence : ton gout.
--> Un "gentil dictateur" reste un dictateur, qui ne sera pas gentil pour certaines personnes. Des fois tu as de la chance ça va dans ton sens, des fois non.
[^] # Re: Drôle
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Si le peuple n'arrive pas à se décider tout seul, et que le dictateur bienveillant décide, ne crois-tu pas qu'il y aura au minimum 50% des gens qui se sentiront trahis?
Par opposition au dictateur qui est là pour opprimer son peuple et faire taire les opposants, abuser de son pouvoir.
Pour les 50% mini des gens contre une décision du dictateur bienveillant, ce sera exactement ce qu'il pensent du dictateur bienveillant.
Un dictateur bienveillant fait moins de dégât qu'un dictateur pays dirigeant d'un pays juste parce que :
- Il ne dirige pas d'armée
- pour l'open-source, il est à la merci d'un Fork.
- les gens peuvent quitter le "pays" sans problème
Sinon, l'idée du dictateur bienveillant est exactement la même qu'un dictateur normal... Il décide à la place des autres ce qui l'arrange lui (ce qui lui plait), en faisant taire les opposants ("on est parti sur xxx, la solution concurrente n'a plus à être discutée").
Dans le logiciel, il en faut, sinon on a du mal à avancer rapidement, mais ça n'enlève pas le fait que c'est une dictature... L'avenir de Python peut être décidé par un seul homme qui n'a pas de contre-pouvoir (exemple : une "loi" qui dit que si x% de la communauté vote contre une solution proposée par le gentil dictateur, le gentil dictateur ne peut pas imposer) gravé dans le marbre (l'intérêt étant de connaitre les limites démocratiques avant de les atteindre...)
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Ne t'en déplaise, une bonne documentation est un point essentiel pour un langage quand tu veux le diffuser partout.
Une mauvaise documentation ne va pas attirer les développeurs du dimanche, qui demain seront les développeurs professionnels et feront l'effet de volume.
C'est sur ce genre de détail que certaines choses peuvent échouer... Pas celui-ci tout seul, mais une mauvaise documentation aide à faire fuir les gens si ils ont d'autres reproches à faire.
Bon, après, 99% des logiciels sont mono-plate-forme Windows, une bonne partie des applis web sont en PHP qui a une documentation tout aussi lisible (à défaut d'être 100% exacte ;-) ), alors bon, c'est vous qui voyaient...
[^] # Re: Drôle
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
La démocratie, le vote démocratique, est un vote qui ne peut être rejeté si le "gentil dictateur" peut décider que le vote ne va pas dans la bonne direction.
Tant qu'un dictateur, aussi gentil soit-il aujourd'hui (ce qui ne garanti pas qu'il le sera demain), peut poser un veto sans qu'il y ai un recours possible [1], le vote reste qu'une proposition, pas une obligation, et le langage est alors contrôlé par une personne.
Car c'est au moment ou on voudra aller à l'encontre du gentil dictateur qu'on s'apercevra qu'il n'est pas si gentil que ça.
Donc OK, je met Java en dehors de tout ça, si j'ai bien compris SUN ne peut plus poser de Veto, mais pour Python, désolé tu ne m'a pas convaincu : Microsoft écoute les développeurs et fait évoluer le language en fonction de la demande, ça revient en pratique et en théorie exactement au même que pour Python, la mise en form "comité" pour faire joli en moins pour MS. Tant que Python sera une démocratie sous condition, ce ne sera pas une démocratie, ce sera un langage contrôlé par une personne.
Ce qui, en théorie est encore plus dangereux que le cas Microsoft : On ne peut changer le dictateur de Python, mais on peut changer Microsoft (on peut acheter 50% + 1 actions de MS, ou convaincre les actionnaires qu'il faut changer de direction).
Plus j'y réfléchis, et plus je vois Python comme plus directif que C# au niveau du "management"... (reste alors à forker, mais c'est aussi faisable pour C#....)
Le "méchant" n'est pas forcement celui auquel on croit en premier.
[1] ça me fait penser à la Belgique dont si je me souviens bien le parlement a mis le roi "dans l'incapacité de signer" pendant quelques jours pour faire passer une loi sur l'homosexualité qui demandait une signature du roi pour être valide mais que le roi ne souhaitait pas signer, bref il y a moyen de contourner ;-) Corrigez-moi si je me trompe.
[^] # Re: Drôle
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Merci pour l'info.
Donc pour paraphraser patrick_g, dans le cas de Python on a une seule personne (c'est mieux qu'une entité?) qui décide de tout et on a la communauté qui ne décide de rien et qui a juste le droit de proposer des choses sans être sûre que ce sera pris en compte (si le gentil dictateur fait la tête, quelques soit tes arguments et la popularité de ta demande, elle peut être rejetée sans avoir à fournir de raison.)
Mouais, finalement Java ou Python, ce n'est pas beaucoup mieux que C# de ce côté... Pas un argument contre C#.
[^] # Re: Drôle
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Bon, admettons pour Python, c'est une fondation qui s'en occupe, je ne sais pas quel est le degré de liberté laissé aux proposeurs (j'ai quand même du mal à croire qu'il n'y a pas un "gentil dictateur", vu le temps que les organismes W3C, C ou C++ mettent pour mettre tout le monde d'accord quand il y a une démocratie bien affichée...)
Par contre pour Java je tique : à ma connaissance si tu n'es pas d'accord avec SUN, ce sera SUN qui aura le dernier mot. Java est sous le contrôle de SUN autant que C# est sous le contrôle de Microsoft.
[^] # Re: Pourquoi Mono ?
Posté par Zenitram (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
http://java.sun.com/javase/6/docs/api/java/lang/String.html
http://msdn.microsoft.com/fr-fr/library/system.string_member(...)
Tu donnes un magnifique exemple :
- La doc Java est une horreur à lire, un truc de vieux informaticien au niveau de la mise en page (j'ai les 36 variante d'une méthode dont je ne veux pas, ça noit la méthode que je cherche)
- La doc MSDN est agréable à lire, bien plus présentable, les choses sont bien séparées, l'important est affiché sur la première page pour m'aider à trouver ce que je cherche.
Note: pour rajouter un language, le C++!
http://www.cplusplus.com/reference/string/string/
Aussi assez agréable à lire.
C'est sans doutes une question de gouts, mais clairement, MSDN dépasse JavaDoc de loin pour ma rapidité de recherche de méthode dont je ne connait pas le nom (le plus souvent, pour le reste il y a l'aut-completion de mon IDE)