Heu depuis la 2.0 (donc je dirai plus d'un an facilement) pour l'upstream c'est par pip ou setup.py en local. Tu ne serais pas tombé sur le vieux wiki (supprimé depuis) marqué en deprecated tout gros sur la page principale? :) (ta remarque sur debian fraîche me fait penser que si).
Sinon des paquets sont disponibles sur Fedora/RH depuis… heu disons sacrément longtemps (la 1.0 je crois mais je peux me tromper), grâce au travail de hvad. Debian ça a pris plus de temps car… disons que c'est debian donc c'était autrement plus long :)
Plus sérieusement, un outil de supervision ça prendra de toute manière plus de 4h pour en mesurer l'efficacité. L'installation des outils c'est toujours relativement facile (quand on prends la bonne doc ;) ) mais la partie configuration là ça se corse, car tout le monde a des besoins très différents en la matière et l'adaptation à ses besoins bah… c'est pas forcément trivial ^
Si en 2h tu as fait le tour de tes besoins, c'est qu'ils étaient relativement simples, et dans ce cas je conseille le relativement méconnu (à tort) Sensu. Son scope est de l'ordre de 10% d'un Nagios ou d'un Shinken a fortiori, mais c'est bien plus accessible ┗(＾0＾)┓
En fait c'est plus un rajout qu'un remplacement (cf https://github.com/Alignak-monitoring/alignak/pull/5/files), ils ne suppriment pas l'ancien header. Après ce n'est pas leur premier fork, je pense qu'ils savent ce qui se fait. Donc j'ai pas de crainte de ce côté là :)
Le vrai soucis (en tout cas une part importante) ce sont les clients je pense. Pourquoi on France on a une armée de SSII et aux US des éditeurs? Les fonds pour se développer aident à ça oui sans l'ombre d'une hésitation, mais un client français va te demander le prix en 1ère question, alors que l'américains va te demander le ROI. Çà ne motive pas à mettre tes forces dans la technique et donc l'excellence :)
Et tu as une idée géniale de modèle qui marche dans la vraie vie donc? ^
En fait la question 1 est relativement mal posée. Il y a de grosses disparités entre les marchés. Tu remarqueras qu'entre la France où le critère N°1 est le prix et les US où la première question qu'on te pose c'est le ROI, je te laisse deviner quels sont les modèles avec lesquels les sociétés débutent de chaque côté de l'atlantique ^
Pour la question 3: sincèrement en France non, seul le prix va importer dans une grande majorité de cas, et l'open source a la un atout majeur: c'est sans licence payante. Soucis: c'est la plupart du temps installé et mis en place sans aucun retour (ni financier ni de code) à l'équipe qui code. Ça ne marche qu'un temps ce modèle (hors levée de fond pour faire du buzz et monter une offre dérivée type SaaS ou Enterprise, mais on en revient au cas 1).
Je suis d'accord que le côté privatif/fermé fait que c'est facile à mettre en place sur un écosystème privatif, mais je pense que c'est tout à fait faisable côté libre.
Ah ça on pourra le voir, on est d'accord. Mais dans les faits combien "regardent"? Est-ce que tous, et je dis bien tous, les paquets compilés dans les distribs sont relus par un comité de plusieurs personnes, et avec un comité qui change régulièrement? Si par exemple un paquet installé par défaut est géré par 1 ou deux personnes, qu'est ce qui empêche ces personnes de se faire corrompre et mettre un tel certificat en douce?
C'est un peu comme l'histoire d'OpenSSL: oui tout le monde peut relire, mais dans les faits combien le font vraiment?
Sincèrement je serais étonné que ça ne soit déjà pas le cas et que si on faisait un audit 100% d'une distro en phase de compilation on ait pas une petite surprise par ici ou par là. Si j'étais à la NSA c'est ce que je proposerai en tout cas :) (genre je sais pas affaiblir avec un patch la création d'entropie de certificats SSL ou ce genre de choses :D ).
Ah j'avais cru comprendre que c'était en parallèle et non pas en réutilisant nftable. Techniquement c'est déjà moins lourd, même si sur le fond ça fait que tu as quand même deux endroits/manières de gérer ton firewall.
Systemd tente quand même d'unifier pas mal de points en un tout cohérent, ce n'est pas rien. Ensuite s'il est facile de déboîter une brique pour en mettre une autre à la place ça bien. Genre ici ce qu'il ne faut pas c'est que du doive obligatoirement passer par la définition des services pour gérer la partie réseau de tes daemons. Si ça repose sur des briques/lib communes, tu peux avoir 80% des cas gérés avec systemd, et les 20% derniers avec des briques plus adaptés/spécifiques :D
Je pense que son soucis c'est qu'il a été vu comme un "simple" serveur d'init. Or c'est une sorte de middleware pour l'OS. C'est plus à comparer avec la libc qu'avec un systemV au final. Bon après il a du démarrer comme un init et évoluer vers ça.
Ça mets aux oubliette les principes unix une telle vision (quoi que chaque conteneur faisant son travail spécifique, et systemd étant là pour faire le pipe c'est pas non plus orthogonal avec unix en fait… juste à 89° ^ ).
Ensuite faut pas se leurrer, on s'oriente de plus en plus vers des systèmes applicatifs jetables une fois instanciés (l'image et la manière dont on orchestre les images est ce sur quoi on travaille, les instances non). EC2 a ouvert la voie, Docker renfonce le clou avec son écosystème (peu importe ce qu'on pense prod/pas prod, la question n'est pas là, si c'est pas lui ça sera un autre qui arrivera à la prod). On est plus qu'incité avec les outils qu'on a à notre disposition de bâtir de manière quasi-automagique notre infra. Or arrivé à ce niveau là, on n'a plus trop besoin d'avoir un init à la systemd pour lancer X services sur le même serveur, mais plutôt de lancer X boites sur X serveurs hôtes différents qui échangeront ensemble à travers un réseaux bâti lui aussi de manière quasi-automagique.
Bien? Mal? Sincèrement je ne sais pas. De plus peu être que finalement seule une minorité d'admins en aura besoin réellement d'un tel système, et que la majorité restera avec le bon vieux système de VM installée à la main.
Je pense que personne n'est naïf au point de croire que systemd est juste là pour faire plaisir à ses développeurs, et que lorsqu'ils rajoutent un pan à leur outil c'est juste pour avoir ds lignes de code à entrer dans leur emacs/vi/nano/notepad (rayé la mention inutile). C'est leur taf, pas leur hobbie, il y a une raison économique derrière. Ainsi lorsque je m'amuse à extrapoler les avancées des différents outils ça donne ça, ensuite rien ne dit qu'une autre organisation que redhat n'a pas autre chose dans les cartons :) (je pense tout particulièrement à google, facebook ou amazon, qui ont l'air de ne pas attendre que des éditeurs leur fournissent les outils centraux de leur SI).
Ou alors je me trompe complètement et Lennart c'est juste un grand curieux qui veut toucher à tous les domaines d'un OS ^ ^
Je prends le pari sur une implémentation de conteneurs à la docker. Après tout les cgroups ils savent faire aussi. Un intérêt serait par exemple d'avoir une unique distribution "systemd" qui lance des applis d'autres distributions dans leur propre conteneur.
De là à penser qu'ensuite une intégration poussée entre openstack et ces hyperviseurs systemd rendrait la plateforme redhat parfaitement adaptée et surtout centrale…
Pour en revenir à des sujets moins trollesque (et encore), c'est pas complètement stupide de laisser à systemd le soin de gérer les flux et les redirections. En effet ça peut être lié à un service (genre un service apache ou un load balanceur?), mais ça signifie qu'il va falloir réimplémenter tout iptable/nftable pour que ce soit viable (deux systèmes qui se marchent dessus ça ne fonctionne jamais bien longtemps sur un système). Le coût me parait gros à vrai dire.
On pourrait presque demander ce qui ne va pas dépendre de systemd en fait, car s'il gère les services et la pile réseaux, restera les filesystems et la gestion de version des données dessus.
A la limite ce qui serait bien c'est que systemd nous sorte un gestionnaire de paquet qui soit pris d'office partout (ce qui serait quasiment ait s'ils font des conteneurs). Là ça serait un vrai changement majeur et un bénéfice non négligeable je trouve :)
On peux comprendre le responsable Debian qui souhaite avoir le source le plus "source" possible et que ça soit le plus adapté possible à Debian.
Mais d'un autre côté, le but d'un dev c'est que ça soit utilisé facilement par ses utilisateurs et que ça soit simple à maintenir. Or, bien souvent, les demandes des packageurs font que ça sera plus complexes à maintenir sans vrai intérêt pour l'utilisateur (autre que le fait d'avoir une debian super propre à coup sûr, ce qui est déjà un bon point il est vrai).
Je trouve donc normal que certains n'aient juste pas le temps ni l'envie de rentrer dans un système si complexe et contraignant. Là encore je ne critique pas Debian, car pour atteindre leur niveau de qualité de leur distribution ils n'ont gère le choix.
C'est juste que pour les projets ça ne vaux pas tout le temps le coût, il ne faut donc pas s'étonner que beaucoup de projets proposent leur repo dans leur coin et laisse des versions ultra vieilles de leurs outils dans les repo des distributions.
Est-ce que sincèrement quelqu'un croit encore à l'avenir de "gros" serveurs quand les applications (vous savez, le truc réellement important au final) s'orientent massivement vers une scalabilité horizontale sans limite? Nos chers gros de l'internet font tous avec de petits serveurs jetables plutôt que des gros. Or leurs techniques sont de plus en plus reprisent par les sociétés "normales" (genre cac40 and co).
On est à l'air de l’élastique, avec des instance qui viennent et repartent. On a tous les outils pour. Seules certaines grosses applications d'entreprise (comprendre: usine à gaz) ne savent pas gérer cette logique (il faut voir ce qu'il faut faire pour juste rajouter un simple nœud applicatif à un ERP Oracle…).
Est-ce que ce processeur est techniquement génial? oui. Est-ce qu'il sera acheté par quelques gros groupes historiques? Oui sûrement. Est-ce qu'il va s'implanter largement et changer l'orientation du marché? Certainement pas.
Tout à fait d'accord. Qu'on soit d'accord avec lui ou pas techniquement ne justifie de toute manière en rien qu'on le critique sur sa personne et encore moins qu'on s'en prenne à son intégrité physique.
Il est également vrai que bien souvent ceux qui l'ouvrent le plus grand sont ceux qui en ont fait le moins. Une simple raison serait qu'ils sont restés dans leur joli monde rêvé et ne sont jamais descendu au niveau de la triste réalité et des concessions qu'elle demande?
Autre point qu'on ne saurait répéter encore et encore: ils ne sont pas content de systemd? Ils en font un autre à leur goût! On ne les force pas à l'utiliser. On ne force en rien de rester sur la même distribution encore et encore. Si ça les choque vraiment, ils changent. Si ça ne les choquent pas à ce point ils font avec.
disclaimer: je n'aime pas la complexité apparente de systemd (jamais eu le temps de vraiment creuser le sujet). Mais jamais je n'irais dire à un mainteneur de choisir autre chose (c'est son taf) et encore moins dire à l'auteur d’arrêter de coder (de quel droit?). Si ça me gênait vraiment je ferais les efforts pour apprendre systemd ou maintenir un autre init (mais je n'ai ni le temps ni les compétences sur ce point là je pense :) ).
Merci pour ce journal qui s'attaque à une problématique du bon côté, ça change des guerres trollifères. Bon au final certains vont quand même, malgré tes efforts, réussir à réorienté les commentaires vers la guerre idéologique systemd.
Je n'avais vraiment, mais vraiment, pas envie de creuser sur systemd jusqu'à maintenant, mais là ton post m'a titillé la curiosité.
Je suis d'accord sur le côté politique de la chose. C'est un écosystème linux qui est en marche. Bien ou mal, ça restera totalement subjectif et dépendant de l'utilisation que l'on fait de linux ou des outils qui souhaitent le gérer lui en priorité. Bref, pas la peine de lancer un débat là dessus qui ne peux pas avoir de vérité absolue.
Ce site à service gratuit ferme car il n'a cependant pas trouvé de modèle économique viable
ça résume assez bien pourquoi ça ferme je pense. Est-ce qu'on sait quel business model ils avaient prévu? Je n'ai pas cherché pendant des heures non plus, mais je ne trouve rien sur leur site quand à une offre payante ou une question limitation faite pour pousser à payer.
Ca allège le soucis oui, mais c'est loin de régler correctement la maintenance. C'est ce qu'on fait dans les outils genre Nagios ou Shinken par exemple, la notion de groupes de contacts (aka ~profile). Mais ça reste très complexe quand tu as plusieurs milliers d'équipements sur X datacenters chacun avec ses équipes, et donc les éléments ont des métriques qui ne doivent être vue que par une partie des équipes (genre le infos systèmes par les sysadmin, les métriques oracle par les dba, etc etc).
Donc le mapping est vraiment d'un ordre de grandeur monstrueux si tu veux le maintenir à la main (infaisable dans les faits sur de grosses infras). Tu as donc aussi besoin de profile/groupe sur tous tes éléments (que ce soit les serveurs, c'est presque "facile", mais aussi sur tous les métriques qu'ils ont, et là c'est chaud).
Pour l'avoir géré dans Shinken (groupes, héritages de templates and co), je les comprends parfaitement de ne PAS s’embêter avec ça. Quand on voit que malgré ce manque énorme les outil sont quand même déployés chez de gros utilisateurs, tu relativise beaucoup l'importance de l'énormité du manque en fait :p
En gros la partie chiffrement et auth doit être gérée par un élément tiers, mais si l'appli reçoit comme information l’identité (vérifiée) alors elle doit l'appliquer comme un filtre supplémentaire.
Le vrai soucis c'est pas trop de ce côté de la connexion en fait, car ça se fait assez bien peu importe le backend http utilisé. Mais ce qui est vraiment problématique pour les concepteurs c'est que ceci signifie qu'il faut avoir un mapping user<->objets, et ça à définir/maintenir c'est déjà rude d'un point de vue conceptuel, mais en plus ça va demander sûrement la création d'une UI de configuration et gestion. Or c'est pas vendeur lors d'un test pour attirer l'utilisateur, donc ils préfèrent laisser ça à plus tard :)
J'avoue être du même avis. Toute les couches d'auth et de sécurisation devraient être factorisées plutôt que réimplémentées par chaque outil (avec ses failles potentielles). Quand on parle d'application web mettre un frontal pour gérer le https correctement est pas si mal par exemple, surtout que tu factorise tes connaissance et tes configurations entre les X outils, plutôt que voir comment on gère sur chacun.
On peut difficilement faire plus moche si c'est pour de la génération de graph, surtout que ça fait des images statiques, pas des graphiques dynamiques :p
Le meilleur que j'ai trouvé pour switcher depuis highchart c'est justement nvd3. De base son style est moche, mais bon doit y avoir moyen de backporter un thème potable.
Sinon il a même des features similaires à highstocks (avec la version réduite du graph sur le bas pour le "zoom"). Et là plus de soucis de licences :p
Ce projet a l'air très intéressant et déjà bien documenté, bravo :)
Mais (y a toujours un mais…) j'ai juste une question sur l'utilisation de la lib Highcharts pour les graphs. Si je ne m'abuse, cette lib n'est pas libre (cf www.highcharts.com/license) et gratuite que pour une utilisation non commerciale.
Les personnes non averties qu'elles ont besoin d'une licence Highcharts se retrouveraient donc dans l'illégalité s'ils présentent une UI facette à leur clients par exemple, même si Facette est en BSD.
Même si j'avoue que je suis aussi un grand fan de cette lib, est-ce que pour un outil libre, que l'on souhaite utilisable par tout le monde sans risque d'avocat and co, ne serait-il pas préférable de switcher vers un équivalent genre http://nvd3.org/ (avec un petit re-stylage car de base c'est moche…).
Bravo en tout cas pour le projet, ça donne envie d'aller creuser dans ses métriques :D
Oui, quand ça impacte la compréhension, et donc le fond, je suis pour un rappel, hors de question d'arriver au langage SMS également (peu d'effort pour un qui écrit, mais beaucoup pour tous ceux qui lisent).
Mais comme tu dis la limite est pas facile à placer. Juste que là je crois que vu le nombre de commentaires autour de points de détails qui n'apportent rien au fond du sujet, un simple rappel des modérateurs sur le fait qu'aller trop loin dans ce sens est juste contre productif pour le bien de la communauté (on perds des membres, et le plus souvent les plus expérimentés qui ont autre chose à faire que passer leur temps sur un détail de forme).
[^] # Re: Installation
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 2.4. Évalué à 6. Dernière modification le 21 mai 2015 à 07:08.
Heu depuis la 2.0 (donc je dirai plus d'un an facilement) pour l'upstream c'est par pip ou setup.py en local. Tu ne serais pas tombé sur le vieux wiki (supprimé depuis) marqué en deprecated tout gros sur la page principale? :) (ta remarque sur debian fraîche me fait penser que si).
Sinon des paquets sont disponibles sur Fedora/RH depuis… heu disons sacrément longtemps (la 1.0 je crois mais je peux me tromper), grâce au travail de hvad. Debian ça a pris plus de temps car… disons que c'est debian donc c'était autrement plus long :)
Plus sérieusement, un outil de supervision ça prendra de toute manière plus de 4h pour en mesurer l'efficacité. L'installation des outils c'est toujours relativement facile (quand on prends la bonne doc ;) ) mais la partie configuration là ça se corse, car tout le monde a des besoins très différents en la matière et l'adaptation à ses besoins bah… c'est pas forcément trivial ^
Si en 2h tu as fait le tour de tes besoins, c'est qu'ils étaient relativement simples, et dans ce cas je conseille le relativement méconnu (à tort) Sensu. Son scope est de l'ordre de 10% d'un Nagios ou d'un Shinken a fortiori, mais c'est bien plus accessible ┗(＾0＾)┓
[^] # Re: copyright et fork
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 2.4. Évalué à 5.
C'est indiqué dans la news ;)
[^] # Re: copyright et fork
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 2.4. Évalué à 2.
Sincèrement même si t'en manques un ou deux je pense pas qu'on vous jettera la pierre. C'est qu'il y a un peu beaucoup de fichiers quand même :)
[^] # Re: copyright et fork
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 2.4. Évalué à 2.
En fait c'est plus un rajout qu'un remplacement (cf https://github.com/Alignak-monitoring/alignak/pull/5/files), ils ne suppriment pas l'ancien header. Après ce n'est pas leur premier fork, je pense qu'ils savent ce qui se fait. Donc j'ai pas de crainte de ce côté là :)
# Mauvais clients
Posté par Jean Gabes (site web personnel) . En réponse au journal techos bradés. Évalué à 10.
Le vrai soucis (en tout cas une part importante) ce sont les clients je pense. Pourquoi on France on a une armée de SSII et aux US des éditeurs? Les fonds pour se développer aident à ça oui sans l'ombre d'une hésitation, mais un client français va te demander le prix en 1ère question, alors que l'américains va te demander le ROI. Çà ne motive pas à mettre tes forces dans la technique et donc l'excellence :)
# Hum...
Posté par Jean Gabes (site web personnel) . En réponse au journal Code libre/oss : offre proprio ?. Évalué à 3.
Et tu as une idée géniale de modèle qui marche dans la vraie vie donc? ^
En fait la question 1 est relativement mal posée. Il y a de grosses disparités entre les marchés. Tu remarqueras qu'entre la France où le critère N°1 est le prix et les US où la première question qu'on te pose c'est le ROI, je te laisse deviner quels sont les modèles avec lesquels les sociétés débutent de chaque côté de l'atlantique ^
Pour la question 3: sincèrement en France non, seul le prix va importer dans une grande majorité de cas, et l'open source a la un atout majeur: c'est sans licence payante. Soucis: c'est la plupart du temps installé et mis en place sans aucun retour (ni financier ni de code) à l'équipe qui code. Ça ne marche qu'un temps ce modèle (hors levée de fond pour faire du buzz et monter une offre dérivée type SaaS ou Enterprise, mais on en revient au cas 1).
# Trivial avec du proprio, mais pas impossible avec du libre
Posté par Jean Gabes (site web personnel) . En réponse au journal Superfish ou: j'ai rien compris au logiciel propriétaire. Évalué à 10.
Je suis d'accord que le côté privatif/fermé fait que c'est facile à mettre en place sur un écosystème privatif, mais je pense que c'est tout à fait faisable côté libre.
Ah ça on pourra le voir, on est d'accord. Mais dans les faits combien "regardent"? Est-ce que tous, et je dis bien tous, les paquets compilés dans les distribs sont relus par un comité de plusieurs personnes, et avec un comité qui change régulièrement? Si par exemple un paquet installé par défaut est géré par 1 ou deux personnes, qu'est ce qui empêche ces personnes de se faire corrompre et mettre un tel certificat en douce?
C'est un peu comme l'histoire d'OpenSSL: oui tout le monde peut relire, mais dans les faits combien le font vraiment?
Sincèrement je serais étonné que ça ne soit déjà pas le cas et que si on faisait un audit 100% d'une distro en phase de compilation on ait pas une petite surprise par ici ou par là. Si j'étais à la NSA c'est ce que je proposerai en tout cas :) (genre je sais pas affaiblir avec un patch la création d'entropie de certificats SSL ou ce genre de choses :D ).
[^] # Re: Les conteneurs
Posté par Jean Gabes (site web personnel) . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 6.
Ah j'avais cru comprendre que c'était en parallèle et non pas en réutilisant nftable. Techniquement c'est déjà moins lourd, même si sur le fond ça fait que tu as quand même deux endroits/manières de gérer ton firewall.
Systemd tente quand même d'unifier pas mal de points en un tout cohérent, ce n'est pas rien. Ensuite s'il est facile de déboîter une brique pour en mettre une autre à la place ça bien. Genre ici ce qu'il ne faut pas c'est que du doive obligatoirement passer par la définition des services pour gérer la partie réseau de tes daemons. Si ça repose sur des briques/lib communes, tu peux avoir 80% des cas gérés avec systemd, et les 20% derniers avec des briques plus adaptés/spécifiques :D
Je pense que son soucis c'est qu'il a été vu comme un "simple" serveur d'init. Or c'est une sorte de middleware pour l'OS. C'est plus à comparer avec la libc qu'avec un systemV au final. Bon après il a du démarrer comme un init et évoluer vers ça.
[^] # Re: Les conteneurs
Posté par Jean Gabes (site web personnel) . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 10.
Bon en fait les conteneurs systemd les a déjà: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html …..
[^] # Re: Les conteneurs
Posté par Jean Gabes (site web personnel) . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 8.
Ah oui ça change :p
Ça mets aux oubliette les principes unix une telle vision (quoi que chaque conteneur faisant son travail spécifique, et systemd étant là pour faire le pipe c'est pas non plus orthogonal avec unix en fait… juste à 89° ^ ).
Ensuite faut pas se leurrer, on s'oriente de plus en plus vers des systèmes applicatifs jetables une fois instanciés (l'image et la manière dont on orchestre les images est ce sur quoi on travaille, les instances non). EC2 a ouvert la voie, Docker renfonce le clou avec son écosystème (peu importe ce qu'on pense prod/pas prod, la question n'est pas là, si c'est pas lui ça sera un autre qui arrivera à la prod). On est plus qu'incité avec les outils qu'on a à notre disposition de bâtir de manière quasi-automagique notre infra. Or arrivé à ce niveau là, on n'a plus trop besoin d'avoir un init à la systemd pour lancer X services sur le même serveur, mais plutôt de lancer X boites sur X serveurs hôtes différents qui échangeront ensemble à travers un réseaux bâti lui aussi de manière quasi-automagique.
Bien? Mal? Sincèrement je ne sais pas. De plus peu être que finalement seule une minorité d'admins en aura besoin réellement d'un tel système, et que la majorité restera avec le bon vieux système de VM installée à la main.
Je pense que personne n'est naïf au point de croire que systemd est juste là pour faire plaisir à ses développeurs, et que lorsqu'ils rajoutent un pan à leur outil c'est juste pour avoir ds lignes de code à entrer dans leur emacs/vi/nano/notepad (rayé la mention inutile). C'est leur taf, pas leur hobbie, il y a une raison économique derrière. Ainsi lorsque je m'amuse à extrapoler les avancées des différents outils ça donne ça, ensuite rien ne dit qu'une autre organisation que redhat n'a pas autre chose dans les cartons :) (je pense tout particulièrement à google, facebook ou amazon, qui ont l'air de ne pas attendre que des éditeurs leur fournissent les outils centraux de leur SI).
Ou alors je me trompe complètement et Lennart c'est juste un grand curieux qui veut toucher à tous les domaines d'un OS ^ ^
# Les conteneurs
Posté par Jean Gabes (site web personnel) . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 10.
Je prends le pari sur une implémentation de conteneurs à la docker. Après tout les cgroups ils savent faire aussi. Un intérêt serait par exemple d'avoir une unique distribution "systemd" qui lance des applis d'autres distributions dans leur propre conteneur.
De là à penser qu'ensuite une intégration poussée entre openstack et ces hyperviseurs systemd rendrait la plateforme redhat parfaitement adaptée et surtout centrale…
Pour en revenir à des sujets moins trollesque (et encore), c'est pas complètement stupide de laisser à systemd le soin de gérer les flux et les redirections. En effet ça peut être lié à un service (genre un service apache ou un load balanceur?), mais ça signifie qu'il va falloir réimplémenter tout iptable/nftable pour que ce soit viable (deux systèmes qui se marchent dessus ça ne fonctionne jamais bien longtemps sur un système). Le coût me parait gros à vrai dire.
On pourrait presque demander ce qui ne va pas dépendre de systemd en fait, car s'il gère les services et la pile réseaux, restera les filesystems et la gestion de version des données dessus.
A la limite ce qui serait bien c'est que systemd nous sorte un gestionnaire de paquet qui soit pris d'office partout (ce qui serait quasiment ait s'ils font des conteneurs). Là ça serait un vrai changement majeur et un bénéfice non négligeable je trouve :)
# Compréhensible dans les deux sens
Posté par Jean Gabes (site web personnel) . En réponse au journal Pourquoi vous ne devriez pas packager vous-même votre logiciel pour Debian ?. Évalué à 6.
On peux comprendre le responsable Debian qui souhaite avoir le source le plus "source" possible et que ça soit le plus adapté possible à Debian.
Mais d'un autre côté, le but d'un dev c'est que ça soit utilisé facilement par ses utilisateurs et que ça soit simple à maintenir. Or, bien souvent, les demandes des packageurs font que ça sera plus complexes à maintenir sans vrai intérêt pour l'utilisateur (autre que le fait d'avoir une debian super propre à coup sûr, ce qui est déjà un bon point il est vrai).
Je trouve donc normal que certains n'aient juste pas le temps ni l'envie de rentrer dans un système si complexe et contraignant. Là encore je ne critique pas Debian, car pour atteindre leur niveau de qualité de leur distribution ils n'ont gère le choix.
C'est juste que pour les projets ça ne vaux pas tout le temps le coût, il ne faut donc pas s'étonner que beaucoup de projets proposent leur repo dans leur coin et laisse des versions ultra vieilles de leurs outils dans les repo des distributions.
[^] # Re: Et la crémière
Posté par Jean Gabes (site web personnel) . En réponse au journal Marre des popups qui obligent à accepter les cookies. Évalué à 5.
On gagnerait du temps à lister quel nouveaux projets vont sur sourcefore et qui y est encore non?
# Concentration?
Posté par Jean Gabes (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 8.
Est-ce que sincèrement quelqu'un croit encore à l'avenir de "gros" serveurs quand les applications (vous savez, le truc réellement important au final) s'orientent massivement vers une scalabilité horizontale sans limite? Nos chers gros de l'internet font tous avec de petits serveurs jetables plutôt que des gros. Or leurs techniques sont de plus en plus reprisent par les sociétés "normales" (genre cac40 and co).
On est à l'air de l’élastique, avec des instance qui viennent et repartent. On a tous les outils pour. Seules certaines grosses applications d'entreprise (comprendre: usine à gaz) ne savent pas gérer cette logique (il faut voir ce qu'il faut faire pour juste rajouter un simple nœud applicatif à un ERP Oracle…).
Est-ce que ce processeur est techniquement génial? oui. Est-ce qu'il sera acheté par quelques gros groupes historiques? Oui sûrement. Est-ce qu'il va s'implanter largement et changer l'orientation du marché? Certainement pas.
[^] # Re: Lennart Poettering trouve la communauté Linux désagréable
Posté par Jean Gabes (site web personnel) . En réponse au journal Lennart Poettering trouve la communauté Linux désagréable. Évalué à 10.
Tout à fait d'accord. Qu'on soit d'accord avec lui ou pas techniquement ne justifie de toute manière en rien qu'on le critique sur sa personne et encore moins qu'on s'en prenne à son intégrité physique.
Il est également vrai que bien souvent ceux qui l'ouvrent le plus grand sont ceux qui en ont fait le moins. Une simple raison serait qu'ils sont restés dans leur joli monde rêvé et ne sont jamais descendu au niveau de la triste réalité et des concessions qu'elle demande?
Autre point qu'on ne saurait répéter encore et encore: ils ne sont pas content de systemd? Ils en font un autre à leur goût! On ne les force pas à l'utiliser. On ne force en rien de rester sur la même distribution encore et encore. Si ça les choque vraiment, ils changent. Si ça ne les choquent pas à ce point ils font avec.
disclaimer: je n'aime pas la complexité apparente de systemd (jamais eu le temps de vraiment creuser le sujet). Mais jamais je n'irais dire à un mainteneur de choisir autre chose (c'est son taf) et encore moins dire à l'auteur d’arrêter de coder (de quel droit?). Si ça me gênait vraiment je ferais les efforts pour apprendre systemd ou maintenir un autre init (mais je n'ai ni le temps ni les compétences sur ce point là je pense :) ).
# Enfin un journal sur systemd bien orienté
Posté par Jean Gabes (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 10.
Merci pour ce journal qui s'attaque à une problématique du bon côté, ça change des guerres trollifères. Bon au final certains vont quand même, malgré tes efforts, réussir à réorienté les commentaires vers la guerre idéologique systemd.
Je n'avais vraiment, mais vraiment, pas envie de creuser sur systemd jusqu'à maintenant, mais là ton post m'a titillé la curiosité.
Je suis d'accord sur le côté politique de la chose. C'est un écosystème linux qui est en marche. Bien ou mal, ça restera totalement subjectif et dépendant de l'utilisation que l'on fait de linux ou des outils qui souhaitent le gérer lui en priorité. Bref, pas la peine de lancer un débat là dessus qui ne peux pas avoir de vérité absolue.
# Prévisible?
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Fermeture du site Fotopedia. Évalué à 2.
C'est vraiment dommage, mais :
ça résume assez bien pourquoi ça ferme je pense. Est-ce qu'on sait quel business model ils avaient prévu? Je n'ai pas cherché pendant des heures non plus, mais je ne trouve rien sur leur site quand à une offre payante ou une question limitation faite pour pousser à payer.
[^] # Re: Alternatives
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Facette, outil de visualisation de séries numériques. Évalué à 4.
Ca allège le soucis oui, mais c'est loin de régler correctement la maintenance. C'est ce qu'on fait dans les outils genre Nagios ou Shinken par exemple, la notion de groupes de contacts (aka ~profile). Mais ça reste très complexe quand tu as plusieurs milliers d'équipements sur X datacenters chacun avec ses équipes, et donc les éléments ont des métriques qui ne doivent être vue que par une partie des équipes (genre le infos systèmes par les sysadmin, les métriques oracle par les dba, etc etc).
Donc le mapping est vraiment d'un ordre de grandeur monstrueux si tu veux le maintenir à la main (infaisable dans les faits sur de grosses infras). Tu as donc aussi besoin de profile/groupe sur tous tes éléments (que ce soit les serveurs, c'est presque "facile", mais aussi sur tous les métriques qu'ils ont, et là c'est chaud).
Pour l'avoir géré dans Shinken (groupes, héritages de templates and co), je les comprends parfaitement de ne PAS s’embêter avec ça. Quand on voit que malgré ce manque énorme les outil sont quand même déployés chez de gros utilisateurs, tu relativise beaucoup l'importance de l'énormité du manque en fait :p
[^] # Re: Alternatives
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Facette, outil de visualisation de séries numériques. Évalué à 4.
Tout à fait juste.
En gros la partie chiffrement et auth doit être gérée par un élément tiers, mais si l'appli reçoit comme information l’identité (vérifiée) alors elle doit l'appliquer comme un filtre supplémentaire.
Le vrai soucis c'est pas trop de ce côté de la connexion en fait, car ça se fait assez bien peu importe le backend http utilisé. Mais ce qui est vraiment problématique pour les concepteurs c'est que ceci signifie qu'il faut avoir un mapping user<->objets, et ça à définir/maintenir c'est déjà rude d'un point de vue conceptuel, mais en plus ça va demander sûrement la création d'une UI de configuration et gestion. Or c'est pas vendeur lors d'un test pour attirer l'utilisateur, donc ils préfèrent laisser ça à plus tard :)
[^] # Re: Alternatives
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Facette, outil de visualisation de séries numériques. Évalué à 6.
J'avoue être du même avis. Toute les couches d'auth et de sécurisation devraient être factorisées plutôt que réimplémentées par chaque outil (avec ses failles potentielles). Quand on parle d'application web mettre un frontal pour gérer le https correctement est pas si mal par exemple, surtout que tu factorise tes connaissance et tes configurations entre les X outils, plutôt que voir comment on gère sur chacun.
[^] # Re: Intéressant mais quid de Highcharts et sa licence?
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Facette, outil de visualisation de séries numériques. Évalué à 3.
On peut difficilement faire plus moche si c'est pour de la génération de graph, surtout que ça fait des images statiques, pas des graphiques dynamiques :p
[^] # Re: Intéressant mais quid de Highcharts et sa licence?
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Facette, outil de visualisation de séries numériques. Évalué à 3.
Le meilleur que j'ai trouvé pour switcher depuis highchart c'est justement nvd3. De base son style est moche, mais bon doit y avoir moyen de backporter un thème potable.
Sinon il a même des features similaires à highstocks (avec la version réduite du graph sur le bas pour le "zoom"). Et là plus de soucis de licences :p
# Intéressant mais quid de Highcharts et sa licence?
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Facette, outil de visualisation de séries numériques. Évalué à 8.
Ce projet a l'air très intéressant et déjà bien documenté, bravo :)
Mais (y a toujours un mais…) j'ai juste une question sur l'utilisation de la lib Highcharts pour les graphs. Si je ne m'abuse, cette lib n'est pas libre (cf www.highcharts.com/license) et gratuite que pour une utilisation non commerciale.
Les personnes non averties qu'elles ont besoin d'une licence Highcharts se retrouveraient donc dans l'illégalité s'ils présentent une UI facette à leur clients par exemple, même si Facette est en BSD.
Même si j'avoue que je suis aussi un grand fan de cette lib, est-ce que pour un outil libre, que l'on souhaite utilisable par tout le monde sans risque d'avocat and co, ne serait-il pas préférable de switcher vers un équivalent genre http://nvd3.org/ (avec un petit re-stylage car de base c'est moche…).
Bravo en tout cas pour le projet, ça donne envie d'aller creuser dans ses métriques :D
[^] # Re: Pas CLI
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Sortie de Glances version 2.0. Évalué à 2.
Si tu veux faire des requêtes de supervision le REST est tout à fait adapté, websocket certainement pas :)
[^] # Re: Pas CLI
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Sortie de Glances version 2.0. Évalué à 3.
Oui, quand ça impacte la compréhension, et donc le fond, je suis pour un rappel, hors de question d'arriver au langage SMS également (peu d'effort pour un qui écrit, mais beaucoup pour tous ceux qui lisent).
Mais comme tu dis la limite est pas facile à placer. Juste que là je crois que vu le nombre de commentaires autour de points de détails qui n'apportent rien au fond du sujet, un simple rappel des modérateurs sur le fait qu'aller trop loin dans ce sens est juste contre productif pour le bien de la communauté (on perds des membres, et le plus souvent les plus expérimentés qui ont autre chose à faire que passer leur temps sur un détail de forme).
J'ouvre un ticket dans le suivi donc :)