reno a écrit 3886 commentaires

Comme d'habitude LWN fournit un résumé de grand qualité: http://lwn.net/Articles/452865

Cependant, le point qui m'a le plus intéressé (plutôt que le débat classique portable vs non-portabilité) est l'avis d'Al Viro: http://lwn.net/Articles/453529/
Il déteste systemd car il dépend de partie du kernel qu'il n'aime pas comme les cgroup et fanotify, intéressant car j'ignorais que ces parties du kernel était si mal vue..

Il n'aime pas D-Bus, il préfère plumber(*) , ce n'est pas la première critique que je vois de D-Bus, intéressant aussi: quelqu'un connait-il les deux pour donner son avis?

*un protocole dévoloppé pour Plan9: http://en.wikipedia.org/wiki/Plumber_(program)

Bah, tu peux dire tout ce que tu veux, quand les objectifs ne sont pas les même cela ne va pas changer grand chose:
1-les utilisateurs comme Linus (et plein d'autre) veulent un bureau "quasi-stable" i.e les nouvelles fonctionnalité c'est sympa mais uniquement si ça ne change pas trop la façon de faire, si ça n'occupe pas trop de ressource et si ça ne rend pas le bureau plus fragile.
2-ce qu'on voit avec KDE et Gnome, c'est que leurs développeurs (*) veulent faire des nouvelles choses avec des technos intéressantes.

Comme les objectifs des utilisateurs et des développeurs KDE&Gnome sont différents et que les utilisateurs ne payent pas ces développeurs, ce n'est pas surprenant que les utilisateurs 'à la Linus' ne soient pas satisfaits de ce que font les développeurs KDE&Gnome et qu'ils aillent voir ailleurs, heureusement qu'il n'y a pas que KDE et Gnome..

*: pas forcément tous, mais c'est le résultat vu de l'extérieur.

OK, rien j'y suis allé trop fort: SMEP est une avancée intéressante.

Quant aux débordements d'entiers tout bon processeur se doit d'avoir un bit d'overflow sur les opérations entiéres, c'est le cas des X86.

Sauf qu'avec les MIPS, tu peux avoir des trap en cas de débordement sur les opérations entières et si tu as le bon gout de programmer en Ada, ça correspond à une exception, tout ça quasiment gratuitement au niveau performance, contrairement au test des bits d'overflow..

sauf à créer des tampons pur-silicium autogérés ... encore une décennie ou deux soit patient ;-) !

C'est à ça que je fais allusion avec les segments, mais vu la difficulté de faire évoluer les jeux d'instructions des CPUs, une ou deux décennies ne suffiront probablement pas..

ils reviendront quant ça sera stable (kde4 à l'époque)

Je ne sais pas si on peut vraiment juger car peut-on vraiment dire que kde4 soit stable?

Un exemple: apparemment il y a eu intégration d'une réécrite de code pour Strigi/Népomuk entre la dernière "RC" et la livraison finale de KDE4.7,
ce qui veut dire 2 choses: les RC ne sont pas vraiment des RC et il y a du code peu testé dans une version dite stable;
alors je ne suis pas sûr qu'on puisse dire que kde4 soit vraiment stable..

Donc à mon avis, c'est trop tôt pour voir si les utilisateurs qui veulent du stable vont revenir..

Bin non justement dans ce cas présent, il est peu probable que la roue soit réinventée ce qui est dommage car les fabriquants de CPU ajoutent des millions de transistors pour gagner 0.0001% en performance, mais rien pour:
-détecter les débordements d'entier sauf si on a la chance d'avoir un MIPS.
-empêcher les écrasements de buffer..

Et bien ça dépend: si ton application est déjà conçue de manière à limiter l'"abus de privilège" alors le portage est normalement relativement simple, sinon ça peut être compliqué..

Bof, la sécurité ce n'est pas rétro-actif, tu ne peux pas l'appliquer ensuite par des droits d'administrations, enfin tu peux essayer, mais le résultat est inférieur a ce que tu obtiens si tu prends en compte ce besoin lors de la conception..

Sendmail vs Postfix/Qmail, Firefox vs Chrome: tout dans un processus contre une décomposition en processus avec séparation des privilèges, le résultat n'est pas le même et ajouter une politique de sécurité par dessus ne résous pas tout.

Moins de GNU, plus de BSD.

Est-ce vraiment une bonne chose ?

Pour un projet qui se base sur la license BSD, j'imagine que oui!
Après le troll GPL/BSD habituel, bof: on n'est pas Vendredi.

De plus je ne crois pas que LLVM/CLANG fasse partie intégrante du projet, donc il n'y a pas plus de BSD.

LLVM/CLANG est sous license BSD, donc plus de BSD est correct.

Pour en revenir à FreeBSD 9, une grande nouveauté pour moi c'est l'intégration de capsicum! Enfin un OS "grand public"(*) qui fournit des capabilites!

Et puis il y a des développeurs d'OpenBSD qui semblent intéressé, ça aussi c'est une bonne nouvelle car je peux très bien imaginer les développeurs d'OpenBSD utilisant les capabilities autant qu'ils le peuvent dans leurs outils, d'ailleurs apparemment il y en a qui portent OpenSSH sur capsicum.

Linux est en retard sur ce coup la(**), quand on voit les bidouilles infâmes que sont obligés de faire les développeurs de Chrome pour avoir un bac à sable sur Linux (ils sont obligés d'intégrer un dé-assembleur x86! ).. Et c'est un vrai problème, car plus c'est sale:
1) moins ça a de chance d'être adopté par d'autre logiciels
2) plus ça a de chance d'être buggé..

*: par rapport à KeyKOS, EROS, CapROS, Coyotos, FreeBSD est grand public!
**: Linux a les POSIX capabilites, mais pas les capabilites ce qui n'est pas du tout la même chose.

Pourra t'on améliorer le logiciel de la freebox ?

Je ne sais pas, mais vu comment Free a lutté pour garder le code secret, cela ne m'étonnerait pas qu'ils utilisent la tivoisation pour s'assurer que le logiciel qui tourne sur la Freebox ne soit pas modifié..

Une première étape est d'avoir un bon niveau en C.

En C et en Anglais je dirais.

D'un coté je suis d'accord pour dire que faire une RC avec un projet de la taille de KDE ce n'est pas évident.
De l'autre, il y a plein de gens qui désactivent Nepomuk donc s'il n'est pas prêt pour une release, pourquoi l'activer par défaut?

Multiplier des fonctionnalités au détriment de la fiabilité, bof.

Mesa a le même comportement, ils utilisent des RC mais déconseillent quand même l'utilisation de la x.y.0 en production.

D'un autre coté, il y a Linus qui quand il fait un patch de 15 lignes fait une nouvelle RC car c'était dans un domaine compliqué,
il a eu raison d'ailleurs car le correctif n'était pas encore 100% correct (*), tu peux toujours trouver des gens qui ont un mauvais processus de développement,
ça ne veut pas dire qu'il faut les imiter pour autant..
/mode c'était mieux avant/ A une époque KDE avait des vrais RC..

*: http://lwn.net/Articles/452117/

Bah, dans ce cas là, c'est plutôt malhonnête(*) d'appeler ça des RC, ce sont des béta-versions pas des RC.

Je trouve que imr a tort quand il dit "Ca fait longtemps que RC veut dire alpha et pas seulement pour KDE":
certain mots comme "hacker" n'ont plus leur sens original, mais pour RC ce n'est pas encore le cas,
donc soit KDE utilise vraiment un système a base de RC et respecte le principe, soit ils utilisent des "béta" versions
c'est à eux de choisir, les deux sont défendables (les RC ça ne marche que si il y a suffisamment de testeurs), mais dire l'un et faire l'autre: beurk!

*: le terme est trop fort, mais je n'ai pas trouver mieux.

Merci pour le lien, la partie que je trouve amusante c'est qu'il me semble que c'est la troisième version pour les IO.
Java c'est un escargot: ça bouge, mais alors l'évolution est d'une lenteur..
La page que tu donnes à un sous lien (en Anglais) sur ce sujet, c'est hilarant ou triste selon l'humeur:
http://today.java.net/pub/a/today/2008/07/03/jsr-203-new-file-apis.html

Peut-être que Java finira par intégrer les évolutions de Scala/Kotlin, mais je pense qu'à ce rythme ce ne sera pas pour ce millénaire..

Pas réveillé, je lis la liste des améliorations en me disant "Tiens? C'est bien tout ça." jusqu'à ce que j'arrive à la fin de ton journal.
Bref, je me suis bien fait avoir, bravo!

Juste une question: c'est quoi les "safe navigation operator"?

Leur documentation conseille d'utiliser Qt4.7.4 le site web de Qt dit que la dernière version est la 4.7.3, bon ça c'est juste amusant.

Beaucoup plus gênant sur le forum kde, quelqu'un a dit
qu'une portion significante de strigi/nepomuk avaient été réécrite et intégré après la dernière RC!
Si c'est vrai (et je pense que ça l'est car personne ne l'a corrigé) alors intégrer une grosse modification, activée par défaut, ils ont du oublier ce que
"Release Candidate" voulait dire..

Je me demande pourquoi les développeurs de KDE autorisent ce genre de chose?
Si c'est du code important, alors il faut le tester sérieusement (quitte à retarder la livraison),
si le code n'est pas important et qu'on n'a pas eu le temps de le tester sérieusement, alors il faut le désactiver par défaut.

Les autres options ne me paraissent vraiment pas sérieuse..

Oui mais n'est-il pas encore plus efficace de mettre plus de RAM avec le budget économisé sur le SSD?

Et bien ça dépend: si ton appli fait des fsync a la pelle (Firefox..), ou au démarrage d'une application/du système, mettre plus de RAM ne t'aidera pas: un SSD si,
mais il y a des cas ou plus de RAM est mieux qu'un SSD oui.

Linux prêt pour le desktop, je dois l'entendre depuis plus de 10 ans déjà.

Et bien ça dépend beaucoup de ce que tu entends par "prêt pour le desktop"!
Si par ça tu entends: je peux faire du développement avec vi et gcc, oui il est prêt depuis longtemps..

Si pour toi, c'est "il y a plein de jeux 3D d'un niveau comparable à ce qui existe sous Windows", bin non il n'est pas prêt (oui je connais Wine)..

Pour les SSDs, c'est pareil c'est plutôt subjectif, personnellement je pense que si tu as 1) suffisamment de RAM (à partir d'un certain niveau ça n'aide plus beaucoup), 2) un disque dur rapide mais que ton ordinateur ne te semble toujours pas assez réactif (et que le CPU n'est pas en cause) alors ta seule option réaliste est le SSD..

C'est à ça que cela me fait penser..
Ils feraient mieux de mettre le paquet sur Electrolysis, parce que sans ça l'architecture de Firefox fait vraiment obsolète par rapport à celle de Chrome/Chromium.
Une fois qu'ils auront compléter ça, alors ils pourront passer à autre chose, avant bof..

Les segments sont utilisé par personne.

Oui, c'est un très bon argument: on voit bien que la sécurité actuelle est parfaite donc ne changeons rien! ;-)
Sinon un article qui parle des segments et de leur intérêt pour la sécurité (note que l'implémentation des segments pour le x86 est différente):
http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-02.pdf

Tout d'abord un grand merci pour cette dépêche.

Juste une petite note: tu notes qu'il était possible d'avoir l'équivalent de la fonctionnalité de SMEP grâce à la segmentation, cependant la segmentation n'est disponible qu'en mode 32bit pour les x86: AMD l'a retiré dans le mode 64bit,
dommage pour une fois que les x86 avaient une fonctionnalité intéressante (pour la sécurité)..

A quand un CPU ayant des pointeurs 96 bits (64bit d'adressage et 32bit de segments)?
Ça rendrait très difficile l'exploitation de débordement de tampons!

Il faut impérativement un FAI ?
Je ne vois pas pourquoi.
Un serveur quelconque suffit. On se connecte en https dessus et hop, le serveur s'occupe du VPN (car c'est un VPN).
Alors bien sûr, ça complique car un serveur quelconque, ça fait facilement louche.

Je suis d'accord: je l'ai suggéré ci-dessous, après pour que cela ait de l'intérêt par rapport à un proxy Tor, il faut que ce soit un "vrai" site web,
autrement on n'a pas gagné grand chose..

Ha bon, et comment ça reste secret tout cela ?

De la même façon que les IP des proxys Tor restent secrets.. Pas plus, pas moins, sachant que si un gouvernement récupère une clef publique ce n'est pas trop grave: c'est moins risqué pour l'utilisateur, car 'à priori' le gouvernement ne peut distinguer les utilisateurs normaux des utilisateurs contournant le parefeu.

Si je suis le gouvernement français (non, pardon, chinois, en France on ne fait pas des choses pareilles) j'ai vite fait de diligenter les bonnes personnes pour récupérer le nécessaire de décodage. Les bonnes personnes n'ayant éventuellement même pas besoin de se déplacer.

La sécurité parfaite ça n'existe pas, mais compare ça à surveiller des utilisateurs de proxy Tor, qu'est-ce qui est le plus facile?
Dans un cas, il faut juste recuperer les adresses IP des proxys et enregistrer les adresses IP des utilisateurs,
dans l'autre il faut recuperer une clef privée en plus: pas si facile!

Il y a peu de change que les FAI implémentent Télex, mais des sites web dont les propriétaires estiment que fournir une passerelle à des Internautes Chinois est plus important que de risquer un filtrage par le gouvernement Chinois pourraient décider d'implémenter Télex.

L'avantage pour l'utilisateur c'est qu'utiliser un site web "Telexiser" est beaucoup moins incriminent qu'un proxy-Tor car pour savoir qu'il s'agit d'une requete Telex et non pas d'une requete HTTPS, il faut connaitre la clef privé du site.
Est-ce que ça existe déjà des proxy "discrets" qui réutilisent HTTPS?

Une question que j'aurais du poser dans le journal: à votre avis des FAI vont-ils implémenter Télex quand ce sera un logiciel mature?
Même sans incitation des gouvernements?

Euh, je ne pense pas que les smartphones soient la cible: les ARM n'ont pas toujours des performances en calcul flottant super,
alors le changement de représentation des réels de fixed-point à floating-point ne serait pas forcément une bonne idée..