reno a écrit 3886 commentaires

Les principaux problèmes d'ABI causant des mots de têtes aux packagers sont assez différents.

L'un vient du fait que la taille des types est décidée à la compilation en C++.

Je me demande si les librairies compilées ne posent pas plus de problème qu'ils en résolvent et si un système à la ANDF ne serait pas intéressant..

Et puis ça permettrait potentiellement de "reconfigurer la librairie" en fonction de l'application: une application qui a un gros besoin de performance? Un int C reste un entier avec débordement silencieux, autrement un int devient un entier 'vérifié' qui arrête l'application en cas de débordement (sémantique autorisée par le C/C++).

Pour l'utilisation de vtable et d'un vrai "appel par message" en plus, je trouve ta suggestion intéressante après tout c'est juste l'API externe qui nécessite d'être déclarée ainsi (si on veut maximiser les perf) et bien délimiter/définir l'API externe est une bonne idée je pense.
Dans le même genre, j'ai toujours trouver dommage qu'en C++ les méthodes étaient publique par défaut au lieu de privée.

Oui enfin l'immobilisme d'X et l'inadaptation entre les toolkits (p… il y en a que 2 qui comptent pas f… de collaborer??) et X est un gros gâchis pas la peine de revenir la dessus..

Avec Wayland, on va gagner un système efficace pour l'embarqué ( http://www.collabora.com/about-us/blog/2014/08/13/wayland-x11-arm-mali/ ) au prix d'un affichage distant sous-optimal (en théorie), je pense que pour beaucoup ce n'est pas trop cher, même si c'est dommage car on aurait probablement pu avoir les deux..

Oui, les toolkits n'exploitent pas bien X à l'heure actuelle.

Note quand même que dans TOUT les cas si l'utilisateur, les applications ou les toolkits ne jouent pas le jeux, ça peut créer des problèmes pour l'affichage distant: avec Wayland il a été évoqué de compresser les buffers avant de les envoyer pour réduire la bande passante utilisé, ce n'est pas difficile d'imaginer un thème de bureau ou des applications qui réduise l'efficacité de cette compression: genre un effet de flamme dynamique en papier peint avec des fenêtres translucides, trop cool comme thème non?

Et hop la bande passante qui explose avec Wayland (avec X ça dépendrait de la façon de faire, ça peut être la même chose ou 'moins pire')..

Pour moi, une vrai transparence réseau, c'est assez orthogonal au serveur d'affichage.

Hum, pas tout a fait, la conception de Wayland ne peut pas être aussi efficace en distant qu'une architecture 'à la X' (puisqu'avec X tu peux passer des buffer comme avec Wayland mais pas l'inverse: pas de commande de dessin à distance avec Wayland) après les utilisateurs se fichent de la conception ce qu'ils comparent eux ce sont des implémentations, à voir en pratique donc..

pour ce qui est de Wayland, si tu es de bonne fois tu admettras quand même que le problème que tu cherche à résoudre est juste 1000 fois plus compliqué que ce cherche a faire Wayland (un affichage local efficace)..
Et en fait le bon point de départ pour ta "transparence 2.0" ne serait pas Wayland mais X où on peut noter que l’amélioration de la transparence réseau plutôt basique qu'X propose a attiré relativement peu de monde et n'a pas été réintégré dans X: NX ou autre, ça devrait être utilisé pour faire un "X12" plutôt que d'être un élément séparé!

Le problème, c'est pas l'intégrisme

Ah? Pourtant respecter intégralement les préceptes de la religion, moi je trouve que c'est un problème quand la religion dit qu'il faut tuer ceux qui ont quitté la religion, les femmes infidèles, etc.

.. mais en Anglais, le lien vers celui pour Maryam Mirzakhani: http://www.simonsfoundation.org/quanta/20140812-a-tenacious-explorer-of-abstract-surfaces/
mais il y a un article pour chacun des vainqueurs.

et on se dit que les ventes d'iPhone vont baisser aussi

Ah? Pourtant le futur iPhone grand écran devrait être un carton.

Les smartphones stagnent: plus de nouvelle super-fonctionnalité, juste du peaufinage, mais le peaufinage ça peut être super important: il y a plein de points soit rare (étanchéité, batterie amovible) soit carrément inexistant (anti choc, inrayable(*), écran bien lisible en plein soleil) qui amélioreraient beaucoup la vie des utilisateurs..

Ça c'est le coté matériel, mais coté logiciel la fluidité d'Android, l'ergonomie des téléphones/tablettes c'est loin d'être ça encore (exemples: comment on fait pour remonter en haut d'écran avec Chrome? pour avoir un clavier décent sur iPad il faut attendre iOS8..).

Après le peu d'appareil avec double SIM, microSD et batterie amovible montre bien que les fabriquant d'appareil pensent d'abord à eux et aux opérateurs téléphoniques, les besoins du clients passent ensuite seulement.

*: à voir les futurs écrans d'Apple en saphirs..

Là il y a en plus, "quasiment tout" généré, mais oui ça n'est pas nouveau.
Mon plus gros problème c'est que tout cette recherche va dans le vide, ou sont les sources?

Et bien d'après leur rapport, ils sont plutôt content de ce qu'ils ont obtenu.
Après je ne crois pas qu'il y ait un accès aux sources donc..

Pour seL4, ça fait 5 ans que c'est sorti et ils marquent toujours que le support du multicœur comme 'expérimental'.. Même mon téléphone est multicœur, donc je maintiens: seL4 est un jouet (à l'heure actuelle).

Pour le reste, c'est probablement une question de temps..

Bricoleurs? Quand tu vois la difficulté de prouver même des petits programmes..
seL4 est l'exception pas la règle et quand tu lis leur FAQ sur le multicoeur..
Par contre pour l'utilisation du C plutôt qu Ada (par exemple) là je suis d'accord.

la refactorisation du mamouth LibreOffice..

D'un autre coté, il y a le projet STEPS d'Alan Kay qui repart du début et prétend avoir un traitement de texte puissant en très peu de ligne.. Dommage que STEPS ce soit uniquement de la recherche et que ça a l'air moribond (dernier rapport officiel en 2011), les 2 approches sont intéressantes..

Y a qu'a demander.. Voici le lien: https://news.ycombinator.com/item?id=8104407

Oui enfin quand tu lis leur FAQ sur le support expérimental du multi-coeur par seL4, ça calme plutôt à l'heure actuelle, non?

Capsicum reste, malgré tout cela, un gain mesurable en sécurité puisque ça permet de faire passer la surface d'attaque de "absolument titanesque" [coupé] à juste "complètement énorme" (le noyau Linux).

La fin pourrait être "affinée": à une partie du noyau Linux puisque tu peux restreindre les appels systèmes autorisés.

Pas la peine d'aller chercher à l'étranger: le rainbow warrior, les écoutes personnelles de Mitterand (on pourrait trouver plein d'autre exemples) ça me parait difficilement légal, non?

Et pourtant les suites judiciaire ont été ridicules..

Je ne mettrais pas LXC/Docker et Capsicum dans la même catégorie..
Pour LXC/Docker effectivement pouvoir attaquer tout le noyau ça fait beaucoup.

Pour Capsicum, je ne sais pas si je suis d'accord, certes ça dépend beaucoup de l'application et de la façon dont elle conçue, mais en général tu restreins beaucoup ce qu'il est permis de faire ce qui complique quand même énormément la vie d'attaquant.

Ce qui est sympa avec Capsicum, c'est que les gens d'OpenSSH et de Chrome s'y intéressent et rien qu'avec ces 2 applications "capsicumisées", cela devrait apporter un réel gain en sécurité..

Mais ça pose de redoutables problèmes d'ergonomie et d'interfaces

L'approche de qube-os ne me parait pas si mal que ça: par exemple, tu mets une VM différente pour des contextes différents: une pour ton boulot, une pour tes activités perso, une pour les enfants et une autre pour les activités risquées: installation d'une appli dont tu ne sais pas trop si elle inclut un adware ou pas, etc.

Les contextes étant différent le besoin de communication entre les VMs est réduit..

Après comme le dit Michel Barret, la virtualisation ça consomme énormément de RAM et de disque, ce qui est un sacré inconvénient..

Heartbleed et beaucoup, beaucoup d'autre failles.. Le C ou le C++ d'un point de vue sécurité..

Linus avait jeté le bébé avec l'eau du bain en disant qu'il y avait suffisamment de modules de sécurité et qu'il ne voulait pas en intégrer un nouveau.

Oui enfin Linus, par défaut il dit non et puis après il discute..
Vu le nombre de fonctionnalités qu'on doit lui demander d'introduire dans Linux, ça me parait d'ailleurs une stratégie tout à fait raisonnable!

Question de quelqu'un qui ne connaît rien au kernel : ne serait-il pas possible d'implémenter Capsicum sous forme d'un LSM

Alors
1) les LSM ne sont pas 'stackable'/additionnable donc si tu implémente Capsicum sous forme d'un LSM alors tu aurais l'alternative d'utiliser Capsicum XOU SELinux XOU …

2) Capsicum c'est pour les devs qui veulent rendre leur logiciel plus robuste, c'est donc assez différent des politiques de sécurité qui sont plus pour les admins.

Donc si Capsicum n'est pas présent en standard, il y a peu de chance que les devs vont faire l'effort de modifier leur code pour en tenir compte.

Je ne vois pas pourquoi tu réponds sur ma suggestion de "contraignante", "héréditaire" comme évoqué plus haut me parait bien mieux..

Lu sur Internet: la WTFPL est déconseillé par un avocat aux USA.

Suite à ces révélations, comment se fait-il qu'on autorise encore les google cars en France, ou que le cloud CNRS soit géré par Microsoft ??

Je ne vois pas le rapport entre les 2..
Pour Microsoft OK c'est aberrant, pour les voitures Google que font-elle d'illégal?

La cryptographie fonctionne !

Mort de rire.. Tu ose écrire ça après toute une série de vulnérabilité dans les implémentations??

Pour ce qui est de prendre en compte sérieusement la sécurité, quand est-ce qu'on porte tout du C/C++ vers ATS ou Ada (ou Rust quand il sera mur)?

Plutot d'accord, mais c'est quand meme ce que le titre du journal implique/sous-entends..