Firwen a écrit 562 commentaires

Pareillement,

L'idée est intéressante. Je rêve d'un système de dépendance en C++ à la Go ou la homebrew qui télécharge / compile directement l'arborescence de toute projet en utilisant GitHub ou similaire.

Le projet le semble beaucoup moins.
A mon humble avis, un nouveau projet pour outil de développement, en 2015, qui n'est pas open source, encore moins libre…. est un projet qui va droit dans le mur.

Je n'ai aucune envie de lier la compilation de mes projets avec un outil que:

• je ne peux pas trouver dans les dépôts des distributions standards
• je ne peux pas modifier moi même en cas de pépin car je n'ai pas les sources.
• je n'ai aucune garantie qu'il existera encore dans 5 ans.

On parle d'un soft qui peut avoir un rôle centrale pour la durée de vie d'un logiciel là…. pas d'un jouet pour enfant.

Le beaucoup plus léger (en ce qui concerne l'occupation RAM, pour les I/O je suis convaincu) me semble vraiment exagéré.

C'est ton opinion.

Pour l'anecdote, J'utilise beaucoup docker pour faire du re-packaging en local dans des environnements "propres".

Là où je peux sur ma machine personnel (un simple laptop) faire tourner maximum une dizaine de VM + distro standards en parallèle.

J'arrive aisément à faire tourner une cinquantaine de conteneurs pour le même genre de taches, sans grande difficulté.

C'est un point de montage ?

C'est un point de montage.

On peut faire un container qui contient à la fois les données et la configuration, il n'y a selon moi pas de raisons valables pour séparer les deux.

Y a des raisons valables. L'une d'entre elle est de pouvoir "rebuilder" ton image en case de mise à jour sans avoir à te retaper toute la configuration….

certes

Tu développes ? Si je ne m'abuse, avec Docker (ou n'importe quel système de conteneurs), la distribution guest tourne également en mémoire. Par exemple, si j'ai 20 conteneurs qui font tourner une Ubuntu, j'ai 20 Ubuntu en mémoire, non ?

Non. Tu n'as pas réellement 20 ubuntu en mémoire. Tu as juste l'emprunte mémoire des quelques bibliothèques et du process que tu fais tourner dans son "environnent" Ubuntu.

Tu n'as pas l'emprunte mémoire associé au Kernel de chaque guest, tu n'as pas non plus l'emprunte mémoire associée aux démons d'init, de networking, de logging / monitoring de chaque guest. Toutes ces choses sont fait directement par l'host.

L'emprunte mémoire des containers est trés faible.

Ceci dit, un VMware fan me rétorquerait trés certainement que VMWare ou KVM ont leur propre solutions pour éviter le dédoublement des page mémoire identiques sur l'host ( KSM pour KVM ).

Mais même considérant ça, la containérisation est généralement beaucoup plus légère que la virtualisation.

image de l'image

Généralement l'image directement. Il est tout à faire possible de faire des images minimalistes avec Docker. Un environnement de base épuré peut être réduit à 20-40Mb d'espace disque.

pour l'exploitation

Ma solution pour ça c'est d'utiliser un volume externe qui contient les fichier de configuration.
Ça t'autorise à séparer le versionning du soft en lui même du versionning de la configuration.

Les plus pointilleux font ça via Cloud-init, etcd ou autre, comme pour une VM traditionnel.

Mouais , enfin l'overhead d'une VM c'est pas grand chose

Ça dépend surtout de ton échelle et de tes cas d'utilisations, mais non l'overhead de la virtualisation n'est pas négligeable.

D'un point de vue purement CPU, tu as raison et c'est de l'ordre de 2-5%.

Par contre pour les I/O disk, c'est bien plus important. Spécialement si tes VM tournent sur un RBD ( type Ceph ou autre).

L'emprunte mémoire du guest OS est aussi à prendre en compte. Il peut aller de quelques Méga pour une image optimisé à quelques Giga pour des distros standards, là où il sera null dans le cas d'un container.

Il n 'y aucune raison de moinsé, c'est un débat interessant.

Sauf que non. La philosophie derrière Docker, c'est de lancer un process (et un seul) par conteneur. Et en foreground parce que le conteneur s'arrête si le process lancé s'arrête

J'aimerai savoir sur quoi tu te bases pour dire ça.
Tu peux parfaitement utiliser un seul container docker pour lancer plusieurs services.
Tu peux parfaitement l'utiliser pour lancer un serveur d'application et Apache ( et même rsyslog ) dans le même conteneur.
Et ce sans supervisord, un simple script bash fait l'affaire.

Installer SSH dans un container docker est considéré comme une mauvaise pratique en effet, pour la simple raison que c'est un over kill. Il y a une dizaines de manière différente de "binder" dans un container sans avoir à déployer SSH.

Le système de cache de Docker ne comprends pas que apt-get update; apt-get full-upgrade n'est pas idempotent et gardera en cache une image avec une ancienne liste de paquets sans la mettre à jour.

Les mises à jour sont problématiques oui. Mais ça c'est pas propre à docker, c'est propre à tout système qui a un versionning stricte. Que ça soit docker, le système d'apps d'OSX ou nix.
Un workaround pour ça est simplement de faire executer un apt-get upgrade au démarrage du container….

Le système de construction via les Dockerfile est aussi trop rudimentaire pour gérer facilement des déploiements d'applications et la lenteur des builds et gênante.

Ça c'est ton avis. J'aurai plutôt tendance à dire que sa simplicité est sa force. Le Dockerfile t'autorise simplement à construire une image comme une recette de cuisine, étape par étape, couche par couche.

Si tu trouves ça limité: qu'est-ce qui t’empêche d'utiliser Docker build avec Cloudinit, puppet ou je ne sais quel tool de on choix ? ça se fait en deux lignes dans le Dockerfile.

Docker (et tout système de container) n'est PAS une solution de virtualisation, c'est juste un chroot sous stéroïdes que tu peux déployer/cloner/distribuer facilement.

Avec les mpm itk, peruser ou autre d'apache. Par contre, c'est un vhost par user.

Ou sans utiliser mod_dav. Avec un fcgi + dav server et un suexec bien configuré par utilisateur.

ça t'autorise même à utiliser AFS/NFS en backend si c'est fait proprement avec kerberos….

Sauf si tu veux que chaque utilisateur soit propriétaire de ses fichiers. Tu sais un truc comme gérer différentes UID

Ce que tu peux faire aisément si tu sais comment configurer mod_dav et apache.

Avec Apache ? mmmm …

Arrête donc de dire n'importe quoi.
FTP a une liste de problèmes de sécurité inhérent au design du protocole aussi longue et ennuyeuse que le JT de Jean Pierre Pernaud.
A tel point qu'ils en ont même fait un RFC (https://tools.ietf.org/html/rfc2577).
Simplement parce que le méchanisme d'ouverture de data-channel séparé est absoluement ignoble de ce point de vue pour des raisons évidentes….

ça n'a rien à voir avec la sécurisation d'un serveur HTTP, Apache ou autre.

Ça aurait été des plus charmants d'essayer de nous illustrer des cas d'utilisations au lieu de nous balancer un épic "SFTP C tRo bien, FTS sa pue" sans plus d'informations.

Tu sembles chercher une solution idéale pour du drag / drop de fichier sur un serveur ( mutualisé ou autre ).

Et une des meilleurs solution pour ça ne s'appelle ni FTPS, SFTP, TFTP, LFTP, SFTPS ou PornFTP. C'est simplement WebDav.

• WebDav se déploie simplement avec Apache
• Il n'est pas TOFU contrairement à SFTP, et supporte correctement SSL
• Il n'a pas de canal de donnée auxilaire ce qui veut dire : -> Pas de problème avec les pare-feu, NAT ou autre -> Pas de problème de sécu lié au DDOS.
• Il y a une plétoire de client disponibles sur tous les OS, cyberduck…… ou des choses comme , daviX ou cadaver si tu cherches des command line tools.

Ceci dis, il me semble que dans le monde du libre, l'ensemble des mirroirs de fait avec du rsync sur ssh (ou sur rsync).

C'est partiellement vrai mais pas toujours.

Le problème de la solution rsync + ssh… C'est justement SSH. Tu dois d'une manière ou d'une autre donner un accés SSH à un tiers avec les risques que ça comporte. Là où FXP t'autorise simplement une action de transfert.

FXP et plus précisement gridFTP, est pour ces raisons très utilisé en HPC, dans les environments de type Grid, ou pour le déplacement de données massives entre serveurs.

pas que Ubuntu:
- toutes les distributions qui ont network-manager
- 99% des OS qui ont une auto configuration pour les interfaces réseaux potables ( OSX, même Windows…. )

Et c'est normal j'ai envie de dire.
Le logique par défaut communément admise c'est "avoir du réseau qui marche par défaut", et "configure en manuel si tu veux".

La logique OpenBSD ça serait plutot "c'est potentiellement vérolé ! ne faisons rien !", configurons donc tous notre eth0 à grand coup d'ifconfig.

Je comprends pas ce que tu veux dire… DHCP n'est activé par défaut sur une aucune interface, encore heureux, que ça soit v6 ou v4. Il faut que tu dises explicitement que tu veux un daemon DHCP.

Ben tu confirmes exactement ce que je disais sur la sécurité. Car tous les autres OS / distributions linux l'ont généralement activé par défaut.

c'est marrant, j'ai comme l'impression que tu avais envie de troller et que tu as juste cherché un pretexte pour placer ton petit laius sur la sécurité.

Non c'était gratuit au passage ça.

Bref, ça ressemble pas mal à ce que tu dis non ?

Non.
Y a une grande différence entre tout désactiver par défaut, et désactiver simplement ce que tu trouves risqué ( en l'occurence le spoofing RA )
Laissez le DHCPv6 activé fait déja une belle différence.

Justement, ça évite d'avoir une dual-stack sans le savoir (ce qui doit être une des plus grosse faille de sécurité en ce moment), par exemple avec un système compromis qui balance des RA.

Dans ce cas, et si ils sont paranoïaques à ce point :
Il suffit simplement de désactiver les RA par défaut, en supportant uniquement DHCPv6 ou similaire.
Ou encore d'implémenter un mécanisme de protection maison contre le spoofing RA.

Je vais trés certainement m'attirer les foudres des BSD-boys ici présent mais je dirai que ça sent surtout le retard du à un manque de man power ou/et du à la procédure d'intégration nazi super stricte d'OpenBSD…..

L’extrémisme en sécurité c'est merveilleux.
Ça peut justifier tout et n'importe quoi et surtout n'importe quoi quand il s'agit d'inaction :

• Garder IE6 en entreprise pendant 15 ans car c'est "safe" car supporté… ( on connait, on maitrise…. )
• Foutre 80% de la puissance des bécanes en l'air pour faire tourner des bloatwares plus dangereux que sécurisant. ( McAfee, je te la dédicace celle là)
• Utiliser des softs qui ont 20 ans et des déficits évidant en terme de fonctionnalités, qui réduisent votre productivité car on a "peur" de ce qu'on ne "connait" pas.

La sécurité poussé à l’extrême, dans tous les domaines, c'est la prise de decision par la peur.
Et dans tous les domaines, la prise de decision par la peur, ça n'apporte que des emmerdes.

Par contre, je n'ai pas compris le lien avec les prototypes.

J'ai essayer de l'expliquer dans le post précédent le tiens.

Ceci dit, je suis à peut prêt aussi doué pour les explications détaillées que greenpeace pour construire des centrales nucléaires.

La composition anonyme est juste une "astuce" pour avoir une forme appauvri d’héritage et eviter les collisions de noms

Par exemple, pour une struct animal

    struct Animal{
       int size;
    }

un heritage typique est :

    struct Ours: Animal{

    }

    Ours ours;
    print(ours.size)

Une composition serait de faire :

    struct Ours{
       Animal animal_data;
    }
    Ours ours
    print(ours.animal_data.size)

Une composition anonyme en Go ressemble à ça

    struct Ours{
       Animal;
    }
    Ours ours
    print(ours.size)

La principal différence avec l'heritage est que la composition anonyme n'implique pas le polymorphisme.

Il est impossible en golang de faire qqchose comme :

    struct Arbre{
       virtual msg() { print("hello arbre") }
    }

    struct Tilleul {
       Arbre;
       virtual msg() { print("hello tilleuls") }
    }

    Arbre* a = new Tilleuls()
    a->msg()
    # hello tilleuls

Ça ne marchera simplement pas dans le cas d'une composition anonyme, simplement car la composition n'implique pas le système de vtable qu'a C++ par exemple.
Mais d'un autre coté, ça permet de composer un objet qui contient plusieurs sous objets de manière completement transparente comme on peut faire en héritage multiple et même si ces objets ont un parent en commun : on s'en fout.

Pour le polymorphisme, c'est fait en Golang via le concept d'interface et d’héritage structurel et non par type comme en Java.
C'est assez bien expliqué ici http://golangtutorials.blogspot.ch/2011/06/polymorphism-in-go.html

Grosso-modo contrairement à Java ou similaire, pour "matcher" une interface, tu n'as pas besoin de l’hériter ou d'en dériver.
Tout objet possédant une "signature" similaire à celle de l'interface ( une methode Speak() ) dans l’exemple, sera considérer comme un objet parfaitement valide.

C'est puissant, trés puissant.

Quand au dernier point à propos de la composition anonyme avec un go-pointer, Ceci l'illustre bien

    type JohnLenon struct {
        nom string
    }

    type JohnLenonEnConcert struct{
        *JohnLenon

        concert string

    }


    func main() {

        john := JohnLenon{"john's name"}
        john_concert := JohnLenonEnConcert{&john, "A paris"}

        fmt.Printf(" nom de john: %s \n", john.nom)
        fmt.Printf(" nom de john en concert : %s \n", john_concert.nom)

        john.nom = "bob";
        fmt.Printf(" nom de john en concert : %s \n", john_concert.nom)    

    }


 nom de john: john's name 
 nom de john en concert : john's name 
 nom de john en concert : bob     

La composition dans ce cas reference un objet déja existant… qui veut etre modifié… cloné… partagé… etc..

Si tu veux changer ça, avoir à la fois du polymorphisme, de l'inférence de type et de l'héritage, à priori, c'est impossible. On ne peut avoir que 2 des 3. Je serais curieux de voir un langage sans héritage, pour voir.

Golang n'a pas d'heritage.

Il ont une approche basé sur de la composition anonyme et de l'interfaçage structurel.

Et si ça a l'air louche au premier abord, je trouve leur approche TRES puissante à l'usage.

Primo, ça permet de definir des methodes dans des classes défini dans des modules externes, de la même manière que les "traits" dans Rust.

Secondo, la composition anonyme autorise une approche "Mixin", en ayant l'avantage de l'heritage multiple sans avoir les problèmes de l'heritage en Diamant.

Tertio, l'utilisation de go-pointer comme composant anonyme autorise de se rapprocher de ce qu'on peut faire dans un langage à prototype: Tu crée un objet depuis un objet.
ça te permet de garder sa contextualisation, son interface et de l'étendre de manière dynamique.

Je ne suis pas d'accord. Le +. et *. est chiant, mais en ouvrant le bon module (open float), cela se corrige.

Donc je traduis tes propos en quelque chose de moins biaisé :

"Donc oui le "tout explicite" est une connerie, ".+" en est le preuve. Mais depuis OCaml 4.0 ( 2ans max si ma mémoire est bonne), on a admit sans admettre que c'était une connerie et on s'est décider à fournir l'operator overloading pour OCaml aprés 10 ans de refus ( comme pour le threading d'ailleurs ).
Et tu peux maintenant utiliser de manière transparente l'overloading en ouvrant le module float tout en foutant à la poubelle le principe du 'tout est explicite'.
"

Sinon entre parenthèses, l'operator overloading existe en C++ depuis 20 ans maintenant.

Mais j'ai vraiment pas envie de m'éterniser là dessus: faire avouer à un programmeur OCaml que leur langage a des problèmes c'est comme essayer de faire avouer à un Apple-boy que son Mac n'est pas parfait: long, pénible et peine perdu.

De manière général, quand un langage généraliste reste un langage de niche comme OCaml…..C'est qu'il y a des raisons à ça…

Tu compares int_of_float avec ça ?

Je n'ai jamais dit que l'approche de Rust était la bonne. Juste que celle d'OCaml "le tout explicit et simple" était une connerie.

J'imagine bien que la syntaxe permet des subtilités. Mais je croyais que le C++ avait calmé les concepteurs concernant les subtilités des langages. Cela peut devenir une énorme source d'erreur.

Mmmh, entre nous il y a un compromis à trouver entre avoir trop de subtilités et une simplification extrême de la grammaire à la ML/OCaml.

Sous peine de finir avec des horreurs du genre .+ .- .* int_of_float and co vendu au nom de la "safety" et de l'inférence de type.
Pour résulter en un truc "simple" mais qui vous pourrit joyeusement la vie à l'usage ;;;;;;;;;;;;;;;

C'est ce qui est marrant avec les "libristes" qui parlent beaucoup pour critiquer, mais ne font rien : ils critiquent que les

Allez, parce qu'on est Vendredi….

Tu me feras toujours rire mon cher Zenit.

Remplace "libristes" par "arabes" et "critiquer" par "profiter/consommer/abuser" et on dirait presque un discours de Marine le Pen.
Même consistance, même approche : généralisation hâtive sans fondement, point de vue personnel exprimée comme si tu détenais la parole de Dieu, amalgame entre un comportement et le "tag" d'une communauté.

C'est assez ironique en soit non ? :D

Sinon pour en revenir à ton point. Ces communistes fainéants parasites "libristes", comme tu dis… sont les même qui ont pondu "from scratch" des choses comme Owncloud, Jabbix, Mailpile, TextSecure, WordPress, Seeks, searx….. utilisé par des millions d'utilisateurs justement pour répondre à cet problématique.

Tu as déja pensé à te lancer en politique ? je suis sur que tu aurais du succés par les temps qui courent.

Envoie-les moi, je suis preneur et paierai sans problème ce prix (évidement, je les prends sous couvert qu'il soient compétents et capables de coder genre ce dont on parle cad des modifs dans LO qui seront acceptées upstream).
Tu en connais, moi je n'en connais pas (pour ce prix, on peut avoir certes, mais moins de compétences).

Ben, tu ne dois pas être dans le monde de la recherche mon cher Zenit.

Les laboratoires sont remplis de personnes payé bien moins que ça pour des compétences bien supérieurs à "savoir faire un patch LO" .

Ça reste encore le cas, le français reste une langue très utilisée dans les instances internationales

Ou pas.
La langue de l'international est l'anglais, il y a de très fortes chance qu'elle le restera et il serait bon d'arrêter de se voiler la face.

Le français est encore PARTIELLEMENT utilisé dans QUELQUES organisations internationales pour des raisons historiques ( Société des nations -> ONU ) ou géographiques ( Bruxelles, Genève … ): point. En dehors de ça c'est finit, n'en déplaise à l'académie la maison de retraite française.

Il serait bon que la France arrête de se trouver des excuses pour être une des dernière roue du chariot concernant l'apprentissage de l'Anglais.