reno a écrit 3880 commentaires

Pour être simple et robuste, Venti ne permet pas de supprimer des données, seulement d'en ajouter.

Ça, ça n'est pas être simple, c'est être un FS inutilisable, un jouet: pas de quoi se vanter..
A un moment donnée je sauvegarde un gros fichier (un film par exemple) et je ne peux plus l'effacer??

Un OS ne devrait-il pas être « fait » pour N machines, N à partir de 1 ?

Gérer le cas "N > 1 machines", ça rajoute quand même une sacrée complexité à l'OS..
C'est sympa pour les utilisateurs, sauf que les problèmes d'annuaire et autre se retrouvent à l'identique dès que tu as un parc hétérogène..

Par rapport aux shells classiques qui sont bien trop fragiles: mets des espaces, des caractères spéciaux et beaucoup de scripts ne fonctionnent plus, mais en transmettant des objets et non plus du texte, PowerShell améliore le pipe classique.
Après le problème du PowerShell c'est qu'il vit dans le monde Windows qui est très,très mal conçu par bien des aspects ..

A priori, rien: Le point fort de Plan9, c'est surtout le gain en souplesse liée à la généralisation des "principes d'Unix" je doute que ça se remarque sur une utilisation occasionnelle..
Tout comme un utilisateur de DOS ne remarquera pas tout de suite, le gain en puissance lié au Shell UNIX et que les dev UNIX ont ignoré l'avancée de PowerShell..

Est-ce que tu as déjà vu le merdier que c’est NFS?
En plus rien à voir, ce sont des logiciels différents qui s’occupent de gérer le système de fichier local et NFS.
RAF et RAF!
L'important est que l'*interface*(l'API) soit la même (cf Plan9) mais comme avec Wayland ils n'ont fait que la moitié "facile" du boulot,
on peut s'attendre à ce que le résultat soit un bazar incohérent..

L'affichage local et l'affichage distant, ce ne sont pas du tout les mêmes contraintes.

L'accès aux fichiers disque en local et en distant, ce ne sont pas du tout les mêmes contraintes, mais je suis content quand même que NFS existe..

mais je dois concéder à Microsoft qu'essayer d'introduire une vraie rupture par rapport à l'ancien (qui date quand même de Win 95) est une bonne chose.

Bah, qu'il y ait une mode des interfaces utilisateurs et que donc le changement pour le changement soit un plus, hum, comment-dire, c'est la victoire du marketing sur la "vraie" simplicité d'utilisation.
Tu ne doit pas aimer la ligne de commande, ça ne change pas assez..

Tiens, je te conseille de lire ça des nouveautés:
http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/
j'aime bien son point de vue.

PS: Je ne dis pas que ça s'applique à Wayland (ne serait-ce qu'à cause des failles de sécurité inacceptable d'X), par contre systemd, j'ai l'impression que la compatibilité avec SysVinit est loin d'être parfaite (d'après une page de LWN, désolé elle est encore 'réservée aux contributeurs') et que le coté journalisation est encore immature..

Remplace "design propre" par "conception simplifiée en optimisant pour l'affichage local" et je suis d'accord avec toi.
Je ne trouve pas particulièrement "propre" d'avoir relégué l'affichage distant à un statut de 'seconde zone'.

Ça tombe bien, c'est son rôle!

Hum, si tu regarde la page sur X12 et que tu regarde Wayland, tu te dis que ça n'a rien à voir!
Le point sur la transparence réseau par exemple..

Euh tu es sur? http://www.phoronix.com/scan.php?page=news_item&px=MTUxNjA
Moi pas ;-)

Bah, les démos sont souvent faites:
1) sur le matériel du développeur donc un truc plutôt puissant.
2) avec uniquement le code lié à la démo qui tourne
les problèmes (que ce soit les glitchs visuels ou les effets de saccades) vont apparaitre quand la machine sera "à genoux"
donc pas dans une démo "normale"..

La fluidité lors des déplacements et de changement de taille de fenêtres sera quand même bien supérieure.

Tu met les 2 ensemble, mais je pense que tu ne devrais pas:
-Déplacement de fenêtre: OK, ça sera bien sûr plus fluide car la gestion du déplacement sera faite uniquement par le serveur.

-Pour le changement de taille, ce n'est pas le cas..
Le comportement dépend en fait des choix d'implémentation du compositeur et le problème est en fait qu'il y a un compromis à faire entre la fluidité et le rendu visuel.
A l'heure actuelle X privilégie la fluidité (le corps de la fenetre est redimensionné par le serveur) au rendu (si le client n'envoit pas le contenu à temps, c'est moche), Weston|Gnome/Wayland vont faire le choix opposé: le rendu: on affiche une nouvelle fenetre redimensionné que quand le client l'envoie (donc pas de glitch visuel) au détriment potentiel de la fluidité (si le client n'arrive pas à suivre le rythme le redimensionnement de la fenêtre sera 'saccadé'), KWin va rester sur la gestion des décorations coté serveur donc je pense qu'il aura le même "défaut" qu'X.

A mon avis, l'utilisateur final ne verras pas de grande différence entre wayland et Xorg. Voire même, il n'en verra pas du tout.

Ça dépend, sur les petites configurations, l’amélioration en efficacité en local pourra se ressentir, d'autant plus que dans certains cas le compositeur Wayland sera + optimisé que ne l'est le compositeur X (Raspberry Pi).

Après dans des configurations "normales" effectivement ça m'étonnerait que ça se ressente beaucoup, mis à part les nouveaux bugs (nouveau code --> nouveaux bugs) et pire les problèmes de conception/d'écosystème qui vont mettre pas mal de temps à se résoudre: un exemple si un compositeur A a un backend pour faire X (RDP par exemple), ça n'implique en rien qu'un compositeur B va supporter aussi cette backend (sauf si A et B sont 2 plugins d'un même compositeur bien sûr), je pense que les utilisateurs vont bien s'arracher les cheveux au début pour choisir quel compositeur prendre, après quand la poussière sera retombée ça ira beaucoup mieux.

C'est une transition, donc comme toute transition ça dépendra beaucoup de la stratégie utilisée pour la distribution..

Puisque ton journal est le dernier sur le sujet, j'en profite pour donner un lien de LWN http://lwn.net/Articles/584029/ qui indique Scientific Linux pourrait devenir une variante de CentOS.
Pour une fois qu'on assiste à des regroupements de ressources plutôt qu'à des fork, je trouve ça intéressant..

Hum, accumuler des solutions sous-optimales pendant des années est un problème: ça finit par "c'est in-maintenable, on réécrit tout du début", je trouve que les blogs de Michael Meeks montrent qu'on peut retravailler en profondeur un logiciel pour l’améliorer même quand il était dans un état lamentable.

Déjà les commentaires en Allemands… Ça, ça mérite d'être dénigré!

Et tu marques "A l'époque ou le code a été écrit et avec les outils dispo, ils n'auraient probablement pas fait mieux.", c'est faux, il y a plusieurs styles de développement:
-on utilise les outils dispo et on contourne leurs problèmes dans notre code.
-on corrige les outils dispo s'ils ont des problèmes et on a du code propre.

Et puis il y a des développeurs meilleur que d'autre, cf la conception pas très heureuse de Calc..

Pour le code ça m'étonnerait, il me semble qu'il est parti d'un moteur GPL existant..
Pour les data, elles seront en "CreativeCommons Attribution 4.0 International" donc le jeux sera vraiment libre.

Et aussi pourquoi être passé de C# à C++?
C'était marqué dans le lien du premier message vers les screenshots et j'avoue que ça m'a surpris..

Non, le Coran ne dit pas qu'il faut exterminer toute religion. Il contient plutôt des règles de bonnes conduites en fait, et incite à la paix, à la tolérance, et au pardon.

Hum, tu es sûr? Il me semblait pourtant que le changement de religion ou que ceux qui prêchaient pour une autre religion n'était pas vraiment considéré avec tolérance dans le Coran..

Ce qui me paraissait un gros point au niveau sécurité, maintenant je ne l'ai pas vu dans les release note alors j'ignore si c'est le cas..

Hum, prendre cette page avec beaucoup de pincettes: Qt for D est morts d'après ce j'ai lu sur les forums de D..
Il y a plein de bindings Qt qui sont en fait inutilisable..

Si je dois en refaire ce sera juste parce que le projet sur lequel je bosse l'utilise.

Ou le langage: les bindings Qt disponible sont ridicules (hors de C++ et Python, dommage!) comparés à ceux de GTK..

Les VLIWs classiques avaient un jeu d'instruction qui montrait directement le matériel pour optimiser l'utilisation du matériel: changement de techno == plus d'unité fonctionnelle --> changement de jeu d'instruction..

L'Itanium n'est pas un VLIW classique de ce point de vue, il y a en effet la compatibilité binaire d'une version à l'autre..

Une grande partie de ce boulot pourrait être fait en statique, une fois pour toute.

Pas d'accord: un load ça peut être assez rapide (cache L1) ou très lent (RAM), et vu qu'il y a beaucoup de load, tu as au contraire une grande partie du boulot qui a une durée très imprévisible où les algos statique ont des problèmes..

Les VLIW ce n'est pas nouveau, ils ont 2 gros problèmes:
- d'un processeur a l'autre, on perd la compatibilité binaire.
- les compilateurs fonctionnent bien que pour du code scientifique très régulier, pas pour du code "normal": c'est la raison principale pour laquelle l'Itanium (qui est une sorte de VLIW) s'est planté en beauté..

D'ailleur sur le sujet, certains réfléchissent beaucoup, cf l'architecture "Mill CPU" qui est un projet de VLIW, mais qui n'existe que sur le papier actuellement:
http://www.reddit.com/r/programming/search?q=mill+cpu&restrict_sr=on&sort=relevance&t=all