reno a écrit 3886 commentaires

Je pense qu'il parle de fenetres en onglets, comme BeOS.
Sinon, franchement, les messages "cette application ne repond pas, voulez vous …" je connais sous Windows, je ne suis pas impatient de retrouver l'equivalent sous Linux, tout ca pour avoir des fenetres jolies quand on les déplace/déforme..

Dans Wayland, il y a une nette separation entre les clients et le serveur d'affichage/gestionnaire de fenetre/compositeur pour des raisons de sécurité et de performance.
Donc un dock est plutot censé faire partie du serveur, eventuellement par un plugin (Weston le permet).
Apres j'ai comme un doute que les dev de KDE ou Gnome considèrent comme prioritaire dimplementer des interfaces qui remplacent ce qu'ils font eux même..

Normalement, tous les compositeurs implémentant Wayland sont (ou seront) équivalents, c'est transparent pour l'application cliente.

Ouh la attention! Les compositeurs seront équivalent pour l'affichage des fenêtres mais par exemple Weston a une sortie RDP et il n'est pas du tout garanti que les autres compositeurs l'auront..

Pour le reste, les interfaces privilégiées dont tu parles, devraient être dans xdg-shell qui est en cours de développement.

C'est impressionnant comme durée de vie!
Je me demandes quel autres logiciels ont >30 ans et sont toujours utilisés..

Hum, je crois que la ba aussi, ça aurait pu se passer comme ça s'ils n'étaient pas tombés sur des gens intelligents..

En Ada (de mémoire) rien ne t’empêche d'avoir un pointeur entre 2 structure de durée de vie incompatible si tu gère la mémoire manuellement, en Rust il me semble que le système de type est là pour éviter les erreurs 'use after free'..

Ce qui a un coût lors de l'écriture du programme: il faut associer aux variables avec leur durée de vie, ceux qui se plaignaient qu'Ada c'était trop stricte, et bien Rust ça l'est encore plus!

T’inquiètes, on a Rust sur le feu pour éviter ce genre de soucis. :p

C'est vrai qu'un nouveau langage est nécessaire pour éviter les dépassement de tampon, Ada, OCaml, Java et autres ça n'existe pas..

Lennart devrait nous régler la question dans pas très longtemps, je pense.

J'ignore si tu plaisante ou pas, mais systemd a un support des bacs à sables, comme les bacs à sables et le packaging ont un lien (c'est beaucoup plus simple si tu peux installer des packages dans un bac à sable sans que le système hôte les voient), ce n'est pas à exclure qu'il y ai de l'action de ce coté là..

Pour revenir au sujet du journal, il y a 2 types d'outils de packaging:
-les "classiques" qui ont grosso-modo les mêmes fonctionnalités: rpm vs deb par exemple.
Dans ce cas là effectivement, c'est une diversité négative: plus d'outils a apprendre qui font la même chose, donc une perte de temps et d'énergie considérable.

-ceux qui apportent des nouvelles fonctionnalités: Nix là, c'est justifié.
Mais bien sûr, Nix a AUSSI un clone Guix, pfff..

Mais bon dans tout les cas, la duplication d'efforts dans ce domaine existe depuis longtemps, donc je ne vois pas trop la situation évoluer..

On voit ce que ça donne avec le cloud souverain.

Je ne sais pas exactement ce que tu entends par là mais le cloud étant sur du matériel physique avoir un cloud Français a un sens, un OS Français, désolé quoi qu'en dise Benoit Jacob, je ne vois pas 1)quel est l'intérêt 2)ce que c'est

1) Coté sécurité Linux est une passoire (on parle de se défendre contre la NSA hein, pas contre un cracker du Dimanche), donc je ne vois pas l'intérêt d'avoir une n-ième distribution Linux.
Pour avoir un vrai OS sécurisé, il faudrait ressusciter un truc du genre de Coyotos, ça, ça aurait un intérêt coté sécurité, mais bon vu qu'il faudrait tout réécrire..

2) c'est quoi un OS Français? Une distribution Linux|BSD gérée par une entreprise Française?
Donc ~1% du travail (la sélection et la configuration des paquets) est fait par une entreprise Française et ça en fait un OS Français??

Le gouvernement n'a pas aidé Mandrake (rappel: l'espionnage des Américains et des autres, ça n'est pas nouveau(!!!)), pourquoi le ferait-il pour Firefox OS?
Pour quelles raisons?

J'avais remarqué aussi mais pourquoi ce phénomène apparait qu'en France?

Pas la moindre idée, mais lors d'un séjour (qui commence à dater) aux USA, j'avais remarqué qu'il y avait bien moins de magazine sur Linux qu'en France, pourtant j’étais à Palo Alto et San Francisco, pas vraiment un coin des US arriéré au niveau informatique..

Probable: dans mon cas, j'étais fainéant pour passer le boot par défaut du PC familial de XP à Linux mais la fin des MAJ de WindowsXP m'a décidé..

Eviv Xubuntu.

Attendez donc quand wayland va arriver… Ca va etre rigolo les aspects des fenetres qui seront toutes differentes suivant ton toolkit…

Au début, c'est probable en effet, mais après ce n'est pas parce que
1) la décoration des fenetres PEUT être gérée par le client qu'elle DOIT être gérée par le client. Le dev de KWin pense utiliser la décoration coté serveur.
2) même en cas de décoration gérée par les clients, on peut envisager une "libdeco" partagée par plusieurs toolkits.
Après, effectivement quand on regarde le bordel actuel ça ne rend pas optimiste entre ce qu'il est possible de faire et ce qui va arriver en pratique..

C'est plus simple effectivement d'utiliser une distribution bleeding-edge mais il y a probablement moins de "variantes" de Wayland que dans RB OS, après tout dépend de ce qu'on veut faire..

PS:
D'après un post sur phoronix Wayland ne marche pas non plus avec Nouveau sur RB OS..

La façon la plus simple de tester les diverses combinaisons de Wayland est probablement d'utiliser la distribution "RebeccaBlackOS" qui vient d'être mise à jour avec Wayland 1.5:
http://lists.freedesktop.org/archives/wayland-devel/2014-May/015158.html
http://sourceforge.net/projects/rebeccablackos/files/2014-05-26/
http://www.phoronix.com/scan.php?page=news_item&px=MTcwMzQ

À priori master/slave --> primary/replica ça ne me choquait pas particulièrement (mis à part la raison loufoque pour le changement) et puis je me suis souvenu que dans certaines base de donnée on a de la réplication multi-maitre et donc ça deviendrait "multi-primary" et là il faudrait demander à un Anglais pour être sûr mais je trouve que ça fait bizarre..

Ce que je trouve dommage quand il y a ce genre d'absurdité, c'est que les journalistes ne mettent pas en difficulté quelqu'un qui sort un truc absurde comme ça..
Les hommes politiques sont entrainés pour se sortir par sophisme de n'importe quel situation difficile mais là, ça n'aurait pas été compliqué quand même de faire remarquer les énormes incohérences que tu signales.

J'oubliais: Weston a une backend RDP donc il y a déjà la "transparence réseau" dans le monde Wayland en dehors de X, enfin si et seulement si tu utilise Weston bien sûr!
Avec les compositeur Wayland de Gnome ou de KDE là..

Ça dépend de ce que tu appelles NX + Wayland..

Si c'est "les applis continue a appeler X et utiliser NX + XWayland pour l'accès distant à un bureau Wayland", je ne vois pas ou est le problème (enfin si je le vois, le proche futur où les devs GTK et Qt qui disent X11 c'est obsolète, on ne supporte plus).

Si tu veux dire avoir l'équivalent de NX directement sur Wayland, en théorie non ça ne devrait pas bien marcher en WAN et faible BP, en pratique il faut voir ça peut dépendre des applis, des thèmes, de la méthode de compression utilisée..

Si on ne veut pas que des weberies, c'est important la transparence réseau, et qui marche !

Je suis d'accord, mais la difficulté c'est que quand tu fais la combinatoire:
(LAN ou WAN) * (client léger ou client lourd) * (machine distante normale ou machine distante type serveur sans carte graphique/carte graphique minimale), ça fait beaucoup de cas différent et les piles graphiques qui se comportent bien dans chacun des cas sont totalement différentes.

La "solution" d'accès distant sur Wayland (envoyer les delta entre les images obtenues) devrait très bien fonctionner en LAN entre 2 machines puissantes peut-être même mieux que X, après dans les autres cas effectivement ça sera probablement pas terrible mais bon il reste X (XWayland) pour ces cas là..

(ou pas encore)

Pas dans ce cas là cf le post de (reynum)[http://linuxfr.org/nodes/102256/comments/1538894].

Parce que Wayland est seulement le protocole universel de "bas niveau" pour échanger des buffers.

Universel dans le sens ou il ne dépend pas d'un cas d'utilisation particulier.

Au dessus il y a plusieurs protocoles qui dépendent de la situation:
-pour un desktop xdg-shell dans Weston (et les autres compositeurs de bureau)
- je crois que l'industrie auto a un protocole au dessus de Wayland pour la centrale embarquée
etc.

C'est le protocole qu'ils mettent au point: ils essayent de faire une interface 'standardisée' pour qu'il y ai interopérabilité entre les applications et les desktop.
Qu'une appli Qt puissent fonctionner dans un desktop GNOME par exemple.

C'est faux. Il y en a qui ont râlé parce que désactiver le successeur est moins intuitif.

Pas seulement, apparemment si tu ajoutes ton home il reste quand même actif et indexe le reste..

Bah, le look de KDE n'est pas le problème, le problème c'est la philosophie du projet (les devs d'abord, même quand c'est pour activer par défauts des fonctionnalités moisies).

Donc si les devs de LXQt s'inspirent du look de KDE, ça n'est pas un problème..

Hum, le tweet dit, empêche l'exploit de cette vulnérabilité.
Tout les exploits ou celui là en particulier?
Là est la question..