Au cas par cas, tu veux dire que les serveurs ont pas tous besoin d'être mis à jour ou d'avoir ntp, ssh et les mêmes clés ssh ? Qu'il y a pas le même besoin de mettre un motd, qu'ils ont des systémes de monitoring différents et totalement non factorisable ?
parce que sinon, tu peux déployer un outil pour gerer les points communs, et tant pis pour le reste.
Comme dit plus haut, je m'en sert sur une infra de moins de 10 machines, et le simple fait de passer par puppet et svn permet à tout le monde de suivre les modifs, et de réagir si un truc est cassé ( genre, revert, genre, regarder le diff ).
Perso, j'ai migré de cfengine 2 à puppet, et je suis fan de puppet. On l'utilise au taf sur 1700 serveurs, je l'utilise sur mes 6 serveurs, et sur les serveurs de Mageia ( d'ailleurs, le dépot est publique : http://svnweb.mageia.org/adm/ , si tu veux voir une archi plus complète qu'un hello world ). De ce que j'ai vu au FOSDEM, c'est utilisé par Debian, par Fedora, par Wikimedia, entre autres références plus prestigieuses.
Mais comme je pense que plein de gens vont te dire du bien de Puppet, je vais vite me focaliser par honnêteté sur les soucis.
Le plus gros souci de puppet, c'est que la configuration simple ne va pas tenir la charge ( genre, sqlite + serveur par défaut webrick ), mais ça se déploie vite.
Donc tu va très vite devoir te pencher sur les soucis de scalability, mais c'est amplement couvert sur le web ( hélas pas de façon très intégré à la distribution, mais y a du travail avec ça en cours )
Autre souci, c'est du ruby, donc une consommation mémoire supérieur à celle de cfengine, et pas aussi rapide à converger ( mais ceci dit, je n'ai pas vraiment vu de problème avec ça au vue des machines que j'ai , mais si le but est d'avoir des milliers de mini vm, ça peut être bloquant ).
Enfin, il faut bien voir que puppet est un langage de description, pas de programmation. Ce qui peut faire grincer des dents si tu ne le prends pas comme tel, les choix qui ont été fait sont très opiniatre, et pareil, tout le monde n'aime pas.
À contrario, chef a l'air plus difficile à déployer, mais permet plus de choses. Il utilise directement ruby pour décrire les systèmes ( ce que puppet peut faire aussi, mais c'est pas très employé de ce que je sais ). Chef est plus apte à servir de brique de base pour faire un outil de gestion d'infrastructure ( genre, une interface personnalisé ). Il y a un article très bien dans Linux Mag sur le sujet, je t'invite à regarder.
Et pour finir, si tu as du RH/Centos, l'outil Cloudforms que Red hat va sortir devrait s'appuyer sur puppet, ce qui garanti que le support de puppet ne devrait pas être trop mauvais ( alors qu'il y a pas de paquet rpm de chef pour le moment en dehors de celui d'opscode, ce qui me fait sauter au plafond en tant que contributeur à une distribution ).
Si je regarde les différents noms dans le Changelog, on voit quand même des emails @sco.com, @fujitsu.com @ibm.com, @juniper.net, @openwall.net
Les releases sont fait à part. Je sais pas ou est le cvs, et j'avais déjà du mal à savoir ce qu'on peut faire avec des branches quand j'avais à l'utiliser, c'est pas maintenant que j'utilise plus que je vais pouvoir le dire. La seul mention que je trouve est un cvs readonly, qui est géré par le dit Damien.
Donc peut être que le cvs est aussi à part du projet principal.
djm est commiter openbsd. dtucker est aussi commiter sur openssh, et sur openntpd ( vu qu'il fait pareil, la portabilité ). Mais il se présente comme "helper on debian" http://www.advogato.org/person/dtucker/.
Tim rice est consultant unix, et semble faire autre chose que du bsd.
Donc je ne suis pas sur qu'on puisse dire que le taf de portabilité est fait par les devs openbsd, vu qu'on trouve des infos un chouia flou.
D'un coté, c'est 2 projets séparés, avec des correctifs qui sont venus de partout, mais de l'autre, les gens qui committent sur le 2me ont aussi les droits sur le premier, ce qui fait qu'il s'agit de facto de codeur openbsd.
Une vraie réponse serait de faire le compte des modifs de la version portable, et d'ou viennent les patchs.
J'attends quand même qu'on me montre la différence entre "on doit coder un serveur ssh, on va se servr des fonctions présentes que sur notre version de BSD et laisser le reste du monde sur une version portable ou adopter nos changements", et "on va coder un demon de gestion du boot, on va se servir des fonctiones présentes sur notre noyau et laisser le reste du monde se demerder".
J'avais trouvé normal la réaction de l'équipe d'openbsd d'utiliser leurs fonctionnalités autant que possible et de restreindre leur focus et le code pour leur os. C'est naturel d'utiliser les avancés de leur plateforme. C'est aussi naturel de vouloir avoir un code minimal, et je pense que Theo et Lennart seraient d'accord sur le fait que la portabilité inter unix peut rendre le code moche.
Donc venir sortir Theo de raadt comme exemple de chantre de la portabilité, faut pas déconner. Sur ce point la, je pense qu'il rejoint la plupart des devs, à savoir qu'il a un seuil de tolérance à ce qu'il peut accepter au nom de la portabilité.
Quand à l'avis d'Ulrich, il était surtout motivé par les trucs "exotiques" d'arm, comme les histoires d'alignements, le fait que ça soit le bordel sur les jeux d'instructions, et les types de procs, etc. Linus rale aussi sur les SOC et tout le foutoir que c'est, mais personne ne remets en cause son avis. Et même si je suis ni d'accord avec la forme des échanges sur internet d'Ulrich, ni avec la conclusion qu'il en tire, je pense qu'on peut au moins se dire que sur le fond, ses arguments n'étaient pas totalement creux.
En fait, je me disait pareil que toi, puis j'ai fait les comptes. Y a 4000 personnes dans la boite en 2010 ( source wikipedia ). La boite a 19 ans, des gens ont du partir, venir, on va miser sur 6000 personnes qui sont passés par la ( estimation à la louche ). À supposer 20% de personnes impliqués dans le libre et donc à même d'être connu du public linuxfrien, ça fait 800 personnes.
Sur les 800, on va compter parmi les gens avec un caractère bien trempé qui ont fait les gros titres sur Linuxfr :
- Jeff Johnson
- Ulrich Drepper
- Lennart Poettering ( et je tiens à préciser que moi, j'aime bien Lennart )
on peut rajouter une paire de gens de GNOME, un ou deux codeurs de yum, visons large, ça va faire 10 personnes.
10 sur 800. ça fait pas grand chose.
La question est plus de savoir si c'est pas le logiciel libre qui fait qu'on doit avoir son petit caractère , que ça soit par construction ( l'exemple revient assez souvent dans les débats sur les femmes et le libre ), ou parce que tout se passe sur internet. Et auquel cas, en effet, on a l'impression statistique que tout les psychopathes sont chez Red Hat, vu qu'une grande variété de codeurs sont chez eux. À supposer qu'une personne compétente mais anti social arrive à devenir grand mamamouchi d'un projet, il y a des chances que les compétences pures compensent le coté anti social, et donc qu'il se retrouve à se faire embaucher pour bosser sur le dit projet , ie, chez une société qui contribue au libre.
En effet, personne de logique ne va embaucher un anti social pour bosser avec ses équipes. Mais si la personne est déjà en place, avec des équipes externes qui l'acceptent, alors la pénalité est moindre. Donc la compétence éclipse le coté antisocial.
Je doute fort que tu puisses tirer la nuit sans te faire remarquer, et je doute fort que tu te fatigues à monter sur ton toit de maison la nuit ( en tout cas, moi, je le ferais pas ), ou que tu puisses monter tout court dans le cas d'un immeuble.
Pour être rentable, je pense qu'il faut viser les zones fortement peuplés, ie les grandes villes, la ou tu va choper 40 à 50 signals wifis depuis le toit, et d'avoir de la chance.
Et sérieusement, si un truc un peu silencieux se pose sur le toit de mon immeuble, je le verrais pas, et je doute l'entendre. Et si tu veux être malin, tu peux rajouter des stickers "meteo france", ou "si vous trouvez ce drone de mesure meteo, merci de contacter untel sur email@example.org, ou de le placer dans un colis à destination de XXXX".
( sinon, dans la catégorie "truc à faire", ç'est de mettre l'appareil dans une moto de livraison de pizza, comme suggérer un jour par quelqu'un du projet openbmap )
Dans mon souvenir, l'eglibc est un fork de la glibc, et surtout parce que Ulrich Drepper n'est pas super diplomate ( genre, "arm, c'est merdique", etc ).
Et j'ai pas le sentiment qu'on retrouve beaucoup d'outil de l'embarqué ( busybox, ulibc, framebuffer ) vers le desktop, à part java ( qui je rappelle à la base, vient du projet oak dans les années 90 )
Si un missile tomahawk coute 650 000 euros, je pense pas qu'un missile sol air soit bien moins cher. Même à 1000 euros le missile, un drone fait maison couterait vachement moins cher. Autant dire que le combat est financièrement perdu.
Ça irait sans doute moins cher d'aller avec un hélico pour déstabiliser les drones, même si ça va douiller niveau carburant.
Et un programme sans menu, c'est un programme qui existe pas pour la plupart des gens ( et une regression pour la plupart ). C'est pas pour rien que tout les softs du monde mettent un menu dans windows ( menu pourri au passage ).
Un programme pas intégré ( au hasard, un rippeur de cd ), c'est un programme qui marche pas pour certains ( si le soft n'apparait pas quand on demande à ripper, ou si les programmes se marchent dessus ).
Un programme mal intégré, ça peut être aussi un truc tout con comme un soft qui a besoin d'un module kernel ( genre vbox ), et donc qui a besoin des droits admins ( et de certaines APIs qu'on devrait pas donner à un programme 3rd party, AMHA ).
L'intégration, c'est aussi la gestion des mimetypes. C'est faisable, vu qu'android arrive à le faire via le systéme d'intent, et pourtant, y a encore des programmes qui le font pas correctement, genre, carcast et les liens itpc, ce qui rends l'ajout de podcast complexes.
Les gens prennent l'intégration pour acquise, mais je pense qu'il faut vraiment participer à une distribution pour comprendre ce que ça recouvre sous Linux. Donc je ne peux que inviter les gens à venir voir les choses du coté du distributeur pour mieux comprendre.
La théorie, c'est aussi "les gens sont capables de gérer ça correctement et rien de mal ne va arriver en général".
En pratique, ça passe, jusqu'à ce que ça casse.
Très franchement, moi, je suis pour, vu que si quelqu'un vient me râler dessus, je vais pouvoir dire "pas ma faute" ( manquerais plus que je sois responsable de ce que je peux pas gérer, faut pas déconner ) ou "faut plus de moyen" ( parce que bon, si je dois être capable de gérer les macs, les pcs, les ipads, les tablettes androids, il me faut soit une formation, soit au moins le matos pour que je puisse jouer avec ).
Et faut bien se rendre compte que si les boites filent du matos aux gens, c'est bien parce qu'elles sont obligés ( pourquoi, comment, je sais pas ). Si on peut économiser sur le budget informatique, on le fait en général, et on a pas attendu l'iPad et les smartphones pour avoir des appareils qu'on peut amener ( au hasard, les pc portables qu'une majorité d'étudiants ont depuis 10 ans ).
En même temps, c'est normal, vu que Ubuntu cherche à se placer comme plateforme.
On vérifie :
- un public non réticent à l'idée de payer, c'est fait ( cf ubuntu one )
- une infrastructure pour compiler, distribuer et gérer tout le projet, c'est fait ( les ppas + launchpad )
- des cours pour apprendre à utiliser la plateforme, c'est fait ( genre, la doc python par défaut depuis 8 ans, cours sur irc )
- de la pub autour de ça, c'est fait ( http://www.jonobacon.org/2010/01/30/connecting-the-opportunistic-dots/ )
- une interface adapté, c'est fait ( http://www.ubuntu.com/ubuntu/features/ubuntu-software-centre )
Donc oui, Canonical écoute les développeurs commerciaux, vu qu'ils veulent que ça devienne des partenaires.
Microsoft a fait pareil, Apple a fait pareil.
Ce qui va arriver, c'est qu'au début, on va avoir des applis ultrasimples. Ensuite, le marché va être saturé, donc les applications vont devoir se distinguer. Se distinguer, c'est soit :
- offrir des features encore inconnues de tous.
- offrir les features encore inconnues des utilisateurs.
Le premier est dur. Le deuxième est simple, il suffit de prendre les features des autres. Ce qui fait que tu arrives à prendre les utilisateurs du premier marché, et du second.
Donc au bout d'un moment, pour grandir, tu doit offrir plus de fonctionnalités. Le marché étant supposé saturé, si tu le fait pas, quelqu'un le fera à ta place. Donc après un temps, on se retrouve à une situation gérable.
Suffit de voir la tendance dans les téléphones. Les gens utilisent plus "un smartphone qui fait tout", ou "un téléphone, un palm pilot, un lecteur mp3, un ebook reader et une gameboy" ?
Ou dans les IDEs, est ce que les gens vont plus vers eclipse, visual studio ou vers "je choisis mon compilo, mon editeur, mon debuggeur, mon analyseur de code et mon linker". Il suffit de voir la centaine d'entreprise dans le consortium eclipse pour voir ou l’intérêt commerciale se situe.
Une grande partie des gens veulent visiblement du tout intégré. Par exemple, pas avoir 1 logiciel pour lire chaque type de fichier multimedia, ne pas avoir un soft pour acheter de la musique, un pour les films, un pour transférer la musique, un pour les ebooks, etc. C'est relativement logique de pas vouloir passer trop de temps quand on n'est de toute façon pas capable d'apprécier les différences ( contrairement à quelqu'un qui est déjà plus expert et qui va passer du temps sur ça )
Et avant d'avoir des suites bureautiques, on a eu des applis séparés. Du visicalc, du word, du presenter. Et c'est quand les boites sont arrivés qu'on est passé d'un marché ou c'était facile de faire un petit soft ( genre, un shareware ) à un marché ou les plus gros dominent.
Et les plus gros dominent car ils ont plus de force de frappe publicitaires, plus de moyens, etc
Non, faut rajouter la propriété "ressources". C'est faisable d'avoir tout ça avec des ressources infinis. Mais tu peux pas avec des ressources limités, sachant qu'il y a plus de gens qui veulent faire du code que de gens qui veulent faire des paquets ou de la QA.
Dans le monde windows, un projet, c'est un tout, tu as les devs ( ou plutot, l'éditeur, ça va d'une équipe de 1 à une boite entière ), qui fait l'installeur, et la QA, et la traduction.
Dans le monde du libre, les codeurs font que le code, parfois des gens débarquent pour traduire. La QA est parfois faite par les codeurs, parfois faite par les utilisateurs, souvent les 2, assez souvent sans grand formalisme ( sous windows aussi, je précise, ça dépend plus de bénévole vs gens payés pour ).
La distribution est minimale pour les projets libres en général ( il y a plus de gens qui font "je tag dans git et voilou" que de projet comme mozilla ). Et la ou l'intégration dans windows est aussi souvent minimal ( exemple, la gestion des menus, l'intégration avec d'autres logiciels, etc ), sous Linux, elle est plus riche et représente une valeur ajouté ( à mon sens ).
Le vrai souci est que les distros linux sont faites par des sysadmins, qui donc répondent à leur problématique. Les developpeurs font le code, qui réponds à leur besoin ( genre, ne pas se faire chier avec une ABI ), certains ont fait leur systéme de paquets ( gems, jar, etc ) pour répondre à leur besoin.
Les utilisateurs bureautiques typiques, ils font rien, trop l'habitude qu'on leur file tout cuit le taf. Il y a pas besoin de savoir comment marche l'ordinateur pour s'en servir ( au contraire de coder ou d'administrer ), donc les gens ne savent pas. Donc forcément, y a que des boites commerciales qui répondent à leur besoin, car c'est globalement la seule chose qu'on va réussir à avoir de la part de la vaste majorité d'un point de vue, de l'argent.
Donc c'est le modèle même du libre et son économie contributive qui ne va pas au grand publique actuel, au moins du point de vue logiciel. Et je précise logiciel car si on prends wikipedia, on voit que ça marche pas trop mal, mais surtout parce que c'est atrocement simple de contribuer.
Bien sur, je suis totalement partial à ce sujet, mais je pense que si c'était si bien, les gens auraient adopté ça en masse. On a beau dire "les distros verrouillent", les distros sont aussi indépendantes, et si tout le monde a bloqué, c'est pas une concertation venu d'une cabale secrète, c'est bien que chaque distro a indépendamment dit "y a un souci".
[^] # Re: Pertinance ?
Posté par Misc (site web personnel) . En réponse au journal Jouer au ptit chef ou à la poupée ?. Évalué à 4.
"c'est une compétence qui s'arrache sur le marché, donc ça permet de te recaser plus facilement"
[^] # Re: Cloudify
Posté par Misc (site web personnel) . En réponse au journal Jouer au ptit chef ou à la poupée ?. Évalué à 2.
J'arrive pas à trouver le code, c'est écrit en quoi ?
[^] # Re: Pertinance ?
Posté par Misc (site web personnel) . En réponse au journal Jouer au ptit chef ou à la poupée ?. Évalué à 3.
Au cas par cas, tu veux dire que les serveurs ont pas tous besoin d'être mis à jour ou d'avoir ntp, ssh et les mêmes clés ssh ? Qu'il y a pas le même besoin de mettre un motd, qu'ils ont des systémes de monitoring différents et totalement non factorisable ?
parce que sinon, tu peux déployer un outil pour gerer les points communs, et tant pis pour le reste.
Comme dit plus haut, je m'en sert sur une infra de moins de 10 machines, et le simple fait de passer par puppet et svn permet à tout le monde de suivre les modifs, et de réagir si un truc est cassé ( genre, revert, genre, regarder le diff ).
# Fan de puppet
Posté par Misc (site web personnel) . En réponse au journal Jouer au ptit chef ou à la poupée ?. Évalué à 10.
Perso, j'ai migré de cfengine 2 à puppet, et je suis fan de puppet. On l'utilise au taf sur 1700 serveurs, je l'utilise sur mes 6 serveurs, et sur les serveurs de Mageia ( d'ailleurs, le dépot est publique : http://svnweb.mageia.org/adm/ , si tu veux voir une archi plus complète qu'un hello world ). De ce que j'ai vu au FOSDEM, c'est utilisé par Debian, par Fedora, par Wikimedia, entre autres références plus prestigieuses.
Mais comme je pense que plein de gens vont te dire du bien de Puppet, je vais vite me focaliser par honnêteté sur les soucis.
Le plus gros souci de puppet, c'est que la configuration simple ne va pas tenir la charge ( genre, sqlite + serveur par défaut webrick ), mais ça se déploie vite.
Donc tu va très vite devoir te pencher sur les soucis de scalability, mais c'est amplement couvert sur le web ( hélas pas de façon très intégré à la distribution, mais y a du travail avec ça en cours )
Autre souci, c'est du ruby, donc une consommation mémoire supérieur à celle de cfengine, et pas aussi rapide à converger ( mais ceci dit, je n'ai pas vraiment vu de problème avec ça au vue des machines que j'ai , mais si le but est d'avoir des milliers de mini vm, ça peut être bloquant ).
Enfin, il faut bien voir que puppet est un langage de description, pas de programmation. Ce qui peut faire grincer des dents si tu ne le prends pas comme tel, les choix qui ont été fait sont très opiniatre, et pareil, tout le monde n'aime pas.
À contrario, chef a l'air plus difficile à déployer, mais permet plus de choses. Il utilise directement ruby pour décrire les systèmes ( ce que puppet peut faire aussi, mais c'est pas très employé de ce que je sais ). Chef est plus apte à servir de brique de base pour faire un outil de gestion d'infrastructure ( genre, une interface personnalisé ). Il y a un article très bien dans Linux Mag sur le sujet, je t'invite à regarder.
Et pour finir, si tu as du RH/Centos, l'outil Cloudforms que Red hat va sortir devrait s'appuyer sur puppet, ce qui garanti que le support de puppet ne devrait pas être trop mauvais ( alors qu'il y a pas de paquet rpm de chef pour le moment en dehors de celui d'opscode, ce qui me fait sauter au plafond en tant que contributeur à une distribution ).
[^] # Re: Une main de fer dans un gant d'acier
Posté par Misc (site web personnel) . En réponse au journal La glibc s'ouvre à la communauté. Évalué à 5.
Les gens d'openbsd, c'est vague. Si je suis http://openssh.org/history.html#portable , il y a 2 noms. Damien Miller est un dev qui fait un peu d'openbsd ( cf http://www.mindrot.org/~djm/ ), même si visiblement, un peu, c'est déjà pas mal.
Phil Hands est visiblement un dev debian ( http://www.hands.com/~phil/ ).
Donc ça fait 1 "gens" d'openbsd.
Si je regarde les différents noms dans le Changelog, on voit quand même des emails @sco.com, @fujitsu.com @ibm.com, @juniper.net, @openwall.net
Les releases sont fait à part. Je sais pas ou est le cvs, et j'avais déjà du mal à savoir ce qu'on peut faire avec des branches quand j'avais à l'utiliser, c'est pas maintenant que j'utilise plus que je vais pouvoir le dire. La seul mention que je trouve est un cvs readonly, qui est géré par le dit Damien.
Donc peut être que le cvs est aussi à part du projet principal.
À contrario, si je regarde la liste des changements récents ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/ChangeLog
, on voit en effet 3 nicks :
djm ( damien miller )
dtucker ( darren tucker )
tim ( tim rice )
djm est commiter openbsd. dtucker est aussi commiter sur openssh, et sur openntpd ( vu qu'il fait pareil, la portabilité ). Mais il se présente comme "helper on debian" http://www.advogato.org/person/dtucker/.
Tim rice est consultant unix, et semble faire autre chose que du bsd.
Donc je ne suis pas sur qu'on puisse dire que le taf de portabilité est fait par les devs openbsd, vu qu'on trouve des infos un chouia flou.
D'un coté, c'est 2 projets séparés, avec des correctifs qui sont venus de partout, mais de l'autre, les gens qui committent sur le 2me ont aussi les droits sur le premier, ce qui fait qu'il s'agit de facto de codeur openbsd.
Une vraie réponse serait de faire le compte des modifs de la version portable, et d'ou viennent les patchs.
[^] # Re: Une main de fer dans un gant d'acier
Posté par Misc (site web personnel) . En réponse au journal La glibc s'ouvre à la communauté. Évalué à 8.
Et la portabilité vers des OS autres qu'openbsd ( http://openssh.org/portable.html ) ?
J'attends quand même qu'on me montre la différence entre "on doit coder un serveur ssh, on va se servr des fonctions présentes que sur notre version de BSD et laisser le reste du monde sur une version portable ou adopter nos changements", et "on va coder un demon de gestion du boot, on va se servir des fonctiones présentes sur notre noyau et laisser le reste du monde se demerder".
J'avais trouvé normal la réaction de l'équipe d'openbsd d'utiliser leurs fonctionnalités autant que possible et de restreindre leur focus et le code pour leur os. C'est naturel d'utiliser les avancés de leur plateforme. C'est aussi naturel de vouloir avoir un code minimal, et je pense que Theo et Lennart seraient d'accord sur le fait que la portabilité inter unix peut rendre le code moche.
Donc venir sortir Theo de raadt comme exemple de chantre de la portabilité, faut pas déconner. Sur ce point la, je pense qu'il rejoint la plupart des devs, à savoir qu'il a un seuil de tolérance à ce qu'il peut accepter au nom de la portabilité.
Quand à l'avis d'Ulrich, il était surtout motivé par les trucs "exotiques" d'arm, comme les histoires d'alignements, le fait que ça soit le bordel sur les jeux d'instructions, et les types de procs, etc. Linus rale aussi sur les SOC et tout le foutoir que c'est, mais personne ne remets en cause son avis. Et même si je suis ni d'accord avec la forme des échanges sur internet d'Ulrich, ni avec la conclusion qu'il en tire, je pense qu'on peut au moins se dire que sur le fond, ses arguments n'étaient pas totalement creux.
[^] # Re: Quand je remonte un peu en arrière ...
Posté par Misc (site web personnel) . En réponse au journal La glibc s'ouvre à la communauté. Évalué à 5.
Il manque pas un
[^] # Re: Une main de fer dans un gant d'acier
Posté par Misc (site web personnel) . En réponse au journal La glibc s'ouvre à la communauté. Évalué à 7.
En fait, je me disait pareil que toi, puis j'ai fait les comptes. Y a 4000 personnes dans la boite en 2010 ( source wikipedia ). La boite a 19 ans, des gens ont du partir, venir, on va miser sur 6000 personnes qui sont passés par la ( estimation à la louche ). À supposer 20% de personnes impliqués dans le libre et donc à même d'être connu du public linuxfrien, ça fait 800 personnes.
Sur les 800, on va compter parmi les gens avec un caractère bien trempé qui ont fait les gros titres sur Linuxfr :
- Jeff Johnson
- Ulrich Drepper
- Lennart Poettering ( et je tiens à préciser que moi, j'aime bien Lennart )
on peut rajouter une paire de gens de GNOME, un ou deux codeurs de yum, visons large, ça va faire 10 personnes.
10 sur 800. ça fait pas grand chose.
La question est plus de savoir si c'est pas le logiciel libre qui fait qu'on doit avoir son petit caractère , que ça soit par construction ( l'exemple revient assez souvent dans les débats sur les femmes et le libre ), ou parce que tout se passe sur internet. Et auquel cas, en effet, on a l'impression statistique que tout les psychopathes sont chez Red Hat, vu qu'une grande variété de codeurs sont chez eux. À supposer qu'une personne compétente mais anti social arrive à devenir grand mamamouchi d'un projet, il y a des chances que les compétences pures compensent le coté anti social, et donc qu'il se retrouve à se faire embaucher pour bosser sur le dit projet , ie, chez une société qui contribue au libre.
En effet, personne de logique ne va embaucher un anti social pour bosser avec ses équipes. Mais si la personne est déjà en place, avec des équipes externes qui l'acceptent, alors la pénalité est moindre. Donc la compétence éclipse le coté antisocial.
[^] # Re: Une main de fer dans un gant d'acier
Posté par Misc (site web personnel) . En réponse au journal La glibc s'ouvre à la communauté. Évalué à 10.
Ulrich aussi averti plusieurs fois, mais en te mordant.
En fait, il faut considérer la tête sanglante sur son bureau comme un avertissement.
[^] # Re: Arch yabon
Posté par Misc (site web personnel) . En réponse au journal Les aventuriers de la distribution perdue. Évalué à 4.
http://article.gmane.org/gmane.linux.redhat.fedora.devel/161438
"The only thing that gets drivers written is writing the damn driver."
[^] # Re: Arch'ment bon! La pédagogie en plus!
Posté par Misc (site web personnel) . En réponse au journal Les aventuriers de la distribution perdue. Évalué à 5.
En fait, les archistes sont les nouveaux gentooistes.
http://greenfly.org/mes.html
[^] # Re: Les mamouths
Posté par Misc (site web personnel) . En réponse au journal Les aventuriers de la distribution perdue. Évalué à 3.
Sinon, y a EPEL pour faire des paquets. https://fedoraproject.org/wiki/EPEL
( et il y a une souscription offerte pour les packageurs, pour ce que Centos rebute, et qui trouve que 50 euros par an, c'est trop cher )
[^] # Re: heu ..
Posté par Misc (site web personnel) . En réponse au journal Inscrivez vous à Facebook, il sait déjà tout de vous. Évalué à 3.
Sinon, tu prends une carte mobile chez sfr/orange/bouygues, le temps que l'opérateur valide ton identité, tu as eu ton compte gmail.
Ensuite, tu revends le tel pour pas qu'on te retrouve avec ton IMSI ( ou tu utilises un tel ou le firmware peut changer l'imsi )
# Nimage
Posté par Misc (site web personnel) . En réponse au journal Inscrivez vous à Facebook, il sait déjà tout de vous. Évalué à 10.
C'est le datacenter de l'étoile noire ?
[^] # Re: No Wi-Fi Cannot
Posté par Misc (site web personnel) . En réponse au journal Enfin un site vraiment dans les nuages. Évalué à 2.
Je doute fort que tu puisses tirer la nuit sans te faire remarquer, et je doute fort que tu te fatigues à monter sur ton toit de maison la nuit ( en tout cas, moi, je le ferais pas ), ou que tu puisses monter tout court dans le cas d'un immeuble.
Pour être rentable, je pense qu'il faut viser les zones fortement peuplés, ie les grandes villes, la ou tu va choper 40 à 50 signals wifis depuis le toit, et d'avoir de la chance.
Et sérieusement, si un truc un peu silencieux se pose sur le toit de mon immeuble, je le verrais pas, et je doute l'entendre. Et si tu veux être malin, tu peux rajouter des stickers "meteo france", ou "si vous trouvez ce drone de mesure meteo, merci de contacter untel sur email@example.org, ou de le placer dans un colis à destination de XXXX".
( sinon, dans la catégorie "truc à faire", ç'est de mettre l'appareil dans une moto de livraison de pizza, comme suggérer un jour par quelqu'un du projet openbmap )
[^] # Re: V
Posté par Misc (site web personnel) . En réponse au journal Sarkozy ou le relativisme absolu. Évalué à 3.
Je pense que c'était des attaques à l'arme bactériologique ( mais je retrouve plus mon dvd et j'ai pas la bd ici ).
[^] # Re: Petite question
Posté par Misc (site web personnel) . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 5.
Dans mon souvenir, l'eglibc est un fork de la glibc, et surtout parce que Ulrich Drepper n'est pas super diplomate ( genre, "arm, c'est merdique", etc ).
Et j'ai pas le sentiment qu'on retrouve beaucoup d'outil de l'embarqué ( busybox, ulibc, framebuffer ) vers le desktop, à part java ( qui je rappelle à la base, vient du projet oak dans les années 90 )
[^] # Re: No Wi-Fi Cannot
Posté par Misc (site web personnel) . En réponse au journal Enfin un site vraiment dans les nuages. Évalué à 4.
Suffit de les poser la nuit sur le toit d'un immeuble.
[^] # Re: Pourquoi pas
Posté par Misc (site web personnel) . En réponse au journal Enfin un site vraiment dans les nuages. Évalué à 1.
Je pense qu'au prix du missile, ça risque de devenir vite couteux.
Pour info : http://bigbrowser.blog.lemonde.fr/2011/03/23/combien-ca-coute-le-prix-de-lintervention-en-libye/
Si un missile tomahawk coute 650 000 euros, je pense pas qu'un missile sol air soit bien moins cher. Même à 1000 euros le missile, un drone fait maison couterait vachement moins cher. Autant dire que le combat est financièrement perdu.
Ça irait sans doute moins cher d'aller avec un hélico pour déstabiliser les drones, même si ça va douiller niveau carburant.
[^] # Re: Analyse erronée
Posté par Misc (site web personnel) . En réponse au journal L'échec du bureau libre sous Linux réside paradoxalement dans le fait qu'il n'est pas assez libre.. Évalué à 3.
Si c'est si simple, pourquoi personne le fait ?
et tu veux dire quoi par "patch de dépôt" ?
Et un programme sans menu, c'est un programme qui existe pas pour la plupart des gens ( et une regression pour la plupart ). C'est pas pour rien que tout les softs du monde mettent un menu dans windows ( menu pourri au passage ).
Un programme pas intégré ( au hasard, un rippeur de cd ), c'est un programme qui marche pas pour certains ( si le soft n'apparait pas quand on demande à ripper, ou si les programmes se marchent dessus ).
Un programme mal intégré, ça peut être aussi un truc tout con comme un soft qui a besoin d'un module kernel ( genre vbox ), et donc qui a besoin des droits admins ( et de certaines APIs qu'on devrait pas donner à un programme 3rd party, AMHA ).
L'intégration, c'est aussi la gestion des mimetypes. C'est faisable, vu qu'android arrive à le faire via le systéme d'intent, et pourtant, y a encore des programmes qui le font pas correctement, genre, carcast et les liens itpc, ce qui rends l'ajout de podcast complexes.
Les gens prennent l'intégration pour acquise, mais je pense qu'il faut vraiment participer à une distribution pour comprendre ce que ça recouvre sous Linux. Donc je ne peux que inviter les gens à venir voir les choses du coté du distributeur pour mieux comprendre.
[^] # Re: Combien de marins, combien de capitaines ?
Posté par Misc (site web personnel) . En réponse au journal L'échec du bureau libre sous Linux réside paradoxalement dans le fait qu'il n'est pas assez libre.. Évalué à 2.
La théorie, c'est aussi "les gens sont capables de gérer ça correctement et rien de mal ne va arriver en général".
En pratique, ça passe, jusqu'à ce que ça casse.
Très franchement, moi, je suis pour, vu que si quelqu'un vient me râler dessus, je vais pouvoir dire "pas ma faute" ( manquerais plus que je sois responsable de ce que je peux pas gérer, faut pas déconner ) ou "faut plus de moyen" ( parce que bon, si je dois être capable de gérer les macs, les pcs, les ipads, les tablettes androids, il me faut soit une formation, soit au moins le matos pour que je puisse jouer avec ).
Et faut bien se rendre compte que si les boites filent du matos aux gens, c'est bien parce qu'elles sont obligés ( pourquoi, comment, je sais pas ). Si on peut économiser sur le budget informatique, on le fait en général, et on a pas attendu l'iPad et les smartphones pour avoir des appareils qu'on peut amener ( au hasard, les pc portables qu'une majorité d'étudiants ont depuis 10 ans ).
[^] # Re: Analyse erronée
Posté par Misc (site web personnel) . En réponse au journal L'échec du bureau libre sous Linux réside paradoxalement dans le fait qu'il n'est pas assez libre.. Évalué à 3.
En même temps, c'est normal, vu que Ubuntu cherche à se placer comme plateforme.
On vérifie :
- un public non réticent à l'idée de payer, c'est fait ( cf ubuntu one )
- une infrastructure pour compiler, distribuer et gérer tout le projet, c'est fait ( les ppas + launchpad )
- des cours pour apprendre à utiliser la plateforme, c'est fait ( genre, la doc python par défaut depuis 8 ans, cours sur irc )
- de la pub autour de ça, c'est fait ( http://www.jonobacon.org/2010/01/30/connecting-the-opportunistic-dots/ )
- une interface adapté, c'est fait ( http://www.ubuntu.com/ubuntu/features/ubuntu-software-centre )
Et le business plan qui va avec :
http://www.ubuntu.com/devices/tv & http://www.ubuntu.com/devices/android
Donc oui, Canonical écoute les développeurs commerciaux, vu qu'ils veulent que ça devienne des partenaires.
Microsoft a fait pareil, Apple a fait pareil.
[^] # Re: Analyse erronée
Posté par Misc (site web personnel) . En réponse au journal L'échec du bureau libre sous Linux réside paradoxalement dans le fait qu'il n'est pas assez libre.. Évalué à 3.
Ce qui va arriver, c'est qu'au début, on va avoir des applis ultrasimples. Ensuite, le marché va être saturé, donc les applications vont devoir se distinguer. Se distinguer, c'est soit :
- offrir des features encore inconnues de tous.
- offrir les features encore inconnues des utilisateurs.
Le premier est dur. Le deuxième est simple, il suffit de prendre les features des autres. Ce qui fait que tu arrives à prendre les utilisateurs du premier marché, et du second.
Donc au bout d'un moment, pour grandir, tu doit offrir plus de fonctionnalités. Le marché étant supposé saturé, si tu le fait pas, quelqu'un le fera à ta place. Donc après un temps, on se retrouve à une situation gérable.
Suffit de voir la tendance dans les téléphones. Les gens utilisent plus "un smartphone qui fait tout", ou "un téléphone, un palm pilot, un lecteur mp3, un ebook reader et une gameboy" ?
Ou dans les IDEs, est ce que les gens vont plus vers eclipse, visual studio ou vers "je choisis mon compilo, mon editeur, mon debuggeur, mon analyseur de code et mon linker". Il suffit de voir la centaine d'entreprise dans le consortium eclipse pour voir ou l’intérêt commerciale se situe.
Une grande partie des gens veulent visiblement du tout intégré. Par exemple, pas avoir 1 logiciel pour lire chaque type de fichier multimedia, ne pas avoir un soft pour acheter de la musique, un pour les films, un pour transférer la musique, un pour les ebooks, etc. C'est relativement logique de pas vouloir passer trop de temps quand on n'est de toute façon pas capable d'apprécier les différences ( contrairement à quelqu'un qui est déjà plus expert et qui va passer du temps sur ça )
Et avant d'avoir des suites bureautiques, on a eu des applis séparés. Du visicalc, du word, du presenter. Et c'est quand les boites sont arrivés qu'on est passé d'un marché ou c'était facile de faire un petit soft ( genre, un shareware ) à un marché ou les plus gros dominent.
Et les plus gros dominent car ils ont plus de force de frappe publicitaires, plus de moyens, etc
[^] # Re: Analyse erronée
Posté par Misc (site web personnel) . En réponse au journal L'échec du bureau libre sous Linux réside paradoxalement dans le fait qu'il n'est pas assez libre.. Évalué à 3.
Non, faut rajouter la propriété "ressources". C'est faisable d'avoir tout ça avec des ressources infinis. Mais tu peux pas avec des ressources limités, sachant qu'il y a plus de gens qui veulent faire du code que de gens qui veulent faire des paquets ou de la QA.
Dans le monde windows, un projet, c'est un tout, tu as les devs ( ou plutot, l'éditeur, ça va d'une équipe de 1 à une boite entière ), qui fait l'installeur, et la QA, et la traduction.
Dans le monde du libre, les codeurs font que le code, parfois des gens débarquent pour traduire. La QA est parfois faite par les codeurs, parfois faite par les utilisateurs, souvent les 2, assez souvent sans grand formalisme ( sous windows aussi, je précise, ça dépend plus de bénévole vs gens payés pour ).
La distribution est minimale pour les projets libres en général ( il y a plus de gens qui font "je tag dans git et voilou" que de projet comme mozilla ). Et la ou l'intégration dans windows est aussi souvent minimal ( exemple, la gestion des menus, l'intégration avec d'autres logiciels, etc ), sous Linux, elle est plus riche et représente une valeur ajouté ( à mon sens ).
Le vrai souci est que les distros linux sont faites par des sysadmins, qui donc répondent à leur problématique. Les developpeurs font le code, qui réponds à leur besoin ( genre, ne pas se faire chier avec une ABI ), certains ont fait leur systéme de paquets ( gems, jar, etc ) pour répondre à leur besoin.
Les utilisateurs bureautiques typiques, ils font rien, trop l'habitude qu'on leur file tout cuit le taf. Il y a pas besoin de savoir comment marche l'ordinateur pour s'en servir ( au contraire de coder ou d'administrer ), donc les gens ne savent pas. Donc forcément, y a que des boites commerciales qui répondent à leur besoin, car c'est globalement la seule chose qu'on va réussir à avoir de la part de la vaste majorité d'un point de vue, de l'argent.
Donc c'est le modèle même du libre et son économie contributive qui ne va pas au grand publique actuel, au moins du point de vue logiciel. Et je précise logiciel car si on prends wikipedia, on voit que ça marche pas trop mal, mais surtout parce que c'est atrocement simple de contribuer.
[^] # Re: Analyse erronée
Posté par Misc (site web personnel) . En réponse au journal L'échec du bureau libre sous Linux réside paradoxalement dans le fait qu'il n'est pas assez libre.. Évalué à 3.
Les raisons ont été couvertes en long et en large il y a une paire d'années :
http://www.licquia.org/archives/2005/03/27/autopackage-considered-harmful/
Bien sur, je suis totalement partial à ce sujet, mais je pense que si c'était si bien, les gens auraient adopté ça en masse. On a beau dire "les distros verrouillent", les distros sont aussi indépendantes, et si tout le monde a bloqué, c'est pas une concertation venu d'une cabale secrète, c'est bien que chaque distro a indépendamment dit "y a un souci".