systemd fonctionne bien mieux que SysV (en partie grâce aux cgroups) :
systemd ne démarre que ce dont l'utilisateur a besoin (là où SysV était basé sur le pari que le matériel ne change jamais après le boot. :p Et puis cet idiot démarrait tous les services qu'on lui avait configuré à l'avance. C'est bien, mais c'est peut-être pas la peine de démarrer CUPS alors qu'il n'y a pas d'imprimante…)
on peut enfin tuer un service de manière fiable (vivent les cgroups !)
fini les scripts init nauséabonds et compliqués
on standardise les unit files, plutôt que d'avoir chaque distrib avec ses scripts d'inits propre pour le même service
systemd offre tout une boîte à outils bien utile (systemd-analyze, …)
on peut enfin lancer un service que lorsqu'un évènement arrive (exemple : pas la peine de lancer Apache tant qu'il n'y a pas de connexion réseau)
moins de processus pour démarrer un service (vu qu'on utilise pas de scripting, chose qui n'était pas fait pour ça)
démarrage parralèlisé et plus rapide
gestion des dépendances entre services plus simple
le bordel d'avoir des dizaines de répértoires /etc/rc.d ou /etc/init.d est fini ! \o/
le bordel des runlevels obscurs (dont la définition exacte de chaque peut être différent entre les distribs) est enfin fini est fini (on utilise des targets à la place).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
OK, donc la fonctionnalité qui intéresse tout le monde s’appelle « network-capability ». Merci de l’info, on se couchera moins con ce soir, et nos plus plates excuses pour avoir osé appeler ça de la « network transparency ».
Enfin !
Qu’est-ce que ça change au fait que cette fonctionnalité existe et est utilisée dans X actuellement ?
Rien. Si ce n'est qu'on parle enfin de la même chose.
Le fait que ce ne soit pas de la « transparence réseau » n’est pas une explication justifiant sa non-implémentation dans Wayland.
Ben c'est pas comme ça que c'est justifié. Essentiellement, Wayland ne le spécifie pas, parce que :
1) C'est un erreur de spécifier tout et n'importe quoi dans le marbre (ça donne l'énorme complexité du protocole X11 et de ses multiples extensions, et un code tentaculaire et extrêmement difficile à maintenir/comprendre)
2) Le support des bibliothèques partagées étant universelle aujourd'hui, il n'y a plus besoin d'une architecture client/serveur sous-optimale pour l'affichage local.
3) Wayland est là pour faire une seule chose, et la faire bien : de l'affichage local (Xorg fait essentiellement de l'IPC, et le fait très mal)
Les développeurs de Wayland ont mille raisons valables de ne pas vouloir implémenter cette fonctionnalité (ne serait-ce que la raison qui tue : ce sont eux qui codent),
Ce sont eux qui codent Xorg depuis 10 ans. Et qui codent Wayland depuis 5 ans, en fait.
Ils n’ont pas besoin de jouer sur les mots comme ça. Surtout si c’est pour après venir se plaindre des méchants qui racontent des choses fausses sur Internet.
D'abord, personne ne joue sur les mots.
Ensuite, faut bien expliquer Xorg et ses défauts (y compris les mythes à son sujet, nombreux) avant d'expliquer Wayland et ses objectifs. Ça permet d'avoir du recul.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
1) Les dev de Xorg qui embrassent Wayland ne sont pas neutres, ils défendent leur décision, on n'est pas obligé de répéter bêtement ce qu'ils disent..
Ben en face on confond toujours bêtement transparence réseau et affichage à distance, donc bon.
2) tu n’arrête pas de répéter la transparence réseau ci, la transparence réseau ça, mais tout le monde le sait que la transparence réseau ça n'existe pas vraiment puisque la bande passante et la latence sont totalement différentes ET CA A TOUJOURS ÉTÉ LE CAS (la latence tu sais ça n'a pas beaucoup changé..).
Vous voulez pas comprendre non plus que quand les fenêtres sont complexes (thèmes, thèmes d'icônes, décorations, polices complexes, animations), et qu'on se tape un protocole synchrone et bavard, la latence explose ?
A partir de là, quelle est la définition raisonnable du terme que tout le monde utilise?
Un protocole d'affichage graphique qui intègre l'affichage distant par défaut, point.
Donc quand le dév de Xorg dit qu'il n'est pas network transparent mais juste network-capable, il ne connaît pas le protocole X11 ?
Dur, pour quelqu'un qui travaille dessus depuis 10 ans.
Donc
1) Wayland ne fournit pas ça. On peut ajouter des surcouches à Wayland (dont X), l'implémenter dans le serveur d'affichage (sous-optimal bien sûr, par rapport à une gestion dans le protocole), mais Wayland lui-même est purement local.
2) X11 a l'accès distant en natif lui, même si c'était un accident (quoique vu le nombre d'universités qui se servaient de cette fonctionnalité, c'était un accident très utilisé), même s'il est sous-optimal..
La capacité d'utilisation à distance est prévue dans l'architecture même de Xorg/X11. La transparence réseau, ça, c'était un accident :
Let's go back into the 80s of the last century when X got invented. Back then
Unix didn't support shared libraries. Drawing functions on the other hand were
quite complex and adding it to each process was not possible due to memory
constraints. Therefore a client-server approach was used so that all the
drawing functionality would be in the server and the clients would only need a
considerably smaller library to use the protocol to communicate with the
server.
That's how X became network transparent, but it has never been the aim to be
so, it's rather a side-effect of the constraints by the operating system and
hardware back in those days.
In the last decade moving to the client went even further. All modern toolkits
render completely client side, that is use either CPU or OpenGL to render into
a local buffer and just transfer the resulting image to X. And that's the
point where the network transparency really hits its limits. What we are now
doing is transferring video over X - without any compression, neither loss-
less nor lossy). In such a situation VNC provides clearly the better choices.
The end result of this trend is Wayland which doesn't have a server side
rendering component any more.
Obviously one can say now that everything used to be better in the past, but
there are reasons why it's done that way. CPU or OpenGL is just faster on a
local machine which is as of today the majority of systems. The exchange of
the image data is extremely fast on a local system as one can use the SHM
extension and just use a shared memory segment as the rendering target. So the
local usage increases while the remote capabilities go down. In the discussion
about Wayland one can see again and again that people complain about it, but
nobody "in charge" cares about it, because X was never meant to be used that
way.
Qt 4.(0-7) and Qt 3 and not really different in that regard. Since 4.8
rendering has switched completely to client side by default. If you are using
Qt with network transparency: ensure that the graphics system is set to
native!
But, KDE4's visual style is way more complex. This includes everything: icons,
widget style, window decorations and most important: animations. Especially
Oxygen is very complex (even on a local system it contributes quite a lot to
resource usage) and uses animations. The radial gradient on the global window
is slow in X and by that completely unsuited for network transparent usage.
Therefore: the flatter the style the better. A general recommendation is to
use the Plastique style as widget style and Laptop style in window decoration
(don't use Plastik, it uses strong gradients, too).
Animations are problematic as they are dependent on the connection to the X
server and get slowed down by roundtrips. KDE 3 was rather static and didn't
animate much (I assume that you disabled the tooltips of Kicker). Animations
mean that way more data needs to be transferred to the server and thus one
easily hits bandwith limits. There is a global setting to disable the
animations, though it's not honored by all applications: systemsettings ->
Application Appearance -> Style -> Fine Tuning (tab) -> Graphical effects
(dropdown)
KDE4/QT4 seems to be aimed elsewhere than our sort of usage.
hardly any software written in the last decade is suited for that, because as
I explained X is not suited for it.
It's sadly
not alone there with things like Firefox and Openoffice assuming that
the display device has both a lightspeed connection and infinite
resource.
Especially Firefox is no surprise. The complete content is considered as one
canvas and the modern web is just updating all the time. On a local system it
doesn't matter, but on a remote it means transferring video data for which X
is not suited for. The same more or less with OpenOffice. The rendering is
probably done client side, so it transmits the complete document view as one
image to X whenever it changes. If you are a fast typer that will be painful.
The whole concept of X11 client (lots of resource typically
running on a powerful server grade computer) and X11 server (limited
resource merely a device to provide a mouse/keyboard and screen) seems
to have been forgotten.
No :-) It had never been considered and there are better ways today. Think of
the broadway HTML capabilities of GTK which gives you for example OpenOffice
in a browser.
On a positive note, you offered to tell me how KDE4 can be configured
for a Terminal Server environment and I'll take you up on that; if only
for my own education and to find out what I, and many others it seems,
did wrong.
The general recommendations as already mentioned in this mail summarized:
* ensure graphics system is native
* disable all animations (everywhere)
* don't use Oxygen or any other heavy style - neither as window decoration nor
as widget style
* switch to a less detail icon theme, best disable icons globally for
toolbars, menus, etc. Each icon needs to be transferred uncompressed
* stick to an older version of KDE SC (max 4.8 I'd say), the latest ones use
QML and are probably ignoring the animation settings everywhere because it has
become so easy to do animations.
(ça finira bien par rentrer dans vos têtes dures)
Ceci dit X s'est amélioré avec le temps pour l'accès distant: cache de glyphe XRender qui te permet d'afficher efficacement du texte, XCB asynchrone vs XLib synchrone, là malheureusement les toolkits ont traîné les pieds pour passer à XCB..
De manière amusante c'est Wayland qui a poussé les dev Qt a passé à XCB pour Qt5 (car les deux sont asynchrones), donc l'affichage distant sous X avec Qt devrait s’améliorer grâce à Wayland :-)
Bien.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Pas si rare que ça non. Déjà ce n'est que pour les dernières versions de GTK et QT. Et encore toutes les applications KDE4 sont encore utilisables. Il suffit de les lancer avec l'option --graphicssystem native. Alors prétendre que ça n'existe pas c'est un peu fort de boudin.
X est network capable, j'dis pas le contraire. Mais pas network-transparent. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Oh bordel vous êtes LOURDS à pas vouloir comprendre.
Ça, c’est de la sodomie de drosophile. En quoi le nom de la fonctionnalité change quoi que ce soit ?
Ce sont deux fonctionnalités DIFFÉRENTES.
OK, X est seulement « network-capable ». En quoi ça répond aux inquiétudes de ceux qui utilisent cette fonctionnalité aujourd’hui et qui apprennent que Wayland n’en disposera pas ?
En rien. Au début de la vidéo, il explique d'abord ce qu'est vraiment Xorg, ses problèmes, avant d'expliquer Wayland et ses objectifs.
(Je ne parle pas pour moi, j’ai déjà clairement dit que, bien qu’utilisateur de la « network-capability » de X, elle ne m’était pas indispensable.)
Ah.
En gros, on a le discours suivant :
« Quoi, on ne pourra pas utiliser Wayland à travers le réseau ? Mais euh, j’aimais bien la transparence réseau de X moi, ça me rend bien service.
Ben si on peut. Weston le prouve avec son support RDP et SPICE.
— Vous dites n’importe quoi, ça fait dix ans que X n’est plus transparent vis-à-vis du réseau. On peut l’utiliser en réseau (network-capable) mais ce n’est pas transparent.
Ben oui. La transparence réseau n'est pas un synonyme pour l'utilisation à distance.
— Oui, euh, bon d’accord, appelez-ça comme vous voulez,
Encore une fois ce n'est pas un changement de nom, c'est appeler un chat un chat, et appeler un chien, un chien.
le fait est que ça me rend service de l’utiliser en réseau, c’est dommage de ne pas garder ça dans Wayland.
Si c'est pour réinventer Xorg de A à Z, y'a aucun intérêt. Wayland est là pour remplacer X11/Xorg pour l'affichage local, là où Xorg pose d'énormes problèmes. X11 a montré que mélanger les deux dans un même protocole n'est pas optimal, et amène à casser le standard X11 de dix mille manières subtiles (donc avoir un code schizophrène) pour que ça fonctionne à peu près.
— Mais non, puisque je vous dis que X n’est déjà plus network-transparent, pourquoi Wayland devrait l’être ? »
Wayland c'est pour l'affichage local. VNC, RDP, SPICE, NX, etc… font dix fois mieux que X. Il existe déjà aussi un support RDP et SPICE pour Weston, l'implémentation de référence.
Je ne remets pas en cause les choix des développeurs de Wayland : ils estiment préférable de laisser de côté cette fonctionnalité et de la confier à des outils tiers (RDP ou assimilés), je n’ai rien à y redire. Mais à quoi bon prétendre que la fonctionnalité n’existe pas, n’existe plus, ou jouer sur les mots en disant que puisque X n’est plus network-transparent, Wayland n’a pas à être network-capable ?
Ils prétendent (enfin, ils savent, et les gusses sur LWN.net ou linuxfr racontent des bobards) que X est network-capable, plus network-transparent. À cause de : DRI, les fenêtres beaucoup plus complexes, et le protocole X11 qui n'est pas du tout fait pour l'utilisation en réseau.
Avec Wayland ils veulent remplacer Xorg (qui fait de l'IPC, essentiellement, et dix mille autres choses, très mal) par un logiciel qui fait une seule chose et la fait bien (concept de "every frame is perfect") : de l'affichage en local (voire juste du DRI, vu que presque tout est laissé au compositeur pour ne rien imposer).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Moi quand quelqu'un me dit qu'une fonctionnalité que j'utilise n'existe pas ou que personne s'en sert, je vois pas pourquoi j'aurai de l'estime pour lui.
Il ne dit pas que X n'a pas de capacités réseau, ni que personne ne s'en sert.
Il dit que X n'a pas de transparence réseau.
Qu'il considère que la seule définition de transparence réseau est de la transparence pure et qu'il vienne claironner que c'est un mythe, c'est quand même de la putain de mauvaise foi. Personne ici n'a jamais claironné que tout les buffers passent dans une socket Unix ou que tout les appels de rendu OpenGL passent par X. Par contre tout ceux qui utilisent X en réseau sont d'accord pour parler de transparence réseau même si elle n'est pas pure. S'amuser à changer la définition de transparence réseau pour nous faire dire ce que personne n'a jamais dit, c'est de la stratégie de l'homme de paille et c'est prendre les gens pour des cons.
Il ne fait aucunement cela dans la vidéo ou le texte donné en lien de ce journal, c'est du pur délire de ta part.
Sinon, utiliser X sans DRI, c'est pas comme si il y avais pas une tétrachiée de personne qui l'ont fait, le font et le feront, et ce sans savoir ce qu'est X ou DRI. Il suffit juste qu'ils n'aient pas d'accélération matérielle qui marche pas hors de la boite, qui n'est pas ou mal installée ou qui n'est pas assez stable pour être utilisée par défaut,
C'est bien. Mais le problème de la non-transparence réseau ne se limite pas au direct rendering. Il y a aussi le fait que le protocole X11 est synchrone (mauvais pour l'usage en réseau), beaucoup trop bavard (mauvais pour l'usage en réseau), et que les fenêtres (thèmes, icônes, polices, décorations, animations) sont beaucoup plus lourdes (mauvais pour l'usage en réseau).
Trois gros points noirs qui font que la transparence réseau de X de fait n'est plus (ce qui n'empêche pas X d'être utilisable à distance, encore une fois ce n'est pas une histoire de capacité mais de transparence).
J'affirme pas le contraire. Si X correspond de moins en moins à un besoin desktop d'afficher des effets kikoolol 3D en utilisant une carte graphique bien gérée, surpuissante et directement branchée sur une prise de courant, je suis pas contre le casser.
C'est surtout que X en local introduit beaucoup trop de latence (le protocole fait que X n'attend pas par exemple qu'une fenêtre soit redimensionnée avant de la redessiner en permanence) et de bugs graphiques (ce n'est pas une histoire de pilote - pour chaque élément de la fenêtre, X considère que c'est aussi une fenêtre, et n'assure aucunement la cohérence entre les deux. D'ailleurs, parmis les développeurs de Xorg : "personne ne comprends la fonction de validation d'une fenêtre"). Essaie de redimensionner une fenêtre (ça n'arrive pas uniquement dans ce cas là, c'est juste là où c'est le plus visible), tu verras à quel point ça lag et c'est moche.
Mais si le remplacent ne supporte pas les usages moins desktop, il ne faut pas s'étonner que des gens viennent dire que le remplacent est totalement inutile pour eux, parce qu'ils ont parfaitement raison.
Ben si le remplacant le supporte : pour preuve Weston supporte RDP, et il y a un backend Weston-SPICE sur GitHub.
J'affirme que le cœur du protocole X était 'network transparent', et vu que tu affirme qu'il n'a pas changé, il l'est toujours.
Aucun toolkit graphique ne l'utilise. A moins d'utiliser des applications non-GTK/QT/EFL/Whatever, je doutes que tu utilises des applications qui utilisent encore la vieille API de dessin de X11, en plus des fenêtres très simples des années '80 (eh oui, la transparence réseau, qui n'était qu'un concours de circonstances, c'était à ce prix).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Vas-y reste enfermé dans tes préjugés. Et surtout n'écoute rien d'autre. On dirait un vieux curé qui a peur de perdre la foi en lisant Renan…
Je connais Soral et ses thèses. Je ne vais pas en reprendre, non merci.
D'ailleurs ça serait cool que t'arrête de faire l'amalgame Linux - communisme comme dans ton avatar. Linux n'est pas un OS d'assassins de masse au nom de la « lutte contre le fascisme ».
D'ailleurs, ce serait bien si tu pouvais te greffer un sens de l'humour.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Je ne fais que répeter ce que disent les développeurs de Xorg, et c'est moi le troll ?
D'ailleurs, non, je n'ai pas fini. Du moins, pas avant que ça ne rentre : je ne dis pas que X n'a pas de capacitées pour l'utilisation à distance. Je dis que la transparence réseau a disparu depuis longtemps. La transparence réseau de Xorg existait du temps où chaque application utilisait l'API de dessin de Xorg (qui a une architecture client/serveur, du fait qu'à l'époque Unix ne connaissait pas le concept de bibliothèque partagée).
De fait, la transparence réseau (qui n'était là qu'à cause d'un concours de circonstances) a disparu à cause :
- des toolkits qui n'utilisent plus l'API de dessin mais le direct rendering ("affiche moi cette image et c'est tout")
- des fenêtres qui sont beaucoup plus compliquées graphiquement aujourd'hui (thème graphique, thème d'icônes, décorations, effets graphiques, polices lissées, …)
- du fait du protocole X11, qui n'a jamais été adapté pour une utilisation en réseau (il est synchrone, il induit des allers-retours constants - X11 est très bavard -, …)
Bref, de nos jours, la latence est trop grande pour parler de transparence réseau (à moins d'utiliser des applications qui utilisent les API de dessin de X plutôt qu'un toolkit tel que GTK ou QT, ce qui doit être hyper rare). VNC, SPICE, RDP, font mieux (même si ce n'est pas encore transparent).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Quand tu veux créer un remplaçant, c'est pertinent de créer une solution qui possède à minima le même sous ensemble de fonctionnalités que ce que tu veux remplacer.
Bah non, sinon c'est réinventer la roue (carrée).
Toutes les fonctionnalités non utilisées aujourd'hui dans le protocole X11 ne sont pas dans Wayland. Sinon, Wayland n'aurait aucun intérêt.
Le fait que Xorg soit pourri ne permet pas d'inférer que ces fonctionnalités le sont conceptuellement
Xorg est pourri, et le protocole X11 est composé à 90% de bois mort pour l'affichage local.
sinon on peut très bien dire que Xorg gère très mal l'affichage
Oui, il le gère très mal.
(il tourne en root sauf sous OpenBSD et possède des failles de sécurité permettant l'élévation de privilège de manière assez facile) et donc qu'il ne faut absolument pas implémenter la gestion de l'affichage dans weston.
Weston, c'est une implémentation du protocole Wayland, avec déjà des fonctionnalités réseau (RDP, au moins). Que des capacités d'utilisation à distance soient déjà implémentées dans le compositeur de référence expérimental devrait rassurer les plus grincheux, AMHA.
Il faut différencier :
la fonctionnalité : le réseau
L'affichage à distance, plutôt.
l'une des solutions pour le mettre en place : X11
Très mauvaise solution, trop bavarde et même pas asynchrone.
l'implémentation de cette solution : Xorg
Implémentation pas faite pour le réseau, et qui date des années 80, du temps où Unix ne connaissait pas les bibliothèques partagées.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Je pense que c'est ça qui choque. Que ça soit imparfait c'est une chose, que ça les fasse chier de travailler dessus c'est tout à fait possible, mais vouloir créer un remplaçant en retirant une fonctionnalité utilisée, ça choque toujours (comme quand Google supprime Google Reader par exemple).
À quoi bon réinventer Xorg ?
Autant garder Xorg !
Et puis aujourd'hui déjà, alors que Wayland est à peine implémenté (Weston n'est qu'un exemple, les toolkits et WM ne sont pas encore compatibles, ou pas tout à fait), on a déjà une alternative pour SPICE, et une pour RDP. Donc je vois pas pourquoi il faudrait s'inquiéter. Il y a encore des années de développement avant de commencer un début d'abandon de Xorg.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Je pense qu'il y a pas mal de malentendu, créé par les développeurs eux-même, en affirmant que la transparence réseau n'existe pas.
Non. La transparence réseau de Xorg existait du temps où chaque application utilisait l'API de dessin de Xorg (qui a une architecture client/serveur, du fait qu'à l'époque Unix ne connaissait pas le concept de bibliothèque partagée).
De fait, la transparence réseau (qui n'était là qu'à cause d'un concours de circonstances) a disparu à cause :
- des toolkits qui n'utilisent plus l'API de dessin mais le direct rendering
- des fenêtres qui sont beaucoup plus compliquées graphiquement aujourd'hui (thème graphique, thème d'icônes, décorations, effets graphiques, polices lissées, …)
- du fait du protocole X11, qui n'a jamais été adapté pour une utilisation en réseau (il est synchrone, il induit des allers-retours constants - X11 est très bavard -, …)
C'est juste une hyperbole.
Non. C'est pas de leur faute si plein de monde sur LWN, linuxfr, et ailleurs, confondent transparence réseau et capacitées réseau.
C'est comme dire que Windows n'a pas d'alternative sur PC desktop.
Il y a des alternatives à Xorg pour l'utilisation à distance, mais ça n'utilise pas le protocole X11.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Ça n'a pas l'air de parler franchement de transparence réseau, ou si peu.
Très bien utilise alors ta définition perso, après tout lex dévs de X ont forcément tort.
Tu vas leur expliquer la transparence réseau, et ils vont laisser tomber Wayland à coup sûr !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Si on part sur cet autre définition débile de la transparence réseau, alors elle est impossible quelque soit le protocole et donc n'existe pas.
C'est toi qui confond depuis le début ce que les développeurs de Xorg dénoncent : X est 'network capable' PAS 'network transparent'. Ce n'est plus vrai depuis au moins 10 ans, faut se mettre à la page !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Réinventer la roue, NIH ?
Posté par xcomcmdr . En réponse à la dépêche systemd 208 : logind et Wayland. Évalué à 7. Dernière modification le 06 octobre 2013 à 15:20.
Ni Wayland, ni systemd, n'ont vocation à faire partie d'un quelconque système universel.
systemd : l'init moderne grâce à linux (cgroups, …).
wayland : le protocole moderne pour l'affichage local.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Réinventer la roue, NIH ?
Posté par xcomcmdr . En réponse à la dépêche systemd 208 : logind et Wayland. Évalué à 10. Dernière modification le 05 octobre 2013 à 19:36.
LUL WAT ?!
systemd fonctionne bien mieux que SysV (en partie grâce aux cgroups) :
systemd ne démarre que ce dont l'utilisateur a besoin (là où SysV était basé sur le pari que le matériel ne change jamais après le boot. :p Et puis cet idiot démarrait tous les services qu'on lui avait configuré à l'avance. C'est bien, mais c'est peut-être pas la peine de démarrer CUPS alors qu'il n'y a pas d'imprimante…)
on peut enfin tuer un service de manière fiable (vivent les cgroups !)
fini les scripts init nauséabonds et compliqués
on standardise les unit files, plutôt que d'avoir chaque distrib avec ses scripts d'inits propre pour le même service
systemd offre tout une boîte à outils bien utile (systemd-analyze, …)
on peut enfin lancer un service que lorsqu'un évènement arrive (exemple : pas la peine de lancer Apache tant qu'il n'y a pas de connexion réseau)
moins de processus pour démarrer un service (vu qu'on utilise pas de scripting, chose qui n'était pas fait pour ça)
démarrage parralèlisé et plus rapide
gestion des dépendances entre services plus simple
le bordel d'avoir des dizaines de répértoires /etc/rc.d ou /etc/init.d est fini ! \o/
le bordel des runlevels obscurs (dont la définition exacte de chaque peut être différent entre les distribs) est enfin fini est fini (on utilise des targets à la place).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: je ne crois pas
Posté par xcomcmdr . En réponse au message Entente illégale Intel Microsoft ?. Évalué à 3.
J'ai réussi à installer Windows 7 sur une machine avec un CPU Intel Pentium 3.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Contribuer à la bibliothèque de composants ?
Posté par xcomcmdr . En réponse à la dépêche QElectroTech 0.3. Évalué à 1.
http://linuxfr.org/nodes/93946/comments/1490243
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ubuntu?
Posté par xcomcmdr . En réponse au journal Mon premier journal bookmark... mais que fait la police ?. Évalué à 7.
Pourquoi 6 mois / 3 ans ?!
- Depuis la 12.04, les LTS sont sur 5 ans.
- Les versions non-LTS sont supportés sur 18 mois (9 mois depuis la 13.04).
Et puis les versions LTS comme non-LTS bénéficient de PPAs (la gendarmerie pourrait même faire ses propres PPAs facilement…).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Réinventer la roue, NIH ?
Posté par xcomcmdr . En réponse à la dépêche systemd 208 : logind et Wayland. Évalué à -1.
Ça se voit que c'est vendredi !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mouais…
Posté par xcomcmdr . En réponse au journal "Pussy Riot. Lettre du camp 14 de Mordovie". Évalué à 9. Dernière modification le 02 octobre 2013 à 12:43.
Non, puisque les droits de l'embryon s'effacent devant les droits de la femme, et c'est très bien ainsi.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mouais…
Posté par xcomcmdr . En réponse au journal "Pussy Riot. Lettre du camp 14 de Mordovie". Évalué à 8. Dernière modification le 02 octobre 2013 à 12:19.
"Pro-mort", joli néologisme réducteur.
J'en ai un pour les anti-avortement et les anti-euthanasie : anti-droits (ou chieurs-pros, au choix).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: United State of America : le pays du la liberté d'expression !
Posté par xcomcmdr . En réponse au journal NSA: Est-il interdit de retirer un message indiquant que la NSA est passé vous voir ?. Évalué à 3.
La partie "A well regulated Militia" a été oubliée.
L'USA, pays des snipers !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OSEF
Posté par xcomcmdr . En réponse au journal Le mythe de la transparence réseau. Évalué à 2.
Enfin !
Rien. Si ce n'est qu'on parle enfin de la même chose.
Ben c'est pas comme ça que c'est justifié. Essentiellement, Wayland ne le spécifie pas, parce que :
1) C'est un erreur de spécifier tout et n'importe quoi dans le marbre (ça donne l'énorme complexité du protocole X11 et de ses multiples extensions, et un code tentaculaire et extrêmement difficile à maintenir/comprendre)
2) Le support des bibliothèques partagées étant universelle aujourd'hui, il n'y a plus besoin d'une architecture client/serveur sous-optimale pour l'affichage local.
3) Wayland est là pour faire une seule chose, et la faire bien : de l'affichage local (Xorg fait essentiellement de l'IPC, et le fait très mal)
Ce sont eux qui codent Xorg depuis 10 ans. Et qui codent Wayland depuis 5 ans, en fait.
D'abord, personne ne joue sur les mots.
Ensuite, faut bien expliquer Xorg et ses défauts (y compris les mythes à son sujet, nombreux) avant d'expliquer Wayland et ses objectifs. Ça permet d'avoir du recul.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OSEF
Posté par xcomcmdr . En réponse au journal Le mythe de la transparence réseau. Évalué à 1. Dernière modification le 01 octobre 2013 à 10:29.
Ben en face on confond toujours bêtement transparence réseau et affichage à distance, donc bon.
Vous voulez pas comprendre non plus que quand les fenêtres sont complexes (thèmes, thèmes d'icônes, décorations, polices complexes, animations), et qu'on se tape un protocole synchrone et bavard, la latence explose ?
Donc quand le dév de Xorg dit qu'il n'est pas network transparent mais juste network-capable, il ne connaît pas le protocole X11 ?
Dur, pour quelqu'un qui travaille dessus depuis 10 ans.
La capacité d'utilisation à distance est prévue dans l'architecture même de Xorg/X11. La transparence réseau, ça, c'était un accident :
(ça finira bien par rentrer dans vos têtes dures)
Bien.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OSEF
Posté par xcomcmdr . En réponse au journal Le mythe de la transparence réseau. Évalué à 2.
X est network capable, j'dis pas le contraire. Mais pas network-transparent. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OSEF
Posté par xcomcmdr . En réponse au journal Le mythe de la transparence réseau. Évalué à 2.
Oh bordel vous êtes LOURDS à pas vouloir comprendre.
Ce sont deux fonctionnalités DIFFÉRENTES.
En rien. Au début de la vidéo, il explique d'abord ce qu'est vraiment Xorg, ses problèmes, avant d'expliquer Wayland et ses objectifs.
Ah.
Ben si on peut. Weston le prouve avec son support RDP et SPICE.
Ben oui. La transparence réseau n'est pas un synonyme pour l'utilisation à distance.
Encore une fois ce n'est pas un changement de nom, c'est appeler un chat un chat, et appeler un chien, un chien.
Si c'est pour réinventer Xorg de A à Z, y'a aucun intérêt. Wayland est là pour remplacer X11/Xorg pour l'affichage local, là où Xorg pose d'énormes problèmes. X11 a montré que mélanger les deux dans un même protocole n'est pas optimal, et amène à casser le standard X11 de dix mille manières subtiles (donc avoir un code schizophrène) pour que ça fonctionne à peu près.
Wayland c'est pour l'affichage local. VNC, RDP, SPICE, NX, etc… font dix fois mieux que X. Il existe déjà aussi un support RDP et SPICE pour Weston, l'implémentation de référence.
Ils prétendent (enfin, ils savent, et les gusses sur LWN.net ou linuxfr racontent des bobards) que X est network-capable, plus network-transparent. À cause de : DRI, les fenêtres beaucoup plus complexes, et le protocole X11 qui n'est pas du tout fait pour l'utilisation en réseau.
Avec Wayland ils veulent remplacer Xorg (qui fait de l'IPC, essentiellement, et dix mille autres choses, très mal) par un logiciel qui fait une seule chose et la fait bien (concept de "every frame is perfect") : de l'affichage en local (voire juste du DRI, vu que presque tout est laissé au compositeur pour ne rien imposer).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OSEF
Posté par xcomcmdr . En réponse au journal Le mythe de la transparence réseau. Évalué à 5.
Il ne dit pas que X n'a pas de capacités réseau, ni que personne ne s'en sert.
Il dit que X n'a pas de transparence réseau.
Il ne fait aucunement cela dans la vidéo ou le texte donné en lien de ce journal, c'est du pur délire de ta part.
C'est bien. Mais le problème de la non-transparence réseau ne se limite pas au direct rendering. Il y a aussi le fait que le protocole X11 est synchrone (mauvais pour l'usage en réseau), beaucoup trop bavard (mauvais pour l'usage en réseau), et que les fenêtres (thèmes, icônes, polices, décorations, animations) sont beaucoup plus lourdes (mauvais pour l'usage en réseau).
Trois gros points noirs qui font que la transparence réseau de X de fait n'est plus (ce qui n'empêche pas X d'être utilisable à distance, encore une fois ce n'est pas une histoire de capacité mais de transparence).
C'est surtout que X en local introduit beaucoup trop de latence (le protocole fait que X n'attend pas par exemple qu'une fenêtre soit redimensionnée avant de la redessiner en permanence) et de bugs graphiques (ce n'est pas une histoire de pilote - pour chaque élément de la fenêtre, X considère que c'est aussi une fenêtre, et n'assure aucunement la cohérence entre les deux. D'ailleurs, parmis les développeurs de Xorg : "personne ne comprends la fonction de validation d'une fenêtre"). Essaie de redimensionner une fenêtre (ça n'arrive pas uniquement dans ce cas là, c'est juste là où c'est le plus visible), tu verras à quel point ça lag et c'est moche.
Ben si le remplacant le supporte : pour preuve Weston supporte RDP, et il y a un backend Weston-SPICE sur GitHub.
Aucun toolkit graphique ne l'utilise. A moins d'utiliser des applications non-GTK/QT/EFL/Whatever, je doutes que tu utilises des applications qui utilisent encore la vieille API de dessin de X11, en plus des fenêtres très simples des années '80 (eh oui, la transparence réseau, qui n'était qu'un concours de circonstances, c'était à ce prix).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pussy riot : l'analyse d'Alain Soral
Posté par xcomcmdr . En réponse au journal "Pussy Riot. Lettre du camp 14 de Mordovie". Évalué à 4.
Eh bien tant pis.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pussy riot : l'analyse d'Alain Soral
Posté par xcomcmdr . En réponse au journal "Pussy Riot. Lettre du camp 14 de Mordovie". Évalué à 5.
La Glorious People License
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pussy riot : l'analyse d'Alain Soral
Posté par xcomcmdr . En réponse au journal "Pussy Riot. Lettre du camp 14 de Mordovie". Évalué à 7. Dernière modification le 30 septembre 2013 à 17:00.
Je connais Soral et ses thèses. Je ne vais pas en reprendre, non merci.
D'ailleurs, ce serait bien si tu pouvais te greffer un sens de l'humour.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OSEF
Posté par xcomcmdr . En réponse au journal Le mythe de la transparence réseau. Évalué à 1. Dernière modification le 30 septembre 2013 à 16:51.
Je ne fais que répeter ce que disent les développeurs de Xorg, et c'est moi le troll ?
D'ailleurs, non, je n'ai pas fini. Du moins, pas avant que ça ne rentre : je ne dis pas que X n'a pas de capacitées pour l'utilisation à distance. Je dis que la transparence réseau a disparu depuis longtemps. La transparence réseau de Xorg existait du temps où chaque application utilisait l'API de dessin de Xorg (qui a une architecture client/serveur, du fait qu'à l'époque Unix ne connaissait pas le concept de bibliothèque partagée).
De fait, la transparence réseau (qui n'était là qu'à cause d'un concours de circonstances) a disparu à cause :
- des toolkits qui n'utilisent plus l'API de dessin mais le direct rendering ("affiche moi cette image et c'est tout")
- des fenêtres qui sont beaucoup plus compliquées graphiquement aujourd'hui (thème graphique, thème d'icônes, décorations, effets graphiques, polices lissées, …)
- du fait du protocole X11, qui n'a jamais été adapté pour une utilisation en réseau (il est synchrone, il induit des allers-retours constants - X11 est très bavard -, …)
Bref, de nos jours, la latence est trop grande pour parler de transparence réseau (à moins d'utiliser des applications qui utilisent les API de dessin de X plutôt qu'un toolkit tel que GTK ou QT, ce qui doit être hyper rare). VNC, SPICE, RDP, font mieux (même si ce n'est pas encore transparent).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pussy riot : l'analyse d'Alain Soral
Posté par xcomcmdr . En réponse au journal "Pussy Riot. Lettre du camp 14 de Mordovie". Évalué à 2.
Y'a une différence entre être ouvert d'esprit, et avoir des courants d'airs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OSEF
Posté par xcomcmdr . En réponse au journal Le mythe de la transparence réseau. Évalué à 1.
Bah non, sinon c'est réinventer la roue (carrée).
Toutes les fonctionnalités non utilisées aujourd'hui dans le protocole X11 ne sont pas dans Wayland. Sinon, Wayland n'aurait aucun intérêt.
Xorg est pourri, et le protocole X11 est composé à 90% de bois mort pour l'affichage local.
Oui, il le gère très mal.
Weston, c'est une implémentation du protocole Wayland, avec déjà des fonctionnalités réseau (RDP, au moins). Que des capacités d'utilisation à distance soient déjà implémentées dans le compositeur de référence expérimental devrait rassurer les plus grincheux, AMHA.
L'affichage à distance, plutôt.
Très mauvaise solution, trop bavarde et même pas asynchrone.
Implémentation pas faite pour le réseau, et qui date des années 80, du temps où Unix ne connaissait pas les bibliothèques partagées.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: heureusement
Posté par xcomcmdr . En réponse au message est-il légal de vendre une appliance centos avec un logiciel proprio dedans ?. Évalué à 2.
Ici
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OSEF
Posté par xcomcmdr . En réponse au journal Le mythe de la transparence réseau. Évalué à 4.
À quoi bon réinventer Xorg ?
Autant garder Xorg !
Et puis aujourd'hui déjà, alors que Wayland est à peine implémenté (Weston n'est qu'un exemple, les toolkits et WM ne sont pas encore compatibles, ou pas tout à fait), on a déjà une alternative pour SPICE, et une pour RDP. Donc je vois pas pourquoi il faudrait s'inquiéter. Il y a encore des années de développement avant de commencer un début d'abandon de Xorg.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OSEF
Posté par xcomcmdr . En réponse au journal Le mythe de la transparence réseau. Évalué à 3.
Non. La transparence réseau de Xorg existait du temps où chaque application utilisait l'API de dessin de Xorg (qui a une architecture client/serveur, du fait qu'à l'époque Unix ne connaissait pas le concept de bibliothèque partagée).
De fait, la transparence réseau (qui n'était là qu'à cause d'un concours de circonstances) a disparu à cause :
- des toolkits qui n'utilisent plus l'API de dessin mais le direct rendering
- des fenêtres qui sont beaucoup plus compliquées graphiquement aujourd'hui (thème graphique, thème d'icônes, décorations, effets graphiques, polices lissées, …)
- du fait du protocole X11, qui n'a jamais été adapté pour une utilisation en réseau (il est synchrone, il induit des allers-retours constants - X11 est très bavard -, …)
Non. C'est pas de leur faute si plein de monde sur LWN, linuxfr, et ailleurs, confondent transparence réseau et capacitées réseau.
Il y a des alternatives à Xorg pour l'utilisation à distance, mais ça n'utilise pas le protocole X11.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OSEF
Posté par xcomcmdr . En réponse au journal Le mythe de la transparence réseau. Évalué à 3.
Très bien utilise alors ta définition perso, après tout lex dévs de X ont forcément tort.
Tu vas leur expliquer la transparence réseau, et ils vont laisser tomber Wayland à coup sûr !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: OSEF
Posté par xcomcmdr . En réponse au journal Le mythe de la transparence réseau. Évalué à 0. Dernière modification le 29 septembre 2013 à 21:12.
C'est toi qui confond depuis le début ce que les développeurs de Xorg dénoncent : X est 'network capable' PAS 'network transparent'. Ce n'est plus vrai depuis au moins 10 ans, faut se mettre à la page !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)