Les bureaux sont en région parisienne, à la défense ( tour Franklin, sauf erreur de ma part ), mais la boite est ouverte au télétravail (on peut citer Vincent Untz comme superstar bossant depuis Grenoble, par exemple, mais j'en connais d'autre).
Ceci dit, il y a des travaux sur le fait d'avoir la pile tcp/ip en userspace, et avoir des interpréteurs directement lancé à la place du kernel (notamment sur des VM, voir le projet Mirage, erlang on xen, etc).
Donc la question de la séparation kernelspace/userspace est en effet remis en cause. Après tout, pendant longtemps, on a eu les drivers graphiques en dehors du kernel. ( et on a encore des drivers en dehors pour l'USB, par exemple, ou les imprimantes ).
Le type ne dit pas que Linux va disparaître, le mec dit que
Linux va être approprié par RedHat.
ce qui prouve qu'il y a quand même toute une éducation à refaire.
Parce que d'une part, ça fait des années que Red hat contribue sur des tonnes de projets ( http://community.redhat.com/software/ ), ça fait des années que Red hat est dans le top des contributeurs kernels, et du système de base ( gcc, glibc, coreutils, etc ).
Donc si tout d'un coup, la personne s'en rends compte, c'est soit qu'il avait pas la moindre idée de comment c'était fait avant et donc, un manque d'éducation sur la chaine de production, un peu comme le fait qu'on ne sait pas d’où vient la bouffe ou nos chaussures. Ou le fait d'attribuer incorrectement l'origine uniquement au distributeur, auquel cas on peut se poser la question de l'impact de certaines distribs qui se positionnent comme "linux = nous" (je parle d'Ubuntu, pour être clair.. )
systemd est un choix stratégique pour, à priori, amener les
systèmes Linux vers une adoption plus importante dans le
contexte du desktop.
Le terme que tu cherches est peut être "intégration" plus que "adoption".
Ensuite, ouais, Gnome ne sa cache pas de vouloir s'intégrer dans la plateforme, et de s'appuyer sur les APIs existantes pour se focaliser sur les couches les plus hautes. La coopération entre projets libres, c'est aussi ça et Si KDE et GNOME délègue la gestion du suspend à un composant externe, ça fait toujours ça de moins comme code à dupliquer et à corriger 2 fois.
La liberté de bénéficier gratos du travail d'intégration des gens qui font le boulot bien sur. En fait, il a toujours la liberté, c'est juste que l'intégration lui plait pas, donc il doit la refaire. Et c'est plus gratos, faut investir de son temps.
Tu as le droit de te plaindre, mais ça veut pas dire que les gens vont pas te répondre. Le droit de râler s'applique aussi à tes propos, et si tu estimes ça chiant, fait preuve d'un peu d'empathie et dit toi qu'il y a des devs qui se prennent ça pour le moindre changement qu'ils font.
Et si tu te dit que ça n'apporte rien au débat, pose toi la question de savoir ce que redire ce qui a été dit 100 fois apporte aussi.
Alors je rajoute un bémol, il y a des nuances entre "ne fait rien du tout" et "mets tout son pognon dessus". Le desktop pour RH est entre les 2. Il y a un produit ( cf site web, chercher "RHEL Workstation" ), il y a des clients ( cf site web également, genre pixar ). Il y a des gens payés dessus ( cf les gens dont on trouve le nom dans les changelog et les gens payé sur gnome ).
Ensuite, ouais, y a pas besoin d'aller éplucher les rapports donnés à la SEC pour dire que c'est pas le produit qui ramène le plus de pognon ( et ça en ramène assez pour autofinancer l'équipe, d'après le chef de l'équipe Desktop chez eux que j'ai croisé au Guadec à Strasbourg ).
Donc ça pourrait trés bien être un truc sponso par RH et utile sur le desktop.
Le fait est que systemd offre des fonctions utiles pour le serveur:
- le fait de tuer de manière sure un service
- les limitations de ressources via cgroups
- la gestion des containers
- le fait de placer chaque service dans un environnement propre et répétable
- un système de HA rudimentaire (via la relance automatique, chose qu'on demande parfois à un opérateur humain de faire)
- l'activation par socket, ce qui permet de faire du "à la demande", et donc d'augmenter la densité des services par serveur
- l'isolation des services, pour une plus grande sécurité d'un service exposé sur le réseau (PrivatTmp, blacklist de syscall, etc )
C'est des fonctions qui répondent plus à des problématiques "serveur" que des problématiques 'desktop'.
Et il semble que ça requiert un patch non trivial sur le kernel ( des histoires avec openat et chmod entre temps ) et que les discussions pour faire ça dans la glibc n'ont pas aboutit à un patch. Et que les gens de musl semblent pousser aussi pour le support kernel.
Un autre exemple est :
"mkdir a; ln -s a b; rmdir b/"
Et il a donné que 2 exemples, mais je suis sur qu'on peut en trouver des tonnes.
Donc à partir du moment ou le monde Linux se fout globalement de la norme POSIX depuis des années, je trouve assez curieux les gens qui disent "il faut la respecter", et je crois que ton vœu est donc déjà réalisé
Je vois pas ou est marqué "du texte brut" dans ce qui est cité, c'est une interprétation de ta part sur ce que tu estime être clair. Techniquement, du xml serait aussi du texte brut, ça n'a rien de clair en pratique.
C'est marqué "des moyens de communication clair". Des appels RPC définis (exemple, l'API qu'un process doit implémenter pour un filesystem sur le hurd) sont des moyens clairs de communication ( sauf si tu penses que l'API posix, à base de grosso modo les mêmes primitves, n'est pas clair et donc ne respecte pas l'esprit UNIX.
On peut quand même voi comment une simple phrase sorti de son contexte et répété advitam eternam en guise d’épitome d'un ouvrage exposant l'état de l'art de la recherche d'il y a 40 ans dans un domaine bougant à toute vitesse est encore trop compliqué pour que les gens l'utilisent pour exprimer une idée clair.
Je commence à trouver ça curieux qu'un groupe fortement imprégné par l'esprit scientifique en revienne presque à des méthodes shamanique de vénération des textes "anciens" sans avoir le moindre recul vis à vis d'eux et de leur propre position.
Il est mal formulé, mais ce qu'il veut dire, c'est que pour lui, le bash est plus accessible que le C. Ensuite, autant je suis d'accord avec ça pour certaines personnes, autant je suis pas sur que ça soit généralisable d'une part, et si important d'autre part.
C'est pas généralisable car je pense que python serait plus accessible sur le principe que bash, et que du point de vue des nombres de devs, des choses comme javascript ou php serait sans doute plus important, ce qui veut pas dire que c'est une bonne idée. Sur la population ciblé des sysadmins, des choses comme perl ou ruby me semble aussi connu que bash (surtout ruby avec la montée de puppet/chef), et fournisse de meilleurs libs et un écosystème plus haut niveau. Mais quand tu connais que le bash, forcément, tu te dit que ç'est ce qu'il faut utiliser.
Et l'argument est aussi celui qui a été utilisé pour justifier que les softs de l'OLPC soient écrit en python et modifiable par les utilisateurs directement dans l'interface.
Et c'est pas si important d'autre parce que globalement, tout est écrit en autre chose que bash. Le libre n'a pas vraiment été bloqué par le fait que beaucoup de choses étaient en C avant, et j'aurais même tendance à dire que les sysadmins de l'époque des débuts d'unix savaient faire du C, vu le nombre de soft écrit en C à ce moment la par des admins ( typiquement, des trucs comme cron/atd, sendmail, et autres trucs historiques ).
Donc oui, y a des gens pour qui bash est naturel et ils voient ça comme une privation de la liberté de comprendre et d'étudier de la GPL. Mais c'est une privation lié à une limitation de leur savoir sur le moment plus qu'une limitation absolu, donc pour moi, l'argument ne suffit pas à justifier de ne pas changer.
Ce que je retiens, c'est surtout que si ce point de la philosophie unix était important, on tournerais plus sous qnx ou le hurd. Voir même sur darwin, si je me souviens bien.
Voir même celui de NT, qui est une espace de micro noyau aussi, sauf erreur de ma part.
Donc bon, c'est bien joli de citer des textes sacralisés sans les comprendre et sans savoir, mais ça fait quand même passé les gens pour des rigolos.
Je connais un ISV qui voulait avoir systemd sur une base EL6. Mais ensuite, c'est vouloir le beurre et l'argent du beurre, si tu dépends de quelqu'un d'autre pour ta base, tu dépends des choix de l'autre groupe.
Non, je doute que je sous estime le travail de faire une distribution Linux. Si tu vois pas pourquoi, je pense que Google doit pouvoir donner la réponse. ( suffit de chercher à "mageia founders", doit bien y avoir encore mon nom, et sans doute une paire d'interview à gauche à droite à partir de la ).
Maintenant, par abus de langage, je pense qu'il y a confusion entre distribution Linux et distribution.
Si tu distribues des logiciels et que tu vises une intégration, alors tu fait une distribution. Certes, pas une distribution Linux ou un système d'exploitation, mais c'est pas pour rien qu'il y a plusieurs mots et qu'on accole "linux" au bout.
Par exemple, le CPAN parle aussi de distribution pour qualifier un module que tu distribue. Tex et LaTex aussi utilisent le mot.
Tu veux dire que Amazon et Rackspace arriverais à faire mieux ?
Prenons une hypothèse de travail, il y a 2 boites, donc ayant des services commerciaux, qui doivent se partager l'argent des clients, chacune apportant sa part de travail ( qui mérite salaire ), avec d'un coté un provider cloud qui grimpe, de l'autre, le leader mondial de l'open source. Et chacune ayant son idée d'une juste répartition de la part du gâteau.
Est ce que le souci serait pas simplement de pas réussir à s'entendre sur ce qui est une part juste pour les 2, et donc simplement des négociations commerciales, tout bêtement ?
Et comme le support d'HyperV est pas non plus super vieux dans RHEL après tout : https://access.redhat.com/solutions/261453
Et peut être qu'il faut plus dans le kernel pour que ça soit correctement supportable par l'éditeur sur le long terme ( cad sur les 10 à 13 ans de durée de vie de RHEL 6 ou 7, à minima, problématique qui touche pas les distros à durée de vie plus courtes comme Centos, Ubuntu et Suse )
La véritable question, c'est déjà de se poser la question pourquoi tu doit avoir un avis sur systemd ?
C'est quand même un logiciel qui va impacter principalement les gens qui font les distributions plus que les autres, vu que si ça marche, c'est globalement transparent, et ça va pas être différent que d'avoir un avis sur le firewall de la distro ou le gestionnaire de paquet ( et je parle bien du gestionnaire, pas des dépots, car tout les gestionnaires font la même chose au final ).
Mais pour une raison que j'ai pas pigé, tout d'un coup, tout le monde a cru bon avoir un avis sur l'init.
C'est ça la question à se poser, comment une telle panique de masse s'est monté, sur la base de quelques sites webs incorrects, d'articles destinés juste à faire monter les tensions et ce genre de choses ( et je dit pas ça spécialement après avoir relu des trucs sur le #gamergate tout le weekend, mon nouveau développement favori étant : http://deaglenation.tv/ )
Mais je suis pour le fait d'essayer, pleinement. Perso, je l'aurais pas fait comme ça à la base ( ni même refait un projet de distro encore une fois sans avoir du temps libre suffisant pour un temps plein sur le projet ), et je trouve qu'ils s'y prennent comme des manches (l'interface des archives mails est un chouia naze, la transparence du projet est assez mauvaise, cf gitlab non publique, cf le fait qu'on sait pas qui est derrière les VUA de base, etc ) mais en effet, ils essayent.
Mais j'ai beau penser que c'est bien d'essayer, ça veut pas dire qu'ils sont à l'abri de pointer les éléments qui me semblent être ridicule, surtout après avoir dit en long, en large et en travers que tout le monde est derrière eux.
Et c'est pas vraiment le cas. Pourtant, 900 personnes, chacune donnant 5 euros par mois, ça paye un dev à temps plein. Et Devuan a déjà la structure pour gérer ça. Pourquoi ça n'arrive pas ?
Et si il y a plus de supporters que les 900 VUA, ça permet de payer plus de monde…
Alors très franchement, autant je suis en faveur d'avoir des gens qui agissent, autant les chiffres me paraissent ridicules.
Si il y a bien 932 personnes ( ce que je suppose être les gens inscrits sur la ML ), alors c'est rien face à tout les utilisateurs du libre ( si ubuntu se réclament d'une 20aine de million d'utilisateur, que Fedora va dans le même ordre de Magnitude et que RH dépasse le milliard de dollar en chiffres d'affaire ).
Ensuite, si sur les 932, y en a serais que 1% qui bosse ( ie 10 ), ça aurait déjà du produire bien plus de choses. Mageia, qui était à la base un fork de Mandriva, avait en moins de 4 mois déjà un système de build complet, une structure de gouvernance débattu, une présence juridique via une assoce, un site web correct, et une alpha en guide de MVP en 5 à 6 mois, avec des volontaires pour la faire aussi.
Donc j'ai d'énormes doutes sur les chiffres, et si les chiffres sont exactes, le nombre de dilettante est relativement élevé et un peu triste. Ils font quoi tout ces gens qui se réclament comme étant vétérans UNIX, ie par définition, compétent en admin système ?
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.
[^] # Re: Empire français
Posté par Misc (site web personnel) . En réponse au journal SUSE Linux se prépare à recruter 150 personnes !. Évalué à 2.
Les bureaux sont en région parisienne, à la défense ( tour Franklin, sauf erreur de ma part ), mais la boite est ouverte au télétravail (on peut citer Vincent Untz comme superstar bossant depuis Grenoble, par exemple, mais j'en connais d'autre).
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3.
Ceci dit, il y a des travaux sur le fait d'avoir la pile tcp/ip en userspace, et avoir des interpréteurs directement lancé à la place du kernel (notamment sur des VM, voir le projet Mirage, erlang on xen, etc).
Donc la question de la séparation kernelspace/userspace est en effet remis en cause. Après tout, pendant longtemps, on a eu les drivers graphiques en dehors du kernel. ( et on a encore des drivers en dehors pour l'USB, par exemple, ou les imprimantes ).
[^] # Re: Z spotted
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 2.
ce qui prouve qu'il y a quand même toute une éducation à refaire.
Parce que d'une part, ça fait des années que Red hat contribue sur des tonnes de projets ( http://community.redhat.com/software/ ), ça fait des années que Red hat est dans le top des contributeurs kernels, et du système de base ( gcc, glibc, coreutils, etc ).
Donc si tout d'un coup, la personne s'en rends compte, c'est soit qu'il avait pas la moindre idée de comment c'était fait avant et donc, un manque d'éducation sur la chaine de production, un peu comme le fait qu'on ne sait pas d’où vient la bouffe ou nos chaussures. Ou le fait d'attribuer incorrectement l'origine uniquement au distributeur, auquel cas on peut se poser la question de l'impact de certaines distribs qui se positionnent comme "linux = nous" (je parle d'Ubuntu, pour être clair.. )
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 7.
Le terme que tu cherches est peut être "intégration" plus que "adoption".
Ensuite, ouais, Gnome ne sa cache pas de vouloir s'intégrer dans la plateforme, et de s'appuyer sur les APIs existantes pour se focaliser sur les couches les plus hautes. La coopération entre projets libres, c'est aussi ça et Si KDE et GNOME délègue la gestion du suspend à un composant externe, ça fait toujours ça de moins comme code à dupliquer et à corriger 2 fois.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 4. Dernière modification le 28 février 2015 à 11:09.
La liberté de bénéficier gratos du travail d'intégration des gens qui font le boulot bien sur. En fait, il a toujours la liberté, c'est juste que l'intégration lui plait pas, donc il doit la refaire. Et c'est plus gratos, faut investir de son temps.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3.
Tu as le droit de te plaindre, mais ça veut pas dire que les gens vont pas te répondre. Le droit de râler s'applique aussi à tes propos, et si tu estimes ça chiant, fait preuve d'un peu d'empathie et dit toi qu'il y a des devs qui se prennent ça pour le moindre changement qu'ils font.
Et si tu te dit que ça n'apporte rien au débat, pose toi la question de savoir ce que redire ce qui a été dit 100 fois apporte aussi.
[^] # Re: Cela confirme mon avis sur cette brique système: sympa sur les dekstop , incensée sur un serveur
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 7.
Alors je rajoute un bémol, il y a des nuances entre "ne fait rien du tout" et "mets tout son pognon dessus". Le desktop pour RH est entre les 2. Il y a un produit ( cf site web, chercher "RHEL Workstation" ), il y a des clients ( cf site web également, genre pixar ). Il y a des gens payés dessus ( cf les gens dont on trouve le nom dans les changelog et les gens payé sur gnome ).
Ensuite, ouais, y a pas besoin d'aller éplucher les rapports donnés à la SEC pour dire que c'est pas le produit qui ramène le plus de pognon ( et ça en ramène assez pour autofinancer l'équipe, d'après le chef de l'équipe Desktop chez eux que j'ai croisé au Guadec à Strasbourg ).
Donc ça pourrait trés bien être un truc sponso par RH et utile sur le desktop.
Le fait est que systemd offre des fonctions utiles pour le serveur:
- le fait de tuer de manière sure un service
- les limitations de ressources via cgroups
- la gestion des containers
- le fait de placer chaque service dans un environnement propre et répétable
- un système de HA rudimentaire (via la relance automatique, chose qu'on demande parfois à un opérateur humain de faire)
- l'activation par socket, ce qui permet de faire du "à la demande", et donc d'augmenter la densité des services par serveur
- l'isolation des services, pour une plus grande sécurité d'un service exposé sur le réseau (PrivatTmp, blacklist de syscall, etc )
C'est des fonctions qui répondent plus à des problématiques "serveur" que des problématiques 'desktop'.
[^] # Re: Quelqu'un devrait modifier l'API de linux pour autre chose que POSIX...
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 10.
Mais le fait est que de manière amusante, aucune distrib Linux moderne n'est certifié POSIX, et que le kernel ne le permet pas.
On a eu la discussion au travail, et les exemples cités sont assez obscures, mais montre bien le souci.
Par exemple, posix defini O_SEARCH
http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
Et il semble que ça requiert un patch non trivial sur le kernel ( des histoires avec openat et chmod entre temps ) et que les discussions pour faire ça dans la glibc n'ont pas aboutit à un patch. Et que les gens de musl semblent pousser aussi pour le support kernel.
Un autre exemple est :
"mkdir a; ln -s a b; rmdir b/"
Sur linux, ça fait un message d'erreur.
D'après la norme POSIX, le / indique de s'appliquer à la cible du symlink :
http://cygwin.com/ml/cygwin/2005-04/msg00566.html
https://unix.stackexchange.com/questions/29769/trailing-slashes-on-symbolic-links-to-directories
Et sur OS X, qui est certifié Posix, ça passe.
Et il a donné que 2 exemples, mais je suis sur qu'on peut en trouver des tonnes.
Donc à partir du moment ou le monde Linux se fout globalement de la norme POSIX depuis des années, je trouve assez curieux les gens qui disent "il faut la respecter", et je crois que ton vœu est donc déjà réalisé
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 5.
Je vois pas ou est marqué "du texte brut" dans ce qui est cité, c'est une interprétation de ta part sur ce que tu estime être clair. Techniquement, du xml serait aussi du texte brut, ça n'a rien de clair en pratique.
C'est marqué "des moyens de communication clair". Des appels RPC définis (exemple, l'API qu'un process doit implémenter pour un filesystem sur le hurd) sont des moyens clairs de communication ( sauf si tu penses que l'API posix, à base de grosso modo les mêmes primitves, n'est pas clair et donc ne respecte pas l'esprit UNIX.
On peut quand même voi comment une simple phrase sorti de son contexte et répété advitam eternam en guise d’épitome d'un ouvrage exposant l'état de l'art de la recherche d'il y a 40 ans dans un domaine bougant à toute vitesse est encore trop compliqué pour que les gens l'utilisent pour exprimer une idée clair.
Je commence à trouver ça curieux qu'un groupe fortement imprégné par l'esprit scientifique en revienne presque à des méthodes shamanique de vénération des textes "anciens" sans avoir le moindre recul vis à vis d'eux et de leur propre position.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 10.
Il est mal formulé, mais ce qu'il veut dire, c'est que pour lui, le bash est plus accessible que le C. Ensuite, autant je suis d'accord avec ça pour certaines personnes, autant je suis pas sur que ça soit généralisable d'une part, et si important d'autre part.
C'est pas généralisable car je pense que python serait plus accessible sur le principe que bash, et que du point de vue des nombres de devs, des choses comme javascript ou php serait sans doute plus important, ce qui veut pas dire que c'est une bonne idée. Sur la population ciblé des sysadmins, des choses comme perl ou ruby me semble aussi connu que bash (surtout ruby avec la montée de puppet/chef), et fournisse de meilleurs libs et un écosystème plus haut niveau. Mais quand tu connais que le bash, forcément, tu te dit que ç'est ce qu'il faut utiliser.
Et l'argument est aussi celui qui a été utilisé pour justifier que les softs de l'OLPC soient écrit en python et modifiable par les utilisateurs directement dans l'interface.
Et c'est pas si important d'autre parce que globalement, tout est écrit en autre chose que bash. Le libre n'a pas vraiment été bloqué par le fait que beaucoup de choses étaient en C avant, et j'aurais même tendance à dire que les sysadmins de l'époque des débuts d'unix savaient faire du C, vu le nombre de soft écrit en C à ce moment la par des admins ( typiquement, des trucs comme cron/atd, sendmail, et autres trucs historiques ).
Donc oui, y a des gens pour qui bash est naturel et ils voient ça comme une privation de la liberté de comprendre et d'étudier de la GPL. Mais c'est une privation lié à une limitation de leur savoir sur le moment plus qu'une limitation absolu, donc pour moi, l'argument ne suffit pas à justifier de ne pas changer.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 5. Dernière modification le 26 février 2015 à 10:58.
Ce que je retiens, c'est surtout que si ce point de la philosophie unix était important, on tournerais plus sous qnx ou le hurd. Voir même sur darwin, si je me souviens bien.
Voir même celui de NT, qui est une espace de micro noyau aussi, sauf erreur de ma part.
Donc bon, c'est bien joli de citer des textes sacralisés sans les comprendre et sans savoir, mais ça fait quand même passé les gens pour des rigolos.
[^] # Re: LTS ? Systèmes embarqués nécessitant un vieu kernel ?
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 2.
Je connais un ISV qui voulait avoir systemd sur une base EL6. Mais ensuite, c'est vouloir le beurre et l'argent du beurre, si tu dépends de quelqu'un d'autre pour ta base, tu dépends des choix de l'autre groupe.
[^] # Re: Ahh linuxfr
Posté par Misc (site web personnel) . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 4.
Non, je doute que je sous estime le travail de faire une distribution Linux. Si tu vois pas pourquoi, je pense que Google doit pouvoir donner la réponse. ( suffit de chercher à "mageia founders", doit bien y avoir encore mon nom, et sans doute une paire d'interview à gauche à droite à partir de la ).
Maintenant, par abus de langage, je pense qu'il y a confusion entre distribution Linux et distribution.
Si tu distribues des logiciels et que tu vises une intégration, alors tu fait une distribution. Certes, pas une distribution Linux ou un système d'exploitation, mais c'est pas pour rien qu'il y a plusieurs mots et qu'on accole "linux" au bout.
Par exemple, le CPAN parle aussi de distribution pour qualifier un module que tu distribue. Tex et LaTex aussi utilisent le mot.
[^] # Re: Bureau au Canada ?
Posté par Misc (site web personnel) . En réponse au journal SUSE Linux se prépare à recruter 150 personnes !. Évalué à 2.
Red hat a un bureau au Canada (même plusieurs, un à Montreal, techniquement chez Enovance, et un à Toronto).
J'avais croisé un avant vente de Suse lors d'un meetup de Linux Montreal, donc je suppose que Suse a une présence la bas.
Mais sinon, le travail en remote existe aussi.
[^] # Re: simple
Posté par Misc (site web personnel) . En réponse au journal Redhat, la grande perdante de la virtualisation Microsoft Azure ?. Évalué à 2.
Tu veux dire que Amazon et Rackspace arriverais à faire mieux ?
Prenons une hypothèse de travail, il y a 2 boites, donc ayant des services commerciaux, qui doivent se partager l'argent des clients, chacune apportant sa part de travail ( qui mérite salaire ), avec d'un coté un provider cloud qui grimpe, de l'autre, le leader mondial de l'open source. Et chacune ayant son idée d'une juste répartition de la part du gâteau.
Est ce que le souci serait pas simplement de pas réussir à s'entendre sur ce qui est une part juste pour les 2, et donc simplement des négociations commerciales, tout bêtement ?
Un autre raison possible pourrait être une question aussi de support de l'OS sous jacent à un niveau de qualité satisfaisant. Red hat a une certification pour les providers de cloud :
http://www.redhat.com/fr/resources/red-hat-certified-cloud-provider-management-architecture-service
Et comme le support d'HyperV est pas non plus super vieux dans RHEL après tout : https://access.redhat.com/solutions/261453
Et peut être qu'il faut plus dans le kernel pour que ça soit correctement supportable par l'éditeur sur le long terme ( cad sur les 10 à 13 ans de durée de vie de RHEL 6 ou 7, à minima, problématique qui touche pas les distros à durée de vie plus courtes comme Centos, Ubuntu et Suse )
[^] # Re: Ahh linuxfr
Posté par Misc (site web personnel) . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 1.
Dans une vision ou tu fait des paquets et de l'intégration ( ie, ton exemple de rajouter un script d'init et des daemons ), alors tu fait une distro.
Que ta distro soit "Debian + mon paquet maison" ça change rien, c'est pas différent de "ma ubuntu + un fond d'ecran"
[^] # Re: Ahh linuxfr
Posté par Misc (site web personnel) . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 6.
La véritable question, c'est déjà de se poser la question pourquoi tu doit avoir un avis sur systemd ?
C'est quand même un logiciel qui va impacter principalement les gens qui font les distributions plus que les autres, vu que si ça marche, c'est globalement transparent, et ça va pas être différent que d'avoir un avis sur le firewall de la distro ou le gestionnaire de paquet ( et je parle bien du gestionnaire, pas des dépots, car tout les gestionnaires font la même chose au final ).
Mais pour une raison que j'ai pas pigé, tout d'un coup, tout le monde a cru bon avoir un avis sur l'init.
C'est ça la question à se poser, comment une telle panique de masse s'est monté, sur la base de quelques sites webs incorrects, d'articles destinés juste à faire monter les tensions et ce genre de choses ( et je dit pas ça spécialement après avoir relu des trucs sur le #gamergate tout le weekend, mon nouveau développement favori étant : http://deaglenation.tv/ )
[^] # Re: Collectif de 932 personnes ?
Posté par Misc (site web personnel) . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 4.
Mais je suis pour le fait d'essayer, pleinement. Perso, je l'aurais pas fait comme ça à la base ( ni même refait un projet de distro encore une fois sans avoir du temps libre suffisant pour un temps plein sur le projet ), et je trouve qu'ils s'y prennent comme des manches (l'interface des archives mails est un chouia naze, la transparence du projet est assez mauvaise, cf gitlab non publique, cf le fait qu'on sait pas qui est derrière les VUA de base, etc ) mais en effet, ils essayent.
Mais j'ai beau penser que c'est bien d'essayer, ça veut pas dire qu'ils sont à l'abri de pointer les éléments qui me semblent être ridicule, surtout après avoir dit en long, en large et en travers que tout le monde est derrière eux.
Et c'est pas vraiment le cas. Pourtant, 900 personnes, chacune donnant 5 euros par mois, ça paye un dev à temps plein. Et Devuan a déjà la structure pour gérer ça. Pourquoi ça n'arrive pas ?
Et si il y a plus de supporters que les 900 VUA, ça permet de payer plus de monde…
[^] # Re: Collectif de 932 personnes ?
Posté par Misc (site web personnel) . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 1.
Donc si une personne arrive à faire 106 paquets, le travail des 931 autres est ou ?
Même sur la liste, y a pas le trafic de 930 personnes. Est ce que les 930 personnes, c'est pas 700 lurkers et 200 gens qui postent ?
Je crois pas que ça aide le projet que de donner des chiffres trompeurs, vraiment.
# Collectif de 932 personnes ?
Posté par Misc (site web personnel) . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 6.
Alors très franchement, autant je suis en faveur d'avoir des gens qui agissent, autant les chiffres me paraissent ridicules.
Si il y a bien 932 personnes ( ce que je suppose être les gens inscrits sur la ML ), alors c'est rien face à tout les utilisateurs du libre ( si ubuntu se réclament d'une 20aine de million d'utilisateur, que Fedora va dans le même ordre de Magnitude et que RH dépasse le milliard de dollar en chiffres d'affaire ).
Ensuite, si sur les 932, y en a serais que 1% qui bosse ( ie 10 ), ça aurait déjà du produire bien plus de choses. Mageia, qui était à la base un fork de Mandriva, avait en moins de 4 mois déjà un système de build complet, une structure de gouvernance débattu, une présence juridique via une assoce, un site web correct, et une alpha en guide de MVP en 5 à 6 mois, avec des volontaires pour la faire aussi.
Donc j'ai d'énormes doutes sur les chiffres, et si les chiffres sont exactes, le nombre de dilettante est relativement élevé et un peu triste. Ils font quoi tout ces gens qui se réclament comme étant vétérans UNIX, ie par définition, compétent en admin système ?
[^] # Re: .
Posté par Misc (site web personnel) . En réponse au journal systemd: je me lance. Évalué à 9.
Ca me parait une bonne idée, oui, est ce que tu peux ouvrir un bug sur le sujet ?
[^] # Re: Pas 'dredi
Posté par Misc (site web personnel) . En réponse au journal Faille de sécurité glibc. Évalué à 2.
Ouais, le vrai risque est de voir qu'une fonction oublié ou obscur pose souci. Mais pour le moment, c'est pas la catastrophe non plus.
[^] # 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.