En effet, j'avais totalement oublié le CLA de Digia. Ceci dit, la différence est aussi dans le logiciel visé, et la licence.
QT est sous LGPL, donc ta principale obligation si tu fait un logiciel proprio serait de distribuer le code de QT ( et c'est grosso modo détaillé sur la page du projet de façon assez clair ).
Tu va devoir aller voir Digia si tu veux modifier QT et ne pas distribuer les sources. Le coeur de métier de Digia étant le consulting, et la vente de service marche mieux quand le logiciel est vivant ( ie, genre quand ça bouge et qu'il faut former sans arrêt les gens, et faire des upgrades de code, et quand le soft est "gros" ), donc ils font tout pour que ça soit le cas ( aka, favoriser l'innovation ).
Unity, Upstart et d'autres sont sous GPL v3, ce qui implique aussi de distribuer le code, mais pas uniquement. Par exemple, ça implique aussi de filer les potentiels clés pour les mises à jours, la fameuse clause anti tivoization. Et je pense que la partie sur les brevets de la GPL v3 rentre dans la même catégorie d'incitation à prendre la version proprio du code.
En effet, un des marchés affichés par Canonical est les OEMs et que ça soit les OEMs de téléphones ou de télé, je pense que la plupart ont des brevets qu'ils utilisent et chérissent (surtout dans le mobile), et qu'ils veulent pas qu'on puissent modifier leur firmware, pour des questions de DRMs, etc.
Donc la ou Digia se sert du CLA de manière sans doute accessoire ( AMHA ), j'ai le sentiment que Canonical se sert des obligations de la GPL v3 de manière bien plus offensive commercialement ce qui est philosophiquement gênant ( du style "filez nous du pognon pour pas avoir à traiter avec les hippies communistes du logiciel libre" ).
Ensuite, oui, le discours flou de Canonical n'aide pas et amplifie beaucoup l'effet, alors que Digia reste très discret et au contraire, à fait preuve d'ouverture en ouvrant plus les choses que depuis l'époque de Trolltech. Et peut être que Digia fait plein de pognon grâce au CLA et mon analyse est fausse concernant Canonical.
Ils le font peut être évolués au fur et à mesure. Ils veulent peut être continuer à le vendre sous license proprio, ce qu'ils ne pourraient faire qu'avec un CLA à la Canonical ( et on a vu comment Canonical se fait descendre pour faire exactement ça ).
Peut être que le moteur dépend de logiciels ou ils ne peuvent pas filer le code ( genre, bundle avec leur offre sous windows ). Peut être qu'ils ont signés des NDAs avec nvidia/amd.
Y a des milliers de raisons de pas réussir à le libérer, en dehors de pas vouloir. Mais bien sur, peut être qu'ils s'en foutent, je dit pas non plus.
L'idée d'utiliser un signal, c'est bien pour signaler que le processus est prêt. SI on le fait sans vraiment savoir ( iequand on a lancé mais qu'on a pas vraiment vérifié ), on reviens à ce que ferait un gestionnaire de processus sans notification.
Le coup de ne pouvoir surveiller que son fils, c'est sans
utiliser les cgroup, hors, systemd l'utilise justement.
Je suis pas spécialiste des cgroups, mais waitid ( qui est utilisé par upstart pour choper l'état d'un fils ) n'est pas lié avec les cgroups. La façon dont systemd utilise les cgroups, c'est juste pour grouper les process et les limiter. Et il se sert du second pour la répartition des ressources, et du premier comme un liste de soft à tuer avec une boucle. Les primitives unix ne permettent pas autre chose, sauf erreur de ma part ( ie, surveiller un processus arbitraire, sauf via ptrace, ce qui pose un autre type de souci, et ptrace qui est utilisé justement aussi par upstart, avec aussi une implémentation avec un certain nombre de souci dans son design )
Et même, pourquoi n'exec-t-il pas erl ?
ça oui, c'est la solution théorique, et je suis d'accord qu'idéalement, c'est ce qu'il faut faire. Ensuite, il y a la pratique, et dans la pratique, il y a des options pour que ça n'arrive pas ( dans le cas de.
Bon, il a peut-être des raisons, et le coup du SIGSTOP peut
effectivement sembler bidouille dans ce cas.
Et c'est le souci. Le SIGSTOP semble séduisant pour un daemon simple, mais pour un daemon simple, il y a pas de souci.
Et ça deviens compliqué assez vite pour les programmes non triviaux, programmes non triviaux qui justement bénéficient d'autant plus de la notification car ils font plein de choses avant d'être prêt.
L'avantage du protocole de systemd, c'est qu'il est transparent si c'est fait comme il faut. sd_notify est une non opération si il n'est pas lancé avec les variables qui vont bien. Donc pas de souci de doc, pas d'interférence avec un usage ( bien que ça soit un souci d'ordre très théorique, j'ai passé du temps à voir en pratique ce qui l'utilise chez debian et j'ai trouvé surtout des softs pour utilisateur plus que système, donc le souci est pas non plus trés bloquant, on peut reconnaitre ça )
Bah, l'implémentation d'upstrart est pourrie, et ?
et ça fait 5 ans qu'elle est pourrie. Que dire de plus à part que visiblement, personne n'a revu le truc dans le détail ?
Sinon je peux continuer pour te dire pourquoi le protocole est pourri et pas juste l'implémentation. Prends par exemple un soft comme couchdb en erlang. Comme c'est de l'erlang, il faut lancer via erl avec souvent un script bash qui va mettre divers variables, etc. Du coup, comme un processus ne peut surveiller que son fils, il se passe quoi dans le cas d'un soft comme le dit couchdb qui fait pas forcément un exec à la fin ( ie, le cas très précis de couchdb avec l'option pour relancer automatiquement le soft quand il se gauffre, cf /usr/bin/couchdb ) ?
Soit le script fait le SIGSTOP mais il va faire ça avant que couchdb soit prêt, soit erl le fait, mais personne ne va le surveiller.
On peut tenter le coup aussi avec un soft qui lance 2 softs ( genre miredo-client, qui va se relancer avec moins de priviléges ). Celui qui est surveiller (le premier) est pas celui qui fait le taf (le 2eme).
Et on peut généraliser le cas avec apache, php-fpm. Du coup, le code passe de "je fait raise(sigstop) + un if" à "je mets en place un canal de comm entre le fils et moi pour que le fils me signal son état, et que moi ensuite je fasse un SIGSTOP pour signaler à mon propre père.
Avec le protocole de systemd, on se contente juste de passer la variable et le file descriptor. Le travail est beaucoup plus simple. Et point bonus, tu peux faire plus que juste dire "je suis prêt".
alors toi tu n'as pas du faire beaucoup d'empaquetage de
logiciels.
Je ne suis pas sur qu'il soit sage d'user d'un argument de ce genre sans avoir fait un minimum de vérification et vérifier avant de supposer. ( mais je reconnais que depuis que j'utilise que mon pseudo sur linuxfr, c'est beaucoup plus dur de vérifier qui je suis quand on n'a pas plus de choses pour une recherche google ). mais je te laisse le soin de vérifier quand je te dit que ça doit bien faire 10 ans que je fait des paquets rpms, que j'ai codé sur des softs comme rpmlint, que j'ai participé à divers distros voir forké une distro et bosser sur la mise en place de son systéme de build entre autres choses.
Quand tu fais réellement de l'intégration, ajouter une
dépendance n'est pas du tout anodin.
Si il y a que ça, tu peux aussi prendre les fichiers .c et .h prévu pour ça depuis le code de systemd. Moi, je trouve ça dégeu, mais si upstream insiste à pas rajouter de lien, c'est son code.
Aprés, je dit pas que c'est insurmontable, mais c'est ajouter
des milliers de fois
une charge qui pourrait être évitée (enfin, très réduite) si
systemd l'implémentait.
Encore une fois, il y a 2 logiciels dans tout debian qui supporte le dit protocole. Donc il faudrait :
1) rajouter le dit protocole dans systemd de façon correcte ( ce qui est déjà pas le cas chez upstart )
2) rajouter le support sur les milliers de paquets en question 3) patcher la documentation des milliers de paquets.
Et bien sur, résoudre les cas épineux tels que j'ai énoncé ( et sans trop me forcer )
Ensuite, c'est pas comme si Debian avait déjà fait des milliers de patchs pour tout un tas de trucs ( GFDL et la DGSF, le portage sur le Hurd, le portage pour kfreebsd ). C'est pas comme si les packageurs de Fedora ou d'autres distros doivent régulièrement faire des patchs pour tel nouvelle version de gcc ou tel options de gcc, tel lib qui a été mise à jours et qui changent 2/3 trucs.
Enfin, je continue à dire qu'il n'y a pas vraiment besoin de rajouter de protocole de notification pour la plupart des softs. Il y a plus d’intérêt à faire du on-demand avec les sockets par exemple.
il ignore l'utilisation de SIGSTOP seulement si un
flag/variable d'environnement est mis, dit que ça peut être
utilisé pour autre chose, mais là c'est dans le cas où le
process l'utilise sur lui-même
Elle relance le process tout le temps. Donc SIGSTOP ne marche plus. Tu noteras que visiblement, il n'y a pas de vérification de l'endroit d'ou viens le signal, vu que ça utilise waitid (cf le code de libnih) qui reçoit juste l'état. Donc si j'envoie un signal SIGSTOP, il est ignoré.
et introduire une dépendance à sa lib (il doit s'en foutre du
boulot de mise à jour de tous les paquets, même les plus
vieux/exotiques/etc…), …
Les logiciels marchent sans avoir besoin de signaler leur "readyness", le fait que personne ou presque n'implémente le protocole d'upstart est la preuve. Et rajouter l'appel en question , c'est surtout du taf sur les autootools que sur le code, c'est pas vraiment le plus compliqué.
Et j'ai bien regardé, j'ai trouvé 2 softs qui utilisent le dit protocole. openssh et xorg. Et c'est des patchs de Canonical dans les 2 cas. Pour un truc qui date de 2008, on peut pas dire que les foules se jettent dessus.
Je pense que logind va être difficile à éviter, vu que ça remplace consolekit.
Et je pense que l'argument de Lennart sur "la gestion des cgroups doit être dans le pid 1 si le pid 1 utilise les cgroups" me semble assez logique. Et la méthode de gestion des processus de upstart ( soit pas de fork, soit avec l'envoie de SIGSTOP, soit avec ptrace, ie 2 hacks fragiles et un truc potable mais pas complet ) ne me semble pas fiable par rapport à l'usage des cgroups pour les cas complexes.
Et comme Lennart le dit sur son g+ ( https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/ip8e1DqJdxT ), upstart n'utilise même pas son propre paradigme correctement pour les systèmes de fichiers, et n'a pas énormément bougé depuis 4 ans ( et c'est vrai que upstart a l'air de moins bouger que systemd :
et surtout que c'est reparti entre 2012 et 2013, curieusement quand systemd a commencé à prendre la place de upstart un peu partout ( y a 2/3 ans chez Fedora, et un peu partout ailleurs après ).
Raisons de sécurité mais pas que, voire même pas
prioritairement. Theo avait expliqué dans une conférence il y a
un moment (hop là petite excuse pour dire, j'ai cherché sur le
net, j'ai pas retrouvé) que le fait de disposer de sa propre
infrastructure lui permettait d'effectuer un bon nombre de tests
qui sont difficilement réalisables sur des infrastructures
tiers, à fortiori des infrastructures de gens qui gagnent leur
vie avec.
Ça se fait aussi. Le projet Mageia a son propre switch manageable dans le bout de rack alloué avec son petit range IP chez LO et on aurait pu demander plus si on avait besoin de plus. Le projet Fedora avait son propre cluster de build ARM dans un "rack" dans une université avant que ça parte dans un DC à phoenix. ( un truc fait maison du style http://blog.chris.tylers.info/uploads/IMAG0182a.jpg )
Quand à faire tomber les switchs, c'est pour ça qu'on a inventé les prises commandés par le réseau. Même si ça coute dans les 400€ sur amazon, ça reviens à être de l'infra comme le reste. Avec une console série style cyclades, tu peux même reflasher ton switch sans souci.
Ensuite, je veux bien reconnaitre que c'est plus rare de tomber sur des hébergeurs de ce genre, mais si 2 projets de distributions Linux arrivent à le faire, c'est que c'est pas non plus impossible. Donc je persiste sur le fait qu'il y a un choix de sécurité surtout, car le reste de ce que tu énonces me semblent être un faux problème.
En fait, c'est plus subtile que ça. Fedora, Centos, Debian acceptent tous d'avoir des serveurs dans des data centers et des salles autre que les leurs.
Et je pense avoir lu ( mais j'ai pas de lien sur ça ) que les dits serveurs sont tous chez Theo, dans sa cave, pour divers questions de sécurité.
Ce qui du coup fait que les aides habituelles des facs, des hébéergeurs, etc ne s'appliquent pas, car ce n'est pas ce que le projet veux.
Des boites qui filent des thunes, y en a pas des tonnes. Ç'est plus complexe, faut passer par la compta, par la direction, etc. C'est faisable, mais je pense que la plupart des gens veulent pas se fatiguer pour ça.
Alors que des boites qui filent de l’hébergement gratos, ça se trouve. En france et sans être exhaustif, tu as Lost Oasis ( mageia, tuxfamilly, plf et plein de monde ), tu as gandi ( mageia encore ), tu as ovh ( filé un serveur pour l'ex AUFML ), tu as Free ( linuxfr ), ou Ikoula ( pour fedora-fr.org ), ou d'autres assoces ( le crans gère un serveur d'OSM, par exemple ).
Et ça se trouve car il y a moins de paperasse, tu en parles avec des gens qui comprennent le souci genre ton chef et son chef à lui tout au plus, et basta. Voir même, c'est ton coeur de métieur de filer des machines, donc tu dit juste "ça, y a une remise de 100%".
Ensuite, oui, ça aide d'avoir un sponsor qui peut payer, mais les projets arrivent assez souvent sans trop de mal à s'en passer.
Tu peux tagguer des photos de gens qui te ressemblent sur facebook, et dévier un peu à chaque fois. Voir mieux, avoir plusieurs comptes facebook avec ton nom, et tagguer plus ou moins au pif.
C'est un outil qui permet de modéliser l'activité de ton entreprise, la partie "métier".
prenons l'exemple d'une boulangerie, il faut gerer les stocks de croissant, les fournisseurs, les factures, etc. Tout ça, tu le rentres dans ton outil, et il te donnes les rapports que tu veux. Par exemple, il sort les papiers pour la compta, il te sort les factures, et la, tu peux avoir une vue de ton activité commerciale.
Essaye de t'imaginer commercant, pour un gros ou un petit truc, et de ce que tu dois faire, et de te dire "il faut que je formalise ça et que j'informatise tout". Et la, tryton te permet de le faire, non pas directement, mais via une boite à outil ( et par exemple, nereid te permet de faire une interface web qui va avec tryton pour avoir ensuite un package complet, et tryton-flask te permet de faire des trucs simples et rapides, ou de tout refaire le reste en flask et en python, si tu te sens l’âme d'un dev.
Je vois bien que la version 0.1 veut dire que c'est pas encore mature ni prêt, et plus un truc pour expérimenter, mais la, y a un module avec une classe de 5 méthodes, alors que Nereid a l'air d'être bien plus avancé ( genre déjà, un site web, des tests ) de l'extérieur..
Donc je ne vois pas en quoi c'est une alternative dans l'état des choses, vu qu'il manque des tonnes de trucs. Et bon, le complément qui fait beaucoup moins que l'outil qu'il vise à remplacer, pareil, je pense que c'est s'avancer un peu vite vis à vis du projet.
C'est un peu ce qui est reproché à Upstart par un membre du tech-ctte, c'est que sur upstart, il y a que Canonical ( et Google via ChromeOS ) qui contribue.
Au point de vue sécurité, cela permet aux frameworks de sécurité
(SELinux, Apparmor…) d'éviter de faire confiance à l'userspace.
je suis modérement pas d'accord. D'une part, dans l'état des choses, le démon dbus fait l'arbitrage de qui a le droit de faire quoi via selinux et apparmor. Pour cela, il profite du fait qu'il a une vision globale sur les messages.
Bien sur, il est en userspace, mais il tourne dans un domaine de sécurité séparé du process userspace auquel on ne fait pas confiance, donc la distinction est plus complexe que kernel space vs userspace.
Et c'est ce point qui pose souci au dev de Canonical, car ils ont besoin de plus de précision que juste laisser passer ou non le message.
Actuellement, pour reprendre une analogie, le filtrage par selinux est de l'ordre d'un filtrage de niveau ip/tcp sur une couche réseau classique. Ce que Canonical a besoin pour confiner les applications, c'est plus un truc du style filtrage protocolaire. Ce qui se fait sans souci en userspace, et qui va avoir une énorme résistance au niveau du kernel. Et si le positionnement d'un tel filtre est évidement au lieu de passage dans le kernel, ça va pas aller.
Une solution serait de faire comme le défunt nufw, ie faire passer le message en userspace pour filtrage avant de retourner au kernel, mais ça devient inefficace. Une autre solution pourrait être une dérivation ( ie, le message va au destinataire et à un démon de filtrage, et le destinataire attends que le demon de filtrage dise "oui" ), mais la, on rajoute des délais un peu inutile et une architecture un peu plus complexe et fragile.
Donc je comprends que le passage vers le kernel dérange des gens, même si je pense qu'avec le temps, un moyen de filtrer efficacement soit ajouté dans le kernel.
Et toujours à mon bien humble avis, si Debian adopte systemd, ça
sera le moment où systemd entrera en production, la communauté
peut le prendre en charge non une seule entité. si Debian
n'adopte pas systemd par contre, donc n'y fourre plus son nez
dedans, là ça sera un frein sévère à systemd (à mes yeux)
Dans la mesure ou systemd est déjà dans plein de distributions, dans le mesure ou j'ai vu presque personne dire "je suis sysadmin, je surkiffe trop upstart qui permet des trucs trop bien", je pense que la communauté a déjà choisi.
Non pas que upstart soit catastrophique, mais j'ai le sentiment que personne parmi les sysadmins que je connais ne cherche à tirer parti des fonctions avancés. Et pourtant, upstart est présent dans RHEL, Ubuntu server, etc.
Upstart a déjà 5 ans, est globalement mature ( minus certains soucis de conceptions, genre l'usage de ptrace pour suivre les process ), et bien qu'il a été utilisé dans l'embarqué ( genre le nokia n9 ), j'ai pas le sentiment que son modèle à base d'evenement ne séduise plus que ça. Ça se voit par rapport par exemple aux posts de blog qui parlent du projet, qui sont bien moins nombreux que pour systemd, ou du moins, qui m'avait l'air moins nombreux quand j'ai regardé il y a quelques semaines, alors que la communauté Ubuntu est censé être une des plus grande niveau utilisateur.
Donc non, je pense pas qu'une non-adoption de systemd par debian soit un frein. J'aurais plus tendance à dire que ça va arriver dans debian, quoi que le tech-ctte fasse, et que au contraire, un refus ( ce qui n'est pas le cas actuellement, mais le cas chez Ubuntu ) serait un frein pour la distribution, sauf à avoir l'égalité au niveau des fonctions, ce qui est un travail en cours ( par exemple, l'usage des cgroups dans upstart, il reste plus que tout le reste à faire ).
En effet, mais openrc ne semble pas passionner les foules. Malgré le fait que les devs rajoutent des fonctions ( support de cgroups pour suivre les processus ), seul Thomas Goirand semble le pousser. Mais il ne perds pas son temps, et je pense qu'il travaille d'arrache pied pour résoudre les soucis, et je pense qu'en effet, ça pourrait faire un bon complément sur les plateformes BSD et Hurd si un autre système d'init est choisi pour Linux.
Debian comme la plupart des distributions utilise ce genre de fonction pour gagner du temps au boot depuis longtemps, donc ça pourrait être un retour en arrière que de devoir la désactiver par défaut.
Si avec ça, personne n'est inspiré pour une discussion technique, je peux commencer à lancer la discussion sur le nombre de ligne de code upstart et systemd comparé, et comment upstart passe vraiment trop de temps à communiquer en interne de part son architecture la ou systemd rajoute des features dans son code à la place, mais j'ai peur d'être tout seul sur le sujet.
Et ici il y a au moins 3 hommes qui ont fait la même chose, donc
égalité.
on est pas la pour compter, tu es (comme d'hab) à coté de la plaque. Je suis la pour faire remarquer que la remarque :
"Interestingly, the crusaders[2] are to date all male, and often assert that women can’t like jokes about breasts or sex in general3. How fucked up is that?"
Est factuellement incorrect. Au mieux, Laurent fait preuve d'ignorance, mais j'en doute fortement, ne serais que parce qu'il sait ou était le screenshot. Au pire, il refait l'histoire dans sa tête pour ne pas se remettre en question sur certains points.
Le reste, c'est juste ton bullshit habituel, je pense que je vais pas perdre mon temps à tenter de discuter, si tu sais pas lire ce à quoi tu réponds, c'est pas en écrivant plus que tu va l'apprendre.
Si ça n'apporte rien à l'argument, tu n'auras donc aucun problème à le corriger ou à la retirer sur ton blog, vu que ça n'apporte rien à part des faits incorrects ?
Ou ça viole un autre principe qu'on connait pas à priori et qui ne va pas du tout aller en faveur d'une non remise en cause de ta vision ?
Tu noteras que je fait une différence entre le projet, et Laurent. Le projet a changé des choses ( sans grande pompes, car il faudrait pas reconnaitre qu'il y a un souci ) et Laurent lui non. Comme le dit quelqu'un sur le fil, il ne faut pas confondre la communauté et les membres individuelles. Si ensuite, tu (toi, pas le projet) n'arrive pas à faire la différence au premier coup d'oeil ( notamment par exemple l'usage de la seconde personne du singulier pour adresser directement pkk ), je pense qu'il y a un souci.
Ensuite, pour le fait que tu n'as pas vu de screenshot, c'est facile, le screenshot en question était sur la page de qvideoboob, jusqu'en juillet 2012. On voit encore sur archive.org le message "if you are under the age of 18 or find this screenshots offensive, please don't look at them.", cf https://web.archive.org/web/20110302193534/http://weboob.org/QVideoob
Ou on peut aussi voir le très curieux :
"If you are at work, or if you are under 18, you probably don't want to display porn videos. You juste have to uncheck the Display NSFW videos box."
Sur la même page.
Au passage, pour voir si tu as pas des soucis de vue, on va tomber d'accord pour dire que le logo de la caisse d'épargne sur le site de weboob est le même que celui de la banque, mais avec le bras mis comme un penis en érection ? Et que le logo pour le module de lolix est celui de lolix avec un pénis sous le gnu ?
C'est vrai que poster un journal non technique pour se plaindre qu'il y a pas assez de contenu technique dans une dépêche qui n'a rien de technique ( sans remettre en cause sa qualité, mais parler des nouveautés d'un logiciel qu'on peut qualifier de sujet à controverse, ç'est pas ce que j'appelle parler de technique ), c'est en effet cocasse.
Quand en plus, celui ci monopolise les discussions via un sujet plus populaire ( car tout le monde a un avis sur linuxfr ), c'est même curieusement contre productif sur le long terme.
En te basant sur des fais qui sont faux. j'ai vu 3 personnes de sexe féminin se plaindre du nom ( ou plutot du coté enfantin et vulgaire de l'ensemble, entre le nom, les images pornos sur le site web ( qui ont disparu justement suite à la discussion ), des logos de mauvais gout rajouté à dessein avec les détails qui tuent qu'on ne voit que quand on sait ou regarder ).
Bien sur, pour voir ces femmes faire part de leur mécontentement, il faut aller ailleurs que sur linuxfr, comme par exemple sur le stand weboob des RMLLs 2012 à Genève.
Mais tu peux continuer à te baser ton analyse sur ta vision tronqué du monde bien sur, et ne pas te remettre en cause.
[^] # Re: Commentaire et questions
Posté par Misc (site web personnel) . En réponse au journal DD & Valve. Évalué à 5.
En effet, j'avais totalement oublié le CLA de Digia. Ceci dit, la différence est aussi dans le logiciel visé, et la licence.
QT est sous LGPL, donc ta principale obligation si tu fait un logiciel proprio serait de distribuer le code de QT ( et c'est grosso modo détaillé sur la page du projet de façon assez clair ).
Tu va devoir aller voir Digia si tu veux modifier QT et ne pas distribuer les sources. Le coeur de métier de Digia étant le consulting, et la vente de service marche mieux quand le logiciel est vivant ( ie, genre quand ça bouge et qu'il faut former sans arrêt les gens, et faire des upgrades de code, et quand le soft est "gros" ), donc ils font tout pour que ça soit le cas ( aka, favoriser l'innovation ).
Unity, Upstart et d'autres sont sous GPL v3, ce qui implique aussi de distribuer le code, mais pas uniquement. Par exemple, ça implique aussi de filer les potentiels clés pour les mises à jours, la fameuse clause anti tivoization. Et je pense que la partie sur les brevets de la GPL v3 rentre dans la même catégorie d'incitation à prendre la version proprio du code.
En effet, un des marchés affichés par Canonical est les OEMs et que ça soit les OEMs de téléphones ou de télé, je pense que la plupart ont des brevets qu'ils utilisent et chérissent (surtout dans le mobile), et qu'ils veulent pas qu'on puissent modifier leur firmware, pour des questions de DRMs, etc.
Donc la ou Digia se sert du CLA de manière sans doute accessoire ( AMHA ), j'ai le sentiment que Canonical se sert des obligations de la GPL v3 de manière bien plus offensive commercialement ce qui est philosophiquement gênant ( du style "filez nous du pognon pour pas avoir à traiter avec les hippies communistes du logiciel libre" ).
Ensuite, oui, le discours flou de Canonical n'aide pas et amplifie beaucoup l'effet, alors que Digia reste très discret et au contraire, à fait preuve d'ouverture en ouvrant plus les choses que depuis l'époque de Trolltech. Et peut être que Digia fait plein de pognon grâce au CLA et mon analyse est fausse concernant Canonical.
[^] # Re: Commentaire et questions
Posté par Misc (site web personnel) . En réponse au journal DD & Valve. Évalué à 3.
Ils le font peut être évolués au fur et à mesure. Ils veulent peut être continuer à le vendre sous license proprio, ce qu'ils ne pourraient faire qu'avec un CLA à la Canonical ( et on a vu comment Canonical se fait descendre pour faire exactement ça ).
Peut être que le moteur dépend de logiciels ou ils ne peuvent pas filer le code ( genre, bundle avec leur offre sous windows ). Peut être qu'ils ont signés des NDAs avec nvidia/amd.
Y a des milliers de raisons de pas réussir à le libérer, en dehors de pas vouloir. Mais bien sur, peut être qu'ils s'en foutent, je dit pas non plus.
[^] # Re: Est-ce que Valve est sponsorisée par un concurrent à Debian ?
Posté par Misc (site web personnel) . En réponse au journal DD & Valve. Évalué à 6.
Ma foi, avec les 235 personnes qui ont signés la pétition il y a 2 ans ( https://www.change.org/petitions/lennart-poettering-stop-writing-useless-programs-systemd-journal ), il y a sans doute moyen d'avoir assez d'argent pour payer la même chose.
Et si tu rajoutes les dizaines de millions d'autres qui sont contre, il y a sans doute moyen d'avoir au moins 100€ de plus.
[^] # Re: Mini précision, variable d'environnement
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 6. Dernière modification le 24 janvier 2014 à 01:10.
L'idée d'utiliser un signal, c'est bien pour signaler que le processus est prêt. SI on le fait sans vraiment savoir ( iequand on a lancé mais qu'on a pas vraiment vérifié ), on reviens à ce que ferait un gestionnaire de processus sans notification.
Je suis pas spécialiste des cgroups, mais waitid ( qui est utilisé par upstart pour choper l'état d'un fils ) n'est pas lié avec les cgroups. La façon dont systemd utilise les cgroups, c'est juste pour grouper les process et les limiter. Et il se sert du second pour la répartition des ressources, et du premier comme un liste de soft à tuer avec une boucle. Les primitives unix ne permettent pas autre chose, sauf erreur de ma part ( ie, surveiller un processus arbitraire, sauf via ptrace, ce qui pose un autre type de souci, et ptrace qui est utilisé justement aussi par upstart, avec aussi une implémentation avec un certain nombre de souci dans son design )
ça oui, c'est la solution théorique, et je suis d'accord qu'idéalement, c'est ce qu'il faut faire. Ensuite, il y a la pratique, et dans la pratique, il y a des options pour que ça n'arrive pas ( dans le cas de.
Et c'est le souci. Le SIGSTOP semble séduisant pour un daemon simple, mais pour un daemon simple, il y a pas de souci.
Et ça deviens compliqué assez vite pour les programmes non triviaux, programmes non triviaux qui justement bénéficient d'autant plus de la notification car ils font plein de choses avant d'être prêt.
L'avantage du protocole de systemd, c'est qu'il est transparent si c'est fait comme il faut. sd_notify est une non opération si il n'est pas lancé avec les variables qui vont bien. Donc pas de souci de doc, pas d'interférence avec un usage ( bien que ça soit un souci d'ordre très théorique, j'ai passé du temps à voir en pratique ce qui l'utilise chez debian et j'ai trouvé surtout des softs pour utilisateur plus que système, donc le souci est pas non plus trés bloquant, on peut reconnaitre ça )
[^] # Re: Mini précision, variable d'environnement
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 10.
et ça fait 5 ans qu'elle est pourrie. Que dire de plus à part que visiblement, personne n'a revu le truc dans le détail ?
Sinon je peux continuer pour te dire pourquoi le protocole est pourri et pas juste l'implémentation. Prends par exemple un soft comme couchdb en erlang. Comme c'est de l'erlang, il faut lancer via erl avec souvent un script bash qui va mettre divers variables, etc. Du coup, comme un processus ne peut surveiller que son fils, il se passe quoi dans le cas d'un soft comme le dit couchdb qui fait pas forcément un exec à la fin ( ie, le cas très précis de couchdb avec l'option pour relancer automatiquement le soft quand il se gauffre, cf /usr/bin/couchdb ) ?
Soit le script fait le SIGSTOP mais il va faire ça avant que couchdb soit prêt, soit erl le fait, mais personne ne va le surveiller.
On peut tenter le coup aussi avec un soft qui lance 2 softs ( genre miredo-client, qui va se relancer avec moins de priviléges ). Celui qui est surveiller (le premier) est pas celui qui fait le taf (le 2eme).
Et on peut généraliser le cas avec apache, php-fpm. Du coup, le code passe de "je fait raise(sigstop) + un if" à "je mets en place un canal de comm entre le fils et moi pour que le fils me signal son état, et que moi ensuite je fasse un SIGSTOP pour signaler à mon propre père.
Avec le protocole de systemd, on se contente juste de passer la variable et le file descriptor. Le travail est beaucoup plus simple. Et point bonus, tu peux faire plus que juste dire "je suis prêt".
Je ne suis pas sur qu'il soit sage d'user d'un argument de ce genre sans avoir fait un minimum de vérification et vérifier avant de supposer. ( mais je reconnais que depuis que j'utilise que mon pseudo sur linuxfr, c'est beaucoup plus dur de vérifier qui je suis quand on n'a pas plus de choses pour une recherche google ). mais je te laisse le soin de vérifier quand je te dit que ça doit bien faire 10 ans que je fait des paquets rpms, que j'ai codé sur des softs comme rpmlint, que j'ai participé à divers distros voir forké une distro et bosser sur la mise en place de son systéme de build entre autres choses.
Si il y a que ça, tu peux aussi prendre les fichiers .c et .h prévu pour ça depuis le code de systemd. Moi, je trouve ça dégeu, mais si upstream insiste à pas rajouter de lien, c'est son code.
Encore une fois, il y a 2 logiciels dans tout debian qui supporte le dit protocole. Donc il faudrait :
1) rajouter le dit protocole dans systemd de façon correcte ( ce qui est déjà pas le cas chez upstart )
2) rajouter le support sur les milliers de paquets en question 3) patcher la documentation des milliers de paquets.
Et bien sur, résoudre les cas épineux tels que j'ai énoncé ( et sans trop me forcer )
Ensuite, c'est pas comme si Debian avait déjà fait des milliers de patchs pour tout un tas de trucs ( GFDL et la DGSF, le portage sur le Hurd, le portage pour kfreebsd ). C'est pas comme si les packageurs de Fedora ou d'autres distros doivent régulièrement faire des patchs pour tel nouvelle version de gcc ou tel options de gcc, tel lib qui a été mise à jours et qui changent 2/3 trucs.
Enfin, je continue à dire qu'il n'y a pas vraiment besoin de rajouter de protocole de notification pour la plupart des softs. Il y a plus d’intérêt à faire du on-demand avec les sockets par exemple.
[^] # Re: Mini précision, variable d'environnement
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 5.
L'implémentation d'upstart a un souci :
https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/upstart/trusty/view/head:/init/job_process.c#L1482
Elle relance le process tout le temps. Donc SIGSTOP ne marche plus. Tu noteras que visiblement, il n'y a pas de vérification de l'endroit d'ou viens le signal, vu que ça utilise waitid (cf le code de libnih) qui reçoit juste l'état. Donc si j'envoie un signal SIGSTOP, il est ignoré.
Les logiciels marchent sans avoir besoin de signaler leur "readyness", le fait que personne ou presque n'implémente le protocole d'upstart est la preuve. Et rajouter l'appel en question , c'est surtout du taf sur les autootools que sur le code, c'est pas vraiment le plus compliqué.
Et j'ai bien regardé, j'ai trouvé 2 softs qui utilisent le dit protocole. openssh et xorg. Et c'est des patchs de Canonical dans les 2 cas. Pour un truc qui date de 2008, on peut pas dire que les foules se jettent dessus.
[^] # Re: Et maintenant ?
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 1.
Ah merde, ça m'a semblé tellement logique d'avoir un nombre impair :/
[^] # Re: Et maintenant ?
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 4.
Il reste encore une personne. Et bon, une fois que le tech-ctte dit un truc, faut juste attendre que quelqu'un fasse le boulot.
Il serait amusant que ça soit upstart, ne serais que pour continuer à troller :p
[^] # Re: Et pour une poignée de liens en plus
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 8.
Je pense que logind va être difficile à éviter, vu que ça remplace consolekit.
Et je pense que l'argument de Lennart sur "la gestion des cgroups doit être dans le pid 1 si le pid 1 utilise les cgroups" me semble assez logique. Et la méthode de gestion des processus de upstart ( soit pas de fork, soit avec l'envoie de SIGSTOP, soit avec ptrace, ie 2 hacks fragiles et un truc potable mais pas complet ) ne me semble pas fiable par rapport à l'usage des cgroups pour les cas complexes.
Et comme Lennart le dit sur son g+ ( https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/ip8e1DqJdxT ), upstart n'utilise même pas son propre paradigme correctement pour les systèmes de fichiers, et n'a pas énormément bougé depuis 4 ans ( et c'est vrai que upstart a l'air de moins bouger que systemd :
https://www.ohloh.net/p/systemd
vs
https://www.ohloh.net/p/upstart
et surtout que c'est reparti entre 2012 et 2013, curieusement quand systemd a commencé à prendre la place de upstart un peu partout ( y a 2/3 ans chez Fedora, et un peu partout ailleurs après ).
[^] # Re: Oui
Posté par Misc (site web personnel) . En réponse au journal Projets Open Source, des vaches à lait ?. Évalué à 6.
Ça se fait aussi. Le projet Mageia a son propre switch manageable dans le bout de rack alloué avec son petit range IP chez LO et on aurait pu demander plus si on avait besoin de plus. Le projet Fedora avait son propre cluster de build ARM dans un "rack" dans une université avant que ça parte dans un DC à phoenix. ( un truc fait maison du style http://blog.chris.tylers.info/uploads/IMAG0182a.jpg )
Quand à faire tomber les switchs, c'est pour ça qu'on a inventé les prises commandés par le réseau. Même si ça coute dans les 400€ sur amazon, ça reviens à être de l'infra comme le reste. Avec une console série style cyclades, tu peux même reflasher ton switch sans souci.
Ensuite, je veux bien reconnaitre que c'est plus rare de tomber sur des hébergeurs de ce genre, mais si 2 projets de distributions Linux arrivent à le faire, c'est que c'est pas non plus impossible. Donc je persiste sur le fait qu'il y a un choix de sécurité surtout, car le reste de ce que tu énonces me semblent être un faux problème.
[^] # Re: Oui
Posté par Misc (site web personnel) . En réponse au journal Projets Open Source, des vaches à lait ?. Évalué à 10.
En fait, c'est plus subtile que ça. Fedora, Centos, Debian acceptent tous d'avoir des serveurs dans des data centers et des salles autre que les leurs.
Et je pense avoir lu ( mais j'ai pas de lien sur ça ) que les dits serveurs sont tous chez Theo, dans sa cave, pour divers questions de sécurité.
Ce qui du coup fait que les aides habituelles des facs, des hébéergeurs, etc ne s'appliquent pas, car ce n'est pas ce que le projet veux.
Des boites qui filent des thunes, y en a pas des tonnes. Ç'est plus complexe, faut passer par la compta, par la direction, etc. C'est faisable, mais je pense que la plupart des gens veulent pas se fatiguer pour ça.
Alors que des boites qui filent de l’hébergement gratos, ça se trouve. En france et sans être exhaustif, tu as Lost Oasis ( mageia, tuxfamilly, plf et plein de monde ), tu as gandi ( mageia encore ), tu as ovh ( filé un serveur pour l'ex AUFML ), tu as Free ( linuxfr ), ou Ikoula ( pour fedora-fr.org ), ou d'autres assoces ( le crans gère un serveur d'OSM, par exemple ).
Et ça se trouve car il y a moins de paperasse, tu en parles avec des gens qui comprennent le souci genre ton chef et son chef à lui tout au plus, et basta. Voir même, c'est ton coeur de métieur de filer des machines, donc tu dit juste "ça, y a une remise de 100%".
Ensuite, oui, ça aide d'avoir un sponsor qui peut payer, mais les projets arrivent assez souvent sans trop de mal à s'en passer.
[^] # Re: cool
Posté par Misc (site web personnel) . En réponse au journal Système de Dé-ciblage (google and co) pour augmenter l'anonymat. Évalué à 3.
Tu peux tagguer des photos de gens qui te ressemblent sur facebook, et dévier un peu à chaque fois. Voir mieux, avoir plusieurs comptes facebook avec ton nom, et tagguer plus ou moins au pif.
[^] # Re: Tryton
Posté par Misc (site web personnel) . En réponse au journal Utiliser Tryton dans son application Flask. Évalué à 5.
C'est un outil qui permet de modéliser l'activité de ton entreprise, la partie "métier".
prenons l'exemple d'une boulangerie, il faut gerer les stocks de croissant, les fournisseurs, les factures, etc. Tout ça, tu le rentres dans ton outil, et il te donnes les rapports que tu veux. Par exemple, il sort les papiers pour la compta, il te sort les factures, et la, tu peux avoir une vue de ton activité commerciale.
Essaye de t'imaginer commercant, pour un gros ou un petit truc, et de ce que tu dois faire, et de te dire "il faut que je formalise ça et que j'informatise tout". Et la, tryton te permet de le faire, non pas directement, mais via une boite à outil ( et par exemple, nereid te permet de faire une interface web qui va avec tryton pour avoir ensuite un package complet, et tryton-flask te permet de faire des trucs simples et rapides, ou de tout refaire le reste en flask et en python, si tu te sens l’âme d'un dev.
# Nereid a quand même l'air plus complet
Posté par Misc (site web personnel) . En réponse au journal Utiliser Tryton dans son application Flask. Évalué à 3.
Je vois bien que la version 0.1 veut dire que c'est pas encore mature ni prêt, et plus un truc pour expérimenter, mais la, y a un module avec une classe de 5 méthodes, alors que Nereid a l'air d'être bien plus avancé ( genre déjà, un site web, des tests ) de l'extérieur..
Donc je ne vois pas en quoi c'est une alternative dans l'état des choses, vu qu'il manque des tonnes de trucs. Et bon, le complément qui fait beaucoup moins que l'outil qu'il vise à remplacer, pareil, je pense que c'est s'avancer un peu vite vis à vis du projet.
[^] # Re: Et pour une poignée de liens en plus
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 9.
Et des gens seront payé pour écrire la doc ( https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/System_Administrators_Guide/chap-Managing_Services_with_systemd.html ), très logiquement pour expliquer comment marche systemd à des gens en formation ( formation RHCE, etc ), et des gens seront payé pour faire des unités systemd pour les outils proprios.
Et je pense que tu peux aussi rajouter SLES 12, qui devrait logiquement également proposer systemd ( cf https://www.suse.com/communities/conversations/systemd-is-not-about-systeme-d/ )
Ou parler de CoreOs ( http://coreos.com/ ), qui est une startup qui bosse sur l'hebergement de container, et qui au passage embauche de ce que j'ai compris. Ou Pantheon ( https://www.getpantheon.com/blog/pantheon-running-over-500000-systemd-units ).
C'est un peu ce qui est reproché à Upstart par un membre du tech-ctte, c'est que sur upstart, il y a que Canonical ( et Google via ChromeOS ) qui contribue.
[^] # Re: kdbus
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 4.
je suis modérement pas d'accord. D'une part, dans l'état des choses, le démon dbus fait l'arbitrage de qui a le droit de faire quoi via selinux et apparmor. Pour cela, il profite du fait qu'il a une vision globale sur les messages.
Bien sur, il est en userspace, mais il tourne dans un domaine de sécurité séparé du process userspace auquel on ne fait pas confiance, donc la distinction est plus complexe que kernel space vs userspace.
Et c'est ce point qui pose souci au dev de Canonical, car ils ont besoin de plus de précision que juste laisser passer ou non le message.
Actuellement, pour reprendre une analogie, le filtrage par selinux est de l'ordre d'un filtrage de niveau ip/tcp sur une couche réseau classique. Ce que Canonical a besoin pour confiner les applications, c'est plus un truc du style filtrage protocolaire. Ce qui se fait sans souci en userspace, et qui va avoir une énorme résistance au niveau du kernel. Et si le positionnement d'un tel filtre est évidement au lieu de passage dans le kernel, ça va pas aller.
Une solution serait de faire comme le défunt nufw, ie faire passer le message en userspace pour filtrage avant de retourner au kernel, mais ça devient inefficace. Une autre solution pourrait être une dérivation ( ie, le message va au destinataire et à un démon de filtrage, et le destinataire attends que le demon de filtrage dise "oui" ), mais la, on rajoute des délais un peu inutile et une architecture un peu plus complexe et fragile.
Donc je comprends que le passage vers le kernel dérange des gens, même si je pense qu'avec le temps, un moyen de filtrer efficacement soit ajouté dans le kernel.
[^] # Re: Et pour une poignée de liens en plus
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 10.
Dans la mesure ou systemd est déjà dans plein de distributions, dans le mesure ou j'ai vu presque personne dire "je suis sysadmin, je surkiffe trop upstart qui permet des trucs trop bien", je pense que la communauté a déjà choisi.
Non pas que upstart soit catastrophique, mais j'ai le sentiment que personne parmi les sysadmins que je connais ne cherche à tirer parti des fonctions avancés. Et pourtant, upstart est présent dans RHEL, Ubuntu server, etc.
Upstart a déjà 5 ans, est globalement mature ( minus certains soucis de conceptions, genre l'usage de ptrace pour suivre les process ), et bien qu'il a été utilisé dans l'embarqué ( genre le nokia n9 ), j'ai pas le sentiment que son modèle à base d'evenement ne séduise plus que ça. Ça se voit par rapport par exemple aux posts de blog qui parlent du projet, qui sont bien moins nombreux que pour systemd, ou du moins, qui m'avait l'air moins nombreux quand j'ai regardé il y a quelques semaines, alors que la communauté Ubuntu est censé être une des plus grande niveau utilisateur.
Donc non, je pense pas qu'une non-adoption de systemd par debian soit un frein. J'aurais plus tendance à dire que ça va arriver dans debian, quoi que le tech-ctte fasse, et que au contraire, un refus ( ce qui n'est pas le cas actuellement, mais le cas chez Ubuntu ) serait un frein pour la distribution, sauf à avoir l'égalité au niveau des fonctions, ce qui est un travail en cours ( par exemple, l'usage des cgroups dans upstart, il reste plus que tout le reste à faire ).
[^] # Re: Encryption des données
Posté par Misc (site web personnel) . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 5.
En parlant de encfs :
https://defuse.ca/audits/encfs.htm
[^] # Re: OpenRC
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 6.
En effet, mais openrc ne semble pas passionner les foules. Malgré le fait que les devs rajoutent des fonctions ( support de cgroups pour suivre les processus ), seul Thomas Goirand semble le pousser. Mais il ne perds pas son temps, et je pense qu'il travaille d'arrache pied pour résoudre les soucis, et je pense qu'en effet, ça pourrait faire un bon complément sur les plateformes BSD et Hurd si un autre système d'init est choisi pour Linux.
Ensuite, quelqu'un note dans les liens que ce bug sur le boot en parallèle n'est toujours pas corrigé
https://bugs.gentoo.org/show_bug.cgi?id=391945
Debian comme la plupart des distributions utilise ce genre de fonction pour gagner du temps au boot depuis longtemps, donc ça pourrait être un retour en arrière que de devoir la désactiver par défaut.
# Et pour une poignée de liens en plus
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 10.
La discussion sur hacker news :
https://news.ycombinator.com/item?id=7076294
La discussion sur lwn :
http://lwn.net/Articles/578208/
Une autre sur kdbus :
http://lwn.net/Articles/580194/
Et une réponse de GKH :
http://lwn.net/Articles/580814/
Si avec ça, personne n'est inspiré pour une discussion technique, je peux commencer à lancer la discussion sur le nombre de ligne de code upstart et systemd comparé, et comment upstart passe vraiment trop de temps à communiquer en interne de part son architecture la ou systemd rajoute des features dans son code à la place, mais j'ai peur d'être tout seul sur le sujet.
[^] # Re: asshole detector
Posté par Misc (site web personnel) . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 4.
on est pas la pour compter, tu es (comme d'hab) à coté de la plaque. Je suis la pour faire remarquer que la remarque :
"Interestingly, the crusaders[2] are to date all male, and often assert that women can’t like jokes about breasts or sex in general3. How fucked up is that?"
Est factuellement incorrect. Au mieux, Laurent fait preuve d'ignorance, mais j'en doute fortement, ne serais que parce qu'il sait ou était le screenshot. Au pire, il refait l'histoire dans sa tête pour ne pas se remettre en question sur certains points.
Le reste, c'est juste ton bullshit habituel, je pense que je vais pas perdre mon temps à tenter de discuter, si tu sais pas lire ce à quoi tu réponds, c'est pas en écrivant plus que tu va l'apprendre.
[^] # Re: asshole detector
Posté par Misc (site web personnel) . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 2.
Si ça n'apporte rien à l'argument, tu n'auras donc aucun problème à le corriger ou à la retirer sur ton blog, vu que ça n'apporte rien à part des faits incorrects ?
Ou ça viole un autre principe qu'on connait pas à priori et qui ne va pas du tout aller en faveur d'une non remise en cause de ta vision ?
[^] # Re: asshole detector
Posté par Misc (site web personnel) . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 6.
Tu noteras que je fait une différence entre le projet, et Laurent. Le projet a changé des choses ( sans grande pompes, car il faudrait pas reconnaitre qu'il y a un souci ) et Laurent lui non. Comme le dit quelqu'un sur le fil, il ne faut pas confondre la communauté et les membres individuelles. Si ensuite, tu (toi, pas le projet) n'arrive pas à faire la différence au premier coup d'oeil ( notamment par exemple l'usage de la seconde personne du singulier pour adresser directement pkk ), je pense qu'il y a un souci.
Ensuite, pour le fait que tu n'as pas vu de screenshot, c'est facile, le screenshot en question était sur la page de qvideoboob, jusqu'en juillet 2012. On voit encore sur archive.org le message "if you are under the age of 18 or find this screenshots offensive, please don't look at them.", cf https://web.archive.org/web/20110302193534/http://weboob.org/QVideoob
Ou on peut aussi voir le très curieux :
"If you are at work, or if you are under 18, you probably don't want to display porn videos. You juste have to uncheck the Display NSFW videos box."
Sur la même page.
Au passage, pour voir si tu as pas des soucis de vue, on va tomber d'accord pour dire que le logo de la caisse d'épargne sur le site de weboob est le même que celui de la banque, mais avec le bras mis comme un penis en érection ? Et que le logo pour le module de lolix est celui de lolix avec un pénis sous le gnu ?
[^] # Re: En ce moment même...
Posté par Misc (site web personnel) . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 10.
C'est vrai que poster un journal non technique pour se plaindre qu'il y a pas assez de contenu technique dans une dépêche qui n'a rien de technique ( sans remettre en cause sa qualité, mais parler des nouveautés d'un logiciel qu'on peut qualifier de sujet à controverse, ç'est pas ce que j'appelle parler de technique ), c'est en effet cocasse.
Quand en plus, celui ci monopolise les discussions via un sujet plus populaire ( car tout le monde a un avis sur linuxfr ), c'est même curieusement contre productif sur le long terme.
[^] # Re: asshole detector
Posté par Misc (site web personnel) . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 7.
En te basant sur des fais qui sont faux. j'ai vu 3 personnes de sexe féminin se plaindre du nom ( ou plutot du coté enfantin et vulgaire de l'ensemble, entre le nom, les images pornos sur le site web ( qui ont disparu justement suite à la discussion ), des logos de mauvais gout rajouté à dessein avec les détails qui tuent qu'on ne voit que quand on sait ou regarder ).
Bien sur, pour voir ces femmes faire part de leur mécontentement, il faut aller ailleurs que sur linuxfr, comme par exemple sur le stand weboob des RMLLs 2012 à Genève.
Mais tu peux continuer à te baser ton analyse sur ta vision tronqué du monde bien sur, et ne pas te remettre en cause.