Siosm a écrit 50 commentaires

Donc "supporté/développé par Ubuntu" équivaut chez toi à "pas supporté du tout". J'imagine que ça fera plaisir à tous ceux qui bossent chez eux.

La tournure fâcheuse de ma phrase de conclusion peut laisser sous entendre que c'est ce que je pense. Ce n'est pas du tout le cas. J'ai pris grand soin de préciser à chaque fois que les logiciels n'était plus supportés que par les développeurs Ubuntu. Il n'y a aucun jugement de valeur. C'est une constatation de la charge de travail grandissante qui ne sera supportée que par Ubuntu, pendant cinq ans, et ceci alors que les prochaines versions n'utiliserons pas les mêmes logiciels (Upstart/systemd, Compiz/Mir).

C'est pas comme si côté Desktop Ubuntu et ses dérivés étaient très répandus hein.

Le fait qu'une distribution soit populaire auprès des utilisateurs ne va pas réduire la charge de travail des mainteneurs.

genre ils vont intégré systemd à l'arrache dans une LTS alors que ça fait des années qu'upstart est correctement intégré.

Je n'ai jamais dit cela. Comme Ubuntu n'a pas attendu Debian pour choisir d'utiliser et de développer Upstart, Ubuntu n'avait pas plus de raison d'attendre le choix de Debian pour se positionner sur le futur d'Upstart. Le travail d'intégration aurait pu démarrer bien avant.

Ce travail d'intégration de systemd dans les distributions a déjà été en grande partie fait par toutes les autres distributions et par Debian. Il aurait peut-être été judicieux d'envisager de reporter la date de sortie de cette version comme cela avait été fait pour la version 6.06.

Donc si j'ai bien compris, le statu quo chez Debian est plus acceptable que chez Ubuntu.

Les situations ne sont pas du tout comparables. systemd est disponible dans Debian depuis un certain temps et fonctionne. Ce n'est pas le cas dans la version 14.04 d'Ubuntu (ils viennent juste de rendre systemd fonctionnel en prévision de la 14.10). Debian s'est donné les moyens de prendre une décision en mettant à disposition toute les alternatives.

Ça me semble raisonnable d'attendre la décision du projet upstream avant de changer.

Ont-il attendu que Debian passe sur Upstart pour passer sur Upstart ?

Il se moque des améliorations liées à la sécurité dans le noyau Linux et insulte les développeurs noyau.

Tout d'abord, je tiens à préciser que le fait que je rapporte ses propos (ou ses vidéos) dans la catégorie sécurité (et les commentaires) ne veut pas dire que je cautionne son comportement. Je trouve son attitude, son égocentrisme et ses critiques gratuites à tout va déplacés.

En revanche, il faut noter que sur le plan de la réflexion en terme de sécurité, le projet grsecurity est très en avance sur la majeure partie des protections. Il faut donc absolument tenir compte de leurs arguments même si ils ne les expriment pas de la meilleure façon malheureusement.

Je pense que le travail de fond sur la randomization de l'espace d'adressage du noyau est une bonne chose.

Je pense que kASLR n'est pas une bonne idée. Les raisons sont simples et elles sont détaillés dans l'article sur le blog/forum de grsecurity :
- Le principe même d'ALSR est un cache misère et non pas une solution ;
- ASLR marche pour les processus parce les adresses mémoires changent à chaque exécution. Avec kASLR, ce n'est pas le cas, les adresses ne changent qu'au démarrage ;
- ASLR marche parce que l'intervalle disponible pour rendre les adresses mémoires aléatoires est très grand, donc les probabilités de trouver la bonne très faibles. Dans le cas de kASLR, l'intervalle est beaucoup plus petit : il est beaucoup plus facile de tomber sur la bonne adresse ;
- ASLR est efficace sur un système si et seulement si l'on dispose d'un mécanisme pour empêcher un programme en cours de brute force de s'exécuter après un certain nombre de crashs suspects. Ce n'est pas le cas de kASLR, puisqu'il est possible de faire crasher en continu un driver par exemple qui sera rechargé à nouveau et que l'on pourra continuer d'exploiter car les adresses ne sont changées qu'au démarrage de la machine. N'importe quel bug non fatal dans le kernel pourra être utilisé ainsi ;
- kASLR introduit de la complexité (inutile) dans le noyau au démarrage, lors du débogage…

il ferait mieux d'apprendre à communiquer avec les développeurs pour faire entrer ses grosses modifications GRSecurity dans le noyau.

On espère tous que cela se produira un jour. Je pense qu'il nous faut plutôt un courageux pour faire le boulot.

Comme prévu (c'était en quelque sorte annoncé dans sa critique sur le blog de grsecurity), Brad Spengler a trouvé plusieurs méthodes pour contourner kASLR sur le noyau 3.14, dès sa sortie, avec vidéos à l'appui, mais pas de code source :
* https://twitter.com/grsecurity/status/450760661463998465
* https://twitter.com/grsecurity/status/450831571487301632

Petite précision : je n'ai pas tout fait dans la partie système de fichiers, juste un bout. Je ne sais pas qui a fait le reste (d'où l'importance de s'ajouter dans la liste des contributeurs).

A ma connaissance, CoreOS n'est pas du tout développé par les gens de dotCloud, l'entreprise à l'origine de Docker, dont le nom a d'ailleurs été changé en octobre dernier en Docker Inc (http://blog.docker.io/2013/10/dotcloud-is-becoming-docker-inc/).

CoreOS n'«hypervise» pas non plus de conteneur vu qu'il n'y a tout simplement pas d'hyperviseur dans CoreOS vu que les conteneurs sont une technologie différentes des hyperviseurs et des machines virtuelles.

Docker peut «virtualiser» (sens large) aussi bien une application qu'un système complet (toujours sans le noyau). L'intérêt de Docker réside principalement dans son mécanisme de gestion des images et des «recettes» pour les construire.

2014-03-17 mupuf : Un mainteneur est quelqu'un qui a accepté d'être responsable de la partie sur le long terme. Si il y a déjà un mainteneur sur la partie, tu ne peux t'ajouter que dans la catégorie contributeur. Si tu penses pouvoir faire un meilleur travail sur le long terme, tu peux demander au mainteneur de te laisser la place.

Le but du mainteneur, c'est de forcer une personne à s'investir et suivre les mises à jour pour avoir une vision plus globale du développement. Sans mainteneur, on est à la merci des traductions bêtes et méchantes des commit logs. Parfois, on a même droit à des contre sens complets.

J'aime beaucoup le seul commentaire sur l'article en lien :

awesome example why one should rather use C++

Bref il utilise Upstart de la façon la plus inutile qu'il soit, si RHEL 7 fait pareil avec SystemD, ça promet !

C'est peu probable, vu que la quasi totalité des services sous Fedora depuis la version 18 (la version sur laquelle est basée RHEL si je ne me trompe pas) n'utilisent plus de script d'init mais uniquement les units systemd.

PS: Arrêtez d'écrire systemd n'importe comment s'il vous plaît.

Surtout que Fedora ne l'utilise plus depuis la version 15 : http://fedoraproject.org/wiki/Features/systemd. Le site officiel d'Upstart n'est pas non plus à jour à ce sujet : http://upstart.ubuntu.com/

Je remplace "complètement démarré" par : je peux m'y logger.

Est-ce que les connaisseurs de chaque système d'initialisation pourraient indiquer comment est-ce que l'on fait pour savoir, une fois le système complètement démarré, quels services ont échoué lors du démarrage et quels services sont effectivement lancés ?

Merci

J'ai suivi les instructions officielles et les instructions associées au torrent. Le but ici c'est juste de récupérer les fichiers plus rapidement qu'avec leur système de miroirs. Il n'y a aucun changement par rapport à la release officielle.

Pour ma part, j'ai juste eu à renommer le dossier avec tout le contenu téléchargé en "darkmod" et à copier les missions dans le dossier fms.

Je vous conseille d'aller chercher les fichiers principaux du jeux (et les missions éventuellement) en bittorent sur votre site préféré (la baie des pirates ou autres) parce la dernière fois que j'avais essayé, les serveurs étaient blindés.

Dommage qu'ils n'aient pas prévu un torrent officiel, mode de diffusion qui s'adapte particulièrement bien aux annonces de ce style qui font rapidement tomber les serveurs en téléchargement direct vu la demande.

Version enregistrée au format simple (en utilisant inkscape). Pas d'amélioration pour moi sur Firefox : https://tim.siosm.fr/downloads/emarabout_plain_no_inkscape.svg

PS : Firefox n'affiche pas tout le texte de la version SVG.

En effet, j'avoue, je n'ai pas testé avec Firefox. J'ai fait l'image avec Inkscape.

On peut toujours le remettre facilement maintenant que c'est une version en SVG !

La version PNG : https://tim.siosm.fr/downloads/emarabout.png

Autre lecteur de flux RSS : Leselys, application web écrite en python utilisant mongodb, à héberger soi-même (Page GitHub). Le design est minimal, mais les fonctionnalités sont là et le développement avance vite.

Au fait, ma mauvaise opinion sur « les Waylands » vient principalement de cet article + commentaires : http://smspillaz.wordpress.com/2012/12/24/sideways/ (il travaillait chez Canonical à l'époque, Mir était un POC en interne et son adoption n'avait pas encore été décidée). Le fait que le scénario du pire (les Waylands donc) ce soit réalisé est celon moi l'une des raison qui ont fait perdre la foi en Wayland chez Canonical. C'est pour ça que j'essaye de comprendre.

Je ne vois pas bien où est-ce qu'il a perdu la foi vu qu'il recommande justement de tout mettre dans Weston. C'est très bien, personne n'as dit que si Weston était suffisant pour la plupart des gens alors il fallait nécessairement coder un autre compositeur. Si Weston est assez complet ou personnalisable il deviendra le compositeur par défaut.

Il n'as pas envie de porter compiz pour Wayland parce qu'il trouve que Weston fait déjà le boulot. Tout le monde est content !

Encore une fois, le compositeur alternatif dont on parle le plus est Kwin, et il a plusieurs très bonnes raisons d'exister :
- Tout le code de gestion de fenêtre et de composition est déjà là. La partie jugée difficile par le mainteneur de compiz n'est justement pas mise à la poubelle, elle est réutilisée pour Wayland.
- L'objectif est de conserver une seule base de code au niveau du compositeur/gestionnaire de fenêtre entre Xorg et Wayland. Encore un objectif louable, on pourra tester les deux versions sur une même machine, changer si l'un plante pour une raison ou une autre.

En ce qu'il s'agit de GNOME, je crois que le travail des développeurs parle de lui même (http://lwn.net/Articles/558879/) : ils intègrent leurs outils progressivement. Je n'ai pas encore entendu parlé d'un compositeur spécial GNOME même si des POC on été réalisés (https://wiki.gnome.org/Wayland/GnomeShell).

Pour Enlightenment, ils vont faire leur propre compositeur apparemment. Position que l'on peut tout à fait comprendre puisque leur objectif annoncé est l'embarqué. Ils n'ont donc pas nécessairement besoin de tout ce qui est dans Weston. Je ne connais pas l'état d'avancement du projet.

Le débat Mir/Wayland n'est actuellement pas objectif.

Le débat sur les licences est des plus objectifs selon moi : http://mjg59.dreamwidth.org/25376.html. Tant que l'on aura ce genre de comportement on pourra difficilement parler d'ouverture.

La description des avantages techniques de Wayland le semble aussi : http://blog.martin-graesslin.com/blog/2013/05/mir-in-kubuntu/ && http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1. Si ces liens contenant majoritairement des arguments techniques ne sont pas "objectifs", je ne sais pas ce qu'y l'est.

Je n'ai pas encore trouvé un seul article techniquement pertinent sur les avantages de Mir. Toute la communication de Mark Shuttleworth est basée sur des "buzz word". Toutes les remarques "techniques" des développeurs de Mir se sont fait sévèrement critiquées, et la première chose que l'on a appris lorsque Mir a été annoncé, c'est que ses développeurs ne comprenaient pas comment marchait Wayland. C'est donc un bon début pour le critiquer…

Tout à fait. Mais en pratique personne ne le fait.
C'est là que le bât blesse selon moi, je n'aurais rien à redire si tout le monde avait étendu Weston plutôt que de refaire son propre truc.

Je crois bien me souvenir qu'il y a des gens qui le font chez Intel. De plus ceux qui ont fait les premiers essais de tilling window manager ont modifié aussi Weston et ne sont pas parti de zéro. Weston était prévu à l'origine pour être un exemple, c'est tout. Il est logique que les gens fassent leur propre implémentation.

(Citations suivantes issues d'un autre commentaire)

Même si Mir a été annoncé (trop ?) tard et avec une maladresse incroyable, il me parait techniquement mieux architecturé.

C'est étonnamment pas du tout l'avis de tous les gens que l'on pourrait juger techniquement compétents sur le sujet : les développeurs de la stack graphique sous Linux, qui sont étrangement aussi plus ou moins liés à Wayland/Weston.

On a un serveur qui fourni une API (pas un protocole) et le shell qui vient se brancher dessus (via une couche d'abstraction, ou pas). C'est certes beaucoup plus restrictif, mais ça limite les risques de divisions.

La différence entre un protocole et une API est extrêmement mince ici vu qu'il y une implémentation du protocole Wayland sous forme de bibliothèque. Je vois mal l'avantage que pourrait avoir l'un sur l'autre, si ce n'est que Canonical a clairement annoncé qu'ils ne comptaient pas faire attention à la compatibilité alors que l'objectif de Wayland est justement d'y faire très attention.

Specific compositor implementations may have their own interfaces provided as extensions
C'est ça qui me fait peur. Xorg aussi utilise des extensions par rapport aux specs X11, mais vu que tout le monde l'utilise la question de la compatibilité entre les implémentation ne se pose pas.

Rien ici n'est obligatoire et ce n'est pas la voie qui est envisagée par les environnements de bureau actuels. Ces extensions sont là pour palier aux cas qui ne peuvent pas être prévus actuellement. Tout dans Wayland est fait pour prévoir le futur pour éviter de reproduire la situation avec Xorg.

le support des pilotes Mir

Mais qu'est-ce qu'un "pilote Mir" ? Seul Canonical le sait. En attendant que ça sorte, je vois mal comment on pourrait dire que cela va ou pas marcher. Il est totalement vain de continuer de discuter sur ce sujet et encore plus de dire que cela sera mieux parce que cela n'existe pas !

Quand des boites comme Jolla disent avoir porté Wayland pour qu'il utilise les drivers Android, ça veut juste dire qu'ils ont codé un compositeur spécifique (forké en l’occurrence).

Là encore, on n'en sait absolument rien ! Qu'est-ce qui dit qu'ils ne vont pas reverser entièrement leur compositeur comme un module pour Weston ? Et même dans le cas où ce serait un fork de Weston, ce ne serait pas le premier fork de logiciel réalisé par une entreprise pour l'adapter à un besoin spécifique (Ubuntu/Canonical ?) !

Pour en revenir à mon point initial, l'idée du « chacun son implémentation » va pour moi poser plus de problèmes qu'autre chose.

On a déjà plusieurs toolkits, rien d'insurmontable. Le monde du logiciel libre n'est pas connu pour l'unicité de ses implémentations/outils.

Il aurait mieux fallut rendre Weston plus flexible pour que les différents shells viennent s'y implémenter en tant que plugins.

Est-ce que tu crois vraiment que l'on pourrait merger Compiz et Kwin ou Mutter ? L'idée de vouloir un compositor pour tout le monde part d'une bonne intention mais ne reflète pas la réalité (Webkit/Bink ? il y a des tonnes d'exemples).

Sauf si je fais fausse route, cette FAQ est inexacte. Wayland ne réutilise pas les drivers ni l'infrastructure existante, Wayland n'est qu'un protocole, pas un morceau de code.

Wayland est un protocole avec une implémentation de référence sous forme de bibliothèque.

Weston, UNE implémentation, (qui était certes probablement unique à l'époque) réutilise en effet la pile graphique libre.

Et pas que la pile graphique libre puisque Weston fonctionne aussi sur le Raspberry Pi, qui ne dispose pas de drivers réellement libres, ou sur des téléphones "Android" sans drivers libres non plus.

Il faut se rappeler que Wayland/Weston est développé en partie par des employés de chez Intel, qui ne sont donc pas payés pour supporter tous les drivers exotiques qui existent. Cela n'empêche bien sûr personne de le faire.

Ce que je veux dire c'est que l'ensemble des compositeurs Wayland ne semblent pas partager de code à ce niveau (l'interface) et que c'est selon moi extrêmement casse gueule.

Dans le modèle actuel, il n'y a pas plus de partage de code au niveau de l'interface. Aucun changement à ce niveau.
Si l'on parle de l'interface entre les applications et le compositeur et bien c'est la libwayland. Avant on avait la Xlib ou XCB. Tout cela est bien entendu utilisé/masqué par les toolkits (Qt, GTK+…).

(notez que la situation serait exactement la même si Canonical avait décider de faire son propre compositeur Wayland plutôt que Mir)

Désolé mais non, parce que l'ajout de Mir implique des modifications dans d'autres projets, comme celles nécessaires à l'ajout de Wayland : Mesa, tous les toolkits…
Si ils avaient décidé de faire un compositeur Wayland, rien de tout cela ne serait nécessaire.

Il me semble que KDE et Gnome ont eux aussi prévu d'utiliser un compositeur système pour gérer les sessions, ce qui implique de lancer le compositeur en question bien avant l'écran de login.

Du coup je doute fortement que les compositeurs seront (ou resteront) suffisamment compatibles entre eux pour permettre le switch des environnements de bureau.

En ce moment il y a les logins manager et les environnements de bureau et cela ne pose aucun soucis. Certes un system compositor ferait plus de chose que le login manager, mais il n'y a pas de raison que les environnements deviennent incompatibles. Le but du system compositor est principalement d'assurer le changement d'utilisateur et d'environnement justement (Chapter 2. Types of Compositors). L'avantage avec Wayland justement c'est que l'on peut imbriquer tout ça sans trop de soucis puisque l'imbrication est justement supportée (nested compositing).

Pour cette raison, entre autre, j'ai du mal comprendre pourquoi Wayland demande à tout le monde de ré-implémenter son propre compositeur.

Personne n'est obligé de ré-implémenter son propre compositeur, il est tout à fait possible d'utiliser Weston et de coder juste la partie qui gère les fenêtres ou autre dans un module pour weston. Le mainteneur de Kwin veut faire son propre compositeur parce qu'il ne veut tout simplement pas jeter tout le code de Kwin à la poubelle et qu'il pense pouvoir garder une grande base commune entre le support de X.org et Wayland (la gestion des fenêtre, le rendu des bordure, les thèmes…).

De ce point de vue, l'approche Mir qui consiste à séparer l'implémentation du bureau du serveur d'affichage avec une couche de glue entre les deux me parait être conceptuellement plus intelligente.

L'approche de Mir semble plutôt être de vouloir tout gluer ensemble (https://wiki.ubuntu.com/Mir/Spec?action=AttachFile&do=get&target=mir-scope.png). Je ne comprend pas trop ce qu'il faudrait séparer entre le bureau et le compositeur. Il faut se rappeler que dans le cas de Wayland, ce sont les applications qui font le rendu de leur contenu et le compositeur se charge juste de l'afficher à l'écran et de gérer les fenêtres. Je vois mal comment on pourrait séparer celui qui affiche les fenêtres de celui qui les gère.

(car oui, Mir en lui même n'est absolument pas spécifique à Unity, Canonical à même proposé son aide pour porter les autres shells).

Quelle vaste blague, je pense que l'on peut attendre longtemps l'aide de Cannonical sur ce point. Si ils veulent que les autres shells marchent, ils peuvent tout à fait les porter, on n'attends que ça. J'ai comme l'impression que cela ne vas pas se produire.

Par exemple, si je ne m'abuse, quand les pilotes proprios vont supporter Mir, c'est bien chaque compositeur Wayland qui va devoir se rendre compatible indépendamment.

Toujours pareil, on aimerait bien voir ces fameux drivers avec le support pour Mir. Dans la situation actuelle, principalement sur les téléphones mobiles, il y a libhybris, qui peut être exploitée par Wayland/Weston (http://en.wikipedia.org/wiki/Hybris_%28software%29). Je doute très fortement que Cannonical arrivera à obtenir autre chose que ce "standard" implicite obtenu avec les drivers propriétaires pour Android. Dans le cas ou ils y arriveraient, qu'est-ce qui empêcherait les compositeurs Wayland de supporter aussi cette nouvelle librairie spéciale Mir ?

Bonjour les bugs entre les différentes implémentations. Et qu'est-ce qui nous dit qu'une appli Gnome continuera de fonctionner aussi bien sous Kwin si l'appli en question a été codée en suivant les spécificités de l'implémentation de Wayland faite par Gnome-Shell ?

Il ne faut pas confondre le travail du compositeur avec celui des applications qui ne font que du rendu, en utilisant en grande partie un version d'OpenGL ou du rendu software sur le CPU. Même les drivers propriétaires sont obligés de fournir une librairie 'libgl' si ils veulent que les applications marchent avec leur driver. Coder une application avec des "spécificités de l'implémentation de Wayland faite par Gnome-Shell" est un non-sens. Le protocole est fixé, versionné, et les extensions sont ajoutées dans Wayland, pas par les compositeurs qui vont "remplacer" Weston.