TImaniac a écrit 6423 commentaires

bref rien de neuf sous le soleil et je vois vraiment pas l'interet de la chose.
Ben si, montrer que question productivité on peut faire un truc en 4 jours au lieu de tout recoder en 6 mois. D'où l'intérêt de supporter plusieurs langages sur une même plateforme.

Et ce que l'on remarque c'est que Quake2.NET qui est ecrit en C n'est pas aussi rapide que le Quake2 original
Nan nan nan.
Si tu compares vraiment avec l'original, Quake2.NET en C est plus rapide que l'original, parcque l'original n'avait pas les optimisations P4. Si on recompile les 2 avec le support des optimisations p4, c'est là qu'on retrouve l'écart à 85%, ce qui paraît logique étant donné qu'il y a la machine virtuelle qui tourne dessous.
et que la version Java est aussi rapide que Quake2 en C sous .NET !!!
Nan, comme je l'ai dit c'est incomparable, pour plusieurs raisons :
ils ne disent pas quelles optimisations ils ont "activé" à la compilation, ce qui fait que si ca se trouve ils comparent avec la version original du jeu non recompilé, auquel cas Quake2.NET va plus vite que l'original.
Ensuite le moteur a été complètement réécrit, si on suit les différentes version sorties, ils ont mis du temps avant de réussir à obtenir des perfs similaires, ils ont du passer un bon bout de temps à optimiser, suffit de voir leur tableau.
De toute façon je trouve ce genre de bench pas vraiment utile, puisque le plus gros du travail est envoyé à la carte graphique, ce n'est alors si .NET ni Java qui font le taf. Ce qui a ralenti Java, c'est les nombeux appels à travers JNI qui font tout ramer, ils ont du optimiser celà le plus possible pour éviter les échanges entre leur couche bibliothèques qui utilise OpenGL et le moteur en Java.

JE vois déjà ta réaction : oui mais y'a du vert au dessus de hardware !
Et alors ? si le schéma l'a mis là ce n'est pas pour autant que y'a un lien direct entre les 2...
Suffit de voir où est la JVM... tout ce qui se trouve à droite devrait être au dessus de la JVM, sinon celà ne peut pas être en Java... Enfin je suppose que le schéma est plus "lisible" comme ceci, ils ont voulu faire l'analogie avec les fonctionnalités des kernels.
Y'a un n-kernel dont le but est d'effectuer (comme tout kernel) l'abstraction matérielle, bref, cet OS est en grande partie en Java si on prend la définition Windozienne d'un OS (avec les classes et tout), mais si on prend la définition Unixienne, y'a la moitié en rouge, la moitié en vert, et la partie eu rouge montre bien qu'on ne peut pas tout faire en Java.

Oh ben dis-donc c'est quoi cette partie toute rouge ? de l'assembleur ? tiens donc ! Ca doit être nouveau en Java ;-)

Non non, c'est bidon, tout ce qui touche le matos n'est pas géré en Java.

En même temps ils ont du tout recoder alors bon voilà quoi...
Si les textures doivent être les originaux, mais les textures sont elles sous GPL ou sous un autre type de licence ?

Euh, alcohol lit les images de logiciels Windows...
Ces formats d'images n'apportent en général pas grand chose, si ce n'est des informations supplémentaires sur les subdata par exemple, ou pour le format alcohol des conneries pour simuler les erreurs disques afin de contourner des protections... sinon rien ne vaut un bon vieux .iso.

Contourner des protections sous Linux est idiots :
- il n'y a pas de logiciels linux protégés de la sorte,
- les formats windows contenant les infos pour passer la protection sont des CD de soft sous Windows, donc vois pas l'intérêt.

Après dis oti bien que sous Linux la plupart des softs utilisent cdrecord en arrière plan pour effectuer la gravure et mkisofs pour créer des isos. Donc ils vont tous pouvoir plus ou moins faire la même chose.

Après certains formats iso Windows sont parfois de simples iso renommé avec une autre extension.

Ah oui, j'oubliai, là au moins on peut vraiment vérifier la perte de peformance entre la version native et la version portée, c'est le même code qui est utilisé :
#if _MANAGED
"Quake II (managed)",
#else
"Quake II (native)",
#endif

Le même genre de portage supermégautile : Quake II .NET
http://www.codeproject.com/managedcpp/Quake2.asp(...)

Décidemment y'en a qui n'ont rien à foutre :)

Pour ceux qui veulent pas troller :

"Running Quake II.NET in the timedemo test indicates the managed version performs about 85% as fast as the native version"

bizzare comme chiffre ;)

Pour ceux qui veulent troller :

Project UNIX name: jake2
Registered: 2004-06-04 00:59
jake2 jake2-0.9.3 September 7, 2004

Quake 2 .NET :
Porting the C code to native C++ took about 4 days, and porting to managed C++ took another day.

En fait la plupart des distributions récentes intègrent désormais le noyau Linux 2.6 qui a le gros désavantage de ne plus tenir sur une disquette :-/ C'est pourquoi en général ils refilent une image de boot pour CD ou clé USB, mais encore faut-il que ta carte mère veuille bien booter dessus...
Sinon une autre méthode :
Si tu as déjà un Linux d'installer, arrange toi pour booter sur les .iso directement sur le disque dur (je te laisse googeuliser, j'avais réussi pour ma fedora core 2 en tout cas)

J'oubliais, pour demonter :
umount /mnt/usbkey

et pour plus d'infos, notamment si ma méthode marche pas (le support USB n'est peut être pas activé) :
http://lea-linux.org/hardware/cleusb.html(...)

sinon poses des questions ;)

Bonjour,

l'opération de montage consiste à "insérer" ta clé USB Dans le système de fichier à un emplacement précis : le point de montage. Par principe mon met ces points de montages dans /mnt , par exemple pour toi /mnt/usbkey par exemple. il te faut donc créer un dossier vide dans /mnt que tu appeleras usbkey. Tu ne peux faire cette opération qu'en tant qu'administrateur, c'est à dire sous le compte root.
Maintenant que ton dossier /mnt/usbkey existe, il te faut effectuer le "montage" dans le système de fichier, bref faire pointer /mnt/usbkey directement sur ta clé. La commande qui fait celà est "mount". Voici le squelette de la ligne que l'on tappe habituellement :
mount -t vfat -o user,sync /dev/xxx /mnt/usbkey
"-t vfat" indique le type (-t) de fichier présent sur ta clé, c'est probablement du FAT Windows, d'où le vfat.
"-o user,sync" c'est les options, ici on veut que tous les utilisateurs (user) autre que l'admin (root) puisse accéder à la clé. "sync" indique qu'on veut que les fichiers soit synchronisé, cad que quand tu fais une modification sur la clé, ajouter un fichire par exemple, l'opération s'effectue immédiatement, ce qui t'évite de faire un "démontage" ou en tout cas en diminue grandment les conséquences si tu oublies de le faire :)
ensuite on retrouve 2 arguments :
"/dev/xxx" : c'est le chemin indiquant l'emplacement physique de ta clé. (/dev pour device, cad périphériques). J'ai mis ici xxx parcque celà peut changer suivant la version de Linux que tu as. Généralement c'est "sda" ou "sda1", "sdb", sdb1", fait plusieurs essai tu verras bien :)
"/mnt/usbkey" indique bien entendu le point où tu as effectuer le montage.

Voilà :-)
Amuse toi bien

Après tout dépend de la distribution Linux que tu as : RedHat ? Mandrake ? etc.

une adresse qui se finit par une virgule, même avec un espace derrière, est valide. Donc impossible pour Templeet de détecter si l'url doit se finir avec la virgule ou alors si c'est une virgule de la phrase... Templeet est pas intelligent non plus.

oué enfin le résultat est que les logiciels qui rippent et encode dans un autre format (DivX & Co) n'ont comme par hasard pas l'autorisation nécessaire du DVD Forum :) Donc pour l'utilisateur le CSS doit être contourné pour pouvoir faire une "copie" sans graveur DVD...

Ben la différence avec Flash c'est que le views de Macromedia est 100% copatible avec la techno Flash (encore heureux), alors que même l'Adobe SVG Viewer n'est pas compatible avec toutes les spécifs SVG...

Y'aurait pas une connerie du style :
Windows, il change l'heure du bios lors des changement "été/hiver"
Debian fait soit pareil, soit change l'heure qu'elle affiche, cad l'heure du bios+1 ?
Me semble en tout cas qu'à l'installe Debian m'avait posé la question... en cas de reboot sous Windows, il doit forcement en résulter un décalage dans le 2ème cas, sauf si celui-ci est configuré pour se synchroniser sur un serveur de temps...

Tu peux aussi envisager iFolder de Novell par exemple.

Bof je vois pas ou est la difficulte.
Ben si je viens de le dire, les changements était vraiment perceptibles pour le consommateur : la qualité CD, la taille du média, la simplicité d'utilisation du lecteur, l'absence de dégradation du support, tout celà permis de passer facilement au support CD.

Maintenant tu veux qu'ils inventent quoi ?

Tu dis que celà va arriver dans 5 à 10 ans, effectivement je donne encore à peu près ce temps de vie pour le CD audio. Cependant je me pose des questions sur l'intérêt d'avoir un remplacant... La mode est aux formats numériques sur des types de support multiples, je penses pas qu'il sera utile d'avoir un support standard dans 10 ans...

http://linux.rice.edu/installfest/howto/post_install_redhat9.html#a(...)

dis moi t'avais la flemme de taper "apt-get redhat 9" dans google ? ;)

Avec le deploiement de .NET et surtout l'arrivee de Longhorn les pierres vont etre posee.
C'est quoi le rapport ? NGSCB & Co, c'est une techno basé sur une compatibilité matérielle complètement indépendante de .NET ou même avec LongHorn : je suppose que Microsoft pourra intégrer celà à Windows XP de la même manière.

Pour la méthode de vérification des albums; je ne sais pas comment cela fonctionne mais je ne sais pas non plus comment va évoluer le format CDROM si une telle loi été adopté au USA...
Ben, il faudrait qu'ils innovent ouachement pour justifier l'existence d'un nouveau format de CD Audio... T'imagines le nombres de périphériques à changer ? C'est tout bonnement innimaginable ! Du 33t au CD Audio il y a eu un pas de géant au niveau de la qualité et de la longétivité du média, mais là je vois difficilement comment faire gober la pillule aux consommateurs... C'est pour celà que je ne penses pas que cette loi vise les supports ou les DRM, mais bel est bien les réseaux de p2p : ceux-ci ne sont pas contrôler par les majors, il est donc important pour eux de les interdire, alors que les DRM ou les format de CD sont sous leur maîtrise.

On peut plus facilement aux gens d'utiliser quelque chose (ici le p2p) que de les obliger à utiliser quelquechose (DRM). Encore moins de façon autoritaire à travers une loi !

la meilleure solution consiste sans doute à installer apt-get ou yum sur ta RedHat par exemple :)

Je suis d'accord avec ce que tu expliques, cette loi semble viser les moyen d'échange et/ou de copies, mais ne vise pas à obliger l'utilisation de DRM, ce choix d'utilisation ou non de DRM sera laissé aux fournisseurs de contenu c'est tout.
Tu dis que WMP est capable de reconnaître un contenu protégé... WMP ne fait que comparer certains aspects comme la durée des pistes, ce n'est pas ce que j'appelle une méthode fiable... Surtout offline. Il faut bien pouvoir rendre la lecture d'un CD possible même offline, sinon il y a des consommateurs qui vont râler ! Et pourquoi pas obliger l'autoradio à s'identifier par GPS tant qu'on y est ?

Enfin de toute façon je crois que l'article l'explique très bien, cette loi vise avant tout les réseaux de p2p.

Il y a d'autres lois qui régissent l'utilisation des DRM, de toute façon le CD Audio est le parfait exemple de support sans DRM qui devrait être interdit si on te suit dans ton idée ;)

Pourquoi ?
Cette loi obligement nullement au créateur d'un contenu numérique l'utilisation de DRM... Cette loi propose d'interdire les moyens d'échanges de contenus sous Copyright en qualifiant l'utilisateur de tels moyens de criminels, c'est tout...
Si tu veux continuer de parler des DRM tu sais où ça se passe ;)

C'est pas vraiment le fait qu'un PC puisse potentiellement être ciblé par cette loi qui me fait peur, c'est plutôt cette enième tentative de culpabiliser l'utilisateur du p2p : "Maintenant vous êtes carrement un criminel !"

Ah quand la chaise électrique pour avoir téléchargé le dernier britney spears ?