Je connais une banque française ( dont je vais taire le nom, principalement parce que j'ai oublié ou la personne qui m'a dit ça lors d'un meetup travaille ) qui a des gens qui teste TheForeman et qui sont en avance de phase, pour reprendre leur termes vis à vis de certains produits RH, justement en vue de faire des retours plus tôt. Le fait d'avoir du logiciel libre permet pour eux ce genre de liberté, aussi bien en test plus rapide que de participer à la boucle de retroaction au coeur de l'innovation du logiciel libre.
C'est pas la police qu'est-ce que cela vient faire là pour un pc
de dev.
Ma foi, ils viennent quand même demandé. Ensuite, tu peux te dire "moi, je sais qu'ils ont pas le droit de venir fouiller, alor sje vais leur dire merde", mais que je sache, on demande pas à l'utilisateur. On parle des controles du BSA en pensant que c'est spécifique à Microsoft, mais en pratique, les grands éditeurs de soft autre que Microsoft aiment aussi vérifier que les clients ne grugent pas ( et dieu sait qu'ils le font, parfois par erreur, et parfois moins ). Donc ouais, il te faut de l'inventaire, car les commerciaux se gênent pas pour utiliser le manque de "compliance" comme moyen de négocier. Si tu utilises 1500 Autocad et que tu payes pour 50, et que ça se sait, ç'est risqué.
Concernant le reste du poste, tu devrait un peu te rappeler
que le service IT est un productif, un truc nécessaire mais
qui ne produit pas. Le dev est celui qui rapporte des sous à
la boite, l'IT est à son service pas l'inverse !
Tu vois, c'est exactement ce genre d'arrogance que je dénonce ne pensant que les devs se croient plus important que le reste du monde.
Comptablement, les devs e la R&D aussi coute de l'argent sont donc aussi un centre de cout. Ensuite, comme ça, ils arrivent pas à le digérer, ils en parlent pas, mais voila, l'argent rentre via les contrats ( service commerciale ), les consultants que tu places ( service consulting ), le support ou les différentes BUs en fonction de ton organisation. Mais ça ne sert qu'à modéliser les flux à l'intérieur, tu as beau être commercial, ça veut pas dire que tu as carte blanche à faire ce que tu veux, et la plupart sont à mon sens fliqué.
Et tout le reste de dehors de la modélisation comptable, c'est du flan que les gens rajoutent pour se mettre en avant et rabaisser les autres, en diabolisant le fait de dépenser l'argent. Tout les gens des services au contact du client pensent qu'ils sont ceux qui rapportent le plus et le vrai coeur de métier. J'ai souvent vu des gens tenter de se justifier de leur existence en disant "nan mais je bosse la ou ça rapporte".
Et parfois en rabaissant tout ceux qui sont pas aux contacts du client ( typiquement, service généraux, HR, IT, Marketing, etc ) en disant qu'ils ne rapportent rien. Ce qui est une aberration.
De la même façon, certains commerciaux ( ou project manager ) voient les devs comme étant à leur service ( vu qu'ils sont au service du client ).
Tout comme un projet libre, une entreprise est une équipe, et il faut quelqu'un pour s'occuper de chaque chose. Tu peux faire une distinction interne/externe ou ce que tu veux, ou vivre dans un monde centré sur ton poste, je continue de penser que la culture du développeur rock star visiblement file des melons énormes à une partie de la profession. Mais un rapide reality check serait de voir le salaire d'un commercial ( avec les primes ) ou d'un consultant pour voir, voir même par rapport aux autres ingénieurs non informatiques. Mais la chute risque d'être rude.
Si les départements informatiques existent, c'est pas pour rendre un service que les gens seraient capable de faire d'eux même. Mais bien parce que c'est un boulot que les autres savent pas faire. La preuve, les gens sont pas foutu de gérer leur machines chez eux dans leur majorité, et les gens deviennent pas compétent juste en se déplaçant d'un coup dans les murs de la boite.
Faut aussi compter le temps pour gérer la machine, voir le prix des licenses ( si tu dev sous Windows, ce qui n'est pas le cas pour le cas qu'on discute, sauf à utiliser des SDKs spécifiques proprios ou je ne sais pas quoi qu'on peut trouver dans l'embarqué ). Si ils ont pris le choix d'avoir une machine de build centralisé, c'est aussi le genre de choses à prendre en compte. Combien de temps tu passes à remettre ton env de compilation quand ça se gaufre, combien de temps tu passes à t'assurer que tout le monde à la même version.
Exemple de mon ancien boulot, on faisait du PyQT pour déploiement sur la debian stable de l'époque. Sauf que comme personne n'était en stable, personne n'avait la même version de PyQT. Et c'était le cas parce qu'on était tous responsable de nos machines.
Bien sur, ça a donné des merdes en production ou lors de la QA, parce que tout les devs avaient choisit un Debian unstable ou une autre distribution pour leur confort. Maintenant, on a des infras de CI et ce genre de choses, donc c'est moins un souci, mais c'est pas le cas de tout le monde.
mais tu pourrais être un agent du FSB qui ferait la remarque pour que quelqu'un fasse un remarque sur le fait que je soit un agent de la NSA qui va faire remarquer que en parlant de la DSD et de la DGSI tu fait oublier la NSA ?
Merci d'illustrer que le dev moyen n'a pas la moindre idée des contraintes autres que les siennes, et que les gens semblent se croire plus important que le reste du monde.
Se dire "quoi, je doit me justifier" est arrogant, et c'est faire preuve de myopie que de croire que "les régles s'appliquent pas pour moi".
La gestion de la compta d'une entreprise, c'est pas exactement la même que celle d'un particulier ou d'une startup. Déjà, quand tu as une boite assez grande, tu veux un fournisseur qui soit capable d'assurer la garantie pour la durée ( genre 3 ans, parfois 5 ans ), ce qui implique d'avoir des stocks et de pas avoir fait faillite.
Si tu bosses dans une multinationale, tu va tenter de faire les achats depuis une seule entité pour simplifier les choses, donc elle doit être capable de facturer parfois dans un autre pays, avec le casse tête de la TVA intra communautaire. Ou si tu bosses dans l'administration, tu achètes pas toujours ce que tu veux, y a des appels d'offres.
Et le matos que tu achètes, tu récupères la TVA ( parfois ).
Et puis, tu cherches à le recycler de façon propre, donc tu évites de renouveler tout les ans, loin de la ( ce qui veut dire que tu va pas avoir la bécane a 32G de ram qui a été présenté lors de l'E3 la semaine dernière ). Il y a les questions d'amortissements, les contrôles du BSA, l'inventaire pour connaitre les actifs immobilisés ( parce que bon, si chaque machine coute 1000€ et qu'il y a 700 personnes dans la boite, 700 000 euros de matos, c'est pas "négligeable" ). Y a la question de la garantie ( pièce de rechange, réponse sous 24h ).
Et point bonus, y a des boites qui demandent d'avoir une assurance chez le fournisseur.
Ça, c'est juste les achats et pourquoi tu prends pas forcément ce que tu veux.
À coté, dans "j'achéte ce que je veux" viens aussi le "je fait ce que je veux". Cad il y a aussi la problématique d'être root sur sa machine. La, on va de "j'ai pas besoin d'antivirus parce que ça n'arrive qu'aux autres" à "oups, j'ai oublié mon dhcpd qui tourne pour mes machines virtuels, j'ai juste mis en l'air le réseau de la boite pendant 3h" ou "j'ai mis un radvd pour tester, oups".
y a plein de raison d'avoir besoin de se justifier. Tout personne croyant le contraire vis dans un monde de bisounours loin de la réalité du terrain, et devrait aller faire 1 ou 2 ans dans un département informatique.
Si tu écoutes les développeurs ( ou les techos d'une manière général ), chacun voudraient avoir son cluster de compilation dédié, sans avoir le département informatique qui va foutre la grouille avec la sécurité et ce genre de choses.
Donc je pense que oui, c'est toujours facile de dépenser l'argent des autres. Même si en effet, je trouve que le matériel donné est un peu faiblard, dire qu'on peut pas bosser, c'est aussi ridicule car on a réussi à bosser depuis des années avec du matos moins rapide. Et bien que ça coute que 700€ pour une personne, combien ça coute à l'échelle de la société ?
Car bon, tu files à une personne, les autres veulent ça aussi, et paf, tu te retrouves à upgrader tout ton parc avec le cout des machines et du temps pour la mise à jour. Tout le monde n'a pas la patience d'attendre, et lors de mon premier travail, on avait des disques durs limités à 10G pour la partition pour que les gens ne ralent pas ( alors qu'on avait des disques durs de 40 à 80G en pratique, mais non partitionné pour tirer parti de l'espace à dessein ). Je peux citer d'autres exemples de gens qui réclament des machines, qui font un Proof of concept de 5j et qui font plus rien après avec. De gens qui réclament une machine, commence à déployer des trucs dessus et soudain, tu as un serveur dans un bureau qui est critique pour le taf, sans sauvegarde, sans redondance, avec du matos sans garantie, etc.
Donc non, il faut avoir une gouvernance des ressources informatiques en amont pour éviter les conneries et aberrations de ce genre. Et je parle même pas de la sécurité de la chose, et les soucis de sécurité, ça n'arrive pas qu'aux autres ( "tiens, je mettrais bien un serveur nfs ouvert pour tous, et puis je vais partager mon /home avec le LAN, je vois pas ce qui peut arriver de mal". ).
Et c'est pas des exemples que j'ai inventé. C'est des exemples que j'ai vécu.
La question est aussi l'importance des investissements dans la surveillance par rapport à des trucs comme avoir des gilets pareballes, etc.
Autant je n'ai pas les chiffres, autant pour avoir bosser dans le domaine de la sécurité informatique, c'est quand même du flan qui est vendu et comme les administrations étant en majorité composé de gens aussi qualifiés que le reste de la population à ce niveau la, avec donc les mêmes conséquences que chez monsieur et madame tout le monde, hélas.
Donc quitte à dépenser de l'argent, je préfère que ça soit dans des trucs ou le risque de filoutage est moins grand, mais si on me demande mon avis.
Sauf erreur, l'upstream de Satellite est plutôt Spacewalk:
Non. Satellite 5 a pour amont Spacewalk.
Satellite 6 a pour amont plusieurs logiciels, dont Katello, Pulp, Candlepin, Puppet, Theforeman.
A priori, Spacewalk est conçu par Red Hat pour Red Hat et ses dérivés.
Suse l'utilise aussi sauf erreur de ma part pour suse manager, et je pense qu'il y a eu un support pour les .deb pendant un temps (peut être encore le cas, peut être pas).
Sauf erreur de ma part, spacewalk est l'amont de Satelite 5, et il a été décidé de repartir sur des nouvelles bases avec Sat 6, et donc katello, Foreman, etc.
Spacewalk a des fonctions de gestions de config ( genre déposer un fichier, installer un paquet ), mais c'est pas aussi poussé que katello/foreman/etc qui vont utiliser puppet et faire des choses vachement plus puissantes, dans mon souvenir.
En sachant au passage que si tu es dans le groupe docker, c'est comme si tu était root ( tu lance un container avec un mount bindé d'un repertoire, tu modifie les permissions pour mettre un +s, hop, tu es root)
En gros, docker commence à intégrer de base des trucs que coreos propose, et donc coreos inc. pense que docker inc. va leur marcher commercialement sur les pieds tot ou tard.
Je crois que c'est ce que je dit, c'est que tu peux te limiter, mais c'est plus du shell. Et surtout, tu peux pas forcer les gens à se limiter sauf à prendre autre chose qu'un shell pour parser.
Par exemple, export foo=bar va marcher avec un init en shell qui fait un source ou une execution, mais pas avec systemd ou un autre outil. L'interpolation de variable avec () va pas l'être. Ou tu as les exemple de foo=bar bar2 avec ou sans quotes. Dans du clé/valeur pur, ça peut marcher. Il y a la question des chaines multilignes aussi.
je suis assez surpris que ça bloque journalctl. Sur ma RHEL 7, un strace montre que ça ouvre directement le fichier journal, donc je voit pas vraiment comment un crash de systemd va impacter ça.
Je vois bien d'autres façons dont ça peut faire chier ( exemple, le démarrage à la demande de sshd qui marcherais sans doute plus ), mais ça n'a pas l'air d'être ce que tu décris.
Quand a bloquer reboot, je pourrais imaginer un fallback qui fait un echo 'b' dans /proc, mais ça peut être bloqué aussi. Ou juste l'appel reboot en direct.
Ceci dit, dans le cas de musl, c'est simplement que systemd utilise du code de la glibc, et les gens de musl veulent pas rajouter le code dans leur libc ( pour rester minimaliste ) , et les gens de systemd veulent pas dupliquer le code de la glibc dans leur projet ( car la copie de code, c'est mal ).
Je comprends le point de vue des 2, mais dans une optique de factorisation du code, je donnerais raison aux gens de systemd. Une solution serait peut être de faire un 3eme projet "compat-libc" qui rajoute les fonctions que musl refuse d'ajouter, quitte à linker différemment.
Mais bon, les gens préfèrent troller plutôt que de faire du code.
Y en a parfois, c'est juste que c'est masqué sous le FUD et les commentaires sans remarques, et du peu que j'ai réussi à trouver, ce sont pas tant des améliorations que des tradeoffs différents.
En pratique, ils prennent déjà en compte la communauté, sinon, ça serait pas adopté et il n'y aurait pas des patchs. Ensuite quand la remarque ça deviens "je pense qu'il faut tout refaire le logiciel parce que j'accorde plus d'importance à ce point qu'à ce point la", tu peux pas satisfaire tout le monde.
J'ai du mal m'exprimer, ce que je veux dire, c'est que la table des processus est limité à 65000 et des poussières entrées, non ? (en tout cas pid_t est un int sous la glibc, donc 32 bits, donc 2**32 entrées)
Ensuite, que ça soit le dernier truc à tomber, c'est une chose, et encore une fois, je ne doute pas que d'autres trucs tombent avant. J'ai pas fait de remarques sur la taille du process, mais du containers complets, ie avec le reste des process dedans pour estimer à la louche le nombre qu'on peut imaginer lancer avec la ram disponible. Mais encore une fois, c'est de l'estimation, j'ai pas réussi à trouver grand chose.
Et je présuppose aussi d'une archi ou chaque container est lancé par un service séparé, ce qui est pas forcément le cas (docker n'a pas l'air de faire ça, par exemple).
Mais bon, en effet, "64k of process is enough for everybody" :)
Que 'systemd' soit dans les dépôts de Debian malgré sa
philosophie anti UNIX et son code discutable,
Tu peux détailler ce que tu veux dire par "code discutable" ? Car à chaque fois que les gens disent ça, j'ai le sentiment que c'est juste pour trainer dans la boue le projet. Pour une raison inconnue, les gens estiment que pour systemd, la barre doit être plus haute que pour tout le reste, y compris le noyau.
Exemple, les devs refusent des patchs, c'est des gros dictateurs. Linus le fait, c'est un génie qui défend sa vision sans la moindre erreur. Les critiques sont systématiquement sur Lennart, même quand c'est GKH qui pousse kdbus. Le design est examiné en détail, alors que tout le monde se fout du reste.
Donc j'ai quand même le sentiment que les gens répètent des trucs sans se justifier, juste pour convaincre d'autre personnes qui n'ont pas les compétences pour juger.
En général, quand je dit ça, les gens sortent le bugzilla de freedesktop, sans prendre la peine de donner des chiffres pour comparer le nombre de bugs par rapport à d'autres projets, ou donne les CVE, pareil sans donner de chiffres moyens.
Et pour cause, car si on regarde la mise à jour d'un paquet du kernel, on voit que les CVE et les bugs sont la et sont corrigé, donc donner des chiffres ne serait pas vraiment productif, sauf à dire "le kernel aussi est buggué", ce qui entrainerais un blocage. Donc plutôt que de parler de chiffres en bon ingénieur, on utilise un argument d'autorité, et on ressasse sans arrêt sans se remettre en cause.
Donc, suite à ça,j'ai regardé à gauche à droite, mais j'ai pas la prétention de tout piger d'un coup, donc si je dit une connerie, faut le dire :).
Donc l'idée, est d'avoir un processus lancé par init, et ce processus, via un appel système, devient un "init local". Comme ça veut rien dire, j'explique. par init local, j'entends un processus en charge de recevoir les signaux des orphans, tout comme init, et qui chope les zombies pour les tuer, ce qui semble éviter les cgroups pour suivre les process, et ce qui permet de pousser le code en dehors du pid 1.
C'est une approche intéressante, mais ça veut pas dire une occupation doublé dans la table des processus ?
Genre si je lance 10 000 containers, je vais avoir 10 000 processus de supervision. C'est pas un souci en temps normal et pas un souci pour tout de suite ( voir même un souci pour jamais peut être ), mais si tu imagines 100 Mo par containers, ça va te faire 1T de ram pour 1000 ( ce qui est faisable ), donc on est pas loin du stade ou ça va AMHA poser souci ( genre vers les 10000/20000 ). Bien sur, avec un systéme comme ksm, et avec des containers plus petits, ça peut arriver vite.
Ensuite, peut être que c'est le cpu et les I/O qui vont tomber en premier donc je me fait des idées.
C'est une bonne remarque, mais ça devient du coup plus compliqué, car la logique de surveillance d'un process est présente 2 fois. une fois dans init et une fois dans smf.
Et comme quelqu'un l'a fait remarquer sur lwn ( http://lwn.net/Articles/623527/ ), le pid 1 pourrait très bien ne rien avoir de spécial, et ne pas planter le kernel en cas de crash ( ou se faire relancer par le kernel ).
Car c'est quand même la plus grande peur des gens "si ça plante, mon système plante", alors qu'en pratique, c'est pas le fait d'être PID1 qui nous mets dans la merde. C'est le fait de planter, PID1 ou PID50, à partir du moment ou il gère l'état des processus.
Donc faire 2 trucs, ça sert à juste à rajouter de la complexité. Si SMF se vautre, je suis spas sur d'imaginer l'état du système après ( sauf à avoir l'info poussé dans le kernel sous une forme quelquconque, genre l'équivalent des cgroupes avec des metadonnés , et à ce que smf reprenne l'info du kernel quand ile st relancé, mais on arrive à un truc encore moins portable et poussé dans un truc plus critique depuis l'userspace dans le kernel, alors qu'on essaye surtout l'inverse ).
[^] # Re: Prems LOL
Posté par Misc (site web personnel) . En réponse au journal Faille de sécurité glibc. Évalué à 6.
Je connais une banque française ( dont je vais taire le nom, principalement parce que j'ai oublié ou la personne qui m'a dit ça lors d'un meetup travaille ) qui a des gens qui teste TheForeman et qui sont en avance de phase, pour reprendre leur termes vis à vis de certains produits RH, justement en vue de faire des retours plus tôt. Le fait d'avoir du logiciel libre permet pour eux ce genre de liberté, aussi bien en test plus rapide que de participer à la boucle de retroaction au coeur de l'innovation du logiciel libre.
[^] # Re: .
Posté par Misc (site web personnel) . En réponse au journal Un bond en avant pour Gitlab.com. Évalué à 3.
Si par "job dans l'informatique", tu veux dire "être developpeur", peut être. Mais y a des tafs cools en dehors de ça.
[^] # Re: Sérieux?
Posté par Misc (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 7.
Ma foi, ils viennent quand même demandé. Ensuite, tu peux te dire "moi, je sais qu'ils ont pas le droit de venir fouiller, alor sje vais leur dire merde", mais que je sache, on demande pas à l'utilisateur. On parle des controles du BSA en pensant que c'est spécifique à Microsoft, mais en pratique, les grands éditeurs de soft autre que Microsoft aiment aussi vérifier que les clients ne grugent pas ( et dieu sait qu'ils le font, parfois par erreur, et parfois moins ). Donc ouais, il te faut de l'inventaire, car les commerciaux se gênent pas pour utiliser le manque de "compliance" comme moyen de négocier. Si tu utilises 1500 Autocad et que tu payes pour 50, et que ça se sait, ç'est risqué.
Tu vois, c'est exactement ce genre d'arrogance que je dénonce ne pensant que les devs se croient plus important que le reste du monde.
Comptablement, les devs e la R&D aussi coute de l'argent sont donc aussi un centre de cout. Ensuite, comme ça, ils arrivent pas à le digérer, ils en parlent pas, mais voila, l'argent rentre via les contrats ( service commerciale ), les consultants que tu places ( service consulting ), le support ou les différentes BUs en fonction de ton organisation. Mais ça ne sert qu'à modéliser les flux à l'intérieur, tu as beau être commercial, ça veut pas dire que tu as carte blanche à faire ce que tu veux, et la plupart sont à mon sens fliqué.
Et tout le reste de dehors de la modélisation comptable, c'est du flan que les gens rajoutent pour se mettre en avant et rabaisser les autres, en diabolisant le fait de dépenser l'argent. Tout les gens des services au contact du client pensent qu'ils sont ceux qui rapportent le plus et le vrai coeur de métier. J'ai souvent vu des gens tenter de se justifier de leur existence en disant "nan mais je bosse la ou ça rapporte".
Et parfois en rabaissant tout ceux qui sont pas aux contacts du client ( typiquement, service généraux, HR, IT, Marketing, etc ) en disant qu'ils ne rapportent rien. Ce qui est une aberration.
De la même façon, certains commerciaux ( ou project manager ) voient les devs comme étant à leur service ( vu qu'ils sont au service du client ).
Tout comme un projet libre, une entreprise est une équipe, et il faut quelqu'un pour s'occuper de chaque chose. Tu peux faire une distinction interne/externe ou ce que tu veux, ou vivre dans un monde centré sur ton poste, je continue de penser que la culture du développeur rock star visiblement file des melons énormes à une partie de la profession. Mais un rapide reality check serait de voir le salaire d'un commercial ( avec les primes ) ou d'un consultant pour voir, voir même par rapport aux autres ingénieurs non informatiques. Mais la chute risque d'être rude.
Si les départements informatiques existent, c'est pas pour rendre un service que les gens seraient capable de faire d'eux même. Mais bien parce que c'est un boulot que les autres savent pas faire. La preuve, les gens sont pas foutu de gérer leur machines chez eux dans leur majorité, et les gens deviennent pas compétent juste en se déplaçant d'un coup dans les murs de la boite.
[^] # Re: comprend pas
Posté par Misc (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 7.
Faut aussi compter le temps pour gérer la machine, voir le prix des licenses ( si tu dev sous Windows, ce qui n'est pas le cas pour le cas qu'on discute, sauf à utiliser des SDKs spécifiques proprios ou je ne sais pas quoi qu'on peut trouver dans l'embarqué ). Si ils ont pris le choix d'avoir une machine de build centralisé, c'est aussi le genre de choses à prendre en compte. Combien de temps tu passes à remettre ton env de compilation quand ça se gaufre, combien de temps tu passes à t'assurer que tout le monde à la même version.
Exemple de mon ancien boulot, on faisait du PyQT pour déploiement sur la debian stable de l'époque. Sauf que comme personne n'était en stable, personne n'avait la même version de PyQT. Et c'était le cas parce qu'on était tous responsable de nos machines.
Bien sur, ça a donné des merdes en production ou lors de la QA, parce que tout les devs avaient choisit un Debian unstable ou une autre distribution pour leur confort. Maintenant, on a des infras de CI et ce genre de choses, donc c'est moins un souci, mais c'est pas le cas de tout le monde.
[^] # Re: Non
Posté par Misc (site web personnel) . En réponse au journal Une backdoor de la NSA dans OpenSSH ?. Évalué à 10.
mais tu pourrais être un agent du FSB qui ferait la remarque pour que quelqu'un fasse un remarque sur le fait que je soit un agent de la NSA qui va faire remarquer que en parlant de la DSD et de la DGSI tu fait oublier la NSA ?
[^] # Re: Avec le lien
Posté par Misc (site web personnel) . En réponse au journal Une backdoor de la NSA dans OpenSSH ?. Évalué à 10.
Quoi, les gens peuvent modifier les logiciels libres pour rajouter du code et remplacer le binaire ?
Clairement oui, je vais réinstaller mes serveurs en windows, car c'est visiblement plus sur.
[^] # Re: Sérieux?
Posté par Misc (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 10.
Merci d'illustrer que le dev moyen n'a pas la moindre idée des contraintes autres que les siennes, et que les gens semblent se croire plus important que le reste du monde.
Se dire "quoi, je doit me justifier" est arrogant, et c'est faire preuve de myopie que de croire que "les régles s'appliquent pas pour moi".
La gestion de la compta d'une entreprise, c'est pas exactement la même que celle d'un particulier ou d'une startup. Déjà, quand tu as une boite assez grande, tu veux un fournisseur qui soit capable d'assurer la garantie pour la durée ( genre 3 ans, parfois 5 ans ), ce qui implique d'avoir des stocks et de pas avoir fait faillite.
Si tu bosses dans une multinationale, tu va tenter de faire les achats depuis une seule entité pour simplifier les choses, donc elle doit être capable de facturer parfois dans un autre pays, avec le casse tête de la TVA intra communautaire. Ou si tu bosses dans l'administration, tu achètes pas toujours ce que tu veux, y a des appels d'offres.
Et le matos que tu achètes, tu récupères la TVA ( parfois ).
Et puis, tu cherches à le recycler de façon propre, donc tu évites de renouveler tout les ans, loin de la ( ce qui veut dire que tu va pas avoir la bécane a 32G de ram qui a été présenté lors de l'E3 la semaine dernière ). Il y a les questions d'amortissements, les contrôles du BSA, l'inventaire pour connaitre les actifs immobilisés ( parce que bon, si chaque machine coute 1000€ et qu'il y a 700 personnes dans la boite, 700 000 euros de matos, c'est pas "négligeable" ). Y a la question de la garantie ( pièce de rechange, réponse sous 24h ).
Et point bonus, y a des boites qui demandent d'avoir une assurance chez le fournisseur.
Ça, c'est juste les achats et pourquoi tu prends pas forcément ce que tu veux.
À coté, dans "j'achéte ce que je veux" viens aussi le "je fait ce que je veux". Cad il y a aussi la problématique d'être root sur sa machine. La, on va de "j'ai pas besoin d'antivirus parce que ça n'arrive qu'aux autres" à "oups, j'ai oublié mon dhcpd qui tourne pour mes machines virtuels, j'ai juste mis en l'air le réseau de la boite pendant 3h" ou "j'ai mis un radvd pour tester, oups".
y a plein de raison d'avoir besoin de se justifier. Tout personne croyant le contraire vis dans un monde de bisounours loin de la réalité du terrain, et devrait aller faire 1 ou 2 ans dans un département informatique.
[^] # Re: comprend pas
Posté par Misc (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 10.
Si tu écoutes les développeurs ( ou les techos d'une manière général ), chacun voudraient avoir son cluster de compilation dédié, sans avoir le département informatique qui va foutre la grouille avec la sécurité et ce genre de choses.
Donc je pense que oui, c'est toujours facile de dépenser l'argent des autres. Même si en effet, je trouve que le matériel donné est un peu faiblard, dire qu'on peut pas bosser, c'est aussi ridicule car on a réussi à bosser depuis des années avec du matos moins rapide. Et bien que ça coute que 700€ pour une personne, combien ça coute à l'échelle de la société ?
Car bon, tu files à une personne, les autres veulent ça aussi, et paf, tu te retrouves à upgrader tout ton parc avec le cout des machines et du temps pour la mise à jour. Tout le monde n'a pas la patience d'attendre, et lors de mon premier travail, on avait des disques durs limités à 10G pour la partition pour que les gens ne ralent pas ( alors qu'on avait des disques durs de 40 à 80G en pratique, mais non partitionné pour tirer parti de l'espace à dessein ). Je peux citer d'autres exemples de gens qui réclament des machines, qui font un Proof of concept de 5j et qui font plus rien après avec. De gens qui réclament une machine, commence à déployer des trucs dessus et soudain, tu as un serveur dans un bureau qui est critique pour le taf, sans sauvegarde, sans redondance, avec du matos sans garantie, etc.
Donc non, il faut avoir une gouvernance des ressources informatiques en amont pour éviter les conneries et aberrations de ce genre. Et je parle même pas de la sécurité de la chose, et les soucis de sécurité, ça n'arrive pas qu'aux autres ( "tiens, je mettrais bien un serveur nfs ouvert pour tous, et puis je vais partager mon /home avec le LAN, je vois pas ce qui peut arriver de mal". ).
Et c'est pas des exemples que j'ai inventé. C'est des exemples que j'ai vécu.
[^] # Re: Et c'est une belle merde
Posté par Misc (site web personnel) . En réponse au journal Manu est avec vous. Évalué à 3.
La question est aussi l'importance des investissements dans la surveillance par rapport à des trucs comme avoir des gilets pareballes, etc.
Autant je n'ai pas les chiffres, autant pour avoir bosser dans le domaine de la sécurité informatique, c'est quand même du flan qui est vendu et comme les administrations étant en majorité composé de gens aussi qualifiés que le reste de la population à ce niveau la, avec donc les mêmes conséquences que chez monsieur et madame tout le monde, hélas.
Donc quitte à dépenser de l'argent, je préfère que ça soit dans des trucs ou le risque de filoutage est moins grand, mais si on me demande mon avis.
[^] # Re: Un équivalent pour Debian ?
Posté par Misc (site web personnel) . En réponse à la dépêche Katello 2.0. Évalué à 2.
Alors en regardant sur github :
https://github.com/Katello/katello-installer
Il semble que l'installeur supporte debian.
Par exemple :
https://github.com/Katello/katello-installer/blob/master/modules/dhcp/manifests/init.pp
Ensuite, peut etre que tout n'est pas supporté, mais prends une VM et teste :)
[^] # Re: Spacewalk
Posté par Misc (site web personnel) . En réponse à la dépêche Katello 2.0. Évalué à 5.
Non. Satellite 5 a pour amont Spacewalk.
Satellite 6 a pour amont plusieurs logiciels, dont Katello, Pulp, Candlepin, Puppet, Theforeman.
Suse l'utilise aussi sauf erreur de ma part pour suse manager, et je pense qu'il y a eu un support pour les .deb pendant un temps (peut être encore le cas, peut être pas).
[^] # Re: Petite question
Posté par Misc (site web personnel) . En réponse à la dépêche Katello 2.0. Évalué à 5.
Sauf erreur de ma part, spacewalk est l'amont de Satelite 5, et il a été décidé de repartir sur des nouvelles bases avec Sat 6, et donc katello, Foreman, etc.
Spacewalk a des fonctions de gestions de config ( genre déposer un fichier, installer un paquet ), mais c'est pas aussi poussé que katello/foreman/etc qui vont utiliser puppet et faire des choses vachement plus puissantes, dans mon souvenir.
[^] # Re: Et ça gère ?
Posté par Misc (site web personnel) . En réponse à la dépêche Katello 2.0. Évalué à 3.
Pulp gere aussi les images docker, les images ostree, les paquets pip, les images pour openstack, les modules d ela forge puppet, et les paquets deb :
https://github.com/pulp, cf pulp_truc comme depot. Ensuite, certains sont expérimentaux, d'autres non, donc les retours sont les bienvenus.
Pour katello, par contre, je suis un peu plus perdu.
[^] # Re: Comment ça root ?
Posté par Misc (site web personnel) . En réponse à la dépêche Rocket, ou pourquoi l'équipe de CoreOS lance une alternative à Docker. Évalué à 8.
En sachant au passage que si tu es dans le groupe docker, c'est comme si tu était root ( tu lance un container avec un mount bindé d'un repertoire, tu modifie les permissions pour mettre un +s, hop, tu es root)
[^] # Re: Dépêche pas très claire...
Posté par Misc (site web personnel) . En réponse à la dépêche Rocket, ou pourquoi l'équipe de CoreOS lance une alternative à Docker. Évalué à 10.
En gros, docker commence à intégrer de base des trucs que coreos propose, et donc coreos inc. pense que docker inc. va leur marcher commercialement sur les pieds tot ou tard.
Du coup, ils partent sur leur propre solution.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 3.
Je crois que c'est ce que je dit, c'est que tu peux te limiter, mais c'est plus du shell. Et surtout, tu peux pas forcer les gens à se limiter sauf à prendre autre chose qu'un shell pour parser.
Par exemple, export foo=bar va marcher avec un init en shell qui fait un source ou une execution, mais pas avec systemd ou un autre outil. L'interpolation de variable avec
() va pas l'être. Ou tu as les exemple de foo=bar bar2 avec ou sans quotes. Dans du clé/valeur pur, ça peut marcher. Il y a la question des chaines multilignes aussi.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 2.
je suis assez surpris que ça bloque journalctl. Sur ma RHEL 7, un strace montre que ça ouvre directement le fichier journal, donc je voit pas vraiment comment un crash de systemd va impacter ça.
Je vois bien d'autres façons dont ça peut faire chier ( exemple, le démarrage à la demande de sshd qui marcherais sans doute plus ), mais ça n'a pas l'air d'être ce que tu décris.
Quand a bloquer reboot, je pourrais imaginer un fallback qui fait un echo 'b' dans /proc, mais ça peut être bloqué aussi. Ou juste l'appel reboot en direct.
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 6.
Il t’empêche pas de l'appliquer sur ton build.
Ceci dit, dans le cas de musl, c'est simplement que systemd utilise du code de la glibc, et les gens de musl veulent pas rajouter le code dans leur libc ( pour rester minimaliste ) , et les gens de systemd veulent pas dupliquer le code de la glibc dans leur projet ( car la copie de code, c'est mal ).
Je comprends le point de vue des 2, mais dans une optique de factorisation du code, je donnerais raison aux gens de systemd. Une solution serait peut être de faire un 3eme projet "compat-libc" qui rajoute les fonctions que musl refuse d'ajouter, quitte à linker différemment.
Mais bon, les gens préfèrent troller plutôt que de faire du code.
[^] # Re: Ou bien ?
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 3.
Y en a parfois, c'est juste que c'est masqué sous le FUD et les commentaires sans remarques, et du peu que j'ai réussi à trouver, ce sont pas tant des améliorations que des tradeoffs différents.
En pratique, ils prennent déjà en compte la communauté, sinon, ça serait pas adopté et il n'y aurait pas des patchs. Ensuite quand la remarque ça deviens "je pense qu'il faut tout refaire le logiciel parce que j'accorde plus d'importance à ce point qu'à ce point la", tu peux pas satisfaire tout le monde.
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 1.
J'ai du mal m'exprimer, ce que je veux dire, c'est que la table des processus est limité à 65000 et des poussières entrées, non ? (en tout cas pid_t est un int sous la glibc, donc 32 bits, donc 2**32 entrées)
Ensuite, que ça soit le dernier truc à tomber, c'est une chose, et encore une fois, je ne doute pas que d'autres trucs tombent avant. J'ai pas fait de remarques sur la taille du process, mais du containers complets, ie avec le reste des process dedans pour estimer à la louche le nombre qu'on peut imaginer lancer avec la ram disponible. Mais encore une fois, c'est de l'estimation, j'ai pas réussi à trouver grand chose.
Et je présuppose aussi d'une archi ou chaque container est lancé par un service séparé, ce qui est pas forcément le cas (docker n'a pas l'air de faire ça, par exemple).
Mais bon, en effet, "64k of process is enough for everybody" :)
[^] # Re: Fonctionnalités clées.
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 2.
Qu'est ce qui serait le taf, et le taf dans quel logiciel ou quel os ?
[^] # Re: Les raisons du fork
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 10.
Tu peux détailler ce que tu veux dire par "code discutable" ? Car à chaque fois que les gens disent ça, j'ai le sentiment que c'est juste pour trainer dans la boue le projet. Pour une raison inconnue, les gens estiment que pour systemd, la barre doit être plus haute que pour tout le reste, y compris le noyau.
Exemple, les devs refusent des patchs, c'est des gros dictateurs. Linus le fait, c'est un génie qui défend sa vision sans la moindre erreur. Les critiques sont systématiquement sur Lennart, même quand c'est GKH qui pousse kdbus. Le design est examiné en détail, alors que tout le monde se fout du reste.
Donc j'ai quand même le sentiment que les gens répètent des trucs sans se justifier, juste pour convaincre d'autre personnes qui n'ont pas les compétences pour juger.
En général, quand je dit ça, les gens sortent le bugzilla de freedesktop, sans prendre la peine de donner des chiffres pour comparer le nombre de bugs par rapport à d'autres projets, ou donne les CVE, pareil sans donner de chiffres moyens.
Et pour cause, car si on regarde la mise à jour d'un paquet du kernel, on voit que les CVE et les bugs sont la et sont corrigé, donc donner des chiffres ne serait pas vraiment productif, sauf à dire "le kernel aussi est buggué", ce qui entrainerais un blocage. Donc plutôt que de parler de chiffres en bon ingénieur, on utilise un argument d'autorité, et on ressasse sans arrêt sans se remettre en cause.
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 1.
Donc, suite à ça,j'ai regardé à gauche à droite, mais j'ai pas la prétention de tout piger d'un coup, donc si je dit une connerie, faut le dire :).
Donc l'idée, est d'avoir un processus lancé par init, et ce processus, via un appel système, devient un "init local". Comme ça veut rien dire, j'explique. par init local, j'entends un processus en charge de recevoir les signaux des orphans, tout comme init, et qui chope les zombies pour les tuer, ce qui semble éviter les cgroups pour suivre les process, et ce qui permet de pousser le code en dehors du pid 1.
C'est une approche intéressante, mais ça veut pas dire une occupation doublé dans la table des processus ?
Genre si je lance 10 000 containers, je vais avoir 10 000 processus de supervision. C'est pas un souci en temps normal et pas un souci pour tout de suite ( voir même un souci pour jamais peut être ), mais si tu imagines 100 Mo par containers, ça va te faire 1T de ram pour 1000 ( ce qui est faisable ), donc on est pas loin du stade ou ça va AMHA poser souci ( genre vers les 10000/20000 ). Bien sur, avec un systéme comme ksm, et avec des containers plus petits, ça peut arriver vite.
Ensuite, peut être que c'est le cpu et les I/O qui vont tomber en premier donc je me fait des idées.
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 3.
Possible, mais si tu peux préciser un peu plus ?
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 1.
C'est une bonne remarque, mais ça devient du coup plus compliqué, car la logique de surveillance d'un process est présente 2 fois. une fois dans init et une fois dans smf.
Et comme quelqu'un l'a fait remarquer sur lwn ( http://lwn.net/Articles/623527/ ), le pid 1 pourrait très bien ne rien avoir de spécial, et ne pas planter le kernel en cas de crash ( ou se faire relancer par le kernel ).
Car c'est quand même la plus grande peur des gens "si ça plante, mon système plante", alors qu'en pratique, c'est pas le fait d'être PID1 qui nous mets dans la merde. C'est le fait de planter, PID1 ou PID50, à partir du moment ou il gère l'état des processus.
Donc faire 2 trucs, ça sert à juste à rajouter de la complexité. Si SMF se vautre, je suis spas sur d'imaginer l'état du système après ( sauf à avoir l'info poussé dans le kernel sous une forme quelquconque, genre l'équivalent des cgroupes avec des metadonnés , et à ce que smf reprenne l'info du kernel quand ile st relancé, mais on arrive à un truc encore moins portable et poussé dans un truc plus critique depuis l'userspace dans le kernel, alors qu'on essaye surtout l'inverse ).