Le navigateur Opera va passer à l'omniprésent Webkit, et utiliser V8 en moteur javascript (l'interpréteur javascript JIT de Google Chrome). C'était déjà le cas pour le navigateur mobile (d'abord pour la principale raison que Apple interdit tout moteur différent de Webkit sur IOS), et ça va bientôt être le cas de la version de bureau.
Opera n'est pas libre mais fonctionne sous Linux, et a toujours été un «bon» navigateur.
Jusqu'à présent, ils développaient leur propre moteur de rendu et interpréteur javascript, et avaient participé de manière active dans la guerre des navigateurs. On peut penser que le passage à Webkit est dans une stratégie de réduction des coûts. Mais Webkit est libre et Opera a annoncé qu'ils redistribuerons leurs modifications. C'est donc une stratégie plus OpenSource et libre qu'adopte Opera.
Est-ce qu'il vaut mieux un navigateur propriétaire mais innovant, ou quelques contributions de plus dans Webkit ?
http://my.opera.com/ODIN/blog/300-million-users-and-move-to-webkit
# Les deux
Posté par Kerro . Évalué à 10.
À titre strictement personnel, je ne vois pas de problème à ce que l'innovation puisse être issue de produits propriétaires.
Bien entendu c'est mieux en étant libre, mais globalement ce qui fait avancer les choses sont les idées, pas une implémentation précise.
Par exemple le système des onglets a été un progrès important. Avoir le code source de cette fonctionnalité n'apporte que peu.
Dans d'autres cas la somme de travail est considérable, c'est là que le source est bien utile. C'est d'ailleurs le raisonnement d'Opera en passant à Webkit.
# Mono-culture
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Amusant, je lisais justement il y a peu de temps : http://www.hteumeuleu.fr/la-mono-culture-webkit/ .
C'est assez effrayant je trouve.
[^] # Re: Mono-culture
Posté par mackwic . Évalué à 4.
Excellent lien ! Ce site est plein de perles !
[^] # Re: Mono-culture
Posté par Zenitram (site web personnel) . Évalué à 7.
Sauf qu'il tape à côté :
Mais c'est libre.
Donc quand le dictateur merde, tu forkes et le dictateur coule avec sa connerie (plus personne n'utilise). Un dictateur pas sympa ne peut pas survivre avec le libre, et l'auteur l'a oublié. On a déjà vu des forks de trucs très bien implanté (Xfree, LibreOffice…) pour la démo.
Non, ce n'est pas effrayant, c'est comme Linux : les ressources en commun, et si Linus merde un jour, il dégagera, pareil pour Webkit. Si c'est pas assez pour qu'il dégage, tu maintiens tes patchs (il y a plein de forks de Linux qui vivent à côté, avantage = même base!).
Vive le libre, avec les avantages (mise en commun) et… Les avantages (pas de risque de dictature malveillante).
Donc c'est très bien, merci le libre (BSD de surcroît, donc sans problèmes de licence pas compatible)
[^] # Re: Mono-culture
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Tu ne tiens pas compte de l'inertie et de l'instinct grégaire. Si un projet libre déconne mais pas trop, il continuera, alors qu'avec un peu de concurrence cela pourrait être évité. D'une façon générale, même avec des logiciels libres, la concurrence est une bonne chose et la mono-culture une catastrophe.
[^] # Re: Mono-culture
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 13 février 2013 à 13:25.
Donc Linux est une catastrophe? Je ne compte pas les BSD ou autres ayant très très peu d'utilisateurs par rapport à Linux.
Perso : je ne pense pas, je pense même le contraire, grâce à la mise en commun ça avance, et très très vite. La "mono-culture" (un peu fort pour du libre : ça mélange plein de cultures en fait!) a plutôt du bon… Et c'est démontré tous les jours avec Linux.
Il y a la théorie, puis la pratique : en pratique, l'investissement est trop énorme pour tenir la route à plusieurs comme ça, et travailler ensemble est plus rentable.
[^] # Re: Mono-culture
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -1.
Avec le développement de logiciels comme systemd, qui laissent tomber toute prétention à la portabilité ? Oui.
[^] # Re: Mono-culture
Posté par Zenitram (site web personnel) . Évalué à 6.
ah oui, j'oubliais : Ubuntu est une catastrophe (oui,tant qu'à faire, je la rajoute), Webkit est une catastrophe, systemd est une catastrophe et j'en passe. On peut aussi résumer : tout ce qui a du succès est une catastrophe, aucune tête ne devrait dépasser.
[^] # Re: Mono-culture
Posté par Anonyme . Évalué à 3.
C'est toujours la même chose. À fragmenter sans s'arrêter on perd en « force commune », et à ne pas fragmenter on perd en compétitivité.
Avoir des moteurs de rendu différents et qui ont évolués chacun de leur côté, plus ou moins, est une bonne chose. Ça fait des moteurs JavaScript plus performants, par exemple.
S'il y avait un fork de Linux (ça existe d'ailleurs non ?), et qui soit au moins aussi utilisé que son papa, on assisterait sans doute à de gros remaniements de chaque côté (on pourrait pas faire un fork de menuconfig ? :-) ).
Bon de toute façon, 2013, l'année du desktop BSD.
[^] # Re: Mono-culture
Posté par Adrien . Évalué à 5.
Il me semble que c'est le fondement même du libre, et des bibliothèques : partager du code, comme ça on évite de réinventer la roue à chaque fois… Il semblerait débile de refaire une libpng ou libtiff tellement le gain de temps est évident, mais pour un moteur web, c'est de la mono-culture… :-)
[^] # Re: Mono-culture
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Les traumatismes de la période IE6 ne disparaîtront pas avant très, très longtemps …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mono-culture
Posté par Yukito (site web personnel) . Évalué à 9.
En même temps, il faut voir que la mono-culture possède certains avantages. Le succès du noyau Linux est très lié au fait que les forks ont été évités et que tous les efforts se sont regroupés autour d'une base de code commune. Même google en a marre de maintenir android dans son coin, et fait remonter de plus en plus de patchs vers la branche principale.
Sur certaines briques de nos systèmes (je pense principalement aux systèmes de paquets), on peut même dire qu'on souffre de l'absence de mono-culture.
Dans le cas précis des navigateurs, je ne sais pas trop, car je n'ai pas assez de connaissances sur les moteurs de rendu. S'il y a des différences majeures d'architecture, ça peut justifier de maintenir plusieurs moteurs, mais si tout se ressemble et qu'en fait chacun implémente plus ou moins la même chose et de la même façon, la convergence est naturelle.
# Différent, mais propriétaire
Posté par mackwic . Évalué à 10.
Qu'Opera abandonne son moteur de rendu me rend un peu triste. Ils sont très méritant et ont toujours été très (ré)actifs sur les normes W3C.
Certes, certaines propriétés ont été implémentées à l'arrache à grand coup de
//FIXME, mais leur dynamisme est toujours à louer.Je pense que c'est sans conteste une perte pour le web, car c'est par la diversité des acteurs que le consensus se trouve. Concentrer les acteurs sur webkit ne fait que donner plus de pouvoir à ceux qui en contrôlent les releases.
Cependant, Opera a toujours été une petite structure, et Presto a accumulé du retard (via ses
//FIXME, vous vous souvenez ?). Je comprend tout à fait leur besoin de se recentrer sur un navigateur compétitif et toujours innovant comme ils savent si bien le faire.Alors, si c'est pour qu'Opera soit plus innovateur que jamais, si ça leur permet de continuer de révolutionner la façon même dont on utilise notre navigateur (tabs, extensions, speed-dial, mouse-gesture, et tellement d'autres); on peut dire dans ce cas que c'est un moindre mal.
Je continuerais de supporter Mozilla Firefox parce que dans le contexte actuel, leur position d'ouverture prévaut et marque une opposition nécessaire avec Chrome et sa poudre aux yeux intrusive, mais Opera est un acteur qu'il serait dommage de regarder de haut.
# Triste
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 7.
Triste de voir l'un des meilleurs moteurs web au monde (et le plus ancien !) disparaître au profit d'une monoculture webkit peu intéressante.
Quelle sera la différence alors entre Opera et les autres navigateurs ? C'est se tirer une balle dans le pied je trouve…
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Triste
Posté par Zenitram (site web personnel) . Évalué à 3.
Le point fort d'Opera n'est pas son moteur (c'est même plutôt un handicap, car les sites ne font pas toujours attention à tester avec lui), mais son interface homme-machine.
Au contraire, c'est arrêter d'essayer de rattraper les mastodontes des moteurs web alors qu'on n'est pas dimensionné pour.
[^] # Re: Triste
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 5.
Justement le point fort d'Opera c'est l'intégration très forte entre le moteur et ses interfaces : mouse gestures, user scripts bien plus évolués que dans GreaseMonkey (modification des scripts chargés à la volée par exemple), raccourcis clavier personnalisables (impossible dans FF et Chromium), widgets, extensions, sans compter que c'est le moteur le plus avancé pour plein de choses : web forms, HTML5, SVG, etc.
Les autres sont à des années derrière rien que sur le sujet du SVG hélas.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Triste
Posté par Gof (site web personnel) . Évalué à 2.
Je ne connais pas bien Opera, mais qu'est-ce qui empêche d'implémenter toutes les fonctionnalités que tu cite en utilisant Webkit ?
Il vont peut être aider à améliorer le SVG dans Webkit. C'est une bonne chose, non ?
[^] # Re: Triste
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
User scripts : limitation du moteur webkit, web forms : ils en veulent pas, SVG : ils s'en foutent (mention spéciale à Firefox qui a refusé par principe d'intégrer le patch pour les SVG fonts), etc.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Triste
Posté par Zenitram (site web personnel) . Évalué à -1.
Linux refuse grsecurity, est-ce une raison pour faire un nouvel OS en entier, ou n'est-il pas plus optimal de maintenir un patch?
je te laisse adapter pour le sujet du journal.
Bref, ce n'est pas des "ils n'en veulent pas" qu'il faut démontrer, mais des incompatibilité méga-énormes qui rendraient le coût de la maintenance du patch plus important que le coût de maintenir Presto en entier.
La, l'argument est HS, on ne parle pas d'un moteur proprio… J'ai l'impression que les gens oublient le principal : c'est libre, donc patchable. Ah non, le principal est : ça coûte de la thune, donc faut trouver la méthode optimale, pas un "ils n'en veulent pas donc je développe tout de zéro". Argumentez donc en prenant en compte ce point.
[^] # Re: Triste
Posté par barmic . Évalué à 3.
C'est faux. C'est libre donc forkable (éventuellement c'est patchable si les créateurs le veulent bien).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Triste
Posté par Zenitram (site web personnel) . Évalué à 0.
Si il faut expliquer précisément : tu peux patcher et diffuser ta version patchée et/ou diffuser ton patch, sans pour autant forker le projet entier, ce qui te fait maintenir ton patch uniquement, pas le code entier. J'avais pourtant donné un projet comme exemple…
[^] # Re: Triste
Posté par barmic . Évalué à 1.
grsecurity qui supporte linux 2.6.32 et 3.2 ce qui donne le support d'une version tout les 3 ans :
https://grsecurity.net/download_stable.php
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Triste
Posté par Zenitram (site web personnel) . Évalué à 0.
C'est une exemple de faisabilité.
Après, Linux faisant le nécessaire pour pas qu'on se plaigne trop de lui, il n'y a pas trop le besoin de maintenir des patchs à côté.
Comme quoi, un seul OS peut contenter du monde. Pareil pour les moteurs web.
J'attend toujours qu'on me démontre que ça coûtera plus cher à Opera ou autre de maintenir des patchs pour ce qui est refusé et qu'ils veulent absolument comparé à se taper un moteur entier.
Car on parle bien de coût.
[^] # Re: Triste
Posté par barmic . Évalué à 3.
Déjà que pour grsecurity c'est mou comme cycle et contraignant (ça passe parce que c'est mis sur des serveur et que la communauté linux supporte ces versions pendant quelques années) pour un moteur HTML et un javascript qui évolue en permanence (il n'y a qu'à voir la fréquence de sortie de chrome, webkit est presque en rolling release) et le besoin pour les utilisateurs d'être toujours à jour (même si on peut se poser la question de la pertinence de ce besoin), je ne vois pas comment c'est gérable sans exploser en vole.
C'est surtout qu'il n'y a pas d'alternative. Un moteur de rendu HTML multiplateforme et embarquable, il n'y en a qu'un depuis que Mozilla a arrêter d'espérer faire de gecko un produit.
Je ne cherche pas à te démontrer et personne ne le peu. Il faudrait déjà savoir ce que compte faire Opera pour ça. Ce qu'on te dis c'est que c'est loin d'être sûr qu'ils vont y gagner. Ce n'est pas parce que le code est disponible que tu peut envisager de maintenir des patchs extérieurs sans en devenir fou (encore une fois même google a fini par arrêter).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Triste
Posté par Zenitram (site web personnel) . Évalué à 0.
Le problème est que eux pensent qu'ils vont exploser en vol dans tous les cas avec leur moteur seul dans leur coin. Donc ce n'est pas vraiment un argument.
Je m'excuse de croire plus leur croyance que la vôtre : eux y misent leur salaire, pas vous, et à mon avis, ils y ont bien plus réfléchi que vous (sans compter qu'ils ont un avantage sur vous : il connaissent la qualité de leur code, pas vous).
C'est quand même toujours surprenant : des gens qui ont regardé de loin et n'ont rien à perdre pensent avoir plus raison que les gens qui ont tout à perdre (leur boulot, rien que ça : tout le monde n'est pas Nokia avec un je m'en fou sur les salariés et faisons un deal pour s'auto-détruire). alors certes, parfois c'est vrai et les gens qui ont décidé le découvrent trop tard, mais ça arrive plus souvent de voir que ceux qui ont passé bien plus de temps à décider et surtout mise leur salaire ont raison.
[^] # Re: Triste
Posté par barmic . Évalué à 4.
Mais je n'ai jamais dis qu'ils vont se planter, juste que je ne les crois pas en mesure de garder une série de patch autour de webkit sans les faire intégrer à court terme. Pour eux c'est donc une dépendance au bon vouloir des commiteurs du projet webkit, mais je leur fait confiance ils arrivent bien à s'entendre entre Appel et Google ça devrait bien se passer.
Je suis surpris que cette annonce ne soit pas accompagnée d'une annonce de libération de Presto (puisque de toute manière c'est ce qu'ils vont faire découper des morceaux de leur moteur et les ré-implémenter dans webkits).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Triste
Posté par claudex . Évalué à 5.
Ils n'ont peut-être pas les droits sur tout le code.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Triste
Posté par Damien Thébault . Évalué à 2.
Il y'a aussi une branche "test" qui est actuellement en 3.7, qui est reprise notamment par gentoo hardened, que j'utilise actuellement et qui fonctionne parfaitement bien !
[^] # Re: Triste
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 1.
Du coup il ne reste plus que IE et Firefox qui ont un moteur différent de WebKit. Et donc un seul moteur open source, si on ne compte pas les projets plus petits comme l'excellent KHTML, Dillo, etc.
Ça risque de mettre encore plus un sacré coup à Gecko qui perds déjà pas mal de parts de marché face à WebKit…
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Triste
Posté par Olivier Serve (site web personnel) . Évalué à 7.
Certes mais à qui la faute ?
C'est dommage, mais c'est la conséquence directe d'un choix stratégique de la Fondation Mozilla. Elle n'a pas su anticiper la banalisation de l'emploi (et donc le besoin) d'un moteur HTML. En refusant d'investir dans « l'intégrabilité » de Gecko, elle a voulu garder son bébé pour elle-même. Du coup les gens vont voir ailleurs, comment le leur reprocher ?
# Analyse de glazou
Posté par Troy McClure (site web personnel) . Évalué à 9.
worth reading: http://www.glazman.org/weblog/dotclear/index.php?post/2013/02/13/Strange-day-for-the-Open-Web
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 3.
Je me demande s'il aurait écrit la même chose si Opera avait choisi Gecko…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par Framasky (site web personnel) . Évalué à 6.
Sans doute pas, mais ce serait parce que Gecko n'est pas en situation de monopole sur les appareils mobiles (smartphones, tablettes) et donc ne menace personne de mono-culture. Il aurait aussi pu remplacer IE par Firefox dans son argumentaire, ça aurait fait le même résultat (sauf que le titre ne nous aurait pas fait bondir).
Le problème avec webkit est le même qu'avec IE6 : "site optimisé pour…"
Tiens, Icinga, un fork de Nagios, a une interface mobile. Compatible webkit only, alors qu'ils utilisent sencha touch, un framework qui dit « Build universal, mobile web apps for any device and platform. ». Donc ils auraient pu faire un truc universel, ils l'ont pas fait parce qu'ils se sont concentrés sur Webkit. D'où le danger de la monoculture webkit.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Analyse de glazou
Posté par Jux (site web personnel) . Évalué à 3.
Autant je veux bien qu'on trouve regrettable que Webkit devienne un quasi-monopole, autant la comparaison avec IE6 me semble à côté. IE6 c'était une implémentation fermée avec des comportements peu rationnels et des plugins (ActiveX) infâmes. Webkit, même en monopole, ça reste une implémentation ouverte basée sur des standards. Même si c'est pas la concurrence idéal avec 10 moteurs de rendu différents chacun à 10% de parts de marché, c'est quand même pas comparable.
[^] # Re: Analyse de glazou
Posté par Framasky (site web personnel) . Évalué à 6. Dernière modification le 13 février 2013 à 20:08.
Je suis d'accord avec toi, c'est pas tout à fait la même chose, mais on va quand même finir avec des "site optimisé pour…" qui laisseront de côté les autres navigateurs.
Typiquement, l'exemple de la version mobile d'icinga. Et ça c'est mal.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à -1.
Même si ça arrive, je ne vois pas vraiment le problème. Webkit est libre, n'importe qui pourra s'en servir pour son navigateur.
C'est pas comme si tout le web devenait à la merci d'une seule compagnie : Webkit est libre pour tout le monde.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par Framasky (site web personnel) . Évalué à 1.
Bah, manque d'innovation par exemple ? Pendant combien de temps on s'est traîné les boulets d'IE6 ? Les dév veulent développer (enfin, j'espère) pour un standard, pas pour un moteur de rendu. Parce que le jour où il y a un nouveau navigateur trop bien de la mort qui tue et que tout le monde se rue dessus, mais c'est con, il prend pas les css commençant par -webkit, il faudra tout refaire.
Que webkit innove, ok, qu'il ait pendant un certain temps des trucs spécifiques, ok, mais il faudrait vite les standardiser ces trucs spécifiques, sinon on arrive à la situation décrite ci-dessus : les dév vont faire du -webkit, sans doute parce que ces nouveaux trucs -webkit pas standard fait des trucs trop cools, comme un nyancat qui se fait monter par une licorne invisible rose sur toute la page, et du coup on récupère un web pour webkit, les autres ont qu'à aller se faire foutre avec leur navigateur de merde.
C'est aussi pour éviter ça que Mozilla pousse la standardisation de l'API javascript de Firefox OS (vibreur, appels, contacts, toussa) : pour que les dév fassent une page html+css+js et que ça puisse communiquer avec tout téléphone/navigateur implémentant cette API.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 3.
Encore une fois, si le manque d'innovation gêne quelqu'un, ça va forker et puis c'est tout.
Comment vous pouvez comparer Webkit avec IE6 qui était :
* propriétaire ;
* en situation de monopole parce que préinstallé sur 99% des PC neufs ;
* un navigateur web complet alors que Webkit n'est qu'un moteur dont l'interface peut parfaitement être innovante ;
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par barmic . Évalué à 2.
Ça ne change rien au problème.
webkit est dans 90% des navigateurs
On s'en fout à l'époque d'IE6 aussi il y avait des navigateurs autre que IE6 avec le moteur trident comme maxthon ou avant browser. Le problème venait du moteur html le reste, parce que c'est lui qui emprisonne (c'est lui qui rend le web visible uniquement d'un moteur donné).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 0.
Justement si, on peut forker et porter sur d'autres plate-formes.
Ce qui fait combien de part de marché ? Certainement pas 90%, IE et Fx étant encore très bien placé.
Au passage, vous vous plaignez que ça tue la concurrence, mais pourtant Fx et IE existent sur plate-forme mobile. Donc au contraire, ça la stimule.
Alors comparez Webkit avec Trident, pas avec IE6. Et d'ailleurs, ça n'a pas empêché Firefox d'avoir du succès. Comme quoi, non, la situation ne risque pas d'être bloquante.
Mais je reconnais qu'il y a une grosse différence : IE6 n'était que sur Windows, alors qu'on a des navigateurs Webkit sur toutes les plate-formes aujourd'hui : même Haiku et E17 en préparent chacun un, et jusqu'à Symbian, pourtant en fin de fin ! Donc je vois encore moins le problème :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par claudex . Évalué à 5.
Ça fait plus de 80% des navigateurs de smartphone. Donc, tous les développements mobiles sont fait pour Webkit et c'est tout.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à -1.
Encore une fois : où est le problème, puisque Webkit est disponible partout ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par claudex . Évalué à 5.
En tant qu'utilisateur de Firefox sous Android, je peux témoigner que ça fait un peu penser à l'époque Firefox 1 sur PC, même si ce n'est pas encore aussi grave. Entre les fois où tu n'as pas la version mobile parce qu'elle est distribuée en fonction de l'UA, et les fois où la version mobile est dégueu parce que la CSS est faite à coup de -webkit-, c'est vite pénible.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 2.
J'ai moi aussi utilisé Firefox sous Android. Et à mon avis les plus gros problèmes, ce ne sont pas les incompatibilités (que je n'ai jamais vues), c'est la lourdeur horrible de Fx, tant pour les sites que pour l'interface.
Si Fx a percé face à IE, ce n'est pas pour son support du web, c'est surtout pour son interface et sa légèreté. Sur Android, on en est loin.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par Framasky (site web personnel) . Évalué à 2.
Essaye une beta, une aurora ou une nightly, la question de la lourdeur n'est plus là (ou si peu).
Quant à l'interface, c'est une question de goût et de couleurs, mais personnellement, j'aime beaucoup ce qu'ils ont fait.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Analyse de glazou
Posté par ✅ ffx . Évalué à 1.
Le problème est d'obliger des gens qui n'ont pas envie d'utiliser webkit à l'utiliser
[^] # Re: Analyse de glazou
Posté par Gof (site web personnel) . Évalué à 1.
Obliger qui ? Et comment ?
Personne n'est obligé.
[^] # Re: Analyse de glazou
Posté par claudex . Évalué à 5.
C'est comme à l'époque d'IE6, tu n'étais pas obligé de l'utiliser. La comparaison tient toujours.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à -1.
Même si c'est le cas, tu n'es pas pour autant lié à un navigateur, un système ou une plateforme matérielle.
Il y a tout de même suffisamment de choix dans tous ces navigateurs Webkit pour ne pas en trouver qui plaise.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par claudex . Évalué à 4. Dernière modification le 14 février 2013 à 17:48.
J'ai (un peu) cherché, mais je n'ai pas trouvé de navigateur libre suffisamment rapide et à jour, avec un vrai adbock et des onglets verticaux à la Tree Style Tab autre que Firefox pour le desktop. Et pour le mobile, je cherche un navigateur qui peut se synchroniser avec mon Firefox sur le desktop.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Analyse de glazou
Posté par pasBill pasGates . Évalué à 0.
Comme tu avais le choix entre les navigateurs bases sur le moteur de rendu d'IE6…
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 1.
Oui, mais je n'avais pas le choix de l'OS (Windows only) et peu de choix pour la plate-forme (celles que Windows supportait à l'époque, si je me souviens bien x86, IA64 et Alpha).
Webkit est quasiement sur tous les OS (même Symbian) et toutes les plate-formes.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par barmic . Évalué à 1.
Après de blocage où plus rien n'évoluait.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 4. Dernière modification le 14 février 2013 à 14:13.
Oui, mais à quoi était dû ce blocage ? Au fait que Microsoft était seul fournisseur et développeur de Trident. Sans concurrence, normal qu'il n'y ait plus d'innovation.
Mais ici, on est face à un logiciel développé par de multiples boîtes en concurrence (je dirais même féroce) : donc je ne vois pas comment il peut y avoir blocage.
Il y aura peut-être monopole du moteur, mais pas dans les navigateurs : il y en a tellement que la concurrence et l'innovation seront toujours là.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par barmic . Évalué à 1.
Violer les standards ça ne te dérange pas, toi ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Analyse de glazou
Posté par groumly . Évalué à 2.
aaaah, ca va!
Si le w3c arretait de se branler la nouille, peut etre que les gens y feraient plus attention aussi. Le standard est auto proclame, pour autant que je sache, le w3c n'a pas mandat d'elu par le monde pour diriger le web.
Si ses membres les plus ardents commencent a se barrer ailleurs, c'est ptetre qu'il ya un probleme de ce que cote la aussi non?
Tu peux pas d'un cote prêcher la competition parce que c'est bien et que ca favorise l'innovation et force a se sortir les doigts du cul, et par derriere te plaindre que ceux qui ont innove raflent la mise et que ceux qui se sont pas sorti les doigts sont dans la merde.
La question des brevets est un faux argument, la question est pas de savoir si ya une monoculture webkit, mais de savoir si la voix de chacun est ecoutee par le projet.
Vu que ce sont deux companies en guerre thermonucleaire qui dirigent le projet et qu'ils arrivent a se mettre d'accord, j'ai envie de dire oui.
Glazman a beau jeu de faire la pucelle effarouchee, il a des billes dans gecko et forcemment ca l'arrange pas trop d'avoir rate le virage mobile. Et ca va appeler sa boite disruptive innovations par derriere, nan mais serieux…
Et la plupart de ceux qui se plaignent dans ce journal sont du genre a avoir tente de foutre du firefox partout ya 5 ans et revaient de voir FF a 90% du marche, alors ca va les lecons de morale rigide, hein…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Analyse de glazou
Posté par barmic . Évalué à 4.
Il est reconnu par les acteurs du web (soit en y contribuant soit en respectant leur standard). Ça suffit de facto.
C'est facile de beugler contre le w3c aujourd'hui alors qu'on était bien content qu'il soit là lors de la première guerre des navigateur et après.
Google quitte le w3c ? Si tu veux juste dire qu'ils implémentent des choses en dehors des normes, je n'y vois personnellement aucun inconvénient, mais il faut une volonté de standardiser les choses. Ce que j'ai critiqué c'est de se contenter de la première partie sans chercher à standardiser les choses. C'est le genre de trucs qui donne flash, silverlight, les activeX et les applets java. Je ne crois pas qu'il y ai grand monde pour dire du bien de ces techno aujourd'hui.
Et le w3c c'est quoi ? À minima 3 compagnies qui sont à couteau tirés.
Je n'apprécie pas particulièrement Glazman de manière général.
Non personnellement, mon idéal se placerait à 1/3 pour les trois moteurs (webkit, gecko et trident), avec de la place pour tout nouveau moteur. Je préfère quelque chose qui respecte un standard que quelque chose de libre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Analyse de glazou
Posté par windu.2b . Évalué à 4.
3 tiers + de la place pour un autre ? On croirait revivre un dialogue de Marcel Pagnol… :-)
[^] # Re: Analyse de glazou
Posté par groumly . Évalué à 3.
D'un autre cote, le w3c a gache pas loin de dix ans sur le xhtml avec le resultat grandiose qu'on lui connait. Pendant que d'autre bossaient sur des trucs qui interessaient les gens.
C'est facile aussi de dire que le w3c c'est parfait parce qu'ils ont pondu des standards ya 10 ans. Force est de constater que le w3c a merde sur le xhtml, a persiste sur le xhtml2.0 et que si c'etait pas pour le whatwg, ils y seraient encore ces cons. Et encore, va falloir attendre 2014 pour qu'ils en fassent une recommendation.
Ben moi je prefere un truc libre qui met tout le monde d'accord qu'un truc qui respecte un standard juste pour le principe de respecter un standard.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Analyse de glazou
Posté par barmic . Évalué à 5.
Le xhtml était une bonne idée pour avoir quelque chose d'un peu mieux foutu est plus simple à parser que le html. Ça aurait bien simplifié les moteurs de rendu et simplifié la vie de weboob (ou des libs qu'ils utilisent).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Analyse de glazou
Posté par groumly . Évalué à -1.
Clair que forcer le monde entier a generer du XML 100% valide sous peine de tout peter, c'etait une idee grandiose et super realiste.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Analyse de glazou
Posté par claudex . Évalué à 1.
Si seulement il existait des outils pour générer du XML valide.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Analyse de glazou
Posté par groumly . Évalué à 0.
Parce que c'est evidemment super simple a integrer a tous les workflows, et aucun developeur n'a jamais fait la moindre erreur ni ecrit le moindre bug, c'est bien connu!
C'est sur que si tu fait un site web a la papa, statique comme en 99, c'est plus facile, si tu commences a toucher au dom ou prendre du contenu utilisateurs ou qui voent d'ailleurs, ca devient plus tordu.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Analyse de glazou
Posté par Moonz . Évalué à 7.
Les développeurs font des erreurs (et même des erreurs de syntaxe qu’un compilo pourrait corriger tout seul !), et pourtant dans tous les autres domaines les compilateurs n’ont aucun problème à te péter à la gueule si tu respecte pas la syntaxe du langage. Le monde des développeurs ne s’est pas pour autant écroulé, et une telle rigueur permet même de faire des choses très sympas (refactoring par exemple).
[^] # Re: Analyse de glazou
Posté par windu.2b . Évalué à 6.
Si prendre en compte du XHTML valide dans le Web d'aujourd'hui, où les pages se construisent à-la-volée (Ajax, …), te parait compliqué, qu'en est-il alors du même Web avec du (X)HTML pas valide, mais qui doit quand même être compris et rendu correctement par les moteurs (X)HTML ?!?
[^] # Re: Analyse de glazou
Posté par Moonz . Évalué à 7.
Ça pose pourtant problème à personne pour les suites bureautiques (OOXML/Oasis), les protocoles (XMPP), la doc (Docbook), les webservice (XML-RPC/SOAP), une partie du web (RSS/Atom), les images (SVG)…
[^] # Re: Analyse de glazou
Posté par Eric P. . Évalué à 2.
Je suis tout a fait d'accord avec toi, ca me parait aberrant d'autoriser les erreurs de code.
D'ailleurs je pense que tous les navigateur devraient afficher une notification disant: "Attention, le site web toto.com n'est pas conforme aux standards du W3C, ce qui peut causer des problemes dans l'affichage ou l'interactivite des pages". Pas un popup bloquant comme la fameuse erreur javascript d'IE, mais une notification apparaissant en dessous de l'URL. Peut-etre que les sites penseraient a leur image et corrigeraient plus vite.
Par contre en ce qui concerne le XML strict pour pouvoir utiliser n'importe quel parseur XML, la situation n'est pas tout a fait identique a celle d'un document bureautique par exemple: si une page HTML pese plusieurs mega octets (tres longue liste…) et que la connexion n'est pas trop rapide, l'utilisateur s'attend a voir le navigateur commencer a afficher la page meme si la fin du fichier n'est pas telechargee. Donc le navigateur risque de devoir commencer a afficher avant d'avoir les balises fermantes.
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 2. Dernière modification le 14 février 2013 à 11:55.
Ben ça tombe bien, on a ici un truc libre qui respecte un standard et qui met tout le monde d'accord :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par Framasky (site web personnel) . Évalué à 2.
Et qui implémente des trucs non-standard qui ne sont pas proposés à la standardisation assez vite pour que ça ne fasse chier personne.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 2.
Si c'est pour faire mieux, j'avoue qu'on peut se poser la question.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par barmic . Évalué à 2.
Flash aussi était là pour faire mieux (en tout cas pour faire des trucs pas faisable autrement).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 1.
Donc en attendant d'avoir une norme, on a eu Flash qui comblait le manque. Je ne vois pas le problème.
Aurait-on Youtube aujourd'hui s'il n'y avait pas eu Flash ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par barmic . Évalué à 3.
Et ceux qui souffrent d'handicap disent merci à cette techno qui leur a permis de se passer du web pendant des années, ceux qui ont pris des malware aussi en sont très content ainsi évidement que ceux qui ont vu leur batteries fondre à vu d'œil sous l'effet d'un swf un peu chargé.
(après coup c'est marrant de voir des utilisateurs de logiciels libre content de flash)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 3.
Donc parce qu'on peut faire un mauvais usage d'une technologie, c'est que cette dernière est mauvaise ?
Euh, j'ai jamais vu un cas de malware dû à Flash. Par contre, des malware sans Flash, j'en ai vu quelques un.
Ben oui, même si c'était pas parfait il faut bien reconnaître que Flash a pu apporter des usages qu'on n'avait pas avant. Et je n'en suis pas content en tant que tel, mais je suis satisfait qu'il ait lancé la problèmatique de la balise video, par exemple.
Au passage, la comparaison est encore une fois biaisée : Flash était propriétaire et géré par une seule boîte. Webkit est libre et gérée par plusieurs boîtes concurrentes.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Est-ce que youtube est une bonne chose?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Analyse de glazou
Posté par Framasky (site web personnel) . Évalué à 1.
Oui : http://youtu.be/oHg5SJYRHA0
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Analyse de glazou
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
Messieurs les moinsseurs, Flash n'est pas nécessaire, la
preuve.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Analyse de glazou
Posté par Gof (site web personnel) . Évalué à 2.
[^] # Re: Analyse de glazou
Posté par oinkoink_daotter . Évalué à 2.
De mémoire c'est faux. Il y a encore des vidéos qui n'ont pas été recodées avec le codec qui va bien du coup bim le player html5.
[^] # Re: Analyse de glazou
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu dois avoir un problème avec la notion de temps.
Flash est apparu car il manquait la balise "video" qui a pris des plombes avant 'être impélmente sans Flash, pas à cause du WebM vs H264 ou que sais-je, qui n'est qu'un détail.
[^] # Re: Analyse de glazou
Posté par barmic . Évalué à 4.
Ouai, enfin il n'a pas était fait pour faire du streaming vidée. Il a était fait pour faire un peu de tout (avoir une approche plus application), le fait qu'il soit beaucoup utilisé pour lire des vidéos ne doit pas cacher qu'il a aussi beaucoup servi à faire des jeux vidéos ou des applications. Si le but avait était d'afficher de la vidéo ils auraient pu le faire plus simplement et il y avait avant flash des greffons qui permettais de lire des vidéos en streaming.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Analyse de glazou
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Même sans balise dédiée, on peut parfaitement distribuer des vidéos via le web:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à -2.
Génial. Donc faut télécharger toute la vidéo même si tu ne veux voir que quelques minutes au milieu.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par barmic . Évalué à 4.
Ça dépend. Le streaming passe par exemple sur vlc et le seek je ne sais pas ça doit dépendre du format de vidéo et de la configuration du serveur web, non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Analyse de glazou
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 5.
Quel danger ?
C'est pas comme si Webkit n'était disponible que pour une plate-forme sur un type de matériel précis. Combien de navigateurs utilisent Webkit ? Et ça n'est pas prêt de s'arrêter : combien y'en aura-t-il à l'avenir ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par barmic . Évalué à 1.
Ça tue la concurrence. Moi j'utilise firefox, d'autres utilisent IE et ne veulent pas changer parce que ça leur convient et que ce qu'ils veulent c'est accéder au web et pas au web by webkit (quand bien même webkit est libre).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 2.
Pas du tout, ça force la concurrence à s'adapter. Rien n'empêche Mozilla et Microsoft de reprendre Webkit, d'ailleurs il y a déjà eu des posts des développeurs respectifs sur cette idée.
C'est aussi ça, le logiciel libre.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par barmic . Évalué à 1.
C'est un peu comme si tu disais qu'empêcher d'utiliser autre chose que Windows ça ne tue pas la concurrence ça la force à s'adapter rien empêche de passer à windows et de faire ces logiciels dessus.
Je parlais de concurrence des moteurs HTMl et tu me parle justement de créer un monopole. C'est comme si on disait que maintenant gcc fait ce qu'il veut du langage C et que de toute manière c'est aux autres de s'adapter (note il a des extensions GNU, je suis au courant).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 3.
Je n'arrive pas à saisir comment ton raisonnement déduit de mes propos que je souhaite empêcher quoi que ce soit.
Tout se fait suivant les qualités des logiciels, rien n'est forcé dans l'histoire : les développeurs et utilisateurs préfèrent le moteur Webkit, donc c'est aux autres de se poser la question du pourquoi et de mettre à la hauteur.
C'est un peu la base du libre, rien n'est forcé ou empêché. Et si ça ne convient pas à quelqu'un, il est toujours libre de forker.
Sauf que ce n'est pas GCC qui définit l'évolution du format C tout comme ce n'est pas Webkit qui définit les formats du web.
Et quand bien même ça serait le cas, ce sont des normes ouvertes : les autres seraient toujours libres de les implémenter puisque tout le monde y a accès.
Et encore une fois, personne n'est lié à rien à un fournisseur en particulier : Webkit est disponible sur suffisamment de plate-forme matérielles et logicielles, et comme il est libre, il peut être porté sur d'autres plate-formes.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par barmic . Évalué à 1.
Ben si de plus en plus de monde est lié à webkit.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 0.
Webkit n'est pas un fournisseur, c'est une technologie. Il ne te force pas à utiliser un navigateur, un OS ou un matériel spécifique, c'est cela que j'entendais par « fournisseur ».
Je n'ai donc toujours pas la réponse à ma question : en quoi est-ce un problème ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
C'est un problème parce que si webkit, donc son implémentation devient un "standard de facto", alors il n'y aura plus de raison pour que Google ou Apple poussent leurs "innovations" à la standardisation. Ils ont déjà prouvé par le passé que la standardisation, ils s'en foutaient un peu. Je pense par exemple aux API Audio, aux transformations et animations CSS et j'en passe : ils ont développé le truc, ils l'ont inclus dans une release officielle, et seulement après ils ont envoyés leurs gars au W3C avec un brouillon de spec. Et fallait voir les brouillons. Le truc écrit sur un coin de nappe. Sous-spécifiés à mort. À l'époque, ça ressemblait à du gros foutage de gueule.
Bref, le risque à terme, c'est beaucoup moins de standardisation au W3C.
Du coup, comment vont faire ceux qui veulent développer un nouveau moteur, en utilisant par exemple des nouveaux algorithmes et donc qui exclu de réutiliser Webkit ? Comment vont-ils savoir comment implémenter telle ou telle fonctionnalité ?
Par exemple, Mozilla développe en parallèle un tout nouveau moteur de rendu, Servo. Sa particularité et de repartir from scratch, afin d'avoir un coeur totalement multi-threadé : les différentes parties d'une page seront générées par de multiple thread au niveau graphique. Ce qu'aucun moteur de rendu HTML aujourd'hui n'arrive à faire. Gecko y arrive un peu ( Off Main Thread Animations , Off Main Thread Compositing etc ). Chez webkit, ils s'y cassent les dents.
Alors donc, une boite qui veut faire un nouveau moteur de rendu utilisant des techniques innovantes, comment fait-elle pour implémenter les trucs qui ne sont "spécifiés" que dans le code source de webkit (ou dans la doc pour dev web, mais une telle doc n'est jamais suffisante pour implémenter un truc à l'identique) ?
En regardant le code source ? Ça peut être une piste, mais c'est une grosse blague ! Grosse blague parce que déjà un truc aussi complexe qu'un moteur comme webkit, ça a plein de bugs. Et webkit est probablement celui qui en a le plus, n'en déplaise à tout ces partisans. Autrement dit, dans l'implémentation d'un truc qui n'a pas de spécification, comme séparer le bon grain de l'ivraie ? qu'est ce qui est bug, qu'est ce qui ne l'est pas ? L'affichage de la balise X dans un certain cas de figure a tel résultat bizarre : c'est normal ? c'est voulu ? c'est un bug ? ou c'est une limitation de l'implémentation ?
D'autre part, un code source ça peut être très complexe, et il n'est pas toujours facile, dans l'implémentation d'un algorithme, d'en déduire le fonctionnement de cet algorithme, pourquoi comment etc… Alors qu'il serait plus simple, pour faire une nouvelle implémentation, de lire une spec : on sait tout de suite que pour implémenter ceci, cela, il faut que ça respecte telle ou telle règle, que ça produise tel résultat etc. Ce que je veux dire, c'est que souvent, pour implémenter une spec simple, il faille faire du code monstrueux. Un exemple : la spec CSS est simple à comprendre, mais l'implémentation est monstrueusement compliquée (et c'est la raison aussi pour laquelle certaines propriétés CSS mettent des années à se standardiser : les développeurs de navigateurs peinent à trouver des solutions d'implémentations satisfaisantes, en terme de perf etc.. ça sert à rien de standardiser un truc qu'on ne peut implémenter, même si ça pourrait intéresser des milliers de dev web).
Bref, une implémentation, un code source, ne peut définir un standard, comme l'indique un gars ici.
Qui dit monoculture, dit moins de standardisation, dit moins de chance d'avoir des alternatives.
Et cette monoculture pourrait d'ailleurs bien se retourner contre webkit, si rien n'est spécifié officiellement : "webkit 2" refait from scratch, qui aurait un rendu identique avec "webkit 1", aurait du mal à voir le jour. Comme les autres quoi.
(rappel: dans un projet long terme comme Mozilla/Webkit, les équipes changent, les développeurs partent, le code reste, mais bien souvent sous-documenté).
[^] # Re: Analyse de glazou
Posté par Zenitram (site web personnel) . Évalué à 5.
Bizarre, Mozilla n'hésite pas à intégrer WebM et Opus, qui ont comme norme… un bon gros code source.
Ce qui fait tomber tout l’argumentaire, car il faudrait que cet argumentaire ne soit pas utilisé que quand ça arrange.
Webkit comme norme ne serait que ce qui est déjà accepté dans d'autres domaines : bizarre, quand je hurle sur WebM et Opus, pas foule pour dire que c'est horrible que ce soit une implémentation de référence, la réponse que j'ai est plutôt "c'est bien, on est préssé, t'as qu'à lire le code source, et il est la norme, fait comme lui, implémente les mêmes bugs si il faut". Ben voila, même réponse pour WebKit!
Bref : argument à géométrie variable.
[^] # Re: Analyse de glazou
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
Comme dans le commentaire du dessous, tu confonds motocyclette et poids lourds. Un moteur de rendu est un agrégat de technologies. Le code d'un moteur de rendu est plus complexe, de par sa taille et les technologies qu'il implémente, que le code d'un codec audio et video. Même si un codec, c'est tout de même complexe, ce n'est "que" l'application de formules mathématiques (j'exagère mais bon). Un moteur de rendu, il n'y a pas une spécification, mais des spécifications : les spéc CSS n'expliquent pas comment obtenir un résultat (ou très vaguement), mais ce que doit être le résultat. Du coup il y a plusieurs manières d'implémenter un moteur de rendu CSS.
C'est pour cela qu'un moteur de rendu HTML/CSS ne peut pas servir de norme ou d'implémentation de référence.
[^] # Re: Analyse de glazou
Posté par Zenitram (site web personnel) . Évalué à 3.
Effectivement : on arrive bien à faire des concurrents libres pour le web, par contre à la ramasse complet pour les codecs audio et video. (parait qu'Opus tient la route, certes, mais pour la vidéo c'est loin derrière)
C'est à se demander pourquoi ils ne pondent pas vite fait la spec si c'est juste une motocyclette.
C'est un peu insultant envers ce qui n'est pas ton domaine : d'autres domaines sont difficiles, aussi.
Je trouve "étonnant" que parfois, l'argument est valable pour la personne qui parle, parfois pas, suivant des critères des plus aléatoires, on ne sait pas trop d'où ils sortent. Non, c'est pareil : dans les deux cas, les specs sont importantes, mais "bizarrement" quand ça arrange pas trop, on les oublient. Dans les deux cas, il faut des specs car c'est exactement le même problème d’interopérabilité!
[^] # Re: Analyse de glazou
Posté par oinkoink_daotter . Évalué à 2.
Pour une réalité à géométrie variable aussi. Faut être gonflé pour comparer l'intégration d'un moteur de rendu et un codec video.
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à -1.
Mais bien sûr. C'est à demander ce que foutent les développeurs de VP8 et de Theora : qu'est-ce qu'ils attendent pour être au niveau de H.264 ? C'est tellement simple.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par oinkoink_daotter . Évalué à -1.
euh hein ?
je parle d'intégrer/utiliser un truc, pas de le faire évoluer fonctionnellement.
[^] # Re: Analyse de glazou
Posté par Adrien . Évalué à 3.
Si j'ai bien compris, tu critiques le fait que tout le monde veuille se baser sur webkit pour afficher des pages web. Il faudrait plusieurs moteurs, pour avoir de la concurrence pour que les moteurs respectent les normes.
J'ai plusieurs remarques sur tout ceci :
– je suppose que tu critique bien fort toutes les bibliothèques du genre libogg, libpng, etc. En effet, elle deviennent très rapidement en situation de presque-monopole.
– la concurrence améliorerait de façon globale les moteurs. Il me semble que au contraire, webkit (ou tout moteur libre) est très bon pour la concurrence. Il permet à tous de créer son propre moteur de recherche rapidement : il suffit de forker webkit et zou. Comment mieux stimuler la concurrence ?? Ça me semble largement plus préférable à une situation où tu as 5 moteurs complètement fermés qui contrôle le marché, et où il faut repartir de zéro pour faire un nouveau truc.
– Maintenir un moteur de recherche représente un coût et un travail sans doute important. Dans ce cas il me semble que mutualiser les efforts me semble aller dans le sens du progrès, puisque ça libère du temps pour faire autre chose : de nouvelles fonctionnalités, des tests plus poussés, se concentrer sur l'interface, etc.
– Sans être connaisseur, il me semble que le respect des normes HTML/CSS, etc. est surtout le fait des développeurs, qui utilise des trucs pas finalisé. Il faudrait donc se poser la question pourquoi ces gens-là ne veulent pas se conformer aux normes ? Les normes sont mal faites ? Ces gens sont des sagouins ?
[^] # Re: Analyse de glazou
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
libogg et libpng ne sont pas en situation de monopole, il existe des implémentations dans d'autres langages que le C.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Analyse de glazou
Posté par Adrien . Évalué à 2.
Ça tombe bien, il existe aussi d'autres implémentations de webkit… et webkit est loin de représenter 90% de « part de marché »…
[^] # Re: Analyse de glazou
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
malheureusement, ça reste la même base de code avec tout ses points forts mais aussi ses défauts.
[^] # Re: Analyse de glazou
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Tu compares des motocyclettes avec des poids lourds de 30 tonnes. Tu compares des projets de quelques (dizaine de?) milliers de lignes de code, avec des projets qui en font plusieurs millions.
D'autre part, OGG, png et compagnie, sont spécifiées. Il y a une spéc, indépendante de l'implémentation, qui permet à quiconque de réaliser une implémentation. De plus, ces spécifications ne bougent pas toutes les quinzaines de jours (ça se compte plutôt en années). Alors, à part réécrire une implémentation pour le plaisir tous les 3 mois, il n'y a pas forcément d'intérêt à forker.
Et dans mon post, je parle du cas où il n'y a plus de spec au niveau HTML &co. Ce qui risque d'arriver car les spec HTML/CSS et autre technos sont en constantes évolutions, à tel point qu'il y a plein de trucs pas spécifiés dans webkit.
Moteur de recherche ? c'est quoi le rapport avec un moteur de rendu HTML comme webkit ?
Et forker webkit ? si c'est juste avoir 1 patch ou deux, ok. Mais forker pour faire des développements lourds, cela nécessite alors des gros moyens. La complexité d'un moteur de rendu HTML/CSS n'est en rien comparable avec celle d'une lib ogg ou jpeg.
Oui et non. Si on veut standardiser, il faut deux implémentations (requises par le W3C), sur des bases de code différentes, si on veut pouvoir lever les problèmes d'une spécification. Cela est lié, encore une fois, à la complexité d'un moteur de rendu. Plusieurs implémentations valident le fait que cela est implémentable justement. Le fait que ce soit implémenté dans un projet ne permet pas de valider une spéc. Cela est déjà arrivé qu'un truc pouvait être implémenté dans un moteur et pas dans un autre, ou plus difficilement, à cause de l'architecture utilisée.
oui, mais ils ne devraient pas.
par incompétence. un vrai développeur web a conscience, selon moi, des conséquences de ne pas respecter les normes. Et donc, il ne doit pas utiliser des trucs expérimentaux, car il sait, quand il est compétent, que ce sont des trucs pas terminés, proprios, et donc qui ne fonctionnera pas dans les autres navigateurs. Pire, si c'est une feature qui devient standard, par exemple une propriété CSS, le prefixe -webkit-* (ou -moz-*) saute dans les versions suivantes du navigateur, et du coup la fonctionnalité utilisée sur le site n'existe plus. Bref, un site soit-disant "optimisé pour webkit" devient… non optimisé pour webkit. Un comble quoi.
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à 0.
Tiens, exactement comme le w3c et Webkit : il y a une spec indépendante de l'implémentation.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
spéc qui peut ne plus exister si webkit devenait l'unique moteur de rendu.
[^] # Re: Analyse de glazou
Posté par zebra3 . Évalué à -1.
Et alors ?
Si Webkit devient l'unique moteur, même sans spec, ben tout le monde l'utilisera et on aura le même rendu quelque soit le navigateur et la plate-forme. De plus, sa destinée n'est pas lié à une seule structure (comme celle de Firefox avec Mozilla soit dit en passant) mais à plusieurs boîtes, donc pas de dérives. Et on ne perd pas l'innovation puisque les navigateurs pouvant librement l'utiliser, ceux-ci seront obligés d'innover sur l'interface et les fonctionnalités pour se démarquer.
Au final, c'est bénéfique pour l'utilisateur et le développeur.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Analyse de glazou
Posté par Adrien . Évalué à 4.
Donc deux poids, deux mesures, suivant la taille du projet et la spécification plus ou moins mal foutu ? Si c'est un problème de spec qui bouge trop vite, le problème est alors du côté des faiseurs de spec non ?
J'aurais aussi pu citer Xorg comme exemple un peu plus gros…
[^] # Re: Analyse de glazou
Posté par Nonolapéro . Évalué à 3.
Servo, c'est prévu pour être intégrable dans d'autres navigateurs ou logiciels ou il sera dans le même cas que Gecko ?
[^] # Re: Analyse de glazou
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 0.
Je n'en sais rien pour Servo. Il n'y a pas de raison que cela ne le soit pas. Gecko est intégrable depuis la nuit des temps.
https://developer.mozilla.org/en-US/docs/Gecko/Embedding_Mozilla
Certes l'API est un peu vieillote et apparemment plus compliqué que pour webkit malheureusement. Des travaux avaient commencé pour simplifier tout ça mais ça à l'air au point mort.
[^] # Re: Analyse de glazou
Posté par Olivier Serve (site web personnel) . Évalué à 8.
WebKit a du succès parce qu'il répond à un besoin : avoir un moteur HTML efficace et facilement intégrable (niveau doc, technique, juridique et coût). Et il est le seul.
Si la Fondation Mozilla s'était sorti les doigts et avait vraiment promu Gecko dans une optique d'intégration, on n'en serait pas là.
À partir de là, soit Mozilla continue sur sa lancée, et ça ne fera que renforcer WebKit, soit un effort est porté sur l'intégration de Gecko et il est peut-être possible de remonter.
C'est peut-être regrettable, mais je ne vois pas comment on pourrait reprocher le choix de WebKit comme moteur aujourd'hui.
# Cluclu
Posté par Pierre-Marie D . Évalué à 2.
Justement aujourd'hui : http://pro.clubic.com/creation-de-site-web/langage-programmation/html-5/actualite-540606-standard-web-webkit-navigateur-css-html.html
Étrangement, d'après Clubic, Opéra n'est pas sûr de vouloir opter pour Webkit.
# Le raisonnement fallacieux envers Webkit
Posté par Anonyme . Évalué à 9.
Je trouve qu'il y a un raisonnement fallacieux de beaucoup de monde concernant Webkit et sa supposé domination qui ferait de Google et Apple les maître du monde d'internet.
Les gens semblent comparer Webkit à IE6 il y a quelques années, et c'est de ce point de vu là que le raisonnement est fallacieux, car les différences sont quand même importantes.
Webkit est un projet libre, et à la différence du propriétaire, la concurrence au sein du libre lui est plus néfaste que la convergence et la collaboration des différentes forces de développement, car cette convergence est profitable à tous dès l'instant que le projet est développé de manière ouverte et équitable, lorsque cela n'est plus le cas, il est possible à quiconque de forker les projets pour continuer à les faire exister selon une éthique plus juste et plus performante, le nombre d'exemple de projets forkés et aujourd'hui utilisés majoritairement est significatif pour en conclure que ça marche.
Pour comparer ce qu'on entends vis-à-vis de Webkit, cela serait comme considérer que la position de monopole du noyaux Linux face au noyaux BSD serait néfaste au développement de l'ensemble des écosystèmes informatiques. Or si la moitié des contributeurs de Linux n'allaient plus s'occuper que du noyaux BSD, on aurait sans doute un meilleurs noyaux BSD, mais la force de développement des noyaux se diviserait au lieux de s’additionner.
Ce raisonnement peut-être en parti contredit toutefois lorsque les paradigmes sont différents, par exemple dans le cas des bases de données, il est tout à fait pertinent de voir de la concurrence car il permet d'exploiter différents paradigmes de développement et d'usage, or concernant les navigateurs le but de chacun d'entre eux est de permettre l'affichage et l'interprétation d'un code de manière standard, la multiplication du code pour faire la même chose est du coup mathématiquement plus néfaste que bénéfique.
Je suis convaincu pour ma part qu'une convergence des différents navigateurs vers un même système de rendu libre (qu'il soit Webkit ou un autre), serait un très grand bénéfice pour le développement et donc pour les applications web, et malgré l'utilisation d'outils permettant d'uniformiser les comportements au seins des navigateurs comme LESS et autres réinitialisateurs css, le temps passé à faire en sorte que cela marche "partout" est considérable pour un développeur, et ne parlons même pas d'IE qui pour le coups est une véritable plaie mais qui semble être pour certains préférable à un outil libre qu'est Webkit. ( http://pro.clubic.com/chroniques/actualite-537878-chronique-anicet-mbida-vivement-internet-explorer-redevienne-leader.html )
Donc pour ma part, je suis enthousiaste de voir Opera adopter Webkit, et je pense effectivement qu'un apport de développeur au projet libre Webkit ne ne peut qu'être bénéfique.
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par Guillaume T . Évalué à -3.
Webkit est un projet libre, et à la différence du propriétaire, la concurrence au sein du libre lui est plus néfaste que la convergence et la collaboration des différentes forces de développement, car cette convergence est profitable à tous dès l'instant que le projet est développé de manière ouverte et équitable,
Le fait qu'Apple impose Webkit sur ces terminaux incite à penser que le projet n'est ni ouvert, ni équitable
lorsque cela n'est plus le cas, il est possible à quiconque de forker les projets pour continuer à les faire exister selon une éthique plus juste et plus performante,
Développer plusieurs branches de logiciel différentes à la base (gecko/webkit) est probablement plus pertinent que de forker webkit dans 6 mois
L'interprétation d'un code de manière standard, la multiplication du code pour faire la même chose est du coup mathématiquement plus néfaste que bénéfique.
Je suis loin d'en être convaincu par cet argument. Par ailleurs, l'intérêt d'un "code standard" est justement de permettre plusieurs solutions d'interprétation
Je suis convaincu pour ma part qu'une convergence des différents navigateurs vers un même système de rendu libre (qu'il soit Webkit ou un autre), serait un très grand bénéfice pour le développement
Tu peux sortir le même argument pour gnome vs kde, vi vs emacs, linux vs hurd, il en restera que ce que tu y gagnes, tu le perds en double sur pleins d'autres facteurs
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Ca montre surtout qu'Apple n'est ni ouvert ni équitable.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par groumly . Évalué à -2.
Ca montre surtout que vous savez pas de quoi vous parlez…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par Jux (site web personnel) . Évalué à 3.
???? Je ne sais même pas quoi tellement c'est du même niveau que "Le libre, c'est impossible de faire de l'argent avec".
Je demande sérieusement à voir sur le "perds en double". Linux est justement un bon exemple d'une monoculture qui marche assez bien. Et puis bon, les monocultures, dans le libre, lorsqu'elle ne conviennent plus, elles s'en vont assez facilement : GCC (pas trop extensible, LLVM s'engouffre), Apache (trop lourd pour certaines choses => nginx, lighttpd).
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par zebra3 . Évalué à 3.
Et alors ? Il n'y a pas qu'Apple dans la vie.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par Anonyme . Évalué à 5.
Merci pour cette démonstration de sophisme. Comme dit plus haut, sous prétexte qu'une entreprise impose une technologie libre dans ses périphériques propriétaire rendrait du coup la technologie non libre et son développement non équitable ? Pour moi la licence LGPL et BSD sont des licences libre, et le projet respecte les règles du logiciel libre.
Dans l'éventualité qu'il soit nécessaire de forker webkit dans 6 mois.
C'est bien pour cela que j'ai fais mention des paradigmes, on ne peut pas comparer un moteur de rendu avec un environnement de bureau ou un éditeur de texte, car ils apportent un concept ou une philosophie différente à l'utilisateur, ce dont n'a pas intérêt à faire un moteur de rendu qui doit être un outil n'ayant pour seul but que l'exécution d'une application fidèlement à ce que le développeur s'attend à obtenir.
Est-ce que les gens demandent à ce qu'il existe une concurrence dans les implémentations de python ou perl ? Non, parce que ça ne serait par pertinent, et ça n'empêche pas qu'il existe des tas d'implémentations de ces langages. Par contre dans le cas de java, on est heureux que openjdk existe, mais le jour où openjdk aura pris le pas sur le runtime d'oracle, est-ce qu'on entendra avec autant de véhémences qu'il ne faut pas laisser le monopole du runtime java à openjdk ?
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Non, ce n'est absolument pas une bonne chose.
D'une part pour les standards, pour la compétition avec d'autres moteurs. Faut pas oublier que le matos évolue. Webkit est déjà "obsolète" pour le matos actuel. Ex : pas de rendu threadé d'une même page donc n'utilise pas à fond les processeurs multicoeurs. Et pour que cela puisse être fait dans webkit, il faut réécrire au moins tout le layout engine. Et réimplementer toutes les features sous-spécifiées. Et donc s'attendre à des comportements différents sur ces trucs sous-spécifiés. Bref, voir mon post plus haut.
D'autre part, une monoculture webkit ne va rien arranger du tout dans ton travail. Il y a des dizaines de navigateurs différents qui utilisent… une version différente de webkit ! Rien que Chrome et Safari n'ont pas le même webkit. C'est la même base de code, certes, mais qui n'a pas le même "age", qui n'est pas patché pareil (coucou les extensions css proprio!), qui n'est pas compilé avec les mêmes composants (pile réseau, backend graphique…), et même pas avec le même moteur JS qui ne sont même pas au même niveau pour l’implémentation d'EcmaScript.
Bref, des dizaines de webkit dans la nature. Même si un jour Webkit est sur 99% des machines (tient, ça me rappelle une époque ça), tu continuera donc à faire des polyfills, des hacks css et des trucs tordus pour que ton appli qui marchait super bien dans Safari, fonctionne aussi super bien sur le dernier navigateur à la mode qui utilise webkit mais avec des patchs qui ne sont pas encore dans le dépôt webkit.
Mais pire que ça, si webkit est sur 99% des machines, tu te retrouveras avec les mêmes défauts, surtout au niveau du rendu ou CSS (qui sont les deux choses les plus compliqués à hacker/corriger). Tu ne pourras même pas avoir le bonheur de développer avec un navigateur alternatif qui n'a pas ce problème. Parce que faut pas te leurrer, un bug, même si y des milliers de contributeurs, il ne sera pas corrigé si l'architecture du moteur de rendu ne le permet pas (sans une réécriture massive du code). C'est déjà arrivé, que ce soit dans Gecko ou dans Webkit. L'un a des défauts que n'a pas l'autre et vice versa.
En clair, développer pour un unique moteur de rendu, c'est peut être se faciliter la vie sur certaines choses, mais c'est aussi subir pour d'autres choses. Et si un jour il n'y a plus d'alternatives, tu subiras encore plus, et peut-être même que ça pourrait devenir bloquant sur certains projet. Par ex, tu ne pourras même pas proposer à ton client, pour son appli intranet "installez tel navigateur, c'est ce qui correspond le mieux à vos besoins".
Le développeur web doit arrêter de faire de la merde, comme utiliser les extensions propriétaires (webkit-* et moz* etc).
Mais les navigateurs devraient aussi arrêter de fournir des trucs pas standards ou expérimentales dans les releases stables… M'enfin, d'un point de vue marketing, pour Google ou Apple, ça n'a pas de sens.
Et arrêtez avec ces histoires de fork. Forker un projet aussi gros que webkit, implique avoir une armée de développeurs pour suivre la concurrence sur les trucs "standards de facto" pour ne pas être distancé, et pour également développer les spécificités. Et sachant qu'un moteur de layout, c'est complexe, et cela nécessite des très bons développeurs qui ne courent malheureusement pas les rues… Bref, forker webkit nécessite d'être une supère grosse boite.
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par Anonyme . Évalué à 4.
Donc pour résumer ton commentaire, la monoculture webkit c'est pas bien par ce c'est trop diversifié, il y a trop de version de webkit differentes ?
J'adore.
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 15 février 2013 à 13:54.
Moi je n'adore pas ta mauvaise foi manifeste.
Avoir une seule implémentation de technos webs (une seule base de code), ça pue (surtout quand le code source est detenu et dirigé par des grosses boites comme Google et Apple).
Et malheureusement, même en ayant qu'une seule implémentation, ça ne résout en rien les problèmes actuels des développeurs (le fait de devoir faire du dev "cross-browser").
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par Anonyme . Évalué à 3.
Tandis que réimplementer son navigateur from scratch dans son coin c'est évidemment à la portée de tout le monde.
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 0.
où ai-je dit ça ??
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par zebra3 . Évalué à 3.
Nulle part, mais c'est ce qu'on déduit de tes propos lorsque tu dis qu'il faut des standards implémentables par tous. Si ce doit être implémentable, c'est bien pour faire un moteur de rendu, non ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
il faut des standards implémentables par tous, oui exactement. Au moins par ceux qui ont les moyens de monter un tel projet. Et si à terme il n'y a qu'un seul moteur de rendu non standardisé, comment ceux qui voudraient se lancer dans un tel projet pour X raisons, pourront le faire ? Comment avoir cette liberté ? La monoculture webkit, par ses conséquences, pourrait bien priver des développeurs de cette liberté d'entreprendre d’implémenter un nouveau moteur de rendu ayant une nouvelle architecture etc, puisqu'il y aura la difficulté de reproduire les "bugs" du seul moteur de rendu existant, bugs qui seraient au fil du temps devenu des "features" d'un standard de fait, non spécifié.
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par xcomcmdr . Évalué à 2.
Euh les threads c'est pas forcément un bon plan. Le gain potentiel versus complexité est à voir au cas par cas.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
La complexité dépend de la manière dont c'est implémenté, d'une part, et potentiellement aussi du langage utilisé. Bien qu'on puisse faire du multi-thread en C/C++ (langage utilisé dans Gecko ou Webkit), il n'est pas forcément le meilleur langage permettant d'exprimer de la façon la plus simple une architecture mutli-thread. On y arrive, certes, mais effectivement, cela peut être difficile et complexe à faire dans un truc aussi complexe qu'un moteur de rendu.
C'est pour cela que Mozilla se lance dans un nouveau moteur experimental, Servo, en utilisant un nouveau langage, Rust, incluant la notion de parallélisme dans son "adn", permettant donc à priori de simplifier les choses quand on veut faire du multi-thread.
# Hommage
Posté par kursus_hc . Évalué à 10.
[^] # Re: Hommage
Posté par xavier dumont . Évalué à 1.
C'est l'opéra de 4 sous, ton truc. Je comprends qu'il se refasse une beauté, avec une gueule pareille….
[^] # Re: Hommage
Posté par kursus_hc . Évalué à 3.
Pour mieux comprendre : http://knowyourmeme.com/memes/forever-alone
[^] # Re: Hommage
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Fallait être libre!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Hommage
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 6.
Aucun lien avec le moteur de rendu. Ils pourront continuer à innover sur ces aspects là avec leur interface.
Le seul lien avec le moteur de rendu. Mais réussir aux tests n'est pas une garantie de succès dans la vie.
Forcément, il est proprio. S'il s'était donné la peine d'être libre.
[^] # Re: Hommage
Posté par 태 (site web personnel) . Évalué à 8.
Le content blocker, c'est lié au moteur de rendu.
Mais bien sur ! Tous les développeurs web testent avec khtml mais aucun avec trident.
[^] # Re: Hommage
Posté par zebra3 . Évalué à 2.
En quoi ? Il suffit de dire au moteur de ne pas charger tel contenu, je n'y vois rien de spécifique.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Non
Posté par groumly . Évalué à 1.
1) apple n'interdit pas d'utiliser autre chose que webkit. Apple interdit le jit dans les applis pour des raisons de secu (trop facile de peter la sandbox sinon), ou plus exactement, ios n'offre pas la possibilite d'avoir des regions executables accessible en ecriture, ce qui exclue de fait tout jit.
Niveau moteur de rendu, tu fais ce que tu ceux, y compris engloutir un fric monstre dans ton moteur perso qui au final marchera moins bien qu'une UIWebView.
Pour le moteur de rendu, vu la qualite de safari mobile, personne n'est assez fou (ou idiot), pour utiliser autre chose que ca
2) sauf opera pour ios qui au dernieres nouvelles n'utilise pas webkit, mais leur technu de rendu deporte cote serveurs (faut bien tente de se differencier qq part), qui etait vaguement une bonne idee en 2009 mais qui est completement debile depuis fin 2009.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Se l'interdisent-ils à eux-mêmes ?
[^] # Re: Non
Posté par groumly . Évalué à 2.
Sorti de safari, qui n'est pas distribue sur le store, oui.
Les applis Apple sur le store n'ont pas a acces a Nitro, et yen a qq unes (une 20aine si tu veux tout savoir).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par Guillaume Denry (site web personnel) . Évalué à 2. Dernière modification le 14 février 2013 à 08:33.
Même pour son propre moteur ?
(grillé par Tanguy)
[^] # Re: Non
Posté par groumly . Évalué à 4.
Pour son propre moteur (Safari Mobile dans une UIWebView n'a pas nitro, la regle est la meme pour tout le monde sur le store, y compris apple, parce que oui, les mecs qui ont ecrit AppleStore ou iTunesConnect n'ont pas grand chose avec la team iOS), oui, pour le navigateur du systeme, non.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par Gof (site web personnel) . Évalué à 2.
De quelle sandbox tu parles ? Et comment le JIT peux faire peter cette sandbox ?
C'est à l'OS d'interdire l'accès à certains fichier ou APIs. Et le JIT ne peux pas passer outre.
[^] # Re: Non
Posté par groumly . Évalué à 0.
Ca pete toute la validation a priori de l'app store, et tu peux ensuite aller faire mumuse a droite a gauche sur le FS.
Dans le fond, iOS n'est qu'un macosx tournant sur ARM.
Sur le sujet de nitro, vu le parc deploye et le cote hautement personel d'un telephone, ca en ferait une cible de choix pour des personnes malintentionees en tout genre, Apple n'a pas envie qu'iOS devienne le windows XP SP1 de 2013.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par barmic . Évalué à 2.
Ils ont pas de sécurité dans leur conteneur ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Non
Posté par groumly . Évalué à 1.
Quand t'as 500 millions de devices qui font tourner l'OS, la motivation est grande, et la sécurité sera petee tot ou tard, surtout quand il suffit de pointer le telephone sur une URL avec du JS pourri. Imagine les degats rien que sur twitter ou facebook.
Regarde ce qui arrive a linux l'os le plus securise de la planete sur android. Entre les malwares et les sms qui foutent le telephone par terre, c'est pas particulierement joli.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par barmic . Évalué à 1.
C'est la même problématique qu'ailleurs. Les navigateurs, les machines virtuelles et tout les hyperviseurs ont se problèmes là, est-ce pour autant qu'ils n'y arrive pas. D'ailleurs j'ai appris récemment que :
Non et de loin, je pense plutôt à OpenBSD quand on parle de « l'os le plus securise de la planete ».
Pour les SMS foireux c'est arrivé sur une version masterisée par Samsung. Il ne faut pas croire qu'il n'y aura jamais de failles même sous iOS, la seule chose d'importante c'est de savoir comment est-ce que c'est géré par les développeurs (notamment combien de temps se passe entre la découverte ou l'utilisation de la faille et le moment où c'est corrigé chez les utilisateurs). À ce sujet Samsung n'a pas était terrible et c'est surtout occupé de très haut de gamme.
MacOS possède les jails qui sont assez bien réputé pour cloisonner des processus (jit ou pas).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Non
Posté par GaMa (site web personnel) . Évalué à 1. Dernière modification le 15 février 2013 à 17:41.
T'as des sources ? Ça m’intéresse.
Matthieu Gautier|irc:starmad
[^] # Re: Non
Posté par claudex . Évalué à 4.
http://www.arm.com/products/processors/technologies/virtualization-extensions.php
http://www.vmware.com/products/desktop_virtualization/mobile/overview.html
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Non
Posté par barmic . Évalué à 2.
La dernière conférence de la guilde du 5 février :
http://www.guilde.asso.fr/rencontres/20130205/
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Non
Posté par ndv . Évalué à 2.
apple n'interdit pas d'utiliser autre chose que webkit.
Si:
Apple won't allow a different web engine (like Gecko, which Firefox uses) on iOS
Source: https://support.mozilla.org/en-US/questions/945460
[^] # Re: Non
Posté par groumly . Évalué à -1. Dernière modification le 14 février 2013 à 10:03.
Et bien, tu dois pouvoir me pointer l'article des conditions de l'AppStore qui interdit explicitement ca?
Plutot qu'un mec sur un site de support communautaire qui dit que.
Je vais t'aider: la clause n'existe pas. Ou peut etre qu'opera a eu un passe droit pour etre sur le store?
Apple n'en a rien a foutre que tu utilise webkit ou pas, d'ailleurs je voudrais bien savoir comment ils feraient pour savoir si tu utilise webkit ou pas. Et quelle version de webkit? Un webkit modifie, ca passe? Mais est ce que c'est vraiment encore webkit si c'est modifie?
Ou peut etre que tu racontes des conneries tellement enormes qu'elles sont dures a croire?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par Jux (site web personnel) . Évalué à 4.
Bon j'ai pas de compte "Développeur Apple", donc je ne peux pas accéder à la toute dernière version, mais d'après ça :
Il y a d'autres perles d'ailleurs, genre
Putain de puritanisme
[^] # Re: Non
Posté par groumly . Évalué à 0.
T'as rate le point 1.1:
Je viens de verifier le vrai contrat, celui que j'ai signe, pas le blabla marketing qu'apple a sorti pour calmer les esprits ya deux ans, ils ne disent pas que tu dois utiliser webkit.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par Jux (site web personnel) . Évalué à 2. Dernière modification le 14 février 2013 à 11:24.
Un lien vers le vrai contrat ? Si tu es développeur, tu peux aussi nous fournir une version à jour des pré-requis pour développeurs ?
Vu le nombre de refus/lenteur dans leur processus d'approval pour leur App Store, je doute fortement que si tu viole une de leur directive (même si c'est pas une règle), ils te laissent passer.
[^] # Re: Non
Posté par groumly . Évalué à 1.
Le contrat, tu t'enregistres sur developer.apple.com et tu l'as. Je te filerais bien un lien, mais tu vas arriver sur une page de login.
Ensuite, j'aimerais bien savoir quelle experience tu as avec l'appstore, autre que les on dit de linuxfr.
Des pleureuses qui respectent pas les regles, yen a, des blaireaux qui cherchent leur minute de gloire sur internet et font du rafu, yen a aussi.
Des rejections fermes illegitimes, ca devient plutot rare, meme si c'etait un peu plus courant au debut. Ca fait 2 ans que je fais ca professionellement, 3 ans en tout, j'ai des dizaines d'updates dans les pattes, qq applis toutes neuves aussi, les rares rejections ont toujours ete argumentees et valides.
Et elles sont toujours basees sur le developer program agreeemnt, pas un document qui dit en premier lieu qu'il est pas contractuel et n'a aucune valeur.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par Jux (site web personnel) . Évalué à 4.
Je n'ai pas d'expérience avec l'app store, mais je ne vois pas ce que ça vient faire ici. Le document que je cite plus haut est celui qui donne les "guidelines" sur cette page :
https://developer.apple.com/appstore/guidelines.html
C'est même écrit "Ensure your apps comply with these guidelines before submitting them for review."
Ensuite, Apple ne permet pas le téléchargement/interprétation de code exécutable, ça va être difficile de faire un interpréteur javascript :
http://www.apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-Store-Review-Guidelines.html
Maintenant, si tu as des informations qui montrent qu'Apple ne fait pas respecter ses propres guidelines, on discute, mais sinon, c'est du vent. A moins dans ton expérience avec l'App store tu n'aies soumis une application qui inclu un moteur HTML, du JIT ou autre chose de "borderline" avec les guidelines Apple ?
[^] # Re: Non
Posté par groumly . Évalué à -1. Dernière modification le 14 février 2013 à 19:06.
Bon, ecoutes, c'est simple.
Tu t'enregistres chez apple, lit le contrat et reviens ici.
Tu peux citer toutes les pages que tu veux, chez apple et ailleurs, on s'en fout copieux, elles sont pas contractuelles, seul l'ios porgram agreement l'est.
Partant de la tu vas lire ce putain de contrat, ou tu las fermes.
Si t'avais de l'experience sur le store, tu saurais ce que tu peux ou pas faire, et t'aurais lu au mons en partie le developer agreement, plutot que de colporter des on dit mensongers.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par Jux (site web personnel) . Évalué à 3. Dernière modification le 14 février 2013 à 21:57.
De 1 tu ne me dis pas de la fermer.
De 2, je te cite des guidelines et un communiqué de presse d'Apple qui disent que tu ne peux pas changer le moteur HTML / Javascript. Toi, tout ce que tu as comme argument en réponse c'est "va lire le contrat", mais tu es bien incapable de me citer un seul passage du contrat qui contredit ce que je dis.
Y'a même John Gruber qui explique que Apple ne laisse pas d'autres apps accéder au runtime javascript qui fait du JIT et que c'est une raison pour laquelle les autres browser iOS (chrome inclus) sont plus lents que Safari.
Alors maintenant, soit tu sors des faits qui contredisent ce que je dis, soit tu arrête de te cacher derrière ta "connaissance de l'app store" et un contrat qui ne dit probablement rien d'autre que Apple se réserve le droit de refuser une application qui ne respecte pas les guidelines.
[^] # Re: Non
Posté par groumly . Évalué à -2.
Arrete de raconter des conneries, j'arreterais de te dire de te taire.
Ta page de guidelines dit explicitement: "Ce document n'a rien de contractuel, ceci n'est pas la list officielle des regles, juste des conseils qui aident a se faire valider. Referez vous au contrat pour avoir les règles".
Et oui, ne pas implementer un moteur de rendu complet aide a se faire valider.
Je ne peux pas te citer de passage du contrat parce que le contrat ne dit pas "tu peux pas utiliser autre chose que WebKit", ce qui est precisement le sujet de la discussion. Et c'est pourquoi je demande, en vain, d'avoir la partie qui interdit d'utiliser autre chose que webkit. J'ai cherche, j'ai pas trouve, et visiblement personne d'autre n'a trouve vu qu'il aurait suffit de me citer l'article pour me clouer le bec.
Oui, comme j'ai dit plus haut: iOS n'autorise pas des pages executables en ecriture. Ca empeche de fait d'implementer un JIT. Et c'est valable aussi pour les applis d'apple, c'est une limitation volontaire de la UIWebView.
Maintenant, je vois pas ce que ca a faire avec une interdiction d'utiliser autre chose que webkit, tout ce que ca dit, c'est que personne n'a acces a Nitro a moins de s'appeler Safari Mobile. Ca empeche pas de porter Gecko pour iOS et de l'utiliser pour Firefox Mobile.
Et entre nous, meme si je lit Gruber tout les jorus et que j'apprecie une bonne partie de ses commentaires, sur un point de vue technique, il est completement largue et ne comprends pas grand chose.
Oh! tu vas te detendre la. Celui qui doit appuyer ses faits, c'est toi, tu pretends qu'Apple interdit explictement qq chose, montre moi la regle explicite. T'es pas foutu de le faire parce que cette regle n'existe pas.
Commence par lire le contrat, il est au contraire tres prolixe, il fait 50 pages. Il ne dit pas "probablement" rien, il est au contraire plutot precis. Mais pour savoir ca, faut prendre la peine de se renseigner, plutot que de colporter des mensonges.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par barmic . Évalué à 8.
T'es entrain d'expliquer qu'ils ne t'interdisent pas de le faire, ils t'inderisent juste d'avoir des performances décentes, c'est ça ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Non
Posté par Jux (site web personnel) . Évalué à 0.
Ah donc leur guidelines ne servent à rien ? Pourquoi ils disent qu'ils ne veulent pas d'applis qui utilisent autre chose que Webkit si en fait ils les autorisent quand même ?
C'est pas parce que y'a noté "ce document n'est pas un document légal" sur leur guidelines qu'ils ne se basent pas dessus. Jusqu'à nouvel avis, les guidelines c'est tout ce qu'on a et si ils les donnent, c'est bien qu'ils se basent dessus.
Simplement, pour s'éviter des poursuites, ils marquent que ça n'as pas de valeur légal parce qu'il n'y a pas 10 juristes qui sont passés dessus.
On voit d'ailleurs que tu es très au fait du fonctionnement des navigateurs sur iOs . Tu n'arrives pas à nous trouver un seul exemple d'une appli qui inclu un moteur HTML autre que WebKit, Javascript avec JIT autre que V8. Mozilla dit que Apple ne veut pas, Opera passe par du rendu sur un serveur distant…
[^] # Re: Non
Posté par groumly . Évalué à 2.
Bon. Tu trolles tout ce que tu veux, tout ce que je vois c'est que t'es pas foutu de me sortir l'article qui dit que c'est interdit. Ca devrait etre facile pourtant, non?
Si la regle est si explicite que ca.
Mais tu fumes quoi serieux? ce qu'on a, c'est le developer agreement, tres clair et detaille…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par 태 (site web personnel) . Évalué à 3.
Opera mini ne contient pas de "web engine". Donc pas besoin de passe droit.
[^] # Re: Non
Posté par groumly . Évalué à -1.
Ben il permet de browser le web, donc il fait un rendu d'une facon ou d'une autre, et il utilise pas webkit, donc bon.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par Jux (site web personnel) . Évalué à 2.
Ils font le rendu sur un serveur et ils envoient le résultat au téléphone :
http://www.opera.com/mobile/specs/
[^] # Re: Non
Posté par ndv . Évalué à -1.
Hello, Apple fanboy. Tristan Nitot signalait la même chose, c'est le président de Mozilla Europe, pas un gus dans un garage qui poste sur un forum.
Petit rappel : pour contourner cette limitation, Opera a dû faire un navigateur sans moteur de rendu. Presto était déporté sur leurs serveurs, et le résultat était streamé sur l'application mobile. Malgré cela, Apple a trainé les pieds pour valider l'application a tel point qu'Opera a fait une page spéciale avec un compteur de jours depuis la demande de validation.
[^] # Re: Non
Posté par groumly . Évalué à 1.
Hello couillon!
Tistan nitot raconte parfois aussi des betises! Et je me fout de savoir ce que machin dit.
Bill gates a dit des choses aussi sur linux, et il etait ceo de msft usa, pas un gus dans un garage!
Je vais reiterer ma question un derniere fois.
Quelle clause du programm agreement interdit ca?
Pointes moi vers la regles de l'iOS program agreeement qui interdit de faire ca.
Tu peux t'enregistrer, c'est gratuit, t'as pas besoin de payer. Lit le contrat, montre moi la clause.
Booouuh! 3 semaines pour approuver un browser! Oh mon dieu! C'est un scandale!
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par El Titi . Évalué à 0.
Au hasard, le fait que tout doit utiliser les APIs d'Apple, ne pas embarquer de libs réutilsables et être ecrit en objective C.
Bref plutôt que de tout réimplémenter from scratch pour passer les exigence d'Apple, la raison l'emporte on adopte leurs briques.
[^] # Re: Non
Posté par groumly . Évalué à 2.
Je vais me repeter, mais bon:
- j'utilise un paquet des libs, cocoapods devient meme plutot poplaire ces jours ci
- je me demande ce que font ces qq millers de lignes de code c/c++ dans mon projet actuel si tout doit etre ecrit en objc. A se demander pourquoi apple a cree l'objc++ d'ailleurs.
Alors je vais reiterer: pointe moi la clause du contrat exigeant ca. Ou ferme la une bonne fois pour toute.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par claudex . Évalué à 2.
Il me semble que tu t'énerve beaucoup alors que tu ne montre pas plus que lui le contrat en question.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Non
Posté par groumly . Évalué à 3.
Probablement parce que j'ai une obligation contractuelle de pas le distribuer.
Par contre, il est vraiment pas dur a trouver si tu te donnes la peine d'utiliser un email jetable.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par barmic . Évalué à 6.
Si ça dérange les gens de chez Cupertino de diffuser l'information, il ne faut qu'ils soient trop surpris s'il circulent des infos erronées.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Non
Posté par groumly . Évalué à 1.
Ben d'un autre cote, le contrat est accessible en 5 minutes, suffit de s'enregistrer, c'est gratuit et immediat.
Mais pour faire ca, faut avoir envie d'admettre qu'apple n'interdit pas autre chose que WebKit, ce qui n'est visiblement pas le cas ici.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par barmic . Évalué à 2.
Si c'est pareil pourquoi ne pas le diffuser librement et pourquoi te donner des interdictions contractuelles ? Ça leur éviterais d'avoir de la désinformation ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Non
Posté par groumly . Évalué à 1.
J'en sais rien, tu peux demander a tim cook.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Non
Posté par Zenitram (site web personnel) . Évalué à -2.
C'est obligé d'être insultant et stéréotyper dès qu'une personne n'est pas d'accord avec toi.
"si tu n'es pas avec moi, tu es contre moi", mentalité de merde.
# Ouverture de Presto
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Le CTO d'Opera lance une hypothèse.
https://lists.webkit.org/pipermail/webkit-dev/2013-February/023841.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.