CrEv a écrit 4577 commentaires

Malhonnête ? tout de suite les insultes …

Ce n'est pas une insulte.

Je note juste qu'il y a deux commentaires successifs qui disent grosso modo la même chose :

• Ben non, ils ont tout ça..
• OVH propose tout ça

Dont le commentaire parent parle de :

Queues ?
Serverless ?
Monitoring (securité, reliabilité…) ?
Identité (federation, etc…)
Isolation (equivalent aux VPCs & VPC endpoints d'AWS, etc…) ?
Databases (NoSQL, SQL…)
etc…

Dire qu'ils ont tout ça c'est juste faux.
Ce qui n'enlève rien à ce qu'ils proposent.

Mais faut arrêter de dire que tout ce qu'on peut faire sur GCP/Azure/AWS on peut le faire avec OVH.

C'est aussi ce que j'ai vu. Mais ça n'a donc strictement rien à voir.
Sur AWS, je peux avoir une fonction serverless qui va automatiquement s'exécuter quand je pose un fichier dans un bucket s3 (genre upload par un utilisateur), faire ce que je veux sur le fichier et poser le nouveau fichier ailleurs.
Sans avoir aucun serveur ni rien, du serverless quoi.

Dire que OVH fait tout ce que AWS/Azure/… font c'est juste être malhonnête.

OVH propose tout ça, mais :

• leur site est mal foutu ;

Quelqu'un a des liens ? Parce que je trouve aucune référence à des solutions de queues ou de serverless.

Il y a un équivalent aux Lambda d'AWS sur OVH?
J'ai vu des choses pour déployer du openfaas dans du kubernetes OVH, mais ça n'a rien à voir. Il y a autre chose ?

Entre autre parce que tu veux découpler les responsabilités.
Ton service est là pour réaliser des actions, et balance tout dans les sorties standard.
Se connecter à des systèmes de logs n'est pas de sa responsabilité.
Un autre service lui a pour responsabilité de prendre des logs et des les envoyer quelque part.
Ce qui fait donc que ton premier service n'a pas à s'occuper de la dispo, réussite ou non de l'envoi, de gérer les timeouts, latences, etc. Il publie du log c'est tout. Et le jour où tu veux changer de système de log, ben c'est vachement plus simple aussi.

Voir par exemple la section sur les logs des 12 factor: https://12factor.net/fr/logs

"cracher" est peut-être pas le plus approprié, mais il y a eu une volonté de faire passer Linux comme étant un nouveau pour GNU, GNU étant là avant (enfin surtout parce que Hurd n'a jamais fonctionné) alors que c'est plutôt le contraire. Ce sont les outils GNU qui ont été portés sur Linux.

Independently, in 1991, Linus Torvalds released the first version of the Linux kernel. Early Linux developers ported GNU code, including the GNU C Compiler, to run on Linux.

et

When Linus Torvalds was asked in the documentary Revolution OS whether the name "GNU/Linux" was justified, he replied:

Well, I think it's justified, but it's justified if you actually make a GNU distribution of Linux … the same way that I think that "Red Hat Linux" is fine, or "SUSE Linux" or "Debian Linux", because if you actually make your own distribution of Linux, you get to name the thing, but calling Linux in general "GNU Linux" I think is just ridiculous.

https://en.wikipedia.org/wiki/GNU/Linux_naming_controversy

De ce que je vois/lis, on utilise un système linux sur lequel des outils GNU ont été portés ainsi que d'autres couches, et non un système GNU dans lequel on a remplacé Hurd par Linux.

À la base, le système d’exploitation, c’est GNU. Il lui manquait un noyau viable, Linux est venu combler ce vide avec brio. Le terme « GNU/Linux » est le produit de cette union ; mais enlever le GNU, alors que c’est lui le projet originel de système d’exploitation libre, c’est ignorer l’histoire.

Ben en fait c'est juste l'inverse.
Linux était là, et GNU crachait dessus.
Linux qui avançait a utilisé des outils dont certains venaient du projet GNU.
Et un beau jour, après avoir tellement tapé sur Linux en disant que Hurd c'était beaucoup plus mieux ils se sont enfin rendu compte qu'ils n'y arriveront jamais et Linux est devenu le noyau de base de GNU à la place de Hurd.
Et à partir de là certains ont voulu appeler ça GNU/Linux.
GNU/Linux c'est avant tout une histoire d'ego de mon point de vue.

Oui, la formulation n'est pas bonne. Ce qui part chez Mirantis c'est la CLI EE liée aux produits enterprise. La CLI standard, open source, sera toujours maintenue chez Docker.

Je dis juste qu'en dehors du docker hub la cible en terme de marché pour ramener des pépettes ce sont les gens qui travaillent sur des systèmes non linux.

Ben vu que Docker Desktop est gratuit pour mac/win ça ne change pas grand chose. (oui ok, même si très récemment une version Enterprise de Docker Desktop est sortie)

quand tu le fais tourner sur ton laptop t'es pas obligé de t'encombrer de VMs

Avec podman ?
Soit j'ai loupé un truc soit podman n'est qu'un client remote sous win/mac. Donc si tu veux le faire tourner il te faut une VM, sauf qu'il n'existe pas à ma connaissance d'outil comme docker desktop qui le fait pour toi.

Et sous linux ben podman ou docker t'as pas besoin de VM.

Le coup de l'alias c'est pas vraiment un argument. C'est juste un témoin de la résistance au changement.

Heu non. Quand tu fais ça dans des confs, tu t'adresses à un public qui est là pour voir des nouveautés. Pas pour entendre que c'est juste pareil qu'avant.

Mais sinon dans le même genre on peut prendre buildah, en conf par les devs même on a droit à un beau : "pas besoin d'équivalent de Dockerfile on a déjà bash". C'est vraiment ne pas capter du tout que l'UX est importante, que non tout le monde ne veut pas faire de bash et que beaucoup de devs aimeraient bien des outils plus facile à utiliser.

leur cible actuelle c'est pas les linuxiens de toute façon mais plutôt les devs utilisant des laptops sous windows et mac.

s/les devs utilisant des laptops sous windows et mac/les devs/

Alors oui, beaucoup de devs sont sous windows et mac. Même si le logiciel final tourne sous linux. Et comme les solutions de conteneurs sont uniquement sous linux (ok il y a les conteneurs windows aussi) ben faut bien trouver quelque chose pour leur rendre ça dispo.

Et docker c'est aussi l'engine, compose, etc. Donc dire que la cible n'inclue pas les devs sous linux c'est faux.

note : je bosse chez Docker

En effet Docker a vendu la partie enterprise de la boite. C'est déjà assez différent de vendre "son business".

Que reste-t-il ?
Ben il reste ce que tout le monde utilise surtout, le core, la cli, desktop, le hub, etc.

Pour faire simple Docker n'avait pas réussi à choisir entre outils pour dev et solution d'entreprises et a tenté de faire les deux.
Aujourd'hui la partie entreprise s'est séparée et Docker revient aux fondamentaux, les outils pour développeurs avec une bonne UX. Car pour le moment j'ai toujours pas vu autre chose. Il n'y a qu'à voir les confs podman où on conseille de faire un alias docker=podman 🙃

Docker reste donc docker.

Concernant ce qui rapporte de l'argent, le hub rapporte déjà de l'argent à Docker. Et en passant de 350 à 75 personnes les besoins ne sont pas non plus les mêmes.

A noter aussi que en plus de se concentrer sur les outils développeurs, Docker vient de lever $35m !

Vont-ils devenir un patent troll ?

lol

Vont-ils essayer de vendre la marque à une autre boîte ?

Non, la marque Docker reste chez Docker.
Docker reste Docker.

jamais eu besoin :/

Bref, comment tu fais, cher journal ?

Ben MacOS + homebrew, what else?

Mais sinon tu peux utiliser homebrew sous linux.

Oups, si un modérateur peut corriger : on se prends -> on se prend

Ça gêne si c'est une modératrice ? Si oui, je remettrai la faute.

---

Oups, si un modérateur peut corriger : on se prends -> on se prend

Ça gêne si c'est une modératrice ? Si oui, je remettrai la faute ;-)

---

Juste pour montrer qu'avec quelques caractères de plus ça aide à transmettre plus d'informations sur le ton.
On peut lire la même phrase de deux façons, le smiley permet d'inciter le lecteur à la lire de la bonne (enfin celle que j'imagine).

Maintenant, faudrait ptetre juste se détendre et pas sortir des attaques à tout vas

je trouve ta façon de répondre un poil mépriosant, voire agressive (ça va pas être triste si t'es passée modératrice).

Sa réponse n'était ni méprisante, ni agressive mais celle-ci est un peu déplacée je trouve et justement pleine de mépris.

je vais fermer mon compte d'ici ce soir

Demain, j'arrête!

Où est le problème d'intérêt général qu'une administration migre sous office 365?

C'est quoi le lien avec "lanceur d'alerte". Il en existe plusieurs définitions mais on tourne autour de l'idée de crime, délit, de risque de santé publique, de sécurité, d'intérêt général.
Bref, si je comprend bien là on a une administration qui migre sur Office 365.
Alors je me dis que peut-être je saisi pas bien l'ampleur du changement et de ses conséquences, mais voir "lanceur d'alerte" pour une migration sur office 365 j'arrive pas à faire le lien.

https://github.com/CaliOpen/Caliopen/projects/2 ?

(onglet projet)

De manière beaucoup plus limitée je pense, il m'arrive d'utiliser StGit.

StGit is a Python application providing similar functionality to Quilt (i.e. pushing/popping patches to/from a stack) on top of Git. These operations are performed using Git commands and the patches are stored as Git commit objects

Pour ceux qui ne voient pas bien l'intérêt de la gestion de patches, faire quelques essais avec StGit peut être une façon simple de voir ce que ça donne.

Dans mon workflow classique, j'utilise beaucoup rebase (avec autosquash). Il m'arrive fréquemment de réordonner mes commits, d'en squasher plusieurs, ou de faire des git commit --fixup.
Avec StGit beaucoup moins, si je veux corriger/améliorer/modifier un changement, je me place sur ce changement (j'enlève tout ce qui est au dessus), je met à jour mon changement, et j'applique de nouveau les autres changements. C'est vraiment plus simple je trouve.

il substitut la police Liberation Serif, d'accord elle n'est peut-être pas installée
Comme si Microsoft était incapable de savoir les caractéristiques de Liberation Serif et faire la substitution par Times New Roman !

Ben en même temps comment veux-tu que office trouve les caractéristiques d'une police non présente sur le système ?

Dans ma vraie vie à moi, c'est le format OOXML et MS-Word qui ne marchent pas.

J'ai quand même plus l'impression que c'est une critique de la (non) compatibilité entre un document fait sous libre office et un document fait sous MS Office, non ? Des choix différents et des problèmes à l'import peuvent être tout autant du fait d'un des formats ou de l'autre. Il n'y a rien de "prouvé" à part que dans certains cas l'import se passe mal/pas comme prévu.

Pour info c'est Android et non Androïd.

Question conne, mais si c'est tant une horreur, pourquoi ça existe et ça se développe ?

Il y a beaucoup de choses qui se développent sans que ce soit particulièrement souhaitable (extrémisme, les cyberattaques, le harcèlement, le spam, les platistes, les antivax,…)

Je sais bien qu'on est sur linuxfr, mais c'est sérieux comme réponse ?
Une question sur l'omniprésence d'electron et la réponse parle de "extrémisme, les cyberattaques, le harcèlement, le spam, les platistes, les antivax" ?

Surtout que la question était quand même précisée, orientée :

Quelle alternative existe aujourd'hui pour faire des app multi-plateformes (desktop + web à minima) ?

Parce que on peut crasher autant qu'on veut sur electron, aujourd'hui c'est tout de même ce qui permet à plein d'app d'exister aussi bien sous forme d'appli desktop que de site web.
Ça a écrasé les dernières tentatives à la GTK, Qt, etc.

Alors est-ce souhaitable ? Probablement pas en théorie. Mais pratico-pratiquement c'est déjà ce que font beaucoup de gens avec Electron JS et c'est une horreur qui a besoin de disparaître

Question conne, mais si c'est tant une horreur, pourquoi ça existe et ça se développe ?
Quelle alternative existe aujourd'hui pour faire des app multi-plateformes (desktop + web à minima) ?

Peut-être parce que la NETIQUETTE n'a pas su s'adapter aux nouveaux usages ?

Par exemple, à titre personnel, je regrette la mort de la NETIQUETTE comme charte de bonne conduite.

Ok ok, on se paluche sur un cas qui n'a pas marché, avant tellement peu de détails qu'en vrai on ne peut rien en dire.

Mais en vrai, ce sont quoi les problèmes ?
Je vais le faire dans l'autre sens. Toutes les machines que j'ai (que j'ai ou tous les serveurs que je lance au taff, et on doit en lancer grosso modo une centaine par jour) sont avec systemd (j'ai même eu du fleet). Et systemd est juste un élément clé. Les services, la gestion de dépendance entre les services, les drop-in pour overrider de la conf, les notifs entre service, journald avec des exporteurs type journalbeat, les logs docker avec driver journald, etc.

Bref pour le moment, en dehors des trolls sur des cas particuliers, j'ai toujours pas vu en quoi c'était le mal et pourquoi il faudrait s'en éloigner alors que ça juste marche bien.

Ok, le seul vrai problème que j'ai eu c'est quand Coreos a décidé sur une release mineur de changer la config du format de stockage des logs, qui était incompatible avec ma version courante de journalbeat. De là à incriminer systemd…