benoar a écrit 4244 commentaires

Tu as une démo?
Car je vois que l'option "range" du protocole HTTP dans ton idée, celui-ci contient un nombre d'octets (donc inutile pour la vidéo, ou on demande un timecode vu qu'on ne sait pas le nombre d'octets) et celui-ci sauterait le header du fichier, donc fichier illisible que ce soit MP4 ou OGG (donc inutile aussi). Impossible de désigner donc un endroit en HTML.

Tu l'as trouvé toi-même plus bas : il va lire l'index (justement avec un Range, comme l'index est souvent à la fin) puis peut facilement trouver l'offset en octet pour aller à la seconde s, toujours avec Range.

Comment? démo demandée aussi.

Oui, c'est un player standalone, mplayer pour ne pas le citer. OK, j'ai un peu triché.

Ah... Oui, forcément, du coup tu perds tout l'intérêt du web :
- Toi tu peux sauter à un endroit (ton lecteur a lu le header, à l'index, donc sait faire la traduction timecode vers octets), mais la page web ne peut pas dire d'aller automatiquement à tel timecode voir le truc intéressant. Et c'est justement la fonction qui manque! Que ce soit en HTML ou ta solution.
- Il te manque alors toute l'intégration de la vidéo dans la page web, super...

Oui, j'ai rien du tout d'intégré, mais ça me va très bien (oui, je dois représenter 0,00001% du "web").

Désolé, mais la, c'est vraiment ne pas vouloir comprendre le besoin auquel répond Flash et la critique sur HTML5 faite par les gens faisant le web, tu répond avec un truc qui a encore moins de fonctionnalités que la valise video actuellement.

Effectivement, ma critique n'était pas vraiment sur "comment avoir un player bien intégré". C'était plutôt que ça me fait rire qu'on se prenne la tête sur des problématiques qui ont été réglées de manière standard depuis belle lurette. Alors certes, c'est pas intégré joliment à ton browser, mais moi ça couvre mon besoin (oui, je sais, je représente 0,00001% ...) et le fait mieux que Flash et HTML5 réuni. Et tout ça depuis des années, bien avant que ces deux technos soient inventées.

PS: ah si maintenant je me rappelle d'un site où tout marche bien comme ça : http://trailers.apple.com
Player bien intégré (contrôles en HTML), flux standard (H264), on peut seeker comme on veut, et on a du fullscreen qui marche nickel. Tout ça sans faire lagger la machine, et en plus on peut copier facilement l'URL pour download ! Mais comment ce miracle est-il possible ? Balise object. Oui, bon, je t'en ai déjà parlé, je radote même beaucoup ici avec ça, ça dépend du player hôte, blahblah, etc. Mais en gros ça marche sur ma Debian et sur les Mac (je suppose, mais bon, j'en suis à peu près sûr) ce qui couvre déjà un certains nombre de personnes. Mais non, on va plutôt inventer un nouveau standard qui ne fait même pas la moitié de cette balise parce que ça serait trop facile de faire évoluer un standard qui existe déjà.

Je ne comprends pas pourquoi tu es moinssé, il y a à mon avis une partie de vrai dans ce que tu dis.

Avec HTML5 et WebM, tout le monde s'est mis à cracher sur Flash comme si d'un coup ça devenait une technologie de merde. Moi, j'en suis convaincu, mais à ce que je sache, tout le monde continue d'utiliser Flash sans vergogne. Donc quelle est votre crédibilité ? Adobe a dû se fâcher contre Google après leur soutien trop appuyé à HTML5, et avec l'argument qu'ils ont, c-à-d la technologie Flash dont tout le monde dépend encore énormément, Google a décidé de revoir un peu sa critique de Flash (voire retourner sa veste).

Voilà, sinon, en passant, moi j'ai un player H264 libre, j'habite en Europe ; je peux également sauter à n'importe quel endroit du flux en HTTP grâce à la superbe option Range de ce protocole qui existe depuis 11 ans ; et je peux faire du plein écran sans problème, sans que des pubs ne puissent me pourrir juste au dessus.

Tout ça grâce à la simple extension Unplug qui nous fournit ce que n'importe quel site devrait faire quand il diffuse une vidéo : un lien hyper-texte direct vers la vidéo ! Quelle révolution, le lien hyper-texte !
D'ailleurs, en parlant de protections, Youtube vient de ré-interdire aujourd'hui même le téléchargement de vidéos par ce même lien (la seule solution pour moi pour lire une vidéo) avec un bon 403 Forbidden, comme ils avaient essayé il y a quelques mois. À l'époque, ils étaient revenu en arrière après une semaine. Vont-ils continuer plus longtemps cette fois-ci ? (je suppute qu'un bidouillage de User Agent devrait arriver à contourner cette protection, mais ça me fait chier)

Tiens, je viens de lire ya 30s la signature de khane<, je je trouve plutôt bien à propos :
Administrateur système : Personne ne sait ce qu'on fait, tout le monde sait quand on ne le fait pas.

Iceweasel 3.5.10. Et le JIT n'est pas activé puisque ça n'est pas encore implémenté en dehors des bêta pour amd64.

Moi je suis juste allé voir la page perso du monsieur qui a posté cet article ...

Chez moi :
* Python : 23,47s
* Javascript : 42s (en gros)

Je suis en amd64, donc sans JIT, c'est ça qui doit faire la différence ...

Ce qui me fait drôle dans cette histoire, c'est de recevoir une réponse contenant une adresse non routable sur internet. Et cette adresse vient, justement, d'internet (puisque je loue le fait d'être connecté à internet). Je veux bien que ce soit leur réseau, mais je ne suis _jamais_ sensé recevoir de telles adresses (sauf si j'ai un VPN par exemple, mais là ce n'est pas du "internet").

Je dirais que c'est tout à fait classique : ils ont des machines en interne chargées de router le traffic de leurs abonnés, mais qui n'ont pas besoin d'avoir une IP publique (i.e. elles ne sont accédées par Orange que depuis son propre réseau). Elles peuvent router du traffic à destination d'IP publiques sans problèmes, elles ont les routes pour. Et toi, tu ne verras normalement jamais leur adresse nulle part, et effectivement tu as raison de filtrer tout ce qui est non routable. Sauf que là tu as explicitement fait un traceroute, qui doit être la seule commande où tu verras cette machine, mais tu l'as bien demandé : ce 3è hop vient d'un paquet que t'as envoyé avec un TTL de 3, bah là machine fait ce qu'une machine normale fera : _elle_ te renvoie un paquet provenant de son adresse disant que le TTL est arrivé à 0.

En tous cas, je ne vois pas en quoi cela a pu poser un problème à ton réseau, normalement elle n'interfère en rien. Ce serait bien d'avoir le détail pour qu'on comprenne.

Sauf qu'en testing, tu peux attendre les corrections pendant des plombes. Faire rentrer un paquet dans testing est beaucoup plus long que dans sid. C'est bien pour éviter de casser les choses en allant trop vite, mais quand testing est cassée (à cause d'un bug qu'on n'a pas vu dans sid), elle met aussi longtemps à être réparée ...

D'ailleurs, à propos d'import et d'anciennes données, j'espère qu'il est aussi prévu de garder les anciennes URLs ? (au moins pour les anciens articles) C'est faisable pas trop difficilement en RoR ?

Netcraft nous indique qu'avant le squattage, le serveur était http://66.35.39.65/trac/ ...

Ta description me fait un peu penser à XCode en faisant de l'Objective C. Bon, ça doit pas être aussi haut niveau que tu l'espérerais, mais c'est pas mal quand même. J'avais particulièrement aimé le debug à la volée avec rechargement de code à chaud (sans redémarrer l'appli, bien sûr) qui a été "intégré" (i.e. renvoyé upstream) à gdb juste après, il me semble (puisque XCode utilise justement gdb). Même si les IDE "modernes" genre Eclipse doivent faire pareil aujourd'hui (mon expérience d'XCode date de quelques années déjà, il a du encore s'améliorer depuis).

Exactement pareil, dans Iceweasel, ça marchait jamais, je m'arrachais les cheveux. La solution parcellite ci-dessus me dépanne bien !

Rho putain j'ai espéré trouver un truc du genre depuis longtemps, et je n'avais jamais vu cette option !

Sur des petites bécanes qui n'ont pas flash, rien que l'affichage de cette barre faisait lagger à mort FF car la barre s'affiche en slidant pixel par pixel, faisant réafficher la page un pixel plus bas à la fois, opération super lente sur un vieille bécane ... Merci !

L'utilité étant d'avoir toujours la même longueur / syntaxe de chaîne (plus facile à parser/stocker).

Avoir toujours la même "syntaxe" d'adresse est le but de la "norme" dont je parlais : elle expliquaient comment compresser l'adresse de manière à ce qu'une adresse donnée n'ait qu'une et une seule forme. Le truc était fait dans l'optique de comparaison d'adresse. Ça permet d'avoir une forme canonique (j'avoue que je confond toujours ce mot avec "normalisé" : ton utilisation de ce mot est donc tout à fait bonne pour moi, en fait ...).

Si c'est un proxy HTTP, malheureusement tu n'auras que droit à du HTTP ...

Regarde en:Dynamic DNS pour ce qui est de mettre à jour le serveur DNS.

Comme indiqué dans le bug-report que tu pointes, le fix est déjà dans unstable ; il devrait arriver bientôt dans testing, ou alors tu peux aussi installer le paquet d'unstable (ce qui est mieux que d'installer des paquets de stable dans testing).

En tous cas, tu tombes sur le plus gros problème de testing : les bugfixs mettent des années à arriver, c'est comme ça. Moi, je préfère largement unstable.

Je connaît pas d'autre RFC qui parle du sujet, mais si tu as plus d'infos je serais heureux de corriger mon code et mon cerveau :)

Bon, impossible de retrouver le papier où j'avais vu ça ... (il me semblait que c'était une RFC ...) C'était en gros pour avoir une forme canonique d'IPv6, en explicitant les cas ambigus comme quand on a deux suites de 0 (sur 16 bits) séparés, laquelle compresser en :: (j'ai souvenir de "celle de gauche") ; qu'on "compresse" toujours un maximum ; etc. Mais bon, tant pis.

Moi j'ai déjà récupéré des Acer "HS" parce que surchauffe, et ce n'était qu'un problème de poussière. OK ça demande un démontage complet, mais après la bécane marche très bien.

chaque constructeur faisant sa sauce.

Et il est aussi dit un peu plus loin dans le thread que les constructeurs ne se cassent pas le cul à factoriser le code, et préfèrent copier/coller le code existant en rajoutant leurs modifications, ce qui n'aide pas à arranger le bordel.

Avec ça, le header REMOTE_ADDR et autres headers du genre sont remplacés par une adresse IP aléatoire générée à l'aide de la véritable adresse IP comme seed. Ainsi pour le code PHP en dessous, ça ne change rien au niveau logique, sauf qu'il ne peut avoir accès à la véritable IP du client.

Au début, je n'ai pas très bien compris ton explication, mais en allant voir ton lien, j'ai capté : tu fais un hash de l'IP, représenté également comme une IP.

Ça peut être pas mal ... Par contre, en IPv4, ça doit être facile de faire une rainbow table pour retrouver l'IP d'origine. Bon, par contre, en IPv6 ...

Enfin, petite remarque : ta normalisation d'IPv6 ne suit pas, selon moi, la RFC que j'avais vu à ce sujet (on n'étend pas tout "bêtement"). Vu que tu dis juste "following the RFC", je ne sais pas à laquelle tu te réfères.

Arrête de nous narguer !

Si t'es vraiment motivé, comme le dit ze_lionix, c'est le meilleur moyen de montrer que t'as vraiment envie de t'embarquer dans ce domaine (haha). En plus, t'auras des gens qui sont dans l'embarqué _et_ le logiciel libre. Si ça te tente vraiment, dis toi aussi que tu n'auras plus jamais l'occasion de faire ça ...

Oui, je pense, à moins de gros changement dans les drivers.

Je viens d'en apprendre un peu sur les dts/dtb tout à l'heure, t'as de la chance ...

Donc, le "Device Tree Source" c'est, en gros, un fichier qui va décrire ta board et ses périphériques. Ça réunit les informations "bas niveau" sur l'organisation des bus, les interrputions, des mapping mémoire, etc. Ça se compile donc en dtb.
Ça permet de ne pas coder "en dur" l'initialisation des périphériques dans le kernel. Je suppose qu'on peut comme ça utiliser le même kernel sur deux boards différentes (mais de la même archi, quand même) en changeant juste le dtb.

Quant au ramdisk, je suppose que tu parles de l'initramfs (anciennement initrd). Bah ça c'est comme sur n'importe quelle distro d'aujourd'hui : ça contient les modules nécessaires au boot de ta carte. Pareil qu'avant, ça permet de mettre plein de drivers dedans pour plein de périphs différents, mais qui ne seront chargés qu'en fonction de leur utilisation.

Sinon, tu aurais pu aussi préciser ce qu'était le "avant" et "après" dans ta description, c'est toujours utile pour avoir un peu de contexte.