La musique ne s'entends pas qu'avec les oreille, mais avec tout le corps, la richesse spectrale est importante a ce niveau (enfin, un technoman invétéré ne doit sans doute pas comprendre cela, qui est très largement reconnu dans les milieux audiophiles musique classique)
oula...
je suis a peu pres certain de ne pas me tromper en avancant que la tek ratisse tres large dans la bande spectrale, comme tu dis..
de l'infrabasse aux hautes frequences, tout y passe.
Pose toi devant un gros mur de son en free pour t'en rendre compte.
Ou parles en avec un medecin, il devrait te confirmer ce que je te dis.
rien a redire sinon, je voulais juste relever le point precedent
Oui, exactement.
Et la remarque sur le fait que ça ne s'entends pas qu'avec les oreilles : devant un bon mur d'enceintes, les basses qui font vibrer le corps entier sont aussi pour beaucoup dans l'écoute de cette musique.
A ma connaissance, c'était un simple checksum. Il y aurait eu un md5 à la place, la première tentative de crackage n'aurait pas été possible.
Il me semble que c'était plutôt un système à clé publique/privée. Le kernel sur lequel la console boot est signé par microsoft, et la console contient la clé publique pour vérifier l'origine du kernel. D'où le problème de booter avec linux dessus.
Le buffer overflow n'a pas servi à découvrir la clé (qui est assez grande pour être incassable aussi, 2048 bits il me semble) mais à executer un bout de code qui charge le kernel linux en mémoire (tient, yaurait eu un patch NX pour la xbox ils auraient été dans la merde). Mais la console devait d'abord booter normalement, et puis executer le jeu dont on a trouvé le buffer overflow.
Houla, ya beaucoup mieux pour ça (et plus "propre") : depuis vim, un coup de ":make" pour lancer la compil (on peut personnaliser la commande avec ":set makeprg=...", et mettre par exemple "latex \!" à la place; par défaut c'est "make" tout court), puis ":cc" pour voir l'erreur (on arrive sur la première erreur directement après un ":make"), et ":cn" pour passer à la suivante. C'est vraiment très utile. Pour le reste voir ":help quickfix".
Cela fait quelques temps déjà (1 an et demi) que le ventilateur de ma GeForce 2 Pro est en rade.
"Content" de savoir que je ne suis pas le seul à avoir ce problème avec cette carte dont le ventilo est d'une solidité et d'une fiabilité .... désastreuse. Pareil que toi, montage d'un autre ventilo avec 2 bouts de ficelles ...
Ensuite : citez donc un debugger qui sait charger un binaire de 100mo, montrer tous les types montrables, faire du hotfixing et faire suivre les breakpoints avec les modifications du code, montrer le code de manière correcte etc. Puisque c'est de sa faute s'il arrive pas à bosser.
gdb ... pour Mac OS X !! :)
il gère :
- les headers précompilés
- tous les types du système (enfin en Objective-C dumoins)
- le hotfix
- suivi des breakpoints avec la modif du code
- affichage correct du code
- il plante peu (enfin c'est surtout XCode qui plante ...)
- et plein d'autres trucs
bon pour les binaires de 100Mo je sais pas, mais comme dis plus haut, faut être un peu neuneu pour débugger avec toutes les libs en statique.
Bon ok, tout ca c'est dispo uniquement en utilisant XCode d'Apple, qui est un gros truc proprio qui n'est pas prêt d'être libre. Mais tout ça est géré dans le fond par gcc & gdb !
Deuxième truc, je sais pas si c'est possible de faire du hotfix en ligne de commande, ni si tout ça est faisable autrement qu'en codant en Objective-C ...
Vous allez me dire "mais tout ça c'est codé par des ingés de chez Apple, personne aurait pu faire ça dans le libre". Certes, il se sont bien démerdés, et en plus tout ce code est libre comme tout le reste de gcc, mais je pense qu'un jour ou l'autre on l'aurait eu par des contributeurs bénévoles. Un peu moins rapidement, peut-être.
On en arrive à des situations ubuesques comme celle de Microsoft qui arrive à breveter le multibureau avec comme exemple des captures d'écrans de KDE !
Je voudrais juste faire remarquer (si ce n'a pas déjà été fait) que ces captures sont là pour illustrer les applications déjà existantes; c'est écrit dans le texte du brevet (oui, il faut l'avoir lu avant pour savoir ...).
Le brevet porte sur le desktop switcher (enfin le truc qui donne un aperçu des bureaux) : La capture de KDE 1 (où on ne voit que le nom du bureau) montre qu'on ne voit pas les fenêtres des desktops, la capture de Gnome montre qu'on voit les fenêtres en petit mais pas leur contenu (juste un carré); eux, ils justifient leur brevet par le fait qu'il affichent le contenu de la fenêtre dans leur desktop switcher.
Mais cela n'empêche pas qu'Enlightenment l'a fait bien avant eux, mais ça bien sûr, ils n'en parlent pas ...
Et aussi que ça n'est pas si innovant de n'améliorer un truc que très légèrement (d'ailleurs je crois que c'est un motif de refus du brevet en france si on se base sur un truc déjà existant et en ne l'améliorant que très peu)
[^] # Re: Et ca ne s'arrangera pas de sitot.
Posté par benoar . En réponse à la dépêche UFC-Que choisir déplore le manque d'interopérabilité dans la musique en ligne. Évalué à 1.
Oui, exactement.
Et la remarque sur le fait que ça ne s'entends pas qu'avec les oreilles : devant un bon mur d'enceintes, les basses qui font vibrer le corps entier sont aussi pour beaucoup dans l'écoute de cette musique.
[^] # Re: Sur le DRM ...
Posté par benoar . En réponse à la dépêche Le DRM ne fonctionne pas, et on le savait.. Évalué à 2.
Il me semble que c'était plutôt un système à clé publique/privée. Le kernel sur lequel la console boot est signé par microsoft, et la console contient la clé publique pour vérifier l'origine du kernel. D'où le problème de booter avec linux dessus.
Le buffer overflow n'a pas servi à découvrir la clé (qui est assez grande pour être incassable aussi, 2048 bits il me semble) mais à executer un bout de code qui charge le kernel linux en mémoire (tient, yaurait eu un patch NX pour la xbox ils auraient été dans la merde). Mais la console devait d'abord booter normalement, et puis executer le jeu dont on a trouvé le buffer overflow.
[^] # Re: vim
Posté par benoar . En réponse au journal Votre commande favorite. Évalué à 3.
[^] # Re: Monitorer une carte nVidia...
Posté par benoar . En réponse à la dépêche Nouvelles versions des pilotes ATI et NVIDIA pour GNU/Linux. Évalué à 1.
"Content" de savoir que je ne suis pas le seul à avoir ce problème avec cette carte dont le ventilo est d'une solidité et d'une fiabilité .... désastreuse. Pareil que toi, montage d'un autre ventilo avec 2 bouts de ficelles ...
[^] # Re: c'est quand même formidable
Posté par benoar . En réponse au journal Linux : la plus vaste blague de l'informatique. Évalué à 1.
gdb ... pour Mac OS X !! :)
il gère :
- les headers précompilés
- tous les types du système (enfin en Objective-C dumoins)
- le hotfix
- suivi des breakpoints avec la modif du code
- affichage correct du code
- il plante peu (enfin c'est surtout XCode qui plante ...)
- et plein d'autres trucs
bon pour les binaires de 100Mo je sais pas, mais comme dis plus haut, faut être un peu neuneu pour débugger avec toutes les libs en statique.
Bon ok, tout ca c'est dispo uniquement en utilisant XCode d'Apple, qui est un gros truc proprio qui n'est pas prêt d'être libre. Mais tout ça est géré dans le fond par gcc & gdb !
Deuxième truc, je sais pas si c'est possible de faire du hotfix en ligne de commande, ni si tout ça est faisable autrement qu'en codant en Objective-C ...
Vous allez me dire "mais tout ça c'est codé par des ingés de chez Apple, personne aurait pu faire ça dans le libre". Certes, il se sont bien démerdés, et en plus tout ce code est libre comme tout le reste de gcc, mais je pense qu'un jour ou l'autre on l'aurait eu par des contributeurs bénévoles. Un peu moins rapidement, peut-être.
Alors bon, arrêtez de cracher sur gdb ...
[^] # Re: Hummm cela cache aussi la brevetabilite des algo mathematiques
Posté par benoar . En réponse à la dépêche Brevets logiciels : analyse de la directive votée par le Conseil de l'UE. Évalué à 7.
Je voudrais juste faire remarquer (si ce n'a pas déjà été fait) que ces captures sont là pour illustrer les applications déjà existantes; c'est écrit dans le texte du brevet (oui, il faut l'avoir lu avant pour savoir ...).
Le brevet porte sur le desktop switcher (enfin le truc qui donne un aperçu des bureaux) : La capture de KDE 1 (où on ne voit que le nom du bureau) montre qu'on ne voit pas les fenêtres des desktops, la capture de Gnome montre qu'on voit les fenêtres en petit mais pas leur contenu (juste un carré); eux, ils justifient leur brevet par le fait qu'il affichent le contenu de la fenêtre dans leur desktop switcher.
Mais cela n'empêche pas qu'Enlightenment l'a fait bien avant eux, mais ça bien sûr, ils n'en parlent pas ...
Et aussi que ça n'est pas si innovant de n'améliorer un truc que très légèrement (d'ailleurs je crois que c'est un motif de refus du brevet en france si on se base sur un truc déjà existant et en ne l'améliorant que très peu)