groumly a écrit 3282 commentaires

La première place revient à des visiteurs Linux n'utilisant pas une des distributions que tu cites.

La premiere place revient surtout a android. Ca change pas grand chose a son argument, la diversite c'est de la connerie, tu touches 95% des utilisateurs avec une petite poignee de distrib.

Apres, si tu veux aborder le sujet de la securite sous android avec un modele de permissions douteux et des constructeurs et operateurs qui freinent des 4 fers sur les mise a jour, on peut, et ca va etre drole.

Ah ben ca va vachement avancer la situation, les conflits bien gras, ya que ca de vrai pour résoudre les problèmes.

Potentiellement, faut aussi penser a remettre en cause les affiches elles meme, hein…

Mac/Win résolvent en partie le problème de manière radicale: chaque appli embarque ses .dll !

Non, ils resolvent le probleme en fournissant des libs de base stables, qui couvrent une grosse partie des besoins, et en laissant les devs tiers se debrouiller sur le reste. tu peux tout a fait faire une appli non triviale macosx qui ne depend d'aucune dylib. Tu sais tres exactement ce qui est dispo sur quelle version de macosx, et ca resoud la majeure partie du probleme.

Sous linux, la gestion des dependances est effectivement indispensable vu que le denominateur commun a toute les distribs, c'est la libc (et encore, zont pas toutes la meme).

Ton point étant ?

Rien du tout. Il aime bien gueuler, il a la rage contre la machine et tout, mais au final, c'est surtout du vent.

Je dit pas "le volume on s'en fout", je dit que le volume n'est pas la seule partie de l'equation.
En l'occurence, BPG ne resoud pas totalement le probleme du voyageur, tu vas toujours te faire extorquer sur les sms et les appels telephoniques aussi, BPG ou pas. Le probleme c'est pas la bande passante, le problème c'est ton opérateur.
Ne pas avoir accès au wifi en voyage, ca reste assez rare - tu dors bien quelque part, et ce quelque part a de grandes chances d'avoir un accès a internet. Les hotels ont un pc en libre accès a l'accueil, les gens ont tendance a avoir internet chez eux, bref t'as pas mal d'options. Reste des cas aux marges, mais ca reste exactement ca, des cas aux marges.
Je voyage 2 jours par semaine depuis 2 ans, le seul endroit ou j'ai pas du wifi gratos, c'est entre le bureau et mon hotel (bon, pas de wifi dans le metro non plus, mais sous la baie, ca va pas être simple).

L'autre façon de voir le probleme c'est que l'infrastructure réseau va évoluer plus vite que ca ne va prendre de temps pour deployer le format a un niveau ou il fera une difference. PNG a bien mit 10 ans a se deployer de façon universelle. A ton avis, a quoi ressemblerait l'infrastructure internet globale dans 10 ans?

Les problemes que tu décris vont se résoudre tout seul par un upgrade de l'infrastructure réseau avant que BPG soit complètement déployé. PNG a perce parce qu'il répondait a un besoin qui ne pouvait être satisfait (canal alpha + plein de couleurs), BPG ne parait répondre qu'a un probleme qui va se résoudre tout seul, c'est dur de justifier une migration, non?

Non, effectivement, ca m'est jamais arrive. Comme 99.9% de la population.

Tu ne fais qu'appuyer mon argument, c'est un cas tres a la marge, qui ne justifie pas l'immensité de la tache en soit.

Ils sont pas oblige de mettre ca dans chaque pub/bande annonce. C'est ca qui a pose un enorme probleme avec la bsd, devoir mentioner les auteurs qq part plaque dans le package, tout le monde s'en branle, c'est facile a faire.
Ne pas pouvoir faire la moindre pub sans mettre un acknowledgement long comme un jour pain c'est autre chose.

Vu que ce qui coute tres cher sur mobile, c'est la latence, et donc l'etablissement de la connexion (les bandes passantes sont plus que raisonable, une fois la latence absorbee), va falloir une putain de difference pour combler la difference, et le cpu c'est pas gratos non plus.
J'avais visite la page depuis mon iphone 6 sur du lte plus qu'honnete, et je croyais que le format necessitait un plugin et ne s'affichait pas tellement ca a mit longtemps a se rendre. Et l'iphone 6 est pas degueu niveau cpu non plus.

Et non, on est clairement pas d'accord sur la majorite du sujet.
Ce que je dit c'est que le cout d'upgrader 100% du matos/soft existant est faramineux, supporte par des gens qui ne beneficient pas des avantages, et que donc le gain financier/technique est tres discutable. Une des characteristiques de jpeg/png, c'est que c'est supporte partout. Ca a deja prit 10 ans pour voir le png decemment supporte, et ca c'est fait parce qu'il avait un avantage majeur sur le gif (non, pas les brevets, la qualite pourrie du gif), et qu'il permettait des choses impossibles autrement (canal alpha + rendu decente). Si le seule argument c'est "les images sont plus petites", ca fait un peu leger a se mettre sous la dent.

Ca veut pas dire qu'on changera jamais de format, mais va falloir un peu plus que ca pour justifier la migration.

PS : et pas de chance pour ton argumentation, pour ce cas précis, il y a une lib JS qui marche chez tout le monde ou presque (reste quelques anti-JS, mineur, leur faute), donc même en pratique… Ca marche chez tes parents, comme quoi l'auteur a pensé à tout.

T'es pas bien ou quoi, t'as vu le temps de rendu en js? Au pifometre j'ai quasi une seconde de rendu pour une image chargee du cache sur un ipad dernier cri, qui est loin d'etre ramollo du cpu si on remet les choses en perspectives.
A ce compte la, non ca marche pas, et v'la le merdier si t'as plus d'une image sur ta page, vu le support exemplaire du multithreading en javascript.
Une image quelconque chargee en jpeg/png, c'est meme pas une miliseconde…

C'est cool pour faire une comparaison rapide, vu que tout le monde peut voir la difference de poids/qualite sans avoir un plugin des bois, mais sorti de ca, c'est de la folie pure et dure de deployer ca en production.
Sans compter que ca resoud pas le probleme de workflow, faut integrer le tout dans la chaine de production/management des images, et le monde des applis natives ou une librairie javascript, ben ca me fait une belle jambe.

Le cout pour sortir du traditionel jpeg/png est faramineux vu l'omnipresence de ces 2 formats, va falloir argumenter serieusement pour les remplacer, avec des bons arguments, sans compter que ceux qui payent (editeurs de navigateurs/os) ne sont pas ceux qui profitent (sites webs).

Tous les auteurs doivent etre cites, y comprit dans les "advertisment material". En gros, tu fait une pub pour "supermachin turbo 2000", t'es oblige de mettre "ce prduit utilise sooper dooper library" pour tous les projets bsd 4 clauses que t'utilise.

Ca devient tres vite un cauchemard legal, et les mecs du departement com' petent un boulon parce que ya 4 fois plus de texte dans l'acknowledgement qu'ailleurs.
Du coup ils ont fini par virer la clause, et la seul vraie obligation, c'est de maintenir la mention du copyright, et interdire l'utilisation des auteurs pour promouvoir un travail derive.

Yen a qui diraient que c'est vachement plus elegant et efficace que les 42 pages de la gpl, et ils auraient tout a fait raison. Yen a d'autre qui diraient que c'est un subtile lance de troll, et entre nous, ils auraient pas tout a fait tord non plus.

Et si ils ont abandonné les web-apps, c'est plutôt parce que ça les empêchait de contrôler ce que l'utilisateur pouvait installer, et donc monnayer l'installation des applis.

Ben voyons, c'est pour ca qu'ils se sont empresses de sortir ce qui est (et a toujours ete) de tres loin le meilleur navigateur mobile, avec un support exemplaire des specs depuis le tout debut.
Rappelle toi, au debut, la concurrence c'etait opera machin, avec un rendu effectue cote serveur, ont fait mieux pour l'interactivite. Chrome se de rouille tres bien, mais avouer ce qui est, les perfs sous android sont en deca de ce qu'offre ios.

Non, ils ont ouvert le sdk parce qu'ils se sont rendu compte du potentiel monstrueux qu'ils avaient entre les mains.
Et ils ont offert un navigateur complet, performant et respectueux des specs parce que les gens veulent un navigateur complet, performant et respectueux des specs. Lesdits gens ont ensuite choisi, et visiblement aussi bien les gens que les developeurs preferent les applis natives.

Une application en natif peut ne pas communiquer du tout ;-)

Gne?

Les développeurs pro sont justement ceux qui vont vouloir gagner de l'argent avec leur application : autant partir sur les plates-formes qui maximisent le profit : Android et iOS.

Oui, c'est un peu mon point, le projet est mort ne.

Ya un mode offline en html5 pour ca.

Donc réutiliser les mêmes technologies pour de telles application c'est plus simple et moins cher.

Tu negliges la qualite de l'ui. Une ui native, c'est < 5 ms de temps de reaction a un tap, un scrolling parfait, des animations a 60 fps sur tous les devices.
C'est probablement possible de faire un truc de qualite en js, mais ca demande vachement plus de boulot que pour du natif.

Le probleme c'est qu'entre temps, le monde natif a fait des bonds en avant monstrueux niveau facilite de developement, et a comble les trous que le web peine encore a comble (geo localisation/fencing, photo/video, gyroscopes, lecteurs d'empreintes, keychain, synchro dans le cloud, carnet d'addresse et autres, qualite/vitesse des animations, etc.).
Les developeurs d'applis natives ont mit la barre super haut, pendant que le w3c en etait a se demander s'il fallait ajouter h264 dans la liste des codecs supportes, ca a pas aide. Sans compter que la philosophie (tres louable) d'universalite du web, couplee a des navigateurs qui se remettent a tirer la couverture vers eux avec des api proprio (genre chrome) vient foutre la grouille la dedans.
Et le monde du dev web avec un nouveau frameowrk qui defonce tout wui sort tous les 6 mois aide pas non plus a attirer les gens et les aider a passer du temps sur les features plutot que la maintenance.

Dit autrement, en 2008, c'etait infiniment plus simple de faire une appli riche en js/html que ca ne l'etait en natif. Avec les attentes qui ont serieusement evoluees, la tendance s'est inversee.

Sans compte que la tendance actuelle niveau perf cpu, c'est plus les operations/secondes, mais les operations/watt, et la le web est tres severement a la traine.

Mais le premier, ça implique de gérer un serveur web correctement ainsi que les informations personnelles des gens qui l'utilise et donc avoir la confiance de ces derniers.

Je comprends pas, l'appli n'envoie pas plus d'info personelle si elle hostee par un serveur qui t'appartient. Un nignx, un cdn devant et ca roule, t'as pas besoin de plus. Mozilla pourrait meme proposer ca en service (gratuit ou payant, ca les regarde ca).

Ensuite, on est en droit d'esperer que firefox vise les developeurs pro, et pas pinpin qui a ecrit la 4200ieme calculatrice sur le store, telechargee par lui meme et sa maman. C'est pas delirant de demander que les developeurs web sachent configurer un serveur statique.

Ça fait un sacré terrain d'expérimentation pour tester ou découvrir de nouveaux trucs. Par exemple, les nouvelles api qu'ils veulent introduire.

Et donc ca justifie de develope un os complet et tout le merdier qui va avec, plutot que de mettre ca dans firefox directement? Quitte a mettre ca dans un build de dev?

Je comprends pas l'engouement a deployer des webapps via un store.
Ca regroupe les desavantages natif + web (sotre pete couille a gerer, deployment non controles et mauvaises performances), sans avoir le moindre avantage.
Ya pas de mal a faire des applis web, mais deployez les sur le web, ca vous rendra la vie plus simple.

Rajoute par dessus le fait qu'ils sont extremement en retard sur un marche qui est deja largement verrouille/domine par apple et google, ils sont tres probablement en train de cramer des ressources pour rien. Meme microsoft se casse les dents sur les os mobiles depuis 5 ou 6 ans, avec toute leur force de frappe financiere et marketing, je vois pas comment mozilla peut s'en sortir avec une solution inferieure aux 2 leaders, et sans partnership serieux avec des constructeurs hardware.

Bref, on en reparle dans 2 ans, mais mon petit doit me dit que ca va aller bien leur histoire.

Ben voyons. Le messager "d'origine" s'est fait griller au poteau par la bsd 4 clauses pourtant, qui est sortie avant la gpl.

La realite, c'est qu'il ya plusieurs mouvements, avec differentes motivations qui sont sortis de la soupe primordiale de l'informatique. Certains voient un grand interet a encourager la redistribution de code, d'autres considerent que la liberte de l'utilisateur est plus importante que tout.

Blabla, tu tournes autour du pot, au final tu dis rien de concret, a part enoncer des banalites vielles de 35 ans sans expliquer en quoi les choses sont mal faites, tout ca pour finir par un "j'expliquerais plus tard, j'ai la flemme la".
Mais bizarrement, t'as quand meme prit le temps de pondre un long commentaire.

Lancer le programme qui gère le réseau et le programme qui gère /dev fait partie de l'init, mais gérer le réseau et /dev ne font clairement pas partie de l'init.

Ca tombe bien, ils ne font pas partie de l'init, c'est pour ca qu'ils sont dans des binaires a part. Par conre, il semble qu'ils soient suffisament proche de l'init pour justifier une integration poussee avec systemd, ce qui est justement la discussion ici. Ca aide beaucoup que systemd soit au courant de ce qu'ils ont fait/ou ils en sont pour savoir ce qu'il doit faire ensuite.

Sisi, d'ailleurs c'est à cela que servent les systèmes d'init normalement : gérer l'ordre de lancement des programmes, comme tu l'as si bien décrit plus haut.

Tout le monde n'est pas d'accord, visiblement. Macosx a launchd, solaris smf. Meme windows le gueux a un fonctionnement similaire.

Parceque justement, si on veut que tout fonctionne bien il faut que « l'interface » soit claire. Il faut que le rôle du programme soit clairement établi.

Ah ben heureusement que t'es la pour accorder le peu de ton temps disponible a lennart et lui donner des conseils, parce qu'il y avait pas pense. D'ailleurs personne n'y avait pense.

Bon, maintenant que tu nous a rappele ce qu'on apprends aux etudiants a leur deuxieme cour d'informatique en deug, si tu passais a la vitesse superieure?
Prend n'importe lequel de ces 80 binaires, et explique nous en quoi son role est mal defini, et ce que tu ferais pour le definir plus precisement, ainsi que comment tu modifierais son interface.

Mais le système d'init n'est pas censé s'occuper du réseau, s'occuper de /dev, il est censé coordonner l'initialisation de ton système. Et la, c'est plus simple.

Oui, c'est sur que quand on remplace des actions concretes par une vague phrase qui ne veut pas dire grand chose, ca parait plus simple. Qu'est ce que tu disais deja sur l'importance d'avoir des roles clairement definis?
Tant qu'on y est , si tu pouvais nous expliquer en quoi sysv coordone quoi que ce soit, ca serait sympa. De ce que j'en sait, sysv coordonne pas grand chose, il se contente de lancer des scripts dans un ordre defini par l'utilisateur, qui se coordonent tant bien que mal eux meme.

Et d'ailleurs, en quoi le reseau et /dev ne font pas partie de l'init? Remplir /dev, ca parait etre qq chose d'assez important a l'init quand meme, non? Ca va etre vachement plus dur de demarrer si tes disques ne sont pas dans /dev, tu crois pas?
Et demarrer tes services reseaux, ton pare feu et ce genre de choses, ca marcherait pas un chouilla mieux apres que tes interfaces reseaux soient montees?

En quoi on aurait des interfaces plus claires?
Tu changes juste le nom du projet, ca va pas magiquement resoudre le probleme de l'interdependence intrinseque de tous ces composants. Au contraire, ca va juste rendre plus dure la tache de comprendre le tout.

Dit autrement, les 80 binaires ne sont pas le probleme, le probleme c'est qu'un systeme d'init moderne est complexe par nature. Gueuler sur lennart va pas changer grand chose au probleme, et on entends pas beaucoup de suggestion constructives, juste des gens qui gueulent que "pffouuulala, l'informatique, c'est dur de nos jours, c'etait mieux avant quand ca en faisait vachement moins".

mais systemd est trop complexe, trop gros (80 binaires qui font des choses totalement différentes et normalement indépendante : logind, udev, networkd, …)

Tu suggeres quoi alors?
Qu'on mette les 80 binaires en un? En quoi ca va arranger les choses?
Qu'on sorte les 80 binaires de systemd et dans leur propre projet? En quoi ca changerais la complexite? Ca revient juste a changer leur nom, ca va pas nous avancer des masses.
Qu'on se separe des 80 binaires tout simplement? Et que donc on se passe des fonctionalites des 80 binaires (qui servent bien a quelque chose quand meme, quoi que t'en penses).

En general, oui.

Ils prendront le probleme main une bonne fois pour toute.
En faisant une e-petition pour demander a lennart d'aller elever des chevres dans le larzac.