Tout ce que je cherche c’est à pouvoir reproduire avec un poste Linux ce que je fais déjà avec les postes Windows (et des serveurs Samba). Donc les extensions unix ne m’apporterait que des choses en plus, mais pas ce que j’ai déjà sans, parce qu’avec des postes Windows ça marche déjà sans.
Il n’y a pas de serveur Windows1 dans mon schéma. Pour chacune des entités que j’administre ce sont des serveurs Debian avec des postes Windows. Les Windows ne sont que des postes clients. Ce sont des Windows à cause de certains outils qui sont spécifiques, les uns étant déjà morts quand ils ont été livrés, les autres n’étant pas d’abord rendu nécessaire à cause de leur qualité ou de leur fonctionnalité mais d’abord à cause de la captivité des utilisateurs, remarquez que cette captivité est forcément présente avec les "déjà morts". Mais plus le temps passe et plus les utilisateurs me demandent des outils qui sont plus faciles à installer sous Linux que sous Windows, qui sont de meilleur qualité sous Linux, ou qui sont mieux intégrés sous Linux.
J’ai une entité qui a complètement abandonné MS Office, initialement je fournissais toujours MS Office mais un jour j’ai découvert que 90% de leurs documents étaient des odt qu’ils éditaient avec LibreOffice, il y a eu quelque changements structurels dans cette entité et ce n’est plus moi qui fournissait Office, et personne ne l’a fait. Personne ne s’en est rendu compte avant deux ans, quand un poste mal configuré n’avait pas associé les .doc à LibreOffice et où l’on m’a demandé MS Office "pour lire les .doc". J’ai refait l’association et je n’en ai plus entendu parler.
Mais dans une autre entité qui n’avais jamais eu MS Office et qui n’en avait eu besoin, il y a quelques mois un partenaire à changé sa méthode de travail basée sur une usine à gaz MS Office, alors cette entité a du passer à MS Office pour garder la compatibilité avec son partenaire, le coût des licence pour poignée de personnes avait une valeur de 8 000,ドル mais MS a tout offert je crois, ou presque. Et j’imagine que de partenaires en partenaires, tous n’ont pas la ristourne.
1 Depuis quelques mois j’ai une exception : une entité qui a un AD-DC Windows (parce qu’il fait partie de la préco officielle pour le réseau auquel appartient cette entité) et dans ce cas c’est juste un remplaçant de Samba par rapport au schéma ordinaire, il a remplacé un Samba et pourrait être remplacé par un Samba. Je n’y vois d’ailleurs aucun intérêt par rapport à un Samba, et parce que c’est un Windows, est fortement lié au matériel ce qui peut s’avérer très contraignant en cas de problème (Windows ne sachant pas faire du RAID lui-même la solution est fournie par le hard, donc le système dépend du hard). Excepté cette verrue dans toutes mes autres entités tout est conçu pour que la première machine venue (même un poste de travail) puisse remplacer le serveur en cas de crise majeure : une clé contient un hyperviseur qui démarre des vm qui sont sur des paires de disque, il suffit de déplacer la clé et les paires de disques sur n’importe quoi pour que le service reparte. N’importe quoi peut remplacer n’importe quoi.
Pour les utilisateurs, n’importe quel poste de travail Windows remplace n’importe quel poste de travail Windows (les installations ne sont pas déplaçables, mais chaque machine est agnostique côté utilisateur). Pour les administrateurs, n’importe quelle machine peut remplacer un serveur, les installations sont entièrement déplaçables. La nouveauté c’est que maintenant j’ai une demande qui émerge pour des postes Linux dans un service. Le service qui en exprime la demande ne connaît pas Linux et n’a jamais mis la main dessus, mais soient les logiciels sont mieux distribués sous Linux (ce qui est mieux pour eux puisque ça me permettrait de leur fournir un meilleur service), soit ils sont mieux intégrés, reçoivent plus de soins sous Linux, ou sont tout simplement historiquement des logiciels Linux portés sous Windows sur le tard et encore un peu trop frais sous Windows.
Cela dit, un revirement peut aller très vite, comme le témoigne le cas « MS Office pour la compatibilité avec le partenaire » cité précédemment.
Dans les cas extrèmes une porte de sortie pourrait la sous-couche Linux de Windows 10, mais ça manque d’intégration. Ça répond aussi à la question de PasBillPasGates : Windows est obligé de fournir une compatibilité binaire sans recompilation avec Ubuntu pour survivre dans certains domaines. Windows peut bien fournir docker que personne n’en veut si on peut pas faire du apt-get dedans avec des ppa Ubuntu.
PasBillPasGate doit certainement savoir qu’initialement les liens symboliques sous Windows (présents dans NTFS depuis des décennies) exigeaient des privilèges administrateurs pour être créés (parce que c’était considérés comme une faille de sécurité), mais après des décennies ils ont été contraints de faire machine arrière devant la demande de leurs propres développeurs et de leurs propres clients qui ne pouvaient pas supporter d’avoir un OS de seconde zone. Historiquement c’est Git qui a forcé la main à Microsoft sur ce coup-là. Windows était la raison non-technique pour laquelle il n’était pas possible de mettre des liens symbolique dans un dépôt Git dès que le projet était multi-plateforme. Microsoft a permis les liens symboliques en donnant comme raison officielle qu’il n’était plus défendable que leurs propres développeurs utilisant Git aient moins bien que le reste du monde.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: automatisation de la session utilisateur
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Intégration d'un poste GNU/Linux dans un domaine Windows. Évalué à 3. Dernière modification le 16 novembre 2017 à 04:58.
Tout ce que je cherche c’est à pouvoir reproduire avec un poste Linux ce que je fais déjà avec les postes Windows (et des serveurs Samba). Donc les extensions unix ne m’apporterait que des choses en plus, mais pas ce que j’ai déjà sans, parce qu’avec des postes Windows ça marche déjà sans.
Il n’y a pas de serveur Windows1 dans mon schéma. Pour chacune des entités que j’administre ce sont des serveurs Debian avec des postes Windows. Les Windows ne sont que des postes clients. Ce sont des Windows à cause de certains outils qui sont spécifiques, les uns étant déjà morts quand ils ont été livrés, les autres n’étant pas d’abord rendu nécessaire à cause de leur qualité ou de leur fonctionnalité mais d’abord à cause de la captivité des utilisateurs, remarquez que cette captivité est forcément présente avec les "déjà morts". Mais plus le temps passe et plus les utilisateurs me demandent des outils qui sont plus faciles à installer sous Linux que sous Windows, qui sont de meilleur qualité sous Linux, ou qui sont mieux intégrés sous Linux.
J’ai une entité qui a complètement abandonné MS Office, initialement je fournissais toujours MS Office mais un jour j’ai découvert que 90% de leurs documents étaient des odt qu’ils éditaient avec LibreOffice, il y a eu quelque changements structurels dans cette entité et ce n’est plus moi qui fournissait Office, et personne ne l’a fait. Personne ne s’en est rendu compte avant deux ans, quand un poste mal configuré n’avait pas associé les .doc à LibreOffice et où l’on m’a demandé MS Office "pour lire les .doc". J’ai refait l’association et je n’en ai plus entendu parler.
Mais dans une autre entité qui n’avais jamais eu MS Office et qui n’en avait eu besoin, il y a quelques mois un partenaire à changé sa méthode de travail basée sur une usine à gaz MS Office, alors cette entité a du passer à MS Office pour garder la compatibilité avec son partenaire, le coût des licence pour poignée de personnes avait une valeur de 8 000,ドル mais MS a tout offert je crois, ou presque. Et j’imagine que de partenaires en partenaires, tous n’ont pas la ristourne.
1 Depuis quelques mois j’ai une exception : une entité qui a un AD-DC Windows (parce qu’il fait partie de la préco officielle pour le réseau auquel appartient cette entité) et dans ce cas c’est juste un remplaçant de Samba par rapport au schéma ordinaire, il a remplacé un Samba et pourrait être remplacé par un Samba. Je n’y vois d’ailleurs aucun intérêt par rapport à un Samba, et parce que c’est un Windows, est fortement lié au matériel ce qui peut s’avérer très contraignant en cas de problème (Windows ne sachant pas faire du RAID lui-même la solution est fournie par le hard, donc le système dépend du hard). Excepté cette verrue dans toutes mes autres entités tout est conçu pour que la première machine venue (même un poste de travail) puisse remplacer le serveur en cas de crise majeure : une clé contient un hyperviseur qui démarre des vm qui sont sur des paires de disque, il suffit de déplacer la clé et les paires de disques sur n’importe quoi pour que le service reparte. N’importe quoi peut remplacer n’importe quoi.
Pour les utilisateurs, n’importe quel poste de travail Windows remplace n’importe quel poste de travail Windows (les installations ne sont pas déplaçables, mais chaque machine est agnostique côté utilisateur). Pour les administrateurs, n’importe quelle machine peut remplacer un serveur, les installations sont entièrement déplaçables. La nouveauté c’est que maintenant j’ai une demande qui émerge pour des postes Linux dans un service. Le service qui en exprime la demande ne connaît pas Linux et n’a jamais mis la main dessus, mais soient les logiciels sont mieux distribués sous Linux (ce qui est mieux pour eux puisque ça me permettrait de leur fournir un meilleur service), soit ils sont mieux intégrés, reçoivent plus de soins sous Linux, ou sont tout simplement historiquement des logiciels Linux portés sous Windows sur le tard et encore un peu trop frais sous Windows.
Cela dit, un revirement peut aller très vite, comme le témoigne le cas « MS Office pour la compatibilité avec le partenaire » cité précédemment.
Dans les cas extrèmes une porte de sortie pourrait la sous-couche Linux de Windows 10, mais ça manque d’intégration. Ça répond aussi à la question de PasBillPasGates : Windows est obligé de fournir une compatibilité binaire sans recompilation avec Ubuntu pour survivre dans certains domaines. Windows peut bien fournir docker que personne n’en veut si on peut pas faire du apt-get dedans avec des ppa Ubuntu.
PasBillPasGate doit certainement savoir qu’initialement les liens symboliques sous Windows (présents dans NTFS depuis des décennies) exigeaient des privilèges administrateurs pour être créés (parce que c’était considérés comme une faille de sécurité), mais après des décennies ils ont été contraints de faire machine arrière devant la demande de leurs propres développeurs et de leurs propres clients qui ne pouvaient pas supporter d’avoir un OS de seconde zone. Historiquement c’est Git qui a forcé la main à Microsoft sur ce coup-là. Windows était la raison non-technique pour laquelle il n’était pas possible de mettre des liens symbolique dans un dépôt Git dès que le projet était multi-plateforme. Microsoft a permis les liens symboliques en donnant comme raison officielle qu’il n’était plus défendable que leurs propres développeurs utilisant Git aient moins bien que le reste du monde.
ce commentaire est sous licence cc by 4 et précédentes