[F] [mOved] Mon langage est mieux que le tien - Page 57

Plutôt un programme PlusShell 0.99 avec le kernel intégré.

Non, c'est pire que ca, tu embarque le kernel de maniere caché dans ton programme sois disant nostub, enfin tu ne vois meme pas le kernel ni le fichier nostub, la totalité des lib dépendantes (et ce meme si elles sont deja isntallé dans ta TI) et le kernel est automatiquement installé et supprimé a l'execution/fin d'execution du container, et ce meme si un kernel est deja installé, et j'en passe.

Arvi89: le veritable probleme des container, à pars le fait qu'il sont une déduplication de l'OS deja installé (et demande des options que je refuse de mettre dans mon kernel car elle sont pour moi des problèmes de sécurité potentiels) c'est qu'ils sont la pour cacher la dette technique existante et surtout le fait que les technologies utilisé sont tous sauf au point, exemple: RubyOnRail.
Je ne connais pas assez Ruby en tant que language donc je ne peux pas juger de sa qualitée. Par contre j'ai assez d'experience opur savoir a quel point c'est la merde et que chaque mise a jour du language casse les version precedentes et demander de passer des heures/jours pour reparer une simple MaJ et refaire marcher un pauvre service web dépendant de Ruby, voir je n'ai jamais reussi a (re)faire marcher le service en question.

Les container on été créé en partit a cause de ca, plutôt que résoudre les problèmes on en cree un nouveau.

Sans compter qu'on a aucun veritable control sur ce qui est dans le container sous peine de le rendre non fonctionel. Si le fait qu'il utilise telle version de la lib X, ou que le service Y ne te conviens pas et est incompatible avec le service Z que tu utilise ailleurs en dehors de ce container, tu peux rien faire.

Bref, encore un truc que beaucoup de gents crient haut et fort que c'est super génial, et qui va rester dans les anales de l'informatique comme une des pires fausses bonnes idées, mais il va falloir des années pour que les gens comprennent..

./1679
Euh, non. Juste l'app dans le container en fait.

./1683
Ca peut aussi servir à ce que tous les devs aient le même env de dev, comme ça on n'a pas de "mais ça marche sur ma machine", parce que si ça marche sur ta machine, le container sera éxactement le même en prod.

S'il y a un service X ou Y dans le container, si j'ai Z autre part qui est inccompatible en temps normal, justement car c'est dans un container ça ne va rien faire du tout. Il n'y a rien qui rentre en conflit. Tu peux avoir 10 différentes versions de Mysql pour 10 projets différents, c'est pas bien grave.

Justement, avoir 10 versions différentes de MySQL (ou de n'importe quel autre logiciel), c'est une horreur du point de vue gestion / maintenance. Le fait que ce soit embarqué dans un conteneur ne résout rien : s'il y a une faille de sécurité, ça veut dire que tu dois mettre à jour 10 trucs au lieu d'un seul.

Je suis assez d'accord avec Godzil : au lieu de se dire "c'est le bazar -> essayons de mieux organiser les choses", avec les containers le raisonnement est "c'est le bazar -> rendons ce bazar moins gênant en apparence". C'est grosso modo le même raisonnement derrière la méthodologie agile, les milliers de dépendances des projets NodeJS, etc.

Tout n'est pas à jeter, mais c'est quand même souvent une fausse bonne idée qui consiste à planquer la poussière sous le tapis.

L'exemple de 10 versions n'est pas à faire, c'était pour dire qu'il ne peut pas y avoir d'incimpatibilités entre les différents containers, puisque justement, tout est séparé.

Perso je suis bien content de ne pas avoir à installer mongo, postgre, ruby pour les différentes apps que j'utilise. Et si j'ai 3 mysql qu'il fauit mettre à jour à cause d'une faille, c'est pas très compliqué, et pas très long non plus.

Godzil (./1683) :
qui va rester dans les anales de l'informatique

"anales"? C'est fait exprès?

Arvi89 (./1686) :
Perso je suis bien content de ne pas avoir à installer mongo, postgre, ruby pour les différentes apps que j'utilise.

La résolution automatique des dépendances, en as-tu déjà entendu parler?

Arvi: oui c'est pour ca que je ne peux psa installer le container de Discuss parce qu'il entre en conflit avec le serveur apache qui est sur mon serveur, mais il n'y a pas d'incompatibilité possible entre les containers...

Et non il ya plus que "juste une app" dans un container, il y a la libc, toutes les dépendances en terme de lib, avec des version parfois pas compatible directement avec le kernel, tous les services dont a besoin l'outils et ce meme si ils existent deja sur le serveur...

Désolé mais 10 container == 10 versions de MySQL + 10 Apache + 10 PHP (par exemple) c'est 10x du foutage de gueule.
Mon serveur gere 4 et + site, avec un seul apache, un seul MySQL, un seul PHP et c'est pas vraiment compliqué a gerer, loin de la. Et si un des sites se mettait a prendre trop de BP/Temps CPU il partirais sur un autre serveur, et c'est une chose que les container ne peuvent resoudre de toute maniere.

Kevin Kofler (./1687) :
La résolution automatique des dépendances, en as-tu déjà entendu parler?

As-tu déjà essayé d'installer une app en ruby, redmine par exemple ?

Et si je peux éviter d'avoir à installer différents paquets partout sur mon serveur, je m'en porte pas plus mal. Et le jour où je veux dégager le service en question, il n'y a plus un trace.

sauf que c'est symptomatique du developement web et de Ruby. les container ne sont pas uen solution mais juste un gros coup de peinture pour masquer le veritable probleme.

Si RubyOnRail n'était une telle merde a mettre en place, ca ne serait pas un probleme.

D'ailleurs on vois bien que la majorité des container sont pour des applications en Ruby...

Godzil (./1688) :
Arvi: oui c'est pour ca que je ne peux psa installer le container de Discuss parce qu'il entre en conflit avec le serveur apache qui est sur mon serveur, mais il n'y a pas d'incompatibilité possible entre les containers...

Discourse est une exception, j'ai jamais vu un truc aussi chiant à installer même dans un container. Prendre ça comme exemple est de mauvaise foi.

Migrer un container sur un autre serveur se fait très facilement, je ne vois pas le problème non plus

Et 10 fois apache, oui tu as peut-être les fichiers d'installation 10 fois (c'est pas ça qui va remplir le serveur mais bon...), mais après chaque process se lance comme le ferrait de toutes façons lorsqu'il y a 1 apache d'installé sur le serveur. Je ne dis pas que gérer 10 sites sur un serveur c'est compliqué à gérer, loin de là, juste dans plein de cas c'est très pratique (mais je n'utiliserais pas ça pour tout).

Quand à une incompatibilité, à part discourse où ils ont fait ça comme des nuls, j'ai perso jamais eu un soucis.

edit :

CONTAINER ID        IMAGE                         COMMAND                  CREATED             STATUS              PORTS                                                                  NAMES
537d9d776610        gitlab/gitlab-ce:8.7.3-ce.0   "/assets/wrapper"        29 hours ago        Up 6 hours          0.0.0.0:10022->22/tcp, 0.0.0.0:10080->80/tcp, 0.0.0.0:10443->443/tcp   gitlab-ce
2dec3589df28        rocket.chat:0.31              "node main.js"           12 days ago         Up 12 days          0.0.0.0:3000->3000/tcp                                                 rocketchat
51a77f561815        mquandalle/wekan              "/bin/sh -c 'bash $ME"   2 weeks ago         Up 2 weeks          0.0.0.0:8990->80/tcp                                                   wekan
426112b1123a        mongo                         "/entrypoint.sh mongo"   2 weeks ago         Up 2 weeks          27017/tcp                                                              wekan-mongodb
f6a432a1dd2e        ubuntu:14.04                  "/bin/bash"              2 weeks ago         Up 2 weeks          0.0.0.0:8989->80/tcp                                                   phabricator
3e0e77e384c5        redmine:3.2.2                 "/docker-entrypoint.s"   2 weeks ago         Up 2 weeks          0.0.0.0:3089->3000/tcp                                                 redmine
aac652d203e3        mongo                         "/entrypoint.sh --sma"   6 weeks ago         Up 2 weeks          27017/tcp                                                              db-rc
36c400648a39        ubuntu:14.04                  "/bin/bash"              3 months ago        Up 11 weeks         0.0.0.0:9003->9000/tcp                                                 gloomy_jones

Comme ça j'ai pu tester gitlab, phabricator, wekan, redmine, un ubuntu qui fait tourner php7, plus d'autres trucs (odoo par éxemple, ou d'autres web apps qui demandent beaucoup de trucs à installer). Et pas de résidus de paquets lorsque je supprime un container.

Non il y a une difference majeure entre un seul serveur qui gere toutes ses resources et 10 qui tournent en //
Non seulement l'overhead du serveur est multiplié par 10, et il n'y a aucune synchro entre chacun des serveurs cars ils pensent chacun etre seul au monde.

La difference etnre 10 serveur apache poru 10 site, et un seul serveur apache avec 10 thread, c'est que le serveur apache avec 10 thread est capable de faire du load balancing entre les 10 thread la ou tes 10 serveurs apaches ne font qu'un seul truc

Ce n'est pas pour rien qu'on a inventé le concept de "process légé" aka: threads.

Et tes 10 container avec leur 10 apaches, leur 10 Mysql, tu auras forcement des conflits. Le port 80 ne peux pas etre ouvert par 10 applications, idem pour le port pour MySQL, etc..
Bref tu es obligé d'ajouter un serveur en plus pour faire proxy entre les 10 apps intallé #simple#

Le principe des container c'est exactement ce que fait Atlassian depuis des années avec Jira, Confluence & co.. Et franchement c'est devenu un critere de refus de mon coté ce genre d'application qui a décrété qu'il savait mieux que toi ce qu'il faut faire. Qu'il y ai un mode "pour les nuls" a la limite, mais quelqu'un qui installe un serveur n'est pas sensé etre un "nul" et il est sensé savoir ce qu'il fait.

C'est d'ailleurs le symptome de ces container: faire faire de l'admin sys a des gens qui sont de simple developeurs et ne connaissent pas forcement toutes les subtilités de l'administration systeme.

A propos, utiliser un container pour avoir un environnement identique entre tous les dev ? Mouarf. Il y a bien plus simple pour ca (et bien plus efficace)
- Un serveur avec les outils
- NFS
- Installer le meme OS chez tous le monde, et leur dire d'aller se faire foutre si ils disent "non mais moi je veux la distribution machin parceque" et ne pas laisser les utilisateurs installer/mettre a jour leur distribution sous risque de se prendre un gros de la part des admin sys si il y a le moindre problème avec leur machine parce que X ou Y ne marche pas.

Un container n'est PAS une solution a ce genre de choses, c'est un palliatif.
C'est comme donner un placebo pour un rhume en disant que ca va faire effet, c'est une non resolution d'un probleme simple par un problème 100x plus complexe en apparence 100x plus simple, mais les apparences sont trompeuses.


Et je vais rejoindre Kevin pour le coup, si tu as des "residus" c'est que l'installation des dépendances n'a pas été fait correctement. Ou plutot que les gestionaire de paquets (que ca soit le machin de ruby, ou python) ne gere pas correctmente les dépendances et n'est pas capable de faire le menage apres installation si personne n'utilise une lib.

Gentoo est tres efficace pour ca: emerge depclean marche très bien pour virer les machins inutiles, a partir du moment ou ce sont des dépendances tiré par un ebuild que tu as explicitement installé. depclean ne vire pas les ebuild qui on été explicitement installé par l'utilisateur (heureusement d'ailleurs)

T'inquiète pas Godzil, un jour ils vont inventer la mutualisation des ressources inter-conteneurs. Et tout rentrera dans l'ordre

Bon à part ça, c'est pas un peu sur le principe des conteneurs que fonctionnent les apps, ou du moins certaines apps, sous OSX ? J'avais cru comprendre ça, mais de loin et j'ai pas approfondi, donc ne me tire pas dessus à boulet rouge

Folco (./1693) :
Bon à part ça, c'est pas un peu sur le principe des conteneurs que fonctionnent les apps, ou du moins certaines apps, sous OSX ? J'avais cru comprendre ça, mais de loin et j'ai pas approfondi, donc ne me tire pas dessus à boulet rouge

Il y a de ça, en effet... plus encore avec le sandboxing.

Oui et non, c'est quand meme assez different, ce n'est pas un OS complet (ou quasi complet) qui est tiré, certaines libs oui, mais c'est comme une application Windows qui installe ses DLL dans son dossier, la difference, c'est que sous OS X, le dossier est masqué.

Un container c'est bien plus que ca, c'est plus proche de la virtualisation que ne sont les applications sous Windows ou OS X.

Et les applications Windows et OS X qui bundlent tout sont aussi pourries, ce n'est qu'un workaround pour les défaillances du système d'exploitation (incapable de résoudre les dépendances automatiquement). De plus, généralement, on bundle des DLLs, la solution de paresse totalement idiote qui réunit les désavantages des bibliothèques statiques et dynamiques.

Arvi89 > oui, pour tester, c'est super pratique.

Par contre, de la prod sur le long terme…
Soit tu t'occupes toi-même de gérer le contenu des conteneurs, donc à chaque mise à jour d'un des composants, tu dois identifier quel conteneur utilise quel composant, puis mettre à jour le conteneur, et puis mettre à jour les serveurs qui utilisent ce conteneur.
Soit tu t'en fous de savoir quels sont les composants de chaque conteneur, mais dans ce cas tu es incapable de dire si ton système est vulnérable à la faille de sécurité qui affecte YYYY en version X.Y.Z.c.


Folco > pour les apps OS X, la répartition est différente. Les composants communs sont quasiment tous fournis par le système (libc + le framework Cocoa), il y a a priori peu de libs dupliquées d'une appli à l'autre. Avec une grosse louche, tu auras peut-être 5% de données répliquées.
Pour les conteneurs, toujours avec une grosse louche, ça va monter à plus de 50% vu que chaque conteneur aura sa copie de MySQL + Apache + X + Y + Z

Que veux-tu, Windows est un système d'exploitation ouvert qui permet à n'importe qui de faire tourner son application. Dans une distro linux, tout passe par la moulinette des décideurs de la distro, avec leurs guidelines psycho-rigides auxquelles t'es obligé de te plier.
Au moins sous Windows, pas de version de lib ou de je ne sais quoi imposée, tu fais ce que tu veux, c'est ça la liberté.
Quant aux dépendances, Windows sait les gérer quand il le veut (par exemple, pour la toolchain de dev : tu choisis l'apps que tu veux installer, les dépendances le sont automagiquement).

Folco (./1698) :
Que veux-tu, Windows est un système d'exploitation ouvert qui permet à n'importe qui de faire tourner son application. Dans une distro linux, tout passe par la moulinette des décideurs de la distro, avec leurs guidelines psycho-rigides auxquelles t'es obligé de te plier.
Au moins sous Windows, pas de version de lib ou de je ne sais quoi imposée, tu fais ce que tu veux, c'est ça la liberté.

Quant aux dépendances, Windows sait les gérer quand il le veut (par exemple, pour la toolchain de dev : tu choisis l'apps que tu veux installer, les dépendances le sont automagiquement).

Chez moi, l'automagie ne marche pas

https://godbolt.org/
Voilà qui devrait plaire à Folco

Sympathique.

il manque quand même le 68k pour que ça soit totalement Folco compilant

C'est la première chose que j'ai cherchée

Folco compilant

Joli

Bien vu

A defaut d'assembleur 68000 en ligne, on a au moins un desassembleur: https://www.onlinedisassembler.com/static/home/

Zerosquare (./1700) :
https://godbolt.org/

Attention, leur "x86" est en réalité x86_64.

6_6

Tout un article plein d'alarmisme, et quelques paragraphes finaux qui disent qu'en fait, rien ne va changer. Et puis ça ne concerne que Java EE, pas Java lui-même (Java SE). Les implémentations libres de Java EE sont très connues et s'en sortiront très bien même dans l'éventualité où ils devraient arrêter de s'appeler "Java EE".

Tout un article plein d'alarmisme, et quelques paragraphes finaux qui disent qu'en fait, rien ne va changer. Et puis ça ne concerne que Java EE, pas Java lui-même (Java SE).

Le problème c'est que depuis quelques années c'est JavaEE, qui maintient Java :
- JavaME a juste disparu depuis l'avènement de iOS et d'Android.
- Java SE pour les applets n'a jamais décollé est il est désormais complètement marginalisé suite aux problèmes de sécurité. Maintenant le HTML5/JavaScript permet de réaliser la plupart des choses que permetaient les Applets, sans plugins.
- JavaSE pour les applications desktop reste anecdotique, et Oracle ne fait plus trop d'efforts dessus depuis quelques années.

Les implémentations libres de Java EE sont très connues et s'en sortiront très bien même dans l'éventualité où ils devraient arrêter de s'appeler "Java EE".

La seule implémentation Libre vraiment bonne de est OpenJDK qui est totalement contrôlée par Oracle, et la seule qui aurait pu lui faire de l'ombre était Harmony, que Oracle a justement condamné a mort.

Le soucis des implémentations libres, c'est que Oracle garde une épée de Damoclès dessus. En effet, il reste maitre du kit de certification Java qui lui est tout sauf libre. Oracle en est le seul maitre et il y accorde l'accès de manière tout a fait discriminatoire. C'est comme cela qu'il a signé l'arrêt de mort du projet Apache Harmony qui n'a pas pu être certifié et donc été abandonné par son plus gros controbuteur IBM, car ça mettait les utilisateurs à la merci des brevets de Sun/Oracle.

Il y a certes l'OpenJDK, mais pour y contribuer, il faut céder la propriété du code a Oracle qui l'utilisera pour sa version propriétaire.
Par contre si on forke, on retrouve à nouveau dans la situation de Harmony : on ne sera probablement jamais certifié et on est donc exposé a une attaque en justice d'Oracle, ce qui est dissuasif pour toute entreprise sérieuse.
Bref c'est de la GPL, mais pas vraiment libre pour autant