TImaniac a écrit 6423 commentaires

j'ai pas dit libre, j'ai dit librement implémentable. Mais bon on parle ici de norme, pas de logiciel, on peut difficilement appliquer la notion de libre à une norme, de la même manière que l'on ne peut pas dire que le HTML ou le XML est libre...

Merde t'as trouvé le troll vicieux :)
Mais je peux encore me rattraper : il existe une implémentation qui ne viole aucun brevet et qui est 100% GPL (je parles des libs) :-p Si quelqu'un râle parcque c'est mal, personne n'a gueulé quand y'a eu une implémentation libre de Unix ;)

erf, pourquoi ne pas faire pareil avec le logiciel ? closed-source pour faire du blé, et zou après on libère les sources. Vous allez dire que c'est mal. Bah je penses que c'est également pareil pour le principe du manuel.

Sun peut attaquer sur .Net avec J2EE
sans vouloir troller, mais c'est j'aurai plutôt mis Microsoft comme assayant.

Et si on mettait un système de notation pour noter les meilleur trolls ? le gagnant aurait le droit de poster son troll en première page, en tant que news... un peu comme le topic correspondant à ce post par exemple :)

J'en profite pour faire remarquer qu'il serait utile d'avoir justement ce lien quand on cliques sur un post, genre par exemple quand on veut matter nos derniers posts, ils est souvent intéressant d'aller voir si y'a pas des réponses, et le fait de devoir cliquer sur le sujet et retrouver le post, c un peu chiant.
voili voilou, je sais pas si je serais entendu mais bon.

Je rajouterai que la correspondance framework.NET/XAML aura également l'avantage de décmocratiser encore plus XAML puisque le programmeur connaîtra déjà toutes les balises, celui-ci étant déjà habitué au framework : pas de perte de temps à apprendre un nouvel API.

XAML est la syntaxe XML correspondant exactement au framework .NET (c'est pas une copie de XUL comme on voudrait bien le faire croire par ici, même si l'idée est la même) :
- les noms de balises correspondent au noms des classes
- les noms des attributs correspondent aux noms des champs des classes
- la hiérarchie correspond à la hiérarchie des conteneurs graphiques .NET.

où je veux en venir ?
Icaza est le chef du projet Mono, qui a comme ambition de porter le framework.NET sous linux, implémenter XAML ne va vraiment pas être compliqué vu la correspondance, et Mono semble être un point de départ tout prêt pour XAML, d'où l'idée de Icaza de ce portage supplémentaire.
Intérêt ?
Bah, le programmeur aura désormais le choix entre XAML et GTK (bah vi, Glade# et GTK# servent à ça), dans le langage .NET qu'ils veulent (parcque quand on fait un bind pour .NET ou mono on le fait pour tous les langages de la plateforme), et pourront même facilement avoir 2 GUI différentes en XML : si je suis sous win je charge le XAML, si je suis sous nux je charge le Glade, c pas bo ca ?
Voili voilou, je tenais à apporter ces quelques précisions sur les motivations de Icaza.

sans vouloir troller, mais XAML n'est pas du tout une copie conforme de XUL, c'est une copie conforme du framework .NET avec la syntaxe XML (les balises ont le nom exact des classes, et les attributs correspondent exactement aux champs des classes).
Résultat : XAML est bien évidemment utilisable avec le framework .NET (une translation est d'ailleur faite au chargement du fichier XAML), et donc par tous les langages du framework .NET (qui a été prévu pour être multi-langage) : C#, VB.NET, c++ managed mais aussi Java, Python, ML, etc.
De plus, grâce à ce cher Icaza, il y a également un bind de Glade (Glade#) pour .NET, Glade est donc à présent disponible pour TOUS les langages .NET. le programmeur .NET n'a donc que l'embarras du choix, soit il utilise Glade s'il veut utiliser GTK (GTK#) soit il utilisera XAML pour une GUI plus windozienne.

ils se sont surtout plaint que c t pas un format xml et que c t pas facile de justement manipuler des css pour cette même raison.

Il est bon de rappeler que Microsoft avait d'abord choisi les CSS pour l'IHM, manque de po les développeurs se sont plaint, et ils ont chercher une nouvelle solution, purement XML qui correspondait mieux aux attentes des développeurs.

C# = norme ECMA and norme ISO
ISO ou ECMA = librement implémentable et utilisable
C# = librement implémentable et utilisable
CQFD

On a le droit de poster des trolls dans les news en première page maintenant ?

Ca peut être un programme dont l'espace mémoire virtuel est bien défini et qui est la seule zone autorisée à être utilisée par le code.
Tu peux appliquer les même règles de sécurités aux périphériques, aux systèmes de fichier, etc.
Ce n'est qu'un exemple, il y a d'autres règles de sécurité.

"les gens ne seront pas obligés de racheter tous leurs softs"
Alors si ça c pas de la mauvaise foi... premièrement les softs qui sont incompatibles sont rares, alors ne généralise pas. Ensuite il existe aussi des softs commerciaux non libre sous nunux avec lesquels tu auras exactement le même problème, et là comme par hasard tu vas dire que c'est de la faute des softs qui otn des failles de sécurité et que c'est pas la faute à l'OS...
De toute façon pour la plupart des softs les patchs sont gratos, effectivement pour les anciens prog celà peut poser problème. Mais faut-il laisser des vieux prog troués de partout ? Bah de toute façon c'est l'occasion ou jamais de proposer des solutions libres alternatives. Donc je ne vois toujours pas le problème.

la première version de linux à intégrer la 1.6
mdr :)

Et ? le format de pilotes signés numériquement de Microsoft ne change pas avec la SP2... y dis qui voit pas le rapport. Là, le problème vient surtout d'importantes modifications dans la gestion de la mémoire et son accès.

tu n'a pas bien lu mon post. Je dis que si ca se trouve on trouvera un problème de sécurité dans nunux qui se révelera être un problème de conception, et la résolution du problème entraînera peut être des modifications plus profondes du noyau, et zou, adieu la compatibilité. Pour le moment les failles de sécurité découvertes peuvent effectivement être simplement "patchées", mais ça ne sera peut être pas toujours le cas.

Erf, c'est toujours le même problème :
soit Microsoft garde une certaine compatibilité avec l'existant, auquel cas il garde aussi des gros problèmes de conceptions et de sécurité auquel cas tous les anti-Microsoft gueulent "oué c une passoire !"
soit Microsoft essai de changer un peu d'architecture pour palier ces mêmes problèmes de sécurité, auquel cas les anti-Microsoft gueulent "oué c'est pas compatible !"
Super le raisonnement à 2 balles...
Tu proposes quoi comme solution ?
De plus pour avoir tester le service pack 2, j'ai perso eu aucun problème logiciels, sauf peut être mon firewall qui a tiré la gueule la première fois... (mais bon je m'y attendais) Sinon tout semble marcher comme avant. Donc ce problème de compatibilité reste minime et s'il permet plus de sécurité, crier au loup est, je trouve, vraiment déplacé.
Enfin je te rappelle que ce problème peut se poser dans le futur pour n'importe quel OS, aussi bien un nunux, et que ferais-tu si là encore tu dois choisir entre compatibilité et sécurité ?
De toute façon les gros softs vont être mis à jour en cas de pépins, pour les autres softs, bah, z'ont qu'à de faire de l'open-source, comme ca tout le monde pourra modifier les progs concernés (ok c utopique mais bon).

ben euh, effectivement faut pas se leurer, c'est pas aussi parfait que le framework by Microsoft, celà dis, j'ai un projet sur mono qu tourne pour le moment parfaitement, j'ai pas encore trouvé de bug, l'implémentation du framework est à mon avis déjà bien utilisable, en tout cas ça me semble stable. Pour ce qui est de la rapidité, ca s'améliore de version en version.
Sinon pour la portabilité, je suis entièrement d'accord avec toi :) Celà dépend beaucoup des API utlisés dessous, notamment du toolkit graphique. Perso je cible un OS, et si ca tourne sur un autre sans modifs, tant mieux, sinon je recode la partie GUI, seule partie pas vraiment portable (question d'intégration surtout).
Mais bon, reste que je code généralement sous visual studio .NET avec GTK# et Glade, et franchement, je me pose même pas la question, je sais que ca tournera nickel sous nux, c'est quand même du grand confort :) Vi parcque effectivement ce qui manque réellement à mono c'est un véritable environnement de développement, le problème est en train d'être en partie résolu avec le portage en GTK de SharpDevelop.
Voili voilou, si ca peut t'aider.

vi vi Apache ignore bel et bien le tag méta, il faut donc que tu modifies ton conf pour que Apache arrête de foutre un charset par défaut !

Autant pour moi, IE fait pareil, sauf quand on affiche les souces où il retrouve bien le charset UTF-8. Me demande pas pkoi. Mais dans tous les cas, c'est la faute à Apache qui force le charset au lieu de respecter celui du document. Bizzare que cette option soit par défaut je trouve.

Vi il semble clair qu'il faille virer le charset par défaut d'apache, sinon il balance tout dans ce charset, ce qui foire tous les accents du document. On notera au passage que IE est plus malin sur ce coup puisqu'il vérifie si dans l'en-tête c'est pas précisé le charset à utiliser, auquel cas c'est celui-ci qui est pris en compte, contrairement à mozilla qui se fit au charset envoyé par Apache.

Bah exemple : l'implémentation ds génériques tiens (je conçois qu'ils aient trouvé utile de vouloir les rendre compatibles avec les VM actuelles, mais vlà l'implémentation qui se résume plus à de la conversion de code qu'un vrai support).
autres exemples : la surcharge d'opérateurs, les mots-clés ref et out, les pointeurs (pas de troll svp, c'est parfois utile niveau perf), les propriétés (fini les setMachin et getMachin), les indexeurs, les délégués, les événements, les types valeurs, et surtout, le versionning !

Bah réfléchi à ma solution alors, elle est 100% libre et t'aura l'avantage de ne pas avoir à réécrire de client pour Windows parcque GTK# est également sous zindows. Au pire t'aura juste à réécrire un client pour MacOS X si GTK# n'a pas encore fini d'être porté d'ici là.