groumly a écrit 3293 commentaires

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.

il y a plus d'yeux, donc de chance de trouver et de corriger des failles de sécurités.

Debian openssl, apple ssl, heartbleed et shellshock en sont de parfait exemples, d'alleurs. Ou encore php (just formthe lulz).

Non, la realite c'est que personne ne relir le code parce que c'est chiant a mourir, et que c'est de toutes facons pas comme ca qu'on trouve la plupart des failles, et personne n'ecrit de tests parce que c'est chiant a mourir et que ca casse les builds.
La realite c'est qu'a moins de payer des gens a plein temps pour faire ce boulot, personne ne le fait. Libre ou pas n'est pas la question.

Tu veux dire que sur les autres distro, il manque ul?

si c'est de moins en moins utile parce qu'il y a de plus en plus de possibilité de faire de l'édition distante

C'est pas que c'est de moins en moins utile, c'est surtout que c'est une horrible idée de faire ce genre de choses. C'est jamais ok de modifier un fichier a la rache en remote.
Ton code, tu le modifies pas sur le serveur directement. C'est jamais ok de faire ca. Tu corriges localement, push et redeploies.
La config de tes serveurs, tu la modifies pas a la rache, un par un. Tu met a jour ton repo chef/puppet/whatever et t'applique ca sur tous a la fois.

Clair, quand on pense que c'est le peripherique avec lequel t'interagit le plus, faut etre vraiment con pour investir 110 dol sur plusieurs annees la dedans.

Tu peux rajouter south park dans les exceptions, au moins les premieres saisons. Admirablement bien traduit, et extremement bien joue, j'arrive pas a decider quelle version je prefere.

Blablabla. Des excuses a la con tout ca.
Tu veux faire la morale et chier dans les bottes des autres, c'est ton droit, mais applique ta morale stricte a toi meme avant de faire chier les autres.

e tente progressivement de m'en approcher

A bah ca va, tu te mouilles pas trop dis donc. Tu essayes (au lieu de faire), progressivement (donc t'essayes pas vraiment en fait au debut) de t'en approcher (donc tu veux meme pas y arriver, juste t'en approcher).
Ca valait bien un journal qui denonce, monsieur faites c'que j'dit, pas c'que j'fait.

Twitter n'accumule à priori pas de valeurs avec les données que ses utilisateurs lui donnent

Lulz. Ouais, et leurs actionnaires, ils sont motive par l'envie de faire un moyen de communication efficace et gratuit. Les pubs sont pas du tout ciblees, et aucune boite ne fait de pub sur twtter, de quelque facon que ce soit.

J'ai pas compris ce que tu voulais montrer dans ton exemple

Dans cet exemple, la partie interessante est planquee a 3 niveau d'indentation, dans 2 if. ton code gestion du cas ou tu ne veux rien faire est melange avec celui ou tu fais effectivement qqchose. Dit autrement, c'est beaucoup plus simple a relire un code qui dit "valide tes input et annule tout si ca va pas, puis fait qqchose", plutot que "si des conditions sont verifiees, alors fait ca, et suit toute la fonction pour apprendre toute a la fin que si pointeur est nul, alors on return la valeur qui a ete sete par defaut 20 lignes plus haut.".
Ton code est plus robuste aussi, tu risques pas de faire une connerie si t'es deja sorti de la fonction. Plus t'as de code entre la creation d'une variable et son return, plus t'as de chance de faire de la merde avec, c'est une variante du concept de "les seuls bugs que t'aura pas sont dans du code que t'as pas ecrit".

Je ne vois pas de cas où tu fais quelque chose de si secret que personne d'autre que ta fonction doit savoir ce que c'est (on parle de fonctions pures dans l'énorme majorité des cas)

Sans etre secret, on peut etre sympa pour ceux qui passent derriere et eviter de leur laisser une tonne de fonction a noms abscons qui ne sont appelees qu'a un seul endroit.

Ça n'oblige l'utilisateur à aller voir le code de la méthode que si tu n'a pas documenter la méthode, que tu n'a pas de convention pour ça et que ton langage ne t'aide pas.

Si t'ecris du code trivial tout seul dans ton coin, oui, c'est sur. mais c'est pas un cas tres pertinent. Les conventions, faut bien relire le code pour s'assurer qu'elle a bien ete suivie. Et mon langage m'aide beaucoup pour ce que je fais, merci bien, mais il ne resoud pas tous les problemes.

D'expérience dans la majorité des cas tu peux découper.

Ben d'experience, c'est pas le cas. J'ai des controlleurs qui font 80-100 lignes dans -viewDidLoad, et ya pas grand chose que je puisse y faire, a part dire au gars du produit d'aller se faire cuire un oeuf. J'ai essaye de les couper "setupThis, setupThat", et au final t'as un setup qui depend du resultat d'une operation au dessus, et t'as un gros merdier sur les bras. Soit t'as des signatures a la con, soit t'as une imbrication d'appel de fonction douteuses. Dans les deux cas, le code qui t'interesse est eparpille, et t'as au final rien gagne du tout.

Fonction trop longue, fonction trop longue c'est facile a dire ca. T'en foutrais moi des fonction trop longues.

Ca arrive regulierement d'avoir des fonction des 50-100 lignes de code qui ne peuvent etre divisee sans avoir des noms de fonction a la con avec des signatures des bois, exposer des methodes que tu ne veux pas exposer, meme en private, et se perdre dans un dedale d'appels. Les controlleurs dans une UI tombent souvent dans ce cas.

Sans compter le "rightward shift" et les declarations de variables en dehors du bloc quand tu veux checker tes input et faire un return null.
Et tu force le relecteur a se taper toute la fonction pour savoir ce qu'il se passe si un imput est null .

Typiquement:

Something maFonction(pointer *a)
{
Something = null;
If (a != nil)
{
Qqchose
If(qqchose)
{
Encore autre chose
}
}
return something;
}

Ca se reecrit tres bien en early exit, vachement plus lisible et tu finit pas a 3 niveaux d'indentation dans la partie interessante.
Desole pour l'indentation des bois, markdown me court sur le haricot ce soir.

Et les metro/stations, ils s'entretiennent tout seuls? EDF fournit gracieusement l'electricite pour l'eclairage et le chauffage?

Certains/beaucoup en abusent avec des trucs du genre
var foo = une condition plutot longue avec des && ? Un appel de fonction : une autre condition ? Qq chose : autre chose;

Tant que les 3 parties de l'operateurs sont triviales et tiennent sur une ligne, ya effectivement pas de raisons de pas l'utiliser.

Une question que je me pose depuis un bail, a chaque que j'entends cette expression en fait: c'est quoi au juste une "distrib au petits oignons"?
Nan parce qu'autant quand on parle de cuisine, j'ai une bonne idee, mais quand on parle d'installation/configuration de logiciels automatisables (et automatises), j'ai du mal a comprendre l'analogie.

tu peux hasher les regions et maintenir un compte de cette facons, pour ensuite ne garder que les 4-5 plus frequents.
Bon, après je sais pas si c'est ce qu'ils font en pratique, mais c'est tout a fait possible de tenir le compte sans tout stocker en clair.

je devrais parler au passé vu qu'elles ne sont plus du tout stockées à ma connaissance

Ya toujours un historique , limité aux 4-5 endroits les plus souvent frequente, sur le telephone. Tu peux le desactiver, evidemment.

Les sauvegardes itunes peuvent (et c'est meme recommende), etre chiffree, ce qui limite bequcoup la surface d'attaque. C'est pas le cas par defaut, cela dit, avec icloud, ca devient rare de voir des gens faire des backups via iunes.