Beretta_Vexee a écrit 1582 commentaires

Heu je parle dans le cadre d'un dev console.
Les interfaces et autres ne sont pas forcement documenter ou cellement celon ce que le fabricant veut bien donner et autoriser, tu te donc obliger d'utiliser ses librairies et ses exemples.

Sur PC la demarche est trés differente.

Michael Simms a donné quelques précisions à ce sujet sur le forum de happypenguin.org, et ce sera clairement propriétaire

Bas si il veulent developper et distribuer sur un autre plateforme de jeu que le PC ( genre n'importe qu'elle console ), ils n'ont pas vraiment le choix non plus, les boites derriére les consoles ne files pas de licence de dev a n'importe qui, et surtout les devkit et leurs code n'est pas ouvert et ne risque pas de l'étre.

Bon apres moi ce que je trouve plus etrange dans cette nouvelle, c'est qu'on y fait un appel aux developpeur uniquement alors qu'il est de notoir que ce qui manque aux jeux libre ou communautére méme les plus abouties, ce sont des graphistes, des musiciens, des modeleurs 3D etc etc ...

OpenBeOS est sous licence MIT si je ne me trompe.
Donc il peut trés bien y avoir recuperation de partie d'OpenBeOS par YellowTab, apres la question sera les 2 parties seront ils gagnient dans cette affaire ?

Perso, je pence que les rares utilisateurs de BeOS qui reste a ce jour son des passionés et qu'ils se tourneront plus volontier vers un OpenBeOS gratos et fait par des passionés, qu'un trucs YellowTabs visiblement peut ambitieux ( c'est pas un bonne chose quand une societée dit ouvertement on va repiquer des partie d'un projet libre qui est loin d'avoir fait ses preuves et qui est encore en dev pour notre produit ) .

Je pence que c'est plus compliqué que tu ne le crois.
QNX a une longue histoire dans l'embarqué, leur noyau qui est un modele de ce qui se fait de mieux dans le domaine temps réel a surment du beneficier de demande et d'addaptation a des systemes et supports specifiques, ils peuvent tous simplement pas se permetre de liberer les sources comme cela sans verifier que celle-ci ne contienne pas des informations ou du code qui n'est pas protegé par une autre licence ou des clauses de non divulgations.

Ouaih mais avec un MMX pour processeur 64Bits on traiterait 4 pixel a la fois ;-)

1) le nForce est un chipset de type north gate, c'est a dire un controleur mémoire assez courant sur les cartes méres pour athlon XP et non une carte graphique ( http://www.nvidia.com/view.asp?PAGE=nforce(...) ). Je fesais reference a son bus de donnée qui est sur 128Bits et non a son bus d'addressage.
Le fait est que l'Opteron et l'Athon 64, ne sont pas qu'un simple extention du x86 avec un bus et des registres sur 64Bits, mais integres aussi pas mal d'inovation comme le controleur hypertransport qui permet des echanges sur 256Bits.

2) un traitement 64Bits sur un processeur 32Bit prendra toujours 2 fois plus de cycle que sur un processeur 64Bits, que ce soit bien supporté ou pas.

3)Le gros intéret d'os Linux 64 bits, c'est l'adressage mémoire.
Oui mais la on parle de processeur, et l'Opteron et Athlon 64 apporte un peut plus que l'addressage 64Bits, et je pence que GCC ne crachera pas sur quelques registre en plus et un cache plus large et plus rapide.
De plus je suis percuadé qu'il y bon nombre d'applications qui peuvent beneficier d'un traitement sur 64Bit, que ce soit en matiére de graphisme, de video ou de la 3D, ( 3 domaine ou de plus l'assembleur a encore sa place et son mot a dire, des filtres on l'on pourrait traiter 2 pixel a la fois etc etc ...), sans parler des applications qui manipules de grands nombres comme le cryptage ou les calculs scientifiques, ( méme si le gain est pas de l'ordre de 100% il est tout de méme enorme ).

De plus des algos sur 64Bits existe mais faute d'architecture populaire en 64bits ils sont sous exploités, je pence par exemple au Tiger Hash, qui déjà plus rapide que le SHA1 et MD5 sur un cpu 32Bit ecrase tous sur un 64Bits.

En fait les cartes nForce sont déjà en 128Bits et normalement l'Hypertransport devrait étre a 256Bits, donc oui c'est pas en relation directe avec les 64Bits ( quoi que le controleur mémoire est en partie integré au CPU avec l'Opteron et l'Athlon 64 ), mais il y a bien gain de Bande passante mémoire. Quand a l'espace mémoire je crois que nos pauvre disque de plusieurs dizaine de giga pourront supporter le surcout de quelque octets des libraries partagés. P.S. 386SX 16->32Bits 386DX 32->32Bits méme chose avec les 486SX

bas le monsieur par du principe que:
Sur une architecture 32Bits classique le plus petit block mémoire fait 32Bits et que donc sur une architecture 64Bit celui-ci fera 32Bits.
Et que donc un simple int prendra la méme place en mémoire qu'un quad word ( 2 Double ).
Hors rien n'est moin sur vue que c'est un processeur 16/32/64 au quel on aura affaire, le passage du bus de 16 a 32Bit avec le 386DX, n'a pas fait exploser la consomation mémoire, je ne vois pas pourquoi cela serait le cas avec le passage de 32 a 64bit, dans le cas d'un processeur purement 64Bit cela aurait été different.

Pour l'espace disque je comprends pas trop moi méme, mais peut étre par t'il du principe que les cluster seront de 64Bits aussi, ce qui est un peut ridicule vue que sur n'importe quel systéme avec de gros capacité les cluster font déjà souvent plus de 64Bits mais bon ...

Apres pour ce qui dise que le 64Bit est sans interet sortit de l'addressage mémoire qui passe la barre des 4Go, c'est un peut reducteur, la bande passente mémoire va sacrement augmenté et ce méme pour les applications 32bit si le processeur gére bien le tout, de plus le domaine de la video, de la 3D et du multimedia en general font déjà largement usage du MMX et SSE, ce qui prouve bien qu'il y a bien une utilité a des operations sur 64 voir 128bits.

Je pence d'aillieur qu'on peut tout affait rapprocher le x86-64 du MMX et du SSE, tout le monde reniait leur utilisé au debut et maintenant ils sont trés largement addopté, de plus le x86-64 apporte des inovations nettement plus importante que le MMX et SSE

Wmware est un virtualiseur, il ne peut pas fonctionner sur autre chose qu'un x86, ce n'est pas un emulateur comme VirtualPC.

Si tu vire le nom des developpeur tu contreviens a la proprietée intelectuelle des auteurs, et donc annule toute legitimité a la licence emploiée qui a été choisie par l'auteur du code.

Linus torvald a choisit de developper son soft sous GPL, c'est parce que linus l'a choisit que son code est sous GPL, et non parce qu'il a la mention de la GPL en debut des sources.
Si tu vire la reference aux auteurs originaux, c'est de l'expropriation et tu peux te torcher avec la licence.
BSD, MIT ou autre ne veulent pas dire domaine publique, ce code appartient toujours a quelqu'un le quelqu'un a simplement donner divers autorisation via une licence pour que l'on puisse utiliser son code librement.

Le rapport avec Intel ?
Ces 2 bourdes ( qui ne sont pas plus grosse que d'autre de la par de personne bien plus eminante en la matiére ) nous sont dut a Bill gate et non a un ingenieur d'Intel.

C'est quoi ce copier/coller de la bréve de Clubic.com ?

http://www.clubic.com/n/n7984.html(...)

Demontrer la puissance de sed sur une volume important de code source sous licence BSD.

A par ca aucun.

il y a des gens qui utilise SSL pour autre chose que de l'internet, faut pas voir que son petit interet.

EAL4 en gros c'est que le system est stable en condition de fonctionnement normal ( hors attaque donc ). En gros ca veut dire que le systeme est bon pour les missions de prod, voir critique, en general ce sont les switch et equipement reseau qui beneficie de cette certification. Les niveaux EAL sont definie par un cahier des charge et une etude du systeme a evalué, par exemple le niveau EAL 5 demande pour le test que chaque fonction de base du system soit modulaire et qu'elle puisse étre testé separement, et ainci de suite, le niveau vont de 1 ( verification vite faite des principes mise en oeuvre sur le papier ) a 7 ( etude en profondeur de tous le system en passent pas son evironement de dev, la resistance aux attaques, la resistance a la vulnerabilité d'un des modules etc etc ... ).

AOL ?

Je confirme, Pheonix c'est le terrein de jeu de tout un tas de developpeur Mozilla, qui teste des trucs et qui se lache avec Pheonix sur des trucs qui ne sont pas vitale ou plannifié pour Moz, ou qui pourrait étre problématique celon une certaine vision "commerciale" de Moz.

Comprendre, les ingés de Netscape font un travail enorme sur Mozilla et c'est bien en contre partie il traine un heritage d'interface utilisateur et de look&feel trés classique, pheonix se veut plus novateur dans ce domaine et surtout plus rapide, dans le principe je pence qu'on pourrait le comparer a Safari d'apple, leger rapid et simple.

C'est plustot saint de voir que ce fork survie trés bien en // de moz et que les 2 profite l'un de l'autre.

Toi ta rien comprie.

Je decrie le fonctionnement de SCP/palladium pas de TCPA !!!

TCPA en gros c'est un coprocesseur genre carte a puce, USIM, il s'occupe absolument pas du CPU, des tache ou de la gestion mémoire, c'est une puce d'extention cryptographique standardisé pas grand chose de plus.

Puisqu'on parle de l'embarqué, le F-cpu integret'il des fonctions d'economie d'energie ou de variation de frequence ?

Est il possible de predire une consomation moyenne du F-cpu sans processeur physique ? ( en fonction de la finesse de gravure bien entendut )

La
http://www.mail-archive.com/cryptography@wasabisystems.com/msg02579(...)
et dans le reste de la file
http://www.mail-archive.com/cryptography@wasabisystems.com/msg02581(...)

On sait peut de chose de SCP/Palladium, mais toutes les personnes qui si sont penchés sont d'accord pour dire que pour faire ce qu'il decrive cela passe par la mise en place d'un nouveau niveau de prioritée mémoire superieur ou au moin egual a l'OS, le fameux Ring -1 ou Hyper system comme il est dit dans l'un des communiqué de MS ( je crois que le terme est reprit par l'ingenieur de AMI interviewé sur /. au sujet de SCP et TCPA ), méme si apres le reste des fonctions peuvent étre exporté vers un coprocesseur ou une autre puce, cela implique une modification non negligable de l'architecture mémoire du processeur et donc du MMU dont c'est le travail de gerer cela.

TCPA quand a lui ne s'occupe absolument pas de la mémoire du CPU.

la GPL dans le cadre du projet F-CPU ne touche que le code VLD, les fondeur peuvent trés bien produire des puces equipés sans violer la GPL.

Apres je perciste a pencer que le TCPA/LaGrande, qui apporte pas mal (plus) des fonctions des cartes a puces peuevent étre trés utiles, et si de plus elles sont bien consue elles n'ont pas grand chose a perdre a étre transparente ( méme si personne ne peut verifier effectivement que le code donné est bien celui utilisé ... ).

Apers Palladium/next-generation trucs je trouve le principe stupide, et liberticide.

P.S.
TCPA n'est qu'un coprocesseur, Palladium/Fritz sera vraisemblablement une extention de la MMU du processeur coupler avec des fonctions de protection mémoire forte, et d'un systéme de certificat et de confience.

Hum, il fait plus grand chose sans FFmpeg le pauvre Gstreamer a ce moment la, livrer Gstreamer sans FFmpeg c'est comme livrer Mplayer sans libavcodec, c'est inutile et absurde.

Quand Templeet sera debuggé et que les signature auront fait leur retour...

Gstreamer utilise lui aussi FFmpeg et donc Libavcodec, donc le question reste entiére ? Visiblement celon la page de FFmpeg presque tous les projet video qui decode de l'AVI et support des codec non natif utilise Libavcodec ou FFmpeg...

bon pour libavcodec je connais pas trop mais je vieux bien qu'il y ait un probléme de licence mais c'est quoi le probléme avec FFmpeg ( si ce n'est que lui aussi utilise libavcodec ) ?