Ben autant le dire direct : Qt est peut être une référence en matière de toolkit sur le desktop, mais il est totalement à la ramasse pour ce qui est du mobile, donc passe ton chemin de ce côté.
Sur mobile, tu as grosso modo 4 façons de faire :
- technos "portables" à base de technos Web : HTML5 & Co. Le côté portable est tout relatif puisque tu dois te contenter d'un sous-ensemble commun de fonctionnalités, et si t'es un minimum sensible à l'ergonomie, tu dois adaptée ton IHM pour respecter les guidelines de chaque plateforme. Sans parler des contraintes de perfs qui limitent bon nombre de scénarios d'application. Bref, pratique pour vendre une appli à pas cher pour un client qui veut juste voir son logo sur les stores.
- techno "portable" façon AIR : le nouveau Java : une appli, tourne partout, l'IHM aussi. Mêmes contraintes qu'au dessus, modulo les perfs qui sont un peu meilleur.
- techno "à moitié" portable façon Mono : même outils, même langage, mêmes API hors IHM, mais toolkit natif sur chaque plateforme. Inconvénient : faut recoder l'IHM pour chaque cible. Avantages : on a un résultat identique à une appli native au niveau design, ergo & perf, et on utilise des outils plus productifs et cross-plateforme.
- techno "native" : on prend les outils de chaque plateforme, et on recode tout from scratch pour chaque plateforme. Avantages : pas de limites. Inconvénients : faut du temps.
A moins de me tromper, Steve Coast (ne sais pas d'où vient le M.) n'a pas du tout été engagé chez Microsoft pour s'occuper d'OSM mais bien pour améliorer leur propre service propriétaire (Bing Maps), et M$ n'est pas du tout impliqué dans OSM, ni ne donne un sous.
Ben justement, le Times indique le contraire, d'où cette news et les liens associés :
The Times reports that Coast is working on developing open-source software that will make it simpler for developers to get data from and use OpenStreetMap. And it also reports that Microsoft has been donating "valuable map data" to OpenStreetMap.
Alors effectivement y'a aucun chiffre, si quelqu'un a plus d'info…
Pourquoi les HP ont eu moins de succès ? […] Une simple démonstration de Txtrider (puis de ses clones) pouvait faire la différence dans la tête d'un écolier pour choisir une TI 68k.
Faut dire que la TI92 avait tout pour plaire au geek programmeur :
- un grand écran (bien plus grand que les HP)
- un clavier
- un IDE complet côté PC (TIGCC) avec un vrai langage (TIGCC).
- un proc à 10/12MHz permettant de faire des choses vraiments sympas :
Sans parler du CAS mathématique qui était vraiment performant et un module de géométrie sans équivalent sur HP.
En fait à part une notation inversée pour faire genre je suis l'élite, y'avait quoi comme intérêt sur une HP ?
PS : ok, je suis pas objectif, mon pseudo en a même gardé des traces ;)
Je veux en venir au fait que Google, en ne mettant pas le player HTML5 par défaut, surtout sous Chrome, ne pousse pas du tout à l'adoption de webm : le support sous Youtube reste invisible pour 99% des utilisateurs. S'il y avait une vrai volonté d'alternative, il serait le lecteur par défaut.
Si Google en avait vraiment quelque chose à branler d'imposer Webm, la priorité serait sur le player HTML5 + webm que sur des fonctionnalités annexes comme les annotations. Ca montre bien quelles sont leurs priorités.
Ou comment proposer un gros chiffre "50 Go" qu'on sera très peu capable d'utiliser (à part avec des bidouilles) à cause de limites arbitraires faites pour que tu ne puisses pas utiliser ce gros chiffre...
Cette limite est surtout pour éviter que le service se transforme en megaupload. L'usage voulant qu'un flim tienne sur 700Mo en règle générale.
Ensuite, ce n'est pas absolument pas inexploitable : j'ai 30 Go de zik et 20 Go de photos, et les fichiers sont très loin de faire 100 Mo, je sais même pas s'il y en a 2% qui font 10 Mo (de gros mp3 en 320 peut être).
Donc non, 50Go avec 100Mo de limite, ca peut avoir des usages, j'ai même envie de dire que ca correspond aux besoins de stockage à la mode : photo et zik, pour les avoir toujours partout.
Oui mais ils ne vont pas du tout au bout de la logique : sous chrome, c'est le lecteur flash par défaut !
Clairement, ils encodent en webm uniquement pour dire "regardez, on peut faire autre chose que du H264", autrement dit, c'est un moyen de pression commercial au moment d'achter leur licence H264. Après quand il s'agit d'usage de masse, aka youtube, rien ne vaut un bon gros player flash avec flux H264 et pubs en overlay intégré. Business is business après tout.
"Le brevet". Hem. Il y a une floppée de brevets sur le H264, gérés dans un consortium pour les revendre sous forme de licence.
De l'autre côté, Google propose webm, qui utilise des algos tellement proches du H264 que personne ne croit 2 secondes qu'il ne soit couvert par aucun brevet H264.
Donc oué, Google achète un brevet qui doit lui permettre de payer moins cher sa licence pour diffuser toutes ses vidéos youtube... en H264.
Si toutes les vidéos youtube étaient disponibles en webm, si Google interdisait le H264 en input youtube et si youtube diffusait exclusivement en webm sur Android, là oué, on pourrait croire 2 minutes que Google a des ambitions pour concurrencer réellement H264. Webm n'est qu'un prétexte : "attention les gars, nous faites pas trop raquer sinon on se démerde sans vous". Ctou. Rien à branler du libre dans ce contexte.
et ?
Le XML est un méta-langage qui peut décrire des langages de programmation, généralement de manière déclarative, mais pas uniquement. Exemple : XSLT.
Si j'utilise disons une fonction non-POSIX, mon but n'est pas de faire chier un organisme de normalisation mais de satisfaire un besoin.
Oui mais tu crées une application non portable. On peut s'en branler totalement dans le contexte de ton programme dont tout le monde se cogne, mais quand on parle d'un site web, certains sont attachés à une certaine interopérabilité et au respect des standards pour permettre à chacun de librement choisir son navigateur.
Je ne vois pas pourquoi leurs problèmes d'organisation interne les autorisent à incriminer les développeurs Web qui, eux, n'y sont pour rien.
Les développeurs font ce qu'ils veulent on est d'accord, comme y'a 10 ans ils avaient tout à fait le droit de faire un site IE6 only avec de bons gros ActiveX qui répondaient à leurs besoins. Mais il est normal d'attirer leur attention sur la problématique de l'interopérabilité et à faire attention de ne pas s'enfermer dans une logique où il n'y aurait qu'un seul navigateur.
Tiens, tiré de Wikipedia :
"Les FAI sont, aux termes de l'article 43-7 de la loi de 1986 sur la liberté de communication, telle que modifiée par la loi du 1/08/2000 (reprise à l'article 6-I 1° de la LCEN): « les personnes physiques ou morales dont l'activité est d'offrir un accès à des services de communication en ligne autres que de correspondance privée »."
Effectivement, c'est bizarre que la justice est tord alors que c'est toi qui a raison.
Ou alors peut être qu'il n'y a toujours que toi pour considérer que le numéro port TCP/UDP est une correspondance privée parcque tu es persuadé que les couches ISO sont inscrits dans le code pénal.
Non ce n'est sûrement pas une coïncidence : Megaupload devait savoir que ca sentait le roussi et a dû tenter de se faire une virginité en s'acoquinant avec des "artistes". Le clip avec les stars américaines est un peu dans la même idée.
Dans tous les cas : c'est évident qu'ils étaient conscient de l'utilisation illégale qui était faite de leur outil, on peut presque dire quasiment exclusivement pour celà.
Après qu'on se méprenne pas : je ne trouve pas que la loi de la propriété intellectuelle ici enfreinte soit juste et éthique :)
De facto, l'usage est de s'en servir dans un navigateur, avec donc un gaspillage assez énorme de bande passante
C'est du grand n'importe quoi. Il y a de nombreux usages hors-navigateur : SVN, transfert de fichier, web-services, API REST, HTTP streaming, etc. Forcement, toi tu te contente de ta petite expérience utilisateur et ce que tu en vois.
Ce qui me fait doucement rire, c'est que tu ventes des solutions pourtant réputées pour ne pas être efficace pour 2 sous niveau ressources (XMPP over bloated XML), et que tu utilises parfois ces protocoles au dessus de HTTP (genre là j'utilises Pidgin, client XMPP, à travers un passerelle HTTP).
(javascript sur navigateur sur OS, versus application native sur OS
Admet que tu mélanges tout : javascript & HTML c'est au niveau supérieur. HTTP c'est relativement neutre sur le contenu, et tu peux à prêt y faire circuler n'importe quoi. Forcement, à vouloir mettre tout dans le même panier, on fait forcement des raccourcis foireux.
". Dans les faits, on met d'un côté un navigateur Web qui bouffe un maximum de RAM et de CPU, de l'autre côté généralement un LAMP qui bouffe aussi un max de ressources, par rapport à ce qui serait bouffé si c'était prosody qui parle à mcabber.
Nawak. Je mets en place régulièrement des web-services. Côté serveur, si je mets un LAMP, c'est que j'ai besoin d'une base de donnée et d'un contenu dynamique : ca n'a rien à voir avec HTTP, quelque soit le protocole que tu choisis, si t'as besoin de gérer des contenus dynamiques qui doivent persister, il te faudra un serveur applicatif capable de cracher les données et un serveur de données pour les stocker.
Mais quelle limite? Impossible de choisir une limite qui soit assez haute pour ne gener aucune application legitime, et en meme temps assez basse pour eviter les DoS sur tous les systemes, etc.
Bien sûr que si c'est possible de choisir une limite ! Prends la conso mémoire de la JVM : elle impose une limite, configurable, qui empêche une appli web d'en demander trop. Si une appli légitime en a besoin, l'utilisateur peut modifier la config de la JVM au cas par cas, mais il est primordiale d'avoir une limite par défaut pour empêcher les applications non légitimes de faire des conneries et s'écrouler le système.
Mais c'est sûr, si tu pars du principe qu'un jour y'aura une appli légitime qui a besoin d'un accès root, de 5 Go de ram, alors oui, c'est difficile de choisir des limites.
Tout ce qu'on pourrait faire c'est couper la poire en deux, taper au milieu de la fourchette, dire "pas plus de 256 M de memoire par domaine pour les scripts" et on aurait encore tous les problemes: ca serait encore trop pour beaucoup de machines, et pas assez pour beaucoup de scripts specialises.
Le runtime peut très bien s'adapter aux ressources disponibles pour définir la limite à ne pas atteindre. Et si le script a besoin de plus, bah tant pis : pas assez de ressources, c'est comme ça : message d'erreur à la limite. Les ressources ne sont pas infinis, il est normal que le runtime impose une limite pour ne pas mettre la machine à genoux, et c'est aux scripts de s'adapter !
Et quand un jeu Facebook buggerait a cause de ca, on recevrait des milliers de plaintes.
Mouais c'est vrai, autant laisser la machine tomber à genou plutôt que d'afficher un beau message d'erreur quand la conso mémoire commence à devenir indécente aux regards des ressources dispo...
Surtout que ce que tu dis est totalement contradictoire avec la réalité : prends par exemple la conso CPU : Firefox comme Chrome affiche un message d'erreur si un script met trop de temps à s'exécuter. Il y a une limite d'imposée, un message d'erreur affiché. Comment t'explique ce comportement alors qu'il peut y avoir des applications légitimes qui consomment beaucoup de CPU ?
Et dis moi, vous faite pareil aussi pour la gestion sur disque ? Vous laissez les cookies ou les données HTML5 locales faire 1Go sur disque ? Non parcque je suis sûr qu'on peut trouver des applications légitimes...
Idem pour le bug avec beaucoup de grandes images. Et ca n'etait que 2 exemples...
Même si on est pas d'accord sur la pertinence ou non de mettre une limite, le principal est qu'il soit possible d'en mettre une.
Dans tous les cas, la situation est bien différente telle que tu la présentes avec WebGL et le GPU : d'après ce que tu dis, il n'est techniquement pas possible (en tout cas de manière générale) de poser une limite sur la monopolisation du GPU, et ca c'est un vrai problème.
Au passage je m'étonne que tu ne sois pas plus critique envers le fait que des accès présentés comme "à Internet" (mais qui n'en sont pas) ne permettent d'accéder qu'au Web. C'est aussi délirant qu'un accès sur lequel seul SSH passerait (en fait, c'est pire, car SSH permet au moins d'y tunneler facilement autre chose sans overhead délirant).
Houlà, mais je dis pas que c'est bien de tout faire passer sur HTTP, je donne juste l'explication. Le problème est bien dans les politiques d'accès internet, que ce soit l'admin psychopathe en entreprise qui trouve le port POP dangereux ou le méchant FAI mobile qui veut pas que tu fasses de SSH.
S'il ne s'agit que de servir des fichiers statiques il ne consomme pas beaucoup.
Voilà, l'overhead est techniquement ridicule, on est d'accord.
S'il s'agit de publier des informations de statut (micro-blogging versus XMPP), de proposer une interface de discussion (IRC/XMPP versus appli Web de chat), de discuter (forum PHPxx versus UUCP), alors le serveur HTTP sera accompagné d'une base de données, de scripts en PHP ou autre langage interprété, et nécessitera davantage qu'un CPU de modem-routeur pour faire ce qu'on lui demande dans un délai raisonnable.
Tu mélanges tout et n'importe quoi. HTTP n'est qu'un protocole offrant la possibilité de requêter une ressource distante : tu peux faire au dessus un protocole de type IRC, de type XMPP (ce dernier le fait déjà d'ailleur).
Pour toi HTTP == application web HTML + tout le bordel : tu compares un simple serveur de communication avec un serveur qui t'expose le client utilisateur. Non, dans HTTP tu peux faire passer la même chose que ce que tu fais passer au niveau XMPP ou IRC. Il y a un overhead, certes, des contraintes qui font que ce n'est pas aussi efficace, mais si ton serveur fait le même boulot avec pour seule différence de le faire au dessus de HTTP, alors il le consommera probablement pas beaucoup plus de ressources.
Si tu veux vraiment te soucier de ce problème d'overhead ajouté par HTTP, arrête de parler d'XMPP, parcque dans le genre overhead, XMPP te formatte tes messages en XML, qui, je te le rappelle, doit être le langage le plus verbeux inventé pour faire circuler la moindre donnée. A côté, l'en-tête HTTP est ridicule.
Ya pas plus de cote inherent d'un cote ou de l'autre, ca reste au browser de s'assurer que tout va pas peter, apres tout, c'est lui qui alloue ces ressources au final...
Je suis bien d'accord, mais de ce que je comprend du problème soulevé par WebGL, c'est que le navigateur ne peut justement pas empêcher ce problème, le GPU étant non-préemptible. Ou alors il faut contrôler le problème en amont et construire une API qui interdisent d'arriver dans une situation de blocage. D'où ma question : OpenGL (variante ES) était-il vraiment la bonne base à prendre dans un contexte d'exécution de code web ?
Dans le fond, on est d'accord, donner acces direct au matos au premier clampin venu sur internet, ca pue la mauvaise idee, point a la ligne.
Et c'est pas les failles de flash avec les webcams/micros qui vont me contredire.
C'est même encore pire : flash est une sandbox, et comme tu le fais remarqué, il y a quand même des bugs. C'est bien pour celà que WebGL me fait peur : on expose des API encore plus bas-niveau, non sandboxés si je comprends bien.
La spec JS (ou EcmaScript) ne dit absolument pas qu'un code JS peut allouer autant de mémoire qu'il veut : il est tout à fait normal et légitime de mettre une limite, et c'est ce qui est fait en pratique par les runtime JS. Donc non, ce n'est pas un DoS inhérent à la plateforme HTML+JS.
une simple page web avec beaucoup de grandes images, surtout sur un navigateur qui utilise le GPU
Là encore, le navigateur peut tout à fait empêcher ça et imposer une limite : je ne vois donc pas où est le soucis.
Rappel : toi tu parles d'un problème inhérent à la spec qui offre un accès à des fonctions trop bas niveau conduisant à l'impossibilité par le système d'empêcher une monopolisation du GPU. Bref, c'est un DoS "by design".
FF a eu il ya longtemps un bug provoquant un freeze du browser.
Là on parle d'un bug dans un navigateur. Moi je demande à voir un problème inhérent dans HTML+JS qui ouvre la porte à un DoS de la même manière que la spec WebGL.
Disons que c'est pas comme si les pilotes 3D etaient pas reputes pour etre la principale source de crash et de problemes de secu dans un os.
Toutafé, raison de plus pour éviter d'exposer des API aussi bas niveau qu'OpenGL à une page HTML+JS.
[^] # Re: mono?
Posté par TImaniac (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 7.
Ben autant le dire direct : Qt est peut être une référence en matière de toolkit sur le desktop, mais il est totalement à la ramasse pour ce qui est du mobile, donc passe ton chemin de ce côté.
Sur mobile, tu as grosso modo 4 façons de faire :
- technos "portables" à base de technos Web : HTML5 & Co. Le côté portable est tout relatif puisque tu dois te contenter d'un sous-ensemble commun de fonctionnalités, et si t'es un minimum sensible à l'ergonomie, tu dois adaptée ton IHM pour respecter les guidelines de chaque plateforme. Sans parler des contraintes de perfs qui limitent bon nombre de scénarios d'application. Bref, pratique pour vendre une appli à pas cher pour un client qui veut juste voir son logo sur les stores.
- techno "portable" façon AIR : le nouveau Java : une appli, tourne partout, l'IHM aussi. Mêmes contraintes qu'au dessus, modulo les perfs qui sont un peu meilleur.
- techno "à moitié" portable façon Mono : même outils, même langage, mêmes API hors IHM, mais toolkit natif sur chaque plateforme. Inconvénient : faut recoder l'IHM pour chaque cible. Avantages : on a un résultat identique à une appli native au niveau design, ergo & perf, et on utilise des outils plus productifs et cross-plateforme.
- techno "native" : on prend les outils de chaque plateforme, et on recode tout from scratch pour chaque plateforme. Avantages : pas de limites. Inconvénients : faut du temps.
[^] # Re: Quelle OPA?
Posté par TImaniac (site web personnel) . En réponse à la dépêche OPA sur OpenStreetMap. Évalué à 2.
Ben justement, le Times indique le contraire, d'où cette news et les liens associés :
The Times reports that Coast is working on developing open-source software that will make it simpler for developers to get data from and use OpenStreetMap. And it also reports that Microsoft has been donating "valuable map data" to OpenStreetMap.
Alors effectivement y'a aucun chiffre, si quelqu'un a plus d'info…
[^] # Re: pfff
Posté par TImaniac (site web personnel) . En réponse à la dépêche Punix, le baptême du feu. Évalué à 4.
Faut dire que la TI92 avait tout pour plaire au geek programmeur :
- un grand écran (bien plus grand que les HP)
- un clavier
- un IDE complet côté PC (TIGCC) avec un vrai langage (TIGCC).
- un proc à 10/12MHz permettant de faire des choses vraiments sympas :
Sans parler du CAS mathématique qui était vraiment performant et un module de géométrie sans équivalent sur HP.
En fait à part une notation inversée pour faire genre je suis l'élite, y'avait quoi comme intérêt sur une HP ?
PS : ok, je suis pas objectif, mon pseudo en a même gardé des traces ;)
[^] # Re: Mais pourquoi "Linux n'est pas prêt pour le Bureau" ?
Posté par TImaniac (site web personnel) . En réponse au journal L'échec du bureau libre sous Linux réside paradoxalement dans le fait qu'il n'est pas assez libre.. Évalué à 2.
"Linux Desktop" dans le titre, donc oui, on parle bien du Linux pour le PC de bureau, pas la tablette.
[^] # Re: pathétique journal
Posté par TImaniac (site web personnel) . En réponse au journal Quand Microsoft fait sa pleureuse.... Évalué à 2.
Je veux en venir au fait que Google, en ne mettant pas le player HTML5 par défaut, surtout sous Chrome, ne pousse pas du tout à l'adoption de webm : le support sous Youtube reste invisible pour 99% des utilisateurs. S'il y avait une vrai volonté d'alternative, il serait le lecteur par défaut.
[^] # Re: pathétique journal
Posté par TImaniac (site web personnel) . En réponse au journal Quand Microsoft fait sa pleureuse.... Évalué à 1.
Si Google en avait vraiment quelque chose à branler d'imposer Webm, la priorité serait sur le player HTML5 + webm que sur des fonctionnalités annexes comme les annotations. Ca montre bien quelles sont leurs priorités.
[^] # Re: pathétique journal
Posté par TImaniac (site web personnel) . En réponse au journal Quand Microsoft fait sa pleureuse.... Évalué à 1.
y dit qu'il voit pas le rapport.
[^] # Re: Mouais...
Posté par TImaniac (site web personnel) . En réponse au journal 50 Go dans le Cloud.... Évalué à 5.
Cette limite est surtout pour éviter que le service se transforme en megaupload. L'usage voulant qu'un flim tienne sur 700Mo en règle générale.
Ensuite, ce n'est pas absolument pas inexploitable : j'ai 30 Go de zik et 20 Go de photos, et les fichiers sont très loin de faire 100 Mo, je sais même pas s'il y en a 2% qui font 10 Mo (de gros mp3 en 320 peut être).
Donc non, 50Go avec 100Mo de limite, ca peut avoir des usages, j'ai même envie de dire que ca correspond aux besoins de stockage à la mode : photo et zik, pour les avoir toujours partout.
[^] # Re: pathétique journal
Posté par TImaniac (site web personnel) . En réponse au journal Quand Microsoft fait sa pleureuse.... Évalué à 4.
Oui mais ils ne vont pas du tout au bout de la logique : sous chrome, c'est le lecteur flash par défaut !
Clairement, ils encodent en webm uniquement pour dire "regardez, on peut faire autre chose que du H264", autrement dit, c'est un moyen de pression commercial au moment d'achter leur licence H264. Après quand il s'agit d'usage de masse, aka youtube, rien ne vaut un bon gros player flash avec flux H264 et pubs en overlay intégré. Business is business après tout.
[^] # Re: pathétique journal
Posté par TImaniac (site web personnel) . En réponse au journal Quand Microsoft fait sa pleureuse.... Évalué à 2.
"Le brevet". Hem. Il y a une floppée de brevets sur le H264, gérés dans un consortium pour les revendre sous forme de licence.
De l'autre côté, Google propose webm, qui utilise des algos tellement proches du H264 que personne ne croit 2 secondes qu'il ne soit couvert par aucun brevet H264.
Donc oué, Google achète un brevet qui doit lui permettre de payer moins cher sa licence pour diffuser toutes ses vidéos youtube... en H264.
Si toutes les vidéos youtube étaient disponibles en webm, si Google interdisait le H264 en input youtube et si youtube diffusait exclusivement en webm sur Android, là oué, on pourrait croire 2 minutes que Google a des ambitions pour concurrencer réellement H264. Webm n'est qu'un prétexte : "attention les gars, nous faites pas trop raquer sinon on se démerde sans vous". Ctou. Rien à branler du libre dans ce contexte.
[^] # Re: heu ...
Posté par TImaniac (site web personnel) . En réponse au journal Debian ? Ça vaut 14 milliards d'euros.. Évalué à 3.
et ?
Le XML est un méta-langage qui peut décrire des langages de programmation, généralement de manière déclarative, mais pas uniquement. Exemple : XSLT.
[^] # Re: Please fill out this field
Posté par TImaniac (site web personnel) . En réponse à la dépêche Appel pour le web ouvert !. Évalué à 10.
Oui mais tu crées une application non portable. On peut s'en branler totalement dans le contexte de ton programme dont tout le monde se cogne, mais quand on parle d'un site web, certains sont attachés à une certaine interopérabilité et au respect des standards pour permettre à chacun de librement choisir son navigateur.
Les développeurs font ce qu'ils veulent on est d'accord, comme y'a 10 ans ils avaient tout à fait le droit de faire un site IE6 only avec de bons gros ActiveX qui répondaient à leurs besoins. Mais il est normal d'attirer leur attention sur la problématique de l'interopérabilité et à faire attention de ne pas s'enfermer dans une logique où il n'y aurait qu'un seul navigateur.
[^] # Re: autre tentative
Posté par TImaniac (site web personnel) . En réponse au journal Bien comprendre les différentes idéologies politiques. Évalué à 6.
ni toutes autres formes d’êtres vivants en ma possession.
Sachant que tout ce qu'on mange vient du monde vivant (si on met de côté le sel), tu fais quoi ? tu suces des cailloux ?
[^] # Re: Quelques détails...
Posté par TImaniac (site web personnel) . En réponse au journal Free condamné pour avoir menti à ses clients !. Évalué à 3.
Tiens, tiré de Wikipedia :
"Les FAI sont, aux termes de l'article 43-7 de la loi de 1986 sur la liberté de communication, telle que modifiée par la loi du 1/08/2000 (reprise à l'article 6-I 1° de la LCEN): « les personnes physiques ou morales dont l'activité est d'offrir un accès à des services de communication en ligne autres que de correspondance privée »."
[^] # Re: Quelques détails...
Posté par TImaniac (site web personnel) . En réponse au journal Free condamné pour avoir menti à ses clients !. Évalué à -4.
Effectivement, c'est bizarre que la justice est tord alors que c'est toi qui a raison.
Ou alors peut être qu'il n'y a toujours que toi pour considérer que le numéro port TCP/UDP est une correspondance privée parcque tu es persuadé que les couches ISO sont inscrits dans le code pénal.
[^] # Re: Megaupload voulait rétribuer les ayants-droits.
Posté par TImaniac (site web personnel) . En réponse au journal Mégaupload fermé, tant mieux ! Je suis comédien, mes films ne sont pas gratuits. Évalué à 8.
Non ce n'est sûrement pas une coïncidence : Megaupload devait savoir que ca sentait le roussi et a dû tenter de se faire une virginité en s'acoquinant avec des "artistes". Le clip avec les stars américaines est un peu dans la même idée.
Dans tous les cas : c'est évident qu'ils étaient conscient de l'utilisation illégale qui était faite de leur outil, on peut presque dire quasiment exclusivement pour celà.
Après qu'on se méprenne pas : je ne trouve pas que la loi de la propriété intellectuelle ici enfreinte soit juste et éthique :)
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 3.
C'est du grand n'importe quoi. Il y a de nombreux usages hors-navigateur : SVN, transfert de fichier, web-services, API REST, HTTP streaming, etc. Forcement, toi tu te contente de ta petite expérience utilisateur et ce que tu en vois.
Ce qui me fait doucement rire, c'est que tu ventes des solutions pourtant réputées pour ne pas être efficace pour 2 sous niveau ressources (XMPP over bloated XML), et que tu utilises parfois ces protocoles au dessus de HTTP (genre là j'utilises Pidgin, client XMPP, à travers un passerelle HTTP).
Admet que tu mélanges tout : javascript & HTML c'est au niveau supérieur. HTTP c'est relativement neutre sur le contenu, et tu peux à prêt y faire circuler n'importe quoi. Forcement, à vouloir mettre tout dans le même panier, on fait forcement des raccourcis foireux.
Nawak. Je mets en place régulièrement des web-services. Côté serveur, si je mets un LAMP, c'est que j'ai besoin d'une base de donnée et d'un contenu dynamique : ca n'a rien à voir avec HTTP, quelque soit le protocole que tu choisis, si t'as besoin de gérer des contenus dynamiques qui doivent persister, il te faudra un serveur applicatif capable de cracher les données et un serveur de données pour les stocker.
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 2.
Bien sûr que si c'est possible de choisir une limite ! Prends la conso mémoire de la JVM : elle impose une limite, configurable, qui empêche une appli web d'en demander trop. Si une appli légitime en a besoin, l'utilisateur peut modifier la config de la JVM au cas par cas, mais il est primordiale d'avoir une limite par défaut pour empêcher les applications non légitimes de faire des conneries et s'écrouler le système.
Mais c'est sûr, si tu pars du principe qu'un jour y'aura une appli légitime qui a besoin d'un accès root, de 5 Go de ram, alors oui, c'est difficile de choisir des limites.
Le runtime peut très bien s'adapter aux ressources disponibles pour définir la limite à ne pas atteindre. Et si le script a besoin de plus, bah tant pis : pas assez de ressources, c'est comme ça : message d'erreur à la limite. Les ressources ne sont pas infinis, il est normal que le runtime impose une limite pour ne pas mettre la machine à genoux, et c'est aux scripts de s'adapter !
Mouais c'est vrai, autant laisser la machine tomber à genou plutôt que d'afficher un beau message d'erreur quand la conso mémoire commence à devenir indécente aux regards des ressources dispo...
Surtout que ce que tu dis est totalement contradictoire avec la réalité : prends par exemple la conso CPU : Firefox comme Chrome affiche un message d'erreur si un script met trop de temps à s'exécuter. Il y a une limite d'imposée, un message d'erreur affiché. Comment t'explique ce comportement alors qu'il peut y avoir des applications légitimes qui consomment beaucoup de CPU ?
Et dis moi, vous faite pareil aussi pour la gestion sur disque ? Vous laissez les cookies ou les données HTML5 locales faire 1Go sur disque ? Non parcque je suis sûr qu'on peut trouver des applications légitimes...
Même si on est pas d'accord sur la pertinence ou non de mettre une limite, le principal est qu'il soit possible d'en mettre une.
Dans tous les cas, la situation est bien différente telle que tu la présentes avec WebGL et le GPU : d'après ce que tu dis, il n'est techniquement pas possible (en tout cas de manière générale) de poser une limite sur la monopolisation du GPU, et ca c'est un vrai problème.
[^] # Re: réponse du micro...
Posté par TImaniac (site web personnel) . En réponse au journal Tester votre chaîne Hi-Fi avec Qloud. Évalué à 10.
Tu oublies le principal dans les possibilités d'avoir un son mauvais : le fait d'écouter de la zik de merde :)
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 0.
Houlà, mais je dis pas que c'est bien de tout faire passer sur HTTP, je donne juste l'explication. Le problème est bien dans les politiques d'accès internet, que ce soit l'admin psychopathe en entreprise qui trouve le port POP dangereux ou le méchant FAI mobile qui veut pas que tu fasses de SSH.
Voilà, l'overhead est techniquement ridicule, on est d'accord.
Tu mélanges tout et n'importe quoi. HTTP n'est qu'un protocole offrant la possibilité de requêter une ressource distante : tu peux faire au dessus un protocole de type IRC, de type XMPP (ce dernier le fait déjà d'ailleur).
Pour toi HTTP == application web HTML + tout le bordel : tu compares un simple serveur de communication avec un serveur qui t'expose le client utilisateur. Non, dans HTTP tu peux faire passer la même chose que ce que tu fais passer au niveau XMPP ou IRC. Il y a un overhead, certes, des contraintes qui font que ce n'est pas aussi efficace, mais si ton serveur fait le même boulot avec pour seule différence de le faire au dessus de HTTP, alors il le consommera probablement pas beaucoup plus de ressources.
Si tu veux vraiment te soucier de ce problème d'overhead ajouté par HTTP, arrête de parler d'XMPP, parcque dans le genre overhead, XMPP te formatte tes messages en XML, qui, je te le rappelle, doit être le langage le plus verbeux inventé pour faire circuler la moindre donnée. A côté, l'en-tête HTTP est ridicule.
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 2.
Je suis bien d'accord, mais de ce que je comprend du problème soulevé par WebGL, c'est que le navigateur ne peut justement pas empêcher ce problème, le GPU étant non-préemptible. Ou alors il faut contrôler le problème en amont et construire une API qui interdisent d'arriver dans une situation de blocage. D'où ma question : OpenGL (variante ES) était-il vraiment la bonne base à prendre dans un contexte d'exécution de code web ?
C'est même encore pire : flash est une sandbox, et comme tu le fais remarqué, il y a quand même des bugs. C'est bien pour celà que WebGL me fait peur : on expose des API encore plus bas-niveau, non sandboxés si je comprends bien.
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 0.
Tu veux diffuser un live vidéo en BitTorrent ? Et tu nous parles d'efficacité ?
Ils sont adaptés à la réalité d'internet : en gros seul HTTP passe à peu prêt partout.
Gni ?
Tu peux expliquer en quoi un serveur de fichier en HTTP consomme beaucoup trop de ressource par rapport à un serveur de fichiers en FTP ?
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 2.
La spec JS (ou EcmaScript) ne dit absolument pas qu'un code JS peut allouer autant de mémoire qu'il veut : il est tout à fait normal et légitime de mettre une limite, et c'est ce qui est fait en pratique par les runtime JS. Donc non, ce n'est pas un DoS inhérent à la plateforme HTML+JS.
Là encore, le navigateur peut tout à fait empêcher ça et imposer une limite : je ne vois donc pas où est le soucis.
Rappel : toi tu parles d'un problème inhérent à la spec qui offre un accès à des fonctions trop bas niveau conduisant à l'impossibilité par le système d'empêcher une monopolisation du GPU. Bref, c'est un DoS "by design".
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 2.
Là on parle d'un bug dans un navigateur. Moi je demande à voir un problème inhérent dans HTML+JS qui ouvre la porte à un DoS de la même manière que la spec WebGL.
Toutafé, raison de plus pour éviter d'exposer des API aussi bas niveau qu'OpenGL à une page HTML+JS.
[^] # Re: ca fait peur
Posté par TImaniac (site web personnel) . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 3.
Tu as des exemples concrêts de DoS inherents à la plateforme web (html+js) ?