Nan mais ça viole l'esprit unix, tu piges pas. Au contraire de l'option -u de sort, qui duplique pas du tout ce que fait uniq. Au contraire de sed et awk qui font qu'une chose à la fois, au contraire de bash qui a l'option ( non active sur Debian ) d'ouvrir des sockets tcp (dupliquant nc/socat).
Au contraire des ACLs et de SELinux, qui viole l'esprit des permissions unix. Au contraire d'iptables qui viole le principe de "tout est fichier", tout comme les milliers d'ioctl.
Y en a une ou deux personnes qui le font, en essayant de garder upstart en état de marche, enfin en continuant l'intégration dans Debian, y a des gens qui bossent sur openrc. Mais en effet, la majorité a visiblement pas les compétences pour faire grand chose de plus que des articles de blog.
J'ai pas beaucoup plus d'expérience que vous en la matière, mais
je me demande surtout quel est l'avis d'un mainteneur de
sysvinit et de ses nombreux fichiers de script.
Alors je ne rentre pas exactement dans la catégorie que tu cherches ( j'ai maintenu plein de choses, mais pas sysvinit ), mais dans la mesure ou Arch, Mageia et Opensuse ont adoptés systemd ( et je dirais Fedora aussi ), je pense que les mainteneurs ont fait leur choix sans avoir le moindre soupçon de pression.
On m'a dit que altq n'est plus dans le kernel depuis 3j. Et il y a des gens qui ont portés pf sur netbsd. Donc bon, c'est faisable.
Tout comme des gens ont fait des portages de l'API doors de solaris, ou des gens qui ont fait tourner zfs sur freebsd et linux via fuse. C'est juste un boulot énorme.
Quand à carp, oui, c'est réimplementable, tout comme des gens ont refait une implémentations de certains API de systemd, suffit de suivre le protocole.
Mais c'est vrai que je trouve difficilement des choses aussi étroitement lié à un kernel, en dehors du kernel et utilisant beaucoup d'api spécifique du kernel.
Le travail est pas non plus exactement le même, porter une lib C est un daemon qui dépend de fonctions non présente dans les autres kernels, c'est pas exactement la même chose. J'attends de voir une équipe qui va porter openbgpd qui sont bien plus dépendant du kernel d'openbsd qu'openssh ou libressl puisse l'être. Ou le portage de pf/altq sur linux.
À la différence que "vous avez le droit de forker" est faciliter par l'usage de git de base. Et pas du bla bla sur "si on laisse les gens forker, plus personne ne va tourner sur la version HEAD donc on va garder CVS" comme le dit Theo.
docker + selinux pour la sécurité + ostree pour les updates atomics + cockpit pour l'interface web et systemd pour la gestion des limites et la centralisation des logs. Le tout sur une base de distro qu'on connait ( fedora/centos pour le moment, mais rien n'empeche de prendre de la debian si quelqu'un code la partie qui fait un arbre ostree à partir d'un .deb, l'auteur serait très heureux d'ajouter ça )
Rajoute aussi geard, pour orchestrer les containers et les déployer, et source-to-image, qui va prendre un depot git et le combiner avec une image docker pour le deployer directement dans atomic ( https://github.com/openshift/docker-source-to-images ).
Quoi, ce groupe mené par un leader "éclairé" écrit encore du code propre à une platforme pour laisser les autres dans la panade en forçant l'usage d'API qui sont en dehors de la norme POSIX et d'UNIX, c'est quoi ce bordel, combien de temps est ce qu'on va tolérer les débordements de sys…. Ah, on me signale dans l'oreillette que c'est pas Lennart, donc c'est parfaitement acceptable de faire ça, pardon pour l'intervention.
( pour clarifier, je ne critique pas le fait que openbsd le fasse, c'est leur droit, mais je note juste le double standard à ce sujet, et en fait, juste pour lancer le débat qu'autre chose )
Donc je pense qu'il est pas déconnant de supposer que c'est un poste à temps complet, sauf preuve contraire.
Sans blague ? C'est fou, ça, je n'étais pas au courant. Ça ne
m'est pas venu à l'idée de faire un peu de recherche avant
d'écrire. Je le note, ça me servira à l'avenir, c'est pas bête.
En fait, j'avais des doutes sur le fait de te pointer ça, car c'est en effet évident qu'il faut faire des recherches, mais je suis bien content de voir qu'à partir de maintenant, tu va avoir le bagage théorique pour pouvoir affirmer tes propos au lieu de déclamer ça sur un ton péremptoire sans avoir de quoi étayer tes allégations.
Si tu veux. Quand on ne sert qu'à trouver de l'argent pour
financer son propre salaire et pousser son projet
Je lit plus que "vous devrez gagner de l'argent pour vous payer". mais bon, peut être que ma maitrise de l'anglais n'est pas au point.
que lorsqu'on merde sur le seul truc qu'on a à faire (faire
cracher des donateurs au bassinet
En l'occurence, les donateurs sont la. C'est pas un souci de pas avoir réussi à trouver assez d'argent, c'est juste un souci de coordination vis à vis des rentrées et des sorties. Est ce que c'est un souci ? Oui. Est ce que c'est un souci grave. non. Tout au plus, des dépenses pour des volontaires sont repoussés à plus tard, aucune n'étant critique pour eux ( vu que les plus critiques sont les stagiaires de l'OPW qui ont été payés ). Les serveurs tournent, je pense que les salariés sont payés, et l'organisation du GUADEC a été mise dans la boucle et n'a pas de souci que je sache.
Donc au contraire, je pense que les soucis ont été gérés correctement, malgré une erreur initiale. Erreur qui incombe aussi à tout le board gnome, car les décisions sont pas prises de manière unilatéral par la directrice.
Non, pas « ie » : ça ne dit pas qu'elle a bossé 5 ans ; ça dit
qu'elle a pu bosser 5 ans après son diplôme, mais qu'elle a pu
faire 6 mois chez l'un et 3 mois chez l'autre.
Oui, bien sur, elle aurait pu aussi travailler comme agent secret pendant 5 ans, ça serait aussi crédible.
Et comme il y a une unique source d'info sur le sujet, on ne
saura jamais.
Ben on peut demander aux cabinets, on peut demander à quelqu'un au SFLC, y a plein de façon de vérifier, si c'est vraiment important. mais il est possible que la vérité te convienne moins que ton "9 mois d'interim dans 2 cabinets" car ça irait sans doute moins dans ton sens.
De toutes façons, ce n'est pas la peine de batailler là-dessus
: je ne considère pas ça comme une grosse expérience par
rapport à son parcours dans les fondations, tu considères que
si, restons-en là.
Ce que je montre, c'est que factuelement, la proposition "a presque toujours « travaillé » dans ce genre de structure. " est fausse si tu rajoutes 5 ans en dehors de "ce genre de structure" sur 14 ans de carrière.
Alors je doit reconnaitre que j'imagine que ça va faire plaisir à tout les gens qui veulent pas systemd, mais j'imagine qu'il y a aucun lien de cause à effet.
Par contre, ce qui me chagrine, c'est qu'on sait pas exactement qui est derrière l'idée. IE, tout les articles parlent d'un groupe distinct, mais la, je ne sais pas si il y a déjà des volontaires, etc.
Mais les 100 000$ je les ai tirés d'ailleurs : 96 ou 97 000$
salaire de base + d'éventuelles primes de résultat
Donc ce qui veut dire que les 2 autres salariés se partagent 71 000$. Ce qui fait 35 000$ chaque, si tu retires les 40/50% à la louche, ça laisse du 17500$, donc 12 000€. Et ça, c'est sans compter les frais qu'on doit leur rembourser.
Donc permet moi de croire que ton calcul de 100 000$ + primes est un chouia foireux, sauf à rajouter "esclavagisme" sur la liste des griefs que tu rajoutes à charge.
Pas vraiment, non, je crois que cette directrice a presque
toujours « travaillé » dans ce genre de structure.
La directrice a un nom, et une page wikipedia.
je comprends bien que visiblement, tu as une forme de mépris pour tout ces gens qui bosse dans le domaine du libre en dehors de la technique et qui gasp le font à temps plein et sont payer pour ça, mais c'est pas dur à vérifier :
En fait, chaque fois qu'on voit "tel faille a été trouvé par $grosse_boite", c'est pas forcément par hasard. Avec grosse boite étant Google, Suse, IBM, Red Hat, etc.
La rubrique security de LWN permet de voir un peu, ou oss-sec. Par exemple, comme c'est vendredi, ici, on voit bien qu'il y a eu un audit de code de systemd :
( bien sur, le fait d'avoir des gens payé à faire ça, ça implique pas qu'on fasse pas aussi des choses en tant que communauté, et pour ma part, je compte bien m'attaquer à ça et prêcher la bonne parole comme j'ai fait à l'OWF )
expenditures, c'est les dépenses, ça inclue les salaires et les frais remboursé par la fondation ( comme par n'importe quelle boulot ).
Par exemple, ça prends en compte les voyages, l'hotel, la nourriture, et les divers choses qui sont payés par l'employeur ( impôts à la source aux US, assurance chômage privé, etc, etc ).
Par exemple, je vois que les couts de voyages des commerciaux qui montent vers du 3000€ par mois, ça va vite vers du 36 000€ par an, soit la moitié des 100 000$ au taux de change du jour. Donc même si je suppose que la directrice de la fondation bouge moins que mes collègues, si je rajoute divers choses, je pense qu'elle est payé aussi bien que dans le privé (voir moins, car bon, une avocate de profession avec un petit paquet d'xp, ça doit gagner quand même pas mal quand je vois les tarifs que pratique la mienne), mais je doute qu'elle soit super bien payé non plus.
Non, de ce que j'ai vu en parlant avec des membres de la fondation, ils ont le compte. Ils ont juste pas les fonds de roulements, car comme tout le monde ayant déjà organisé un événement bénévole avec sponsors, l'argent sort parfois avant de rentrer ( vu que les sponsors payent après coup ).
Apache est un cas quand même assez extreme. À coté, tu as des trucs comme postgrey, nginx, auditd pour ne citer que 3 exemples qui me viennent à l'espirt en regardant une debian ou y a pas de souci de nommage vis à vis des autres distributions.
On peut aussi imaginer avoir des switchs de compilations comme c'est justement déjà le cas pour le placement des répertoires, et donc s'intégrer dans l'actuel.
Aprés tout, si les distributions se retrouvent à mettre des patchs sur les pages de man, c'est pas très différent.
Et on peut aussi se dire que pour les nouveaux services, le fichier sera déjà de base, ce qui va réduire les risques de divergences.
Si tu peux pas corriger ça sans casser la LSB, je vois pas trop
comment tu peux faire; Un script LSB est quand même censé être
quasiment auto-suffisant et de ne rien dépendre d'autre que des
helpers dans /lib/lsb/.
Je pense que tu te rajoutes une contrainte sorti de nulle part. Certains scripts debian utilise par exemple start-stop-daemon et c'est pas spécifié dans la lsb. Donc soit tu considères que les scripts sont pas portables d'une distro à une autre malgré le fait d'être lsb-compliant et donc la limitation n'a aucun sens. Soit c'est un bug, et voila ce que tu as à corriger. ( j'ai juste vu puppet, nginx, mcstrans vite fait, mais tu as le temps de faire un audit complet ).
Enfin ça, c'est si ton affirmation "il manque quoi" n'est pas juste une formule rhétorique, car la, tu sembles plus dire que y a des problèmes, mais c'est pas urgent alors personne devrait bosser dessus.
il faudrait dire quelle probleme le nouveau système d'init
resout et en quoi cette solution est une amelioration
Ok, alors systemd résoud plusieurs soucis.
Tout d'abord, ça permet d'arreter un démon de manière sur. Sur dans le sens ou on est sur qu'il le fait. Plus de trucs qui trainent aprés un crash d'un process lancé par apache qui lance un cgi qui lance un truc à la con qui plante en faisant un pipe.
Plus de race condition comme dans le script bind de Debian.
Ensuite, ça permet de résoudre le souci des interfaces haut niveau de pas avoir d'API à utiliser. Par exemple, un projet comme cockpit (http://cockpit-project.org/) utilise les API, au lieu de lancer le script d'init avec un code de retour non assuré. Ou ça permet de changer de maniére fiable le nom de domaine de la machine (hostnamectl), l'arrangement du clavier et de la console (localectl), l'heure et l'usage ou pas de ntp. Gnome devait avoir un code relativement compliqué pour s'adapter à la façon de faire de chaque distro pour un taf globalement la même partout, à savoir lancer ntpd.
Enfin, il permet de lancer les services dans un environnement propre. Cad sans groupe supplémentaire (genre, si le programmeur se plante et change d'abord l'uid avant le gid, si il change le gid sans mettre à zero la liste des groupes supplémentaires), sans variable d’environnement parasites (genre, si quelqu'un avec un shell en allemand relance apache, alors les pages en php vont utiliser les locales allemandes pour le tri alphabétique).
( et ça, c'est juste dans mon historique firefox )
Et pour finir, ça réduit aussi la maintenance des distros car tu peux mettre en commun les unités de services, c'est plus facile pour les mainteneurs débutants, donc ça réduit la courbe d'apprentissage pour eux.
En fait, j'ai croisé l'auteur de bareos ce weekend. De ce qu'il me dit, le fork a commencé parce que la version libre de bacula n'avait plus d'évolution vu que c'est un logiciel open-core ). Et depuis le fork, soudainement, ça change ( iel eoc de bouge à nouveau ).
Il m'a aussi dit que la FSF dit qu'il n'y a plus de souci avec le code et que le copyright du code appartient à la FSF, que l'auteur de bacula a ralé parce qu'il a commité le code dans git mais que c'était "par erreur", mais qu'il est resté la pendant 6 mois et a eu plusieurs commits.
La partie sur "y a plus eu de souci" semble aussi vérifiable en regardant la keynote de la conférence, mais j'ai pas cherché.
J'ai pas fouillé le reste, mais j'aurais tendance à dire que le mélange "on donne le code à la FSF pour faire du proprio à coté" me parait curieux. Et forker, ça fait parti de la règle du jeu du libre, donc je vois pas en quoi ça peut être un souci de copyright. À coté, les codeurs de bareos peuvent pas se payer car ils doivent payer un avocat pour des charges qu'ils ne connaissent pas.
Perso, j'aurais tendance à plutôt partir vers bareos, ne serais que parce que le business model est plus propre.
Ben du coup, tu peux comparer le fait que dans les 2 cas, ça donne une nouvelle méthode de déploiment.
Dans un cas, c'est docker, qui va te donner un modèle de déploiment à la lxc, centré sur les applications sous forme d'un tarball.
Dans l'autre, tu as Fedora-atomic, utilisant ostree, qui te donne aussi un mode de déploiment différent du mode classique, et différent de docker.
Donc ouais, ç'est comparable sur ce point. Ensuite, que les 2 trucs soient différents est un enfoncage de porte ouvertes évident, mais justement, ça montre bien le coté innovant de Fedora qui explore divers pistes.
[^] # Re: L'avis d'un mainteneur.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 10.
Nan mais ça viole l'esprit unix, tu piges pas. Au contraire de l'option -u de sort, qui duplique pas du tout ce que fait uniq. Au contraire de sed et awk qui font qu'une chose à la fois, au contraire de bash qui a l'option ( non active sur Debian ) d'ouvrir des sockets tcp (dupliquant nc/socat).
Au contraire des ACLs et de SELinux, qui viole l'esprit des permissions unix. Au contraire d'iptables qui viole le principe de "tout est fichier", tout comme les milliers d'ioctl.
[^] # Re: But du site ?
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 10.
Tu veux dire, faire du vrai travail ?
Y en a une ou deux personnes qui le font, en essayant de garder upstart en état de marche, enfin en continuant l'intégration dans Debian, y a des gens qui bossent sur openrc. Mais en effet, la majorité a visiblement pas les compétences pour faire grand chose de plus que des articles de blog.
[^] # Re: Lennux Is Not UniX
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 4.
ça marche aussi correctement sur le serveur en mageia de mon coloc, sur mon serveur en EL 7, et sur mon serveur en Fedora.
Ceci dit, mon coloc semble aussi se plaindre d'autofs qui segfault et se vautre.
Donc j'aurais tendance plus à dire que c'est un souci spécifique à autofs. Tu as utilisé l'implémentation dans systemd ?
http://www.freedesktop.org/software/systemd/man/systemd.automount.html
[^] # Re: L'avis d'un mainteneur.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 9.
Alors je ne rentre pas exactement dans la catégorie que tu cherches ( j'ai maintenu plein de choses, mais pas sysvinit ), mais dans la mesure ou Arch, Mageia et Opensuse ont adoptés systemd ( et je dirais Fedora aussi ), je pense que les mainteneurs ont fait leur choix sans avoir le moindre soupçon de pression.
Sinon:
http://www.piware.de/2014/04/booting-ubuntu-with-systemd-test-packages-available/
visiblement, même su ubuntu, ça marche quasiment sans modif.
[^] # Re: "on retrouve certains points plus valides"
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 5.
Et pour être précis, c'est optionnel.
http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac#n664
[^] # Re: et ca compile ?
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 2.
On m'a dit que altq n'est plus dans le kernel depuis 3j. Et il y a des gens qui ont portés pf sur netbsd. Donc bon, c'est faisable.
Tout comme des gens ont fait des portages de l'API doors de solaris, ou des gens qui ont fait tourner zfs sur freebsd et linux via fuse. C'est juste un boulot énorme.
Quand à carp, oui, c'est réimplementable, tout comme des gens ont refait une implémentations de certains API de systemd, suffit de suivre le protocole.
Mais c'est vrai que je trouve difficilement des choses aussi étroitement lié à un kernel, en dehors du kernel et utilisant beaucoup d'api spécifique du kernel.
[^] # Re: ...
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 7.
C'est pas parce qu'il est audité qu'on trouve 100% des failles. Les erreurs, ça arrive à tout le monde.
[^] # Re: et ca compile ?
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 3.
Le travail est pas non plus exactement le même, porter une lib C est un daemon qui dépend de fonctions non présente dans les autres kernels, c'est pas exactement la même chose. J'attends de voir une équipe qui va porter openbgpd qui sont bien plus dépendant du kernel d'openbsd qu'openssh ou libressl puisse l'être. Ou le portage de pf/altq sur linux.
[^] # Re: et ca compile ?
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 7.
À la différence que "vous avez le droit de forker" est faciliter par l'usage de git de base. Et pas du bla bla sur "si on laisse les gens forker, plus personne ne va tourner sur la version HEAD donc on va garder CVS" comme le dit Theo.
# Et project atomic ?
Posté par Misc (site web personnel) . En réponse à la dépêche Logiciels pour survivre avec Docker. Évalué à 8.
Sinon, y a ça qui a été annoncé la semaine dernière :
http://www.projectatomic.io/
docker + selinux pour la sécurité + ostree pour les updates atomics + cockpit pour l'interface web et systemd pour la gestion des limites et la centralisation des logs. Le tout sur une base de distro qu'on connait ( fedora/centos pour le moment, mais rien n'empeche de prendre de la debian si quelqu'un code la partie qui fait un arbre ostree à partir d'un .deb, l'auteur serait très heureux d'ajouter ça )
Rajoute aussi geard, pour orchestrer les containers et les déployer, et source-to-image, qui va prendre un depot git et le combiner avec une image docker pour le deployer directement dans atomic ( https://github.com/openshift/docker-source-to-images ).
[^] # Re: et ca compile ?
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 10.
Quoi, ce groupe mené par un leader "éclairé" écrit encore du code propre à une platforme pour laisser les autres dans la panade en forçant l'usage d'API qui sont en dehors de la norme POSIX et d'UNIX, c'est quoi ce bordel, combien de temps est ce qu'on va tolérer les débordements de sys…. Ah, on me signale dans l'oreillette que c'est pas Lennart, donc c'est parfaitement acceptable de faire ça, pardon pour l'intervention.
( pour clarifier, je ne critique pas le fait que openbsd le fasse, c'est leur droit, mais je note juste le double standard à ce sujet, et en fait, juste pour lancer le débat qu'autre chose )
[^] # Re: Et les algorithmes GOST ?
Posté par Misc (site web personnel) . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 9.
Donc il faut se concentrer sur les algos apatrides ?
Ça va être chaud, non ?
[^] # Re: Vitalité du projet
Posté par Misc (site web personnel) . En réponse à la dépêche GNOME 3.12 : sans domicile. Évalué à 2.
Bonne remarque, mais qui a dit que Karen était a temps plein aussi ?
La job description du poste de sysadmin de 2010 ne mentionne pas un poste à mi temps :
https://wiki.gnome.org/Sysadmin/Archive/JobDescription
Donc je pense qu'il est pas déconnant de supposer que c'est un poste à temps complet, sauf preuve contraire.
En fait, j'avais des doutes sur le fait de te pointer ça, car c'est en effet évident qu'il faut faire des recherches, mais je suis bien content de voir qu'à partir de maintenant, tu va avoir le bagage théorique pour pouvoir affirmer tes propos au lieu de déclamer ça sur un ton péremptoire sans avoir de quoi étayer tes allégations.
Je pense que tu pourrais mettre à profit tes nouvelles compétences de recherches sur le web pour trouver un cours d'anglais, car quand je lit la job description:
http://blogs.gnome.org/foundation/2010/11/16/gnome-foundation-is-hiring/
Je lit plus que "vous devrez gagner de l'argent pour vous payer". mais bon, peut être que ma maitrise de l'anglais n'est pas au point.
En l'occurence, les donateurs sont la. C'est pas un souci de pas avoir réussi à trouver assez d'argent, c'est juste un souci de coordination vis à vis des rentrées et des sorties. Est ce que c'est un souci ? Oui. Est ce que c'est un souci grave. non. Tout au plus, des dépenses pour des volontaires sont repoussés à plus tard, aucune n'étant critique pour eux ( vu que les plus critiques sont les stagiaires de l'OPW qui ont été payés ). Les serveurs tournent, je pense que les salariés sont payés, et l'organisation du GUADEC a été mise dans la boucle et n'a pas de souci que je sache.
Donc au contraire, je pense que les soucis ont été gérés correctement, malgré une erreur initiale. Erreur qui incombe aussi à tout le board gnome, car les décisions sont pas prises de manière unilatéral par la directrice.
Oui, bien sur, elle aurait pu aussi travailler comme agent secret pendant 5 ans, ça serait aussi crédible.
Ben on peut demander aux cabinets, on peut demander à quelqu'un au SFLC, y a plein de façon de vérifier, si c'est vraiment important. mais il est possible que la vérité te convienne moins que ton "9 mois d'interim dans 2 cabinets" car ça irait sans doute moins dans ton sens.
Ce que je montre, c'est que factuelement, la proposition "a presque toujours « travaillé » dans ce genre de structure. " est fausse si tu rajoutes 5 ans en dehors de "ce genre de structure" sur 14 ans de carrière.
# Qui ?
Posté par Misc (site web personnel) . En réponse au journal 5 ans de support pour un sous-ensemble de Debian Squeeze. Évalué à 3.
Alors je doit reconnaitre que j'imagine que ça va faire plaisir à tout les gens qui veulent pas systemd, mais j'imagine qu'il y a aucun lien de cause à effet.
Par contre, ce qui me chagrine, c'est qu'on sait pas exactement qui est derrière l'idée. IE, tout les articles parlent d'un groupe distinct, mais la, je ne sais pas si il y a déjà des volontaires, etc.
[^] # Re: Vitalité du projet
Posté par Misc (site web personnel) . En réponse à la dépêche GNOME 3.12 : sans domicile. Évalué à 6.
Donc ce qui veut dire que les 2 autres salariés se partagent 71 000$. Ce qui fait 35 000$ chaque, si tu retires les 40/50% à la louche, ça laisse du 17500$, donc 12 000€. Et ça, c'est sans compter les frais qu'on doit leur rembourser.
Donc permet moi de croire que ton calcul de 100 000$ + primes est un chouia foireux, sauf à rajouter "esclavagisme" sur la liste des griefs que tu rajoutes à charge.
La directrice a un nom, et une page wikipedia.
je comprends bien que visiblement, tu as une forme de mépris pour tout ces gens qui bosse dans le domaine du libre en dehors de la technique et qui gasp le font à temps plein et sont payer pour ça, mais c'est pas dur à vérifier :
https://en.wikipedia.org/wiki/Karen_Sandler
IE, elle a passé 5 ans comme juriste dans 2 cabinets classiques à NY avant d'aller bosser comme juriste au SFLC, puis à la tête de la fondation.
[^] # Re: Coverity
Posté par Misc (site web personnel) . En réponse au journal Idée stupide sur la sécurité du code. Évalué à 5.
Ouais, et puis des distributeurs commerciaux pourraient même payer des gens pour regarder le code et les résultats, genre comme :
http://osdir.com/ml/kde-commits/2013-01/msg08528.html
ou https://www.redhat.com/archives/pki-devel/2012-July/msg00057.html
Ou ce genre de boite pourrait payer des gens pour bosser sur l'analyse statique :
https://fedoraproject.org/wiki/StaticAnalysis
En fait, chaque fois qu'on voit "tel faille a été trouvé par $grosse_boite", c'est pas forcément par hasard. Avec grosse boite étant Google, Suse, IBM, Red Hat, etc.
La rubrique security de LWN permet de voir un peu, ou oss-sec. Par exemple, comme c'est vendredi, ici, on voit bien qu'il y a eu un audit de code de systemd :
http://seclists.org/oss-sec/2013/q4/4
( bien sur, le fait d'avoir des gens payé à faire ça, ça implique pas qu'on fasse pas aussi des choses en tant que communauté, et pour ma part, je compte bien m'attaquer à ça et prêcher la bonne parole comme j'ai fait à l'OWF )
[^] # Re: Vitalité du projet
Posté par Misc (site web personnel) . En réponse à la dépêche GNOME 3.12 : sans domicile. Évalué à 8.
Dépenses != salaires uniquement.
expenditures, c'est les dépenses, ça inclue les salaires et les frais remboursé par la fondation ( comme par n'importe quelle boulot ).
Par exemple, ça prends en compte les voyages, l'hotel, la nourriture, et les divers choses qui sont payés par l'employeur ( impôts à la source aux US, assurance chômage privé, etc, etc ).
Par exemple, je vois que les couts de voyages des commerciaux qui montent vers du 3000€ par mois, ça va vite vers du 36 000€ par an, soit la moitié des 100 000$ au taux de change du jour. Donc même si je suppose que la directrice de la fondation bouge moins que mes collègues, si je rajoute divers choses, je pense qu'elle est payé aussi bien que dans le privé (voir moins, car bon, une avocate de profession avec un petit paquet d'xp, ça doit gagner quand même pas mal quand je vois les tarifs que pratique la mienne), mais je doute qu'elle soit super bien payé non plus.
[^] # Re: Attention à ne pas mélanger...
Posté par Misc (site web personnel) . En réponse au journal Gnome, l'outbreak après l'outreach?. Évalué à 6.
Non, de ce que j'ai vu en parlant avec des membres de la fondation, ils ont le compte. Ils ont juste pas les fonds de roulements, car comme tout le monde ayant déjà organisé un événement bénévole avec sponsors, l'argent sort parfois avant de rentrer ( vu que les sponsors payent après coup ).
[^] # Re: Apache : que de différences entre deux distributions !
Posté par Misc (site web personnel) . En réponse au journal Dépèche de ouf en préparation !!!!. Évalué à 3.
Y a plusieurs raisons.
Raison historique, parfois, genre le packageur a fait ça il y a 10 ans et il change pas pour pas briser la compatibilité.
Arrangement des packageurs pour faire cohabiter 2 distros en même temps ( genre parfois /etc/toto et /etc/toto2 ), exemple, nsd sur Debian.
Parfois, le paquet rajoute des fonctionnalités en plus ( genre a2enmod pour Debian ).
[^] # Re: meme sa façon d'argumenter est nulle
Posté par Misc (site web personnel) . En réponse au journal Dépèche de ouf en préparation !!!!. Évalué à 4.
Apache est un cas quand même assez extreme. À coté, tu as des trucs comme postgrey, nginx, auditd pour ne citer que 3 exemples qui me viennent à l'espirt en regardant une debian ou y a pas de souci de nommage vis à vis des autres distributions.
On peut aussi imaginer avoir des switchs de compilations comme c'est justement déjà le cas pour le placement des répertoires, et donc s'intégrer dans l'actuel.
Aprés tout, si les distributions se retrouvent à mettre des patchs sur les pages de man, c'est pas très différent.
Et on peut aussi se dire que pour les nouveaux services, le fichier sera déjà de base, ce qui va réduire les risques de divergences.
[^] # Re: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par Misc (site web personnel) . En réponse au journal Dépèche de ouf en préparation !!!!. Évalué à 6.
Je pense que tu te rajoutes une contrainte sorti de nulle part. Certains scripts debian utilise par exemple start-stop-daemon et c'est pas spécifié dans la lsb. Donc soit tu considères que les scripts sont pas portables d'une distro à une autre malgré le fait d'être lsb-compliant et donc la limitation n'a aucun sens. Soit c'est un bug, et voila ce que tu as à corriger. ( j'ai juste vu puppet, nginx, mcstrans vite fait, mais tu as le temps de faire un audit complet ).
Enfin ça, c'est si ton affirmation "il manque quoi" n'est pas juste une formule rhétorique, car la, tu sembles plus dire que y a des problèmes, mais c'est pas urgent alors personne devrait bosser dessus.
[^] # Re: meme sa façon d'argumenter est nulle
Posté par Misc (site web personnel) . En réponse au journal Dépèche de ouf en préparation !!!!. Évalué à 10.
Ok, alors systemd résoud plusieurs soucis.
Tout d'abord, ça permet d'arreter un démon de manière sur. Sur dans le sens ou on est sur qu'il le fait. Plus de trucs qui trainent aprés un crash d'un process lancé par apache qui lance un cgi qui lance un truc à la con qui plante en faisant un pipe.
Plus de race condition comme dans le script bind de Debian.
Ensuite, ça permet de résoudre le souci des interfaces haut niveau de pas avoir d'API à utiliser. Par exemple, un projet comme cockpit (http://cockpit-project.org/) utilise les API, au lieu de lancer le script d'init avec un code de retour non assuré. Ou ça permet de changer de maniére fiable le nom de domaine de la machine (hostnamectl), l'arrangement du clavier et de la console (localectl), l'heure et l'usage ou pas de ntp. Gnome devait avoir un code relativement compliqué pour s'adapter à la façon de faire de chaque distro pour un taf globalement la même partout, à savoir lancer ntpd.
Enfin, il permet de lancer les services dans un environnement propre. Cad sans groupe supplémentaire (genre, si le programmeur se plante et change d'abord l'uid avant le gid, si il change le gid sans mettre à zero la liste des groupes supplémentaires), sans variable d’environnement parasites (genre, si quelqu'un avec un shell en allemand relance apache, alors les pages en php vont utiliser les locales allemandes pour le tri alphabétique).
Normalement, tu es censé utilisé service pour régler le 2nd souci, mais d'expérience, tout le monde ne le fait pas. Et pour le premier, ma fois, j'ai du trouvé 3 bugs comme ça, genre https://bugzilla.redhat.com/show_bug.cgi?id=1000722 , https://bugzilla.redhat.com/show_bug.cgi?id=894626
Et ça arrive aussi à d'autres programmes :
https://bugzilla.redhat.com/show_bug.cgi?id=130112
https://bugzilla.redhat.com/show_bug.cgi?id=828436
( et ça, c'est juste dans mon historique firefox )
Et pour finir, ça réduit aussi la maintenance des distros car tu peux mettre en commun les unités de services, c'est plus facile pour les mainteneurs débutants, donc ça réduit la courbe d'apprentissage pour eux.
J'ose croire que ça réponds à la question.
[^] # Re: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par Misc (site web personnel) . En réponse au journal Dépèche de ouf en préparation !!!!. Évalué à 10.
j'ai pas la bande passante pour dire tout ce qui manque, mais par exemple, le manque flagrant de suite de tests est un manque.
Upstart a une suite de test. Systemd a une suite de test. SysVInit a rien. Donc voila, commence déjà par ça.
Sauf à dire "j'ai pas besoin de tester, je sais que tout marche comme il faut".
# Bareos vs bacula
Posté par Misc (site web personnel) . En réponse au journal Bacula : ça bouge dans la sauvegarde !. Évalué à 10.
En fait, j'ai croisé l'auteur de bareos ce weekend. De ce qu'il me dit, le fork a commencé parce que la version libre de bacula n'avait plus d'évolution vu que c'est un logiciel open-core ). Et depuis le fork, soudainement, ça change ( iel eoc de bouge à nouveau ).
Il m'a aussi dit que la FSF dit qu'il n'y a plus de souci avec le code et que le copyright du code appartient à la FSF, que l'auteur de bacula a ralé parce qu'il a commité le code dans git mais que c'était "par erreur", mais qu'il est resté la pendant 6 mois et a eu plusieurs commits.
La partie sur la FSF est vérifiable :
http://www.bacula.org/git/cgit.cgi/bacula/tree/bacula/LICENSE
La partie sur "y a plus eu de souci" semble aussi vérifiable en regardant la keynote de la conférence, mais j'ai pas cherché.
J'ai pas fouillé le reste, mais j'aurais tendance à dire que le mélange "on donne le code à la FSF pour faire du proprio à coté" me parait curieux. Et forker, ça fait parti de la règle du jeu du libre, donc je vois pas en quoi ça peut être un souci de copyright. À coté, les codeurs de bareos peuvent pas se payer car ils doivent payer un avocat pour des charges qu'ils ne connaissent pas.
Perso, j'aurais tendance à plutôt partir vers bareos, ne serais que parce que le business model est plus propre.
[^] # Re: comme on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Fedora.next. Évalué à 5.
Ben du coup, tu peux comparer le fait que dans les 2 cas, ça donne une nouvelle méthode de déploiment.
Dans un cas, c'est docker, qui va te donner un modèle de déploiment à la lxc, centré sur les applications sous forme d'un tarball.
Dans l'autre, tu as Fedora-atomic, utilisant ostree, qui te donne aussi un mode de déploiment différent du mode classique, et différent de docker.
Donc ouais, ç'est comparable sur ce point. Ensuite, que les 2 trucs soient différents est un enfoncage de porte ouvertes évident, mais justement, ça montre bien le coté innovant de Fedora qui explore divers pistes.