Je n'avais pas connaissance de leur fin mais en les lisant oui c'est exactement ça. Plus je regarde, plus je me dis que marketing $ + tutoriaux triviaux en 5min sont la clé, là où un produit fini (par exemple les soucis de sharding tu tombes pas dessus lors d'un tuto…) ne sera pas pris car moins "vendeur".
Ensuite ce modèle marche pour écraser le marché "gratuit" et faire assoir sa marque, mais pour monétiser par la suite il faut régler de vrais soucis de sociétés (là encore, c'est souvent pas des problèmes techniques qu'il faut régler, mais par exemple gérer les droits de base depuis ldap sera plus important qu'un sharding parfait).
En résumé et avec une certaine ironie: si les experts techniques sont d'accord pour dire que ton outil est le plus puissant du marché: tu fonces droit vers ta perte, bravo…
Tu n'as pas expliqué le lien de cause à effet.
Si l' "artisan" (l'un l'est, pas l'autre? Quelle différence?) n'a pas su convaincre celui qui possède les 81M$ que sa base était meilleure pour commencer à investir que de partir de 0, peut-être que c'est juste que c'était pas bien fait (en imaginant que l'artisan n'a pas caché volontairement dans son coin sa travail pour se plaindre ensuite de ne pas avoir été vu)?
En effet j'ai pas creusé. Ici le cas est un peu symptomatique, car ils ont pu avoir 81M$ car ils avaient déjà eu une réussite avant, ce n'était pas inné et magique avec leur plan mongodb (même s'il était forcément bon et équilibré, car tu ne donnes pas 81M$ dans le vide).
Ce que je voulais mettre en avant c'était le fait que de toute manière les dés vont être pipés dès le début, et qu'en terme de moyens il y a juste un problème d'échelle. Il faudrait avoir le produit parfait sur une niche ultra visible/hype à une équipe reteinte -aka mes artisans mais on va revenir sur le terme qui t’irrite on dirait :) -
L'un n’empêche pas l'autre, du moment où des gens sont intéressés. Si l'un meurt, c'est juste qu'il n'y avait pas de gens intéressés et qu'il y avait mieux ailleurs. En quoi est-ce mal?
Est-ce mal? Non. Je dirai dommage pour l'équipe resteinte, mais c'est la règle du jeu, et de toute manière la masse aura un produit fini avec le gros éditeur. Donc non, ce n'est pas un mal. (je laisse de côté la partie "politique" sur le fait que dans ce cas le capital va gagner à tous les coup, c'est pas le point ici, je veux juste me placer d'un point de vue end user qui a ce qu'il souhaite).
Ce qui est 100% normal, tout le monde n'étant pas masochiste.
A te lire, je sens que tu y vois un mal, est-ce faux? Si non, pourquoi?
Je me suis mal fait comprendre alors: non ce n'est pas un mal. Comme tu dis on est pas des masochistes, et si je peux avoir facilement et d manière agréable ce que je souhaites, je vois pas pourquoi je prendrais une autre solution rude et pas claire. (là encore je laisse de côté la politique et donc le fait que c'est libre blablabla, là on parle de end user, les licences ils s'en fichent jusqu'au jour où leurs données sont affichées dans la nature).
N'importe quoi : un artisan, il sait aussi faire du joli et ergonomique. C'est une choix personnel de la personne.
Le terme n'était pas bon, meaculpa je le reprends. En plus tu donnes une bonne définition juste en dessous:
c'est plutôt la différence entre les gens voulant faire que ce qui leur plait (mais qu'on les paye pour ça) et ceux sachant trouver un équilibre entre la technique et la demande des utilisateurs.
Exact.
Là où je ne suis pas totalement d'accord c'est qu'en fait la technique ne dois pas entrer en ligne de compte et que seul les demandes utilisateurs doivent compter au final. La technique ne doit être prise en compte que pour répondre sur la faisabilité et le temps que ça va demander (donc au final le prix).
Et c'est peut être bien là le point névralgique du truc: la plupart des projets qui réussissent ne sont pas technique (ou alors uniquement à la marge) et que ça va impliquer une barrière d'entrée très forte.
Docker? une superbe intégration de principes qui existaient depuis des années (containers + repository externes), aidée par la hype autour de go.
Mongodb? de simples objets json requétables, avec du distribués qui utilise du sharding sur clé. Rien de bien révolutionnaire dans les BDD, mais ultra facile à utiliser, superbement documenté et avec dès le début une myriades de lib pour les langages importants.
Qui tente de mettre un mysql en cluster? juste les fous. Par contre le faire avec un mongodb ça va, car ça parait plus facile (alors que bon au final les soucis de l'uns l'autres les aura).
Ils sont très bons. Et ce qu'ils vendent ce n'est pas de la technique, mais une très bonne connaissance de leur (potentiels) clients et leur attentes/points qui font mal.
Le modèle fonctionne, les utilisateurs finaux ont quelque chose qui leur parle et qui est simple à utiliser. Par contre ça demande un investissement marketing/édition (doc & ergonomie & outils divers, donc beaucoup de $ au final car il faut bien payer ses employés).
De base mon avis est que "recruter gratuitement" des contributeurs c'est faisable si tu es sur un domaine de recherche et/ou hautement technique. Par contre une fois la phase de recherche/exploration finie, là c'est mission impossible (il n'y a qu'à voir combien de designer il y a dans le monde open source par rapport aux dev).
Je suis d'accord avec toi, certaines petites équipes peuvent faire ultra ergonomique (il n'y a qu'à voir les jeux indépendants), mais reconnait que ce n'est pas la norme quand on parle d'outil Open Source fait par des petites équipes par hobby (car là c'est le défi technique qui prime).
Ma conclusion personnelle est donc de base le modèle collaboratif sera plus naturel sur les nouveaux domaines.
Par contre une fois le domaine dépoussiéré, là le modèle collaboratif s’effondre (ou a minima diminue de plusieurs ordres de grandeurs) faute de personnes pour le faire vivre. Ici les éditeurs prennent le lead car ils peuvent offrir une contrepartie aux contributeurs autre que la gloire: un salaire :D
A titre personnel je passe encore mes soirées à diminuer le nombre de malloc de mon code et d'aligner au mieux mes structures, car c'est un défi qui m'amuse. Mais je dois bien le reconnaître: aucun client ne me paiera pour ça, donc cette activité restera un hobby.
Tout le monde pourrait vivre tranquillement avec cette équation, mais le fait que les éditeurs investissent de plus en plus tôt la sphère de recherche/dev (merci l'argent des investisseurs) fait que les équipes réduites sont repoussées encore et encore vers des niches toujours plus petites.
Ce n'est pas très "juste" pour elles (les équipes réduites), mais j'ai dit qu'on laissait le côté "politique" de côté, et d'un point de vue end-user les éditeurs leur apportant ce qu'elles veulent (et gratuitement pour les premières versions en prime, le temps de comprendre le marché et faire connaitre leur marque), les équipes réduites n'ont plus d'intérêt. (Aller rapidement pour le côté politique car certains vont se sentir floué: leur place n'est-elle pas dans la recherche publique alors?).
Ce n'est cependant pas prêt de s’arrêter concernant la marketisation. Il y a un effet ciseau qui va amplifier encore plus ça dans les années à venir.
Côté "offre": l'open source est un marketing pas trop cher. Donc beaucoup d'éditeur commencent pas là afin de limiter leur frais de marketing, et ensuite faire leur travail d'éditeur (vendre de la licence sur une version plus simple ou plus puissante).
La concurrence entre les projets artisanaux et les projets de sociétés sont biaisés au possibles. Si tu prends par exemple Mongodb: ils ont commencé avec 81M$ en banque. Fin du game pour un courageux artisant en face. Ils peuvent se payer un site et une doc, ils peuvent payer une 30aine de tech evangelist pour écumer les conférences dans tous les pays. Et donc ils gagnent (cf point sur la demande).
Côté demande: là encore ça a changé drastiquement avec les années. Oui il y a toujours des hackers qui adorent bidouiller (dans le sens noble du terme) et découvrir:faire des choses par eux même. Mais faut pas se leurrer: ils sont une minorité (10%? grand max).
La majorité des personnes va aller consommer des solutions faites par d'autres. Oui ils vont monter leur infra, mais l partie "création" va être ultra limitée, car tout simplement ils n'en ont pas besoin (pas d'offances ici, c'est juste pas leur job ou leur besoin dans leur taf).
Si tu propose un outil avec un site joli, une doc sous forme de tuto, une cohérence globale bien pensée (aka: ce sont des éditeurs, c'est leur taf de garantir une cohérence) avec un design pas trop moche, bah l'outil de l’artisan peux être bien meilleur sur la théorie, il perds. Car il est inaccessible au commun des mortel (non personne n'aime lire 500 pages de doc, un tuto à la limite, mais pas plus).
Les téléphones portables et leur interface ultra accessible à fait des dégâts: la majorité des utilisateurs avancés (dont on parle ici) veulent la même puissance ergonomique dans leur métier de tous les jours. Et non, un artisan ne mets pas ç a en avant (lui mets la puissance et la complétude, c'est théoriquement génial, mais inutile et inaccessible pour 90% des utilisateurs).
Conclusion: faut faire avec, il y aura toujours un monde de hackers et un monde de la masse. Les premiers explorent, inventent, mais ce qu'ils vont est inaccessible pour les seconds. Et là les éditeurs arrivent pour packager/enrober les trouvailles des premiers et permettre aux utilisateurs finaux d'en profiter aussi.
Le temps que les seconds ne limitent pas la recherche/exploration des premiers (oui je vise les brevets), alors finalement le modèle marche pas si mal, sauf si l’artisan souhaitait vivre de son hobby juste en faisant son art. Ce modèle là est mort ou tend à mourir à terme pour sûr (sauf marché de niche jusqu'à ce que les utilisateurs normaux en aient besoin, là on relance le cycle).
J'y ais pensé à une époque à étendre le scope, genre booster les temps d’exécutions, permettre des retours plus larges et complexes (log etc etc) car on a une grosse partie du scope.
Mais bon je pense que ce qui pèche en général sur les outils d'ordonnancements c'est pas trop l'éxécution, mais bien la gestion finae du workflow de tes actions (genre éviter de passer par des fichier plat pour gérer les flags d'éxécutions à la minimine dans les scripts ).
Or là je peux pas apporter grand chose sur ce point, et j'avais pas fait le tour de la supervision (j'ai toujours pas fini d'en faire le tour d'ailleurs ).
Mais je ne serai pas étonné que quelqu'un un jour fork Shinken pour en faire un outil d'ordonnacement. Ca serait même bien :) Reste que il faudra lui donner un UI de configuration des jobs qui sera à la hauteur, et c'est là que ça va devenir complexe. D'expérience, faire un moteur c'est facile, mais une UI intuitive et qui aide les utilisateurs, là c'est une autre paire de manche :D
Pour Shinken oui c'est plutôt orienté sur les gros parc en effet ^
Tu as regardé du côté de Sensu? c'est plutôt light? (enfin surtout côté feature de mon point de vue, mais étant l'auteur de Shinken disons que mon point de vue sur les feature minimale d'un outil n'est pas forcément le même que d'autres ).
Sinon je pense qu'on peux aussi détourner un Consul de son rôle premier, mais là c'est peu être moins pratique. A voir.
Non là le soucis c'ets qu'en gros quelqu'un va pouvoir envoyer des arguments à tes commandes. Genre potentiellement des ">/dev/null;echo "myssh" >> .ssh/authorized_keys2". Et là…..
En plus, nrpe est vraiment limité en terme de protocole, surtout sur la taille du buffer récupéré ( à une époque c'était 1024o compilé en hard, ça a peu être changé mais purée ce que c'était petit…).
Bon je passe sur le fait que le "SSL" dedans n'est pas le meilleur en soit (genre tu peux oublier avoir une véritable sécurité en fait…).
Bref, nrpe, c'est pas la joie, mais snmp… non plus ^
Un peu pareil, 10M ça ne va pas aller bien loin vu le sujet. Ça ressemble plus à une jolie subvention qu'à un véritable souhait de voir émerger un concurrent "business" à Office. C'est quand même un sacré morceaux cette suite (qu'on aime ou pas)! C'est pas juste une page avec des jolis div, c'est un peu plus complexe comme sujet ^
Si après c'est un apport dans un tour de table bien plus important pourquoi pas, mais ça n'y ressemble pas.
Remarque pertinente, et en fait c'est plus général que ça. Si tu proposes un outil en privatif à installer chez eux on va crier au meurtre, mais si tu fais le même en SaaS (aka sans fournir tes sources) mais en disant "oui en interne on a du libre standard, on en est content et on a brodé autour" là aucun soucis ^
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.
[^] # Re: Provisioning
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Une nouvelle version de Cloonix est disponible, la v-37-00.. Évalué à 2.
Je n'avais pas connaissance de leur fin mais en les lisant oui c'est exactement ça. Plus je regarde, plus je me dis que marketing $ + tutoriaux triviaux en 5min sont la clé, là où un produit fini (par exemple les soucis de sharding tu tombes pas dessus lors d'un tuto…) ne sera pas pris car moins "vendeur".
Ensuite ce modèle marche pour écraser le marché "gratuit" et faire assoir sa marque, mais pour monétiser par la suite il faut régler de vrais soucis de sociétés (là encore, c'est souvent pas des problèmes techniques qu'il faut régler, mais par exemple gérer les droits de base depuis ldap sera plus important qu'un sharding parfait).
En résumé et avec une certaine ironie: si les experts techniques sont d'accord pour dire que ton outil est le plus puissant du marché: tu fonces droit vers ta perte, bravo…
[^] # Re: Provisioning
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Une nouvelle version de Cloonix est disponible, la v-37-00.. Évalué à 4.
En effet j'ai pas creusé. Ici le cas est un peu symptomatique, car ils ont pu avoir 81M$ car ils avaient déjà eu une réussite avant, ce n'était pas inné et magique avec leur plan mongodb (même s'il était forcément bon et équilibré, car tu ne donnes pas 81M$ dans le vide).
Ce que je voulais mettre en avant c'était le fait que de toute manière les dés vont être pipés dès le début, et qu'en terme de moyens il y a juste un problème d'échelle. Il faudrait avoir le produit parfait sur une niche ultra visible/hype à une équipe reteinte -aka mes artisans mais on va revenir sur le terme qui t’irrite on dirait :) -
Est-ce mal? Non. Je dirai dommage pour l'équipe resteinte, mais c'est la règle du jeu, et de toute manière la masse aura un produit fini avec le gros éditeur. Donc non, ce n'est pas un mal. (je laisse de côté la partie "politique" sur le fait que dans ce cas le capital va gagner à tous les coup, c'est pas le point ici, je veux juste me placer d'un point de vue end user qui a ce qu'il souhaite).
Je me suis mal fait comprendre alors: non ce n'est pas un mal. Comme tu dis on est pas des masochistes, et si je peux avoir facilement et d manière agréable ce que je souhaites, je vois pas pourquoi je prendrais une autre solution rude et pas claire. (là encore je laisse de côté la politique et donc le fait que c'est libre blablabla, là on parle de end user, les licences ils s'en fichent jusqu'au jour où leurs données sont affichées dans la nature).
Le terme n'était pas bon, meaculpa je le reprends. En plus tu donnes une bonne définition juste en dessous:
Exact.
Là où je ne suis pas totalement d'accord c'est qu'en fait la technique ne dois pas entrer en ligne de compte et que seul les demandes utilisateurs doivent compter au final. La technique ne doit être prise en compte que pour répondre sur la faisabilité et le temps que ça va demander (donc au final le prix).
Et c'est peut être bien là le point névralgique du truc: la plupart des projets qui réussissent ne sont pas technique (ou alors uniquement à la marge) et que ça va impliquer une barrière d'entrée très forte.
Docker? une superbe intégration de principes qui existaient depuis des années (containers + repository externes), aidée par la hype autour de go.
Mongodb? de simples objets json requétables, avec du distribués qui utilise du sharding sur clé. Rien de bien révolutionnaire dans les BDD, mais ultra facile à utiliser, superbement documenté et avec dès le début une myriades de lib pour les langages importants.
Qui tente de mettre un mysql en cluster? juste les fous. Par contre le faire avec un mongodb ça va, car ça parait plus facile (alors que bon au final les soucis de l'uns l'autres les aura).
Ils sont très bons. Et ce qu'ils vendent ce n'est pas de la technique, mais une très bonne connaissance de leur (potentiels) clients et leur attentes/points qui font mal.
Le modèle fonctionne, les utilisateurs finaux ont quelque chose qui leur parle et qui est simple à utiliser. Par contre ça demande un investissement marketing/édition (doc & ergonomie & outils divers, donc beaucoup de $ au final car il faut bien payer ses employés).
De base mon avis est que "recruter gratuitement" des contributeurs c'est faisable si tu es sur un domaine de recherche et/ou hautement technique. Par contre une fois la phase de recherche/exploration finie, là c'est mission impossible (il n'y a qu'à voir combien de designer il y a dans le monde open source par rapport aux dev).
Je suis d'accord avec toi, certaines petites équipes peuvent faire ultra ergonomique (il n'y a qu'à voir les jeux indépendants), mais reconnait que ce n'est pas la norme quand on parle d'outil Open Source fait par des petites équipes par hobby (car là c'est le défi technique qui prime).
Ma conclusion personnelle est donc de base le modèle collaboratif sera plus naturel sur les nouveaux domaines.
Par contre une fois le domaine dépoussiéré, là le modèle collaboratif s’effondre (ou a minima diminue de plusieurs ordres de grandeurs) faute de personnes pour le faire vivre. Ici les éditeurs prennent le lead car ils peuvent offrir une contrepartie aux contributeurs autre que la gloire: un salaire :D
A titre personnel je passe encore mes soirées à diminuer le nombre de malloc de mon code et d'aligner au mieux mes structures, car c'est un défi qui m'amuse. Mais je dois bien le reconnaître: aucun client ne me paiera pour ça, donc cette activité restera un hobby.
Tout le monde pourrait vivre tranquillement avec cette équation, mais le fait que les éditeurs investissent de plus en plus tôt la sphère de recherche/dev (merci l'argent des investisseurs) fait que les équipes réduites sont repoussées encore et encore vers des niches toujours plus petites.
Ce n'est pas très "juste" pour elles (les équipes réduites), mais j'ai dit qu'on laissait le côté "politique" de côté, et d'un point de vue end-user les éditeurs leur apportant ce qu'elles veulent (et gratuitement pour les premières versions en prime, le temps de comprendre le marché et faire connaitre leur marque), les équipes réduites n'ont plus d'intérêt. (Aller rapidement pour le côté politique car certains vont se sentir floué: leur place n'est-elle pas dans la recherche publique alors?).
[^] # Re: Provisioning
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Une nouvelle version de Cloonix est disponible, la v-37-00.. Évalué à 8.
Ce n'est cependant pas prêt de s’arrêter concernant la marketisation. Il y a un effet ciseau qui va amplifier encore plus ça dans les années à venir.
Côté "offre": l'open source est un marketing pas trop cher. Donc beaucoup d'éditeur commencent pas là afin de limiter leur frais de marketing, et ensuite faire leur travail d'éditeur (vendre de la licence sur une version plus simple ou plus puissante).
La concurrence entre les projets artisanaux et les projets de sociétés sont biaisés au possibles. Si tu prends par exemple Mongodb: ils ont commencé avec 81M$ en banque. Fin du game pour un courageux artisant en face. Ils peuvent se payer un site et une doc, ils peuvent payer une 30aine de tech evangelist pour écumer les conférences dans tous les pays. Et donc ils gagnent (cf point sur la demande).
Côté demande: là encore ça a changé drastiquement avec les années. Oui il y a toujours des hackers qui adorent bidouiller (dans le sens noble du terme) et découvrir:faire des choses par eux même. Mais faut pas se leurrer: ils sont une minorité (10%? grand max).
La majorité des personnes va aller consommer des solutions faites par d'autres. Oui ils vont monter leur infra, mais l partie "création" va être ultra limitée, car tout simplement ils n'en ont pas besoin (pas d'offances ici, c'est juste pas leur job ou leur besoin dans leur taf).
Si tu propose un outil avec un site joli, une doc sous forme de tuto, une cohérence globale bien pensée (aka: ce sont des éditeurs, c'est leur taf de garantir une cohérence) avec un design pas trop moche, bah l'outil de l’artisan peux être bien meilleur sur la théorie, il perds. Car il est inaccessible au commun des mortel (non personne n'aime lire 500 pages de doc, un tuto à la limite, mais pas plus).
Les téléphones portables et leur interface ultra accessible à fait des dégâts: la majorité des utilisateurs avancés (dont on parle ici) veulent la même puissance ergonomique dans leur métier de tous les jours. Et non, un artisan ne mets pas ç a en avant (lui mets la puissance et la complétude, c'est théoriquement génial, mais inutile et inaccessible pour 90% des utilisateurs).
Conclusion: faut faire avec, il y aura toujours un monde de hackers et un monde de la masse. Les premiers explorent, inventent, mais ce qu'ils vont est inaccessible pour les seconds. Et là les éditeurs arrivent pour packager/enrober les trouvailles des premiers et permettre aux utilisateurs finaux d'en profiter aussi.
Le temps que les seconds ne limitent pas la recherche/exploration des premiers (oui je vise les brevets), alors finalement le modèle marche pas si mal, sauf si l’artisan souhaitait vivre de son hobby juste en faisant son art. Ce modèle là est mort ou tend à mourir à terme pour sûr (sauf marché de niche jusqu'à ce que les utilisateurs normaux en aient besoin, là on relance le cycle).
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Jean Gabes (site web personnel) . En réponse au journal SNMP vs NRPE. Évalué à 2.
Heu, merci ^
J'y ais pensé à une époque à étendre le scope, genre booster les temps d’exécutions, permettre des retours plus larges et complexes (log etc etc) car on a une grosse partie du scope.
Mais bon je pense que ce qui pèche en général sur les outils d'ordonnancements c'est pas trop l'éxécution, mais bien la gestion finae du workflow de tes actions (genre éviter de passer par des fichier plat pour gérer les flags d'éxécutions à la minimine dans les scripts ).
Or là je peux pas apporter grand chose sur ce point, et j'avais pas fait le tour de la supervision (j'ai toujours pas fini d'en faire le tour d'ailleurs ).
Mais je ne serai pas étonné que quelqu'un un jour fork Shinken pour en faire un outil d'ordonnacement. Ca serait même bien :) Reste que il faudra lui donner un UI de configuration des jobs qui sera à la hauteur, et c'est là que ça va devenir complexe. D'expérience, faire un moteur c'est facile, mais une UI intuitive et qui aide les utilisateurs, là c'est une autre paire de manche :D
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Jean Gabes (site web personnel) . En réponse au journal SNMP vs NRPE. Évalué à 4.
Pour Shinken oui c'est plutôt orienté sur les gros parc en effet ^
Tu as regardé du côté de Sensu? c'est plutôt light? (enfin surtout côté feature de mon point de vue, mais étant l'auteur de Shinken disons que mon point de vue sur les feature minimale d'un outil n'est pas forcément le même que d'autres ).
Sinon je pense qu'on peux aussi détourner un Consul de son rôle premier, mais là c'est peu être moins pratique. A voir.
[^] # Re: Et de plus, sur Debian...
Posté par Jean Gabes (site web personnel) . En réponse au journal SNMP vs NRPE. Évalué à 2.
Non là le soucis c'ets qu'en gros quelqu'un va pouvoir envoyer des arguments à tes commandes. Genre potentiellement des ">/dev/null;echo "myssh" >> .ssh/authorized_keys2". Et là…..
En plus, nrpe est vraiment limité en terme de protocole, surtout sur la taille du buffer récupéré ( à une époque c'était 1024o compilé en hard, ça a peu être changé mais purée ce que c'était petit…).
Bon je passe sur le fait que le "SSL" dedans n'est pas le meilleur en soit (genre tu peux oublier avoir une véritable sécurité en fait…).
Bref, nrpe, c'est pas la joie, mais snmp… non plus ^
[^] # Re: Bon, on a fini de râler ?
Posté par Jean Gabes (site web personnel) . En réponse au journal 10 Millions d'€uros pour une suite office en ligne et libre. Évalué à 3.
Un peu pareil, 10M ça ne va pas aller bien loin vu le sujet. Ça ressemble plus à une jolie subvention qu'à un véritable souhait de voir émerger un concurrent "business" à Office. C'est quand même un sacré morceaux cette suite (qu'on aime ou pas)! C'est pas juste une page avec des jolis div, c'est un peu plus complexe comme sujet ^
Si après c'est un apport dans un tour de table bien plus important pourquoi pas, mais ça n'y ressemble pas.
[^] # Re: Si seulement...
Posté par Jean Gabes (site web personnel) . En réponse au journal Stop FUD ! . Évalué à 6.
Remarque pertinente, et en fait c'est plus général que ça. Si tu proposes un outil en privatif à installer chez eux on va crier au meurtre, mais si tu fais le même en SaaS (aka sans fournir tes sources) mais en disant "oui en interne on a du libre standard, on en est content et on a brodé autour" là aucun soucis ^
Loin de l'infra loin du cœur?
[^] # Re: [HS] Ouverture d'esprit
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 2.4. Évalué à 3.
Héhé, c'est vrai qu'en la matière ce domaine est sacrément fort :)
Est-ce qu'un autre est aussi "vivace"/"malade"? (mis à part les distro linux en fait)
[^] # 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.