La transparence réseau est une mauvaise solution à un vrai problème. Et principalement une relique du passé, qui vient direct des terminaux léger/server lourd des années 80.
C’était utile à l’époque ou 640kB de ram était suffisant pour tout le monde, et permettait des économies en achetant des clients légers qui n’avait que besoin de gérer l’affichage d’une appli qui tournait à distance, et où le traffic réseau public était l’exception.
À une époque ou 15% de la population mondiale, et 90% de la population occidentale, a dans la poche un processeur qui met la tannée à un serveur haut de gamme en single thread, et où la majorité du traffic est publique, ça devient dur de voir l’intérêt.
C’est beaucoup plus simple de garder les données centralisée la ou ça fait du sens de les centraliser, et d’avoir un process local y accéder via n’importe quel protocole fait du sens pour y accéder, que de passer une décennie à se demander comment envoyer des keystrokes de façons sécurisée via le réseau, avec le son, et les notifications et tout le barda qui vient avec ça, tout en petant les intégrations desktop genre indexed search etc.
Typiquement, ton example de firebird, un webmail resoud le problème de façon beaucoup plus élégante. Encore plus si le cas d’usage c’était récupérer un code 2fa pour se connecter à un service de streaming, ce problème a été résolu y’a plus de 10 ans par les Roku, Apple TV et autres, d’une manière beaucoup plus élégante, fiable, et pratique pour tout le monde.
ou ton example VLC, Plex c’est pas fait pour les chiens, c’est plus facile de streamer un flux 4mb que de devoir décoder a la source, puis compresser a la source inefficacement, et décompresser a nouveau a la réception. Et en plus t’auras le son 5.1 en cadeau bonux, et les sous titres ne seront pas aliases/compresse a la truelle.
il reste toujours des cas d’usage réels ou t’as besoin de faire tourner le code sur une machine distante spécifique, mais c’est très spécifique (ferme de build/compilation/rendu/etl/que sais je encore), et la encore y’a très peu d’intérêt de faire un rendu distant de l’appli, et beaucoup plus simple d’utiliser un des multiple protocoles de transfert de données pour qu’un client distant fasse le rendu tout seul de données distantes.
[^] # Re: Transparence réseau qui fonctionne bien pour moi
Posté par groumly . En réponse au journal Les distributions Linux abandonnent X11 pour Wayland. Évalué à 7.
La transparence réseau est une mauvaise solution à un vrai problème. Et principalement une relique du passé, qui vient direct des terminaux léger/server lourd des années 80.
C’était utile à l’époque ou 640kB de ram était suffisant pour tout le monde, et permettait des économies en achetant des clients légers qui n’avait que besoin de gérer l’affichage d’une appli qui tournait à distance, et où le traffic réseau public était l’exception.
À une époque ou 15% de la population mondiale, et 90% de la population occidentale, a dans la poche un processeur qui met la tannée à un serveur haut de gamme en single thread, et où la majorité du traffic est publique, ça devient dur de voir l’intérêt.
C’est beaucoup plus simple de garder les données centralisée la ou ça fait du sens de les centraliser, et d’avoir un process local y accéder via n’importe quel protocole fait du sens pour y accéder, que de passer une décennie à se demander comment envoyer des keystrokes de façons sécurisée via le réseau, avec le son, et les notifications et tout le barda qui vient avec ça, tout en petant les intégrations desktop genre indexed search etc.
Typiquement, ton example de firebird, un webmail resoud le problème de façon beaucoup plus élégante. Encore plus si le cas d’usage c’était récupérer un code 2fa pour se connecter à un service de streaming, ce problème a été résolu y’a plus de 10 ans par les Roku, Apple TV et autres, d’une manière beaucoup plus élégante, fiable, et pratique pour tout le monde.
ou ton example VLC, Plex c’est pas fait pour les chiens, c’est plus facile de streamer un flux 4mb que de devoir décoder a la source, puis compresser a la source inefficacement, et décompresser a nouveau a la réception. Et en plus t’auras le son 5.1 en cadeau bonux, et les sous titres ne seront pas aliases/compresse a la truelle.
il reste toujours des cas d’usage réels ou t’as besoin de faire tourner le code sur une machine distante spécifique, mais c’est très spécifique (ferme de build/compilation/rendu/etl/que sais je encore), et la encore y’a très peu d’intérêt de faire un rendu distant de l’appli, et beaucoup plus simple d’utiliser un des multiple protocoles de transfert de données pour qu’un client distant fasse le rendu tout seul de données distantes.