TImaniac a écrit 6420 commentaires

J'en profite pour te demander ce que tu entends quand tu dis :
Mais encore une fois, en fait on s'en fout un peu. Le point important est qu'en C#, on peut avoir un comportement différent pour un objet selon le type de la variable qui contient la référence vers l'objet, alors que c'est impossible en Java. Personnellement, je trouve ça plutôt gênant et surtout, je ne vois pas d'application pratique.

Sauf que dans .NET/Mono, les chargements de classes se font TOUJOURS de manière dynamique s'il n'est pas situé dans la même dll...

oki merci pour les infos !
quand je suis allé sur majordo y'avait pleins de mailing-list je savais pas laquelle choisir :) en tout cas heureux de savoir que je ne duis pas le seul avec ce bug !

Moi je dis qu'ils avaient qu'à déposer un brevet ces étudiants ;)

Ca fait des années qu'on sait faire des optimisations globales qui permettent de virer les virtual inutiles
Dans le cas de C#, le code est transformé en code intermédiaire, si le compilateur a procédé à des optimisations, comme par exemple des inlines, je vois de gros problèmes dans certains scénarios :
Je déclare une classe qui dérive d'une classe du code intermédiaire...
je fais la même chose au runtime de manière dynamique...

C'est pas pour rien que Java ou C# n'a jamais et ne pourra jamais procéder à ce genre d'opitmisation !

Tu vois où est le problème maintenant ;)

AH oué effectivement, ce sont bien amusé quand même, parcque le mec il a une voix qui ressemble étrangement :) Même les instruments sont bien reproduits, j'y ai vu que du feu !

essai quoi ? J'ai effectivement effectuée la manip la première fois... ce que je voulais dire c'est que ce n'est peut-être pas une partition FAT standard vu qu'il faut un utilitaire spécial pour effectuer le formattage, et peut être celà vient-il de celà...
Par contre je veux bien discuter sur une mailing-list de kernel.org, mais laquelle ???

Et donc la question qui tue : avec quoi ils ont truqué la voix ?

Payante pour une utilisation commerciale il me semble.

d'après les explications qu'on m'a donné dans le premier post que j'avais fait, c'est bien un 2.6.8-rcX que j'ai, et pourtant...

Vi j'ai bien reformatter ma clé sous Windows... le seul truc c'est qu'il y a une partie du schmurck qui est constitué du firmware du player mp3, et je sais qu'il fallait faire un premier formattage spéciale avec l'utilitaire de Philips. Peut-être celà vient-il de celà ?

Bon bah j'ai résolu le problème avec brio : j'ai enlevé la fermeture du paquet de brioche qui était coinssé dedans :p

Mon expérience me dit qu'il ne faut pas trop te baser sur un langage, la plupart peuvent être utilisés sur la plupart des OS, mais sur des API indépendants de l'OS.
En fait le principal soucis vient de l'interface graphique, et là il y a 2 écoles :
- même code pour toutes les plateformes :
- avantages : 100% portable, diminue le boulot du programmeur
- inconvénients : malgrès ce que evulent faire croirent leurs concepteurs, il est impossible d'avoir à la fois un toolkit graphique portable et puissant qui utilise toutes les possibilités de l'OS cible : bien que visuellement corrects lorsqu'ils utilisent directement les API graphique de l'OS cible, ils leurs manquent soient des fonctionnalités (parcque il fau prendre les facteurs communs), soit émulés (beaucoup moins classs déjà) et surtout ils ne sont pas du tout intégrés à l'environnement (parcque si c'était juste une histoire de skin je verrais vraiment pas l'intérêt d'avoir conçu pleins de toolkit différents, de charte graphique, ou tout simplement d'environnement)
- exemples : Java, Python+Qt, Perl+GTK, etc.

- même code pour l'application, mais pas pour la couche graphique :
- avantages : tu garanties l'intégration visuelle et ergonomique de ton application, ce qui est beaucoup plus "professionnel", notamment pour des applications desktop destinées à monsieur-tout-le-monde.
- inconvénients : il faut bien séparer l'interface graphique du reste de l'application (mais à vrai dire celà ne fera qu'augmenter la qualité de l'architecture de l'appli) et bien sûr il faut réécrire l'interface pour chaque environnement, ce qui est plus long à programmer et à maintenir si l'interface est amenée à changer.
- exemples : N'importe quel langage "portable" + toolkit spécifique pour chaque plateforme Qt/Gtk/WinForms/Cocoa

Mes conseils :
Il est intéressant de noter que tu peux envisager la deuxième solution en utilisant un toolkit "portable" comme Qt ou GTK que l'on retrouve sur de nombreuses plateforme, ce qui te permet d'obtenir une application dans un premier temps 100% portable même si elle n'est pas intégrée. Tu pourras dans un 2nd temps réécrire l'interface spécifique. Utilise au passage un langage "portable" , soit interprété (Python, Perl, Ruby, etc.), soit utilisant un code intermédiaire (Java, C#).
C++ peut être une solution mais tu devras recompiler pour chaque plateforme, le code binaire n'étant pas vraiment portable, surtout lorsque tu changes d'architecture (par exemple sur Mac).
Par contre je vois pas trop l'intérêt de PHP qui a pour objectif d'être utilisé dans le cadre d'une application web. Je ne te conseillerai XUL et tout ce qui va avec seulement si ton application est là encore orientée web, parcque pour le moment les API sont un peu limité si on sort de ce cadre.
Perso j'utilise Mono et une couche graphique différence pour chaque plateforme.

Je ne dénigre pas le travail du rédacteur, tout le monde à le droit à l'erreur, encore moins celui du modérateur (puisqu'il n'a pas fait son travail, pas besoin de le dénigrer ;-) ) : je constate juste une forte réactivité des news actuellement (ce qui est un point positif à mon goût), et je note au passage le manque de vérifications et donc de sérieux de celles-ci (c'est le point négatif). Peut-être celà est-il dû au concours organisé cette semaine pour gagner un T-Shirt, donc j'espère que les modéros trouveront dès la semaine prochaine un compromis entre qualité et quantité ;-)

Quand je pense qu'un modérateur avait justifié le fait que les news étaient longues à arriver parcqu'il fallait vérifier leur contenu, les liens, etc. C'est vrai que celà remet fortement en question le sérieux des news du site (et donc du site pour les décideurs) ce qui est vraiment déplorable. Enfin apparement il a été choisi la quantité à la place de la qualité...

Nan mais c'est pas sur le "pourquoi" des brevets (ca évidemment ils vont pas dire que c'est pour attaquer le voisin) que je voulais tirer l'attention, mais sur le fait que Microsoft est communiqué clairement sur le fait que ll'utilisation de leurs brevets était gratuit... Donc là encore si quelqu'un a un lien je veux bien.

Explication (tiré d'une interview sur artima.com) :

Anders Hejlsberg: There are several reasons. One is performance. We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method. That's one issue.

A more important issue is versioning. There are two schools of thought about virtual methods. The academic school of thought says, "Everything should be virtual, because I might want to override it someday." The pragmatic school of thought, which comes from building real applications that run in the real world, says, "We've got to be real careful about what we make virtual."

When we make something virtual in a platform, we're making an awful lot of promises about how it evolves in the future. For a non-virtual method, we promise that when you call this method, x and y will happen. When we publish a virtual method in an API, we not only promise that when you call this method, x and y will happen. We also promise that when you override this method, we will call it in this particular sequence with regard to these other ones and the state will be in this and that invariant.

Every time you say virtual in an API, you are creating a call back hook. As an OS or API framework designer, you've got to be real careful about that. You don't want users overriding and hooking at any arbitrary point in an API, because you cannot necessarily make those promises. And people may not fully understand the promises they are making when they make something virtual.

Tiens ca tombe bien je viens de lire celà sur VTR-Hardware.com :

Q : Parlons un peu des brevets logiciels, un sujet sensible depuis quelques mois. Parmi les brevets déposés par Microsoft, citons "le double clic sur les pocket PC" ou encore la "todo list auto-générée". Pourquoi ces brevets ? Est ce en prévision de procès envers d'autres sociétés ?
R : Les brevets logiciels sont un sujet sensible actuellement, particulièrement lorsqu'ils proviennent de Microsoft. Il faut savoir que certains de nos concurrents nous dépassent "haut la main" en termes de nombres de brevets déposés A ma connaissance, Microsoft n'a jamais fait jouer de façon rétroactive ses brevets.
Ces brevets sont à comprendre comme des protections contre d'éventuels procès. C'est le cas, par exemple, du procès Eolas, un procès qui à terme risquait de paralyser non seulement Microsoft mais aussi toute l'industrie en interdisant l'utilisation de plugins dans les applications, et en particulier dans Internet Explorer.
Donc oui, ces brevets servent à nous prémunir de ces procès, et Microsoft a clairement communiqué sur le fait que nous accordons des droits d'utilisations gratuits de ces techniques faisant l'objet de dépots de brevets, comme par exemple les Schémas XML de Office 2003.


Après bien entendu, ce genre d'interview n'a surement aucune valeur juridique (et encore moins morale), mais si Microsoft a vraiment communiqué sur le sujet, il doit bien y avoir une annonce officielle quelque part sur la position de Microsoft vis-à-vis de l'exploitation de leurs brevets... Si quelqu'un a un lien je serais très intéressé.

Je comprend tout à fait ton point de vue. Maintenant voici un extrait d'interview (tiré de VTR-Harware.com) :

Q:Parlons un peu des brevets logiciels, un sujet sensible depuis quelques mois. Parmi les brevets déposés par Microsoft, citons "le double clic sur les pocket PC" ou encore la "todo list auto-générée". Pourquoi ces brevets ? Est ce en prévision de procès envers d'autres sociétés ?

R:Les brevets logiciels sont un sujet sensible actuellement, particulièrement lorsqu'ils proviennent de Microsoft. Il faut savoir que certains de nos concurrents nous dépassent "haut la main" en termes de nombres de brevets déposés A ma connaissance, Microsoft n'a jamais fait jouer de façon rétroactive ses brevets.
Ces brevets sont à comprendre comme des protections contre d'éventuels procès. C'est le cas, par exemple, du procès Eolas, un procès qui à terme risquait de paralyser non seulement Microsoft mais aussi toute l'industrie en interdisant l'utilisation de plugins dans les applications, et en particulier dans Internet Explorer.
Donc oui, ces brevets servent à nous prémunir de ces procès, et Microsoft a clairement communiqué sur le fait que nous accordons des droits d'utilisations gratuits de ces techniques faisant l'objet de dépots de brevets, comme par exemple les Schémas XML de Office 2003.

Si Microsoft a clairement communiqué sur le sujet, je pense qu'il doit y avoir moyen de trouver un communiqué... Enfin en tout cas Microsoft laisse quand même sous-entendre à quoi leur servent les brevets...

Pour les points 3 et 6, seul l'avenir nous dira si c'est rentable commercialement... Microsoft proposera des DRM tant que les majors y croiront et tant qu'ils y croiront ce sera bon pour Microsoft qui vendra des DRM.

Sinon un article à lire : http://www.vnunet.fr/actu/article.htm?numero=12534(...)
Microsoft a l'air bien décidé à "imposer" des standards. Doit-on se réjouir ? Je ne sais pas. Pour les acteurs du marché celà est sans doute positif. Pour le consommateur celà sera sans doute une amélioration par rapport à ce qui est porposé en terme d'interopérabilité actuellement. Par contre pour les droits du consommateur et pour la culture en général...

J2EE c'est Java pour les solutions d'entreprises (comprendre grosses solutions côté serveur) : en gros un serveur d'application te permet d'exécuter des EJB (Entreprise JavaBeans) qui sont des objets Java réutilisables. Le serveur d'application fournit de nombreux services permettant de créer facilement des applicaitons distribuées avec des services de persistance, de tolérance de charge ou encore la gestion des transactions.
Le but est de ne pas avoir à réinventer la roue à chaque fois, les même services étant souvent nécessaire d'une solution à l'autre.

Pour la disquette de boot c'est normal, le kernel 2.6 ne rentre plus sur une disquette :)

Je trouve que critiquer VirginMega dans ce contexte est légèrement déplacé, et déforme grandement la réalité.
Dans une interview, virgin expliquait clairement qu'ils ont essayés de contacter Apple pour pouvoir utiliser leur solution (et ainsi proposer une plus grande compatibilité avec plus de produits du marché), Apple a dénié répondre. Alors je trouve celà entièrement normal qu'ils portent plainte contre Apple qui abuse ici de sa position dominante pour éviter la concurrence directe.
Le problème de l'interopérabilité est par contre toujours présent, il n'existe aucun standard de DRM et c'est bien dommage. Enfin en tout cas Microsoft accepte que son format soit utiliser dans de nombreux périphériques, et une plateforme basée sur le WMA est quand même bien plus "standard" quand vous allez à Confo que la solution d'Apple...
En tout cas je fais un constat : les DRM semblent inévitable pour les acteurs du marché (enfin pour eux), et au lieu de critiquer ce système, nous aurions du plancher sur une solution "libre" et plus apte à devenir un standard, basée sur le ogg vorbis (comme par exemple celà, mais vu le prix de la licence pour un usage commercial (sik) : http://www.sidespace.com/products/oggs/(...))
A l'opposé je me dis que cette guerre de formats des DRM est pas plus mal, que le consommateur de base ne va pas s'y retrouver et j'espère ainsi que ces sytèmes n'auront aucun succès.

chez moi les rpm de firefox n'ont jamais marché correctement (sous ma fedora core 2), alors bon voilà quoi...

Le reste n'est à ce stade que prévisions.
Au lieu de blablatérer sur les brevets et leurs risques pour Mono, réfléchi plutôt pourquoi Microsoft a déposé des standards à l'ECMA et à l'ISO, pourquoi Microsoft a fait Rotor, pourquoi les ingé de Microsoft ne se font pas virer pour avoir bien voulu répondre aux questions des développeurs de Mono, pourquoi De Icaza était invité aux "meetings" Microsoft... Peut-être parcque Microsoft pense que celà peut être bon pour eux que leur techno soit réutilisée. Bref, quand ils disent que la licence sera gratuite, celà va complètement dans ce sens, et j'ai franchement du mal à suivre ton raisonnement... regarde le fond et les intérêts de chacuns plutôt que d'essayer de discréditer une techno parcque t'aime pas Microsoft.