Non, l'architecture de Wayland ne permet absolument pas de separer le tout. C'est juste impossible. Et c'est aussi pourquoi Wayland est fait de cette maniere pour corriger deux problemes majeurs de X : les inputs et la securite. Si ton composite manager commence a faire tourner ta fenetre, tu fais comment pour modifier les inputs sans que tout le flux d'input passe aussi par le composite manager pour subir la bonne deformation ? Meme question pour lutter contre le phishing et les keylogger, tu fais comment sans une cooperation fine entre le composite manager, le window manager et le systeme d'input ? Tu peux pas. Toutes les implementations sures, efficaces et fonctionnelle de Wayland seront monolytique.
Approcher le developpement avec des dogmes, c'est pas une bonne idee. Il faut voir la situation et s'adapter au contexte. Pour le coup ne pas montrer de souplesse dans l'analyse et la solution d'un probleme technique n'est pas un bon signe…
Wayland, c'est le merge du composite manager, du window manager et de X. Je ne comprend donc pas ton "heureusement"…
De plus la conception de X lui a permit de tenir 20 ans sans etre reecrit. En informatique, je connais peu d'exemple qui ont tenu aussi longtemps en etant aussi centrale (Et X n'est pas encore remplace, Wayland est a encore bien deux ans de dev de pouvoir le remplacer). Surtout que X a ete cree du temps ou la majorite du probleme etait d'acceder graphiquement a des main frame. Alors que aujourd'hui, la majorite des usages sont dans l'embarque et la mobilite… Des trucs qui n'avaient meme pas ete envisage lors de la conception.
Je n'ai pas lu d'article detaille sur comment fonctionnait Blit, et l'histoire ne l'a pas retenu, donc je ne peux me prononcer dessus. Mais clairement critiquer X… J'attend de voir ou sera le soft que tu ecris dans 20 ans et comment il aura evoluer, si il survit jusque la ! :-D
Oui … Et là n'est pas la question. Ici, on parlait de principes architecturaux, pas d'utilisation.
Il va falloir que tu demontres a des developpeurs experimentes que ton principe KISS va fournir un meilleur resultat… Le principe KISS est souvent sorti dans deux situations :
- quand on affronte une horreur sans queue ni tete et qu'on ne peut pas faire autrement que tout jeter.
- quand une personne qui n'a pas assez d'experience ne comprend pas ce qu'elle a en face d'elle.
Le probleme, c'est de faire la difference entre l'un et l'autre.
Sinon il y a plein de cas ou le fais de separer entre process pose des problemes. Perte d'information, de cache, difficulte de detecter finement les erreurs, efficacite generale and so on. Donc le principe KISS, c'est comme les designs patterns, faut pas en abuser betement. Ceux ne sont pas des religions !
Joli de prendre X comme exemple ! Le probleme de X, identifie aujourd'hui, c'est que justement, il devrait inclure le Window Manager et le Composite Manager… Une belle demonstration par l'absurde que de faire une seule tache et la faire bien, n'est pas forcement en terme de design la meilleur solution. C'est un dogme, tout comme le principe KISS qui n'est pas forcement une bonne idee dans tous les cas.
Apple a ouvert la voie et le reste du monde tente tant bien que mal de suivre
PS : une différence avec systemd, c'est que les fichiers de configuration sont en XML, format standard et universel par excellence, ce qui est une preuve de plus qu'Apple a vu tout juste.
Si avec tout ca, tu n'es pas entrain de te rouler par terre, tu as vraiment des nerfs d'acier ! Moi pas :-D
Posté par cedric .
En réponse au journal udev forké.
Évalué à 2.
Wouhou, ca se transforme en troll sur DBus ! Bon, tu proposes quoi comme alternative a DBus ? Un truc libre, standard avec des outils et facilement integrable par tout le monde ?
A ma connaissance, il n'y a rien. Et non, faire des IPC direct a la mano avec les daemons, n'est pas une bonne reponse. Car cela duplique du code, rend difficile l'interoperabilite et l'ecriture de frontend alternatif.
Certe techniquement dbus, ca pourait etre plus lege, plus rapide, plus efficace, mais tu peux proposer des patchs pour ca. Je rappel, le code est libre et tous les utilisateurs de libdbus en profiteraient… Avantage d'avoir une brique comune !
Posté par cedric .
En réponse au journal udev forké.
Évalué à 4.
Elles interragissent reellement en profondeur avec systemd declenchant des evenements auquel des units peuvent reagir entre autre chose. Mais rien n'empeche une distrib de recoder un daemon qui a la meme API DBus. En fait techniquement, c'est la meilleur solution. Systemd fournit une infra qui permet au projet upstream de propager plus facilement leurs ameliorations dans les distribs en diminuant les acces a des fichiers ou des scripts custom.
Pour un projet upstream, c'est juste ideal. Je me plug sur l'API DBus, et je n'ai plus a avoir un truc custom par distrib. Forcement, ca facilite la vie de tout le monde, sauf ceux qui veulent etre different… A eux de developper leur demon de remplacement, c'est pas tres difficile en meme temps. Mais ca deplace clairement les problemes sur ceux qui les creent ce qui est une bonne chose.
Posté par cedric .
En réponse au journal udev forké.
Évalué à 5.
Wouah ! Une theorie du complot des distributions Linux commerciales ! Joli, j'avais pas encore rencontre une telle idee… Lennart, il aurait pas tue JFK ? Et ca serait pas ca soucoupe volante qui s'est crashe a Roswell ?
Posté par cedric .
En réponse au journal udev forké.
Évalué à 4.
Il y a une difference. Tu peux le faire toi meme. Il y a une doc, tu peux lire, apprendre, comprendre, verifier et agir.
La politique, c'est une autre histoire. Faut raconter aux gens ceux qu'ils veulent bien entendre sur le moment. Apres la realiter et les consequences ont peu d'importance.
Pour la finance, il y a clairement un manque d'information, de culture economique, scientifique et geostrategique importante qui fait que bon nombre de personne ne sont pas capable de comprendre ceux qu'on raconte. Entre autre chose, la speculation sur les matieres premieres a une influence minimal sur leur prix. A leur actuel, la principale raison de la monte du prix, c'est la rarefaction du petrole a bas cout…
Posté par cedric .
En réponse au journal udev forké.
Évalué à 8.
La difference majeur, c'est qu'une unite systemd peut etre fourni par le projet upstream et fonctionnera sur toutes les distribs. Ca veut dire moins de boulot dans la distrib, integration a terme plus rapide des nouveautes et teste plus large. Pour les mainteneurs, c'est un gain, pour les developpeurs, c'est un gain.
Non, c'est juste que systemd est une mauvaise idée.
Si c'etait une si mauvaise idee, pourquoi la majorite des gens qui font des distribs, developpe des plateformes ou developpe du soft sur Linux suivent le mouvement ? Ni upstart ni openrc n'ont reussi a gagner une tel attraction. Et ni Lennart ni Red Hat ne paye ces gens pour adopter systemd, ils le font parce que techniquement, c'est une meilleur solution que l'existent. Cela leur facilite la vie, leur permet d'avoir un systeme plus dynamique, plus maintenable et plus efficace…
Ensuite il y a un truc que tu n'as pas compris, Linux est base sur l'evolution. Tous les logiciels, les bibliotheques vivent et meurent au gres de l'apparition d'une concurrence plus efficace, d'une mainteneur plus motive and so on. Linux est un eco systeme ou les theorie Darwinnienne s'applique. Il n'y a rien de stable ad vitam eternam. Si la communaute dans sa majorite pense que d'aller dans une direction est mieux, c'est ce qui se passera.
Tu peux de maniere individuelle choisir de ne pas la suivre. C'est ton droit. Et tu peux le faire, tu as les sources. Mais il y a un prix a payer, le faire soi meme. A toi de choisir.
Je n'ai pas testé mais après avoir parcouru quelques forums sur l'utilisation de WebOS sur un Palm Pré et une tablette Touchpad il ne me semble pas que l'autonomie s'écroule plus que ça par rapport à un smartphone/tablette iOS/Android. Si Facebook est natif sur iOS par exemple c'est surtout parce qu'une application native sera toujours beaucoup plus rapide qu'une application web.
Chaque fois que tu utilises ton CPU/GPU, que tu fais une operation, tu consommes de la batterie. Avoir quelques choses de rapide, implique que tu utilises donc ta machine de maniere plus optimale et qu'elle peut plus rapidement se rendormir. Au final, tu as un lien direct entre rapidite et batterie…
Apres tu as aujourd'hui 3 composants qui consomment beaucoup, l'ecran (en fonction de la resolution), le modem (surtout en LTE) et le CPU/GPU. A charge de travail equivalente, le logiciel peut difficilement influencer plus que le CPU/GPU. Donc l'autonomie va directement dependre de l'importance de chaqu'un des trois dans la consomation. Je pense que sur une tablette, l'ecran est le premier consomateur. Sur un telephone, non LTE, c'est le CPU/GPU. Le natif donnera toujours un avantage quand le CPU/GPU a de l'importance, donc sur telephone (un ecran < 4") donnera plus d'autonomie. Sur une tablette, je n'ai pas fait de test, mais c'est peut etre l'ecran le plus gros consomateur…
Posté par cedric .
En réponse au journal udev forké.
Évalué à 2.
Difficilement et compare a la vitesse de l'equivalent windows, Linux est deja tres optimise. Le probleme principal, c'est que tu dois faire :
- destruction des anciennes pages
- chargement du nouveau programme
- chargement des dependences
- linkage
- initialisation du programme et des dependences
- execution
- retour du resultat
- nettoyage de la memoire
Forcement, face a juste execution + retour du resultat, tu as zero chance d'y arriver meme avec la meilleur volonte du monde :-) Ensuite systemd amene aussi d'autres amelioration, comme des optimisations entre les differentes taches que tu ne peux pas faire en shell vu que chaque process est isole. Et ainsi de suite.
J'avoue, j'ai jamais trouve le CSS ou l'HTML simple. Bon, JavaScript, c'est autre chose, clairement un langage tres pratique pour prototyper. Mais a partir d'une certaine taille de code, ca devient difficilement gerable.
Donc qu'est-ce que tu trouves dans les technos web qui font que c'est rapide a ecrire ? Tu t'y prend comment ? Parce que sans un toolkit comme JQuery ou PhoneGap, j'ai vraiment du mal et encore, le resultat ressemble soit a rien soit a qqc qui existe deja…
Bon, et sinon l'HTML dans le mobile, c'est une vachement bonne idee pour les vendeurs de batterie, mais pour l'utilisation au jour le jour, j'ai un doute… et je suis pas le seul, Facebook sur iPhone fait du natif pour toutes les taches commune et courante…
Posté par cedric .
En réponse au journal udev forké.
Évalué à 10.
Vous croyez que le merge de systemd et udev, c'est fait comment ? Lennart a debarque sur la ML de udev en prenant en otage les familles des developpeurs de ce projet ?!
Si udev a finit dans systemd, c'est que les mainteneurs de udev ont trouve que c'etait une bonne idee. Ils l'ont accepte et meme voulu, on merge pas du code par magie ! C'est un choix qui doit aider ces deux projets et les faire avancer plus efficacement.
Alors faut arreter avec vos theories du complot et vos histoires de restriction de liberte. Les developpeurs font les choix techniques qui leur semblent les meilleurs, si jamais ca vous convient pas faite un fork et prouve que vous avez raison en le faisant depasser l'original (C'est clairement l'objectif du fork de udev). Ce sera une competition technique et pas des idiotes theories complotistes qui veulent des rapports d'evaluation geostrategiques…
Posté par cedric .
En réponse au journal udev forké.
Évalué à 7.
Non, car le nombre de fork + exec ne diminuerait pas, le nombre de fichiers a acceder sur le systeme reste eleve, chaque unite de demarrage resterait complexe et dependante de la distribution. Au final, le shell restera toujours inefficace face a un programme qui fait toute l'init.
Sans compter que, avec systemd, il est possible d'optimiser beaucoup de chose. On peut, par exemple, arriver a generer un cache compose d'un unique fichier decrivant tout le boot. En terme de performance et d'efficacite, par design, un programme comme systemd a un avantage impossible pour un script shell a atteindre.
Oui, mais non. La mobilité n'a pas fait disparaitre le PC de bureau. Elle l'a complétée, mais pas remplacée. Exemple typique, l'iphone/ipad qui a besoin d'une machine apple pour fonctionner à 100%.
Tout comme les appareils photos numeriques n'ont pas disparu. Pourtant quand tu fais le touriste a l'etranger, la majorite des gens prends ses photos avec son smart phone. Il se vend plus de laptop que de desktop depuis 2007. Et depuis cette annee, il se vend plus de smartphone que de PC (laptop + desktop). L'impact, c'est que la technologie, les prix et la competition a lieu sur le segment le plus large. Si demain le seul marche sur lequel tu peux mettre Linux, necessite que tu payes plus que les autres, tu t'exclues mecaniquement. Et tu rend le renouvellement de ta communaute plus difficile. A terme, cela veut dire simplement le ralentissement du developpement de ta plate forme…
Donc meme si quelque chose ne disparait pas, sur le long terme, ca peut etre tres penalisant. Mais comme je l'ai dis, on est au debut du mouvement, le remplacement n'est pas pour tout de suite.
Juste enorme! Linux a toujours eu une réputation de sécurité au contraire de windows.
La reputation ne fait pas la realite. C'est vrai sur le serveur, sur le desktop, c'est une autre histoire. Lorsque tu demarres une application qui accede a X, tu n'oublies jamais que tout ce que tu tappes et tout ce que tu vois, peux etre intercepte silencieusement par n'importe quelle application. Et ce n'est qu'un debut, les fichiers personnelles sont accessibles par toutes les applications, les services dbus utilisateurs aussi, … La protection de Linux sur le Desktop, c'est qu'il est fragmente et qu'il n'y a pas assez de monde pour justifier l'effort de l'attaquer. Mais ca n'empeche pas d'etre critique sur la situation.
Je pose une vraie question: comment est-ce possible qu'en 2012 un linuxien réclame plus de sécurité et un store???
Tous les developpeurs d'application ont un probleme avec les distributions. Elles mettent du temps a integrer les packages. GNOME estime que cela met 6 mois pour etre package. Ce qui veut dire que quand tu as des bugs reports, cela arrive 6 mois trop tard. Et GNOME est dans une bonne situation avec une demande forte des utilisateurs, donc une update rapide. Il y a des applications/bibliotheques qui ont des annees de retard dans certaine distribution. Sans compter les distributions qui ont du mal a faire un packaging correct. Mais ca peut aussi etre pire, tu as les utilisateurs de Gentoo qui adore jouer avec les flags de compilation et qui comprennent rien a ce que cela implique dans le resultat. Enfin il y a aussi une perte du lien entre le developpeur et l'utilisateur, donc un probleme de communication qui peut resulter en une deconnexion entre les utilisateurs et les developpeurs.
Voila pourquoi GNOME reflechit a GNOME OS par exemple. Ca resoud ce probleme. Apres certaine distribution, je pense uniquement a Arch, mais il y en a peut etre d'autre peut etre, arrive a fournir un bon resultat (qui repond au probleme precedent). Malheureusement tout le monde n'a pas le temps de faire une install Arch, ni ne veut forcement l'utiliser. Et ca, le store, repond a cette problematique… En tant que developpeur, je ne vois meme pas comment on peut ignorer ce probleme.
Tout d'abord, merci pour ta réponse intéressante et argumentée.
De rien et merci a toi de partager ton point de vue. Participant au projet Enlightenment, c'est une discussion on ne peut plus interressante pour moi.
Je connais et j'admire MagicInk, mais je ne pense pas que ces applications soient aussi répondérantes aujourd'hui que tu le dis. Dans les logiciels que j'utilise tous les jours aucune ne fait vraiment ça, à part le logiciel distant hébergé par Google (spécialisation des résultats de recherche, qui d'ailleurs me gonfle pas mal, et publicité personnalisée). Je ne crois pas qu'on puisse dire aujourd'hui que ça constitue la "grandes majorité des applications", en tout cas sur des distributions GNU/Linux classiques.
Tu mets exactement le doigt sur une lacune du monde GNU/Linux. Le cloud (via Google, Facebook, voir meme github) et Android qui vient globalement du meme monde, offre une plus grande integration et plus de possibilite d'etendre les fonctions d'une application que ne le permette des applications locales. Pourtant mon PC a acces a tous les cloud en meme temps et a plus de donnees personnelles stocke localement que n'importe lequel de ces services en ligne. Donc pourquoi les developpeurs ne font il pas plus pour integrer tout ca et faciliter la vie de l'utilisateur ? En fait, le projet KDE a pas mal d'avance dans le domaine (principalement parce qu'il redeveloppe toutes leurs applications), mais on est encore loin de ce qu'on peut juste imaginer aujourd'hui.
J'ai donc très peu d'expérience sur la conception et la structure de ces "applications contextuelles" et je peux difficilement en dire plus sur comment les intégrer à ces modèles de sécurité. Je suis cependant confiant du fait qu'on pourra le faire quand elles se développeront (l'idée est d'isoler le composant qui construit le contexte pour le faire tourner dans un processus à part ayant des droits spécialiser, et de travailler sur son interface avec les autres composants pour qu'elle ne transmette pas trop d'information).
Idee interressante. En gros, on obtient un modele ou on a un grabber qui aura des droits particuliers et sera en mesure d'extraire l'information pour la presenter aux applications. Ca complexifie clairement le code et augmente la consomation de ressource, mais faut voir si cela a un impact important au final. C'est une idee a creuser, voir plus bas.
Quand je regarde les applications que j'utilise aujourd'hui (un navigateur web, un éditeur de textes/programmes, des programmes pour lire des images/musiques/vidéos, un client mail, un lecteur PDF, quelques jeux, plus tout le userland invisible qui fait tourner tout ça), elles sont toutes simples à sécuriser par une restriction de droits (approximative au début, puis de plus en plus fine quand les modèles de sécurité s'améliorent), sauf peut-être le navigateur web qui a en plus le problème d'être devenu un sous-monde à part au sein duquel les problématiques de sécurité/compartementalisation se re-posent. Mais je reste confiant qu'un modèle même relativement simple permettrait de réduire de plusieurs ordres de grandeur la surface de la Trusted Computing Base.
Le client mail est loin d'etre simple, c'est le premier composant d'une suite de communication et il doit etre a terme capable de fournir un contexte fort en nourrissant, calendrier, carnet d'adresse, todo, im, … en information pertinente. A partir du moment ou tu commences a ajouter des fonctions de communication et de contexte facilement integrable dans une application externe, tu peux imaginer les scenarios suivant :
Dans ton editeur de code, tu as une ligne de code que tu ne comprend pas, tu veux en discuter avec l'auteur. Tu fais un petit tour dans le menu contextuel, celui-ci te propose de discuter avec l'auteur sur IRC ou par IM en utilisant les informations fournit par Git, ton carnet d'adresse et ton client IRC/IM.
Tu ouvres un PDF depuis ton client mail, ajoute des notes dedans, puis repond au mail precedent. Ce serait plutot utile si le client mail pouvait t'afficher les notes prises dans ton lecteur de PDF.
Tu recois un lien via une discussion dans un mail. Tu navigues un peu dans le site. Puis tu reviens dans le mail pour faire une reponse. Ce serait interressant de pouvoir afficher une arborescence du sites visite de maniere a pouvoir mieux ce souvenir de ce qu'on voulait repondre.
Tu te souviens que suites a une discussion avec quelqu'un en particulier, tu avais fait une recherche qui t'avait donnee un resultat interressant. Tu ouvres ton carnet d'adresse, clicke sur la personne et tu as acces a l'historique de toutes les actions que tu as fait en rapport avec cette personne. Il devient ainsi facile de retrouver le resultat que tu cherchais.
C'est juste des idees, mais tu peux imaginer le meme genre de scenario avec ton IM, IRC ou les SMS. Aujourd'hui, ils n'existent aucun environnement qui fournit ce genre d'infrastructure. Les plus proche sont Android et KDE. Mais ils ont tous les deux des problemes de securites de mon point de vue. Maintenant si on developpe une telle suite de communication, il est absolument necessaire de penser comment realiser la securite de l'ensemble, sans impacter les performances (faut que ca tourne sur n'importe quel machine a peu pres moderne du smartphone au desktop en incluant les netbook) et en ayant une UI qui facilite le plus possible la vie de l'utilisateur.
D'ailleur, je pense bien que c'est un gros fail de Apple de ne pas permettre ce genre de fonctionnalite. Mais bon, on verra si le futur ira dans cette direction ou non.
Pour moi ce n'est pas au calendrier d'indexer mes mails mais plutôt au client mail de prévenir le calendrier s'il détecte un événement; ou alors à un démon externe de faire la médiation entre les deux. Dans tous les cas le processus calendrier n'a pas besoin des droits sur mes mails.
Hum, un demon externe en charge de processer les mails, voyons les problemes. Comment peut-on etendre l'analyse du contenu des mails ? Est-ce qu'un langage de script sera suffisant ? Ou faut-il inclure aussi la possibilite d'avoir des modules binaires ? Comment tagger automatiquement les images inclus en piece jointe en passant dessus un OCR ou une reconnaissance faciale ? Dans quel langage serait ecrit une IA qui comprendrait le contenu meme du mail ? Je pense que tu as maintenant une idee plus precise des contraintes.
Pour moi dans un bon design il y a des cycles de conception avec une discussion entre les concepteurs du modèle de sécurité et les concepteurs des applications.
C'est ce que l'on fait ici :-) Bon, j'avoue j'ai hijacke ce thread a propos d'Apple…
l'utilisateur dans sa voiture il prend les tournants comme il veut, il ne cherche pas à comprendre ce qu'est le code de la route et pas le resepcter
Meme avec la peur de la police et le risque pour sa propre vie, un certain nombre d'individu se comporte de maniere particulierement idiote sur la route.
l'utilisateur qui veut stocker son argent il le donne au premier type venu qui promet de le lui rendre, il ne cherche pas à comprendre si le type est de confiance
Pour le coup, c'est clairement ce qu'on fait avec nos banques quand on place de l'argent. On fait aveuglement confiance a son banquier qui s'est charge de faire la revue des produits financiers pour nous. Mais des fois il se fait avoir ou il est malhonnete et ca se finit au tribunal.
l'utilisateur qui sort de chez lui laisse la porte ouverte, lui demander de fermer sa porte à clé augmente de 50% les chance de le voir déménager
Sans vouloir etre mesquin sur ce coup la, une porte ferme a clef, ca ne stop pas grand monde … Et j'ai d'ailleurs souvent vu des gens qui oubliaient de fermer la porte de leur appartement quand j'etais encore a Paris. Donc faut pas trop compter sur ca non plus ;-)
par défaut les applications ne créent pas de danger, elles sont conçues de façon à ne pas avoir besoin de privilèges (donc pas besoin d'avertir); cf. l'exemple de départ où c'est un démon externe qui accède à l'arborescence de fichier
A mon sens, il y a tres peu d'application qui vont rentrer dans cette categorie. De mon point de vue, il y a 3 types d'applications :
les fart app, biniou marketing qui doit surtout pas acceder au reste du systeme.
les jeux, qui ont besoin d'information limite comme par exemple contacter explicitement un ami pour jouer avec lui, se connecter au reseau pour envoyer un high score et mon identite. Donc un niveau de droit d'acces plutot faible.
enfin la grande majorite des applications, celle qui etende le contexte des informations deja acquise. En gros, c'est application accede a des donnees privees, de maniere plutot automatise pour faciliter la vie de l'utilisateur, en extrait de l'information et en rajoute pour proposer des choix a l'utilisateur qui lui facilite la vie. Ces applications ont besoin de droit d'acces tres fin pour limiter les risques pour l'utilisateur et en meme temps de beaucoup de droit en fonction de leur tache.
Les applications de la derniere categorie etant celle specifique a ton environnement et faisant reellement la difference avec le reste du monde. Soit tu rend l'ecriture de ces applications tres difficile et tu vas laisser la concurrence te prendre des utilisateurs, soit tu leur facilite la vie (et surtout celle des utilisateurs). C'est donc une categorie extrement importante voir crutial pour la reussite d'un environnement. Pour une meilleur idee de ce que je decris, je ne peux que te recommander la lecture du mini livre de Brett Victor, Magic Ink (http://worrydream.com/MagicInk/).
les choix de sécurité sont le plus possible combinés à une action utilisateur qui fait avancer son travail. C'est tout l'intérêt de dire qu'on donne accès à l'application aux fichiers que les utilisateurs a explicitement ouvert : ça permet d'avoir une seule action "choisir un fichier et donner les droits à l'application" qui est utile, et pas un popup indépendant "l'application veut lire tel fichier, oui/non" qui se met en travers de l'utilisation.
Maintenant imagine une application de calendrier qui va indexer et parcourir tous tes mails a la recherche de possible evenement en piece jointe ou directement dans le contexte du mail. Le developpeur a explicitement demander l'acces a ces informations dans son package, maintenant quel question doit on poser a l'utilisateur ? Tu connais deja mon point de vue, aucune :-) L'application fait ce quel est sence faire, pas la peine d'ennuyer l'utilisateur avec un comportement normal.
Pour moi la partie "réduire les privilèges au maximum" est primordiale puisqu'elle a l'effet de réduire la zone d'attaque (TCB, trusted computing base) de plusieurs ordres de grandeur, en nous permettant de concentrer les efforts les plus coûteux (analyse statique, méthodes formelles de preuve de correction, etc.) seulement sur la partie critique tout en donnant de bonnes garanties de "pire cas" sur le reste. Et cette partie passe par des choix de conception qui mettent en jeu l'interface utilisateur.
Oh, je crois que je me suis mal fait comprendre. Je pense que toutes applications installe doit venir avec ces mecanismes de securite. C'est juste qu'a aucun moment, il n'est necessaire selon moi de poser une question a l'utilisateur.
Encore une fois, pour moi l'interaction avec l'utilisateur ça ne veut pas dire lui casser les pieds en permanence pour lui poser des questions de sécurité qui le distraient de son travail, mais plutôt savoir interpréter ses actions pour pouvoir gérer la sécurité de façon non-intrusive (il choisit un fichier dans le dialogue "ouvrir un fichier", donc il veut bien donner les droits dessus à l'application), tout en s'assurant que ces droits qu'il donne sont explicites et que l'application ne peut pas l'induire malicieusement en erreur¹.
Sauf que cela marche pour les cas simple, un editeur de texte par exemple, mais des que tu veux des choses plus automatise, comme l'exemple de mplayer, cela se fait a l'encontre de l'utilisateur. Alors dans le cas de mplayer, le systeme pourrait etre tres intelligent et donner les droits d'acces a des fichiers lie comme les sous-titre. Mais le probleme se posera a chaque fois qu'une fonction automatique sera ajoute pour simplifier la vie de l'utilisateur… Le systeme de securite de Apple manque donc de finesse et de contexte, et compense cela en mettant la pression sur l'utilisateur et les developpeurs.
Si il ne demandait que l'acces au fichier video a l'utilisateur et donner silentieusement l'acces qui va bien au sous titre, alors le systeme d'Apple serait bien concu de mon point de vue. Car il n'aurait a aucun moment pose une question de securite, mais juste un bon classique quel fichier afficher !
¹: un exemple est une forme de "fishing" au niveau de l'interface graphique; je suis un petit démon malicieux qui tourne en background et, quand je devine que l'utilisateur s'apprête à se connecter à un serveur par Putty, je fais apparaître une fenêtre popup qui ressemble comme deux gouttes d'eau à celle de Putty, en espérant que l'utilisateur mette le mot de passe du serveur dans ma fenêtre. On peut s'en protéger en forçant au niveau du systèmes de fenêtre que la provenance de chaque popup est claire pour l'utilisateur et ne peut pas être "camouflée" par les applications.
Sous windows, peut etre, sous Linux, c'est plus simple, tu grabbe en permanence le clavier sous X, meme pas besoin de fishing pour recuperer le mot de passe :-) Avec Wayland, on pourra nettement augmenter la securite et vu que le composite manager sera en charge de l'affichage et des inputs, on pourra faire des effets et affichage different entre les applications demandant un mot de passe et les autres.
Pour moi au contraire c'est la seule façon de faire les choses correctement : c'est l'utilisateur qui a les informations pour faire les choix de sécurité concernant ses données. Le modèle Unix est conçu pour protéger le système partagé de tous les utilisateurs, et les utilisateurs les uns des autres; il ne protège pas un utilisateur de ses propres programmes.
L'utilisateur, il cliques sur Ok pour que son application marche. Il ne cherche tres rapidement plus a comprendre pourquoi une application lui demande quelque chose. Il veut que ca marche et qu'on ne l'ennuie pas avec des questions superflues ! En ergonomie, chaque cliques augmentent de 50% les chances de perdrent l'utilisateur. Donc toutes questions de securite resulte en une mauvaise ergonomie. Ce n'est pas une solution !
En très grossier plus un modèle de sécurité est fin, plus il est difficile à faire comprendre à l'utilisateur—et donc paradoxalement il peut en être d'autant moins efficace. Pour un niveau de finesse donné il y a des efforts à faire pour obtenir un modèle à l'interface compréhensible. Il n'y a pas de secret, on y arrive en travaillant sur ces questions par itérations successives. Le modèle smartphone actuel de "le programme demande tel genre de capacités grossières, est-ce que ça vous semble raisonnable ?" est déjà un pas en avant. À mon avis on peut faire encore beaucoup plus fin en étant grossièrement aussi clair. Il faut repenser les interfaces pour que les concepts et bordures d'interface qui sont claires à l'utilisateur (par exemple "Mes Documents" et "Documents Partagés") correspondent aux bordures du système de sécurité.
Vu qu'on melange dans cette discussion deux problemes, comment interagir avec l'utilisateur et le proteger des applications malveillante et comment le proteger des failles de securite. Pour le proteger des failles de securite, c'est une problematique technique et un arsenal technique va clairement aider. Noyau et linker permettant de faire de l'adressage memoire aleatoire, canarie, analyse statique du code, privilege super fin de l'application (definit par le developpeur) et definition des sorties (en gros, quand il y a des donnees privees dans un fichier que l'application cree, le systeme en est informe et prend les mesures necessaires), virtualisation, secure boot et trusted computing. Avec ca le potentiel d'une attaque sur un systeme aillant une faille devient tres difficile et a aucun moment l'intervention de l'utilisateur a ete necessaire. Donc aucune problematique d'ergonomie.
J'aime aussi assez bien l'idee de faire payer les droits demander aux developpeurs. Plus il en demande, plus c'est chere… Mais ca, ca ne marche pas avec le logiciel libre.
Maintenant, pourquoi est-ce que l'utilisateur doit-il intervenir dans le process ? Le seul moment ou il a une decision a prendre, c'est quand il a installe une application. Et ca decision est simple, quel est le rating de l'application et combien de personne l'on installe ? Apres si il pousse un peu le truc, il lira aussi quelques reviews. A cette etape, il faut exposer l'information pertinente, savoir si l'application a ete auditer, si les droits sont logiques, si personne n'a eu de souci. Je ne vois pas pourquoi on ne fait pas la difference entre les utilisateurs qui ne comprennent rien a la securite et ceux que cela interresse. Je pense que vu qu'on cherche a resoudre un probleme humain, des gens qui ecrivent du code malicieux, il faut une solution qui implique des etres humains. Donc c'est au moment de l'installation que les informations pertinentes doivent etre afficher pour prendre une decision. Et il faut que ce soit simple a comprendre !
Et oui, je fais fondamentalement la difference entre un comportement attendu et l'utilisation d'une faille dans un logiciel existant.
Je ne vois pas trop ce que ça change du point de vue des dégâts causés à l'utilisateur, tu peux développer plus sur ce point ?
Le probleme est fondamentalement different meme si le resultat peut etre le meme. Dans un cas, tu as une tracabilite, avec la possibilite juridique d'intervenir dans l'autre tu es dans un cas anonyme et il faut des recherches plus ou moins pousser pour trouver un coupable. Plus le developpeur comprend que si il fait volontairement une betise, il sera identifie et penalement poursuivit, moins il prendra de risque sur la plateforme. Comme c'est un probleme different, il demande des reponses differentes. Et a aucun moment, on peut compter sur l'utilisateur pour prendre la bonne solution surtout sur une question complique.
En faisant cette difference, tu peux agir de maniere plus simple pour l'utilisateur sans le mettre en danger pour autant.
Je suis en desaccord fondamentale avec cette approche de devoir "crowdsourcer" la securite a un utilisateur qui de toute facon veut juste que ca marche et ne comprend ni la question ni pourquoi on l'embete avec ca, ca va rien donner. Apple a les moyens d'auditer le code, de le tester, d'agir promptement en cas de probleme et meme de poursuivre le createur du probleme en justice. La difference fondamentale avec le logiciel libre, elle est la. Apple ne peut pas avoir confiance dans les developpeurs de sa plateforme, donc il met une politique en place. Politique qui doit lui couter le moins possible. Aller au tribunal dans le monde entier ca doit couter bonbon, et il faut verifier que la creation de virus et autre malware est illegal pour que ca serve a quelque chose. C'est un probleme humain avant d'etre un probleme technique.
Tant que le logiciel libre passe par des distributions et offre un mecanisme lent de propagation des changements vers les utilisateurs (ce que sont les repository de distribution), alors on reste fortement protege du probleme. Et oui, on peut avoir confiance dans la tres tres grande majorite des developpeurs de logiciel libre. Mais le jour ou on ouvre la porte a un cycle court du type AppStore ou n'importe qui peut faire n'importe quoi. On a la meme problematique. Alors soit on emmerde l'utilisateur en le privant de fonctionnalite utile et on lui simplifie la vie, en mettant en danger ses donnees personnelles, soit on met en place une politique de securite tres contraignante a la Apple. Soit on y reflechit serieusement maintenant et on essaye de trouver une solution plus acceptable.
On peut imaginer que les applications indiquent au systeme quand elles enregistrent des donnees personnelles, utiliser de la crypto pour le stockage via un daemon dans lequel on peut avoir confiance (les kwallet et consort sont clairement pas designer pour la securite). On permet aux utilisateurs avance d'utiliser un LD_PRELOAD pour detecter les applications qui font des betises. On met en place un systeme de review different en fonction des gens qui font les checks de securite et ceux qui ne comprennent pas la question. On compile toutes les applications et le kernel par defaut avec tous les flags ameliorant la securite. Et surtout ON N'UTILISE PLUS X ! Alors dans ce cas la, on pourra avoir un AppStore sous Linux. Mais meme la, il faudra toujours un kill switch avec un moyen d'avertir directement les utilisateurs…
En attendant, la solution d'Apple ne fait qu'impacter ses utilisateurs en les privant de service utile sans reelement les proteger de quoique ce soit… Et oui, je fais fondamentalement la difference entre un comportement attendu et l'utilisation d'une faille dans un logiciel existant.
Sous MacOS, le systeme de fichier connait le mime type directement. Probleme regle pour eux :-)
Sous Linux, il faudrait qu'il soit automatiquement ajouter par le systeme lors d'un acces en lecture dans les attributs du fichiers, si il n'a pas deja ete evalue (Bien entendu en cas d'ecriture, l'attribut doit etre supprime). Utiliser un daemon et inotify pose des problemes de charge et des races conditions. Donc il faut un truc qui bloque ton appel systeme open/read si l'attribut n'est pas la et declenche une tache pour en faire l'evaluation et coller le bon label. Pas trivial et je ne pense pas qu'on est deja l'infra dans le noyau pour faire ca.
Financierement, c'est une catastrophe. Cela va finir de ruiner les anglais. Aucune ville d'un pays developpe ayant recu les JO d'ete n'a reussi a maintenir correctement dans le temps cette nouvelle infrastructure du fait des couts d'entretien. Dans le cas de Londre, les calculs de cout de fabrication ont ete minimise d'un facteur 2 ou 3, et les comptes sont deja dans le rouge au depart. Le resultat va etre sympa pour les impots des Londoniens…
Entre ca et l'etat policie mis en place pour l'evenement, heureusement que Paris n'a pas gagne !
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . En réponse à la dépêche Le point sur udev et systemd. Évalué à 2.
Ah la belle critique universitaire. Mais bon, elle resiste malheureusement pas au code sur le terrain. Va savoir pourquoi…
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . En réponse à la dépêche Le point sur udev et systemd. Évalué à 4.
Non, l'architecture de Wayland ne permet absolument pas de separer le tout. C'est juste impossible. Et c'est aussi pourquoi Wayland est fait de cette maniere pour corriger deux problemes majeurs de X : les inputs et la securite. Si ton composite manager commence a faire tourner ta fenetre, tu fais comment pour modifier les inputs sans que tout le flux d'input passe aussi par le composite manager pour subir la bonne deformation ? Meme question pour lutter contre le phishing et les keylogger, tu fais comment sans une cooperation fine entre le composite manager, le window manager et le systeme d'input ? Tu peux pas. Toutes les implementations sures, efficaces et fonctionnelle de Wayland seront monolytique.
[^] # Re: Quels sont les floating et les tilings ?
Posté par cedric . En réponse au sondage Quel gestionnaire de fenêtres utilisez‐vous ?. Évalué à 2.
Enlightenment (flottant et pavant, le choix est par bureau virtuel)
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . En réponse à la dépêche Le point sur udev et systemd. Évalué à 2.
Approcher le developpement avec des dogmes, c'est pas une bonne idee. Il faut voir la situation et s'adapter au contexte. Pour le coup ne pas montrer de souplesse dans l'analyse et la solution d'un probleme technique n'est pas un bon signe…
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . En réponse à la dépêche Le point sur udev et systemd. Évalué à 7.
Wayland, c'est le merge du composite manager, du window manager et de X. Je ne comprend donc pas ton "heureusement"…
De plus la conception de X lui a permit de tenir 20 ans sans etre reecrit. En informatique, je connais peu d'exemple qui ont tenu aussi longtemps en etant aussi centrale (Et X n'est pas encore remplace, Wayland est a encore bien deux ans de dev de pouvoir le remplacer). Surtout que X a ete cree du temps ou la majorite du probleme etait d'acceder graphiquement a des main frame. Alors que aujourd'hui, la majorite des usages sont dans l'embarque et la mobilite… Des trucs qui n'avaient meme pas ete envisage lors de la conception.
Je n'ai pas lu d'article detaille sur comment fonctionnait Blit, et l'histoire ne l'a pas retenu, donc je ne peux me prononcer dessus. Mais clairement critiquer X… J'attend de voir ou sera le soft que tu ecris dans 20 ans et comment il aura evoluer, si il survit jusque la ! :-D
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . En réponse à la dépêche Le point sur udev et systemd. Évalué à 2.
Il va falloir que tu demontres a des developpeurs experimentes que ton principe KISS va fournir un meilleur resultat… Le principe KISS est souvent sorti dans deux situations :
- quand on affronte une horreur sans queue ni tete et qu'on ne peut pas faire autrement que tout jeter.
- quand une personne qui n'a pas assez d'experience ne comprend pas ce qu'elle a en face d'elle.
Le probleme, c'est de faire la difference entre l'un et l'autre.
Sinon il y a plein de cas ou le fais de separer entre process pose des problemes. Perte d'information, de cache, difficulte de detecter finement les erreurs, efficacite generale and so on. Donc le principe KISS, c'est comme les designs patterns, faut pas en abuser betement. Ceux ne sont pas des religions !
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . En réponse à la dépêche Le point sur udev et systemd. Évalué à 4.
Joli de prendre X comme exemple ! Le probleme de X, identifie aujourd'hui, c'est que justement, il devrait inclure le Window Manager et le Composite Manager… Une belle demonstration par l'absurde que de faire une seule tache et la faire bien, n'est pas forcement en terme de design la meilleur solution. C'est un dogme, tout comme le principe KISS qui n'est pas forcement une bonne idee dans tous les cas.
[^] # Re: Bientôt vendredi
Posté par cedric . En réponse à la dépêche Le point sur udev et systemd. Évalué à 3.
Fallait pas t'arreter de lire. Tu as manque :
Si avec tout ca, tu n'es pas entrain de te rouler par terre, tu as vraiment des nerfs d'acier ! Moi pas :-D
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par cedric . En réponse au journal udev forké. Évalué à 2.
Wouhou, ca se transforme en troll sur DBus ! Bon, tu proposes quoi comme alternative a DBus ? Un truc libre, standard avec des outils et facilement integrable par tout le monde ?
A ma connaissance, il n'y a rien. Et non, faire des IPC direct a la mano avec les daemons, n'est pas une bonne reponse. Car cela duplique du code, rend difficile l'interoperabilite et l'ecriture de frontend alternatif.
Certe techniquement dbus, ca pourait etre plus lege, plus rapide, plus efficace, mais tu peux proposer des patchs pour ca. Je rappel, le code est libre et tous les utilisateurs de libdbus en profiteraient… Avantage d'avoir une brique comune !
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par cedric . En réponse au journal udev forké. Évalué à 4.
Elles interragissent reellement en profondeur avec systemd declenchant des evenements auquel des units peuvent reagir entre autre chose. Mais rien n'empeche une distrib de recoder un daemon qui a la meme API DBus. En fait techniquement, c'est la meilleur solution. Systemd fournit une infra qui permet au projet upstream de propager plus facilement leurs ameliorations dans les distribs en diminuant les acces a des fichiers ou des scripts custom.
Pour un projet upstream, c'est juste ideal. Je me plug sur l'API DBus, et je n'ai plus a avoir un truc custom par distrib. Forcement, ca facilite la vie de tout le monde, sauf ceux qui veulent etre different… A eux de developper leur demon de remplacement, c'est pas tres difficile en meme temps. Mais ca deplace clairement les problemes sur ceux qui les creent ce qui est une bonne chose.
[^] # Re: la guerre de s unices
Posté par cedric . En réponse au journal udev forké. Évalué à 5.
Wouah ! Une theorie du complot des distributions Linux commerciales ! Joli, j'avais pas encore rencontre une telle idee… Lennart, il aurait pas tue JFK ? Et ca serait pas ca soucoupe volante qui s'est crashe a Roswell ?
[^] # Re: la guerre de s unices
Posté par cedric . En réponse au journal udev forké. Évalué à 4.
Il y a une difference. Tu peux le faire toi meme. Il y a une doc, tu peux lire, apprendre, comprendre, verifier et agir.
La politique, c'est une autre histoire. Faut raconter aux gens ceux qu'ils veulent bien entendre sur le moment. Apres la realiter et les consequences ont peu d'importance.
Pour la finance, il y a clairement un manque d'information, de culture economique, scientifique et geostrategique importante qui fait que bon nombre de personne ne sont pas capable de comprendre ceux qu'on raconte. Entre autre chose, la speculation sur les matieres premieres a une influence minimal sur leur prix. A leur actuel, la principale raison de la monte du prix, c'est la rarefaction du petrole a bas cout…
[^] # Re: la guerre de s unices
Posté par cedric . En réponse au journal udev forké. Évalué à 8.
La difference majeur, c'est qu'une unite systemd peut etre fourni par le projet upstream et fonctionnera sur toutes les distribs. Ca veut dire moins de boulot dans la distrib, integration a terme plus rapide des nouveautes et teste plus large. Pour les mainteneurs, c'est un gain, pour les developpeurs, c'est un gain.
Si c'etait une si mauvaise idee, pourquoi la majorite des gens qui font des distribs, developpe des plateformes ou developpe du soft sur Linux suivent le mouvement ? Ni upstart ni openrc n'ont reussi a gagner une tel attraction. Et ni Lennart ni Red Hat ne paye ces gens pour adopter systemd, ils le font parce que techniquement, c'est une meilleur solution que l'existent. Cela leur facilite la vie, leur permet d'avoir un systeme plus dynamique, plus maintenable et plus efficace…
Ensuite il y a un truc que tu n'as pas compris, Linux est base sur l'evolution. Tous les logiciels, les bibliotheques vivent et meurent au gres de l'apparition d'une concurrence plus efficace, d'une mainteneur plus motive and so on. Linux est un eco systeme ou les theorie Darwinnienne s'applique. Il n'y a rien de stable ad vitam eternam. Si la communaute dans sa majorite pense que d'aller dans une direction est mieux, c'est ce qui se passera.
Tu peux de maniere individuelle choisir de ne pas la suivre. C'est ton droit. Et tu peux le faire, tu as les sources. Mais il y a un prix a payer, le faire soi meme. A toi de choisir.
[^] # Re: HTML, CSS, JavaScript, au lieu de Java
Posté par cedric . En réponse à la dépêche Open webOS, brut de décoffrage. Évalué à 3.
Chaque fois que tu utilises ton CPU/GPU, que tu fais une operation, tu consommes de la batterie. Avoir quelques choses de rapide, implique que tu utilises donc ta machine de maniere plus optimale et qu'elle peut plus rapidement se rendormir. Au final, tu as un lien direct entre rapidite et batterie…
Apres tu as aujourd'hui 3 composants qui consomment beaucoup, l'ecran (en fonction de la resolution), le modem (surtout en LTE) et le CPU/GPU. A charge de travail equivalente, le logiciel peut difficilement influencer plus que le CPU/GPU. Donc l'autonomie va directement dependre de l'importance de chaqu'un des trois dans la consomation. Je pense que sur une tablette, l'ecran est le premier consomateur. Sur un telephone, non LTE, c'est le CPU/GPU. Le natif donnera toujours un avantage quand le CPU/GPU a de l'importance, donc sur telephone (un ecran < 4") donnera plus d'autonomie. Sur une tablette, je n'ai pas fait de test, mais c'est peut etre l'ecran le plus gros consomateur…
[^] # Re: la guerre de s unices
Posté par cedric . En réponse au journal udev forké. Évalué à 2.
Difficilement et compare a la vitesse de l'equivalent windows, Linux est deja tres optimise. Le probleme principal, c'est que tu dois faire :
- destruction des anciennes pages
- chargement du nouveau programme
- chargement des dependences
- linkage
- initialisation du programme et des dependences
- execution
- retour du resultat
- nettoyage de la memoire
Forcement, face a juste execution + retour du resultat, tu as zero chance d'y arriver meme avec la meilleur volonte du monde :-) Ensuite systemd amene aussi d'autres amelioration, comme des optimisations entre les differentes taches que tu ne peux pas faire en shell vu que chaque process est isole. Et ainsi de suite.
[^] # Re: HTML, CSS, JavaScript, au lieu de Java
Posté par cedric . En réponse à la dépêche Open webOS, brut de décoffrage. Évalué à 8.
J'avoue, j'ai jamais trouve le CSS ou l'HTML simple. Bon, JavaScript, c'est autre chose, clairement un langage tres pratique pour prototyper. Mais a partir d'une certaine taille de code, ca devient difficilement gerable.
Donc qu'est-ce que tu trouves dans les technos web qui font que c'est rapide a ecrire ? Tu t'y prend comment ? Parce que sans un toolkit comme JQuery ou PhoneGap, j'ai vraiment du mal et encore, le resultat ressemble soit a rien soit a qqc qui existe deja…
Bon, et sinon l'HTML dans le mobile, c'est une vachement bonne idee pour les vendeurs de batterie, mais pour l'utilisation au jour le jour, j'ai un doute… et je suis pas le seul, Facebook sur iPhone fait du natif pour toutes les taches commune et courante…
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par cedric . En réponse au journal udev forké. Évalué à 10.
Vous croyez que le merge de systemd et udev, c'est fait comment ? Lennart a debarque sur la ML de udev en prenant en otage les familles des developpeurs de ce projet ?!
Si udev a finit dans systemd, c'est que les mainteneurs de udev ont trouve que c'etait une bonne idee. Ils l'ont accepte et meme voulu, on merge pas du code par magie ! C'est un choix qui doit aider ces deux projets et les faire avancer plus efficacement.
Alors faut arreter avec vos theories du complot et vos histoires de restriction de liberte. Les developpeurs font les choix techniques qui leur semblent les meilleurs, si jamais ca vous convient pas faite un fork et prouve que vous avez raison en le faisant depasser l'original (C'est clairement l'objectif du fork de udev). Ce sera une competition technique et pas des idiotes theories complotistes qui veulent des rapports d'evaluation geostrategiques…
[^] # Re: la guerre de s unices
Posté par cedric . En réponse au journal udev forké. Évalué à 7.
Non, car le nombre de fork + exec ne diminuerait pas, le nombre de fichiers a acceder sur le systeme reste eleve, chaque unite de demarrage resterait complexe et dependante de la distribution. Au final, le shell restera toujours inefficace face a un programme qui fait toute l'init.
Sans compter que, avec systemd, il est possible d'optimiser beaucoup de chose. On peut, par exemple, arriver a generer un cache compose d'un unique fichier decrivant tout le boot. En terme de performance et d'efficacite, par design, un programme comme systemd a un avantage impossible pour un script shell a atteindre.
[^] # Re: Oui, mais.
Posté par cedric . En réponse au journal Self serving. Évalué à 2.
Tout comme les appareils photos numeriques n'ont pas disparu. Pourtant quand tu fais le touriste a l'etranger, la majorite des gens prends ses photos avec son smart phone. Il se vend plus de laptop que de desktop depuis 2007. Et depuis cette annee, il se vend plus de smartphone que de PC (laptop + desktop). L'impact, c'est que la technologie, les prix et la competition a lieu sur le segment le plus large. Si demain le seul marche sur lequel tu peux mettre Linux, necessite que tu payes plus que les autres, tu t'exclues mecaniquement. Et tu rend le renouvellement de ta communaute plus difficile. A terme, cela veut dire simplement le ralentissement du developpement de ta plate forme…
Donc meme si quelque chose ne disparait pas, sur le long terme, ca peut etre tres penalisant. Mais comme je l'ai dis, on est au debut du mouvement, le remplacement n'est pas pour tout de suite.
La reputation ne fait pas la realite. C'est vrai sur le serveur, sur le desktop, c'est une autre histoire. Lorsque tu demarres une application qui accede a X, tu n'oublies jamais que tout ce que tu tappes et tout ce que tu vois, peux etre intercepte silencieusement par n'importe quelle application. Et ce n'est qu'un debut, les fichiers personnelles sont accessibles par toutes les applications, les services dbus utilisateurs aussi, … La protection de Linux sur le Desktop, c'est qu'il est fragmente et qu'il n'y a pas assez de monde pour justifier l'effort de l'attaquer. Mais ca n'empeche pas d'etre critique sur la situation.
Tous les developpeurs d'application ont un probleme avec les distributions. Elles mettent du temps a integrer les packages. GNOME estime que cela met 6 mois pour etre package. Ce qui veut dire que quand tu as des bugs reports, cela arrive 6 mois trop tard. Et GNOME est dans une bonne situation avec une demande forte des utilisateurs, donc une update rapide. Il y a des applications/bibliotheques qui ont des annees de retard dans certaine distribution. Sans compter les distributions qui ont du mal a faire un packaging correct. Mais ca peut aussi etre pire, tu as les utilisateurs de Gentoo qui adore jouer avec les flags de compilation et qui comprennent rien a ce que cela implique dans le resultat. Enfin il y a aussi une perte du lien entre le developpeur et l'utilisateur, donc un probleme de communication qui peut resulter en une deconnexion entre les utilisateurs et les developpeurs.
Voila pourquoi GNOME reflechit a GNOME OS par exemple. Ca resoud ce probleme. Apres certaine distribution, je pense uniquement a Arch, mais il y en a peut etre d'autre peut etre, arrive a fournir un bon resultat (qui repond au probleme precedent). Malheureusement tout le monde n'a pas le temps de faire une install Arch, ni ne veut forcement l'utiliser. Et ca, le store, repond a cette problematique… En tant que developpeur, je ne vois meme pas comment on peut ignorer ce probleme.
[^] # Re: La politique de sécurité est bonne
Posté par cedric . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 2.
De rien et merci a toi de partager ton point de vue. Participant au projet Enlightenment, c'est une discussion on ne peut plus interressante pour moi.
Tu mets exactement le doigt sur une lacune du monde GNU/Linux. Le cloud (via Google, Facebook, voir meme github) et Android qui vient globalement du meme monde, offre une plus grande integration et plus de possibilite d'etendre les fonctions d'une application que ne le permette des applications locales. Pourtant mon PC a acces a tous les cloud en meme temps et a plus de donnees personnelles stocke localement que n'importe lequel de ces services en ligne. Donc pourquoi les developpeurs ne font il pas plus pour integrer tout ca et faciliter la vie de l'utilisateur ? En fait, le projet KDE a pas mal d'avance dans le domaine (principalement parce qu'il redeveloppe toutes leurs applications), mais on est encore loin de ce qu'on peut juste imaginer aujourd'hui.
Idee interressante. En gros, on obtient un modele ou on a un grabber qui aura des droits particuliers et sera en mesure d'extraire l'information pour la presenter aux applications. Ca complexifie clairement le code et augmente la consomation de ressource, mais faut voir si cela a un impact important au final. C'est une idee a creuser, voir plus bas.
Le client mail est loin d'etre simple, c'est le premier composant d'une suite de communication et il doit etre a terme capable de fournir un contexte fort en nourrissant, calendrier, carnet d'adresse, todo, im, … en information pertinente. A partir du moment ou tu commences a ajouter des fonctions de communication et de contexte facilement integrable dans une application externe, tu peux imaginer les scenarios suivant :
Dans ton editeur de code, tu as une ligne de code que tu ne comprend pas, tu veux en discuter avec l'auteur. Tu fais un petit tour dans le menu contextuel, celui-ci te propose de discuter avec l'auteur sur IRC ou par IM en utilisant les informations fournit par Git, ton carnet d'adresse et ton client IRC/IM.
Tu ouvres un PDF depuis ton client mail, ajoute des notes dedans, puis repond au mail precedent. Ce serait plutot utile si le client mail pouvait t'afficher les notes prises dans ton lecteur de PDF.
Tu recois un lien via une discussion dans un mail. Tu navigues un peu dans le site. Puis tu reviens dans le mail pour faire une reponse. Ce serait interressant de pouvoir afficher une arborescence du sites visite de maniere a pouvoir mieux ce souvenir de ce qu'on voulait repondre.
Tu te souviens que suites a une discussion avec quelqu'un en particulier, tu avais fait une recherche qui t'avait donnee un resultat interressant. Tu ouvres ton carnet d'adresse, clicke sur la personne et tu as acces a l'historique de toutes les actions que tu as fait en rapport avec cette personne. Il devient ainsi facile de retrouver le resultat que tu cherchais.
C'est juste des idees, mais tu peux imaginer le meme genre de scenario avec ton IM, IRC ou les SMS. Aujourd'hui, ils n'existent aucun environnement qui fournit ce genre d'infrastructure. Les plus proche sont Android et KDE. Mais ils ont tous les deux des problemes de securites de mon point de vue. Maintenant si on developpe une telle suite de communication, il est absolument necessaire de penser comment realiser la securite de l'ensemble, sans impacter les performances (faut que ca tourne sur n'importe quel machine a peu pres moderne du smartphone au desktop en incluant les netbook) et en ayant une UI qui facilite le plus possible la vie de l'utilisateur.
D'ailleur, je pense bien que c'est un gros fail de Apple de ne pas permettre ce genre de fonctionnalite. Mais bon, on verra si le futur ira dans cette direction ou non.
Hum, un demon externe en charge de processer les mails, voyons les problemes. Comment peut-on etendre l'analyse du contenu des mails ? Est-ce qu'un langage de script sera suffisant ? Ou faut-il inclure aussi la possibilite d'avoir des modules binaires ? Comment tagger automatiquement les images inclus en piece jointe en passant dessus un OCR ou une reconnaissance faciale ? Dans quel langage serait ecrit une IA qui comprendrait le contenu meme du mail ? Je pense que tu as maintenant une idee plus precise des contraintes.
C'est ce que l'on fait ici :-) Bon, j'avoue j'ai hijacke ce thread a propos d'Apple…
[^] # Re: La politique de sécurité est bonne
Posté par cedric . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 4.
Meme avec la peur de la police et le risque pour sa propre vie, un certain nombre d'individu se comporte de maniere particulierement idiote sur la route.
Pour le coup, c'est clairement ce qu'on fait avec nos banques quand on place de l'argent. On fait aveuglement confiance a son banquier qui s'est charge de faire la revue des produits financiers pour nous. Mais des fois il se fait avoir ou il est malhonnete et ca se finit au tribunal.
Sans vouloir etre mesquin sur ce coup la, une porte ferme a clef, ca ne stop pas grand monde … Et j'ai d'ailleurs souvent vu des gens qui oubliaient de fermer la porte de leur appartement quand j'etais encore a Paris. Donc faut pas trop compter sur ca non plus ;-)
A mon sens, il y a tres peu d'application qui vont rentrer dans cette categorie. De mon point de vue, il y a 3 types d'applications :
Les applications de la derniere categorie etant celle specifique a ton environnement et faisant reellement la difference avec le reste du monde. Soit tu rend l'ecriture de ces applications tres difficile et tu vas laisser la concurrence te prendre des utilisateurs, soit tu leur facilite la vie (et surtout celle des utilisateurs). C'est donc une categorie extrement importante voir crutial pour la reussite d'un environnement. Pour une meilleur idee de ce que je decris, je ne peux que te recommander la lecture du mini livre de Brett Victor, Magic Ink (http://worrydream.com/MagicInk/).
Maintenant imagine une application de calendrier qui va indexer et parcourir tous tes mails a la recherche de possible evenement en piece jointe ou directement dans le contexte du mail. Le developpeur a explicitement demander l'acces a ces informations dans son package, maintenant quel question doit on poser a l'utilisateur ? Tu connais deja mon point de vue, aucune :-) L'application fait ce quel est sence faire, pas la peine d'ennuyer l'utilisateur avec un comportement normal.
Oh, je crois que je me suis mal fait comprendre. Je pense que toutes applications installe doit venir avec ces mecanismes de securite. C'est juste qu'a aucun moment, il n'est necessaire selon moi de poser une question a l'utilisateur.
Sauf que cela marche pour les cas simple, un editeur de texte par exemple, mais des que tu veux des choses plus automatise, comme l'exemple de mplayer, cela se fait a l'encontre de l'utilisateur. Alors dans le cas de mplayer, le systeme pourrait etre tres intelligent et donner les droits d'acces a des fichiers lie comme les sous-titre. Mais le probleme se posera a chaque fois qu'une fonction automatique sera ajoute pour simplifier la vie de l'utilisateur… Le systeme de securite de Apple manque donc de finesse et de contexte, et compense cela en mettant la pression sur l'utilisateur et les developpeurs.
Si il ne demandait que l'acces au fichier video a l'utilisateur et donner silentieusement l'acces qui va bien au sous titre, alors le systeme d'Apple serait bien concu de mon point de vue. Car il n'aurait a aucun moment pose une question de securite, mais juste un bon classique quel fichier afficher !
Sous windows, peut etre, sous Linux, c'est plus simple, tu grabbe en permanence le clavier sous X, meme pas besoin de fishing pour recuperer le mot de passe :-) Avec Wayland, on pourra nettement augmenter la securite et vu que le composite manager sera en charge de l'affichage et des inputs, on pourra faire des effets et affichage different entre les applications demandant un mot de passe et les autres.
[^] # Re: La politique de sécurité est bonne
Posté par cedric . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 3.
L'utilisateur, il cliques sur Ok pour que son application marche. Il ne cherche tres rapidement plus a comprendre pourquoi une application lui demande quelque chose. Il veut que ca marche et qu'on ne l'ennuie pas avec des questions superflues ! En ergonomie, chaque cliques augmentent de 50% les chances de perdrent l'utilisateur. Donc toutes questions de securite resulte en une mauvaise ergonomie. Ce n'est pas une solution !
Vu qu'on melange dans cette discussion deux problemes, comment interagir avec l'utilisateur et le proteger des applications malveillante et comment le proteger des failles de securite. Pour le proteger des failles de securite, c'est une problematique technique et un arsenal technique va clairement aider. Noyau et linker permettant de faire de l'adressage memoire aleatoire, canarie, analyse statique du code, privilege super fin de l'application (definit par le developpeur) et definition des sorties (en gros, quand il y a des donnees privees dans un fichier que l'application cree, le systeme en est informe et prend les mesures necessaires), virtualisation, secure boot et trusted computing. Avec ca le potentiel d'une attaque sur un systeme aillant une faille devient tres difficile et a aucun moment l'intervention de l'utilisateur a ete necessaire. Donc aucune problematique d'ergonomie.
J'aime aussi assez bien l'idee de faire payer les droits demander aux developpeurs. Plus il en demande, plus c'est chere… Mais ca, ca ne marche pas avec le logiciel libre.
Maintenant, pourquoi est-ce que l'utilisateur doit-il intervenir dans le process ? Le seul moment ou il a une decision a prendre, c'est quand il a installe une application. Et ca decision est simple, quel est le rating de l'application et combien de personne l'on installe ? Apres si il pousse un peu le truc, il lira aussi quelques reviews. A cette etape, il faut exposer l'information pertinente, savoir si l'application a ete auditer, si les droits sont logiques, si personne n'a eu de souci. Je ne vois pas pourquoi on ne fait pas la difference entre les utilisateurs qui ne comprennent rien a la securite et ceux que cela interresse. Je pense que vu qu'on cherche a resoudre un probleme humain, des gens qui ecrivent du code malicieux, il faut une solution qui implique des etres humains. Donc c'est au moment de l'installation que les informations pertinentes doivent etre afficher pour prendre une decision. Et il faut que ce soit simple a comprendre !
Le probleme est fondamentalement different meme si le resultat peut etre le meme. Dans un cas, tu as une tracabilite, avec la possibilite juridique d'intervenir dans l'autre tu es dans un cas anonyme et il faut des recherches plus ou moins pousser pour trouver un coupable. Plus le developpeur comprend que si il fait volontairement une betise, il sera identifie et penalement poursuivit, moins il prendra de risque sur la plateforme. Comme c'est un probleme different, il demande des reponses differentes. Et a aucun moment, on peut compter sur l'utilisateur pour prendre la bonne solution surtout sur une question complique.
En faisant cette difference, tu peux agir de maniere plus simple pour l'utilisateur sans le mettre en danger pour autant.
[^] # Re: La politique de sécurité est bonne
Posté par cedric . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 3.
Je suis en desaccord fondamentale avec cette approche de devoir "crowdsourcer" la securite a un utilisateur qui de toute facon veut juste que ca marche et ne comprend ni la question ni pourquoi on l'embete avec ca, ca va rien donner. Apple a les moyens d'auditer le code, de le tester, d'agir promptement en cas de probleme et meme de poursuivre le createur du probleme en justice. La difference fondamentale avec le logiciel libre, elle est la. Apple ne peut pas avoir confiance dans les developpeurs de sa plateforme, donc il met une politique en place. Politique qui doit lui couter le moins possible. Aller au tribunal dans le monde entier ca doit couter bonbon, et il faut verifier que la creation de virus et autre malware est illegal pour que ca serve a quelque chose. C'est un probleme humain avant d'etre un probleme technique.
Tant que le logiciel libre passe par des distributions et offre un mecanisme lent de propagation des changements vers les utilisateurs (ce que sont les repository de distribution), alors on reste fortement protege du probleme. Et oui, on peut avoir confiance dans la tres tres grande majorite des developpeurs de logiciel libre. Mais le jour ou on ouvre la porte a un cycle court du type AppStore ou n'importe qui peut faire n'importe quoi. On a la meme problematique. Alors soit on emmerde l'utilisateur en le privant de fonctionnalite utile et on lui simplifie la vie, en mettant en danger ses donnees personnelles, soit on met en place une politique de securite tres contraignante a la Apple. Soit on y reflechit serieusement maintenant et on essaye de trouver une solution plus acceptable.
On peut imaginer que les applications indiquent au systeme quand elles enregistrent des donnees personnelles, utiliser de la crypto pour le stockage via un daemon dans lequel on peut avoir confiance (les kwallet et consort sont clairement pas designer pour la securite). On permet aux utilisateurs avance d'utiliser un LD_PRELOAD pour detecter les applications qui font des betises. On met en place un systeme de review different en fonction des gens qui font les checks de securite et ceux qui ne comprennent pas la question. On compile toutes les applications et le kernel par defaut avec tous les flags ameliorant la securite. Et surtout ON N'UTILISE PLUS X ! Alors dans ce cas la, on pourra avoir un AppStore sous Linux. Mais meme la, il faudra toujours un kill switch avec un moyen d'avertir directement les utilisateurs…
En attendant, la solution d'Apple ne fait qu'impacter ses utilisateurs en les privant de service utile sans reelement les proteger de quoique ce soit… Et oui, je fais fondamentalement la difference entre un comportement attendu et l'utilisation d'une faille dans un logiciel existant.
[^] # Re: La politique de sécurité est bonne
Posté par cedric . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 2.
Sous MacOS, le systeme de fichier connait le mime type directement. Probleme regle pour eux :-)
Sous Linux, il faudrait qu'il soit automatiquement ajouter par le systeme lors d'un acces en lecture dans les attributs du fichiers, si il n'a pas deja ete evalue (Bien entendu en cas d'ecriture, l'attribut doit etre supprime). Utiliser un daemon et inotify pose des problemes de charge et des races conditions. Donc il faut un truc qui bloque ton appel systeme open/read si l'attribut n'est pas la et declenche une tache pour en faire l'evaluation et coller le bon label. Pas trivial et je ne pense pas qu'on est deja l'infra dans le noyau pour faire ca.
[^] # Re: Paris (SG) c'est cher aussi
Posté par cedric . En réponse au journal Il était une fois, un petit pas... Maintenant, c'est 6 grandes roues !. Évalué à 10.
Financierement, c'est une catastrophe. Cela va finir de ruiner les anglais. Aucune ville d'un pays developpe ayant recu les JO d'ete n'a reussi a maintenir correctement dans le temps cette nouvelle infrastructure du fait des couts d'entretien. Dans le cas de Londre, les calculs de cout de fabrication ont ete minimise d'un facteur 2 ou 3, et les comptes sont deja dans le rouge au depart. Le resultat va etre sympa pour les impots des Londoniens…
Entre ca et l'etat policie mis en place pour l'evenement, heureusement que Paris n'a pas gagne !